Agreed - lets make this as generic as possible (subject to hardware support);

Goal for Reference Platform

We should define and follow standards where we need to - for example common partition tables ….
Boot from eMMC
Boot from SD
Boot from USB Stick
Boot from network (GRUB 2) using on board ethernet or USB ethernet dongle

All from an open source bootloader with ATF, OPTEE, UEFI, ACPI/DT, Fastboot support etc. 

George



On Nov 11, 2015, at 10:07 AM, Ricardo Salveti <ricardo.salveti@linaro.org> wrote:

On Wed, Nov 11, 2015 at 12:39 PM, Steve McIntyre
<steve.mcintyre@linaro.org> wrote:
On Wed, Nov 11, 2015 at 01:50:15PM +0000, Daniel Thompson wrote:
On 11/11/15 06:35, Koen Kooi wrote:
Device           Start     End Sectors  Size Type
/dev/mmcblk0p1    2048    4095    2048    1M Microsoft basic data
/dev/mmcblk0p2    4096    6143    2048    1M Microsoft basic data
/dev/mmcblk0p3    6144    8191    2048    1M Microsoft basic data
/dev/mmcblk0p4    8192   24575   16384    8M BIOS boot
/dev/mmcblk0p5   24576   28671    4096    2M Microsoft basic data
/dev/mmcblk0p6   28672  159743  131072   64M EFI System
/dev/mmcblk0p7  159744  684031  524288  256M Microsoft basic data
/dev/mmcblk0p8  684032 1208319  524288  256M Linux reserved
/dev/mmcblk0p9 1208320 7471070 6262751    3G Microsoft basic data

So you proved Marcins point: instead of ESP + rootfs like you'd expect
hikey has vrl, vrl_backup, mcuimage and more partitions. Having the
script below doesn't make it less 'magic'.

Isn't that a consequence of loading UEFI itself from the same media (eMMC)
that UEFI loads the OS?

I think we might always need at least one partition configured to "protect"
the firmware; we need to be able to direct an off-the-shelf (i.e. does not
have any special knowledge about hikey) OS installer not to mess with it.

What is the best way to mark such a partition to encourage installers to do
that by default?

Most installers won't touch anything they don't recognise, but it
could be clearer here. Just using "Microsoft basic data" as a
partition type doesn't tell anybody anything useful here. From reading
https://en.wikipedia.org/wiki/GUID_Partition_Table, I'd suggest maybe
using Reserved (8DA63339-0007-60C0-C436-083AC8230908) or (maybe
better) picking/registering a different partition type altogether.

That should indeed work better for eMMC. Other option we should have
is having the firmware as part of the eMMC and the OS installed at the
SDcard (and then the partition table/logic would be generic enough).

In the end we need to support both, since people might want to also
install distros on a usb disk (specially with USB 3.0), which would be
similar to the sdcard logic.

Cheers,
-- 
Ricardo Salveti
_______________________________________________
Dev mailing list
Dev@lists.96boards.org
https://lists.96boards.org/mailman/listinfo/dev