Erik Schumacher [Mon, 28 Oct 2024 15:29:42 +0000 (15:29 +0000)]
net: dwc_eth_qos: Add support for platform specific reset
This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Rasmus Villemoes [Thu, 24 Oct 2024 12:27:35 +0000 (14:27 +0200)]
imx: hab: fix size of IVT+CSF blob tacked on to u-boot.itb
Loading flash.bin using uuu fails when flash.bin does not have the
right size.
When flash.bin is loaded from some storage medium (sd card/emmc), SPL
just loads some random garbage bytes from beyond what has been
populated when flash.bin was written, but when loaded via uuu, SPL
hangs waiting for the host to send the expected number of bytes. Which
is (size of FIT image aligned to 0x1000)+CONFIG_CSF_SIZE. The
alignment to 0x1000 is already done and is necessary in all cases
because that's the exact expected location of the 32 byte IVT
header. But the IVT+CSF blob tacked onto the end must be a total of
CONFIG_CSF_SIZE.
This is exactly the same fix as 89f19f45d650, except that this time
around I don't know how to cleanly get CONFIG_CSF_SIZE.
Tom Rini [Tue, 29 Oct 2024 02:54:36 +0000 (20:54 -0600)]
Merge patch series "boards: siemens: iot2050: SM variant, sysinfo support, fixes & cleanups"
Jan Kiszka <jan.kiszka@siemens.com> says:
This adds support for the new IOT2050 SM variant, introduces a sysinfo
driver which also permits SMBIOS support and switches the board to
OF_UPSTREAM. There are some further fixes for the boards included as well.
Not yet included is configuration support for DMA isolation via the PVU as
this depends on not yet merged DT bindings and another overlay.
[trini: This is just the first 10 patches in the series for now]
Baocheng Su [Tue, 22 Oct 2024 06:04:27 +0000 (08:04 +0200)]
board: iot2050: Support new IOT2050-SM variant
Main differences between the new variant and Advanced PG2:
1. Arduino interface is removed. Instead, an new ASIC is added for
communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
available.
3. DP interface is tailored down. Instead, to communicate with the
PLC 1200 signal modules, a USB 3.0 type B connector is added but the
signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: rebased over OF_UPSTREAM] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Conor Dooley [Wed, 23 Oct 2024 10:17:54 +0000 (11:17 +0100)]
riscv: dts: mpfs: migrate to OF_UPSTREAM
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up the devicetree rework that is in progress at [1].
Conor Dooley [Wed, 23 Oct 2024 10:17:52 +0000 (11:17 +0100)]
clk: microchip: mpfs: support new syscon based devicetree configuration
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "cfg" and "periph" clocks a
reg region within the clock controller, rather as two registers within
a syscon region that also contains pinctrl, interrupt muxing controls
and other functions.
Make up for lost time and describe these regions as they should have
been originally, preserving support for the existing two configurations
for the sake of existing systems with firmware-provided devicetrees.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Anton Blanchard [Thu, 8 Aug 2024 02:14:17 +0000 (02:14 +0000)]
riscv: resume needs to be a global
If we take an exception before u-boot is relocated, there's a good
chance we will end up in an endless loop of exceptions because resume is
invalid until after relocation.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Jan Kiszka [Tue, 22 Oct 2024 06:04:25 +0000 (08:04 +0200)]
arm64: dts: ti: iot2050: Add overlays for M.2 used by firmware
To allow firmware to pick up all DTs from here, move the overlays that
are normally applied during DT fixup to the kernel source as well. Hook
then into the build nevertheless to ensure that regular checks are
performed.
Li Hua Qian [Tue, 22 Oct 2024 06:04:24 +0000 (08:04 +0200)]
arm64: dts: ti: iot2050: Disable lock-step for all iot2050 boards
The PG1 A variant of the iot2050 series has been identified which
partially lacks support for lock-step mode. This implies that all
iot2050 boards can't support this mode. As a result, lock-step mode has
been disabled across all iot2050 boards for consistency and to avoid
potential issues.
Jan Kiszka [Tue, 22 Oct 2024 06:04:23 +0000 (08:04 +0200)]
board: siemens: iot2050: Stop using special spl DT sources
We can simply use the default DT, Basic PG1, because no nodes that are
different between the variants play a role for SPL. Will help with the
migration to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Baocheng Su [Tue, 22 Oct 2024 06:04:22 +0000 (08:04 +0200)]
board: siemens: iot2050: Generalize the fdt fixup
The fdt fixup logic actually also applies to other possible variants who
also have device tree overlays. So generalize this part by extracting
it from the m.2 specific function and make it a standalone one.
Since now we only have M.2 variant consuming the overlay, it may not
have immediate effect for other variant, however this makes the future
variant more easier to apply fdt fixups.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Baocheng Su [Tue, 22 Oct 2024 06:04:20 +0000 (08:04 +0200)]
board: siemens: iot2050: Control pcie power for all variants
The power control pin of pcie interface not only works for M.2 interface
but also for miniPCIE, so promote this logic to all variants to
workaround the module hang issue.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Tom Rini [Tue, 29 Oct 2024 02:53:34 +0000 (20:53 -0600)]
Revert "acpi_table: Fix coverity defect in acpi_write_spcr"
This commit introduces a number of failure to build issues. For now,
revert it and we will wait for v2 to address the issue and the build
problems as well.
Patrick Rudolph [Mon, 28 Oct 2024 08:08:35 +0000 (09:08 +0100)]
acpi_table: Fix coverity defect in acpi_write_spcr
Fix "Integer handling issues (SIGN_EXTENSION)" in newly added code:
Cast serial_info.reg_offset to u64 to prevent an integer overflow when
shifted too many bits to the left. Currently this never happens as the
shift is supposed to be less than 4.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Moritz Fischer <moritzf@google.com>
Paul Barker [Wed, 23 Oct 2024 10:53:19 +0000 (11:53 +0100)]
mmc: renesas-sdhi: Add compatible string for rzg2l-sdhi
After the recent dts/upstream subtree merge, the sdhi compatible string
used in the device tree for RZ/G2L family SoCs is "renesas,rzg2l-sdhi"
not "renesas,rcar-gen3-sdhi". This broke the ability to access the eMMC
and SD card devices on RZ/G2L boards.
Fix this by adding the new compatible string to the sdhi driver.
Fixes: 136b7b6d2e98 ("Subtree merge tag 'v6.11-dts' of dts repo [1] into dts/upstream") Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Marek Vasut [Sun, 27 Oct 2024 02:04:31 +0000 (03:04 +0100)]
ARM: renesas: Drop old unused power DT headers
Renesas R-Car systems use mainline Linux DTs for U-Boot via OF_UPSTREAM,
which also includes headers from dts/upstream/include/dt-bindings/power .
Remove unused legacy DT header files from include/dt-bindings/power .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Marek Vasut [Sun, 27 Oct 2024 02:04:30 +0000 (03:04 +0100)]
ARM: renesas: Drop old unused clock DT headers
Renesas R-Car systems use mainline Linux DTs for U-Boot via OF_UPSTREAM,
which also includes headers from dts/upstream/include/dt-bindings/clock .
Remove unused legacy DT header files from include/dt-bindings/clock .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Mayuresh Chitale [Fri, 23 Aug 2024 09:41:25 +0000 (09:41 +0000)]
riscv: Add support for defining instructions
Add insn-def.h which is similar to that in linux and contains the macros
to generate any instruction of type 'I' using the assembler's .insn
directive.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
E Shattow [Sat, 26 Oct 2024 12:40:15 +0000 (05:40 -0700)]
riscv64: dts: starfive: Mars ethernet0 phy delay values sync with upstream Linux
Milk-V Mars vendor board support package has value 0xa (multiplier=150) for both
rx and tx delay. Upstream Linux has this as 1500 for both rx and tx delay. There
is no documentation for why this should remain 1900 so correct it now. Mars CM
and Mars CM Lite follow the same network phy delay values as Mars in the vendor
board support package.
Fixes: 92db23f7660de5897c8e3b91489b5b5780ffcd16 Signed-off-by: E Shattow <e@freeshell.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This patch series enables full RVVM virtual machine support which was
earlier inconveniently provided as out-of-tree patchset.
This should be cleaner than a separate board config, since both
emulators provide similar feature set. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Enable framebuffer for better virtual machine integration.
Some guests need EFI FB to work properly. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
QEMU supports NVMe devices, but U-Boot only tries to boot from Virtio.
This is problematic when explicitly using NVMe, so fix that.
Additionally, RVVM virtual machine is almost fully compatible with QEMU,
except it only implements NVMe drives instead of VirtIO. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Andrew Goodbody [Fri, 25 Oct 2024 17:07:00 +0000 (18:07 +0100)]
x86: Missed removal of CMD_BOOTEFI_HELLO_COMPILE
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the usage in this Makefile was not
updated. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Andrew Goodbody [Fri, 25 Oct 2024 16:47:32 +0000 (17:47 +0100)]
test: efi_loader: Fix dependency for http test
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the dependency for
test_efi_helloworld_net_http was not updated and so is now incorrect
preventing the test from ever running. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tom Rini [Sun, 27 Oct 2024 23:14:22 +0000 (17:14 -0600)]
Merge patch series "Implement ACPI on aarch64"
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Patrick Rudolph [Wed, 23 Oct 2024 13:20:19 +0000 (15:20 +0200)]
configs: Add RPI4 ACPI defconfig
Allows to build the RPi4 with ACPI enabled.
TEST: - Boots on qemu-system-aarch64 -machine raspi4b
- Boots on real hardware with arm_64bit=1 in config.txt
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:17 +0000 (15:20 +0200)]
arm: mach-bcm283x: Enable ARMV8_MULTIENTRY
On FDT platforms the APs are brought out of reset using the spin-table
as defined in the DT. On ACPI enabled platforms there's no FDT, thus
enable the ARMV8_MULTIENTRY and BLOBLIST to use the ACPI parking
protocol instead.
TEST: - APs enter Linux when run on qemu-system-aarch64 -machine raspi4b
- APs on real hardware do not enter Linux, but continue spinning in
their ACPI parking protocol spinloop. To be investigated.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:16 +0000 (15:20 +0200)]
arm: mach-bcm283x: Add ARMV8_MULTIENTRY support
When ACPI is enabled over FDT the APs cannot be brought out of reset
by the OS using the "FDT spin-table" mechanism, as no FDT is provided
to the OS. The APs must be released out of reset in u-boot and then
brought up in an ACPI compliant fashion.
When ARMV8_MULTIENTRY is specified, the APs are released from reset
and will enter U-Boot after it has been relocated as well.
By default ARMV8_MULTIENTRY is not selected, keeping existing behaviour.
TEST: All APs enter U-Boot when run on qemu-system-aarch64 and on
real hardware.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:14 +0000 (15:20 +0200)]
armv8: cpu: Enable ACPI parking protocol
Update the generic entry point code to support the ACPI parking protocol.
The ACPI parking protocol can be used when PSCI is not available to bring
up secondary CPU cores.
When enabled secondary CPUs will enter U-Boot proper and spin in their own
4KiB reserved memory page, which also acts as mailbox with the OS to
release the CPU.
TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:13 +0000 (15:20 +0200)]
arm: cpu: Add ACPI parking protocol support
On Arm platforms that use ACPI they cannot rely on the "spin-table"
CPU bringup usually defined in the FDT. Thus implement the
'ACPI Multi-processor Startup for ARM Platforms', also referred to as
'ACPI parking protocol'.
The ACPI parking protocol works similar to the spin-table mechanism, but
the specification also covers lots of shortcomings of the spin-table
implementations.
Every CPU defined in the ACPI MADT table has it's own 4K page where the
spinloop code and the OS mailbox resides. When selected the U-Boot board
code must make sure that the secondary CPUs enter u-boot after relocation
as well, so that they can enter the spinloop code residing in the ACPI
parking protocol pages.
The OS will then write to the mailbox and generate an IPI to release the
CPUs from the spinloop code.
For now it's only implemented on ARMv8, but can easily be extended to
other platforms, like ARMv7.
TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 23 Oct 2024 13:20:12 +0000 (15:20 +0200)]
board: raspberrypi: Add ASL files from tianocore
Add the necessary DSDT files copied from tianocore to boot the RPi4.
In addition generate a board specific SSDT to dynamically enable/disable
ACPI devices based on FDT. This is required to support the various variants
and boot options. It also allows to test the code on QEMU 9.0 without
modifications, since it doesn't emulate PCIe yet.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:11 +0000 (15:20 +0200)]
arm: bcm283x: Generate ACPI tables
Generate SoC specific ACPI tables for BCM2711:
- FADT
- PPTT
- GTDT
Board specific tables like DSDT and SSDT are added in a separate patch.
MADT is already properly generated from the FDT.
When ACPI is enabled for a different SoC compliation will fail by
design, indicating the required functions that needs to be implemented.
When ACPI is not enabled the added code does nothing, keeping existing
behaviour.
TEST: Booted on RPi4 with only ACPI enabled, providing no FDT to the OS.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 23 Oct 2024 13:20:10 +0000 (15:20 +0200)]
arm: mach-bcm283x: Bring in some header files from tianocore
These header files presumably duplicate things already in the U-Boot
devicetree. For now, bring them in to get the ASL code and ACPI table
code to compile.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:09 +0000 (15:20 +0200)]
arm: mach-bcm283x: Map the ARM local MMIO as well
Cover the "ARM local MMIO" range as well in the default MMU mapping in
order to allow future code to access the GIC-400 without crashing. For
now the GIC is not touched in u-boot, thus this change is a noop.
See [1](BCM2711 ARM Peripherals) for reference.
TEST: Enabled CONFIG_GICV2 and accessed the GIC in C code without crash.
Patrick Rudolph [Wed, 23 Oct 2024 13:20:08 +0000 (15:20 +0200)]
board: emulation: Add QEMU sbsa support
Add support for Arm sbsa [1] v0.3+ that is supported by QEMU [2].
Unlike other Arm based platforms the machine only provides a minimal
FDT that contains number of CPUs, ammount of memory and machine-version.
The boot firmware has to provide ACPI tables to the OS.
Due to this design a full DTB is added here as well that allows U-Boot's
driver to properly function. The DTB is appended at the end of the U-Boot
image and will be merged with the QEMU provided DTB.
In addition provide documentation how to use, enable binman to fabricate both
ROMs that are required to boot and add ACPI tables to make it full compatible
to the EDK2 reference implementation.
The board was tested using Fedora 40 Aarch64 Workstation. It's able
to boot from USB and AHCI or network.
Tested and found working:
- serial
- PCI
- xHCI
- Bochs display
- AHCI
- network using e1000e
- CPU init
- Booting Fedora 40
1: Server Base System Architecture (SBSA)
2: https://www.qemu.org/docs/master/system/arm/sbsa.html
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:06 +0000 (15:20 +0200)]
drivers/arm: Implement acpi_fill_madt
Fill the MADT table in the GIC driver and armv8 CPU driver to
drop SoC specific code. While the GIC only needs devicetree
data, the CPU driver needs additional information stored in
the cpu_plat struct.
While on it update the only board making use of the existing
drivers and writing ACPI MADT in mainboard code.
TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT.
Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org>
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.
The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().
TEST: Read the interrupts from the GIC node for ACPI MADT generation.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Moritz Fischer <moritzf@google.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:04 +0000 (15:20 +0200)]
arm: lib: Add GICV2 driver
Add a generic GICV2 driver that:
- parses the DT and generates the ACPI MADT subtables
- implement of_xlate() and allows irq_get_by_index() to return the
correct interrupt mappings
Map DT interrupts to ARM GIC interrupts as follows:
- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs
TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:01 +0000 (15:20 +0200)]
drivers/cpu: Add generic armv8 cpu driver
Add a generic driver that binds to armv8 CPU nodes. The generic driver allows
- to enumerate CPUs present in a system, even when no other driver binds it
- generates ACPI SSDT code for each CPU
- Fill the ACPI MADT table (implemented in a follow up patch)
The newly introduced code could also be reused on other CPU drivers that are
compatible with armv8.
TEST: Booted on QEMU sbsa and verify the driver binds to CPU nodes.
Confirmed with FWTS that all ACPI processor devices are present.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:00 +0000 (15:20 +0200)]
drivers: ata: Rename ahci_mvebu
Rename 'ahci_mvebu' to 'ahci_generic' and select it by default.
The AHCI driver contains no SoC specific code and only expects the
base address to be passed, thus rename it to ahci_generic and add the
DT compatible string "generic-ahci".
Update existing defconfigs to use the new Kconfig name as well.
TEST: Booted on QEMU sbsa using the generic-ahci node.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Stefan Roese <sr@denx.de> Acked-by: Tony Dinh <mibodhi@gmail.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:59 +0000 (15:19 +0200)]
drivers: usb: Add generic XHCI
Add support for the generic XHCI driver that contains no SoC
specific code. It can be used on platforms that simply work out
of the box, like on emulated platforms.
TEST: Booted on QEMU sbsa machine using the generic xhci driver.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Marek Vasut <marex@denx.de>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:57 +0000 (15:19 +0200)]
acpi: Allocate and write ACPI tables
Allocate memory for ACPI tables in generic acpi code. When ACPI wasn't
installed in other places, install the ACPI table using BLOBLISTs.
This allows non x86 platforms to boot using ACPI only in case the
EFI loader is being used, since EFI is necessary to advertise the location
of the ACPI tables in memory.
TEST: Booted QEMU SBSA (no QFW) using EFI and ACPI only.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:56 +0000 (15:19 +0200)]
acpi_table: Support platforms with unusable RSDT
Since ACPI 2.0 the RSDT is deprecated and the XSDT should be preferred.
Until now the RSDT and XSDT entries were keept in sync as all platforms
that installed ACPI tables placed them below 4GiB and thus the address
would fit into the 32bit RSDT.
On platforms that do not have usable DRAM below 4GiB, like QEMU sbsa,
the RSDT cannot be used. Allow both RSDT and XSDT to be null and only
fill those tables that are present in acpi_add_table().
TEST: Fixes a crash on QEMU sbsa and allows to boot on QEMU sbsa.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:52 +0000 (15:19 +0200)]
acpi: acpi_table: Bump revisions
The FADT structure found in U-Boot represents FADT revision 6 and the
GICC and GICD structures defined in U-Boot are based on ACPI revision
6.3.
Bump the table revision to fix FWTS failures seen on aarch64.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:49 +0000 (15:19 +0200)]
acpi: Add define for GTDT
Add the interrupt flag used in ACPI GTDT table as define.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Moritz Fischer <moritzf@google.com>
Maximilian Brune [Wed, 23 Oct 2024 13:19:48 +0000 (15:19 +0200)]
serial: serial_pl01x: Implement .getinfo() for PL01
When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Moritz Fischer <moritzf@google.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:19:46 +0000 (15:19 +0200)]
acpi: x86: Move MADT to common code
Write MADT in common code and let the SoC fill out the body by
calling acpi_fill_madt() which must be implemented at SoC level.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
Maximilian Brune [Wed, 23 Oct 2024 13:19:45 +0000 (15:19 +0200)]
acpi: x86: Write FADT in common code
Write the FADT in common code since it's used on all architectures.
Since the FADT is mandatory all SoCs or mainboards must implement the
introduced function acpi_fill_fadt() and properly update the FADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
Maximilian Brune [Wed, 23 Oct 2024 13:19:44 +0000 (15:19 +0200)]
acpi: x86: Move SPCR and DBG2 into common code
This moves the SPCR and DBG2 table generation into common code, so that
they can be used by architectures other than x86.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Sun, 27 Oct 2024 16:19:57 +0000 (10:19 -0600)]
Merge patch series "net: ksz9477: add support for KSZ GbE switches using SPI bus"
Romain Naour <romain.naour@smile.fr> says:
We are using a custom board where an ethernet switch device KSZ9896 is
available. This family of devices can use several types of serial bus
as management interface: mdio, i2c or SPI. Due to board design
constraints and because we initially planned to use this device only
from Linux, the SPI bus was used.
Luckily we are using a recent enough u-boot release where KSZ9477
driver is available... but only for the i2c interface. Indeed, unlike
the kernel driver, the KSZ9477 driver doesn't use the regmap API to
access the underlying bus since the regmap API is limited to direct
memory access [1].
Until regmap API with bus support is available in U-boot, we introduced
struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI).
This series has been tested on the current master branch (after v2024.10
release).
net: recv(): return -EAGAIN instead of 0 when no cleanup is expected
Some drivers do not behave properly when free_pkt() is called with a
length of zero. It is an issue I observed when developing the lwIP
series [1] (see "QEMU CI tests for r2dplus_i82557c, r2dplus_rtl8139"
in the change log) and which I fixed incorrectly by not calling
free_pkt() when recv() returns 0. That turned out to be wrong for two
reasons:
1. The DM documentation [2] clearly requires it:
"The **recv** function polls for availability of a new packet. [...]
If there is an error [...], return 0 if you require the packet to
be cleaned up normally, or a negative error code otherwise (cleanup
not necessary or already done).
If **free_pkt** is defined, U-Boot will call it after a received
packet has been processed [...]. free_pkt() will be called after
recv(), for the same packet [...]"
2. The imx8mp_evk platform will fail with OOM errors if free_pkt() is
not called after recv() returns 0:
u-boot=> tftp 192.168.0.16:50M
Using ethernet@30be0000 device
TFTP from server 192.168.0.16; our IP address is 192.168.0.48
Filename '50M'.
Load address: 0x40480000
Loading: #######################fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
...
Therefore, make recv() return -EAGAIN instead of 0 when no packet is
available and the driver doesn't expect free_pkt() to be called
subsequently.
Romain Naour [Tue, 8 Oct 2024 07:54:29 +0000 (09:54 +0200)]
net: ksz9477: store ksz bus operations functions
The ksz9477 Linux kernel driver is based on regmap API to seamlessly
communicate to switch devices connected via different buses like SPI
or I2C. The current regmap implementation in U-Boot only supports
memory-mapped registers access [1].
Until regmap API with bus support is available in U-boot, introduce
struct ksz_phy_ops to store low-level ksz bus operations (I2C for now).
Romain Naour [Tue, 8 Oct 2024 07:54:28 +0000 (09:54 +0200)]
net: ksz9477: set i2c bus offset length only when needed
In order to add ksz9477 SPI bus support, check parent bus
is an I2C bus before calling i2c_set_offset_len().
Doing so, ksz_i2c_probe() will now return an error (-EINVAL) if
the parent bus is not the one expected by the ksz-switch u-boot
driver.
Indeed, the DSA KSZ devicetree binding doesn't specify anything
about the underlying bus between the SoC and the DSA switch, so
the same "compatible" string can be used wathever the management
interface used (SPI or I2C).
The ksz-switch u-boot driver currently only support I2C interface
but will match a compatible "microchip,ksz9xxx" located under
under an SPI bus node.
Romain Naour [Tue, 8 Oct 2024 07:54:27 +0000 (09:54 +0200)]
net: ksz9477: rename udevice_id tab to ksz_ids
The DSA KSZ devicetree binding doesn't specify anything about the
underlying bus between the SoC and the DSA switch, so the same
"compatible" string can be used wathever the management interface
used. The driver must be able to access the underlying bus without
any help from the compatible string (like for TPM2 TIS devices).
So, rename udevice_id tab to ksz_ids since it's not specific to i2c
bus.
Romain Naour [Tue, 8 Oct 2024 07:54:25 +0000 (09:54 +0200)]
net: ksz9477: remove dev_set_parent_priv() call
The ksz9477 is currently the only driver using dev_set_parent_priv()
outside of the driver model. Also, there was no explanation in the
commit adding ksz9477 driver and why dev_set_parent_priv() is
required.
Actually there is a typo in ksz_mdio_probe() while retrieving
the parent (switch@0) private data:
Printing the address of struct ksz_dsa_priv *priv allows
to notice the slight difference:
ksz_i2c_probe: ksz_dsa_priv *priv 0xfdf45768 // address of the saved priv
ksz_mdio_bind: ksz_dsa_priv *priv 0xfdf45798 // address returned by dev_get_parent_priv(dev->parent)
ksz_mdio_bind: ksz_dsa_priv *priv 0xfdf45768 // address returned by dev_get_priv(dev->parent)
The ksz_mdio driver get the wrong data and without
dev_set_parent_priv() the mdio driver fail to access the underlying
bus.
While it doesn't cause any issue with I2C bus, it override the
per-child data used by the SPI bus (struct spi_slave) and prevent
further bus access (even with sspi command).
Hanyuan Zhao [Fri, 9 Aug 2024 08:57:01 +0000 (16:57 +0800)]
net: dc2114x: remove the pass all multicast flag in operation mode settings
Remove the OMR_PM flag and choose 16 perfect filtering mode since in
modern networks there're plenty of multicasts and set ORM_PM flag will
increase the dc2114x's workload and ask the U-Boot to handle packets
not related to itself. And most of the time, U-Boot does not need this
feature.
Hanyuan Zhao [Fri, 9 Aug 2024 08:57:00 +0000 (16:57 +0800)]
net: dc2114x: allow users to decide how to tx packets according to IP core
Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. Originally this
driver uses only one tx descriptor and organizes it as a ring buffer,
which would lead to a problem that one packet would be sent twice.
This commit adds support to prevent this bug if you are using IP
cores with this issue, by using multiple tx descriptors and
organizing them as a real well-defined ring buffer.
Hanyuan Zhao [Fri, 9 Aug 2024 08:56:59 +0000 (16:56 +0800)]
net: dc2114x: allow users to decide whether to detect the tx No Carrier errors
Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. A packet could be
sent successfully but reported with No Carrier error. Latest drivers
of this IP core have not detect this error anymore.
projects / u-boot.git / log