>>>>>> 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@lists.denx.de/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