In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
CONFIG_DM_ETH, so the function prototype definition when
CONFIG_DM_ETH=n does nothing, so it can be dropped. It is also
never reachable, since the whole function is already under #ifdef
CONFIG_PHY_FIXED (which again, as I said, depends on CONFIG_DM_ETH=y).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-3-olteanv@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.
It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of parsing gd->fdt_blob directly,
because that enables it to work on live OF systems.
The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c ("drivers/net/phy: add fixed-phy /
fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already
mismatched leading to a potential truncation (flat OF offset was
supposed to be a long and not an int), we really cannot extend this
hack any longer, because there's no way an int will hold the other
representation of ofnode, the struct device_node *np.
So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in
commit eef0b8a930 ("net: phy: add ofnode node to struct phy_device").
This will populate phydev->node for the fixed PHY.
Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.
I do believe I've converted all the possible call paths for creating
a PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-2-olteanv@gmail.com>
[bmeng: keep fixedphy_probe(); update mdio-uclass.c to handle fixed phy]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
the ethernet controller connects to a fixed-link pseudo-PHY device.
Note there are two ways to describe a fixed PHY attached to an
Ethernet device:
- the new DT binding, where 'fixed-link' is a sub-node of the
Ethernet device
- the old DT binding, where 'fixed-link' is a property with 5
cells encoding various information about the fixed PHY
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Per the upstream Linux kernel doc:
Documentation/devicetree/bindings/net/ethernet-controller.yaml
There are two ways to describe a fixed PHY attached to an Ethernet
device. This updates our dt-bindings doc to add the old DT bindings.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Add a driver for the PowerPC Book E watchdog driver that is present on a
number of Freescale/NXP SoCs.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The SELI8 design is a new tdm service unit card for Hitachi-Powergrids
XMC and FOX product lines.
It is based on NXP LS1021 SoC and it provides following interfaces:
- IFC interface for NOR, NAND and external FPGA's
- 1 x RGMII ETH for debug purposes
- 2 x SGMII ETH for management communication via back-plane
- 1 x uQE HDLC for management communication via back-plane
- 1 x I2C for peripheral devices
- 1 x SPI for peripheral devices
- 1 x UART for debug logging
It is foreseen that the design will be later re-used for another XMC and
FOX service cards with similar SoC requirements.
Signed-off-by: Rainer Boschung <rainer.boschung@hitachi-powergrids.com>
Signed-off-by: Matteo Ghidoni <matteo.ghidoni@hitachi-powergrids.com>
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Includes DT definition for the following serdes protocols using various
PHY cards: 85xx, 13xx, 65xx, 9999, 7777.
Note that the default device tree for QDS now uses 85xx.
Enabling any of the others requires patching the fsl-ls1028a-qds.dtsi
file (the includes at the bottom of the file).
The phy-handle is specified as a path rather than a label because it is
possible to use the #include multiple times (meaning that more than one
PHY riser card of one type is inserted), and therefore, there would be
duplicate labels with the same name.
LBRW means that the board needs lane B rework before using this dtsi.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Add support for the DW PCIe controller found in the Amlogic Meson AXG and
G12 (G12A, G12B, SM1) SoCs.
This uses the common DW PCIe helpers introducted previously.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
With the introduction of pcie_dw_rockchip, and need to support the DW PCIe in the
Amlogic AXG & G12 SoCs, most of the DW PCIe helpers would be duplicated.
This introduce a "common" DW PCIe helpers file with common code merged from the
dw_ti and dw_rockchip drivers and adapted to fit with the upcoming dw_meson.
The following changes will switch the dw_ti and dw_rockchip to use these helpers.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Green Wan <green.wan@sifive.com>
[bmeng: remove the blank line at EOF of drivers/pci/pcie_dw_common.c]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Fix copy/paste errors in the descriptions of mtrr_close () and mtrr_set().
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
An entry is missing in the FSP-S devicetree bindings, and as a result
the description for the next few following entries is off by one line.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Most modern OpenSSL engines have methods overridden at the EVP level rather
than at RSA level, to make these engines work properly with mkimage, the RSA
signing code needs to switch to using EVP_* APIs as much as possible.
Signed-off-by: Donald Chan <hoiho@lab126.com>
[trini: Rebase on top of keyfile changes]
Signed-off-by: Tom Rini <trini@konsulko.com>
OP-TEE images are normally packaged with
type = "tee;
os = "tee";
However, fit_image_load() thinks that is somehow invalid. However if
they were declared as type = "kernel", os = "linux", fit_image_load()
would happily accept them and allow the boot to continue. There is no
technical limitation to excluding "tee".
Allowing "tee" images is useful in a boot flow where OP-TEE is
executed before linux.
In fact, I think it's unintuitive for a "load"ing function to also do
parsing and contain a bunch ad-hoc heuristics that only its caller
might know. But I don't make the rules, I just write fixes. In more
polite terms: refactoring the fit_image API is beyond the scope of
this change.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Consider the following FIT:
images {
whipple {};
};
configurations {
conf-1 {
firmware = "whipple";
};
};
Getting the 'firmware' image with fit_image_load() is not possible, as
it doesn't understand 'firmware =' properties. Although one could pass
IH_TYPE_FIRMWARE for 'image_type', this needs to be converted to a
"firmware" string for FDT lookup -- exactly what this change does.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The 'firmware' property of a config node takes precedence over the
'kernel' property. 'standalone' is deprecated. However, give users a
couple of releases where 'standalone' still works, but warns loudly.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
U-Boot expects the FDT to be located right after the _end
linker symbol (see fdtdec.c: board_fdt_blob_setup())
The "basic" LOAD_FIT path is aware of this limitation, and relocates
the FDT at the expected location. Guessing the expected location
probably only works reliably on 32-bit arm, and it feels like a hack.
One proposal would be to pass the FDT address to u-boot
(e.g. using 'r2' on arm platforms).
The variable is named "fdt_hack" to remind future contributors that,
"hey! we should fix the underlying problem". However, that is beyond
the scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The information on the OS should be contained in the FIT, as the
self-explanatory "os" property of a node under /images. Hard-coding
this to U_BOOT might send us down the wrong path later in the boot
process.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The correct FDT to use is described by the "fdt" property of the
configuration node. When the fit_unamep argument to fit_image_load()
is "fdt", we get the "/images/fdt" node. This is incorrect, as it
ignores the "fdt" property of the config node, and in most cases,
the "/images/fdt" node doesn't exist.
Use NULL for the 'fit_unamep' argument. With NULL, fit_image_load()
uses the IH_TYPE_FLATDT value to read the config property "fdt",
which points to the correct FDT node(s).
fit_image_load() should probably be split into a function that reads
an image by name, and one that reads an image by config reference. I
don't make those decisions, I just point out the craziness.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Several architectures had a default board_fit_config_name_match already;
this provides a generic weak version. We default to rejecting all configs.
This will use the FIT's default config, instead of the first config. This
may result in boot failures if there are multiple configurations and the
first config is *not* the default.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
The new correct way to load an FPGA image is to declare it in the list
of "loadables". multi-with-fpga.its used the now deprecated "fpga"
property. Since this example most likely intended to use u-boot's
generic FPGA loading code, compatible = "u-boot,fpga-legacy" is also
appropriate here.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The "simple" SPL_LOAD_FIT path is the most compliant with the format
documented in doc/uImage.FIT/source_file_format.txt. The other two
paths to load a FIT are SPL_LOAD_FIT_FULL and the "bootm" command.
Since the Kconfig menu is the most likely place for a new user to see
these options, it seems like the most logical candidate to document
the limitations. This documents the _known_ issues, and is not
intended to be a complete list of all follies.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 4afc4f37c7 ("doc: FIT image: Clarify format and simplify
syntax") and delegated FPGA images to be added via the list of
"loadables" in lieu of the "fpga" property. Now actually implement
this in code.
Note that the "compatible" property is ignored for the time being, as
implementing "compatible" loading is beyond the scope of this change.
However, "u-boot,fpga-legacy" is accepted without warning.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Commit 4afc4f37c7 ("doc: FIT image: Clarify format and simplify
syntax") requires that FPGA images be referenced through the
"loadables" in the config node. This means that "fpga" properties in
config nodes are deprecated.
Given that there are likely FIT images which use "fpga", let's not
break those right away. Print a warning message that such use is
deprecated, and give users a couple of releases to update their
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The FPGA loading code in spl_simple_fit_read() can easily be separated
from the rest of the logic. It is split into two functions instead of
one because spl_fit_upload_fpga() is used in a subsequent patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 4afc4f37c7 ("doc: FIT image: Clarify format and simplify
syntax") introduced a "compatible" property for loadable images.
It did not define its contents. Use "u-boot,fpga-legacy" compatible
string to specify that fpga_load() should be used to load the image.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
spl_load_fit_image() will try to load an image at the address given
in the "load" property. Absent such property, it uses
image_info->load_addr
Correct use of this is demonstrated in spl_fit_append_fdt(), which
resets the 'load_addr' before each spl_load_fit_image() call.
On the other hand loading "loadables" loop in spl_load_simple_fit()
completely ignores this. It re-uses the same structure, but doesn't
reset load_addr. If loadable [i] does not have a "load" property, its
load address defaults to load_addr, which still contains the address
of loadable [i - 1].
A simple solution is to treat NULL as an invalid load address. The
caller can set load_addr = 0 to request an abort if the "load"
property is absent.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Originally, the ECDSA code path used 'keydir' as the key filename.
mkimage has since been updated to include a new 'keyfile' argument.
Use the new argument for passing in the key.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the ECDSA signing path to use the appropriate one.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the RSA signing path to use the appropriate one.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's not always desirable to use 'keydir' and some ad-hoc heuristics
to get the filename of the signing key. More often, just passing the
filename is the simpler, easier, and logical thing to do.
Since mkimage doesn't use long options, we're slowly running out of
letters. I've chosen '-G' because it was available.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After lots of debating, this documents how we'd like mkimage to treat
'keydir' and 'keyfile' arguments. The rest is in the docs.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test to make sure that the ECDSA signatures generated by
mkimage can be verified successfully. pyCryptodomex was chosen as the
crypto library because it integrates much better with python code.
Using openssl would have been unnecessarily painful.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We wish to use pycryptodomex to verify code paths involving ECDSA
signatures. Add it to requirements.txt so that they get picked up
automatically .gitlab and .azure tasks
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mkimage supports rsa2048, and rsa4096 signatures. With newer silicon
now supporting hardware-accelerated ECDSA, it makes sense to expand
signing support to elliptic curves.
Implement host-side ECDSA signing and verification with libcrypto.
Device-side implementation of signature verification is beyond the
scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
fdt_add_bignum() is useful for algorithms other than just RSA. To
allow its use for ECDSA, move it to a common file under lib/.
The new file is suffixed with '-libcrypto' because it has a direct
dependency on openssl. This is due to the use of the "BIGNUM *" type.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
rsa-checksum.c sontains the hash_calculate() implementations. Despite
the "rsa-" file prefix, this function is useful for other algorithms.
To prevent confusion, move this file to lib/, and rename it to
hash-checksum.c, to give it a more "generic" feel.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In case exit is called in a script without parameter, the command
returns -2 ; in case exit is called with a numerical parameter,
the command returns -2 and lower. This leads to the following problem:
=> setenv foo 'echo bar ; exit 1' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit 0' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit -2' ; run foo ; echo $?
bar
0
That is, no matter what the 'exit' command argument is, the return
value is always 0 and so it is not possible to use script return
value in subsequent tests.
Fix this and simplify the exit command such that if exit is called with
no argument, the command returns 0, just like 'true' in cmd/test.c. In
case the command is called with any argument that is positive integer,
the argument is set as return value.
=> setenv foo 'echo bar ; exit 1' ; run foo ; echo $?
bar
1
=> setenv foo 'echo bar ; exit 0' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit -2' ; run foo ; echo $?
bar
0
Note that this does change ABI established in 2004 , although it is
unclear whether that ABI was originally OK or not.
Fixes: c26e454dfc
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Tom Rini <trini@konsulko.com>
Call the translation function on the ofnode_read_resource result only
when the livetree is not activated.
Today of_address_to_resource() calls ofnode_read_resource() for livetree
support and fdt_get_resource() when livetree is not supported.
The fdt_get_resource() doesn't do the address translation
so when it is required when livetree is activated but this address
translation is already done by ofnode_read_resource().
Fixes: 240720e905 ("firmware: scmi: mailbox/smt agent device")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This is the only driver that uses this function. Update it to use the
alternative which is dm_gpio_clrset_flags().
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Harm Berntsen <harm.berntsen@nedap.com>
Select CMD_QFW and QFW_MMIO in the qemu-arm board (covers arm and
arm64).
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add MMIO driver for QFW.
Note that there is no consumer as of this patch.
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A sandbox driver and test are added for the qfw uclass, and a test in
QEMU added for qfw functionality to confirm it doesn't break in real
world use.
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
