Elclaudio

Hey rizo, thats right. the c2 is pretty stable with older kernel. He's been running 24/24 for a few years without much glitch here. Power consumption is pretty low also. It lacks usb3 which make it unsuitable for a home router and with latter kernel I had also issues with usb. That's why I starting to phasing it out. My RPI4 has arrived and I spend most of the week end building, configuring and testing it under Openwrt and I must say I'm impressed, it managed to drive GB fiber without problem. Now I'm starting to think it may be a good idea to just buy another one for home automation purposes, especialy since I've just recently find out that you can activate 5 uart in total, that's a blessing for what I've in mind.

it's nice and handy to be able to backup our os image and restore it, just in case. The problem is that a full os backup need the root partition to be mounted read only. And some of us are running the device without any monitor attached (headless) or it's not very practical to get acces to the sdcard (for exemple, when the device is installed in the electrical cabinet) So, I had the idea of creating some kind of ramdisk with some utilities (base tools, ssh, rsync...) to backup the "offline" root partition and send it to another computer. Ultimately, this process could be started also by network boot, by U-Boot script. When you decide to backup the root partition, just go to /boot and replace the boot.scr adapted for your need and purposes and reboot. For debugging, it's best to have access to the serial console with and uart to usb or be connected locally with a monitor. as a start, I've tried 2 methods of booting, from sdcard at first, and network (which is a little more tricky but I won't talk much about it for now) boot.cmd (and boot.scr): setenv bootargs init=/bin/bash root=/dev/mmcblk1p1 ro rootwait console=ttyAML0,115200 console=tty1 setenv devtype "mmc" ext4load mmc 0 ${kernel_addr_r} /boot/uImage ext4load mmc 0 ${fdt_addr_r} /boot/dtb/${fdtfile} bootm ${kernel_addr_r} - ${fdt_addr_r} this boot the kernel but I got stuck at some point while booting, I believe that's because of the root partition. I don't want to use the root partition on the sdcard, instead I need some kind of independent ramdisk root partition (with the tools for backup) Do you have an idea of how to achieve this, how to create and boot from a "squashfs" recovery like partition ?

Despite efforts in trying to resolve the issue myself and since none of the latest armbian work ootb, I've ordered a raspberry pi 4 and planning to move my entire home automation on it asap. That's a real problem for all theses board, if you manage to get your hands on one, software support is generaly poor (I don't talk about armbian but the manufacturer, in this case, hardkernel). At least with a pi, we still have updates even for old boards. As a side note, I've heard a pi 4 if powerfull enough to act as a 1GB router, so I will also try the latest openwrt snapshot on it and may be move my x86 router on a pi 4 if all goes well.

thanks for your tests. I also tried different power supply (usb vs jack) and forced 100M with an old switch, booting without any usb device attached, it doesn't change anything

something is really strange here. I kept my "working armbian 21.0.2" test image on an sdcard with U-Boot 2021.01 on it. Last time, I checked, it worked great, eth0 active on each boot, no apparent issue. Because I've haven't configured all things on it (I have FHEM, mosquitto, a webserver, cellular dongle, wifi ap etc) I'm still running the old armbian with kernel 4.19.69-meson64 as a daily driver, which is rock solid. Now, in order to test the latest U-boot version, I've put the 21.0.2 test image card back in and guess what : eth0 doesn't work anymore. I've changed anything to this image since last time I checked. So I put the latest U-boot 2021.04-rc3 in it : same thing, still no eth0. I then put back my old sd with kernel 4.19.69-meson64 : all works as it should. The main difference I see is that the old image is using "legacy boot" so to speak as it's refered in boot.cmd vs modern boot in latest armbian. Also, the old armbian doesn't output anything on connected hdmi screen before kernel is booted while latest armbian show U-boot messages. But this different boot method doesn't explain why it worked before and not anymore. @guidol : it's possible, while, I'm not sure of it, that it work for you because you're on a 100Mbps link ? I've heard some reports that eth0 used to work on 100M but not on 1G in the past. Or it could be the environnement, connected usb device at boot, power supply. I don't recall also if your using an emmc or an sdcard ?

Thanks Igor, I will try the next nightly soon and report back

Hi Igor I don't undestand, you said that armbian use the latest stable (2021.01) but either in armbian stable or nightly, there is only 2020.10 ? or it is just the term "tend" that explain it perhaps ?

I found a more recent version of U-Boot that work nicely, eth0 is working as expected and the various test I've done show that it appear stable in various situations. this U-Boot come from opensuse and is more recent that the one used in armbian, event in latest trunk, U-Boot 2021.01 (Feb 16 2021 - 19:58:28 +0000) link to the rpm archive : http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/OdroidC2/standard/aarch64/odroidc2-firmware-20170419-5.150.aarch64.rpm for your convenience, I extracted it here (md5sum 4c52ad58f483bb8ce9fd767c6af9f077 ) : u-boot.zip

I'm trying to build U-Boot from official repo on github, I managed to successfully build it for odroid-c2 (U-Boot 2021.04-rc3-00133-ge4dba4ba6f (Mar 06 2021 - 182939 +0100) but the kernel isn't loaded, there is a bootloop. I copied only the file u-boot.bin to the boot sectors like before, but I may have missed something, is there any other file to copy ? also could this be due to the file bl1.bin.hardkernel which is not generated (a blob file ?) Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 aml log : SIG CHK : 351 for address 0x01700000 reset... GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0; TE: 114007 no sdio debug board detected BL2 Built : 11:44:26, Nov 25 2015. gxb gfb13a3b-c2 - jcao@wonton Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 aml log : SIG CHK : 351 for address 0x01700000 reset... GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0; TE: 113565 no sdio debug board detected BL2 Built : 11:44:26, Nov 25 2015. gxb gfb13a3b-c2 - jcao@wonton Board ID = 8 set vcck to 1100 mv set vddee to 1050 mv CPU clk: 1536MHz DDR channel setting: DDR0 Rank0+1 same DDR0: 2048MB(auto) @ 912MHz(2T)-13 DataBus test pass! AddrBus test pass! Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x000000b0 aml log : SIG CHK : 351 for address 0x01700000 reset... GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0; TE: 113990 no sdio debug board detected BL2 Built : 11:44:26, Nov 25 2015.

I've not switched to nightly in my current testing image since I've installed and configured some stuff, instead, I've downloaded the whole latest nightly image Armbian_21.05.0-trunk.37_Odroidc2_hirsute_current_5.10.20.img.xz (md5: d69704708d7d4b38991b8a6eea790c17) from 2021-03-05 09:50. Well, this image is broken, not only the ethernet does not work (embedded U-Boot 2020.10-armbian (Jan 12 2021 - 192822 +0100) but the OS itself doen't boot at all, it's stuck on (I think) uboot prompt > tested on 2 different sd card.

Thats when you wished a day duration should be 48h..even then, when you do things for free, it's perfectly understandable. We all have a life

Damn, and this code is supposed to drive rocket into space

I don't see any suspicious change in armbian commit between thoses dates, there is commit 07447294c7a9d11301f1aecf3bac4e53ac6a6f18 in april 2020 which add C4 support, so it means the issue should be on the main U-Boot code right ?

thanks you I can compare the two u-boot main source with this simple link : https://github.com/u-boot/u-boot/compare/v2020.04...v2020.10 But how do I add https://github.com/armbian/build/commits/master/patch/u-boot/u-boot-meson64 to the Mix ??

Like the bootloop issue I had ? > https://forum.armbian.com/topic/17112-odroid-c2-no-eth0-with-latest-image/?do=findComment&comment=120395 Do you know how to compare the changes made to u-boot between Armbian_20.11.3 (U-Boot 2020.04-armbian (Dec 12 2020 - 000749 +0100) and Armbian_20.11.6 (U-Boot 2020.10-armbian (Jan 05 2021 - 014047 +0100), because the issue seems to be caused by a change in source code here