On Tue, Mar 14, 2017 at 9:27 AM, mike.valk@gmail.com mike.valk@gmail.com wrote:
2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Fri, Mar 10, 2017 at 1:56 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
Always boot externally? That means that every housing must contain storage and an OS.
not at all. you misunderstand. external *on the card*. for example: the micro-sd card slot on the EOMA68-A20.
Figured as much just wanted to be explicit
good idea to check
I think the OS should remain with the card. Weather that's on NAND, eMMC or SD. That should be irrelevant.
that's not entiirely for us to decide (as in: booting from Housings should not be *prohibited*) but yes, of course the Card has to be capable of stand-alone boot.
Then multi boot is implied.
... yyyyeah it is.
But for the average jane/joe to switch/repair/upgrade that OS we must have a "simple" mechanism for booting external media while keeping the main media connected.
A Intel BIOS usually has a "boot" order which can be modified. For EOMA we don't have that "luxury".
well... we do... as i believe it is reasonable to simply say that the responsibility is with the retailer to ensure that whatever function(s) and housing(s) they sell must actually work as sold. if they want to provide a boot order, they may do so.
Although in this stage of the project it is not really a hot issue.
correct. we're currently in the "get the documentation and some reference implementations out there" phase.
Leaving this to the "market" will result in 1001 different options which will require 1001+ methods for loading a new OS on the card.
technically correct but unlikely, given that what's _likely_ to happen is that certain methods will become favourable for the "market" to simply copy directly from whatever source repository happens to be most commonly available and 100% suitable to their immediate needs.
No way a independent software vendor is going to support 1001+ boot/install options.
... and they won't have to, and won't need to. all that they will need is the methods required that allow them to sell product.... and AS LONG AS THE REST IS OPEN they *will* receive an EOMA68 Complliance Certificate.
i believe i've documented this in the standard, now, when i did a major rewrite and split everything clearly out by "roles". basically the "Manufacturer Role" must:
* provide whatever boot method they see fit * provide CLEAR DEMONSTRATIONS that the Card is indeed "open" i.e. that other "roles" *MAY* if they so choose REPLACE THE ENTIRE OS AND BOOTLOADER entirely from software libre sources WITHOUT LOSING FUNCTIONALITY DUE TO PROPRIETARY FIRMWARE OR SOFTWARE.
it is *NOT* the responsibility of the manufacturer to support a billion different boot options. if a Technical End-User (one of the roles) or a Re-purposer (another of the roles) *wishes* to replace the OS, wishes to support a billion different boot options, they MUST be at liberty to do so, from documented and NDA-free publicly-accessible resources.
totally different roles and responsibilities, mike.
The housing may not have a screen or an input device for changing options.
correct... however anyone who supplies such housings would also be taking full responsibility for creating a suitable OS.
I guess it should be that the last boot init should scan for external devices and look for a specific file name "eomaboot.txt" or some thing.
too complex and not really necessary if it is the responsibility of the retailer to ensure that the product they sell "works". btw to emphasise: one of the other responsibilities of the retailer is to NOT lock down the device so that 3rd parties are no longer permitted to replace the OS and boot mechanism entirely.
I afraid that's not enough. They release a card or housing make an OS for it and then they are done.
... not quite: they must also demonstrate and prove that the OS *can* be replaced, from entirely libre open and NDA-free documentation and resources. if they can't, they don't receive Certification, simple as that.
Not locking down to boot is enough to say: "Hey they can load something else. If they know wat they are doing"
yes. as long as it's from publicly-documented NDA-free resources, i see no problem with RE_PURPOSERS or TECHNICAL_END_USERS being expected to take on that responsibility themselves.
i also *specifically* state that it is perfectly acceptable for the OEM (and associated sales channels) to deny warranty support (invalidate the warranty) under such circumstances where RE_PURPOSERS or TECHNICAL_END_USERS carry out such re-flashing / re-purposing.
i'd be interested to hear if people agree with that, particularly given that it may actually be possible for people to damage a Housing or Card through overheating if they blatantly ignore the EOMA68 standard and try "overclocking" for example.
That's the status right now. A product is made software is tweaked to work and done...
not quite
Loading a Android MOD is a tricky business. It's replacing the running OS using the running system. When failed it's bricked.
then they would not receive Certification (if it is impossible to recover the device by any reasonable means).
very simple, mike.
The bootloading process of AW(FEX) has been reverse engeneerd. The other SoC not. They all require propriety software to flash software to a bricked device like Allwinners Livesuit/Phoenixsuit.
then they would not receive Certification because they would be failing to demonstrate that the device may be re-purposed using NDA-free publicly-accessbile libre tools and software.
all this _genuinely_ has been covered in the (rather large) rewrite that i did several months back, mike. it was a hell of a lot of writing, though, and i had to stop as it was taking up seeerious amounts of time. i got the majority of it done though.
l.