Vladimir Oltean [Wed, 29 Sep 2021 15:04:39 +0000 (18:04 +0300)]
net: introduce a helper to determine whether to use in-band autoneg
Certain serial SERDES protocols like 1000base-x, 2500base-x, SGMII,
USXGMII can operate either in a mode where the PHY (be it on-board or
inside an SFP module) passes the link parameters (speed, duplex, pause)
to the MAC through in-band through control words standardized by IEEE
802.3 clause 37, or in a mode where the MAC must configure (force) its
link parameters based on information obtained out-of-band (MDIO reads,
guesswork etc).
In Linux, the OF node property named "managed" is parsed by the phylink
framework, and the convention is that if a driver uses phylink, then the
presence of this property means that in-band autoneg should be enabled,
otherwise it shouldn't.
To be compatible with the OF node bindings of drivers that use phylink
in Linux, introduce parsing support for this property in U-Boot too.
Vladimir Oltean [Wed, 29 Sep 2021 15:04:38 +0000 (18:04 +0300)]
net: dsa: allow drivers to get the port OF node
In the current DSA switch driver API, only the udevice of the switch
(belonging to UCLASS_DSA) is exposed, as well as an "int port" argument.
So drivers do not have access to the udevice of individual ports
(belonging to UCLASS_ETH), one of the reasons being that not all ports
have an associated UCLASS_ETH udevice.
However, all DSA ports have an OF node, and in some cases the driver
needs a handle to it, for all ports including the CPU port. Example: the
following Linux per-port device tree property:
managed = "in-band-status";
states whether a port should operate with clause 37 in-band autoneg
enabled or not.
This patch exposes a function which can be called by individual drivers
as needed.
Vladimir Oltean [Wed, 29 Sep 2021 15:04:36 +0000 (18:04 +0300)]
net: tsec: add support for promiscuous mode
The Freescale TSEC can be a DSA master, and the ports of the attached
DSA switch can have different MAC addresses compared to the TSEC.
Nonetheless, the TSEC must receive the packets on behalf of those switch
ports. Therefore, implement the promiscuous mode method to allow DSA to
set this.
Note that the init_registers() function called from eth_ops :: start
overwrites this setting. There is no reason why the RCTRL register
should be zero-initialized, so just stop clearing it so that the setting
we applied in eth_ops :: set_promisc sticks.
Vladimir Oltean [Mon, 27 Sep 2021 23:13:42 +0000 (02:13 +0300)]
net: phy: mscc: add support for VSC8502 in dual RGMII mode
The VSC8502 is a Microchip (formerly Microsemi, formerly Vitesse)
dual port, gigabit Ethernet copper PHY which supports the MII, GMII and
RGMII MAC-side interfaces.
Of these, I could only test RGMII, and my board needed RGMII delays to
be applied by software, so I am able to confirm that this patch handles
that properly.
Tom Rini [Sat, 20 Nov 2021 14:36:37 +0000 (09:36 -0500)]
Merge branch 'efi-2022-01' of https://source.denx.de/u-boot/custodians/u-boot-efi
Scripts:
* Update spelling.txt
LMB:
* remove extern keyword in lmb.h
* drop unused lmb_size_bytes()
Test:
* test truncation in snprintf()
Documentation:
* add include/lmb.h to HTML documentation
UEFI:
* reduce non-debug logging output for measured boot
* fix use after free in measured boot
* startup the tpm device when installing the protocol
* implement EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES
* record capsule result only if capsule is read
Ilias Apalodimas [Thu, 18 Nov 2021 08:13:42 +0000 (10:13 +0200)]
efi_loader: startup the tpm device when installing the protocol
Due to U-Boot's lazy binding mentality the TPM is probed but not properly
initialized. The user can startup the device from the command line
e.g 'tpm2 startup TPM2_SU_CLEAR'. However we can initialize the TPM during
the TCG protocol installation, which is easier to use overall.
Ilias Apalodimas [Thu, 18 Nov 2021 07:03:39 +0000 (09:03 +0200)]
efi_loader: fix FinalEvents table if an EFI app invoked GetEventLog
As described in the TCG spec [1] in sections 7.1.1 and 7.1.2 the FinalEvent
table should include events after GetEventLog has been called. This
currently works for us as long as the kernel is the only EFI application
calling that. Specifically we only implement what's described in 7.1.1.
So refactor the code a bit and support EFI application(s) calling
GetEventLog. Events will now be logged in both the EventLog and FinalEvent
table as long as ExitBootServices haven't been invoked.
Masami Hiramatsu [Fri, 12 Nov 2021 13:05:15 +0000 (22:05 +0900)]
efi_loader: capsule: Record capsule result only if capsule is read
Record capsule update result only if the capsule file is
successfully read, because the capsule GUID is not sure when
the file can not be read or the file is not a capsule.
Without this fix, if user puts a dummy (non-capsule) file
under (ESP)EFI/UpdateCapsule, U-Boot causes a synchronous
abort.
This also fixes use-after-free bug of the 'capsule' variable.
Tom Rini [Thu, 18 Nov 2021 23:25:19 +0000 (18:25 -0500)]
Merge branch '2021-11-18-regression-fixes'
- An assortment of fixes related to GD, GD_FLG_SKIP_RELOC, and the lmb
- Environment fix on synquacer developmentbox
- Fix for get_info is not valid in partition code
Marek Vasut [Sat, 13 Nov 2021 17:34:37 +0000 (18:34 +0100)]
lmb: Reserve U-Boot separately if relocation is disabled
In case U-Boot starts with GD_FLG_SKIP_RELOC, the U-Boot code is
not relocated, however the stack and heap is at the end of DRAM
after relocation. Reserve a LMB area for the non-relocated U-Boot
code so it won't be overwritten.
Marek Vasut [Sat, 13 Nov 2021 17:34:04 +0000 (18:34 +0100)]
board_f: Copy GD to new GD even if relocation disabled
Even if U-Boot has relocation disabled via GD_FLG_SKIP_RELOC , the
relocated stage of U-Boot still picks GD from new_gd location. The
U-Boot itself is not relocated, but GD might be, so copy the GD to
new GD location even if relocation is disabled.
Masami Hiramatsu [Thu, 18 Nov 2021 05:45:25 +0000 (14:45 +0900)]
Revert "board: synquacer: developerbox: Don't set gd->env_addr to default_environment"
Without default setting of gd->env_addr, U-Boot will cause
a synchronous abort if the env-variables on the SPI flash is
broken or not saved corectly. Set gd->env_addr correctly.
Tom Rini [Thu, 18 Nov 2021 18:46:00 +0000 (13:46 -0500)]
Merge branch '2021-11-17-assorted-driver-platform-updates' into next
- NVMe updates
- TI AM64x related USB updates
- Update PCIe CAM support macros, add PCI CAM support as well
- AST2600, Apple (ARM64) pinctrl drivers
- ARM-specific DEBUG uart inconsistencies fixed
- MediaTek MMC improvement
- aspeed: Support secure boot chain with FIT image verification
Jon Lin [Tue, 19 Oct 2021 02:40:54 +0000 (10:40 +0800)]
nvme: Fix error in nvme_setup_prps
Consulting to "NVM Express® Base Specification, revision 2.0".
If more PRP List pages are required, then the last entry of
the PRP List contains the Page Base Address of the next PRP
List page. The next PRP List page shall be memory page aligned.
Jon Lin [Tue, 19 Oct 2021 02:40:53 +0000 (10:40 +0800)]
nvme: Enable FUA
Most NVME devcies maintain data in internal cache for an uncertain
times, and u-boot has no method to force NVME to flush cache.
So this patch adds FUA to avoid data loss caused by power off after data
programming.
Alistair Delva [Wed, 20 Oct 2021 21:31:34 +0000 (21:31 +0000)]
RFC: arm: pci: Add PCI cam support to PCI-E ecam driver
When booting U-Boot in crosvm, the virtual machine emulates a PCI cam
device, not the PCI-E 'ecam' device normally seen on e.g. QEMU. This
PCI device can be supported with only trivial changes to the ecam
driver.
Instead of adding a completely new driver which is identical besides the
initialization step, add support for the PCI version to the existing
driver.
Chia-Wei Wang [Wed, 27 Oct 2021 06:17:35 +0000 (14:17 +0800)]
configs: ast2600: Boot kernel FIT in DRAM
AST2600 leverages the FIT hash/signature verification to fulfill
secure boot trust chain. To improve the performance and save SW
code size for those crypto operations, the two HW crypto engine,
HACE and ACRY, are enabled.
However, both of the engines can only access to data stored in
DRAM space. Therefore, we need to move the FIT image into DRAM
before the booting.
This patch update the CONFIG_BOOTCOMMAND to execute the pre-defined
ENV variable which consists of FIT image copy to memory and booting.
Chia-Wei Wang [Wed, 27 Oct 2021 06:17:32 +0000 (14:17 +0800)]
ast2600: spl: Locate load buffer in DRAM space
Return CONFIG_SYS_LOAD_ADDR pointing to DRAM space for
spl_get_load_buffer() to allow generic SPL image loading
code (e.g. FIT and Ymodem) to store data in DRAM.
Chia-Wei Wang [Wed, 27 Oct 2021 06:17:24 +0000 (14:17 +0800)]
image: fit: Fix parameter name for hash algorithm
Fix inconsistent function parameter name of the hash algorithm.
Signed-off-by: Chia-Wei Wang <[email protected]> Fixes: 92055e138f2 ("image: Drop if/elseif hash selection in calculate_hash()") Reviewed-by: Joel Stanley <[email protected]> Reviewed-by: Simon Glass <[email protected]>
Simon Glass [Wed, 3 Nov 2021 13:16:06 +0000 (07:16 -0600)]
arm: Init the debug UART
At present we don't init the debug UART in the generic ARM code, but
instead leave it to individual machines to handle. This is not the
way it is supposed to work.
Add the required init to the crt files. This ensures that the UART
is available as early as possible and that the announcement appears
when it should, if enabled.
Pali Rohár [Wed, 3 Nov 2021 00:01:05 +0000 (01:01 +0100)]
pci: Add standard PCIe ECAM macros
Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.
Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.
Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.
U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.
Without get_desc, the tpm command will not provide a
description of the device in 'tpm device' or 'tpm info'.
Due to the characteristics of the Atmel TPM it isn't
possible to determine certain attributes (e.g open/close
status) without using the TPM stack (compare Infineon
and ST TPM drivers), so just print out the chip model
and udevice name as the identifier.
Mathew McBride [Thu, 11 Nov 2021 04:06:27 +0000 (04:06 +0000)]
cmd: tpm-v1: fix load_key_by_sha1 compile errors
This command is not compiled by default and has not been updated alongside
changes to the tpmv1 API, such as passing the TPM udevice to the relevant
functions.
Tom Rini [Wed, 17 Nov 2021 01:55:12 +0000 (20:55 -0500)]
Merge branch '2021-11-16-env-rework' into next
To quote Simon:
One barrier to completing the 7-year-long Kconfig migration is that
the default environment is implemented using ad-hoc CONFIG options.
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS.
It is not really feasible to move the environment to Kconfig as it is
hundreds of lines of text in some cases.
Even considering the current situation, it is painful to add large
amounts of text to the config-header file and dealing with quoting and
newlines is harder than it should be. It would be better if we could just
type the script into a text file and have it included by U-Boot.
This is already supported by the CONFIG_USE_DEFAULT_ENV_FILE feature. But
that does not support use of CONFIG options or comments, so is best suited
for use by other build systems wanting to define the U-Boot environment.
Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file board/<vendor>/<board>.env or
use CONFIG_ENV_SOURCE_FILE to set a filename.
The environment variables should be of the form "var=value". Values can
extend to multiple lines. This series converts the existing environment
documentation to rST and updates it to explain how to use this.
Simon Glass [Fri, 22 Oct 2021 03:08:52 +0000 (21:08 -0600)]
bootm: Tidy up use of autostart env var
This has different semantics in different places. Go with the bootm method
and put it in a common function so that the behaviour is consistent in
U-Boot. Update the docs.
To be clear, this changes the way that 'bootelf' and standalone boot
work. Before, if autostart was set to "fred" or "YES", for example, they
would consider that a "yes". This may change behaviour for some boards,
but the only in-tree boards which mention autostart use "no" to disable
it, which will still work.
Simon Glass [Fri, 22 Oct 2021 03:08:46 +0000 (21:08 -0600)]
env: Allow U-Boot scripts to be placed in a .env file
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.
Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board/<vendor>
directory, typically called <board>.env and controlled by the
CONFIG_ENV_SOURCE_FILE option.
The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example.
In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.
This uses the C preprocessor, means that comments can be included in the
environment using /* ... */
Also support += to allow variables to be appended to. This is needed when
using the preprocessor.
Simon Glass [Fri, 22 Oct 2021 03:08:44 +0000 (21:08 -0600)]
sandbox: Drop distro_boot
This is a complicated set of #defines and it is painful to convert to a
text file. We can (once pending patches are applied) provide the same
functionality with bootmethod. Drop this for sandbox to allow conversion
to a text-file environment.
Tom Rini [Tue, 16 Nov 2021 14:51:04 +0000 (09:51 -0500)]
Merge tag 'xilinx-for-v2022.01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2022.01-rc3
sdhci:
- Fix emmc mini case with missing firmware interface
zynqmp:
- Restore JTAG interface if required
- Allow overriding board name
- Add support for DLC21
- Fix one fallthrought statement description
- Use config macro instead of name duplication
- Save multiboot to variable
firmware:
- Handle ipi_req errors better
- Use local buffer in case user doesn't need it instead of NULL/0 location
Andy Shevchenko [Mon, 8 Nov 2021 18:03:38 +0000 (21:03 +0300)]
image: Explicitly declare do_bdinfo()
Compiler is not happy:
common/image-board.c: In function ‘boot_get_kbd’:
common/image-board.c:902:17: warning: implicit declaration of function ‘do_bdinfo’ [-Wimplicit-function-declaration]
902 | do_bdinfo(NULL, 0, 0, NULL);
| ^~~~~~~~~
Masami Hiramatsu [Wed, 10 Nov 2021 00:40:07 +0000 (09:40 +0900)]
configs: synquacer: Fix dfu_alt_info to use nor1
Fix dfu_alt_info to use nor1 instead of the device name.
This reverts a part of commit 59bd18d4c4d7 ("configs: synquacer:
Remove mtdparts settings and update DFU setting") because the
commit a4f2d8341455 ("mtd: spi: nor: force mtd name to "nor%d"")
changed the mtd device naming scheme to nor%d.
The subdivision name "TQ Components" hasn't been in use for a long time.
Rename the vendor directory to "tq", which also matches our Device Tree
vendor prefix.
Alistair Delva [Wed, 20 Oct 2021 21:31:32 +0000 (21:31 +0000)]
arm64: relocate-rela: Add support for ld.lld
Cap end of relocations by the binary size.
Linkers like to insert some auxiliary sections between .rela.dyn and
.bss_start. These sections don't make their way to the final binary, but
reloc_rela still tries to relocate them, resulting in attempted read
past the end of file.
When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
default on arm64) breaks the build. After this patch, U-Boot can be
linked successfully with and without CONFIG_STATIC_RELA.
projects / u-boot.git / log