Jump to content

Board Support Idea


Recommended Posts

A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering:  Could we put the board support patches into their own repo separate from the build scripts themselves?

 

More specifically:

 

  • board support for "Boards of Interest" to the Armbian maintainers would be in whatever "official" repos we dedicate, I recommend separating per board family or SoC
  • board support for CSC goes into, predictably, a CSC repo
  • board support for EOL boards can be spun off into their own repo
  • TV boxes go into a TV box repo

 

Advantages:

  • Supporting every pet project wont result in build system bloat as it does today.
  • Users of the script can maintain a csc board support repo with the required structure without hacking on the build script itself, making adding such a board to the "supported" repo much easier, if even necessary.
  • While I don't "tiptoe through the tulips" with CSC boards, I do go to some effort not to break them with changes.  Those boards won't be interacting with the others anymore, they'll have their own space.

 

Cons:

 

  • Perceived fragmentation of support.  In reality this is a good way to disengage the build script from pet projects and focus on the boards we as a team care about. 
  • Some work to implement (although I think the biggest part can be laced into the menu where you choose the board (CSC/WIP vs supported)

 

@lanefu, @Igor, Could we add an "RFC" tag?  would be useful, and consistent with linux terminology.

Link to comment
Share on other sites

2 minutes ago, TonyMac32 said:

A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering:  Could we put the board support patches into their own repo separate from the build scripts themselves?


I had similar though but not fragmenting to CSC/EOL/TVBOXES. Only moving patches section to the separate repository? Both "cons" goes away :)

Link to comment
Share on other sites

1 minute ago, Igor said:

I had similar though but not fragmenting to CSC/EOL/TVBOXES. Only moving patches section to the separate repository? Both "cons" goes away :)

 

I think this could also be handled in stages, patches first.  One of the things I see when we get a "variety show" going in a family is that the u-boot and family tweaking scripts go absolutely off the rails as far as complexity is concerned.

Link to comment
Share on other sites

1 minute ago, TonyMac32 said:

I think this could also be handled in stages, patches first. 


Finished this

and moved patches to separate repository.

 

4 minutes ago, TonyMac32 said:

One of the things I see when we get a "variety show" going in a family is that the u-boot and family tweaking scripts go absolutely off the rails as far as complexity is concerned.


Agree. This was designed to be able to handle rare exceptions which are sadly not that rare.

Link to comment
Share on other sites

10 minutes ago, Igor said:

sadly not that rare

 

Well, look at Amlogic, every single flavor of every SoC family has a different proprietary blob and different offsets for where it goes, it's a mess.

Link to comment
Share on other sites

Well im a big fan of git submodules in general...  it would be nice to be able to version the build and configs separately.    Build scripts could pull latest submodule by default, but would def need an option flag to leave things alone when desired.  Maybe even a param to specify a tag for config repo

 

A repo per soc would make it super lean, by only initializing a submodule on demand..... but thats probably uneeded complexity 🙄

Link to comment
Share on other sites

On 4/3/2019 at 6:44 AM, TonyMac32 said:
  • board support for CSC goes into, predictably, a CSC repo
  • board support for EOL boards can be spun off into their own repo

 

well.. problem if csc is out of the normal pipe.. if kernelpatches are needed.. they probably break with every update.. :s I know csc are csc for a reason.. but, explaining this again and again.. will be a pain.. I would be in favor of moving csc into a subfolder of the patching.. and have some sort of a bot.. once recognized that a csc patch doesn't apply properly, it gets automatic disabled (for sure.. complains will still come, but at least we would have something which is explainable, eos related patches could sit in the same subfolder), documented that those patches are not maintained anymore by the core project... 

 

 

Link to comment
Share on other sites

I think you misunderstood, I am proposing making each board family a self-contained unit, no patches exist at all in the build system itself, so the CSC stuff can do whatever it likes. The mechanism is to support users having their own boards without having to glue them into the other code.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

42 minutes ago, TonyMac32 said:

I think you misunderstood, I am proposing making each board family a self-contained unit,

Maybe.. :D

 

but if you separate patches in their own repo they still break from time to time.. and then? if csc patches are separate from official patches how to deal with it? the kernel will still be 'per boardfamily' means needed for csc as well to work properly.

Link to comment
Share on other sites

Maybe..
 
but if you separate patches in their own repo they still break from time to time.. and then? if csc patches are separate from official patches how to deal with it? the kernel will still be 'per boardfamily' means needed for csc as well to work properly.
The *C*ommunity will have to *S*upport.


Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

and the moderators have to explain again and again.. :D and again.. That's why csc patches should have a 'tag' (could be subfolder or csc_random_feature.patch) and a bot disables them automatically in case they break. first we would know soon which csc boards get community support and those who don't can be moved to eos, second as long as the patches apply properly they don't harm us (only if it's a 'bad' one which modifies stuff it shouldn't) so those boards get a decent support even when we don't invest much work into them. 

 

Otherwise I only see freeze kernel by default for csc as a sane option. constantly explaining our users that their csc board breaks cause we dropped their DTS and it messes around is kind of boring, including the 'armbian is not stable on my board blabla.. :D

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines