--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jan 17, 2018 at 12:31 AM, Jonathan Neuschäfer j.neuschaefer@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.