Maxim Uvarov [Tue, 26 Dec 2023 15:46:15 +0000 (21:46 +0600)]
driver/net/rtl8139: remove debug print
debug print delays reset of the driver. Finally I see
bunch of "rx error FFFF" errors in the screen. CI can
not handle many prints. While network works fine there
Michal Simek [Wed, 10 Jan 2024 12:34:20 +0000 (13:34 +0100)]
arm64: zynqmp: Remove ltc2954 node
Remove already disabled node. GPIO connections are handled by pmufw that's
why there is no reason to have it described for non secure firmware.
If someone wants to handle it from OS revert this patch and also update
PMUFW configuration and pinctrl setting for these GPIO pins.
Robert Marko [Wed, 29 Nov 2023 10:11:08 +0000 (11:11 +0100)]
arm: mvebu: eDPU: support new board revision
There is a new eDPU revision that uses Marvell 88E6361 switch onboard.
We can rely on detecting the switch to enable and fixup the Linux DTS
so a single DTS can be used.
There is currently no support for the 88E6361 switch and thus no working
networking in U-Boot, so we disable both ports.
Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Fri, 27 Oct 2023 00:44:11 +0000 (13:44 +1300)]
arm: mvebu: AC5: Use finer grained memory map
The ATF implementation for AC5/AC5X ends up with bl31 living in some
internal SRAM. This is in the middle of the large MMIO region that we
were using. Adjust this to be finer grained blocks based on the address
map from the AC5X Family Control and Management Subsystem Functional
Datasheet.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Brandon Maier [Thu, 4 Jan 2024 18:50:07 +0000 (18:50 +0000)]
tools: zynqmpimage: print all partition sizes
Two of the partition size fields are not printed. Currently only the
"total" size is displayed, which is the size of the image data
(encrypted), padding, expansion, and authentication data. Add the
"unencrypted data" size, which is the original size of the data before
being encrypted. And "encrypted data" size, which is just the encrypted
data.
To avoid printing useless information, only print the encrypted and
unencrypted sizes if they are different from the total.
Brandon Maier [Thu, 4 Jan 2024 18:50:06 +0000 (18:50 +0000)]
tools: zynqmpimage: show info on partition 0
The zynqmpimage_print_header() skips printing the first partition. This
is because the image header can contain duplicate fields as the first
partition. However some fields, like the partition attributes, are only
present in the partition table. It is also possible for the first
partition to not be declared in the image header, if the image is not a
bootloader image.
Michal Simek [Thu, 4 Jan 2024 10:28:35 +0000 (11:28 +0100)]
arm64: zynqmp: Match dwc3 interrupts description with values
Correct IRQ values don't match IRQ line description.
There is one more IRQ (hiber) but it is not described in DT binding spec
that's why value is not described. Just for completeness dwc3_0 has hiber
IRQ at 75 and dwc3_1 at 76.
Michal Simek [Fri, 5 Jan 2024 09:55:51 +0000 (10:55 +0100)]
arm64: zynqmp: Add support for new power-management node name
zynqmp-power node is going to be renamed to power-management which should
be generic enough. New name came from dt-binding review that's why there is
no way around. Add support new name but also at the same time check old
name just in case older dt binding is used.
Tom Rini [Tue, 9 Jan 2024 17:50:04 +0000 (12:50 -0500)]
Merge tag 'smbios-2024-04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request smbios-2024-04-rc1
* make table_compute_checksum() arguments const
* remove duplicate function verify_checksum()
* enable setting processor family > 0xff
* set correct SMBIOS processor family value for RISC-V
* avoid importing ofnode.h in smbios.h
* provide a UEFI tool to dump SMBIOS table
Sam Protsenko [Thu, 30 Nov 2023 20:13:50 +0000 (14:13 -0600)]
pinctrl: exynos: Refactor handling the pin related dt properties
All pin related dt properties (pin-function, pin-pud and pin-drv) are
handled in a very similar way. Get rid of that code duplication by
extracting the corresponding data knowledge into an actual data
structure (array), and then just iterating over it.
No functional change, it's a refactoring commit.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Thu, 30 Nov 2023 20:13:49 +0000 (14:13 -0600)]
pinctrl: exynos: Support different register types in pin banks
Get rid of hard-coded register offsets and widths. Instead provide a way
for pinctrl drivers to specify different pin bank register offsets and
widths. This in turn makes it possible to add support for new SoCs that
have registers with offset/width values different than generic ones
already available in pinctrl-exynos driver.
Offset constants (now unused in pinctrl-exynos.c) are moved to
pinctrl-exynos7420 driver, which is the single user of those constants.
The design of this patch follows Linux kernel pinctrl-exynos driver
design, in terms of added data structures and types. This patch doesn't
add support for any new SoCs and shouldn't introduce any functional
changes.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Thu, 30 Nov 2023 20:13:48 +0000 (14:13 -0600)]
pinctrl: exynos: Rework pin_to_bank_base() to obtain data by name
Rework pin_to_bank_base() function to obtain bank data structure by bank
name instead of getting bank base address by pin name, and rename it to
get_bank() to reflect this change. This in turn leads to the extraction
of parse_pin(), so the caller has to use it before calling get_bank().
No functional change. This is a refactoring commit which prepares
pinctrl driver code for handling different sizes of register fields,
which will be added next.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Thu, 30 Nov 2023 20:13:47 +0000 (14:13 -0600)]
pinctrl: exynos: Extract pin parsing code into a separate function
Next commits are going to re-design the pin_to_bank_base() function and
its usage in a way that the pin parsing code will be called separately.
Extract it into a separate function first, as a refactoring commit.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Ion Agorria [Fri, 5 Jan 2024 07:22:12 +0000 (09:22 +0200)]
test: hush: dollar: fix bugous behavior
The dollar test was merged with bugous console behavior, and
instead of fixing it, this behavior was just workarounded.
It seems like without the fix the ut_assert_skipline(); didn't clear
console and running ut_assert_skipline(); many times would give always
OK. With
lib: membuff: fix readline not returning line in case of overflow
the line is cleared correctly and next assert fails because now there
is nothing to clean which is correct if we look the this a bit above
the failing assert:
if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
/*
* For some strange reasons, the console is not empty after
* running above command.
* So, we reset it to not have side effects for other tests.
*/
console_record_reset_enable();
} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
ut_assert_console_end();
}
Which further confirms that tests workaround the old problem and now
that problem is fixed we can remove the whole if blocks and simply
place ut_assert_console_end() right after ut_assert_skipline() without
any conditional and will pass green.
So this part of code goes from:
ut_assert_skipline();
ut_assert_skipline();
if (gd->flags & GD_FLG_HUSH_MODERN_PARSER) {
/* See above comments. */
console_record_reset_enable();
} else if (gd->flags & GD_FLG_HUSH_OLD_PARSER) {
ut_assert_console_end();
}
to become:
ut_assert_skipline();
ut_assert_console_end();
Same thing should be done with the if block mentioned above that calls
console_record_reset_enable().
Tom Rini [Tue, 9 Jan 2024 14:00:39 +0000 (09:00 -0500)]
Merge tag 'rng-2024-04-rc1' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request rng-2024-04-rc1
QEMU does not provide information in the device-tree if the ARMv8.5 RNDR
or the RISC-V Zkr RNG have been enabled on the command line.
In different parts of our code we assume that the first RNG device is the
one to be used. Therefore it is preferable to detect the availability of
said devices already in the bind method.
There has been a related discussion if the U_BOOT_DRVINFO() macro should be
used for architectural devices
(https://lore.kernel.org/u-boot/20231031125552.26698-1-heinrich.schuchardt@canonical.com/).
This aspect is not touched by this series.
Ion Agorria [Fri, 5 Jan 2024 07:22:09 +0000 (09:22 +0200)]
common: console: record console from the beginning
Set flag to enable console record on console_record_init
and not only on console_record_reset_enable. This fixes
missing start of U-Boot log for fastboot oem console
command.
Ion Agorria [Fri, 5 Jan 2024 07:22:07 +0000 (09:22 +0200)]
fastboot: implement "getvar all"
This commit implements "fastboot getvar all" listing
by iterating the existing dispatchers that don't require
parameters (as we pass NULL), uses fastboot multiresponse.
Ion Agorria [Fri, 5 Jan 2024 07:22:06 +0000 (09:22 +0200)]
fastboot: multiresponse support
Currently u-boot fastboot can only send one message back to host,
so if there is a need to print more than one line messages must be
kept sending until all the required data is obtained. This behavior
can be adjusted using multiresponce ability (getting multiple lines
of response) proposed in this patch.
Tejas Bhumkar [Thu, 4 Jan 2024 04:52:17 +0000 (10:22 +0530)]
xilinx: Enable the NFS command by default
Enabled the default utilization of the NFS command across all Xilinx
platforms to facilitate the booting of images through the network
using the NFS protocol.
Michal Simek [Tue, 19 Dec 2023 16:16:50 +0000 (17:16 +0100)]
arm64: zynqmp: Rename i2c?-gpio to i2c?-gpio-grp
Anything ending with gpio/gpios is taken as gpio phande/description which
is reported as the issue coming from gpio-consumer.yaml schema.
That's why rename the gpio suffix to gpio-grp to avoid name collision.
Michal Simek [Tue, 19 Dec 2023 16:16:47 +0000 (17:16 +0100)]
arm64: zynqmp: Move fixed clock to / for kv260
fixed clock nodes can't be on the bus because they are missing reg
property. That's why move them to root.
And because it is root it is good to have it as the first node in a file.
Michal Simek [Mon, 18 Dec 2023 13:41:39 +0000 (14:41 +0100)]
arm64: zynqmp: Generate dfu_alt_info based on multiboot register
Commit 2c8a09219cdb ("arm64: zynqmp: Add multiboot support for SPL/SPI
offset calculation") enabled u-boot.itb offset calculation based on
multiboot register. It is also good to reflect location of u-boot.itb image
for dfu_alt generation.
Michal Simek [Mon, 18 Dec 2023 13:08:36 +0000 (14:08 +0100)]
arm64: zynqmp: Fix i2c bus for kd240
i2c1 is having all chips on it that's why use it instead of 0.
You can see this error when you boot system.
eth0: ethernet@ff0c0000
Setting bus to 0
Failure changing bus number (-19)
Enable permission for node ID 33
Enable permission for node ID 47
Hit any key to stop autoboot: 0
cpu: riscv: set correct SMBIOS processor family value
The SMBIOS specification requires to set the processor family in the type 4
(Processor Information) table to specific values depending only on the
bitness of the system (0x200 for RV32 and 0x201 for RV64).
With this patch dmidecode shows
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: Not Specified
Type: Central Processor
Family: RV64
for qemu-riscv64_smode_defconfig.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Many value of processor type exceed 0xff and have to be stored as u16
value. In the type 4 table set processor_family = 0xfe signaling that
field processor_family2 is used and write the actual value into the
processor_family2 field.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
lib: make table_compute_checksum() arguments const
table_compute_checksum() does neither changes the content of the
checksummed buffer nor the buffer length. Adding const to the
definition makes the function wider usable.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The existence of devices should be checked in the bind method and not in
the probe method. Adjust the RISC-V Zkr RNG driver accordingly.
Use ENOENT (and not ENODEV) to signal that the device is not available.
Fixes: ceec977ba1a9 ("rng: Provide a RNG based on the RISC-V Zkr ISA extension") Reported-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In different parts of our code we assume that the first RNG device is the
one to be used. Therefore it is preferable to detect the availability of
the RNDR register already in the bind method.
For signaling the non-existence of a device the driver model requires using
ENOENT (and not ENODEV).
Fixes: 31565bb0aa2d ("driver: rng: Add DM_RNG interface for ARMv8.5 RNDR registers") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com>
Tom Rini [Mon, 8 Jan 2024 18:39:00 +0000 (13:39 -0500)]
Merge tag 'u-boot-imx-master-20240108' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
- Removed fdt_addr from verdin-imx8mm to fix booting via bootefi.
- Support Ethernet PHY autodection on Data Modul i.MX8M Mini/Plus eDM
SBC
- Add i.MX93 binman support
- Add support for imx93-var-som
Mathieu Othacehe [Fri, 29 Dec 2023 10:55:23 +0000 (11:55 +0100)]
Add imx93-var-som support
Add support for the Variscite VAR-SOM-IMX93 evaluation kit. The SoM
consists of an NXP iMX93 dual A55 CPU. The SoM is mounted on a Variscite
Symphony SBC.
fdt_addr variable is the location in flash of the device tree blob [1], it
does not exist for verdin-imx8mm.
Because of this the bootefi command fails unless the optional
`[fdt address]` parameter is passed on the command line,
bootefi.c:efi_install_fdt() assumes that `fdt_addr` is valid when
present.
Fix this removing fdt_addr from the U-Boot environment.
[1] doc/usage/environment.rst
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Marek Vasut [Mon, 1 Jan 2024 21:05:54 +0000 (22:05 +0100)]
ARM: imx: Auto-detect PHY on Data Modul i.MX8M Mini/Plus eDM SBC
Implement fdtdec_board_setup() auto-detection of ethernet PHY.
This uses properties of the hardware and pull resistor placement.
If GPIO1_16 RGMII_MDC is HIGH, then R530 (MX8MM eDM SBC) or
R390 (MX8MP eDM SBC) is populated. R530 or R390 is populated
only on boards with AR8031 PHY.
If GPIO1_16 RGMII_MDC is LOW, then the in-SoM pull down is the
dominant pull resistor. This is the case on boards with BCM54213PE
PHY.
In case AR8031 PHY is populated, the PHY MDIO address is 0, in
case BCM54213PE PHY is populated, the PHY MDIO address is 1, the
fdtdec_board_setup() is used to patch the correct address into
the U-Boot control DT.
Enable broadcom PHY support to support both PHYs.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Add fields for the location of ACPI tables to the global data.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We have two implementations of write_acpi_tables(). One for writing ACPI
tables based on ACPI_WRITER() entries another based on copying tables from
QEMU.
Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
QEMU and use it consistently.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
acpi: support 64bit in acpi_find_table for DSDT and FACS
Use X_DSDT and X_FIRMWARE_CTRL if available.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap: Signed-off-by: Simon Glass <sjg@chromium.org>
On non x86 platforms the hardware reduce flag must be set in the FADT
table. Write an error message if the flag is missing.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap, add hyphens: Signed-off-by: Simon Glass <sjg@chromium.org>
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If
field X_DSDT is filled, field DSDT must be ignored.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap: Signed-off-by: Simon Glass <sjg@chromium.org>
Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to
to uintptr_t to fill these.
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If
field X_DSDT is filled, field DSDT must be ignored. We should not fill
unused fields.
See the field definitions in chapter "5.2.9 Fixed ACPI Description Table
(FADT)" of the ACPI Specification 6.5.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 4 Jan 2024 01:49:19 +0000 (18:49 -0700)]
fdt: Allow the devicetree to come from a bloblist
Standard passage provides for a bloblist to be passed from one firmware
phase to the next. That can be used to pass the devicetree along as well.
Add an option to support this.
Tests for this will be added as part of the Universal Payload work.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sun, 31 Dec 2023 15:25:55 +0000 (08:25 -0700)]
efi: Correct smbios-table installation
At present this code allocates memory when writing the tables and
then unnecessarily adds another memory map when installing it.
Adjust the code to allocate the tables using the normal U-Boot
mechanism. This avoids doing an EFI memory allocation early in
U-Boot, which may use memory that would be overwritten by a
'load' command, for example.
Simon Glass [Sun, 31 Dec 2023 15:25:54 +0000 (08:25 -0700)]
acpi: Write pointers to tables instead of addresses
Sandbox uses an API to map between addresses and pointers. This allows
it to have (emulated) memory at zero and avoid arch-specific addressing
details. It also allows memory-mapped peripherals to work.
As an example, on many machines sandbox maps address 100 to pointer
value 10000000.
However this is not correct for ACPI, if sandbox starts another program
(e.g EFI app) and passes it the tables. That app has no knowledge of
sandbox's address mapping. So to make this work we want to store 10000000 as the value in the table.
Add two new 'nomap' functions which clearly make this exeption to how
sandbox works.
This should allow EFI apps to access ACPI tables with sandbox, e.g. for
testing purposes.
Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Simon Glass [Sun, 31 Dec 2023 15:25:49 +0000 (08:25 -0700)]
efi: Use the correct GUID for the SMBIOS table
EFI does not use the 'anchor string' to determine the SMBIOS table
version, instead preferring to have two separate GUIDs. Use the correct
one, depending on the table version.
Call unmap_system() to balance to the use of map_sysmem()
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Sun, 31 Dec 2023 15:25:47 +0000 (08:25 -0700)]
smbios: Use SMBIOS 3.0 to support an address above 4GB
When the SMBIOS table is written to an address above 4GB a 32-bit table
address is not large enough.
Use an SMBIOS3 table in that case.
Note that we cannot use efi_allocate_pages() since this function has
nothing to do with EFI. There is no equivalent function to allocate
memory below 4GB in U-Boot. One solution would be to create a separate
malloc() pool, or just always put the malloc() pool below 4GB.
- Use log_debug() for warning
- Rebase on Heinrich's smbios.h patch
- Set the checksum for SMBIOS3
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>