Currently, Esspresobin switch is being setup directly in last_stage_init()
which makes it hard to add support for any other board to be setup.
So, lets just move the switch setup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
which makes it hard to add support for any other board to be fixed up.
So, lets just move the FDT fixup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
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>
* 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmWdDaQACgkQhO4vgnE3
U0taKhAApj9/lSw6naB4L+/1x+caPIsrwmkp8muBiKlF3u9wXv7PoP+cpLe1+upE
RlxiWtmN7nlBJqr7wdKQUGzL16zNQY4yWQbZz47tVUtcJ/l9feF2otcAI8OTcJz+
GA9FR0dXWWFFrfIfCbJ/AyOA71KnzYS9Z9k95ek0ONpXC8uSMgdUn/tL4TO2ccBU
Uz9EO2fjYTBTUu2dY+iOoc8Pfi3FVk7KiASIijSgs4lkNqx/xgOXf5cP+LjvUOkV
N7hFtaIblewjPm6JzEhHRB/YaoTObolQw30HQQroz5vHhYhkmpEU15e4BhSPhsud
ZQ8TZr9rm6nPrkeOaDSdbF7gBKE1IrMHKZnQStDq+40ADX5TOTlKvNMiVQhpt7Mg
BIBbYG/k1SQQarSaZWaMlWVzZuAoN8dMS/NZXH2UUkS/OxxBAyR8bTxLapJIwZGP
OrBCzR9AZzubXBpI2CzE3k1b5UyTVEBFkzDC6BXg+FbgDzaqWUPOW00kQhn1zpMM
xajk1kXnedlhVQxtAquvwvdKS8OT5JGYRC+Obmfs8YZKp7F8Aw00C3Ex1Qvp4K6x
45bxWBFboGLdPuZsZ/Vpsuvh4G5DLHoekHkFGOlbLHICq1WYXjnsgpLYtm9g5Ret
y9WpUryayjjS0pGrQ6OAgr59+LODYic3rRYI595CtxDKNu4DkZ8=
=oHtG
-----END PGP SIGNATURE-----
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
Use counterpart dev_read_* functions instead of fdt* ones. It fixes
checkpatch warnings like this:
WARNING: Use the livetree API (dev_read_...)
#54: FILE: drivers/pinctrl/exynos/pinctrl-exynos.c:137:
pinvals[idx] = fdtdec_get_int(fdt, node,
and also makes it possible to avoid using the global data pointer in the
driver.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Pull some variables declared in exynos_pinctrl_set_state() into its
loop, to reduce their scope. Style commit, no functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
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>
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>
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>
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>
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmWc8AgACgkQhO4vgnE3
U0u/fxAAqkb7en80XhWHM3iKn6R81JuixxD33FkPPfD7+EDTkkBr/2ylEENNNzSl
nSI+LIPQ7/Isew/L/wlylg9+db76nZ1QC49avIIF/Q1Gl4yjOzi88nLT9cn4wZhT
HhdbW19XB68APmkJJ5f9jwG+Oli7GZdtZQHtkVKJeBD90pBaH1pOW3sRki4nxmAO
3qWpdwQWAi0S2itPyDXIA/FcxIQqK2ateoBGqNoiwNkTwEyJIh74M7y3nm5UW7xC
hmUful9qiiI6Xu/GUZ/RNpMbjevEO0buQNB43RVrR4SpkkU3cwgx5zJBF9Z+/Hiv
tHGUlbrPUnMp+I8gDp7VaaKELIY6FVJREzb8GQxb3yj6+wI+b3v/AyOsV4yy86eI
5KX6p1UBJ0RJxB6D9A54F1nVwNXiu8ujRk6zcfBtupKMV8Srxl8tF0OoZSbULb30
CpaoPjWnW2itSvK4+2zFZYsIIWZpkqK3cuHDxmrrQomOynB6VkKDToXmwLkp1uUA
kKWh+gqrJkZn3omiDfTNpQwiHRPuOXy0zB2KLPXmGDEDhKSZs9VVvQTzfaXcpKNp
YFPGG62Bk/h/cJUF4wOawB4ufEvDoG3qMyJUBY8AJNCH7KeMDV3VeWXx1ABUgruw
2WzfjcM1FgxdUyr5Qrj1cP/bBKuwu0TJpy66pEaoQ4w68csDFtE=
=5m7m
-----END PGP SIGNATURE-----
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.
An EFI binary smbiosdump.efi is provided that can be used to check the
SMBIOS table for consistency and to dump it as a file.
The tool provides the following commands:
check
Check the SMBIOS table for consistency.
exit
Leave the tool.
help
Show available commands.
save
Save the SMBIOS table to a file on the EFI system partition. The file
can be further analyzed with the dmidecode command line tool::
dmidecode --from-dump <filename>
Specifying 'nocolor' as load option data suppresses colored output and
clearing of the screen.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The smbios.h include does not use any definitions from ofnode.h.
So don't include it.
As DECLARE_GLOBAL_DATA_PTR is no longer defined via dm/of.h we need to
add it to efi_smbios.c.
Add now missing includes to smbios-parser.c.
Remove a superfluous check comparing the sizes of the SMBIOS 2.1 and SMBIOS
3.0 anchors.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
The function verify_checksum() duplicates what table_compute_checksum()
does. Replace it. table_compute_checksum() is always compiled.
Fixes: 415eab0655 ("smbios: add parsing API")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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: ceec977ba1 ("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: 31565bb0aa ("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>
- 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
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.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
Add dedicated Makefile targets for the i.MX93 and a new imx93-u-boot.dtsi
device-tree to create binman images.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
This is extending commit 6516c9b349 ("spl: binman: Disable u_boot_any
symbols for i.MX8M boards") to i.MX93 boards.
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
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>
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>
allow devicetree from bloblist
ACPI support for ARM and RISC-V
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmWbPygRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIrebFRQf+MS1t+wtPFz9Y8i7zBrEV1+fpPOp8XhJ5
m7uCkCDYO1oYShI1ht6X1nzvprElk/J9ZWTUg2IXOFzSaaBiPrylcc5bDjkd2F7A
FxqXn2oqKPIXYoZsJgVS2ua5m5pQbZk9ahX5NWzQV8xLMNjgK6BvCUX3zQsLtS1C
jo3ly+G+FlnFZ187qqxzIQiVkRX6p/U+JLERsgfy9q0Fic5drBydQ3F8UjMdORq2
NxxxjOl76vC+9O2A+XXC2c/1EiXR/DK2Mtz+lxA/d5/ZDrepp1bnJUjdV5qD4LdX
+ZuwJBdctrlK0piOIJuAR7YjpNfxeUJl6L9l/3Hg2X3P8U84V0zqiA==
=AD87
-----END PGP SIGNATURE-----
Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
switch to SMBIOS3 tables
allow devicetree from bloblist
ACPI support for ARM and RISC-V
Enable the QEMU firmware interface if ACPI tables are to be supported on
the QEMU platform.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Provide a configuration fragment to enable ACPI on QEMU.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Select CONFIG_SUPPORT_ACPI to allow usage of ACPI tables with RISC-V.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable the QEMU firmware interface if ACPI tables are to be supported on
the QEMU platform.
Enable the QFW MMIO interface if the QEMU firmware interface is enabled.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86.
X86 calls write_acpi_tables() in write_tables().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Add fields for the location of ACPI tables to the global data.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the code related to copying tables from QEMU to a separate code
module.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
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>
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>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Use the word 'acpi' in this test so that it runs along with all the
other ACPI tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Only the v3 table is supported now, so always use this when installing
the EFI table.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
These tables are a pain since there is no way to handle memory above
4GB. Use SMBIOS3 always.
This should hopefully not create problems on x86 devices, since SMBIOS3
was released seven years ago (2015).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
