Re: [BUG] efi_loader: incorrect creation of device paths

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

On Sat, Nov 20, 2021 at 01:54:30PM +0100, Heinrich Schuchardt wrote:
> Hello Takahiro,
> 
> in a prior mail we have discussed the creation of device paths for USB
> mass storage devices.
> 
> On the sand boxyou get the following devices after 'usb start':
> 
>  Class     Index  Probed  Driver                Name
> -----------------------------------------------------------
>  usb           0  [ + ]   usb_sandbox           |-- usb@1
>  usb_hub       0  [ + ]   usb_hub               |   `-- hub
>  usb_mass_s    0  [ + ]   usb_mass_storage      |       |--
> usb_mass_storage
>  blk           3  [   ]   usb_storage_blk       |       |   `--
> usb_mass_storage.lun0
>  usb_mass_s    1  [ + ]   usb_mass_storage      |       |--
> usb_mass_storage
>  blk           4  [   ]   usb_storage_blk       |       |   `--
> usb_mass_storage.lun0
>  usb_mass_s    2  [ + ]   usb_mass_storage      |       `--
> usb_mass_storage
>  blk           5  [   ]   usb_storage_blk       |           `--
> usb_mass_storage.lun0
> 
> For of these storage devices we try to create the same device path which
> is not allowable:
> 
> => usb start
> starting USB...
> Bus usb@1: scanning bus usb@1 for devices... 5 USB Device(s) found
>        scanning usb for storage devices... 3 Storage Device(s) found
> =>
> => efidebug dh
> Scanning disk mmc2.blk...
> handle 0000000015e34f00,
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)
> Scanning disk mmc1.blk...
> handle 0000000015e36b30,
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)
> Scanning disk mmc0.blk...
> handle 0000000015e35b00,
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(2)
> Scanning disk usb_mass_storage.lun0...
> handle 0000000015e35c10,
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0)
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> BTRFS: superblock end 69632 is larger than device size 512
> Scanning disk usb_mass_storage.lun0...
> handle 0000000015e361f0,
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0)
> ERROR: failure to add disk device usb_mass_storage.lun0, r = 20
> Error: Cannot initialize UEFI sub-system, r = 20
> 
> I will provide a patch that will allow the first USB device to be used
> and avoids stopping the boot process. But we really have to walk the dm
> tree to create a device patch for USB devices based on port IDs.
> 
> We should add a new field to struct uclass_driver:
> 
> struct efi_device_path *get_node(udevice *dev);
> 
> This function shall return a pointer to an freshly allocated buffer with
> the device node for the device. To build the devicepath we can then walk
> the dm tree.

I'm not sure this is an acceptable solution.

Let me make sure:
The goal would be to create a device path like
   .../USB(0x1,0x0)/HD(1,...)
instead of
   .../UsbHub(0x0,0x0,0x0,0x3)/UsbMassStorage(0x46f4,0x1,0x0,0x0)/HD(1,...)
as we already see this format for SCSI:
   .../Scsi(0,0)/HD(1,..)

Right?

-Takahiro Akashi
      
   


> To make migration easier: If the function pointer or the return value is
> NULL we can create a CTRL() node as dummy using the uclass_id and the
> device number.
> 
> Best regards
> 
> Heinrich