Somehow I do not see any inlining with initcalls now. I was sure I saw
it when this commit went in, but now it seems to make things worse.
This reverts commit 47870afab9.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current event spy is always passed the event context and the event.
The context is always NULL for a static spy. The event is not often used.
Introduce a 'simple' spy which takes no arguments. This allows us to drop
the adaptation code that many of these spy records use.
Update the event script to find these in the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
- pcie-bcmstb improvements, nvmxip improvements, fix a corner case in
the serial uclass, send error messages to stderr in host tools, fwu
library CI state fixup, turn some setexpr diagnostic messages to debug
Neither successful match nor lack thereof should be considered an
extraordinary situation. Thus, neither require printing a message.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The sandbox_set_enable_memio() should only ever be set during
sandbox testing, not within driver itself, move it back to test/ .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Cast the address such that it can be printed without warnings
on both 32bit and 64bit systems. This really should use some
better print formatter, but for the lack of it, do it this way.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Get rid of nvmxip_mmio_rawread() and just implement the readl()/readq()
reader loop within nvmxip_blk_read(). Cast the destination buffer as
needed and increment the read by either 4 or 8 bytes depending on if
this is systemd with 32bit or 64bit physical address.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Perform all the block device creation only once, after the driver itself
successfully bound. Do not do this in uclass post bind, as this might be
triggered multiple times. For example the ut_dm_host test triggers this
and triggers a memory leak that way, since there are now multiple block
devices created using the blk_create_devicef() .
To retain the old probe-on-boot behavior, set DM_FLAG_PROBE_AFTER_BIND
flag in uclass post_bind callback, so the driver model would probe the
driver at the right time.
Rename the function as well, to match similar functions in
other block-related subsystems, like the mmc one.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The current CI test worked by sheer luck, the g_dev global pointer
in the fwu library was never initialized and the test equally well
failed on sandbox64. Trigger the main loop in sandbox tests too to
initialize that global state, and move the sandbox specific exit
from fwu_boottime_checks after g_dev is initialized.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reset gd->cur_serial_dev pointer to avoid calling non-relocated code
from relocated code if a serial driver is not found and
CONFIG_REQUIRE_SERIAL_CONSOLE is disabled.
Here is detailed explanation of what this patch is trying to fix.
U-boot calls the serial_find_console_or_panic() function twice.
The first console setup occurs before U-boot relocation in
the serial_init(). This stage uses simple FDT parsing and
assigns gd->cur_serial_dev to a "serial" device that lives in
non-relocated code too.
The second console setup after U-boot relocation(from serial_initialize())
may use full live DT (if OF_LIVE enabled) probe sequence with buses,
clocks, resets, etc... And if the console setup fails at this step,
than we should be caught by panic_str("No serial driver found").
But... If we disable CONFIG_REQUIRE_SERIAL_CONSOLE, than we
return from serial_init() with gd->cur_serial_dev pointing
to the "old"(non-relocated) serial device.
And if this area, where "old" serial device is placed, is changed
(e.g. Linux kernel may be relocated at this address), than we will get
an unexpected crash on the next call of printf().
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
The make by default cuts off the stdout output from external tools,
so all error messages from the image-host are not shown in a make
output. Besides that, it is a common approach to use stderr stream
for error messages.
Use stderr for all error messages in image-host.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
When the Broadcom STB PCIe controller is initialized, it must be set
into one of three CLKREQ# modes: "none"/"aspm"/"l1ss". The Linux driver,
through today, hard-codes "aspm" since the vast majority of boards using
this driver have a fixed PCIe bus with the CLKREQ# signal wired up.
The Raspberry Pi CM4, however, can be connected to a plethora of PCIe
devices, some of which do not connect the CLKREQ# line (they just leave
it floating). So "aspm" mode is no longer appropriate in all cases. In
Linux, there is a proposed patchset [1] to determine the proper mode.
This doesn't really make sense in U-Boot's case, so we just change the
assumption from "aspm" to "none" (which is always safe).
This patch DOES resolve a real-world crash that occurs when U-Boot is
running on a Raspberry Pi CM4 installed in slot 3 of a Turing Pi 2
cluster board.
[1]: https://lore.kernel.org/all/20230428223500.23337-1-jim2101024@gmail.com/
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Since the initial U-Boot driver was ported here from Linux, the latter
has had a few changes for robustness/stability. This patch brings over
two of them:
- Do not attempt to access the configuration space of a PCIe device if
the link has gone down, as that will result in an asynchronous SError
interrupt which will crash U-Boot.
- Wait for the recommended 100ms after PERST# is deasserted.
I sent this patch while debugging a crash involving PCIe, but these
are unrelated improvements. I do not believe that this patch fixes any
real-world bug.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmTu+QMcHGV1Z2VuLmhy
aXN0ZXZAY29sbGFib3JhLmNvbQAKCRAesx4CDqwvyFqVB/9z5lV4zhqWYiQ+wNZL
Gxs3//DSS5iVHU+xaPRrYQT99Yn2/kfM2LeQ4REBOaOTP7IX2ewmOEro4OUViFuC
kt/WnHD0XzN+2o8akIdVC5YudgVcuX751SQtp5dqcbN6FylSH010+YIZTvaJoNQn
+Wny1ZZhpuNJJEPvLxE/eiJ3jFwvEAjC+jH328uQIeSLknPh93hGJOFc/02F0O2o
s96J1/VZ4qvvQKYw0sgNtGb/0Og7V0RLW27+RfwhH4XJvAIv/A6MioTyRaCS2h7H
tzj/hFXbzGtu+AqrEtMgNjzC7vAx+0266P/Zx/DOWKoWLDIYkWSLpYKLut0E6CUe
+fcB
=L/iw
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2023.10-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2023.10 cycle:
This feature set includes a new board sama5d29 Curiosity, and various
fixes and alignments for sam9x60 and sam9x60 curiosity board.
To quote the author:
This patchset aims to bring two capsule related tasks under the U-Boot
build flow.
The first task is related to generation of capsules. The capsules can be
generated as part of U-Boot build, and this is being achieved through
binman, by adding a capsule entry type. The capsules can be generated by
specifying the capsule parameters as properties under the capsule entry
node.
The other task is the embedding of the public key into the platform's
DTB. The public key is in the form of an EFI Signature List(ESL) file
and is used for capsule authentication. This is being achieved by adding
the signature node containing the capsule public key in the platform's
DTB.
Corresponding changes have also been made to the test setup of the EFI
capsule update feature. The ESL public key file was embedded into the
sandbox platform's test.dtb as part of the test setup, post U-Boot
build. This is now no longer needed as the embedding of the ESL happens
as part of the build.
Secondly, the capsules needed for testing the EFI capsule update feature
were being generated through the invocation of the mkeficapsule tool.
This setup has also been changed to introduce generation of these
capsules through binman.
The document has been updated to reflect the above changes.
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the U-Boot build.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The public key EFI Signature List(ESL) needed for capsule
authentication is now embedded into the platform's DTB as part of the
build. Remove the superfluous logic from the test setup.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Add the path to the public key EFI Signature List(ESL) file for the
sandbox variants which enable capsule authentication. This ESL file
gets embedded into the platform's device-tree as part of the build.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a target for generating a dtsi file which contains the signature
node with the ESL file included as a property under the signature
node. Include the dtsi file in the dtb. This brings the embedding of
the ESL in the dtb into the U-Boot build flow.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
At the time of building the DTB, some dtsi files can be selected for
inclusion. Have these dtsi files as dependencies for the DTB
target. This also ensures generation or updating the dtsi files if
need be.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At the time of building a device-tree file, all the *u-boot.dtsi files
are looked for, in a particular order, and the first file found is
included. Then, the list of files specified in the
CONFIG_DEVICE_TREE_INCLUDES symbol are included.
Combine these files that are to be included into a variable, and then
include all these files in one go.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When running the trace test on the sandbox platform, the current size
of 16MiB is no longer large enough for capturing the entire trace
history, and results in truncation. Use a size of 32MiB for the trace
buffer on the sandbox platform while running the trace test.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The EFI capsules can now be generated as part of U-Boot build, through
binman. Highlight these changes in the documentation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Support has been added for generating the EFI capsules through
binman. Make changes in the EFI capsule update testing feature to
generate capsules through binman.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Add support in binman for generating EFI capsules. The capsule
parameters can be specified through the capsule binman entry. Also add
test cases in binman for testing capsule generation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a bintool for generating EFI capsules. This calls the mkeficapsule
tool which generates the capsules.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable the EFI capsule update code on all sandbox variants. This was
already enabled on the sandbox, sandbox64 and sandbox_flattree
variants. The rest of the variants also have the EFI capsule update
module enabled now. With this commit, the mkeficapsule tool also gets
enabled on all variants.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the private keys and public key certificates which are to be used
for capsule authentication while testing the EFI capsule update
functionality. There are two pairs of private and public keys, good
and bad. The good key pair will be used for signing capsules, whilst
the bad key pair is to be used as malicious keys for testing
authentication failure cases. The capsule_pub_key_good.crt is also
converted to an EFI Signature List(ESL) file, SIGNER.esl, which is
embedded in the platform's device-tree for capsule authentication.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a newline at the end of the dts, without which the build fails
when including a dtsi file.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Copied as is from Linux Kernel release v6.4.
(dts file is still the same in Linux v6.5-rc7 but was moved to vendor
sub-directories with v6.5-rc1.)
Button works out of the box now if the following config options are
enabled: CONFIG_BUTTON, CONFIG_BUTTON_GPIO, CONFIG_CMD_BUTTON,
CONFIG_DM_GPIO.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
If CONFIG_LED and CONFIG_LED_GPIO are enabled, it is not necessary to
initialize the RGB LED on the board by manually setting hardcoded GPIOs
anymore. Everything is well defined in dts and can be used like on
boards of other vendors.
Keep the old behaviour as fallback, though.
With all this in place enabling CONFIG_CMD_LED gives us a working 'led'
command on the U-Boot shell.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Copied as is from Linux Kernel release v6.4.
(dts file is still the same in Linux v6.5-rc7 but was moved to vendor
sub-directories with v6.5-rc1.)
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Since commit 61040097a9 ("reset: at91: Add reset driver for basic
assert/deassert operations") the compatible "microchip,sam9x60-rstc" for
the sam9x60 reset controller in sam9x60.dtsi is not handled by
CONFIG_SYSRESET_AT91 anymore, but by CONFIG_RESET_AT91 now. This
resulted in the following error message, when trying to reset from
U-Boot shell:
U-Boot> reset
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
Fixed by enabling the new driver in the relevant defconfigs. Tested on
sam9x60-curiosity board. Defconfigs for sam9x60ek adapted in the same
way, but without testing. These should be all sam9x60 boards affected
in U-Boot here.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
The board has two SD card slots and we have two defconfigs for booting
from either the first (micro SD) named 'sam9x60_curiosity_mmc_defconfig'
or the second (full size SD) named 'sam9x60_curiosity_mmc1_defconfig'.
For comparable Microchip boards (sama5d27-som1-ek, sama5d29-curiosity,
sama7g5ek) with two card slots the defconfigs only differ in BOOTARGS,
BOOTCOMMAND, and ENV_FAT_DEVICE_AND_PART and the same should be the case
for sam9x60_curiosity.
Here the 'mmc1' config has more options enabled to support the raw NAND
flash populated on the board, so the 'mmc' config (for mmc0) was adapted
by enabling additional options, instead of removing options from mmc1.
The 'mem=128M' argument can be dropped from kernel command line, because
it is redundant to memory node in dts in both Linux and U-Boot:
memory@20000000 {
reg = <0x20000000 0x8000000>;
};
Signed-off-by: Alexander Dahl <ada@thorsis.com>
First, update CI to using gcc-13.2 from 13.1, and rebuild the CI
containers. This is needed because the second part adds utilities for
tests and provides, to quote the author:
This updates the ChromiumOS bootmeth to detect multiple kernel
partitions on a disk.
It also includes minor code improvements to the partition drivers,
including accessors for the optional fields.
This series also includes some other related tweaks in testing.
The latest kernel.org toolchains for gcc are now 13.2.0, so upgrade to
that.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The existing ChromiumOS bootmeth only supports reading a single kernel
partition, either 2 or 4. In fact there are normally two options
available.
Use the GUID to detect kernel partitions, with the BOOTMETHF_ANY_PART
flag, so that bootstd does not require a valid filesystem before calling
the bootmeth.
Tidy up and improve the logging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
[trini: Add missing select of PARTITION_TYPE_GUID]
Signed-off-by: Tom Rini <trini@konsulko.com>
Some bootmeths support scanning a partition without a filesystem on it.
Add a flag to support this.
This will allow the ChromiumOS bootmeth to find kernel partition, which
are stored in a special format, without a filesystem.
Signed-off-by: Simon Glass <sjg@chromium.org>
The ChromiumOS bootmeth has no tests at present. Before adding more
features. add a basic test.
This creates a disk which can be scanned by the bootmeth, so make sure
things work. It is quite rudimentary, since the kernel is faked, the root
disk is missing and there is no cmdline stored.
Enable the bootmeth for snow so it can build the unit test.
Signed-off-by: Simon Glass <sjg@chromium.org>
We currently use mmc4 for tests. Update the function which sets this up
so that it can handle any device.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present 'bootflow list' shows <NULL> for the filename when it is not
present. Show an empty string instead, since that is more user-friendly.
Signed-off-by: Simon Glass <sjg@chromium.org>
These are currently created in the source directory, which is not ideal.
Move them to the persistent-data directory instead. Update the test so
skip validating the filename, since it now includes a full path.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some pytests create files in the persistent-data directory. It is useful
to be able to access these files in C tests. Add a function which can
locate a file given its leaf name, using the environment variable set
up in test/py/conftest.py
Signed-off-by: Simon Glass <sjg@chromium.org>
These should be in the header file for easy browsing, not in the source
code. Move them and add a missing Return on one of the functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
