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

Jonathan Neuschäfer j.neuschaefer at gmx.net
Tue Jan 9 22:22:57 GMT 2018


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

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?

So, can a CPU card assume that it may use the UART right after reset,
without first consulting the EEPROM?

(I understand that if a housing board has, for example, a Bluetooth
module connected to the UART, something must make sure that none of that
early debug output reaches the BT module, but I guess one could easily
enough have a GPIO pin that controls whether the UART is cut off from
the BT module, and the OS could toggle this pin once it knows that it
won't send debug output anymore. The same GPIO pin might also control if
the Bluetooth module is powered up at all.)

Best regards,
Jonathan Neuschäfer


[1]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Start-up_procedure
[2]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Requirements_for_UART
[3]: As a side-note, the term "I/O Board" is a little bit unclear to me:
     Both CPU cards/boards and housing boards perform I/O. I figured
     that "I/O board" means "housing board", but I (personally) think
     the spec would be clearer if it talked about "housings" or "housing
     boards" in the first place.


More information about the arm-netbook mailing list