bfgmatik

Thanks for solving this problem. I will test this as soon as I get back to my workshop next week. I looked in sources of u-boot v2020.10 and it seems that u-boot calculates the MAC address based on CPU sid registers (in function setup_environment(), file board/sunxi/board.c by calling sunxi_get_sid() and making a CRC32 calculation on received unique register values. So basically this what we need. I'm currently working on a project utilising NanoPi Duo2 and this board has the same problem with changing mac address. And for some other boards like NanoPi M1, ethernet0 alias is correctly defined in dts files.

I'm running a fresh installation of Armbian 20.11 Focal with Linux 5.8.16-sunxi on NanoPi Neo board with Allwinner H3. root@nanopineo:~# uname -a Linux nanopineo 5.8.16-sunxi #20.08.14 SMP Tue Oct 20 22:15:32 CEST 2020 armv7l armv7l armv7l GNU/Linux The problem is that MAC address changes on every boot. This is very problematic for systems where an IP is assigned by DHCP based on MAC address table. I have two important questions: 1) Why MAC address is not generated based on processor unique ID? This seems to be the most sensible solution. 2) What part of code/startup script is assigning the random MAC address? Unfortunatelly I was not able to find startup script (or firstrun script) which does the thing. Is the random mac address assigned by device driver or the kernel? Changes in /boot/armbianEnv.txt or /etc/network/interfaces didn't give me a static MAC address (it is still random after every boot).

Hello, Please let me know what are the differences between different Armbian variants. There are a lot of them: Buster, Focal, Bullseye,etc. I was googling for more than 15 minutes and I didn't find an answer to this question.

In case anyone is interested. I was able to find a workaround by overwriting the 2018.11 u-boot in the .IMG file with older u-boot 2018.05 from my earlier image. The rest of the image is up-to-date with latest ARMBIAN 5.74. Looks like everything works now, but it seems that u-boot 2018.11 does not work correctly with legacy kernels, at least for NanoPi Duo and OrangePi Zero.

Ok, friends, I really need some help from you to resolve the issue as I spent many hours with it. I added some debuging information to boot.scr: Found U-Boot script /boot/boot.scr 4051 bytes read in 14 ms (282.2 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 144 bytes read in 10 ms (13.7 KiB/s) load mmc 0 0x43300000 /boot/uInitrd 5222048 bytes read in 422 ms (11.8 MiB/s) load mmc 0 0x42000000 /boot/zImage 4755248 bytes read in 387 ms (11.7 MiB/s) Found legacy kernel configuration load mmc 0 0x43000000 /boot/script.bin 35400 bytes read in 32 ms (1.1 MiB/s) bootz 0x42000000 0x43300000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5221984 Bytes = 5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ... (no more output) Looks like script.bin is correctly loaded to 0x43000000, init Ramdisk is loaded to 0x43300000, kernel is loaded to 0x42000000, If I understand correctly, legacy kernel gets all its configuration from script.bin. My questions are: what parameters are passed to the kernel from u-boot? Looks like there is no bootargs variable. How do kernel know where in memory to search for script.bin? I even tried to copy the whole /boot directory from a working older image (with kernel, ramdisk and script.bin) and still the kernel doesn't give any output via serial console. I believe that something changed with a new U-boot 2018.11 and some parameters are not passed to kernel or they are incorrect.

I mounted the img file, modified "boot/armbianEnv.txt" setting verbosity to 7 (console=serial was already present). Then I unmounted and burned the image to SD Card. Unfortunately the serial output is absolutely the same as with verbosity=1...

Below is a dump from serial console. Unfortunately this doesn't help my anything as this output is very similar to a working build from June 2018. The difference is that after "Starting kernel" there are no more output and kernel is probably not loaded, LAN leds do not blink, heartbeat LED does not blink. I also tried to build Orange Pi Zero image (which is a very similar hardware and in June 2018 worked with NanoPi Duo board). Result is the same, there is no output after "Starting kernel". U-Boot 2018.11-armbian (Feb 03 2019 - 20:07:15 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi DUO Air DRAM: 256 MiB MMC: SUNXI SD/MMC: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial Net: No ethernet found. 230454 bytes read in 35 ms (6.3 MiB/s) Unknown command 'bmp' - try 'help' starting USB... No controllers found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3798 bytes read in 14 ms (264.6 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 144 bytes read in 11 ms (12.7 KiB/s) 5222019 bytes read in 419 ms (11.9 MiB/s) 4654944 bytes read in 377 ms (11.8 MiB/s) Found legacy kernel configuration 35400 bytes read in 31 ms (1.1 MiB/s) ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5221955 Bytes = 5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ...

Hello everyone, Around July 2018 I was able to successfully build an Armbian image for NanoPi Duo using provided documentation: https://docs.armbian.com/Developer-Guide_Build-Preparation/ The reason I decided to build the image was that I needed it with legacy kernel 3.4.113. For some reason there were significant problems with using the mainline kernel with direwolf application which is an amateur radio APRS modem. The device hanged with mainline kernel after few hours of operation without any reason and this was not an overheat problem (temperatures below 50 degrees and a huge heatsink). I believe that it is some problem with audio driver for H2 which seems to be rewriten in mainline kernel, I don't see any other possibility as direwolf doesn't use any other peripherals and when it is not running or even running without soundcard, the device does not hang. Anyway, on July 2018 I was able to build it with kernel 3.4.113. I had to make a proper fex file for nanopiduo, because it is not available in sources. The resulting image file worked flawlessly for many months (Armbian_5.55_Nanopiduo_Ubuntu_xenial_default_3.4.113.img). Today I wanted to make the build again using the Ubuntu Bionic which seems to be now the only supported environment. I believe that I made everything like before, added the same fex file for nanopiduo and got a proper img file (Armbian_5.74_Nanopiduo_Ubuntu_xenial_default_3.4.113.img). But... the device does not even boot. Looks like something must have changed in the software, maybe U-boot version, maybe some configuration. Do you have any clue what may be wrong? Is the legacy kernel going to be no longer supported? On Monday I'm going to check via serial console, maybe it will give some output helping to understand what's going on. But it looks like I have a problem.