Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Mar 2015 14:18:38 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Paul Mather <paul@gromit.dlib.vt.edu>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: How to use u-boot-beaglebone port?
Message-ID:  <1426623518.62241.11.camel@freebsd.org>
In-Reply-To: <C9CD0919-10D4-4F7A-B90B-157762189DAD@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> <F016BFCC-8CAA-4AE6-8142-40A9B69BD707@gromit.dlib.vt.edu> <1426607993.25614.9.camel@freebsd.org> <F7EAB879-E70D-4ED5-8C5B-3B21FBED123A@gromit.dlib.vt.edu> <1426617259.62241.3.camel@freebsd.org> <C9CD0919-10D4-4F7A-B90B-157762189DAD@gromit.dlib.vt.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-03-17 at 15:30 -0400, Paul Mather wrote:
> On Mar 17, 2015, at 2:34 PM, Ian Lepore <ian@freebsd.org> wrote:
> 
> > On Tue, 2015-03-17 at 14:21 -0400, Paul Mather wrote:
> >> On Mar 17, 2015, at 11:59 AM, Ian Lepore <ian@freebsd.org> wrote:
> >> 
> >>> On Tue, 2015-03-17 at 09:55 -0400, Paul Mather wrote:
> >>>> On Mar 16, 2015, at 3:39 PM, Ian Lepore <ian@FreeBSD.org> wrote:
> >>>> 
> >>>>> On Sun, 2015-03-15 at 19:57 -0700, Tim Kientzle wrote:
> >>>>>>> On Mar 12, 2015, at 5:59 PM, Paul Mather <paul@gromit.dlib.vt.edu> wrote:
> >>>>>>> 
> >>>>>>> Has anyone successfully used the sysutils/u-boot-beaglebone port?
> >>>>>>> 
> >>>>>>> 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.
> >>>>>>> 
> >>>>>>> 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.
> >>>>>> 
> >>>>>> 
> >>>>>> Apparently, no one ever patched the port to use bb-uboot.img and bb-ubldr
> >>>>>> as the name.
> >>>>>> 
> >>>>>> 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.
> >>>>>> 
> >>>>> 
> >>>>> 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.
> >>>>> 
> >>>>> -- Ian
> >>>>> 
> >>>>> [*] Because armv6 != 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.
> >>>> 
> >>>> 
> >>>> 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.
> >>>> 
> >>>> 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.
> >>>> 
> >>>> 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?
> >>>> 
> >>>> Cheers,
> >>>> 
> >>>> Paul.
> >>> 
> >>> 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
> >>> 
> >>> Entry point address:               0x88000074
> >>> 
> >>> and whatever it is should be your uboot loadaddr + 0x74.
> >> 
> >> 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.
> >> 
> >> 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=1000000" 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?)
> >> 
> >>> 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.)
> >> 
> >> It looks like your supposition above is correct and a mis-matching loadaddr variable is likely to blame.
> >> 
> >> Is a loadaddr of 0x1000000 correct for a BBB?
> >> 
> >> Cheers,
> >> 
> >> Paul.
> > 
> > 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.
> > 
> > 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.
> 
> What is the best place to set this?
> 
> 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:
> 
> 	# Address at which ubldr will be loaded.
> 	# This varies for different boards and SOCs.
> 	UBLDR_LOADADDR?=        0x1000000
> 
> 
> The "?=" 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.)
> 
> 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)?
> 
> Many thanks for the help and information.  I plan to rebuild /boot/ubldr with a UBLDR_LOADADDR of 0x88000000.
> 
> Cheers,
> 
> Paul.

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.

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.

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: 

  https://wiki.freebsd.org/FreeBSD/arm/crossbuild

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1426623518.62241.11.camel>