linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jens Axboe <axboe@kernel.dk>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Micha?? Miros??aw <mirq-linux@rere.qmqm.pl>,
	David Heidelberg <david@ixit.cz>,
	Peter Geis <pgwipeout@gmail.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Christoph Hellwig <hch@infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ion Agorria <AG0RRIA@yahoo.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>,
	linux-tegra@vger.kernel.org, linux-block@vger.kernel.org,
	linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH v1 3/3] partitions/efi: Support gpt_sector parameter needed by NVIDIA Tegra devices
Date: Mon, 29 Mar 2021 21:38:57 +0300	[thread overview]
Message-ID: <134f84a2-94e8-9f82-eb3e-8ec90fafe581@gmail.com> (raw)
In-Reply-To: <20210329173151.urs4x36m3bq6txrf@offworld>

29.03.2021 20:31, Davidlohr Bueso пишет:
> On Sun, 28 Mar 2021, Dmitry Osipenko wrote:
> 
>> All NVIDIA Tegra20..124 Android devices use proprietary bootloader
>> which supplies the gpt_sector=<sector> kernel cmdline parameter that
>> should be used for looking up the EFI partition table on internal EMMC
>> storage.  If the kernel cmdline parameter isn't supplied, then the
>> partition is expected to be placed around the last but one sector of
>> EMMC.
>>
>> Apparently this was done in order to hide the PT from a usual userspace
>> tools since EFI entry exists only for compatibility with a Linux kernel,
>> while a custom proprietary partition table is what is really used by
>> these Android devices, thus these tools may corrupt the real PT, making
>> device unbootable and very difficult to restore.
>>
>> Add support for the gpt_sector cmdline parameter which will be used
>> for finding EFI entry on internal EMMC storage of NVIDIA Tegra20+
>> devices.
> 
> Since this is proprietary and playing yucky games hiding the pt, why not
> just force for the fallback on Nvidia's side and always just use the entry
> at the end of the block device? I'm not loving introducing a generic
> parameter for an obscure ad-hoc feature.

I understand the reluctance to support the ad-hoc features, I wouldn't
want to support this myself if I was in yours position.  This all is
necessary solely in order to provide a good user experience using
mainline kernel on the consumer devices that have Tegra SoC inside.  A
more advanced users could bypass the secure boot restrictions and
reformat the partition table as they wish, but this is very involved.
The only reason I'm submitting these patches is to allow more people to
have fun with their devices running mainline Linux without a need to
bother with extra out-of-tree patches.

There are total four possible variants of the PT that I'm aware about:

1. GPT entry exists at the proper "backup" location in the end of a
block device.  Unfortunately only Nexus 7 is known to have this.

2. GPT entry exists at the give sector offset using the gpt_sector=<>
parameter.  This offset may or may not match the offset that we can
calculate based on EMMC boot offset.  This case is common for the vast
majority of devices.

3. GPT entry exists at the expected sector offset which is calculated
based on EMMC boot offset.  This is common for devices that use older
versions of NVIDIA bootloader which doesn't provide the gpt_sector=<>
parameter.

4. GPT entry doesn't exist at all and other means are used to convey the
partition table info.  This is rare, but happens for the oldest devices.
 Using a reversed-engineered tegra-partition format helps in this case.

Technically we could use the reversed-engineered tegra-partition without
caring about GPT at all, but this may result in a different number of a
visible partitions to the system in comparison to the GPT entry because
some of partitions may be hidden from the GPT, like partition where
media keys are stored and etc.  This could be confusing and quite
inconvenient when /dev/mmcblk0p4 becomes /dev/mmcblk0p6, so it's more
preferred to use the existing GPT entry.

      reply	other threads:[~2021-03-29 18:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27 21:20 [PATCH v1 0/3] Support EFI partition on NVIDIA Tegra devices Dmitry Osipenko
2021-03-27 21:20 ` [PATCH v1 1/3] mmc: core: Add raw_boot_mult field to mmc_ext_csd Dmitry Osipenko
2021-03-27 21:20 ` [PATCH v1 2/3] mmc: block: Add mmc_bdev_to_card() helper Dmitry Osipenko
2021-03-27 21:21 ` [PATCH v1 3/3] partitions/efi: Support gpt_sector parameter needed by NVIDIA Tegra devices Dmitry Osipenko
2021-03-29  6:18   ` Christoph Hellwig
2021-03-29 13:07     ` Dmitry Osipenko
2021-03-29 17:31   ` Davidlohr Bueso
2021-03-29 18:38     ` Dmitry Osipenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=134f84a2-94e8-9f82-eb3e-8ec90fafe581@gmail.com \
    --to=digetx@gmail.com \
    --cc=AG0RRIA@yahoo.com \
    --cc=adrian.hunter@intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=axboe@kernel.dk \
    --cc=clamor95@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=david@ixit.cz \
    --cc=hch@infradead.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=pgwipeout@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=thierry.reding@gmail.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).