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

On Fri, Aug 26, 2016 at 7:01 PM, Alexander .S.T. Ross maillist_arm-netbook@aross.me wrote:

heres a pad to make notes/ draft ideas: https://public.pad.fsfe.org/p/eoma68_handheld

i'd prefer it be kept on the wiki page http://rhombus-tech.net/community_ideas/clamshell_microlaptop/ i can set up a pad at some point... if you're going to use an external pad please link it to that wiki page.

l.

*All* handheld computers are a mess. Google up the PSION Organizer II some time. My example was made the year I was born... 1986. There are two PCBs and a ribbon cable inside your average Org2, and the traces on the motherboard are positively draconian -- they have a habit of jumping from one side to the other three or four times on their way to the ribbon cable...

Here, have a picture --> http://archive.psion2.org/org2/images/circuit.jpg

That's just the *top* side of the mainboard... there's a 36-key keyboard on the other side, along with another plate of spaghetti traces! Mind you that's the deluxe "LZ64" model, although it's not really any more complicated than the rest of 'em. For the curious... the three chips at the top are LCD drivers, HD44780s. The big chip below and to the left is the HD6303-series CPU (sort of an enhanced Motorola 6800). Below that is the RAM (all 64k of it, lol) and what I suspect is an early gate array, and below *those* would be the ROM. Note that it actually uses chip resistors... the cheaper ones used carbon strips deposited on the board. Not kidding!

Why do I care? There's a small community still, based around that thing, and I (not quite realizing what I was getting into) volunteered myself to reverse-engineer it. I *think* I might've made a mistake...

On Fri, Sep 2, 2016 at 12:37 PM, Joseph Honold mozzwald@gmail.com wrote:

On 09/02/2016 09:58 AM, Luke Kenneth Casson Leighton wrote:

...

well, do add the research that you've done to http://rhombus-tech.net/community_ideas/clamshell_microlaptop/

that's what the wiki is there for. at the same time can you please add mention of the SEW291 3G module, and that it's $12 in low volume, and that it uses an MSM6260 chipset.

Will do. Really, I'm just trying to keep the *conversation* going and get more input from others.

...

also, whilst initially it looks really great to add a $1 TI TCA8418 or other I2C chip, you soon find that you need another $1 chip, then another $1 ADC/DAC chip, then another $1 chip, and pretty soon it's like "hang on a minute this is f*****g stupid, that's $5 worth of ICs to do the same job as a $1.50 STM32F072!"

Good point. It all depends on what features get implemented in the handheld. TCA8418 combined with STMPE811 touch controller/gpio expander seems like a possible low cost option. Both have linux drivers so no need for custom firmware.

...

also bear in mind that from experience with the HTC Universal reverse-engineering doing clamshell phone / pdas is f****** complicated. beyond *any* shadow of doubt they are by far and above way more complex in terms of I/O than laptops, or even intel desktop PCs.

Yeah, the mechanics of the hinge and getting cables from top to bottom would be a pain. I'm leaning towards the candybar form factor to keep it less complicated.

My list of wanted features: QWERTY Keypad with backlight Wifi Cellular (optional) 640x480 or higher resolution LCD Touchscreen (resistive) Ambient Light Sensor (for backlight dimming) USB Audio (headphone jack, internal mic, ear speaker for phone, loudspeaker) USB Hub [wifi, audio, cellular, external host port(s)] Camera (optional, USB) Micro SD Slot

You might be able to get a good head start by taking the GTA04 schematics (basis of Neo900) and looking at modifying them to accept an EOMA-68 computer card rather than having an onboard processor.

The GTA04 is a fairly mature schematic, the latest revision GTA04A5 is going through the final stages before a production run.

http://projects.goldelico.com/p/gta04-main/

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

On Fri, Sep 2, 2016 at 7:26 PM, Paul Boddie paul@boddie.org.uk wrote:

The Pyra [3] is supposed to be modular (having, for example, a replaceable CPU board [4] and potentially other boards), but it isn't certain that the hardware (above the component level) will be libre [5]. But it might be worth mentioning in any arguments about modularity because the designers clearly think that something fairly similar to EOMA68 is worthwhile.

the pyra discussion on the crowdfunding campaign (there have been several others) shows that people are definitely interested. https://pyra-handheld.com/boards/threads/really-cool-modular-and-freedom-res...

On 02/09/16 15:33, Joseph Honold wrote:

A handheld QWERTY device has been my goal for EOMA68 since I found out about it.

:)

Mouse could be implemented as a "keymouse" (like we use on Zipit, uinput driver). Basically, hold a modifier key and use DPad to move cursor and right/left click buttons.

Or something like Mouseless (recursive 9-box grid) or Mousemove: https://www.youtube.com/watch?v=6P7gZFtihKM

What is everyones favorite form factor?

Ideally, a design like the HTC Universal ("clamshell tablet"?), or alternatively the N900/Neo900 or HTC Dream ("slide"?), with a hybrid ("transreflective"?) screen a bit like the ones Mary Lou Jepsen or Pixel Qi made for the OLPC XO-1. That kind of screen can be switched between backlit for conventional computing, and reflective, where it functions a bit like an e-ink display, reducing eye strain and battery drain.

That way, a single hand-held device would be:

- Mini laptop - Mini tablet - E-book reader - (Phone too, possibly.)

The advantage of the HTC Univeral's design is that when stowed, the screen is protected from scratches. However, modern glass ("gorilla glass", etc) potentially makes that unnecessary, which is why the slide mechanism would be viable.

I don't know if that kind of glass is compatible with hybrid displays of the kind I mentioned above. Nor do I know if such hybrid displays are even remotely obtainable or affordable in the relevant sizes or with suitable interfaces. We live in hope :)

On 02/09/16 15:33, Joseph Honold wrote:

Ultimately, I want to have cellular phone capability (voice/data/sms) [... ]

Pyra is nice but wouldn't be a good as a traditional cellphone unless you put ear speaker and mic on backside of LCD/lid.

Any microphones or speakers (or cameras for that matter), if present, should have hardware switches so that they can be kept disconnected when not in use, to avoid eavesdropping, key-logging, etc.

On 02/09/16 16:52, Luke Kenneth Casson Leighton wrote:

the hybrid nature of the pixelqi screens was achieved by MASSIVELY reducing the viewing angle, to the point where the distance between people's eyes became a critical factor.

I've never owned an XO-1, but on the occasions I used them, I really liked the screens.

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

On Fri, Sep 16, 2016 at 5:30 PM, Joseph Honold mozzwald@gmail.com wrote:

On 09/02/2016 09:33 AM, Joseph Honold wrote:

...

I've been looking at various LCD options and all of the RGB ones that are 3.5"-4" have low resolution (320x240, 480x320, and expensive 640x480). This lead me to look at MIPI DSI displays which are cheaper with higher resolution but more complicated requiring a conversion IC. I see mention of the SSD2828 RGB to MIPI chip in the mailing list which seems low cost and it is already used in a couple A20 devices. Has anyone had experience with this chip? It seems u-boot enables it but I'm not sure how linux interacts with it.

http://arm-netbook.phcomp.co.narkive.com/tTYfuse7/rgb-to-mipi http://linux-sunxi.org/SSD2828

I poked #linux-sunxi on irc and found out u-boot (mainline) sets up the SSD2828 device and passes it over to linux (mainline) SimpleFB driver. The MSI Primo 8.1 tablet uses the SSD2828 and has an example configuration

https://github.com/linux-sunxi/u-boot-sunxi/blob/mirror/next/configs/MSI_Pri...

I currently have a Marsboard A20 and was able to get u-boot/linux mainline running on it the other day. My plan is to create a ssd2828 breakout board that I can do some testing with the Marsboard in preparation for designing an EOMA68 housing.

oo good! if you're intending to do that as GPLv3+ i would like to put you in touch with manuel (gacuest) as he's using the SSD2828 for the EOMA68 hand-held games console.

The eoma68-A20 card is shipping with linux 3.4 and is (of course) possible to upgrade to u-boot/linux mainline.

yes... because it's the only kernel that fully supports all the hardware in a stable fashion. bear in mind that i've done approximately 50 kernel compiles searching for a stable mainline linux kernel. the problem is somewhere around 4.0rc5 and 4.0rc6. i.e. 4.0rc5 works, 4.0rc6 doesn't.

How would a special configuration like this be handled by the standard where your housing requires a special bootloader/kernel?

knock yourself out: do whatever you like. the only thing is, if you want to be able to call it an "EOMA68-compliant Housing" that's a totally different matter.

Is it just a matter of having a boot device on the housing (sd card, usb, etc)?

mmm this came up a couple years ago: it was concluded that this practice - of putting boot devices onto Housings - would be a Bad Idea (for EOMA68 compliance)... but that, obviously, if you are not interested in making a formal declaration "Compliant With The EOMA68 Standard", you're free to do whatever you like.

the reason why it would be a bad idea to have boot devices on the housing is of course that when you take the EOMA68 card out and put a different one in.... now the new card has no idea how to boot.

so, they really do have to be self-contained... [if you want to be able to make a formal declaration, "compliant with the EOMA68 standard"].

Does the eeprom fit in this process somehow?

the eeprom we concluded that it would act merely like the USB / PCI "id". nothing else. that would be sufficient to identify the Housing, with its associated hardware peripherals. must properly document that. from there, u-boot and linux kernel would use that to pull in "device-tree fragments": https://lkml.org/lkml/2015/11/10/593

Pantelis Antoniou is (has) implemented the required "live devicetree reconfiguring / adding" hooks that will allow per-housing pre-compiled BINARY fragments to be selected and incorporated.

the eeprom's contents (an 8 byte number) will be used exactly as is done with USB ids to select which "fragment" shall be added.

the discussion with pantelis included the question, "what happens when the Housing is live-unplugged or the device is suspended, resumed, and discovers that it's in a completely different Housing?" - he'd not considered that as a possibility.

basically there's a "roadmap"... we're not there yet, but the pieces are in place.

l.

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

On Wed, Sep 21, 2016 at 10:59 PM, Joseph Honold mozzwald@gmail.com wrote:

...

so, they really do have to be self-contained... [if you want to be able to make a formal declaration, "compliant with the EOMA68 standard"].

I don't see how a housing that needs a particular libre bootloader, kernel or driver is non-compliant with the standard (as it is currently written). Perhaps there needs to be more clarification of the boot process and software requirements for compliance?

there is: mainly the burden is on the Cards (not the Housings), but it is essential that the I2C EEPROM at address 0x51 contain the required "identification" information... and that hasn't yet been completely implemented yet.

so until that's work's been done, people implementing Housings need to be keenly aware of that... if they would like to be able to claim "compliance".

u-boot can boot from just about anything now (except maybe punched cards :). You could easily write the boot process to check for boot devices in a specific order, lastly to internal NAND. We use this process on the Zipit Z2: if u-boot script on sdcard, boot from it, else if uboot script on usb, boot from it, else boot internal NOR. This can work on the EOMA cards as well.

there are some source code modifications required to both the linux kernel and u-boot, to add the patch that can load device-tree binary fragments, but then also there is the specific specialisation that needs to be added which reads the EOMA68 I2C EEPROM in order to be able to ascertain *which* dtb binary fragment shall be added in.

so, part of the compliance of Housings manufacturers *will* be that they will need to provide a device-tree fragment that is kept up-to-date. if the linux kernel devicetree format changes suddently (in linux version 9.999 for example) they'll be required to provide an update if they would like to keep their Housing Certification up-to-date.

Have you considered creating two standards instead of one? Make one a hardware compliance (physical, electrical, mechanical, etc) and a separate software compliance? That way one could be hardware compliant but use it's own software. (as I finish that sentence I can already hear the big NO to that question :)

no :) that would bring the standard into disrepute, by violating the tagline "Just Plug It In: It Will Work". now you have to replace that with: "First You Must Check If The Hardware Is Compliant With The Hardware Standard, Then You Must Check If The Software Is Compliant With The Software Standard, Oh And If Both Those Things Are True Then Yes You Can Plug It In and It Will Work. Or, You Could Just Try Plugging It In And Guessing".

... that's a clear violation of the basic underlying principle of the EOMA68 standard's simplicity, isn't it?

It just doesn't make sense (to me) to effectively lock someone to a particular bootloader/kernel that is potentially less capable by denying them compliance. As long as my housing works with free/libre software, what's the problem?

the EOMA68 standard is not merely about "working with free / libre software". it's about making **100 MILLION AND ABOVE PER YEAR** free/libre Housings (and Cards) and ensuring that the returns rate is well below 0.001% (0.001% of 100 million a year is a hundred THOUSAND units a year, which is absolutely insanely large, and could well represent the entire profit margin for that year. mass-volume is radically different).

you cannot possibly expect, with those kinds of numbers, that people will be capable of compiling their own kernels etc. etc. or even that they are capable of installing a new OS. they want something that "just works". if it don't work, they'll return it (or discard it).

In a case where a housing is designed to be a router, if I plug my A20 cpu card that ships with a desktop gui OS, it is in no way configured to be usable as a router.

that's absolutely fine and permitted: i would expect the user to plug in an OTG Cable, plug in an HDMI cable, boot from internal NAND or internal MicroSD and off they go. in effect they would merely be using the router for "power provision". if the desktop OS is kept properly patched and up-to-date, the device-tree binaries would already be on the CPU Card, so it would even recognise the USB devices and other hardware of the Housing. not that there might necessarily be any applications installed which could take advantage of the extra hardware, but that's the user's problem to deal with by installing the applications that they require.

the key bit that's glossed over there is: the user should be keeping the OS (specifically the u-boot and linux kernel) up-to-date so that it is capable of recognising all Housings. for _that_ to work, all Housings implementers / designers *must* keep the device-tree fragments up-to-date.

any end-user that doesn't keep their OS up-to-date (stops automatic updates from being installed, for example) is "on their own".

the envisaged process isn't perfect, by any means: we do have to be realistic about that.

So, would you deny that the router housing EOMA compliance?

of course not, because the question is a misunderstanding of the process.

anyone who is plugging in (for example) an EOMA68-A20 into a (for example) router Housing is probably the kind of expert who knows what they're doing. if they're even *remotely* contemplating that kind of re-purposing / mixing-and-matching (and are the first or one of the first to consider doing it) i think it's safe to assume that they would be capable of customising (or entirely replacing) the OS with one that is more suited to the job of "being a router" as opposed to "being a desktop OS".

several years ago, we looked at the possibility of adding "a large software trove" to Housings, placing basically multiple OSes and/or drivers onto some special MANDATORY storage within EVERY housing. as you might imagine, that was deemed totally impractical, very very quickly.

now, it would be _really nice_ if each "Housing Community" had some sort of pre-compiled OSes for all the different Cards out there, but realistically that's also not going to be totally practical either: a specialist FPGA Card for example we could not possibly expect every compliant Housing Designer to purchase absolutely every single Card (especially if some of them costs thousands of dollars).

and that's where the role "Guardian of the EOMA68 Standard" comes into play, because that *is* the responsibility of the Guardian(s) to ensure that all Housing and all Card designers who seek to be compliant with the EOMA68 Standard provide samples (on an ongoing basis) to the Guardian(s) so that they *can* do testing and/or OS setups etc. etc. which the independent manufacturers simply could not.

basically, there's a roadmap in my head which hasn't really been written down yet. or, it was... it was written ad-hoc on the mailing list several years ago as part of a discussion amongst the prominent responding members of that time. i don't believe any of those people are still active on the list: i'm the last one remaining so i am the last one who still actively remembers those discussions.

now, ta-daaa! congratulations: you are :)

Can you just require all source code and shipped binaries be available before compliance is approved?

in light of the above, the question may need to be reworded / rethought. just as the Bill of Ethics points out: entropy will require to be continuously overcome in order to achieve [continuous] compliance. it's not a one-off "fire-and-forget" process.

l.

On 09/22/2016 07:33 AM, Joseph Honold wrote:

On 09/21/2016 10:46 PM, Luke Kenneth Casson Leighton wrote:

...

...

In a case where a housing is designed to be a router, if I plug my A20 cpu card that ships with a desktop gui OS, it is in no way configured to be usable as a router.

that's absolutely fine and permitted: i would expect the user to plug in an OTG Cable, plug in an HDMI cable, boot from internal NAND or internal MicroSD and off they go. in effect they would merely be using the router for "power provision". if the desktop OS is kept properly patched and up-to-date, the device-tree binaries would already be on the CPU Card, so it would even recognise the USB devices and other hardware of the Housing. not that there might necessarily be any applications installed which could take advantage of the extra hardware, but that's the user's problem to deal with by installing the applications that they require.

the key bit that's glossed over there is: the user should be keeping the OS (specifically the u-boot and linux kernel) up-to-date so that it is capable of recognising all Housings. for _that_ to work, all Housings implementers / designers *must* keep the device-tree fragments up-to-date.

any end-user that doesn't keep their OS up-to-date (stops automatic updates from being installed, for example) is "on their own".

the envisaged process isn't perfect, by any means: we do have to be realistic about that.

...

So, would you deny that the router housing EOMA compliance?

of course not, because the question is a misunderstanding of the process.

anyone who is plugging in (for example) an EOMA68-A20 into a (for example) router Housing is probably the kind of expert who knows what they're doing. if they're even *remotely* contemplating that kind of re-purposing / mixing-and-matching (and are the first or one of the first to consider doing it) i think it's safe to assume that they would be capable of customising (or entirely replacing) the OS with one that is more suited to the job of "being a router" as opposed to "being a desktop OS".

If an average consumer buys a housing that claims it is a router and plugs in their old A20 cpu card (that contains a pre-installed desktop style OS) the hardware may be configured correctly per the dtb, but they surely won't be happy when they find out they need to setup a firewall, dhcp server, etc, etc, and much much more. The definition of "plug it in and it works" here is sketchy at best. IMO, "works" means, works as a router like the housing packaging said it would, and I expect most consumers would think the same. Now, average consumer tosses cpu card and housing in the trash and never buys EOMA again because it didn't *just work*.

Consumers should expect some kind of setup for any new hardware, especially a networking appliance, but asking them to install and properly configure a router OS is preposterous. If you allow a provision for housings to boot, the router housing manufacturer can provide a suitable OS (eg openwrt) and average consumer can be happy.

As a user, I would expect to be sold a router housing and a router EOMA68 computer card. I would expect the router housing to be able to host my desktop card as well. I would also expect the router card to work in my desktop housing.

On 09/22/2016 03:07 PM, Luke Kenneth Casson Leighton wrote:

---

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

On Thu, Sep 22, 2016 at 8:07 AM, pelzflorian (Florian Pelz) pelzflorian@pelzflorian.de wrote:

...

As a user, I would expect to be sold a router housing and a router EOMA68 computer card. I would expect the router housing to be able to host my desktop card as well. I would also expect the router card to work in my desktop housing.

provision of power is about the common denominator: i already outlined the example where use of the OTG port and HDMI cable would allow the CPU-Card-With-The-Desktop-OS to be useful and functional. anything else that you get (such as a USB-based WIFI adapter or USB-based Ethernet port) is a "plus" but is in no way guaranteed and should in no way be *expected*, either.

Yes, exactly.

the other way round is unlikely to work and, if you did not then seek out (at your own expense and initiative) a replacement OS, replacing the Router OS with a Desktop OS, then that is your lookout. also: router cards are quite likely to be 120 to 500mhz single-core MIPS processors with on-board RAM restricted to potentially as little as 8 MB (yes 8 MEGABYTES - that's eight MB). if you are *genuinely* expecting a 120mhz processor with 8mb of RAM to be capable of running a Desktop OS, you are (to put it mildly) completely delusional.

basically it's necessary to apply some common sense, here.

No, no, that’s not what I meant. What I meant is that when plugging in the router card into a desktop housing, it should still work *as a router* (as in, bootable and maybe a dumb switch). The housing may not have the required ports of course for proper usage as a router and the router OS is probably (hopefully, security-wise) not usable as a desktop OS, but it should show something like a tty on the display.

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

On Thu, Sep 22, 2016 at 6:33 AM, Joseph Honold mozzwald@gmail.com wrote:

On 09/21/2016 10:46 PM, Luke Kenneth Casson Leighton wrote:

...

...

I don't see how a housing that needs a particular libre bootloader, kernel or driver is non-compliant with the standard (as it is currently written). Perhaps there needs to be more clarification of the boot process and software requirements for compliance?

there is: mainly the burden is on the Cards (not the Housings), but it is essential that the I2C EEPROM at address 0x51 contain the required "identification" information... and that hasn't yet been completely implemented yet.

so until that's work's been done, people implementing Housings need to be keenly aware of that... if they would like to be able to claim "compliance".

ok, so it's not written in the spec yet.

correct. this is a massive project. i've been the only one working on it, so all previous discussions were "theoretical", therefore were a bit nebulous, but they _did_ spur me to actually think about it (for several years, over several years).

the fact that you now actually want to know means that it's time to actually thrash it out and document it properly.

...

no :) that would bring the standard into disrepute, by violating the tagline "Just Plug It In: It Will Work". now you have to replace that with: "First You Must Check If The Hardware Is Compliant With The Hardware Standard, Then You Must Check If The Software Is Compliant With The Software Standard, Oh And If Both Those Things Are True Then Yes You Can Plug It In and It Will Work. Or, You Could Just Try Plugging It In And Guessing".

... that's a clear violation of the basic underlying principle of the EOMA68 standard's simplicity, isn't it?

seems simple enough to me. two shiny stickers, one says EOMA68 HW Compliant, other says EOMA68 SW Compliant. If it's missing the SW, the manufacturer should supply you software :P

the very fact that two separate and distinct stickers exist *is* in and of *itself* a clear violation of the simplicity principle "Just Plug It In, It Will Work". the physical form-factor (the hardware connector interoperability) *is* a "guarantee" that "If You Can Actually Get It Into The Socket, Which Is A Simple Act Taking A Few Seconds And Requiring No Technical Knowledge, It Will Work".

let's try an analogy. let's take an SD/MMC Card. if you have on the outside of the SD/MMC Card "SD/MMC SW Compliant" and there were some that didn't, and you couldn't even tell if some little fuck in a back yard factory somewhere was REMOVING (or worse ADDING) stickers, how long do you think it would be before other Memory Card Standards took over in full force from SD/MMC?

no. we simply cannot possibly expect people - force people - to read stickers in order to make technical decisions. you plug it in, it works. no thought required.

to even consider doing anything else would *automatically* bring the standard into disrepute (even before it got off the ground).

...

...

It just doesn't make sense (to me) to effectively lock someone to a particular bootloader/kernel that is potentially less capable by denying them compliance. As long as my housing works with free/libre software, what's the problem?

the EOMA68 standard is not merely about "working with free / libre software". it's about making **100 MILLION AND ABOVE PER YEAR** free/libre Housings (and Cards) and ensuring that the returns rate is well below 0.001% (0.001% of 100 million a year is a hundred THOUSAND units a year, which is absolutely insanely large, and could well represent the entire profit margin for that year. mass-volume is radically different).

you cannot possibly expect, with those kinds of numbers, that people will be capable of compiling their own kernels etc. etc. or even that they are capable of installing a new OS. they want something that "just works". if it don't work, they'll return it (or discard it).

I don't expect the average consumer to compile any software. If you allowed housings to be bootable, (via sd card for example), a manufacturer can supply a sd card with the device and provide their own update channel.

as noted further down: this scenario was discussed a few years ago and discarded as completely unworkable. how would you:

* ensure that a MIPS-based Card was capable of booting from media in someone *else's* Housing * ensure that a RISCV-based Card or an FPGA Card was likewise capable of booting from the same media * how can the Card Manufacturer even know that there's going to *be* an SD Card slot?

these and many more scenarios make it flat-out impossible to make any kinds of "Lowest Common Denominator" assessments.... or more to the point: the "Lowest Common Denominator" is *literally* the "Empty Set". i.e. there *are* no common boot methods from Housings. period.

...

anyone who is plugging in (for example) an EOMA68-A20 into a (for example) router Housing is probably the kind of expert who knows what they're doing. if they're even *remotely* contemplating that kind of re-purposing / mixing-and-matching (and are the first or one of the first to consider doing it) i think it's safe to assume that they would be capable of customising (or entirely replacing) the OS with one that is more suited to the job of "being a router" as opposed to "being a desktop OS".

If an average consumer buys a housing that claims it is a router and plugs in their old A20 cpu card (that contains a pre-installed desktop style OS) the hardware may be configured correctly per the dtb, but they surely won't be happy when they find out they need to setup a firewall, dhcp server, etc, etc, and much much more.

the fact that they took a CPU Card with a *desktop* OS is the clue here. if they did that, they should expect to have "a set of desktop functions". i did answer this above. they have two choices:

(a) go get a router OS for that CPU Card (this is not unreasonable under the circumstances) (b) go install the software required (this is not unreasonable under the circumstances)

The definition of "plug it in and it works" here is sketchy at best.

yes. accepted. i answered (and you didn't acknowledge) that i would consider it reasonable that someone who mixes and matches in this way would likely be a "re-purposing" individual, sufficiently technically aware to fall into either category (a) or category (b).

if they do *not* consider it "reasonable" then i would say... mmm.... tough. we can't do everything.

IMO, "works" means, works as a router like the housing packaging said it would, and I expect most consumers would think the same. Now, average consumer tosses cpu card and housing in the trash and never buys EOMA again because it didn't *just work*.

if they did that, it's their choice. we can't stop everybody from being irresponsible: we can't stop everybody from making decisions without first getting on the internet and checking "why doesn't this work, does anyone have any advice".

however in these circumstances, these are "not normal". someone buys a desktop OS and a desktop Housing, they're Certified by the retailer to work. if they then buy a 3rd party Router Housing and try plugging it in, guess what? they're outside of mainstream aren't they? i would expect such people not to be complete idiots. they experimented. i would expect them to be capable of being curious about the results. or, to just put the CPU Card back into the Desktop Housing.

now, if they bought both devices *second hand*, i would *also* expect such people to have done a little bit of research in advance, and to have some common sense.

therefore, the actual number of people who are complete idiots, throwing away perfectly good hardware with very little actual thought and analysis, i would actually expect to be qute small.

however if there was a fuckwit *RETAILER* who sold a router housing and a desktop OS computer card and told the customer "yeah yeah it'll work fine", NOW i have a problem with that, and i will be going after the seller aggressively because then the RETAILER is genuinely bringing EOMA68 into disrepute. actually, the seller (being a total idiot) would have to accept the items back under warranty (due to the seller's own ignorance).

hmmm, good point. need to make sure that there's proper training for retailers and that they understand the consequences of misinforming their customers.

Consumers should expect some kind of setup for any new hardware, especially a networking appliance, but asking them to install and properly configure a router OS is preposterous.

if the products were mis-sold... YES.

if the products were bought 2nd-hand... NO

if the products were bought from different 3rd parties... NO. you don't go complaining to Microsoft if the HP printer doesn't work, do you?

If you allow a provision for housings to boot, the router housing manufacturer can provide a suitable OS (eg openwrt) and average consumer can be happy.

no, it can't. that forces the OS to be pre-compiled for a totally unidentified CPU. how can you KNOW what CPUs will be placed into EOMA68 Card form-factor in the future? how can you pre-compile openwrt for a processor that hasn't even been invented yet?

it's simply impossible.

...

...

Can you just require all source code and shipped binaries be available before compliance is approved?

in light of the above, the question may need to be reworded / rethought. just as the Bill of Ethics points out: entropy will require to be continuously overcome in order to achieve [continuous] compliance. it's not a one-off "fire-and-forget" process.

Here's a totally different question instead :) Let's say someone makes a non-compliant housing and wants to market it to tech minded folk who can handle installing their own bootloader/kernel. Will it be legal to market it as non-compliant and use the EOMA name?

NO. i cannot take the risk that someone gets killed or badly injured due to an electrical fire caused by non-compliance. if during an investigation where someone is killed, i would end up being accused (and quite probably convicted) of manslaughter.

the answer is therefore an unequivocable and non-negotiable NO.

that said: the use of the word "legal" is misleading. you should be using the word "permitted".

now, given that you now know this (and see below as well), if you were to blatantly *ignore* what i said (which is "NO") and went ahead anyway, *then* it would most definitely NOT be legal, and you would be liable for prosecution (both civil and criminal).

"This housing accepts EOMA cpu cards but is non-compliant with the official specifications" or some such warning?

NO. the risk is too great that without a proper test in a safe environment that the 3rd party Housing would not cause irreversible damage to people's Cards. even just doing the testing could result in a short-circuit and cause a fire (due to a design fault in the Housing).

this isn't "just software", and it's not a "desktop PC" or a hermetically-sealed unit.

some of these housings will take 20 watts or contain Lithium Batteries. 20 watts is more than enough to cause an electrical fire, and a Lithium Battery if overheated or otherwise mistreated could explode.

even if it was pure software, certain types of budget smartphones are actually incredibly dangerous. one such phone is a low-cost HTC WINCE phone from about 10 years ago. during the reverse-engineering we discovered that the GSM Radio Power Level was software-programmed from shared memory between the DSP and the WINCE OS. bear in mind that WINCE has absolutely *no* memory protection (no virtual memory whatsoever), it was literally possible for any application to set the GSM Radio Power Level to sufficiently dangerously high levels that it could cause the (very small) phone to overheat.

whilst this example is extremely rare (and very stupid of HTC to have done such cost-cutting exercises) it illustrates that messing about with hardware is nothing like as straightforward as our Desktop PCs and Laptops would have us believe. people who work on CoreBoot (and other direct-to-the-hardware style programming) will be able to tell you any number of stories where they've damaged or blown up hardware by programming it incorrectly at such a low level.

we need to recognise that and, accordingly, act RESPONSIBLY.

l.

btw joseph, could you please use a mailer that doesn't place entire paragraphs onto a single line? the general rule for mailing lists is to have line-breaks approximately every 70 chars or so. usually this can be achieved by ensuring that you reply "plaintext" mode only, disabling "rich text" for replies.

On Fri, Sep 23, 2016 at 4:41 PM, Joseph Honold mozzwald@gmail.com wrote:

...

the fact that you now actually want to know means that it's time to actually thrash it out and document it properly.

Yes, this should be documented. More on this at the end.

ack.

...

to even consider doing anything else would *automatically* bring the standard into disrepute (even before it got off the ground).

Sure, it's probably not the best idea to use stickers. But I have a another idea. You continue to have the restrictive EOMA specification but create a separate permissive specification that utilizes the EOMA spec as a basis. Call it something significantly different and not likely to be confused, maybe PEMA (Permissive Embedded Modular Architecture). These two specs would be compatible on a hardware level (and retain the free/libre software requirement) with other certain restrictions removed (eg, the bootable housing restriction). I can sell my bootable housing as compatible with the PEMA spec.

unfortunately that doesn't work, because of the following scenario:

* someone buys an EOMA68 Housing * they also buy an EOMA68 Card * they are happy (because it "Just Works") * they then get sold something which is sold to them as an "Upgrade" EOMA68 Card * it fits into the slot. * but it doesn't work

after a LOT of trouble, and annoyance, and a very very public and embarrassing fight on a forum, where various "Consumer Watchdog Groups" get involved, which is then picked up by the BBC, *and* the Guardian newspaper, *and* TheRegister *and* slashdot (all of which generates MASSIVE confusion thus bringing EOMA68 into total disrepute as a "Just Plug It In, It Will Work" standard)...

... after all that, it turns out that it was some fuckwit china 3rd party clone who took a PEMA card and deliberately mis-sold it as EOMA68-compliant.

the answer's no. sorry.

...

these and many more scenarios make it flat-out impossible to make any kinds of "Lowest Common Denominator" assessments.... or more to the point: the "Lowest Common Denominator" is *literally* the "Empty Set". i.e. there *are* no common boot methods from Housings. period.

I still don't think the idea of *allowing* (not requiring) housings to be bootable is unworkable.

oh. allowing? of course not. that's perfectly reasonable. but remember: the EOMA68 standard is based exclusively around *mandatory* requirements. i've told the story several times now from my university professor's *two* separate experiences with standards that were lost golden opportunities, thanks to "optional-itis" - one of those was the X.25 standard.

The "lowest common denominator" here is the USB bus

ah! no it's not! there is no guarantee that Housings *require* USB peripherals at all. thus the idea must remain "allowed" rather than "mandatory as part of the spec"

and SD/MMC bus on the EOMA68 connector which *IS REQUIRED* as per the spec

yeeeees....

and *could* contain bootable media.

wark-wark. the keyword here is "could". it could also not have any connection at all, or it could be used for GPIO, or it could be used for connecting to SD/MMC-based WIFI..

you just don't know (because that's down to the Housing Implementers) and that's why booting from Housing-based media must remain "allowed" rather than "mandatory as part of the spec".

This means, if a housing chooses to implement the SD card, it *might* be bootable media.

yep. that's why booting from housing-based media has to be "allowed" (i.e. "not prohibited"), but not "mandatory". but (re-reading what you mention below), if it is added to the spec that it is optional to sell Cards which *always* look for external boot media on Housings and will *FAIL* if that media is not present, that is NOT okay.

so it has to be something that the end-user chooses for their own convenience, rather than being something that is RELIED on.

Let's switch to the Pocket QWERTY Computer as an example instead of router. The A20 cpu card ships with Parabola, a desktop/workstation style OS. I want my customers to have a good experience when they use my handheld housing. Using an OS tailored for desktop/workstation computing is *not* a good experience on a small screen (I've tried this with the Zipit and it "worked", but was not very productive). I can make this transition even *easier* for average consumer by supplying a SD card with Replicant or some other custom libre distribution designed for small screens.

or, you could supply multiple OS SD cards for them, and set up the NAND to look an OS on the A20's MicroSD Card slot.

yes, i'm keenly aware that the alteration of the OS to suit LCD size is a Big Deal. putting it another way: it's a PAIN IN THE ASS! :)

it's made even more complicated (for the A20) by the fact that the people who did the sunxi u-boot and mainline kernel didn't think about this in advance: they've specified that the LCD shall be set up by u-boot and u-boot alone, leaving absolutely no possibility for changing the LCD size without a total reboot! oops...

I could partition the SD card and put any number of distributions on there with a boot menu. This way, they do not need to fuss with installing an OS to the cpu card NAND that works *well* with the housing. When next years latest and greatest cpu card comes out, I can get a beta version of the cpu card, produce an OS that works with my handheld and publish it on my website for free download before the new cpu card ships to customers. I could sell SD cards for cost+shipping with pre-installed OS for the new cpu card if the customer doesn't want to bother making an SD card. Easy-peasy for average consumer. Files on the cpu card NAND can be accessed easily via mounting so you still have access to all your data.

yyep. all perfectly reasonable.... and nothing to do with the spec... but if the Card is incapable of booting *unless* that external media is present, that's unacceptable.

The A20 card has a micro sd slot. Is booting from this allowed in the spec?

anything at the other end of the card - user-facing - is permitted. there are absolutely no restrictions (other than anything protruding must not physically impinge on the ability to insert the card into Housings).

so of course it's permitted: it's part of the Card. it travels *with* the Card.

now, the key difference here between booting from Housing-based media and Card-based media is: the Card-based media (removable or not) stays *with* the Card. it thus *guarantees* that the Card will boot.

What if the next CPU card does not have an SD slot (it's not required by the spec)?

now you're into "cheap-ass" territory. people who pay cheap-ass money for cheap-ass goods can expect to "get what they pay for". given that we're talking saving $0.20 for a lack of a micro-sd card slot, you know we're talking *real* cheap-ass money-misers :)

no, if manufacturers are saving $0.20 you know that they're probably trying to produce something for the $12 to $15 retail market. all bets are off as to "features" at that point.

basically at this level of cheap-ass-ness as long as they're compliant with the "bare minimum" EOMA68 spec i'll tolerate it.

Now average consumer is forced to install a different OS to internal NAND if they want a *useful* device.

or, because it was so utterly cheap-ass they just buy another $12 to $15 Card with a handily pre-installed OS. so in these circumstances, end-users would, instead of buying a replacement MicroSD card, would just treat the ENTIRE CARD as being "A Computing Appliance".

buying one that has Android preinstalled ($12) and another with Games preinstalled ($12) - heck you could even have completely different Games Cards just like you had or have Cartridges (Nintendo, Gameboy) - is perfectly reasonable.

What happens if average consumer installs handheld OS to their A20 card NAND, plugs it into their laptop or desktop? Handheld OS for a workstation doesn't seem very *useful*.

i don't see why that has to be considered to be absolutely true. i hear people complaining "i'm using my phone but the screen's too small" - would it not be incredibly convenient to just temporarily pop out the Computer Card and pop it into a Housing with a larger screen, even for five minutes, just to view a document properly?

My suggestion here is to make a housing "just work" as the *housing* is intended. If my housing doesn't work as intended when the cpu card is plugged in, it puts my company *and* the standard into disrepute.

you can always sell multiple OS cards and have end-users swap them over. in a few years time i envisage that we will have other methods to deal with this, starting most likely with VMs / OSes that are selected at boot time (exactly as you describe), and moving to adaptation at the OS level later (including icon size, menus and so on).

certainly i know that KDE is capable of adapting applications dynamically, by way of simply specifying a different "spec" file. applications can therefore *dynamically* adapt to screen size or other features (such as touchscreen / mouse).

this *really* is still at the very early phases, but it really *has* been thought out. the last discussions on this "OS adaptation" were something like three years ago, though.

...

hmmm, good point. need to make sure that there's proper training for retailers and that they understand the consequences of misinforming their customers.

Here, you are defining "desktop OS computer card" which isn't defined anywhere in the spec. I see no claims in the spec that there is such a thing as a desktop computer card, router computer card, phone computer card, etc etc.

that's correct.

With your claim of “just plug it in: it will work”, the retailer would be justified selling a *ANY* cpu card and *ANY* housing together and expect it to work. Is it the right thing to do? No.

no. retailers can only be directly involved once the OSes have been adapted to cope with the variation. that might take a few years: i can live with that.

as long as it does not bring the standard into disrepute in the process, i *might* permit a *limited* retail sale of say products where the CPU Card is preinstalled in the Housing, or where the LCD size is sufficiently similar between two Housings so that the difference is effectively immaterial (say, a 1366x768 LCD screen size for a Laptop and a 1280x800 for a tablet - something like that).

remember, the primary purpose here is to ensure that the units on both sides don't end up in landfill. if that's likely to happen, i'd rather the units weren't sold AT ALL (until they and the OSes *are* ready).

this is the difference between this project and a standard commercial profit-maximising outfit. a standard profit-maximising commercial outfit would rush ahead and get things out the door as soon as they could.

If you sell me a cpu card and a housing with the claim that “just plug it in: it will work”, it should work as intended as a complete package. If I have an old cpu card collecting dust, I should be able to use it under the claim “just plug it in: it will work.”

within reason... and within the expected cost, yes. in the 2nd-hand market and "recycling / re-use" market, i expect there to at least be *one* technically-competent person who makes the necessary phase-change adjustments before selling/handing the item(s) over to the next non-technical end-users who will expect that claim to be true.

Allowing the housing manufacturer the *option* to boot from media can assist in fulfilling this claim.

*thinks*.... the moment i hear the word "option", that is an instant red flag. options are what destroy standards. i spent five years analysing a range of standards, and 25 years ago it was deeply impressed onto me through the example of X.25 quite how dangerous "options" are.

so, to reiterate above: if the Card will *not function* unless that external media expected to be on a Housing is discovered, that is completely unacceptable.

now, on the other hand, if there is at least some level of functionality (whether it be Lowest Common Denominator or something) then that *might* be tolerable. if there is a "Download A Full OS" button, that also might be tolerable.

it's complex, basically, and would need careful evaluation on a case-by-case basis.

Mr. Salesman can have a rack of SD cards to sell to average consumer and provide a free or paid service of installing the OS on the card for them. Or, average consumer can use my nifty cross platform free/libre SD Card Imaging program to download and install the correct OS for them. Easy-peasy, nowhere near impossible.

yes. these can go into the main MicroSD slot actually on the Card. bit of a pain that they have to be for a particular CPU, so it would probably make more sense (given the low cost of the Computer Cards themselves) to just sell the OS preinstalled (an Android EOMA68-A20, a ChromeOS EOMA6-A20, a GNU/Linux Distro EOMA68-A20 etc etc. blah blah) but there you go.

Again, my issue here is the misleading/lofty claim of “just plug it in: it will work.”

no, that's the *goal*. you've misunderstood. it's the *goal* that that claim be true. remember, we're still working this out! so, you're helping to refine what is and is not permitted.

but everything gets "judged", "does the claim still hold?" if the answer is "yes" then it's okay. if the answer is "no" then, clearly we either wait until more work (on OSes for example) has been done, or we just have to live with it.

The way I understand it after your explanations this phrase should be "just plug it in: it will work, but if you want it to be useful you'll need to install and configure software yourself" which is completely against the idea of the project.

if there's a techically-literate person in the loop / scenario, i find that to be perfectly acceptable.

The use of this phrase needs to be rethought and/or reworded. Since ethics is a hot topic on the mailing list these days :) ... it's unethical to claim “just plug it in: it will work” when the housing doesn't work as intended. Sure, it will boot and be some sort of Frankenstein device, but it's not a useful device.

Let's try a silly example. I sell you a Harley Davidson Motorcycle (without an engine installed) and I sell you a separate lawnmower engine that fits perfectly into in that motorcycle. I tell you "just plug it in and it works." You go home, plug in the engine, strap on your helmet, start your engine and ... you ride free on the open road at a whopping 1 mph. Sure, it works, but it's not a good experience. Obviously, this example isn't very good in relation to EOMA and software, but it makes the point of customer dissatisfaction when the claim is "just plug it in and it works".

well if you look more carefully you'll see that i actually qualified this a number of times over the years (bear in mind that you're new to the conversation so won't have seen this) with the (sotto voice) of the more honest salesman, "But You Get What You Pay For, Know What I Mean".

if people pay $12 for a Computer Card, they Get What They Pay For.

normally this was in the context of people paying for Cards with USB 1.1 interfaces instead of USB 2.0 interfaces, but the same rule applies: if you pay only $12 retail for a Computer Card where the processor is a single-core MIPS 1ghz (or less), you cannot expect it to perform miracles.

...

some of these housings will take 20 watts or contain Lithium Batteries. 20 watts is more than enough to cause an electrical fire, and a Lithium Battery if overheated or otherwise mistreated could explode.

Understood. And this leads me to the specification which, if documented properly, would reduce the likely hood of an incident.

actually, we've already had some 3rd party implementers fail to listen, implementing *hardware* that did not comply to the specification. they also tried to take control of the EOMA68 Standard by making public statements without consultation and without authorisation. i had to publicly reprimand them and make it absolutely clear - publicly - that they were acting in a completely unauthorised fashion and were not permitted to make further statements or claims.

so no: even from this one incident, we know *already* that people can and will fail to read the specification properly. a Compliance Test is therefore absolutely critical.

At a minimum, there needs to be some sort of *disclaimer* / *notation* / *message* at the top of the EOMA specification page that indicates it is a "work in progress" and possibly point to a section (at the bottom/separate page?) with all of the unwritten/unfinished requirements/proposals/ideas.

good idea. just have to find time to do that :)

I was under the impression that the standard was mostly complete

the hardware side is.... but it's a really complex project, and it's still at an early phase. this current phase is where, with the hardware in place, the software can begin to be created.

we had to *have* hardware in order for there to *be* the opportunity to get the software ready... so that's next.

and only after the fact, this information is coming to light (my fault for lack of due diligence in research and asking questions). I understand you've been working on this for a long time and *you* have this all worked out in your head, but I (and likely others) surely don't. If I had known how restrictive the specification is going to be, I would have thought much harder about using EOMA for a project/product. I obviously misunderstood how far along the project is. Perhaps the roadmap you mentioned previously would help.

apologies - i haven't had time to write one. this is one of the down-sides of there not being enough other people involved. expecting other people to be committed for five years without payment of any kind and without hope of financial renumeration for potenially several more is a bit too much... so all the people that *were* expecting to financially exploit this project (and jeapordise it in the process) have all left (some of them are still causing huge problems, but that's another story).

Based on the specification on the elinux.org wiki, I had plans/ideas which now need to be completely changed to support restrictions that are nowhere to be found (not easily anyway).

review what i said above about being able to boot from removable media actually on the Card itself: i think you'll find (after evaluating that) that the perceived restrictions are incorrect / unjustified / insert-suitable-word-here.

It's quite frustrating to hear "you can't do that" time and again. My impressions of the specification based on the information readily available are clearly incorrect. I see it more as a hardware spec with the additional requirement of free/libre software being provided/available. That's my interpretation and is obviously incorrect.

yes. this is a mass-volume standard that *happens* to have libre software as a preference (where closed / proprietary software is tolerated under certain strict circumstances).

I understand the basis for your restrictions against booting from a housing, it just doesn't seem like a good idea to me and isn't very free/libre, IMO.

anybody is perfectly at liberty to completely ignore the EOMA68 standard (from a software perspective) - in doing so they are NOT permitted to call it "EOMA68 compliant", that's all.

manuel's team (with the hand-held games console) will be choosing this route. they will simply be using the EOMA68-A20 as a "module".

if you recall, i brought this up on the OSHWA mailing list a month or so ago. there is a naive expectation that the Four Freedoms may be applied to create a Hardware Compliance Standard without further adaptation or taking into consideration the consequences:. that simply isn't true.

so we have the scenario where the OSHWA creators have failed to add a disclaimer or add any indications that someone who puts an OSHWA "sticker" on a product is not liable for any damages, and that the person doing so is simply blithely permitted to put that sticker on, regardless of the fitness for purpose *of* that hardware, thus bringing the *ENTIRE* OSHWA Certification process into disrepute and exposing its writers to massive liability!

they seem to have ignored my advice and warnings about this, but the fact that i have mentioned it discharges my obligation to them...

the fact is that we simply cannot just naively create hardware standards - even Open ones - and expect that the Four Freedoms will be sufficient or adequate safeguards all on their own.

If you make it easier for manufacturers to provide a good user experience, then the customer is happy and will use it longer.

deployment to retail *WILL* be delayed indefinitely until that statement becomes true.

Don't get me wrong, I still think the idea is good and has good intentions. I'm happy to support it. I'm just pointing out issues I see to hopefully make it better.

appreciated.

so. summary:

(1) use the A20's on-board SD card slot. you'll be able to do what you're expecting (deploy multiple OSes) (2) don't worry about cheap-ass Cards. people Get What They Pay For. (3) technical users are expected to be involved in transforming / repurposing 2nd-hand cards (4) "Just Plug It In, It Will Work" is qualified by sotto-voice "But You Get What You Pay For" (5) Hardware's ready so that software can be worked on (6) Four Freedoms cannot be deployed as-is to Hardware Standards. (7) Retail deployment is DEFERRED INDEFINITELY until such time as the expected outcome is true. NOT the other way round.

errr... i think that's it. let me know if (1) works for you. i think it should.

l.

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

On Sat, Sep 24, 2016 at 10:42 PM, Louis Pearson desttinghimgame@gmail.com wrote:

On Fri, Sep 23, 2016 at 9:27 PM Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

...

...

What if the next CPU card does not have an SD slot (it's not required by the spec)?

now you're into "cheap-ass" territory. people who pay cheap-ass money for cheap-ass goods can expect to "get what they pay for". given that we're talking saving $0.20 for a lack of a micro-sd card slot, you know we're talking *real* cheap-ass money-misers :)

no, if manufacturers are saving $0.20 you know that they're probably trying to produce something for the $12 to $15 retail market. all bets are off as to "features" at that point.

basically at this level of cheap-ass-ness as long as they're compliant with the "bare minimum" EOMA68 spec i'll tolerate it.

I'd like to bring up the point that lacking a micro-sd card slot may not have to do with cheapness, but physical limitations. What if there is no room for it because other connectors / doohickeys were considered more important for the specific card?

then you can get a top-loading or side-loading set of PCMCIA casework made up, and (if top-loading) use one of the top-loading MicroSD card holders that you get for mobile phones.

very simple solution. investigated this 4 years ago.

l.

On Sun, Sep 25, 2016 at 5:11 PM, Joseph Honold mozzwald@gmail.com wrote:

On 09/23/2016 10:27 PM, Luke Kenneth Casson Leighton wrote:

...

btw joseph, could you please use a mailer that doesn't place entire paragraphs onto a single line? the general rule for mailing lists is to have line-breaks approximately every 70 chars or so. usually this can be achieved by ensuring that you reply "plaintext" mode only, disabling "rich text" for replies.

Sorry, hopefully this is better.

looks great. may not be "perfect" but the mailing list software (mailman) clearly copes and handles the required conversion, which is what really matters in the end.

...

yep. that's why booting from housing-based media has to be "allowed" (i.e. "not prohibited"), but not "mandatory". but (re-reading what you mention below), if it is added to the spec that it is optional to sell Cards which *always* look for external boot media on Housings and will *FAIL* if that media is not present, that is NOT okay.

so it has to be something that the end-user chooses for their own convenience, rather than being something that is RELIED on.

I re-read the spec regarding SD/MMC and see it is not required by housings and could be GPIO instead. My mistake. USB though, is required for all cpu cards and therefore is *available* to all housings.

available yes: guaranteed to be present, no.

for example on the breakout board (the most extreme case), they're *clearly* not present: nothing is (strictly speaking even the I2C EEPROM is not present because the breakout board is really just a component not an actual Housing, but you get my point).

imagine for example that "blind / sighted" design. is there even any *need* for USB ports or any internal USB devices *at all*? i can't think of a single reason why the USB ports should even be connected. not even the LCD need be connected on that. all you need is to use some of the buttons as GPIO, to have a capacitive panel (maybe!) via I2C... err.... that's it.

where is there even a *requirement* that the USB wires even be *connected*?

should we FORCE the blind/sighted design to have a USB port, when the casework may not even have space to fit one? no, of course not, that's completely unacceptable!

another example: a tablet which uses up all the USB ports for internal peripherals. USB port 1 is connected to a camera USB port 2 is connected to an Audio IC.

... where's the USB storage in that example?

... where's the external USB port to plug *in* USB storage?

should we FORCE the tablet, as part of the EOMA68 Specification, to REQUIRE a USB port or to REQUIRE USB storage? no, of course not, that's completely unacceptable!

so this is why it must not be "expected" that the Housing *always* have USB storage attached (to either of its two USB ports).

as you cannot rely on USB being present, so in turn you cannot have Cards that fail to boot if USB is not present.

u-boot can be configured to scan the USB bus for storage media, even if that bus is not connected in the housing. If storage device found, attempt to load uboot script from a defined location on that device. If uboot script found, load and run it, else, boot from cpu card.

Simple if/then/else.

indeed. perfectly acceptable... but not guaranteed to be the case. so, it has to be a "MAY", or a "is permitted" as opposed to being a "MUST".

Also, since you are checking the eeprom device id in u-boot, it could be possible to check the dtb for sd card nodes and optionally boot like above (if/then/else).

exactly. optional... but still cannot be relied on as being "absolutely guraranteed"

...

...

I could partition the SD card and put any number of distributions on there with a boot menu. This way, they do not need to fuss with installing an OS to the cpu card NAND that works *well* with the housing. When next years latest and greatest cpu card comes out, I can get a beta version of the cpu card, produce an OS that works with my handheld and publish it on my website for free download before the new cpu card ships to customers. I could sell SD cards for cost+shipping with pre-installed OS for the new cpu card if the customer doesn't want to bother making an SD card. Easy-peasy for average consumer. Files on the cpu card NAND can be accessed easily via mounting so you still have access to all your data.

yyep. all perfectly reasonable.... and nothing to do with the spec... but if the Card is incapable of booting *unless* that external media is present, that's unacceptable.

No, it's not part of the spec, just trying to make a point that it can be easier for the housing manufacturer to customize the experience if housing boot is available.

indeed it can.... but they should not *expect* it to be there. in other words the spec has to be something like,

"if the housing happens to have externally-discovered bootable media it is PERMITTED to use it, but the MAIN functionality MUST not rely on that".

I'm not advocating for the cpu card to not boot if media is not available in the housing. It's a simple if/then/else statement; else being "boot whatever is on the cpu card".

exactly. that's perfectly acceptable.

We should not assume the cpu card will have an sd card if it's not required.

mmm.... too many "nots" for me to process that :)

...

...

Mr. Salesman can have a rack of SD cards to sell to average consumer and provide a free or paid service of installing the OS on the card for them. Or, average consumer can use my nifty cross platform free/libre SD Card Imaging program to download and install the correct OS for them. Easy-peasy, nowhere near impossible.

yes. these can go into the main MicroSD slot actually on the Card. bit of a pain that they have to be for a particular CPU, so it would probably make more sense (given the low cost of the Computer Cards themselves) to just sell the OS preinstalled (an Android EOMA68-A20, a ChromeOS EOMA6-A20, a GNU/Linux Distro EOMA68-A20 etc etc. blah blah) but there you go.

Hmm, with that kind of thinking, I can see people just tossing the old card in the trash because it's so "cheap".

we can't totally control the way that people think or act, we can only consider putting in place incentives.

The seller should proactively attempt to buy back or accept for donation the old cards if customer isn't going to use the old one.

yes. or, just encourage them to put them on ebay. and/or reach out to recycling companies and say, "hey guys if you get any of THESE we'll take 'em!"

"Cheap" also depends on who you are. I see EOMA being deployed in low/no income areas of the world where the user may have little to no experience with computers. I understand that someone would likely be available to assist in a situation like this (missionaries, non-profits and the like).

exactly.

Housing boot could make it easier to deploy and still call it EOMA compliant.

sorry: whilst it would _be_ easier, it's simply not possible. in the scenario that you give, the low-cost may even have been achieved by removing things like USB connectors and saving $4 by not including internal USB storage in the Housing.

the Card really does have to be stand-alone capable of booting.

now, in the case of the EOMA68-!C1t prototype, this was actually a good example. the 176-pin QFT IC1t processor only has (had) one available boot option: eMMC / MicroSD. as in: the only other SD/MMC interface had to go to the EOMA68 connector.

in this case, there were simply not enough pins to put in an additional NAND IC, nor was there a 3rd SD/MMC.

so in this case, i simply made the user-facing MMC *THE* boot media. the Card booted SOLELY AND EXCLUSIVELY from the (one remaining) SD/MMC interface.

now, this has the side-effect that it is *always* going to be possible to replace the OS, simply by preparing a replacement OS MicroSD Card.

so even in the case of SoCs that are as little as $2 around which $12-$15 Cards can be built, it's *NOT* as bad as it appears on the surface...

... thus mitigating against the need to make "housing boot" a mandatory requirement whilst claiming EOMA68 compliance.

think through the implications, joseph. if you say "this device is EOMA68 compliant even though it will only boot from Housings", you have to then think through the implications of what might happen if people in the 1st world go "oo! that's amazing! i'll buy 1 million of those, thank you!"

that then makes its way out into the world, fast becoming the dominant "novelty toy"... which people in the 1st world start to try to use in Housings which *have no USB storage*...

aaaaand you're f*****d.

...

anybody is perfectly at liberty to completely ignore the EOMA68 standard (from a software perspective) - in doing so they are NOT permitted to call it "EOMA68 compliant", that's all.

manuel's team (with the hand-held games console) will be choosing this route. they will simply be using the EOMA68-A20 as a "module".

So, in this case, is he allowed to use the "EOMA" name anywhere regarding his product?

strictly... no.

I see his site calls it "ZEOMA" and states "ZEOMA is based on the EOMA-68 concept." Based on our discussion I am under the impression that this would not be allowed.

my understanding is: "based on" is about the closest you can get away with, i believe, in the Trademark world, without being in clear and blatant violation of the Trademark.

He is not calling it "EOMA Compliant" but is creating the connection from his device to the EOMA standard which could be confused with compliance.

yeah. i'll have to have a word with their team.

...

so. summary:

(1) use the A20's on-board SD card slot. you'll be able to do what you're expecting (deploy multiple OSes) (2) don't worry about cheap-ass Cards. people Get What They Pay For. (3) technical users are expected to be involved in transforming / repurposing 2nd-hand cards (4) "Just Plug It In, It Will Work" is qualified by sotto-voice "But You Get What You Pay For" (5) Hardware's ready so that software can be worked on (6) Four Freedoms cannot be deployed as-is to Hardware Standards. (7) Retail deployment is DEFERRED INDEFINITELY until such time as the expected outcome is true. NOT the other way round.

whoops how did this lot get lumped together as a single block of text??

...

errr... i think that's it. let me know if (1) works for you. i think it should.

(1) is okay with me if the cpu card sd slot is *required* by the spec,

no it's not *required*... it just so happens that most manufacturers who *don't* provide it will find that people get a bit arsey.

otherwise there is no *guarantee* that the sd card slot exists on the cpu card.

correct... but remember, FPGA-based EOMA68 Cards and Pass-through Cards are permitted as part of the spec (yes, Pass-through Cards are a special case).

and, people may actually wish to make special "promotion" or "secure" Cards. secure cards (such as those which could contain an RFID key-entry IC) should *NOT* have an sd card slot as it would clearly be a security risk.

these would therefore have to be dealt with on a case-by-case basis, applying for examptions to the otherwise-general rules.

Anyway, I'm not going to push the issue anymore as I think I've made my point and you've made yours. I hope you consider the option viable if it ever comes up again.

i'll make a start on the "Software / OS" section, i'm going to divide it down into separate roles (Manufacturer, Retailer, Recycler, Technical End-User, Non-Technical End-User).

it's actually hellishly complex which is why i haven't outlined it before.

Still, all this won't help me get the SSD2828 working which spawned the debate since it currently requires mainline u-boot/kernel. Looks like I just need to find/write a linux driver for it :)

i know. all a bit of a pain, but that's software, and it's why we haven't gone to "FULL ON RETAIL PRODUCTION MODE".

btw remember that mainline u-boot / kernel *does* actually work... with the Revision 2.2 EOMA68-A20 Cards it just only works for about 90 to 300 seconds and i haven't been able to track down why.

there's clearly a bug somewhere around 4.0rc5 to 4.0rc6 which, if found, fixed, and patched, would make mainline perfectly acceptable for ongoing usage (with the EOMA68-A20).

also please always always remember, jospeh: the EOMA68-A20 Card is just the first in the series. the next one (whatever it is) will most likely work straight out-of-the-box with mainline as it could be based around a processor that's modern and up-to-date... or current.

one based around the Freescale iMX6 for example would work straight away (because the iMX6 has a 19 year lifecycle so has a strong committment from Freescale to keep it up-to-date).

l.

http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Software#Libre_S...

haaaaa maaan, ok moved this to a separate page, i'd particularly appreciate some input / feedback / perspectives on this section, as it's more of an opportunity to explain why people who are considering getting involved with EOMA68 are having some serious conceptual difficulties.

if you recall the discussion (or just the length of the discussion) on the "code of conduct" thread, that is a classic example.

l.

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

On Fri, Sep 30, 2016 at 12:06 AM, Joseph Honold mozzwald@gmail.com wrote:

On 09/26/2016 03:39 AM, Luke Kenneth Casson Leighton wrote:

...

*deep breath*.... ok so i've been writing non-stop since i previously replied, and can only reasonably say to be 15% through what's needed (!)

http://elinux.org/Embedded_Open_Modular_Architecture/EOMA68#EOMA68_Software_...

l.

This helps to understand more about the project goals. Thanks. I've read thru it a couple times already and yeah, it's a lot to grasp :)

if i'm absolutely honest i can't quite believe it myself. sure, i defined the goal, and was even aware of the intended scope... but actually then walking through every possible permutation of every potential disruption and otherwise-accepted industry practice for each and every role... faaaaaakin eeeelll :)

at least you didn't go (as i would expect many mass-volume manufacturers to do), "wtf??? whaddyamean i can't use a locked 3G modem in these products??? whaddyamean i have to go to the extra expense of putting in a socket so that people can easily replace the WIFI, and whaddyamean i can't use the industry-standard practice of DRM-locking the WIFI's id to the BIOS because that's how we GET OUR MAAAOONEYYYYYY by f*****g people over when it comes to upgraddiiing and they have to come to uuuus to buy overpriced WIFI cards, waaaa, waaaa, i wannt my moommmeeeyyyy you're being soo unfaaaaair, waaaa, waaaa"

ahem. sorry about that :) i thought really overdoing it would make the point better. it has to be said though that there are some of these kinds of "wtf??" moments even for libre pcb designers. a way to get across how "free/libre" does NOT mean "free to do what you like with blatant disregard for consequences" is the "Bad USB" attacks.

if this was "USB" we were talking about, instead of EOMA68, how would you see a product that did the exact same thing as the new "Bad USB" devices would be viewed, even if the schematics and PCB CAD files were made available under a libre license? (for those people not familiar with "Bad USB", they basically use the 5.0v socket to charge up internal capacitors, then use that to release massive 240+ volt AC power spikes down both the power lines and the USB signal lines).

would it be *okay* for someone to "claim that that is USB compliant???" is it even okay that they use the word "USB" in the phrase "Bad USB" [serious question].

whilst we might argue that the above example is "clearly not intended to be compliant with USB", what about the failure of cable manufacturers recently to comply with the power specification of USB 3, recently? those are clearly *intended* to be compliant with the power specification, but they are failing to put in the right resistors to indicate what current is permitted to be carried, and/or they are failing to utilise wires that are of sufficient thickness, and/or they are simply not designing the connectors and/or PCB layout correctly in order to handle that kind of current.

should we say with hindsight that this is a failure of the 3rd party manufacturers, or is it the failure of the USB Association, or is it both?

I'm going to make what I want for myself now and see how it pans out in regards to compliance, keeping in mind what's in the spec already.

it's the hardware side (the pinouts) that have had the most attention, obviously (like i said) creating the hardware itself is the first priority: that's why this campaign was done, duh, to get actual hardware out to people (get over that all too common "vapourware" barrier, you know what i mean?)

It will be a functional prototype for personal use. If down the road, others show interest then I'll deal with any changes that need to be made.

if you're happy to work in public - i.e. release what you are doing *all the time* as opposed to "i'll release it when i'm done, because i'm scared that people might criticise what i'm doing or copy it and not collaborate" - then two very important things happen:

(1) we can review the situation easily, and can clarify the relevant role "Libre Engineer" in the EOMA68 specification as it goes along

(2) we can invite other people to collaborate. already i am trying to encourage the hand-held games console team to get in touch again (perhaps set up a separate mailing list and irc channel for them because this one is definitely overloaded now) because they too need the exact same SSD2828. but if both of you are working to the principle "i'll release it when it's finalised", there's absolutely no point considering doing that.

l.

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

On Mon, Sep 26, 2016 at 2:59 PM, Vincent Legoll vincent.legoll@gmail.com wrote:

Hello,

...

btw remember that mainline u-boot / kernel *does* actually work... with the Revision 2.2 EOMA68-A20 Cards it just only works for about 90 to 300 seconds and i haven't been able to track down why.

Care to elaborate a bit on that, is there more information somewhere, a bug report, anything ?

*i* haven't... because the linux-sunxi community operate off of non-free infrastructure. if you'd like to report a bug using the non-free resource known as github, or would like to join their mailing list using the proprietary web interface, and are happy to have your email address and your copyrighted words treated as "advertising fodder" by google, please feel free to do so! :)

I ask because the 300 seconds uptime rings a bell, maybe not relevant, but suspicious at least. The kernel was (maybe still is) initializing the timer (if I remember correctly) subsystem 5 minutes before wraparound, just so it is easier to catch bugs, by making those wraparound bugs easier triggerable...

ok so it might be a simple matter of putting the right "thing" into the dtb or something. i was using the cubieboard2 dtb (which may not actually be properly up-to-date).

...

there's clearly a bug somewhere around 4.0rc5 to 4.0rc6 which, if found, fixed, and patched, would make mainline perfectly acceptable for ongoing usage (with the EOMA68-A20).

That should be easy enough to bissect, if you have a reproducer.

i tried: it was an absolute bitch. as in, i tried for THREE DAYS, did approximately 100 kernel compiles, and still couldn't isolate it. the problem stems from the way that "git bisect" works, compounded by the fact that other kernel errors interfered with the assessment of whether a given kernel was "good" or "bad".

l.

...

Care to elaborate a bit on that, is there more information somewhere, a bug report, anything ?

*i* haven't... because the linux-sunxi community operate off of non-free infrastructure.

You could also report that kind of things to LKML, as a generic ARM problem, it'll probably reach a significant part of the same people...

if you'd like to report a bug using the non-free resource known as github, or would like to join their mailing list using the proprietary web interface, and are happy to have your email address and your copyrighted words treated as "advertising fodder" by google, please feel free to do so! :)

There are alternatives, and I don't understand why *I* should report something I don't have experienced myself, I don't have the HW to reproduce and is too vague... But I understand your time is precious these days.

...

...

there's clearly a bug somewhere around 4.0rc5 to 4.0rc6 which, if found, fixed, and patched, would make mainline perfectly acceptable for ongoing usage (with the EOMA68-A20).

That should be easy enough to bissect, if you have a reproducer.

i tried: it was an absolute bitch. as in, i tried for THREE DAYS, did approximately 100 kernel compiles, and still couldn't isolate it. the problem stems from the way that "git bisect" works, compounded by the fact that other kernel errors interfered with the assessment of whether a given kernel was "good" or "bad".

Yes, sometimes there are multiple bugs that fight against your bisection, I already have endured one of those (in intel's drm driver), but eventually found the culprit... It was time consuming though...

On Sun, Sep 25, 2016 at 5:11 PM, Joseph Honold mozzwald@gmail.com wrote:

...

yyep. all perfectly reasonable.... and nothing to do with the spec... but if the Card is incapable of booting *unless* that external media is present, that's unacceptable.

No, it's not part of the spec, just trying to make a point that it can be easier for the housing manufacturer to customize the experience if housing boot is available.

I'm not advocating for the cpu card to not boot if media is not available in the housing. It's a simple if/then/else statement; else being "boot whatever is on the cpu card".

sorry, i missed the most important flaw in this, which i've now outlined in the (new) software-related part of the spec, and it's this: if you replace the Card (even with one that has the same SoC but with a different amount of RAM), there's absolutely no guarantee that the resources or the instruction set is capable of running the media, *even* if it were able to access it.

remember that it's perfectly acceptable to have an x86 Card, or a MIPS Card, or a Card that expected MIPSEL, or a MIPS64, or a PowerPC, or even a 72mhz ARM Cortex M0 if it is powerful enough to run an LCD (even if it's monochrome: 1366x768 is actually only just over 128k so in theory it's doable).

the only way that an arbitrary processor (including future ones!) would even remotely be capable of "booting" from external arbitrary media is if it was in something like machine-independent bytecode (CLR, Java, FORTH, Python bytecode, etc.) or was actually in source-code form (perl, python, or other interpreted language).

and many many other exceptions that are, when you get down to it, just too f*****g horrible to contemplate.

...

manuel's team (with the hand-held games console) will be choosing this route. they will simply be using the EOMA68-A20 as a "module".

So, in this case, is he allowed to use the "EOMA" name anywhere regarding his product? I see his site calls it "ZEOMA" and states "ZEOMA is based on the EOMA-68 concept." Based on our discussion I am under the impression that this would not be allowed. He is not calling it "EOMA Compliant" but is creating the connection from his device to the EOMA standard which could be confused with compliance.

given that the games console development is a GPLv3+ (libre-licensed) project, i'm attempting to create an appropriate section that covers this scenario adequately.

one thing that's becoming clear is that there's an order of precedence here for what is acceptable, in a similar way to the legal requirements for vehicle safety (both Aviation and Road vehicles).

we simply cannot blithely claim that just because it's "free" and "open" that we can do whatever the hell we like. safety and consideration for future interoperability *ABSOLUTELY* has to take precedence.

kinda weird.

l.

2016-09-24 5:27 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:

<SNIP>

...

Let's switch to the Pocket QWERTY Computer as an example instead of

router. The A20 cpu card ships with Parabola, a desktop/workstation style OS. I want my customers to have a good experience when they use my handheld housing. Using an OS tailored for desktop/workstation computing is *not* a good experience on a small screen (I've tried this with the Zipit and it "worked", but was not very productive). I can make this transition even *easier* for average consumer by supplying a SD card with Replicant or some other custom libre distribution designed for small screens.

or, you could supply multiple OS SD cards for them, and set up the NAND to look an OS on the A20's MicroSD Card slot.

yes, i'm keenly aware that the alteration of the OS to suit LCD size is a Big Deal. putting it another way: it's a PAIN IN THE ASS! :)

it's made even more complicated (for the A20) by the fact that the people who did the sunxi u-boot and mainline kernel didn't think about this in advance: they've specified that the LCD shall be set up by u-boot and u-boot alone, leaving absolutely no possibility for changing the LCD size without a total reboot! oops...

Not quite sure that is the case. U-Boot provides "early" setup, regulator and clocks etc., for u-boot output. SimpleFB takes over the settings from U-Boot (via u-boot modified device-tree). But a proper KMS/DRM driver (sunxi has something working for A13, H3, A33) may change all that. Too bad that libv got burned and refused to release his work. https://lkml.org/lkml/2015/10/30/358 http://linux-sunxi.org/Linux_mainlining_effort

So yeah for SimpleFB you're bound to change the display settings in advance of a (re)boot. To the specific device. With proper KMS not.

Which leads to the EOMA68 minimum allowed display resolution should be set in U-Boot.

<snip>

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

On Sun, Oct 2, 2016 at 9:03 AM, Vincent Legoll vincent.legoll@gmail.com wrote:

Hello,

On Tue, Sep 27, 2016 at 4:55 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:

...

Not quite sure that is the case. U-Boot provides "early" setup, regulator and clocks etc., for u-boot output. SimpleFB takes over the settings from U-Boot (via u-boot modified device-tree). But a proper KMS/DRM driver (sunxi has something working for A13, H3, A33) may change all that.

There are problems with the H3 (& variants) display driver, on the HDMI output front, as seen on : http://linux-sunxi.org/GPL_Violations

Currently the driver cannot be mainlained as-is.

... and as direct a result the H3 has been crossed off the list for consideration and inclusion in EOMA Cards.

l.

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

On Sun, Oct 2, 2016 at 10:49 AM, Vincent Legoll vincent.legoll@gmail.com wrote:

Hello,

On Sun, Oct 2, 2016 at 10:25 AM, Luke Kenneth Casson Leighton wrote:

...

...

There are problems with the H3 (& variants) display driver, on the HDMI output front, as seen on : http://linux-sunxi.org/GPL_Violations

Currently the driver cannot be mainlained as-is.

... and as direct a result the H3 has been crossed off the list for consideration and inclusion in EOMA Cards.

That may change, as it needs only some license clarification on some published code from AW. And knowledge of the HDMI PHY model they used (which differs from the previous generations of HW).

Do you have contacts inside AW for the groups that created this chip, maybe you could try a bit of lobbying in that case...

i'll be talking to the teams, yes. bear in mind that each team is completely independent and controlled by different investors.

l.

Hello,

On Mon, Oct 3, 2016 at 1:26 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:

...

There are problems with the H3 (& variants) display driver, on the HDMI output front, as seen on : http://linux-sunxi.org/GPL_Violations

Currently the driver cannot be mainlained as-is.

Bear in mind that page is regarding the code in the "Allwinner (Lichee)" kernel. This does not reflect the code made by the sunxi community to enable graphics output on mainline.

I was speaking of the driver written by Jean-François Moine: http://moinejf.free.fr/opi2/index.html

But some of it is based on AW's lichee code, and some of it would need further informations (HDMI PHY model) from AW before being mainlinable.

I spoke last week about such things with Jean-François.

Besides the code from Allwinner, even with the proper licencing, is not mainline material. Very quick and dirty code and hacks.

Yes, we all know that, sadly... :-(

H3 support is mostly hindered by availability and interest.

I've got an H3 based SBC that I'm tinkering with, and a few others are also working on it. But that's getting off topic.

Cheers

Hello,

...

...

H3 support is mostly hindered by availability and interest.

I've got an H3 based SBC that I'm tinkering with, and a few others are also working on it. But that's getting off topic.

no it's not: if there's a chance that a specific processor can be utilised in EOMA68 Cards it's definitely ON topic.

Yes, but it may be better to wait when you're ready for launching the second CPU card project (ie probably after the first one is done or almost) so that you can work and lobby for a more up-to-date SoC to be used/usable...

The H3 is already contentious because of that very subject which may not be liberable (even if it looks like a small thing, HDMI output is an important factor(HTPC). So not having it may be a showstopper for a significant portion of the currently reachable user-base)

Cheers

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

On Sun, Sep 4, 2016 at 5:50 PM, Joseph Honold mozzwald@gmail.com wrote:

The difficult part (IMO) is creating the rubber/silicone overlay. A prototype could be made by either 3D printing a mold and casting a silicone keypad, or just 3D print the keys in plastic (or some other preferably soft material). Both these methods should work but I don't expect backlight to work well if at all (need translucent material). The labeling of keys might be difficult to achieve with 3d printng.

easily done with a dual-head 3d filament printer. there's clear/translucent PLA and PETG available. so, not a problem at all. there is also gel-like material available but it's much harder to work with and i don't know its durability (personally i wouldn't use it, or would research it very carefully in advance).

l.

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

On Sun, Sep 4, 2016 at 6:51 PM, Sam Pablo Kuper sampablokuper@posteo.net wrote:

On 04/09/16 17:50, Joseph Honold wrote:

...

My idea is to use snap domes attached to a sticker and placed directly on the pcb which has exposed copper pads for contacts (keyboard matrix). The sticker could be laser (or hand) cut to any shape and snap domes hand placed (for prototype). The snap dome method is how most phones (and Zipit Z2, see my post https://mozzwald.com/articles/zipit-soft-keypad-mod) do it these days. The snap domes are available and I actually got a sample kit from Snaptron (http://www.snaptron.com). There are some far east manufacturers of snap domes also.

I've seen pictures of these, but I don't think I've used them more than once or twice. I wasn't crazy about them, but they sure do seem like they would make manufacture easier. How does their reliability compare to other mechanisms?

metal domes are rated for ridiculous numbers of presses.

l.

On Sunday 4. September 2016 18.50.53 Joseph Honold wrote:

My idea is to use snap domes attached to a sticker and placed directly on the pcb which has exposed copper pads for contacts (keyboard matrix). The sticker could be laser (or hand) cut to any shape and snap domes hand placed (for prototype). The snap dome method is how most phones (and Zipit Z2, see my post https://mozzwald.com/articles/zipit-soft-keypad-mod) do it these days. The snap domes are available and I actually got a sample kit from Snaptron (http://www.snaptron.com). There are some far east manufacturers of snap domes also.

For reference, here are some pictures of the originally-planned successor to the Ben NanoNote that show what you're talking about:

http://en.qi-hardware.com/wiki/File:AVT2_RC1_keys.jpg

(The circuit boards, employing fairly simple contacts for domes as opposed to the oft-seen elaborate patterns that are potentially more suitable for coated- silicone keymats/overlays, as far as I can tell.)

http://en.qi-hardware.com/wiki/File:AVT2_v1.0_works.jpg

(The "dome sheet" applied to the board.)

Somewhere on that site is a picture of the "dome sheets" being applied by assembly line workers, but I can't find it at the moment.

The difficult part (IMO) is creating the rubber/silicone overlay. A prototype could be made by either 3D printing a mold and casting a silicone keypad, or just 3D print the keys in plastic (or some other preferably soft material). Both these methods should work but I don't expect backlight to work well if at all (need translucent material). The labeling of keys might be difficult to achieve with 3d printng.

Overlay/keymat production seems quite specialised, but maybe people here know a bit more about it.

Before I found out about EOMA68 I was intending to make a raspi handheld using this keypad layout https://mozzwald.com/public/images/misc/keypad.png

Are there any preferred keypad layouts?

That's asking for trouble! One thing I wouldn't mind knowing is how decent space bars are done using domes. Do they really involve multiple domes, or are there elongated ones that do this job?

Paul

On Sunday 4. September 2016 23.14.22 Joseph Honold wrote:

On 09/04/2016 03:11 PM, Paul Boddie wrote:

...

That's asking for trouble! One thing I wouldn't mind knowing is how decent space bars are done using domes. Do they really involve multiple domes, or are there elongated ones that do this job?

What trouble?

I just meant that everybody has their own favourite layout. ;-)

They do make oblong snap domes: http://www.snaptron.com/products/standard-domes/e-series/e-series-oblong/

Makes sense to use an oblong one but it depends on what's cheaper. If three regular snap domes are cheaper than one oblong, use the regular size (plus the qty discount if they're all the same).

Never had any issues with my Zipit spacebar that use 3 domes.

Well, if it works... I saw one keypad design once that had maybe three separate space buttons next to each other, which I thought was rather horrible.

The Ben NanoNote has a single space button, of course, which isn't really enough for anyone used to anything larger.

Paul

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

On Sun, Sep 4, 2016 at 7:14 PM, Sam Pablo Kuper sampablokuper@posteo.net wrote:

On 04/09/16 17:16, Sam Pablo Kuper wrote:

...

Therefore, in pursuit of (2), I made a spreadsheet [...]

https://docs.google.com/spreadsheets/d/1PD_tAIW7cuiXEe97BrcIRBfF9Sbo07limynx...

If you want to view the sheet in your browser, then you can do that here, but this requires running proprietary JavaScript which, obviously, I don't recommend:

https://docs.google.com/spreadsheets/d/1PD_tAIW7cuiXEe97BrcIRBfF9Sbo07limynx...

P.S. These spreadsheets are, as you will see, incomplete. Many fields haven't been filled in. Nevertheless, it gives a rough overview of the options on the market.

I would welcome patches, formatted as CSV files, if anyone is really keen. (Feel free to send them to me, to spare the whole mailing list(s) having to receive them.) Otherwise, I will either fill in the blanks as time allows, or let the spreadsheet languish if I conclude that making a keyboard is better than adapting an existing one.

Thanks, and sorry for the noise!

nah, knock yourself out, this is what this list is here for. if it does get too much we'll break it into separate lists / forums as appropriate.

l.

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

On Sun, Sep 4, 2016 at 5:47 PM, Stephen Paul Weber singpolyma@singpolyma.net wrote:

...

It would be great to have a housing for the EOMA68 that is of a similar form factor to one of these devices:

• DragonBox Pyra [1]

Isn't EOMA68 too big to work for handhelds?

manuel's team managed it. they're creating an EOMA68 hand-held games console.

l.

On 09/09/16 10:31, Alexander .S.T. Ross wrote:

heres a small table top keyboard from a phone case: http://m.banggood.com/General-Wired-Keyboard-Flip-Holster-Case-For-Andriod-M...

Thanks! Added to spreadsheet.