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: Johan M. <joh...@gm...> - 2017-07-21 07:08:18
|
In summary: we all seem to agree that creating a partition for the data read by the SoC ROM is a good idea. What we need in this case is a layout that looks like this: Protective MBR+GPT Header - 1st partition - Partition Entry Table - Rest of the partitions. On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca...> wrote: > 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 > > ------------------------------------------------------------ > ------------------ > 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 > |
