From owner-freebsd-arm@FreeBSD.ORG Thu Mar 19 15:19:40 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C216284; Thu, 19 Mar 2015 15:19:40 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 512CDF11; Thu, 19 Mar 2015 15:19:40 +0000 (UTC) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 52F1B9EB; Thu, 19 Mar 2015 11:19:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: How to use u-boot-beaglebone port? From: Paul Mather In-Reply-To: <1426623518.62241.11.camel@freebsd.org> Date: Thu, 19 Mar 2015 11:19:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33BDB9B4-2226-4B51-A7CF-BA6D0277E92A@gromit.dlib.vt.edu> References: <17B779D7-2962-4455-9062-51411F316648@gromit.dlib.vt.edu> <986F5E5D-C784-4BEF-81E3-49A9F27C0E8F@kientzle.com> <1426534773.95554.15.camel@freebsd.org> <1426607993.25614.9.camel@freebsd.org> <1426617259.62241.3.camel@freebsd.org> <1426623518.62241.11.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:19:40 -0000 On Mar 17, 2015, at 4:18 PM, Ian Lepore wrote: > On Tue, 2015-03-17 at 15:30 -0400, Paul Mather wrote: >> On Mar 17, 2015, at 2:34 PM, Ian Lepore wrote: >>=20 >>> On Tue, 2015-03-17 at 14:21 -0400, Paul Mather wrote: >>>> On Mar 17, 2015, at 11:59 AM, Ian Lepore wrote: >>>>=20 >>>>> On Tue, 2015-03-17 at 09:55 -0400, Paul Mather wrote: >>>>>> On Mar 16, 2015, at 3:39 PM, Ian Lepore wrote: >>>>>>=20 >>>>>>> On Sun, 2015-03-15 at 19:57 -0700, Tim Kientzle wrote: >>>>>>>>> On Mar 12, 2015, at 5:59 PM, Paul Mather = wrote: >>>>>>>>>=20 >>>>>>>>> Has anyone successfully used the sysutils/u-boot-beaglebone = port? >>>>>>>>>=20 >>>>>>>>> I managed to build [1] and install it today. I tried to = install it to the SD card FAT partition, as per the README, and the = result was an unbootable system. >>>>>>>>>=20 >>>>>>>>> When I copied the u-boot.img file as u-boot.img (rather than = the bb-uboot.img as suggested in the README), I got it to start up to = the "U-Boot#" prompt. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Apparently, no one ever patched the port to use bb-uboot.img = and bb-ubldr >>>>>>>> as the name. >>>>>>>>=20 >>>>>>>> I did this in Crochet when I was experimenting with having = multiple >>>>>>>> U-Boots on a single SD card image. That experiment was to try >>>>>>>> to see what would be required to build single images that = booted on >>>>>>>> multiple different devices. >>>>>>>>=20 >>>>>>>=20 >>>>>>> When I created the u-boot-beaglebone port I specifically removed = that >>>>>>> bb- prefix stuff, because there will never be a unified image = that runs >>>>>>> on both rpi and beaglebone [*]. I had hoped someone would = update >>>>>>> crochet to use the new ports and this is one of the minor = changes that >>>>>>> would be needed on the crochet side. >>>>>>>=20 >>>>>>> -- Ian >>>>>>>=20 >>>>>>> [*] Because armv6 !=3D armv7 in this case. While armv6 is = synonymous with >>>>>>> armv7 for most purposes in freebsd, the rpi is the exception to = that in >>>>>>> that it really IS armv6, and that leads to the kernel being = built with >>>>>>> different cache maintenance routines that don't work on armv7. >>>>>>=20 >>>>>>=20 >>>>>> Does the sysutils/u-boot-beaglebone boot the BeagleBone Black for = you? As I reported earlier in the start to this thread, I can't get it = to boot the system for me. >>>>>>=20 >>>>>> I've copied MLO, u-boot.img, and /boot/ubldr to the FAT = partition, but I just get to where U-Boot loads ubldr and then pauses = before starting over again in a loop. >>>>>>=20 >>>>>> Are there some other files that need to be copied to the FAT = partition, or are those three files, plus the defaults compiled into = u-boot.img sufficient to boot the BeagleBone Black from SD card? >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Paul. >>>>>=20 >>>>> Yep, it works for me on BBW and BBB. The only time I've seen a = totally >>>>> silent lockup like that is when the loadaddr variable in the uboot = env >>>>> didn't match the UBLDR_LOADADDR value when ubldr was compiled. = For BB, >>>>> those values are usually 0x88000000, iirc. If you do a "readelf = -a >>>>> ubldr" on your build system you should see a line like >>>>>=20 >>>>> Entry point address: 0x88000074 >>>>>=20 >>>>> and whatever it is should be your uboot loadaddr + 0x74. >>>>=20 >>>> My current /boot/ubldr entry point address appears to be 0x1000074, = which seems to be derived from the default set in = /usr/src/sys/boot/arm/uboot/Makefile. >>>>=20 >>>> What would I need to put in uEnv.txt to get such a ubldr to boot = via the sysutils/u-boot-beaglebone port files? Would I just need to = have the single line "loadaddr=3D1000000" in uEnv.txt, or would I have = to reproduce the whole environment embedded into u-boot.img? (Do the = settings in uEnv.txt replace entirely those in u-boot.img?) >>>>=20 >>>>> You should only need MLO, u-boot.img, and ubldr on the fat = partition. >>>>> (There is an optional uEnv.txt that can be there, but it's not = required >>>>> to boot.) >>>>=20 >>>> It looks like your supposition above is correct and a mis-matching = loadaddr variable is likely to blame. >>>>=20 >>>> Is a loadaddr of 0x1000000 correct for a BBB? >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>=20 >>> The address is a physical ram address, so you can't just make up any >>> number -- there has to be actual ram at that address on the board, = and >>> the address must not conflict with where u-boot itself is loaded and >>> where the kernel will be loaded. >>>=20 >>> I think the BB ram starts at 0x80000000, so 0x10000000 won't work. = The >>> right fix would be to recompile ubldr with UBLDR_LOADADDR set to >>> 0x88000000. >>=20 >> What is the best place to set this? >>=20 >> My current /boot/ubldr is the product of a native build. I looked = through the source code and it seems the only place that sets this is = /usr/src/sys/boot/arm/uboot/Makefile, where we have this: >>=20 >> # Address at which ubldr will be loaded. >> # This varies for different boards and SOCs. >> UBLDR_LOADADDR?=3D 0x1000000 >>=20 >>=20 >> The "?=3D" makes me think this is just a fallback default to stop the = build from breaking and that UBLDR_LOADADDR needs to be set accordingly = for each different ARM system. If that is so, and we know what the = UBLDR_LOADADDR should be for the BBB (or at least that the default won't = work because there's no RAM there on the BBB), then why doesn't -CURRENT = set a value such that a working ubldr is built? (I'd prefer ubldr not = to be built at all than a non-working version be built.) >>=20 >> I presume I could set this in /etc/make.conf on my BBB. Could I put = it in my BBB kernel config file (which seems a good place for it)? >>=20 >> Many thanks for the help and information. I plan to rebuild = /boot/ubldr with a UBLDR_LOADADDR of 0x88000000. >>=20 >> Cheers, >>=20 >> Paul. >=20 > The value needs to be different for every system/board, so the value = in > the makefile is just a placeholder to let test builds finish. It = can't > go into the kernel config because ubldr is built with world, not = kernel. Maybe the value should be changed to 0xdeadbeef to make it more obvious = it is just a placeholder? :-) > If you only build for BBB on your build host, you could just put the > value in /etc/make.conf because it doesn't mean anything for an x86 > build. I think you can also set it as an env var. If you build for > more than one arm board then you probably need a wrapper script that > supplies such per-board values to the build. >=20 > The crochet script is one such wrapper, appropriate for people who = want > to occasionally build a complete image. If you're doing development > work where you need to repeatedly rebuild, another type of wrapper > script (and other developer info) can be found here:=20 >=20 > https://wiki.freebsd.org/FreeBSD/arm/crossbuild Thanks for the info and the crossbuild link (which documents the = UBLDR_LOADADDR issue under "Pesky details":). The crossbuild Wiki page = looks very good. Now I have an installed BBB and RPi, I usually try to do native build = updates. I have a script for rebuilding world and kernel, and I'll add = an appropriate "-DUBLDR_LOADADDR=3D..." to the make invocation in that. Cheers, Paul.=