[fedora-arm] Funding for creation of Fedora 20 Pandaboard spin

[Robert Nelson]

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

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.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/