Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1

2024-01-01 Thread Jan Kiszka
On 27.12.23 13:39, Nishanth Menon wrote:
> On 15:00-20231221, Tom Rini wrote:
>> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote:
>>
>>> Hello Everyone!
>>>
>>> This series gets the am65x booting again along with syncing the device
>>> tree files with v6.7-rc1 Linux.
>>>
>>> The bulk of these patches unify the WKUP SPL board file with the arm64
>>> files to make future syncs from Linux much easier. In the end the DTBs
>>> should look a lot like what the DTBs look like for the am64x which
>>> is fairly similar to the am65x.
>>>
>>> For those interested in what UART boot looks like:
>>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc
>>>
>>> Thanks for reviewing and happy holidays
>>> ~Bryan
>>
>> For the series,
>> Tested-by: Tom Rini 
>>
>> Nishanth, does this path work for you?
>>
> 
> Other than the minor comments provided in the relevant patches,
> 
> The following files also need sync up with v6.7-rc1.
> 
> k3-am65-iot2050-common-pg2.dtsi
> k3-am65-iot2050-common.dtsi
> k3-am6528-iot2050-basic-common.dtsi
> k3-am6548-iot2050-advanced-common.dtsi
> k3-am6548-iot2050-advanced-m2.dts
> 
> Jan - could you look at syncing those once an update to this series is
> posted? We could probably have a smoother v6.8-rc1 from then on.
> 

We currently plan to sync once support for the new SM variant is in the
upstream DT. Do you see other changes that would benefit from an earlier
sync?

Jan

-- 
Siemens AG, Technology
Linux Expert Center



[PATCH v3] test/py: i2c: Add tests for i2c command

2024-01-01 Thread Love Kumar
Add below test cases for i2c commands:
i2c_bus - To show i2c bus info,
i2c_dev - To set or show the current bus,
i2c_probe - To probe the i2c device,
i2c_eeprom - To test i2c eeprom device,
i2c_probe_all_buses - To list down all the buses and probes it

Signed-off-by: Love Kumar 
---
Changes in v2:
- Take the configured eeprom value from env to read back and compare
Changes in v3:
- Add test env dependency to run it for provided i2c bus list
---
 test/py/tests/test_i2c.py | 116 ++
 1 file changed, 116 insertions(+)
 create mode 100644 test/py/tests/test_i2c.py

diff --git a/test/py/tests/test_i2c.py b/test/py/tests/test_i2c.py
new file mode 100644
index ..825d0c2e6eb7
--- /dev/null
+++ b/test/py/tests/test_i2c.py
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import random
+import re
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+the i2c device info including the bus list and eeprom address/value. This test
+will be automatically skipped without this.
+
+For example:
+
+# Setup env__i2c_device_test to set the i2c bus list and probe_all boolean
+# parameter. For i2c_probe_all_buses case, if probe_all parameter is set to
+# False then it probes all the buses listed in bus_list instead of probing all
+# the buses available.
+env__i2c_device_test = {
+'bus_list': [0, 2, 5, 12, 16, 18],
+'probe_all': False,
+}
+
+# Setup env__i2c_eeprom_device_test to set the i2c bus number, eeprom address
+# and configured value for i2c_eeprom test case. Test will be skipped if
+# env__i2c_eeprom_device_test is not set
+env__i2c_eeprom_device_test = {
+'bus': 3,
+'eeprom_addr': 0x54,
+'eeprom_val': '30 31',
+}
+"""
+
+def get_i2c_test_env(u_boot_console):
+f = u_boot_console.config.env.get("env__i2c_device_test", None)
+if not f:
+pytest.skip("No I2C device to test!")
+else:
+bus_list = f.get("bus_list", None)
+if not bus_list:
+pytest.skip("I2C bus list is not provided!")
+probe_all = f.get("probe_all", False)
+return bus_list, probe_all
+
+@pytest.mark.buildconfigspec("cmd_i2c")
+def test_i2c_bus(u_boot_console):
+bus_list, probe = get_i2c_test_env(u_boot_console)
+bus = random.choice(bus_list)
+expected_response = f"Bus {bus}:"
+response = u_boot_console.run_command("i2c bus")
+assert expected_response in response
+
+@pytest.mark.buildconfigspec("cmd_i2c")
+def test_i2c_dev(u_boot_console):
+bus_list, probe = get_i2c_test_env(u_boot_console)
+expected_response = "Current bus is"
+response = u_boot_console.run_command("i2c dev")
+assert expected_response in response
+
+@pytest.mark.buildconfigspec("cmd_i2c")
+def test_i2c_probe(u_boot_console):
+bus_list, probe = get_i2c_test_env(u_boot_console)
+bus = random.choice(bus_list)
+expected_response = f"Setting bus to {bus}"
+response = u_boot_console.run_command(f"i2c dev {bus}")
+assert expected_response in response
+expected_response = "Valid chip addresses:"
+response = u_boot_console.run_command("i2c probe")
+assert expected_response in response
+
+@pytest.mark.buildconfigspec("cmd_i2c")
+def test_i2c_eeprom(u_boot_console):
+f = u_boot_console.config.env.get("env__i2c_eeprom_device_test", None)
+if not f:
+pytest.skip("No I2C eeprom to test!")
+
+bus = f.get("bus", 0)
+if bus < 0:
+pytest.fail("No bus specified via env__i2c_eeprom_device_test!")
+
+addr = f.get("eeprom_addr", -1)
+if addr < 0:
+pytest.fail("No eeprom address specified via 
env__i2c_eeprom_device_test!")
+
+value = f.get("eeprom_val")
+if not value:
+pytest.fail(
+"No eeprom configured value provided via 
env__i2c_eeprom_device_test!"
+)
+
+# Enable i2c mux bridge
+u_boot_console.run_command("i2c dev %x" % bus)
+u_boot_console.run_command("i2c probe")
+output = u_boot_console.run_command("i2c md %x 0 5" % addr)
+assert value in output
+
+@pytest.mark.buildconfigspec("cmd_i2c")
+def test_i2c_probe_all_buses(u_boot_console):
+bus_list, probe = get_i2c_test_env(u_boot_console)
+bus = random.choice(bus_list)
+expected_response = f"Bus {bus}:"
+response = u_boot_console.run_command("i2c bus")
+assert expected_response in response
+
+# Get all the bus list
+if probe:
+buses = re.findall("Bus (.+?):", response)
+bus_list = [int(x) for x in buses]
+
+for dev in bus_list:
+expected_response = f"Setting bus to {dev}"
+response = u_boot_console.run_command(f"i2c dev {dev}")
+assert expected_response in response
+expected_response = "Valid chip addresses:"
+response = u_boot_console.run_command("i2c probe")
+assert expected_response in response
-- 
2.25.1



[PATCH v3] test/py: mii: Add tests for mii command

2024-01-01 Thread Love Kumar
Add below test cases for mii commands:
mii_info -To display MII PHY info
mii_list - To list MII devices
mii_set_device - To set MII device
mii_read - To reads register from MII PHY address
mii_dump - To display data from MII PHY address

Signed-off-by: Love Kumar 
---
Changes in v2:
- Get MII device list from env instead of auto-detecting it
- Set the MII device to its current device after testing so that it
won't impact next cases
Changes in v3:
 - Use single quote in env to maintain consistency
---
 test/py/tests/test_mii.py | 92 +++
 1 file changed, 92 insertions(+)
 create mode 100644 test/py/tests/test_mii.py

diff --git a/test/py/tests/test_mii.py b/test/py/tests/test_mii.py
new file mode 100644
index ..7b6816d1089e
--- /dev/null
+++ b/test/py/tests/test_mii.py
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import re
+
+"""
+Note: This test doesn't rely on boardenv_* configuration value but they can
+change test behavior.
+
+For example:
+
+# Setup env__mii_deive_test_skip to True if tests with ethernet PHY devices
+# should be skipped. For example: Missing PHY device
+env__mii_device_test_skip = True
+
+# Setup env__mii_device_test to set the MII device names. Test will be skipped
+# if env_mii_device_test is not set
+env__mii_device_test = {
+'device_list': ['eth0', 'eth1'],
+}
+"""
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_info(u_boot_console):
+if u_boot_console.config.env.get("env__mii_device_test_skip", False):
+pytest.skip("MII device test is not enabled!")
+expected_output = "PHY"
+output = u_boot_console.run_command("mii info")
+if not re.search(r"PHY (.+?):", output):
+pytest.skip("PHY device does not exist!")
+assert expected_output in output
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_list(u_boot_console):
+if u_boot_console.config.env.get("env__mii_device_test_skip", False):
+pytest.skip("MII device test is not enabled!")
+
+f = u_boot_console.config.env.get("env__mii_device_test", None)
+if not f:
+pytest.skip("No MII device to test!")
+
+dev_list = f.get("device_list")
+if not dev_list:
+pytest.fail("No MII device list provided via env__mii_device_test!")
+
+expected_output = "Current device"
+output = u_boot_console.run_command("mii device")
+mii_devices = (
+re.search(r"MII devices: '(.+)'", output).groups()[0].replace("'", 
"").split()
+)
+
+assert len([x for x in dev_list if x in mii_devices]) == len(dev_list)
+assert expected_output in output
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_set_device(u_boot_console):
+test_mii_list(u_boot_console)
+f = u_boot_console.config.env.get("env__mii_device_test", None)
+dev_list = f.get("device_list")
+output = u_boot_console.run_command("mii device")
+current_dev = re.search(r"Current device: '(.+?)'", output).groups()[0]
+
+for dev in dev_list:
+u_boot_console.run_command(f"mii device {dev}")
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
+
+u_boot_console.run_command(f"mii device {current_dev}")
+output = u_boot_console.run_command("mii device")
+dev = re.search(r"Current device: '(.+?)'", output).groups()[0]
+assert current_dev == dev
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_read(u_boot_console):
+test_mii_list(u_boot_console)
+output = u_boot_console.run_command("mii info")
+eth_addr = hex(int(re.search(r"PHY (.+?):", output).groups()[0], 16))
+u_boot_console.run_command(f"mii read {eth_addr} 0")
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
+
+@pytest.mark.buildconfigspec("cmd_mii")
+def test_mii_dump(u_boot_console):
+test_mii_list(u_boot_console)
+expected_response = "PHY control register"
+output = u_boot_console.run_command("mii info")
+eth_addr = hex(int(re.search(r"PHY (.+?):", output).groups()[0], 16))
+response = u_boot_console.run_command(f"mii dump {eth_addr} 0")
+assert expected_response in response
+output = u_boot_console.run_command("echo $?")
+assert output.endswith("0")
-- 
2.25.1



Re: [PATCH] board: rockchip: Add support for FriendlyARM NanoPi R2C Plus

2024-01-01 Thread Kever Yang

Hi Tianling,

On 2023/12/23 12:00, Tianling Shen wrote:

The NanoPi R2C Plus is a small variant of NanoPi R2C with a on-board
eMMC flash (8G) included.

The device tree is taken from the kernel v6.5.

Signed-off-by: Tianling Shen 
---
  arch/arm/dts/Makefile |   1 +
  .../dts/rk3328-nanopi-r2c-plus-u-boot.dtsi|   9 ++
  arch/arm/dts/rk3328-nanopi-r2c-plus.dts   |  33 +
  board/rockchip/evb_rk3328/MAINTAINERS |   6 +
  configs/nanopi-r2c-plus-rk3328_defconfig  | 114 ++
  5 files changed, 163 insertions(+)
  create mode 100644 arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3328-nanopi-r2c-plus.dts
  create mode 100644 configs/nanopi-r2c-plus-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9d28a485bec..6909f95e084 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -126,6 +126,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
  dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-nanopi-r2c.dtb \
+   rk3328-nanopi-r2c-plus.dtb \
rk3328-nanopi-r2s.dtb \
rk3328-orangepi-r1-plus.dtb \
rk3328-orangepi-r1-plus-lts.dtb \
diff --git a/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi 
b/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
new file mode 100644
index 000..f8adb9e5e1f
--- /dev/null
+++ b/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "rk3328-nanopi-r2c-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
diff --git a/arch/arm/dts/rk3328-nanopi-r2c-plus.dts 
b/arch/arm/dts/rk3328-nanopi-r2c-plus.dts
new file mode 100644
index 000..16a1958e457
--- /dev/null
+++ b/arch/arm/dts/rk3328-nanopi-r2c-plus.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2021 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2023 Tianling Shen 
+ */
+
+/dts-v1/;
+#include "rk3328-nanopi-r2c.dts"
+
+/ {
+   model = "FriendlyElec NanoPi R2C Plus";
+   compatible = "friendlyarm,nanopi-r2c-plus", "rockchip,rk3328";
+
+   aliases {
+   mmc1 = 
+   };
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   max-frequency = <15000>;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _bus8>;
+   vmmc-supply = <_io_33>;
+   vqmmc-supply = <_emmc>;
+   status = "okay";
+};
diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
b/board/rockchip/evb_rk3328/MAINTAINERS
index 8a19eb373d0..5fc114a63f6 100644
--- a/board/rockchip/evb_rk3328/MAINTAINERS
+++ b/board/rockchip/evb_rk3328/MAINTAINERS
@@ -11,6 +11,12 @@ S:  Maintained
  F:  configs/nanopi-r2c-rk3328_defconfig
  F:  arch/arm/dts/rk3328-nanopi-r2c-u-boot.dtsi
  
+NANOPI-R2C-PLUS-RK3328

+M:  Tianling Shen 
+S:  Maintained
+F:  configs/nanopi-r2c-plus-rk3328_defconfig
+F:  arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
+
  NANOPI-R2S-RK3328
  M:  David Bauer 
  S:  Maintained
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
new file mode 100644
index 000..320ed8b434a
--- /dev/null
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -0,0 +1,114 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
+CONFIG_SF_DEFAULT_SPEED=2000
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_DEFAULT_DEVICE_TREE="rk3328-nanopi-r2c-plus"
+CONFIG_DM_RESET=y
+CONFIG_ROCKCHIP_RK3328=y
+CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_TPL_LIBCOMMON_SUPPORT=y
+CONFIG_TPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC=y
+CONFIG_SPL_STACK_R_ADDR=0x60
+CONFIG_SPL_STACK=0x40
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x800


    Did you test both TPL and SPL?


Thanks,

- Kever


+CONFIG_DEBUG_UART_BASE=0xFF13
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SYS_LOAD_ADDR=0x800800
+CONFIG_DEBUG_UART=y
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_MISC_INIT_R=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x200
+CONFIG_SPL_BSS_MAX_SIZE=0x2000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_I2C=y
+CONFIG_SPL_POWER=y
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_TPL_SYS_MALLOC_SIMPLE=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y

Re: [PATCH v2] rockchip: rk35xx: expand space for decompressed kernel

2024-01-01 Thread Kever Yang



On 2023/12/27 00:43, Hugh Cole-Baker wrote:

An uncompressed 6.7.0-rc1 Linux kernel Image built with the arm64
defconfig is about 40MB. This does not fit in to the space between
kernel_comp_addr_r and fdt_addr_r, so when uncompressing an Image.gz
to this size, the FDT will be overwritten. Rearrange addresses to have
128MiB for the kernel and its decompression buffer, then devicetree,
overlay and ramdisk at the end.

Signed-off-by: Hugh Cole-Baker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes from v1:
Reorder things to have to have 128MiB for kernel and decompression space,
then devicetree, overlays and ramdisk.
Update kernel_comp_size to 128MiB.

  include/configs/rk3568_common.h | 12 ++--
  include/configs/rk3588_common.h | 12 ++--
  2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/configs/rk3568_common.h b/include/configs/rk3568_common.h
index 1b7d3437b1..48f93083de 100644
--- a/include/configs/rk3568_common.h
+++ b/include/configs/rk3568_common.h
@@ -20,12 +20,12 @@
"script_offset_f=0xffe000\0"  \
"script_size_f=0x2000\0"  \
"pxefile_addr_r=0x00e0\0" \
-   "fdt_addr_r=0x0a10\0" \
-   "fdtoverlay_addr_r=0x0200\0"  \
-   "kernel_addr_r=0x0208\0"  \
-   "ramdisk_addr_r=0x0a20\0" \
-   "kernel_comp_addr_r=0x0800\0" \
-   "kernel_comp_size=0x200\0"
+   "kernel_addr_r=0x0200\0"  \
+   "kernel_comp_addr_r=0x0a00\0" \
+   "fdt_addr_r=0x1200\0" \
+   "fdtoverlay_addr_r=0x1210\0"  \
+   "ramdisk_addr_r=0x1218\0" \
+   "kernel_comp_size=0x800\0"
  
  #define CFG_EXTRA_ENV_SETTINGS		\

ENV_MEM_LAYOUT_SETTINGS \
diff --git a/include/configs/rk3588_common.h b/include/configs/rk3588_common.h
index 46389d087d..70430612ef 100644
--- a/include/configs/rk3588_common.h
+++ b/include/configs/rk3588_common.h
@@ -19,12 +19,12 @@
"script_offset_f=0xffe000\0"  \
"script_size_f=0x2000\0"  \
"pxefile_addr_r=0x00e0\0" \
-   "fdt_addr_r=0x0a10\0" \
-   "fdtoverlay_addr_r=0x0200\0"  \
-   "kernel_addr_r=0x0208\0"  \
-   "ramdisk_addr_r=0x0a20\0" \
-   "kernel_comp_addr_r=0x0800\0" \
-   "kernel_comp_size=0x200\0"
+   "kernel_addr_r=0x0200\0"  \
+   "kernel_comp_addr_r=0x0a00\0" \
+   "fdt_addr_r=0x1200\0" \
+   "fdtoverlay_addr_r=0x1210\0"  \
+   "ramdisk_addr_r=0x1218\0" \
+   "kernel_comp_size=0x800\0"
  
  #define CFG_EXTRA_ENV_SETTINGS \

"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \


Re: [PATCH v1] arm: dts: rockchip: rk3288: move to 64 bit reg size

2024-01-01 Thread Kever Yang



On 2023/12/27 20:06, Johan Jonker wrote:

To make automatic Rockchip DT syncing possible from Linux to U-boot prepare
rk3288.dtsi by moving to 64 bit reg size.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3288-evb.dtsi |   2 +-
  arch/arm/dts/rk3288-firefly.dtsi |   2 +-
  arch/arm/dts/rk3288-miqi.dtsi|   2 +-
  arch/arm/dts/rk3288-phycore-som.dtsi |   2 +-
  arch/arm/dts/rk3288-popmetal.dtsi|   2 +-
  arch/arm/dts/rk3288-rock2-som.dtsi   |   2 +-
  arch/arm/dts/rk3288-tinker.dtsi  |   2 +-
  arch/arm/dts/rk3288-u-boot.dtsi  |  14 +-
  arch/arm/dts/rk3288-veyron.dtsi  |   2 +-
  arch/arm/dts/rk3288.dtsi | 259 +++
  arch/arm/mach-rockchip/Kconfig   |   1 +
  11 files changed, 165 insertions(+), 125 deletions(-)

diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
index 72da8847344c..0e347beb154d 100644
--- a/arch/arm/dts/rk3288-evb.dtsi
+++ b/arch/arm/dts/rk3288-evb.dtsi
@@ -7,7 +7,7 @@

  / {
memory {
-   reg = <0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

ext_gmac: external-gmac-clock {
diff --git a/arch/arm/dts/rk3288-firefly.dtsi b/arch/arm/dts/rk3288-firefly.dtsi
index 1117d3913ed7..0824b19ee642 100644
--- a/arch/arm/dts/rk3288-firefly.dtsi
+++ b/arch/arm/dts/rk3288-firefly.dtsi
@@ -7,7 +7,7 @@

  / {
memory {
-   reg = <0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

ext_gmac: external-gmac-clock {
diff --git a/arch/arm/dts/rk3288-miqi.dtsi b/arch/arm/dts/rk3288-miqi.dtsi
index 00c8613d6d73..c56e1109e3ac 100644
--- a/arch/arm/dts/rk3288-miqi.dtsi
+++ b/arch/arm/dts/rk3288-miqi.dtsi
@@ -8,7 +8,7 @@
  / {
memory {
device_type = "memory";
-   reg = <0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

ext_gmac: external-gmac-clock {
diff --git a/arch/arm/dts/rk3288-phycore-som.dtsi 
b/arch/arm/dts/rk3288-phycore-som.dtsi
index 70c00308d736..bde5910ff625 100644
--- a/arch/arm/dts/rk3288-phycore-som.dtsi
+++ b/arch/arm/dts/rk3288-phycore-som.dtsi
@@ -55,7 +55,7 @@
 */
memory {
device_type = "memory";
-   reg = <0 0x800>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

aliases {
diff --git a/arch/arm/dts/rk3288-popmetal.dtsi 
b/arch/arm/dts/rk3288-popmetal.dtsi
index d732a70678ba..ecff641b1099 100644
--- a/arch/arm/dts/rk3288-popmetal.dtsi
+++ b/arch/arm/dts/rk3288-popmetal.dtsi
@@ -44,7 +44,7 @@
  / {
memory{
device_type = "memory";
-   reg = <0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

ext_gmac: external-gmac-clock {
diff --git a/arch/arm/dts/rk3288-rock2-som.dtsi 
b/arch/arm/dts/rk3288-rock2-som.dtsi
index 1ece66f3e162..58e32fbb80f6 100644
--- a/arch/arm/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/dts/rk3288-rock2-som.dtsi
@@ -43,7 +43,7 @@

  / {
memory {
-   reg = <0x0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
device_type = "memory";
};

diff --git a/arch/arm/dts/rk3288-tinker.dtsi b/arch/arm/dts/rk3288-tinker.dtsi
index 46460ae455e2..62b4beb25100 100644
--- a/arch/arm/dts/rk3288-tinker.dtsi
+++ b/arch/arm/dts/rk3288-tinker.dtsi
@@ -44,7 +44,7 @@
  / {
memory {
device_type = "memory";
-   reg = <0x0 0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>;
};

ext_gmac: external-gmac-clock {
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index c4c5a2d225c4..a43d320ade7b 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -29,10 +29,10 @@

dmc: dmc@ff61 {
compatible = "rockchip,rk3288-dmc", "syscon";
-   reg = <0xff61 0x3fc
-  0xff62 0x294
-  0xff63 0x3fc
-  0xff64 0x294>;
+   reg = <0x0 0xff61 0x0 0x3fc
+  0x0 0xff62 0x0 0x294
+  0x0 0xff63 0x0 0x3fc
+  0x0 0xff64 0x0 0x294>;
clocks = < PCLK_DDRUPCTL0>, < PCLK_PUBL0>,
 < PCLK_DDRUPCTL1>, < PCLK_PUBL1>,
 < ARMCLK>;
@@ -50,7 +50,7 @@

noc: syscon@ffac {
compatible = "rockchip,rk3288-noc", "syscon";
-   reg = <0xffac 0x2000>;
+   reg = <0x0 0xffac 0x0 0x2000>;
bootph-all;
};
  };
@@ -134,3 +134,7 @@
   {
bootph-all;
  };
+
+ {
+   bootph-all;
+};
diff --git a/arch/arm/dts/rk3288-veyron.dtsi b/arch/arm/dts/rk3288-veyron.dtsi
index 434b0d494e5e..99406151bf59 100644
--- a/arch/arm/dts/rk3288-veyron.dtsi
+++ b/arch/arm/dts/rk3288-veyron.dtsi
@@ -11,7 +11,7 @@


Re: [PATCH] rockchip: rk3568: add support of all UART

2024-01-01 Thread Kever Yang

Hi Arseniy,

On 2024/1/1 21:43, Arseniy Mescheryakov wrote:

Thanks for the answer.
I think developers should have the opportunity to configure UART from
the u-boot directly (via configuration) without any additional
proprietary blobs.
The soc driver source code is used for hardware, I think soc vendor has 
a recommend hardware design which is UART2
for debug uart in RK3568, and the board vendor may change this design if 
the board has special requirement,

please add the driver based on real hardware.
Th key reason is that the bootloader only add driver it needs for 
hardware, not adding all the drivers, or else the size

will be very big.

Thanks,
- Kever


There is 
https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3568/rk3568.c
, that has same functionality as my patch, but it has a lot of code
duplication and because of it i add a lot of macroses.
Maybe there is any target that has a lot of UARTs instances and its
configuration going in other way than mine and hasn't a lot of code
duplication.


On Sun, Dec 31, 2023 at 3:31 AM Jonas Karlman  wrote:

Hi Arseniy,

On 2023-12-30 12:20, Arseniy Meshcheryakov wrote:

This patch add support of all UARTs for rk3568, which can be used in console.

Please explain why this is needed, on rk35xx the rockchip ddr init blob
is required and can setup correct uart iomux with rkbin/tools/ddrbin_tool [1].

And U-Boot SPL and proper can use the serial, gpio and pinctrl drivers
to configure correct uart iomux for any board not using uart2.

We should be able to remove the current code that configures uart2 M0
iomux and still have a working debug console.

Please provide more details why and on what board you need this.

[1] 
https://github.com/rockchip-linux/rkbin/blob/master/tools/ddrbin_tool_user_guide.txt#L72-L75


Signed-off-by: Arseniy Meshcheryakov 
---
  arch/arm/mach-rockchip/rk3568/rk3568.c | 470 -
  1 file changed, 452 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c 
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 69ef19cc85..f79b47ee5b 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -34,26 +34,468 @@
  #define CPU_GRF_BASE 0xfdc3
  #define GRF_CORE_PVTPLL_CON0 (0x10)

-/* PMU_GRF_GPIO0D_IOMUX_L */
  enum {
+ /* PMU_GRF_GPIO0C_IOMUX_L */
+ GPIO0C1_SHIFT   = 4,
+ GPIO0C1_MASK= GENMASK(6, 4),
+ GPIO0C1_GPIO= 0,
+ GPIO0C1_UART0_M0_TX = 3,
+
+ GPIO0C0_SHIFT   = 0,
+ GPIO0C0_MASK= GENMASK(2, 0),
+ GPIO0C0_GPIO= 0,
+ GPIO0C0_UART0_M0_RX = 3,
+
+ /* PMU_GRF_GPIO0D_IOMUX_L */
   GPIO0D1_SHIFT   = 4,
   GPIO0D1_MASK= GENMASK(6, 4),
   GPIO0D1_GPIO= 0,
- GPIO0D1_UART2_TXM0,
+ GPIO0D1_UART2_M0_TX,

   GPIO0D0_SHIFT   = 0,
   GPIO0D0_MASK= GENMASK(2, 0),
   GPIO0D0_GPIO= 0,
- GPIO0D0_UART2_RXM0,
-};
+ GPIO0D0_UART2_M0_RX,
+
+ /* GRF_GPIO1A_IOMUX_L */
+ GPIO1A1_SHIFT   = 4,
+ GPIO1A1_MASK= GENMASK(6, 4),
+ GPIO1A1_GPIO= 0,
+ GPIO1A1_UART3_M0_TX = 2,
+
+ GPIO1A0_SHIFT   = 0,
+ GPIO1A0_MASK= GENMASK(2, 0),
+ GPIO1A0_GPIO= 0,
+ GPIO1A0_UART3_M0_RX = 2,
+
+ /* GRF_GPIO1A_IOMUX_H */
+ GPIO1A6_SHIFT   = 8,
+ GPIO1A6_MASK= GENMASK(10, 8),
+ GPIO1A6_GPIO= 0,
+ GPIO1A6_UART4_M0_TX = 2,
+
+
+ GPIO1A4_SHIFT   = 0,
+ GPIO1A4_MASK= GENMASK(2, 0),
+ GPIO1A4_GPIO= 0,
+ GPIO1A4_UART4_M0_RX = 2,
+
+ /* GRF_GPIO1D_IOMUX_H */
+ GPIO1D6_SHIFT   = 8,
+ GPIO1D6_MASK= GENMASK(10, 8),
+ GPIO1D6_GPIO= 0,
+ GPIO1D6_UART2_M1_RX = 2,
+ GPIO1D6_UART6_M1_RX,
+
+ GPIO1D5_SHIFT   = 4,
+ GPIO1D5_MASK= GENMASK(6, 4),
+ GPIO1D5_GPIO= 0,
+ GPIO1D5_UART2_M1_TX = 2,
+ GPIO1D5_UART6_M1_TX,
+
+ /* GRF_GPIO2A_IOMUX_L */
+ GPIO2A3_SHIFT   = 12,
+ GPIO2A3_MASK= GENMASK(14, 12),
+ GPIO2A3_GPIO= 0,
+ GPIO2A3_UART6_M0_RX = 3,
+
+ GPIO2A2_SHIFT   = 8,
+ GPIO2A2_MASK= GENMASK(10, 8),
+ GPIO2A2_GPIO= 0,
+ GPIO2A2_UART5_M0_TX = 3,
+
+ GPIO2A1_SHIFT   = 4,
+ GPIO2A1_MASK= GENMASK(6, 4),
+ GPIO2A1_GPIO= 0,
+ GPIO2A1_UART5_M0_RX = 3,
+
+ /* GRF_GPIO2A_IOMUX_H */
+ GPIO2A7_SHIFT   = 12,
+ GPIO2A7_MASK= GENMASK(14, 12),
+ GPIO2A7_GPIO= 0,
+ GPIO2A7_UART9_M0_RX = 3,
+
+ GPIO2A6_SHIFT   = 8,
+ GPIO2A6_MASK= GENMASK(10, 8),
+ GPIO2A6_GPIO= 0,
+ GPIO2A6_UART7_M0_TX = 3,
+
+ 

Re: Please pull u-boot-dm next

2024-01-01 Thread Tom Rini
On Mon, Jan 01, 2024 at 10:31:57AM -0700, Simon Glass wrote:

> Hi Tom,
> 
> This is for -next
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/19131
> 
> https://dev.azure.com/simon0972/u-boot/_build/results?buildId=57=results
> 
> 
> The following changes since commit 2b28c3b871cd5d55b19f0a86cef970139f8ab952:
> 
>   Merge patch series "Modernize U-Boot shell" (2023-12-28 14:38:25 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-next-1124
> 
> for you to fetch changes up to e266d2731145681a55d862360f1b61690b0c6820:
> 
>   bloblist: Update documentation and header comment (2023-12-31 07:21:02 
> -0700)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

2024-01-01 Thread Tom Rini
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> Hi Mark, Tom,
> 
> On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  wrote:
> >
> > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > From: Tom Rini 
> > >
> > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > Hi Sumit,
> > > >
> > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg  
> > > > wrote:
> > > > >
> > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  wrote:
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > > Hi Tom, Sumit,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote:
> > > > > > > > > > Hi Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Allow platform owners to mirror devicetree files from 
> > > > > > > > > > > devitree-rebasing
> > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > > build then along with any *-u-boot.dtsi file present in 
> > > > > > > > > > > arch/$(ARCH)/dts
> > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > >
> > > > > > > > > > > This will help easy migration for platforms which 
> > > > > > > > > > > currently are compliant
> > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > Changes in v3:
> > > > > > > > > > > --
> > > > > > > > > > > - Minor commit message update
> > > > > > > > > > >
> > > > > > > > > > > Changes in v2:
> > > > > > > > > > > --
> > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > >
> > > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > >   enables a live tree which is available after 
> > > > > > > > > > > relocation,
> > > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > > >
> > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > +   bool "Enable use of devicetree imported from 
> > > > > > > > > > > Linux kernel release"
> > > > > > > > > > > +   help
> > > > > > > > > > > + Traditionally, U-Boot platforms used to have 
> > > > > > > > > > > their custom devicetree
> > > > > > > > > > > + files or copy devicetree files from Linux 
> > > > > > > > > > > kernel which are hard to
> > > > > > > > > > > + maintain and can usually get out-of-sync from 
> > > > > > > > > > > Linux kernel. This
> > > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > > + a regular sync will be maintained every major 
> > > > > > > > > > > Linux kernel release
> > > > > > > > > > > + cycle. However, platforms can still have some 
> > > > > > > > > > > custom u-boot specific
> > > > > > > > > > > + bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > >
> > > > > > > > > > My only other suggestion here is to mention that this 
> > > > > > > > > > should be set in
> > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means 
> > > > > > > > > > that it
> > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > >
> > > > > > > > > >   bool  # Enable use of devicetree imported from Linux 
> > > > > > > > > > kernel release
> > > > > > > > >
> > > > > > > > > I think we can just keep prompting for it now, to make the 
> > > > > > > > > transition
> > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > >
> > > > > > > > > > Also, this doesn't seem to work for me. Before this series 
> > > > > > > > > > I get these
> > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > >
> > > > > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb
> > > > > > > > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb
> > > > > > > > > > rk3399-evb.dtb  rk3399-leez-p710.dtb
> > > 

Re: [PATCH v2 2/2] efi_loader: provide tool to dump SMBIOS table

2024-01-01 Thread Heinrich Schuchardt

On 1/1/24 23:41, Simon Glass wrote:

Hi Heinrich,

On Mon, Jan 1, 2024 at 11:50 AM Heinrich Schuchardt
 wrote:


An EFI binary dmidump.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 

Specifying 'nocolor' as load option data suppresses colored output and
clearing of the screen.

Signed-off-by: Heinrich Schuchardt 
---
v2:
 fix an incorrect variable usage when checking the result of memcmp
---
  lib/efi_loader/Makefile  |   7 +
  lib/efi_loader/dmidump.c | 595 +++
  2 files changed, 602 insertions(+)
  create mode 100644 lib/efi_loader/dmidump.c


Does this tool need tests?


Once we have all the SMBIOS stuff in, we could use the tool in a test to 
verify that the SMBIOS tables are correctly installed.




Can you please split up do_save() a bit and also move the command loop
into its own function? Otherwise it looks good to me.



diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 24d33d5409..71880d330e 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -16,6 +16,8 @@ CFLAGS_boothart.o := $(CFLAGS_EFI) -Os -ffreestanding
  CFLAGS_REMOVE_boothart.o := $(CFLAGS_NON_EFI)
  CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
  CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
+CFLAGS_dmidump.o := $(CFLAGS_EFI) -Os -ffreestanding
+CFLAGS_REMOVE_dmidump.o := $(CFLAGS_NON_EFI)
  CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
  CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
  CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding


Is there a way to have a list of these tools such that the flags stuff
is done automatically and doesn't need to be repeated each time?


Looking at

scripts/Makefile.lib:102:
_c_flags = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags))

this is not possible.




@@ -31,6 +33,11 @@ always += helloworld.efi
  targets += helloworld.o
  endif

+ifneq ($(CONFIG_GENERATE_SMBIOS_TABLE),)
+always += dmidump.efi
+targets += dmidump.o


How about smbios_tool ? I think 'dmi' is a bit of an obfuscation.


We can call it smbiosdump.efi.

Thanks for reviewing.

Best regards

Heinrich




+endif
+
  ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
  always += dtbdump.efi
  targets += dtbdump.o


[..]

Regards,
SImon




[PATCH v2 1/1] x86: all firmware tables must be paragraph aligned

2024-01-01 Thread Heinrich Schuchardt
On qemu-x86_64_defconfig the following was observed:

=> efidebug tables
000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table

The SMBIOS configuration table does not point to a paragraph-aligned
(16 byte aligned) address. The reason is that in write_tables() rom_addr is
not aligned and copied to gd->arch.smbios_start.

The Simple Firmware Interface requires that the SFI table is paragraph-
aligned but our code does not guarantee this.

As all tables written in write_tables() must be paragraph-aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().

Add paragraph-alignment in write_tables().

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass 
---
v2:
explain the term paragraph-aligned
---
 arch/x86/lib/tables.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 5b5070f7ca..89d4d30a6a 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -97,6 +97,8 @@ int write_tables(void)
int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
u32 rom_table_end;
 
+   rom_addr = ALIGN(rom_addr, 16);
+
if (!strcmp("smbios", table->name))
gd->arch.smbios_start = rom_addr;
 
-- 
2.43.0



Re: [PATCH 1/1] x86: all firmware tables must be paragraph aligned

2024-01-01 Thread Heinrich Schuchardt

On 1/1/24 23:41, Simon Glass wrote:

On Mon, Jan 1, 2024 at 4:52 AM Heinrich Schuchardt
 wrote:


On qemu-x86_64_defconfig the following was observed:

 => efidebug tables
 000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table

The SMBIOS configuration table does not point to a paragraph aligned
address. The reason is that in write_tables() rom_addr is not aligned and
copied to gd->arch.smbios_start.

The Simple Firmware Interface requires that the SFI table is paragraph
aligned but our code does not guarantee this.

As all tables written in write_tables() must be paragraph aligned, we


paragraph-aligned

But was is a paragraph? Is that an x86 term?


The term paragraph is used by the SMBIOS spec.

The reason why non-UEFI x86 requires low addresses (< 1MiB) for tables 
is that booting starts in real-mode.


Any memory address evenly divisible by 16 is called a paragraph 
boundary. [1]


[1] Memory Paragraphs in Real Mode
http://www.c-jump.com/CIS77/ASM/Memory/M77_0080_paragraphs.htm

A segment begins on a paragraph boundary, which is an address divisible 
by decimal 16 or hex 10. [2]


[2] Programming with 8086 microprocessor
https://www.uobabylon.edu.iq/eprints/publication_1_2613_35.pdf

Best regards

Heinrich




should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().

Add paragraph alignment in write_tables().

Signed-off-by: Heinrich Schuchardt 
---
  arch/x86/lib/tables.c | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Simon Glass 




diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 5b5070f7ca..89d4d30a6a 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -97,6 +97,8 @@ int write_tables(void)
 int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
 u32 rom_table_end;

+   rom_addr = ALIGN(rom_addr, 16);
+
 if (!strcmp("smbios", table->name))
 gd->arch.smbios_start = rom_addr;

--
2.43.0





Re: [PATCH 1/1] cmd: fdt: check fdt address

2024-01-01 Thread Simon Glass
Hi Heinrich,

On Sun, Dec 31, 2023 at 9:31 AM Heinrich Schuchardt
 wrote:
>
> On 12/31/23 15:22, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, Dec 20, 2023 at 5:00 PM Heinrich Schuchardt
> >  wrote:
> >>
> >> Trying to read a device-tree from an illegal address leads to a crash.
> >>
> >> Check that the parameter passed to 'fdt addr' is within the RAM area and
> >> non-zero.
> >
> > What is the motivation for this patch? Is something crashing? We don't
> > do this with the 'md' command, for example.
>
> QEMU with too little memory was crashing. But maybe we should write an
> explicit warning about too little memory instead.

Probably.

[..]

Regards,
Simon


Re: [PATCH 1/1] x86: all firmware tables must be paragraph aligned

2024-01-01 Thread Simon Glass
On Mon, Jan 1, 2024 at 4:52 AM Heinrich Schuchardt
 wrote:
>
> On qemu-x86_64_defconfig the following was observed:
>
> => efidebug tables
> 000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table
>
> The SMBIOS configuration table does not point to a paragraph aligned
> address. The reason is that in write_tables() rom_addr is not aligned and
> copied to gd->arch.smbios_start.
>
> The Simple Firmware Interface requires that the SFI table is paragraph
> aligned but our code does not guarantee this.
>
> As all tables written in write_tables() must be paragraph aligned, we

paragraph-aligned

But was is a paragraph? Is that an x86 term?

> should implement the address rounding in write_tables() and not in table
> specific routines like copy_pirq_routing_table().
>
> Add paragraph alignment in write_tables().
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/x86/lib/tables.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 


>
> diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
> index 5b5070f7ca..89d4d30a6a 100644
> --- a/arch/x86/lib/tables.c
> +++ b/arch/x86/lib/tables.c
> @@ -97,6 +97,8 @@ int write_tables(void)
> int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
> u32 rom_table_end;
>
> +   rom_addr = ALIGN(rom_addr, 16);
> +
> if (!strcmp("smbios", table->name))
> gd->arch.smbios_start = rom_addr;
>
> --
> 2.43.0
>


Re: [PATCH v5 04/12] smbios: Use SMBIOS 3.0 to support an address above 4GB

2024-01-01 Thread Simon Glass
Hi Heinrich,

On Mon, Jan 1, 2024 at 10:34 AM Heinrich Schuchardt  wrote:
>
> On 12/31/23 16:25, Simon Glass wrote:
> > 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 
> > ---
> >
> > (no changes since v4)
> >
> > Changes in v4:
> > - Check the start of the table rather than the end
> >
> > Changes in v2:
> > - Check the end of the table rather than the start.
> >
> >   include/smbios.h |  6 +-
> >   lib/smbios.c | 30 +-
> >   2 files changed, 30 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/smbios.h b/include/smbios.h
> > index e601283d293..77be58887a2 100644
> > --- a/include/smbios.h
> > +++ b/include/smbios.h
> > @@ -12,7 +12,7 @@
> >
> >   /* SMBIOS spec version implemented */
> >   #define SMBIOS_MAJOR_VER3
> > -#define SMBIOS_MINOR_VER 0
> > +#define SMBIOS_MINOR_VER 7
> >
> >   enum {
> >   SMBIOS_STR_MAX  = 64,   /* Maximum length allowed for a string */
> > @@ -80,6 +80,10 @@ struct __packed smbios3_entry {
> >   u64 struct_table_address;
> >   };
> >
> > +/* These two structures should use the same amount of 16-byte-aligned 
> > space */
>
> I cannot see from where you take such a requirement.
> By chance it is fulfilled by the current definitions.
> If this a leftover from debugging we should remove it.

Oh, I just assumed it was a requirement, perhaps. Yes we can remove
this, if you like. In fact perhaps we should remove all SMBIOS2 stuff
as a follow-up?

Regards,
Simon


Re: [PATCH v2 2/2] efi_loader: provide tool to dump SMBIOS table

2024-01-01 Thread Simon Glass
Hi Heinrich,

On Mon, Jan 1, 2024 at 11:50 AM Heinrich Schuchardt
 wrote:
>
> An EFI binary dmidump.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 
>
> Specifying 'nocolor' as load option data suppresses colored output and
> clearing of the screen.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> fix an incorrect variable usage when checking the result of memcmp
> ---
>  lib/efi_loader/Makefile  |   7 +
>  lib/efi_loader/dmidump.c | 595 +++
>  2 files changed, 602 insertions(+)
>  create mode 100644 lib/efi_loader/dmidump.c

Does this tool need tests?

Can you please split up do_save() a bit and also move the command loop
into its own function? Otherwise it looks good to me.

>
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 24d33d5409..71880d330e 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -16,6 +16,8 @@ CFLAGS_boothart.o := $(CFLAGS_EFI) -Os -ffreestanding
>  CFLAGS_REMOVE_boothart.o := $(CFLAGS_NON_EFI)
>  CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
>  CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
> +CFLAGS_dmidump.o := $(CFLAGS_EFI) -Os -ffreestanding
> +CFLAGS_REMOVE_dmidump.o := $(CFLAGS_NON_EFI)
>  CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
>  CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
>  CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding

Is there a way to have a list of these tools such that the flags stuff
is done automatically and doesn't need to be repeated each time?

> @@ -31,6 +33,11 @@ always += helloworld.efi
>  targets += helloworld.o
>  endif
>
> +ifneq ($(CONFIG_GENERATE_SMBIOS_TABLE),)
> +always += dmidump.efi
> +targets += dmidump.o

How about smbios_tool ? I think 'dmi' is a bit of an obfuscation.

> +endif
> +
>  ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
>  always += dtbdump.efi
>  targets += dtbdump.o

[..]

Regards,
SImon


Re: [PATCH v2 1/2] smbios: smbios.h should not import ofnode.h

2024-01-01 Thread Simon Glass
On Mon, Jan 1, 2024 at 11:50 AM Heinrich Schuchardt
 wrote:
>
> 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 
> ---
> v2:
> new patch
> ---
>  include/smbios.h| 6 +-
>  lib/efi_loader/efi_smbios.c | 3 +++
>  lib/smbios-parser.c | 3 +++
>  3 files changed, 7 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

2024-01-01 Thread Simon Glass
Hi Mark, Tom,

On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis  wrote:
>
> > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > From: Tom Rini 
> >
> > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > Hi Sumit,
> > >
> > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg  wrote:
> > > >
> > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass  wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote:
> > > > > > > Hi Tom, Sumit,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote:
> > > > > > > > > Hi Sumit,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Allow platform owners to mirror devicetree files from 
> > > > > > > > > > devitree-rebasing
> > > > > > > > > > directory into dts/arch/$(ARCH) (special case for 
> > > > > > > > > > dts/arch/arm64). Then
> > > > > > > > > > build then along with any *-u-boot.dtsi file present in 
> > > > > > > > > > arch/$(ARCH)/dts
> > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > >
> > > > > > > > > > This will help easy migration for platforms which currently 
> > > > > > > > > > are compliant
> > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Sumit Garg 
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Changes in v3:
> > > > > > > > > > --
> > > > > > > > > > - Minor commit message update
> > > > > > > > > >
> > > > > > > > > > Changes in v2:
> > > > > > > > > > --
> > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > >
> > > > > > > > > >  dts/Kconfig | 11 +++
> > > > > > > > > >  dts/Makefile| 17 ++---
> > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++
> > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > >
> > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > >   enables a live tree which is available after 
> > > > > > > > > > relocation,
> > > > > > > > > >   and can be adjusted as needed.
> > > > > > > > > >
> > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > +   bool "Enable use of devicetree imported from Linux 
> > > > > > > > > > kernel release"
> > > > > > > > > > +   help
> > > > > > > > > > + Traditionally, U-Boot platforms used to have 
> > > > > > > > > > their custom devicetree
> > > > > > > > > > + files or copy devicetree files from Linux kernel 
> > > > > > > > > > which are hard to
> > > > > > > > > > + maintain and can usually get out-of-sync from 
> > > > > > > > > > Linux kernel. This
> > > > > > > > > > + option enables platforms to migrate to 
> > > > > > > > > > devicetree-rebasing repo where
> > > > > > > > > > + a regular sync will be maintained every major 
> > > > > > > > > > Linux kernel release
> > > > > > > > > > + cycle. However, platforms can still have some 
> > > > > > > > > > custom u-boot specific
> > > > > > > > > > + bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > >
> > > > > > > > > My only other suggestion here is to mention that this should 
> > > > > > > > > be set in
> > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that 
> > > > > > > > > it
> > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > >
> > > > > > > > >   bool  # Enable use of devicetree imported from Linux 
> > > > > > > > > kernel release
> > > > > > > >
> > > > > > > > I think we can just keep prompting for it now, to make the 
> > > > > > > > transition
> > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > >
> > > > > > > > > Also, this doesn't seem to work for me. Before this series I 
> > > > > > > > > get these
> > > > > > > > > files when building firefly-rk3399:
> > > > > > > > >
> > > > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb
> > > > > > > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb
> > > > > > > > > rk3399-evb.dtb  rk3399-leez-p710.dtb
> > > > > > > > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb
> > > > > > > > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb
> > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > rk3399-firefly.dtb  rk3399-nanopi-m4-2gb.dtb
> > > > > 

[PATCH] net: phy: broadcom: Configure LEDs on BCM54210E

2024-01-01 Thread Marek Vasut
Configure LEDs on BCM54210E so they would blink on activity
and indicate link speed. Without this the LEDs are always on
if cable is plugged in.

Signed-off-by: Marek Vasut 
---
Cc: Joe Hershberger 
Cc: Rafał Miłecki 
Cc: Ramon Fried 
Cc: Rasmus Villemoes 
---
 drivers/net/phy/broadcom.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 82e3bbef7dd..ecccb7c3b54 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -42,6 +42,12 @@
 #define BCM54810_SHD_CLK_CTL   0x3
 #define BCM54810_SHD_CLK_CTL_GTXCLK_EN BIT(9)
 
+#define BCM54XX_SHD_LEDS1  0x0d
+#define BCM_LED_SRC_LINKSPD2   0x1
+#define BCM_LED_SRC_ACTIVITYLED0x3
+#define BCM54XX_SHD_LEDS1_LED3(src)(((src) & 0xf) << 4)
+#define BCM54XX_SHD_LEDS1_LED1(src)(((src) & 0xf) << 0)
+
 static int bcm54xx_auxctl_read(struct phy_device *phydev, u16 regnum)
 {
/* The register must be written to both the Shadow Register Select and
@@ -148,7 +154,16 @@ static int bcm54210e_config(struct phy_device *phydev)
if (ret < 0)
return ret;
 
-   return bcm5461_config(phydev);
+   ret = bcm5461_config(phydev);
+   if (ret < 0)
+   return ret;
+
+   /* Configure LEDs to blink. */
+   bcm_phy_write_shadow(phydev, BCM54XX_SHD_LEDS1,
+BCM54XX_SHD_LEDS1_LED1(BCM_LED_SRC_ACTIVITYLED) |
+BCM54XX_SHD_LEDS1_LED3(BCM_LED_SRC_LINKSPD2));
+
+   return 0;
 }
 
 static int bcm54xx_parse_status(struct phy_device *phydev)
-- 
2.43.0



[PATCH] ARM: imx: Auto-detect PHY on Data Modul i.MX8M Mini/Plus eDM SBC

2024-01-01 Thread Marek Vasut
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 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 .../dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi |  6 ---
 .../imx8mm_data_modul_edm_sbc.c   | 42 
 .../imx8mp_data_modul_edm_sbc.c   | 50 +++
 configs/imx8mm_data_modul_edm_sbc_defconfig   |  1 +
 configs/imx8mp_data_modul_edm_sbc_defconfig   |  1 +
 5 files changed, 94 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi 
b/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
index a2b5976b6bd..cb6ea356fd7 100644
--- a/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
@@ -51,12 +51,6 @@
};
 };
 
- {
-   /delete-property/ assigned-clocks;
-   /delete-property/ assigned-clock-parents;
-   /delete-property/ assigned-clock-rates;
-};
-
  {
bootph-pre-ram;
 };
diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c 
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index ff89333b732..bfb2bddc1d1 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -5,9 +5,11 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -34,3 +36,43 @@ int board_late_init(void)
 
return 0;
 }
+
+int fdtdec_board_setup(const void *fdt_blob)
+{
+   const void __iomem *mux = (void __iomem *)IOMUXC_BASE_ADDR +
+   FIELD_GET(MUX_CTRL_OFS_MASK, IMX8MM_PAD_ENET_MDC_GPIO1_IO16);
+   const char *phy_compat = "ethernet-phy-ieee802.3-c22";
+   bool is_bcmphy;
+   int phy_node;
+   int ret;
+
+   /* Do nothing if not i.MX8MM eDM SBC */
+   ret = fdt_node_check_compatible(fdt_blob, 0, 
"dmo,imx8mm-data-modul-edm-sbc");
+   if (ret)
+   return 0;
+
+   /*
+* If GPIO1_16 RGMII_MDC is HIGH, then R530 is populated.
+* R530 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.
+*/
+   setbits_le32(mux, IOMUX_CONFIG_SION);
+   is_bcmphy = !(readl(GPIO1_BASE_ADDR) & BIT(16));
+   clrbits_le32(mux, IOMUX_CONFIG_SION);
+
+   phy_node = fdt_node_offset_by_compatible(fdt_blob, -1, phy_compat);
+   if (phy_node < 0)
+   return 0;
+
+   /*
+* Update PHY MDC address in control DT based on the populated
+* PHY type. AR8031 is at address 0, BCM54213PE is at address 1.
+*/
+   fdt_setprop_inplace_u32((void *)fdt_blob, phy_node,
+   "reg", is_bcmphy ? 1 : 0);
+
+   return 0;
+}
diff --git a/board/data_modul/imx8mp_edm_sbc/imx8mp_data_modul_edm_sbc.c 
b/board/data_modul/imx8mp_edm_sbc/imx8mp_data_modul_edm_sbc.c
index 9fbbbc1b77e..f0f373aa280 100644
--- a/board/data_modul/imx8mp_edm_sbc/imx8mp_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mp_edm_sbc/imx8mp_data_modul_edm_sbc.c
@@ -5,11 +5,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,3 +67,51 @@ int board_late_init(void)
 
return 0;
 }
+
+int fdtdec_board_setup(const void *fdt_blob)
+{
+   const void __iomem *mux = (void __iomem *)IOMUXC_BASE_ADDR +
+   FIELD_GET(MUX_CTRL_OFS_MASK, MX8MP_PAD_ENET_MDC__ENET_QOS_MDC);
+   const char *phy_compat = "ethernet-phy-ieee802.3-c22";
+   bool is_bcmphy;
+   int phy_node;
+   int ret;
+
+   /* Do nothing if not i.MX8MP eDM SBC */
+   ret = fdt_node_check_compatible(fdt_blob, 0, 
"dmo,imx8mp-data-modul-edm-sbc");
+   if (ret)
+   return 0;
+
+   /*
+* If GPIO1_16 RGMII_MDC is HIGH, then R390 is populated.
+* 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.
+*/
+   setbits_le32(mux, IOMUX_CONFIG_SION);
+   is_bcmphy = 

[PATCH v2 2/2] efi_loader: provide tool to dump SMBIOS table

2024-01-01 Thread Heinrich Schuchardt
An EFI binary dmidump.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 

Specifying 'nocolor' as load option data suppresses colored output and
clearing of the screen.

Signed-off-by: Heinrich Schuchardt 
---
v2:
fix an incorrect variable usage when checking the result of memcmp
---
 lib/efi_loader/Makefile  |   7 +
 lib/efi_loader/dmidump.c | 595 +++
 2 files changed, 602 insertions(+)
 create mode 100644 lib/efi_loader/dmidump.c

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 24d33d5409..71880d330e 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -16,6 +16,8 @@ CFLAGS_boothart.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_boothart.o := $(CFLAGS_NON_EFI)
 CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
+CFLAGS_dmidump.o := $(CFLAGS_EFI) -Os -ffreestanding
+CFLAGS_REMOVE_dmidump.o := $(CFLAGS_NON_EFI)
 CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
 CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding
@@ -31,6 +33,11 @@ always += helloworld.efi
 targets += helloworld.o
 endif
 
+ifneq ($(CONFIG_GENERATE_SMBIOS_TABLE),)
+always += dmidump.efi
+targets += dmidump.o
+endif
+
 ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
 always += dtbdump.efi
 targets += dtbdump.o
diff --git a/lib/efi_loader/dmidump.c b/lib/efi_loader/dmidump.c
new file mode 100644
index 00..2a43a2808c
--- /dev/null
+++ b/lib/efi_loader/dmidump.c
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2023, Heinrich Schuchardt 
+ *
+ * dmidump.efi saves the SMBIOS table as file.
+ *
+ * Specifying 'nocolor' as load option data suppresses colored output and
+ * clearing of the screen.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define BUFFER_SIZE 64
+
+static struct efi_simple_text_output_protocol *cerr;
+static struct efi_simple_text_output_protocol *cout;
+static struct efi_simple_text_input_protocol *cin;
+static struct efi_boot_services *bs;
+static efi_handle_t handle;
+static struct efi_system_table *systable;
+static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+static const efi_guid_t smbios3_guid = SMBIOS3_TABLE_GUID;
+static const efi_guid_t loaded_image_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID;
+static const efi_guid_t guid_simple_file_system_protocol =
+   EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
+static const efi_guid_t efi_system_partition_guid = PARTITION_SYSTEM_GUID;
+static bool nocolor;
+
+/**
+ * color() - set foreground color
+ *
+ * @color: foreground color
+ */
+static void color(u8 color)
+{
+   if (!nocolor)
+   cout->set_attribute(cout, color | EFI_BACKGROUND_BLACK);
+}
+
+/**
+ * print() - print string
+ *
+ * @string:text
+ */
+static void print(u16 *string)
+{
+   cout->output_string(cout, string);
+}
+
+/**
+ * cls() - clear screen
+ */
+static void cls(void)
+{
+   if (nocolor)
+   print(u"\r\n");
+   else
+   cout->clear_screen(cout);
+}
+
+/**
+ * error() - print error string
+ *
+ * @string:error text
+ */
+static void error(u16 *string)
+{
+   color(EFI_LIGHTRED);
+   print(string);
+   color(EFI_LIGHTBLUE);
+}
+
+/**
+ * efi_input_yn() - get answer to yes/no question
+ *
+ * Return:
+ * y or Y
+ * EFI_SUCCESS
+ * n or N
+ * EFI_ACCESS_DENIED
+ * ESC
+ * EFI_ABORTED
+ */
+static efi_status_t efi_input_yn(void)
+{
+   struct efi_input_key key = {0};
+   efi_uintn_t index;
+   efi_status_t ret;
+
+   /* Drain the console input */
+   ret = cin->reset(cin, true);
+   for (;;) {
+   ret = bs->wait_for_event(1, >wait_for_key, );
+   if (ret != EFI_SUCCESS)
+   continue;
+   ret = cin->read_key_stroke(cin, );
+   if (ret != EFI_SUCCESS)
+   continue;
+   switch (key.scan_code) {
+   case 0x17: /* Escape */
+   return EFI_ABORTED;
+   default:
+   break;
+   }
+   /* Convert to lower case */
+   switch (key.unicode_char | 0x20) {
+   case 'y':
+   return EFI_SUCCESS;
+   case 'n':
+   return EFI_ACCESS_DENIED;
+   default:
+   break;
+   }
+   }
+}
+
+/**
+ * efi_input() - read string from console
+ *
+ * @buffer:input buffer
+ * 

[PATCH v2 1/2] smbios: smbios.h should not import ofnode.h

2024-01-01 Thread Heinrich Schuchardt
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 
---
v2:
new patch
---
 include/smbios.h| 6 +-
 lib/efi_loader/efi_smbios.c | 3 +++
 lib/smbios-parser.c | 3 +++
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/smbios.h b/include/smbios.h
index 49de32fec2..b507b9d9d7 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -8,7 +8,7 @@
 #ifndef _SMBIOS_H_
 #define _SMBIOS_H_
 
-#include 
+#include 
 
 /* SMBIOS spec version implemented */
 #define SMBIOS_MAJOR_VER   3
@@ -80,10 +80,6 @@ struct __packed smbios3_entry {
u64 struct_table_address;
 };
 
-/* These two structures should use the same amount of 16-byte-aligned space */
-static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
- ALIGN(16, sizeof(struct smbios3_entry)));
-
 /* BIOS characteristics */
 #define BIOS_CHARACTERISTICS_PCI_SUPPORTED (1 << 7)
 #define BIOS_CHARACTERISTICS_UPGRADEABLE   (1 << 11)
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index eb6d2ba43c..b2ec1f7919 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 const efi_guid_t smbios3_guid = SMBIOS3_TABLE_GUID;
 
diff --git a/lib/smbios-parser.c b/lib/smbios-parser.c
index b578c30840..b041592152 100644
--- a/lib/smbios-parser.c
+++ b/lib/smbios-parser.c
@@ -5,7 +5,10 @@
 
 #define LOG_CATEGORY   LOGC_BOOT
 
+#include 
 #include 
+#include 
+#include 
 
 static inline int verify_checksum(const struct smbios_entry *e)
 {
-- 
2.43.0



[PATCH v2 9/2] efi_loader: provide tool to dump SMBIOS table

2024-01-01 Thread Heinrich Schuchardt
An EFI binary dmidump.efi is provided that can be used to check the SMBIOS
table for consistency and to dump it as a file.

As a prerequisite remove superfluous include from smbios.h.

v2:
remove dm/ofnode.h from smbios.h
fix a wrong variable usage on dmidump.efi

Heinrich Schuchardt (2):
  smbios: smbios.h should not import ofnode.h
  efi_loader: provide tool to dump SMBIOS table

 include/smbios.h|   6 +-
 lib/efi_loader/Makefile |   7 +
 lib/efi_loader/dmidump.c| 595 
 lib/efi_loader/efi_smbios.c |   3 +
 lib/smbios-parser.c |   3 +
 5 files changed, 609 insertions(+), 5 deletions(-)
 create mode 100644 lib/efi_loader/dmidump.c

-- 
2.43.0



Re: [PATCH v5 04/12] smbios: Use SMBIOS 3.0 to support an address above 4GB

2024-01-01 Thread Heinrich Schuchardt

On 12/31/23 16:25, Simon Glass wrote:

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 
---

(no changes since v4)

Changes in v4:
- Check the start of the table rather than the end

Changes in v2:
- Check the end of the table rather than the start.

  include/smbios.h |  6 +-
  lib/smbios.c | 30 +-
  2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/include/smbios.h b/include/smbios.h
index e601283d293..77be58887a2 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -12,7 +12,7 @@

  /* SMBIOS spec version implemented */
  #define SMBIOS_MAJOR_VER  3
-#define SMBIOS_MINOR_VER   0
+#define SMBIOS_MINOR_VER   7

  enum {
SMBIOS_STR_MAX  = 64,   /* Maximum length allowed for a string */
@@ -80,6 +80,10 @@ struct __packed smbios3_entry {
u64 struct_table_address;
  };

+/* These two structures should use the same amount of 16-byte-aligned space */


I cannot see from where you take such a requirement.
By chance it is fulfilled by the current definitions.
If this a leftover from debugging we should remove it.

Best regards

Heinrich


+static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
+ ALIGN(16, sizeof(struct smbios3_entry)));
+
  /* BIOS characteristics */
  #define BIOS_CHARACTERISTICS_PCI_SUPPORTED(1 << 7)
  #define BIOS_CHARACTERISTICS_UPGRADEABLE  (1 << 11)
diff --git a/lib/smbios.c b/lib/smbios.c
index eea72670bd9..7f79d969c92 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -567,7 +567,11 @@ ulong write_smbios_table(ulong addr)
addr = ALIGN(addr, 16);
start_addr = addr;

-   addr += sizeof(struct smbios_entry);
+   /*
+* So far we don't know which struct will be used, but they both end
+* up using the same amount of 16-bit-aligned space
+*/
+   addr += max(sizeof(struct smbios_entry), sizeof(struct smbios3_entry));
addr = ALIGN(addr, 16);
tables = addr;

@@ -590,16 +594,32 @@ ulong write_smbios_table(ulong addr)
 * We must use a pointer here so things work correctly on sandbox. The
 * user of this table is not aware of the mapping of addresses to
 * sandbox's DRAM buffer.
+*
+* Check the address of the end of the tables. If it is above 4GB then
+* it is sensible to use SMBIOS3 even if the start of the table is below
+* 4GB (this case is very unlikely to happen in practice)
 */
table_addr = (ulong)map_sysmem(tables, 0);
-   if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX) {
+   if (sizeof(table_addr) > sizeof(u32) && addr >= (ulong)UINT_MAX) {
+   struct smbios3_entry *se;
/*
 * We need to put this >32-bit pointer into the table but the
 * field is only 32 bits wide.
 */
-   printf("WARNING: SMBIOS table_address overflow %llx\n",
-  (unsigned long long)table_addr);
-   addr = 0;
+   log_debug("WARNING: Using SMBIOS3.0 due to table-address overflow 
%lx\n",
+ table_addr);
+   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
+   memset(se, '\0', sizeof(struct smbios_entry));
+   memcpy(se->anchor, "_SM3_", 5);
+   se->length = sizeof(struct smbios3_entry);
+   se->major_ver = SMBIOS_MAJOR_VER;
+   se->minor_ver = SMBIOS_MINOR_VER;
+   se->doc_rev = 0;
+   se->entry_point_rev = 1;
+   se->max_struct_size = len;
+   se->struct_table_address = table_addr;
+   se->checksum = table_compute_checksum(se,
+   sizeof(struct smbios3_entry));
} else {
struct smbios_entry *se;





Please pull u-boot-dm next

2024-01-01 Thread Simon Glass
Hi Tom,

This is for -next

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/19131

https://dev.azure.com/simon0972/u-boot/_build/results?buildId=57=results


The following changes since commit 2b28c3b871cd5d55b19f0a86cef970139f8ab952:

  Merge patch series "Modernize U-Boot shell" (2023-12-28 14:38:25 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-next-1124

for you to fetch changes up to e266d2731145681a55d862360f1b61690b0c6820:

  bloblist: Update documentation and header comment (2023-12-31 07:21:02 -0700)


support propagating supernode properties with bootph schema
align bloblist with v0.9 of Firmware Handoff spec


Heinrich Schuchardt (2):
  buildman: type cotaining
  binman: used-before-assignment in ftest.py

Simon Glass (22):
  x86: coral: Align bootph SPI-flash subnodes with parent
  fdtgrep: Tidy up a few type warnings and comments
  fdtgrep: Correct ordering of flags
  fdtgrep: Correct references to fdt_find_regions()
  fdtgrep: Tidy up comment for h_include()
  fdtgrep: Simplify code to inverting the match
  fdtgrep: Move property checking into a function
  sandbox: Correct SPL condition for building devicetree
  fdtgrep: Allow propagating properties up to supernodes
  Makefile: Use the fdtgrep -u flag
  bloblist: Update the tag numbering
  bloblist: Adjust API to align in powers of 2
  bloblist: Change the magic value
  bloblist: Set version to 1
  bloblist: Access record hdr_size and tag via a function
  bloblist: Drop spare value from bloblist record
  bloblist: Checksum the entire bloblist
  bloblist: Handle alignment with a void entry
  bloblist: Reduce blob-header size
  bloblist: Adjust the bloblist header
  bloblist: Add alignment to bloblist_new()
  bloblist: Update documentation and header comment

 arch/x86/dts/chromebook_coral.dts |   6 ++-
 arch/x86/lib/tables.c |   3 +-
 common/bloblist.c | 205
-
 doc/develop/bloblist.rst  |   4 +-
 include/bloblist.h| 166
+-
 scripts/Makefile.lib  |  13 ++-
 scripts/Makefile.spl  |   2 +-
 test/bloblist.c   | 105
+++---
 tools/binman/ftest.py |  20 +++---
 tools/buildman/boards.py  |   2 +-
 tools/fdtgrep.c   | 123
++

Regards,
Simon


Re: [PATCH v5 01/11] bloblist: Update the tag numbering

2024-01-01 Thread Simon Glass
From: Simon Glass 

Align bloblist tags with the FW handoff spec v0.9.
The most common ones are from 0.
TF related ones are from 0x100.
All non-standard ones from 0xfff000.

Added new defined tags:
BLOBLISTT_OPTEE_PAGABLE_PART for TF.
BLOBLISTT_TPM_EVLOG and BLOBLISTT_TPM_CRB_BASE for TPM.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- Align bloblist tags to FW handoff spec v0.9.
Changes in v3
- Add TPM related tags

 common/bloblist.c  | 18 ++---
 include/bloblist.h | 67 +-
 test/bloblist.c|  4 +--
 3 files changed, 52 insertions(+), 37 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 02/11] bloblist: Adjust API to align in powers of 2

2024-01-01 Thread Simon Glass
From: Simon Glass 

The updated bloblist structure stores the alignment as a power-of-two
value in its structures. Adjust the API to use this, to avoid needing to
calling ilog2().
Update the bloblist alignment from 16 bytes to 8 bytes.
Drop a stale comment while we are here.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
---
Changes in v2
- Update the bloblist alignment to align to FW handoff spec v0.9.
Changes in v4
- Update the commit message.

 arch/x86/lib/tables.c |  3 ++-
 common/bloblist.c | 24 +++-
 include/bloblist.h| 12 +++-
 test/bloblist.c   |  4 ++--
 4 files changed, 22 insertions(+), 21 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 03/11] bloblist: Change the magic value

2024-01-01 Thread Simon Glass
From: Simon Glass 

This uses a new value with spec v0.9 so change it.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Simon Glass 
---
Changes in v2
- Update the bloblist magic to align to FW handoff spec v0.9.
Changes in v3
- Update the bloblist magic to align to FW handoff spec up to commit 3592349.

 include/bloblist.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 06/11] bloblist: Checksum the entire bloblist

2024-01-01 Thread Simon Glass
From: Simon Glass 

Use a sinple 8-bit checksum for bloblist, as specified by the spec
version 0.9.
Spec v0.9 specifies that the entire bloblist area is checksummed,
including unused portions. Update the code to follow this.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v4
- Patch #7 and #8 from v3 are squashed into this patch.

 common/bloblist.c  | 13 -
 include/bloblist.h |  5 ++---
 test/bloblist.c| 10 --
 3 files changed, 14 insertions(+), 14 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 04/11] bloblist: Set version to 1

2024-01-01 Thread Simon Glass
From: Simon Glass 

The new bloblist for v0.9 has version 1 so update this value.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Simon Glass 
---
 include/bloblist.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 05/11] bloblist: Access record hdr_size and tag via a function

2024-01-01 Thread Simon Glass
From: Simon Glass 

Convert accesses to tag and hdr_size via function for grouping tag and
hdr_size together later.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v3
- Update commit message.

 common/bloblist.c | 38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 07/11] bloblist: Handle alignment with a void entry

2024-01-01 Thread Simon Glass
From: Simon Glass 

Rather than setting the alignment using the header size, add an entirely
new entry to cover the gap left by the alignment.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
---
Changes in v5
- Optimize how to calculate the new allocated size.

 common/bloblist.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 08/11] bloblist: Reduce blob-header size

2024-01-01 Thread Simon Glass
From: Simon Glass 

The v0.9 spec provides for an 8-byte header for each blob, with fewer
fields.
Drop spare value from bloblist record header.
The blob data start address should be aligned to the alignment specified
by the bloblist header.
Update the implementation to match this.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
---
Changes in v2
- Update the blob start address to align to the alignment required by
  the bloblist header.
- Define the macros of bloblist header size and bloblist record header
  size as the size of their structures.
Changes in v3
- Update the calculation of the bloblist record offset to make sure
  that each bloblist record data section start address fulfills the
  alignment requirement.
- Update commit message.
Changes in v5
- Squash #6 from v4 into this patch.

 common/bloblist.c  | 24 +++-
 include/bloblist.h | 34 ++
 test/bloblist.c| 16 
 3 files changed, 45 insertions(+), 29 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 09/11] bloblist: Adjust the bloblist header

2024-01-01 Thread Simon Glass
From: Simon Glass 

The v0.9 spec provides for a 24-byte header. Update the implementation
to match this.
Rename the fields of the bloblist header to align to the spec.
Adds an alignment field into the bloblist header.
Update the related bloblist APIs and UT testcases.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
---
Changes in v3
- Update the bloblist header to align to FW handoff spec up to commit 3592349.
- Update the related testcases.
Changes in v4
- Patch #14 from v3 is squashed into this patch.

 common/bloblist.c  | 86 +++---
 include/bloblist.h | 44 ++--
 test/bloblist.c| 37 ++--
 3 files changed, 95 insertions(+), 72 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 10/11] bloblist: Add alignment to bloblist_new()

2024-01-01 Thread Simon Glass
From: Simon Glass 

Allow the alignment to be specified when creating a bloblist.

Signed-off-by: Simon Glass 
Co-developed-by: Raymond Mao 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
Changes in v3
- Keep the flag argument to align to FW handoff spec up to commit 3592349.
Changes in v4
- Minor fix to use a full ternary operator in function bloblist_new().

 common/bloblist.c  |  5 +++--
 include/bloblist.h |  3 ++-
 test/bloblist.c| 40 ++--
 3 files changed, 27 insertions(+), 21 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v5 11/11] bloblist: Update documentation and header comment

2024-01-01 Thread Simon Glass
From: Simon Glass 

Align the documentation with the v0.9 spec.

Signed-off-by: Simon Glass 
Signed-off-by: Raymond Mao 
Reviewed-by: Ilias Apalodimas 
---
 doc/develop/bloblist.rst | 4 +++-
 include/bloblist.h   | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 1/1] buildman: type cotaining

2024-01-01 Thread Simon Glass
On Fri, 15 Dec 2023 at 02:42, Heinrich Schuchardt
 wrote:
>
> %s/cotaining/containing/
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  tools/buildman/boards.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied to u-boot-dm/next, thanks!


Re: [PATCH 01/10] x86: coral: Align bootph SPI-flash subnodes with parent

2024-01-01 Thread Simon Glass
The subnode has different tags from the parents, which is not correct.
Fix the subnode.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/chromebook_coral.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 1/1] binman: used-before-assignment in ftest.py

2024-01-01 Thread Simon Glass
On Fri, 15 Dec 2023 at 16:26, Heinrich Schuchardt
 wrote:
>
> Pytest 7.4.3 complains if a variable is used in a finally clause without
> having been initialized before the try clause.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  tools/binman/ftest.py | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm/next, thanks!


Re: [PATCH 04/10] fdtgrep: Correct references to fdt_find_regions()

2024-01-01 Thread Simon Glass
The function name is actually fdtgrep_find_regions() so update the name
in comments accordinging.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 05/10] fdtgrep: Tidy up comment for h_include()

2024-01-01 Thread Simon Glass
Copy the comment from fdt_first_region() so that it is clear what value
this function returns.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 02/10] fdtgrep: Tidy up a few type warnings and comments

2024-01-01 Thread Simon Glass
Align the code with the upstream version at fdt-tools which had a few
tweaks before being applied.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 06/10] fdtgrep: Simplify code to inverting the match

2024-01-01 Thread Simon Glass
The code to invert the match in h_include() is a bit convoluted.
Simplify it by using disp->invert only once.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 03/10] fdtgrep: Correct ordering of flags

2024-01-01 Thread Simon Glass
Two of the flags are out of order, so fix this.

Also adjust the ordering of one flag in the main switch()

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 07/10] fdtgrep: Move property checking into a function

2024-01-01 Thread Simon Glass
The h_include() function includes a piece which checks if a node
contains a property being searched for. Move this into its own
function to reduce the size of the h_include() function.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 48 +++-
 1 file changed, 35 insertions(+), 13 deletions(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH 08/10] sandbox: Correct SPL condition for building devicetree

2024-01-01 Thread Simon Glass
With sandbox, CONFIG_SANDBOX is y so the current rule ends up building
the devicetree for only those SPL builds where it is unwanted.

Correct the condition. This allows sandbox_vpl to produce a
u-boot-vpl.dtb file.

Fixes: e7fb789612e ("sandbox: Remove OF_HOSTFILE")

Signed-off-by: Simon Glass 
---

 scripts/Makefile.spl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH v2 10/10] Makefile: Use the fdtgrep -u flag

2024-01-01 Thread Simon Glass
On Tue, Dec 19, 2023 at 07:21:25AM -0700, Simon Glass wrote:

> Use this flag so that the bootph binding is obeyed correctly.
>
> Add a comment about what is going on.
>
> Signed-off-by: Simon Glass 
> Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/12

Reviewed-by: Tom Rini 

-- 
Tom

Applied to u-boot-dm/next, thanks!


Re: [PATCH 09/10] fdtgrep: Allow propagating properties up to supernodes

2024-01-01 Thread Simon Glass
The existing bootph binding is defined such that properties in a
subnode are also implied in the supernode also, as in this example:

   buttons {
  /* bootph,pre-ram is implied by btn1 */
  compatible = "gpio-keys";

  btn1 {
 bootph,pre-ram;
 gpios = <_a 3 0>;
 label = "button1";
 linux,code = ;
  };

Provide an option to implement this in fdtgrep.

Signed-off-by: Simon Glass 
---

 tools/fdtgrep.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!


Re: [PATCH] rockchip: rk3568: add support of all UART

2024-01-01 Thread Jonas Karlman
Hi Arseniy,

On 2024-01-01 14:43, Arseniy Mescheryakov wrote:
> Thanks for the answer.
> I think developers should have the opportunity to configure UART from
> the u-boot directly (via configuration) without any additional
> proprietary blobs.

Sure and it should already be possible using existing Kconfig options
and devicetree, e.g to use uart5 on rk356x:

CONFIG_SPL_DM_SERIAL=y
CONFIG_SPL_PINCTRL=y
CONFIG_SPL_PINCTRL_ROCKCHIP=y
CONFIG_DEBUG_UART_BASE=0xfe69

and

/ {
chosen {
stdout-path = 
};
};

_xfer {
bootph-all;
};

 {
bootph-all;
clock-frequency = <2400>;
pinctrl-0 = <_xfer>;
status = "okay";
};

That should make the pinctrl driver configure correct iomux for uart5.

And if you also want to have working console output to uart5 from ddr
init and TF-A blobs you must use rkbin tools/ddrbin_tool to configure
the proprietary blobs required to boot rk356x boards.

> 
> There is 
> https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3568/rk3568.c
> , that has same functionality as my patch, but it has a lot of code
> duplication and because of it i add a lot of macroses.
> Maybe there is any target that has a lot of UARTs instances and its
> configuration going in other way than mine and hasn't a lot of code
> duplication.

Correct, the vendor U-Boot contain code that can init uart iomux for all
different uart and iomux combos. With a proper devicetree and driver
model it should not be needed.

Also with all current supported rk356x boards using the default uart2
for serial console there should not really be a need for adding this
code, or do you have a board/device in mind where this is needed?

Regards,
Jonas

> 
> 
> On Sun, Dec 31, 2023 at 3:31 AM Jonas Karlman  wrote:
>>
>> Hi Arseniy,
>>
>> On 2023-12-30 12:20, Arseniy Meshcheryakov wrote:
>>> This patch add support of all UARTs for rk3568, which can be used in 
>>> console.
>>
>> Please explain why this is needed, on rk35xx the rockchip ddr init blob
>> is required and can setup correct uart iomux with rkbin/tools/ddrbin_tool 
>> [1].
>>
>> And U-Boot SPL and proper can use the serial, gpio and pinctrl drivers
>> to configure correct uart iomux for any board not using uart2.
>>
>> We should be able to remove the current code that configures uart2 M0
>> iomux and still have a working debug console.
>>
>> Please provide more details why and on what board you need this.
>>
>> [1] 
>> https://github.com/rockchip-linux/rkbin/blob/master/tools/ddrbin_tool_user_guide.txt#L72-L75
>>
>>>
>>> Signed-off-by: Arseniy Meshcheryakov 
>>> ---
>>>  arch/arm/mach-rockchip/rk3568/rk3568.c | 470 -
>>>  1 file changed, 452 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c 
>>> b/arch/arm/mach-rockchip/rk3568/rk3568.c
>>> index 69ef19cc85..f79b47ee5b 100644
>>> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
>>> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
>>> @@ -34,26 +34,468 @@
>>>  #define CPU_GRF_BASE 0xfdc3
>>>  #define GRF_CORE_PVTPLL_CON0 (0x10)
>>>
>>> -/* PMU_GRF_GPIO0D_IOMUX_L */
>>>  enum {
>>> + /* PMU_GRF_GPIO0C_IOMUX_L */
>>> + GPIO0C1_SHIFT   = 4,
>>> + GPIO0C1_MASK= GENMASK(6, 4),
>>> + GPIO0C1_GPIO= 0,
>>> + GPIO0C1_UART0_M0_TX = 3,
>>> +
>>> + GPIO0C0_SHIFT   = 0,
>>> + GPIO0C0_MASK= GENMASK(2, 0),
>>> + GPIO0C0_GPIO= 0,
>>> + GPIO0C0_UART0_M0_RX = 3,
>>> +
>>> + /* PMU_GRF_GPIO0D_IOMUX_L */
>>>   GPIO0D1_SHIFT   = 4,
>>>   GPIO0D1_MASK= GENMASK(6, 4),
>>>   GPIO0D1_GPIO= 0,
>>> - GPIO0D1_UART2_TXM0,
>>> + GPIO0D1_UART2_M0_TX,
>>>
>>>   GPIO0D0_SHIFT   = 0,
>>>   GPIO0D0_MASK= GENMASK(2, 0),
>>>   GPIO0D0_GPIO= 0,
>>> - GPIO0D0_UART2_RXM0,
>>> -};
>>> + GPIO0D0_UART2_M0_RX,
>>> +
>>> + /* GRF_GPIO1A_IOMUX_L */
>>> + GPIO1A1_SHIFT   = 4,
>>> + GPIO1A1_MASK= GENMASK(6, 4),
>>> + GPIO1A1_GPIO= 0,
>>> + GPIO1A1_UART3_M0_TX = 2,
>>> +
>>> + GPIO1A0_SHIFT   = 0,
>>> + GPIO1A0_MASK= GENMASK(2, 0),
>>> + GPIO1A0_GPIO= 0,
>>> + GPIO1A0_UART3_M0_RX = 2,
>>> +
>>> + /* GRF_GPIO1A_IOMUX_H */
>>> + GPIO1A6_SHIFT   = 8,
>>> + GPIO1A6_MASK= GENMASK(10, 8),
>>> + GPIO1A6_GPIO= 0,
>>> + GPIO1A6_UART4_M0_TX = 2,
>>> +
>>> +
>>> + GPIO1A4_SHIFT   = 0,
>>> + GPIO1A4_MASK= GENMASK(2, 0),
>>> + GPIO1A4_GPIO= 0,
>>> + GPIO1A4_UART4_M0_RX = 2,
>>> +
>>> + /* GRF_GPIO1D_IOMUX_H */
>>> + GPIO1D6_SHIFT   = 8,
>>> + GPIO1D6_MASK= GENMASK(10, 8),
>>> + GPIO1D6_GPIO= 0,
>>> + GPIO1D6_UART2_M1_RX = 2,
>>> + 

Re: [PATCH] rockchip: rk3568: add support of all UART

2024-01-01 Thread Arseniy Mescheryakov
Thanks for the answer.
I think developers should have the opportunity to configure UART from
the u-boot directly (via configuration) without any additional
proprietary blobs.

There is 
https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3568/rk3568.c
, that has same functionality as my patch, but it has a lot of code
duplication and because of it i add a lot of macroses.
Maybe there is any target that has a lot of UARTs instances and its
configuration going in other way than mine and hasn't a lot of code
duplication.


On Sun, Dec 31, 2023 at 3:31 AM Jonas Karlman  wrote:
>
> Hi Arseniy,
>
> On 2023-12-30 12:20, Arseniy Meshcheryakov wrote:
> > This patch add support of all UARTs for rk3568, which can be used in 
> > console.
>
> Please explain why this is needed, on rk35xx the rockchip ddr init blob
> is required and can setup correct uart iomux with rkbin/tools/ddrbin_tool [1].
>
> And U-Boot SPL and proper can use the serial, gpio and pinctrl drivers
> to configure correct uart iomux for any board not using uart2.
>
> We should be able to remove the current code that configures uart2 M0
> iomux and still have a working debug console.
>
> Please provide more details why and on what board you need this.
>
> [1] 
> https://github.com/rockchip-linux/rkbin/blob/master/tools/ddrbin_tool_user_guide.txt#L72-L75
>
> >
> > Signed-off-by: Arseniy Meshcheryakov 
> > ---
> >  arch/arm/mach-rockchip/rk3568/rk3568.c | 470 -
> >  1 file changed, 452 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c 
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index 69ef19cc85..f79b47ee5b 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -34,26 +34,468 @@
> >  #define CPU_GRF_BASE 0xfdc3
> >  #define GRF_CORE_PVTPLL_CON0 (0x10)
> >
> > -/* PMU_GRF_GPIO0D_IOMUX_L */
> >  enum {
> > + /* PMU_GRF_GPIO0C_IOMUX_L */
> > + GPIO0C1_SHIFT   = 4,
> > + GPIO0C1_MASK= GENMASK(6, 4),
> > + GPIO0C1_GPIO= 0,
> > + GPIO0C1_UART0_M0_TX = 3,
> > +
> > + GPIO0C0_SHIFT   = 0,
> > + GPIO0C0_MASK= GENMASK(2, 0),
> > + GPIO0C0_GPIO= 0,
> > + GPIO0C0_UART0_M0_RX = 3,
> > +
> > + /* PMU_GRF_GPIO0D_IOMUX_L */
> >   GPIO0D1_SHIFT   = 4,
> >   GPIO0D1_MASK= GENMASK(6, 4),
> >   GPIO0D1_GPIO= 0,
> > - GPIO0D1_UART2_TXM0,
> > + GPIO0D1_UART2_M0_TX,
> >
> >   GPIO0D0_SHIFT   = 0,
> >   GPIO0D0_MASK= GENMASK(2, 0),
> >   GPIO0D0_GPIO= 0,
> > - GPIO0D0_UART2_RXM0,
> > -};
> > + GPIO0D0_UART2_M0_RX,
> > +
> > + /* GRF_GPIO1A_IOMUX_L */
> > + GPIO1A1_SHIFT   = 4,
> > + GPIO1A1_MASK= GENMASK(6, 4),
> > + GPIO1A1_GPIO= 0,
> > + GPIO1A1_UART3_M0_TX = 2,
> > +
> > + GPIO1A0_SHIFT   = 0,
> > + GPIO1A0_MASK= GENMASK(2, 0),
> > + GPIO1A0_GPIO= 0,
> > + GPIO1A0_UART3_M0_RX = 2,
> > +
> > + /* GRF_GPIO1A_IOMUX_H */
> > + GPIO1A6_SHIFT   = 8,
> > + GPIO1A6_MASK= GENMASK(10, 8),
> > + GPIO1A6_GPIO= 0,
> > + GPIO1A6_UART4_M0_TX = 2,
> > +
> > +
> > + GPIO1A4_SHIFT   = 0,
> > + GPIO1A4_MASK= GENMASK(2, 0),
> > + GPIO1A4_GPIO= 0,
> > + GPIO1A4_UART4_M0_RX = 2,
> > +
> > + /* GRF_GPIO1D_IOMUX_H */
> > + GPIO1D6_SHIFT   = 8,
> > + GPIO1D6_MASK= GENMASK(10, 8),
> > + GPIO1D6_GPIO= 0,
> > + GPIO1D6_UART2_M1_RX = 2,
> > + GPIO1D6_UART6_M1_RX,
> > +
> > + GPIO1D5_SHIFT   = 4,
> > + GPIO1D5_MASK= GENMASK(6, 4),
> > + GPIO1D5_GPIO= 0,
> > + GPIO1D5_UART2_M1_TX = 2,
> > + GPIO1D5_UART6_M1_TX,
> > +
> > + /* GRF_GPIO2A_IOMUX_L */
> > + GPIO2A3_SHIFT   = 12,
> > + GPIO2A3_MASK= GENMASK(14, 12),
> > + GPIO2A3_GPIO= 0,
> > + GPIO2A3_UART6_M0_RX = 3,
> > +
> > + GPIO2A2_SHIFT   = 8,
> > + GPIO2A2_MASK= GENMASK(10, 8),
> > + GPIO2A2_GPIO= 0,
> > + GPIO2A2_UART5_M0_TX = 3,
> > +
> > + GPIO2A1_SHIFT   = 4,
> > + GPIO2A1_MASK= GENMASK(6, 4),
> > + GPIO2A1_GPIO= 0,
> > + GPIO2A1_UART5_M0_RX = 3,
> > +
> > + /* GRF_GPIO2A_IOMUX_H */
> > + GPIO2A7_SHIFT   = 12,
> > + GPIO2A7_MASK= GENMASK(14, 12),
> > + GPIO2A7_GPIO= 0,
> > + GPIO2A7_UART9_M0_RX = 3,
> > +
> > + GPIO2A6_SHIFT   = 8,
> > + GPIO2A6_MASK= GENMASK(10, 8),
> > + GPIO2A6_GPIO= 0,
> > + GPIO2A6_UART7_M0_TX = 3,
> > +
> > + GPIO2A5_SHIFT   = 4,
> > + 

Re: [PATCH v5 08/12] smbios: Drop support for SMBIOS2 tables

2024-01-01 Thread Peter Robinson
On Sun, Dec 31, 2023 at 3:26 PM Simon Glass  wrote:
>
> 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 
Reviewed-by: Peter Robinson 

It's also worth noting here the aarch64 Server Base Boot Requirements
(SBBR) has required SMBIOS v3 since version 1.0 of the spec [1].

[1] https://documentation-service.arm.com/static/5fb7e5adca04df4095c1d64d

> ---
>
> Changes in v5:
> - Add new patch to drop support for SMBIOS2 tables
>
>  lib/smbios.c | 76 
>  1 file changed, 17 insertions(+), 59 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index cfd451e4088..d9d52bd58d7 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -545,13 +545,12 @@ ulong write_smbios_table(ulong addr)
>  {
> ofnode parent_node = ofnode_null();
> ulong table_addr, start_addr;
> +   struct smbios3_entry *se;
> struct smbios_ctx ctx;
> ulong tables;
> int len = 0;
> int max_struct_size = 0;
> int handle = 0;
> -   char *istart;
> -   int isize;
> int i;
>
> ctx.node = ofnode_null();
> @@ -565,12 +564,8 @@ ulong write_smbios_table(ulong addr)
>
> start_addr = addr;
>
> -   /*
> -* So far we don't know which struct will be used, but they both end
> -* up using the same amount of 16-bit-aligned space
> -*/
> -   addr += max(sizeof(struct smbios_entry), sizeof(struct 
> smbios3_entry));
> -   addr = ALIGN(addr, 16);
> +   /* move past the (so-far-unwritten) header to start writing structs */
> +   addr = ALIGN(addr + sizeof(struct smbios3_entry), 16);
> tables = addr;
>
> /* populate minimum required tables */
> @@ -592,59 +587,22 @@ ulong write_smbios_table(ulong addr)
>  * We must use a pointer here so things work correctly on sandbox. The
>  * user of this table is not aware of the mapping of addresses to
>  * sandbox's DRAM buffer.
> -*
> -* Check the address of the end of the tables. If it is above 4GB then
> -* it is sensible to use SMBIOS3 even if the start of the table is 
> below
> -* 4GB (this case is very unlikely to happen in practice)
>  */
> table_addr = (ulong)map_sysmem(tables, 0);
> -   if (sizeof(table_addr) > sizeof(u32) && addr >= (ulong)UINT_MAX) {
> -   struct smbios3_entry *se;
> -   /*
> -* We need to put this >32-bit pointer into the table but the
> -* field is only 32 bits wide.
> -*/
> -   log_debug("WARNING: Using SMBIOS3.0 due to table-address 
> overflow %lx\n",
> - table_addr);
> -   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> -   memset(se, '\0', sizeof(struct smbios_entry));
> -   memcpy(se->anchor, "_SM3_", 5);
> -   se->length = sizeof(struct smbios3_entry);
> -   se->major_ver = SMBIOS_MAJOR_VER;
> -   se->minor_ver = SMBIOS_MINOR_VER;
> -   se->doc_rev = 0;
> -   se->entry_point_rev = 1;
> -   se->max_struct_size = len;
> -   se->struct_table_address = table_addr;
> -   se->checksum = table_compute_checksum(se,
> -   sizeof(struct smbios3_entry));
> -   } else {
> -   struct smbios_entry *se;
> -
> -   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> -   memset(se, '\0', sizeof(struct smbios_entry));
> -   memcpy(se->anchor, "_SM_", 4);
> -   se->length = sizeof(struct smbios_entry);
> -   se->major_ver = SMBIOS_MAJOR_VER;
> -   se->minor_ver = SMBIOS_MINOR_VER;
> -   se->max_struct_size = max_struct_size;
> -   memcpy(se->intermediate_anchor, "_DMI_", 5);
> -   se->struct_table_length = len;
> -
> -   se->struct_table_address = table_addr;
> -
> -   se->struct_count = handle;
> -
> -   /* calculate checksums */
> -   istart = (char *)se + SMBIOS_INTERMEDIATE_OFFSET;
> -   isize = sizeof(struct smbios_entry) -
> -   SMBIOS_INTERMEDIATE_OFFSET;
> -   se->intermediate_checksum = table_compute_checksum(istart,
> -  isize);
> -   se->checksum = table_compute_checksum(se,
> - sizeof(struct smbios_entry));
> -   unmap_sysmem(se);
> -   }
> +
> +   /* now go back and write the SMBIOS3 header */
> +   se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> +   memset(se, 

[PATCH 1/1] efi_loader: provide tool to dump SMBIOS table

2024-01-01 Thread Heinrich Schuchardt
An EFI binary dmidump.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 

Specifying 'nocolor' as load option data suppresses colored output and
clearing of the screen.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/Makefile  |   7 +
 lib/efi_loader/dmidump.c | 596 +++
 2 files changed, 603 insertions(+)
 create mode 100644 lib/efi_loader/dmidump.c

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 24d33d5409..71880d330e 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -16,6 +16,8 @@ CFLAGS_boothart.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_boothart.o := $(CFLAGS_NON_EFI)
 CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
+CFLAGS_dmidump.o := $(CFLAGS_EFI) -Os -ffreestanding
+CFLAGS_REMOVE_dmidump.o := $(CFLAGS_NON_EFI)
 CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
 CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
 CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding
@@ -31,6 +33,11 @@ always += helloworld.efi
 targets += helloworld.o
 endif
 
+ifneq ($(CONFIG_GENERATE_SMBIOS_TABLE),)
+always += dmidump.efi
+targets += dmidump.o
+endif
+
 ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
 always += dtbdump.efi
 targets += dtbdump.o
diff --git a/lib/efi_loader/dmidump.c b/lib/efi_loader/dmidump.c
new file mode 100644
index 00..e90d81058c
--- /dev/null
+++ b/lib/efi_loader/dmidump.c
@@ -0,0 +1,596 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2023, Heinrich Schuchardt 
+ *
+ * dmidump.efi saves the SMBIOS table as file.
+ *
+ * Specifying 'nocolor' as load option data suppresses colored output and
+ * clearing of the screen.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define BUFFER_SIZE 64
+
+static struct efi_simple_text_output_protocol *cerr;
+static struct efi_simple_text_output_protocol *cout;
+static struct efi_simple_text_input_protocol *cin;
+static struct efi_boot_services *bs;
+static efi_handle_t handle;
+static struct efi_system_table *systable;
+static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+static const efi_guid_t smbios3_guid = SMBIOS3_TABLE_GUID;
+static const efi_guid_t loaded_image_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID;
+static const efi_guid_t guid_simple_file_system_protocol =
+   EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
+static const efi_guid_t efi_system_partition_guid = PARTITION_SYSTEM_GUID;
+static bool nocolor;
+
+/**
+ * color() - set foreground color
+ *
+ * @color: foreground color
+ */
+static void color(u8 color)
+{
+   if (!nocolor)
+   cout->set_attribute(cout, color | EFI_BACKGROUND_BLACK);
+}
+
+/**
+ * print() - print string
+ *
+ * @string:text
+ */
+static void print(u16 *string)
+{
+   cout->output_string(cout, string);
+}
+
+/**
+ * cls() - clear screen
+ */
+static void cls(void)
+{
+   if (nocolor)
+   print(u"\r\n");
+   else
+   cout->clear_screen(cout);
+}
+
+/**
+ * error() - print error string
+ *
+ * @string:error text
+ */
+static void error(u16 *string)
+{
+   color(EFI_LIGHTRED);
+   print(string);
+   color(EFI_LIGHTBLUE);
+}
+
+/**
+ * efi_input_yn() - get answer to yes/no question
+ *
+ * Return:
+ * y or Y
+ * EFI_SUCCESS
+ * n or N
+ * EFI_ACCESS_DENIED
+ * ESC
+ * EFI_ABORTED
+ */
+static efi_status_t efi_input_yn(void)
+{
+   struct efi_input_key key = {0};
+   efi_uintn_t index;
+   efi_status_t ret;
+
+   /* Drain the console input */
+   ret = cin->reset(cin, true);
+   for (;;) {
+   ret = bs->wait_for_event(1, >wait_for_key, );
+   if (ret != EFI_SUCCESS)
+   continue;
+   ret = cin->read_key_stroke(cin, );
+   if (ret != EFI_SUCCESS)
+   continue;
+   switch (key.scan_code) {
+   case 0x17: /* Escape */
+   return EFI_ABORTED;
+   default:
+   break;
+   }
+   /* Convert to lower case */
+   switch (key.unicode_char | 0x20) {
+   case 'y':
+   return EFI_SUCCESS;
+   case 'n':
+   return EFI_ACCESS_DENIED;
+   default:
+   break;
+   }
+   }
+}
+
+/**
+ * efi_input() - read string from console
+ *
+ * @buffer:input buffer
+ * @buffer_size:   buffer size
+ * Return: status code
+ */
+static 

[PATCH 1/1] x86: all firmware tables must be paragraph aligned

2024-01-01 Thread Heinrich Schuchardt
On qemu-x86_64_defconfig the following was observed:

=> efidebug tables
000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table

The SMBIOS configuration table does not point to a paragraph aligned
address. The reason is that in write_tables() rom_addr is not aligned and
copied to gd->arch.smbios_start.

The Simple Firmware Interface requires that the SFI table is paragraph
aligned but our code does not guarantee this.

As all tables written in write_tables() must be paragraph aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().

Add paragraph alignment in write_tables().

Signed-off-by: Heinrich Schuchardt 
---
 arch/x86/lib/tables.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 5b5070f7ca..89d4d30a6a 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -97,6 +97,8 @@ int write_tables(void)
int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
u32 rom_table_end;
 
+   rom_addr = ALIGN(rom_addr, 16);
+
if (!strcmp("smbios", table->name))
gd->arch.smbios_start = rom_addr;
 
-- 
2.43.0



Re: [PATCH v5 12/12] efi: Correct smbios-table installation

2024-01-01 Thread Heinrich Schuchardt

On 1/1/24 01:37, Simon Glass wrote:

Hi Heinrich,

On Sun, Dec 31, 2023 at 9:27 AM Heinrich Schuchardt  wrote:


On 12/31/23 16:25, Simon Glass wrote:

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 


In patch 11/12 you changed the address fields in ACPI tables from
sandbox virtual addresses to pointers. Do you plan to do the same for
SMBIOS?


I haven't looked at it, but could if it would help. Are you planning
to add an EFI test app for sandbox?


Yes, we need a test checking that the SMBIOS protocol is correctly
installed. A tool like dtbdump.efi (lib/efi_loader/dtbdump.efi) would
allow to dump the SMBIOS table to file and then use dmidecode to check
the tables for consistency.

Best regards

Heinrich