All debug messages from ep0.c except a few are printed by dbg_ep0() macro.
So for remaining few exceptions use also dbg_ep0() instead of serial_printf().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If we do not set FIFO buffer address and size for some endpoint which is in
use then default programmed address 0x0 would be used which is in conflict
with address of FIFO buffer for endpoint 0. Moreover address of FIFO buffer
for endpoint 0 cannot be programmed, it is fixed to 0x0. Sharing address
space between more endpoints cause data loss and unexpected errors.
This patch is fixing transmission of characters over usbtty serial console
and allows using of usbtty for debugging purposes on Nokia N900.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Interrupt for EP0 is indicated in intrtx register via first bit. This bit
is set for both RX and TX despite register has only TX in its name. First
bit in intrrx register is reserved, not used and never set.
So remove calling musb_peri_ep0() function at every iteration of udc_irq()
and musb_peri_rx() and call it only from musb_peri_tx() when correct
interrupt bit in initrtx it set.
Address from SET ADDRESS command must be set to faddr register only after
acknowledging SERV_RXPKTRDY followed by received EP0 interrupt. So prior
calling musb_peri_ep0_set_address() check for EP0 interrupt instead of
(incorrect) MUSB_INTR_SOF interrupt.
This patch fixes issue that host (computer) cannot register U-Boot USB
device and is failing with errors:
usb 1-1: new full-speed USB device number 86 using xhci_hcd
usb 1-1: Device not responding to setup address.
usb 1-1: Device not responding to setup address.
usb 1-1: device not accepting address 86, error -71
U-Boot was writing address to faddr register too early and did not wait for
correct interrupt after which should update address.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If musb_peri_rx_ep() was called to process received HW buffer but U-Boot
cannot read it yet (e.g. because U-Boot SW buffer is full) then interrupt
was marked as processed also when HW buffer stayed unprocessed.
U-Boot tried to process this buffer again when it received interrupt again,
but it can receive it only when sender (host) sends a new data. As sender
(host) is not going to send a new data until U-Boot process current data
this issue caused a deadlock in case sender (host) is emitting data faster
than U-Boot can process it.
Reading musb intrrx register automatically clears this register and marks
interrupt as processed. So to prevent marking interrupt in U-Boot as
processed, adds a new variable pending_intrrx which would contain
unprocessed bits of intrrx register.
For a second step, every time when musb_peri_rx_ep() is called and there
are waiting data to be processed (signaled by MUSB_RXCSR_RXPKTRDY) either
acknowledge sender (via musb_peri_rx_ack()) that whole HW buffer was
processed or set corresponding bit in pending_intrrx that HW buffer was not
fully processed yet and next iteration is required after U-Boot allocates
space for reading HW buffer.
This patch fixes receiving large usb buffers, e.g. file transfer via Kermit
protocol implemented by 'loadb' U-Boot command over usbtty serial console.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If udc_endpoint_write() was called with bigger payload which does not fit
into one USB packet it is needed to transmit payload in more USB packets.
First packet is transmitted by udc_endpoint_write() call itself and other
packets are put into waiting queue.
Implement function musb_peri_tx() which checks if endpoints are ready for
transmit and continue transmission of waiting queue.
This patch fixes sending big output from printenv command over usbtty
serial console.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>>
PERI_RXCSR is 16bit register so store its value into 16bit local variable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
This patch fixes configuring FIFOs for one-directional endpoints which have
only one queue (either RX or TX, but noth both).
Size of FIFO buffer is 2^(idx+3) bytes and starting address is 2^(addr+3).
Moreover first 64 bytes are reserved for EP0.
Without this patch if FIFO size specified by caller was zero then idx was
incorrectly calculated (expr. ffs(0)-1) and size overflowed in fifosz
register. This register uses has only 4 bits for FIFO size. Moreover
specifying zero buffer size is not possible (with idx=0 is minimal buffer
size 8 bytes).
So even for one-directional endpoints we need to correctly specify both
(RX and TX) FIFO buffer sizes and its addresses.
This patch is fixing calculation of start address and buffer size to
minimal value and ensures that it would not overlap with buffer reserved
for EP0.
This issue caused loose of packets on USB bus in both directions and
basically usbtty was unusable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Without this patch clearing was done only when U-Boot was compiled with
MUSB Host Controller. But clearing of data toggle bit is needed also for
MUSB Device Controller otherwise Device Controller does not work correctly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
musb udc code depends on usb gadget code provided by CONFIG_USB_DEVICE as
defined in drivers/usb/gadget/Makefile. But this Makefile is not included
into U-Boot build when CONFIG_USB_GADGET is not set. As CONFIG_USB_DEVICE
cannot be enabled together with CONFIG_USB_GADGET it means that dependency
for musb udc code is not compiled during build. Fix it by including
drivers/usb/gadget dependency also when CONFIG_USB_DEVICE is set.
This patch fixes compile errors:
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_rx':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_idle':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_zero_data_request':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_idle':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_rx':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_rcv_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_rx_ep':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_rcv_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_endpoint_write':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_tx_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_irq':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o:u-boot/drivers/usb/musb/musb_udc.c: more undefined references to `usbd_device_event_irq' follow
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_setup_ep':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_alloc_urb'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_startup_events':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
make: *** [Makefile:1762: u-boot] Error 1
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Function next_urb() selects the last urb data buffer from linked list to
which next data from usbtty's puts function should be appended.
But to check if TX data still exists it is needed to look at the first urb
data buffer from linked list. So check for endpoint->tx_urb (first from the
linked list) instead of current_urb (the last from the linked list).
Successful call to udc_endpoint_write() may invalidate active urb and
allocate new urb in queue which invalidates pointer returned by next_urb()
function.
So call next_urb() prior putting data into urb buffer and call it every
time after using udc_endpoint_write() function to prevent sending data from
usbtty's puts function in incorrect order.
This patch fixes issue that usbtty code does not transmit data when they
are waiting in the tx queue.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
This function has incorrect implementation of prepending CR prior LF.
Without this patch it prepended CR prior whole string which is going to be
written and let LF without leading CR. Fix this issue by inserting CR at
correct place to make output on usbtty serial console more readable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
On the RPi4 armv7 build we have the situationt that we use physical
addresses of 64 bit, while the virtual addresses are 32 bit.
Remap the base address in this scenario via map_physmem().
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Add tuning functionality which is needed for HS200 mode.
For HS200, program the correct needed 1.8 voltage
Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
The EFI Grub workaround isn't needed with Grub version 2.04 or higher.
This version was published over a year ago, so disable the workaround
to reduce boot time.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
In drivers we use a family of printing functions including pr_err() and
pr_cont(). CONFIG_LOGLEVEL is used to control which of these lead to output
via printf().
Our logging functions allow finer grained control of output. So replace
printf() by the matching logging functions. The usage of CONFIG_LOGLEVEL
remains unchanged.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
location key offset other than -1, it currently fails via BUG_ON.
The offset can have other value than -1, though. This can happen for
example if a subvolume is renamed:
$ btrfs subvolume create X && sync
Create subvolume './X'
$ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$
location key (270 ROOT_ITEM 18446744073709551615) type DIR
transid 283 data_len 0 name_len 1
name: X
$ mv X Y && sync
$ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$
location key (270 ROOT_ITEM 0) type DIR
transid 285 data_len 0 name_len 1
name: Y
As can be seen the offset changed from -1ULL to 0.
Do not fail in this case.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: David Sterba <dsterba@suse.com>
Cc: Qu Wenruo <wqu@suse.com>
Cc: Tom Rini <trini@konsulko.com>
As Stephen is no longer actively maintaining the uboot-test-hooks
repository, switch to using the instance on our GitLab.
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
- Enable uefi related commands for STMicroelectronics STM32MP15 boards
- Remove duplicate uart nodes in stm32mp15 device tree
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAmA5DRwACgkQ4rK92eCq
k3WKtQf+Nk2N8XzhKgoz4dfg+A/uZ1ppKiuuYfHWitvw9OLrjGO61MnYOc6Dh7De
LchPExBYnatj3lxu3IEaaNUGJRujnt9n3W8JNQTGB81MI1TO2oITEhAyDqpMGtqt
pvr1NaoxhZM4B7n/HoQnVB+XtlP08w45SQiEXjjaO82hWRk45sAZ7WGFSs60iVck
ocqhrJ/2AraG98JQPxWfvdqr+24gl1Gt++KT/cdHS//IeYJJYuiCD3m9vOj8TatH
gDVbfR6tquZ5HLvKr/orRz3smaCuutWdHcDwcjs3kFK1rBHSYFZhG3qHQ3ZqNm+w
T/7JIqz4W366o7QZXXlCoi56w2tpug==
=f/Cg
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20210226' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm
- Add USB host boot support in stm32mp1 config
- Enable uefi related commands for STMicroelectronics STM32MP15 boards
- Remove duplicate uart nodes in stm32mp15 device tree
VenHw and VenMedia device path nodes may carry vendor defined data of
arbitrary length. When converting a device path node to text ensure that we
do not overrun our internal buffer.
In our implementation of
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL.ConvertDevicePathToText() we could first
determine the output length and then allocate buffers but that would nearly
double the code size. Therefore keep the preallocated buffers and truncate
excessive device paths instead.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Fix a missing comma sign (,) from a printf(), that is only
reachable if DEBUG is defined, in which case the build fails with:
tools/mkeficapsule.c:266:36: error: expected ‘)’ before ‘bin’
266 | printf("\tbin: %s\n\ttype: %pUl\n" bin, guid);
| ^~~~
| )
Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI spec does not allow ACPI tables to be in runtime services memory.
It recommends EfiACPIReclaimMemory.
Remove a superfluous check that the allocated pages are 16 byte aligned.
EFI pages are 4 KiB aligned.
Fixes: 86df34d42b ("efi_loader: Install ACPI configuration tables")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support. We can also store the EFI variables in a file on the
ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though. Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env related
and efidebug commands and allow users to do that
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Remove duplicated uart nodes introduced with commit 62f95af92a
("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4"),
because the uart nodes wasn't correctly ordered in alphabetic order.
Only cosmetic: the generated device tree don't change.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add support for booting from USB pen drive, since USB host port is
available on the STM32MP1.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Since commit 8745b9ebcc ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.
This was due to a too restrictive test which checked that the gadget
driver speed was either FS or HS.
So all gadget driver with max speed set to speed higher than
HS (SS in case of composite gadget driver in our case) are not
allowed, which is wrong.
Update the speed test in usb_gadget_register_driver() and in
dwc2_gadget_start() to allow all gadget driver speed equal or higher
than FS.
Tested on stm32mp157c-ev1 board.
Fixes: c791c8431c ("usb: dwc2: convert driver to DM_USB_GADGET")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
The OUT endpoint can just be ignored as it is not used, just as the
corresponding Set_Report request for IN-only interfaces. E.g. the
Linux gadget hid keyboard also provides an interrupt endpoint.
Also cleanup confusing debug messages like "found set protocol", which
is printed when a keyboard device is found, while the Set_Protocol request
is issued quite some time later.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
add support for the UUU commands ACmd and UCmd.
Enable them through the Kconfig option
CONFIG_FASTBOOT_UUU_SUPPORT
base was commit in NXP kernel
9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
and ported it to current mainline. Tested this patch
on imx6ul based board.
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This documents the way U-Boot understands partitions specifications.
This also updates the fastboot documentation for the changes in the
previous commit.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This anchor is only for the k210 partition layout, so rename it
appropriately. This keeps it from conflicting with the (to be added)
anchor for U-Boot partitions in general.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds support for partitions of the form "dev.hwpart:part" and
"dev#partname". This allows one to flash to eMMC boot partitions without
having to use CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT. It also allows one to
flash to an entire device without needing CONFIG_FASTBOOT_MMC_USER_NAME.
Lastly, one can also flash MMC devices other than
CONFIG_FASTBOOT_FLASH_MMC_DEV.
Because devices can be specified explicitly, CONFIG_FASTBOOT_FLASH_MMC_DEV
is used only when necessary for existing functionality. For those cases,
fastboot_mmc_get_dev has been added as a helper function. This allows
There should be no conflicts with the existing system, but just in case, I
have ordered detection of these names after all existing names.
The fastboot_mmc_part test has been updated for these new names.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This makes the next commit more readable by doing the move now.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The only thing mmcpart was used for was to pass to blk_dselect_hwpart.
This calls blk_dselect_hwpart directly from raw_part_get_info_by_name. The
error handling is dropped, but it is reintroduced in the next commit
(albeit less specificly).
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds support for things like "#partname" and "0.1#partname". The block
device parsing is done like in blk_get_device_part_str.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds an option to part_get_info_by_dev_and_name_or_num to allow
callers to specify whether whole-disk partitions are fine.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Several functions in disk/part.c just return -1 on error. This makes them
return different errnos for different failures. This helps callers
differentiate between failures, even if they cannot read stdout.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This test verifies the mapping between fastboot partitions and partitions
as understood by U-Boot. It also tests the creation of GPT partitions,
though that is not the primary goal.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds support writing to the sandbox mmc backed by an in-memory
buffer. The unit test has been updated to test reading, writing, and
erasing. I'm not sure what MMCs erase to; I picked 0, but if it's 0xFF
then that can be easily changed.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- turris_mox: Enhancements, mostlly defconfig changes (Pali)
- pci-aardvark: Set Max Payload Size and Max Read Request Size
to 512 bytes (Pali)
- pci_mvebu: Minor cleanup and refactoring (Marek)
- Upgrade A38x DDR3 training to version 14.0.0 (Marek)
