Hi Alexey, On 2026-09-18T06:35:41, Alexey Charkov <[email protected]> wrote:
> Given that the normal use of this mechanism is for symmetric A/B boot, > real world scenarios will usually have both W-LU-A and W-LU-B provisioned > with identical geometry, so the geometry for the boot W-LU can be inferred > from the active boot LU, while its special 0xb0 LUN can still be used for > reads and writes to have the device itself abstract away the actual > request routing, even when the active boot LU is changed. Just to check, what is the benefit of sending the reads through LUN 0xb0? Patch 8 already reads bBootLunEn and walks the unit descriptors to find the real LU, so the host is doing the resolution anyway. SPL could pass that LUN to scsi_get_blk_by_lun() from patch 5 and load from an ordinary block device, with its own geometry. That follows the A/B switch just the same, since as far as I can see nothing in U-Boot writes bBootLunEn, so the active LU cannot change between the scan and the load. It also avoids most of the SCSI-core changes (the unit-attention retry, the W-LU list, the alias op and the borrowed geometry in patches 1-4) along with patches 6 and 9. The series would shrink to a UFS helper which reports the active boot LU, the lookup and the SPL change. If the W-LU must be used (e.g. for something the real LU cannot do), please can you explain why in the cover letter? What do you think? > This series adds support for loading the U-Boot proper from the boot W-LU, > allowing to use the native A/B boot mechanism without the need to hardcode > the "real" LUN in the SPL configuration. The effect is wider than SPL, though. Patch 9 adds the boot W-LU to the scan for every UFS controller, in U-Boot proper too, with no way to turn it off. If the W-LU approach stays, I think this needs to be opt-in; see my comments on that patch. > CI passes all green: The series adds new behaviour to the SCSI uclass but has no tests. I have made suggestions on the individual patches. Also, no board enables SPL_UFS_RAW_U_BOOT_USE_BOOT_WLUN, so nothing in the tree exercises the new path. The only SPL_UFS_SUPPORT users are rock-4d-rk3576 and nanopi-m5-rk3576. Is the plan to convert one of those, or add a new board? Some documentation would help as well, covering how the boot LUs need to be provisioned (bBootLunID, bBootLunEn), since the only description is in the Kconfig help. > 2. The scan itself needs to learn to look beyond the normal LUN range when > the implementation supports W-LUs, as they are numbered above 0x80, and > "borrow" the geometry from the physical LU the W-LU is aliased to > (patches 3-5) Patch 5 is the lookup helper used by the SPL loader, not part of the scan, so it is not really described here. Similarly, patch 1 is mostly a UFS-driver change rather than SCSI core. BTW I think you mean 'transient' rather than 'transitive' in item 1. Regards, Simon
