With commit 793e623011 ("spi: mtk_spim: get spi clk rate only once") a
new system to calculate the SPI clocks has been added.
Unfortunately, the do_div macro overrides the global priv->pll_clk_rate
field. This will cause to have a reduced clock rate on each subsequent
SPI call.
Signed-off-by: Valerio 'ftp21' Mancini <ftp21@ftp21.eu>
Signed-off-by: Nicolò Veronese <nicveronese@gmail.com>
We're seeing sporadic errors like
ENVC include/generated/env.txt
HOSTCC scripts/basic/fixdep
ENVP include/generated/env.in
ENVT include/generated/environment.h
HOSTCC tools/printinitialenv
/bin/sh: 1: scripts/basic/fixdep: not found
make[1]: *** [scripts/Makefile.host:95: tools/printinitialenv] Error 127
make[1]: *** Deleting file 'tools/printinitialenv'
make: *** [Makefile:2446: u-boot-initial-env] Error 2
make: *** Waiting for unfinished jobs....
where sometimes the "fixdep: not found" is instead "fixdep: Permission
denied" and the Error 127 becomes 126.
This smells like a race condition, and indeed it is: Currently,
u-boot-initial-env is a prerequisite of the envtools target, which
also lists scripts_basic as a prerequisite:
envtools: u-boot-initial-env scripts_basic $(version_h) $(timestamp_h) tools/version.h
$(Q)$(MAKE) $(build)=tools/env
However, the u-boot-initial-env rule involves building the
printinitialenv helper, which in turn is built using an if_changed_dep
rule. That means we must ensure scripts/basic/fixdep is built and
ready before trying to build printinitialenv, i.e. the
u-boot-initial-env rule itself must depend on the phony scripts_basic
target.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added new xenguest_arm64_virtio_defconfig which
enables support for virtio-blk using various types
of transport like virtio-pci, vrtio-mmio. Currently
supported: up to 2 PCI host bridges and 10 MMIO devices.
Note: DT parsing code was partly taken from pci-uclass.c
Limitation: All memory regions should be
below 4GB address space.
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
Current gd->ram_size and gd->ram_top reflect only the
first DRAM bank even if the SynQuacer Developerbox could
have up to three DRAM banks.
With the commit 06d514d77c ("lmb: consider EFI memory map"),
the first DRAM bank indicates <4GB address, so whole >4GB memory
is marked as EFI_BOOT_SERVICES_DATA and it results that
U-Boot can not access >4GB memory.
Since 64-bits DRAM address is fully available on the SynQuacer
Developerbox, let's set the installed DIMM information to
gd->ram_top and gd->ram_size.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Before using the result of env_get("stdin") we must check if it is NULL.
Avoid #if. This resolves the -Wunused-but-set-variable issue and we don't
need a dummy assignment in the else branch. Anyway this warning is
disabled in the Makefile.
For sake of readability use an early return after the configuration check.
Checking CONFIG_SPL_BUILD is incorrect as env_get() is only defined if
CONFIG_$(SPL_TPL)ENV_SUPPORT=y.
Fixes: 985ca3945f ("spl: input: Allow input in SPL and TPL")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Make it possible for data that was externalized using a static external
position (-p) to be internalized. Enables the ability to convert
existing FIT images built with -p to be converted to a FIT image where the
data is internal, to be converted to a FIT image where the data is
external relative to the end of the FIT (-E) or change the initial
static external position to a different static external position (-p).
Removing the original external-data-related properties ensures that
they're not present after conversion. Without this, they would still be
present in the resulting FIT even if the FIT has been, for example,
internalized.
Signed-off-by: Lars Feyaerts <lars@bitbiz.be>
Reviewed-by: Simon Glass <sjg@chromium.org>
Have checkpatch.pl skip warnings for use of fdtdec_* functions in
ooling; livetree isn't used there.
Signed-off-by: Lars Feyaerts <lars@bitbiz.be>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
At present on Sandbox when binding to a host backing file, the host
block device is created with a hard-coded 512 bytes block size.
Such assumption works for most cases, but for situation that with a raw
image file dump from a pre-formatted GPT partitioned disk image from a
4KiB block size device, when binding this file to a host device and mapping
this device to a blkmap, "blkmap" command like "blkmap part" won't work
correctly, due to block size mismatch during parsing the partition table.
This series updates Sandbox block driver, as well as the blkmap driver,
to get rid of the hard-coded 512 bytes block size assumption.
This series is available at u-boot-x86/blk for testing.
Test log (512 block size):
=> host bind 0 test.img
=> host info
dev blocks blksz label path
0 262144 512 0 test.img
=> blkmap create 0
Created "0"
=> blkmap map 0 0 40000 linear host 0 0
Block 0x0+0x40000 mapped to block 0x0 of "host 0"
=> blkmap info
Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
Type: Hard Disk
Capacity: 128.0 MB = 0.1 GB (262144 x 512)
=> blkmap part
Partition Map for BLKMAP device 0 -- Partition Type: EFI
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000022 0x000000bd "u-boot-spl"
attrs: 0x0000000000000000
type: 5b193300-fc78-40cd-8002-e86c45580b47
(5b193300-fc78-40cd-8002-e86c45580b47)
guid: 0bb6bb6e-4aac-4c27-be03-016b01e7b941
2 0x00000822 0x00000c84 "u-boot"
attrs: 0x0000000000000000
type: 2e54b353-1271-4842-806f-e436d6af6985
(2e54b353-1271-4842-806f-e436d6af6985)
guid: 91d50814-8e31-4cc0-97dc-779e1dc59056
3 0x00000c85 0x0000cc84 "rootfs"
attrs: 0x0000000000000004
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 42799722-6e55-46e6-afa9-529e7af3f03b
Test log (4096 block size):
=> host bind 0 test.img 4096
=> host info
dev blocks blksz label path
0 32768 4096 0 test.img
=> blkmap create 0
Created "0"
=> blkmap map 0 0 8000 linear host 0 0
Block 0x0+0x8000 mapped to block 0x0 of "host 0"
=> blkmap info
Device 0: Vendor: U-Boot Rev: 1.0 Prod: blkmap
Type: Hard Disk
Capacity: 128.0 MB = 0.1 GB (32768 x 4096)
=> blkmap part
Partition Map for BLKMAP device 0 -- Partition Type: EFI
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000100 0x00001fff "primary"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: eba904d7-72c1-4dbd-bb4e-36be49cba5e3
2 0x00002000 0x00007ffa "primary"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: c48c360e-db47-46da-ab87-26416fad3cd3
Print out the blkmap device type when showing partition header for
a blkmap device.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's helpful to output the device uclass id for unknown devices
during the debugging process.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
blk_{read,write}_devnum() are no longer used by anywhere in the
source tree. Drop them.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
commit 3d2fc79714 ("cmd: blk: Allow generic read/write operations to work in sandbox")
used the hard-coded block size (512) for accessing the sandbox host
device. Now that we have added support for non-512 block size for both
Sandbox host device and blkmap driver, let's stop using the hard-coded
block size.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
get_desc() can be useful outside blk-uclass.c. Let's change it to
an API and make it externally visible.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present if a device to map has a block size other than 512,
the blkmap map process just fails. There is no reason why we
can't just use the block size of the mapped device.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's useful if we can print out the block size of the host device
in the "host info" command.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since we are emulating a block device, its size should be multiple
of the configured block size.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Allow optionally set the logical block size of the host device to
bind in the "host bind" command. If not given, defaults to 512.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
At present the host bind command does not require filename to be
provided. When it is not given NULL is passed to the host device
driver, which ends up failure afterwards.
Change to mandate the filename so that it is useful.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Cleanup how we pick what to launch in SPL, a few test changes, some TI
K3 platform updates, top-level Makefile fixes and related cleanup,
correct a problem with LMB overlap, other assorted fixes.
Reset the FLSHxCR1 registers to default value. ROM may set the register
value and it affects the SPI NAND normal functions.
Signed-off-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Populate the device tree with the MC reserved memory regions.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Populate the device tree with the MC reserved memory regions.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add support for declaring in device tree the reserved memory ranges
required for MC. Since the MC firmware acts as any DMA master present
in the SoC, the reserved memory ranges need also be identity mapped
in the SMMU, so create the required 'iommu-addresses' property in
the reserved memory nodes.
For now this support is used only on LX2160A SoCs.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Some functions are not used outside this file, so make them static.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
PPA was a secure firmware developed in-house which is no longer
supported and replaced by TF-A quite some years ago. Drop support
for it.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
PPA was a secure firmware developed in-house which is no longer
supported and replaced by TF-A quite some years ago. This makes
the defconfigs that make use of PPA obsolete, so remove them.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
[Merged part 1 and part 2]
Signed-off-by: Peng Fan <peng.fan@nxp.com>
SPL doesn't have OF_LIVE enabled, so we can only run tests with a flat
tree. Don't skip them even if they don't use the devicetree.
Fixes: 6ec5178c0e ("test: Skip flat-tree tests if devicetree is not used")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
String "/soc/fman/ethernet@e8000" is 25 bytes long
and not 24 due to extra byte for null character at
the end.
Signed-off-by: Francois Berder <fberder@outlook.fr>
When copying the name of a stdio device we must ensure that it is NUL
terminated before passing it to strcmp() to avoid a buffer overrun.
Truncating the name field leads to failure to deregister a stdio device.
When copying we must ensure that the name field sizes match.
Addresses-Coverity-ID: 350462 String not null terminated
Fixes: 5294e97832 ("stdio: extend "name" to 32 symbols")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The size of the name of a udevice is not limited.
When setting the fixed sized name field of a stdio device we must ensure
that the target string is NUL terminated to avoid buffer overflows.
Fixes: 57d92753d4 ("dm: Add a uclass for serial devices")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
spl_board_prepare_for_boot() is not called before jumping/invoking atf,
optee, opensbi or linux images.
Jump to image at the end of board_init_r() to fix this.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
spl_invoke_atf function will not be returned to SPL. Thus, we need to
set __noreturn function attribute to the function.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Use uintptr_t instead of phys_addr_t where appropriate, so passing the
addresses to writel() doesn't result in compile warnings when PHYS_64BIT
is set for 32bit builds (which is actually a useful configuration, as
the K3 SoC family boots from an R5 SPL, which may pass bank information
based on gd->bd->bi_dram to fdt_fixup_memory_banks() etc., so PHYS_64BIT
is needed for fixing up the upper bank).
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Execute "time <sleep cmd>", and validate that it gives the approximately
the correct amount of command execution time.
Signed-off-by: Love Kumar <love.kumar@amd.com>
Add test case for an address range which is coalescing with one of
range and overlapping with next range
Cc: Simon Glass <sjg@google.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In case of new memory range to be added is coalesced
with any already added non last lmb region.
And there is possibility that, then region in which new memory
range added is not adjacent to next region. But have some
sections are overlapping.
So along with adjacency check with next lmb region,
check for overlap should be done.
In case overlap is found, adjust and merge these two lmb
region into one.
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
- None of the callers perform error checking and based on the non-empty
versions of this function, there's no checking to be done, so make
this a void.
- Add a default weak version of the function.
- Remove the empty versions of exynos_init now that we have a weak
version.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of reviewing a new platform, Daniel Schwierzeck noted that we
can have an empty Makefile in the board directory and don't need an
empty board.c file as well. Further with further cleanup in the
Makefile we can now omit the Makefile entirely. Remove a number of now
unnecessary board.c and Makefiles.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is entirely possible at this point to have platforms in U-Boot that
do not have board-specific C code (just Kconfig or environment) and so
make it optional to have to descend in to and then build in the board
directory.
Signed-off-by: Tom Rini <trini@konsulko.com>
Allow for a proper configuration of CFI flash banks avaialble on the vexpress_ca9x4
board. Without this option, the CFI flash incorrectly detects that the board has two
banks of 32MB flash devices, while in reality, the board provides
two flash banks, each with 64MB size. As a result, it becomes impossible to e.g. to
save u-boot env in flash. According to device tree for this board and
its implementation in QEMU, the CFI width should be set to 32 bits.
After applying this fix, CFI flash will correctly detect both flash
banks each with a size of 64MB. As as result the functionality of e.g. saving u-boot
env will work correctly.
Tested on QEMU 6.2.0.
Cc: Kristian Amlie <kristian.amlie@northern.tech>
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Reviewed-by: Kristian Amlie <kristian.amlie@northern.tech>
If the source .env file changes to one that is also older than the
generated env.txt file then the .env file is not regenerated. This
means when switching board configs we do not regenerate the env.
This can be tested with:
$ make j721e_evm_a72_defconfig
$ make # this may fail to complete but that is okay for this test
$ make am64x_evm_a53_defconfig
$ make
$ vim include/generated/env.txt
Note this is still the J721e env not the AM64 config as expected.
As ENV_FILE is set based on configuration, regenerate anytime
autoconf.h changes.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
