This ensures both interfaces can be used in U-Boot and both MAC addresses
are exported to the Linux kernel devicetree.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
We need to set CONFIG_SDP_LOADADDR to a valid RAM address to make
SDP boot work. Use the end of the DDR (256 MiB minimum) as other
boards do.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
The header from the local directory should use double quotes instead
of brackets. Otherwise the compiler might not search the local
directory.
Fixes: 93935acc6f ("imx: imx6ul: kontron-sl-mx6ul: Select correct boot and env device")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Rasmus Villemoes <ravi@prevas.dk> says:
The first two patches make memtest run ~40x faster (when, as it should
be, dcache is disabled), with the second patch being responsible for
most of that. At least on the beagleboneblack which I used for
testing; other boards and configurations will likely see different
numbers.
This is for CONFIG_SYS_ALT_MEMTEST=y and
CONFIG_SYS_ALT_MEMTEST_BITFLIP=n; one could probably get a similar
improvement in the bitflip case since that also has a schedule() call
in the inner loop.
Link: https://lore.kernel.org/r/20250822181848.3325832-1-ravi@prevas.dk
Hiding a qualifier such as "volatile" inside a typedef makes the code
much harder to understand. Since addr and dummy being
volatile-qualified are important for the correctness of the test code,
make it more obvious by spelling it out as "volatile ulong".
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>
A function call itself for every word written or read+written in these
loops is bad enough. But since the memory test must be run with dcache
disabled, the schedule() call, traversing the linked list of
registered cyclic clients, and accessing the 'struct cyclic_info' for
each to see if any are due for a callback, is quite expensive. On a
beagleboneblack, testing a modest 16MiB region takes 2.5 minutes:
=> dcache off
=> time mtest 0x81000000 0x82000000 0 1
Testing 81000000 ... 82000000:
Iteration: 1
Tested 1 iteration(s) with 0 errors.
time: 2 minutes, 28.946 seconds
There is really no need for calling schedule() so frequently. It is
quite easy to limit the calls to once for every 256 words by using a
u8 variable. With that, the same test as above becomes 37 times
faster:
=> dcache off
=> time mtest 0x81000000 0x82000000 0 1
Testing 81000000 ... 82000000:
Iteration: 1
Tested 1 iteration(s) with 0 errors.
time: 4.052 seconds
Note that we are still making a total of
3 loops * (4 * 2^20 words/loop) / (256 words/call) = 49152 calls
during those ~4000 milliseconds, so the schedule() calls are still
done less than 0.1ms apart.
These numbers are just for a beagleboneblack, other boards may have a
slower memory, but we are _two orders of magnitude_ away from
schedule() "only" being called at 100Hz, which is still more than
enough to ensure any watchdog is kept happy.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>
It is obviously important that the addr pointer used to access the
memory region being tested is volatile-qualified, to prevent the
compiler from optimizing out the "write this value, read it back,
check that it is what we expect".
However, none of these auxiliary variables have any such need for,
effectively, being forced to live on the stack and cause each and
every reference to them to do a memory access.
This makes the memtest about 15% faster on a beagleboneblack.
Before:
=> dcache off
=> time mtest 0x81000000 0x81100000 0 1
Testing 81000000 ... 81100000:
Iteration: 1
Tested 1 iteration(s) with 0 errors.
time: 10.868 seconds
After:
=> dcache off
=> time mtest 0x81000000 0x81100000 0 1
Testing 81000000 ... 81100000:
Iteration: 1
Tested 1 iteration(s) with 0 errors.
time: 9.209 seconds
[Without the 'dcache off', there's no difference in the time, about
0.6s, but the memtest cannot usefully be done with dcache enabled.]
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/27536
- Update compatibles for PMICs used by exynos devices
- Support system reset and reset status for pca9450
- Fix for pca9450 LDO5 registers and drop deprecated sd-vsel-gpios
- Two minor fixes found by smatch
Remove unnecessary whitespace before '\n' in trace printf
format strings (checkpatch warning QUOTED_WHITESPACE_BEFORE_NEWLINE).
No functional change intended.
Signed-off-by: Bhimeswararao Matsa <bhimeswararao.matsa@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In sdhci_iproc_execute_tuning the variable tuning_loop_counter is
unsigned and therefore will always fail the test for it being less than
0. Fix this by changing the variable type to be s8.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
PCA9450 PMIC supports reading the reset status from the PWRON_STAT
register. Bits 7-4 give indication of the PMIC reset cause:
- PWRON (BIT7) - Power ON triggered by PMIC_ON_REQ input line,
- WDOGB (BIT6) - Boot after cold reset by WDOGB pin (watchdog reset),
- SW_RST (BIT5) - Boot after cold reset initiated by the software,
- PMIC_RST (BIT4) - Boot after PMIC_RST_B input line trigger.
Add support for reading reset status via the sysreset framework in a
convenient printable format.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The family of PCA9450 PMICs have the ability to perform system resets.
Restarting via PMIC is preferred method of restarting the system as all
the peripherals are brought to a know state after a power-cycle. The
PCA9450 features a cold restart procedure which is initiated by an I2C
command 0x14 to the SW_RST register.
Support in Linux for restarting via PCA9450 PMIC has been added by
Linux commit 6157e62b07d9 ("regulator: pca9450: Add restart handler").
Now add support for it also in the U-Boot via sysreset framework.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
exynos_power_init sets up regulators for the emmc and sdcard, but
these regulators are already marked as always-on and boot-on and hence
are handled already by the regulator-uclass. Since we currently try to
set them up twice we get error -114 (EALREADY) from exynos_power_init
on every boot:
LDO20@VDDQ_EMMC_1.8V: set 1800000 uV; enabling (ret: -114)
LDO22@VDDQ_EMMC_2.8V: set 2800000 uV; enabling (ret: -114)
LDO21@TFLASH_2.8V: set 2800000 uV; enabling (ret: -114)
Remove the superfluous exynos_power_init to silence these errors.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8997 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
All u-boot users now use maxim,max8997-pmic instead, as does Linux's
DTSes, so we can now safely drop the maxim,max8997 compatible.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Instead of maxim,max8997. Linux uses maxim,max8997-pmic, so with this
change we align the trats DTS with its linux counterpart.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux's DTSes uses maxim,max8997-pmic, so check for this compatible
as well so that max8997 pmic driver can support both u-boot and
Linux's DTSes.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8998 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux uses just regulators { }; instead of voltage-regulators { };, so
this change aligns the DTSes found in the two projects.
The max8998 driver does not yet parse the regulators node, so we can
safely change its name without breaking anything.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
All devicetrees that use s2mps11 driver have been converted to use
regulators { };, so we can safely drop the voltage-regulators fallback
check.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
With this both linux and u-boot uses the same node name, which
simplifies devicetree parsing in s2mps11 driver.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Linux's DTSes uses regulators { }; while u-boot's DTSes uses
voltage-regulators { };. Look for regulators, and fallback to
voltage-regulators if not found, so that both type of DTSes can be
used with the driver.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The sd-vsel-gpios property in the root of the PMIC node is deprecated
and therefore not parsed by the driver anymore. We can safely remove
this as it wasn't used anyway due to the pad not having the correct
pinmux settings.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The sd-vsel-gpios property in the root of the PMIC node is deprecated
and therefore not parsed by the driver anymore. We can safely remove
this as it wasn't used anyway due to the pad not having the correct
pinmux settings.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
There are two ways to set the output voltage of the LD05
regulator. First by writing to the voltage selection registers
and second by toggling the SD_VSEL signal.
Usually board designers connect SD_VSEL to the VSELECT signal
controlled by the USDHC controller, but in some cases the
signal is hardwired to a fixed low level (therefore selecting
3.3V as initial value for allowing to boot from the SD card).
In these cases, the voltage is only determined by the value
of the LDO5CTRL_L register. Introduce a property
nxp,sd-vsel-fixed-low to let the driver know that SD_VSEL
is low and there is no GPIO to actually get that
information from dynamically.
This is equivalent to the following change in Linux:
c8c1ab2c5cb7 ("regulator: pca9450: Handle hardware with fixed SD_VSEL for LDO5")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
For LDO5 we need to be able to check the status of the SD_VSEL input in
order to know which control register is used. Read the status of the
SD_VSEL signal via GPIO and use the correct register accordingly.
To use this, the LDO5 node in the devicetree needs the sd-vsel-gpios
property to reference the GPIO that is used to read back the SD_VSEL
status internally. Please note that the SION bit in the IOMUX must be
set if the signal is muxed as VSELECT and controlled by the USDHC
controller.
This is equivalent to the following change in Linux:
3ce6f4f943dd ("regulator: pca9450: Fix control register for LDO5")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The LDO5 regulator has two configuration registers, but only
LDO5CTRL_L contains the bits for enabling/disabling the regulator.
This is equivalent to the following change in Linux:
f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5")
Fixes: 326337fb00 ("pmic: pca9450: Add regulator driver")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This reverts commit 2add051175.
It turns out that all boards using the PCA9450 actually have the
SD_VSEL input connected to the VSELECT signal of the SoCs SD/MMC
interface. Therefore we don't need manual control for this signal
via GPIO and there aren't any users.
This is equivalent to the following change in Linux:
c73be62caabb ("Revert "regulator: pca9450: Add SD_VSEL GPIO for LDO5"")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The code in tps65910_regulator.c treats the field supply in struct
tps65910_regulator_pdata as an int and even tests the value for being
negative so change it from a u32 to int so that the code all works as
expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The video test here is specific to the sandbox SDL video driver, so only
build it when that is enabled rather than VIDEO is enabled.
Reported-by: Alison Chaiken <alison@she-devel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The MediaTek mt6323 power driver cannot build without access to some
platform specific header files. Express that requirements in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
The commends in include/power/pmic.h say that once SPL_DM_PMIC exists we
should update things. This has been true for some time, so let us update
this to have the legacy portions in their own header, which should not
be directly included. This cleans up the logic within the file too
slightly.
Signed-off-by: Tom Rini <trini@konsulko.com>
In tps65941_buck_val and tps65941_ldo_val hex is an unsigned variable
being assigned the return value from a function that returns int. Change
hex to be an int so that the following test for an error as a negative
value will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In order to get the expected result from
rzg2l_usbphy_regulator_get_enable the return expression needs
parenthesis so that the binary and is performed before the double
logical not.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In palmas_smps_val and palmas_ldo_val hex is an unsigned variable being
assigned the return value from a function that returns int. Change hex
to be an int so that the following test for an error as a negative value
will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In lp87565_buck_val hex is an unsigned variable being assigned the return
value from a function that returns int. Change hex to be an int so that
the following test for an error as a negative value will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In lp873x_buck_val and lp873x_ldo_val hex is an unsigned variable being
assigned the return value from a function that returns int. Change hex
to be an int so that the following test for an error as a negative value
will work as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
In pmic_reg_read ret is only assigned to inside #if
CONFIG_IS_ENABLED(DM_I2C) so move the test and return ret inside as well
and also guard the declaration of ret with CONFIG_IS_ENABLED(DM_I2C) to
prevent a warning about an unused variable.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
In axp_init after checking the chip ID there is an else clause that
returns ret. ret is guaranteed to be 0 at this point as the code would
have returned above if not. The next statement is a return 0 so the
return ret is redundant, remove it.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
AMD/Xilinx/FPGA changes for v2026.01-rc1
mbv:
- Add it to CI loop
versal2:
- Wire UFS driver
serial:
- Add support for OF_PLATDATA in uartlite
misc:
- Mark some structures as const
u-boot internals were being corrupted following an EFI callback to
get_rng(). One of the many footprints was a corruption of the EFI
protocols linked list.
A request for >16 bytes of random data is broken into smaller requests.
Those requests are fed in a loop to the CAAM RNG, which uses a job
queue ring for interaction.
However, the job queue descriptor is created only at probe time. That
descriptor may end up needing an endian swap (LS1046A) before being fed
to the CAAM RNG. This corrupts the descriptor for the next iteration,
since it will be blindly endian swapped yet again.
Two issues arise. The number of words to endian swap is taken from the
input descriptor itself. So on the second iteration, the length has been
corrupted. This results in a corruption past the end of the descriptor:
whatever is after in memory is endian swapped too. Second, some of the
entries in the descriptor are DMA addresses. If the descriptor is still
somehow considered valid after swapping, the data at the corrupted DMA
address is now trampled.
Linux properly initializes the descriptor for each iteration. This is
what is now done with this commit.
Signed-off-by: Anthony Pighin <anthony.pighin@nokia.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
These values were calculated but not set.
They are required for the calculation of the delays, as stated in the
"QorIQ LS1043A Reference Manual, Rev. 6, 07/2020" page 2172.
The delays are calculated as (1/freq)*PCSSCK*CSSCK and
(1/freq)*PASC*ASC.
Signed-off-by: Tomas Alvarez Vanoli <tomas.alvarez-vanoli@hitachienergy.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In get_lpuart_clk_rate if the call to clk_get_rate returns an error then
the call to return should pass the value of the error which is in rate
rather than ret which will be 0 as its value is not affected by this
error.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Annette KobouandFabio Estevam
Frieder SchrempfandFabio Estevam
Tom Rini
Rasmus VillemoesandTom Rini
Bhimeswararao MatsaandPeng Fan
Andrew GoodbodyandPeng Fan
Primoz FiserandPeng Fan
Henrik GrimlerandPeng Fan
Anthony Pighin (Nokia)andPeng Fan
Tomas Alvarez VanoliandPeng Fan