FreeBSD and BeagleBone

[Rafal Jaworowski]

On 2012-01-22, at 00:29, Tim Kientzle wrote:

> 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.

Yes, this output following the ## Starting.. line is from ubldr.

When looking at the memory layout make sure the new linking address of ubldr (and the loading address as well) doesn't confilct with U-Boot private range (code, data, stack etc.) after relocation to RAM. It typically would relocate itself by the very end of available RAM in the system, but there's no strict rule, at least for ARM systems -- I have seen configurations where it would be the opposite and use space at the beginning of RAM. If you overun this area for any reason (which is very easy, there's no protection) it would certainly crash.

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

In general yes, the challenge is how to do this in a smart and flexible way: loader/ubldr is built as part of the world which you don't want to entagle with platform specific knobs. On the other hand a configurable like this is specific to some board (not even a chip, soc or a familiy, anybody can have their U-Boot configured differently underneath..), so the question is how to convey this knowledge.

Rafal