<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton <span dir="ltr"><<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, Mar 10, 2017 at 1:56 PM, <a href="mailto:mike.valk@gmail.com">mike.valk@gmail.com</a><br>
<<a href="mailto:mike.valk@gmail.com">mike.valk@gmail.com</a>> wrote:<br>> Always boot externally? That means that every housing must contain storage<br>
> and an OS.<br>
<br>
</span> not at all.  you misunderstand.  external *on the card*.  for<br>
example: the micro-sd card slot on the EOMA68-A20.<br></blockquote><div><br></div><div>Figured as much just wanted to be explicit <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> I think the OS should remain with the card. Weather that's on NAND, eMMC or<br>
> SD. That should be irrelevant.<br>
<br>
</span> that's not entiirely for us to decide (as in: booting from Housings<br>
should not be *prohibited*) but yes, of course the Card has to be<br>
capable of stand-alone boot.</blockquote><div><br></div><div>Then multi boot is implied.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> But for the average jane/joe to switch/repair/upgrade that OS we must have a<br>
> "simple" mechanism for booting external media while keeping the main media<br>
> connected.<br>
><br>
> A Intel BIOS usually has a "boot" order which can be modified. For EOMA we<br>
> don't have that "luxury".<br>
<br>
</span> well... we do... as i believe it is reasonable to simply say that the<br>
responsibility is with the retailer to ensure that whatever<br>
function(s) and housing(s) they sell must actually work as sold.  if<br>
they want to provide a boot order, they may do so.<br></blockquote><div><br></div><div>Although in this stage of the project it is not really a hot issue. </div><div><br></div><div>Leaving this to the "market" will result in 1001 different options which will require 1001+ methods for loading a new OS on the card.</div><div><br></div><div>No way a independent software vendor is going to support 1001+ boot/install options. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> The housing may not have a screen or an input<br>
> device for changing options.<br>
<br>
</span> correct... however anyone who supplies such housings would also be<br>
taking full responsibility for creating a suitable OS.<br>
<span class="gmail-"><br>
> I guess it should be that the last boot init should scan for external<br>
> devices and look for a specific file name "eomaboot.txt" or some thing.<br>
<br>
</span> too complex and not really necessary if it is the responsibility of<br>
the retailer to ensure that the product they sell "works".  btw to<br>
emphasise: one of the other responsibilities of the retailer is to NOT<br>
lock down the device so that 3rd parties are no longer permitted to<br>
replace the OS and boot mechanism entirely.<br></blockquote><div><br></div><div>I afraid that's not enough. They release a card or housing make an OS for it and then they are done. </div><div><br></div><div>Not locking down to boot is enough to say: "Hey they can load something else. If they know wat they are doing"</div><div><br></div><div>That's the status right now. A product is made software is tweaked to work and done...</div><div><br></div><div>Loading a Android MOD is a tricky business. It's replacing the running OS using the running system. When failed it's bricked. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 also, *when* microsoft and apple start creating proprietary Cards<br>
(hard as it may be for them to support the full range of available<br>
Housings by the time they get the memo) it should not be made<br>
difficult or impossible for them to comply with the standard because<br>
it's been "assumed all along that Linux Is God".   remember, it's<br>
perfectly possible to have an EOMA68-compliant FPGA Card.<br></blockquote><div><br></div><div>Or a STM32F. I know. You could even build one from discrete logic.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" rel="noreferrer" target="_blank">http://lists.phcomp.co.uk/<wbr>mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a></div></div></blockquote></div><br></div></div>