Tom Rini [Tue, 28 Nov 2023 17:53:14 +0000 (12:53 -0500)]
Merge patch series "sysinfo: Expand sysinfo with some more banner information"
To quote the author:
The show_board_info() function was adjusted to weak so that it could be
entirely replaced with a board-specific implementation.
The intended way for boards to provide their own information is via a
sysinfo driver. But currently there is no way to show anything other
than the model name.
This series adds support for showing a few more items, in a way that is
easy for boards to extend.
Since there is already a weak checkboard() function, we don't need to
have two levels of weak function here. So this series drops the weak
attribute from show_board_info()
Existing boards will see a slight change in output, in that the model
name will appear first, before any custom output. If that is a problem,
then the solution is to implement a sysinfo driver for the board.
Simon Glass [Mon, 13 Nov 2023 02:58:29 +0000 (19:58 -0700)]
x86: coreboot: Add a sysinfo driver
Create a sysinfo driver to avoid needing a custom checkboard()
function. With this the following information is printed when booting
from coreboot under QEMU:
Model: Standard PC (i440FX + PIIX, 1996)
Manufacturer: QEMU
Prior-stage version: 4.21-885-g2a87ef1eca56
Prior-stage date: 11/11/2023
Simon Glass [Mon, 13 Nov 2023 02:58:28 +0000 (19:58 -0700)]
sysinfo: Allow displaying more info on startup
At present only the model name is shown on start. Some boards want to
display more information. Add some more options to allow display of the
manufacturer as well as the version and date of any prior-stage
firmware.
This is useful for coreboot, at least. If other boards have more
information to display, it is easy to add it, now.
Simon Glass [Mon, 13 Nov 2023 02:58:27 +0000 (19:58 -0700)]
Revert "generic-board: make show_board_info a weak function"
We already have:
- a sysinfo driver-interface which can obtain the model
- a weak function called checkboard() for showing board info
The current implementation has a weak function on top of a weak
function. Now that all boards have been updated to use checkboard()
instead, drop the __weak on show_board_info()
Simon Glass [Mon, 13 Nov 2023 02:58:26 +0000 (19:58 -0700)]
udoo: Use checkboard() instead of show_board_info()
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Simon Glass [Mon, 13 Nov 2023 02:58:25 +0000 (19:58 -0700)]
toradex: Use checkboard() instead of show_board_info()
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Make all the checkboard() functions call the new tdx_checkboard() so
that the same information is displayed.
Simon Glass [Mon, 13 Nov 2023 02:58:24 +0000 (19:58 -0700)]
solidrun: Use checkboard() instead of show_board_info()
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Simon Glass [Mon, 13 Nov 2023 02:58:23 +0000 (19:58 -0700)]
turris: Use checkboard() instead of show_board_info()
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Simon Glass [Mon, 13 Nov 2023 02:58:22 +0000 (19:58 -0700)]
meson: Use checkboard() instead of show_board_info()
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Bin Meng [Wed, 11 Oct 2023 13:15:48 +0000 (21:15 +0800)]
pci_ids: Add Red Hat vendor and device IDs
Red Hat, Inc. donates a part of its device ID range [1] to QEMU,
to be used for virtual devices. This commit adds several typical
devices that are useful in U-Boot.
- Make dfu entity name size configurable in KConfig
- Implement start-stop for UMS (graceful shutdown via eject)
- Improve help messages for cmd/bind
- Improve help message for udc bind failures
Tom Rini [Sat, 25 Nov 2023 17:32:48 +0000 (12:32 -0500)]
Merge branch '2023-11-25-assorted-platform-updates' into next
- Updates for the Siemens AM335x platforms, Nuvoton platforms, and
disable CONFIG_NET on platforms that lack NETDEVICES, so that
NETDEVICES can be implied by NET.
Tom Rini [Thu, 9 Nov 2023 00:12:25 +0000 (19:12 -0500)]
net: Make NET imply NETDEVICES
Normally, when NET is enabled, CMD_NET will then be enabled and in turn
NETDEVICES will (likely) be enabled via imply. However, if we disable
CMDLINE in a defconfig we now no longer get CMD_NET enabling NETDEVICES
for us. This suggestion (as an imply is) really isn't about the network
commands but network itself and is a legacy of how intertwined
NET/CMD_NET were historically. Move this over to the NET entry instead
where it is a more logical fit.
Reported-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 17 Nov 2023 15:47:57 +0000 (10:47 -0500)]
boards: Disable NET on platforms without NETDEVICES
None of these platforms enabled a networking devices, and disabled
CMD_NET. Given that we used to gate network support on CMD_NET rather
than NET, we disable CONFIG_NET on these platforms now.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Enrico Leto [Wed, 8 Nov 2023 14:53:17 +0000 (15:53 +0100)]
siemens,am335x: clean-up draco targets
Draco is a family of 3 boards: thuban, rastaban & etamin. Rename all
targets of the family adding the draco- prefix to increase readibility
and simplify future commits about concerning all boards of the family.
The name draco was initially used for the first target. It's deprecated
since a 2nd target was introduced. Unfortunately the draco target was
copied to the thuban target instead to be renamed. Remove it to save
unnecessary maintenance effort.
Signed-off-by: Enrico Leto <enrico.leto@siemens.com>
Tom Rini [Wed, 22 Nov 2023 19:05:53 +0000 (14:05 -0500)]
Merge branch '2023-11-22-TI-K3-cleanups' into next
This brings in a large number of cleanups and reorganizations to the TI
K3 family of SoCs. We get DTS resyncs for most of the SoCs under that
umbrella as well, and a few enhancements too.
arm: dts: k3-*-binman: Move to using templated FITs
Reduce redundancy in code by using templates to generate the A72 boot
binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb
(for legacy boot following devices J721E and AM65x).
Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Acked-by: Andrew Davis <afd@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
arm: dts: k3-binman: Add support for FIT templates
Add templates for FIT images used extensively across K3 boards with most
of the code common. This includes the FIT portions of:
- tispl.bin
- u-boot.img
- sysfw.itb (in case of legacy boot flow)
Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
arm: k3: Enable instruction cache for main domain SPL
Change spl_enable_dcache so it also enable icache on SPL
initialization for the main domain part of the boot flow. This
improves bootloader booting time.
Robert Nelson [Sat, 4 Nov 2023 08:11:00 +0000 (03:11 -0500)]
arm: dts: Add k3-j721e-beagleboneai64
BeagleBoard.org BeagleBone AI-64 is an open source hardware single
board computer based on the Texas Instruments TDA4VM SoC featuring
dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
2x 6-core Programmable Real-Time Unit and Industrial Communication
SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
BeagleBone expansion headers.
This board family can be indentified by the BBONEAI-64-B0 in the
at24 eeprom:
Nishanth Menon [Sat, 4 Nov 2023 08:01:35 +0000 (03:01 -0500)]
board: Move beagleplay under beagle vendor folder
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now] Signed-off-by: Tom Rini <trini@konsulko.com>
Nishanth Menon [Sat, 4 Nov 2023 08:01:33 +0000 (03:01 -0500)]
arm: dts: k3-am625-beagleplay-u-boot/r5: Just depend on k3-binman.dtsi
With the upcoming folder separation, there is no further need to depend
on am625-binman.dtsi. Duplicate the existing definitions to u-boot.dtsi
and r5.dts as appropriate.
Nishanth Menon [Sat, 4 Nov 2023 07:21:50 +0000 (02:21 -0500)]
doc: board: ti: j721e_evm: Use board relative path for include directives
When using include directives within a section that is included by non
TI board rst file, k3.rst and other include paths need to be relative to
doc/board/ base.
Nishanth Menon [Sat, 4 Nov 2023 07:21:49 +0000 (02:21 -0500)]
configs: j7200_evm_a72_defconfig: Switch to bootstd
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Nishanth Menon [Sat, 4 Nov 2023 07:21:48 +0000 (02:21 -0500)]
configs: j7200: Remove HBMC_AM654 config
Kernel commit 1b77265626a4 ("arm64: dts: ti: k3-j7200-mcu-wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.
This is similar to the approach in commit 5b2671594b80 ("configs:
j721e: Remove HBMC_AM654 config"), introduced to j7200 evm platform.
Nishanth Menon [Sat, 4 Nov 2023 07:21:47 +0000 (02:21 -0500)]
arm: mach-k3: j721e: Improve support for UDA FS
Commit 5019170970ad ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b368b ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
Nishanth Menon [Sat, 4 Nov 2023 07:21:44 +0000 (02:21 -0500)]
arm: mach-k3: Kconfig: Introduce a symbol to indicate J7200
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Nishanth Menon [Sat, 4 Nov 2023 07:21:43 +0000 (02:21 -0500)]
configs: j721e_evm_a72_defconfig: Switch to bootstd
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Nishanth Menon [Sat, 4 Nov 2023 02:45:11 +0000 (21:45 -0500)]
arm: mach-k3: Move TI dummy keys out of board folder
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Nishanth Menon [Sat, 4 Nov 2023 02:45:10 +0000 (21:45 -0500)]
arm: mach-k3: Move K3 degenerate keys out of board folder
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Davis <afd@ti.com>
Andrew Davis [Tue, 14 Nov 2023 15:59:49 +0000 (09:59 -0600)]
arm: mach-k3: Remove incorrect checks for SPL build
The kconfig option SPL means this build supports SPL but not that
this build is SPL, nor that this build is the SPL running on R5.
For options that are for R5 SPL use CPU_V7R.
Andrew Davis [Wed, 1 Nov 2023 20:35:30 +0000 (15:35 -0500)]
arm: mach-k3: j721s2: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:29 +0000 (15:35 -0500)]
arm: mach-k3: am62ax: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:28 +0000 (15:35 -0500)]
arm: mach-k3: am62x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:27 +0000 (15:35 -0500)]
arm: mach-k3: am64x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:26 +0000 (15:35 -0500)]
arm: mach-k3: am65x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:25 +0000 (15:35 -0500)]
arm: mach-k3: j721e: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:24 +0000 (15:35 -0500)]
board: ti: Add dependency from TARGET selection to SOC
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Miquel Raynal [Tue, 10 Oct 2023 09:03:04 +0000 (11:03 +0200)]
usb: udc: Try to clarify an error message
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.
Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.
Miquel Raynal [Tue, 10 Oct 2023 09:03:03 +0000 (11:03 +0200)]
cmd: bind: Try to improve the (un)bind help
While it may sound totally obvious for the regular U-Boot developer to
get the parameters of the bind/unbind commands from the output of 'dm
tree', it did not felt straightforward to me until I was explicitly
told to look there. And even when I knew the command, I did not make a
direct link between the arguments of this command and the columns
returned by 'dm tree'.
Several of us lost a lot of time because of that, I would like to kindly
help other users by slightly improving this textual line. Unfortunately,
because of how this string is used (like within the 'help' command) I
cannot detail much more, but at least the pointer is there.
While we add this message, we can also imply CMD_DM when we enable
CMD_BIND so the debug message does not lead to an unknown command. This
way the 'dm' command will likely be there unless explicitly disabled.
Miquel Raynal [Tue, 10 Oct 2023 09:03:02 +0000 (11:03 +0200)]
cmd: Change the dependencies between CMD_BIND and USB_GADGET
Today CMD_BIND defaults to 'y' when USB_ETHER is enabled. In practice,
CMD_BIND should default to 'y' when any USB gadget is enabled not only
USB_ETHER. Let's invert the logic of the dependency and use the weak
'imply' keyword to enforce this.
Marek Vasut [Tue, 7 Nov 2023 00:09:59 +0000 (01:09 +0100)]
usb: gadget: f_mass_storage: Stop ums on START-STOP UNIT SCSI command
Exit the UMS handler loop in case START-STOP UNIT SCSI command is
received. This is sent e.g. by the util-linux eject(1) command and
indicates to the device that it is supposed to spin down the media
and enter low power state.
This effectively adds support for exitting the 'ums' command from
host using 'eject /dev/sdN' that is on par with 'dfu-util -e' .
Jaehoon Chung [Mon, 20 Jun 2022 11:13:54 +0000 (20:13 +0900)]
dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
Add CONFIG_DFU_NAME_MAX_SIZE to change the proper size.
If name is longer than default size, it can do wrong behavior during updating
image. So it need to change the proper maximum size.
This patch is proviced the solution to change value with configuration.
scsi: set dma direction to NONE for TEST UNIT READY
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.
With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.
Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Marek Vasut <marex@denx.de>
projects / u-boot.git / log