Hi Heinrich,
On Tue, Sep 26, 2023 at 4:58 PM Heinrich Schuchardt xypron.glpk@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