On Thu, Nov 12, 2015 at 2:52 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Thu, Nov 12, 2015 at 01:45:15PM +0000, Grant Likely wrote:
On Wed, Nov 11, 2015 at 2: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.
Reserved would be fine I think. The partition attribute flags may be the right place to mark partitions as required-do-not-touch. Bit 0 means system partition (do not touch or move). Bit 1 means EFI should ignore the contents and not attempt to read. Setting those two flags may be sufficient to keep those partitions around. But I digress from the main point...
ACK, those bits would make sens.
Doing full system images like were doing now is fine to get people up and running, but it doesn't help distros. When the MMC is shared between firmware and the OS, we need to take a two stage approach to OS support:
- Prepare the platform (just enough partitioning to hold the firmware images)
- OS/Distro installer (OS does it's own thing for installation,
including creating/moving the ESP if need be)
The first stage is firmly our responsibility or the board vendor's. It should leave the MMC partitioned, but no OS partitions exist yet. The ESP may exist, but if it does then it should be empty (or alternately, the firmware is okay with it being empty).
Yup.
Second stage is the distro installer. It should be able to do all the normal activities that an installer does with one restriction: It must not delete the reserved partitions. If it does, or if the user does manually, then the user has to go back to stage 1.
Boards should ship with stage 1 already installed, ready for an OS installer. Installing the OS (or netbooting for that matter) shouldn't require redoing stage 1.
Stage 2 could be a netboot installer, a netboot image, or boot from SD card. End users can also go do their own thing (install firmware images to SD card), but that isn't something we expect distros to support. Users doing that are on their own.
The Debian system images we currently produce are /kind of/ like stage 2, but we're very naive about it by flashing raw filesystem images to disk. Fine for proving things out, but it isn't where we want to be.
Steve, does that sound like a supportable approach for Debian?
Absolutely. It's the kind of setup that debian-installer will be expecting. It should present a reasonable end-user experience if exposed to them directly, and *should* also work sensibly if somebody is pre-seeding an installation for a lights-out setup.
Right. Lets do this then. Ricardo, how do we get there? There UEFI upstreaming work is really important to pick up bugfixes and features from mainline. So is the kernel mainlining work so that distros can pick up board support. We need to have some focus on grub_install to make sure it works correctly on HiKey's UEFI. It would be really good to get the Dragonboard 410c UEFI port working for us, but I don't know if the source code for that has been released.
g.