[U-Boot] [PATCH v1 1/3] Make mmc init come before env_relocate

[Konrad Mattheis]

Dear Wofgang Denk,

> Well, there are IMO two fundamental questions:
> 
> 1) Where do we store the environment?
> 
>    Even if you load the U-Boot binary from - say - MMC/SDCard, there
>    is most probably also another storage medium available on your
>    board which may be easier to use (i. e. available before
>    relocation to RAM) and thus more appropriate to use.
>  
>    Also, not storing the environment on changable media has the
>    affect that it will allow for persistent settings even when you
>    change the mdium you boot from. This may or may not be an
>    advantage, depending on your requirements. My guess is that it
>    would be an advantage in most applications.

I understand the advantages for storing the settings on the board,
but I thing this problem is already perfectly solved. So for that
type of applications there is nothing to do.
But for the other type I'm searching for a good way. Some reasons
this way is also important:
	1. If I have two same hardware boards I just have to change
	   the storage card and the new hardware work in the same way
	   (this is very important for warranty or support problems)
      2. At mass production I don't need to program /flash something

> 2) How do we implement this?
> 
>    Assuming you load the U-Boot binary from - say - MMC/SDCard, you
>    must already have some code running that can do this. Then why
>    should that very same code not be able to load the envrionment from
>    the same MMC/SDCard as well? In the worst case you could make it
>    one big blob that gets loaded in one go.
> 
>    Why do you think we need U-Boot's MMC/SDCard drivers to perform the
>    initial load of the environment from the external storage?
> 
> 
> Thus I suggest two approaches to solve the problem, which both have
> their specific features and advantages, and probably should be not
> considered as alternatives, but used in combination, at least
> optionally.

For the implementation I have now this Idea:

The environment variables can be attached to the uboot-binary. This could be
in the begin or end of the file and both have some advantages and disadvantages,
but this we could discuss later.
At boot time the u-boot has the possibility to get this environment variables
without any driver, because there are in flash or copied into the ram.
So the u-boot just have to look at position if it find these variables
and then will use them.
If you want to change these variables you have two possibilities.
1. do it in u-boot, u-boot load the driver for the storage and then can write on
2. do in later high level linux/win (there it could be good to deliver an easy c code
   for the users)

With this solution you also solve the problem with Scott Wood solution,
because you already have the right env. variables at the start time.
So no problem with serial,...

Best regards,

Konrad Mattheis