On Tue, Mar 11, 2014 at 8:50 AM, Robert Nelson <robertcnelson@xxxxxxxxx> wrote: > On Tue, Mar 11, 2014 at 8:09 AM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>> On Tue, Mar 11, 2014 at 5:35 AM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>>>>> 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.. Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
