Date: Wed, 28 Sep 2022 20:31:12 -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: <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> In-Reply-To: <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com> References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com> <20220928015721.GA73356@www.zefox.net> <C657BE65-ADCC-479B-B756-445D0825E0FA@yahoo.com> <E0BDFF06-3998-48E0-B04D-3B4A11F4A9AE@yahoo.com> <20220928045145.GB73356@www.zefox.net> <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com> <20220928172839.GA75564@www.zefox.net> <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com> <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com> <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net> <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com> <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-28, at 20:04, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Sep-28, at 18:03, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2022-Sep-28, at 17:21, bob prohaska <fbsd@www.zefox.net> wrote:
>>=20
>>> With the correct patches finally in place there is some
>>> extra output from u-boot:
>>>=20
>>> U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700)
>>> . . .
>>> starting USB...
>>> . . .
>>> usb_new_device: Cannot read configuration, skipping device 152d:0583
>>=20
>> The above is reporting U-Boot having a problem dealing with
>> your bridge/drive combination as seen via bridge access,
>> presuming that I recognize the 152d:0583 correctly.
>>=20
>>=20
>>=20
>> Interestingly, that message is not from the routine usb_new_device
>> but is from:
>>=20
>>=20
>> int usb_select_config(struct usb_device *dev)
>> {
>> . . .
>> /*
>> * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely =
sensitive
>> * about this first Get Descriptor request. If there are any =
other
>> * requests in the first microframe, the stick crashes. Wait =
about
>> * one microframe duration here (1mS for USB 1.x , 125uS for =
USB 2.0).
>> */
>> mdelay(1);
>>=20
>> /* only support for one config for now */
>> err =3D usb_get_configuration_len(dev, 0);
>> if (err >=3D 0) {
>> tmpbuf =3D (unsigned char *)malloc_cache_aligned(err);
>> if (!tmpbuf)
>> err =3D -ENOMEM;
>> else
>> err =3D usb_get_configuration_no(dev, 0, =
tmpbuf, err);
>> }
>> if (err < 0) {
>> printf("usb_new_device: Cannot read configuration, " \
>> "skipping device %04x:%04x\n",
>> dev->descriptor.idVendor, =
dev->descriptor.idProduct);
>> free(tmpbuf);
>> return err;
>> }
>> . . .
>>=20
>> where:
>>=20
>> =
/**********************************************************************
>> * gets len of configuration cfgno
>> */
>> int usb_get_configuration_len(struct usb_device *dev, int cfgno)
>> {
>> int result;
>> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, 9);
>> struct usb_config_descriptor *config;
>>=20
>> config =3D (struct usb_config_descriptor *)&buffer[0];
>> result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, 9);
>> if (result < 9) { =20
>> if (result < 0)
>> printf("unable to get descriptor, error %lX\n",
>> dev->status);
>> else
>> printf("config descriptor too short " \
>> "(expected %i, got %i)\n", 9, result);
>> return -EIO;
>> }
>> return le16_to_cpu(config->wTotalLength);
>> }
>>=20
>> and:
>>=20
>> =
/**********************************************************************
>> * gets configuration cfgno and store it in the buffer
>> */
>> int usb_get_configuration_no(struct usb_device *dev, int cfgno,
>> unsigned char *buffer, int length)
>> {
>> int result;
>> struct usb_config_descriptor *config;
>>=20
>> config =3D (struct usb_config_descriptor *)&buffer[0];
>> result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, length);
>> debug("get_conf_no %d Result %d, wLength %d\n", cfgno, result,
>> le16_to_cpu(config->wTotalLength));
>> config->wTotalLength =3D result; /* validated, with CPU byte =
order */
>>=20
>> return result;
>> }
>>=20
>> (I'll skip more nested routine usage.)
>>=20
>>=20
>> We apparently do not have enough output enabled to see the debug
>> routine's output. We are seeing the printf output.
>>=20
>> There might be a way to set the output message levels while at a
>> U-Boot prompt, up to the maximum compiled in. But it may also be
>> that we would need, say,
>>=20
>> CONFIG_LOG_MAX_LEVEL=3D8
>>=20
>> instead of the 7 we are now using.
>=20
> 7 vs. 8 was not the issue.
>=20
> I had the:
>=20
> #define LOG_DDEBUG
> #define DEBUG
>=20
> lines too late in the 3 usb*.c files. Moving them to
> before all the #include's in each leads to getting
> all the debug output too, at least if I set the
> default level to do so.
>=20
> But if it gets far enough to make use of the USB media,
> then it reports, for example, every usb read via output
> like:
>=20
> usb_read: udev 0
>=20
> usb_read: dev 0 startblk 87878da0, blccnt 20 buffer 381a1200
> read10: start 87878da0 blocks 20
> COMMAND phase
> DATA phase
> STATUS phase
> usb_read: end startblk 87878dc0, blccnt 20 buffer 381a5200
>=20
>=20
> It is a rather large amount of output (after the failure
> point you are hitting). The output messes up the loader serial
> output. The EFI loader loading the kernel is done via
> U-Boot services and so all those reads are present. Once
> the kernel is active, U-Boot is not and the serial I/O is
> back to normal.
>=20
>=20
> I've included the updated usb*.c files and the rpi_arm64_fragment
> update with an extra line explicitly for setting the default
> log level.
>=20
It looks like that if you remove files/patch-common_usb__storage.c
and rebuild/install the large output reporting usb reads will not
happen.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
=
<patch-common_usb__hub.c><patch-common_usb__storage.c><patch-common_usb.c>=
<rpi_arm64_fragment>
=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?6AA65AE6-41F1-405F-A592-7D641EA4C9CF>