On Tue, 2023-02-14 at 10:46 +0100, Enrico Jörns wrote: > Hi Richard, > > Am Freitag, dem 03.02.2023 um 14:17 +0000 schrieb Richard Purdie: > > On Fri, 2023-02-03 at 14:50 +0100, Marco Felsch wrote: > > > This adds the support for the barebox bootloader to oe-core. The recipe > > > is based on the recipe found in meta-ptx [1] with a few minor adaptions. > > > > > > This basic support includes the bootloader and the target tools to > > > interact with the bootloader. The host tools support is not part of > > > this commit. This will be added later on as separate recipe. > > > > > > [1] https://github.com/pengutronix/meta-ptx/tree/master/recipes-bsp/barebox > > > > > > Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > > > --- > > > meta/conf/documentation.conf | 7 + > > > meta/recipes-bsp/barebox/barebox.inc | 123 ++++++++++++++++++ > > > meta/recipes-bsp/barebox/barebox_2023.01.0.bb | 5 + > > > ...IMAGE_COMPRESSION-per-default-to-lz4.patch | 40 ++++++ > > > 4 files changed, 175 insertions(+) > > > create mode 100644 meta/recipes-bsp/barebox/barebox.inc > > > create mode 100644 meta/recipes-bsp/barebox/barebox_2023.01.0.bb > > > create mode 100644 meta/recipes-bsp/barebox/files/0001-pbl-set-IMAGE_COMPRESSION-per-default- > > > to-lz4.patch > > > > In order to add something to OE-Core, we need to see it being used by a > > reasonable portion of the ecosystem. Is there enough usage of barebox > > on common boards that justifies this? > > I understand that not each and every package can and should be added to OE-core, so let me provide > my view on why adding barebox could be reasonable. > > First of all, since it is a bootloader and oe-core's purpose is to provide basic common recipes > required to bring up a device, I found it to be a proper location for the recipe. > It does not add any further dependencies in the oe-core ecosystem so additional maintenance should > be limited in scope. > > With over 300 individual contributors and regular monthly releases [1] I would call the barebox > bootloader a common, stable and mature project that is around since ~2009 and provides support for a > wide range of architectures, SoCs and platforms [2] including freely available common boards like > RPI, beaglebone, i.MX eval kits and UEFI in general. > > Ever since, barebox has also been used by different hardware vendors (e.g. [4]) and was chosen by > Kalray [5] as their bootloader. Of course, as you know, it is always difficult to have a reliable > overview of the user base of an open source project as barebox. > > So far there are already a number of barebox oe recipes around [3] that I find worth to consolidate > with adding one reference recipe to oe-core. > > The question if these are sufficient arguments for adding barebox to oe-core probably needs to be > answered by the broader community, but I found it to be a good added value to have a bootloader in > oe-core that adapts many of the well-known schemes of Linux and focuses on being developer-friendly > and framework-driven. > (Let me just drop [6] for those interested in a bit details on what I summed up very roughly here.) Fair enough, I'm open to the idea. It would be interesting/useful to see if anyone else in the community is in favour of this or not. I'm sure you appreciate why we need to ask the question and why we can't just add everything! :) The community usage does appear to be primarily phytec/ptx. > > I noticed there is no maintainers entry being added so this will throw > > QA errors on the autobuilder. > > I would take responsibility for the recipe, backed by other barebox developers here. Ok, that helps. What about testing? I'm a bit worried that in adding this, we'd be adding something which doesn't really get tested by the autobuilder and is hence in an unknown state to us... > > Also, I'm not sure adding doc varflags for individual recipe variables > > to documentation.conf makes sense. We should probably have them in the > > recipe or just put entries into the manual? > > To be honest, this was inspired by the UBOOT_ variables that are placed in documentation.conf thus > we assumed this could be a proper place. We can simply move them into the recipe to limit intrusion > into the rest of the oe ecosystem. There are multiple u-boot pieces so there is a slightly different case there but even then, I think we should likely be rethinking global variables like that which are so specific. Sadly global content isn't something which comes for free in bitbake. I'm not keen to add to the problem if we don't need to. Cheers, Richard
