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.