Odroid C2 mainline kernel support

[tobetter]

@Flole, sorry for asking this. Which kernel build did you use from me before and now? How did you upgrade the kernel?

[Flole]

I was running 4.17.0-rc6-odroid-arm64 from launchpad, I would have to look up the exact link if you need it. Unfortunately that kernel seems to be missing the cpufreq scaling support and for some reason it stalls during reboot sometimes, which is why I tried to upgrade to the one from scpcom that I linked in the other post. I thought there is no newer kernel from you available than the one I am already running, which is why I attempted to switch to scpcom's kernel but that didn't really work out at all as its not booting.

[tobetter]

I was running 4.17.0-rc6-odroid-arm64 from launchpad, I would have to look up the exact link if you need it. Unfortunately that kernel seems to be missing the cpufreq scaling support and for some reason it stalls during reboot sometimes, which is why I tried to upgrade to the one from scpcom that I linked in the other post. I thought there is no newer kernel from you available than the one I am already running, which is why I attempted to switch to scpcom's kernel but that didn't really work out at all as its not booting.

Thank you for the detail. Actually I stop using Launchpad due to the size of the Linux package, I am running my PPA and pushing the mainline kernel. Unfortunately, I've not tested them on ODROID-C2 recently if the mainline kernel can boot. FYI, the mainline kernel is uploading to here, please look up linux-image-5.4.0-rc8-odroid-upstream-arm64 in the page if you are able to try it out. I will try to test it later at home.

[brad]

and then stalled. I would have expected the network to come up and the kernel to mount my rootfs and then continue booting. Anybody knows what might cause this? Is this related to my old uboot?

The network will be setup in either version of uboot and tftp with some configuration in boot.ini (or boot.scr) should allow it to work via tftp.

For NFS kernel boot we need 1 of 2 things..

- initrd loading all drivers and features required in its initramfs (PHY driver, scmmac driver, NFS drivers, dhcp, etc)
- Required modules built to the kernel and early network support (autoconfiguration) enabled

With the later and NFS the we must pass kernel parameters at bootime to configure the network early before we have access to the NFS root filesystem configuration files.

We can tell the kernel to load (autoconfigure network early boot ) with

Code: Select all

root=/dev/nfs

We can tell it the location of our root NFS file-system to boot via something like this.

Code: Select all

nfsroot=192.168.1.11:/mnt/disk1/c2/rootfs

By default it will attempt DHCP but if you want you can specify static options using the "ip=" boot parameter - see for more details https://www.kernel.org/doc/Documentatio ... fsroot.txt

For the C2 in uboot the boot parameters ends up something like this for NFS..

Code: Select all

boot=/dev/nfs ip=dhcp nfsroot=192.168.1.11:/mnt/disk1/develop/c2/rootfs rw rootwait

We can boot rw filesystem mode directly as NFS is configured early and there is no need to remount via /etc/fstab and attempt to switch from an initrd root filesystem

If you show me your uboot.[ini|scr] config (hardkernel or mainline) I can maybe offer some suggestions.

[Flole]

Hi brad,

I verified that the kernel has the ethernet module and nfs module built-in before I loaded it onto my SD Card. My cmdline looks like this and works perfectly fine for the "old" kernel, just the new one has issues with it:

Code: Select all

console=tty0 console=ttyAML0 root=/dev/nfs rw ip=dhcp,,MyOdroid nfsroot=x.x.x.x:/xx/yy/zz/1/,nfsvers=3,retrans=100 no_console_suspend consoleblank=0 disableuhs=true panic=1 

I just tried the latest build from tobetter and something isn't right there aswell: It looks like the network never gets configured, there is no error just after some time I see

Code: Select all

[  111.586538] VFS: Unable to mount root fs via NFS, trying floppy.<\r><\n>

and then it panics.

[brad]

Hi brad,

I verified that the kernel has the ethernet module and nfs module built-in before I loaded it onto my SD Card. My cmdline looks like this and works perfectly fine for the "old" kernel, just the new one has issues with it:

Code: Select all

console=tty0 console=ttyAML0 root=/dev/nfs rw ip=dhcp,,MyOdroid nfsroot=x.x.x.x:/xx/yy/zz/1/,nfsvers=3,retrans=100 no_console_suspend consoleblank=0 disableuhs=true panic=1 

I just tried the latest build from tobetter and something isn't right there aswell: It looks like the network never gets configured, there is no error just after some time I see

Code: Select all

[  111.586538] VFS: Unable to mount root fs via NFS, trying floppy.<\r><\n>

and then it panics.

I think it looks to have the Realtek PHY loading as well by the logs (built in). Does your NFS server logs show it attempting to connect / any errors? should be in messages / syslog

[Flole]

No connection attempt in the logs and it does not even respond to pings, I have the impression that something with the driver is not quite right.

[fvolk]

FWIW I did some testing with 5.4rc5, [...], but had many problems
- USB problems: no detection of devices plugged in after boot (similar problem on 4.21, works with 3.14), I tried applying https://lore.kernel.org/patchwork/patch/1031243/, which removed the warning but not the problem.

Now that 5.4 is out, and this should become a LTS release(?), does anyone know whether this long running USB problem is still unfixed?
I would really like a headless C2 server with a current kernel, but attaching a USB harddisk at a later time has to work. :-/
Although the C2 is an old product I hope it still receives some love for a 20.04 LTS minimal release image with a current kernel...

[igorpec]

Although the C2 is an old product I hope it still receives some love for a 20.04 LTS minimal release image with a current kernel...

With Armbian it receive maximum love all the time We dropped legacy builds some time ago and providing only mainline kernel based images. With a small hack - removing # its possible to build Armbian Ubuntu 20.04 LTS today but its buggy like hell ATM) ... but we have Buster (minimal), Bionic, even Bullseye (next Debian) with this kernel ... https://www.armbian.com/odroid-c2/#kernels-archive-all

System information: http://ix.io/25EH

Attaching USB (NvME) "disk":

Code: Select all

[   39.737777] usb 1-1.1: new high-speed USB device number 7 using dwc2
[   39.838473] usb 1-1.1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[   39.838491] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   39.838504] usb 1-1.1: Product: USB 2.0 Hub
[   39.839553] hub 1-1.1:1.0: USB hub found
[   39.839710] hub 1-1.1:1.0: 4 ports detected
[   39.925815] usb 1-1.3: new high-speed USB device number 8 using dwc2
[   40.026692] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[   40.026702] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   40.026707] usb 1-1.3: Product: USB 2.0 Hub
[   40.027294] hub 1-1.3:1.0: USB hub found
[   40.027437] hub 1-1.3:1.0: 4 ports detected
[   40.413755] usb 1-1.3.1: new high-speed USB device number 9 using dwc2
[   40.614323] usb 1-1.3.1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[   40.614334] usb 1-1.3.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   40.614340] usb 1-1.3.1: Product: USB 2.0 Hub
[   40.615056] hub 1-1.3.1:1.0: USB hub found
[   40.616151] hub 1-1.3.1:1.0: 4 ports detected
[   40.817760] usb 1-1.3.2: new low-speed USB device number 10 using dwc2
[   41.047501] usb 1-1.3.2: New USB device found, idVendor=0c45, idProduct=7403, bcdDevice= 0.01
[   41.047513] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   41.047519] usb 1-1.3.2: Product: USB Device
[   41.047524] usb 1-1.3.2: Manufacturer: SONiX
[   41.053962] input: SONiX USB Device as /devices/platform/soc/c9100000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:0C45:7403.0004/input/input6
[   41.114516] hid-generic 0003:0C45:7403.0004: input,hidraw0: USB HID v1.00 Keyboard [SONiX USB Device] on usb-c9100000.usb-1.3.2/input0
[   41.120243] input: SONiX USB Device Mouse as /devices/platform/soc/c9100000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.1/0003:0C45:7403.0005/input/input7
[   41.120644] input: SONiX USB Device System Control as /devices/platform/soc/c9100000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.1/0003:0C45:7403.0005/input/input8
[   41.178365] hid-generic 0003:0C45:7403.0005: input,hidraw1: USB HID v1.00 Mouse [SONiX USB Device] on usb-c9100000.usb-1.3.2/input1
[   41.225833] usb 1-1.3.1.2: new low-speed USB device number 11 using dwc2
[   41.452563] usb 1-1.3.1.2: New USB device found, idVendor=0458, idProduct=0036, bcdDevice= 1.07
[   41.452572] usb 1-1.3.1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[   41.452576] usb 1-1.3.1.2: Product: NetScroll+Mini Traveler
[   41.452580] usb 1-1.3.1.2: Manufacturer: Genius      
[   41.457208] input: Genius       NetScroll+Mini Traveler as /devices/platform/soc/c9100000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1.2/1-1.3.1.2:1.0/0003:0458:0036.0006/input/input9
[   41.457555] hid-generic 0003:0458:0036.0006: input,hidraw2: USB HID v1.10 Mouse [Genius       NetScroll+Mini Traveler] on usb-c9100000.usb-1.3.1.2/input0
[   43.065743] usb 1-1.1: reset high-speed USB device number 7 using dwc2
[   43.561710] usb 1-1.1.3: new high-speed USB device number 12 using dwc2
[   43.762998] usb 1-1.1.3: New USB device found, idVendor=152d, idProduct=1562, bcdDevice= 2.03
[   43.763025] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   43.763037] usb 1-1.1.3: Product: USB 3.0
[   43.763048] usb 1-1.1.3: Manufacturer: NFHK
[   43.763059] usb 1-1.1.3: SerialNumber: DB9876543211160
[   43.764120] usb 1-1.1.3: The driver for the USB controller dwc2_hsotg does not support scatter-gather which is
[   43.764144] usb 1-1.1.3: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
[   43.764156] usb-storage 1-1.1.3:1.0: USB Mass Storage device detected
[   43.764794] scsi host0: usb-storage 1-1.1.3:1.0
[   43.795603] usbcore: registered new interface driver uas
[   44.770694] scsi 0:0:0:0: Direct-Access     NFHK     USB 3.0          0203 PQ: 0 ANSI: 6
[   54.801038] sd 0:0:0:0: [sda] Spinning up disk...

Attaching flash drives:

Code: Select all

[  453.602842] sd 0:0:0:0: tag#0 timing out command, waited 180s
[  628.583090] usb 1-1.1.3: USB disconnect, device number 12
[  628.598661] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x01 driverbyte=0x00
[  628.598680] sd 0:0:0:0: [sda] Sense not available.
[  628.598859] sd 0:0:0:0: [sda] Attached SCSI disk
[  633.067577] usb 1-1.1: USB disconnect, device number 7
[  692.681131] usb 1-1.1: new high-speed USB device number 13 using dwc2
[  692.783311] usb 1-1.1: New USB device found, idVendor=1005, idProduct=b128, bcdDevice= 1.10
[  692.783330] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  692.783342] usb 1-1.1: Product: FLASH DRIVE
[  692.783353] usb 1-1.1: Manufacturer: USB3.0
[  692.783364] usb 1-1.1: SerialNumber: 070791FB9643E526
[  692.784469] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[  692.785022] scsi host0: usb-storage 1-1.1:1.0
[  693.814327] scsi 0:0:0:0: Direct-Access     USB3.0   FLASH DRIVE      PMAP PQ: 0 ANSI: 6
[  693.816006] sd 0:0:0:0: [sda] 30375936 512-byte logical blocks: (15.6 GB/14.5 GiB)
[  693.816610] sd 0:0:0:0: [sda] Write Protect is off
[  693.816628] sd 0:0:0:0: [sda] Mode Sense: 45 00 00 00
[  693.825814] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[  694.968678]  sda: sda1
[  694.971993] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  707.819571] usb 1-1.1: USB disconnect, device number 13
[  711.112804] usb 1-1.1: new high-speed USB device number 14 using dwc2
[  711.213721] usb 1-1.1: New USB device found, idVendor=048d, idProduct=1234, bcdDevice= 1.00
[  711.213738] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  711.213750] usb 1-1.1: Product: UDisk           
[  711.213770] usb 1-1.1: Manufacturer: General 
[  711.213781] usb 1-1.1: SerialNumber: Љ
[  711.214823] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[  711.215372] scsi host0: usb-storage 1-1.1:1.0
[  712.245817] scsi 0:0:0:0: Direct-Access     General  UDisk            5.00 PQ: 0 ANSI: 2
[  712.247508] sd 0:0:0:0: [sda] 32768000 512-byte logical blocks: (16.8 GB/15.6 GiB)
[  712.258267] sd 0:0:0:0: [sda] Write Protect is off
[  712.258288] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
[  712.258731] sd 0:0:0:0: [sda] No Caching mode page found
[  712.258786] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  712.318723] Alternate GPT is invalid, using primary GPT.
[  712.318773]  sda: sda1
[  712.321591] sd 0:0:0:0: [sda] Attached SCSI removable disk

[fvolk]

So you did figure out a way that one can boot without any USB devices attached, and some time later attaching USB devices works?
What patch did you use? Will you submit the fix to upstream?

I tried Armbian once quite some time ago, but I dropped it for some reason, can't remember why... hmm... maybe try again...

[igorpec]

So you did figure out a way that one can boot without any USB devices attached, and some time later attaching USB devices works?
What patch did you use? Will you submit the fix to upstream?

Those patches are used on top of mainline - one looks related:
https://github.com/armbian/build/tree/m ... 64-current

Features and fixes are eventually getting to mainline but we have no resources to do that on purpose - in any case this is patch author responsibility, not from Armbian maintainers. http://linux-meson.com is around, they do this job professionally. We try this and that, some fixes are ours, some from them, some from greater community.

I tried Armbian once quite some time ago, but I dropped it for some reason, can't remember why... hmm... maybe try again...

IMO each Linux has its own philosophy but with Armbian you are always close or at the max. what's possible with lowest bug count. Try it.

[fvolk]

I need a new kernel so I have the drivers to attach whatever USB Wifi/camera/harddisk/etc. and "it just works", as headless server (aka low-power data acquisition+preprocessing device).
The base OS image should be minimal and low maintenance in updates, basically SSH+Docker,
because the actual software is in a container, shared across platforms (viewtopic.php?f=54&t=36784#p274980).

[igorpec]

I need a new kernel so I have the drivers to attach whatever USB Wifi/camera/harddisk/etc. and "it just works", as headless server (aka low-power data acquisition+preprocessing device).
The base OS image should be minimal and low maintenance in updates, basically SSH+Docker,
because the actual software is in a container, shared across platforms (viewtopic.php?f=54&t=36784#p274980).

Armbian (minimal) is close to this. It is Docker ready for many years now - with our tools you can create your own image (or even a distribution) with pre-installed Docker service in no time, but if you have special needs, demands (!) or bigger quality request, consider investing your money into software development. Perhaps also cover a little part of the work which was already done by community to make your start easier. This - in our case - represent currently more than 1.5 mio EUR of donated engineering hours per year on top of freely available code to create more and better designed freely available code. Which you can use, make it better or redesign for your purpose. "just works" or "i only want stable operations" can easily costs millions.

With Armbian you have just a little more work.

[fvolk]

Tried Armbian buster "Linux odroidc2 5.4.6-meson64 #19.11.4".
For every try I shutdown, disconnected power for 30s, and restarted.

Attaching a USB keyboard after boot works.
Attaching a USB harddisk or USB SSD after boot does not work.
Attaching after boot first a keyboard works, then a USB harddisk does not.
Attaching after boot a USB disk first, then a USB keyboard sometimes works, sometimes not.
Having a USB harddisk attached during boot... and the harddisk works fine.
However, on system shutdown it sounds like an attached USB harddisk does hard emergency parking, meaning the power is cut hard to USB?

So overall, kernel 5.4.6 with Armbian patches still does not robustly support USB late plug-in?

[fvolk]

For reference: USB harddisk: Seagate Backup Plus 2TB, USB SSD: Samsung T5 500GB
Now also tried noname USB stick 8GB... nothing :-/

[igorpec]

So overall, kernel 5.4.6 with Armbian patches still does not robustly support USB late plug-in?

Not perfect, I agree, but this is probably still the best what exists.

If you find a better solution / patches I will be more than happy to implement them. It is also possible to dig in, attach scope and try to reason and fix this behavior. But that is expensive to cover.

[fvolk]

Once I was young and wrote/debugged graphics drivers in assembly real&protected mode for open source software.
Now my hair is grey and my eyes limit the time in front of a screen
I leave the low-level hardware stuff to the younger generation, sorry...

[igorpec]

Now my hair is grey and my eyes limit the time in front of a screen

Welcome to the club of grey hair & thick glasses

[sodd]

Hi,
i just tried mainline kernel and everything seems to be ok, only one thing is missing. good old lirc_odroid (gpio ir transmiter). i found a new module in kernel named gpio-ir-tx and should be the right module for my case, but here's a question.

how can i load this module and set gpio_pin parametr? coz rpi using this module throw dtoverlay in config.txt, but i have no idea how to achive this

Code: Select all

[root@alarm alarm]# modinfo gpio_ir_tx
filename:       /lib/modules/5.5.0-1-ARCH/kernel/drivers/media/rc/gpio-ir-tx.ko.gz
license:        GPL
author:         Sean Young <sean@mess.org>
description:    GPIO IR Bit Banging Transmitter
alias:          of:N*T*Cgpio-ir-txC*
alias:          of:N*T*Cgpio-ir-tx
depends:        rc-core
intree:         Y
name:           gpio_ir_tx
vermagic:       5.5.0-1-ARCH SMP mod_unload aarch64

[mad_ady]

I too am curious about using ir-tx-gpio (which is the normal succesor of lirc_odroid). Most likely the dtoverlay changes can be done direcrly in the dtb, but I haven't seen a concrete example

[chewitt]

The meson-ir kernel module supports the IR sensor on the C2 and the Odroid remote is supported with rc-odroid. Assuming your distro bundles the required parts, have a look at https://wiki.libreelec.tv/infrared_remo ... figuration

[mad_ady]

Yes, but meson-ir is for receiving IR, while we are interested in using home made ir blasters hooked up to a gpio pin, to control other devices.

[fvolk]

Due to "the situation" outside I rather stay at home.
So I want to take another try at NFS rootfs booting my C2s.
After several hours I now have a brandnew rootfs, basically as current as for my H2 cluster, but for C2.
Now I only need a kernel image that NFS boots - I have to compile this myself.

1) download 5.4.24 kernel sources .... done
2) where to get a good C2 compatible .config to start from? Odroid's C2 Wiki page is only for the old kernels :-/
3) what C2 hw support kernel modules do I have to compile-in so I don't need an initramfs - ethernet probably... anything else on ARM?
4) I'm still a bit unsure what I actually need for (u-)boot on ARM - never done this before :-/
* I like Odroid's approach of a standalone 128Mb boot partitition with just 7 files (so second/main partition can be all data)
* should I just take for first tries uImage (=uboot?) from Armbian as that boots a 5.4.x kernel?
* what files do I need in boot partition, then I patch in my own kernel image?

[fvolk]

2) actually, there is one with Armbian: 199765 config-5.4.21-meson64
...and only a bit difference to 5.4.24

[brad]

Due to "the situation" outside I rather stay at home.
So I want to take another try at NFS rootfs booting my C2s.
After several hours I now have a brandnew rootfs, basically as current as for my H2 cluster, but for C2.
Now I only need a kernel image that NFS boots - I have to compile this myself.

1) download 5.4.24 kernel sources .... done
2) where to get a good C2 compatible .config to start from? Odroid's C2 Wiki page is only for the old kernels :-/
3) what C2 hw support kernel modules do I have to compile-in so I don't need an initramfs - ethernet probably... anything else on ARM?
4) I'm still a bit unsure what I actually need for (u-)boot on ARM - never done this before :-/
* I like Odroid's approach of a standalone 128Mb boot partitition with just 7 files (so second/main partition can be all data)
* should I just take for first tries uImage (=uboot?) from Armbian as that boots a 5.4.x kernel?
* what files do I need in boot partition, then I patch in my own kernel image?

2) I use defconfig when compiling a standard kernel on C2 features needed are enabled by default. Cross compiling via buildroot then maybe just the Amlogic Platform which should enable everything

3) For proper NFS boot the following should be compiled in, kernel IP configuration, NFS client, rootnfs, ethernet & PHY so this should do it (maybe bootp is not needed)

CONFIG_REALTEK_PHY=y
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
CONFIG_DWMAC_GENERIC=y
CONFIG_DWMAC_MESON=y
CONFIG_IP_PNP=y
CONFIG_ROOT_NFS=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_DHCP=y

4) I believe armbian uses mainline uboot for C2 so it should work fine with this version. You should not need any files in the partition and can grab them all remotelyfor pxe / tftp. If you want to put them on the C2's partition then you don't need pxe or tftp to boot but can still do NFS boot.

For booting from C2 partition you need

- Kernel boot image & dtb file from your kernel build
- There is a boot.scr (This is a binary boot script) - you will probably need to make a new one for NFS rootfs boot. This is an untested basic example but might help explain what is needed (I would suggest developing script using serial console)

Code: Select all

#MMC Boot NFS
setenv kernel_addr 11000000
setenv fdt_addr 1000000
setenv fsargs "setenv bootargs root=/dev/nfs nfsroot=192.168.0.22:/c2root rw no_console_suspend fsck.fix=yes"
setenv bootcmd 'fatload mmc 0:1 ${kernel_addr} ${bootfile};fatload mmc 0:1 ${fdt_addr} ${fdtfile};run fsargs ;booti ${kernel_addr} - ${fdt_addr}'
boot

If you wanted to pxe boot, default mainline uboot (and I suspect armbian version) with nothing on C2 partition should look for boot.scr via pxe and then tftp, it should find a script which is maybe something like this (once again not tested).

Code: Select all

#TFTP boot NFS
setenv kernel_addr 11000000
setenv fdt_addr 1000000
setenv tftpbootfile Image-5.4
setenv tftpfdtfile meson-gxbb-odroidc2.dtb
setenv ipaddr 192.168.0.18
setenv serverip 192.168.0.22
setenv fsargs "setenv bootargs  root=/dev/nfs nfsroot=192.168.0.22:/c2root rw no_console_suspend fsck.fix=yes"
setenv start_odroidc2 'tftp ${kernel_addr} ${tftpbootfile};tftp ${fdt_addr} ${tftpfdtfile};run fsargs ;booti ${kernel_addr} ${initrd_loadaddr} ${fdt_addr}'
run start_odroidc2
boot

once your have the script working via serial console (either for parition based or remote boot) you can put in to a binary boot.src for uboot using this (with boot.txt being your plaintext script - you need to have uboot-tools installed for mkimage command)

Code: Select all

mkimage -A arm64 -T script -C none -n boot.txt -d boot.txt boot.scr

[brad]

2) actually, there is one with Armbian: 199765 config-5.4.21-meson64
...and only a bit difference to 5.4.24

Armbian might every have everything included you already need for kernel build (ie kernel modules build in and nfs options)

[fvolk]

Thank you for the hints!
So far I got my C2 aarch64 rootfs available on NFS, all fully configured like on my H2 setup.
I have now compiled a first "toolchain works" ~21MB Image of a 5.4.24 kernel, with the config borrowed from Armbian - compile takes forever :-/
The kernel image is surely incomplete/misconfigured, I have not yet compared the settings to my H2 setup, and things never work on first try anyway
But I guess this is for next weekend... stay tuned...

[chewitt]

https://github.com/chewitt/LibreELEC.tv ... rch64.conf
https://github.com/chewitt/linux/tree/amlogic

^ Linux 5.6-rc4 kernel and defconfig .. works fine for LE on C2, but might be missing bits for NFS boot and desktop use. Could be useful as a comparison with Armbian as it has all Amlogic specific driver bits enabled.

[alpha_one_x86]

Hi, with the kernel 5.6.6 the network card failed:
[ 77.212493] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=36)
[ 77.324125] meson8b-dwmac c9410000.ethernet: Failed to reset the dma
[ 77.324834] meson8b-dwmac c9410000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[ 77.333809] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Hw setup failed
[ 77.545393] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=36)
[ 77.651744] meson8b-dwmac c9410000.ethernet: Failed to reset the dma
[ 77.652454] meson8b-dwmac c9410000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[ 77.661432] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Hw setup failed
Reverting https://github.com/torvalds/linux/commi ... ffc5bc07e0:
[ 17.382801] meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1
[ 17.388728] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)

[Flole]

I never got it to work either with a recent kernel, I'm still stuck on 4.17 which is panicing quite often with

Code: Select all

[  218.997812] SError Interrupt on CPU2, code 0xbf000000 -- SError<\r><\n>
[  218.997821] CPU: 2 PID: 17350 Comm: python Not tainted 4.17.0-rc6-odroid-arm64 #1<\r><\n>
[  218.997822] Hardware name: Hardkernel ODROID-C2 (DT)<\r><\n>
[  218.997826] pstate: 60000000 (nZCv daif -PAN -UAO)<\r><\n>
[  218.997827] pc : 0000aaaab4c171a4<\r><\n>
[  218.997829] lr : fffffffffffffffe<\r><\n>
[  218.997830] sp : 0000fffff5e80500<\r><\n>
[  218.997831] x29: 0000fffff5e80500 x28: 0000ffff841fe148 <\r><\n>
[  218.997835] x27: 0000000000007fff x26: 0000ffff83833010 <\r><\n>
[  218.997838] x25: 0000ffff84199f10 x24: 6417988450059ae6 <\r><\n>
[  218.997840] x23: 0000000000001468 x22: 0000ffff8414b010 <\r><\n>
[  218.997843] x21: 0000ffff84199f10 x20: 0000ffff8414d188 <\r><\n>
[  218.997846] x19: 0000ffff841fe168 x18: 0fcfab30f11ac858 <\r><\n>
[  218.997848] x17: 007e7d598788c70b x16: 0000ffff8389f868 <\r><\n>
[  218.997851] x15: 000000000000003b x14: 000000000000003c <\r><\n>
[  218.997853] x13: 0000aaaab4ea4000 x12: 0000000000007fff <\r><\n>
[  218.997856] x11: 0000000000006164 x10: 0000000000000000 <\r><\n>
[  218.997858] x9 : 0000000000000002 x8 : 0000ffff838c5170 <\r><\n>
[  218.997861] x7 : 00000000000000e9 x6 : 0000000000000000 <\r><\n>
[  218.997864] x5 : 0000ffff8414b010 x4 : 0000aaaab4ec6d90 <\r><\n>
[  218.997866] x3 : 0000000000000018 x2 : 000000000000d90b <\r><\n>
[  218.997869] x1 : 00000000000000e8 x0 : 0000aaaab4ebecb0 <\r><\n>
[  218.997874] Kernel panic - not syncing: Asynchronous SError Interrupt<\r><\n>
[  218.997877] CPU: 2 PID: 17350 Comm: python Not tainted 4.17.0-rc6-odroid-arm64 #1<\r><\n>
[  218.997878] Hardware name: Hardkernel ODROID-C2 (DT)<\r><\n>
[  218.997880] Call trace:<\r><\n>
[  218.997893]  dump_backtrace+0x0/0x188<\r><\n>
[  218.997897]  show_stack+0x14/0x20<\r><\n>
[  218.997902]  dump_stack+0x9c/0xbc<\r><\n>
[  218.997906]  panic+0x11c/0x290<\r><\n>
[  218.997908]  nmi_panic+0x6c/0x70<\r><\n>
[  218.997911]  arm64_serror_panic+0x74/0x88<\r><\n>
[  218.997914]  do_serror+0xbc/0xc0<\r><\n>
[  218.997917]  el0_error_naked+0x10/0x18<\r><\n>
[  218.997923] SMP: stopping secondary CPUs<\r><\n>
[  218.997931] Kernel Offset: disabled<\r><\n>
[  218.997934] CPU features: 0x24802004<\r><\n>
[  218.997935] Memory Limit: none<\r><\n>

A more recent kernel might be more stable, who knows, but I can't try it as it won't boot

[alpha_one_x86]

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index b46ef985bb44..c6cf82c607f4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -199,8 +199,8 @@ eth_phy0: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;

- reset-assert-us = <10000>;
- reset-deassert-us = <30000>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
The patch needed for vanilla

[chewitt]

https://github.com/chewitt/linux/commit ... -5.7-integ
https://github.com/chewitt/linux/commits/amlogic

^ those are my current working branches for 5.7(rc2) - no issues with networking that I'm aware of when I was testing.

[brad]

Seen no issues on Armbian buster with Linux 5.4.28-meson64 as a dhcp / dns server. Will have to see what happens when I upgrade.

[miskol]

https://github.com/chewitt/linux/commit ... -5.7-integ
https://github.com/chewitt/linux/commits/amlogic

^ those are my current working branches for 5.7(rc2) - no issues with networking that I'm aware of when I was testing.

Do you have any idea how to get hdmi audio working?

[fvolk]

Thank you for the hints!
So far I got my C2 aarch64 rootfs available on NFS, all fully configured like on my H2 setup.
I have now compiled a first "toolchain works" ~21MB Image of a 5.4.24 kernel, with the config borrowed from Armbian - compile takes forever :-/
The kernel image is surely incomplete/misconfigured, I have not yet compared the settings to my H2 setup, and things never work on first try anyway ;-)
But I guess this is for next weekend... stay tuned...

Ok, because of the curfew and before I lose interest because of upcoming C4 where everything will be better ;-), let's try this again.

Rebuild my kernel, compiled-in all necessary modules for the platform - I think.
Patched an Armbian install with my kernel, rebuild the boot script for u-boot, guessing options...

Booting my kernel I see in DHCP server log:

dnsmasq-dhcp[18001]: 104083227 vendor class: U-Boot.armv8
dnsmasq-dhcp[18001]: 104083227 DHCPDISCOVER(eth0) 00:1e:06:xx:xx:xx
dnsmasq-dhcp[18001]: 104083227 tags: known, eth
dnsmasq-dhcp[18001]: 104083227 DHCPOFFER(eth0) 192.168.1.xx 00:1e:06:xx:xx:xx
dnsmasq-dhcp[18001]: 104083227 requested options: 1:netmask, 3:router, 6:dns-server, 12:hostname,
dnsmasq-dhcp[18001]: 104083227 requested options: 17:root-path

So my kernel is booting and requesting an IP, network drivers are working.
But the screen remains off - so I don't know where it hangs.
Kernel also does not blink blue "alive" led.
I can't ping the IP, so probably it hangs quite early :-(

On x86 systems one always has screen output due to BIOS/UEFI, and compiled-in DRM driver also give high resolution console.
On arm/C2... who is switching on graphics and console?
Am I missing a module? Am I missing a boot option? Does the kernel init graphics by himself on ARM?

Any hint to find out where it hangs appreciated...
Or only via serial console? What do I have to buy?

Stay healthy everyone, don't go outside, stay home and play with Odroids! :-)

[fvolk]

ohhhhh.... wait... the log says vendor U-boot is asking for an IP?
But I passed "ip=dhcp" as bootarg to kernel ...or did I?

[tobetter]

ohhhhh.... wait... the log says vendor U-boot is asking for an IP?
But I passed "ip=dhcp" as bootarg to kernel ...or did I?

If the blue LED is on but not blinking, your C2 is stuck at U-boot. In U-boot, you can see the log through serial console only.
Have you ever boot with any OS image with your C2 yet?

[fvolk]

I got it working , root over NFS! :-)

c2boot.png (27.75 KiB) Viewed 4489 times

The winner is following script by brad - thank you brad!:

setenv kernel_addr 11000000
setenv fdt_addr 1000000
setenv fdtfile boot/meson-gxbb-odroidc2.dtb
setenv bootfile boot/Image
setenv fsargs "setenv bootargs init=/mydisklessinit ip=dhcp root=/dev/nfs nfsroot=192.168.1.xx:/c2,tcp,vers=4.1 no_console_suspend fsck.fix=yes"
setenv bootcmd 'load mmc 0:1 ${kernel_addr} ${bootfile};load mmc 0:1 ${fdt_addr} ${fdtfile};run fsargs ;booti ${kernel_addr} - ${fdt_addr}'
boot

The bug was it has to "load" and not "fatload" - Armbian has just one Linux partition, Odroid's original image has a FAT first partition.
Question 1: Are the load addresses 11000000 and 1000000 of any significance?
Question 2: See picture, free shows total ~2G of mem, dmesg shows 262144K cma-reserved and only 1754636K/2075648K available - what is now correct?

TODO:
Do a PXE boot directly via u-boot - probably brad's second version works, too :-)
Figure out how to install u-boot to a fresh microSD card.
Turn graphics off again to reclaim memory?
Swap over NFS possible?

[rooted]

"Look at the big brain on Brad!" - Pulp Fiction

[brad]

The bug was it has to "load" and not "fatload" - Armbian has just one Linux partition, Odroid's original image has a FAT first partition.
Question 1: Are the load addresses 11000000 and 1000000 of any significance?
Question 2: See picture, free shows total ~2G of mem, dmesg shows 262144K cma-reserved and only 1754636K/2075648K available - what is now correct?

TODO:
Do a PXE boot directly via u-boot - probably brad's second version works, too
Figure out how to install u-boot to a fresh microSD card.
Turn graphics off again to reclaim memory?
Swap over NFS possible?

I'm glad it worked for you

1) 11000000 is a bit random but workable, uboot will relocate the kernel on boot and free this ram for the kernel. 1000000 is the device tree, I suggest leaving it there for reasons I don't completely understand. It is the first region of physical RAM (after the core dump area) that kernel will address on amlogic and where it expects to find the dtb in ram.

2) cma is probably allocated for some firmware to use, video or maybe wifi if you have it? I cannot be sure on this. Try setting cma=100M as a boot parameter in uboot to see if reduces it and things are stable. You can try 0 if you really want to see what happens

I haven't tested the full PXE boot setup but I have seen it trying during packet captures on my dhcp server, Swap over NFS might be possible but a huge wack to performance I would say.

[brad]

"Look at the big brain on Brad!" - Pulp Fiction

Yesterday I spent 1 hour trying to work out why I had no sound. It helps if you turn up the volume. Doh!

[fvolk]

I'm a bit further, this boots from TFTP - thanks again brad for inspiration!

setenv kernel_addr 11000000
setenv fdt_addr 1000000
setenv fdtfile c2/meson-gxbb-odroidc2.dtb
setenv bootfile c2/Image
setenv ipaddr 192.168.1.yy
setenv serverip 192.168.1.xx
setenv fsargs "setenv bootargs init=/mydisklessinit ip=dhcp root=/dev/nfs nfsroot=192.168.1.xx:/c2,tcp,vers=4.1 no_console_suspend fsck.fix=yes"
setenv bootcmd 'tftp ${kernel_addr} ${bootfile}; tftp ${fdt_addr} ${fdtfile}; run fsargs; booti ${kernel_addr} - ${fdt_addr}'
run bootcmd
boot

This moves the kernel image and dtb file also to the server, so a kernel upgrade can be done on one place on the server for all diskless clients :-)
This solution still has one problem, the hard-coded ipaddr.
U-boot should obtain its IP via DHCP.
Removing the line with "ipaddr" boot hangs.
U-boot knows "dhcp" command, and I see the request on server, but this command immediately tries to boot one image.
The command "setenv autoload no" should tell "dhcp" to just config network and do nothing more, but this does not seem to work :-(

Going full PXE is probably not worth the work. The C2 needs microSD with uboot anyway, and if the boot.scr is generic that's fine.
Also, currently in my setup PXE is configured for the H2s, so this surely must be reconfigured to offer H2s and C2s different files.
If I get this to work with the C2 I expect it to work the same for the upcoming C4s.....
hmm, maybe the C4 can boot the same kernel image+filesystem from the server like the C2s, only with different dtb? That would great.

[fvolk]

btw, with this 5.4.24 kernel USB seems still broken - attaching a USB harddisk after boot is not recognized :-/

[moon.linux]

btw, with this 5.4.24 kernel USB seems still broken - attaching a USB harddisk after boot is not recognized :-/

You probably need to connect another USB dongle along with USB Hard disk in parallel for harddisk to get detected.

[fvolk]

btw, with this 5.4.24 kernel USB seems still broken - attaching a USB harddisk after boot is not recognized :-/

You probably need to connect another USB dongle along with USB Hard disk in parallel for harddisk to get detected.

Upgraded to 5.4.38.
Yes, attaching a USB keyboard AND a USB harddisk apparently makes the harddisk work.
This is a workaround, but a harddisk not being detected alone is not good, I want to run a headless server :-/

[MimCom]

Slightly off-topic, but IMO noteworthy that the C4 has a 20.04 LTS build (with Wayland) on kernel 4.9 but with a 5.4 experimental branch. Sure would look pretty if reworked for the C2

[Lost Dog]

Slightly off-topic, but IMO noteworthy that the C4 has a 20.04 LTS build (with Wayland) on kernel 4.9 but with a 5.4 experimental branch. Sure would look pretty if reworked for the C2

I believe Armbian has a 20.04 LTS with 5.6 for the C2. I've played around with it a bit and it seemed stable.

[fvolk]

I have now all the pieces working. Taking a fresh 64GB sdcard, turning it into a diskless node:

Code: Select all

Disk /dev/mmcblk1: 59,3 GiB, 63685263360 bytes, 124385280 sectors
Device         Boot   Start       End   Sectors  Size Id Type
/dev/mmcblk1p1         2048    264191    262144  128M 83 Linux
/dev/mmcblk1p2       264192   6555647   6291456    3G 83 Linux
/dev/mmcblk1p3      6555648 124385279 117829632 56,2G 83 Linux

First, burn a shiny new U-Boot 2020.04 bootloader image.

p1 is /boot with just one file (boot.scr) to boot from TFTP+NFS root:

Code: Select all

setenv kernel_addr 11000000
setenv fdt_addr 1000000
setenv fdtfile c2/meson-gxbb-odroidc2.dtb
setenv bootfile c2/Image
setenv autoload no
dhcp
setenv serverip 192.168.1.xx
tftp ${kernel_addr} ${bootfile}
tftp ${fdt_addr} ${fdtfile}
setenv bootargs init=/mydisklessinit ip=dhcp root=/dev/nfs nfsroot=192.168.1.xx:/c2,tcp,vers=4.1 no_console_suspend fsck.fix=yes
booti ${kernel_addr} - ${fdt_addr}
boot

p2 is 3GB emergency swap for tight ram situations:

Code: Select all

dmesg |grep swap
[   12.570783] Adding 3145724k swap on /dev/mmcblk1p2.  Priority:-2 extents:1 across:3145724k SSFS

p3 is data, e.g. local docker image storage (if partition is found at boot Docker is started, else not)

Rootfs / is provided ro via NFS, with in-memory overlay rw layer on top:

Code: Select all

df -h |sort -k 6
overlay                986M  224K  985M   1% /
/dev/mmcblk1p1         124M  1,6M  123M   2% /boot
devtmpfs                10M     0   10M   0% /dev
192.168.1.xx:/c2/home  834G   78G  756G  10% /home
192.168.1.xx:/c2/root  834G   78G  756G  10% /root
tmpfs                  198M  276K  197M   1% /run
/dev/mmcblk1p3          56G  1,5G   54G   3% /zd

This construction gives my C2s an extended time of useful life, I can now install and test distributed applications on a mini cluster of C2s easily, all running the identical, updated base software :-)
Thanks for all the help!

...now on to the C4 ;-)

[aatoma]

I have now all the pieces working....

Does this mean that you can put together a short tutorial about how to install a fully functional (USB hotplugging included) C2 with up to date kernel?

[fvolk]

Unfortunately plug-in of USB devices after boot is still broken, I currently run 5.4.38.
I have to plug in one USB keyboard and only then something else (e.g. USB stick) is also working. This is annoying :-/

I started with diskless H2 nodes, now diskless C2 nodes, and when the C4s arrive I hope the port is not much work.
I considered writing a summary from my private notes on what to patch for diskless, the process is similar on the different Odroids, however then I would have to make at least a test setup from scratch and this is quite some work. :-/
Once the C4s work, too, we'll see...