Date: Wed, 25 Jan 2012 23:06:25 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Tim Kientzle <tim@kientzle.com> Cc: arm@freebsd.org Subject: Re: FreeBSD and BeagleBone Message-ID: <AE745CFE-81C8-400C-BAC6-CED7341D0A99@semihalf.com> In-Reply-To: <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <CABt%2Bj0mB4w==h_SQ4YyDM24_wGOjcdZDK9T1N3DqjSkap0VkQw@mail.gmail.com> <E8A24EBE-967D-44F8-A884-3207B3C6F0FE@bsdimp.com> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <CAGW5k5ahyaTest3L0NTe1t%2B%2BYBgpLMkWZNpp=GRyz%2Bg=nMcZLg@mail.gmail.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> <E1RoGMT-000DkR-6a@groundzero.grondar.org> <AEF07CD1-6794-4F04-AF9C-938423FE919B@kientzle.com> <DB160959-A698-415D-AACC-659D6469212E@semihalf.com> <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-01-22, at 00:29, Tim Kientzle wrote: > On Jan 21, 2012, at 2:13 AM, Rafal Jaworowski wrote: >>=20 >> On 2012-01-21, at 08:34, Tim Kientzle wrote: >>=20 >>> On Jan 20, 2012, at 7:26 AM, Mark Murray wrote: >>>=20 >>>>> For the moment, I'm more curious about just how far I can push = this >>>>> using FreeBSD tools only. >>>>=20 >>>=20 >>> But ubldr still won't run: >>>=20 >>> U-Boot# fatload mmc 0 0x80008000 ubldr >>> U-Boot# bootelf 0x80008000 >>> <hang> >>>=20 >>> Anyone else used U-Boot to run ubldr on Arm? >>=20 >> 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. >=20 > That certainly does help. Setting the ELF linking address to = 0x80001000 > gets this far: >=20 > 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> >=20 > I think I need to track down some more information on the > memory layout U-Boot uses on this board. >=20 > 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. >=20 > Thanks much! >=20 > Tim >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE745CFE-81C8-400C-BAC6-CED7341D0A99>