# FreeBSD 11 on BBB, bad CRC



## coredumb (Feb 5, 2017)

Hi,
all of my attempts to boot a Beaglebone Black with FreeBSD-11.0-STABLE-arm-armv6-BEAGLEBONE-20170203-r313108 failed with running into a boot loop. U-Boot is telling me this on the console (which my Computer is connected serially to):


```
U-Boot SPL 2017.01-rc3 (Feb 03 2017 - 04:53:18)
Trying to boot from MMC1MMC partition switch failed
*** Warning - MMC partition switch failed, using default environment

reading u-boot.img
reading u-boot.img


U-Boot 2017.01-rc3 (Feb 03 2017 - 04:53:18 +0000)

CPU  : AM335X-GP rev 2.0
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - bad CRC, using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found FreeBSD U-Boot Loader (bin)
reading ubldr.bin
227304 bytes read in 25 ms (8.7 MiB/s)
## Starting application at 0x82000000 ...
prefetch abort
pc : [<0000019c>]          lr : [<00000000>]
reloc pc : [<e08b019c>]    lr : [<e08b0000>]
sp : 9df2f200  ip : 00000000     fp : 00000002
r10: 9ff9fc2c  r9 : 9df2fed8     r8 : 9df3a948
r7 : 9ff520d5  r6 : 00000002     r5 : 82000000  r4 : 820000bc
r3 : 82000000  r2 : 00000040     r1 : 82037758  r0 : 81ffff08
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...
```
This basically is an upgrade en block, since I am not aware of any arm repo to fetch packages from. So I took the latest image to have the BBB most recent again. This is what I did to prepare the micro-sdcard to boot from:

`#> dd if=FreeBSD-11.0-STABLE-arm-armv6-BEAGLEBONE-20170203-r313108.img of=/dev/disk2 bs=1m conv=sync`

This is a proven way to go, it worked with 10.3 before. The only different thing between now and then is an 8 gig card instead a 2 gig one. So I also tried a 2 gig card running the same command but no success, either.
Of course after download I checked the the integrity of that image file using the SHA512 hash value, which matched.

Is there anything I'm missing here? Have things changed in FreeBSD significantly so that the proven way isn't anymore that I overlooked anywhere? Thanks for help in advance.


----------



## acheron (Feb 6, 2017)

u-boot was updated recently, try to use an old version.


----------



## aragats (Nov 10, 2017)

It looks like using the mainstream u-boot instead of the version tailored for FreeBSD.
coredumb, have you resolved it?

Can somebody explain why the mainstream u-boot cannot run ubldr.bin?


----------



## Phishfry (Nov 10, 2017)

Here they talk about it.
"Because ubldr is currently an ELF executable, it is linked to a
specific load address.  Since different boards have their initial
memory at different locations, ubldr must be linked separately for
boards with different initial memory layouts."
https://github.com/freebsd/crochet/tree/master/board/NewBoardExample


----------



## aragats (Nov 10, 2017)

Yes, that's correct for ubldr, that's why ubldr.bin was created ― as a self-relocatble executable.


----------



## parakleta (Nov 23, 2017)

I'm guessing here, but I think it's due to the absence of the U-Boot API.  In the previously linked crochet NewBoardExample there is the following:



> ubldr uses the "U-Boot API" to call into U-Boot for
> hardware interaction.  This requires adding code similar
> to the following to the appropriate board configuration
> in _uboot_sources_/include/configs/someboard.h:
> ...


----------



## balanga (Nov 27, 2017)

aragats said:


> Yes, that's correct for ubldr, that's why ubldr.bin was created ― as a self-relocatble executable.



Can someone explain the difference between ubldr and ubldr.bin? Do I need both of them to boot FreeBSD?


----------



## aragats (Nov 27, 2017)

There was a discussion a couple of years ago:
https://lists.freebsd.org/pipermail/freebsd-arm/2015-July/011906.html

You need only ubldr.bin.


----------



## balanga (Nov 27, 2017)

aragats said:


> There was a discussion a couple of years ago:
> https://lists.freebsd.org/pipermail/freebsd-arm/2015-July/011906.html
> 
> You need only ubldr.bin.



Can you tell me whether ubldr.bin should replace kernel.bin in the instructions here ?


----------



## aragats (Nov 27, 2017)

balanga said:


> Can you tell me whether ubldr.bin should replace kernel.bin in the instructions here ?


I guess that's correct, you should use ubldr.bin instead, which, in its turn, will load the kernel from /boot of the UFS partition.
You can also stop u-boot's autoboot by pressing _Space_ within 2 seconds at the very beginning to launch its shell and try boot manually:
	
	



```
load usb 0:1 0x900000 ubldr.bin
go 0x900000
```


----------



## balanga (Nov 27, 2017)

aragats said:


> I guess that's correct, you should use ubldr.bin instead, which, in its turn, will load the kernel from /boot of the UFS partition.
> You can also stop u-boot's autoboot by pressing _Space_ within 2 seconds at the very beginning to launch its shell and try boot manually:
> 
> 
> ...



What would I need to do to tftpboot?

How does this sound?

```
setenv ipaddr 192.168.1.23
setenv serverip 192.168.1.43
tftp 0x900000 ubldr.bin
bootm 0x900000
```
I realise I need to set up 192.168.1.43 as a tftp server with the correct ubldr.bin in /tftpboot but should I expect to get some sort of FreeBSD logo, msg or somesuch to show I'm heading in the right direction?

I'm using this U-Boot

```
U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:21:31 -0700)
Seagate GoFlex Home

SoC:   Kirkwood 88F6281_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  256 MiB
```


----------



## aragats (Nov 27, 2017)

I don't have any experience with tftpboot. With local files ubldr.bin passes control to FreeBSD kernel, which is local too. Then you can see normal serial console output of the booting process.
With network boot I'm not sure what it expects and where. However, you should see the same boot messages.
Do you have any local storage? I think the problem is that ubldr.bin doesn't know where to search for the kernel file.


----------



## balanga (Nov 27, 2017)

aragats said:


> I don't have any experience with tftpboot. With local files ubldr.bin passes control to FreeBSD kernel, which is local too. Then you can see normal serial console output of the booting process.
> With network boot I'm not sure what it expects and where. However, you should see the same boot messages.
> Do you have any local storage? I think the problem is that ubldr.bin doesn't know where to search for the kernel file.



At the moment my primary concern is to get U-Boot to load ubldr.bin and take it from there. Then at least I'm managing to load FreeBSD.

I do have local storage and will try to use that once I know I'm moving in the right direction. It's taken me months to get this far but it's a completely alien environment and progress is slow.

My eventually hope to be be able to boot FreeBSD directly from flash in a Seagate GoFlexHome unit..
but maybe the hardware requirements are too small...


----------



## balanga (Nov 28, 2017)

balanga said:


> What would I need to do to tftpboot?
> 
> How does this sound?
> 
> ...



Apparently `bootm` is for Linux. `bootelf` should be used for FreeBSD... although `go` seems to be used in most examples I've seen...


----------



## aragats (Nov 28, 2017)

balanga , where is your root filesystem? Is it also on the network?
I believe, by default, ubldr.bin expects to find the kernel in /boot/kernel.


----------



## balanga (Nov 28, 2017)

At the moment I have not yet set up a root filesystem, I just wanted to see if I could load ubldr.bin and see what happens next. Presumably ubldr.bin would output some errors msgs after starting up.

All the old guides... 
https://wiki.freebsd.org/FreeBSDMarvell
https://cooltrainer.org/freebsd-kirkwood/building/
say I should be using kernel.bin and I have found such a file in the build but I'm guessing it's redundant


----------

