<Armbian-Discord> <j​kent> Interesting, this didnt' solve it in user land though
<Armbian-Discord> <I​gorPec> thank you. this is normal mo with this kind of development. not a problem.
<Armbian-Discord> <I​gorPec> u-boot interruption is not that critical problem and anyway i think we are changing this default behavior with a patch, so its not "space" but something else IIRC
<Armbian-Discord> <I​gorPec> i would propose to adjust patches that are broken, remove those that are obsolete and open a PR. This change has to be tested by more people anyway as it affects many boards.
<Armbian-Discord> <I​gorPec> @jkent i have moved all forward https://github.com/armbian/build/pull/4168
<Armbian-Discord> <j​kent> @IgorPec great
<Armbian-Discord> <I​gorPec> i apologize for making your commit obsolete 🙂 there is a lot more to do https://armbian.atlassian.net/jira/dashboards/10000
<Armbian-Discord> <j​kent> Hahaha, I don't mind one bit
<Armbian-Discord> <j​kent> I do need some guidance, if at all possible, I'm digging through linux-5.15.y, trying to solve the ethernet MAC issue in userland... I'm not sure if i'm missing something or what, but I can't fingure out where the MAC registers are reset
<Armbian-Discord> <j​kent> i was hoping i'd find it in dwmac-sunxi.c
<Armbian-Discord> <M​anoftheSea> ethernet mac in userland, can you just have your networking setup write your desired MAC?
<Armbian-Discord> <j​kent> no, it needs to come from the H3's serial number, they way it works in U-Boot
<Armbian-Discord> <j​kent> or passed to the kernel some how
<Armbian-Discord> <c​0rnelius> I have two nanopi neos and both have a diff mac addr. not sure honestly whats going, on ur end.
<Armbian-Discord> <c​0rnelius> unless you mean something else other than the mac addr
<Armbian-Discord> <j​kent> if you swap the card, you'll find out the mac is cached on the card, not from hardware
<Armbian-Discord> <c​0rnelius> ah I see. I haven't tried that.
<Armbian-Discord> <c​0rnelius> you trying to create one img to rule them all or something?
<Armbian-Discord> <M​anoftheSea> well, having u-boot set ethaddr is a good thing.
<Armbian-Discord> <j​kent> no, its not convenient for the end-user or system integrator
<Armbian-Discord> <j​kent> when cloning a card
<Armbian-Discord> <c​0rnelius> tried forcing a new one with macchanger? if it works one could create a service that runs on firstboot.
<Armbian-Discord> <j​kent> it can't be random, thats the problem
<Armbian-Discord> <c​0rnelius> sounds like you have a cloning issue, really.
<Armbian-Discord> <M​anoftheSea> It is more correct for the MAC to go with the hardware, not the software.
<Armbian-Discord> <M​anoftheSea> but does allwinner keep u-boot and params on the card?
<Armbian-Discord> <c​0rnelius> I would also think that the MAC should just change upon booting from another board. But I haven't tested this. I have noticed this behavior with BT dongles where the address remains the same, but I assumed it was just the dongles I was using.
<Armbian-Discord> <M​anoftheSea> same dongle should mean same MAC, unless you're intentionally randomizing
<Armbian-Discord> <j​kent> @ManoftheSea on this particular board (nanopineo), yes, as it doesn't have an emmc. this is how its done in u-boot: https://pastebin.com/SCswiHP6
<Armbian-Discord> <M​anoftheSea> oh that's just gross. Sounds like you need a pre-up step in the userspace network configuration to read the serial number and generate the... is it a hash or is it just mush.
<Armbian-Discord> <j​kent> yeah, its generated as a locally administered mac
<Armbian-Discord> <j​kent> consistency is key though
<Armbian-Discord> <j​kent> I've done a little research and it looks like the best place to add this functionality is in of_net.c
<Armbian-Discord> <j​kent> well, maybe not
<Armbian-Discord> <M​anoftheSea> why in the kernel module?
<Armbian-Discord> <j​kent> I'm not really all that familiar with device tree, last time i really hacked on the kernel, it was all done with platform devices
<Armbian-Discord> <j​kent> gap in knowledge
<Armbian-Discord> <M​anoftheSea> can't you just write a script to call... I think it's ethtool, to write the MAC on boot?
<Armbian-Discord> <j​kent> that would be great, except for the needs of software licensing
<Armbian-Discord> <M​anoftheSea> Then, any of networking, Network-Manager, or systemd-networkd would just pick up the "default" mac from the interface
<Armbian-Discord> <M​anoftheSea> licensing?
<Armbian-Discord> <M​anoftheSea> ip link set dev interface address XX:XX:XX:XX:XX:XX
<Armbian-Discord> <M​anoftheSea> https://wiki.archlinux.org/title/MAC_address_spoofing Has an example of a systemd unit to do the job. Needs a script to do the algorithm, though.
<Armbian-Discord> <N​otthix> Hi guys, I would like to ask if there is a xfce desktop variant for orange pi one, I can only find cli versions https://www.armbian.com/orange-pi-one/
<Armbian-Discord> <j​kent> I think i found a solution by creating an alias in the dts for ethernet0 -> &emac
<Armbian-Discord> <j​kent> building and testing now
<Armbian-Discord> <M​anoftheSea> so you'd need to overlay a compiled dtb per board?
<Armbian-Discord> <M​anoftheSea> how does that help you when cloning?
<Armbian-Discord> <j​kent> alias pulls from u-boot
<Armbian-Discord> <j​kent> if i understand what is going on with the orangepi boards
<Armbian-Discord> <j​kent> i'm testing this, it should be passed from u-boot properly
<Armbian-Discord> <M​anoftheSea> ah, as part of u-boot's fixup of the dtb?
<Armbian-Discord> <j​kent> yes
<Armbian-Discord> <j​kent> nope that didn't work, crap
<Armbian-Discord> <c​0rnelius> if uboot was the solution the mac address would change when pulling the card from one board to the other.
<Armbian-Discord> <c​0rnelius> well ur right. the mac address sticks when pulling the card from one to another. thats pretty lame.
<Armbian-Discord> <T​heBug> @Notthix they are not produced really anymore but what you can do is go to the archive here: https://xogium.performanceservers.nl/archive/orangepione/archive/ there are images there with xfce, you can find one which can work for you.
<Armbian-Discord> <j​kent> even more lame, i can't figure out where its cached at, i've looked at udev, systemd, network-manager...
<Armbian-Discord> <T​heBug> i am not 100 on what your trying to do but is is in /boot/armbianEnv.txt what your thinking or ?
<Armbian-Discord> <j​kent> Looked there too.
<Armbian-Discord> <T​heBug> add something like ethaddr=46:d5:67:c2:29:8e
<Armbian-Discord> <c​0rnelius> nah he wants the board to dictate the mac
<Armbian-Discord> <T​heBug> hmm
<Armbian-Discord> <T​heBug> I mean have it generate on first boot and write there?
<Armbian-Discord> <T​heBug> it wouldn't be out of box per se but you could script it generating something random
<Armbian-Discord> <j​kent> i'll just hacky patch allwinner,sun8i-h3-emac variant
<Armbian-Discord> <j​kent> its not the most elegant solution but it will work for now
<Armbian-Discord> <j​kent> i don't understand the device tree stuff enough to dig into why the ethernet0 to &emac alias did not work
<Armbian-Discord> <j​kent> thanks for trying to help though!
<Armbian-Discord> <M​anoftheSea> Does the driver assign the mac from the DT?
<Armbian-Discord> <M​anoftheSea> Does u-boot usually do this method to set it from ethaddr?
<Armbian-Discord> <c​0rnelius> @TheBug That works for sure. Having a fresh img installed to the board generates the proper mac. He is trying to then clone it, the problem is the clone all populates the same exact mac. I already suggested just have it regenerate the address at boot.
<Armbian-Discord> <M​anoftheSea> Because it sounds like you'd just want u-boot to generate it the way it currently does, and then use it if ethaddr isnt' otherwise set
<Armbian-Discord> <c​0rnelius> i compiled a new uboot and flashed it to the img and rebooted. Same mac addr as before..
<Armbian-Discord> <T​heBug> or do it on the host you are duplicating on and just have it loop mount and write the new random mac to the env file and then consider it complete, then just run the script and have ready image?
<Armbian-Discord> <c​0rnelius> Tome this doesn't seem like its a uboot thing. More like something getting stuck in cache.
<Armbian-Discord> <j​kent> they are two distinct issues
<Armbian-Discord> <M​anoftheSea> cornelius, u-boot would be generating from the serial number using the same algorithm, right? flashing u-boot wouldn't be expected to change something
<Armbian-Discord> <j​kent> u-boot generates a MAC as expected (it starts with a 02 octet, locally-administered MAC)
<Armbian-Discord> <c​0rnelius> well i'm not compiling it on the board. Just flashing it. But I guess I could pull the card and flash it else, but I still don't think that gonna auto-magic create a new mac.
<Armbian-Discord> <j​kent> hold tight, might have human error here... i have two kernels, 5.15 (sep 9) and 5.15.y, (aug 9) and i was working on the aug 9 kernel's device tree... gah.
<Armbian-Discord> <T​heBug> Can I let go yet, starting to lose circulation...
<Armbian-Discord> <j​kent> you may, but i hope you have a parachute!
<Armbian-Discord> <j​kent> okay, build in progress... i had some learning to do with patch management
<Armbian-Discord> <j​kent> probably would have been quicker to compile the dtb myself, but no pain no gain
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian-allwinner
<Armbian-Discord> <j​kent> got it! it works!
<Armbian-Discord> <j​kent> ether 02:81:ce:fc:6d:42 txqueuelen 1000 (Ethernet)
<Armbian-Discord> <T​heBug> geez, about time...
<Armbian-Discord> <T​heBug> I thought my fingers were gonna turn purple
<Armbian-Discord> <j​kent> haha
<Armbian-Discord> <j​kent> Okay, its been verified correct on 3 nanopi neos
<Armbian-Discord> <j​kent> I'm not sure how the patch submission process works, since there are multiple versions
<Armbian-Discord> <j​kent> I'm guessing I should make the patch against edge