On Tue, May 20, 2014 at 12:12 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 20 May 2014, Kevin Hilman wrote:
On Thu, May 8, 2014 at 11:49 AM, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
Dear Nicolas Pitre,
On Wed, 7 May 2014 23:30:47 -0400 (EDT), Nicolas Pitre wrote:
You still can pass initrd=<phys_addr>,<size> to the kernel via the cmdline string. And if neither ATAGS nor DT are provided you'll have to use the cmdline to pass the memory information as well. This can be hardcoded into the kernel with CONFIG_CMDLINE.
However a better solution that doesn't involve hardcoding anything in the kernel if you want to use a multi-platform kernel is to use CONFIG_ARM_APPENDED_DTB and:
make zImage cat arch/arm/boot/zImage your_board.dtb > zImage_with_dtb mkimage ... # to create uImage using zImage_with_dtbObviously you shouldn't have to rebuild your_board.dtb each time you build a new kernel for the same board.
I believe Kevin is already using appended DTB, because the bootloader on the OpenBlocks platform does not have DT support at all, so appended DTB is really the only way to get a mainline kernel to work on this platform.
So what you suggest is that Kevin could use the /chosen/bootargs DT node to encode the initrd address, and then make sure he loads the initrd from the bootloader at the corresponding address?
I'm finally getting around to testing big endian, and I can confirm that using initrd= on the command-line (via DT chosen/bootargs) is working fine for loading an initrd.
The problem now is how to automate this when I'm given a zImage, a pre-built DTB (binary), and a separate ramdisk. Especially when that same unmodified DTB can boot fine for other kernels.
It would be much easier if I could just change the cmdline via u-boot, but since the ATAGs dont' work, the kernel doesn't get the u-boot command-line either (even with CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y).
That leaves me with needing to modify a (binary) DTB. Ugh.
You could standardize around an identical ramdisk address for all your targets where that same unmodified DTB is used. The ramdisk address passed by U-Boot on those platforms where U-Boot is able to do so would be overwritten by the one specified on the kernel cmdline, but if they are the same address then you'll be fine.
I really don't like building in these kinds of assumptions. And even if I did, I still need to modify the DTB somplace. Either boot-time patching, or at build time. Build time is ruled out because I don't have control over all the builds that I'm trying to boot test.
After a little tinkering though, it turns out runtime patching the DTB isn't that hard. DTC can un-compile a dtb to the original .dts. I can then append a dts fragment with a new chosen node, (re)compile that and I get a new dtb with an updated chosen node. I'm playing with that now and it seems workable.
Kevin