Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

1746 profile views
  1. Thanks so much 5kft! Can I find your source/patches anywhere online?
  2. 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
  3. 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?
  4. 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.
  5. Thanks very much for this, I will give it a go
  6. 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
  7. Does anyone have a more recent purchase of this board? Have Xunlong started inluding the mosfet?
  8. 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.
  9. 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!
  10. 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?
  11. Excellent. Look forward to your results. Stay safe, please don't disappear from the Banana 2k2 resistor curse
  12. 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
  13. Actually these could be excellent daughter boards for the NanoPi Duo or Core. C'mon Friendly Elec!
  14. 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)
  15. 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
  • Create New...