Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

Reply: Mark Millard : "Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
In reply to: bob prohaska : "EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Wed, 05 Oct 2022 17:29:28 UTC
On 2022-Oct-5, at 09:07, bob prohaska <fbsd@www.zefox.net> wrote:

> . . .
> 
>> There is such a thing as a pre-built debug EDK2 build,
>> at least for RPi4 EDK2. If there is for RPi3 EDK2,
>> then we might be able to get more message text. But
>> it need not lead to avoiding the problem.
>> 
> 
> I gather you're suggesting that debugging delays in EDK2
> might not have the same effect as debugging delays in u-boot?
> Would it still be worth trying if available?

They still would be problematical. But we did learn things
like that the root hub in the RPi3 was having odd behavior
via U-Boot --even if we did not find a solution to your
overall problem.

But, it turns out that the "build artifacts" for the official
RPi* EDK2 builds have an expiration duration. It has been
long enough since the EDK2 releases release that there is no
debug build artifact available now.

>> 
>> Note that U-Boot was not involved at any stage this time.
> 
> To my understanding u-boot isn't present, unless I made a
> mistake. Are you suggesting something else?

No: the point is that the problems are occurring when
U-Boot can not contribute to the problems. The problem
is in no way U-Boot specific.

>> Adjusting U-Boot would be unlikely to prevent this from
>> happening. Nor is it likely that adjusting EDK2 could.
> 
> Perhaps, but I don't understand the inference... yet.
> AIUI, EDK2 discovers the parameters the kernel needs to
> communicate with the disk and passes them to the kernel.

The kernel uses the Device Tree handed over by either
U-Boot or EDK2. They in turn start from the 1 that is
handed by the RPi* firmware. That in turn starts from
.dtb's in the msdosfs. The RPi* firmware and U-Boot/EDK2
can make adjustments to the original .dtb material
to cover platform details not handled by the static
files in msdosfs.

(An example is the 8 GiByte variations with and without
the lower-3-GiByte DMA limitation: some address ranges
in the final Device Tree vary.)

The Device Tree does not reference the specific USB
devices plugged in. The FreeBSD kernel handles such on
its own. (Such is why it can boot world via USB3 on the
Rock64 but U-Boot and the FreeBSD loader do not deal
with the USB3 as things are.)

FreeBSD's kernel does its own binding and initializations
to the USB context(s).

> Is this a distiction between reading the disk and writing?

I was not referencing that distinction at all.

>> Looks like the FreeBSD kernel would have to manage to deal
>> with the issue via an error recovery handling. There is
>> no evidence to suggest being able to avoid the problem
>> occurring.
>> 
>>> . . .
>>> usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR
>> 
>> Looks to be a consequence of the above.
>> 
>>> Root mount waiting for: usbus1
>>> ugen1.5: <JMicron USB Mass Storage> at usbus1
>>> umass0 on uhub2
>>> umass0: <JMicron USB Mass Storage, class 0/0, rev 2.10/2.14, addr 5> on usbus1
>>> umass0:  SCSI over Bulk-Only; quirks = 0x8100
>>> umass0:0:0: Attached to scbus0
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0: <SABRENT  0214> Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number DD564198838F9
>>> da0: 40.000MB/s transfers
>>> da0: 953869MB (1953525168 512 byte sectors)
>>> da0: quirks=0x2<NO_6_BYTE>
>>> ugen1.6: <FTDI FT232R USB UART> at usbus1
>>> ugen1.5: <JMicron USB Mass Storage> at usbus1 (disconnected)
>> 
>> Possibly another consequence? Or a new failure?
>> ("addr 5" is, apparently, successfully referenced
>> a few lines above. So I'm guessing: new failure.)
>> 
>>> umass0: at uhub2, port 4, addr 5 (disconnected)
>>> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00 
>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> 
> The "...request completed with an error... line is rather familiar
> and in the past has proved innocuous on Pi3 and I think Pi4, though
> not seen recently.

In various past configurations, I've seen one such message
in the kernel's part of the boot sequence historically.
I treat it as normal for what FreeBSD does at this stage
for some types of RPi* --and that is why I did not comment
about it explicitly.

>>> . . .
> 
> For now buildworld is still in the building libraries 
> stage. At the moment it's swap-bound and showing ~750 
> MB swap in use at 53% idle. No sign of disk problems
> yet. Looks like moutroot is more delicate than I/O.

The command sequences are not the same for normal
operation vs. binding time. For example, the kind of
activity that reports:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)

only happens at binding time. And the next message
is the first error report:

usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)

There is no evidence that the 0x0577 is doing
anything odd for the normal-operation context:
No issue to be delicate relative to, for that
kind of context.

There is evidence that the 0x0577 does odd things
for some of the the binding time activities,
although the details relative to the status
relative to the standards is not clear.

I do not have the background to know from the
evidence that we have seen, just what violations
of the standard by the 0x0577 may be involved
vs. what incompletenesses in the FreeBSD binding
logic might be vs. both. Binding logic can not
reasonably be expected to handle arbitrary
violations of the standards --and the 0x0577
context might well be violating the standards.
But implementations of binding logic can be
incomplete relative to standard-conformant
devices as well. So: Unsure.

> If there are any EDK2 boot options worth exploring
> please indicate. I've seen the help menu but nothing
> looks familiar.

Nothing in EDK2 or U-Boot is likely to help with
avoiding the kernel getting the sequence:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)

I'm also not aware of anything that would be relevant
to avoiding the:

BdsDxe: No bootable option or device was found.

during EDK2's activity.

I will note that FreeBSD likely has debugging
notices for the USB binding activities that could
be enabled, not that I know such would prove
useful.


Side note:

I got the following once over night:

Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Controller timeout
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: ============== REGISTER DUMP ==============
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Blk size: 0x00000200 | Blk cnt:  0x00000001
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Argument: 0x40510000 | Trn mode: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Present:  0x000b0000 | Host ctl: 0x00000002
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00000107
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Int enab: 0x00000000 | Sig enab: 0x01ff00fa
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: ===========================================
Oct  5 03:01:11 CA72_UFS kernel: mmcsd0: Error indicated: 1 Timeout

So, apparently, there can be occasional messages about
the microsd card slot for the RPi3 EDK2 context. I've
no clue why the messages were produced but I had removed
and put back the microsd card earlier in the day, without
rebooting between or after. Thus the message lines might
also happen for other types of booting, such as via
U-Boot, if I'd done similarly.

===
Mark Millard
marklmi at yahoo.com