>>>>>>> You may have some success booting by appending the DTB to the kernel. I am >>>>>>> able to boot 3.14 by doing this on a Pandaboard A1 and Pandaboard ES B1. >>>>>>> >>>>>>> 'cat vmlinuz dtb-name > vmlinuz-dtb' >>>>>>> >>>>>>> When the DTB is passed separately there is no output on the console in my >>>>>>> testing. >>>>>> >>>>>> Thank you Paul Whalen for spending some time on this. So it looks like >>>>>> the issue isn't with the kernel and I'm wondering whether our panda >>>>>> uboot has a compile option missing to do with DT support that we've >>>>>> got on other platform uboots that we build. Anyone with any experience >>>>>> can give some ideas in this regard? >>>>>> >>>>>> For some of the newer boards with the different memory options I would >>>>>> think (well from my experience with one of my ES devices) you would at >>>>>> least see part of the boot process before the kernel locks up. >>>>> >>>>> To follow up on this you'll likely want uboot 2014.01 from rawhide [1] >>>>> for the boards with the newer RAM as it has the patch [2] to support >>>>> it in uboot (no idea if there's anything needed for the kernel. >>>>> >>>>> I think the last thing we need to ascertain and fix is why we can't >>>>> boot the panda using FDT as a separate argument vs appended to the >>>>> kernel. If anyone has any ideas about this (I believe it's missing >>>>> from the upstream uboot) or even better patches it would be great if >>>>> you could speak up any time soon ;-) >>>> >>>> Might be a memory collision, what address are you guys using for >>>> default loadaddress/ftdaddress. >>>> >>>> For reference, I've been using: >>>> >>>> loadaddr="0x80300000" >>>> fdtaddr="0x815f0000" >>>> initrdaddr="0x81600000" >>> >>> That is my suspicion, >>> >>> load 0x80300000 >>> initrd 0x81600000 >>> fdt 0x89300000 >>> >>> But the above work fine on both Beagle xM and BBBlack using the same >>> kernel/initd so I would have thought, although would be happily >>> corrected, that it would be similar across the devices with the same >>> components. >> >> Well, unlike the Beagle/BBB u-boot had to deal with a 'high memory' >> situation on the panda, as only the first 750ish is mapped in low. I'd >> shove the fdt address to just under the initrd. > > btw: tom just posted this to u-boot.. > > https://www.mail-archive.com/u-boot@xxxxxxxxxxxxx/msg133919.html > > Might be worth it to move to those defaults.. For reference I've documented the process to boot an out of the box F-20 GA image here: http://nullr0ute.com/2014/03/booting-pandaboard-with-fedora-20-ga/ The fix was so simple! Peter let me know how you get on with your devices, especially the B3 variants, unfortunately I don't have one to test with. There will be a new arm-boot-config on it's way to repos soon with the automated boot fixes but we want to make sure we don't regress anything. Peter _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
