Debian: MAC address keeps changing on every reboot
#11
(08-20-2017, 03:06 AM)dlu Wrote: Can someone explain the solution please?

- If the mac address resides in the "SPI flash", then 00:...:00 and FF:...:FF are both invalid addresses. Which software part corrected the zeroes, and why didn't it correct the FFs?
- Where does the new value for the stable mac address come from? Is it the same code path as seen in rontants loglines (random_ether_addr in rk_get_eth_addr)? Or somewhere else?


I've been playing with this most of the night.  If you write to the SPI with anything ( I placed my name in the SPI at offset 4000 ) and boot, then something  takes over on the next boot and starts to keep track of the mac addy ;  but, with a twist;  when there is all mostly 0xFF there, um, it gets very confused;  

I finally went back and wrote 0x00's to the SPI and rebooted;  will update later ... it takes at least two boots and not sure in my case what will happen.  I'm not really happy about the way that the image is using the SPI flash !!  This is NOT what the SPI flash was intended for, and it prevents me from experimenting with the SPI flash booting. So ayufan and I need to have a talk about this.

At this time,  the mac addy appears to be written to the SPI flash at offset 400 with some other junk at the heading;

example

Code:
rock64@Rock64-A:~/work/spi_flash$ hexdump spi_flash.003
0000000 5644 524b 0002 0000 0001 0001 0040 fbb8
0000010 0003 0000 0006 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 493e babb 3156 0000 0000 0000 0000 0000
0000410 0000 0000 0000 0000 0000 0000 0000 0000
*
000fff0 0000 0000 0000 0000 0000 0000 0002 0000
0010000 0000 0000 0000 0000 0000 0000 0000 0000
*
0040000
There is another small baby bug;  on the xenial-mate image eth1 and eth0 show up;  eth1 is the internal PHY which does not show up on the xenial-minimal image;  anyway,  both of the interfaces eth0 and eth1 have the same mac addy after this "change" which will be a problem once we get the magjacks mounted and have the 10|100 interface going...  the addys must be unique !

Note:  spoke with ayufan;  /dev/mtd3 is a partition;  SPI flash is a lot of data and partitions.  See  /proc/mtd
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#12
Update:  

I have rebooted several times today testing various things;  each time I go back in and check the /dev/mtd3  (vendor) partition which continues to be persistent ( see above post ) and the mac addy is also quite persistent now;  

Shy
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#13
The 0.5.x generates mac address from serial in u-boot, and passes it to linux, so current vendoring on SPI will be removed sometime in the future. This method will be used for eth0 and eth1 as well.
Homepage: https://ayufan.eu

Releases:
Rock/Pro 64/Pinebook Pro: LinuxChromium OS
So/Pine A64/Pinebook: LinuxAndroid 6.0Android 7.1

Buy me a Beer
  Reply
#14
I do have the same issue with the stock debian image but there is no mtd3 device found

linaro@therock:~$ cd /dev
linaro@therock:/dev$ pwd
/dev
linaro@therock:/dev$ ls -l m*
crw-rw-rw- 1 root video  10, 56 Aug 27 12:31 mali
crw-r----- 1 root kmem    1,  1 Aug 27 12:31 mem
crw------- 1 root root   10, 57 Aug 27 12:31 memory_bandwidth
brw-rw---- 1 root disk  179,  0 Aug 27 12:31 mmcblk0
brw-rw---- 1 root disk  179,  1 Aug 27 12:31 mmcblk0p1
brw-rw---- 1 root disk  179,  2 Aug 27 12:31 mmcblk0p2
brw-rw---- 1 root disk  179,  3 Aug 27 12:31 mmcblk0p3
brw-rw---- 1 root disk  179,  4 Aug 27 12:31 mmcblk0p4
brw-rw---- 1 root disk  179,  5 Aug 27 12:31 mmcblk0p5
brw-rw---- 1 root disk  179,  6 Aug 27 12:31 mmcblk0p6
brw-rw---- 1 root disk  179,  7 Aug 27 12:31 mmcblk0p7

mapper:
total 0
crw------- 1 root root 10, 236 Aug 27 12:31 control

Could it be that it has been already removed as mentioned by ayufan?
If so, it doesn't seem that new solution works as every boot creates a new mac.

Thank you
Reinhard
  Reply
#15
(08-19-2017, 07:45 PM)ayufan Wrote: Clear SPI flash. Run `dd if=/dev/zero of=/dev/mtd3` and restart. From now on address should be persisted.

I also tried this command but I am getting:

linaro@linaro-alip:~$ sudo dd if=/dev/zero of=/dev/mtd3
dd: writing to '/dev/mtd3': No space left on device
4018881+0 records in
4018880+0 records out
2057666560 bytes (2.1 GB, 1.9 GiB) copied, 14.8609 s, 138 MB/s

I did reboot my Rock64 and the mac address is changing on booting. Id there any other solution?
I am using:
http://files.pine64.org/os/ROCK64/debian...k64.img.xz

thx
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  problem with debian emmc boot G4zCDzWb 10 1,608 11-01-2024, 04:32 PM
Last Post: bits
  Debian installation via sd card oaFJSADBKV 0 108 10-12-2024, 10:24 AM
Last Post: oaFJSADBKV
  How to update/compile Debian 12.5? Wizardknight 3 1,267 03-29-2024, 05:01 AM
Last Post: gedas07
  Rock64 Debian 11 (Bullseye) install problem jbize 15 11,225 10-12-2023, 05:14 PM
Last Post: tpaul
  rock64-debian-mrfixit-190531.img.xz : missing /usr/lib/dri/rockchip_dri.so popi 5 6,189 08-12-2021, 04:55 AM
Last Post: igorp
  Debian build from mrfixit2001 Luke 18 31,183 05-17-2021, 02:35 AM
Last Post: Wizzard
  Debian kernel stuck at 4.4.167 Enig123 5 6,554 12-29-2020, 12:57 PM
Last Post: kwinz
  Debian (Vanilla) on Rock64 and eMMC - how ? as365n4 4 6,058 09-21-2020, 04:33 AM
Last Post: as365n4
  pcsx rearmed on rock64 debian stretch does not go fullscreen RockyBoulder 2 4,685 05-09-2020, 03:15 AM
Last Post: lawrencejd
  Fedora 31 crosscompilation fdt problem mimics debian 888789 kf5zmi 2 4,645 01-20-2020, 12:25 PM
Last Post: kf5zmi

Forum Jump:


Users browsing this thread: 5 Guest(s)