FreeBSD and BeagleBone

[Tim Kientzle]

On Jan 21, 2012, at 3:29 PM, Tim Kientzle wrote:

> On Jan 21, 2012, at 2:13 AM, Rafal Jaworowski wrote:
>> 
>> On 2012-01-21, at 08:34, Tim Kientzle wrote:
>>> 
>>> But ubldr still won't run:
>>> 
>>> U-Boot# fatload mmc 0 0x80008000 ubldr
>>> U-Boot# bootelf 0x80008000
>>> <hang>
>>> 
>>> Anyone else used U-Boot to run ubldr on Arm?
>> 
>> Looking at memory addresses you use for loading etc. the problem you might be hitting is with a linking address range … try to adjust linking addr range in sys/boot/arm/uboot/ldscript.arm to fit your layout and see if this helps.
> 
> That certainly does help.  Setting the ELF linking address to 0x80001000
> gets this far:
> 
> U-Boot# fatload mmc 0 0x82000000 ubldr
> U-Boot# bootelf 0x82000000
> ## Starting application at 0x80001054
> Consoles: U-Boot console
> Compatible API signature found @8ff760c0
> <hang>

Ah.  This turned out to be a bug in U-Boot's
API implementation.  This board doesn't start
up with RAM mapped to address zero, so dereferencing
a NULL pointer leads to a hang.

In api/api_storage.c, dev_stor_get calls get_dev with the
name of the kind of storage currently being enumerated
("ide", "mmc", etc.)  If the board lacks a particular kind of
storage, then the name here is NULL.  get_dev() dereferences
the name pointer when it calls strncmp().

There's a trivial change to get_dev() (in disk/part.c)
to cause it to return NULL if it's called with a NULL name,
but I'm not sure that's the best solution here.
Seems better to modify dev_stor_get instead.

Any thoughts?

Tim