In message <200602202347.k1KNlWPn021308@guild.plethora.net>, Peter Seebach writ
es:
>Oh!  So, just hack together an i2c_tag_t suitable for passing to
>seeprom_bootstrap_read, given various assumptions I can make on this hardware?
>
>I think what threw me off about this is that the instances I found of this
>elsewhere (e.g., armadillo) appeared to feel it necessary to write whole new
>functions whose addresses could be stuffed into the i2c_tag_t.

Actually, it's not looking as hopeful as it once did.

See, the i2c controller, so far as I can tell, doesn't start out mapped in.
It gets mapped during the attach of the bus it's attached to, and at least
some mapping happens during its own attach.

Thus, my "simple" bootstrap code ends up needing AT LEAST to fully map the
device, and this in turn requires information which simply may not exist that
early in the boot.

Worse, since it's an error to remap the same space, I have to undo the maps
when I'm done so the attach won't be violating the bus_space_map API.  But
it may not matter; I'm not even entirely sure that the addresses in question
are guaranteed to be constants, so it might be that attempting to hardcode
them for the bootstrap run will just doom me to failure.  Worse, it's not
even clear to me that it's possible to do it right; I'm ending up with a raft
of code and constants and trying to imitate a whole lot of code from several
layers of device probing.

It may be that the "right" option is to try to lie to RedBoot and make it
think this is a Linux kernel, then snoop on the registers it would populate
for Linux...

-s