Dear Albert,
In message 20130731090644.2b4ce215@lilith you wrote:
On some boards, yes. For example, if they store the environment in an I2C attached EEPROM. Then you need I2C support early, before console, to read for example the baudrate setting.
Thanks, so some I2C reads are needed. Next question: on these boards, do these I2C reads require DT reads? Maybe a few hard-coded low level I2C reads are enough. I guess DT writes are completely unneeded at that point. Also, why exactly do I2C and, as the case may be, DT, need to write to .data?
A quick check shows that it's actually more than 50 boards that store the env in EEPROM (I'm surprised myself about this large number, given the disadvantages of such an approach), but AFAICT none of these needs to access the DT that early.
More generally, while I think the board_init_f() part of U-Boot should be as short and compact as possible, I understand and admit that it might have to read from just about any (local) storage resource, be it environment or DT or any stored information it needs.
Agreed - actually we're entering an area hear that smells pretty strong like device model reorganization ;-)
So, board_init_() should *strictly* be limited to setting up a console (for information purposes) and giving access to DDR while in the same time never writing to it itself. Bonus points if it can limit itself to *enabling* and postpone any *optimizing*(I am thinking of DDR settings here and no, I don't have specific existing cases in mind; just sayin').
Agreed!
Best regards,
Wolfgang Denk