On Wed, Mar 23, 2011 at 3:11 PM, Grant Likely grant.likely@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: U-Boot: git://git.linaro.org/boot/u-boot-linaro-stable.git
Kernel: git://git.linaro.org/kernel/linux-linaro-2.6.38.git
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 mpurate=720' boot
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 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...
g.
On Fri, 2011-03-25 at 22:46 -0600, Grant Likely wrote: [...]
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 didn't appear to have any problems with dtb relocation on a beagleboard. It does get put at the bottom of RAM just before the kernel, are there things down there like initial stacks or command-line args that could corrupt the dtb?
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...
Thanks for posting to the mailing lists. I was just about to start tackling the off-by-one ramdisk sizes when I thought I'd check the list to see if anyone had been there before me :-)
On Sat, Mar 26, 2011 at 9:33 AM, Tixy tixy@yxit.co.uk wrote:
On Fri, 2011-03-25 at 22:46 -0600, Grant Likely wrote: [...]
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 didn't appear to have any problems with dtb relocation on a beagleboard. It does get put at the bottom of RAM just before the kernel, are there things down there like initial stacks or command-line args that could corrupt the dtb?
No, the dtb replaces the command line and other ATAGs, so no worries there. The initial stack is much higher in RAM, and the initial page tables start at 16k from the base of ram.
The beagleboard sets CONFIG_SYS_BOOTMAPSZ to the first 16k or RAM which is an obsolete limitation and the kernel can handle the dtb located anywhere in RAM. I've got a couple of patches that eliminates the requirement to set CONFIG_SYS_BOOTMAPSZ, but in the current code that means it tries to relocate the dtb to the end of RAM which doesn't seem to work. Relocating to a lower address works fine from my testing.
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...
Thanks for posting to the mailing lists. I was just about to start tackling the off-by-one ramdisk sizes when I thought I'd check the list to see if anyone had been there before me :-)
:-) The tree I posted as a reply to the Device Tree on ARM status report email shows my current trees. There were 2 initrd off-by-one bugs, one in the kernel and one in u-boot. Both are fixed in my tree.
g.
-
Grant Likely -
Tixy