sfx2000

Gah - systemd strikes again... This is upstream stuff - not just Armbian...

Light up a single bus - if you're looking for device detect - otherwise don't do this, and let the kernel sort it once booted with device tree... What problem are you trying to solve?

Sounds like a good reason to revisit that code and make it work across platforms.

what @Igor is getting at - this is a community supported driver - there's no real support from the chipset vendor for Linux. 88XXau has been problematic across the board with all Linux distro's...

Just out of curiousity - what's he using for a screen reader? sfx

1) RPi has fairly good community support for their native Raspian PiOS thingy - now that Canonical is onboard with Pi, not much value add 2) Armbian is just fine without Pi Foundation endorsements, and a distinct lack of interest from them to support Armbian 3) Not so sure, but what I can say is that Armbian is a great community, but not the only one out there 4) Is Pi Foundation willing to fund/support Armbian to port over to Raspberry Pi? I know some folks are concerned about VC3/VC4 and ThreadX, and with Pi4, the eeprom - and this is fair and undocumented... sfx

As mentioned above - interesting - but outside of wrapping PCI-e addresses - this is a security concern

Probably never - as this is a bit of a security concern... There's a reason why there are EL levels in ARM-V8A, and bringing in support for things under the kernel are a bit of a concern. If Mainline picks this up, perhaps, but I suggest that this be kept as a science project - most folks don't need PCI-e support on hobby boards

Realtek lately has been a bit of a pain - lot of chips/variants on 8188, but they're different from a driver level...

IIRC, there was an issue with a the linux headers on one of the more recent Armbian builds - might have been solved...

Pretty early in the morning for US folks - I'm out here in the PDT timezone, which if I recall is 6AM - I'd be ok moving this a couple of hours to 4PM GMT/8AM PDT, which works well for me, as I have teams in the UK/DE that I deal with on the job stuff. That is of course, if you really need/want me present for the meeting.

Sorry - bit busy with the jobby-job... Off the job - some concerns around support for older boards - keeping images over the the legacy... Bit surprised today... seems like AW-H5 has fallen off the supporte path. sfx@192.168.15.23's password: _ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Armbian 20.08.3 Bionic with Linux 5.8.11-sunxi64 No end-user support: built from trunk System load: 2% Up time: 11:28 Memory usage: 8% of 985M IP: 192.168.10.120 CPU temp: 36°C Usage of /: 15% of 15G [ General system configuration (beta): armbian-config ] Last login: Sat Sep 26 08:57:57 2020 from 192.168.15.133

Yes...

Kind of like the stability testing we did for H5 and memory timing... openssl speed -multi 4 Puts a fair load on to the CPU...

the noscan=1 patch take the AP out of compliance with 802.11 simply put - I could fix it, but not inclined to do so... root@cbsim:/etc/config# modinfo ath9k module: /lib/modules/5.4.65/ath9k.ko license: Dual BSD/GPL depends: mac80211,ath9k_hw,ath9k_common,compat,cfg80211,ath name: ath9k vermagic: 5.4.65 mod_unload MIPS32_R2 32BIT root@cbsim:/etc/config# uname -a && hostapd -v Linux cbsim 5.4.65 #0 Sun Sep 13 22:19:27 2020 mips GNU/Linux hostapd v2.10-devel User space daemon for IEEE 802.11 AP management, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator Copyright (c) 2002-2019, Jouni Malinen <j@w1.fi> and contributors

Take a look at ModemManager along with libqmi/libmbim... should support this out of the box with the packages installed. It's a Qualcomm MDM9205 solution, similar to QuecTel and others.

To support MX - one would have the rip out the systemd guts, and reimplement everything that systemd does...

The flash part is NAND, not eMMC - probably out of scope due to the effort needed to bring this up to a good solution. If you can run on SDIO, you're probably good to go - the OPi H3 image is a good starting place.

Cool - keep in mind that the M68K on both Mac and NeXT ran in big-endian mode... Looking at the project page, the m68k emu is a bit on the older side... Back in the day, used to have access to an 040 slab - they were neat boxes.

CNX has samples from FA - both the Neo3 and the R2S... unboxing article is up. https://www.cnx-software.com/2020/08/20/nanopi-neo3-and-nanopi-r2s-gateways-review-part-1-unboxing-teardown/ Looking forward to Jean Luc's next article on those two units...

Installing unbound is one things - now you need to configure it - that's why it stops...

Actually it probably makes a difference if the MAC address is not defined on the SOPINE module in the Cluster(F*ck)Board... If you have collisions on the MAC address - you'll be hard to find an issue here, not just at layer 3, but also at layer 2.

wonder if you're running into the back to the future bug on A64...

As a side note... sfx@nano2:~$ sudo apt list linux-image-current-sunxi64 -a Listing... Done linux-image-current-sunxi64/bionic,now 20.05.2 arm64 [installed] linux-image-current-sunxi64/bionic 20.05.1 arm64 linux-image-current-sunxi64/bionic 20.02.7 arm64

root@mips24k:~# find /lib/modules/|fgrep -i tables /lib/modules/5.4.51/ip6_tables.ko /lib/modules/5.4.51/ip_tables.ko /lib/modules/5.4.51/nf_tables.ko /lib/modules/5.4.51/nf_tables_set.ko /lib/modules/5.4.51/x_tables.ko everything here seems to be fine...