[Arm-netbook] EOMA68 booting process

[Luke Kenneth Casson Leighton]

On Tue, Mar 14, 2017 at 9:27 AM, mike.valk at gmail.com
<mike.valk at gmail.com> wrote:
>
>
> 2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
>>
>> On Fri, Mar 10, 2017 at 1:56 PM, mike.valk at gmail.com
>> <mike.valk at 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.