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.
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. 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.
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).
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.
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".
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.
I agree with Louis on this. Depending on the cpu, other electronics in the cpu card and other ports on the user facing end, there may not be room for a sd card socket. The top loader is a good idea if you have the space; I hadn't considered that. We should not assume the cpu card will have an sd card if it's not required.
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". 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.
"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). Housing boot could make it easier to deploy and still call it EOMA compliant.
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? 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.
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.
(1) is okay with me if the cpu card sd slot is *required* by the spec, otherwise there is no *guarantee* that the sd card slot exists on the cpu card.
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.
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 :)