On Tue, Mar 11, 2014 at 5:35 AM, Peter Robinson
<pbrobinson(a)gmail.com> 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.
Peter