The additional comma messes up the arguments.
Warning appears if built with FPGA_DEBUG defined:
CC drivers/fpga/spartan3.o
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c: In function ‘spartan3_sp_load’:
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c:118:11: warning: too many arguments for format [-Wformat-extra-args]
PRINTF ("%s: Function Table:\n"
^~~~~~~~~~~~~~~~~~~~~~~
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c:18:37: note: in definition of macro ‘PRINTF’
#define PRINTF(fmt,args...) printf (fmt ,##args)
^~~
Fixes: 875c78934e ("Add Xilinx Spartan3 family FPGA support Patch by Kurt Stremerch, 14 February 2005")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20221007122003.11239-4-ada@thorsis.com
That extra comma messes up format arguments.
Warning appears if built with FPGA_DEBUG defined:
CC drivers/fpga/spartan2.o
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan2.c: In function ‘spartan2_sp_load’:
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan2.c:112:11: warning: too many arguments for format [-Wformat-extra-args]
PRINTF ("%s: Function Table:\n"
^~~~~~~~~~~~~~~~~~~~~~~
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan2.c:12:37: note: in definition of macro ‘PRINTF’
#define PRINTF(fmt,args...) printf (fmt ,##args)
^~~
CC drivers/fpga/spartan3.o
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c: In function ‘spartan3_sp_load’:
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c:117:11: warning: too many arguments for format [-Wformat-extra-args]
PRINTF ("%s: Function Table:\n"
^~~~~~~~~~~~~~~~~~~~~~~
/mnt/data/adahl/src/u-boot/drivers/fpga/spartan3.c:17:37: note: in definition of macro ‘PRINTF’
#define PRINTF(fmt,args...) printf (fmt ,##args)
^~~
Fixes: e221174377 ("Initial revision")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20221007122003.11239-3-ada@thorsis.com
Fix the following sparse and compile time warning
triggered with W=1:
drivers/clk/clk_versal.c:605:5:
warning: no previous prototype for 'versal_clock_setup'
[-Wmissing-prototypes]
605 | int versal_clock_setup(void)
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221007105535.31902-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Before this patch you could see in the log:
U-Boot SPL 2022.10-rc5 (Sep 29 2022 - 15:29:27 +0200)
PMUFW: v1.1
Loading new PMUFW cfg obj (32 bytes)
PMUFW: No permission to change config object
Loading new PMUFW cfg obj (2032 bytes)
where it is visible that permission is check before sending PMUFW
configuration (big size).
When this patch is applied it is visible that order is correct.
U-Boot SPL 2022.10-rc5 (Sep 29 2022 - 15:47:08 +0200)
Loading new PMUFW cfg obj (2032 bytes)
PMUFW: v1.1
Loading new PMUFW cfg obj (32 bytes)
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a0bf4f46d670023da4f848790eece6fff22090c2.1664962765.git.michal.simek@amd.com
Compiling with GCC-12 leads to an error:
+board/xilinx/common/board.c:479:37: error: the comparison will always
evaluate as 'true' for the address of 'mac_addr' will never be NULL
[-Werror=address]
+ 479 | if (!desc->mac_addr[i])
+ | ^
Remove the redundant check.
Fixes: a03b594738 ("xilinx: board: Add support for additional card detection")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Link: https://lore.kernel.org/r/20221008091317.52838-1-heinrich.schuchardt@canonical.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
In function ‘set_dfu_alt_info’ a comparison of a u8 value against
0 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`multi_boot()`.
Fix the following warning triggered with W=1:
board/xilinx/zynqmp/zynqmp.c:651:23:
warning: comparison is always false due to limited range of data type
[-Wtype-limits]
651 | if (multiboot < 0)
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004055254.26246-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Fix the following sparse and compile time warning triggered with W=1:
drivers/soc/soc_xilinx_zynqmp.c:288:5:
warning: no previous prototype for 'soc_xilinx_zynqmp_get_machine'
[-Wmissing-prototypes]
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004055201.26146-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
cpu-info.c defines print_cpuinfo(), but neglected to
include its declaration, causing the following sparse and
compile time warnings:
board/xilinx/common/cpu-info.c:10:5:
warning: no previous prototype for 'print_cpuinfo'
[-Wmissing-prototypes]
Include init.h, which includes the missing declaration.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004055053.26047-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Fix the following sparse and compile time warning triggered with W=1:
drivers/spi/zynqmp_gqspi.c:286:6:
warning: no previous prototype for 'zynqmp_qspi_set_tapdelay'
[-Wmissing-prototypes]
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004053730.25602-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
make W=1 generates the following warning in cpu_disable, cpu_status and
cpu_release functions.
arch/arm/mach-zynqmp/mp.c:166:16: warning: comparison of unsigned expression
in '>= 0' is always true [-Wtype-limits]
166 | if (nr >= ZYNQMP_CORE_APU0 && nr <= ZYNQMP_CORE_APU3) {
| ^~
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004053454.25470-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Firmware calls need node_id which is basically "power-domains" id.
At present static values are used based on the "device_id" property of
dt.
Instead of this, read "power-domains" id from dt and use it. Add a
element called node_id in priv structure and read it from dt. Replace
static node_id with this priv->node_id across the driver.
Since "device_id" is not used anywhere else simply remove it.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Link: https://lore.kernel.org/r/20220930092548.18453-3-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
In Versal platform power domain node_id is bigger than u8, hence
change prototype to u32 to accommodate. Change u8 to u32 in the function
prototypes that use node_id and remove casting to u32 from
xilinx_pm_request() call parameters.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Link: https://lore.kernel.org/r/20220930092548.18453-2-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Here are the smatch warning messages:
drivers/net/xilinx_axi_emac.c:324 axiemac_phy_init()
error: 'phydev' dereferencing possible ERR_PTR()
drivers/net/zynq_gem.c:340 zynq_phy_init()
error: 'priv->phydev' dereferencing possible ERR_PTR()
Fix by adding error checking before dereferencing the pointer.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20220929045605.23964-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The maximum length is capped similarly to the emaclite_send function.
Avoid integer underflow for values of ip->ip_len < 30, the minimum
length of an IP packet is 21 bytes.
Signed-off-by: Samuel Obuch <samuel.obuch@codasip.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Link: https://lore.kernel.org/r/20220927112103.155689-3-samuel.obuch@codasip.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Use __raw_read* and __raw_write* functions to ensure read/write
is passed to the memory-mapped regions, as non-volatile accesses
may get optimised out.
Signed-off-by: Samuel Obuch <samuel.obuch@codasip.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Link: https://lore.kernel.org/r/20220927112103.155689-2-samuel.obuch@codasip.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Function ioremap_nocache seems to be defined only for MIPS and Microblaze
architectures. Therefore, the function call in the emaclite driver causes
this driver to be unusable with other architectures, for example RISC-V.
Use ioremap function instead of ioremap_nocache, and include linux/io.h
instead of asm/io.h, so that ioremap function is automatically created,
if not defined by the architecture. We can switch to the ioremap function,
as Microblaze's ioremap_nocache is just empty and in MIPS implementations
of ioremap_nocache and ioremap are the same.
Signed-off-by: Samuel Obuch <samuel.obuch@codasip.com>
Link: https://lore.kernel.org/r/20220927112103.155689-1-samuel.obuch@codasip.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
To check dynamic loading of config object, currently APU_0 is used.
Suggestion from pmwfw team is to load OCM_BANK_0 and check for
XST_PM_NO_ACCESS error only to skip future config objects. Other errors
should not be considered for skipping. Change from NODE_APU_0 to
NODE_OCM_BANK_0 and check for XST_PM_NO_ACCESS to skip future config
objects.
Add ": " to printf statement when there is no permission to load config
object, to align with PMUFW version print.
Update kernel doc for return value for zynqmp_pmufw_load_config_object().
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/2784018844ba4afced0e3edff76bdbfe532f517d.1664523444.git.michal.simek@amd.com
For future DM based FPGA drivers and for now to have a meaningful
logging class for old FPGA drivers.
Suggested-by: Michal Simek <michal.simek@amd.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Dahl <post@lespocky.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20220930120430.42307-2-post@lespocky.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
When the imx8mn.dtsi file was pulled in from Linux, the UARTs
were moved into an spba sub-node which wasn't being included
in the SPL device tree. This meant the references to the UART
weren't being handled properly and when booting the system would
constantly reboot. Fix this by adding the spba node to the spl
device tree to restore normal booting.
Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot
board.
Fixes: 4e5114daf9 ("imx8mn: synchronise device tree with linux")
Signed-off-by: Fabio Estevam <festevam@denx.de>
When the imx8mn.dtsi file was pulled in from Linux, the UARTs
were moved into an spba sub-node which wasn't being included
in the SPL device tree. This meant the references to the UART
weren't being handled properly and when booting the system would
constantly reboot. Fix this by adding the spba node to the spl
device tree to restore normal booting.
Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot
board.
Fixes: 4e5114daf9 ("imx8mn: synchronise device tree with linux")
Signed-off-by: Fabio Estevam <festevam@denx.de>
To quote the author:
At present the ofnode interface is somewhat limited, in that it cannot
access the device tree provided by the OS, only the one used by U-Boot
itself (assuming these are separate). This prevents using ofnode functions
to handle device tree fixups, i.e. ft_board_setup() and the like.
The ofnode interface was introduced to allow a consistent API to access
the device tree, whether a flat tree or a live tree (OF_LIVE) is in use.
With the flat tree, adding nodes and properties at the start of the tree
(as often happens when writing to the /chosen node) requires copying a
lot of data for each operation. With live tree, such operations are
quite a bit faster, since there is no memory copying required. This has to
be weighed against the required memory allocation with OF_LIVE, as well
as the cost of unflattening and flattening the device tree which U-Boot
is running.
This series enables support for access to multiple device trees with the
ofnode interface. This is already available to some extent with OF_LIVE,
but some of the ofnode functions need changes to allow the tree to be
specified.
The mechanism works by using the top 1-4 bits of the device tree offset.
The sign bit is not affected, since negative values must be supported.
With this implemented, it becomes possible to use the ofnode interface
to do device tree fixups. The only current user is the EVT_FT_FIXUP
event.
This has two main benefits:
- ofnode can now be used everywhere, in preference to the libfdt calls
- live tree can eventually be used everywhere, with potential speed
improvements when larger number of fixups are used
This series is only a step along the way. Firstly, while it is possible
to access the 'fix-up' tree using OF_LIVE, most of the fixup functions use
flat tree directly, rather than the ofnode interface. These need to be
updated. Also the tree must be flattened again before it is passed to the
OS. This is not currently implemented.
With OFNODE_MULTI_TREE disabled this has almost no effect on code size:
around 4 bytes if EVENT is enabled, 0 if not. With the feature enabled,
the increase is around 700 bytes, e.g. on venice2:
$ buildman -b ofn2a venice2 -sS --step 0
Summary of 2 commits for 1 boards (1 thread, 64 jobs per thread)
01: image: Drop some other #ifdefs in image-board.c
arm: w+ venice2
48: wip
arm: (for 1/1 boards) all +668.0 text +668.0
This size increase is not too bad, considering the extra functionality,
but is too large to enable everywhere. So for now this features needs to
be opt-in only, based on EVENT.
Documentation:
* doc: improve description of autostart
UEFI:
* prefix test functions with efi_st_ in the LoadImage unit test
* avoid a warning message in efi_initrd_deregister()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmM2ofgACgkQxIHbvCwF
GsQaTw//RqZXBeSxG8Iac231Vd9kSSyDHF+RqhGfgGDnf9n3P2Gi9D9Bs3SwKWx/
aoBTy/O1TQzkG6CoNIIzcQiCR+aqIhDLrO5YfLIbmqWgG4zjpl1+w76NFZiThuJC
RA+IUutwBKChXGpLARn3Wnz58e6upRmbwJC8NbHA+qvvKaMSsBIht5NXoBO1yTrV
qeZEi/WvH6THuh7EjXHObrLcocrg2iQ1b9ydr+o/Y3tR4wZp/vZTeE76UrXv3IJk
37GjcmLj+DW5078IG7p2ThoX0/D81JS/cnLCjoCooGBN4ZUBf3XJxP60hYZG2h6E
hf2B8ExPMhM1pAhFNWbHhZii3FXzqUtyDFf7ICMn39B8mVN/20X6/Tto8UOst/Q7
BBie39eVAkGCbJxQf0MGDjeql3TpfEHxKEZfnAjJAOql05hewvDPxz6VVgtnlIXw
WWFZ2WOlc/RX8AZhwIChDXRXlIGyX3lV8xnbSZxR3XNDbxwTGMTbbXb26PIbZXXs
2qU7iyKyMv2AS+jOY9tKN/DwEUaLmXXxm7Rrjibkzx2eEiQHG2make4uXBFMBv/3
jykzStGdKK74jiievLm/JtbfwSVFvg/eG9Cf+QG+9tyK/tns+c4SVuNAHTTyUKKx
w80f4gaC787M2MajI5FrCCvpoiw0UNOKXeoSpraefIVyb7WL3vs=
=+0LE
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-10-rc6' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-10-rc6
Documentation:
* doc: improve description of autostart
UEFI:
* prefix test functions with efi_st_ in the LoadImage unit test
* avoid a warning message in efi_initrd_deregister()
At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.
This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.
Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current tests do not cover all functions, nor do they cover the new
multi-tree functionality. Add and update the tests accordingly and update
the 'future work' notes in the documentation.
There is a still more testing needed for the failure cases, since at
present some ofnode functions return a libfdt error code instead of
converting it to an errno.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some ofnode functions can only operate on the default device tree, i.e.
U-Boot's control FDT. Add comments to that effect. Fix up the reference to
device tree bindings while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
We need to be able to look up phandles in any FDT, not just the control
FDT. Use the 'other' FDT to test this, with a helper function which gets
this as an oftree that can then we used as needed.
Add a few more tests and some comments at the top of the file, to explain
what is going on.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.
It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.
The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.
Update the documentation a little and fix up the comment for
ofnode_valid().
Signed-off-by: Simon Glass <sjg@chromium.org>
At present, unless OF_LIVE is enabled, ofnode only supports access to one
device tree, the control FDT. This is because only the node offset is
encoded in ofnode, with the tree being implicit.
This makes ofnode (without OF_LIVE) unsuitable for device tree fixups, as
implemented by ft_board_setup() and other such functions.
To solve this, we can use the top bits of the node offset to hold a tree
ID.
Add the definitions for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function turns out to be a little confusing since it looks up a path
and also registers the tree. Split it into two, one that gets the root
node and one that looks up a path, so the purpose is clear.
Registering the tree will happen in a function to be added in a later
patch, called oftree_from_fdt().
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we want to obtain an ofnode in the same tree as a different
ofnode, such as when looking up a subnode. At present this is trivial,
since there is only one tree. When there are multiple trees, this
implementation will change.
Also move the ofnode_to_offset() function up higher in the header file,
since we will need to provide a different implementation with multiple
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
When we have multiple trees, the ofnode logic needs to be told which one
to use. Create a new function which takes an oftree argument, along with
a helper to obtain the FDT pointer from an oftree.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present dm_test_ofnode_root() does this manually. Add some inline
functions to handle it, so this code can be centralised.
Add oftree functions to produce a null tree and to check whether a tree
is valid or not.
Signed-off-by: Simon Glass <sjg@chromium.org>
The flat device tree is assumed to be the control FDT but this is not
always the case. Update the ofnode implementation to obtain the node via
an function call so we can eventually add support for selecting different
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is only one device tree used by the ofnode functions,
except for some esoteric use of live tree. In preparation for supporting
more than one, add a way to reset the list of device trees.
For now this does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current tests do not cover all the behaviour. Add some more.
Tidy up a few inconsistencies between livetree and flattree which come to
light with these tests. Also drop the -ENODATA error since it is never
actually returned.
Signed-off-by: Simon Glass <sjg@chromium.org>
An upcoming patch set creates a global function flush(). To make debugging
easier we should not use the same name for a static function.
Rename static functions in the LoadImage() unit test adding an efi_st_
prefix.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Complete the list of commands influenced by the autostart environment
variable.
Make it clearer what values qualifies at 'yes'.
Eventually the list of environment variables is to be alphabetically
sorted. Move autostart up.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
