On Thu, Mar 9, 2017 at 3:46 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
thanks for the explanation, mike.
So for EOMA we must set/invent a standard which Installers can use regardless the SoC type used in the EOMA card.
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.
anything beyond tthat needs to be analysed *really* carefully, right through its impllications down the *entire* lifecycle. 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
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
On Fri, Mar 10, 2017 at 1:56 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
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.
not at all. you misunderstand. external *on the card*. for example: the micro-sd card slot on the EOMA68-A20.
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.
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.
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.
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.
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
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.
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.
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.
2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Fri, Mar 10, 2017 at 1:56 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
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
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.
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.
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.
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.
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.
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.
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.
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
On Tue, Mar 14, 2017 at 9:27 AM, mike.valk@gmail.com mike.valk@gmail.com wrote:
2017-03-10 16:12 GMT+01:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Fri, Mar 10, 2017 at 1:56 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
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
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.
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.
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.
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.
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.
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.
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.
I afraid that's not enough. They release a card or housing make an OS for it and then they are done.
... not quite: they must also demonstrate and prove that the OS *can* be replaced, from entirely libre open and NDA-free documentation and resources. if they can't, they don't receive Certification, simple as that.
Not locking down to boot is enough to say: "Hey they can load something else. If they know wat they are doing"
yes. as long as it's from publicly-documented NDA-free resources, i see no problem with RE_PURPOSERS or TECHNICAL_END_USERS being expected to take on that responsibility themselves.
i also *specifically* state that it is perfectly acceptable for the OEM (and associated sales channels) to deny warranty support (invalidate the warranty) under such circumstances where RE_PURPOSERS or TECHNICAL_END_USERS carry out such re-flashing / re-purposing.
i'd be interested to hear if people agree with that, particularly given that it may actually be possible for people to damage a Housing or Card through overheating if they blatantly ignore the EOMA68 standard and try "overclocking" for example.
That's the status right now. A product is made software is tweaked to work and done...
not quite
Loading a Android MOD is a tricky business. It's replacing the running OS using the running system. When failed it's bricked.
then they would not receive Certification (if it is impossible to recover the device by any reasonable means).
very simple, mike.
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.
then they would not receive Certification because they would be failing to demonstrate that the device may be re-purposed using NDA-free publicly-accessbile libre tools and software.
all this _genuinely_ has been covered in the (rather large) rewrite that i did several months back, mike. it was a hell of a lot of writing, though, and i had to stop as it was taking up seeerious amounts of time. i got the majority of it done though.
l.
arm-netbook@lists.phcomp.co.uk
-
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com