On Thu, Nov 12, 2015 at 7:45 AM, Grant Likely grant.likely@linaro.org 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...
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).
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.
I personally would like to see the pain of stage 1 related tasks reduced. Yes, solving OS install problems serves a lot of users, but there are a fair number of people that have to deal with components prior to OS boot and everything before that point is different. Some things we may not be able to fix, but I'm sure there are things we can. We've generally just left it to Builds&Baselines team to work around all these differences. We need to stop doing that and standardize things across platforms where we can.
For example, I need to fix the partition table or revert it back to "stage 1". How do I do that in a way that is common across boards? There's varying requirements of what platforms need for partitions or reserved areas, but that is all just data. There is no good reason for the procedure to be different. In good ole non-standard u-boot that can be a "gpt write ${partitions}" command with $partitions coming from environment or "fastboot oem format". For UEFI?
Another example, how do I update UEFI/u-boot without rebuilding ATF. In general, I'd like to be able to replace only the component I care about while retaining the rest of the released images. We should be looking at how to reduce the number of steps and making sure the steps are the same across boards.
Rob