Commit 5bb2c550b1 ("arm: mvebu: Move internal registers in
arch_very_early_init() function") moved code from file cpu.c to lowlevel.c,
which moves Marvell internal registers from address INTREG_BASE_ADDR_REG to
SOC_REGS_PHY_BASE.
But the steps describing how to do it correctly were documented only in
older U-Boot versions and commit cefd764222 ("arm: mvebu: Fix internal
register config on A38x") probably unintentionally removed important
details about MMU from code comments around.
Commit 5bb2c550b1 ("arm: mvebu: Move internal registers in
arch_very_early_init() function") implemented code movement according to
(now incomplete) comments which resulted in semi-broken code.
The result is that I-cache is currently disabled for all Armada 38x boards
and maybe there are some other (unreported / undetected) issues.
Reimplement it correctly. First flush all caches, then disable MMU and L2
cache and then move Marvell internal registers. There is no need to
explicitly disable I-cache.
After this change lzmadec command with lzma image of 0x7000000 bytes is
doing decompression just 5 seconds. Before this change it was 30 seconds.
To make lowlevel.S code more readable, extend asm/pl310.h header file to be
compatible with assembler and use macros from this file.
Fixes: 5bb2c550b1 ("arm: mvebu: Move internal registers in arch_very_early_init() function")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
For some unknown reason when L2 cache is disabled on Armada 385 then loadb,
loadx and loady commands do not work with higher baudrates than 115200
(they just abort transfer) and lzmadec command with lzma image of size
0x7000000 (maybe even smaller, we tested this one) is doing decompression
for more than 2 minutes. After enabling L2 cache decompression takes only
30s and loadb, loadx and loady are stable and working fine.
git bisect identified problematic commit 3308933d2f ("arm: mvebu: Avoid
reading MVEBU_REG_PCIE_DEVID register too many times"). Before this commit
above issues were not present.
But investigation showed that above issue was possible to reproduce also by
reverting that commit and forcing compiler to do inline optimization of
mvebu_soc_family() function. Which seems that the root of this issue is in
caches and position of instruction of segments. So currently it is unknown
what is or was broken, but code movement, code inlining or other compiler
optimization triggered it.
Commit 3e5ce7ceeb ("arm: mvebu: Enable L2 cache on Armada XP") mentioned
that enabling L2 cache on Armada XP improved performance and that Armada
38x has L2 disabled (which is default state) and if needed it has to be
enabled in separate patch. As enabling L2 cache also improve performance
on Armada 38x, enable it.
Note that Aurora cache in no outer mode is available only on Armada XP,
hence it is not touched for Armada 38x code.
Fixes: 3308933d2f ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times")
Reported-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Replace magic constant 1 when disabling MMU by macro CR_M from include
header file asm/system.h.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Commit c86d53fd88 ("arm: mvebu: Don't disable cache at startup on Armada
XP at all") introduced branch for non-AXP code which was guarded by A38X
condition. Fix this issue by checking for AXP platform, not by A38X.
Fixes: c86d53fd88 ("arm: mvebu: Don't disable cache at startup on Armada XP at all")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Commit 3308933d2f ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID
register too many times") broke support for caches on all Armada SoCs.
Before that commit there was code:
if (mvebu_soc_family() != MVEBU_SOC_A375) {
dcache_enable();
}
And after that commit there is code:
if (IS_ENABLED(CONFIG_ARMADA_375)) {
dcache_enable();
}
Comment above this code says that d-cache should be disabled on Armada 375.
But new code inverted logic and broke Armada 375 and slowed down all other
Armada SoCs (including A38x).
Fix this issue by changing logic to:
if (!IS_ENABLED(CONFIG_ARMADA_375)) {
dcache_enable();
}
Which matches behavior prior that commit.
Fixes: 3308933d2f ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Turris Omnia has two serial ports. Both are already specified in device
tree file. But U-Boot by default does not allow to use more than one serial
port unless CONFIG_SERIAL_PROBE_ALL is not enabled.
After enabling CONFIG_SERIAL_PROBE_ALL, U-Boot see also second serial port
(but is inactive by default):
=> coninfo
List of available devices:
serial@12000 00000007 IO stdin stdout stderr
serial@12100 00000007 IO
To allow simultaneously to use more input / output devices it is needed to
enable CONFIG_CONSOLE_MUX option.
With CONFIG_CONSOLE_MUX it is possible to call:
=> setenv stdout 'serial@12000,serial@12100'
And U-Boot output is then visible on both serial ports.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
TCGETS2 is defined in header file asm/ioctls.h provided by linux kernel.
On glib systems it is automatically included by some other glibc include
header file and therefore TCGETS2 is present in termios_linux.h when
linux kernel provides it.
On non-glibc systems (e.g. musl) asm/ioctls.h is not automatically included
which results in the strange error that BOTHER is supported, TCGETS2 not
defined and struct termios does not provide c_ispeed member.
tools/kwboot.c: In function 'kwboot_tty_change_baudrate':
tools/kwboot.c:662:6: error: 'struct termios' has no member named 'c_ospeed'
662 | tio.c_ospeed = tio.c_ispeed = baudrate;
| ^
Fix this issue by explicitly including asm/ioctls.h file which provides
TCGETS2 macro (if supported on selected architecture) to not depending on
glibc auto-include behavior and because termios_linux.h requires it.
With this change it is possible compile kwboot with musl libc.
Reported-by: Michal Vasilek <michal.vasilek@nic.cz>
Signed-off-by: Pali Rohár <pali@kernel.org>
$fdt_addr is mandatory for systems which provides DTB in HW (e.g. ROM) and
wishes to pass that DTB to Linux.
Turris Mox contains DTB binary in SPI NOR memory at "dtb" partition which
starts at offset 0x7f0000 and is 0x10000 bytes long.
Armada 3700 CPU does not allow mapping SPI NOR memory into physical address
space like on other architectures and therefore set $fdt_addr variable to
memory range in RAM and loads this DTB binary from SPI NOR in misc_init_r()
function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When rescue mode was activated reset also bootdelay env variable to its
default value. This will ensure that reset button works and starts rescue
mode also in the case when user changed bootdelay env variable to -1 (which
has meaning to not start autoboot).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Store serial number from atsha cryptochip into the serial# env variable.
U-Boot automatically puts content of this variable into the root device
tree property serial-number when booting Linux kernel. Refactor turris
atsha code and from turris_atsha_otp_get_serial_number() function returns
directly string suitable for printing or storing into device tree. Because
during different boot stages is env storage read-only, it is not possible
to always store serial number into env storage. So introduce a new function
turris_atsha_otp_init_serial_number() which is called at later stage and
which ensures that serial number is correctly stored into env.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
For obvious reasons BootROMS rejects unsigned images when secure boot is
enabled in OTP secure bits. So check for OPT secure bits and do not allow
flashing unsigned images when secure boot is enabled. Access to OTP via
U-Boot fuse API is currently implemented only for A38x and A37xx SoCs.
Additionally Armada 3700 BootROM rejects signed trusted image when secure
boot is not enabled in OTP. So add also check for this case. On the other
hand Armada 38x BootROM acceps images with secure boot header when secure
boot is not enabled in OTP.
OTP secure bits may have burned also boot device source. Check it also and
reject flashing images to target storage which does not match OTP.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Currently for A38x image is checked only header checksum.
So check also for image data checksum to prevent flashing broken image.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Testing on the theadorable Armada XP platform has shown, thaz using the
current value of 1000ms as response timeout does not result in reliable
booting via kwboot. Using 10ms seems to be much better. So let's change
this value to this 10ms instead.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Pali Rohár <pali@kernel.org>
Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
image method of booting. Debian and OpenWrt installer use uImage
with appended DTB for these Kirkwood boards.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Running tests in parallel is much faster, e.g. 15 seconds to run the tests
on sandbox (only), instead of 100 seconds (on a 16-core machine). Add a
'make pcheck' option to access this feature.
Note that the tools/ tests still run each tool's tests once after the
other, although within that, they do run in parallel. So for example,
the buildman tests run in parallel, then the binman tests run in
parallel. There would be a signiificant advantage to running them all
in parallel together, but that would require a large amount of
refactoring, e.g. with more use of pytest fixtures.
Update the documentation to represent the current state.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present when -n is used, all workers try to build U-Boot at once.
Add a lock to ensure that only one of them builds, with the others using
the build that is produced.
The lock file is removed on startup.
Signed-off-by: Simon Glass <sjg@chromium.org>
This assumes that the GPIO starts as 0 but it does not if
test_gpio_input() ran first and test_gpio_exit_statuses() was skipped.
This can happen when running tests in parallel.
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When doing a quick check we don't need to run all the vboot tests. Just
run the first one, which is enough to catch most problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
This test seems to interfere with the other test in this file. Mark it
single-threaded to avoid any problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
This test relies on the silent_linux env variable being set. Add this
to the code so it can run without relying on other bootm tests having been
run first.
Signed-off-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
Add board_rng_seed() as a temporary solution
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmMfNjoRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreaPVAf/SjZXU864AaleX1mCYtOSdhpAictwaJwY
k1MJ/NxuRzvkF+yUMqnJMXVCUno3M9g3zYP4caworu2xL/YEXKCCswyowpNGBMZP
uR84CgroKxLMjx2OPyWIpaAYEJz6O61Nj3AXuUx7y9XwOCiDImOi1et97LfgPA/z
sxBp7Q0QpPMFWiJ6oijH9PdnzoN2A2ddSSYzDiRUtCOsc5XOq6rx27PH10yDyFyV
oBhE/siuERnIt/MvPqs0aNIiKJ6lyjcqkMnDU94LD36EAT6Z3ll5tzJR1f7+DC3p
VFppSypxCJdIw07qliCcCFQhFAe5BcmWQ+FuDydWu3OjOVc/WX0V2w==
=r1u5
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-12sep22' of https://source.denx.de/u-boot/custodians/u-boot-dm
Binman VPL support (patch was lost)
Add board_rng_seed() as a temporary solution
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 <rasmus.villemoes@prevas.dk>
The user provided key address was not flushed in struct aes because of
the flushing location in the function.
Signed-off-by: Janne Ylalehto <ylalehto@gmail.com>
Link: https://lore.kernel.org/r/20220816124525.19671-1-ylalehto@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
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 <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20220808145331.24723-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
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 <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20220805061629.1207-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmMbeUEACgkQxIHbvCwF
GsSGsw//WJAuuzP5ufWGxJk2pR9v9LatIsV+w2W1fBTsTb/dbMZ4Sika2Z1izeer
vmakldnOTLoTXZxng/Ke9J7PEefS8NSUgHbXYLq6a5ckrsji58kGHhDvUjrU2eOf
D4SBh8eGW/wgmnzHgmsVU0vcXbtWUomWlV4v8SGjYWq5KOTOdFGYmMddqv8cnUVa
wXHktLaDi9TzzFdfeYPbAlKboQTdRkw0CbzY8z6jlxm2Yd/i7Iw9v7MWwFN5rv1N
Zlx9Kl0SV1Jz//yzUajyiXXVYK+kVcpjDcvOPhx4GL96mcvW4yyGlOKjpUkTR3H3
l7112u4lwNSUIJIeDMCazqKgdGMsl+RLuJymAIRCdaBs3c0FsuX4WHNAr0H1KT9X
oVnzeBKZKjFTT76Q39F80O0JrdDMxqMm1fGiy1ySlRCJNd+dlYZKoopt8PpWkk1E
IBHsE1m1OXe+n2PNrh6YR9egv9RmfdwBEl0wBftNb9DQ+gNAvR7wVRpmDRCqYuBR
l/k6GsznHK4hh1Wh+BhrrUeQ3YbboK3RvGA9toYp6BEk/5F2dDuy5pVM7OETjGEY
DaKjqPjMv41SCIzpcEkzPJEvQ0tEFuk+GEC168IXQmcV/gttvuLNLFfnlLE1amQr
g09ePeaXKzjiWYSi5wEz1GQs7W9WBnJ5+2zOL41ih125xra6/NE=
=1zZW
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-10-rc5' of 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 <etienne.carriere@linaro.org>
Fixes: commit 05ef48a248 ("efi_driver: EFI block driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Tested-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <etienne.carriere@linaro.org>
Add log message.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add a new unit test to test the integrity of the
EFI Conformance Profile Table.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <heinrich.schuchardt@canonical.com>
Provide a man-page for the tftpput command.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The command's name is a misnomer.
The command loads a file but does not run (boot) it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
