On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote:
On Wed, Jan 10, 2018 at 1:44 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote:
[...]
Thus it would be rather useful to have the UART available as an early debugging facility after production, and in a standardized way.
yes, absolutely.... and there is absolutely nothing stopping the "User" from, in effect, upgrading themselves mentally to the status of "Technical EndUser" - at which point there are completely different rules / state-diagram.
so they would be perfectly and absolutely within their rights to take the Card out, plug it into a.... testing station of some kind (even if that's just a breakout board), plug in a MicroSD card with "UART debug enabled" and off they go.
Although I don't like this solution (what if the on-card firmware wants to print debug logs?), I have to acknowledge that it is a solution. (I would prefer that early debug output is available without (even temporarily) rendering a CPU card non-compliant.)
A Technical Enduser could of course open a card, find the right test points for RX/TX, solder wires to them, run them out of the case, and close the case again, but this procedure is highly card-specific, and probably not always possible, e.g. when the RX/TX lines are routed in a way that makes soldering hard.
no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else.
... and enable early debug mode through unspecified means, right?
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
This is AFAICS not a big problem under my suggested change.
For reference, this is my suggested change: - CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted. - When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM. For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc. - If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2] - I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up.
This is a debug facility. Not all CPU cards have to use it, but all housings must accept it.
Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors.
"Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation.
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
Required by which part? (Or: Required by the standard on behalf of which part?)
- Housings shouldn't require to see any debug messages from CPU cards, that's just silly. Boot debug output is necessarily CPU card specific, so it is not generally useful for any *software* on the housing board. It is only useful for humans[1]. - Housings are, under my suggested change, however required to tolerate early UART output. How this is done is up to the housing designer. For example, if the UART TX pin is connected to an activity LED, the designer might even choose to ignore the flickering during early boot. :-)
I listed some hard(er) to understand phrases in my initial mail:
i know... let's not forget about them but deal with things one at a time, if that's ok. i know from experience, from past discussions, that ANY clarification requires a HUGE amount of effort and discussion, with an exchange that can carry on for several days.
Alright.
i trust that you can appreciate that it would overwhelm both me and you and everyone on this list to have three ongoing *simultaneous* separate and distinct highly-technical logical reasoning discussions, yeh?
Yes.
Thanks, Jonathan Neuschäfer
[1]: ... or CPU card specific housings, which, as far as I understand the standard should be avoided as much as reasonably possible. [2]: I realize this increases the housing BOM by a few components. How large is the price impact?