[Work In Progress] OPNsense Ported into ARM Devices

[nekoprog]

Hi, for the record @tsgan have successfully use freebsd12 with nanopi, means that freebsd12 is a solid base but opnsense still need to port it's current code from freebsd 11.2 to 12, after that tools.git will support most of the pies.

Quite busy lately to check into tools.git, but  I will try it with freebsd12 and modified device configs that will use freesd12 source.

[NetGobbler]

I thought it was dependent on HardenedBSD not FreeBSD.

[franco]

The thing is OPNsense is on top of HardenedBSD. HardenedBSD is on top of FreeBSD. FreeBSD provides most of new hardware support. So it depends on both BSDs to catch up.


Cheers,
Franco

[NetGobbler]

Exactly what I thought, long process.
Hopefully a Pi4, with USB NIC, will be ok.  The Raspberry manufacturers opted to NOT include any kind of crypto chip / functionality in the silicon, so it's going to be pretty basic - but maybe enough for a 100MBit internet (who knows?)  which would still service millions across the internet.

[gazpl]

just saw https://www.cnx-software.com/2019/08/27/banana-pi-bpi-r64-linux-router-board/

[khantroll]

Hi! Has there been any progress on the espressobin? I've got one I'd be happy to test with.

Thanks!

[nekoprog]

Hi! Has there been any progress on the espressobin? I've got one I'd be happy to test with.

Thanks!

espressobin is using aarch64, right now opnsense is using 11.2, not yet supported arm64 device, but rest assured you can hack your way if using freebsd12 and replace *.dtb to something like this armada-3720-espressobin.dtb | armada-3720-community.dtb

If it boots on freebsd12, it will boot on next major release of opnsense. 

UPDATE: Just found out that 11.3 supports aarch64. Could try making device config for RPI3 and Allwinner again.

[khantroll]

I'll give it a go I'm going to have to read up on Opnsense tools, as well as find an 11.3 image for the expressobin (I'm currently running 12.0 on the Espressobin.

Thanks!

[gandalf]

...
Wishlist (Needs uboot slave file in ports to make it work)

#	Device	defconfig	dtb
1	ESPRESSObin	??	armada-3720-espressobin.dtb | armada-3720-community.dtb

...

any tutorial, quick how-to or usefull help for espressobin support available somewhere ?
I may want to test OPNSense on my own board but I am more a Debian/OpenWRT user than a FreeBSD/OPNSense user.

Thanks for your help...

[mimugmail]

It's not supported, sorry

[nekoprog]

Let's hope FreeBSD can add this new port
[new ports] sysutils/u-boot-espressobin

[spikerguy]

Hello,
I am new to opnsense forum but not new to the software on x86.
I want to know how can I port opnsense to Armv7 and aarch64 boards? I have good knowledge in linux world but slowly moving to bsd too.
If there is any guide or documentation for porting freebsd or specifically opnsense then I would love to contribute.
Thanks

[nekoprog]

Hello,
I am new to opnsense forum but not new to the software on x86.
I want to know how can I port opnsense to Armv7 and aarch64 boards? I have good knowledge in linux world but slowly moving to bsd too.
If there is any guide or documentation for porting freebsd or specifically opnsense then I would love to contribute.
Thanks

You can start from here for opnsense build tools. For arm sources, you'll have to look everywhere and bring it back to github opnsense/tools for device configs and build scripts.

[spikerguy]

Thanks for the quick response.
This is something I was looking for. This is full porting tool, I am used to Manjaro-arm-tools which is something similar to this.

I will go through this and get back here to ask more questions.

[dgktkr]

Hi,

I have a ClearFog Base which is based on an armv7 SOC, but it can run armv6. I've gotten FreeBSD 11.2, 12.0 and 12.1 to boot and run on it with both ethernet ports working properly.

I've followed nekoprog's instructions https://github.com/nekoprog/pieSense/blob/master/README.md with appropriate modifications.

In the /usr/tools/Makefile the line

Code: [Select]

ARCH?= ${_ARCH}

was replaced by

Code: [Select]

ARCH?= arm:armv6

and the line

Code: [Select]

DEVICE?= A10

was replaced by

Code: [Select]

DEVICE?= CLEARFOG.


The file /usr/tools/device/CLEARFOG.conf was created and modeled after BANANAPI.conf:

Code: [Select]

export MAKE_ARGS_DEV="
CROSS_BINUTILS_PREFIX=/usr/local/arm-gnueabi-freebsd11.2/bin
UBLDR_LOADADDR=0x900000
"

export PRODUCT_TARGET=arm
export PRODUCT_ARCH=armv6
export PRODUCT_WANTS="arm-gnueabi-binutils qemu-user-static u-boot-clearfog"

export ARM_FAT_SIZE="32m -b 1m"
export ARM_UBOOT_DIR="/usr/local/share/u-boot/u-boot-clearfog"

arm_install_uboot()
{
arm_unmount
dd if=${ARM_UBOOT_DIR}/u-boot-spl.kwb of=/dev/${DEV} bs=1k seek=8 conv=sync
arm_mount
cp ${ARM_UBOOT_DIR}/boot.scr ${STAGEDIR}/boot/msdos
cp -p ${STAGEDIR}/boot/ubldr.bin ${STAGEDIR}/boot/msdos
ln ${STAGEDIR}/boot/dtb/clearfog.dtb ${STAGEDIR}/boot/dtb/armada-388-clearfog.dtb
}


Code: [Select]

#pkg install git qemu-user-static arm-gnueabi-binutils u-boot-clearfog


was invoked and completed successfully.

When

Code: [Select]

/usr/tools #make base

is executed, the computer works for quite a while until the build fails with a relocation overflow. The first sign of trouble is

Code: [Select]

===> usr.bin/clang/clang (all)
cc1_main.o: In function `cc1_main(llvm::ArrayRef<char const*>, char const*, void*)':
cc1_main.cpp:(.text._Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x45c): relocation truncated to fit: R_ARM_CALL against symbol `llvm::install_fatal_error_handler(void (*)(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool), void*)' defined in .text._ZN4llvm27install_fatal_error_handlerEPFvPvRKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEbES0_ section in /usr/obj/arm.armv6/usr/src/lib/clang/libllvm/libllvm.a(ErrorHandling.o)

This problem looks like the same issue reported and supposedly solved about 11 months ago https://github.com/opnsense/tools/issues/113

Running

Code: [Select]

/usr/tools #make xtools


before

Code: [Select]

/usr/tools # make base


doesn't solve the problem. And after building xtools, running

Code: [Select]

/usr/tools #make packages


fails in the same place in the same way as

Code: [Select]

/usr/tools #make base.

Was the fix that was implemented in tools last December propagated to the current version at https://github.com/opnsense/tools?