ESPRESSOBin
-
Saw this today:
https://www.kickstarter.com/projects/874883570/marvell-espressobin-board
I wonder if it would support pfsense?
-
Why arm? Why not a purpose built chip specifically for networking?
-
I wonder if it would support pfsense?
If you read the comments you'll find that jwt (Hacker S. Thompson) already ordered a/some samples. That's the best way to get support for this device from pfSense if possible at all.
-
Please make an official tread for espressobin ;D
-
Please make an official tread for espressobin ;D
Second that!
Board Specs
SoC Marvell Armada 3700LP (88F3720) dual core ARM Cortex A53 processor up to 1.2GHz
System Memory 1 or 2 GB DDR3
Storage 1x SATA interface
1x micro SD card slot with footprint for an optional 4GB EMMC
Network Connectivity 1x Topaz Networking Switch
2x GbE Ethernet LAN
1x Ethernet WAN
1x MiniPCIe slot for Wireless/BLE periphereals
USB 1x USB 3.0
1x USB 2.0
1x micro USB port
Expansion 2x 46-pin GPIO headers for accessories and shields with I2C, GPIOs, PWM, UART, SPI, MMC, etc.
Misc Reset button, JTAG interface
Power supply 12V DC jack or 5V via micro USB port
Power consumption Less than 1W thermal dissipation at 1 GHz -
;D make that 3!
It seems like people are getting their EspressoBIN's delivered now so I hope that the SoC forum will become more lively now.
Official
tech specs: http://espressobin.net/tech-spec/
wiki: http://wiki.espressobin.net/tiki-index.php
forum: http://espressobin.net/forums/ (not http only :-X)cheers, Hans
-
make that 4!
Is there any daily dev source available we can test? Reveived the 2GB espressobin yesterday, so cannot wait to start and contribute. 8)
-
There's no need for ESPRESSPBin thread as we are not working on it.
-
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.
-
@johnkeates:
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.
Yes, that's the right way to do it. We are currently working on a new ARM product https://www.netgate.com/blog/lord-vader-your-firewall-is-ready.html
-
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. -
yes, if you look at that posting, you'll see we helped bring the Armada 38x code to FreeBSD.
and (semi-obviously) we have product based on same.
I'll be working on the 3700 soon.
-
https://twitter.com/gonzopancho/status/936441170963570688
excitement intensifies
-
Hi
Is there any update of PFSENSE running on ESPRESSOBIN? I got my board and I am interested on running pfsense on it
Thanks
-
You could check with FreeBSD, once that's in working order we can do pfSense ;D
-
@johnkeates:
You could check with FreeBSD, once that's in working order we can do pfSense ;D
In this case, we were ahead of FreeBSD.
-
I guess that makes pfSense pretty cool eh ;-)
-
@johnkeates:
I guess that makes pfSense pretty cool eh ;-)
No, sorry, I have to disagree.
This makes pfSense EXTREMELY AWESOME! :)
Well done guys!
(I hope this will help getting pfSense on the MacchiatoBIN as well; and perhaps ClearFog Pro - but I'll be going for the MacchiatoBIN myself).
I'll get myself an EspressoBIN, perhaps two.
I will likely get this USB3 Gbit Ethernet (it's working with Armbian) - in order to …-
Fix the bridged LAN-WAN (yes, this can be corrected by uboot).
-
Keep the LAN speed at maximum (link-aggregation via the Topaz switch).
Note: The captcha says:
"V1 UNSUPPORTED
Please direct siteowner to g.co/recaptcha/upgrade" -
-
espresso.bin needs a custom u-boot to run pfSense anyway.
machiatto.bin is a different thing altogether, and is a target platform for our next-gen product “TNSR”.
PfSense for the SG-3100 was initially developed on a Solid-Run ClearFog.
-
Note: The captcha says:
"V1 UNSUPPORTED
Please direct siteowner to g.co/recaptcha/upgrade"I'm told this should be fixed now. Thanks for reporting.
