Odroid M1

[Shaun Maher]

Hi all.

 

Regarding Petitboot that comes pre-installed in the Odroid M1's SPI.  I 100% understand that the current image does not support Petitboot.  I understand it is a work in progress.  Is the intention though, to have the final production image support
Petitboot?

 

My understanding (and am happy to be corrected) is that without petitboot, booting from SATA/NVMe, without any other storage devices attached, isn't possible (u-boot limitation?).

 

I've been stuffing about and I have been able to get the current WIP build copied to NVMe SSD and booting from petitboot (with one outstanding limitation).  At a high level:

• Copy the "Armbian_22.11.0-trunk_Odroidm1_kinetic_edge_6.1.0-rc1.img.xz" to a USB stick.  Not DD/Etcher/whatever.  Just copied to the USB stick
  • It might be possible to download the image directly within the petitboot shell but the bundled busybox wget command doesn't support https.
• Boot the M1 into petitboot with the above USB stick plugged in.
• Extract and DD the image onto the NVMe block device
  • The USB stick will likely already be mounted in /usr/var/petitboot/mnt/dev/sda1/, so...
  • xz -d -c /usr/var/petitboot/mnt/dev/sda1/Armbian_22.11.0-trunk_Odroidm1_kinetic_edge_6.1.0-rc1.img.xz | dd of=/dev/nvme0n1 bs=4k
• Tamper with the installed image a little before attempting to boot it:
  • mkdir /mnt/nvme0n1p1
  • mount /dev/nvme0n1p1 /mnt/nvme0n1p1
  • rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
  • rm /mnt/nvme0n1p1/boot/boot.ini  (for good measure)
  • Create a petitboot kboot.conf file with suitable settings:
    • echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000"  >/mnt/nvme0n1p1/etc/kboot.conf
  • Reboot
    • echo 1 > /proc/sys/kernel/sysrq
    • echo b > /proc/sysrq-trigger

 

The main limitation with the above, which might be entirely because I'm only a few hours into learning about petitboot, is that using the above method still requires manual intervention at boot time.  The above will add Armbian into the petitboot menu but it won't boot it automatically.  You need to select it with the arrows and hit enter to start it booting.  I'm going to post some questions on the Odroid forum and hopefully get this final quirk resolved.

 

Cheers

Shaun

[Igor]

12 hours ago, Shaun Maher said:

current image does not support Petitboot.

 

Idea is to get rid of everything that smells on proprietary boot loader and all dirty hacks that are required that this hardware boots up. But when this is not finished and become stable there is little to do.

[hi-ko]

a big thumbs up! With the odroidm1 sid-build I managed for the first time to successfully test my use case with lxd and zfs!

Only problem I had:
After installing the zfsutils-linux the kernel module was missing:
 

# /sbin/modprobe zfs
modprobe: FATAL: Module zfs not found in directory /lib/modules/5.19.0-odroid-arm64

I got it working by manually installing/compiling the kernel module:
 

apt install linux-headers-arm64 zfs-dkms

Is this an issue in the debian upstream or in the armbian build?
I am looking forward to a first release!

[rpardini]

I've had great success with the new 6.1-rcX based images. Applying mmind's tree for the DTS only. Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged.

 

Keep in mind these images don't use Petitboot "the kexec stuff" itself but does use the u-boot included in SPI (which is part of Petitboot), and require the env to skip petitboot.

 

 

 

 

[rpardini]

On 11/2/2022 at 9:03 AM, Shaun Maher said:

Tamper with the installed image a little before attempting to boot it:

• mkdir /mnt/nvme0n1p1
• mount /dev/nvme0n1p1 /mnt/nvme0n1p1
• rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
• rm /mnt/nvme0n1p1/boot/boot.ini  (for good measure)
• Create a petitboot kboot.conf file with suitable settings:
  • echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000"  >/mnt/nvme0n1p1/etc/kboot.conf
•  

 

 

Yeah, you can convince Petitboot to `kexec` into Armbian's kernel. Probably can be done on other Petitboot boards too. By then, vendor's uboot, and vendor's kernel is already loaded, `kexec`'ing then into an Armbian mainline kernel. "It works" until it doesn't...

[usual user]

46 minutes ago, rpardini said:

Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged.

I doubt it, if mainline development continues at the same rate as before, the next WIP patches for the pending drivers will certainly be available at this time.

[j0ta]

After compiling Bullseye everything is ok, just one little problem I updated firmware using

armbian-firmware-full

and it downgraded from 22.11.0-trunk to 22.08.6

[usual user]

Odroid-M1 support has just landed  so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.

[rpardini]

8 hours ago, usual user said:

Odroid-M1 support has just landed  so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.

 

Excellent news @usual user. I've bumped Armbian to 6.1 plus the DTS patches. 

My own image at https://github.com/rpardini/armbian-release/releases/download/20221213a/Armbian_20221213a-rpardini_Odroidm1_kinetic_edge_6.1.0.img.xz

Igor has community images too, including desktops... https://github.com/armbian/community/releases (might be some 6.1-rcX still, should be updated the next few days).

 

Any news about ATF and u-boot?

[usual user]

17 hours ago, rpardini said:

Any news about ATF and u-boot?

TF-A is progressing slowly, but there seem to be still open questions.
The DT rebase of u-boot has taken place. It still takes a rebase to be up to date, but this is only a small thing, because the basic structure conversion has already taken place.

But I haven't seen any movement in uboot WIP trees that I'm aware of. IMHO they are waiting to see how the TF-A development turns out in the end to develop u-boot accordingly further. I will report when I get news.
But the most important thing is that for the kernel only the rkvdec2 support is missing, and for the userspace only the FFmpeg v4l2-request support is missing to be usable out-of-the-box with pure mainline support for standard applications. It is thus available for all distributions without special effort for the Odroid-M1. They only have to maintain the distribution-specific modifications that they apply for other devices anyway.
I'm currently playing with jernej's FFmpeg patches for v4l2-request support and VP8 acceleration seems to work. H.264 fails with this error:

[h264_v4l2m2m @ 0xaaaabfc5ae10] Could not find a valid device
[h264_v4l2m2m @ 0xaaaabfc5ae10] can't configure decoder

But I don't know if the 5.1.2 paches basically work or how I can inspect the FFmpeg framework appropriately. With the gstreamer framework, however, everything works as expected.

[Kiendeleo]

I know a solution is being worked on for the lack of NVME boot capability.

 

In the meantime, is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

[usual user]

1 hour ago, Kiendeleo said:

is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

Sure, with distro-boot only a suitable firmware in the firmware area and three files in a partition accessible from the firmware is required.
Because I still have Petitboot in SPI flash, I used @rpardini's initial image as boot trampoline, because Petitboot requires a very special partition layout. Then the kernel binary, the DTB and extlinux.conf copied into the partition, and my operating system is entirely run by the NVME. It should be noted that the kernel binary must be uncompressed, as the legacy firmware does not even support compressed kernel binaries.
I use a microSD card as boot trampoline, because the firmware only reads it, and I only mount it from the operating system read-write if I want to update the kernel binary or the DTB. But an eMMC works the same way. The only annoying thing about this method is the need to copy the kernel binary and DTB over, but this is a simple workaround until mainline firmware is available.

[rpardini]

2 hours ago, Kiendeleo said:

In the meantime, is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

 

I used `armbian-install` (nee `nand-sata-install`) for this with success.

It can use a small boot partition (/boot) on the eMMC to jumpstart kernel, but mount root in NVMe.

Take care to not overwrite SPI/MTD accidentally.

 

[Kiendeleo]

20 hours ago, rpardini said:

I used `armbian-install` (nee `nand-sata-install`) for this with success.

The first time I ran this command, I was only presented with "Boot from SD" and "Boot from SPI" as options. The only drives attached to the board were an eMMC and an NVME Drive. I chose the "Boot From SD" and selected my NVME drive as the target in the next step, which seems to work. After completing the conversion and rebooting, if I run the `sudo armbian-install` command, I am given options for the eMMC. It is working correctly. Is this a bug? Also, is there a manpage somewhere for the `armbian-install` command?

[usual user]

My first u-boot build:

Spoiler

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2023.03.24 22:11:36 =~=~=~=~=~=~=~=~=~=~=~=
DDR Version V1.11 20211103
In
ddrconfig:7
LPDDR4X, 324MHz
BW=32 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=8192MB
tdqss: cs0 dqs0: 48ps, dqs1: -72ps, dqs2: -48ps, dqs3: -144ps,
tdqss: cs1 dqs0: 48ps, dqs1: -72ps, dqs2: -48ps, dqs3: -144ps,

change to: 324MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:41%, vrefout:41%
dram drv:40,odt:0
clk skew:0x61

change to: 528MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:41%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58

change to: 780MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:41%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58

change to: 1560MHz(final freq)
PHY drv:clk:36,ca:36,DQ:29,odt:60
vrefinner:16%, vrefout:22%
dram drv:40,odt:80
vref_ca:00000071
clk skew:0x21
cs 0:
the read training result:
DQS0:0x32, DQS1:0x32, DQS2:0x38, DQS3:0x2a,
min  : 0xf  0xf 0x14 0x10  0x2  0x5  0xa  0x7 , 0xb  0x9  0x1  0x1  0xf  0xc  0xd  0x9 ,
      0x14 0x14  0xf  0xd  0x8  0x2  0x7  0x9 , 0xb  0x5  0x8  0x1 0x10  0xd  0xa  0xc ,
mid  :0x29 0x2b 0x2e 0x2c 0x1d 0x21 0x24 0x20 ,0x24 0x22 0x1a 0x1c 0x28 0x24 0x25 0x23 ,
      0x2f 0x30 0x28 0x28 0x23 0x1e 0x21 0x23 ,0x23 0x20 0x1f 0x1a 0x2a 0x27 0x24 0x27 ,
max  :0x44 0x47 0x48 0x48 0x38 0x3e 0x3e 0x3a ,0x3e 0x3b 0x34 0x38 0x42 0x3d 0x3e 0x3d ,
      0x4b 0x4d 0x42 0x44 0x3f 0x3b 0x3b 0x3e ,0x3b 0x3b 0x37 0x34 0x44 0x42 0x3e 0x42 ,
range:0x35 0x38 0x34 0x38 0x36 0x39 0x34 0x33 ,0x33 0x32 0x33 0x37 0x33 0x31 0x31 0x34 ,
      0x37 0x39 0x33 0x37 0x37 0x39 0x34 0x35 ,0x30 0x36 0x2f 0x33 0x34 0x35 0x34 0x36 ,
the write training result:
DQS0:0x2a, DQS1:0x13, DQS2:0x18, DQS3:0x5,
min  :0x73 0x76 0x78 0x77 0x65 0x6c 0x6f 0x6f 0x6d ,0x54 0x52 0x4c 0x4f 0x56 0x54 0x57 0x54 0x50 ,
      0x60 0x62 0x5a 0x58 0x50 0x50 0x53 0x55 0x57 ,0x4d 0x49 0x48 0x45 0x4f 0x4f 0x4d 0x52 0x46 ,
mid  :0x8f 0x91 0x93 0x91 0x7f 0x85 0x89 0x87 0x84 ,0x6f 0x6e 0x66 0x69 0x71 0x6f 0x71 0x6e 0x6a ,
      0x7d 0x7d 0x75 0x74 0x6c 0x6b 0x6e 0x70 0x72 ,0x67 0x64 0x62 0x5f 0x6a 0x6c 0x67 0x6d 0x61 ,
max  :0xac 0xad 0xaf 0xac 0x99 0x9f 0xa3 0xa0 0x9b ,0x8b 0x8b 0x80 0x83 0x8c 0x8b 0x8c 0x89 0x85 ,
      0x9a 0x99 0x90 0x90 0x89 0x86 0x89 0x8c 0x8d ,0x82 0x80 0x7d 0x79 0x86 0x89 0x82 0x89 0x7d ,
range:0x39 0x37 0x37 0x35 0x34 0x33 0x34 0x31 0x2e ,0x37 0x39 0x34 0x34 0x36 0x37 0x35 0x35 0x35 ,
      0x3a 0x37 0x36 0x38 0x39 0x36 0x36 0x37 0x36 ,0x35 0x37 0x35 0x34 0x37 0x3a 0x35 0x37 0x37 ,
cs 1:
the read training result:
DQS0:0x33, DQS1:0x34, DQS2:0x35, DQS3:0x2d,
min  : 0xe  0xd 0x12  0xf  0x2  0x6  0x9  0x5 , 0xa  0xa  0x1  0x1 0x10  0xc  0xe  0x9 ,
      0x12 0x14  0xe  0xb  0x5  0x0  0x4  0x8 , 0xc  0x7  0x9  0x2 0x11  0xf  0xc  0xf ,
mid  :0x29 0x2a 0x2d 0x2b 0x1e 0x21 0x23 0x20 ,0x24 0x23 0x1b 0x1e 0x2a 0x25 0x28 0x24 ,
      0x2e 0x2f 0x27 0x27 0x20 0x1c 0x1f 0x22 ,0x25 0x22 0x21 0x1c 0x2c 0x2a 0x26 0x2a ,
max  :0x45 0x47 0x49 0x47 0x3b 0x3d 0x3e 0x3b ,0x3f 0x3d 0x36 0x3b 0x45 0x3f 0x42 0x3f ,
      0x4b 0x4b 0x41 0x43 0x3b 0x38 0x3a 0x3d ,0x3e 0x3d 0x3a 0x36 0x47 0x45 0x40 0x45 ,
range:0x37 0x3a 0x37 0x38 0x39 0x37 0x35 0x36 ,0x35 0x33 0x35 0x3a 0x35 0x33 0x34 0x36 ,
      0x39 0x37 0x33 0x38 0x36 0x38 0x36 0x35 ,0x32 0x36 0x31 0x34 0x36 0x36 0x34 0x36 ,
the write training result:
DQS0:0x2a, DQS1:0x13, DQS2:0x18, DQS3:0x5,
min  :0x72 0x76 0x77 0x74 0x65 0x6a 0x6d 0x6d 0x6a ,0x53 0x50 0x4a 0x4e 0x56 0x52 0x55 0x53 0x4c ,
      0x61 0x61 0x5b 0x59 0x52 0x4f 0x53 0x55 0x56 ,0x4a 0x49 0x46 0x43 0x4e 0x4d 0x4a 0x50 0x45 ,
mid  :0x90 0x92 0x94 0x90 0x7d 0x83 0x88 0x86 0x82 ,0x6f 0x6d 0x64 0x68 0x71 0x6e 0x70 0x6e 0x68 ,
      0x7e 0x7d 0x76 0x76 0x6d 0x6b 0x6e 0x71 0x72 ,0x66 0x64 0x61 0x5d 0x6a 0x6b 0x66 0x6c 0x61 ,
max  :0xae 0xae 0xb1 0xad 0x95 0x9d 0xa4 0x9f 0x9b ,0x8b 0x8a 0x7f 0x82 0x8c 0x8a 0x8b 0x89 0x85 ,
      0x9b 0x9a 0x92 0x93 0x89 0x87 0x89 0x8d 0x8e ,0x82 0x7f 0x7d 0x78 0x87 0x89 0x82 0x89 0x7d ,
range:0x3c 0x38 0x3a 0x39 0x30 0x33 0x37 0x32 0x31 ,0x38 0x3a 0x35 0x34 0x36 0x38 0x36 0x36 0x39 ,
      0x3a 0x39 0x37 0x3a 0x37 0x38 0x36 0x38 0x38 ,0x38 0x36 0x37 0x35 0x39 0x3c 0x38 0x39 0x38 ,
CA Training result:
cs:0 min  :0x53 0x57 0x49 0x46 0x49 0x44 0x4f ,0x4f 0x4d 0x44 0x42 0x45 0x42 0x4d ,
cs:0 mid  :0x92 0x92 0x88 0x84 0x88 0x81 0x80 ,0x8d 0x8b 0x82 0x80 0x83 0x80 0x7e ,
cs:0 max  :0xd1 0xce 0xc7 0xc2 0xc7 0xbf 0xb2 ,0xcc 0xc9 0xc0 0xbe 0xc2 0xbf 0xaf ,
cs:0 range:0x7e 0x77 0x7e 0x7c 0x7e 0x7b 0x63 ,0x7d 0x7c 0x7c 0x7c 0x7d 0x7d 0x62 ,
cs:1 min  :0x51 0x5c 0x45 0x4d 0x49 0x48 0x54 ,0x4e 0x52 0x41 0x48 0x43 0x48 0x4b ,
cs:1 mid  :0x93 0x93 0x88 0x86 0x89 0x80 0x85 ,0x8f 0x8c 0x82 0x80 0x85 0x81 0x7e ,
cs:1 max  :0xd6 0xcb 0xcc 0xc0 0xc9 0xb9 0xb6 ,0xd1 0xc7 0xc4 0xb9 0xc7 0xba 0xb2 ,
cs:1 range:0x85 0x6f 0x87 0x73 0x80 0x71 0x62 ,0x83 0x75 0x83 0x71 0x84 0x72 0x67 ,
out

U-Boot SPL 2023.04-rc4 (Mar 24 2023 - 00:00:00 +0000)
Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():v2.3-152-g4e725b15f:cl
NOTICE:  BL31: Built : 10:51:13, Jul 15 2021
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    pmu v1 is valid
INFO:    dfs DDR fsp_param[0].freq_mhz= 1560MHz
INFO:    dfs DDR fsp_param[1].freq_mhz= 324MHz
INFO:    dfs DDR fsp_param[2].freq_mhz= 528MHz
INFO:    dfs DDR fsp_param[3].freq_mhz= 780MHz
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE w
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xa00000
INFO:    SPSR = 0x3c9


U-Boot 2023.04-rc4 (Mar 24 2023 - 00:00:00 +0000)

Model: Hardkernel ODROID-M1
DRAM:  8 GiB (effective 7.7 GiB)
Core:  311 devices, 26 uclasses, devicetree: separate
MMC:   mmc@fe2b0000: 1, mmc@fe310000: 0
Loading Environment from nowhere... OK
In:    serial@fe660000
Out:   serial@fe660000
Err:   serial@fe660000
Model: Hardkernel ODROID-M1
can't get vref-supply: -2
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:   No ethernet found.
Hit any key to stop autoboot:  2  1  0
Card did not respond to voltage select! : -110
Bus usb@fcc00000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd800000: USB EHCI 1.00
Bus usb@fd880000: USB EHCI 1.00
scanning bus usb@fcc00000 for devices... 1 USB Device(s) found
scanning bus usb@fd000000 for devices... 1 USB Device(s) found
scanning bus usb@fd800000 for devices... 2 USB Device(s) found
scanning bus usb@fd880000 for devices... 5 USB Device(s) found
No ethernet found.
No ethernet found.
=>

 

 

[rpardini]

On 3/24/2023 at 10:50 PM, usual user said:

U-Boot 2023.04-rc4 (Mar 24 2023 - 00:00:00 +0000)

Model: Hardkernel ODROID-M1

 

Hey @usual user -- where lie the patches for this? I'm interested 😉

 

[Vodalex]

Hello guys!

 

Just tried another release (community) of armbian for Odroid M1 (Armbian_23.02.0-trunk_Odroidm1_sid_edge_6.1.11.img)

Network seems to work fine here but why does the device show random ip instead of using the physical one, printed on the board?

[usual user]

On 3/31/2023 at 1:57 PM, rpardini said:

where lie the patches for this?

They are floating around. Some of them are in flight to land in mainline, some are WIP in heavy flux. In terms of functionality, mainline would not be able to do more than legacy so far. And since your offered legacy firmware works so far, there is currently no reason to do the work now to use the current mainline version. It is only interesting for someone who wants to add e.g. VOP2 or NVME driver support and ports the drivers from Linux kernel. For all pure users it is easier to wait until all outstanding components have landed and then just use mainline. Anyway, my SPEC file for the uboot-tools package is now ready to build M1 firmware as soon as needed. However, this will certainly take until 2023.07 at the earliest, because there are still some components under discussion and 2023.04 should be available next week.

[rpardini]

On 4/1/2023 at 3:38 PM, usual user said:

They are floating around

 

Thanks for the report. For a minute I thought something more radical had happened, but it seems situation is mostly the same. In the end, it's about SPI -> NVMe boot, possibly with basic EFI support, that would shift the status quo.

For now it seems "interested-enough" users can manage to make pboot boot the Armbian image and make it work decently well for most server/NAS/etc needs.

We do have a few outstanding issues, like Eth MAC being random, any idea about that? (usually also at u-boot level, but I haven't looked into how HK does things)

 

[Michel Lamoré]

I've recently installed Armbian 23.02 on my Odroid. It boots faster than the official Ubuntu 20.04 build from Hardkernel, which I find quite impressive! One problem I run into is how my display looks. When I set the resolution to 1280*720, everything looks fine. However, when I set the resolution to the native resolution of my monitor, 1680*1050, letters are not always correctly displayed. Is this some kind of HiDPI font issue? The display I am using is connected via VGA (using a HDMI to VGA adapter). On the official build text looks normal at 1680*1050.

(1280*720 on Armbian)

 

 (1680*1050 on Armbian. Notice the distorted text below "fractional scaling")

 

 (1680*1050 on Ubuntu, no distortion here)

Edited April 6, 2023 by Michel Lamoré
Added more details

[usual user]

@Kwiboo did a fantastic job. Mainline u-boot becomes usable (console.log) for me.
It enumerates my different systems on different storage media and can natively load the boot components from them.
The use of compressed kernels does not work yet, it bails out like this:

Spoiler

** Booting bootflow 'mmc@fe2b0000.bootdev.part_2' with distro
Fedora-KDE-aarch64-38-20230401 Boot Options
1:<---->ODROID-M1 fedora 50000005-01 verbose swiotlb=65535
2:<---->ODROID-M1 fedora 50000005-01 verbose swiotlb=65535
3:<---->ODROID-M1 fedora 50000005-01 verbose mem=4G
4:<---->ODROID-M1 fedora 50000005-01 previous verbose
5:<---->Fedora-KDE-aarch64-38-20230401
6:<---->NanoPC-T4 trial-01
7:<---->NanoPC-T4 trial-01 previous
8:<---->NanoPC-T4 trial-01 verbose
9:<---->Odroid-N2+ trial-01
10:<--->Odroid-N2+ trial-01 previous
11:<--->Odroid-N2+ SPI NOR trial-01
Enter choice: 1:<------>ODROID-M1 fedora 50000005-01 verbose swiotlb=65535
Retrieving file: /usr/lib/modules/linux/vmlinuz
append: loglevel=9 root=PARTUUID=50000005-01 cma=896M coherent_pool=2M selinux=0 audit=0 console=ttyS02,1500000 console=tty0 fbcon=nodefer rootwait rootfstype=ext4 raid=noautodetect swiotlb=65535
Retrieving file: /usr/lib/modules/linux/dtb/rockchip/rk3568-odroid-m1.dtb
   Uncompressing Kernel Image
Moving Image from 0x2080000 to 0x2200000, end=60f0000
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
2:<---->ODROID-M1 fedora 50000005-01 verbose swiotlb=65535
Retrieving file: /usr/lib/modules/linux/zImage
append: loglevel=9 root=PARTUUID=50000005-01 cma=896M coherent_pool=2M selinux=0 audit=0 console=ttyS02,1500000 console=tty0 fbcon=nodefer rootwait rootfstype=ext4 raid=noautodetect swiotlb=65535
Retrieving file: /usr/lib/modules/linux/dtb/rockchip/rk3568-odroid-m1.dtb
Moving Image from 0x2080000 to 0x2200000, end=60f0000
## Flattened Device Tree blob at 0a100000
   Booting using the fdt blob at 0xa100000
Working FDT set to a100000
Host not halted after 16000 microseconds.
Host not halted after 16000 microseconds.
   Loading Device Tree to 00000000eceb7000, end 00000000ecec89b3 ... OK
Working FDT set to eceb7000

Starting kernel ...

 

The u-boot control still has to be done with the serial console, as HDMI support is still missing, but it is still an early stage and the development is vivid.

 

In the meantime, I have solved the problem with loading compressed kernels for me. Also, I can now use a USB keyboard (usbkbd) for stdin. Both require a correction of the mainline code, but since unfortunately too many in-flight patches have not yet landed, it is still too early to go into detail here. If you already want to play with the functionality that will be provided by the mainline u-boot in the future out-of-the-box, I have uploaded my firmware build here. The firmware can be put in place by:

dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}

into the firmware area of an SD card or an eMMC. If it is started during power-up by holding the SPI recovery button (RCY), it will scan all connected storage media for a usable bootflow.

Supported boot methodes are: extlinux (extlinux.conf), efiboot and legacy-boot (boot.scr).
As soon as video support is available, "U-Boot Standard Boot" will be fully usable, but VOB2 support is still open.

Edited May 11, 2023 by usual user

[mhoffrogge]

@usual user

On 4/22/2023 at 2:04 PM, usual user said:

I have solved the problem with loading compressed kernels for me. Also, I can now use a USB keyboard (usbkbd) for stdin. Both require a correction of the mainline code,

I would be interested in those adaptions - can you provide those changes as a patch or is there a fork repo branch where those patches can be looked up?

[usual user]

6 hours ago, mhoffrogge said:

can you provide those changes

Since I haven't gotten any feedback on my build so far, I don't see much sense in it. In my experience, Armbian users tend to stick to legacy methods  and my extensions only affect the upcomming U-Boot Standard Boot. In addition, the adoption of reviewed-by patches from the patchwork to the mainline tree seems to have stalled. So it may take some time until the general support is available out-of-the-box. And these are valuable improvements to the Rockchip platform, which also benefit ODROID-M1 support.
Since Armbian already has a working boot method, I don't see any reason for an  underpaid Armbian developer to invest his valuable time in an unfinished solution that anyone can have for free when everything finally lands.
For me, it's different story because my preferred distro requires different prerequisites. I had made my build available so that others could save themselves the trouble of self-building, but there doesn't seem to be any particular interest.

[emk2203]

What are the recommended steps to get the M1 boot from eMMC with the current standard Armbian image?

Just skip spi boot, write image to eMMC as usual and boot without a µSD card?

 

@usual userI would very much like to test your build and would also give feedback after.

 

I have just discovered the M1 and I think it is necessary to have as many options as possible. There may be interest from others who, like me, are late to the game, but for this we would need to be able to replicate your build. From what you write, it sounds very promising so far.

 

It would also open the door for more variety in the distributions offered.

Edited August 9, 2023 by emk2203
additional topic

[usual user]

9 hours ago, emk2203 said:

late to the game, but for this we would need to be able to replicate your build.

With the release of U-Boot v2023.10, everyone will be able to create their own firmware on a stable basis.
The only difference to other firmware builds is a 

make odroid-m1-rk3568_defconfig

to setup a suitable configuration for the ODROID-M1.
If you want to build beforehand, you need to dig mailing lists and patchwork for non-landed fixes and improvements to pick them up.

 

9 hours ago, emk2203 said:

It would also open the door for more variety in the distributions offered.

As you can see here this has already happened. They use distributions that are not in any way designed specifically for the ODROID-M1 and where Petitboot is not able to support the bootflow used. And this is possible because the rk3568 SOC has sufficient mainline kernel support.

[emk2203]

Wow, thanks, these are great news! I wait until the 2023.10 release then. I cross my fingers, though -- in the ARM world, I have seen promising stuff delayed for ages or infinitely quite often.

[rpardini]

https://github.com/armbian/build/pull/5606

 

Testing image:

https://github.com/rpardini/armbian-release/releases/download/23.08.18-rpardini-434/Armbian_23.08.18-rpardini-434_Odroidm1_bookworm_edge_6.5.0-rc6.img.xz

 

#### `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works; bump kernel to 6.5-rcX

- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.4.y, update config, rebase patches to 6.4.10
- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.5-rc6; manually fix RK808 breakage in .config; externalize overlays; use Makefile autopatcher; rebase patches
- `odroidm1`/`edge` (`rk3568-odroid`): drop 6.3 and 6.4 patches
- `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works
  - using Kwiboo's `rk3568-2023.10` branch  with BINMAN-handled blobs
  - patches (defconfig unless indicated):
    - boot usb first (rockchip-common)
    - blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot
    - change usb_host0_xhci to otg (u-boot dtsi)
    - enable DM_GADGET, UMS 🔥 and RockUSB
  - **usage instructions**:
    - build & burn image to SD card
    - insert SD card into board
    - **hold the recovery (RCY) button** and power on the board
    - watch board boot
    - **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD
      - if you don't, you'll need to hold the recovery button every boot
      - optionally: use `armbian-install` to install OS to eMMC/NVMe/USB
    - power-off board
    - remove SD card (new u-boot always boots SD first!)
    - boot into your newly de-infested machine
      - boot order: USB, SD, MMC, NVME, SCSI
  - de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI:
    - Armbian UEFI-arm64
    - Fedora 38 aarch64
    - HASSOS for ODROID-M1
    - Talos arm64
    - others...
  - extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address
    - although it is based on cpuid#, doesn't match the HK sticker on the board
      - run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed
  - `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)

[emk2203]

@rpardiniThis testing image looks super promising. Basically everything from my wish list satisfied:

• stable MAC address
• boot from whatever is available via MTD/SPI
• sane boot order which allows for rescue interventions

Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison.

 

Going to test it out as soon as I can, but first I need to properly diagnose a Odroid HC4 HDMI bug for eventually RMA'ing the board.

[rpardini]

1 minute ago, emk2203 said:

Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison.

 

Definitely pick the PR and build whatever userspace you need, there's not much that is userspace dependent (maybe mesa, but I've not tested desktop usage). I've tested on Bookworm, Jammy and Lunar, all work great.

 

5 minutes ago, emk2203 said:

Basically everything from my wish list satisfied

 

Also: UMS mode works absolutely great. Use an SD + recovery button to deinfest, after that you can stop u-boot with the serial console and for example run "pci enum; nvme scan; ums 0 nvme 0" and be able to flash to NVMe via UMS (usb otg) without any SD or eMMC.

Also2: you can fix the MAC address stored in the u-boot env in SPI to match the board sticker if you want. Otherwise, MAC address is generated based on CPU serial number, which is stable, but does not match what's on the sticker. Dunno where HK stores the sticker value (maybe some fuse/OTP?)

 

[usual user]

On 8/19/2023 at 12:44 PM, rpardini said:

UMS mode works absolutely great.

UMS has not interested me much so far. However, the mention still inspired me to bring forward my rebase, which was planned after the v2023.10 GA release. Now my serial console boots up with a nice little boot menu:

  *** U-Boot Boot Menu ***

      Standard Boot
      NVME USB Mass Storage
      eMMC USB Mass Storage
      microSD USB Mass Storage
      usb 0:3
      nvme 0:1
      nvme 0:3
      nvme 0:4
      mmc 1:2
      U-Boot console


  Press UP/DOWN to move, ENTER to select, ESC to quit

Now I don't even need to physically insert the SD card back and forth between the card reader and the M1 when I want to perform a firmware update from my host build system, because the M1 can now act as a card reader itself. And that even for NVME, SATA and eMMC storage. I rarely need this because I usually run updates directly from the M1, but it's still nice to have.
However, this only becomes really interesting when HDMI video is also available and the EXPO menu can also be used.

I guess the day is approaching when I'll finally run this on the serial console:

run mmc-fw-to-sf

It will transfer my self-contained firmware image build into the SPI flash. I will then lose the possibility to use outdated legacy OS forks and can only use modern operating systems with current bootflows, but if I understand correctly, I have never used anything so unmaintained 😉 But the need to press the RCY button at system startup is starting to get annoying.