Hi Wolfgang,
On 15/12/12 11:32, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 50CBB346.30208@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