Samuel Holland [Wed, 13 Oct 2021 02:07:32 +0000 (21:07 -0500)]
net: phy: realtek: Add tx/rx delay config for 8211e
Some boards need to change the tx/rx delay config in order for
gigabit Ethernet to work.
In Linux commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), Realtek documented the bits for overriding the delays
from the hardware straps.
Copy the logic from linux, so the delay config is set from the PHY's
interface type (the phy-mode property in the device tree).
This removes the need for a one-off workaround for the Pine A64+ board.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Peter Hoyes [Thu, 14 Oct 2021 08:40:04 +0000 (09:40 +0100)]
cmd: pxe_utils: Check fdtcontroladdr in label_boot
If using OF_CONTROL, fdtcontroladdr is set to the fdt used to configure
U-Boot. When using PXE, if no fdt is defined in the menu file, and
there is no fdt at fdt_addr, add fall back on fdtcontroladdr too.
We are developing board support for the Armv8r64 FVP using
config_distro_bootcmd. We are also using OF_BOARD and would like the
PXE boot option to default to the fdt provided by board_fdt_blob_setup.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
Walter Stoll [Tue, 12 Oct 2021 11:01:59 +0000 (11:01 +0000)]
net: bootp: Correct VCI string transmission
The VCI string sent during bootp of U-Boot-SPL is corrupt. This is
because the byte counter is not adjusted within the bootp_extended()
function when the VCI string is added. We fix this.
Signed-off-by: Walter Stoll <walter.stoll@duagon.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Vladimir Oltean [Wed, 29 Sep 2021 15:04:42 +0000 (18:04 +0300)]
net: dsa: sja1105: add support for SGMII
The list of ports which support SGMII depending on switch generation is
available here:
https://www.kernel.org/doc/html/latest/networking/dsa/sja1105.html#port-compatibility-matrix
SGMII can either be used to connect to an external PHY or to the host
port. In the first case, the use of in-band autoneg is expected, in the
last, in-band autoneg is expected to be turned off (fixed-link). So the
driver supports both cases.
SGMII support means configuring the PCS and PMA. The PCS is a Synopsys
Designware XPCS, in Linux this has a separate driver but here it is
embedded within the sja1105 driver. If needed it can be taken out later,
although we would need a UCLASS_PCS for it, which we don't have atm.
Nonetheless, I did go all the way to export an internal MDIO bus for PCS
access, because it is nice to be able to debug the PCS through commands
such as:
=> mdio read ethernet-switch@1-pcs 4 1f.0
Reading from bus ethernet-switch@1-pcs
PHY at address 4:
31.0 - 0x1140
The internal MDIO bus is not registered with DM because there is no
udevice on it, as mentioned. But the XPCS code can still be ripped out,
as needed.
I did not add support for 2500base-x because I do not expect this
interface type to be used as a boot source for anybody, it would just
add unnecessary bloat.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Vladimir Oltean [Wed, 29 Sep 2021 15:04:41 +0000 (18:04 +0300)]
net: dsa: add driver for NXP SJA1105 L2 switch
The SJA1105 driver is largely reused from Linux. Its programming model
is that it is blank out of reset, and it waits for a static
configuration stream over SPI, which contains all runtime parameters (it
has no notion of "default values").
Keeping a binary array for the configuration stream would have meant
that aspects such as the CPU port and the MAC speeds could have not been
configured easily, and would have been static and board-dependent.
Live-patching the binary array means recalculating the static config
table CRCs, which is not a fun process.
So we create an abstraction over the static config tables, using the
packing API, same as in Linux. The tables are kept as C structures, and
the binary configuration stream is constructed on-the-go, with CRC and
all.
All static config tables instantiated in this driver are mandatory.
The hardware reference manual can be found at:
https://www.nxp.com/docs/en/user-guide/UM10944.pdf
For tagging, a simplified version of tag_8021q from Linux is used. The
VLAN EtherType is the same (0xdadb) but since we don't want switching in
U-Boot, there is no reason to have a TX VLAN and an RX VLAN for each
port. We just need the RX VLANs to act as the unique pvid of each
front-panel port, to decode the switch port number. The RX VLAN is used
for both RX and TX.
The device tree bindings are the same as in Linux.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Vladimir Oltean [Wed, 29 Sep 2021 15:04:40 +0000 (18:04 +0300)]
net: dsa: felix: configure the in-band autoneg property based on OF node info
Instead of trying to guess which operating modes need in-band
negotiation to be active and which ones don't, parse the available
information from the device tree. That will be correct in the cases we
can already guess, and more.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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.
Signed-off-by: Jon Lin <jon.lin@rock-chips.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
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.
Signed-off-by: Jon Lin <jon.lin@rock-chips.com> Reviewed-by: Stefan Agner <stefan@agner.ch>
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.
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
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.
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com> Reviewed-by: Joel Stanley <joel@jms.id.au>
Johnny Huang [Wed, 27 Oct 2021 06:17:27 +0000 (14:17 +0800)]
crypto: aspeed: Add AST2600 HACE support
Hash and Crypto Engine (HACE) is designed to accelerate the
throughput of hash data digest, and symmetric-key encryption.
Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com> Reviewed-by: Simon Glass <sjg@chromium.org>
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 <chiawei_wang@aspeedtech.com> Fixes: 1affd3abbe0 ("image: Drop if/elseif hash selection in calculate_hash()") Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
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.
Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Wolfgang Denk <wd@denx.de>
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.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Tested-by: Marek Behún <marek.behun@nic.cz>
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.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Behún <marek.behun@nic.cz>
Simon Glass [Mon, 1 Nov 2021 01:17:03 +0000 (19:17 -0600)]
Makefile: Correct TPL rule for OF_REAL
Correct an error in the tpl-dtb parameter to binman. At present the TPL
rule follows SPL but this is not correct, if TPL uses of-platdata, for
example.
Fixes: e67101947eb ("fdt: Update Makefile rules with the new OF_REAL Kconfig") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Marek Behún [Wed, 3 Nov 2021 23:23:23 +0000 (00:23 +0100)]
env: Simplify env_get_default()
Instead of pretending that we don't have environment to force searching
default environment in env_get_default(), get the data from the
default_environment[] buffer directly.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 4 Nov 2021 03:09:18 +0000 (21:09 -0600)]
binman: Support updating the dtb in an ELF file
WIth EFI we must embed the devicetree in an ELF image so that it is loaded
as part of the executable file. We want it to include the binman
definition in there also, which in some cases cannot be created until the
ELF (u-boot) is built. Add an option to binman to support writing the
updated dtb to the ELF file u-boot.out
This is useful with the EFI app, which is always packaged as an ELF file.
Simon Glass [Thu, 4 Nov 2021 03:09:16 +0000 (21:09 -0600)]
binman: Support reading the offset of an ELF-file symbol
Binman needs to be able to update the contents of an ELF file after it has
been build. To support this, add a function to locate the position of a
symbol's contents within the file.
Fix the comments on bss_data.c and Symbol while we are here.
Tom Rini [Mon, 8 Nov 2021 03:59:50 +0000 (22:59 -0500)]
Remove CONFIG_SERIAL_MULTI
This symbol has been functionally dead for a long time. Remove the last
and recent re-introductions of setting it, and update the whitelist so
it will not be re-introduced again.
Tom Rini [Mon, 8 Nov 2021 03:59:38 +0000 (22:59 -0500)]
Convert CONFIG_ENV_IS_IN_SPI_FLASH et al to Kconfig
This converts the following to Kconfig:
CONFIG_ENV_IS_IN_SPI_FLASH
CONFIG_ENV_IS_NOWHERE
CONFIG_ENV_OFFSET
CONFIG_ENV_OVERWRITE
CONFIG_ENV_SECT_SIZE
CONFIG_SYS_MMC_ENV_DEV
CONFIG_SYS_MMC_ENV_PART
projects / uboot.git / log