From owner-freebsd-arm@FreeBSD.ORG Wed Jan 25 22:06:30 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 092AF1065700; Wed, 25 Jan 2012 22:06:30 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 726858FC16; Wed, 25 Jan 2012 22:06:29 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 43F08C384A; Wed, 25 Jan 2012 23:06:28 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 0YLshADXr-Mk; Wed, 25 Jan 2012 23:06:27 +0100 (CET) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7C6D8C3846; Wed, 25 Jan 2012 23:06:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com> Date: Wed, 25 Jan 2012 23:06:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: arm@freebsd.org Subject: Re: FreeBSD and BeagleBone X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:06:30 -0000 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 >>> >>>=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 > >=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