On Tue, Sep 22, 2009 at 08:57:33PM +0200, Wolfgang Denk wrote:
I'm biased. I understand that you do this because you need it for the next patch, which reads the environment from MMC card. But then MMC is just one out of many storage devices, and with the same right we would have to move the SCSI or DoC or S-ATA initialization up, because we could implement storing the environment on such devices, too.
This has not been done so far, because it suffers from the fundamental problem your code is suffering from, too: you cannot access the environment early enough, so for example your board boots with a hard-wird, unchangable console baud rate, despite that you suggest to the user he could change it.
I don't like that, and therefore tend to NAK the whole approach.
The same applies to NAND. The CONFIG_NAND_ENV_DST mechanism makes it a bit better (the first stage loader puts the environment in a designated part of RAM); perhaps something similar could be done here?
There's still a problem with doing any console output during the first stage loading itself (such as to indicate failures). For that, the best I can think of would be to have a CONFIG option for a hardcoded baud, and if you leave it undefined you will get no output until the second stage.
-Scott