Crash when running kernel exactly same as release hash

[kenrestivo]

I have followed the procedure outlined here to attemp to build an exact replica of the arm7 release Raspberry Pi kernel with Device Tree for the 2 B.

I'm following the procedure for sleuthing out what is the correct kernel version as outlined here:
#486

I have built commit 0be82f7 which was found here raspberrypi/firmware@47bd0f0

And I am also using the mkknlimg script (which had to be backported from rpi-3.18.y HEAD, I guess it wasn't in this kernel revision), and Device Tree is indeed running because it is reporting

Jul  1 23:15:44 valve kernel: [    0.000000] Machine model: Raspberry Pi 2 Model B

And dtc -I fs /proc/device-tree also suceeds, so indeed device tree is happening.

However. at boot time there is a kernel crash:

Jul  1 23:15:44 valve kernel: [    1.716033] ------------[ cut here ]------------
Jul  1 23:15:44 valve kernel: [    1.720791] WARNING: CPU: 1 PID: 1 at arch/arm/mach-bcm2709/armctrl.c:148 armctrl_xlate+0x1b4/0x27c()
Jul  1 23:15:44 valve kernel: [    1.730064] Modules linked in:
Jul  1 23:15:44 valve kernel: [    1.733134] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.7-v7+ #1
Jul  1 23:15:44 valve kernel: [    1.740595] [<80018a44>] (unwind_backtrace) from [<80013cf4>] (show_stack+0x20/0x24)
Jul  1 23:15:44 valve kernel: [    1.748371] [<80013cf4>] (show_stack) from [<80647914>] (dump_stack+0x9c/0xd4)
Jul  1 23:15:44 valve kernel: [    1.755618] [<80647914>] (dump_stack) from [<8002a9a8>] (warn_slowpath_common+0x84/0xa0)
Jul  1 23:15:44 valve kernel: [    1.763729] [<8002a9a8>] (warn_slowpath_common) from [<8002aa80>] (warn_slowpath_null+0x2c/0x34)
Jul  1 23:15:44 valve kernel: [    1.772533] [<8002aa80>] (warn_slowpath_null) from [<800253fc>] (armctrl_xlate+0x1b4/0x27c)
Jul  1 23:15:44 valve kernel: [    1.780909] [<800253fc>] (armctrl_xlate) from [<8007ea08>] (irq_create_of_mapping+0x70/0x124)
Jul  1 23:15:44 valve kernel: [    1.789458] [<8007ea08>] (irq_create_of_mapping) from [<80500e70>] (of_irq_get+0x48/0x58)
Jul  1 23:15:44 valve kernel: [    1.797660] [<80500e70>] (of_irq_get) from [<804029e8>] (platform_get_irq+0x2c/0x9c)
Jul  1 23:15:44 valve kernel: [    1.805428] [<804029e8>] (platform_get_irq) from [<8001c9b4>] (cpu_pmu_device_probe+0x174/0x3c8)
Jul  1 23:15:44 valve kernel: [    1.814235] [<8001c9b4>] (cpu_pmu_device_probe) from [<804027c0>] (platform_drv_probe+0x54/0xb4)
Jul  1 23:15:44 valve kernel: [    1.823039] [<804027c0>] (platform_drv_probe) from [<8040060c>] (driver_probe_device+0x14c/0x3a8)
Jul  1 23:15:44 valve kernel: [    1.831930] [<8040060c>] (driver_probe_device) from [<80400958>] (__driver_attach+0x9c/0xa0)
Jul  1 23:15:44 valve kernel: [    1.840392] [<80400958>] (__driver_attach) from [<803fe5ac>] (bus_for_each_dev+0x7c/0xb0)
Jul  1 23:15:44 valve kernel: [    1.848594] [<803fe5ac>] (bus_for_each_dev) from [<803fffb8>] (driver_attach+0x2c/0x30)
Jul  1 23:15:44 valve kernel: [    1.856616] [<803fffb8>] (driver_attach) from [<803ffbb4>] (bus_add_driver+0x170/0x22c)
Jul  1 23:15:44 valve kernel: [    1.864637] [<803ffbb4>] (bus_add_driver) from [<8040128c>] (driver_register+0x88/0x108)
Jul  1 23:15:44 valve kernel: [    1.872746] [<8040128c>] (driver_register) from [<804026ec>] (__platform_driver_register+0x64/0x6c)
Jul  1 23:15:44 valve kernel: [    1.881814] [<804026ec>] (__platform_driver_register) from [<809129a8>] (register_pmu_driver+0x24/0x54)
Jul  1 23:15:44 valve kernel: [    1.891242] [<809129a8>] (register_pmu_driver) from [<80008950>] (do_one_initcall+0xec/0x228)
Jul  1 23:15:44 valve kernel: [    1.899789] [<80008950>] (do_one_initcall) from [<8090df6c>] (kernel_init_freeable+0x1ec/0x290)
Jul  1 23:15:44 valve kernel: [    1.908506] [<8090df6c>] (kernel_init_freeable) from [<80645538>] (kernel_init+0x1c/0xf8)
Jul  1 23:15:44 valve kernel: [    1.916703] [<80645538>] (kernel_init) from [<8000fb88>] (ret_from_fork+0x14/0x20)
Jul  1 23:15:44 valve kernel: [    1.924308] ---[ end trace f31bcedd8fd8f99b ]---

Booting the stock kernel does NOT cause this crash! But... the kernels were-- if I am to believe the documentation in that issue-- built from the same source tree and commit.

The dts files and overlays are exactly copied from the stock firmware distribution; I have not copied over the dts files from the kernel build.

Why is this happening? What is broken? It seems like this should work.

[popcornmix]

Note: rpi-4.0.y is now the default kernel.
rpi-3.18.y should work but won't get any further fixes.

In general you should use the dtb files you have built. In theory they should be the same if they came from the same git hash, but obviously something is wrong, so I'd try copying them (and you will have to copy them when changing kernel version).

What firmware are you on? (vcgencmd version).

[kenrestivo]

Thanks. I'll try 4.0.y.

I was able to get everything working by using the latest 3.18.y tree with the latest dtb compiled from that tree. Apparently the mmc had been moved out of the board support file into the dts.

I am using straight Debian Jessie, not any Raspbian firmware. There is no vcgencmd. I have been looking around for the source code for vcgencmd but have not been able to find it.

[popcornmix]

https://github.com/raspberrypi/userland/tree/master/host_applications/linux/apps/gencmd

[kenrestivo]

Apr 21 2015 14:42:19
Copyright (c) 2012 Broadcom
version 2d5ad04b63af4233440c3f7c8587108223201102 (clean) (release)

FYI

[D3m0n1q733rz]

Here's the issue according to the the compiler:

arch/arm/mach-bcm2709/armctrl.c: In function ‘armctrl_unmask_irq’:
arch/arm/mach-bcm2709/armctrl.c:137:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
unsigned int data = (unsigned int)irq_get_chip_data(d->irq);

If the two were broken down into declaration and then code, it would be alright and the compiler should handle it properly and even compile it just the same as it was intended due to pre-processing.

[pelwell]

That's a warning - we don't like them, but it doesn't affect the generated code. As that file doesn't exist in the rpi-4.4.y tree (which we will move to soon) there is no point in fixing the warning now.