Date: Wed, 25 Jan 2012 22:01:46 -0800 From: Tim Kientzle <tim@kientzle.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: arm@freebsd.org Subject: Re: FreeBSD and BeagleBone Message-ID: <4574F194-D23A-47DC-863B-33B31AEBDC04@kientzle.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 Jan 21, 2012, at 3:29 PM, 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
>>> 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 =85 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>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4574F194-D23A-47DC-863B-33B31AEBDC04>