I wanted to add some additional commands to the env for a new board. The barebox docs have this: The default environment is composed from different directories during compilation: defaultenv/.... ... arch/$ARCH/boards/<board>/env -> board specific overlay Which made me think that putting an "env" directory in the board directory would automatically add it to the environment. It seemed like a few boards I looked at did this and nothing more. But no, this does not work. I see two ways to add extra env. One is to reference a path in CONFIG_DEFAULT_ENVIRONMENT_PATH. The other is to add a path to bbenv-y in the board's Makefile and then defaultenv_append_directory() that linked in data in the board code. But it seems like some boards do neither! How do they work? AFAICT, the answer is they don't work. I tried to do an exhaustive survey of board envs. I found 98 env directories used by 95 boards. 57 of those boards use a manual defaultenv_append_directory(). There are 39 env directories not added this way (efika-mx-smartbook has two env dirs, one in the makefile and one not, thus 57 + 39 - 1 = 95). Of the 39 env dirs not added in board code, 27 are referenced in a defconfig file in CONFIG_DEFAULT_ENVIRONMENT_PATH. And thus 12 env dirs appear to have no use in barebox. delphi-poc20 appears to not even be a board, having just an env file, no code, no references I could, and added in a commit for another board. Mistake? The 12 boards with apparently unused envs: chumby_falconwing crystalfontz-cfa10036 datamodul-edm-qmx6 delphi-poc20 dss11 efika-mx-smartbook generic karo-tx25 karo-tx51 mx31moboard skov-imx6 technexion-wandboard An issue with CONFIG_DEFAULT_ENVIRONMENT_PATH is that it applies to all boards in a config. If multiple boards are built at once, e.g. imx_v7_defconfig, then there is no way for each board to have a different extra env this way. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Hi Trent, On Fri, May 14, 2021 at 11:46:38PM -0700, Trent Piepho wrote: > > The 12 boards with apparently unused envs: > chumby_falconwing > crystalfontz-cfa10036 > datamodul-edm-qmx6 > delphi-poc20 > dss11 > efika-mx-smartbook > generic > karo-tx25 > karo-tx51 > mx31moboard > skov-imx6 > technexion-wandboard > > An issue with CONFIG_DEFAULT_ENVIRONMENT_PATH is that it applies to > all boards in a config. If multiple boards are built at once, e.g. > imx_v7_defconfig, then there is no way for each board to have a > different extra env this way. Thanks for spotting this. It shows some points that could be cleaned up. Generally I suggest to remove the unused files. When they are unused nobody should miss them. For some boards we could think about removing them as well, like for example the i.MX boards that are still not converted to multiimage support. I just sent a series starting this, but that's just a start... Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
On Mon, May 17, 2021 at 12:38 AM Sascha Hauer <sha@pengutronix.de> wrote: > On Fri, May 14, 2021 at 11:46:38PM -0700, Trent Piepho wrote: > > > > An issue with CONFIG_DEFAULT_ENVIRONMENT_PATH is that it applies to > > all boards in a config. If multiple boards are built at once, e.g. > > imx_v7_defconfig, then there is no way for each board to have a > > different extra env this way. > > Thanks for spotting this. It shows some points that could be cleaned up. > Generally I suggest to remove the unused files. When they are unused > nobody should miss them. For some boards we could think about removing Maybe the documentation could be improved, as it appears to say that a board env dir will automatically included? I wonder if some boards, e.g. skov, thought this too and didnt' realize their env was unused. > them as well, like for example the i.MX boards that are still not > converted to multiimage support. If I understand correctly, with multimage support one puts the env directory in the board makefile and then board code will add it. Doesn't this mean that every env for a supported board will be in barebox? I was thinking there might be a way to avoid that and also avoid board specific code. Pass an env overlay, or overlays, in the u-boot dtb that the pbl provides. Do it like a FIT image... e.g: bbenv@0 { compatible = "barebox,environment-data"; barebox-bbenv-data = (raw data of the .bbenv goes here); }; The raw data is injected during build the same way a FIT image puts in the data for a kernel, dtb, initramfs, etc. into the FIT. This way the env is only in the board specific image with the board specific barebox dtb. And common code for barebox's dtb handler can trigger on the node and add it to the dtb instead of duplicating that in the board code. One could also pass additional env to a chained barebox, though I don't know what one would do with that exactly. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
On Mon, May 17, 2021 at 01:57:56PM -0700, Trent Piepho wrote: > On Mon, May 17, 2021 at 12:38 AM Sascha Hauer <sha@pengutronix.de> wrote: > > On Fri, May 14, 2021 at 11:46:38PM -0700, Trent Piepho wrote: > > > > > > An issue with CONFIG_DEFAULT_ENVIRONMENT_PATH is that it applies to > > > all boards in a config. If multiple boards are built at once, e.g. > > > imx_v7_defconfig, then there is no way for each board to have a > > > different extra env this way. > > > > Thanks for spotting this. It shows some points that could be cleaned up. > > Generally I suggest to remove the unused files. When they are unused > > nobody should miss them. For some boards we could think about removing > > Maybe the documentation could be improved, as it appears to say that a > board env dir will automatically included? I wonder if some boards, > e.g. skov, thought this too and didnt' realize their env was unused. Which part of the documentation are you referring to? > > > them as well, like for example the i.MX boards that are still not > > converted to multiimage support. > > If I understand correctly, with multimage support one puts the env > directory in the board makefile and then board code will add it. > Doesn't this mean that every env for a supported board will be in barebox? Yes, indeed. Not the whole environment though, only the files that are overwritten in the board specific environment. The remaining files are still only present once in the binary. This scales well for the few little text files we have, but of course isn't very size efficient once you have bigger files like splash screens in the environment. > > I was thinking there might be a way to avoid that and also avoid board > specific code. > > Pass an env overlay, or overlays, in the u-boot dtb that the pbl > provides. Do it like a FIT image... e.g: > bbenv@0 { > compatible = "barebox,environment-data"; > barebox-bbenv-data = (raw data of the .bbenv goes here); > }; > > The raw data is injected during build the same way a FIT image puts in > the data for a kernel, dtb, initramfs, etc. into the FIT. > > This way the env is only in the board specific image with the board > specific barebox dtb. And common code for barebox's dtb handler can > trigger on the node and add it to the dtb instead of duplicating that > in the board code. One could also pass additional env to a chained > barebox, though I don't know what one would do with that exactly. That sounds doable. We wouldn't even need an overlay, just a way to compile an environment raw image into a dtb. This might be tricky to implement though as we would need a dependency from the dtbs into the environment. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox