On Mon, Jul 2, 2018 at 11:59 PM Alexander Graf <[email protected]> wrote: > > > > On 02.07.18 20:40, William Mills wrote: > > > > > > On 07/02/2018 12:15 PM, Daniel Thompson wrote: > >> On Sun, Jul 01, 2018 at 10:37:49AM -0400, William Mills wrote: > >>> All, > >>> > >>> I rely on your greater knowledge to help me understand these questions. > >>> Thanks in advance. > >>> > >>> 1) GPT and block size > >>> 1A) By querying the device > >>> 1B) Some MBR magic? > >> > >> There's some comments in the fdisk man page that recent Linux kernels > >> "just knows" the sector size and the code to work with GPT partitions in > >> the kernel (block/partitions/efi.c ) will error out of MyLBA does not > >> match the LBA the kernel thinks it is. This means that (unless there' > >> s some fallback code at a layer above the partition parsing code) > >> then if you copy a GPT to a disk with a different sector size it will > >> be broken. > > > > I'm not sure we have seen 4K block devices much in the wild yet have we? > > I think most vendors are just publishing suggested read & write sizes > > and leaving the "block size" set at 512. > > FWIW most (all?) hard drive vendors went back to 512 logical, 4k > physical. But let me CC Hannes to confirm this. > > > > > (I don't really know why the LBA size needs to change in the first > > place. Is 16,777,216 TB not enough for a few years? Drives already > > publish enough info for OS'es not to dumb things.) > > > >> > >> Not sure that matters much though: if you want to fix it up you would > >> arrange for the fixup logic to be part of your initramfs. > >> > > > > Yes, initramfs would be a good place to fix this. But it means firmware > > must deal with it. We can make U-boot handle this but what does > > tianocore do? > > This is pretty much how we do all our images today. It works in both > Tianocore and U-Boot. We also do resize the image on first boot to the > actual target disk size inside initramfs. Works like a charm. > > > > >> > >>> 2) Can GPT be grown? > >> > >> If the backup table is not found at the end of the disk then Linux will > >> log in the dmesg trace that the partition table is damaged but I think > >> will use it nevertheless. > >> > >> Tools like fdisk are typically "uneasy" when why cannot find the > >> backup GPT header and will offer recreate it if you let then. IIRC > >> it basically marks the partition table dirty regardless of whether you > >> have changed it or not (so that it will get updated if you > >> write-and-exit). > >> > > > > fdisk is uneasy if it can't find it via AlternateLBA or is uneasy if > > that is not the end of the disk? > > > > Yesterday I did find language in the UEFI spec (5.3.2 GPT Header) that > > talks about what happens when a volume grows so it is an expected case. > > (They were talking about RAID disks but the same principle applies.) > > > > The wording is a bit strange in the spec. It says its up to platform > > policy whether it automatically restores the primary GPT with out asking > > the user but then says it should ask the user. If is not clear if they > > are talking about the UEFI firmware, the OS during normal boot, or a > > disk tool like fdisk. > > > > > >> > >>> 3) Is it actually required that the partition array start at LBA2? > >> > >> I don't think so, although you'd probably have to author it (or modify a > >> template) by hand. > >> > >> Assuming the code to validate the primary and backup partition tables is > >> shared (e.g. properly decomposed into functions) the code will naturally > >> end up honouring PartitionEntryLBA. > >> > >> BTW this last question made me realize that: > >> > >> a) one of the boards we've always believed to have a boot ROM that > >> mandated MBR might just have a workaround > >> > >> b) I might have overlooked something in the EBBR text about protective > >> partitioning (a.k.a. is it OK to place the system firmware > >> outside the FirstUsableLBA). > >> > >> > >> Daniel. > >> > >> > >> PS Is this merely of academic (or vendor) interest or are you cooking up > >> some crazy addendum for EBBR? > >> > > > > I don't think this is academic at all. If the size of LBA is going to > > start changing on devices we see in the field, we should understand the > > consequences. > > From what I can tell it's not going to change any time soon. Even my > shiny NVMe shows up as 512 byte sector size. > > The only case where I'm not sure which direction we'll see things moving > are NV-DIMMs. There running with PAGE_SIZE == LBA size seems intuitive. > > > The instructions for boards today are to use dd or Win32DiskWriter. > > This works if your writing to a USB stick, an SD Card, a hard disk, or > > an SSD. It works if the image provider is suppling a whole hard disk > > like image or an iso. > > > > The instructions for most OS's even for x86 is to download the .iso and > > dd it to a USB stick. (Actually using a CD/DVD does take extra software). > > > > If dd works for the legacy boot methods but EBBR compliance requires a > > special USB writer, then I would assume everyone would just stay with > > the legacy stuff. > > > > Perhaps it will only be SSDs that change the LBA size or perhaps no one > > will. However, I think I did see wording in the eMMC spec about the > > block size changing in the future. Does that mean SD will change also? > > > > Even if the block size changes will the OS layers hide it? The real > > sector size on CDs is 2048 but linux reports 512 to me. > > That's because the iso9660 driver in Linux (and U-Boot) simply ignores > the actual sector size ;). > > > I am still trying to figure out if a real issue exists or will soon > > exist. If this issue is real, I think it should be addressed in UEFI > > but if not there then in EBBR. We move "disks" around a lot more than > > other people do. > > Yes, let's double check with Hannes :).
On Dragonboard 820c, that has on board UFS disk: Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 6335488 sectors, 24.2 GiB Model: THGBF7G8K4LBATRB Sector size (logical/physical): 4096/4096 bytes > > > Alex > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
