[Arm-netbook] EOMA68 booting process

[mike.valk at gmail.com]

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

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

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

Leaving this to the "market" will result in 1001 different options which
will require 1001+ methods for loading a new OS on the card.

No way a independent software vendor is going to support 1001+ boot/install
options.


>
> > 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 locking down to boot is enough to say: "Hey they can load something
else. If they know wat they are doing"

That's the status right now. A product is made software is tweaked to work
and done...

Loading a Android MOD is a tricky business. It's replacing the running OS
using the running system. When failed it's bricked.

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.

It doesn't have to be a fixed standard. If a mechanism is proposed, than
it's more likely to be used than left to each individual vendor to invent.


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

Or a STM32F. I know. You could even build one from discrete logic.

But most need software to work. That software should be "easely"
maintainable. If not they are going to the landfill if they don't work or
become outdated.

But I understand it is a tricky one. An EOMA card can have varying
"intelligence" and "hardware". A single "boot" method may not be possible.
At least we could try to limit it so that it becomes more
adoptable/maintainable to the end-user.




>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170314/9dc045c6/attachment-0001.html>