Date: Thu, 29 Sep 2022 21:51:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-uboot@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <748A5596-9F39-4036-8D07-5AF098AF0289@yahoo.com> In-Reply-To: <DB44C6A0-2F6B-49FF-9C23-9FA05086C7FA@yahoo.com> References: <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com> <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> <E3A1C678-8C47-4283-9F9F-4C9011DB8A2B@yahoo.com> <20220929054120.GA77803@www.zefox.net> <D7A62820-4928-49F0-8387-C1E6D998B121@yahoo.com> <ABFBD0E6-8A9B-4C99-84DF-BF398F23678A@yahoo.com> <20220929151926.GA80020@www.zefox.net> <F316420B-C7AF-4131-9734-06117FFE212D@yahoo.com> <20220929170927.GB80020@www.zefox.net> <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com> <20220930002742.GA81169@www.zefox.net> <C9C83BA8-2EAB-4B9B-9231-B9AEB2F7CE1F@yahoo.com> <DB44C6A0-2F6B-49FF-9C23-9FA05086C7FA@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-29, at 21:11, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Sep-29, at 19:14, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2022-Sep-29, at 17:27, bob prohaska <fbsd@www.zefox.net> wrote:
>>=20
>>> . . .
>> U-Boot> run bootcmd_usb0
>>=20
>> Device 0:=20
>> usb_read: udev 0
>>=20
>> usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
>> read10: start 0 blocks 1
>> COMMAND phase
>> DATA phase
>> usb_bulk_msg error status 0
>=20
> Looks like the above is from:
>=20
> result =3D usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, =
srb->datalen,
> &data_actlen, USB_CNTL_TIMEOUT * 5);
> /* special handling of STALL in DATA phase */
> if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
> . . .
> }
> if (result < 0) {
> debug("usb_bulk_msg error status %ld\n",
> us->pusb_dev->status);
> usb_stor_BBB_reset(us);
> return USB_STOR_TRANSPORT_FAILED;
> }
>=20
> (result's value seems to not be reported.)
>=20
> The above code's usb_stor_BBB_reset use initiated the below:
>=20
>> BBB_reset
>> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index =
0x0 length 0x0
>> BBB_reset result -110: status 0 reset
>> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
>> BBB_reset result -22: status 0 clearing IN endpoint
>> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
>> BBB_reset result -22: status 0 clearing OUT endpoint
>> BBB_reset done
>=20
> Looks like -110 is from a: return -ETIMEDOUT;
>=20
> Looks like each -22 is from a: return -EINVAL;
>=20
> The -EINVAL results seem to be from usb_clear_halt
> doing:
>=20
> int endp =3D usb_pipeendpoint(pipe)|(usb_pipein(pipe)<<7);
>=20
> result =3D usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> USB_REQ_CLEAR_FEATURE, =
USB_RECIP_ENDPOINT, 0,
> endp, NULL, 0, USB_CNTL_TIMEOUT * 3);
>=20
> /* don't clear if failed */
> if (result < 0) =20
> return result;
>=20
> usb_clear_halt is used twice, via usb_stor_BBB_reset :
>=20
> pipe =3D usb_rcvbulkpipe(us->pusb_dev, us->ep_in);
> result =3D usb_clear_halt(us->pusb_dev, pipe);
>=20
> pipe =3D usb_sndbulkpipe(us->pusb_dev, us->ep_out);
> result =3D usb_clear_halt(us->pusb_dev, pipe);
>=20
>> Read ERROR
>=20
> This is from:
>=20
> retry_it: =20
> if (smallblks =3D=3D ss->max_xfer_blk)
> usb_show_progress();
> srb->datalen =3D block_dev->blksz * smallblks;
> srb->pdata =3D (unsigned char *)buf_addr;
> if (usb_read_10(srb, ss, start, smallblks)) {
> debug("Read ERROR\n");
> ss->flags &=3D ~USB_READY;
> usb_request_sense(srb, ss);
> if (retry--) =20
> goto retry_it;
> blkcnt -=3D blks;
> break;
> } =20
>=20
> The retry_it getting to usb_read_10 again lead to:
>=20
>> COMMAND phase
>> DATA phase
>=20
> So it is the retry using usb_read_10 that ends up with
> the RPi3B reboot happening instead of completing.
>=20
>=20
> I'm not likely to manage to give this further interpretation.
>=20
You generated 2 more error logs. They have (among other
things) . . .
pelorus_console.txt2_boot_loop ends with:
scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0
Device 0:=20
usb_read: udev 0
usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
read10: start 0 blocks 1
COMMAND phase
DATA phase
usb_bulk_msg error status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -110: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -110: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -110: status 0 clearing OUT endpoint
BBB_reset done
Read ERROR
COMMAND phase
usb_stor_BBB_comdat:usb_bulk_msg error
failed to send CBW status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -110: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -110: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -110: status 0 clearing OUT endpoint
BBB_reset done
Request Sense returned 00 00 00
(Then it repeats, starting with read10 again, over and
over.)
pelorus_console_txt3_bootcmd_0_failure ends with:
scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0
Device 0:=20
usb_read: udev 0
usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
read10: start 0 blocks 1
COMMAND phase
DATA phase
usb_bulk_msg error status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -22: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -22: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -22: status 0 clearing OUT endpoint
BBB_reset done
Read ERROR
COMMAND phase
DATA phase
(Apparently it hung up instead of rebooting or repeating?)
So, at leasts 3 different patterns of -ETIMEDOUT and -EINVAL
results in the BBB_reset activity, each of the 3 having a
somewhat different overall behavior.
I've no clue why the mixes of -ETIMEDOUT and -EINVAL happen.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?748A5596-9F39-4036-8D07-5AF098AF0289>