[Arm-netbook] EOMA68 booting process

[mike.valk at gmail.com]

2017-03-10 8:15 GMT+01:00 Luke Kenneth Casson Leighton <lkcl at 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 at lists.phcomp.co.uk
> >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> >> Send large attachments to arm-netbook at files.phcomp.co.uk
> >
> >
> >
> > _______________________________________________
> > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> > Send large attachments to arm-netbook at files.phcomp.co.uk
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170310/697b7c06/attachment.html>