<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-03-10 8:15 GMT+01:00 Luke Kenneth Casson Leighton <span dir="ltr"><<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>></span>: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ah.  right.  the way i see it, the only thing that needs to happen is<br>
that the card has to have enough on-board storage to get to u-boot (or<br>
similar) where it can then recognise the EOMA68 I2C EEPROM (and get<br>
the ID info) or for it to (pretty much) always boot externally and do<br>
the same.<br></blockquote><div><br></div><div>Always boot externally? That means that every housing must contain storage and an OS. </div><div><br></div><div>That would kill a seamless environment on every device and any form of suspend and resume.</div><div><br></div><div>I think the OS should remain with the card. Weather that's on NAND, eMMC or SD. That should be irrelevant.</div><div><br></div><div>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.</div><div><br></div><div>A Intel BIOS usually has a "boot" order which can be modified. For EOMA we don't have that "luxury". The housing may not have a screen or an input device for changing options.</div><div><br></div><div>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.</div><div><br></div><div>If that is found try to boot from it. If it fails perhaps write log to that file.</div><div><br></div><div>If that file is not found boot from internal media.</div><div><br></div><div>I guess this is somewhat different from normal because usually u-boot is build with the OS payload attached kernel,initram,devicetree.</div><div><br></div><div>Updating the kernel means updating u-boot.</div><div><br></div><div>The second stage u-boot is something akin to GRUB/LILO/etc. But fixed to a single boot option.</div><div><br></div><div>Blindly booting something external is probably a security issue. But I see little alternatives to keep is simple. So simple that all you need is a thumbdrive to bootstrap an EOMA card.<br></div><div><br></div><div><div>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.</div><div><br></div><div>It usually also listens to a button press during boot to do the same.</div><div><br></div><div>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.</div></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>
anything beyond tthat needs to be analysed *really* carefully, right<br>
through its impllications down the *entire* lifecycle. </blockquote><div><br></div><div>Absolutly, I too think this is something not to be taken lightly. Any mistake will hunt EOMA for a Long time</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"> which is why i<br>
currently have it as (pretty much) "card must self-boot and must adapt<br>
to EOMA68 EEPROM ID" and it's left as generically as that<br>
<br>
> On A20 <a href="http://et.al" rel="noreferrer" target="_blank">et.al</a>. there is the FEL mode. Which is initialized by that first<br>
> loaded program.<br>
<br>
 from ROM.<br>
<br>
> In this FEL mode you can push an image over USB-OTG. But<br>
> that requires an active USB host not just an USB thumb drive.<br>
<br>
 i do this all the time.  i don't develop for the A20 in any other<br>
way.  when i see the shit that people get themselves into *even though<br>
usb-fel was written years ago* by trying to un-fuck their systems<br>
using LIVESHIT.EXE and other crap i'm just... staggered and genuinely<br>
confused.<br>
<br>
 it's *real* simple and needs just *seven* lines of bash script:<br>
<br>
fel write 0x2000 ./fel-boot-spl-EOMA68_A20_2GB.<wbr>bin<br>
sleep 1<br>
fel exe 0x2000<br>
sleep 1<br>
fel write 0x4a000000 u-boot.new.bin<br>
sleep 1<br>
fel exe 0x4a000000<br>
<br>
the fel-boot-spl.bin is actually the u-boot-spl.bin executable that's<br>
compiled by default in u-boot if you select "CONFIG_SPL".  the<br>
u-boot.new.bin is u-boot without the spl part tacked onto the front.<br>
<br>
it really couldn't be simpler.  you can if you want directly upload<br>
the linux kernel, script.bin, dtb file, initramdisk WHATEVER YOU LIKE<br>
directly into memory and then execute it DIRECTLY.  you don't even<br>
need u-boot to do it.<br>
<br>
<br>
> <a href="http://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB" rel="noreferrer" target="_blank">http://linux-sunxi.org/FEL/<wbr>USBBoot#Booting_U-Boot_over_<wbr>USB</a><br>
> <a href="http://linux-sunxi.org/BROM" rel="noreferrer" target="_blank">http://linux-sunxi.org/BROM</a><br>
><br>
> So the question is are "we" going to build such a thing?<br>
<br>
 i'm yet to be convinced that it's necessary, beyond adapting u-boot<br>
and the linux kernel to read and adapt to the ID in the EOMA68 EEPROM.<br>
what specifically did you have in mind?<br>
<br>
l.<br>
<br>
><br>
>><br>
>><br>
>> -- hendrik<br>
>><br>
>><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><br>
><br>
><br>
><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><br>
<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></blockquote></div><br></div></div>