Jump to content

tabrisnet

Members
  • Posts

    32
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. this board appears to have effervesced from your repo in this commit, just a few weeks ago. is it maintained elsewhere?
  2. does anybody have a photo of the actual chip? A3A444 isn't finding much useful in google for a datasheet
  3. @superkali: "defective" or "silicon lottery loser" ??
  4. 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.
  5. 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?
  6. 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.
  7. 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
  8. 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
  9. 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?
  10. 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
  11. @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?
  12. 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>; };
  13. new Ubuntu/netplan bug: https://bugs.launchpad.net/netplan/+bug/2120999
  14. https://github.com/canonical/netplan/pull/278 <-- related netplan PR
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines