Hello Albert,
Am 31.07.2013 09:06, schrieb Albert ARIBAUD:
Hi Wolfgang,
On Wed, 31 Jul 2013 07:18:21 +0200, Wolfgang Denk<w...@denx.de> wrote:
Dear Albert ARIBAUD,
In message<20130731000921.724f5c71@lilith> you wrote:
board_init_f() is supposed to initialize just enough of the system to
allow relocation. Is initializing i2c necessary in this context?
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
If I understand the tegra driver, dt reads are needed for init
the i2c driver ... but this should be done in the i2c driver
init function ... and this should be possible without writes
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?
I2c do not write before relocation (I hope so), see:
drivers/i2c/i2c_core.c
All writes to internal i2c structs are (should be) protected by a:
if (gd->flags & GD_FLG_RELOC) {
but using i2c write/reads are possible.
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.
On the other hand, it may be hard to immediately know what functions
throughout U-boot are safe to call from within board_init_f(); maybe we
should start thinking about checking and marking these, the simplest
way being to suffix them with "_f" once we have made sure they are safe
to call from within board_init_f().
Hmmm... Maybe instead we should think (also in thinking common bring
up for all boards) about:
getting rid of board_init_f in u-boot code, instead use for all
boards spl code to init needed things and copy and relocate u-boot
to ram in spl code ... so we have in u-boot no longer such
restictions ... but thats just an idea which whirs in my head ...
without thinking to deep in it.
But this approach would have some advantages ...
But we should strictly limit the scope of board_init_f() or we'll find
the board_init_f()/board_init_r() pair following a patch similar to the
SPL/U-Boot pair, where SPL started out as a tiny helper piece of code
and ending up a resizeable (and, I dare to say, sizeable as well) kind
of U-boot. If we let too many features slip in board_init_f(), it'll
blur into a board_init_r() like and before we know it, it'll *require*
DDR, and write access to it too...
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').
In the present instance, I'd rather we either:
- removed dependency on DT etc. by using "hard-coded" low level I2C
reads for those boards that need it (I assume that for each of these
boards the I2C slave, offset, and length to read are constant) in _f
phase, or
But DT is used for initializing the i2c driver in tegra ...
- parsed the _f phase looking for offending functions or calls which
write to .data or .bss and fix them, suffixing them with _f; in
essence, that amounts to starting the implementation of my suggestion
above alongside fixing the issue at hand.
The first approach is rather "let's bring the thing back up first", so
it does not have my preference, but I would understand the need to
quickly fix things.
Yes.
The second approach seems to be going in the same direction as Heiko's
proposal of 07:52 +0200, which I thus second provided it is applicable
to all the boards Wolfgang had in mind.
Lets do us this step as fixup ;-)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
