Odroid M1S Image Planned ?

[Werner]

Did you check already merged PRs which were adding new boards? Like https://github.com/armbian/build/pull/8754/files

Should give some clues.

[Jojo]

6 hours ago, Werner said:

Did you check already merged PRs which were adding new boards? Like https://github.com/armbian/build/pull/8754/files

Should give some clues.

Thank you for your reply!

No, I did not check THIS SPECIFIC PR. But of course the other ones, for example those @Igor already pointed to.

And because of the fact, that I already checked several PR and still being not sure how to do it correctly, I hoped for a more general explanation than just another link to another PR...

 

I wished for some explanations about good practice and how/why things are done the way they are done.

"Path xyz is the place for your .csc files. Path abc for your .dts files because of blablabla..." That would just have been nice to get a better overview.

Beside all the respect and appreciation that I have for you and your colleagues at Armbian, please understand that it is sometimes somewhat exhausting when guys like me try their very best to contribute and then often get calmed by link-drops...

 

Anyway, I'll check out your referred PR and see if that helps.

 

Edited Monday at 05:33 PM by Jojo

[Werner]

We're aware that our documentation isn't great (also about adding new hw: https://docs.armbian.com/Process_Contribute/#adding-a-new-board) but it is hard to find time for such tasks when we're crowded with other stuff already.

 

Quote

To me it seems that this requires not "normal" .config files, but ".csc" files.

The file extension defines a boards support status. https://docs.armbian.com/User-Guide_Board-Support-Rules/

Anyone can add .csc boards.

 

For dts files we have dedicated folders to avoid having a patch necessary for them:

https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.12/dt

https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.18/dt

 

[Jojo]

2 hours ago, Werner said:

We're aware that our documentation isn't great (also about adding new hw: https://docs.armbian.com/Process_Contribute/#adding-a-new-board) but it is hard to find time for such tasks when we're crowded with other stuff already.

Understood, all good.

 

2 hours ago, Werner said:

For dts files we have dedicated folders to avoid having a patch necessary for them:

https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.12/dt

https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.18/dt

That is a good example for something that is not that clear.

I tried to find a ready-to-use dts file for the M1S in the mainline repo, but it is not one single dts file, but a composition of several files where one file refers to the next one and so on (here). I was confused and so I asked ChatGPT how to merge the mainline dts into Armbian. This was how my patches were created.

After compilation there was indeed one single all-in-one dts file for my board but not before...

EDIT: I just tried another build with just taking the top-level dts file from the mainline repo and placing it in the location you mentioned. Worked like a charm, despite my confusion... 😅

 

From my point of view it seemed better to have the patches in place to be sure to always pull the most recent DT from the mainline kernel (that of course would require a defined place to put those patches).

But what you say sounds as if it would be preferable to have dts files instead of patches. Is that correct and why?

Edited Monday at 08:29 PM by Jojo

[Jojo]

On 10/25/2025 at 7:32 AM, usual user said:

Use WebGL Report to be sure.

WebGL1 and WebGL2 is reported to be working. But the performance is horrible...

 

[Werner]

8 hours ago, Jojo said:

But what you say sounds as if it would be preferable to have dts files instead of patches. Is that correct and why?

Yes. In the past everything was added as patch. The problem was (and still is for other reasons) that some patches modifying a dt build on top of each other or stuff breaks. Now the dt can be edited directly and using git blame it is documented who edited what for whatever reason.

Of course sometimes there is an almost perfect dt upstream that needs minor adjustments. Those can be perfectly fine done with a patch.

Also both patches and our dt files only stay for as long as there is no proper equivalent upstream. Once everything is in mainline they are no longer needed.

[Jojo]

3 hours ago, Werner said:

Yes. In the past everything was added as patch. The problem was (and still is for other reasons) that some patches modifying a dt build on top of each other or stuff breaks. Now the dt can be edited directly and using git blame it is documented who edited what for whatever reason.

Of course sometimes there is an almost perfect dt upstream that needs minor adjustments. Those can be perfectly fine done with a patch.

Also both patches and our dt files only stay for as long as there is no proper equivalent upstream. Once everything is in mainline they are no longer needed.

Okay, thanks for the explanation!

 

So, I got Armbian compiled and running by just adding the .dts file and the .csc file. The .csc file is a copy of the ODROID M1 .config file, but with some modifications: I threw out the SPI-related stuff, because the M1S does not have a SPI flash to boot from and it gave me arrors during compilation.

I tested basic functionality with a Ubuntu Noble Cinnamon desktop image as well as a headless server image.

Is this enough to create a pull request? How is the Download page created? Is that made by the Armbian team or do I need to add it there as well (how?) ?

 

Greetings

[Werner]

4 hours ago, Jojo said:

Is this enough to create a pull request?

Yes

 

4 hours ago, Jojo said:

How is the Download page created? Is that made by the Armbian team or do I need to add it there as well (how?) ?

That's on us

[Jojo]

Tested another Armbian, this time Noble with Gnome desktop.

Although I personally do not like that UI, It performs relatively good. As @Werner predicted, glmark2-es2-wayland finished with a score of 277.

WebGL Aquarium demo works significantly better. While 500 fishes still result in very low FPS, 100 fishes is mostly fluent.

 

What I observed on all systems I have tested on the M1S, armbian-config takes extremely long to load/open. Sometimes around 5 minutes or so. It would be interesting to know, if this is expected to be normal...

 

Now that I have tested four different images (Bookworm server, Noble Server, Noble Cinnamon and Noble Gnome), all with "current" kernel (6.12), I feel okay to do the PR.

 

As said, I did not do that much but only adding the .csc file and the .dts file. This gave me the feeling on the other hand, that your build framework is working really great and makes it "relatively easy" to contribute and test own things, as seen as one knows how the things play together. So apart from all my "complains", your build framework is great!👍

 

If there are still other M1S users around: Hi!

[Sérgio Gaspar]

Hi! I am around...

Thank you for all the work you have been doing on the M1S.
Unfortunately I haven't had the opportunity to test recently, but I expect to.

As for the low performance, I really had the feeling that the M1S is slow on graphics, but decent (for its class) on regular CPU work. I had tested with linuxfactory's bookwork image and that was the feeling I got from then.

 

I don't think the long wait time for armbian-config to open is normal. My first bet would be something related to network access, either there is not a working internet access or some configuration is wrong.  My second bet, some sort of reading error on the microSD card. The M1S isn't that sloooow. 
I would suggest you check dmesg for a clue after running armbian-config.

 

Best regards,
Sérgio