Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)

[Johan M. <joh...@gm...>]

For the record: when booting from an SD card, the ROM in Allwinner SoCs
loads 32 kB of code starting at 8 kB. This makes it possible to use a
shorter, non-standard partition table, but of course it would be nicer to
be able to avoid hacks like this.

On 19 July 2017 at 16:27, Rod Smith <rod...@ro...> wrote:

> On 07/19/2017 02:16 AM, Priebe, Sebastian wrote:
> > Hello Rod,
> >
> > thx for your quick reply.
> >
> > To your first problem point: Many SOCs don't care about any
> > partitioning during their boot process. E.g. the Freescale (NXP) SOCs
> > I work with load the LBA block 2 into RAM and expect some special
> > proprietary data there.
>
> OK, thanks. I was mis-reading the code; I thought it was simply moving
> the first usable sector for partitions, not moving the partition table
> itself. If an SoC is stupid enough to require boot code at sector 2,
> then that conflicts with the standard GPT positioning, so moving it may
> be the only solution.
>
> > Currently the gptfdisk tools always put the
> > PTEs there. There is no way around that. I also don't like having
> > some "hidden" data on the disk, but that’s just the way it is. I also
> > don't see a way of putting bootcode in a partition for the Freescale
> > case as there are no free blocks available.
> >
> > I can't say anything to your other points, as I haven't looked into
> > the details yet.
>
> I'll give it some more thought. I'm now inclined to do something about
> this, whether it's accepting some variant of the patch or doing
> something else, liking a new option (analogous to the existing "e"
> option on the experts' menu) to relocate the main partition table entries.
>
> > ------------------------------------------------- Wir ziehen um! Ab
> > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, 86167
> > Augsburg -------------------------------------------------
> >
> > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert
> > Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht:
> > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche Nachricht----- Von:
> > Rod Smith [mailto:rod...@ro...] Gesendet: Dienstag, 18.
> > Juli 2017 20:24 An: gpt...@li...; Priebe,
> > Sebastian <Seb...@ca...> Betreff: Re:
> > [Gptfdisk-general] [PATCH] Support padding between Partition
> > Header(LBA1) and Entries(LBA2)
> >
> > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote:
> >> Hello,
> >>
> >> there was a mail to this list in March 2016 with a patch adding the
> >> option to change the starting LBA of the PTE (byte 72 in the GPT
> >> header):
> >> https://sourceforge.net/p/gptfdisk/mailman/message/34955352/
> >>
> >> Has somebody reviewed or tested that patch?
> >
> > I think I missed that the first time around.
> >
> >> As written in the original message this option is needed for many
> >> embedded devices as many SoC vendors tends to have their
> >> constraints on where to load its bootcode which may conflict with
> >> the default starting LBA (2) of GPT fdisk.
> >>
> >> Why has this patch not been included?
> >
> > After reviewing the code, I have a number of problems with it. Most
> > of these are minor, but the first is major:
> >
> > * I don't understand why this is needed. Why not create a partition
> > (a BIOS Boot Partition or something analogous) to hold the SoC boot
> > code? By disabling the 2048-sector alignment policy, such a partition
> > could easily be located starting at sector 34, which is the first
> > sector that would be safe to use anyway. This strikes me as a
> > superior solution compared to creating a significant chunk of the
> > disk that's "in limbo" -- neither allocated to partitions or official
> > GPT data structures nor available for allocation. It was the reckless
> > use of such space under MBR that led to numerous conflicts between
> > boot loaders and other low-level disk utilities with MBR and
> > BIOS-mode booting. Encouraging something similar with GPT strikes me
> > as a Bad Idea. * Creating a new "j" option on the experts' menu that
> > replicates what "o" does on the main menu would create confusion. *
> > The change to "o" on the main menu makes it harder to use. If this
> > functionality is really needed, that may be unavoidable -- or perhaps
> > a new function could be added to adjust this setting, leaving "o"
> > unaffected. * Perhaps adding "j" was done so that sgdisk's -o could
> > be left to work as it always has. If so, that might be better done
> > by adding an OPTIONAL parameter to -o. I'm not 100% sure that's
> > possible, though; I'd need to dig into the POPT documentation. * The
> > patch included no documentation changes. I could write that myself,
> > of course, but at a minimum, a description of when a non-standard
> > (that is, non-0) padding size is appropriate would be helpful, since
> > I'm unfamiliar with the SoC boot loaders that you say would benefit
> > from such a change.
> >
> > If you can make a case for why putting SoC boot loader code in a
> > partition, even if that means adjust the alignment policy, won't
> > work, then I'll consider this patch. If not, though, I think it's
> > best to reject this patch, since I don't want to contribute to old
> > BIOS/MBR problems infecting the EFI/GPT world.
> >
> > If a partition will do the job, but if you don't think the BIOS Boot
> > Partition is the right type code, then you can create such a GUID and
> > submit a patch that adds it. (It would help if you have some
> > authority in the field and can get buy-in for using that type code.)
> > There might even be ways to tweak the alignment code to minimize
> > problems from having a single unaligned partition on a disk, if
> > that's likely to be an issue.
> >
> > -- Rod Smith rod...@ro... http://www.rodsbooks.com
> >
>
>
> --
> Rod Smith
> rod...@ro...
> http://www.rodsbooks.com
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general
>