Hi Wolfgang, On 15/12/12 11:32, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <50cbb346.30...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot