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

[Jonathan Neuschäfer]

Hi,

On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote:
> On Tue, Jan 9, 2018 at 10:22 PM, Jonathan Neuschäfer
> <j.neuschaefer at gmx.net> wrote:
> > Hi,
> >
> > what follows are a few questions/remarks/misunderstandings regarding the
> > UART pins during early boot.
> >
> > In the EOMA68 specification, the section "Start-up procedure"[1]
> > specifies that "It is required that all pins be disabled (floating
> > tri-state) with the exception of the I2C Bus, the 5.0v Power and the
> > Ground Pins.", which would mean that *any software* running on a CPU
> > card is required to check the housing board's EEPROM before it may
> > output any data on the UART, if I read it correctly.
> 
>  yyup.
> 
> > This would make early debugging harder, because EEPROM detection has to
> > be integrated in very early code, and early code can't simply use the
> > UART as an unconditional debug channel, that's guaranteed to reach the
> > outside of the card, anymore.
> 
>  ok there's a difference between production and factory / testing.
> factory / testing is specifically permitted to do whatever they like,
> totally disregarding the EOMA68 standard IN FULL, should they choose
> to.
> 
>  it is only PRODUCTION where the EOMA68 Specification is REQUIRED -
> unconditionally - to be followed.

I can certainly see cases where a Technical Enduser, as the spec calls
them, wants to modify or replace low-level software on an already
produced card, and perform "testing":

- A card only ships with the SoC vendor's fork of Linux, but the user
  wants to run/port mainline Linux.
- The user wants to change something about the bootloader.
- The card only runs Linux, but the user wants to port BSD.

Thus it would be rather useful to have the UART available as an early
debugging facility after production, and in a standardized way.

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.

In short: Thank you for the clarification. Now I disagree with this
decision in the spec. :-/

(BTW, just to be very clear about the word "early": I mean early in the
card's "run"-cycle (from power-up to power-down), not early in the the
card's life-cycle (from production to destruction).)

>  could i leave it with you to alter the rest of what you wrote to take
> that into account before we proceed further?  also, before proceeding,
> perhaps we should discuss how to make the above absolutely clear.  it
> is very important that there be zero misunderstandings in the EOMA68
> Standard.

I listed some hard(er) to understand phrases in my initial mail:
- "CPU Cards do not require UART buffering"
- "I/O Board" vs. something more obviously unambiguous

I suggest continuing the discussion about clarification of the current
intention of the spec in reply to that mail.


Thanks,
Jonathan Neuschäfer