tabrisnet

this board appears to have effervesced from your repo in this commit, just a few weeks ago. is it maintained elsewhere?

does anybody have a photo of the actual chip? A3A444 isn't finding much useful in google for a datasheet

@superkali: "defective" or "silicon lottery loser" ??

can we have HS200 be the default but an armbian-config option to enable HS400 via an overlay [with appropriate warnings/documentation]? fwiw I have a NanoPC-T6 with current/mainline kernel [running my HomeAssistant, so I'm loathe to mess with it] that I had to abandon using the eMMC due to IO errors. It's in the official case so can't do much inspection either.

the current filogic kernel has no info [in github] for where it was forked from, and trying to apply incremental patches from kernel.org I found it contains pieces of 6.14 in an ostensibly 6.12 branch. @chainsx might you be able to divulge where you forked it from?

T'is one reason to prefer boards that take 12V power. and yes, barrel-connectors, but I can't think of any recent boards that use 5V and barrel connectors. NanoPi-M4 vs NanoPC-T4, with a WD Blue SN500, the T4 was stable. the M4 was not. yes, the M4 used the official power supply.

so first thought: you likely want a serial console [what @SteeMan said about UART pads]. If I had to take a stab in the dark with a rubber knife, see the 4 copper-lined holes near the SD card. you'll have to guess at the pinout tho. also, I went googling for 6051p s905w, and I found this armbian post. I am concerned that there are multiple posts [in general, not just here] saying that the wifi chip isn't supported. but they're old. this looks vaguely like your board https://github.com/ophub/amlogic-s9xxx-armbian/issues/2635

Googling suggests the need for Armbian to re-issue their signing keys. Note, I don't think this means they have to generate a new one. Just re-sign it. https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel https://github.com/fwupd/fwupd/issues/7124 @Igor

It's worth noting that you don't have to necessarily change anything in the build process. As long as you plan to not insert partitions in the middle, you can: write the image to the card with parted, resize the root partition to whatever you want make a new partition If you want to have more than 4 partitions total, this works best with GPT partition table, but legacy msdos works too with a little more effort `fsck.ext4 -f /dev/foo` where foo is the root partition `resize2fs /dev/foo` after you have the machine booted, you can then mkfs the new partition [you could probably do it in advance of booting the system too] I do this regularly, b/c I typically only partition about 1/2 or 1/4 of the SD card to leave the rest for wear-leveling. Are you trying to do this as a one-off or are you trying to do it for a dozen or more SBCs of the same type?

This solution feels janky [specifically, netplan-runner.service shouldn't be needed] But... it works. netplan-macaddress-watcher.path [Path] PathChanged=/run/systemd/network/ Unit=netplan-macaddress-watcher.service [Unit] Before=systemd-networkd.service #[Install] #WantedBy=systemd-networkd.service netplan-macaddress-watcher.service [Unit] Description=Rewrites /run/systemd/network PermanentMACAddress to MACAddress Before=systemd-networkd.service network-pre.target [Service] Type=oneshot User=root ExecStart=/bin/bash /usr/local/bin/netplan-macaddress-mangler.sh netplan-runner.service - it runs netplan as late as possible... [Unit] Description=Runs netplan right after boot After=multi-user.target [Service] Type=oneshot User=root ExecStart=/usr/sbin/netplan apply [Install] WantedBy=multi-user.target netplan-macaddress-mangler.sh - This will need to be renamed if published/packaged. #!/bin/bash -x # can we use $TRIGGER_PATH ? https://man.archlinux.org/man/systemd.exec.5.en # no, we can't, it only tells us the directory, not which file was changed. #FIXME: can we skip this for initial boot? sleep 5; # coalesce the calls /usr/bin/sed -i -e 's/^PermanentMACAddress/MACAddress/' /run/systemd/network/*netplan*.{link,network} #echo -n "networkd is: " if systemctl is-active systemd-networkd >/dev/null; then networkctl reload fi

above PR is merged

@Igor how often does netplan run? how possible might it be to sneak in a sed -i -e 's/PermanentMACAddress/MACAddress/' /run/systemd/network/* networkctl reload in my bootup sequence? will DHCP [on ethEXT1] or carrier up/down events break this?

https://forum.banana-pi.org/t/bpi-r4-eeprom/17836/13 suggests we should figure out how to give the info to uboot? or it already does generate it for us in one case? I can say I find eth0's local-mac-address in the running device tree, but the other two mac@ entries lack it. root@ratatosk:/boot# dtc /proc/device-tree 2>/dev/null |grep -PA 10 'mac@[0-9] ' mac@2 { phy-mode = "usxgmii"; compatible = "mediatek,eth-mac"; status = "okay"; pcs-handle = <0x3a 0x3b>; managed = "in-band-status"; phys = <0x3c>; reg = <0x02>; openwrt,netdev-name = "sfp-wan"; sfp = <0x3d>; }; -- mac@0 { phy-mode = "internal"; local-mac-address = [22 16 68 60 40 c2]; mac-address = [22 16 68 60 40 c2]; compatible = "mediatek,eth-mac"; status = "okay"; reg = <0x00>; phandle = <0x2c>; fixed-link { full-duplex; -- mac@1 { phy-mode = "usxgmii"; compatible = "mediatek,eth-mac"; status = "okay"; pcs-handle = <0x36 0x37>; managed = "in-band-status"; phys = <0x38>; reg = <0x01>; openwrt,netdev-name = "sfp-lan"; sfp = <0x39>; };

new Ubuntu/netplan bug: https://bugs.launchpad.net/netplan/+bug/2120999

https://github.com/canonical/netplan/pull/278 <-- related netplan PR