On Tue, Oct 12, 2021 at 05:37:45PM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 12 Oct 2021 at 15:13, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 12 Oct 2021 at 09:00, Tom Rini trini@konsulko.com wrote:
On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote:
Hi Takahiro,
On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro takahiro.akashi@linaro.org wrote:
The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot device model. In the past, I poposed a couple of patch series, the latest one[1], while Heinrich revealed his idea[2], and the approach taken here is something between them, with a focus on block device handlings.
# The code is a PoC and not well tested yet.
Disks in UEFI world:
In general in UEFI world, accessing to any device is performed through a 'protocol' interface which are installed to (or associated with) the device's UEFI handle (or an opaque pointer to UEFI object data). Protocols are implemented by either the UEFI system itself or UEFI drivers.
For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk hereafter). Currently, every efi_disk may have one of two origins: a.U-Boot's block devices or related partitions (lib/efi_loader/efi_disk.c) b.UEFI objects which are implemented as a block device by UEFI drivers. (lib/efi_driver/efi_block_device.c)
All the efi_diskss as (a) will be enumelated and created only once at UEFI subsystem initialization (efi_disk_register()), which is triggered by first executing one of UEFI-related U-Boot commands, like "bootefi", "setenv -e" or "efidebug". EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) in the corresponding udevice(UCLASS_BLK).
On the other hand, efi_disk as (b) will be created each time UEFI boot services' connect_controller() is executed in UEFI app which, as a (device) controller, gives the method to access the device's data, ie. EFI_BLOCK_IO_PROTOCOL.
>>> more details >>> Internally, connect_controller() search for UEFI driver that can support this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, then calls the driver's 'bind' interface, which eventually installs the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for
- creating additional partitions efi_disk's, and
- supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it.
<<< <<<
Issues:
While an efi_disk represents a device equally for either a whole disk or a partition in UEFI world, the device model treats only a whole disk as a real block device or udevice(UCLASS_BLK).
efi_disk holds and makes use of "blk_desc" data even though blk_desc in plat_data is supposed to be private and not to be accessed outside the device model. # This issue, though, exists for all the implmenetation of U-Boot # file systems as well.
Yes, this was a migration convenience and we should be able to unpick it now.
However we still have SPL_BLK so need to consider whether we can drop that.
To be clear here, in that I can hand-wave my way to seeing a use case for lib/efi_loader/ under SPL, it would not be in a world where we also still would be supporting the non-DM infrastructure, and is also not a near-term goal.
OK good. Perhaps we should add a migration method for SPL_BLK? It would be good to know where we are in terms of the size stuff. I don't see a lot of boards rushing to use of-platdata, though.
What do you mean? Since we have platforms that need to support 12 or 16 KiB of space for SPL, we're not going to enforce SPL_DM. But those platforms can / do need to boot from MMC (SD card I think usually).
In terms of platforms that could, but don't, enable SPL_BLK, that's just the platforms that disable SPL_BLK today as it defaults to enabled when possible.
Well I wonder if we can use of-platdata and DM then perhaps some of these will fit. The OMAP platform I sent patches for was close to complete, I think, and I believe that was one of the tightest. Actually I cannot remember what board that was...
The overhead is perhaps 7KB though, so maybe not suitable for 16KB.
It's only disabled on the vboot config, on am335x platforms. Honestly, I would suggest a separate thread and ask the board maintainers in question why specifically it's off. I know for am335x_boneblack_vboot_defconfig it's inadvertent, it could be turned on no problem I suspect.