[Arm-netbook] Early UART output vs. housing board discovery

[Jonathan Neuschäfer]

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 at 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?