Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)
Brought to you by:
srs5694
Menu
▾
▴
Re: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)
|
From: Priebe, S. <Seb...@ca...> - 2017-07-21 05:58:40
|
Hello Rod,
I agree with you that this can cause confusion. But there are hard restrictions by the SOCs and the GPT concept provides all mechanisms to do what it needed. So, why not let the user of gptfdisk configure it? You can put all this stuff in the experts section and leave the "normal" user with the defaults.
I was thinking of you objections: is it possible to put a partitions at LBA 2? That's what I need to do. With the possibility to move the PTEs itself (e.g. to LBA 512), it should be possible to put a partition infront of the PTEs, right?
Nevertheless, the option to put the PTEs to a configurable LBA (not 2) is very needed.
Greetings,
Sebastian
-------------------------------------------------
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: Donnerstag, 20. Juli 2017 19:52
An: Priebe, Sebastian <Seb...@ca...>; gpt...@li...
Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2)
On 07/20/2017 10:20 AM, Priebe, Sebastian wrote:
> That is another good point.
>
> I would love the possibility to configure the start sector of the
> first partition located at offset 40 in the GPT header independently
> of the number of partitions.
>
> Currently it is calculated from the number of partitions.
Why? This gets back to my first objection, when I misunderstood the point of the patch. If you're just blocking off space between the first partition table and the first partition, then a partition is the appropriate way to reserve that space. Using a partition makes it plain that the space is in use and can provide some clue (through the partition type code and/or description) of what its purpose is.
Rendering a set of blocks unusable by normal partitions and useless to GPT itself just invites confusion and conflicts in how it might be used.
> *Von:*Johan Myréen [mailto:joh...@gm...]
> *Gesendet:* Mittwoch, 19. Juli 2017 18:57
> *An:* gpt...@li...
> *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between
> Partition Header(LBA1) and Entries(LBA2)
>
>
>
> 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...
> <mailto: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.
>
>
> >
>
> CADCON
> Ingenieurgesellschaft mbH & Co. KG
> Geschaeftsfuehrer: Robert Bauer
> Sitz der Gesellschaft: 86368 Gersthofen
> Registergericht: Amtsgericht Augsburg HRA 14521
>
> ------------------------------------------------- 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...
> <mailto:rod...@ro...>] Gesendet: Dienstag, 18.
> > Juli 2017 20:24 An: gpt...@li...
> <mailto:gpt...@li...>; Priebe,
> > Sebastian <Seb...@ca...
> <mailto: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...
> <mailto:rod...@ro...> http://www.rodsbooks.com
> >
>
>
> --
> Rod Smith
> rod...@ro... <mailto: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...
> <mailto:Gpt...@li...>
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general
>
>
>
--
Rod Smith
rod...@ro...
http://www.rodsbooks.com
|
