When probing the LEDs, a default brightness is set based on settings
from the U-Boot device tree, i.e. the 'default-brightness' property
of the LED nodes. If that property is not present, the default
maximum brightness is set.
This should make sure the LED controller's registers affecting the
brightness are correctly initialized and should give a consistent
behaviour.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
This was implemented in order to get dual-slot bootloader
partitions on the BeagleBone Black, whose MLO boots from
the first bootable partition: MLO chainloads u-boot in the
same way.
Signed-off-by: Jérôme Carretero <cJ-uboot@zougloub.eu>
Reviewed-by: Tom Rini <trini@konsulko.com>
Set digest_size SHA384 and SHA512 algorithms in pkcs7 and x509,
(not set by ported linux code, but needed by __UBOOT__ part).
EFI_CAPSULE_AUTHENTICATE doesn't select these algos but required for
correctness if certificates contain sha384WithRSAEncryption or
sha512WithRSAEncryption OIDs.
Signed-off-by: Dhananjay Phadke <dphadke@linux.microsoft.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add a driver which allows to use of LEDs connected
to PWM (Linux compatible).
MAINTAINERS: add i.vozvakhov as a maintainer of leds-pwm
C(required during new functionality adding).
Signed-off-by: Ivan Vozvakhov <i.vozvakhov@corp.mail.ru>
Modify function to support any salt length instead of max
length only. Function now detects salt length by parsing
the content of db buffer. Note that it works with (but is
not limited to) zero-length, digest-length and max-length
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to reduce memory
consumption of function by replacing memory copies of parts of
const buffer by pointers to the original buffer (masked_db and
h are subparts of msg buffer which is declared const, salt is a
subpart of db which is a working buffer, unmodified after being
filled). New pointers scope is limited to the function where
they are declared (not returned to caller by any mean), zeroing
risk of memory fault related to the change.
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to update
const-correctness in targeted functions to comply with
coding-rules and avoid const-cast
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
MCU Timer0 runs at 250MHz, and the clock-frequency defined in DT appears
incorrect.
Without this delays in R5 SPL are 10x off.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When the RNG device is secured with OP-TEE, it is only accessible with
the HWRNG TA, the CONFIG_RNG_OPTEE is needed for STM32MP15 targets
with OP-TEE support.
The probe of this RNG driver fails when the TA is not available in OP-TEE
and the previous driver can be used, as CONFIG_RNG_STM32MP1 is activated
and when the associated node is activated in the device tree with:
&rng1 {
status = "okay";
};
When the RNG is used in OP-TEE, this node should be deactivated in
the Linux and U-Boot device tree.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In U-Boot, the discovery of TA based on its UUID on the TEE bus is
not supported.
This patch only binds the driver associated to the new supported
OP-TEE TA = TA_HWRNG when this driver is enable.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add driver for OP-TEE based Random Number Generator on ARM SoCs
where hardware entropy sources are not accessible to normal world
and the RNG service is provided by a HWRNG Trusted Application (TA).
This driver is based on the linux driver: char/hw_random/optee-rng.c
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
To quote the author:
This series adds support for running valgrind against U-Boot's internal
malloc. This allows for much more useful reports to be generated.
Some example output of valgrind run against u-boot/master with this
branch applied may be found at [1]. Note that valgrind gives up around
acpi. This feature still needs a lot of work on suppressions/hints to
filter out the noise properly.
[1] 2a2f99108e/gistfile1.txt
This documents how to get more detailed results from valgrind made possible
by the last two commits.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This annotates malloc and friends so that valgrind can track the heap. To
do this, we need to follow a few rules:
* Call VALGRIND_MALLOCLIKE_BLOCK whenever we malloc something
* Call VALGRIND_FREELIKE_BLOCK whenever we free something (generally after
we have done our bookkeeping)
* Call VALGRIND_RESIZEINPLACE_BLOCK whenever we change the size of an
allocation. We don't record the original request size of a block, and
neither does valgrind. For this reason, we pretend that the old size of
the allocation was for 0 bytes. This marks the whole allocaton as
undefined, so in order to mark all bits correctly, we must make the whole
new allocation defined with VALGRIND_MAKE_MEM_DEFINED. This may cause us
to miss some invalid reads, but there is no way to detect these without
recording the original size of the allocation.
In addition to the above, dlmalloc itself tends to make a lot of accesses
which we know are safe, but which would be unsafe outside of dlmalloc. For
this reason, we provide a suppression file which ignores errors ocurring in
dlmalloc.c
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Valgrind uses magic code sequences to define an ABI that the client may use
to request behavior from the host. In particular, this may be used to
inform valgrind about custom allocators, such as the one used in U-Boot.
This adds headers defining these sequences to U-Boot. It also adds a config
option to disable emission of these sequences entirely, in the (likely)
event that the user does not wish to use valgrind. Note that this option is
called NVALGRIND upstream, but was renamed (and inverted) to
CONFIG_VALGRIND. Aside from this and the conversion of a few instances of
VALGRIND_DO_CLIENT_REQUEST_EXPR to STMT, these headers are unmodified.
These headers were copied from valgrind 3.16.1-4 as distributed in Arch
Linux. They are licensed with the bzip2 1.16 license. This appears to be a
BSD license with some clauses from Zlib.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
i.MX8MQ use SYS_MALLOC_F_LEN 0x2000, not 0x10000. The OCRAM_S only has
32KB memory, use 0x10000 will make SPL not bootable.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Documentation:
* Describe how enable DM_SERIAL for a board
UEFI
* Preparatory patches for better integration of DM and UEFI
* Use sysreset after capsule updates instead of do_reset
* Allow to disable persisting non-volatile variables
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmJSiD8ACgkQxIHbvCwF
GsQ5FRAAhjV2q+ZawfNRkLQTI+pr/SZFH/H/LypWex8uXO6Enx8QvMU96RBMbtQI
/LbduYDmRfhFbX2L5x+xV7feoMwvP+AOE4xmD55yuuWzmQttgEyGfwQY+mQYg3GU
PwNkBUVN1msoOq7OFjevlk406VvnpYqvAuen1H66m0HkRe73hYucrZnt6Wxy+p+F
fZdIaVpZc97jVHpLGNJBYg9JpUEkEeIcRaeUQHFIys/wZOiWWyTshYNLKQmfN3oV
qNm0iDZMcqCk4XYkQR8R4IjXTHejtgGcKZaQfoLEYONpDOjG+X+nAviJaQ3BLoSK
6+p3UhsoPgA0fT7sZg0dSn73f1xM7njDLhnR2JlZbKxDsV8SCA7+J/q7dElMX9Ld
9/BwzqwU4WpJh4whRdpTFkcRY1ytnBBwltNo9sRm89QfHFIuT9+Rxf6s8GAcbCNU
Pb6P6u44BkAGZG7hCUa3swh0EORISAxVhDJEEf4eWNlKHYE2A3dDFsLioGPPRoPS
RNpXcTfz3cT2E8buDGUefKKCP+9dzSRP5HLHasibfC6LdIaR0aKTS7a1S+C0jjwj
1W+GeStyGKzM+8hq5OREsAfCMRIs9bLq3vs+f7aPPn/FIgebLJmGFykswRQiQTAt
B4wArS79APrqBini887EPF9LoNTtdnRCst+xmMHxVEW0yyDwZWk=
=SxkC
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc1
Documentation:
* Describe how enable DM_SERIAL for a board
UEFI
* Preparatory patches for better integration of DM and UEFI
* Use sysreset after capsule updates instead of do_reset
* Allow to disable persisting non-volatile variables
This reverts commit 8d61237edb.
This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.
Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;
return 0;
}
if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;
return 0;
}
"
Furthermore, the commit is missing DCO SoB line.
Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>
When gpio_request_by_name allocates a gpio output it by default will
de-assert the gpio which for phy-reset will take the PHY out of reset.
As this occurs before eth_phy_reset is called to assert the reset
line it can cause undesired affects if reset timings are not properly
met.
Configure the gpio with GPIOD_IS_OUT_ACTIVE so that reset is kept active
(reset asserted) to avoid this.
Cc: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
When gpio_request_by_name allocates a gpio output it by default will
de-assert the gpio which for phy-reset will take the PHY out of reset.
As this occurs before fec_gpio_reset is called to assert the reset
line it can cause undesired affects if reset timings are not properly
met.
Configure the gpio with GPIOD_IS_OUT_ACTIVE so that reset is kept active
(reset asserted) to avoid this.
Cc: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx8mm-beacon
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Currently we require PHY interface mode to be known when
finding/creating the PHY - the functions
* phy_connect_phy_id()
* phy_device_create()
* create_phy_by_mask()
* search_for_existing_phy()
* get_phy_device_by_mask()
* phy_find_by_mask()
all require the interface parameter, but the only thing done with it is
that it is assigned to phydev->interface.
This makes it impossible to find a PHY device without overwriting the
set mode.
Since the interface mode is not used during .probe() and should be used
at first in .config(), drop the interface parameter from these
functions. Make the default value of phydev->interface (in
phy_device_create()) to be PHY_INTERFACE_MODE_NA. Move the interface
parameter to phy_connect_dev(), where it should be.
Change all occurrences treewide. In occurrences where we don't call
phy_connect_dev() for some reason (they only configure the PHY without
connecting it to an ethernet controller), set
phydev->interface = value from phy_find_by_mask call.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The bcmgenet and sun8i_emac drivers call phy_connect(), which finds /
creates the PHY and also connects it to the eth device via
phy_connect_dev(), then set some phydev members (bcmgenet only), and
then call phy_connect_dev() explicitly again.
Drop the second phy_connect_dev(), since it is unnecesary.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Use phydev->is_c45 instead of is_10g_interface(phydev->interface) to
determine whether clause 45 protocol should be used.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
We want to be able to have phydev->interface uninitialized during
->probe(). We should assume that phydev->interface is initialized only
before ->config().
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Move PHY_INTERFACE_MODE_NA to the beginning of the enum definition to
make it have zero value. This makes it possible (although not
encouraged) to test for invalid/nonexistent interface mode with !val
instead of val == PHY_INTERFACE_MODE_NA.
The comment near the definition says "Must be last", because when the
constant was introduced in commit 5f184715ec ("Create PHY Lib for
U-Boot"), it was used as the maximum value when interating over the
constants. But this is no longer true - we use PHY_INTERFACE_MODE_MAX
for that now, and so we can move it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Rename constant PHY_INTERFACE_MODE_NONE to PHY_INTERFACE_MODE_NA to make
it compatible with Linux' naming.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Rename constant PHY_INTERFACE_MODE_COUNT to PHY_INTERFACE_MODE_MAX to
make it compatible with Linux' naming.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add helpers ofnode_read_phy_mode() and dev_read_phy_mode() to parse the
"phy-mode" / "phy-connection-type" property. Add corresponding UT test.
Use them treewide.
This allows us to inline the phy_get_interface_by_name() into
ofnode_read_phy_mode(), since the former is not used anymore.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
The "phy-interface-type" property should be "phy-connection-type".
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Use the new dm_mdio_read/write/reset() wrappers treewide, instead of
always getting and dereferencing MDIO operations structure pointer.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add wrappers dm_mdio_read(), dm_mdio_write() and dm_mdio_reset() for
DM MDIO's .read(), .write() and .reset() operations.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in
net/mdio-uclass.c function dm_eth_connect_phy_handle(). Also add
corresponding UT test.
This is useful because other part's of U-Boot may want to get PHY ofnode
without connecting a PHY.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use the ARRAY_SIZE() macro instead of hardcoding sizes of arrays in
macros.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
These global variables should both have type
static const char * const
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The type of the return value of phy_read() and phy_read_mmd() is int.
Change the variable to not be unsigned so that we not get into an
unsigned compared against 0.
Signed-off-by: Haolin Li <li.haolin@qq.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
A DM_ETH driver may use phy_connect() towards a PHY address on an MDIO
bus which is not specified in the device tree, as evidenced by:
pfe_eth_probe
-> pfe_phy_configure
-> phy_connect
When this happens, the PHY will have an invalid OF node.
When ar803x_config() runs, it silently fails at ar803x_of_init(), and
therefore, fails to run the rest of the initialization.
This makes MII_BMCR contain what it had after BMCR_RESET (0x8000) has
been written into it by phy_reset(). Since BMCR_RESET is volatile and
self-clearing, the MII_BMCR ends up having a value of 0x0. The further
configuration of this register, which is supposed to be handled by
genphy_config_aneg() lower in ar803x_config(), never gets a chance to
run due to this early error from ar803x_of_init().
As a result of having MII_BMCR as 0, the following symptom appears:
=> setenv ethact pfe_eth0
=> setenv ipaddr 10.0.0.1
=> ping 10.0.0.2
pfe_eth0 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY pfe_eth0
Manually writing 0x1140 into register 0 of the PHY makes the connection
work, but it is rather desirable that the port works without any manual
intervention.
Fixes: fe6293a809 ("phy: atheros: add device tree bindings and config")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
A DM_ETH driver may use phy_connect() towards a PHY address on an MDIO
bus which is not specified in the device tree, as evidenced by:
pfe_eth_probe
-> pfe_phy_configure
-> phy_connect
When this happens, the PHY will have an invalid OF node.
The dp83867_config() method has extra initialization steps which are
bypassed when the PHY lacks an OF node, which is undesirable because it
will lead to broken networking. Allow the rest of the code to run.
Fixes: 085445ca41 ("net: phy: ti: Allow the driver to be more configurable")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
With dm-tag feature, any U-Boot subsystem is allowed to associate
arbitrary number of data with a particular udevice. This can been
see as expanding "struct udevice" without modifying the definition.
As a first user, UEFI subsystem makes use of tags to associate
an efi_disk object with a block device.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
virtio_init() enumerates all the peripherals that are to be materialised
with udevices(UCLASS_VIRIO) and creates particular device instances
(UCLASS_BlK or whatever else) as children.
On the other hand, device_probe() won't be invoked against those resultant
udevices unlike other ordinary device drivers do in the driver model.
This is particularly inconvenient when we want to add "event notification"
callback so that we will be able to automatically create all efi_disk
objects in a later patch.
With this patch applied, "virtio scan" will work in a similar way
to "scsi rescan", "usb start" or others in term of 'probe' semantics.
I didn't add this change to virtio_init() itself because this function
may be called in board_init_r() (indirectly in board_late_init())
before UEFI subsustem is initialized.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every time an ide bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every time a sata bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every time a nvme bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every time a mmc bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Every time a usb bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Every time a scsi bus/port is scanned and a new block device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use sysreset_walk_halt() directly from reset-after-capsule-on-disk
feature to reboot (cold reset) machine instead of using reset command
interface, since this is not a command.
Note that this will make CONFIG_EFI_CAPSULE_ON_DISK depending on
the CONFIG_SYSRESET.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Make efi_load_capsule_drivers() available even if EFI_CAPSULE_ON_DISK
is disabled because the caller (efi_init_obj_list()) expects it only
relays on EFI_HAVE_CAPSULE_SUPPORT.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
