This converts the spi load method to use spl_load. The address used for
LOAD_FIT_FULL may be different, but there are no in-tree users of that
config. Since payload_offs is only used without OS_BOOT, we defer its
initialization.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the blk load method (used exclusively by NVMe) to use
spl_load. As a consequence, it also adds support for LOAD_FIT_FULL and
IMX images.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the nor load method to use spl_load. As a result it also
adds support for LOAD_FIT_FULL. Since this is the last caller of
spl_load_legacy_img, it has been removed.
We can't load FITs with external data with SPL_LOAD_FIT_FULL, so disable the
test in that case. No boards enable SPL_NOR_SUPPORT and SPL_LOAD_FIT_FULL, so
this is not a regression.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the net load method to use spl_load. As a result, it also
adds support for LOAD_FIT_FULL and IMX images.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the nand load method to use spl_load. nand_page_size may not
be valid until after nand_spl_load_image is called (see e.g. fsl_ifc_spl),
so we set bl_len in spl_nand_read. Since spl_load reads the header for us,
we can remove that argument from spl_nand_load_element.
There are two possible regressions which could result from this commit.
First, we ask for a negative address from spl_get_load_buffer. That is,
instead of
header = spl_get_load_buffer(0, sizeof(*header));
we do
header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
this could cause a problem if spl_get_load_buffer does not return valid
memory for negative offsets. Second, we now set bl_len for legacy images.
This can cause memory up to a bl_len - 1 before the image load address to
be written, which might not have been the case before. If this turns out to
be a problem, we can add an option for a bounce buffer.
We can't load FITs with external data with SPL_LOAD_FIT_FULL, so disable the
test in that case. No boards enable SPL_NAND_SUPPORT and SPL_LOAD_FIT_FULL, so
this is not a regression.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the mmc loader to spl_load. Legacy images are handled by
spl_load (via spl_parse_image_header), so mmc_load_legacy can be
omitted. To accurately determine whether mmc_load_image_raw_sector is used
(which might not be the case if SYS_MMCSD_FS_BOOT is enabled), we introduce
a helper config SYS_MMCSD_RAW_MODE. This ensures we can inline spl_load
correctly when a board only boots from filesystems. We still need to check
for SPL_MMC, since some boards enable configure raw mode even without MMC
support.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the fat loader to use spl_load. Some platforms are very
tight on space, so we take care to only include the code we really need.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the ext load method to use spl_load. As a consequence, it
also adds support for FIT and IMX images.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These will soon be supported, so we need to be able to test it. Export the
lzma data and generally use the same process in spl_test_mmc_fs as
do_spl_test_load. If we end up needing this in third place in the future,
it would probably be good to refactor things out.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Aligning addresses and sizes causes overhead which is unnecessary when we
are not loading from block devices. Remove bl_len when it is not needed.
For example, on iot2050 we save 144 bytes with this patch (once the rest of
this series is applied):
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-144 (-144)
Function old new delta
spl_load_simple_fit 920 904 -16
load_simple_fit 496 444 -52
spl_spi_load_image 384 308 -76
Total: Before=87431, After=87287, chg -0.16%
We use panic() instead of BUILD_BUG_ON in spl_set_bl_len because we still
need to be able to compile it for things like mmc_load_image_raw_sector,
even if that function will not be used.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For filesystems, filename serves the same purpose as priv. However,
spl_load_fit_image also uses it to determine whether to use a DMA-aligned
buffer. This is beneficial for FAT, which uses a bounce-buffer if the
destination is not DMA-aligned. However, this is unnecessary now that
filesystems set bl_len to ARCH_DMA_MINALIGN instead. With this done, we can
remove filename entirely.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simplify things a bit for callers of spl_load_info->read by refactoring it
to use units of bytes instead of bl_len. This generally simplifies the
logic, as MMC is the only loader which actually works in sectors. It will
also allow further refactoring to remove the special-case handling of
filename. spl_load_legacy_img already works in units of bytes (oops) so it
doesn't need to be changed.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
This series tests raw nand flash in sandbox and fixes various bugs discovered in
the process. I've tried to do things in a contemporary manner, avoiding the
(numerous) variations present on only a few boards. The test is pretty minimal.
Future work could test the rest of the nand API as well as the MTD API.
Bloat (for v1) at [1] (for boards with SPL_NAND_SUPPORT enabled). Almost
everything grows by a few bytes due to nand_page_size. A few boards grow more,
mostly those using nand_spl_loaders.c. CI at [2].
[1] https://gist.github.com/Forty-Bot/9694f3401893c9e706ccc374922de6c2
[2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/18443
Add a SPL test for the NAND load method. We use some different functions to
do the writing from the main test since things like nand_write_skip_bad
aren't available in SPL.
We disable BBT scanning, since scan_bbt is only populated when not in SPL.
We use nand_spl_loaders.c as it seems to be common to at least a few boards
already. However, we do not use nand_spl_simple.c because it would require
us to implement cmd_ctrl. The various nand load functions are adapted from
omap_gpmc. However, they have been modified for simplicity/correctness.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add a sandbox NAND flash driver to facilitate testing. This driver supports
any number of devices, each using a single chip-select. The OOB data is
stored in-band, with the separation enforced through the API.
For now, create two devices to test with. The first is a very small device
with basic ECC. The second is an 8G device (chosen to be larger than 32
bits). It uses ONFI, with the values copied from the datasheet. It also
doesn't need too strong ECC, which speeds things up.
Although the nand subsystem determines the parameters of a chip based on
the ID, the driver itself requires devicetree properties for each
parameter. We do not derive parameters from the ID because parsing the ID
is non-trivial. We do not just use the parameters that the nand subsystem
has calculated since that is something we should be testing. An exception
is made for the ECC layout, since that is difficult to encode in the device
tree and is not a property of the device itself.
Despite using file I/O to access the backing data, we do not support using
external files. In my experience, these are unnecessary for testing since
tests can generally be written to write their expected data beforehand.
Additionally, we would need to store the "programmed" information somewhere
(complicating the format and the programming process) or try to detect
whether block are erased at runtime (degrading probe speeds).
Information about whether each page has been programmed is stored in an
in-memory buffer. To simplify the implementation, we only support a single
program per erase. While this is accurate for many larger flashes, some
smaller flashes (512 byte) support multiple programs and/or subpage
programs. Support for this could be added later as I believe some
filesystems expect this.
To test ECC, we support error-injection. Surprisingly, only ECC bytes in
the OOB area are protected, even though all bytes are equally susceptible
to error. Because of this, we take care to only corrupt ECC bytes.
Similarly, because ECC covers "steps" and not the whole page, we must take
care to corrupt data in the same way.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Return an error when the user does not select an OS, so we know whether
to boot or not.
Move calling of bootflow_menu_run() into a separate function so we can
call it from other places.
Expand the test to cover these cases.
Add some documentation also, while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust scan_mmc4_bootdev() and related function so that the caller can
do its own 'bootflow scan' command. This allows it to change the flags
if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The primary motivation for having a sandbox without LTO build in CI is
to ensure that we don't have that option break. We now have the ability
to run tests of specific options being enabled/disabled, so drop the
parts of CI that build and test that configuration specifically and add
a build test instead. We still test that "NO_LTO=1" rather than editing
the config file works via the ftrace tests.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that everything is working, add a test to make sure that this
builds correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Many tests make some use of the command line, so require it for all test
code.
This could be teased apart, perhaps with a test flag indicating that it
uses the command line. Leave that for later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Also add test to cover this new function.
Signed-off-by: Algapally Santosh Sagar <santoshsagar.algapally@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230921112043.3144726-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Two bugs have appeared:
- arguments can have an equals sign embedded in them, which must be
considered part of the value
- arguments must fully match the name; partial matches should be
ignored
Fix these and add a test to cover both.
Signed-off-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmU7j50ACgkQgS8AYozs
+qIh8w/+O4UjT0sG1NLwmyV7U1Ypk+EyYaE6wmSWzpsJLfH/YvtObBJOYRuXxRVh
J9lkgCsw8Ct1ZNCrp8iVO+Dz1DtV8+QvTecrUHZqcOhTYDaqxXnlvEH2/EUhgo5T
9a/ZaDtOP1mKz754C4G6G363+iRCvbcqDECeKg9VYxfWCo1cINOmqyQCqlGxFT+h
PKiB5VzUpN/K/yiie+Hr42/+6XaykAUjUvEWeyKOsRmYY4lNiK22vG/puE42bFTh
catXwTE2a7x+yzPKkdhR0UGvDUlIKET2kF6mi+pYN2h/cSUxWTzbP/OxcU9yJOnm
qJiRZ+Woez1I7ul6ln4ci2kiWc3CTYFXfctwrBJPuJ/EO+2EEb3oHqG2S3Fc9VBZ
N17flHW7XZHEQbNexlUhk9cRpCwRuSA5OJXwW+IZIuydgNeo3xF0iYvipbjkEGgW
BBkt8PH+ivTLjEz6Gcmquvo1fHGJLHRIPg7DNb0phGHviuC0zlDJ7N5DZk0CpkiT
36siV9xK4X6qvWkOTa6Ldw60e4tN9nv3VG30uXtPHi3XdOkKfNkyIuqO/5BkkQPt
6yEc9IYXYoWNKDVUGme5+xszZp1sSvqltajG9VVNupt958dFyOSgS5aNa6B4UsWX
3XfndP1/s2bezUHoQx5zjraapKVrqBFLkGeTlCDUD+mEgP440G8=
=gvDs
-----END PGP SIGNATURE-----
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
commit 789ed2784256 ("test/py: replace 'tpm2 init, startup, selftest' sequences")
changed some of the tpm2 init sequences to 'tpm2 autostart' instead of
calling 'tpm init', 'tpm startup TPM2_SU_CLEAR', 'tpm2 self_test full'.
The autostart command calls the afforementioned sequence and on top of
that deals with the 'tpm2 init' return codes if the tpm is already
started. Since we initialize the tpm from various subsystems now,
replace the last remaining instances of 'tpm2 init' with 'tpm2
autostart'. Since the latter calls 'tpm2 init' anyway we will still be
implicitly testing the validity of that command
It's worth noting that since 'tpm2 autostart' performs the startup and
self tests sequences of the tpm we could drop
'test_tpm2_sandbox_self_test_full' and 'test_tpm2_startup, but let's
keep the since they test tpm commands and options
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We currently use PCR 0 for testing the PCR read/extend functionality in
our selftests. How ever those PCRs are defined by the TCG spec for
platform use. For example if the tests run *after* the efi subsystem
initialization, which extends PCRs 0 & 7 it will give a false positive.
So let's switch over to a PCR which is more suitable and is defined for
OS use. It's worth noting that we are using PCR10 here, since PCR9 is
used internally by U-Boot if we choose to measure the loaded DTB
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Use the sandbox TPM driver to measure some boot images in a unit
test case.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This ut has tests for the SCMI power domain protocol as well as DM
interfaces for power domain devices.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Current code allows up to 3 MBR partitions without extended one.
If more than 3 partitions are required, then extended partition(s)
must be used.
This commit allows up to 4 primary MBR partitions without the
need for extended partition.
Add mbr test unit. In order to run the test manually, mmc6.img file
of size 12 MiB or greater is required in the same directory as u-boot.
Test also runs automatically via ./test/py/test.py tool.
Running mbr test is only supported in sandbox mode.
Signed-off-by: Alex Gendin <agendin@matrox.com>
[ And due to some further changes for testing ]
Signed-off-by: Simon Glass <sjg@chromium.org>
Unexpected 'Esc' key presses are accumulated internally, even if it is
already clear that the current escape sequence is invalid. This results
in weird behaviour. For example, the next character after 'Esc' key
simply disappears from input and 'Unknown command' is printed
after 'Enter'.
This commit fixes some issues with extra 'Esc' keys entered by user:
1. Sequence <Esc><Esc><Enter> right after autoboot stop gives:
=>
nknown command 'ry 'help'
=>
2. Sequence <Esc><p><r><i><Enter> gives:
=> ri
Unknown command 'ri' - try 'help'
=>
3. Extra 'Esc' key presses break backspace functionality.
Signed-off-by: Yurii Monakov <monakov.y@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Add Board: rk3588 NanoPC-T6, Orange Pi 5, Orange Pi 5 Plus;
- clk driver fix for rk3568 and rk3588;
- rkmtd cmd support for rockchip nand device;
- dts update and sync from linux;
Add Rockchip rkmtd test:
Create/attach/detach RKMTD device.
Send/read data with Rockchip boot block header.
Test that reusing the same label should work.
Basic test of 'rkmtd' commands.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Date Huang <tjjh89017@hotmail.com>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Reported-by: Ivan Ivanov <ivan.ivanov@suse.com>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
The current logic for "bootflow mmc" is flawed since it checks the
uclass of the bootdev instead of its parent, the media device. Correct
this and add a test that covers this scenario.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
Scan the USB bus as well, so we can check that different uclasses work
correctly in boot_targets
update the function comment with more detail.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
This commit was intended to allow all bootdevs in each boot_targets
entry to be scanned. However it causes bad ordering with bootdevs, e.g.
scanning Ethernet bootdevs when it should be keeping to mmc.
Revert it so we can try another approach.
This reverts commit e824d0d0c219bc6da767f13f90c5b00eefe929f0.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
For some time now running sandbox with -T produces an error:
Core: 270 devices, 95 uclasses, devicetree: board
WDT: Not starting wdt-gpio-toggle
wdt_gpio wdt-gpio-level: Request for wdt gpio failed: -16
WDT: Not starting wdt@0
MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
Use an unallocated GPIO to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 1fc45d6483d ("watchdog: add pulse support to gpio watchdog driver")
Reviewed-by: Stefan Roese <sr@denx.de>
Add test for the SPI load method. This one is pretty straightforward. We
can't enable FIT_EXTERNAL with LOAD_FIT_FULL because spl_spi_load_image
doesn't know the total image size and has to guess from fdt_totalsize. This
doesn't include external data, so loading it will fail.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for the NOR load method. Since NOR is memory-mapped we can
substitute a buffer instead. The only major complication is testing LZMA
decompression. It's too complex to implement LZMA compression in a test, and we
have no in-tree compressor, so we just include some pre-compressed data. This
data was generated through something like
generate_data(plain, plain_size, "lzma")
cat plain.dat | lzma | hexdump -C
and was cleaned up further in my editor.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for loading U-Boot over TFTP. As with other sandbox net
routines, we need to initialize our packets manually since things like
net_set_ether and net_set_udp_header always use "our" addresses. We use
BOOTP instead of DHCP, since DHCP has a tag/length-based format which is
harder to parse. Our TFTP implementation doesn't define as many constants
as I'd like, so I create some here. Note that the TFTP block size is
one-based, but offsets are zero-based.
In order to avoid address errors, we need to set up/define some additional
address information settings. dram_init_banksize would be a good candidate
for settig up bi_dram, but it gets called too late in board_init_r.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for the MMC load method. This shows the general shape of tests
to come: The main test function calls do_spl_test_load with an appropriate
callback to write the image to the medium.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for spl_blk_load_image, currently used only by NVMe. Because
there is no sandbox NVMe driver, just use MMC instead. Avoid falling back
to raw images to make failures more obvious.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add some functions for creating fat/ext2 filesystems with a single file and
a test for them. Filesystems require block devices, and it is easiest to
just use MMC for this. To get an MMC, we must also pull in the test device
tree. SPL_TIMER is necessary for SPL_MMC, perhaps because it uses a timeout.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This add some basic functions to create images, and a test for said
functions. This is not intended to be a test of the image parsing
functions, but rather a framework for creating minimal images for testing
load methods. That said, it does do an OK job at finding bugs in the image
parsing directly.
Since we have two methods for loading/parsing FIT images, add LOAD_FIT_FULL
as a separate CI run.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Returning a negative value from a unit test doesn't automatically fail the
test. We have to fail an assertion. Modify the test to do so.
This now causes the test to count as a failure on VPL. This is because the
fname of SPL (and U-Boot) is generated with make_exec in os_jump_to_image.
The original name of SPL is gone, and we can't determine the name of U-Boot
from the generated name.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to make adding new spl unit tests easier, especially when they may
have many dependencies, add some Kconfigs for the existing image test.
Split it into the parts which are generic (such as callbacks) and the
test-specific parts.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sandbox unit tests in U-Boot proper load a test device tree to have some
devices to work with. In order to do the same in SPL, we must enable
SPL_OF_REAL. However, we already have SPL_OF_PLATDATA enabled. When
generating platdata from a devicetree, it is expected that we will not need
devicetree access functions (even though SPL_OF_CONTROL is enabled). This
expectation does not hold for sandbox, so allow user control of
SPL_OF_REAL.
There are several places in the tree where conditions involving OF_PLATDATA
or OF_REAL no longer function correctly when both of these options can be
selected at the same time. Adjust these conditions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Generally we just drop the #ifdef CONFIG_SYS_LONGHELP and endif lines
and use U_BOOT_LONGHELP to declare the same variable name as before
- In a few places, either rename the variable to follow convention or
introduce the variable as it was being done inline before.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
