Hi Heinrich, On Tue, Sep 26, 2023 at 4:58 PM Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > On 9/26/23 10:43, Bin Meng wrote: > > At present on Sandbox when binding to a host backing file, the host > > block device is created with a hard-coded 512 bytes block size. > > > > Such assumption works for most cases, but for situation that with a raw > > image file dump from a pre-formatted GPT partitioned disk image from a > > 4KiB block size device, when binding this file to a host device and mapping > > this device to a blkmap, "blkmap" command like "blkmap part" won't work > > correctly, due to block size mismatch during parsing the partition table. > > > > This series updates Sandbox block driver, as well as the blkmap driver, > > to get rid of the hard-coded 512 bytes block size assumption. > > > > This series is available at u-boot-x86/blk for testing. > > It is really good to have an easy way to test other block sizes. > > We can also use QEMU for alternative block sizes: > > $ qemu-system-riscv64 -device nvme,help > logical_block_size=<size> > physical_block_size=<size>
Yeah, please report any issue you find. > > In the commit messages, please, make it clear that you refer to logical > block sizes and not to the physical block size. For drivers we rarely care about physical_block_size as they always operate on LBA. But I can write it down clearly that logical block size is used. Regards, Bin
