| Age | Commit message (Collapse) | Author |
|---|
|
At present test_pinmux_status() assumes that test_pinmux_dev() has run
beforehand. Drop this assumption so we can run the tests in parallel.
Signed-off-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dm
Binman VPL support (patch was lost)
Add board_rng_seed() as a temporary solution
|
|
Add support for U-Boot's Verifying Program Loader phase.
Signed-off-by: Simon Glass <[email protected]>
|
|
A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.
This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.
Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.
The board code is responsible for how to actually obtain those
bytes.
- One possibility is for the board to load a seed "file" from
somewhere (it need not be a file in a filesystem of course), and
then ensure that that the same seed file does not get used on
subsequent boots.
* One way to do that is to delete the file, or otherwise mark it as
invalid, then rely on userspace to create a new one, and living
with the possibility of not finding a seed file during some boots.
* Another is to use the scheme used by systemd-boot and create a new
seed file immediately, but in a way that the seed passed to the
kernel and the new (i.e. next) seed cannot be deduced from each
other, see the explanation at
https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
and the current code at
https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c
- The board may have an hwrng from which some bytes can be read; while
the kernel can also do that, doing it in U-Boot and providing a seed
ensures that even very early users in the kernel get good random
numbers.
- If the board has a sensor of some sort (temperature, humidity, GPS,
RTC, whatever), mixing in a reading of that doesn't hurt.
- etc. etc.
These can of course be combined.
The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.
So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?
I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide
ok, let's pass back this buffer and use that as seed, but also let's
set random.trust_bootloader=n so no entropy is credited.
This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
There shouldn't be a reason to have LMB on for these configurations.
LMB was already disabled for ZynqMP by commit 0063487a5b60 ("configs:
zynqmp: Disable LMB for mini u-boot").
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/07d95f619a15672d1a234eddcfbb54c0ab382eaa.1662460867.git.michal.simek@amd.com
|
|
LMB is not required for mini u-boot which runs out of on chip memory.
Disable CONFIG_LMB from mini u-boot defconfig's.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/45fad28825f0f236ad45e700aca1f39afbb22236.1659691195.git.michal.simek@amd.com
|
|
The commit 9996cea75f5a ("lmb/bdinfo: dump lmb info via bdinfo") added
support for dumping LMB information as the part of bdinfo. But code itself
should be called only when LMB is enabled.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://lore.kernel.org/r/3e40c8bb77550dfca9f7eb48fe644a018d971411.1662537127.git.michal.simek@amd.com
|
|
With 2022.01-rc3 upgrade, the size of the mini U-Boot increased and is
not able to fit in OCM. Hence disable unnecessary configs and make room.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/306b57818601fa3571bc75c4182f25aaa3f2a793.1659691195.git.michal.simek@amd.com
|
|
Xilinx is using pca954x i2c muxes on a lot of boards that's why enable this
driver by default.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/c090aea3436c7a4ebe698da6cbc70e70a14baae3.1659691195.git.michal.simek@amd.com
|
|
The user provided key address was not flushed in struct aes because of
the flushing location in the function.
Signed-off-by: Janne Ylalehto <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
The drivers informs the user that a post config was not run after FPGA
configuration. This message is unnecessary in SPL because the
ps7_post_config function is called via spl_board_prepare_for_boot
function before jump_to_image_no_args function from board_init_r
function.
Signed-off-by: Stefan Herbrechtsmeier <[email protected]>
Link: https://lore.kernel.org/r/20220808145331.24723-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <[email protected]>
|
|
Move arm twd timer driver from zynq to generic location.
DM timer drivers are designed differently to original driver. Timer is
counting up and not down.
Information about clock rates are find out in timer_pre_probe() that's
why there is no need to get any additional information from DT in the
driver itself (only register offset).
Signed-off-by: Stefan Herbrechtsmeier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-10-rc5
Documentation:
* man-page for tftpput
UEFI:
* fix driver binding protocol for block IO devices
* don't delete invalid handles
* add a unit test for the EFI Conformance Profile Table
Other:
* correct short text for tftpboot
|
|
UEFI block devices can either mirror U-Boot's internal devices or be
provided by an EFI application like iPXE.
When ConnectController() is invoked for the EFI_BLOCK_IO_PROTOCOL
interface for such an application provided device we create a virtual
U-Boot block device of type "efi_blk".
Currently we do not call ConnectController() when handles for U-Boot's
internal block devices are created. If an EFI application calls
ConnectController() for a handle relating to an internal block device,
we erroneously create an extra "efi_blk" block device.
E.g. the UEFI shell has a command 'connect -r' which calls
ConnectController() for all handles with device path protocol.
In the Supported() method of our EFI_DRIVER_BINDING_PROTOCOL return
EFI_UNSUPPORTED when dealing with an U-Boot internal device.
Reported-by: Etienne Carriere <[email protected]>
Fixes: commit 05ef48a2484b ("efi_driver: EFI block driver")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Etienne Carriere <[email protected]>
Tested-by: Etienne Carriere <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Change efi_delete_handle() to not free EFI handles twice.
This change tries to resolved an issue seen since U-Boot v2022.07
in which ExitBootService() attempts to release some EFI handles twice.
The issue was seen booting a EFI shell that invokes 'connect -r' and
then boots a Linux kernel. Execution of connect command makes EFI
subsystem to bind a block device for each root block devices EFI handles.
However these EFI device handles are already bound to a driver and we
can have 2 registered devices relating to the same EFI handler. On
ExitBootService(), the loop removing the devices makes these EFI handles
to be released twice which corrupts memory.
This patch prevents the memory release operation caused by the issue but
but does not resolve the underlying problem.
Signed-off-by: Etienne Carriere <[email protected]>
Add log message.
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Add a new unit test to test the integrity of the
EFI Conformance Profile Table.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We can use efi_st_get_config_table() in multiple unit tests.
Export the function.
Export system-table and boot-services.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Provide a man-page for the tftpput command.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The command's name is a misnomer.
The command loads a file but does not run (boot) it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Calling tftpput with less than 2 arguments must lead to a failure.
If tftpput is called with two arguments, these are the address and
the size of the file to be transferred.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
- simplify the STM32MP15x package parsing code
- remove test on CONFIG_DM_REGULATOR in stm32mp1 board
and enable CONFIG_DM_REGULATOR for stm32f769-disco
- handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start'
after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>)
- Fix SYS_HZ_CLOCK value for stih410-b2260 board
- Switch STMM32MP15x DHSOM to FMC2 EBI driver
- Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel
|
|
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq
- Pali's patch not in my patchwork, got missed.
- Sean's patch pending for sometime, I just fix conflict when apply
Sean's patch, so pick up.
|
|
binman fixes for bintool support
|
|
Fman microcode is executable code (AFAICT) loaded into a
coprocessor. As such, if verified boot is enabled, it must be verified
like other executable code. However, this is not currently done.
This commit adds verified boot functionality by encapsulating the
microcode in a FIT, which can then be signed/verified as normal. By
default we allow fallback to unencapsulated firmware, but if
CONFIG_FIT_SIGNATURE is enabled, then we make it mandatory. Because
existing Layerscape do not use this config (instead enabling
CONFIG_CHAIN_OF_TRUST), this should not break any existing boards.
An example (mildly-abbreviated) its is provided below:
/ {
#address-cells = <1>;
images {
firmware {
data = /incbin/(/path/to/firmware);
type = "firmware";
arch = "arm64";
compression = "none";
signature {
algo = "sha256,rsa2048";
key-name-hint = "your key name";
};
};
};
configurations {
default = "conf";
conf {
description = "Load FMAN microcode";
fman = "firmware";
};
};
};
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Sean Anderson <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Several ethernet drivers load firmware from FIT images. Convert them to
use the fit_get_data helpers.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
This converts the FIT loading process of the fpga command to use
fit_get_data_node.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
This reduces sec_firmware_get_data to a single call to
fit_get_data_conf_prop. I think sec_firmware_check_copy_loadable could also
be converted, but it does not map as straightforwardly, so I have left it
for a future cleanup.
Signed-off-by: Sean Anderson <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Several different firmware users have repetitive code to extract the
firmware data from a FIT. Add some helper functions to reduce the amount
of repetition. fit_conf_get_prop_node (eventually) calls
fdt_check_node_offset_, so we can avoid an explicit if. In general, this
version avoids printing on error because the callers are typically
library functions, and because the FIT code generally has (debug)
prints of its own. One difference in these helpers is that they use
fit_image_get_data_and_size instead of fit_image_get_data, as the former
handles external data correctly.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The config to use for FIT images can be better specified by enabling
CONFIG_MULTI_DTB_FIT and implementing board_fit_config_name_match.
Signed-off-by: Sean Anderson <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Correctly calculate offsets between SPL and proper U-Boot when new config
option CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR for generating eSDHC boot sector
is enabled. Otherwise SPL would not be able to boot proper U-Boot.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
mode
CPLD in load_default mode ignores watchdog reset signal. It does not reset
board when watchdog triggers reset signal.
Detect load_default mode by GPIO7 - LOAD_DEFAULT_N and delete watchdog
max6370 node from device to prevent registering driver for non-working
watchdog.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
sd2boot and defboot
All *boot env commands overrides default boot source location via i2c.
After board reset without power off, BootROM then starts booting U-Boot
from this specified location instead of the default one.
Add new env command defboot which reverts boot location to the default
value, which in most cases is configurable by HW DIP switches.
And add new env commands norlowerboot, norupperboot, sd2boot to boot from
other locations. norlowerboot would instruct BootROM to boot from lower NOR
bank, norupperboot from upper NOR bank and sd2boot from SD card with
alternative configuration.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Removes hwlocks properties from stm32mp151 pinctrl node. These locks
could be used for other purpose, depending on board and software
configuration hence do not enforce their use to protect pinctrl
devices.
This patch is an alignment with Linux device tree with v6.0 as the
hwsem support wasn’t yet added in pincontrol in kernel. It avoids
issues when the Linux kernel is started with the U-Boot device tree.
Cc: Patrice Chotard <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Signed-off-by: Etienne Carriere <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Perform long overdue conversion of ad-hoc FMC2 EBI bus initialization
to upstream FMC2 EBI driver. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
|
|
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq
Reset fixes for p1_p2_rdb_pc
Fix use after free issue fix in fsl_enetc.c
Fix for fsl ddr: make bank_addr_bits reflect actual bits
sl28 board update
|
|
SYS_HZ_CLOCK was wrongly set to 1GHz whereas it's set to 750MHz
by default by bootrom.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Grzegorz Szymaszek <[email protected]>
|
|
Since commit 5bc6f8c2a97e("video: stm32: remove test on CONFIG_DM_REGULATOR")
backlight was broken with the following message at boot:
stm32-display-dsi dsi@40016c00: Warning: cannot get phy dsi supply
stm32_display display-controller@40016800: panel panel enable backlight error -38
DM_REGULATOR flag must be enabled to fix this issue
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Since commit ef4ce6df3289 "video: stm32: stm32_ltdc: fix data enable polarity"
The panel display output wasn't functional anymore.
Device tree display-timings de-active property value must be updated
to 1.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Handle the input clock of RCC USB_PHY_48, provided by USBPHYC
and named "ck_usbo_48m".
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
ck_usbo_48m is generated by usbphyc PLL and used by OTG controller
for Full-Speed use cases with dedicated Full-Speed transceiver.
ck_usbo_48m is available as soon as the PLL is enabled.
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Add the counter of the PLL user n_pll_cons managed by the 2 functions
stm32_usbphyc_pll_enable / stm32_usbphyc_pll_disable.
This counter allow to remove the function stm32_usbphyc_is_init
and it is a preliminary step for ck_usbo_48m introduction.
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
The tests on CONFIG_DM_REGULATOR, added to avoid compilation issues, can
now be removed, they are no more needed since the commit 16cc5ad0b439
("power: regulator: add dummy helper").
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Simplify the package parsing code for STM32MP15X as package can be
affected with get_cpu_package() result.
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.
Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.
Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.
Fixes: 20fb58fc5a1c ("board: freescale: p1_p2_rdb_pc: Implement board_reset()")
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Watchdog starts working again after CPU reset via
non-watchdog method.
Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.
Note that reset does not occur immediately after calling do_reset(), but
after few ms later as real reset is done by CPLD. So it is normal that
function do_reset() returns. Therefore hangs after calling do_reset() to
prevent CPU execution of the rest U-Boot code.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.
This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.
But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.
To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.
With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.
Signed-off-by: Pali Rohár <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
System reset via the SRST extension in the SBI should be the default.
The driver checks if the extension is available when probing.
So there is no risk in enabling it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
Format the KVM implementation number in a human readable form.
With the patch output of the sbi command for Linux 5.19.1 looks like:
=> sbi
SBI 0.3
KVM 5.19.1
Machine:
Vendor ID 0
Architecture ID 7005c
Implementation ID 7005c
Extensions:
SBI Base Functionality
Timer Extension
IPI Extension
RFENCE Extension
Hart State Management Extension
System Reset Extension
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
