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