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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
