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

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Jan 17, 2018 at 12:31 AM, Jonathan Neuschäfer
<j.neuschaefer at gmx.net> wrote:
> Ok, back to the question of how to improve the standard and reduce
> ambiguity.
>
> On Tue, Jan 09, 2018 at 11:22:57PM +0100, Jonathan Neuschäfer 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.
>
> No need to change this, because it's correct.
>
>> The section "Requirements for UART"[2], however, states: "As this
>> problem is to be taken care of on the I/O Board[3] it is worth observing
>> that CPU Cards do not require UART buffering.", suggesting that the
>> "Start-up procedure" section simply left out UART as one of the
>> interfaces that do not need to be tri-stated by mistake.
>>
>> But I am unclear about the part "CPU Cards do not require UART buffering":
>> - Does it mean that CPU cards do not require the housing board to
>>   perform UART buffering, because they do it themselves?
>> - Or does it mean that CPU cards are not required to perform UART
>>   buffering?
>
> I suggest changing this passage:
>
>         "As this problem is to be taken care of on the I/O Board it is
>         worth observing that CPU Cards do not require UART buffering.
>         They may however require level shifting:"
>
> To this:
>
>         "As this problem is to be taken care of on the Housing Board it
>         is worth observing that CPU Cards don't need to perform UART
>         buffering. They may however need to perform level shifting:"
>
> ... or something like that.

 yehyeh, I/O Board was an older phrase.  i clarified that the level
shifting is to take place on the Housing.  also, i have set a
grammatical rule (important for a standard, for clarity) never to use
contractions "don't, they're, it's".

> Furthermore, it would be useful if the diagram below that had labels for
> the CPU Card and the Housing board (*).

 the level-shifting circuits are all solely and exclusively for
Housings.  it is absolutely imperative that all signals on the CPU
Card be relative to VREFTTL and that VREFTTL be generated by the SoC.
this is absolutely critical so as to ensure that the SoC is not
damaged by over-voltage.


> Older versions of the diagram
> show that the circuit on the left is part of the Housing and the box on
> the right is the CPU Card, but it's not instantaneously obvious in the
> current version.

 ok - someone else did those diagrams.  Housing is always on the left,
CPU Card is always on the right.  the use of the diodes is an
interesting one, it results in current-sinking and only works because
UART is "Open Drain" not CMOS.  it took a while to understand.


> What do you (LKCL) think about changing all instances of "I/O board" in
> the standard to "housing board", or perhaps "Housing Board", to reflect
> that Housing is defined in the terms section?

 yep it was an older term, changed about... 2-3 years ago.

> (Unfortunately this won't be as easy as "sed" and "git commit", because
> the EOMA68 standard isn't maintained in Git :/.)

 i knoooow, it was a decision a long time ago, to keep the standard on
an independent third party "open" site.  pain in the neck not having
it in git.  still, a good-old-fashioned cut/paste jobbie would do the
trick :)

l.