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

> 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@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk