mboehmer Posted December 10, 2019 Share Posted December 10, 2019 Armbianmonitor: http://ix.io/242M Hi all, preparing an image for our next deployment (10 Odroid C2), I found that somehow the MAC address visible in Uboot doesn't make it into Armbian system. On the first copied system (I use odroidbackup.pl), in Uboot "Printenv" I get ethaddr=00:1e:06:36:58:63 Original system gives me: ethaddr=00:1e:06:34:fa:1a Both systems report to our DHCP server with the latter MAC, which will lead to troubles when both boards will be in the same network Any hints how to get the (apparently eFuse stored) MAC into the Armbian system? Thanks in advance, Michael Link to comment Share on other sites More sharing options...
mboehmer Posted December 11, 2019 Author Share Posted December 11, 2019 C'mon... noone has any ideas? Anyone who has some knowledge where the MAC address of C2 boards is injected into the kernel? Link to comment Share on other sites More sharing options...
Igor Posted December 11, 2019 Share Posted December 11, 2019 Where we don't have proper solution, we use userspace hacks. Which you can also try to use. Link to comment Share on other sites More sharing options...
mboehmer Posted December 11, 2019 Author Share Posted December 11, 2019 So there is no way to get the uboot stored MAC into Armbian? I don't get it then how the root system I used for cloning did get the MAC into it, and where it is stored. As in the final system setup will be fixed IPs, this is not a showstopper, anyhow it would be great to understand where Armbian does store the MAC (whereever it came from). Any hints for me? Link to comment Share on other sites More sharing options...
Igor Posted December 11, 2019 Share Posted December 11, 2019 5 minutes ago, mboehmer said: Any hints for me? If we would have a better solution, it would already be a part of the system. Perhaps there is one, just I don't know for it. Link to comment Share on other sites More sharing options...
mboehmer Posted December 11, 2019 Author Share Posted December 11, 2019 I made some investigations, and maybe this one is the place to proceed? https://patchwork.kernel.org/patch/11062673/ It seems to be related to same problem, but on C1. Link to comment Share on other sites More sharing options...
mboehmer Posted December 12, 2019 Author Share Posted December 12, 2019 Problem is solved with change to "dev" kernel, there it works. Change was necessary to get UARTs working (thnx to Martin Link to comment Share on other sites More sharing options...
Recommended Posts