Date: Wed, 28 Sep 2022 20:04: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: <A8C2BA4E-4520-4B34-9614-DDC4D8BEB097@yahoo.com> In-Reply-To: <197D3C46-063B-4C67-AB1A-A3A072521D7F@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 2022-Sep-28, at 18:03, Mark Millard <marklmi@yahoo.com> wrote:
> 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.
7 vs. 8 was not the issue.
I had the:
#define LOG_DDEBUG
#define DEBUG
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.
But if it gets far enough to make use of the USB media,
then it reports, for example, every usb read via output
like:
usb_read: udev 0
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
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.
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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
filename=patch-common_usb__hub.c
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="patch-common_usb__hub.c"
Content-Transfer-Encoding: 7bit
--- common/usb_hub.c.orig 2022-04-04 07:31:32.000000000 -0700
+++ common/usb_hub.c 2022-09-28 19:08:42.261977000 -0700
@@ -16,6 +16,8 @@
* (C) Copyright 2001 Denis Peter, MPL AG Switzerland
*/
+#define LOG_DEBUG
+#define DEBUG
/****************************************************************************
* HUB "Driver"
* Probes device for being a hub and configurate it
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
filename=patch-common_usb__storage.c
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="patch-common_usb__storage.c"
Content-Transfer-Encoding: 7bit
--- common/usb_storage.c.orig 2022-04-04 07:31:32.000000000 -0700
+++ common/usb_storage.c 2022-09-28 19:09:02.566277000 -0700
@@ -20,6 +20,8 @@
* FreeBSD.
*/
+#define LOG_DEBUG
+#define DEBUG
/* Note:
* Currently only the CBI transport protocoll has been implemented, and it
* is only tested with a TEAC USB Floppy. Other Massstorages with CBI or CB
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
filename=patch-common_usb.c
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="patch-common_usb.c"
Content-Transfer-Encoding: 7bit
--- common/usb.c.orig 2022-04-04 07:31:32.000000000 -0700
+++ common/usb.c 2022-09-28 19:08:34.423048000 -0700
@@ -16,6 +16,8 @@
* (C) Copyright 2001 Denis Peter, MPL AG Switzerland
*/
+#define LOG_DEBUG
+#define DEBUG
/*
* How it works:
*
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
filename=rpi_arm64_fragment
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="rpi_arm64_fragment"
Content-Transfer-Encoding: 7bit
CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
CONFIG_RPI_EFI_NR_SPIN_PAGES=2
CONFIG_LOG=y
CONFIG_LOG_MAX_LEVEL=7
CONFIG_LOG_DEFAULT_LEVEL=7
CONFIG_LOG_CONSOLE=y
--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8C2BA4E-4520-4B34-9614-DDC4D8BEB097>