Device Tree on ARM status report - Mar 20
grant.likely at secretlab.ca
Sat Mar 26 04:46:36 UTC 2011
On Wed, Mar 23, 2011 at 3:11 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Tue, Mar 22, 2011 at 04:58:26PM -0700, Andy Doan wrote:
>> On 03/21/2011 02:25 AM, Grant Likely wrote:
>> > Here is the list of hwpacks that should be supported to the best of my
>> > knowledge. Please reply with the hwpacks you can take responsibility
>> > for:
>> > efikamx
>> > igep
>> > imx51
>> > omap3-x11-base
>> > omap3
>> > overo
>> > panda
>> > s5pv310
>> > vexpress
>> Hey Grant,
>> I'm one of the only people with Overo hardware. Its a bit out of my
>> realm of expertise, but I thought I'd give it a shot. All of my
>> knowledge is based on some prior PowerPC FDT work so my assumptions
>> could be off.
>> The kernel's not coming up, so I thought I'd give you a run-down of what
>> I did to see what may have gone wrong.
>> = NOTE: There's always option B - tell me not to bother and someone else
>> will do this :)
>> I worked from the tips of:
>> I built u-boot adding these entries to the include/configs/omap3_overo.h:
>> #define CONFIG_OF_LIBFDT
>> #define CONFIG_SYS_BOOTMAPSZ (8<<20)
>> I then built the kernel using the options you mentioned in this email
>> and added a ".dt_compat" entry to the MACHINE definition in board-overo.c
>> I then made a simple DTS file like what you suggested and compiled it
>> using the DTC package in Natty.
>> I then updated my boot.scr to load to overo.dtb into memory(0x81600000)
>> and update the bootm command to take that address as the 3rd parameter
>> as follows:
>> setenv bootcmd 'fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1
>> 0x81700000 uInitrd; fatload mmc 0:1 0x81600000 overo.dtb; bootm
>> 0x80000000 0x81700000 0x81600000'
>> setenv bootargs ' console=tty0 console=ttyO2,115200n8
>> root=UUID=b1c56ca5-da31-4042-9e1f-3f3144dd9fb6 rootwait ro earlyprintk
>> U-boot starts up and tries to launch the kernel. The kernel does nothing
>> (or at least nothing goes to my serial console):
>> Here's the output:
>> Running bootscript from mmc ...
>> ## Executing script at 82000000
>> reading uImage
>> 4332388 bytes read
>> reading uInitrd
>> 4174199 bytes read
>> reading overo.dtb
>> 312 bytes read
>> ## Booting kernel from Legacy Image at 80000000 ...
>> Image Name: Linux-2.6.38+
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 4332324 Bytes = 4.1 MiB
>> Load Address: 80008000
>> Entry Point: 80008000
>> Verifying Checksum ... OK
>> ## Loading init Ramdisk from Legacy Image at 81700000 ...
>> Image Name: Ubuntu Initrd
>> Image Type: ARM Linux RAMDisk Image (uncompressed)
>> Data Size: 4174135 Bytes = 4 MiB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 81600000
>> Booting using the fdt blob at 0x81600000
>> Loading Kernel Image ... OK
>> Loading Ramdisk to 8fc04000, end 8ffff137 ... OK
>> Loading Device Tree to 807fc000, end 807ff137 ... OK
>> Starting kernel ...
>> Uncompressing Linux... done, booting the kernel.
> Can you boot with the new u-boot, or new u-boot + new kernel using the old non-fdt boot command?
I've played with this a bit on my panda. It appears that when U-Boot
relocates the .dtb, it either moves it to a location that the kernel
cannot read during early boot, or it corrupts it when it is moved.
Either way, the kernel is hooped when it tries to parse the device
tree data, it falls back to the old ATAGs support, but there aren't
any ATAGs either so it cannot actually boot. I've got it working at
the moment by hacking u-boot to /not/ relocate the .dtb blob which
gets me much farther, but it also looks like it also causes problems
with the initramfs image. It currently has an oops when it cannot
mount the initramfs. Still investigating...
More information about the linaro-dev