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.
Kevin