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-... [2]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Requir... [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.
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.
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.
thanks johnathon.
l.
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
On Wed, Jan 10, 2018 at 1:44 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote:
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.
yes, absolutely.... and there is absolutely nothing stopping the "User" from, in effect, upgrading themselves mentally to the status of "Technical EndUser" - at which point there are completely different rules / state-diagram.
so they would be perfectly and absolutely within their rights to take the Card out, plug it into a.... testing station of some kind (even if that's just a breakout board), plug in a MicroSD card with "UART debug enabled" and off they go.
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.
no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else.
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
(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).)
yep understood.
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:
i know... let's not forget about them but deal with things one at a time, if that's ok. i know from experience, from past discussions, that ANY clarification requires a HUGE amount of effort and discussion, with an exchange that can carry on for several days.
i trust that you can appreciate that it would overwhelm both me and you and everyone on this list to have three ongoing *simultaneous* separate and distinct highly-technical logical reasoning discussions, yeh?
l.
On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote:
On Wed, Jan 10, 2018 at 1:44 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote:
[...]
Thus it would be rather useful to have the UART available as an early debugging facility after production, and in a standardized way.
yes, absolutely.... and there is absolutely nothing stopping the "User" from, in effect, upgrading themselves mentally to the status of "Technical EndUser" - at which point there are completely different rules / state-diagram.
so they would be perfectly and absolutely within their rights to take the Card out, plug it into a.... testing station of some kind (even if that's just a breakout board), plug in a MicroSD card with "UART debug enabled" and off they go.
Although I don't like this solution (what if the on-card firmware wants to print debug logs?), I have to acknowledge that it is a solution. (I would prefer that early debug output is available without (even temporarily) rendering a CPU card non-compliant.)
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.
no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else.
... and enable early debug mode through unspecified means, right?
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
This is AFAICS not a big problem under my suggested change.
For reference, this is my suggested change: - CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted. - When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM. For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc. - If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2] - I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up.
This is a debug facility. Not all CPU cards have to use it, but all housings must accept it.
Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors.
"Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation.
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
Required by which part? (Or: Required by the standard on behalf of which part?)
- Housings shouldn't require to see any debug messages from CPU cards, that's just silly. Boot debug output is necessarily CPU card specific, so it is not generally useful for any *software* on the housing board. It is only useful for humans[1]. - Housings are, under my suggested change, however required to tolerate early UART output. How this is done is up to the housing designer. For example, if the UART TX pin is connected to an activity LED, the designer might even choose to ignore the flickering during early boot. :-)
I listed some hard(er) to understand phrases in my initial mail:
i know... let's not forget about them but deal with things one at a time, if that's ok. i know from experience, from past discussions, that ANY clarification requires a HUGE amount of effort and discussion, with an exchange that can carry on for several days.
Alright.
i trust that you can appreciate that it would overwhelm both me and you and everyone on this list to have three ongoing *simultaneous* separate and distinct highly-technical logical reasoning discussions, yeh?
Yes.
Thanks, Jonathan Neuschäfer
[1]: ... or CPU card specific housings, which, as far as I understand the standard should be avoided as much as reasonably possible. [2]: I realize this increases the housing BOM by a few components. How large is the price impact?
On Wed, Jan 10, 2018 at 4:11 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote:
so they would be perfectly and absolutely within their rights to take the Card out, plug it into a.... testing station of some kind (even if that's just a breakout board), plug in a MicroSD card with "UART debug enabled" and off they go.
Although I don't like this solution (what if the on-card firmware wants to print debug logs?), I have to acknowledge that it is a solution. (I would prefer that early debug output is available without (even temporarily) rendering a CPU card non-compliant.)
another solution is: the designer of the Card ensures that, through the user-facing connectors of the Card, that early debug messages may be accessed through one of the peripherals. in the case of the EOMA68-A20 Card, that is possible with the insertion of a "MicroSD Breakout Board", whereupon both JTAG and UART0 are accessible if you boot with the correct pinmux settings.
this, again, does NOT require that the UART wires of EOMA68 be placed into a state that results in total confusion over their use and purpose... more on this below.
no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else.
... and enable early debug mode through unspecified means, right?
no, it's very clearly specified that there *is* no limit or restriction. which is totally different from leaving things "unspecified".
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
This is AFAICS not a big problem under my suggested change.
For reference, this is my suggested change:
- CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted.
ok so that implies that the UART lines MAY be UART... they MIGHT also be GPIO. please bear in mind: anything that involves "confusion" is AUTOMATICALLY prohibited from being included in the EOMA68 Standard. i appreciate that in this case you describe a procedure that would remove doubt, but the procedure itself is very burdensome to implement.
there is a story i told about the X25 Standard which illustrates how these kinds of choices result in lost opportunities and/or total confusion and thus destroy confidence in a standard.
- When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM.
ok so the boot process you propose is:
* bring up the CPU (DDR3, PLLs) * initialise EEPROM GPIO pins and configure them as I2C * read an I2C EEPROM * decode it * work out if it's SAFE to write to UART * THEN write debug / print messages on the UART pins
... can you see how that's not "early" at all?
For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc.
- If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2]
this is _way_ too complicated, and also not clear.
- I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up.
this is even more complicated... and also unnecessary when the person doing the debugging may either:
* in-situ use multiplexing of user-facing connectors (A20 MicroSD / UART-JTAG capability) * take the Card out of the Housing and test it in a home-made or laboratory-owned test Housing.
This is a debug facility. Not all CPU cards have to use it, but all housings must accept it.
that places a huge technical burden and complexity on Housing Designers *and* Card Designers, where no such complexity or burdensome requirements exist at the moment.
Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors.
the purpose of requiring the "non-optionality" is to ensure that there is absolutely no way that a future Card or future Housing will be incompatible with an older Card or an older Housing, no matter how much faster the peripherals on either the Card(s) or the Housing(s) have become.
SD/MMC itself is a perfect example, as not only is the speed auto-negotiated based on how many physical wires "happen to connect" - 1 2 or 4 - but there is also *automatic* host-to-card negotiation of speed capabilities *built into the protocol*. likewise SATA and USB, and also the ADSL / SDSL broadband protocol, and also PCIe. all of these protocols do "negotiation", right down to the VERY slowest, oldest possible equipment that could possibly be plugged in.
all of these protocols are incredibly simple as far as EOMA68 is concerned: they "take care of themselves". UART, SPI, I2C, RGB/TTL and the three degenerate cases GPIO, PWM and EINT on the other hand, cannot "self-negotiate". that's what the I2C EEPROM is for: to describe and specify those functions totally unambiguously so that the Card is GUARANTEED - as long as it follows the EOMA68 specification - NOT to do any damage to itself or to the Housing.
the other consideration i have is that the standard has to be simple, and implementation of Housings and Cards has to be very straightforward. what you are proposing has two possible alternatives (actually a third is as you suggested: open up the Card's case and start re-wiring things and hand-soldering on extra components or connections) where all of the alternatives achieve exactly the same thing.... *without *requiring that the EOMA68 Standard have additional complexity added to it.
"Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation.
exactly. and that's precisely why additional complexity should *not* be added to the negotiation phase.
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
Required by which part?
sorry, the use of the word "part" is not clear. part of the standard? part of the Card? part of the Housing? part of the proposed modification to the standard?
anyway, that was written when i believed that you were proposing that Cards are forced to transmit early boot messages over UART.
- Housings shouldn't require to see any debug messages from CPU cards, that's just silly
the point is: if the wires are to be forced to transmit early debug messages, then in ABSOLUTELY NO WAY can they also be allowed to change over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their use as UART could conceivably cause damage to either the CPU or to the Housing components.
and if there is a current fight between a GPIO that is tied permanently to VREFTTL on the Housing and the forced requirement to transmit UART early debug messages tries to pull it high, we have a serious problem.
i appreciate that you have come up with a solution to this, involving a complex process of ascertaining via the EEPROM whether the pins are GPIO or UART, but it is complexity where *none* exists at the moment, and there are two easy alternatives that place absolutely no burden whatsoever on the Technical EndUser.
i trust that you can appreciate that it would overwhelm both me and you and everyone on this list to have three ongoing *simultaneous* separate and distinct highly-technical logical reasoning discussions, yeh?
Yes.
cool, whew :) this _is_ really important, to make absolutely sure that the standard will be useful and useable for at least the next decade.
thanks johnathon.
l.
Hi,
Please excuse the verbosity of some parts of this email, where I tried to be extra clear.
On Wed, Jan 10, 2018 at 07:22:16PM +0000, Luke Kenneth Casson Leighton wrote:
On Wed, Jan 10, 2018 at 4:11 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote:
[...]
no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else.
... and enable early debug mode through unspecified means, right?
no, it's very clearly specified that there *is* no limit or restriction. which is totally different from leaving things "unspecified".
The EOMA68 spec doesn't specify how to enable early debug mode, that's what I meant.
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
This is AFAICS not a big problem under my suggested change.
For reference, this is my suggested change:
- CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted.
ok so that implies that the UART lines MAY be UART... they MIGHT also be GPIO. please bear in mind: anything that involves "confusion" is AUTOMATICALLY prohibited from being included in the EOMA68 Standard.
Confusion for which group of people?
USERS: Early debug output is a feature that probably shouldn't be documented for Retail Endusers anyway: They can't be expected to find it useful. Technical Endusers however can probably navigate the confusion, and understand the feature if it's documented well enough.
CARD DESIGNERS: I don't think card hardware designs need to change.
HOUSING DESIGNERS: Yes, this puts the burden to tolerate UART mode during early boot on housing designers.
OPERATING SYSTEM DEVELOPERS: Yes, OSes may need to do a little more in order to use the full feature set of a housing.
BOOTLOADER DEVELOPERS: AFAICS, they need to care less about EOMA68 then before, because they can now just print all the debug output they want, without looking at the EEPROM.
i appreciate that in this case you describe a procedure that would remove doubt, but the procedure itself is very burdensome to implement.
there is a story i told about the X25 Standard which illustrates how these kinds of choices result in lost opportunities and/or total confusion and thus destroy confidence in a standard.
- When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM.
ok so the boot process you propose is:
- bring up the CPU (DDR3, PLLs)
- initialise EEPROM GPIO pins and configure them as I2C
- read an I2C EEPROM
- decode it
- work out if it's SAFE to write to UART
- THEN write debug / print messages on the UART pins
... can you see how that's not "early" at all?
No, what I'm trying to propose (and think through) is different:
* Reset the SoC and bring the pins of the EOMA68 connector into the state that's mandated at reset (most pins tri-stated, etc.) * Bring some of the SoC (configure clock trees, maybe the DRAM, too) * Initialize the UART and start using it, because it is safe to use in early boot * Continue bringing up things and printing debug messages * Perhaps already load the OS kernel * Configure the I2C controller and read the EEPROM * Stop doing early debug output, and start using the UART pins in the way that's mandated by the EEPROM
I can see two points where problems might occur: * If software fails to disable early debug output in the UART (this shouldn't too hard to solve in Linux, though). * If the CPU card spontaneously resets without first bringing the housing into a state where it tolerates early debug output (some housings might require such preparation before shutdown).
For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc.
- If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2]
this is _way_ too complicated, and also not clear.
Sorry, what exactly is unclear?
- I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up.
this is even more complicated... and also unnecessary when the person doing the debugging may either:
- in-situ use multiplexing of user-facing connectors (A20 MicroSD /
UART-JTAG capability)
Yes, because this is a completely different approach.
- take the Card out of the Housing and test it in a home-made or
laboratory-owned test Housing.
How can a lab housing tell a card that it's safe to do early debug output? (Or is that still signaled out of band, e.g. by replacing the boot loader?)
This is a debug facility. Not all CPU cards have to use it, but all housings must accept it.
that places a huge technical burden and complexity on Housing Designers *and* Card Designers, where no such complexity or burdensome requirements exist at the moment.
Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors.
the purpose of requiring the "non-optionality" is to ensure that there is absolutely no way that a future Card or future Housing will be incompatible with an older Card or an older Housing, no matter how much faster the peripherals on either the Card(s) or the Housing(s) have become.
[...]
How is speed relevant to this discussion?
"Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation.
exactly. and that's precisely why additional complexity should *not* be added to the negotiation phase.
I don't quite understand your argument here: The only way I'm complicating the "negotiation phase" is by requiring that the software stops any Debug UART output before it switches its use of the UART pins over to the housing-mandated use.
I am not complicating negotiation itself (init I2C controller, read EEPROM, parse EEPROM, act on it).
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
Required by which part?
sorry, the use of the word "part" is not clear. part of the standard? part of the Card? part of the Housing? part of the proposed modification to the standard?
I mean hardware part, which would be either the CPU card or the Housing.
- Housings shouldn't require to see any debug messages from CPU cards, that's just silly
the point is: if the wires are to be forced to transmit early debug messages, then in ABSOLUTELY NO WAY can they also be allowed to change over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their use as UART could conceivably cause damage to either the CPU or to the Housing components.
Ok, I think I see the point here.
and if there is a current fight between a GPIO that is tied permanently to VREFTTL on the Housing and the forced requirement to transmit UART early debug messages tries to pull it high, we have a serious problem.
Permanently (through PCB traces) tying pin 23 (GPIO8/UART_TX) to VREFTTL is not allowed under my proposal.
(And I think you meant "tries to pull it *low*", not high.)
i appreciate that you have come up with a solution to this, involving a complex process of ascertaining via the EEPROM whether the pins are GPIO or UART,
Figuring out (in software) whether the pins are used as UART or GPIO at runtime, by asking the EEPROM, is no more complex than before.
but it is complexity where *none* exists at the moment, and there are two easy alternatives that place absolutely no burden whatsoever on the Technical EndUser.
Soldering to small test pads inside the card is a burden. Figuring out the pin muxing and ordering a microSD breakout board is also a burden.
Those might be small burdens (depending on the experience and market situation of the Technical Enduser), but they are still burdens.
Okay, I think I now understand the main problem with my proposal: Ensuring that it is safe for the CPU card to use pins 23 and 57 during early boot is hard or causes some additional complexity in the housing and software, because (a) because it may reset (and thus enter early boot) spontaneously, and (b) when it leaves early boot, it may have to tell the housing about it.
My goal was to have a mechanism, specified by the EOMA68 standard, by which an interested Technical Enduser can access early debug output of any EOMA68 CPU card, without doing anything CPU card specific (such as ordering a Allwinner A20 µSD breakout board, or opening the card and soldering some wires to the right testpads, or loading a "debug enabled" version of the particular bootloader/OS running on a card).
Here's a *completely different* and significantly simpler proposal, which also fulfills these goals. You probably won't like it because (a) it takes away a pin from general purpose use, (b) it breaks compatibility [see footnote 1] with current hardware.
Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- purpose Debug UART TX pin, where the CPU card may print debug messages in 8N1 format. Debug UART TX high/low is measured against VREFTTL.
CPU card-agnostic applications which require EOMA68, should still not rely on the Debug UART TX line.
As to why the "may" above does not hurt non-optionality: This is not a Retail Enduser facing feature, and should not be advertised to Retail Endusers. If a card doesn't use the Debug UART TX line (i.e. never prints a message), then this doesn't break compatibility with any housings, even housings that are specifically made for the purpose of capturing Debug UART TX output. In the worst case, a Technical Enduser will think "Oh, this card doesn't output anything on the debug line. Now I can't debug it as easily", but not "This card doesn't output anything on the debug line, now my application doesn't work". (Such a CPU card is, in a way, only "hurting itself")
Alternatively, this could be two pins (Debug UART TX and RX) so that something like a bootloader shell may be used. But this is probably worse because it takes another pin away from general-purpose use.
Thanks, Jonathan Neuschäfer
[footnote 1]: Current CPU card hardware could in fact generate a valid (idle) Debug UART TX signal, by driving Debug UART TX high.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jan 11, 2018 at 9:50 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
Hi,
Please excuse the verbosity of some parts of this email, where I tried to be extra clear.
thanks jonathon.
no, it's very clearly specified that there *is* no limit or restriction. which is totally different from leaving things "unspecified".
The EOMA68 spec doesn't specify how to enable early debug mode, that's what I meant.
the correct technical phrase is "it is out of scope". which i forgot to add.
so that's because it's assumed to be part of either a factory install (where the EOMA68 specification does not apply. or it does - or should say - "this is out of scope")
or you are a Technical End-User.... where the EOMA68 specification does not apply. or.. it does, but it says - or should say - "this is out of scope"
In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/
ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output.
This is AFAICS not a big problem under my suggested change.
For reference, this is my suggested change:
- CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted.
ok so that implies that the UART lines MAY be UART... they MIGHT also be GPIO. please bear in mind: anything that involves "confusion" is AUTOMATICALLY prohibited from being included in the EOMA68 Standard.
Confusion for which group of people?
mainly it's the end users
USERS: Early debug output is a feature that probably shouldn't be documented for Retail Endusers anyway:
absolutely. in fact it is the opposite: they should NOT be informed of its existence. they would be totally scared and freaked out.
They can't be expected to find it useful. Technical Endusers however can probably navigate the confusion, and understand the feature if it's documented well enough.
... exactly.
CARD DESIGNERS: I don't think card hardware designs need to change.
yyyeah.... i think it should be _adviseable_ - not mandatory but _advised_ that easy and independent debugging - preferably without dismantlement of Cards - should be mentioned.
HOUSING DESIGNERS: Yes, this puts the burden to tolerate UART mode during early boot on housing designers.
that's the bit that's not acceptable.
OPERATING SYSTEM DEVELOPERS: Yes, OSes may need to do a little more in order to use the full feature set of a housing.
BOOTLOADER DEVELOPERS: AFAICS, they need to care less about EOMA68 then before, because they can now just print all the debug output they want, without looking at the EEPROM.
... and lose 2 critical GPIO pins where they are extremely precious, and if they are not available you have to add $1 to $1.50 to the Housing BOM to add an 8/32-bit MicroController, and massively complicate the OS and Housing design compared to just having 2 GPIO pins?
... no :)
i appreciate that in this case you describe a procedure that would remove doubt, but the procedure itself is very burdensome to implement.
there is a story i told about the X25 Standard which illustrates how these kinds of choices result in lost opportunities and/or total confusion and thus destroy confidence in a standard.
- When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM.
ok so the boot process you propose is:
- bring up the CPU (DDR3, PLLs)
- initialise EEPROM GPIO pins and configure them as I2C
- read an I2C EEPROM
- decode it
- work out if it's SAFE to write to UART
- THEN write debug / print messages on the UART pins
... can you see how that's not "early" at all?
No, what I'm trying to propose (and think through) is different:
- Reset the SoC and bring the pins of the EOMA68 connector into the state that's mandated at reset (most pins tri-stated, etc.)
- Bring some of the SoC (configure clock trees, maybe the DRAM, too)
- Initialize the UART and start using it, because it is safe to use in early boot
yes. ok. this is where the problem starts. this is why i described it as "forced writing to UART". if you FORCE writing to UART, you MUST not have the possibility of these two pins potentially being GPIO.
why? because you get into a CMOS current fight between UART and fixed GPIO function (short to GND or short to VREFTTL) which will either damage the UNBUFFERED processor pins or damage the housing.
therefore you must make it MANDATORY that the ONLY function that those two pins have is: UART.
therefore you LOSE two precious GPIO pins.
and that is not acceptable.
- Continue bringing up things and printing debug messages
- Perhaps already load the OS kernel
- Configure the I2C controller and read the EEPROM
- Stop doing early debug output, and start using the UART pins in the way that's mandated by the EEPROM
too complicated.
I can see two points where problems might occur:
- If software fails to disable early debug output in the UART (this shouldn't too hard to solve in Linux, though).
there is also damage to the SoC or to the housing to take into consideration.
- If the CPU card spontaneously resets without first bringing the housing into a state where it tolerates early debug output (some housings might require such preparation before shutdown).
exactly. and that is far too complicated. right now there is *zero* need - at all - for *any* kind of complexity on the Housings. the Micro-Desktop is.... it's just a bunch of connectors. as in, that's *all* that's needed.
oh! ah.... that's another reason why the proposed change can't be done (aside from it being unnecessary, as there are debug mechanisms available): the MicroDesktop PCB is finalised.
For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc.
- If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2]
this is _way_ too complicated, and also not clear.
Sorry, what exactly is unclear?
it's too complcated, it raises the complexity of Housings from "passive I/O systems" to "requiring some form of boolean logic circuit". it's not needed, it's too complicated, and it's also, realistically, too late.
- I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up.
this is even more complicated... and also unnecessary when the person doing the debugging may either:
- in-situ use multiplexing of user-facing connectors (A20 MicroSD /
UART-JTAG capability)
Yes, because this is a completely different approach.
- take the Card out of the Housing and test it in a home-made or
laboratory-owned test Housing.
How can a lab housing tell a card that it's safe to do early debug output?
that's the responsibility of the Technical End-User to research and determine precisely that.
(Or is that still signaled out of band, e.g. by replacing the boot loader?)
you replace the bootloader. it is *REQUIRED* - as part of the EOMA68 Specification - that the replacement of the bootloader - all of it - be not only possible but the hardware be FULLY DOCUMENTED such that it IS possible.
that allows for companies to provide proprietary bootloaders if they so wish (for which they will be charged extra fixed-rate non-percentage-based non-royalty-based license costs).
if however they release FULL source code of the bootloader (and the full toolchain), they will not be charged any fees at all.
Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors.
the purpose of requiring the "non-optionality" is to ensure that there is absolutely no way that a future Card or future Housing will be incompatible with an older Card or an older Housing, no matter how much faster the peripherals on either the Card(s) or the Housing(s) have become.
[...]
How is speed relevant to this discussion?
it is an illustration of the fact that this is a long-term standard.
"Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation.
exactly. and that's precisely why additional complexity should *not* be added to the negotiation phase.
I don't quite understand your argument here: The only way I'm complicating the "negotiation phase" is by requiring that the software stops any Debug UART output before it switches its use of the UART pins over to the housing-mandated use.
that is far too complicated compared to the "passive" nature of, for example, the Micro-Desktop Housing. see above, the answer is the same as here.
I am not complicating negotiation itself (init I2C controller, read EEPROM, parse EEPROM, act on it).
the current design, there *is* no extra negotiation, period, on the Housings. therefore adding some *is*, by definition, a whole new level of complexity [that is not acceptable. and too late. and unnecessary].
.... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires?
Required by which part?
sorry, the use of the word "part" is not clear. part of the standard? part of the Card? part of the Housing? part of the proposed modification to the standard?
I mean hardware part, which would be either the CPU card or the Housing.
precisely. you do not know. therefore there is the risk of confusion. and therefore, one - or other or both - would be damaged.
it is ABSOLUTELY ESSENTIAL that there be ZERO possibility for ambiguity in a standard.
- Housings shouldn't require to see any debug messages from CPU cards, that's just silly
the point is: if the wires are to be forced to transmit early debug messages, then in ABSOLUTELY NO WAY can they also be allowed to change over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their use as UART could conceivably cause damage to either the CPU or to the Housing components.
Ok, I think I see the point here.
yehyeh. it's really, really important.
and if there is a current fight between a GPIO that is tied permanently to VREFTTL on the Housing and the forced requirement to transmit UART early debug messages tries to pull it high, we have a serious problem.
Permanently (through PCB traces) tying pin 23 (GPIO8/UART_TX) to VREFTTL is not allowed under my proposal.
that would need to be part of the specification. now you have to have a resistor in the circuit to stop damage. NOW you have to wonder if that will stop the GPIO pin, if it is an input, from being able to drive the line properly.
... do you see how it gets massively complex?
and i haven't even gotten into how to protect the GPIO from over-voltage protection during power-down and power-up.
it's just far, far too much, jonathon... *and completely unnecessary*.
(And I think you meant "tries to pull it *low*", not high.)
it doesn't matter which it is: damage can occur either way.
i appreciate that you have come up with a solution to this, involving a complex process of ascertaining via the EEPROM whether the pins are GPIO or UART,
Figuring out (in software) whether the pins are used as UART or GPIO at runtime, by asking the EEPROM, is no more complex than before.
it's too complex, and you can't debug the chip during the EEPROM bring-up phase because it's too dangerous to do so.
it's *too complex* jonathon.
but it is complexity where *none* exists at the moment, and there are two easy alternatives that place absolutely no burden whatsoever on the Technical EndUser.
Soldering to small test pads inside the card is a burden.
yes. it's not recommended.
Figuring out the pin muxing and ordering a microSD breakout board is also a burden.
tough. a Technical End-User *will* be expected to figure it out. that's why they're called "Technical End-User".
Those might be small burdens (depending on the experience and market situation of the Technical Enduser), but they are still burdens.
yep. tough. if they can't figure it out, they can ask someone online how it's done. this is no different from any other dev-board. someone, somewhere, knows how to do it.
Okay, I think I now understand the main problem with my proposal: Ensuring that it is safe for the CPU card to use pins 23 and 57 during early boot is hard or causes some additional complexity in the housing and software, because (a) because it may reset (and thus enter early boot) spontaneously, and (b) when it leaves early boot, it may have to tell the housing about it.
exactly. and the very fact that the housing has to have "logic" in it, where the Housings are currently TOTALLY passive, is a level of complexity that's unacceptable [and unnecessary].
My goal was to have a mechanism, specified by the EOMA68 standard, by which an interested Technical Enduser can access early debug output of any EOMA68 CPU card, without doing anything CPU card specific (such as ordering a Allwinner A20 µSD breakout board, or opening the card and soldering some wires to the right testpads, or loading a "debug enabled" version of the particular bootloader/OS running on a card).
my goal is: to make it easy and safe for normal mass-volume end-users to use EOMA68 systems. "Just Plug It In, It Will Work". everyone else - everything else - comes secondary.
Here's a *completely different* and significantly simpler proposal, which also fulfills these goals. You probably won't like it because (a) it takes away a pin from general purpose use, (b) it breaks compatibility [see footnote 1] with current hardware.
Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- purpose Debug UART TX pin, where the CPU card may print debug messages in 8N1 format. Debug UART TX high/low is measured against VREFTTL.
nope. not enough pins. you're thinking in terms of prioritising "Technical End-User" over "End-User".
the volume of sales to "End User" is intended to be HUNDREDS OF MILLIONS.
the volume of sales to "Technical End User" is expected to measure in the thousands.
... which should the project be prioritised for?
if this was something like a "Mars Board" or a "Beagle Board" or {insert-other-technical-developer-board} it would be a totally different discussion.
this is a *mass-volume* standard, ***NOT*** repeat ***NOT*** a TECHNICAL DEVELOPER user standard.
Alternatively, this could be two pins (Debug UART TX and RX) so that something like a bootloader shell may be used. But this is probably worse because it takes another pin away from general-purpose use.
exactly. now you're getting it. the cost of adding break-out GPIO extenders could add 10 to 20% onto the BOM, and that's totally unacceptable in a *mass-volume* market. it's perfectly acceptable in a "Demo Board" or a "Reference Design Board" or a "Developer Board" scenario, but completely unacceptable for a mass-volume standard.
l.
Thanks for your explanations. That's all I really have to say after that mail.
On Fri, Jan 12, 2018 at 10:29:14AM +0000, Luke Kenneth Casson Leighton wrote: [...]
- If the CPU card spontaneously resets without first bringing the housing into a state where it tolerates early debug output (some housings might require such preparation before shutdown).
exactly. and that is far too complicated. right now there is *zero* need - at all - for *any* kind of complexity on the Housings. the Micro-Desktop is.... it's just a bunch of connectors. as in, that's *all* that's needed.
I wasn't aware housings tend to be *this* simple.
Here's a *completely different* and significantly simpler proposal, which also fulfills these goals. You probably won't like it because (a) it takes away a pin from general purpose use, (b) it breaks compatibility [see footnote 1] with current hardware.
Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- purpose Debug UART TX pin, where the CPU card may print debug messages in 8N1 format. Debug UART TX high/low is measured against VREFTTL.
nope. not enough pins. you're thinking in terms of prioritising "Technical End-User" over "End-User".
the volume of sales to "End User" is intended to be HUNDREDS OF MILLIONS.
the volume of sales to "Technical End User" is expected to measure in the thousands.
Ok, makes sense. That's a valid design point.
Thanks, Jonathan Neuschäfer
On Tue, Jan 16, 2018 at 10:34 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
Thanks for your explanations. That's all I really have to say after that mail.
ok cool.
Micro-Desktop is.... it's just a bunch of connectors. as in, that's *all* that's needed.
I wasn't aware housings tend to be *this* simple.
yehyeh - the phrase is "passive components" or something... not sure which. the laptop pcb, microdesktop, tablet and the router, they're all basically nothing more than a power converter, current-limiting chip, an EEPROM and some connectors. for the video output the only minor "complication" is the inclusion of - again "passive conversion" circuits. an SN75LVDS83b or 6-bit A->D circuits for VGA.
l.
ok so i made a set of changes, replaced "I/O Board" with "Housing" everywhere, and updated the text as you suggest, jonathon. no on the contraction though. also added sentence (repeated) about UART level-shifting diagrams.
On Wed, Jan 17, 2018 at 12:13:52PM +0000, Luke Kenneth Casson Leighton wrote:
ok so i made a set of changes, replaced "I/O Board" with "Housing" everywhere, and updated the text as you suggest, jonathon. no on the contraction though. also added sentence (repeated) about UART level-shifting diagrams.
Thanks!
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.
Furthermore, it would be useful if the diagram below that had labels for the CPU Card and the Housing board (*). 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.
(*) https://elinux.org/File:EOMA68-UART-RX-PROTECT.gif
[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.
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?
(Unfortunately this won't be as easy as "sed" and "git commit", because the EOMA68 standard isn't maintained in Git :/.)
Thanks, Jonathan Neuschäfer
--- 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.
(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 :)
It would require some work to migrate the site, but gitlab https://gitlab.com/ is open source, free, and can host static pages.
On Wed, Jan 17, 2018 at 6:12 AM, Mike Henry mikejackofalltrades@gmail.com wrote:
It would require some work to migrate the site, but gitlab https://gitlab.com/ is open source, free, and can host static pages.
it's ok, mike - i run my own git repository servers, the main thing is, an automated conversion / updating system would be needed... that in turn means a lot _more_ work... unless the standard was moved over to ikiwiki (which means conversion to markdown)... whatever is done it means quite a bit of work and in the process the "independent" use of an impartial and independent *relevant* site - elinux.org - would be lost in the process.
the only two things which would warrant i think some work would be (a) a backup mechanism and (b) hosting - finally - on eoma68.com
l.
Hi,
On Wed, Jan 17, 2018 at 05:52:50AM +0000, Luke Kenneth Casson Leighton wrote:
On Wed, Jan 17, 2018 at 12:31 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
[...]
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".
Ok, let me try again, without these less important differences:
"As this problem is to be taken care of on the I/O Board it is worth observing that CPU Cards do not need to perform UART buffering. They may however need to perform level shifting:"
Thanks, Jonathan Neuschäfer
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jan 17, 2018 at 2:47 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
Ok, let me try again, without these less important differences:
"As this problem is to be taken care of on the I/O Board it is worth observing that CPU Cards do not need to perform UART buffering. They may however need to perform level shifting:"
As this problem is to be taken care of on the Housing it is worth observing that CPU Cards do not need to perform UART buffering (as this would interfere with their potential use as GPIO lines).
i realised that the reason *why* you don't level-shift on the Card was not mentioned.
l.
arm-netbook@lists.phcomp.co.uk
-
Jonathan Neuschäfer -
Luke Kenneth Casson Leighton -
Mike Henry