[U-Boot] [PATCH] ns16550: allow UART address to be set dynamically

[Graeme Russ]

Hi Wolfgang,

On 15/12/12 11:32, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <50CBB346.30208 at gmail.com> you wrote:
>>
>>> And we already have a well-defined way to do this, which is the device
>>> tree.  So any attempts to implement something different should be
>>> reviewed very carefully.
>>
>> I'm not sure I 100% get this, but from what I understand, the SoC (or maybe
>> even some EEPROM on a particular board family) may contain device
>> enumeration data in some vendor specific format (i.e. not in a device tree
>> compatible format).
> 
> Yes, this may, and will, happen.  And we will have to support it.  The
> question is, how to do that.  I definitely do not want to see any
> uncontrolled growth of more and more such board or SoC specific code.
> 
>> The way I see it, there is no way that U-Boot can dictate to SoC and board
>> vendors and say that data must be stored in DT format. So shouldn't U-Boot
> 
> We cannot dictate, but we can encourage and discourage such decisions.
> If we communicate a clear position, we may even prevent ugly things
> from happening.

Understood, but in the end, board and SoC vendors will do what is most
expedient for them, and that may well be a raw binary data format buried in
some reserved ROM area (either on-time-writable or EEPROM)

>> instead implement a board/SoC specific translation layer which converts
>> this custom data into DT format (maybe in SPL if possible)?
> 
> Do you want to see each board grow it's own code to do that?  Because
> this is the extreme that could result from such a decision, and I
> seriously dislike any such thought.  Which is why I'm questioning the
> general approach when I see it first.

Well if the SoC or board (but more likely SoC) has already defined the data
structure, you a bit stuck. I fully agree that board developers that choose
U-Boot as their primary bootloader should be following U-Boot conventions.

>> But the other problem is if this data includes console specific information
>> (UART configuration). We are left blind until the DT functions become
>> available. So maybe we need some small standard interface to allow the
>> console to be configured early. But we need to prevent this from being
>> abused (i.e. being used to do all kinds of hardware setting from the raw
>> data and bypassing DT)
> 
> Why do we have to support such dynamic hardware configuration for a
> very basic thing as the console port at all?

You may not find as much in consumer devices (set-top-boxes, mobile phones,
tablets etc.) but you will in industrial devices.

I can give you an example - Remote Telemetry Units (RTUs). They usually
have a number of serial ports. The number of ports may vary based on the
sub-model. Some ports may be RS-232, some may be RS-485 or RS-422.
Depending on what additional devices you want to communicate with, you may
need to use the 'console/diag' port to connect to a real device. So what
you want to do is route console to another port (if available) or even
netconsole.

> If the hardware designers cannot fix their minds and use a fixed
> console port, they should be willing to suffer fromthe penalty that
> they will have to use board specific board configurations that match
> the actual consoles settings.  Why should we bend and do ugly stuff?
> Just because software is so much easier to change than hardware?
> I'm not going to buy this argument.

I do get your point of view. But I think a combination of storing the
dynamic console info in a DT format, the pre-console buffer and getting DT
available as early as possible can yield a 'non-cludgy' solution. For board
or SoC vendors who, for whatever reason, have implemented non-DT storage of
hardware enumeration data they will be stuck with the penalty of having to
translate that data into DT format before it can be parsed by U-Boot. Maybe
this could be done in SPL. Yes, it's a hack, but if it can't be worked
around, push it as low as possible and as far away from the U-Boot core as
possible

Regards,

Graeme