| Message ID | 20171115101151.11382-1-maxime.ripard@free-electrons.com |
|---|---|
| Headers | show |
| Series | sunxi: Ease eMMC usage and flashing | expand |
On Wed, Nov 15, 2017 at 11:11:47AM +0100, Maxime Ripard wrote: > Here is a set of patches that have been sitting in some variations for > quite some time now. > > This is mostly to ease the eMMC (and MMC, to some extent) flashing > using fastboot that in turn rely on GPT. > > The Allwinner SoCs need to have the SPL located right in the middle of > a traditional GPT, at 8kB. > > To deal with this, we would basically have two options: > - Use the already in-tree solution to move the partition entries to > another arbitrary offset in the MMC. > - Use a smaller number of partitions entries > > Both are non-standards, but are dealt with nicely by the regular tools > and users (at least on a Linux system). However, the first solution is > quite confusing for users (that needs to be aware where the partitions > will be), might be less flexible because not all tools will allow to > create partitions for things between the GPT main entry and the > partition entries, and might confuse tools if such a setup is > available. > > In our case, using the first solution, gdisk will for example refuse > to create a partition for the SPL. > > The second solution though seems to be well handled by all the tools, > and just feels the same, except that you end up with a smaller number > of partitions. In our case, that number is 56 partitions (16 sectors > before the SPL, 1 sector for the protective MBR, 1 sector for the GPT > header, and 4 partition entries per sector) instead of 128, which > doesn't sound very impractical either. > > The two first patches deal with that. > > We then provide a default partitionning scheme. I'd like feedback on > that one. I appreciate that having a good default in such a case, but > I'd like to have a reasonably simple layout that works good enough to > install a distro. I'm a bit short on background on what an EFI > partition is supposed to look like, and what a good size would be. I'd > really like some input on this. Hello, the partitioning scheme from patch no. 3 of this series looks like follows: #define PARTS_DEFAULT \ "name=loader1,start=8k,size=32k;" \ "name=loader2,size=984k;" \ "name=boot,size=128M,bootable;" \ "name=system,size=-;" I assume that the intended use is - loader1: SPL - loader2: u-boot - boot: Linux /boot - system: Linux / AFAIK the UEFI spec requires that the EFI system partition (ESP) is FAT-formatted. Most (probably all?) Linux package management tooling assumes that files from packages are installed onto filesystems that support POSIX semantics, including hardlinks, which FAT does not. This means that distributions cannot re-use an EFI system partition as /boot and therefore need a partition for /boot and an additional ESP (AFAIK commonly mounted to /boot/efi). I would therefore like to propose adding a small separate partition for use as ESP. Regards, Karsten
Hi Karsten, On Wed, Nov 15, 2017 at 09:41:34PM +0100, Karsten Merker wrote: > > We then provide a default partitionning scheme. I'd like feedback on > > that one. I appreciate that having a good default in such a case, but > > I'd like to have a reasonably simple layout that works good enough to > > install a distro. I'm a bit short on background on what an EFI > > partition is supposed to look like, and what a good size would be. I'd > > really like some input on this. > > the partitioning scheme from patch no. 3 of this series looks like > follows: > > #define PARTS_DEFAULT \ > "name=loader1,start=8k,size=32k;" \ > "name=loader2,size=984k;" \ > "name=boot,size=128M,bootable;" \ > "name=system,size=-;" > > I assume that the intended use is > - loader1: SPL > - loader2: u-boot > - boot: Linux /boot > - system: Linux / > > AFAIK the UEFI spec requires that the EFI system partition (ESP) > is FAT-formatted. Most (probably all?) Linux package management > tooling assumes that files from packages are installed onto > filesystems that support POSIX semantics, including hardlinks, > which FAT does not. This means that distributions cannot re-use > an EFI system partition as /boot and therefore need a partition > for /boot and an additional ESP (AFAIK commonly mounted to > /boot/efi). I would therefore like to propose adding a small > separate partition for use as ESP. The original intent of the "boot" partition wasn't really to store /boot, but to be a FAT partition to store the environment + whatever data needed for the EFI partition. Maybe we can rename it if it's confusing? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi, Here is a set of patches that have been sitting in some variations for quite some time now. This is mostly to ease the eMMC (and MMC, to some extent) flashing using fastboot that in turn rely on GPT. The Allwinner SoCs need to have the SPL located right in the middle of a traditional GPT, at 8kB. To deal with this, we would basically have two options: - Use the already in-tree solution to move the partition entries to another arbitrary offset in the MMC. - Use a smaller number of partitions entries Both are non-standards, but are dealt with nicely by the regular tools and users (at least on a Linux system). However, the first solution is quite confusing for users (that needs to be aware where the partitions will be), might be less flexible because not all tools will allow to create partitions for things between the GPT main entry and the partition entries, and might confuse tools if such a setup is available. In our case, using the first solution, gdisk will for example refuse to create a partition for the SPL. The second solution though seems to be well handled by all the tools, and just feels the same, except that you end up with a smaller number of partitions. In our case, that number is 56 partitions (16 sectors before the SPL, 1 sector for the protective MBR, 1 sector for the GPT header, and 4 partition entries per sector) instead of 128, which doesn't sound very impractical either. The two first patches deal with that. We then provide a default partitionning scheme. I'd like feedback on that one. I appreciate that having a good default in such a case, but I'd like to have a reasonably simple layout that works good enough to install a distro. I'm a bit short on background on what an EFI partition is supposed to look like, and what a good size would be. I'd really like some input on this. Finally, we enable fastboot flashing to be able to flash a pristine system just by using FEL, fastboot oem format, and then fastboot flash for the various components. Let me know what you think, Maxime Maxime Ripard (4): part: efi: Add a Kconfig option for the number of partition entries part: efi: Add default number of partition entries for sunxi sunxi: Add default partition scheme fastboot: Enable flashing by default on sunxi cmd/fastboot/Kconfig | 1 + disk/Kconfig | 14 ++++++++++++++ include/configs/sunxi-common.h | 7 +++++++ include/part_efi.h | 2 +- 4 files changed, 23 insertions(+), 1 deletion(-)