If you want to support that hardware as a community, you should get FreeBSD 10 and/or FreeBSD 11 working on it first. If you have a fully working board on FreeBSD, adding support for pfSense should be possible.

If you want to support that hardware as a community, you should get FreeBSD 10 and/or FreeBSD 11 working on it first. If you have a fully working board on FreeBSD, adding support for pfSense should be possible.

I've also investigated some other boards this way, because I too enjoy diversity for the software I use. Most of the time you can get it running fairly easily once FreeBSD up and running, with some hacks to make the pfSense-specific parts happy. After that, it just becomes testing and fixing until all the features are working well.

A really nice bonus is that there is at least some ARM support for pfSense, so we already know that it can actually run. There is a lot of ARM support for FreeBSD as well, so we know that FreeBSD can most likely be made to boot as well. All of this makes porting much better than it used to be.

A somewhat annoying downside to most ARM boards is that you often don't get driver code out in the open, there is a rather nasty requirements of a ton of firmware blobs and sometimes even kernel blobs to use all devices, and once you start using those you have to dig much deeper to integrate it into FreeBSD and pfSense. Take the switch chip for example, you'll probably need to reverse engineer that before you can start using it, unless some driver code is available. Next step would be either hard-configuring the switch chip to just present the ports as separate interfaces, but you'd lose VLAN support. You could alternatively make a switch package for pfSense to 'configure' the switch, but you'd have to not only implement switch controls as a userland binary, but a complete pfSense framework too, or you'd need to do some magic to have your switch setup reflect the results as 'interfaces' so it can be used, or as VLAN interfaces… oh well, lots of stuff to do.

This is just an illustration of what might be involved just to get some packet forwarding working, and it might be much simpler or much harder. Simply 'adding' support isn't the way things work in hardwareland, sadly. On top of that, not all networking hardware is created equally, so if there is some sort of issue with the performance (regarding the switch chip or SoC-Chip interconnect) it may not even turn out to be worth the hassle.

A lot of the cheaper ARM and MIPS boards claiming high throughput often rely on a hardware or microcode implemented NAT processor, and it them only works as long as you don't actually need to process any packets. Ironically, if you aren't going to process your packets, you might as well not use pfSense... so porting it, while working, won't give you an actual return on all of the hard work.

In the case of this board, it really depends on the following:

Can we get AES acceleration to work, preferably via cryptodev

Can we get ethernet to work (at least better than Realtek, preferably as good as Intel)

If either of them are a nope, the board isn't very useful.

Edit:

A small amount of digging later:

The CPU core is supportable, but currently you can't easily boot a BSD kernel from public sources yet as far as I can find

The architecture can be made to work, but Marvel only publicly pushes 38xx ARMADA's with BSD support, no reference on the 37xx during a quick google?

The ARMADA 3xxx has linux support but since it's still being patched into the kernel over the last 6 months, its not exactly mature

There are other Marvell SoC references in the FreeBSD tracker, but it still looks like an ongoing effort over the past 2 years, not exactly mature either

So while this indicates that it can probably be made to work (it uses U-Boot by default? -- freeBSD can boot via U-boot), there would still be quite some work to be done. Other Marvell ARM SoCs have only been listed as 'unknown support' on the FreeBSD Wiki. The fact there is no other easily accessible docs on those Marvell SoCs working with a somewhat official FreeBSD distro smells like NDA to me, as in Marvell not giving out docs to anyone. Commercial investment seems to be the only way to get a working Marvell SoC.

There is in-tree BSD code for the 38xx ARMADA but that seems like a pure Netgate effort for the R-1. https://lists.freebsd.org/pipermail/freebsd-arm/2017-June/016314.html
And that is so fresh and hot-off-the-press that you'd burn your fingers handling that code. OTOH, it might mean that the code would be usable to get extra SoC's that are close to that spec working... so many if's and but's.

I have one request for pfSense on EspressoBIN:
I'd very much like support for an external Gbit Ethernet via USB3.0 - like the Ugreen one mentioned earlier.
The reason I mentioned Ugreen's is that …

It works with Armbian (as proof-of-concept; the driver sources can thus be used for reference)

It's not extremely expensive

There are variants that include a USB3.0 hub, thus might allow increasing the speed by adding a few extra ports.

Though I've been looking very much at the hardware schematic and hoped that the CPU was connected to the Topaz switch via the 2.5Gbit SerDes interface, this might not be the case.
People are reporting maximum throughput of 1Gbit/sec (some less, depending on what O/S they're running), but noone reports anything exceeding 1.4Gbit (I suspect that this number is a misunderstanding anyway).
If the CPU and Topaz are indeed interconnected via the SerDes, then there must be some hardware register that allows to switch the SerDes to 2.5Gbit/sec instead of using 1Gbit/sec.
Some people say that the Topaz switch is causing the slowdown (I don't know exactly what they mean, because I'm pretty sure it would speed up data sent from LAN-to-LAN).

My plans were initially to use the Gbit Ethernet connected via USB3 for WAN and then the 3 ports on the switch for LAN.
However, that might not be a good idea if the total throughput on the switch is limited to 1Gbit (then there's no idea in connecting the extra ports to the switch, except for 'redundancy' - but cables usually don't break if you leave them alone).

Instead, I think it would make more sense to connect several Gbit Ethernet ports via USB3 (the first one could be a USB3-hub + GbE, the next two (or 3) could be the cheaper adapters without USB3-hub.
If that would work, then those ports would be connected to my switch as LAN and the ports on the Topaz would be connected to WAN.
That'd separate WAN from LAN physically plus give the fastest downlink speed, allowing me to take advantage of a Gbit internet connection if/when an upgrade becomes available.
Regardless, the LAN speed is what's important (in my case and most other cases).

I currently know of no recommendable Mini-PCIe GbE cards. I've seen a few, though, but I have no confirmation that they will work with the EspressoBIN. I've seen two models; one single-port and one dual-port card. One is a very tiny card (too tiny for mounting on the EspressoBIN), the other is the size that can be tightened with screws to the EspressoBIN board.

I'll be happy to try out pfSense on the EspressoBIN. I have two 2GB versions arriving one of the next couple of days. :)
-I'll also get one of those Ugreen GbE adapters with built-in USB3 hub; if I can get that to work with Armbian, I'll order a few of the simpler ones too. (I'm told that Armbian gets confused if using more than 3 devices on the USB ports, but I believe that USB3 would be close to saturated with a total of 3 GbE interfaces anyway).

The problem with USB is that it's not an interface suitable for advanced network traffic. While it might be enough for basic home or prosumer usage, it's even worse than Realtek PCIe interfaces.

Exactly. Everyone who's buying a $50 piece of network gear would basically be pissed if they could plug a USB gigabit adapter in and find that it works, because it's not "advanced" enough for the truly discerning.

The problem with USB is that it's not an interface suitable for advanced network traffic. While it might be enough for basic home or prosumer usage, it's even worse than Realtek PCIe interfaces.

There are a few things to consider.
1: Performance. Since the EspressoBIN appears to allow only 1Gbit transfers, this means that if transferring data in both directions between a computer on LAN and the WAN, we'll get a maximum throughput of 500 Mbit in each direction.
If adding an USB3.0 GbE interface that can handle at least 500Mbit/sec in each direction, then we'd already get a faster transfer rate in each direction.

2: Security. If somehow the router is rebooted and crashes before U-Boot can change the LAN-WAN bridging, then attackers can freely inject spambots and other nice stuff into the LAN. This will definitely not be possible if a driver is required in order to get data through the WAN port.

… I for one would not be angry if I could add a USB3.0 device and get an extra GbE port.
Though, I really would prefer having a GbE WAN plus a 2.5Gbit Topaz switch instead of having a 1Gbit switch an USB3.0 port (but mainstream probably likes USB3 better than I). I can probably still add up to 4 GbE ports on Mini-PCIe, but the chance of pfSense supporting exactly those cards I pick is pretty slim.

The problem with USB is that it's not an interface suitable for advanced network traffic. While it might be enough for basic home or prosumer usage, it's even worse than Realtek PCIe interfaces.

There are a few things to consider.
1: Performance. Since the EspressoBIN appears to allow only 1Gbit transfers, this means that if transferring data in both directions between a computer on LAN and the WAN, we'll get a maximum throughput of 500 Mbit in each direction.
If adding an USB3.0 GbE interface that can handle at least 500Mbit/sec in each direction, then we'd already get a faster transfer rate in each direction.

2: Security. If somehow the router is rebooted and crashes before U-Boot can change the LAN-WAN bridging, then attackers can freely inject spambots and other nice stuff into the LAN. This will definitely not be possible if a driver is required in order to get data through the WAN port.

… I for one would not be angry if I could add a USB3.0 device and get an extra GbE port.
Though, I really would prefer having a GbE WAN plus a 2.5Gbit Topaz switch instead of having a 1Gbit switch an USB3.0 port (but mainstream probably likes USB3 better than I). I can probably still add up to 4 GbE ports on Mini-PCIe, but the chance of pfSense supporting exactly those cards I pick is pretty slim.

I don't think anyone would be angry if USB network adapters had the same features and performance as PCIe adapters. Most of the issues stem from the limitations of USB as a bus (i.e. USB traffic costs CPU to get to RAM, PCIe has DMA), and from the manufacturers trying to segment the market, removing certain hardware features (well, mostly turning them off) or limiting stuff in their driver code (i.e. no hardware VLANs or a very small number of queues or queue entries, small buffers in the firmware etc.).

I don't think anyone would be angry if USB network adapters had the same features and performance as PCIe adapters. Most of the issues stem from the limitations of USB as a bus (i.e. USB traffic costs CPU to get to RAM, PCIe has DMA), and from the manufacturers trying to segment the market, removing certain hardware features (well, mostly turning them off) or limiting stuff in their driver code (i.e. no hardware VLANs or a very small number of queues or queue entries, small buffers in the firmware etc.).

Now I understand what @VAMike is saying. ;)
Sure I hate USB - anything USB.
It should never have been "invented".
-But since I now have a board that has this USB3 port, I'd like to exploit it.

If, on the other hand, you think that Mini-PCIe is the way to go with pfSense, I will certainly not stand in your way!
(I just hoped to use Mini-PCIe for an extra 4-port SATA interface).
… However, thinking about it, it's pretty silly having several GbE ports via USB3 and then a total of 11 Gbit SATA available.
The USB3.0 plus the built-in GbE ports wouldn't be able to utilize those speeds anyway.
The built-in SATA can give me 600000000 Bytes per second, where Mini-PCIe can maximum (ideally) give me 500000000 Bytes per second.
So if using one of the GbE ports plus 4 GbE ports on the Mini-PCIe, I think the throughput would be as balanced as it could get.
-Then USB3 could be used for a few (slower) spare harddisks.

Anyway, for my pfSense box, I intend to only run pfSense and a single harddisk (for O/S); no NAS and as little "junk" as possible; stability and performance is much more wanted than a lot of features.
So a bunch of GbE interfaces via Mini-PCIe would still be very appealing to me (even if a Mini-PCIe-to-PCIe breakout cable is necessary).

Anyway, for my pfSense box, I intend to only run pfSense and a single harddisk (for O/S); no NAS and as little "junk" as possible; stability and performance is much more wanted than a lot of features.
So a bunch of GbE interfaces via Mini-PCIe would still be very appealing to me (even if a Mini-PCIe-to-PCIe breakout cable is necessary).

I don't know that we've tested either SATA or PCIe. I wouldn't count on either.