mbox series

[0/4] sunxi: Ease eMMC usage and flashing

Message ID cover.a6248c1657ca90ce628a45a0cbe56e745dfdb954.1511865262.git-series.maxime.ripard@free-electrons.com
Headers show
Series sunxi: Ease eMMC usage and flashing | expand

Message

Maxime Ripard Nov. 28, 2017, 10:34 a.m. UTC
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

Changes from v1:
  - Changed the boot partition name to ESP
  - Used default UUID for the rootfs and esp partitions

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 |  9 +++++++++
 include/part_efi.h             |  2 +-
 4 files changed, 25 insertions(+), 1 deletion(-)

base-commit: c253573f3e269fd9a24ee6684d87dd91106018a5

Comments

Maxime Ripard Nov. 28, 2017, 10:35 a.m. UTC | #1
On Tue, Nov 28, 2017 at 11:34:37AM +0100, Maxime Ripard wrote:
> 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.


That was meant to be a v2...

Thanks!
Maxime



-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com