Age | Commit message (Collapse) | Author |
|
Add s simple test for the I3C uclass in sandbox.
Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
|
|
Create a basic test suit for AES DM uclass that covers all available
operations.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
|
|
This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.
Signed-off-by: Eric Schikschneit <eric.schikschneit@novatechautomation.com>
[trini: Change default order so that X86 && EFI_APP works correctly]
|
|
Use white on black for the expo menu as it is easier on the eyes.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add tests for video bridge ops.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Test suit for of_graph parsing helpers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
|
|
in linux we have the option to create the name of a led
optionally through the following properties:
- function
- color
- function-enumerator
This patch adds support for parsing this properties if there
is no label property.
The led name is created in led_post_bind() and we need some
storage place for it. Currently this patch prevents to use
malloc() instead it stores the name in new member :
char name[LED_MAX_NAME_SIZE];
of struct led_uc_plat. While at it append led tests for the
new feature.
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
implementation"
Christian Marangi <ansuelsmth@gmail.com> says:
This series is split in 2 part.
While adapting the LED boot and activity code to the new property
accepted by Rob in dt-schema repository, a big BUG was discovered.
The reason wasn't clear at start and took me some days to figure it
out.
This was triggered by adding a new phandle in the test.dts to
introduce test for the new OPs.
This single addition caused the sandbox CI test to fail in the
dm_test_ofnode_phandle_ot test.
This doesn't make sense as reverting the change made the CI test
to correctly finish. Also moving the uboot node down
after the first phandle (in test.dts the gpio one) also made
the CI test to correctly finish.
A little bit of searching and debugging made me realize the
parse phandle OPs didn't support other.dts at all and they
were still referencing phandle index from test.dts.
(more info in the related commit)
In short the test was broken all along and was working by
pure luck. The first 4 patch address and fix the problem for good.
The other 4 patch expand and address the property change for
LED boot/activity.
Posting in a single series as changes are trivial and just
to speedup review process. (and also because the second
part depends on the first)
All CI tested with azure pipeline.
Link: https://lore.kernel.org/r/20241110115054.2555-1-ansuelsmth@gmail.com
|
|
Update test for LED activity and boot to follow new implementation with
property set to the LED node phandle.
Also update a copy-paste error in the function name for the activity
tests and actually enable the test with the DM_TEST macro.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add test for ofnode options phandle helper and add new property in the
sandbox test dts.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Expand dm_test_ofnode_phandle(_ot) with new ofnode/tree_parse_phandle() op.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Fix broken dm_test_ofnode_phandle_ot test. They never actually worked
and were passing test by pure luck by having the same phandle index of
test.dts that coincicentally had #gpio-cells in the same index node.
It was sufficient to add a phandle to test.dts to make the test fail.
To correctly test these feature, make use oif the new OPs oftree to
parse phandle.
For consistency with the dm_test_ofnode_phandle, rework the test and
other.dts to use the same property with the other- prefix to every
node.
Also fix dm_test_ofnode_get_by_phandle_ot by making it more robust and
renaming the phandle property to other-phandle.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Rename actual android bootmethod test to specify it's for boot image
version 4.
Add a unit test for testing the Android bootmethod with boot image
version 2.
This requires another mmc image (mmc8) to contain the following
partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
we can test this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc8.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20241126-adnroidv2-v4-5-11636106dc69@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Create a new disk for use with tests, which contains the new 'testapp'
EFI app specifically intended for testing the EFI loader.
Attach it to the USB device, since most testing is currently done with
mmc.
Initially this image will be used to test the EFI bootmeth.
Fix a stale comment in prep_mmc_bootdev() while we are here.
For now this uses sudo and a compressed fallback file, like all the
other bootstd tests. Once this series is in, the patch which moves
this to use user-space tools will be cleaned up and re-submitted.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
|
|
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.
The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().
TEST: Read the interrupts from the GIC node for ACPI MADT generation.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
|
|
At present menu items are stored according to their sequence number in
the menu. In some cases we may want to have holes in that sequence, or
not use a sequence at all.
Add a new 'value' property for menu items. This will be used for
reading and writing, if present. If there is no 'value' property, then
the normal sequence number will be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This phandle was missing in the sandbox DT, add it, otherwise sandbox-i2c
driver cannot look up the emulator via i2c_emul_find(). This fixes the
following i2c_emul_find() error:
"
$ ./u-boot -Dc ""
...
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
...
"
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The dtbs: target is almost identical in all architecture Makefiles.
All architecture Makefiles include scripts/Makefile.dts . Deduplicate
the dtbs: target into scripts/Makefile.dts . No functional change.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #qcom, OF_UPSTREAM
|
|
Expand ofnode options test with new generic helper for bool, int and
string.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add tests for LED boot and activity feature and add required property in
sandbox test DTS.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Sughosh Ganu <sughosh.ganu@linaro.org> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
|
|
The TCG event log buffer is being set at the end of ram memory. This
region of memory is to be reserved as LMB_NOMAP memory in the LMB
memory map. The current location of this buffer overlaps with the
memory region reserved for the U-Boot image, which is at the top of
the usable memory. This worked earlier as the LMB memory map was not
global but caller specific, but fails now because of the overlap.
Move the TCG event log buffer to the start of the ram memory region
instead. Move the location of the early trace buffer and the load
buffer for U-Boot(spl boot) accordingly.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The sandbox pinmux driver is used in the non-test devicetree as well as
the test one. I didn't realize this when I modified the driver for
tests, and so broke the regular use case (which only resulted in
warnings). First, making the pinmux and the UART group available
pre-relocation to avoid ENODEV errors. Then, convert the pin groups and
functions to the new style, adding onewire group as well.
Fixes: 7f0f1806e3a ("test: pinmux: Add test for pin muxing")
Closes: https://source.denx.de/u-boot/u-boot/-/issues/2
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Currently, all the capsules for the sandbox platform are generated at
the time of running the capsule tests. To showcase generation of
capsules through binman, generate all raw(non FIT payload) capsules
needed for the sandbox platform as part of the build. This acts as an
illustrative example for generating capsules as part of a platform's
build.
Make corresponding change in the capsule test's configuration to get
these capsules from the build directory.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
Adjust the DT to match upstream bindings.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
With the recent changes to the Qualcomm PMIC GPIO driver the sandbox
tests for it no longer pass, update the DTS and tests to work with the
changes.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Prepare v2024.01-rc5
|
|
Assign ccf_clk_ops to .ops of clk_ccf driver so that it can act as an
clk provider. Also add "#clock-cells=<1>" to its device tree node.
Add "i2c_root" to clk_test in the device tree and driver for testing.
Get "i2c_root" clock in CCF unit tests and add tests for it.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20231111-enable_count-v3-2-08a821892fa9@outlook.com
|
|
Prepare v2024.01-rc3
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
SCMI power domain management protocol is supported on sandbox
for test purpose. Add fake agent interfaces and associated
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>
|
|
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>
|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic
- add Amlogic A1 clock driver
- add Amlogic A1 reset support
- add USB Device support for Amlogic A1
- enable RNG on Amlogic A1 & Amlogic S4
- move Amlogic Secure Monitor to standalone driver
|
|
We need this to test UCLASS_SM.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20230921081346.22157-4-avromanov@salutedevices.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
SCMI base protocol is mandatory and doesn't need to be listed in a device
tree.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
Any SCMI protocol may have its own channel.
Test this feature on sandbox as the necessary framework was added
in a prior commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
|
|
Provide test coverage for the new expo object type, including building
and reading/writing settings.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The PCI helpers read only the base address for a PCI region. In some cases
the size is needed as well, e.g. to pass along to a driver which needs to
know the size of its register area.
Update the functions to allow the size to be returned. For serial, record
the information and provided it with the serial_info() call.
A limitation still exists in that the size is not available when OF_LIVE
is enabled, so take account of that in the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
s/parititon/partition/
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
ofnode_read_bootscript_flash() reads bootscript address from
/options/u-boot DT node. bootscr-flash-offset and bootscr-flash-size
properties are read and values are filled. When bootscr-flash-size is not
defined, bootscr-flash-offset property is unusable that's why cleaned.
Both of these properties should be defined to function properly.
Also add test to cover this new function.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/08a3e6c09cce13287c69ad370e409e7f1766b406.1693465465.git.michal.simek@amd.com
|
|
ofnode_read_bootscript_address() reads bootscript address from
/options/u-boot DT node. bootscr-address or bootscr-ram-offset properties
are read and values are filled. bootscr-address has higher priority than
bootscr-ram-offset and the only one should be described in DT.
Also add test to cover this new function.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/23be3838502efef61803c90ef6e8b32bbd6ede41.1693465140.git.michal.simek@amd.com
|
|
There is a chance that assigned-clock-rates is given and assigned-clocks
could be empty. Dont return error in that case, because the probe of the
corresponding driver will not be called at all if this fails.
Better to continue to look for it and return 0.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a9a9d853e0ac396cd9b3577cce26279a75765711.1693384296.git.michal.simek@amd.com
|