Odroid M1S Support

[darkxst]

I have an Odroid M1S sitting on my desk happily running HAOS the last couple of weeks. What are the thoughts about adding this board with official HAOS support, its a nice little board for the price.

Compared to the Odroid M1 only has minor differences:

• rk3566 SoC
• Drops the pcie3 interface
• No Spiflash boot chip, it instead installs Petitboot on the soldered eMMC. (this might be a pain as haven't managed to boot mainline uboot from sd card without nuking eMMC first.)
• Different TPL for ddr ram init.

If it wasnt for that last item it could completely share the M1 target and let u-boot handle the device tree and be done...

I could create this as a completely new board no problem, although it mostly will share the same configs as M1 I suspect.
Or perhaps modify the M1 target to build 2 images, just swapping out the binman SPL image u-boot-rockchip.bin for the M1S image.

Any thoughts on the preferred method? happy to prepare PR's for one or the other.

[andrewraj]

I'm waiting for an official HAOS support for this board. Any possibilities of booting from the nvme slot?

[darkxst]

Any possibilities of booting from the nvme slot?

Ive not tested the NVMe slot yet, but I dont expect there would be official support for booting HAOS from NVMe, but only the option to use NVMe as data disk.

It maybe be possible to install u-boot to the eMMC (or sd card) and then have that boot into NVMe, but that would be an exercise left for the adventurous hacker.

[darkxst]

I tested NVMe now, u-boot can detect the SSD ok, so should be possible to boot off NVMe. However u-boot need to be installed on the eMMC.

[nspierbundel]

Hi, can you show the steps you have taken to install haos on the m1s,
are you running from sdcard or from internal emmc ?

[darkxst]

You can find my WIP branch here:
https://github.com/darkxst/ha-operating-system/tree/odroid-m1s

Some test images are building now, you will find them under artifacts when complete:
https://github.com/darkxst/ha-operating-system/actions/runs/7495600927

1. First you need to wipe Petitboot from the eMMC, at the moment you need to do this via UART console:
   dd if=/dev/zero of=/dev/mmcblk0 bs=512 seek=64 count=6080
2. After that you can boot per normal from SD card
3. Finally you can dd the HAOS image to eMMC if you want to run from there.

NB: There will be no upgrade path from these test images, you will need to reinstall once official images are available.

[Wyren]

I'm guessing I'll have to do the same if I want to be stubborn and try the green release first right?

[darkxst]

I'm guessing I'll have to do the same

As far as I can tell, Petitboot can't boot anything using mainline u-boot. so unless your using hardkernel images, you need to wipe petitboot.

try the green release first right

Why would you do that? It has the wrong device tree. U-boot will probably load ok, but the kernel is unlikely to boot fully, and if it somehow loads without panic, it will likely have all sorts of issues with peripherals (aka anything connected to the SoC). You can save yourself the pain by using the images I posted above!

[Wyren]

Haha, thanks. Like I said, stubborn. Also I'm sure that remark shows my grasp of situation. So I'm basically clueless here trying to get a grip on things. But I really appreciate your feedback and the grunt work you already did. I'll stick to your advice. 😇

[nspierbundel]

Nice thanks for sharing.

Can I when booting in usb mode (from sdcard) flash these images direct to eMMC or is petit boot protected in usb mode?
Also I see u use the tobetter kernel , does this already include his vu8s patch ?
https://forum.odroid.com/viewtopic.php?f=214&t=47894

any Idea what needs to be done to get this board in the official supported boards?

[darkxst]

Can I when booting in usb mode (from sdcard) flash these images direct to eMMC or is petit boot protected in usb mode?

You can flash the eMMC from any booted ubuntu system, however once you wipe petitboot and install HAOS there will be no support from USB/NVMe boot as these were provided by Petitboot (unless you restore the eMMC with the hardkernel installers)

Also I see u use the tobetter kernel , does this already include his vu8s patch ?

I only included the device tree ( adapted with some changes for mainline kernel). I haven't included any of the overlays, the vu8s overlays are fairly recent and weren't there when I prepared this initially, I could include them, but not sure how much use it is with HAOS which only has a debug console on the display. Also it disables HDMI which most people would likely to try first!

any Idea what needs to be done to get this board in the official supported boards?

That was the original reason for this post! Not had any official response yet though!

[nspierbundel]

Time to do a clean git clone. And try again.

[nspierbundel]

git clone https://github.com/darkxst/ha-operating-system/

Cloning into 'ha-operating-system'...
remote: Enumerating objects: 67782, done.
remote: Counting objects: 100% (3319/3319), done.
remote: Compressing objects: 100% (356/356), done.
remote: Total 67782 (delta 3062), reused 3142 (delta 2954), pack-reused 64463
Receiving objects: 100% (67782/67782), 36.80 MiB | 7.98 MiB/s, done.
Resolving deltas: 100% (32884/32884), done.
me@build:$ cd
.cache/ .config/ ha-operating-system/ .ssh/
me@build:$ cd ha-operating-system/
me@build:~/ha-operating-system$ git checkout odroid-m1s

branch 'odroid-m1s' set up to track 'origin/odroid-m1s'.
Switched to a new branch 'odroid-m1s'

me@build:~/ha-operating-system$ git submodule update --init

Submodule 'buildroot' (https://github.com/darkxst/ha-buildroot.git) registered for path 'buildroot'
Cloning into '/home/me/ha-operating-system/buildroot'...
Submodule path 'buildroot': checked out 'b6fb8b011328ecc9f15f88f58b6c94567408363f'

me@build:~/ha-operating-system$ sudo scripts/enter.sh make O=output_m1s odroid_m1s

lots of compile stuff going on

Executing post-image script /build/buildroot-external/scripts/post-image.sh
368+0 records in
368+0 records out
188416 bytes (188 kB, 184 KiB) copied, 0.000652491 s, 289 MB/s
2104+0 records in
2104+0 records out
1077248 bytes (1.1 MB, 1.0 MiB) copied, 0.00239418 s, 450 MB/s
mkfs.fat 4.2 (2021-01-31)
mkfs.fat: Warning: lowercase labels might not work properly on some systems
Copying boot.scr
Copying cmdline.txt
Copying haos-config.txt
Copying rk3566-odroid-m1s.dtb
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 98304 1k blocks and 24576 inodes
Filesystem UUID: c76593ca-7242-4b27-ab8f-b645e2b0b9f7
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on /build/output_m1s/images/kernel.img, block size 131072.
[========================================================================================-] 223/223 100%

Exportable Squashfs 4.0 filesystem, lzo compressed, data block size 131072
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 12538.72 Kbytes (12.24 Mbytes)
44.10% of uncompressed filesystem size (28435.61 Kbytes)
Inode table size 809 bytes (0.79 Kbytes)
82.38% of uncompressed inode table size (982 bytes)
Directory table size 22 bytes (0.02 Kbytes)
81.48% of uncompressed directory table size (27 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 0
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of hard-links 0
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
Creating new GPT entries in memory.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

No problems found. 180157 free sectors (88.0 MiB) available in 2
segments, the largest of which is 145375 (71.0 MiB) in size.
32768+0 records in
32768+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.0233083 s, 720 MB/s
25080+0 records in
25080+0 records out
12840960 bytes (13 MB, 12 MiB) copied, 0.0136445 s, 941 MB/s
363528+0 records in
363528+0 records out
186126336 bytes (186 MB, 178 MiB) copied, 0.205919 s, 904 MB/s
196608+0 records in
196608+0 records out
100663296 bytes (101 MB, 96 MiB) copied, 0.0615594 s, 1.6 GB/s
2621440+0 records in
2621440+0 records out
1342177280 bytes (1.3 GB, 1.2 GiB) copied, 1.69538 s, 792 MB/s
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
1+0 records in
1+0 records out
512 bytes copied, 0.00034272 s, 1.5 MB/s
32704+0 records in
32704+0 records out
16744448 bytes (17 MB, 16 MiB) copied, 0.0319994 s, 523 MB/s
rauc-Message: 20:54:29.628: Debug log domains: 'rauc'
rauc-Message: 20:54:29.629: Failed to resolve realpath for '/dev/mapper/ubuntu--vg-ubuntu--lv'
(rauc:1460696): rauc-DEBUG: 20:54:29.629: bundle start
(rauc:1460696): rauc-DEBUG: 20:54:29.629: input directory: /build/output_m1s/images/rauc
(rauc:1460696): rauc-DEBUG: 20:54:29.629: output bundle: /build/output_m1s/images/haos_odroid-m1s-11.3.rc1.raucb
(rauc:1460696): rauc-DEBUG: 20:54:31.599: Payload size: 170446848 bytes.
Creating bundle in 'plain' format

(rauc:1460696): rauc-WARNING **: 20:54:31.850: Detected CRL but CRL checking is disabled!
rauc-Message: 20:54:31.850: Keyring given, doing signature verification
rauc-Message: 20:54:32.113: Verified detached signature by 'O = HassOS, CN = HassOS Self-signed Development Certificate'
(rauc:1460696): rauc-DEBUG: 20:54:32.114: Got 1 elements for trust chain
(rauc:1460696): rauc-DEBUG: 20:54:32.117: Signature offset: 170446848 bytes.
(rauc:1460696): rauc-DEBUG: 20:54:32.117: Bundle size: 170449065 bytes.
make[1]: Leaving directory '/build/buildroot'

Do not clean when building for one target

finished odroid_m1s

starting from scratch did the trick
tommorow I will search my uart cable and try to flash the system. (better to have uart before messing stuff up)

thanks

[nspierbundel]

I could not find my uart cable (Yet) , however I did manage to flash the created file.
using https://dn.odroid.com/RK3566/ODROID-M1S/Installer/ODROID-M1S_EMMC2UMS.img flashed to a sdcard using balena etcher.
step 0 create the sd card per odroids`s instructions.

steps to flash the haos_odroid-1ms...xz file from the images folder located in output

1. boot the odroid m1s from the sdcard created in step 0 using regular power supply. this will create a new usb device on windows.
2. connect the odroid using a usb cable to a (windows) pc
3. use balena etcher to flash the .xz file to the usb device.
4. after flashing is completed shutdown m1s by disconnecting power
5. remove the sdcard
6. power on odroid m1s
7. wait and wait and wait the first boot can take more than 5 minutes. some bootlines can be vissible on the hdmi display
8. login using a webbrowser to your new home assistant.

no need for uart, or dd

[nspierbundel]

if the usb method is not working check https://forum.odroid.com/viewtopic.php?f=216&t=47655
by shorting 2 pins and using the sdcard usb boot the device will get forced in usb mode

[darkxst]

I had not tried the USB tool, but yes that would work well. Ultimately will probably make a installer image using Hardkenerl uboot to flash HAOS to emmc.

by shorting 2 pins and using the sdcard usb boot the device will get forced in usb mode

If you go to the extent of shorting the 2 maskrom pins, you can boot directly into HAOS image as well.

[nspierbundel]

I see there is a new update for kernel 6.6
What would be the apropriate way to add the dts file for the vu8s to the build?
I could add it to the /ha-operating-system/output_m1s/build/linux-6.6.11/arch/arm64/boot/dts$ cd rockchip/ folder and modify the Makefile to include, however this does not seem the right way to me.
I think it should be a patch file in ha-operating-system/buildroot-external/board/hardkernel/odroid-m1s/patches/linux/
just need some directions ;-)

[darkxst]

I see there is a new update for kernel 6.6

yes, I am testing this alongside the 6.6 update for HAOS to come eventually.

What would be the apropriate way to add the dts file for the vu8s to the build?

I think it should be a patch file in ha-operating-system/buildroot-external/board/hardkernel/odroid-m1s/patches/linux/
just need some directions ;-)

You would do the following

1. clone the linux tree from linux-stable repo then
   git check <v6.6tag>
2. import existing patches
   git am ../ha-operating-system/buildroot-external/board/hardkernel/odroid-m1s/patches/linux/*
3. Cherrypick required patches from tobetter's 6.1 repo
4. export all patches
   git format-patch -N -o ../linux-patchset <v6.6tag>

Then you can copy the patch files back into haos build tree

Finally you would just need to activate the overlay via /mnt/boot

All that said I will probably merge these patches in the coming days sometime...

[darkxst]

have you tried below method to get the board in the official repo ?

yes I am well aware of how to create a PR, thanks.

[darkxst]

I see there is a new update for kernel 6.6

My 6.6 branch includes the Vu8s overlay now, not tested yet though.

Should be disabled by default, enable via /mnt/boot/haos-config.txt

[nspierbundel]

Hi,
the display is somewhat working now. nice work.

however the screen is divided in 2 sections .
text start in the middle of the screen and when it exits the screen on the right side it re-enters from the left..

any idea ?

thanks for all your hard work

[darkxst]

maybe I missed some patch when cherry-picking things.

[agners]

Sorry, I mean to respond here already last week, and somehow I keep forgetting. 🙈

I could create this as a completely new board no problem, although it mostly will share the same configs as M1 I suspect. Or perhaps modify the M1 target to build 2 images, just swapping out the binman SPL image u-boot-rockchip.bin for the M1S image.

Any thoughts on the preferred method? happy to prepare PR's for one or the other.

From what Hardkernel told me these two boards use different memory timings. From what I know, there is no way to create boot code which automatically selects the right memory timing. Consequentially, this means we need to have two images 😢

As soon as we need a separate image, I'd say it should have it's own board id on OS level (odroid-m1s I guess). However, on the higher stack I'd say we don't need to duplicate things unnecessarily, so we can just reuse the existing odroid-m1 board.

[darkxst]

From what Hardkernel told me these two boards use different memory timings. From what I know, there is no way to create boot code which automatically selects the right memory timing. Consequentially, this means we need to have two images 😢

Yeh I would agree with that, BROM jumps straight into the Rockchip TPL (ddr.bin) image. So seems no opportunity to select these images at boot.

As soon as we need a separate image, I'd say it should have it's own board id on OS level (odroid-m1s I guess). However, on the higher stack I'd say we don't need to duplicate things unnecessarily, so we can just reuse the existing odroid-m1 board.

OK, I will create PR for this, essentially that is what my current test builds are doing 😄

[darkxst]

Odroid M1S support has now been merged into the development branch.