How to use u-boot-beaglebone port?

Thu Mar 19 15:19:40 UTC 2015

On Mar 17, 2015, at 4:18 PM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Tue, 2015-03-17 at 15:30 -0400, Paul Mather wrote:
>> On Mar 17, 2015, at 2:34 PM, Ian Lepore <ian at 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 at 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 at 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 at 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.

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.
> 
> 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

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=..." to the make invocation in that.

Cheers,

Paul.