From: Tom Rini <trini@konsulko.com>
To: Bin Meng <bmeng@tinylab.org>
Cc: Simon Glass <sjg@chromium.org>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>,
Bin Meng <bmeng.cn@gmail.com>, Heiko Schocher <hs@denx.de>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Jaehoon Chung <jh80.chung@samsung.com>,
Johan Jonker <jbx6244@gmail.com>,
Joshua Watt <jpewhacker@gmail.com>, Marek Vasut <marex@denx.de>,
Mattijs Korpershoek <mkorpershoek@baylibre.com>,
Michal Suchanek <msuchanek@suse.de>, Peng Fan <peng.fan@nxp.com>,
Tobias Waldekranz <tobias@waldekranz.com>
Subject: Re: [PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size
Date: Tue, 10 Oct 2023 21:49:22 -0400 [thread overview]
Message-ID: <20231011014922.GA567787@bill-the-cat> (raw)
In-Reply-To: <20230926084346.2237483-1-bmeng@tinylab.org>
[-- Attachment #1: Type: text/plain, Size: 3567 bytes --]
On Tue, Sep 26, 2023 at 04:43:30PM +0800, 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.
>
> Test log (512 block size):
>
> => host bind 0 test.img
> => host info
> dev blocks blksz label path
> 0 262144 512 0 test.img
> => blkmap create 0
> Created "0"
> => blkmap map 0 0 40000 linear host 0 0
> Block 0x0+0x40000 mapped to block 0x0 of "host 0"
> => blkmap info
> Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
> Type: Hard Disk
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> => blkmap part
>
> Partition Map for BLKMAP device 0 -- Partition Type: EFI
>
> Part Start LBA End LBA Name
> Attributes
> Type GUID
> Partition GUID
> 1 0x00000022 0x000000bd "u-boot-spl"
> attrs: 0x0000000000000000
> type: 5b193300-fc78-40cd-8002-e86c45580b47
> (5b193300-fc78-40cd-8002-e86c45580b47)
> guid: 0bb6bb6e-4aac-4c27-be03-016b01e7b941
> 2 0x00000822 0x00000c84 "u-boot"
> attrs: 0x0000000000000000
> type: 2e54b353-1271-4842-806f-e436d6af6985
> (2e54b353-1271-4842-806f-e436d6af6985)
> guid: 91d50814-8e31-4cc0-97dc-779e1dc59056
> 3 0x00000c85 0x0000cc84 "rootfs"
> attrs: 0x0000000000000004
> type: 0fc63daf-8483-4772-8e79-3d69d8477de4
> (linux)
> guid: 42799722-6e55-46e6-afa9-529e7af3f03b
>
> Test log (4096 block size):
>
> => host bind 0 test.img 4096
> => host info
> dev blocks blksz label path
> 0 32768 4096 0 test.img
> => blkmap create 0
> Created "0"
> => blkmap map 0 0 8000 linear host 0 0
> Block 0x0+0x8000 mapped to block 0x0 of "host 0"
> => blkmap info
> Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
> Type: Hard Disk
> Capacity: 128.0 MB = 0.1 GB (32768 x 4096)
> => blkmap part
>
> Partition Map for BLKMAP device 0 -- Partition Type: EFI
>
> Part Start LBA End LBA Name
> Attributes
> Type GUID
> Partition GUID
> 1 0x00000100 0x00001fff "primary"
> attrs: 0x0000000000000000
> type: 0fc63daf-8483-4772-8e79-3d69d8477de4
> (linux)
> guid: eba904d7-72c1-4dbd-bb4e-36be49cba5e3
> 2 0x00002000 0x00007ffa "primary"
> attrs: 0x0000000000000000
> type: 0fc63daf-8483-4772-8e79-3d69d8477de4
> (linux)
> guid: c48c360e-db47-46da-ab87-26416fad3cd3
With minor changes to apply again, applied to u-boot/master, thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2023-10-11 1:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 8:43 [PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size Bin Meng
2023-09-26 8:43 ` [PATCH 01/15] blk: Use a macro for the typical " Bin Meng
2023-10-02 1:16 ` Simon Glass
2023-09-26 8:43 ` [PATCH 02/15] cmd: host: Mandate the filename parameter in the 'bind' command Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 03/15] blk: sandbox: Support binding a device with a given logical block size Bin Meng
2023-09-26 8:43 ` [PATCH 04/15] blk: host_dev: Make host_sb_detach_file() and host_sb_ops static Bin Meng
2023-10-02 1:16 ` Simon Glass
2023-09-26 8:43 ` [PATCH 05/15] blk: host_dev: Sanity check on the size of host backing file Bin Meng
2023-10-02 1:16 ` Simon Glass
2023-09-26 8:43 ` [PATCH 06/15] cmd: host: Print out the block size of the host device Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 07/15] blk: blkmap: Make bind/unbind routines static Bin Meng
2023-10-02 1:16 ` Simon Glass
2023-09-26 8:43 ` [PATCH 08/15] cmd: blkmap: Make map_handlers[] and its .fn static Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 09/15] blk: blkmap: Support mapping to device of any block size Bin Meng
2023-09-26 19:29 ` Tobias Waldekranz
2023-09-26 22:44 ` Bin Meng
2023-10-02 1:16 ` Simon Glass
2023-09-26 8:43 ` [PATCH 10/15] cmd: blk_common: Use macros for the return values Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-10-10 9:05 ` Bin Meng
2023-10-10 14:58 ` Simon Glass
2023-10-10 20:17 ` Tom Rini
2023-09-26 8:43 ` [PATCH 11/15] dm: blk: Rename get_desc() and make it externally visible Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 12/15] cmd: blk_common: Stop using hard-coded block size for Sandbox operations Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 13/15] dm: blk: Drop blk_{read,write}_devnum() Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 14/15] disk: part: Print out the unknown device uclass id Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:43 ` [PATCH 15/15] disk: part: Handle blkmap device in print_part_header() Bin Meng
2023-10-02 1:17 ` Simon Glass
2023-09-26 8:58 ` [PATCH 00/15] blk: sandbox: Support binding a device with a given logical block size Heinrich Schuchardt
2023-09-26 14:11 ` Bin Meng
2023-10-11 1:49 ` Tom Rini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231011014922.GA567787@bill-the-cat \
--to=trini@konsulko.com \
--cc=abdellatif.elkhlifi@arm.com \
--cc=bmeng.cn@gmail.com \
--cc=bmeng@tinylab.org \
--cc=hs@denx.de \
--cc=jbx6244@gmail.com \
--cc=jh80.chung@samsung.com \
--cc=jpewhacker@gmail.com \
--cc=marex@denx.de \
--cc=mkorpershoek@baylibre.com \
--cc=msuchanek@suse.de \
--cc=peng.fan@nxp.com \
--cc=sjg@chromium.org \
--cc=tobias@waldekranz.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).