Simon Glass [Fri, 19 Nov 2021 20:24:05 +0000 (13:24 -0700)]
video: Support virtio devices with the splash screen
This is useful for showing a logo when booting from qemu.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:24:04 +0000 (13:24 -0700)]
video: Show the U-Boot logo by default
Enable this for boards with a display, unless they are using the SPLASH
feature.
This shows a U-Boot logo on boards with a display, which seems like a
useful thing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:24:03 +0000 (13:24 -0700)]
video: Support showing the U-Boot logo
Show the U-Boot logo by default. This is only 7KB in size so seems like
a useful default for boards that enable a display.
If SPLASH_SCREEN is enabled, it is not enabled by default, so as not to
conflict with that feature.
Also disable it for tests, since we don't want to complicate the output.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:24:02 +0000 (13:24 -0700)]
video: Drop VIDEO_LOGO from cfb_console
This driver is obsolete and only used by nokia_rx51. It should be deleted.
For now, drop the VIDEO_LOGO code to avoid confusion with the new
implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:24:01 +0000 (13:24 -0700)]
video: Convert CONFIG_VIDEO_LOGO to Kconfig
This converts the following to Kconfig:
CONFIG_VIDEO_LOGO
Note that this option depends on CONFIG_DM_VIDEO now, since cfb_console is
deprecated. The only relevant code is now in splash.c
Drop the check for DM_VIDEO in that file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:24:00 +0000 (13:24 -0700)]
video: Drop #ifdefs from video_bmp
Convert the current preprocessor macros to C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:59 +0000 (13:23 -0700)]
video: theadorable: Use RGB565 for BMP blitting
At present this uses RGB555 format for blitting to a display. Sandbox uses
565 and that seems to be more normal for BMP as well. Update the code
accordingly and add a test.
Note that this likely breaks the theadorable board so we may need to
discuss supporting both formats.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:58 +0000 (13:23 -0700)]
video: Add a test for 16bpp BMP files
Add a compressed 16bpp BMP file and a test to cover this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:57 +0000 (13:23 -0700)]
video: Tidy up 24/32 BMP blitting
Drop the unnecessary brackets.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:56 +0000 (13:23 -0700)]
video: Drop the uclass colour map
We don't need this anymore since we use the BMP palette directly. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:55 +0000 (13:23 -0700)]
video: bmp: Update RLE8 support to use the write function
Update this code to use write_pix8() rather than writing the pixels only
for a single supported display depth. This allows us to support any
depth.
Add some more tests too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:54 +0000 (13:23 -0700)]
video: Move BMP pixel-writing into a function
At present the code that writes to a pixel is quite convoluted. It uses a
colour map which is in the uclass and the same code is repeated in
different places within video_bmp_display().
As a first step, create a function which can write a pixel from the
bitmap, no matter what the display depth. Use any provided palette
directly, rather than using the uclass version.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:53 +0000 (13:23 -0700)]
video: Drop fb_put_byte() el at
These functions are not used with driver model, nor in any U-Boot boards.
Drop them and inline the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:52 +0000 (13:23 -0700)]
sandbox: Enable support for the gzip command
This does not work with sandbox at present. Fix it up to use map_sysmem()
to convert an address to a pointer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:51 +0000 (13:23 -0700)]
video: Expand video debugging buffer size
On sandbox these addresses are 16 hex digits log so we need more space
for the debug string. Update it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:50 +0000 (13:23 -0700)]
sandbox: video: Add BMP tests for 32bpp and 8bpp modes
Add a few more tests for BMP rendering. Use a back door into the sandbox
SDL driver to adjust the resolution at runtime.
The truetype code does not support 8bpp. Add this so that the display is
not blank when running in this mode.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:49 +0000 (13:23 -0700)]
sandbox: video: Correct the address of the copy base
The intention is for the copy base to start halfway through the
frame-buffer area. At present is it actually below the frame buffer,
which could have anything in it (probably it is malloc space). Fix
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:48 +0000 (13:23 -0700)]
video: sandbox: Set a maximum frame-buffer size
If U-Boot starts with the frame buffer set to 16bpp but then runs a test
that uses 32bpp, there is not enough space. Update the driver to use the
maximum possible frame-buffer size, to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:47 +0000 (13:23 -0700)]
console: Avoid serial output before the console is running
The video driver uses this for debugging, but if used before relocation it
crashes at present. Avoid trying to output debugging before the console is
ready.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:46 +0000 (13:23 -0700)]
video: sandbox: Avoid duplicate display windows
When unit tests are run they currently create a new window. Update the
code so that the old one is removed first. This avoids the confusion as to
which one is active.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 19 Nov 2021 20:23:45 +0000 (13:23 -0700)]
sandbox: video: Support 8bpp depth
At present sandbox only supports 16 and 32bpp depths, since those are the
easy ones with SDL.
We can support other depths by manually converting the pixel formats. Add
support for this, to enable an 8ppp (monochrome) format.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 24 Dec 2021 14:31:35 +0000 (09:31 -0500)]
Merge branch '2021-12-23-make-OF_BOARD-a-boolean' into next
Merge v8 of Simon's series to make CONFIG_OF_BOARD a boolean option.
Quoting him:
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and
appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in
the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all
in the U-Boot tree. Most boards do provide one, but some don't. Some
don't even provide instructions on how to boot on the board.
The problems with this approach were covered in another patch[1], since
removed from this series.
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
can obtain its devicetree at runtime, even it is has a devicetree built
in U-Boot. This is because U-Boot may be a second-stage bootloader and its
caller may have a better idea about the hardware available in the machine.
This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an
option, available with either OF_SEPARATE or OF_EMBED. This would allow
rpi3, for example, to run with the devicetree provided by the prior
bootloader.
This series makes this change, adding various missing devicetree files
(and placeholders) to make the build work.
To make the 'prior stage' side of things more deterministic, a new
OF_HAS_PRIOR_STAGE is added, which cannot be disabled by updated a board's
defconfig. This should help to prevent mistakes.
It also adds a run-time message showing where the devicetree came from,
as well as warnings if the board's expected flow is not being used. This
comes originally from the 'standard passage' series, which depends on
this series.
It also provides a few qemu clean-ups discovered along the way. The
qemu-riscv64_spl problem is fixed.
Please see [2] for discussion on the v6 series.
I put Heinrich's Tested-by tag[3] for the series onto the three devicetree
patches (ARM and RISC-V) that I think it most affects. It isn't possible
to apply a tag to a whole series at present and in any case there are
changes in v7.
This series is available at u-boot-dm/ofb-working
[1] https://patchwork.ozlabs.org/project/uboot/patch/
20211207001209.3467163-2-sjg@chromium.org/
[2] https://lore.kernel.org/u-boot/
20211205133207.GW1220664@bill-the-cat/T/#mcd8c0258827fbc1bb3000b7ff9ba0929df1ddcb2
[3] https://lore.kernel.org/u-boot/
93913911-4d20-d28f-ee04-
739985184c5e@canonical.com/raw
Simon Glass [Fri, 17 Dec 2021 03:59:39 +0000 (20:59 -0700)]
fdt: Show a runtime warning based on devicetree source
When running, if the devicetree failed to come from the expected source,
show a warning, e.g:
U-Boot ...
DRAM: 128 MiB
Core: 42 devices, 11 uclasses, devicetree: separate
Warning: Unexpected devicetree source (not from a prior stage)
Warning: U-Boot may not function properly
Flash: 64 MiB
...
These warnings should only appear if the board config has been changed, or
the prior stage is broken.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:38 +0000 (20:59 -0700)]
fdt: Avoid emitting an device tree when not needed
U-Boot always needs some sort of a device tree in the build. Some boards
never actually use this, at least in production systems, since a prior
firmware stage sets one up and passes it to U-Boot. At present the only
mechanism to do that is with custom function (OF_BOARD), but future work
will include a standard way of doing this ('standard passage').
It can be confusing to see a device tree emitted from the U-Boot build in
this situation. Add an option to drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:37 +0000 (20:59 -0700)]
fdt: Makefile: Ensure that OF_BOARD is used when needed
Boards which define OF_HAS_PRIOR_STAGE must define OF_BOARD at present,
since a custom function is the only way to obtain the devicetree at
runtime.
Add a build error when this requirement is not met, to avoid accepting
any patches which break this requirement.
Add an allowlist for boards which use it, currently none. This allowlist
can be updated for local development, if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: change of_whitelist to of_allowlist]
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 17 Dec 2021 03:59:36 +0000 (20:59 -0700)]
fdt: Enable OF_HAS_PRIOR_STAGE for most boards with OF_BOARD
Use this new Kconfig instead of OF_BOARD, so we know for sure which boards
obtain their devicetree from a prior stage. Leave sandbox alone since it
does not. Also don't touch xilinx_versal_virt since it does not have a
specific TARGET Kconfig.
This option implies OF_BOARD for now, but with future work standard
passage may be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add rpi_4_32b and rpi_arm64 to the list of boards converted]
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 17 Dec 2021 03:59:35 +0000 (20:59 -0700)]
fdt: Add a Kconfig for boards with a prior stage
When U-Boot is started from another firmware program, not just a prior
phase of U-Boot, special behaviour is typically used. In particular, the
device tree may come from that prior stage.
At present this is sort-of indicated by OF_BOARD, although the
correlation is not 1:1, since that option simply means that the board has
a custom mechanism for obtaining the device tree. For example, sandbox
defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
make use of the devicetree in U-Boot if it wishes, as used by
dragonboard410c until very recently.
Add an explicit Kconfig for this situation. Update the OF_BOARD option to
more-accurately reflect what it is doing, e.g. for sandbox.
Drop the docs in the README as it is out of date.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:34 +0000 (20:59 -0700)]
fdt: Report the devicetree source
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.
Report the devicetree source in bdinfo too.
This looks something like this, with > marking the new line.
U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)
DRAM: 128 MiB
> Core: 42 devices, 11 uclasses, devicetree: passage
Flash: 64 MiB
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:33 +0000 (20:59 -0700)]
fdt: Record where the devicetree came from
Keep track of where the devicetree came from, so we can report this later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:32 +0000 (20:59 -0700)]
dm: core: Allow getting some basic stats
Add a function that returns some basic stats about driver model. For now
we only have two.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:31 +0000 (20:59 -0700)]
fdt: Don't call board_fdt_blob_setup() without OF_BOARD
At present this override function is called even when OF_BOARD is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
A follower patch adds warnings for this scenario, but for now we don't
have a Kconfig that definitively tells us that OF_BOARD should be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:30 +0000 (20:59 -0700)]
fdt: Drop remaining preprocessor macros in fdtdec_setup()
We only have two choices for obtaining the devicetree. Simplify the code
to make that clear.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:29 +0000 (20:59 -0700)]
fdt: Drop OF_CONTROL check in fdtdec_setup()
This function should only be called when OF_CONTROL is enabled. It
fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL
if OF_CONTROL is not enabled.
Drop this useless check.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:28 +0000 (20:59 -0700)]
fdt: Use if() for fdtcontroladdr check
Change this to use if() instead of #if
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:27 +0000 (20:59 -0700)]
fdt: Drop #ifdef around board_fdt_blob_setup()
This serves no purpose. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:26 +0000 (20:59 -0700)]
fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
Move this to the header file to clean up the C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:25 +0000 (20:59 -0700)]
fdt: Drop #ifdefs with MULTI_DTB_FIT
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:24 +0000 (20:59 -0700)]
fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Fri, 17 Dec 2021 03:59:23 +0000 (20:59 -0700)]
fdt: Make it easier to debug u-boot.dtsi files
At present one must hack the Makefile to see what is going on with these
files. Also it doesn't quite work correctly.
Fix this by using an environment variable for debugging. Update the docs
also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:22 +0000 (20:59 -0700)]
fdt: Drop CONFIG_BINMAN_STANDALONE_FDT
This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:21 +0000 (20:59 -0700)]
fdt: Make OF_BOARD a bool option
This should not be a separate option from OF_SEPARATE. It is a run-time
option to override the devicetree, even if present.
Move the option out of the choice.
Disable BINMAN_FDT for a few boards which don't actually use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:20 +0000 (20:59 -0700)]
arm: highbank: Add devicetree files
Add an empty version of this file, so that we can at least build this
board when devicetrees are required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:19 +0000 (20:59 -0700)]
arm: qemu-ppce500: Add a devicetree file
This uses QEMU virt which creates its own devicetree.
Add an empty version of this file, so that we can at least build this
board when devicetrees are required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:18 +0000 (20:59 -0700)]
arm: bcm7xxx: Add a devicetree file
Add an empty devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:17 +0000 (20:59 -0700)]
arm: xilinx_versal_virt: Add a devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:16 +0000 (20:59 -0700)]
arm: octeontx: Add an empty devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:15 +0000 (20:59 -0700)]
arm: xenguest_arm64: Add a empty devicetree file
Add an empty version of this file, so that we can at least build this
board when devicetrees are required.
The real devicetree is created by the Xen project on-the-fly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:14 +0000 (20:59 -0700)]
arm: vexpress: Add a devicetree files for juno
Sync these file, obtained from Linux v5.15.
Add a note for the maintainer, and SPDX lines where they are missing.
The added lines are:
SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
Note, this matches the text in those files, but is not the same as the
GPL-2.0 of some files.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Simon Glass [Fri, 17 Dec 2021 03:59:13 +0000 (20:59 -0700)]
arm: rpi: Sync rpi dts files from Linux
Sync these files, obtained from Linux v5.15.
This adds a devicetree file for rpi_4 which was not there before.
Testing shows no change so far as I can see:
- boots to U-Boot prompt on rpi0, rpi2
- boots to distro on rpi3
- boots to distro on rpi4
I am assuming that syncing with Linux is safe, but the maintainer should
know for sure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:12 +0000 (20:59 -0700)]
riscv: qemu: Split devicetree files for qemu_riscv32/64
This uses QEMU virt which creates its own devicetree.
Copy the existing empty version of this file, so splitting the existing
qemu-virt into two, since anyone actually trying to use this will need a
different devicetree for 32- and 64-bit machines.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:11 +0000 (20:59 -0700)]
arm: qemu: Add a devicetree file for qemu_arm64 virt
This uses QEMU virt which creates its own devicetree.
Add an empty version of this file, so that we can at least build this
board when devicetrees are required.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:10 +0000 (20:59 -0700)]
arm: qemu: Add a devicetree file for qemu_arm
This uses QEMU virt which creates its own devicetree.
Add an empty version of this file, so that we can at least build this
board when devicetrees are required.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:09 +0000 (20:59 -0700)]
arm: riscv: qemu: Explain how to extract the generated dt
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Also explain how to merge it to produce a devicetree with the U-Boot
features included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 17 Dec 2021 03:59:08 +0000 (20:59 -0700)]
arm: qemu: Mention -nographic in the docs
Without this option QEMU appears to hang. Add it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Tue, 21 Dec 2021 13:02:28 +0000 (08:02 -0500)]
Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-marvell into next
- pci_mvebu: Misc improvements and cleanup (Pali)
- turris_mox: Remove extra newline after module topology (Marek)
Heinrich Schuchardt [Tue, 21 Dec 2021 08:00:44 +0000 (09:00 +0100)]
doc: remove duplicate page inclusion
doc/usage/index.rst in branch origin/next includes usage/environment twice.
Remove the duplicate entry.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Marek Behún [Thu, 11 Nov 2021 15:35:49 +0000 (16:35 +0100)]
arm: mvebu: turris_mox: Remove extra newline after module topology
Remove extra newline after module topology is printed.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 11 Nov 2021 15:35:47 +0000 (16:35 +0100)]
pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR
The global data pointer is not used in this driver, remove it's
declaration.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 11 Nov 2021 15:35:43 +0000 (16:35 +0100)]
pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size()
Use more appropriate resource_size() function when working with data in
struct resource.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 11 Nov 2021 15:35:42 +0000 (16:35 +0100)]
pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup
Function mvebu_pcie_setup_wins() sets up all other BARs, so move setup of
BAR[0] to this function to have common code at one place.
In the past, commit
193a1e9f196b ("pci: pci_mvebu: set BAR0 after memory
space is set") moved setup of BAR[0] to another location, due to ath10k
not working in kernel, but the reason why was unknown, but it seems to
work now, and we think the issue then was cause by the PCIe Root Port
presenting itself as a Memory Controller and therefore U-Boot's code
have overwritten the BAR. Since the driver now ignores any write
operations to PCIe Root Port BARs, this should not be an issue anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Tom Rini [Mon, 20 Dec 2021 22:12:04 +0000 (17:12 -0500)]
Merge tag 'v2022.01-rc4' into next
Prepare v2022.01-rc4
Tom Rini [Mon, 20 Dec 2021 16:15:15 +0000 (11:15 -0500)]
Prepare v2022.01-rc4
Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Mon, 20 Dec 2021 14:36:32 +0000 (09:36 -0500)]
Revert "image: Remove #ifdefs from select_ramdisk()"
This reverts commit
f33a2c1bd0fb371511a485cac1f182ba50db51be.
This causes a crash on some platforms as seen here:
https://lore.kernel.org/r/
f153017b-c41a-0d32-67b9-
f288e695f900@baylibre.com/
Reported-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Joakim Tjernlund [Wed, 8 Dec 2021 14:33:11 +0000 (15:33 +0100)]
fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED use
Commit "fw_setenv: lock the flash only if it was locked before"
checks for Locked status with uninitialized erase data.
Address by moving the test for MEMISLOCKED.
Fixes:
8a726b852502 ("fw_setenv: lock the flash only if it was locked before")
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Tom Rini [Mon, 20 Dec 2021 13:51:53 +0000 (08:51 -0500)]
Merge tag '
20211220-fixes-for-2022.01' of https://source.denx.de/u-boot/custodians/u-boot-i2c
i2c changes for
20211220-fixes-for-2022.01
- mvtwsi: Swab the register address if its size is > 1
Stefan Roese [Thu, 18 Nov 2021 08:18:41 +0000 (09:18 +0100)]
i2c: mvtwsi: Swab the register address if its size is > 1
Testing on Armada XP with an EEPROM using register address with size
of 2 has shown, that the register address bytes are sent to the I2C
EEPROM in the incorrect order. This patch swabs the address bytes so
that the correct address is transferred to the I2C device.
BTW: This worked without any issues before migrating Armada XP to
DM I2C.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Samuel Holland <samuel@sholland.org>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Pali Rohár <pali@kernel.org>
Cc: Marek Behún <marek.behun@nic.cz>
Tested-by: Marek Behún <marek.behun@nic.cz>
Tom Rini [Sun, 19 Dec 2021 13:59:59 +0000 (08:59 -0500)]
Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-marvell into next
- Armada XP etc: Move to DM_I2C (Stefan)
- Some mvebu comphy + mox + fdt_support changes (Marek & Pali)
- mvebu: a38x: improve USB3 serdes configuration (Stefan Eichenberger)
- mvebu: Some maintainer updates (Pali)
- mvebu: Misc minor cleanup (Pali)
Pali Rohár [Fri, 17 Dec 2021 17:31:14 +0000 (18:31 +0100)]
arm: mvebu: Use printf for printing fatal errors
There is no point to hide/disable fatal errors via debug() macro.
Print fatal errors loudly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Fri, 17 Dec 2021 17:28:51 +0000 (18:28 +0100)]
arm: mvebu: Remove commented example code
Include file debug_uart.h already contains documentation how to use it.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 16 Dec 2021 11:04:07 +0000 (12:04 +0100)]
arm: mvebu: serial: Add me as co-maintainer and author of Marvell serial drivers
There is no maintainer entry for serial_mvebu_a3700.c. Add entry with Pali
and Stefan as maintainers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 16 Dec 2021 11:04:06 +0000 (12:04 +0100)]
arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers
There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Stefan Eichenberger [Thu, 9 Dec 2021 10:19:34 +0000 (11:19 +0100)]
arm: mvebu: a38x: serdes: improve USB3 electrical configuration
This is a backport from Marvell U-Boot:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
commit
381d029e7a ("fix: serdes: a38x, a39x: Improve USB3 electrical
configuration")
Improves electrical USB3 receiver jitter tolerance test:
- De-Emphasize force, in functional mode the transmitter should always
have 3.5db de-emphasize, so we are forcing it.
- After forcing De-Emphasize, choose 3.5db (After forcing, default is
6dB so need to change it to 3.5dB).
- Align90 set to 0x58 - this is the sample point in the receiver, after
the clock is recovered this sampler samples at the chosen value, usually
it is supposed to be 0x60(which is the center of the eye), but sometimes
after adding jitter and ISI the center of the eye can move slightly and
the sample point is not necessarily the exact center, and after
optimization (searching the middle of the eye manually) it was seen that
the center of the eye is actually 0x58 and not 0x60.
- FFE Res and FFE Cap set to 0xE & 0xF respectively: improves this
settings is adequate according to how the USB3 spec defines the
interconnect, thus improves USB3 jitter tolerance settings.
- Change the resolution of the DFE to 0x3 which is 6mV(highest
resolution) , this avoids the DFE to saturate and cease to work.
- HPF set to 0x3 which is 5Khz high pass filter, the function of the HPF
is to filter the low frequency patterns(below 5Khz) to make sure that
the signal is not a noise, the setting before was 0x1(205Khz), and the
change came since the USB3 CP0 pattern, that is used in the USB3 jitter
tolerance testing, is similar to PRBS15, which has 2^15=32768bits which
is 32768*200ps (200ps is one Unit interval in USB3(5Gbps)) = 6.5us,
which is in frequency terms: 152Khz. since the PRBS15 is a random
pattern and can theoretically have once in a while a pattern that will
be at frequency of 152Khz, hence the previous setting (205khz HPF) can
possibly filter this pattern which can cause to an error in the
receiver, thus this change to avoid such scenarios.
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Signed-off-by: René Straub <rene.straub@netmodule.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Stefan Eichenberger [Thu, 9 Dec 2021 10:19:33 +0000 (11:19 +0100)]
arm: mvebu: a38x: serdes: fix serdes config for USB3
The electrical serdes configuration for USB3 expects an array as data
argument. For USB3 the second value is used (see data_arr_idx = USB3 =
1). However, because only one value is inside the array mv_seq_exec is
accessing an invalid element and the serdes is configured wrongly.
This wrong initialization is leading to an unreliable detection
mechanism for some USB3 devices. We were able to reproduce the issue
regularly with an LTE modem from Sierra Wireless (SM7455) where it was
not detected as USB3 device in 1/3 of all tests.
This commit fixes the issue by setting data_arr_idx to 0. This is the
same value as the original U-Boot from Marvell is using. There it is
called FIRST_CELL which is a define for 0.
See: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
commit
56f963ce4c ("fix: serdes: a38x, a39x: Fix USB3 serdes DB
initialization")
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Signed-off-by: René Straub <rene.straub@netmodule.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:15 +0000 (14:57 +0100)]
fdt_support: Add fdt_delete_disabled_nodes() and use in Turris MOX
Move Turris MOX specific remove_disabled_nodes() to fdt_support with
name fdt_delete_disabled_nodes(), so that others can potentially use it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:14 +0000 (14:57 +0100)]
arm: mvebu: turris_mox: Fix unstable board topology reading
The pre-relocation board topology reading in board_fix_fdt() is
unstable: sometimes wrong data are read from the SPI bus.
This is due to wrong order of SPI bus configuration instructions: we
first need to set the pins to SPI mode, and only after that configure
the bus.
Also add a 1ms delay before enabling chip-select, so that the clock pin
is high for some time before reading the bus.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Fri, 26 Nov 2021 13:57:13 +0000 (14:57 +0100)]
phy: marvell: a3700: Convert to official DT bindings in COMPHY driver
Convert A3720 common PHY driver to official DT bindings.
This puts us closer to be able to synchronize A3720 device-trees with
those from Linux.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Konstantin Porotchkin <kostap@marvell.com>
Cc: Robert Marko <robert.marko@sartura.hr>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Fri, 26 Nov 2021 13:57:12 +0000 (14:57 +0100)]
arm: mvebu: turris_mox: Enable eth1 in U-Boot if a network module is present
Enable eth1 node in U-Boot's device-tree if a network module (SFP, Topaz
or Peridot) is detected.
This is required for proper detection of eth1 comphy in a3700 comphy
driver by the following patches.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:11 +0000 (14:57 +0100)]
arm: mvebu: turris_mox: Find DT nodes by compatible or alias instead of path
It is better to find DT nodes by compatible strings or aliases instead
of path.
There were issues with Linux some DTBs having different names of some
nodes, e.g.
internal-regs
instead of
internal-regs@
d0000000
This should be a generic fix for such issues.
Also since fdt_support now contains needed functions, we can drop our
own implementations.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:10 +0000 (14:57 +0100)]
fdt_support: Add some useful functions
Add functions
fdt_node_offset_by_pathf(),
fdt_create_phandle_by_pathf(),
fdt_set_status_by_pathf()
to get node offset, get/create node phandle and set status for node
given by path/alias formatted with sprintf.
Add functions
fdt_create_phandle_by_compatible(),
fdt_set_status_by_compatible()
to get/create node phandle and set status for first node given by
compatible.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:09 +0000 (14:57 +0100)]
fdt_support: Fix comment for fdt_create_phandle()
This function does not necessarily create a new phandle. If a phandle
exists, no new phandle is created.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:08 +0000 (14:57 +0100)]
fdt_support: Remove FDT_STATUS_FAIL_ERROR_CODE
Since no one uses this feature and I am not aware of any parsers of this
in Linux, remove it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Behún [Fri, 26 Nov 2021 13:57:07 +0000 (14:57 +0100)]
fdt_support: Remove fdt_alloc_phandle() in favor of fdt_generate_phandle()
Commit
f0921f5098d ("fdt: Sync up to the latest libfdt") introduced
fdt_generate_phandle() in libfdt, making fdt_alloc_phandle() obsolete in
fdt_support.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: "hui.song" <hui.song_1@nxp.com>
Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Behún [Fri, 26 Nov 2021 13:57:06 +0000 (14:57 +0100)]
treewide: Use fdt_create_phandle() where appropriate
Replace fdt_alloc_phandle() with subsequent fdt_set_phandle() by
fdt_create_phandle().
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Pali Rohár [Fri, 26 Nov 2021 13:57:05 +0000 (14:57 +0100)]
include/linux/byteorder: Fix compilation of __constant_cpu_to_be32()
The macro __constant_cpu_to_be32() uses ___constant_swab32(), which for
some reason is not defined and causes the following error during
compilation:
include/linux/byteorder/little_endian.h:28:52: warning:
implicit declaration of function ‘___constant_swab32’;
did you mean ‘__builtin_bswap32’? [-Wimplicit-function-declaration]
#define __constant_cpu_to_be32(x) ((__force __be32)___constant_swab32((x)))
Declare all ___constant_swabXX() macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:39 +0000 (09:19 +0100)]
arm: mvebu: armada-xp-theadorable.dts: Add I2C DT nodes
Now with DM I2C support enabled we need to describe the I2C busses and
devices in the DT.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:38 +0000 (09:19 +0100)]
arm: mvebu: axp: ddr: Switch to using DM I2C API
No functional change intended. This patch switches from the legacy I2C
API to the DM I2C API, so that this code can be used with DM I2C
enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:37 +0000 (09:19 +0100)]
arm: mvebu: axp: Remove unreferenced ddr3_get_eprom_fabric() function
This function is not referenced in mainline U-Boot. Let's remove now.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:36 +0000 (09:19 +0100)]
arm: mvebu: axp/high_speed_env_lib: Switch to DM_I2C API
After all Armada XP boards have been switched over from legacy I2C
support to DM I2C, let's now also convert this serdes code to use
the DM I2C API.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:35 +0000 (09:19 +0100)]
arm: mvebu: theadorable: Switch to using DM I2C API
No functional change intended. This patch switches from the legacy I2C
API to the DM I2C API, so that this code can be used with DM I2C
enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:34 +0000 (09:19 +0100)]
arm: mvebu: maxbcm_defconfig: Enable DM_I2C
Move to the DM I2C version, so that this board will not get dropped from
mainline.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:33 +0000 (09:19 +0100)]
arm: mvebu: ds414_defconfig: Enable DM_I2C
Move to the DM I2C version, so that this board will not get dropped from
mainline.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Phil Sutter <phil@nwl.cc>
Stefan Roese [Thu, 18 Nov 2021 08:19:32 +0000 (09:19 +0100)]
arm: mvebu: db-mv784mp-gp_defconfig: Enable DM_I2C
Move to the DM I2C version, so that this board will not get dropped from
mainline.
Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Thu, 18 Nov 2021 08:19:31 +0000 (09:19 +0100)]
arm: mvebu: theadorable_debug_defconfig: Enable DM_I2C
Move to the DM I2C version, so that this board will not get dropped from
mainline.
Signed-off-by: Stefan Roese <sr@denx.de>
Tom Rini [Sat, 18 Dec 2021 19:39:21 +0000 (14:39 -0500)]
Merge tag 'efi-2022-01-rc4-3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-01-rc4-3
Documentation:
* add Calxeda Highbank/Midway board documentation
Bug fixes:
* call part_init() in blk_get_device_by_str() only for MMC
* fix an 'undefined' error in some driver model macros
AKASHI Takahiro [Fri, 10 Dec 2021 06:49:36 +0000 (15:49 +0900)]
dm: fix an 'undefined' error in some macros
Due to a non-existing parameter name in macro's, use of those macro's will
cause a compiler error of "undefined reference".
Unfortunately, dm test doesn't fail because a wrong name ("&dev", hence it
is accidentally a valid name in the context of a caller site) is passed on.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Fixes:
f262d4ca4b2b ("dm: core: Add a way to read platdata for all
child devices")
Fixes:
903e83ee8464 ("dm: core: Add a way to iterate through children,
probing each")
Reviewed-by: Simon Glass <sjg@chromium.org>
AKASHI Takahiro [Fri, 10 Dec 2021 06:49:29 +0000 (15:49 +0900)]
blk: add a helper function, blk_probe_or_unbind()
This function will be commonly used in block device drivers
in the succeeding patches.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
AKASHI Takahiro [Fri, 10 Dec 2021 06:49:28 +0000 (15:49 +0900)]
part: call part_init() in blk_get_device_by_str() only for MMC
In blk_get_device_by_str(), the comment says: "Updates the partition table
for the specified hw partition."
Since hw partition is supported only on MMC, it makes no sense to do so
for other devices.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Andre Przywara [Tue, 14 Dec 2021 17:47:00 +0000 (17:47 +0000)]
doc: board: Add Calxeda Highbank/Midway documentation
The Calxeda servers are using U-Boot as the primary bootloader, which
was shipped as part of a firmware upgrade package.
Even though the machines are considered legacy at this point, the port
still works, so deserves some documentation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 17 Dec 2021 23:18:15 +0000 (18:18 -0500)]
Merge tag 'dm-pull-17dec21' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
binman support for ATF FIP
fdtgrep fixes for empty devicetree
Simon Glass [Wed, 8 Dec 2021 16:55:35 +0000 (09:55 -0700)]
fdtgrep: Handle an empty output tree
In strange cases it is possible for fdtgrep to find nothing to output.
Typically this means that the resulting SPL device tree is not going to
allow anything to boot, but at present the tree is actually invalid,
since it only has an END tag in the struct region.
The FDT spec requires at least a root node. So add a special case to
include at least this, if the FDT_REG_SUPERNODES flag is set.
This ensures that grepping an empty tree still produces a valid tree.
Also add comments to the enum since it is not completely obvious from
the names now.
The typical symptom of this problem is a message from binman:
pylibfdt error -11: FDT_ERR_BADSTRUCTURE
Signed-off-by: Simon Glass <sjg@chromium.org>