Hi Jason
Sorry for answering you as the last though you were the first one replying to my e-mail, but I wanted to answer in order of the length of my reply. And yours was the longest 
Quoting Jason Kridner <jkridner@beagleboard.org>:
Quoting Jason Kridner <jkridner@beagleboard.org>:
I'd like to add a check at address 0x51 for an expansion
board that provides connections to existing expansion boards. Pins
requested by the EEPROM at 0x51 would override requests for pins from
the expansion board specified by the EEPROM at 0x50.
Something like that would remove all plug and play capabilites because you'd
have to program an eeprom with your current hardware setup (and therefore
you are able to place erroneous setups by accident). That would be a great
step back in my opinion.
Why would it break plug-and-play capabilities? Existing expansion
boards would use the 0x50 EEPROM--so nothing would change there. New
expansion boards that don't pass the expansion pins (termination
boards) to a new connector would similarly stick to 0x50. Only new
boards that utilize a few pins and then pass on connections to other
expansion boards (intermediate boards) would use this new 0x51 (or
perhaps 0x57) address.
[...]
The EEPROMs would come programmed by the hardware vendor, just as they do today.
Ok, I think I misunderstood. I thought you were propagating to put a "Board Stack descriptor" on address 0x51. But obviously that was not your proposal.
If I got you right this time, you are simply propagating the idea of another board identification address for boards not using the whole interface you call "intermediate board".
Well maybe I overlooked something else or did not get the whole picture, but wouldn't this approach lead to two new limitations? In fact you can only have ONE board with Adress 0x51 and ONE with Address 0x50. Everything else leads to collisions. So the result is a maximum of two boards stacked up and this is only possible if you have .
[...] This proposal would fix that
and enable boards that could work in combination to work.
As I said above: If I got this right, the only way to combine boards is combining "Termination"-Boards with intermediate boards. I think that's too short-sighted, sorry.
I think the main problem we face in the existing solution is, that there is
no chance to either daisychain devices nor allocating adresses dynamically
on I2C in an easy way. Maybe that point should be adressed somehow?
Intermediate boards would always use the new address. I doubt we want
to go many additional layers deep as signal integrity gets to be an
issue. The ability to go another level deep is part of why I was
suggesting 0x51 rather than 0x57. If we decide, we could just scan
from 0x57 down to 0x50 in the software to see what is connected to the
expansion bus.
And here is your problem: who decides if a board responds to 0x57, 0x51 or any other 0x5X address?
The vendor? With my luck I'll get the need for stacking two boards with the same address. 
The user? Ok, we could do jumpering and expect the user to do the jumpering right. Maybe that's an option.
Dynamically setting the EEPROM address based on topology sounds
intriguing, but I suspect that we'll have wanted to build boards that
were designed to attach to expansion boards "down stream" for anything
to ever work.
Unfortunately I don't see possibility either. In fact you could only do this if you daisychain something through the connectors. As daisychaining I2C would lead to the need of placing an I2C I2C master on each intermediate board, I think that's not a good option.
What we could do is passing the adressing through an extra 4-pin header connector (something similar to the McBSP header on the xM) to the next one, placing some incrementer circuty in between e.g. based on a 74 283 4-bit adder or something ... but I'm not sure if it's worth the effort.
Do you think we need to deal with the possibility of boards that are
configured to be stacked as many as you might like, ie. true daisy
chaining of the boards?
I think keep it simple is a good approach. And I think if it's possible to avoid limitations created by a *too simple* solution with little extra brainwork, we should do that.
Too many systems I've seen have limitations just because someone could not imagine a reason at designtime why one should do something that goes over the limits just created. The result was always that one stumbled over these limitations sooner or later. This might work for software where you can patch almost everything everytime. But in my opinion it never works for interfaces in hardware.
Using EEPROMs,
I think we'll also be practically limited to 8 EEPROMs very quickly
due to addressing. If a board is designed to be daisy chained, is it
reasonable to request it be build with jumpers to specify the address
from 0 to 7? Is that enough? Is it at all practical to think of any
chain longer than that on this very limited bus?
I think you are asking the right questions. Unfornutately I have no answers
But I think if we now make a step away from "single expansion board" towards "multiple expansion boards" we should at least do further than only a one to two transition and open the space currently available. In my opinion it is legal to say: We are able to address 8 boards right now. If we want to expand, we have either to find a device with another präamble than 0x50 or have to redesign the bus.
What about building an expansion board that works as an "Expansionboard
multiplexer"? [...]
That would add a lot of cost onto that board.
I see the point "extra cost" but why "a lot"?
If you are doing this,
you can deal with the software complexity as part of that board and in
higher levels of software, rather than putting it back on this simple
u-boot infrastructure.
You'll have to deal with more than u-boot infrastructure anyway see the post of Hunyue Yau. He even claims that drivers should be able to do pinmux settings. So the u-boot approach is ok for immediatly needed pinmux but in my opinion it's the wrong place for system setup. It should do what it's designed to do: Providing an environment for the kernel to live in. The kernel should provide an environment for the drivers to live in and the drivers... ah I think you know what I mean: I don't want to change the lowest level piece of software just because there is a new expansion board I'd like to use. In my opinion there is no need to do that.
We'll eventually need to train u-boot to build up device tree
entries.
Why u-boot? I don't understand what u-boot can do better here than the OS?
It would have been nice to put more intelligence into the
EEPROM contents, but I expect we'll be able to codify in u-boot the
boards that are specified up to the time we can specify something more
complete to producing device tree entries.
Which always leads to the need of changing the _bootloader_ if you plug another board in or you buy another board and want to use it. I don't think that's practical. It would be better to have some higher level drivers.
I have an idea to simplify the whole pinmux stuff, but I did not have the
time yet to write it down. My thoughts go towards expanding the board info
available in the eeprom by a several informations about pinmux requests from
the expansion board. [...]
Please include device tree in your considerations.
I don't understand the relevance of the device tree. Even if the expansion boards are not hot-pluggable, they are still pluggable. So why don't just use sort of plug and play mechanism at OS level? I'd apreciate if you could explain me more here...
regards
Ueli