# FreeBSD for ESPRESSOBin Marvell Armada 3700?



## KDragon75 (May 27, 2019)

Hello everyone, I'm quite green with the ARM and SBC scene and need some help getting started. I recently got an ESPRESSObin as the title may suggest. In retrospect, this is not the best supported board out there. I do know it will happily run FreeBSD as the pfSene project/Netgate is using in in there production SG-1100.

I need to know more about building the images and if the FreeBSD is statically linked to the load address (Is that the correct terminology?). I would love to find a guide that not only walks me through the process of building a full system image but also explains the entire process and why each step is what it is.

I know this is a bit open ended and I may be missing a lot of basics here but I appreciate any and all help and links.


----------



## balanga (May 27, 2019)

Not sure how to install it but here is confirmation that some version of FreeBSD runs on it:-

_View: https://www.reddit.com/r/PFSENSE/comments/adj0jb/announcing_netgates_espressobinbased_sg1100/_


----------



## KDragon75 (Jun 2, 2019)

I'm not looking to make this into a firewall using prebuilt systems. My goal is simply to boot to FreeBSD in any capacity. I have access to the pfSense images as we have one of the SG-1100 units at work that I get to tinker with. However, I am unable to get even the recovery image to boot. Presently I get stuck with the below messages. I also get the same when using the aarch64 installer image.

```
>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: UFS
   Probing 1 block devices.... done
    UFS found no partitions
Failed to load '/boot/loader.efi'
panic: No bootable partitions found!
## Application terminated, r = -22
```

So It looks like bootaa64.efi is running but for whatever reason, but for whatever reason it will not find /boot/loader.efi. Does bootaa64.efi contain the UFS module or is this still depending on the uboot environment? Everything in uboot is set to load form FAT partitions.

slice 1 (FAT)
  /efi/bootaa64.efi
  /armada-3700.dtb
slice 2 (UFS)
  /boot/loader.efi
  /the reset of the system

Again, I am new to SBCs and UEFI for that mattor. This is intended as a learning exercise more than anything.


----------



## acheron (Jun 2, 2019)

You should look at how images for aarch64 are created or download an image of a board and inspect its ESP.


----------



## KDragon75 (Jun 8, 2019)

Now that I have had some time to look into this, I see /efi/bootaa64.efi is what's running. I have this all on the sdcard at this point with the same layout as before but it still does not see the UFS partition. Does bootaa64.efi have it's own UFS driver or does this still depend on das uboot for file system access? If the latter is the case, I need to re build uboot with ufs or preferably ZFS.


----------



## KDragon75 (Jun 13, 2019)

Everything I'm reading would suggest this is setup correctly and should at least get to the loader.efi but it's not. Does anyone have any ideas?


----------



## khantroll (Jul 3, 2019)

Hi KDragon! Have you made any progress on this? I'm trying to get there too, with a goal of eventually getting OPNSense running on top of it, but I'm new to the Espressobin.


----------



## ucomp (Jul 3, 2019)

KDragon75 said:


> ```
> >>....
> Failed to load '/boot/loader.efi'
> ..
> ```



This message is familiar to me from Rock64 ....
don`t know the details of the EspressoBin but the Rock64 then only worked on Netboot / no SD card support :








						Rock64
					

Just came across the Rock64   Anyone tried installing FreeBSD on one of these? Seems to be a lot better than an RPi3 for about the same money...




					forums.freebsd.org


----------



## tscho (Jul 5, 2019)

Hi there. I just ordered one of this boards. Do you have any update yet? As soon mine arrived I’ll try to install FreeBSD and post my result


----------



## RobCrowston (Jul 7, 2019)

KDragon75 said:


> Now that I have had some time to look into this, I see /efi/bootaa64.efi is what's running. I have this all on the sdcard at this point with the same layout as before but it still does not see the UFS partition. Does bootaa64.efi have it's own UFS driver or does this still depend on das uboot for file system access? If the latter is the case, I need to re build uboot with ufs or preferably ZFS.



Minimal implementations of the UFS and ZFS drivers for the EFI bootloader are in /usr/src/stand/efi/boot1/, with some pieces in /usr/src/stand/libsa/. These are part of the ingredients to make bootaa64.efi.
How are you building u-boot? Did you build it in the way that EspressoBin recommends?

Can you enumerate the partitions on the disk yourself at the U-Boot prompt, before you attempt to boot FreeBSD?


----------



## KDragon75 (Jan 6, 2020)

RobCrowston said:


> Minimal implementations of the UFS and ZFS drivers for the EFI bootloader are in /usr/src/stand/efi/boot1/, with some pieces in /usr/src/stand/libsa/. These are part of the ingredients to make bootaa64.efi.
> How are you building u-boot? Did you build it in the way that EspressoBin recommends?
> 
> Can you enumerate the partitions on the disk yourself at the U-Boot prompt, before you attempt to boot FreeBSD?


I have not built uboot from scratch. This getting a bit out of my depth.


----------



## escape (Feb 16, 2020)

Some experiences with the EspressoBIN and FreeBSD. First of all the uBoot needs to be updated. The Armbian project has some preconfigured available.

In v5 the Topaz switch is configurable from uBoot. It works as a switch. First port index '0' is connected to the CPU, indexes 1 to 3 are the visible RJ45 ports and the last ones are management ports to be configured as a serial management port if read from the available document. Is there a serial management tool to get and set register addresses of the switch chip of the board from the FreeBSD? It looks like it is a MII interface ('SNI' mentioned).

There is no documentation available from Marvell to use the network chip unless you are a corporate user. The only document found was "Marvell Link Street 88E6060". It is older and similar. In uBoot and Linux source code the same code is used for both of the models. The document describes memory addresses and bits in them to configure the switch. There is a remark of restricted material to be accessed with NDA and a placeholder of information not shown.

There is a 'switch' command in uboot. For example `switch write 0 0x04 0x7E` disables the forwarding of the packets from the CPU interface, the `mvneta0`. There is no setting available to set the port to be used separately. It could be the `isolation` setting not available in 6060. This v5 is not a community router board. And not to mention, the board is first a switch before it is configured. It looks like the v5 is just a switch.

It looks like the instructions to use the board are secret and closed from the community users. EspressoBIN v5 is a good NAS or similar device. It should not be considered as a community card based firewall or a router.

The release of the community card should help in developing the commercial products. Maby some kind of _a community support rating  _should be given by the communities with explanations to recognize these issues before anyone uses time buying the card and using the time to configure it. For example the Netgate pfSense (as a commercial product) looks like a good product to buy to be used as a firewall and a router. It uses the same board. How is it different? There is no sense in the community card v5.

Ok. And as a remark, the SCSI SATA/PATA -disk is available only from the uBoot in FreeBSD version 12.1. The FreeBSD does not give access with the current device tree file (if it has anything to do with it) or with the added 'ada' support compiled in the kernel.


----------



## tscho (Feb 16, 2020)

I own a V7 and if I got it right the things which differentiates from v5 to v7 are small things like RAM size, CPU speed and some details like JTAG etc.

Why did you have to update the uBoot? My v7 booted slightly adjusted 13 HEAD with the shipped uBoot. What I didn't figure out is, how to boot the kernel automatically, I always need to issue the following. Does your ESPRESSObin auto boots after you updated uBoot?

```
set currdev=disk0p2
boot
```

I think the switch is not different from v5 to v7. I can change the ports configuration of the switch with ETHERSWITCHCFG(8). What I did is, configure VLANs sub-interfaces on the mvneta0 and than assign the ports to the VLANS. I'm planing to switch my router with the ESPRESSObin in the upcoming days


----------



## escape (Feb 16, 2020)

The installer made the correct settings. It boots directly to login -prompt. It created `/dev/da0p1` and `/dev/da0s2` partitions. Note the 'p' and 's' the installer gave. Additionally I had to copy`boot1.efi` as a first file in the FAT partition as `boot/efi/BOOTaa64.efi`. As a second file the startup.nsh. In UEFI the order is first with a correct filename, if not found, it boots from the first file in the disk. Instructions in URL uses `loader.efi` instead. The used efi -file here may be from the installer.

It may be possible to apply `/boot.config`:

```
0:da(0,2,)/boot/loader
```
in it. The man page `man -S8 boot` and  `man -S8 boot.config`.

Finally in partitioning only GPT partition table works as mentioned in the installer. MSB won't work. There are only slice-numbers. The 'a' -partition is missing from the installer installed system. If read from the man -page, the boot.config is read from the 'a' -partition. It could be it is not found. I have not tried adding a bsdlabel in `/dev/da0s2`, `bsdlabel -w /dev/da0s2`.

I will compile the etherswitch -tool and try it .


----------



## escape (Feb 16, 2020)

Did I mention the device tree? It had to be copied from the obj -directory. I'm using

```
setenv fdt_name /dtb/marvell/armada-3720-espressobin.dtb
setenv bootcmd 'mmc rescan; usb start; scsi reset; fatload mmc 0:1 $kernel_addr $image_name; fatload mmc 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr'
saveenv
```
from the uboot. What everything is found using it would be good to know. What are the correct memory ranges would be good to know.


----------



## tscho (Feb 16, 2020)

I still can't get my had around with autoboot. What I figured out so far is, that I actually created the the partition as da0s2. I can also start manually with the following command  `set bootargs "rootdev=disk0s2";mmc dev 0; fatload mmc 0:1 $kernel_addr $image_name;fatload mmc 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr`

It doesn't make a difference if I write disk0s2 or disk0p2, it boots. Wit the command you posted, which is similar to the one I had before I get the following:

`## Starting EFI application at 07000000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disk sdhci@d0000.blk...
Card did not respond to voltage select!
Scanning disk sdhci@d8000.blk...
Disk sdhci@d8000.blk not ready
Found 3 disks
Consoles: EFI console
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0:`

You mentioned the installer. How did you set up your ESPRESSObin? Do you also use FreeBSD HEAD?


----------



## escape (Feb 17, 2020)

tscho said:


> can't get my had around with autoboot.


I've checked this. The `BOOTaa64.efi` was from the 12.1-RELEASE installation media. It had the same partitions. The `currdev` or rootfs is usually changed from the`loader.conf`. I had tried the same with the same results.


----------



## napyk (Jun 29, 2020)

tscho said:


> I still can't get my had around with autoboot. What I figured out so far is, that I actually created the the partition as da0s2. I can also start manually with the following command  `set bootargs "rootdev=disk0s2";mmc dev 0; fatload mmc 0:1 $kernel_addr $image_name;fatload mmc 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr`
> 
> It doesn't make a difference if I write disk0s2 or disk0p2, it boots. Wit the command you posted, which is similar to the one I had before I get the following:
> 
> ...



Did you manage to fix your autoboot issue? I have the same problem. I also tried to change currdev/rootdev in loader.conf but it seems that it is ignored.


----------



## iucoen (Jul 23, 2020)

I hacked on this for about a week, and I finally got FreeBSD 12.1-stable working. Here are some notes:

- You need to use EFI. EFI is the only way to boot BSD on arm64.
- The u-boot that's shipped (u-boot-2017.03-armada-17.10) does not have full EFI support. The earliest version that has EFI support is u-boot-2018.03. But when I tried to compile that it wouldn't boot. I ended up manually backporting the efiloader changes from 2018.03 to the u-boot-2017.03-armada-17.10 branch and got something that works. And you do need a Linux machine to build this.
- You really need to run stable/12, which has the dts files for this board, and the kernel support to parse the dtb. If you care about controlling the on-board switch chip, then you need a couple of more changes from master.
- Even on CURRENT, the mvneta (nic) driver has a bug which can corrupt packets. There is a small patch to fix this.

I have git trees for all of the above. I'll throw them up on github and post links here.


----------



## iucoen (Jul 23, 2020)

As promised, my github trees:









						GitHub - iucoen/freebsd-espressobin: FreeBSD src tree (read-only mirror)
					

FreeBSD src tree (read-only mirror). Contribute to iucoen/freebsd-espressobin development by creating an account on GitHub.




					github.com
				











						GitHub - iucoen/u-boot-marvell: Marvell Armada U-Boot
					

Marvell Armada U-Boot. Contribute to iucoen/u-boot-marvell development by creating an account on GitHub.




					github.com
				




For building firmware image, follow the directions here exactly:





						ESPRESSObin Wiki | Build From Source - Bootloader
					

ESPRESSObin Wiki




					wiki.espressobin.net
				




My u-boot-tree already has the v7 patches applied. For the 2 other firmware trees, download the patches and apply them yourself. Also, make sure you use the exact version of Linaro toolchain as prescribed. I first tried to build with the default arm cross compiler toolchain installed on Ubuntu, and the resulting binary would not boot.

To create a boot image, follow the general EFI boot scheme. Partition the SD card with GPT, create a small FAT partition for EFI, and copy over /boot/boot1.efi from rootfs to /efi/boot/bootaa64.efi on the EFI partition. Also place the the dtb file in the same partition, and tell u-boot to load both, and run bootefi. The DTB file will then be passed from EFI to the kernel by loader. Make sure you use the dtb that's built from the FreeBSD source tree if you want the networking and switch to work.


----------



## diizzy (Jul 27, 2020)

Nice work, can you please upstream your patches?
Use reviews.freebsd.org for base related changes


----------



## napyk (Aug 10, 2020)

iucoen said:


> As promised, my github trees:
> 
> 
> 
> ...



Sadly I am unable to get your u-boot to work. My espressobin starts to boot and then freezes at the DLL TUNING part. Has anyone had a similar issue?


```
TIM-1.0
WTMI-armada-17.10.5-32a03bb
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           10
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 5, CPU VDD voltage: 1.108V

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

Fill memory before self refresh...done
Now in Self-refresh Mode
Exited self-refresh ...
Self refresh Pass.
DDR self test mode test done!!
Vref read training
===================
Final vdac_value 0x00000022
Vref write training
===================
Final vref_value 0x0000001F

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [7,30,1b]
   DLL 0xc0001050[29:24]: [9,30,1c]
   DLL 0xc0001054[21:16]: [b,32,1e]
   DLL 0xc0001054[29:24]: [d,30,1e]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074
```


----------



## napyk (Aug 12, 2020)

I am quite new to compiling freebsd from source and found it extremely difficult to get the right information, so I want to share how it worked for me.

I compiled inside a virtual machine based on FreeBSD 12.1 stable and logged in as root user. Then i installed bash and exported the build environment variable


```
pkg install bash
bash
mkdir /root/obj
export MAKEOBJDIRPREFIX=/root/obj
```

Then i cloned iucoen freebsd version and compiled it (u can use "make -jX" where X is the amount of compiling processes to speed things up). I had to specify the target architecture because my vm runs on amd64.

```
git clone https://github.com/iucoen/freebsd-espressobin
cd freebsd-espressobin
make TARGET=arm64 TARGET_ARCH=aarch64 buildworld
make TARGET=arm64 TARGET_ARCH=aarch64 buildkernel
```

After compiling has finished I had to create the dtb file for the espressobin which will be located in
"/root/obj/root/freebsd-espressobin/arm64.aarch64/sys/GENERIC/armada-3720-espressobin.dtb"

```
make TARGET=arm64 TARGET_ARCH=aarch64 builddtb FDT_DTS_FILE=/root/freebsd-espressobin/sys/gnu/dts/arm64/marvell/armada-3720-espressobin.dts
```

Next up I prepared the SD card (make sure you pick the right path, for me it was "/dev/da1") and installed the source.

```
gpart destroy -F /dev/da1
gpart create -s gpt /dev/da1
gpart add -t efi -s 40m /dev/da1
gpart add -t freebsd /dev/da1
newfs_msdos -F 32 -c 1 /dev/da1p1
newfs -U -L FreeBSD /dev/da1s2
mount /dev/da1s2 /mnt
make TARGET=arm64 TARGET_ARCH=aarch64 DESTDIR=/mnt installkernel installworld distribution
cp /mnt/boot/boot1.efi /root/bootaa64.efi
umount /mnt
```

Now I copied the dtb file and efi over to the fat partition.


```
mount -t msdosfs /dev/da1p1 /mnt
mkdir -p /mnt/EFI/BOOT
cp /root/bootaa64.efi /mnt/EFI/BOOT/
cp /root/obj/root/freebsd-espressobin/arm64.aarch64/sys/GENERIC/armada-3720-espressobin.dtb /mnt/EFI/BOOT/
umount /mnt
```

Now my only problem left is u-boot. I am able to boot the image with the original u-boot (u-boot-2017.03-armada-17.10) but there is the autoboot problem. I also tried a precompiled u-boot image from armbian which seems to be
u-boot-2018.03-devel-18.12.3 but with this u-boot version I am not able at all to boot into the os. I am getting the erros below:

```
FreeBSD/arm64 EFI loader, Revision 1.1
(Sat Dec 14 19:58:45 UTC 2019 tsgan@nanopc-t4)

   Command line arguments: loader.efi console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/nfs rw ip=0.0.0.0:0.0.0.0:10.4.50.254:255.255.255.0:marvell:eth0:none nfsroot=0.0.0.0:/srv/nfs/,tcp,v3 pci=pcie_bus_safe
   Image base: 0x7000000
   EFI version: 2.70
   EFI Firmware: Das U-Boot (rev 0.00)
   Console: efi (0x1000)
   Load Path: /MemoryMapped(0x1,0x7000000,0x70a41a0)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
Setting currdev to disk0:
Setting currdev to net0:
net0: cannot set rx. filters (status=3)
bootp: no reply
No response for RARP request
net_open: RARP failed
net0: cannot set rx. filters (status=3)
bootp: no reply
No response for RARP request
net_open: RARP failed
net0: cannot set rx. filters (status=3)
bootp: no reply
No response for RARP request
net_open: RARP failed
Startup error in /boot/lua/loader.lua:
LUA ERROR: cannot open /boot/lua/loader.lua: input/output error.
```


----------



## iucoen (Aug 15, 2020)

napyk said:


> Sadly I am unable to get your u-boot to work. My espressobin starts to boot and then freezes at the DLL TUNING part. Has anyone had a similar issue?



Yes. That's because you are not using the exact version of Linaro toolchain. Use 5.2-2015.11-2. Download both the 32bit and 64bit versions.


----------



## iucoen (Aug 15, 2020)

napyk said:


> ```
> cp /mnt/boot/loader.efi /root/bootaa64.efi
> ```



You copied the wrong efi file. You should copy /boot/boot1.efi to bootaa64.efi. boot1.efi then loads loader.efi, and it tells loader.efi which partition it's loaded from, so loader.efi can then load the kernel.


----------



## napyk (Aug 16, 2020)

Thanks for your hints. Last time I followed the espressobin wiki for the toolchain setup. I checked again and noticed that I have to set

```
export PATH=/home/espressobin/toolchain/gcc-linaro-5.2-2015.11-2-x86_64_aarch64-linux-gnu/bin:$PATH
```

instead of:

```
export PATH=$PATH:/home/espressobin/toolchain/gcc-linaro-5.2-2015.11-2-x86_64_aarch64-linux-gnu/bin
```

so that the right toolchain is used. Compiling worked fine and I am able to boot now. Auto booting into freebsd works also. Nice work


----------



## iucoen (Mar 13, 2021)

FreeBSD 13.0 works out of the box!

Here are some easier directions to get started:
0. Build and flash the uboot firmware with EFI support using the git tree I posted.
1. Download the RPI aarch64 image. This image already has the EFI directory structure in place, as well as DTB in the fat boot partition.
2. Configure uboot:
setenv bootcmd 'load mmc 0:1 $fdt_addr dtb/marvell/armada-3720-espressobin.dtb; load mmc 0:1 $kernel_addr EFI/BOOT/bootaa64.efi; bootefi $kernel_addr $fdt_addr'
env save
3. You should be able to boot into FreeBSD 13. The EFI loader loads the device tree and passes to the kernel.


----------



## Chrisfbsd (May 4, 2021)

iucoen thank you for the work on this, I was able to follow your instructions and got up and running in no time.  

tscho
Just wondering if you could share how you configured the vlans with ETHERSWITCHCFG(8). 
"What I did is, configure VLANs sub-interfaces on the mvneta0 and than assign the ports to the Vlans" 

I see ports 0 - 5 then 4 vlangroup

Right now it looks like all ports are members of each vlan group.  Did you just remove all members of each vlangroup leaving just the ports assigned respectively? 

Thanks


----------



## tscho (May 20, 2021)

Chrisfbsd said:


> iucoen thank you for the work on this, I was able to follow your instructions and got up and running in no time.
> 
> tscho
> Just wondering if you could share how you configured the vlans with ETHERSWITCHCFG(8).
> ...


Sorry for the late answer. Somehow I did not get notified about your reply.

I'm still on FreeBSD 13.0-CURRENT but will switch soon to RELEASE, hopefully this doesn't change anything about my config. I've a rc.d script which I run at every start. It contains the following:



> /sbin/etherswitchcfg config vlan_mode dot1q
> /sbin/etherswitchcfg port1 pvid 1
> /sbin/etherswitchcfg vlangroup0 vlan 1 members 0,1
> /sbin/etherswitchcfg vlangroup33 vlan 33 members 0t,2t port2 pvid 33
> ...


----------



## Chrisfbsd (May 23, 2021)

tscho said:


> Sorry for the late answer. Somehow I did not get notified about your reply.
> 
> I'm still on FreeBSD 13.0-CURRENT but will switch soon to RELEASE, hopefully this doesn't change anything about my config. I've a rc.d script which I run at every start. It contains the following:


No worries thanks for sharing the startup script.


----------



## Chrisfbsd (May 29, 2021)

tscho

I tried creating a script in /etc/rc.d called switch and setting the permissions with chmod 555



> #!/bin/sh
> #
> 
> # PROVIDE: switch
> ...



sorry I'm pretty new to freeBSD so I'm not sure how the start up scripts need to be setup.


----------



## tscho (May 29, 2021)

I more or less adopted the Practical rc.d scripting in BSD. This is the result. Not beautiful, but it works



> #!/bin/sh
> # PROVIDE: etherswitch
> . /etc/rc.subr
> . /etc/network.subr
> ...


----------



## iucoen (Jun 11, 2021)

tscho said:


> I more or less adopted the Practical rc.d scripting in BSD. This is the result. Not beautiful, but it works



There is an easier way... You don't need to create a separate service. Just create a script called /etc/start_if.mvneta0 , and this script will be executed as part of bringing up the mvneta0 interface. Also the MAC address is randomly generated on every boot, so you probably want to fix that in this script as well in the first line:
ifconfig mvneta0 ether "<mac address of your device>"


----------



## Chrisfbsd (Jun 11, 2021)

tscho said:


> I more or less adopted the Practical rc.d scripting in BSD. This is the result. Not beautiful, but it works


tscho Thanks for the startup script.  I implemented it and it looks like it's causing a kernal panic on boot up. Just wondering if you had any issues like this.  I added ether_enable="Yes" to /etc/defaults/rc.conf and put your script in /etc/rc.d/

I'll be re-applying the RPI aarch64 image and I'll use a different SD card in the event I have a bad image/card.  

I'll also try to execute the etherswitchcfg commands in the script one at a time to try and see what one may be causing the kernal panic.  

Thanks again for all the assistance


----------



## tscho (Jun 11, 2021)

Chrisfbsd said:


> tscho Thanks for the startup script.  I implemented it and it looks like it's causing a kernal panic on boot up. Just wondering if you had any issues like this.  I added ether_enable="Yes" to /etc/defaults/rc.conf and put your script in /etc/rc.d/
> 
> I'll be re-applying the RPI aarch64 image and I'll use a different SD card in the event I have a bad image/card.
> 
> ...


I didn't have any problems at all. Maybe you can try what Crisfbsd suggested


----------



## Phanlink43 (Sep 28, 2021)

Hello. I am a new freebsd user. 
   I bought an ESPRESSOBIN v7 board and installed FreeBsd 12 OS on it. I tried to connect ESPRESSOBIN to PLX8311 (PCI - brigde of broadcom) via MiniPCIe but didn't get the expected result. 
   Please guide me how to connect ESPRESSOBIN to PLX8311 on FreeBsd.


----------



## SirDice (Sep 28, 2021)

Phanlink43 said:


> I bought an ESPRESSOBIN v7 board and installed FreeBsd 12 OS on it.


Try 13.0 instead.


----------



## Phanlink43 (Sep 28, 2021)

This is the log after booting up my FreeBsd 12.2, The Armada 3700 PCIe Bus Controller driver did not show up there. What can i do to get the driver up? or someone has driver's files please help me to solve this. Tks!!!


----------



## SirDice (Sep 28, 2021)

Phanlink43 said:


> This is the log after booting up my FreeBsd 12.2


Again, try 13.0-RELEASE instead.


----------



## escape (Sep 29, 2021)

I had tried a v5 maby a year ago and don't remember PCI bridge or PLX8311. Finally after some time the 13.0 version had the drivers for the Topaz switch. The 12.2 booted (as the 13 does now) using the device tree -file. Have you tried that? The u-boot can be used from the serial line. The device tree file can be tested. I've compiled the device tree in the kernel and don't (anymore) remember having problems with the PCI bridge. How about the device tree file? (Sorry I don't at the moment have access to check this from the board.)

esc


----------



## Phanlink43 (Sep 30, 2021)

Phanlink43 said:


> to solve this. Tks





SirDice said:


> Again, try 13.0-RELEASE instead.


I've already use the 13.0-RELEASE FreeBsd and the result is the same as I did on the 12.2 Freebsd. Do you have any other solution for this? Tks a lot


----------



## SirDice (Sep 30, 2021)

Phanlink43 said:


> Do you have any other solution for this?


Nope, 13.0-RELEASE would have been your best bet as that has all the latest bells and whistles. Have a look at escape 's suggestions though.


----------



## Phanlink43 (Sep 30, 2021)

escape said:


> I had tried a v5 maby a year ago and don't remember PCI bridge or PLX8311. Finally after some time the 13.0 version had the drivers for the Topaz switch. The 12.2 booted (as the 13 does now) using the device tree -file. Have you tried that? The u-boot can be used from the serial line. The device tree file can be tested. I've compiled the device tree in the kernel and don't (anymore) remember having problems with the PCI bridge. How about the device tree file? (Sorry I don't at the moment have access to check this from the board.)
> 
> esc


- this is the uboot result:
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x10b5     0x8111     Bridge device           0x04

- I used device tree armada-3720-espressobin-v7.dts in FreeBsd source version 13.0. After booting system,  execute the pciconf -lv command, the result did not show anything as it did by uboot
root@:~ # pciconf -lv

root@:~ # 

- I wonder if I correctly used device tree? Or could you please guild me to use device tree as you did. Tks so much!


----------



## escape (Oct 1, 2021)

A good source of information was this URL . It was everything I've found right now from the old bookmarks. The Linux for example the Armbian instructions are good here as well considering the .dtb or .dts -files. The U-Boot is the same. It looks like the boot loader was already found, is the kernel booting? Should the file go as a parameter to it? (Actually I don't remember). Thanks.  Its nice there are many using the same device.


----------



## Phanlink43 (Oct 8, 2021)

escape said:


> A good source of information was this URL . It was everything I've found right now from the old bookmarks. The Linux for example the Armbian instructions are good here as well considering the .dtb or .dts -files. The U-Boot is the same. It looks like the boot loader was already found, is the kernel booting? Should the file go as a parameter to it? (Actually I don't remember). Thanks.  Its nice there are many using the same device.


Tks for your reply.
I could not find “pcie bus controler driver” from kernel booting.
I read the intruction from your link but there are some issues i did not get it. Could you please explain and help me to solve it?
- The first issue is which “pcie bus controler driver” you used?
- Second is: what your device -tree is? Can you share the device tree parameters for me
Thank you


----------



## SleepWalker (Oct 13, 2021)

Hey!
What do you think of the MochaBin-5G SBC








						MochaBin-5G SBC offers 10GbE, WiFi 6, 5G for $159 and up (Crowdfunding) - CNX Software
					

Globalscale Technologies has a follow-up to their low-cost ESPRESSOBin SBC based on Marvell Armada 3700LP SoC. The MochaBin-5G SBC is powered by a Marvell




					www.cnx-software.com
				




How difficult will it be to port FreeBSD to a Marvell Armada 7040


			https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-7040-product-brief-2017-12.pdf


----------



## iucoen (May 11, 2022)

FYI if you are on 13.0 and booting off SD card, do not upgrade to 13.1 yet. There is a regression with the sdhci_xenon0 that prevents the system from booting. I filed a bug here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263928


----------



## SleepWalker (May 29, 2022)

Hi!
I am trying to run FreeBSD 13.0-RELEASE on MochaBin-5G.
I installed OS on SATA disk. And I try
`BootROM - 2.03
Starting AP IOROM 1.02
Booting from eMMC 0
Found valid image at boot postion 0x002
lmv_ddr: mv_ddr-devel-18.12.0-g2e20f5d (May 27 2022 - 18:06:24)
mv_ddr: completed successfully
BL2: Initiating SCP_BL2 transfer to SCP

U-Boot 2018.03-devel-18.12.3-g926d08c7ce (May 27 2022 - 17:55:54 +0000)

Model: Marvell Armada 7040 Mochabin development board
SoC: Armada7040-B0; AP806-B0; CP115-A0
Clock:  CPU     1400 [MHz]
        DDR     800  [MHz]
        FABRIC  800  [MHz]
        MSS     200  [MHz]
LLC Enabled (Exclusive Mode)
DRAM:  8 GiB
Bus spi@700680 CS0 configured for direct access 00000000f9000000:0x1000000
SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB
EEPROM configuration pattern not detected.
Comphy chip #0:
Comphy-0: SGMII1        3.125 Gbps
Comphy-1: USB3_HOST0
Comphy-2: SATA0
Comphy-3: SATA1
Comphy-4: SFI0          10.3125 Gbps
Comphy-5: PEX2
UTMI PHY 0 initialized to USB Host0
UTMI PHY 1 initialized to USB Host1
SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up (Gen1-x1, Bus0)
MMC:   sdhci@6e0000: 0
Loading Environment from SPI Flash... OK
Model: Marvell Armada 7040 Mochabin development board
Net:   eth0: mvpp2-0 [PRIME], eth1: mvpp2-1, eth2: mvpp2-2
Hit any key to stop autoboot:  0
Marvell>>`
`Marvell>> scsi scan
scanning bus for devices...
  Device 0: (1:0) Vendor: ATA Prod.: NT-256 Rev: SN95
            Type: Hard Disk
            Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)

Marvell>> load scsi 0 $kernel_addr_r  efi/boot/bootaa64.efi
262620 bytes read in 26 ms (46.3 MiB/s)
Marvell>> bootefi  $kernel_addr_r
## Starting EFI application at 07000000 ...
Scanning disk sdhci@6e0000.blk...
Scanning disk ahci_scsi.id1lun0...
Found 5 disks
"Synchronous Abort" handler, esr 0x96000046
elr: 0000000000063728 lr : 000000000005b51c (reloc)
elr: 000000007ff9c728 lr : 000000007ff9451c
x0 : 00000000bffff000 x1 : 0000000000000000
x2 : 000000000000001f x3 : 00000000bffff018
x4 : 00000000bffff008 x5 : 0000000000000000
x6 : 0000000000000003 x7 : 00000000bffff020
x8 : 000000007f900000 x9 : 0000000000000008
x10: 0000000000000006 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000022
x14: 0000000000000000 x15: 00000000ffffffff
x16: 0000000000000001 x17: 0000000000000008
x18: 000000007f628dd0 x19: 00000000bffff000
x20: 000000007e620040 x21: 000000007e61f040
x22: 0000000007000000 x23: 0000000000000000
x24: 000000007f6249e0 x25: 000000007ffa4000
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007f6c4670 x29: 000000007f624980

Resetting CPU ...

resetting ...`
GlobalScale U-boot does not work correctly with efi.
Any ideas?


----------



## Phishfry (Aug 25, 2022)

iucoen said:


> FreeBSD 13.0 works out of the box!
> 
> Here are some easier directions to get started:
> 0. Build and flash the uboot firmware with EFI support using the git tree I posted.



Can you please elaborate on the uboot steps?
I bought a second board after the USB OTG connector fell of the first board.

EspressoBin 5.01 1G 2CS. No emmc.

So I have built u-boot for Hummingboard in the past and I want to try and build it for Espressobin.
I see you using Linero to compile. What were the blockers for building on Freebsd?
Should I use the newest u-boot or try with an older tree?

What about the blob it produces? Do you simply flash it to the first sectors of the disk or do you place the file on the EFI fat partition?

My SPI has an old version on it and I am struggling with that.
I need to know u-boot fine details for this board.
I am using SATA recovery method and so far my first two files have failed me.
So I reverted to the boot jumpers, where I found out the manual is either wrong or wonky.
Much like this thread alludes to.








						Load U-Boot from SD card on Espressobin v5
					

Hi everybody, I have an Espressobin v5 in front of me and by default it boots fine from SATA: Quote TIM-1.0 WTMI-armada-17.10.5-bb8f823 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.132V Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to origina...




					forum.armbian.com
				




I really want to run FreeBSD on this board.
I was surprised there is no GENERICSD card image for aarch64.
Scraping junk from RPi image felt odd.

What are fellow EspressoBin users booting from?
SD Card is giving me fits.
I moved on to SATA and USB for the time being.
Do you use the SPI? I assumed you could disable the SPI from jumpers but that seems elusive.

Are your boot jumper settings correct with Espressobin Wiki pictures?

I know that FreeBSD-13.1 is broken for this platform and I am using 13.0-RELEASE


----------



## Phishfry (Aug 25, 2022)

I can pull up this screen. It is the only menu I can get:

```
E
>?
h/? - print this help screen
r yyyyyyyy - read register/memory at address yyyyyyyy in hex
w yyyyyyyy zzzzzzzz - write zzzzzzzz to address yyyyyyyy in hex
j yyyyyyyy - jump to address yyyyyyyy in hex
x y - change the boot mode, where y is in hex
a - UART control passed to AP CPU ROM
c - UART control passed to CM3 CPU ROM
>
E
>
```

I do have a setting with jumpers where I see a series of carrots onscreen >>>>>>>>>>>>>>>
Nothing comes up. Escape key press twice fastly will bring up an exclamation point  >>>>>>>>>>>>>!
Perhaps this is a tftp boot.

I had a working u-boot screen with the original SD card. Unfortunatly I overwrote it.


----------



## iucoen (Sep 13, 2022)

Phishfry said:


> Can you please elaborate on the uboot steps?
> 
> What about the blob it produces? Do you simply flash it to the first sectors of the disk or do you place the file on the EFI fat partition?


The uboot blob is combined with the rest of the firmware and flashed into the SPI. I did it over UART, using directions here: http://wiki.espressobin.net/tiki-index.php?page=Bootloader+recovery+via+UART


----------



## iucoen (Sep 13, 2022)

SleepWalker said:


> GlobalScale U-boot does not work correctly with efi.
> Any ideas?


See an earlier post by me from 2 years ago. You need to compile uboot and the marvell firmware yourself, flash the SPI. I shared a git tree with all the UEFI changes backported to the same version of uboot that espressobin ships with.

Nevermind... you are asking about the Mochabin. I haven't received mine yet. But if what you are saying is true and their u-boot sill doesn't work with EFI, then that's a shame.


----------



## Phishfry (Sep 17, 2022)

iucoen said:


> The uboot blob is combined with the rest of the firmware and flashed into the SPI.


Any chance you could get that u-boot blob for SPI to me? I really don't want to mess with that Linero toolchain.
Will it allow SATA booting? What is your boot target?


----------



## iucoen (Sep 18, 2022)

Phishfry said:


> Any chance you could get that u-boot blob for SPI to me? I really don't want to mess with that Linero toolchain.
> Will it allow SATA booting? What is your boot target?


I boot from SD card. But I think it might work with SATA too. Just set the $kernel variable to the right path.

I am not able to attach binary files in the forum. Can you DM me your email address I'll send it over.


----------

