[Arm-netbook] EOMA68 booting process

[Luke Kenneth Casson Leighton]

On Fri, Mar 10, 2017 at 1:56 PM, mike.valk at gmail.com
<mike.valk at gmail.com> wrote:
> 2017-03-10 8:15 GMT+01:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
>>
>>  ah.  right.  the way i see it, the only thing that needs to happen is
>> that the card has to have enough on-board storage to get to u-boot (or
>> similar) where it can then recognise the EOMA68 I2C EEPROM (and get
>> the ID info) or for it to (pretty much) always boot externally and do
>> the same.
>
>
> 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.

> 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.


> 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.

> 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.

 also, *when* microsoft and apple start creating proprietary Cards
(hard as it may be for them to support the full range of available
Housings by the time they get the memo) it should not be made
difficult or impossible for them to comply with the standard because
it's been "assumed all along that Linux Is God".   remember, it's
perfectly possible to have an EOMA68-compliant FPGA Card.

> If that is found try to boot from it. If it fails perhaps write log to that
> file.
>
> If that file is not found boot from internal media.
>
> I guess this is somewhat different from normal because usually u-boot is
> build with the OS payload attached kernel,initram,devicetree.
>
> Updating the kernel means updating u-boot.

 yyep

> Blindly booting something external is probably a security issue.

 if people want security they shouldn't have let someone else gain
access to their Card in the first place.  or borrow Housings they
don't fully trust.

> But I see
> little alternatives to keep is simple. So simple that all you need is a
> thumbdrive to bootstrap an EOMA card.
>
> On Android they use fastboot and recovery. Which is toggling some persistent
> data from the running OS that u-boot reads from the next boot and chooses a
> different image to load.
>
> It usually also listens to a button press during boot to do the same.
>
> I find that method flawed. It either requires a running OS or a button to
> press. On EOMA there is no button. Else we have to introduce something like
> a reset button/pinhole on the user facing side of the card.

 that's a choice that would be made by individual Card Manufacturers.


>> anything beyond tthat needs to be analysed *really* carefully, right
>> through its impllications down the *entire* lifecycle.
>
>
> Absolutly, I too think this is something not to be taken lightly. Any
> mistake will hunt EOMA for a Long time

 more than that, a single mistake risks destroying the entire
standard.  96boards has completely underestimated the effect of
releasing a standard which is deeply flawed.  their CEO *genuinely*
believed that it was possible to "fix" the flaws in the standard,
after the fact: it simply isn't.

l.