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" Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
