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