Jump to content

Recommended Posts

Posted (edited)
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 by Jojo
Posted

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

 

Posted (edited)
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:

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 by Jojo
Posted
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.

Posted
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

Posted
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

Posted

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!

Posted

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. :P
I would suggest you check dmesg for a clue after running armbian-config.

 

Best regards,
Sérgio

Posted
On 10/29/2025 at 9:55 AM, Jojo said:

If there are still other M1S users around: Hi!

Hey, I am really happy there is someone else with M1S - just got it today in the mail and after first boot received notification that ubuntu 20.04 server is no longer supported (shocker!).

It would be nice to be able to run later kernel (you've mentioned 6.12) on the machine.

I was not able to follow your steps to get it working, unfortunately.

I don't care for desktop performance at all.

Would it be possible to get the image of ubuntu noble server? Or is there some place with idiot-proof step-by-step guide for noobs?

 

Thanks in advance!

Posted (edited)
17 hours ago, SanchoSK said:

Hey, I am really happy there is someone else with M1S - just got it today in the mail and after first boot received notification that ubuntu 20.04 server is no longer supported (shocker!).

It would be nice to be able to run later kernel (you've mentioned 6.12) on the machine.

I was not able to follow your steps to get it working, unfortunately.

I don't care for desktop performance at all.

Would it be possible to get the image of ubuntu noble server? Or is there some place with idiot-proof step-by-step guide for noobs?

 

Thanks in advance!

Currently Noble Server is not planned.

I have the impression, that generally speaking Debian is the way to go for server stuff while Ubuntu is more targeting Desktop systems (at least Armbian). Of course there might be cases where both are provided.

All my small servers here at home run Debian-based systems. Never had any issues or disadvantages compared to Ubuntu...

If you read through this thread, you'll see what is needed to build it on your own:

- clone the Armbian repo

- get the correct dts file and place it in the correct folder

- get the correct csc file and place it in the correct folder

- run the compile script and choose M1S from the list

 

The files and where to place them can be found in the corresponding PR on github.

If you don't get it running on your own just wait/hope a little bit for the board to be officially (community-)supported by Armbian.

Or I share the pre-compiled image with you (on your own risk).

 

Greetings

Edited by Jojo
Posted (edited)

@Jojo Would you be so kind and lend me a hand here?

What I did:

  • clone the repo locally
  • manually changed the files in your PR (csc, dts and modified the .config)
  • run ./compile.sh

The problem is - it does not offer the M1S board in the list of targets.

I must be missing a step or two. Would you mind checking my steps and advise, please?

 

Never mind - all I needed to do is to click the middle option in the compile menu (Show CSC/WIP/EOS/TVB) :)

Edited by SanchoSK
Posted

I just wanted to thank @Jojo for the hints and guidance - it works, my Armbian was directly installed onto my eMMC and booted right away, all seems to be working fine, I can move forward with my project. Really appreciated!

Posted
1 hour ago, SanchoSK said:

I just wanted to thank @Jojo for the hints and guidance - it works, my Armbian was directly installed onto my eMMC and booted right away, all seems to be working fine, I can move forward with my project. Really appreciated!

Good to hear that it worked for you 👍.

The PR on Github seems to be on a good way, so "official" support might be there soon... :)

Posted
On 10/24/2025 at 9:18 AM, Jojo said:

initially I had the M1S connected to the Aux input of my AV receiver. There seems to be a problem with display detection (EDID, available modes) and so the M1S does not know which display mode to set.

In the meantime I got HDMI also working through my AVR. I just changed the cable and that did the trick...

One thing to mention: the system seems to be allergic to hot-plugging the HDMI cable. So if I connect/reconnect the cable during runtime, the HDMI output will be gone. It requires a reboot WITH CABLE CONNECTED.

Not a big issue from my pov, but important to know...

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.

Guest
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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines