Jump to content

Odroid M1S Image Planned ?


Recommended Posts


I'd also like to see armbian running on my M1S.

It arrived today and honestly I ordered it in the hope to see it being supported one day.

Afaik none of the devs currently own an M1S yet, what makes development somewhat more difficult. So I would be happy to contribute by providing my M1S for tests.

So if anyone without an own M1S can provide an Armbian image with modified device tree and so on I will try to perform the desired tests.


Cheers and thank you!

Edited by Jojo
Link to comment
Share on other sites


during the last days there has been some work to add M1S support to Home Assistant. The user @darkxst has modified the device tree used by the mainline u-boot. So maybe this might be a good resource to benefit from?

This is the forum thread: https://community.home-assistant.io/t/add-support-for-odroid-m1s/648102

Here is the merged PR: https://github.com/home-assistant/operating-system/pull/3121



Link to comment
Share on other sites

Hey guys,


looks like the devs are heavily busy with other stuff. As we can read they are currently massively struggling with a lack of ... basically everything. So let's try to support them by helping ourselves and share it with the community :) .

I have not read anything anywhere about an approach to create an Armbian image for the M1S, so lets try to sum up, what we have and what is needed.

I am really not an expert in all that - really NOT! But I like to contribute as far as I can!


I've read somewhere that someone has tried to boot the M1 image on a M1S which kind of "worked" surprisingly, but failed in many ways like HDMI output and so on. This makes me think that the required modifications are mainly regarding entire hardware definitions - the device tree.

There is already an official Home Assistant image for the M1S where the most changes are also regarding the device tree (see link above).


So my idea for the next steps would be:

  1. take the M1 Armbian image as a starting point
  2. replace the Device tree be the one from Home Assistant and see if/how far it starts.


Does this approach make sense and has it chance to work?!


The problem I have: when I download the Home Assistant image and mount it locally I just can not find any DTB file. The same applies to the M1 Armbian image. Does anyone know where to find the DTB files right after downloading the images?


Let's bring this forward guys. We have a sound software base to start from and the omnipotent Armbian build system. If we get people onboard who know better about the bootloader/device tree stuff than me, we should be able to do it :) .





Edited by Jojo
Link to comment
Share on other sites

Just to demonstrate what such a concern would mean for the distribution of my choice:

The only thing in OS space that is really device-specific is the devicetree, which describes how the device is wired. For the linux kernel, it is only relevant that the corresponding drivers for the components listed in the devicetree are also built using the necessary options. Since the drivers for the rk3568 SoC are the same as for the rk3566 SoC (they are wired differently only through the devicetree), there is no need for any special action in this case.
So all I'm missing is a mainline binding compliant devicetree, and I'm done.
Now all that's missing is a firmware that can start the OS of choice. And this contains device-specific code that can't be copied from another device, and must be built specifically for this device.
Fortunately, everything necessary has already been posted on the U-Boot mailing list. The devicetree used still has shortcomings, but it is a start.
In order to verify the handling of different binary bloobs with my build system, I already build the firmware regularly. It's also included in my provided firmware uploads, but I haven't communicated it as I don't own an ODROID-M1S and therefore can't verify its functionality.
For me, the conlusion means:
- Install the firmware

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

- run the ODROID-M1S in UMS mode and tranfer my current image to a NVME
- Since there is no proper mainline devietree, I would use the one that falls off  during the firmware build and copy it in

cp /somewhere/rk3566-odroid-m1s.dtb /usr/lib/modules/linux/dtb/rockchip/rk3566-odroid-m1s.dtb

And I'm ready to rumble.
The same should be able to work with an Armbian ODROID-M1 image.

Edited by usual user
Correction of the DT filename, it is of course the DTB that needs to be copied.
Link to comment
Share on other sites

Yes, so basically my approach is not that wrong to overcome the differences between M1 Armbian image and M1S by using the correct device tree.


7 hours ago, usual user said:

Fortunately, everything necessary has already been posted on the U-Boot mailing list. The devicetree used still has shortcomings, but it is a start.

I dont know the shortcomings you talk about, but AFAIK the device tree used by Home Assistant is fine and works stable, see HERE.


I also got told that I would have to rebuild the u-boot for the M1S (basically what you also said by referring to the firmware to flash).


Is there anything I miss or that I just understand wrong?

How to build the firmware for the M1S?


Sorry for asking so many dumb questions. All this is just far beyond my knowledge and I have never built a firmware - only a kernel with a detailed description 😅. I try to understand what is missing and how we can pull things together without re-inventing the wheel.



Link to comment
Share on other sites

Alright, continuing talking to myself I think I will try to make a build for the OrangePi 3b, because this way I assume to get a mainline compatible u-boot for the RK3566 as well as a recent kernel/file system . Then I will replace the device tree with that one from the M1S.

Any concerns? Of course not...

I will drop myself a note here if this was successful...

Edited by Jojo
Link to comment
Share on other sites

12 hours ago, Jojo said:

What could be the next steps?

Since you have access to all the necessary components, grab an ODROID-M1 OS image of your choice, copy the components into it, and test.
If you install the OS image in the eMMC, be prepared to reinstall the original firmware. The ODROID-M1S does not have SPI flash and expects the firmware in the first instance in the eMMC. This means that the original firmware will be overwritten.
Alternatively, you can test with a microSD card, but you have to shortcircuit the MASK ROM pads each time at boot so that the firmware is loaded from there.
If you only transfer the firmware into the eMMC, you can also start the OS image of micrSD without MASK ROM intervention, this simplifies testing, because in  the OS image only the DTB has to be added and the OS image can be transferred to a microSD card more easily.

17 minutes ago, Jojo said:

I think I will try to make a build for the OrangePi 3b

Nothing has to be build in the first step by yourself, try testing the already availabe components.

Link to comment
Share on other sites

Hey guys,


I just wanted to mention, that I have not forgotten this topic :) .


I just have currently no time to drive this further because of real-life stuff going. Additionally I currently have no hardware in spare which i could perform the tests on. So either you guys wait for a non-specified time or try something on your own.


So long... Cheers

Link to comment
Share on other sites



I have not much time either, but I would like to see an Armbian release for the M1S. I have one M1S unit with me I could use for testing, but I will have to share it with other tasks. Maybe I could help accelerate the process somehow, I just don't know where to start. I have been using Linux on embedded systems for some years, but never went very deep.


I have tried the linuxfactory bookworm image and it works, even with the Vu8S 8" display which connects to the MIPI connector. It must be installed to the onboard eMMC.


Does someone want to guide me on this? Or maybe supply ready to flash images I could test?


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines