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