Dear Wofgang Denk,
Well, there are IMO two fundamental questions:
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
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