Tom Rini [Wed, 23 Feb 2022 17:28:14 +0000 (12:28 -0500)]
powerpc: Remove unused MPC8540/60ADS code
Remove some code, primarily CPM2 related, that is now unused since the
removal of MPC8540/60ADS.
Fixes 3913191c8a6b ("powerpc: mpc8540ads: mpc8560ads: Drop support for MPC8540/60ADS") Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Etienne Carriere [Mon, 21 Feb 2022 08:22:42 +0000 (09:22 +0100)]
clk: scmi: register scmi clocks with CCF
Implements SCMI APIs to retrieve the number exposed SCMI clocks using
SCMI_PROTOCOL_ATTRIBUTES messages and the names of the clocks using
SCMI_CLOCK_ATTRIBUTES messages.
This change updates sandbox SCMI clock test driver to manage these
2 new message IDs.
Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Cc: Clement Leger <clement.leger@bootlin.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Etienne Carriere [Mon, 21 Feb 2022 08:22:41 +0000 (09:22 +0100)]
firmware: scmi: fix sandbox and related tests for clock discovery
Updates sandbox SCMI clock driver and tests since enabling CCF will
mandate clock discovery that is all exposed SCMI clocks shall be
discovered at initialization. For this reason, sandbox SCMI clock
driver must emulate all clocks exposed by SCMI server, not only those
effectively consumed by some other U-Boot devices.
Therefore the sandbox SCMI test driver exposes 3 clocks (IDs 0, 1 and 2)
and sandbox SCMI clock consumer driver gets 2 of them.
Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Etienne Carriere [Mon, 21 Feb 2022 08:22:40 +0000 (09:22 +0100)]
scmi: change parameter dev in devm_scmi_process_msg
Changes devm_scmi_process_msg() first argument from target parent device
to current SCMI device and lookup the SCMI agent device among SCMI device
parents for find the SCMI agent operator needed for communication with
the firmware.
This change is needed in order to support CCF in clk_scmi driver unless
what CCF will fail to find the right udevice related to exposed SCMI
clocks.
This patch allows to simplify the caller sequence, using SCMI device
reference as parameter instead of knowing SCMI uclass topology. This
change also adds some protection in case devm_scmi_process_msg() API
function is called for an invalid device type.
Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Etienne Carriere [Mon, 21 Feb 2022 08:22:39 +0000 (09:22 +0100)]
sandbox: scmi: test against a single scmi agent
As per DT bindings since Linux kernel v5.14, the device tree can define
only 1 SCMI agent node that is named scmi [1]. As a consequence, change
implementation of the SCMI driver test through sandbox architecture to
reflect that.
This change updates sandbox test DT and sandbox SCMI driver accordingly
since all these are impacted.
Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Tom Rini [Wed, 2 Mar 2022 18:59:33 +0000 (13:59 -0500)]
Merge branch '2022-03-02-armv8-fixes-and-cleanups' into next
To quote the author:
I was looking into the arm64 boot code lately and stumbled upon some
issues. Also Nishanth brought back memories of a lengthy debug session,
which was caused due to U-Boot keeping SErrors masked. As the resulting
patches are all somewhat related, I gathered this series here to address
those problems.
Patches 1 to 3 address exception handling issues, with the SError
enablement being the most prominent fix here.
Patch 4 cleans up asm/io.h. This was on the list before[1], but was
somehow lost when it was intercepted by a shorter version of itself.
Patches 5 and 6 clean up some unnecessarily complicated AArch64 assembly
code.
Andre Przywara [Fri, 11 Feb 2022 11:29:39 +0000 (11:29 +0000)]
armv8: Fix and simplify branch_if_master/branch_if_slave
The branch_if_master macro jumps to a label if the CPU is the "master"
core, which we define as having all affinity levels set to 0. To check
for this condition, we need to mask off some bits from the MPIDR
register, then compare the remaining register value against zero.
The implementation of this was slighly broken (it preserved the upper
RES0 bits), overly complicated and hard to understand, especially since
it lacked comments. The same was true for the very similar
branch_if_slave macro.
Use a much shorter assembly sequence for those checks, use the same
masking for both macros (just negate the final branch), and put some
comments on them, to make it clear what the code does.
This allows to drop the second temporary register for branch_if_master,
so we adjust all call sites as well.
Also use the opportunity to remove a misleading comment: the macro
works fine on SoCs with multiple clusters. Judging by the commit
message, the original problem with the Juno SoC stems from the fact that
the master CPU *can* be configured to be from cluster 1, so the
assumption that the master CPU has all affinity values set to 0 does not
hold there. But this is already mentioned above in a comment, so remove
the extra comment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 11 Feb 2022 11:29:38 +0000 (11:29 +0000)]
armv8: Simplify switch_el macro
The switch_el macro is a neat contraption to handle cases where we need
different code depending on the current exception level, but its
implementation was longer than needed.
Simplify it by doing just one comparison, then using the different
condition codes to branch to the desired target. PState.CurrentEL just
holds two bits, and since we don't care about EL0, we can use >, =, < to
select EL3, EL2 and EL1, respectively.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 11 Feb 2022 11:29:37 +0000 (11:29 +0000)]
arm: Clean up asm/io.h
asm/io.h is the header file containing the central MMIO accessor macros.
Judging by the header and the comments, it was apparently once copied
from the Linux kernel, but has deviated since then *heavily*. There is
absolutely no point in staying close to the original Linux code anymore,
so just remove the old cruft, by:
- removing pointless Linux history
- removing commented code
- removing outdated comments
- removing unused definitions (for mem_isa)
This massively improves the readability of the file.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 11 Feb 2022 11:29:36 +0000 (11:29 +0000)]
armv8: Force SP_ELx stack pointer usage
In ARMv8 we have the choice between two stack pointers to use: SP_EL0 or
SP_ELx, which is banked per exception level. This choice is stored in
the SP field of PState, and can be read and set via the SPSel special
register. When the CPU takes an exception, it automatically switches to
the SP_ELx stack pointer.
Trusted Firmware enters U-Boot typically with SPSel set to 1, so we use
SP_ELx all along as our sole stack pointer, both for normal operation and
for exceptions.
But if we now for some reason enter U-Boot with SPSel cleared, we will
setup and use SP_EL0, which is fine, but leaves SP_ELx uninitialised.
When we now take an exception, we try to save the GPRs to some undefined
location, which will usually end badly.
To make sure we always have SP_ELx pointing to some memory, set SPSel
to 1 in the early boot code, to ensure safe operation at all times.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 11 Feb 2022 11:29:35 +0000 (11:29 +0000)]
armv8: Always unmask SErrors
The ARMv8 architecture describes the "SError interrupt" as the fourth
kind of exception, next to synchronous exceptions, IRQs, and FIQs.
Those SErrors signal exceptional conditions from which the system might
not easily recover, and are normally generated by the interconnect as a
response to some bus error. A typical situation is access to a
non-existing memory address or device, but it might be deliberately
triggered by a device as well.
The SError interrupt replaces the Armv7 asynchronous abort.
Trusted Firmware enters U-Boot (BL33) typically with SErrors masked,
and we never enable them. However any SError condition still triggers
the SError interrupt, and this condition stays pending, it just won't be
handled. If now later on the Linux kernel unmasks the "A" bit in PState,
it will immediately take the exception, leading to a kernel crash.
This leaves many people scratching their head about the reason for
this, and leads to long debug sessions, possibly looking at the wrong
places (the kernel, but not U-Boot).
To avoid the situation, just unmask SErrors early in the ARMv8 boot
process, so that the U-Boot exception handlers reports them in a timely
manner. As SErrors are typically asynchronous, the register dump does
not need to point at the actual culprit, but it should happen very
shortly after the condition.
For those exceptions to be taken, we also need to route them to EL2,
if U-Boot is running in this exception level.
This removes the respective code snippet from the Freescale lowlevel
routine, as this is now handled in generic ARMv8 code.
Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 11 Feb 2022 11:29:34 +0000 (11:29 +0000)]
cmd: exception: arm64: fix undefined, add faults
The arm64 version of the exception command was just defining the
undefined exception, but actually copied the AArch32 instruction.
Replace that with an encoding that is guaranteed to be and stay
undefined. Also add instructions to trigger unaligned access faults and
a breakpoint.
This brings ARM64 on par with ARM(32) for the exception command.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Simon Glass [Fri, 11 Feb 2022 20:23:25 +0000 (13:23 -0700)]
buildman: Update default config to build for sandbox
At present the default .buildman file written by buildman does not specify
a default toolchain. Add an 'other' line so this works correctly and
sandbox builds run as expected.
Simon Glass [Fri, 11 Feb 2022 20:23:21 +0000 (13:23 -0700)]
binman: Correct pylint errors
Fix pylint errors that can be fixed and mask those that seem to be
incorrect.
A complication with binman is that it tries to avoid importing libfdt
(or anything that imports it) unless needed, so that things like help
still work if it is missing.
Note that two tests are duplicated in binman and two others have
duplicate names, so both of these issues are fixed also.
Linus Walleij [Sun, 20 Feb 2022 22:47:01 +0000 (23:47 +0100)]
board: stemmy: Detect board variants and patch DTB
This patch scans the cmdline from the Samsung SBL (second stage
bootloader) and stores the parameters board_id=N and lcdtype=N
in order to augment the DTB for different board and LCD types.
We then add a custom ft_board_setup() callback that will inspect
the DTB and patch it using the stored LCD type. At this point
we know which product we are dealing with, so using the passed
board_id we can also print the board variant for diagnostics.
We patch the Codina, Skomer and Kyle DTBs to use the right
LCD type as passed in lcdtype from the SBL.
This also creates an infrastructure for handling any other
Samsung U8500 board variants that may need a slightly augmented
DTB.
Janne Grunau [Sat, 19 Feb 2022 13:05:19 +0000 (14:05 +0100)]
arm: apple: Switch to fully dynamic mem layout
Support for Apple M1 Pro and Max will allow using a single binary for
all M1 SoCs. The M1 Pro/Max have a different memory layout. The RAM
start address is 0x100_0000_0000 instead of 0x8_0000_0000.
Replace the hardcoded memory layout with dynamic initialized
environment variables in board_late_init().
Tested on Mac Mini (2020) and Macbook Pro 14-inch (2021).
Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Felix Brack [Mon, 21 Feb 2022 13:26:05 +0000 (14:26 +0100)]
arm: pdu001: Setup pinmux for console UART as early as possible
To make sure we get a working console as soon as possible in the SPL the
UART pins require to be configured earlier. This is especially
true for the pins of UART3, since the PDU001 board uses this UART for
the console by default.
Felix Brack [Tue, 15 Feb 2022 14:27:23 +0000 (15:27 +0100)]
arm: pdu001: Fix early debugging UART
The changes from commit 0dba45864b2a ("arm: Init the debug UART")
prevent the early debug UART from being initialized correctly.
To fix this we not just configure the pin multiplexer but add setting up
early clocks.
Signed-off-by: Felix Brack <fb@ltec.ch> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Pali Rohár [Sun, 13 Feb 2022 00:09:46 +0000 (01:09 +0100)]
tools: mkimage/dumpimage: Allow to use -l with -T
Currently -l option for mkimage and dumpimage ignores option -T and always
tries to autodetect image type.
With this change it is possible to tell mkimage and dumpimage to parse
image file as specific type (and not random autodetected type). This allows
to use mkimage -l or dumpimage -l as tool for validating image.
params.type for -l option is now by default initialized to zero
(IH_TYPE_INVALID) instead of IH_TYPE_KERNEL. imagetool_get_type() for
IH_TYPE_INVALID returns NULL, which is assigned to tparams. mkimage and
dumpimage code is extended to handle tparams with NULL for -l option. And
imagetool_verify_print_header() is extended to do validation via tparams if
is not NULL.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Masahisa Kojima [Tue, 22 Feb 2022 00:58:30 +0000 (09:58 +0900)]
efi_loader: update the timing of enabling and disabling EFI watchdog
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.
1) The EFI Image may reset or disable the watchdog timer as needed.
2) If control is returned to the firmware's boot manager,
the watchdog timer must be disabled.
3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
the watchdog timer is disabled.
1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.
In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masami Hiramatsu [Wed, 16 Feb 2022 06:16:12 +0000 (15:16 +0900)]
efi_loader: test/py: Reset system after capsule update on disk
Add a cold reset soon after processing capsule update on disk.
This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;
In all cases that a capsule is identified for processing the system is
restarted after capsule processing is completed.
This also reports the result of each capsule update so that the user can
notice that the capsule update has been succeeded or not from console log.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masami Hiramatsu [Wed, 16 Feb 2022 06:16:02 +0000 (15:16 +0900)]
test/py: Handle expected reboot while booting sandbox
Add expected_reset optional argument to ConsoleBase::ensure_spawned(),
ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags()
so that it can handle a reset while the 1st boot process after main
boot logo before prompt correctly.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masami Hiramatsu [Wed, 16 Feb 2022 06:15:42 +0000 (15:15 +0900)]
efi_loader: use efi_update_capsule_firmware() for capsule on disk
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.
Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().
This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.
Ilias Apalodimas [Mon, 14 Feb 2022 09:14:22 +0000 (11:14 +0200)]
efi_loader: fix uefi secure boot with intermediate certs
The general rule of accepting or rejecting an image is
1. Is the sha256 of the image in dbx
2. Is the image signed with a certificate that's found in db and
not in dbx
3. The image carries a cert which is signed by a cert in db (and
not in dbx) and the image can be verified against the former
4. Is the sha256 of the image in db
For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.
However it's the CA cert in the middle of the chain which usually ends up
in the system's db. pkcs7_verify_one() might or might not return the root
certificate for a given chain. But when verifying executables in UEFI, the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db. Currently we only allow this check on self-signed
certificates, so let's remove that check and allow all certs to try a
match an entry in db.
Open questions:
- Does this break any aspect of variable authentication since
efi_signature_verify() is used on those as well?
The wrong phy was being enabled, because it worked and the proper
PHY did not. After the Renesas maintainer made some adjustments
to the device tree, Linux was able to use the proper driver, and
when that device tree was ported to Linux, the ethernet stopped
working due to the lack of rgmii-rxid support. Now that
rgmii-rxid is supported, enable the proper driver to restore
ethernet function.
Fixes: 1eaf61c84db6 ("arm: dts: beacon-rzg2: Resync device trees with Linux 5.16-rc3") Signed-off-by: Adam Ford <aford173@gmail.com>
Adam Ford [Fri, 25 Feb 2022 20:32:52 +0000 (14:32 -0600)]
net: ravb: Add tx/rx delay flag checks and support for rgmii-rxid
Some boards like the Beacon RZ/G2 SOM use either flags for
tx-internal-delay-ps, rx-internal-delay-ps or rgmii-rxid.
In Linux the APSR_RDM flag is set when either rx-internal-delay-ps
is set or the mode is rgmii-rxid, and the APSR_TDM is set when
tx-internal-delay-ps is found or rgmii-txid is set, and both
are set if rgmii-id is set.
The ravb driver in U-Boot driver was missing rgmii-rxid support,
so add that support in a similar fashion to what is done in Linux.
Philippe Reynes [Tue, 22 Feb 2022 13:54:39 +0000 (14:54 +0100)]
scripts: Makefile.lib: generate dsdt_generated.c instead of dsdt.c
There is a conflict between the static file
lib/acpi/dsdt.c and the file dsdt.c generated
dynamicaly by scripts/Makefile.lib. When a
mrproper is done, the static file dsdt.c is
removed. If a build with acpi enabled is
launched after, the following error is raised:
CC lib/acpi/acpi_table.o
make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by 'lib/acpi/dsdt.c'. Stop.
scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
To avoid such error, the generated file is named
dsdt_generated.c instead of dstdt.c.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Patrick Delaunay [Mon, 31 Jan 2022 16:21:38 +0000 (17:21 +0100)]
cmd: clk: replace clk_lookup by uclass_get_device_by_name
The function clk_lookup can be replaced by a direct call
to uclass_get_device_by_name for UCLASS_CLK.
This patch removes duplicated codes by the generic DM API and avoids
issue in clk_lookup because result of uclass_get_device wasn't tested;
when ret < 0, dev = NULL and dev->name is invalid, the next function
call strcmp(name, dev->name) causes a crash.
Patrick Delaunay [Mon, 24 Jan 2022 13:17:14 +0000 (14:17 +0100)]
clk: ccf: correct the test on the parent uclass in clk_enable/clk_disable
It is safe to check if the uclass id on the device is UCLASS_CLK
before to call the clk_ functions, but today this comparison is
not done on the device used in API: clkp->dev->parent
but on the device himself: clkp->dev.
This patch corrects this behavior and tests if the parent device
is a clock device before to call the clock API, clk_enable or
clk_disable, on this device.
Fixes: 0520be0f67e3 ("clk: prograte clk enable/disable to parent") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson [Sat, 15 Jan 2022 20:52:47 +0000 (15:52 -0500)]
clk: Add clk_get_by_name_optional
This adds a helper function for clk_get_by_name in cases where the clock is
optional. Hopefully this helps point driver writers in the right direction.
Also convert some existing users.
Sean Anderson [Wed, 22 Dec 2021 17:11:13 +0000 (12:11 -0500)]
clk: Add driver API to HTML docs
This converts the existing driver API docs (clk-uclass.h) to kernel doc
format and adds them to the HTML documentation. Because the kernel doc
sphinx converter does not handle functions in structs very well, the
individual methods are documented separately. This is primarily inspired by
the phylink documentation [1], which uses this trick extensively.
Sean Anderson [Wed, 22 Dec 2021 17:11:12 +0000 (12:11 -0500)]
clk: Add client API to HTML docs
This converts the existing client (aka clk.h) documentation to kernel doc
format, and adds it to the HTML docs. I have tried to preserve existing
comments as much as possible, refraining from semantic changes.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20211222171114.3091780-4-seanga2@gmail.com
[rebased onto u-boot/master and resolved conflicts] Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson [Wed, 22 Dec 2021 17:11:11 +0000 (12:11 -0500)]
clk: Inline clk_get_*_optional
The optional varients of clk_get_* functions are just simple wrappers.
Reduce code size a bit by inlining them. On platforms where it is not used
(most of them), it will not be compiled in any more. On platforms where
they are used, the inlined branch should not cause any significant growth.
Adam Ford [Sat, 19 Feb 2022 23:08:46 +0000 (17:08 -0600)]
usb: ehci-omap: Remove OMAP_EHCI_PHYx_RESET_GPIO from Kconfig
With the omap-ehci driver now using the phy subsystem to enable
and disable reset, the driver no longer needs to know which
GPIO's are used, and they can be removed from Kconfig.
Adam Ford [Sat, 19 Feb 2022 23:08:45 +0000 (17:08 -0600)]
usb: ehci-omap: Use PHY system to manage phy resets
There are a few boards that use hard-coded GPIO definitions in
their respective defconfig files. If the GPIO's are listed
in their device trees, the nop-phy can toggle the GPIO's,
so the EHCI driver does not need to know anything about the
GPIO's. Add functions for getting the phys and remove the GPIO
toggles since the phy will now do that.
Adam Ford [Sat, 19 Feb 2022 23:08:44 +0000 (17:08 -0600)]
usb: ehci-omap: Make Kconfig select PHY if USB_EHCI_OMAP
The USB_EHCI_OMAP driver currently has a series of Kconfig options
which let users specify a GPIO for the reset pin. Some devices
may have only one reset, while others might have more.
Since there is a nop phy driver, let's selct enable the PHY
system, and imply the nop phy driver. The nop phy driver can now
toggle the reset pins when putting the phy in and out of reset.
If the gpio is listed under the phy, it will get toggled and
the hard-coded config options specifying the GPIO numbers can
eventually go away.
Adam Ford [Sat, 19 Feb 2022 23:08:43 +0000 (17:08 -0600)]
phy: nop-phy: Fix enabling reset
The reset function should place the phy into reset, while the
init function should take the phy out of reset. Currently the
reset function takes it out of reset, and the init calls the
reset.
Adam Ford [Sat, 19 Feb 2022 23:08:42 +0000 (17:08 -0600)]
usb: ehci-omap: Move omap_ehci_hcd_init to omap_ehci_probe
The OMAP3 hierarchy has the ehci node as a sub-node of the
usbhshost. The usbhshost node contains an ohci and an ehci
subnode. The configuration of the ehci belongs in the
EHCI node and not its parent. Move it to the proper probe.
usb start
starting USB...
Bus ehci@48064800: USB EHCI 1.00
Bus usb_otg_hs@480ab000: Port not available.
scanning bus ehci@48064800 for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Adam Ford [Sat, 19 Feb 2022 23:08:41 +0000 (17:08 -0600)]
usb: ehci-omap: Drop dead code
omap_ehci_hcd_stop appears to be dead code, and omap_ehci_hcd_init
is only called by the probe function, so it can be static to that
function. Remove both from the header along with some additional
checking for DM_USB.
On some configs (like stm32mp15_dhcom_basic_defconfig), if configs
SPL_LOAD_FIT_FULL and SPL_FIT_FULL_CHECK are enabled. Then the compilatio
fails with the following error:
arm-linux-gnueabi-ld.bfd: boot/image-fit.o: in function `fit_check_format':
<PATH>/uboot/u-boot-stm/boot/image-fit.c:1641: undefined reference to `fdt_check_full'
scripts/Makefile.spl:509: recipe for target 'spl/u-boot-spl' failed
This issue happens because the function fdt_check_full is only defined if
"!defined(FDT_ASSUME_MASK) || FDT_ASSUME_MASK != 0xff". But this function
may be called even if this condition are not verified. To avoid this issue,
the function fdt_check_full is always defined.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 8 Feb 2022 18:50:00 +0000 (11:50 -0700)]
binman: Move entry-data collection into a Entry method
Collecting the data from a list of entries and putting it in a file is
a useful operation that will be needed by other entry types. Put this into
a method in the Entry class.
Add some documentation about how to collect data for an entry type.
Simon Glass [Tue, 8 Feb 2022 18:49:58 +0000 (11:49 -0700)]
binman: Support a list of strings with the mkimage etype
At present the 'args' property of the mkimage entry type is a string. This
makes it difficult to include CONFIG options in that property. In
particular, this does not work:
args = "-n CONFIG_SYS_SOC -E"
since the preprocessor does not operate within strings, nor does this:
args = "-n" CONFIG_SYS_SOC" "-E"
since the device tree compiler does not understand string concatenation.
Roger Quadros [Sat, 19 Feb 2022 18:50:04 +0000 (20:50 +0200)]
binman: Add support for TEE BL32
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Add missing-blob-help, renumber the test file, update entry-docs: Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 8 Feb 2022 18:49:52 +0000 (11:49 -0700)]
dtoc: Allow deleting nodes and adding them in the same sync
This does not work at present, since the current algorithm assumes that
either there are no nodes or all nodes have an offset. If a node is new,
but an old node is still in the tree, then syncing fails due to this
assumption.
Simon Glass [Tue, 8 Feb 2022 18:49:47 +0000 (11:49 -0700)]
spl: x86: Correct the binman symbols for SPL
These symbols are incorrect, meaning that binman cannot find the
associated entry. This leads to errors like:
binman: Section '/binman/simple-bin': Symbol '_binman_spl_prop_size'
in entry '/binman/simple-bin/u-boot-spl/u-boot-spl-nodtb':
Entry 'spl' not found in list (mkimage,u-boot-spl-nodtb,
u-boot-spl-bss-pad,u-boot-spl-dtb,u-boot-spl,u-boot-img,main-section)
Simon Glass [Tue, 8 Feb 2022 18:49:46 +0000 (11:49 -0700)]
moveconfig: Allow regex matches when finding combinations
It is useful to be able to search for CONFIG options that match a regex,
such as this, which lists boards which define SPL_FIT_GENERATOR and
anything not starting with ROCKCHIP:
Binman keeps track of positions of each entry in the final image, but
currently this data is wrong for things included in FIT entries,
especially since a previous patch makes FIT a subclass of Section and
inherit its implementation.
There are three ways to put data into a FIT image. It can be directly
included as a "data" property, or it can be external to the FIT image
represented by an offset-size pair of properties. This external offset
is either "data-position" from the start of the FIT or "data-offset"
from the end of the FIT, and the size is "data-size" for both. However,
binman doesn't use the "data-offset" method while building FIT entries.
According to the Section docstring, its subclasses should calculate and
set the correct offsets and sizes in SetImagePos() method. Do this for
FIT subentries for the three ways mentioned above, and add tests for the
two ways binman can pack them in.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
binman: Skip processing "hash" subnodes of FIT subsections
Binman's FIT entry type can have image subentries with "hash" subnodes
intended to be processed by mkimage, but not binman. However, the Entry
class and any subclass that reuses its implementation tries to process
these unconditionally. This can lead to an error when boards specify
hash algorithms that binman doesn't support, but mkimage supports.
Let entries skip processing these "hash" subnodes based on an instance
variable, and set this instance variable for FIT subsections. Also
re-enable processing of calculated and missing properties of FIT entries
which was disabled to mitigate this issue.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Neal Liu [Tue, 15 Feb 2022 10:14:40 +0000 (18:14 +0800)]
crypto: aspeed: fix polling RSA status wrong issue
Check interrupt status to see if RSA engine is completed. After completion
of the task, write-clear the status to finish operation.
Add missing register base for completion.
Fixes: 89c36cca0b6 ("crypto: aspeed: Add AST2600 ACRY support") Signed-off-by: Neal Liu <neal_liu@aspeedtech.com> Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Suman Anna [Sun, 13 Feb 2022 18:48:48 +0000 (12:48 -0600)]
arm: dts: k3-j7200: Fix up MAIN R5FSS cluster mode back to Split-mode
The default U-Boot environment variables and design are all set up for
the MAIN R5FSS cluster to be in Split-mode. This is the setting used
when the dts nodes were originally added in v2021.01 U-Boot and the
dt nodes are synched with the kernel binding property names in
commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to upstreamed kernel DT
property names") merged in v2021.04-rc2.
The modes for the MAIN R5FSS cluster got switched back to LockStep mode
by mistake in commit fa09b12dc5f6 ("arm: ti: k3: Resync dts files and
bindings with Linux Kernel v5.14") in v2022.01-rc1. This throws the
following warning messages when early-booting the cores using default
env variables,
k3_r5f_rproc r5f@5d00000: Invalid op: Trying to start secondary core 7 in lockstep mode
Load Remote Processor 3 with data@addr=0x82000000 83148 bytes: Failed!
Fix this by switching back both the clusters to the expected Split-mode.
Make this mode change in the u-boot specific dtsi file to avoid such
sync overrides in the future until the kernel dts is also switched to
Split-mode by default.
Fixes: fa09b12dc5f6 ("arm: ti: k3: Resync dts files and bindings with Linux Kernel v5.14") Signed-off-by: Suman Anna <s-anna@ti.com>
Adam Ford [Sat, 12 Feb 2022 12:12:41 +0000 (06:12 -0600)]
arm: omap3: Make some memory functions static and clean headers
There are a few memory functions for both the emif4 (AM3517)
and sdrc (OMAP35/DM37) code that can be defined as static,
because those functions are not used externally. Make them
static and clean up some of the corresponding headers.
Adam Ford [Sat, 12 Feb 2022 12:12:40 +0000 (06:12 -0600)]
arm: omap3: Cleanup sys_info to fit OMAP3 booting with LTO
With LTO enabled, some functions appear to be optimized in a
way that causes hanging on some OMAP3 boards after some
unrelated patches were applied. The solution appears to make
several functions __used. There also appears be to be some
dead code, so remove it while cleaning this up.
This has been tested on a general purpose OMAP3530, DM3730,
and AM3517.
projects / u-boot.git / log