Dear Simon,
In message 90014ca9-64d8-8e38-a6c0-4c06e991c92c@gmail.com you wrote:
However, this approach creates several difficulties:
As usual, "difficulties" are made for solving.
I mean, none of these are technically challenging in any way.
- Distros like Debian cannot provide a devel package for SWUpdate like u-boot-dev, since U-Boot has its default environment code compiled board-dependently and Debian needed it board-independent.
Thta's fine.
If a board-independent libubootenv.a was provided without a specific default environment, the first update process would destroy the U-Boot environment if it had had bad CRC before. (Thanks Stefano for this good point).
One possible way to fix this is not to use a compiled in default environment for the fw_env tools (or only use this as a very last resort), but instead provide a configuration option to read the default settings from a file. In this case the user could provide his own, board specific default environment.
- If we have a board with U-Boot already preinstalled and want to compile SWUpdate for it, we need the sources of this very U-Boot to get the propper lib. For example in a debian-like build system we had to compile U-Boot again, although it is already installed since we lack a dev package.
- Why does building the U-Boot package not also create these libraries, either directly or as a separate package? - What prevents the creation of such a dev package that only builds the needed lib?
- U-Boot does not provide any default means to install a development library. Thus anything we modify on-top might break with the next version.
Why don't you add this, then? Patches are welcome!
Has there been any progress in the SWupdate/fw_setenv integration? I thought I remember reading something about letting fw_setenv extract the environment from the U-Boot binary in the target, but I cannot find the thread. I do think the current situation should be improved, making fw_setenv independent of the target that is built.
To be honest, I think this is not a clever approach. This whole concept of the compiled in default environment is antediluvian. It comes from a time where we were booting from parallel NOR flasah (or other boot ROM where you directly started executing code) and where we wanted to make sure that we can read the console baud rate very, very soon. Today, many boards don't have environment access in the SPL, and nobody complains that these run with a fixed baud rate only.
Did anybody ever ask who actually _needs_ this compiled in default environment? We could provide other, more efficient configurations if we drop a few of the old requirements (which are not met by many recent boards anyway).
And as this thread is on the swupdate group as well: I would prefer calling an external fw_setenv tool instead of linking in the static library libubootenv.a...
IMO this is just a matter of taste. Both ways should be possible.
Best regards,
Wolfgang Denk