FreeBSD and BeagleBone

Tim Kientzle tim at kientzle.com
Sat Jan 21 23:29:11 UTC 2012


On Jan 21, 2012, at 2:13 AM, Rafal Jaworowski wrote:
> 
> On 2012-01-21, at 08:34, Tim Kientzle wrote:
> 
>> On Jan 20, 2012, at 7:26 AM, Mark Murray wrote:
>> 
>>>> For the moment, I'm more curious about just how far I can push this
>>>> using FreeBSD tools only.
>>> 
>> 
>> 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: ubldr by default is linked against 0x1000000, and the bootelf command would follow this while parsing ELF and placing code/data in memory. If your system config does not allow available RAM in this range it would crash / hang. If this is the case, please 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>

I think I need to track down some more information on the
memory layout U-Boot uses on this board.

I haven't checked yet, but I presume the last lines above
are actually being printed by ubldr through the U-Boot
console routine.  If so, that means I've gotten far enough to use
printf debugging to trace through ubldr and start understanding
how it works and where it's stopping.

Thanks much!

Tim

P.S.  Is it worth trying to generalize the ubldr Makefile
to accept some form of link address specification?



More information about the freebsd-arm mailing list