[bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

u-boot 2022.07 boots fine without any USB devices attached to
RaspberryPi 2 however it hangs early on if external USB drive is
connected, right after:

   Request Sense returned 02 04 01

git bisect indicates first commit to cause regression is:

  8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
  commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
  Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
  Date:   Tue Mar 8 20:36:40 2022 +0900
  
      usb: storage: call device_probe() after scanning
  
      Every time a usb bus/port is scanned and a new device is detected,
      we want to call device_probe() as it will give us a chance to run
      additional post-processings for some purposes.
  
      In particular, support for creating partitions on a device will be added.
  
      Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: Simon Glass <sjg@chromium.org>

Reverting this commit fixes the issue.

Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
Also note that without this change 0 storage devices are detected even
when drive is attached.

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Simon Glass]

Hi Jan,

On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
>
> u-boot 2022.07 boots fine without any USB devices attached to
> RaspberryPi 2 however it hangs early on if external USB drive is
> connected, right after:
>
>    Request Sense returned 02 04 01
>
> git bisect indicates first commit to cause regression is:
>
>   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
>   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
>   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
>   Date:   Tue Mar 8 20:36:40 2022 +0900
>
>       usb: storage: call device_probe() after scanning
>
>       Every time a usb bus/port is scanned and a new device is detected,
>       we want to call device_probe() as it will give us a chance to run
>       additional post-processings for some purposes.
>
>       In particular, support for creating partitions on a device will be added.
>
>       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>       Reviewed-by: Simon Glass <sjg@chromium.org>
>
> Reverting this commit fixes the issue.
>
> Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> Also note that without this change 0 storage devices are detected even
> when drive is attached.

I am not sure what is going on here. Can you provide the full console
trace of the boot? Any idea where it is hanging?

Regards,
Simon

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

On 22.07.2022 02:59, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> >
> > u-boot 2022.07 boots fine without any USB devices attached to
> > RaspberryPi 2 however it hangs early on if external USB drive is
> > connected, right after:
> >
> >    Request Sense returned 02 04 01
> >
> > git bisect indicates first commit to cause regression is:
> >
> >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >   Date:   Tue Mar 8 20:36:40 2022 +0900
> >
> >       usb: storage: call device_probe() after scanning
> >
> >       Every time a usb bus/port is scanned and a new device is detected,
> >       we want to call device_probe() as it will give us a chance to run
> >       additional post-processings for some purposes.
> >
> >       In particular, support for creating partitions on a device will be added.
> >
> >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >       Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Reverting this commit fixes the issue.
> >
> > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > Also note that without this change 0 storage devices are detected even
> > when drive is attached.
> 
> I am not sure what is going on here. Can you provide the full console
> trace of the boot? Any idea where it is hanging?

It hangs very early on during USB start, log from USB initialization
with debug enabled:

  starting USB...
  Bus usb@7e980000: OF: translating address: 0000987e
  OF: parent translation for: 0000003f
  OF: one level translation: 0000983f
  0
     - 0 'gpio@7e200000'
     - found
  dwc2_usb usb@7e980000: set_state_simple op missing
  dwc2_usb usb@7e980000: Can't get reset: -524
  dwc2_usb usb@7e980000: Core Release: 2.80a
  USB DWC2
  Sending event 4/(unknown) to spy 'efi_disk add'
  scanning bus usb@7e980000 for devices... bind node usb1@1
     - attempt to match compatible string 'usb424,9514'
  No match for node 'usb1@1'
  0
     - 0 'gpio@7e200000'
     - found
  usb_hub usb_hub: set_state_simple op missing
  bind node usbether@1
     - attempt to match compatible string 'usb424,ec00'
  No match for node 'usbether@1'
  0
     - 0 'gpio@7e200000'
     - found
  usb_hub usb_hub: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
     - seq=0
  0
     - 0 'gpio@7e200000'
     - found
  smsc95xx_eth smsc95xx_eth: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
  Device NOT ready
     Request Sense returned 02 04 01

Now the place where it hangs is:

  part_efi.c:

  static int part_test_efi(struct blk_desc *dev_desc)
  {
          ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);

where dev_desc->blksz is 3782209548.

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

On 23.07.2022 16:19, Jan Palus wrote:
> On 22.07.2022 02:59, Simon Glass wrote:
> > Hi Jan,
> > 
> > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > >
> > > u-boot 2022.07 boots fine without any USB devices attached to
> > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > connected, right after:
> > >
> > >    Request Sense returned 02 04 01
> > >
> > > git bisect indicates first commit to cause regression is:
> > >
> > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > >
> > >       usb: storage: call device_probe() after scanning
> > >
> > >       Every time a usb bus/port is scanned and a new device is detected,
> > >       we want to call device_probe() as it will give us a chance to run
> > >       additional post-processings for some purposes.
> > >
> > >       In particular, support for creating partitions on a device will be added.
> > >
> > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > >
> > > Reverting this commit fixes the issue.
> > >
> > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > Also note that without this change 0 storage devices are detected even
> > > when drive is attached.
> > 
> > I am not sure what is going on here. Can you provide the full console
> > trace of the boot? Any idea where it is hanging?
> 
...
> 
> Now the place where it hangs is:
> 
>   part_efi.c:
> 
>   static int part_test_efi(struct blk_desc *dev_desc)
>   {
>           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> 
> where dev_desc->blksz is 3782209548.
> 

So it appears block size is read incorrectly? Should be 512 but not sure
where this value 3782209548 is coming from, it's not block capacity
either. After plugging in Linux reports:

  sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

On 23.07.2022 16:43, Jan Palus wrote:
> On 23.07.2022 16:19, Jan Palus wrote:
> > On 22.07.2022 02:59, Simon Glass wrote:
> > > Hi Jan,
> > > 
> > > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > > >
> > > > u-boot 2022.07 boots fine without any USB devices attached to
> > > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > > connected, right after:
> > > >
> > > >    Request Sense returned 02 04 01
> > > >
> > > > git bisect indicates first commit to cause regression is:
> > > >
> > > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > > >
> > > >       usb: storage: call device_probe() after scanning
> > > >
> > > >       Every time a usb bus/port is scanned and a new device is detected,
> > > >       we want to call device_probe() as it will give us a chance to run
> > > >       additional post-processings for some purposes.
> > > >
> > > >       In particular, support for creating partitions on a device will be added.
> > > >
> > > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > > >
> > > > Reverting this commit fixes the issue.
> > > >
> > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > > Also note that without this change 0 storage devices are detected even
> > > > when drive is attached.
> > > 
> > > I am not sure what is going on here. Can you provide the full console
> > > trace of the boot? Any idea where it is hanging?
> > 
> ...
> > 
> > Now the place where it hangs is:
> > 
> >   part_efi.c:
> > 
> >   static int part_test_efi(struct blk_desc *dev_desc)
> >   {
> >           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> > 
> > where dev_desc->blksz is 3782209548.
> > 
> 
> So it appears block size is read incorrectly? Should be 512 but not sure
> where this value 3782209548 is coming from, it's not block capacity
> either. After plugging in Linux reports:
> 
>   sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)

Since this was logged:

  Device NOT ready
     Request Sense returned 02 04 01

then it seems capacity/block size were never determined (happens right
after these log messages if they *don't* occur) so I guess they are
random values and this usb storage should never have been probed? I'll
stop here due to my cluelessness.

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Simon Glass]

Hi Jan,

On Sat, 23 Jul 2022 at 09:03, Jan Palus <jpalus@fastmail.com> wrote:
>
> On 23.07.2022 16:43, Jan Palus wrote:
> > On 23.07.2022 16:19, Jan Palus wrote:
> > > On 22.07.2022 02:59, Simon Glass wrote:
> > > > Hi Jan,
> > > >
> > > > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > > > >
> > > > > u-boot 2022.07 boots fine without any USB devices attached to
> > > > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > > > connected, right after:
> > > > >
> > > > >    Request Sense returned 02 04 01
> > > > >
> > > > > git bisect indicates first commit to cause regression is:
> > > > >
> > > > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > > > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > > > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > > > >
> > > > >       usb: storage: call device_probe() after scanning
> > > > >
> > > > >       Every time a usb bus/port is scanned and a new device is detected,
> > > > >       we want to call device_probe() as it will give us a chance to run
> > > > >       additional post-processings for some purposes.
> > > > >
> > > > >       In particular, support for creating partitions on a device will be added.
> > > > >
> > > > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Reverting this commit fixes the issue.
> > > > >
> > > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > > > Also note that without this change 0 storage devices are detected even
> > > > > when drive is attached.
> > > >
> > > > I am not sure what is going on here. Can you provide the full console
> > > > trace of the boot? Any idea where it is hanging?
> > >
> > ...
> > >
> > > Now the place where it hangs is:
> > >
> > >   part_efi.c:
> > >
> > >   static int part_test_efi(struct blk_desc *dev_desc)
> > >   {
> > >           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> > >
> > > where dev_desc->blksz is 3782209548.
> > >
> >
> > So it appears block size is read incorrectly? Should be 512 but not sure
> > where this value 3782209548 is coming from, it's not block capacity
> > either. After plugging in Linux reports:
> >
> >   sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
>
> Since this was logged:
>
>   Device NOT ready
>      Request Sense returned 02 04 01
>
> then it seems capacity/block size were never determined (happens right
> after these log messages if they *don't* occur) so I guess they are
> random values and this usb storage should never have been probed? I'll
> stop here due to my cluelessness.

Are you able to post the full console log? It should start with the
'U-Boot' banner and end with the hang

Takahiro-san, so you have any ideas?

Regards,
Simon

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

On 23.07.2022 10:42, Simon Glass wrote:
> Hi Jan,
> 
> On Sat, 23 Jul 2022 at 09:03, Jan Palus <jpalus@fastmail.com> wrote:
> >
> > On 23.07.2022 16:43, Jan Palus wrote:
> > > On 23.07.2022 16:19, Jan Palus wrote:
> > > > On 22.07.2022 02:59, Simon Glass wrote:
> > > > > Hi Jan,
> > > > >
> > > > > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > > > > >
> > > > > > u-boot 2022.07 boots fine without any USB devices attached to
> > > > > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > > > > connected, right after:
> > > > > >
> > > > > >    Request Sense returned 02 04 01
> > > > > >
> > > > > > git bisect indicates first commit to cause regression is:
> > > > > >
> > > > > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > > > > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > > > > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > > > > >
> > > > > >       usb: storage: call device_probe() after scanning
> > > > > >
> > > > > >       Every time a usb bus/port is scanned and a new device is detected,
> > > > > >       we want to call device_probe() as it will give us a chance to run
> > > > > >       additional post-processings for some purposes.
> > > > > >
> > > > > >       In particular, support for creating partitions on a device will be added.
> > > > > >
> > > > > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > > >
> > > > > > Reverting this commit fixes the issue.
> > > > > >
> > > > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > > > > Also note that without this change 0 storage devices are detected even
> > > > > > when drive is attached.
> > > > >
> > > > > I am not sure what is going on here. Can you provide the full console
> > > > > trace of the boot? Any idea where it is hanging?
> > > >
> > > ...
> > > >
> > > > Now the place where it hangs is:
> > > >
> > > >   part_efi.c:
> > > >
> > > >   static int part_test_efi(struct blk_desc *dev_desc)
> > > >   {
> > > >           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> > > >
> > > > where dev_desc->blksz is 3782209548.
> > > >
> > >
> > > So it appears block size is read incorrectly? Should be 512 but not sure
> > > where this value 3782209548 is coming from, it's not block capacity
> > > either. After plugging in Linux reports:
> > >
> > >   sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
> >
> > Since this was logged:
> >
> >   Device NOT ready
> >      Request Sense returned 02 04 01
> >
> > then it seems capacity/block size were never determined (happens right
> > after these log messages if they *don't* occur) so I guess they are
> > random values and this usb storage should never have been probed? I'll
> > stop here due to my cluelessness.
> 
> Are you able to post the full console log? It should start with the
> 'U-Boot' banner and end with the hang

Sure. Full log without debug logging:

  U-Boot 2022.07 (Jul 23 2022 - 20:53:41 +0200)
  
  DRAM:  832 MiB
  RPI 2 Model B (0xa01041)
  Core:  64 devices, 14 uclasses, devicetree: embed
  MMC:   mmc@7e202000: 0
  Loading Environment from FAT... Unable to read "uboot.env" from
  mmc0:1... 
  In:    serial
  Out:   vidconsole
  Err:   vidconsole
  Net:   No ethernet found.
  starting USB...
  Bus usb@7e980000: USB DWC2
  scanning bus usb@7e980000 for devices... Device NOT ready
     Request Sense returned 02 04 01

And with debug logging:

  U-Boot 2022.07 (Jul 23 2022 - 20:58:39 +0200)
  
  DRAM:  size=18, ptr=388, limit=400: 7fffe50
  size=4, ptr=38c, limit=400: 7fffe68
  832 MiB
  bind node aliases
  Device 'aliases' has no compatible string
  bind node chosen
  Device 'chosen' has no compatible string
  bind node reserved-memory
  Device 'reserved-memory' has no compatible string
  bind node thermal-zones
  Device 'thermal-zones' has no compatible string
  bind node soc
     - attempt to match compatible string 'simple-bus'
     - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
  bind node timer@7e003000
     - attempt to match compatible string 'brcm,bcm2835-system-timer'
  No match for node 'timer@7e003000'
  bind node txp@7e004000
     - attempt to match compatible string 'brcm,bcm2835-txp'
  No match for node 'txp@7e004000'
  bind node cprman@7e101000
     - attempt to match compatible string 'brcm,bcm2835-cprman'
  No match for node 'cprman@7e101000'
  bind node mailbox@7e00b880
     - attempt to match compatible string 'brcm,bcm2835-mbox'
  No match for node 'mailbox@7e00b880'
  bind node gpio@7e200000
     - attempt to match compatible string 'brcm,bcm2835-gpio'
     - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches 'brcm,bcm2835-gpio'
  bind node serial@7e201000
     - attempt to match compatible string 'arm,pl011'
     - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011'
     - seq=0
  bind node mmc@7e202000
     - attempt to match compatible string 'brcm,bcm2835-sdhost'
     - found match at 'bcm2835-sdhost': 'brcm,bcm2835-sdhost' matches 'brcm,bcm2835-sdhost'
  bind node i2c@7e205000
     - attempt to match compatible string 'brcm,bcm2835-i2c'
  No match for node 'i2c@7e205000'
  bind node aux@7e215000
     - attempt to match compatible string 'brcm,bcm2835-aux'
  No match for node 'aux@7e215000'
  bind node pwm@7e20c000
     - attempt to match compatible string 'brcm,bcm2835-pwm'
  No match for node 'pwm@7e20c000'
  bind node hvs@7e400000
     - attempt to match compatible string 'brcm,bcm2835-hvs'
  No match for node 'hvs@7e400000'
  bind node i2c@7e804000
     - attempt to match compatible string 'brcm,bcm2835-i2c'
  No match for node 'i2c@7e804000'
  bind node usb@7e980000
     - attempt to match compatible string 'brcm,bcm2835-usb'
     - found match at 'dwc2_usb': 'brcm,bcm2835-usb' matches 'brcm,bcm2835-usb'
  bind node usb1@1
     - attempt to match compatible string 'usb424,9514'
  No match for node 'usb1@1'
  bind node dma@7e007000
     - attempt to match compatible string 'brcm,bcm2835-dma'
  No match for node 'dma@7e007000'
  bind node interrupt-controller@7e00b200
     - attempt to match compatible string 'brcm,bcm2836-armctrl-ic'
  No match for node 'interrupt-controller@7e00b200'
  bind node watchdog@7e100000
     - attempt to match compatible string 'brcm,bcm2835-pm'
     - attempt to match compatible string 'brcm,bcm2835-pm-wdt'
  No match for node 'watchdog@7e100000'
  bind node rng@7e104000
     - attempt to match compatible string 'brcm,bcm2835-rng'
  No match for node 'rng@7e104000'
  bind node pixelvalve@7e206000
     - attempt to match compatible string 'brcm,bcm2835-pixelvalve0'
  No match for node 'pixelvalve@7e206000'
  bind node pixelvalve@7e207000
     - attempt to match compatible string 'brcm,bcm2835-pixelvalve1'
  No match for node 'pixelvalve@7e207000'
  bind node thermal@7e212000
     - attempt to match compatible string 'brcm,bcm2836-thermal'
  No match for node 'thermal@7e212000'
  bind node i2c@7e805000
     - attempt to match compatible string 'brcm,bcm2835-i2c'
  No match for node 'i2c@7e805000'
  bind node vec@7e806000
     - attempt to match compatible string 'brcm,bcm2835-vec'
  No match for node 'vec@7e806000'
  bind node pixelvalve@7e807000
     - attempt to match compatible string 'brcm,bcm2835-pixelvalve2'
  No match for node 'pixelvalve@7e807000'
  bind node hdmi@7e902000
     - attempt to match compatible string 'brcm,bcm2835-hdmi'
     - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches 'brcm,bcm2835-hdmi'
  bind node v3d@7ec00000
     - attempt to match compatible string 'brcm,bcm2835-v3d'
  No match for node 'v3d@7ec00000'
  bind node gpu
     - attempt to match compatible string 'brcm,bcm2835-vc4'
  No match for node 'gpu'
  bind node local_intc@40000000
     - attempt to match compatible string 'brcm,bcm2836-l1-intc'
  No match for node 'local_intc@40000000'
  bind node firmware
     - attempt to match compatible string 'raspberrypi,bcm2835-firmware'
     - attempt to match compatible string 'simple-mfd'
     - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
  bind node power
     - attempt to match compatible string 'raspberrypi,bcm2835-power'
  No match for node 'power'
  bind node mailbox@7e00b840
     - attempt to match compatible string 'brcm,bcm2836-vchiq'
     - attempt to match compatible string 'brcm,bcm2835-vchiq'
  No match for node 'mailbox@7e00b840'
  bind node clocks
  Device 'clocks' has no compatible string
  bind node phy
     - attempt to match compatible string 'usb-nop-xceiv'
  No match for node 'phy'
  bind node arm-pmu
     - attempt to match compatible string 'arm,cortex-a7-pmu'
  No match for node 'arm-pmu'
  bind node timer
     - attempt to match compatible string 'arm,armv7-timer'
  No match for node 'timer'
  bind node cpus
  Device 'cpus' has no compatible string
  bind node leds
     - attempt to match compatible string 'gpio-leds'
  No match for node 'leds'
  bind node memory@0
  Device 'memory@0' has no compatible string
  bind node smbios
     - attempt to match compatible string 'u-boot,sysinfo-smbios'
     - found match at 'sysinfo_smbios': 'u-boot,sysinfo-smbios' matches 'u-boot,sysinfo-smbios'
  bind node smbios
  Device 'smbios' has no compatible string
  bind node __symbols__
  Device '__symbols__' has no compatible string
  bind node clk-osc
     - attempt to match compatible string 'fixed-clock'
  No match for node 'clk-osc'
  bind node clk-usb
     - attempt to match compatible string 'fixed-clock'
  No match for node 'clk-usb'
  0
     - 0 'gpio@7e200000'
     - found
  0
     - 0 'gpio@7e200000'
     - found
  pinconfig gpioout: set_state_simple op missing
  0
     - 0 'gpio@7e200000'
     - found
  pinconfig alt0: set_state_simple op missing
  0
     - 0 'gpio@7e200000'
     - found
  pinconfig i2s_alt0: set_state_simple op missing
  simple_bus soc: set_state_simple op missing
  RPI 2 Model B (0xa01041)
  0
     - 0 'gpio@7e200000'
     - found
  pinconfig uart0_gpio14: set_state_simple op missing
  Core:  64 devices, 14 uclasses, devicetree: embed
  MMC:   0
     - 0 'mmc@7e202000'
     - found
  0
     - 0 'gpio@7e200000'
     - found
  pinconfig sdhost_gpio48: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
  bcm2835-sdhost mmc@7e202000: f_max 250000000, f_min 122129
  bcm2835-sdhost mmc@7e202000: bcm2835_probe -> OK
  Sending event 4/(unknown) to spy 'efi_disk add'
  1
     - 0 'mmc@7e202000'
     - not found
  mmc@7e202000: 0
  Loading Environment from FAT... Sending event 4/(unknown) to spy 'efi_disk add'
  Sending event 4/(unknown) to spy 'efi_disk add'
  Sending event 4/(unknown) to spy 'efi_disk add'
   <2, 0, 1024>
   <8, 0, 64>
   <8488, 256, 128>
  FAT read(sect=8098), clust_size=1, read_size=1
  FAT read(sect=94922), clust_size=1, read_size=1
  FAT read(sect=152022), clust_size=1, read_size=1
  FAT read(sect=170944), clust_size=1, read_size=1
  FAT read(sect=8108), clust_size=1, read_size=1
  FAT read(sect=81128), clust_size=1, read_size=1
  FAT read(sect=54597), clust_size=1, read_size=1
  FAT read(sect=28307), clust_size=1, read_size=1
  FAT read(sect=173533), clust_size=1, read_size=1
  FAT read(sect=235690), clust_size=1, read_size=1
  FAT read(sect=156342), clust_size=1, read_size=1
  Unable to read "uboot.env" from mmc0:1... 
  0
     - 0 'hdmi@7e902000'
     - found
  0
     - 0 'gpio@7e200000'
     - found
  bcm2835_video hdmi@7e902000: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
  Sending event 4/(unknown) to spy 'efi_disk add'
  In:    serial
  Out:   vidconsole
  Err:   vidconsole
  0
     - not found
  Net:   No ethernet found.
  starting USB...
  Bus usb@7e980000: 0
     - 0 'gpio@7e200000'
     - found
  dwc2_usb usb@7e980000: set_state_simple op missing
  dwc2_usb usb@7e980000: Can't get reset: -524
  dwc2_usb usb@7e980000: Core Release: 2.80a
  USB DWC2
  Sending event 4/(unknown) to spy 'efi_disk add'
  scanning bus usb@7e980000 for devices... bind node usb1@1
     - attempt to match compatible string 'usb424,9514'
  No match for node 'usb1@1'
  0
     - 0 'gpio@7e200000'
     - found
  usb_hub usb_hub: set_state_simple op missing
  bind node usbether@1
     - attempt to match compatible string 'usb424,ec00'
  No match for node 'usbether@1'
  0
     - 0 'gpio@7e200000'
     - found
  usb_hub usb_hub: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
     - seq=0
  0
     - 0 'gpio@7e200000'
     - found
  smsc95xx_eth smsc95xx_eth: set_state_simple op missing
  Sending event 4/(unknown) to spy 'efi_disk add'
  Device NOT ready
     Request Sense returned 02 04 01

> Takahiro-san, so you have any ideas?
> 
> Regards,
> Simon

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[AKASHI Takahiro]

On Sat, Jul 23, 2022 at 05:03:39PM +0200, Jan Palus wrote:
> On 23.07.2022 16:43, Jan Palus wrote:
> > On 23.07.2022 16:19, Jan Palus wrote:
> > > On 22.07.2022 02:59, Simon Glass wrote:
> > > > Hi Jan,
> > > > 
> > > > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > > > >
> > > > > u-boot 2022.07 boots fine without any USB devices attached to
> > > > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > > > connected, right after:
> > > > >
> > > > >    Request Sense returned 02 04 01
> > > > >
> > > > > git bisect indicates first commit to cause regression is:
> > > > >
> > > > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > > > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > > > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > > > >
> > > > >       usb: storage: call device_probe() after scanning
> > > > >
> > > > >       Every time a usb bus/port is scanned and a new device is detected,
> > > > >       we want to call device_probe() as it will give us a chance to run
> > > > >       additional post-processings for some purposes.
> > > > >
> > > > >       In particular, support for creating partitions on a device will be added.
> > > > >
> > > > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Reverting this commit fixes the issue.
> > > > >
> > > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > > > Also note that without this change 0 storage devices are detected even
> > > > > when drive is attached.
> > > > 
> > > > I am not sure what is going on here. Can you provide the full console
> > > > trace of the boot? Any idea where it is hanging?
> > > 
> > ...
> > > 
> > > Now the place where it hangs is:
> > > 
> > >   part_efi.c:
> > > 
> > >   static int part_test_efi(struct blk_desc *dev_desc)
> > >   {
> > >           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> > > 
> > > where dev_desc->blksz is 3782209548.
> > > 
> > 
> > So it appears block size is read incorrectly? Should be 512 but not sure
> > where this value 3782209548 is coming from, it's not block capacity
> > either. After plugging in Linux reports:
> > 
> >   sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
> 
> Since this was logged:
> 
>   Device NOT ready
>      Request Sense returned 02 04 01
> 
> then it seems capacity/block size were never determined (happens right
> after these log messages if they *don't* occur) so I guess they are
> random values and this usb storage should never have been probed? I'll
> stop here due to my cluelessness.

The code looks like:
  usb_stor_probe_device()
      ...
      blk_create_devicef();
      ret = usb_stor_get_info(udev, data, blkdev);
      if (ret == 1) {
          usb_max_devs++;
          debug("%s: Found device %p\n", __func__, udev);
      } else {
          debug("usb_stor_get_info: Invalid device\n");
          ret = device_unbind(dev);
          if (ret)
              return ret;
						<== (A)
      }

      blk_probe_or_unbind(dev);
      ...


usb_stor_get_info() returns 0 when it generates "Device NOT ready" message.
Then blk_probe_or_unbind(), hence part_test_efi(), is accidentally called
although blkdev is not fully initialised/populated.

I think we should skip the subsequent processing by adding "continue" at (A).

Thanks,
-Takahiro Akashi

Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

On 25.07.2022 11:25, AKASHI Takahiro wrote:
> On Sat, Jul 23, 2022 at 05:03:39PM +0200, Jan Palus wrote:
> > On 23.07.2022 16:43, Jan Palus wrote:
> > > On 23.07.2022 16:19, Jan Palus wrote:
> > > > On 22.07.2022 02:59, Simon Glass wrote:
> > > > > Hi Jan,
> > > > > 
> > > > > On Mon, 18 Jul 2022 at 11:48, Jan Palus <jpalus@fastmail.com> wrote:
> > > > > >
> > > > > > u-boot 2022.07 boots fine without any USB devices attached to
> > > > > > RaspberryPi 2 however it hangs early on if external USB drive is
> > > > > > connected, right after:
> > > > > >
> > > > > >    Request Sense returned 02 04 01
> > > > > >
> > > > > > git bisect indicates first commit to cause regression is:
> > > > > >
> > > > > >   8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
> > > > > >   commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
> > > > > >   Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > > >   Date:   Tue Mar 8 20:36:40 2022 +0900
> > > > > >
> > > > > >       usb: storage: call device_probe() after scanning
> > > > > >
> > > > > >       Every time a usb bus/port is scanned and a new device is detected,
> > > > > >       we want to call device_probe() as it will give us a chance to run
> > > > > >       additional post-processings for some purposes.
> > > > > >
> > > > > >       In particular, support for creating partitions on a device will be added.
> > > > > >
> > > > > >       Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > > >       Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > > >
> > > > > > Reverting this commit fixes the issue.
> > > > > >
> > > > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
> > > > > > Also note that without this change 0 storage devices are detected even
> > > > > > when drive is attached.
> > > > > 
> > > > > I am not sure what is going on here. Can you provide the full console
> > > > > trace of the boot? Any idea where it is hanging?
> > > > 
> > > ...
> > > > 
> > > > Now the place where it hangs is:
> > > > 
> > > >   part_efi.c:
> > > > 
> > > >   static int part_test_efi(struct blk_desc *dev_desc)
> > > >   {
> > > >           ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);
> > > > 
> > > > where dev_desc->blksz is 3782209548.
> > > > 
> > > 
> > > So it appears block size is read incorrectly? Should be 512 but not sure
> > > where this value 3782209548 is coming from, it's not block capacity
> > > either. After plugging in Linux reports:
> > > 
> > >   sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
> > 
> > Since this was logged:
> > 
> >   Device NOT ready
> >      Request Sense returned 02 04 01
> > 
> > then it seems capacity/block size were never determined (happens right
> > after these log messages if they *don't* occur) so I guess they are
> > random values and this usb storage should never have been probed? I'll
> > stop here due to my cluelessness.
> 
> The code looks like:
>   usb_stor_probe_device()
>       ...
>       blk_create_devicef();
>       ret = usb_stor_get_info(udev, data, blkdev);
>       if (ret == 1) {
>           usb_max_devs++;
>           debug("%s: Found device %p\n", __func__, udev);
>       } else {
>           debug("usb_stor_get_info: Invalid device\n");
>           ret = device_unbind(dev);
>           if (ret)
>               return ret;
> 						<== (A)
>       }
> 
>       blk_probe_or_unbind(dev);
>       ...
> 
> 
> usb_stor_get_info() returns 0 when it generates "Device NOT ready" message.
> Then blk_probe_or_unbind(), hence part_test_efi(), is accidentally called
> although blkdev is not fully initialised/populated.
> 
> I think we should skip the subsequent processing by adding "continue" at (A).

I see there is a change proposed in ml in the same place:

https://lists.denx.de/pipermail/u-boot/2022-July/489531.html

Though I'm also wondering "Request Sense returned 02 04 01" from a quick
search appears to indeed mean "Device NOT ready", but "it's becoming
ready" so in my case that's likely about spinning up HDD plates. I
wonder if it shouldn't be treated like -EAGAIN with some timeout as in
second or two the drive would likely report it is ready.