1 1
TonyMac32

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

Share this post


Link to post
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 :)

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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 🙄

Share this post


Link to post
Share on other sites
8 hours ago, TonyMac32 said:

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

wow i'm struggling to figure out how to add it 

Share this post


Link to post
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.

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