• Content Count

  • Joined

  • Last visited

About reverend_t

  • Rank
    Advanced Member

Recent Profile Visitors

1038 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 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?
  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 inte
  11. Excellent. Look forward to your results. Stay safe, please don't disappear from the Banana 2k2 resistor curse
  12. Here you go: 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 nothi
  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