How to use u-boot-beaglebone port?

Paul Mather paul at gromit.dlib.vt.edu
Tue Mar 17 18:21:30 UTC 2015


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.



More information about the freebsd-arm mailing list