Dear Wolfgang,
Regarding your recommendations about U-Boot usage, I completely agree with
that. In fact, In my description, I wouldn't give too many details, but
your answer leads me to add some :-)
As I told you, this "old" u-boot is used only as primary bootloader, and
its main objective is jus
Dear Nicolas,
In message
you wrote:
>
> > Would that really be enough? Please keep in mind that "env save" (or
> > "saveenv") is only responsible for storing the current environment
> > into persistant storage. It does not modify the environment at all.
> > To modify the environment, you can
Would that really be enough? Please keep in mind that "env save" (or
"saveenv") is only responsible for storing the current environment
into persistant storage. It does not modify the environment at all.
To modify the environment, you can use quite a number of commands,
including "env set", "env
Dear Nicolas,
In message
you wrote:
>
> Of course, the user will be able to modify the content of the script, to
> fit with their needs. But on our side, provider of this primary bootloader,
> we want to be sure that the environment of this u-boot won't be changed by
> the user, so that we want
Hi
Let me firstly explain my need. We use U-boot as a primary bootloader, with
a bootcmd which loads and executes a script on one external device (SD ou
USB). This script will continue the boot process (launch a kernel for
example). The corresponding bootcmd defined in CONFIG_BOOTCOMMAND does this
5 matches
Mail list logo
