[Arm-netbook] EOMA68 booting process

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
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

Post by Luke Kenneth Casson Leighton
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.
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
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

Luke Kenneth Casson Leighton

2017-03-10 15:12:27 UTC

Always boot externally? That means that every housing must contain storage
and an OS.

not at all. you misunderstand. external *on the card*. for
example: the micro-sd card slot on the EOMA68-A20.

Post by m***@gmail.com
I think the OS should remain with the card. Weather that's on NAND, eMMC or
SD. That should be irrelevant.

that's not entiirely for us to decide (as in: booting from Housings
should not be *prohibited*) but yes, of course the Card has to be
capable of stand-alone boot.

Post by m***@gmail.com
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".

well... we do... as i believe it is reasonable to simply say that the
responsibility is with the retailer to ensure that whatever
function(s) and housing(s) they sell must actually work as sold. if
they want to provide a boot order, they may do so.

Post by m***@gmail.com
The housing may not have a screen or an input
device for changing options.

correct... however anyone who supplies such housings would also be
taking full responsibility for creating a suitable OS.

Post by m***@gmail.com
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.

too complex and not really necessary if it is the responsibility of
the retailer to ensure that the product they sell "works". btw to
emphasise: one of the other responsibilities of the retailer is to NOT
lock down the device so that 3rd parties are no longer permitted to
replace the OS and boot mechanism entirely.

also, *when* microsoft and apple start creating proprietary Cards
(hard as it may be for them to support the full range of available
Housings by the time they get the memo) it should not be made
difficult or impossible for them to comply with the standard because
it's been "assumed all along that Linux Is God". remember, it's
perfectly possible to have an EOMA68-compliant FPGA Card.

Post by m***@gmail.com
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.

yyep

Post by m***@gmail.com
Blindly booting something external is probably a security issue.

if people want security they shouldn't have let someone else gain
access to their Card in the first place. or borrow Housings they
don't fully trust.

Post by m***@gmail.com
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.

that's a choice that would be made by individual Card Manufacturers.

Post by Luke Kenneth Casson Leighton
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

more than that, a single mistake risks destroying the entire
standard. 96boards has completely underestimated the effect of
releasing a standard which is deeply flawed. their CEO *genuinely*
believed that it was possible to "fix" the flaws in the standard,
after the fact: it simply isn't.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachmen

m***@gmail.com

2017-03-14 09:27:38 UTC

Post by m***@gmail.com
Always boot externally? That means that every housing must contain

storage

Post by m***@gmail.com
and an OS.

not at all. you misunderstand. external *on the card*. for
example: the micro-sd card slot on the EOMA68-A20.

Figured as much just wanted to be explicit

Post by m***@gmail.com
I think the OS should remain with the card. Weather that's on NAND, eMMC

Post by m***@gmail.com
SD. That should be irrelevant.

that's not entiirely for us to decide (as in: booting from Housings
should not be *prohibited*) but yes, of course the Card has to be
capable of stand-alone boot.

Then multi boot is implied.

Post by m***@gmail.com
But for the average jane/joe to switch/repair/upgrade that OS we must

have a

Post by m***@gmail.com
"simple" mechanism for booting external media while keeping the main

media

Post by m***@gmail.com
connected.
A Intel BIOS usually has a "boot" order which can be modified. For EOMA

Post by m***@gmail.com
don't have that "luxury".

Although in this stage of the project it is not really a hot issue.

Leaving this to the "market" will result in 1001 different options which
will require 1001+ methods for loading a new OS on the card.

No way a independent software vendor is going to support 1001+ boot/install
options.

Post by m***@gmail.com
The housing may not have a screen or an input
device for changing options.

correct... however anyone who supplies such housings would also be
taking full responsibility for creating a suitable OS.

Post by m***@gmail.com
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.

I afraid that's not enough. They release a card or housing make an OS for
it and then they are done.

Not locking down to boot is enough to say: "Hey they can load something
else. If they know wat they are doing"

That's the status right now. A product is made software is tweaked to work
and done...

Loading a Android MOD is a tricky business. It's replacing the running OS
using the running system. When failed it's bricked.

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.

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.

Post by Luke Kenneth Casson Leighton
also, *when* microsoft and apple start creating proprietary Cards
(hard as it may be for them to support the full range of available
Housings by the time they get the memo) it should not be made
difficult or impossible for them to comply with the standard because
it's been "assumed all along that Linux Is God". remember, it's
perfectly possible to have an EOMA68-compliant FPGA Card.

Or a STM32F. I know. You could even build one from discrete logic.

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.

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.

Post by Luke Kenneth Casson Leighton
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

Luke Kenneth Casson Leighton

2017-03-14 10:35:09 UTC

Post by m***@gmail.com
Always boot externally? That means that every housing must contain storage
and an OS.

not at all. you misunderstand. external *on the card*. for
example: the micro-sd card slot on the EOMA68-A20.

Figured as much just wanted to be explicit

good idea to check

Post by m***@gmail.com
I think the OS should remain with the card. Weather that's on NAND, eMMC or
SD. That should be irrelevant.

that's not entiirely for us to decide (as in: booting from Housings
should not be *prohibited*) but yes, of course the Card has to be
capable of stand-alone boot.

Then multi boot is implied.

... yyyyeah it is.

Although in this stage of the project it is not really a hot issue.

correct. we're currently in the "get the documentation and some
reference implementations out there" phase.

Post by m***@gmail.com
Leaving this to the "market" will result in 1001 different options which
will require 1001+ methods for loading a new OS on the card.

technically correct but unlikely, given that what's _likely_ to
happen is that certain methods will become favourable for the "market"
to simply copy directly from whatever source repository happens to be
most commonly available and 100% suitable to their immediate needs.

Post by m***@gmail.com
No way a independent software vendor is going to support 1001+ boot/install
options.

... and they won't have to, and won't need to. all that they will
need is the methods required that allow them to sell product.... and
AS LONG AS THE REST IS OPEN they *will* receive an EOMA68 Complliance
Certificate.

i believe i've documented this in the standard, now, when i did a
major rewrite and split everything clearly out by "roles". basically
the "Manufacturer Role" must:

* provide whatever boot method they see fit
* provide CLEAR DEMONSTRATIONS that the Card is indeed "open" i.e.
that other "roles" *MAY* if they so choose REPLACE THE ENTIRE OS AND
BOOTLOADER entirely from software libre sources WITHOUT LOSING
FUNCTIONALITY DUE TO PROPRIETARY FIRMWARE OR SOFTWARE.

it is *NOT* the responsibility of the manufacturer to support a
billion different boot options. if a Technical End-User (one of the
roles) or a Re-purposer (another of the roles) *wishes* to replace the
OS, wishes to support a billion different boot options, they MUST be
at liberty to do so, from documented and NDA-free publicly-accessible
resources.

totally different roles and responsibilities, mike.