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@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