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>
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.
Hanyuan Zhao [Fri, 9 Aug 2024 08:56:58 +0000 (16:56 +0800)]
net: dc2114x: remove unused lines and change the var and print types
This commit fixes a problem that even though the network card does not report
any issues in transmitting a setup frame, the driver prints the error status
every time. Let's set it for debug use.
Hanyuan Zhao [Fri, 9 Aug 2024 08:56:57 +0000 (16:56 +0800)]
net: dc2114x: add support for CPUs that have cache between the memory and the card
This commit adds support for the MIPS and LoongArch CPUs, which would use cache
after they jump into U-Boot. This commit requests the CPU to return the
addresses in uncached windows and flushes the cache in need, to make sure the
memory between the CPU and the network card is in consistency.
Hanyuan Zhao [Fri, 9 Aug 2024 08:56:54 +0000 (16:56 +0800)]
net: dc2114x: add support for platforms that don't have pci controllers
There're a few ethernet IP cores which have the same functions with dc2114x,
and can be connected to CPU by AXI or other buses. This commit adds support
for the platforms that do not have PCI controllers, using MMIO to communicate
with the dc2114x IP core.
- New boards:
rk3566: Hardkernel ODROID-M1S
rk3588s: Hardkernel ODROID-M2
rk3588: NanoPC-T6 LTS
- Migrate to use USB_DWC3_GENERIC for rk3328
- Other board level config and dts update
Jonas Karlman [Thu, 17 Oct 2024 20:00:27 +0000 (20:00 +0000)]
rockchip: rk3588-nanopc-t6: Add support for NanoPC-T6 LTS
Update defconfig to enable features included in pending upstream DT and
implement board_fit_config_name_match() to load correct DT for LTS and
non-LTS version of the NanoPC-T6.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 7588da65fdf09c7de9f903780c212a8ae96f2866) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In the LTS (2310) version the miniPCIe slot got removed and USB 2.0
setup has changed. There are two external accessible ports and two ports
on the internal header.
There is an on-board USB hub which provides:
- one external connector (bottom one)
- two internal ports on pin header
- one port for m.2 E connector
The top USB 2.0 connector comes directly from the SoC.
(cherry picked from commit f4a834fbc8cdb40fddd63d083e8d1c6189ba62dc) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 697963b1c22336a44ac2e33536c652aae1671b3d) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Alex Shumsky [Wed, 16 Oct 2024 10:02:03 +0000 (13:02 +0300)]
rockchip: board: Increase rng-seed size to make it sufficient for modern Linux
Increase rng-seed size to make Linux happy and initialize rng pool instantly.
Linux 5.19+ requires 32 bytes of entropy to initialize random pool, but u-boot
currently provides only 8 bytes.
Linux 5.18 and probably some versions before it used to require 64 bytes.
Bump min value to 64 bytes to be on a safe side.
Linux source references:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.19#n551
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.18#n236
Signed-off-by: Alex Shumsky <alexthreed@gmail.com> Fixes: d2048bafae40 ("rockchip: board: Add board_rng_seed() for all Rockchip devices") Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
- Remove unneeded USB board code and fix reset on mx6ul_14x14_evk.
- Update fastboot buffer size/address for verdin-imx8m{m|p}.
- Fix imxrt1050-evk boot and convert it to standard boot.
- Fix imx8qxp-mek and imx8qm-mek boot.
- Add support for the i.MX93 9X9 QSB board.
- Make livetree API to work on i.MX.
- Set sane default value for i.MX8M SPL_LOAD_FIT_ADDRESS.
- Deduplicate DH i.MX8MP/i.MX6 DHSOM defconfigs.
- Select default TEXT_BASE for i.MX6/i.MX7.
- Several updates for DH i.MX8MP DRC02.
Marek Vasut [Sun, 20 Oct 2024 21:00:38 +0000 (23:00 +0200)]
ARM: imx: soc: Select default TEXT_BASE for i.MX6
Select default U-Boot and SPL text base for the i.MX6 SoC. The U-Boot
and SPL text base is picked as the one used by various i.MX6 boards.
Update all the boards.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Jesse Taube [Fri, 25 Oct 2024 02:02:26 +0000 (22:02 -0400)]
imx: imxrt1050-evk: Fix missing clocks for mmc
Two of the clocks required by the usdhc1 controller are missing from the
clock controller node. A recent change enables all the clocks in the
esdhc node, which fails as they are not defined in the clock controller.
Fixes: 76332fae769 ("mmc: fsl_esdhc_imx: Enable AHB/IPG clk with clk bulk API") Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> Cc: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Fri, 25 Oct 2024 22:55:06 +0000 (00:55 +0200)]
arm64: imx: Deduplicate DH i.MX6 DHSOM defconfig
Deduplicate defconfigs for all DH i.MX6 DHSOM by including common
configs/imx_dhsom_defconfig . This does introduce changes to the
board configuration, namely it enables commands used on all DHSOM
devices consistenty, the prompt is changed to u-boot=>, support for
booting non-Linux OS which was likely never used is disabled, GPT
partition table support is enabled, generic MTD support is enabled,
LED support is enabled, DM PHY, PMIC and regulator support is also
enabled, KASLR command is enabled.
Deduplicate defconfigs for all DH i.MX8MP DHSOM by factoring out the
common parts into generic _dhsom_defconfig and including those using
the #include <configs/...> preprocessor macro, which is applicable to
defconfigs as well. This enables CMD_EXPORTENV on all iMX8MP DHSOM
systems to be consistent with other DHSOM systems.
Marek Vasut [Fri, 25 Oct 2024 22:55:04 +0000 (00:55 +0200)]
arm64: imx: imx8mp: Disable PCA954x I2C mux on DH i.MX8MP DRC02 and PicoITX
Neither the DRC02 nor PicoITX carrier board contains the PCA954x I2C mux
chip, the chip is only present on PDK3 carrier board. Disable support for
the PCA954x mux chip and I2C mux altogether on both i.MX8MP DHCOM DRC02 and
PicoITX.
projects / u-boot.git / log