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

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