Dear Stephen Warren,
In message 4F6A01D3.3020506@wwwdotorg.org you wrote:
It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works).
...
I'd prefer to just have a different U-Boot (build) config for each HW configuration, and define the console UART as part of that configuration using the existing defines that are for that purpose.
This is another option - at the cost of maintaining separate binary images.
If we put the UART ID into the environment, then we either need to:
a) Have a different U-Boot configuration anyway, in order to define the different environment during the U-Boot build process.
b) Post-process the U-Boot binary after building it, in order to modify the environment that's contained in that binary.
Not true. In the normal course of events, the board would boot with a working device tree provided, which provides correct console information. This could be used to auto-initialize the correct environment settings. You just have to make sure that board boots a single time with a working DT image - I don't know how production tests and/or software commissioning on these boards is organized, but this seems to be a possible route to me. [Been there, done that before. About 12 years before, IIRC.] You probably also need to program MAC addresses etc. ?
Best regards,
Wolfgang Denk