reverend_t

Thanks so much 5kft! Can I find your source/patches anywhere online?

Ah OK, so there are no userspace hooks for this? Would it involve editing the following file https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi-dev/add-orangepi-zeroplus.patch for the OPi0+ and changing the DRAM lines: @ -0,0 +1,22 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SYS_TEXT_BASE=0x4a000000 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_MACH_SUN50I_H5=y +CONFIG_DRAM_CLK=624 +CONFIG_DRAM_ZQ=3881977

Hi all Given that the node that H3 consumption uses to change DRAM frequency no longer exists on H5 on the mainline kernel, how would one go about altering this?

Apologies for the necromancy but this here is relevant! I want to disable Wi-Fi entirely on the OPi0+, from the schematic it appears that PA20 is also responsible for the power to the RTL8189 on that board. Are there any advantages to using the DT to set the GPIO to low as opposed to doing it in userspace through sysfs with mainline kernel? If using DT could anyone point me to a guide for this? I've searched but to no avail.

Thanks very much for this, I will give it a go

Is there any news on Armbian support for the v1.1 revision of the NanoPi Neo2 with dvfs? Because of the sensible placement of the cpu, it may be the only small board capable of consistently high speeds (with enough thermal care). If not, could someone point me to how I might go about compiling a working kernel for testing, (I can manually monitor temperatures if thermal monitoring isn't fixed yet on the H5) or even beginning to add more formal support for the board? Not expecting any hand holding

Does anyone have a more recent purchase of this board? Have Xunlong started inluding the mosfet?

Pull request pending for NanoPi Neo 2 and made the demo slightly more verbose. Just wondering, does it might make sense to put all the boards and their pin mappings at the top of armbianio.c into structs? The current system of having to change multiple arrays seems a bit fragile.

Hmmm, I've never thought that e/n/i is particularly complicated. Like most of GNU/Linux it's a powerful tool, possible to get wrong but it's also a solid part of the Linux learning experience. Isn't that also what Armbian is at least partially about? Even Netplan, which is slated to replace ifupdown in 18.04, is largely based on e/n/i (state your desired outcome) principles rather than NM (coddle you from any chance of mishap) principles. And the fact that boards like the Orange Pi Zeroes, etc, open up the world of Linux to more people is something to be celebrated, surely? However, if this is the way things ust be then there's a couple of issues/suggestions: 1. The "standard" Ubuntu/Debian way of disabling Network Manager appears to be broken (at least in H3 5.35 Dev): $ sudo systemctl stop NetworkManager.service $ sudo systemctl disable NetworkManager.service Following these (man page) commands good ol' Network Manager is somehow re-enabled on the next boot. I had to take slightly more drastic step of: mv /lib/systemd/system/NetworkManager.service /lib/systemd/system/NetworkManager.service.BAK after the previous steps to actually slay the vampire. I don't know whether this is due to Armbian's integration of NM into its basic tools or what. 2. The description in /e/n/i needs to be more balanced It sounds like it was written by someone fuming at the ears. It should, of course, emphasise the benefits of NM but should also point out that for any vaguely interesting routing set up (say you want to play with LXD and create neat bridges, VLANs or whatever) then it should contain clear and working instructions on how to disable NM (since the standard Debian way doesn't seem to work). Maybe even better would be to add into armbianconfig. I'll investigate if I have time!

Ubuntu Server edition doesn't use the fundamentally limited Network Manager for a reason. For any kind of semi-complex networking configuration, (say VLANs, bridges, per-network firewall rules, any kind of policy based routing and so on and so on). Also, conversely on little, largely headless servers with static network configurations, Network Manager is a big, bloaty and intrusive process that adds boot time and complications. Just recently I have struggled hugely with difficult to replicate networking issues. I thought (and Network Manager reported) that NM didn't touch the interfaces specified in e/n/i. Turns out not to be the case. Is there any rationale behind Armbian's decision to offer "Ubuntu Server" with added NM? Especially given that it's primary use case is for desktop/laptop scenarios?

Excellent. Look forward to your results. Stay safe, please don't disappear from the Banana 2k2 resistor curse

Here you go: https://github.com/armbian/build/issues/511#issuecomment-258647387 The option to change mode on the R1 appears to be pretty sensibly exported. A simple resistor soldering. Really? The much hyped Espressobin also boots up with all ports bridged? I hope Globalscale have made it as easy as Lamobo to physically change this setting

Actually these could be excellent daughter boards for the NanoPi Duo or Core. C'mon Friendly Elec!

Good points tkaiser. I didn't get the board (it was overpriced by a factor of at least two for me, I don't need Wi-Fi, crappy 'SATA' or many of the other confusing bells and whistles - just give me a VLAN capable switch under the control of a reasonably powerful CPU which I will turn into a router). However, the ports isolated/bridged boot state is simply a pin property of the the BCM switch and is in the datasheet. I see no reason why it wouldn't work and be secure: if you lost the CPU then there's nothing to change the initial (pin controlled) state. If you lost the switch then there's nothing to worry about Put it this way, I use the Ubiquiti Edgerouter X (MT7621 processor with a 5 port gigabit switch with a WAN port created through VLANs) in production with 100% confidence. I'm really hoping that someone (maybe Orange Pi, their R1 is a promising move) will introduce the boards I need: H5 + Broadcom DSA capable switch + 3 gigabit ethernet ports for $30 (the espressobin is OK but pretty power inefficient, the processor's relatively weedy if not using the whizz bang hardware offload) (insert weedy processor here) + swconfig capable switch + 3 gigabit ethernet ports for $20 (to act as a simple linux controlled VLAN capable switch)

Yup, all you need to do is connect with the Wi-Fi, enable masquerading on the Wi-Fi interface, allow ipv4 forwarding, run dnsmasq to listen for DHCP requests from the bridge , and set up a simple firewall. Google Linux router and you'll be presented with hundreds of good guides

That's not correct at all. Many purpose built routers (Edgerouter X, Mikrotik Hex Gr3) have the same design. The question is whether the switch is brought up in bridged or isolated mode before the appropriate VLANs can be established. The design mistake with the Lamobo R1 was to bring up the switch in the wrong mode, but it could be corrected by the addition of a resistor on the board. I'm actually looking forward to the R2 (hoping that BPi will learn from the R1).

What do you mean "gateway"? Draw a diagram or explain more clearly what you're trying to achieve (ie different subnets on lan ports and wifi? which will be your wan port?)

Ha, hadn't thought of it like that. The use of that 1Gb interconnector between the Armada 37xx and the Topaz switch rather than the 2.5Gb line negates one of the main benefits of those comms specific chips over an Allwinner/Broadcom alternative And given that I want to almost always perform Codel/Cake over a saturated link then what use is the fancy hardware NAT acceleration offload? I haven't as yet seen any QoS benchmarks with quad-core A53 chips. If the dual-core 880MHz mips in an ER-X can push 120Mbps then surely we'd get much more puff from a modest H5. If you want to get really fancy you could use an RK3288 and turn its usb3 into a symmetrical 2.5Gb lane to the switch. Now how do we get someone to make these boards Good question about the limitation. I would say yes, unless there is hardware capability on that Topaz for the layer 3 features you want. I guess that if the switch handles all the intra-VLAN stuff at line-rate then you'll have that limitation applied to only the layer-3 stuff? Don't know, need to get my hands on some of this stuff.

In essence what I'm waiting for is a board that uses a Marvell or Broadcom switchdev compatible switch chip, 2-4 gigabit ports and a cheap Allwinner SOC. In fact, the Banana Pi R1 was close, but it had an insane boot up mode for the switch (all ports switchable) and was overpriced by a factor of 3. I don't want on board Wi-Fi, SATA or any other of that BS. This should be possible for $20

Yup indeed. So one way to think about it is like follows. The switch chips found in commodity wireless routers are often the very same that are in expensive managed routers, however the stock firmware provided gives no way to manipulate the powerful features possible on these chips. Openwrt uses a process called swconfig to configure the switch chips in these routers to support VLAN tagging. However, it only exposes the switch as a single network interface so that means that many things are impossible, such as per port/per vlan stats and STP (used to prevent loops from disabling large parts of your network). This is still immensely powerful. A £20 openwrt capable wireless router board from Aliexpress can be made to act as a gigabit managed switch running Linux. The possibilities that just VLAN tagging controlled by Linux provides are amazing! Switchdev/DSA go one step further for compatible switch chips. They expose each port to the OS. Therefore they take advantage of the ability of the switch to perform hardware intra-VLAN routing, but also allow the rest of the system to get involved with inter-VLAN routing/STP/IGMP snooping and other higher level functions, including the use of the hardware accelerators as found in Marvell/Broadcom/Cavium/Mediatek SOCs.This would allow Linux-based switches to be as performant as the proprietary mnged switches from Cisco etc.

Network manager's so frustratingly limited, it always pushes me back to using /etc/network/interfaces, especially when I'm using VLANs and doing any kind of complex routing/masquerading. I'm really interested in these devices coming along with hardware gigabit switch chips (especially the Marvell and Broadcom BCM5XXX chips that can be configured using the Switchdev/DSA process), has anyone experimented with STP on the espressobin?

Those emulators don't have access to low level stuff. They use the capabilities that iOS grants them. I think it's probably worth learning more about sandboxing and virtualisation

Ah great, this explains why I've not been able to build a Pine64 image.

As a wireless bridge for a USB LTE modem

What a wasted opportunity. Even an H5 sitting behind a 3 port switch chip would have been fantastic (as long as the switch was booted in the sane deny all connections mode) as the switch could have taken easy care of switching packets on the same VLAN and brought in the SOC to handle inter VLAN stuff (Netgate's horrifically overpriced sg-1000 is essentially this). (At some point I'm really hoping someone combines an RK3328 with an ax88179 and a decent switch chip so that we can have a genuine dual nic gigabit routing device)