[PATCH v5 2/2] xilinx: board: Add support to pick bootscr address from DT
From: Algapally Santosh Sagar
The bootscript is expected at a default address specific to each
platform.
When high speed memory like Programmable Logic Double Data Rate RAM
(PL DDR RAM) or Higher Bandwidth Memory RAM (HBM) is used the boot.scr
may be loaded at a different offset. The offset needs to be set through
setenv. Due to the default values in some cases the boot.scr is falling
in between the kernel partition.
The bootscript address or the bootscript offset is fetched directly from
the DT and updated in the environment making it easier for automated
flows.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Michal Simek
---
(no changes since v3)
Changes in v3:
- Rename get_bootscript_address() to ofnode_read_bootscript_address()
and move it to common location
- Fix alignments
Changes in v2:
- s/bootscr-offset-from-ram-start/bootscr-ram-offset/
- Aligned with https://github.com/devicetree-org/dt-schema/pull/105
board/xilinx/common/board.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 906d5e3c2d7c..b3fb6acc25a3 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -414,9 +414,25 @@ int board_late_init_xilinx(void)
if (!IS_ENABLED(CONFIG_MICROBLAZE)) {
ulong scriptaddr;
-
- scriptaddr = env_get_hex("scriptaddr", 0);
- ret |= env_set_hex("scriptaddr", gd->ram_base + scriptaddr);
+ u64 bootscr_address;
+ u64 bootscr_offset;
+
+ /* Fetch bootscr_address/bootscr_offset from DT and update */
+ if (!ofnode_read_bootscript_address(&bootscr_address,
+ &bootscr_offset)) {
+ if (bootscr_offset)
+ ret |= env_set_hex("scriptaddr",
+ gd->ram_base +
+ bootscr_offset);
+ else
+ ret |= env_set_hex("scriptaddr",
+ bootscr_address);
+ } else {
+ /* Update scriptaddr(bootscr offset) from env */
+ scriptaddr = env_get_hex("scriptaddr", 0);
+ ret |= env_set_hex("scriptaddr",
+ gd->ram_base + scriptaddr);
+ }
}
if (IS_ENABLED(CONFIG_ARCH_ZYNQ) || IS_ENABLED(CONFIG_MICROBLAZE))
--
2.36.1
[PATCH v5 1/2] dm: core: ofnode: Add ofnode_read_bootscript_address()
ofnode_read_bootscript_address() reads bootscript address from
/options/u-boot DT node. bootscr-address or bootscr-ram-offset properties
are read and values are filled. bootscr-address has higher priority than
bootscr-ram-offset and the only one should be described in DT.
Also add test to cover this new function.
Reviewed-by: Simon Glass
Signed-off-by: Michal Simek
---
Changes in v5:
- CI loop found some issues. Missing errno.h, multiple
ofnode_read_bootscript_address() because of missing static inline for !DM
cases
Changes in v4:
- Update ofnode test based on review from Simon
Changes in v3:
- new patch in this series
arch/sandbox/dts/test.dts | 7 +++
drivers/core/ofnode.c | 25 +
include/dm/ofnode.h | 26 ++
test/dm/ofnode.c | 14 ++
4 files changed, 72 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f351d5cb84b0..84879cc31ac0 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -79,6 +79,13 @@
};
};
+ options {
+ u-boot {
+ compatible = "u-boot,config";
+ bootscr-ram-offset = /bits/ 64 <0x12345678>;
+ };
+ };
+
bootstd {
bootph-verify;
compatible = "u-boot,boot-std";
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af5c..d94f0300c30a 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -1563,6 +1563,31 @@ const char *ofnode_conf_read_str(const char *prop_name)
return ofnode_read_string(node, prop_name);
}
+int ofnode_read_bootscript_address(u64 *bootscr_address, u64 *bootscr_offset)
+{
+ int ret;
+ ofnode uboot;
+
+ *bootscr_address = 0;
+ *bootscr_offset = 0;
+
+ uboot = ofnode_path("/options/u-boot");
+ if (!ofnode_valid(uboot)) {
+ printf("%s: Missing /u-boot node\n", __func__);
+ return -EINVAL;
+ }
+
+ ret = ofnode_read_u64(uboot, "bootscr-address", bootscr_address);
+ if (ret) {
+ ret = ofnode_read_u64(uboot, "bootscr-ram-offset",
+ bootscr_offset);
+ if (ret)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
ofnode ofnode_get_phy_node(ofnode node)
{
/* DT node properties that reference a PHY node */
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 0f38b3e736de..c1afa69e1c56 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -20,6 +20,7 @@
struct resource;
#include
+#include
struct ofnode_phandle_args {
ofnode node;
@@ -1500,6 +1501,26 @@ int ofnode_conf_read_int(const char *prop_name, int
default_val);
*/
const char *ofnode_conf_read_str(const char *prop_name);
+/**
+ * ofnode_read_bootscript_address() - Read bootscr-address or
bootscr-ram-offset
+ *
+ * @bootscr_address: pointer to 64bit address where bootscr-address property
value
+ * is stored
+ * @bootscr_offset: pointer to 64bit offset address where bootscr-ram-offset
+ * property value is stored
+ *
+ * This reads a bootscr-address or bootscr-ram-offset property from
+ * the /options/u-boot/ node of the devicetree. bootscr-address holds the full
+ * address of the boot script file. bootscr-ram-offset holds the boot script
+ * file offset from the start of the ram base address. When bootscr-address is
+ * defined, bootscr-ram-offset property is ignored.
+ *
+ * This only works with the control FDT.
+ *
+ * Return: 0 if OK, -EINVAL if property is not found.
+ */
+int ofnode_read_bootscript_address(u64 *bootscr_address, u64 *bootscr_offset);
+
#else /* CONFIG_DM */
static inline bool ofnode_conf_read_bool(const char *prop_name)
{
@@ -1516,6 +1537,11 @@ static inline const char *ofnode_conf_read_str(const
char *prop_name)
return NULL;
}
+static inline int ofnode_read_bootscript_address(u64 *bootscr_address, u64
*bootscr_offset)
+{
+ return -EINVAL;
+}
+
#endif /* CONFIG_DM */
/**
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index 6fbebc7da085..a4e04f23784f 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -583,6 +583,20 @@ static int dm_test_ofnode_conf(struct unit_test_state *uts)
}
DM_TEST(dm_test_ofnode_conf, 0);
+static int dm_test_ofnode_options(struct unit_test_state *uts)
+{
+ u64 bootscr_address;
+ u64 bootscr_offset;
+
+ ut_assertok(ofnode_read_bootscript_address(&bootscr_address,
+ &bootscr_offset));
+ ut_asserteq_64(0, bootscr_address);
+ ut_asserteq_64(0x12345678, bootscr_offset);
+
+ return 0;
+}
+DM_TEST(dm_test_ofnode_options, 0);
+
static int dm_test_ofnode_for_each_compatible_node(struct unit_test_state *uts)
{
const char compatible[] = "denx,u-boot-fdt-test";
--
2.36.1
Re: [PATCH] fpga: define dummy fpga_load function for debug build
On 8/31/23 04:21, Chanho Park wrote: On 8/16/23 08:54, Chanho Park wrote: This fixes below build error when CC_OPTIMIZE_FOR_DEBUG is enabled and CONFIG_SPL_FPGA is not enabled. I would rewrite this because the connection to SPL_FPGA is just one part of it. It is also taken when CONFIG_FPGA is not enabled. Sure. Will you rewrite while you pick this patch in your tree or do you want me to post v2 patch? Please send v2. Thanks, Michal
Re: [PATCH 09/19] Move fdt_simplefb to boot/
On 25/08/23 01:29, Simon Glass wrote:
> This relates to booting, so move it there. Create a new Kconfig menu for
> things related to devicetree fixup.
>
> Signed-off-by: Simon Glass
Reviewed-by: Devarsh Thakkar
> ---
>
> boot/Kconfig| 16
> boot/Makefile | 1 +
> {common => boot}/fdt_simplefb.c | 0
> common/Kconfig | 9 -
> common/Makefile | 1 -
> 5 files changed, 17 insertions(+), 10 deletions(-)
> rename {common => boot}/fdt_simplefb.c (100%)
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 5e2d4286aeaa..1b2ac7451a61 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -1535,6 +1535,22 @@ config SPL_IMAGE_PRE_LOAD_SIG
>
> endmenu
>
> +if OF_LIBFDT
> +
> +menu "Devicetree fixup"
> +
> +config FDT_SIMPLEFB
> + bool "FDT tools for simplefb support"
> + help
> + Enable the fdt tools to manage the simple fb nodes in device tree.
> + These functions can be used by board to indicate to the OS
> + the presence of the simple frame buffer with associated reserved
> + memory
> +
> +endmenu
> +
> +endif # OF_LIBFDT
> +
> config USE_BOOTARGS
> bool "Enable boot arguments"
> help
> diff --git a/boot/Makefile b/boot/Makefile
> index f15a161614ff..6ce983b83fa4 100644
> --- a/boot/Makefile
> +++ b/boot/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
> endif
>
> obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
> +obj-$(CONFIG_$(SPL_TPL_)FDT_SIMPLEFB) += fdt_simplefb.o
>
> obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
> obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
> diff --git a/common/fdt_simplefb.c b/boot/fdt_simplefb.c
> similarity index 100%
> rename from common/fdt_simplefb.c
> rename to boot/fdt_simplefb.c
> diff --git a/common/Kconfig b/common/Kconfig
> index 2f46fdb3f62c..9693c0ac426f 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -1156,14 +1156,5 @@ config VPL_IMAGE_SIGN_INFO
>
> endif
>
> -config FDT_SIMPLEFB
> - bool "FDT tools for simplefb support"
> - depends on OF_LIBFDT
> - help
> - Enable the fdt tools to manage the simple fb nodes in device tree.
> - These functions can be used by board to indicate to the OS
> - the presence of the simple frame buffer with associated reserved
> - memory
> -
> config IO_TRACE
> bool
> diff --git a/common/Makefile b/common/Makefile
> index 0948721d0b47..5c1617206f07 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -17,7 +17,6 @@ obj-y += board_r.o
> obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
> obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
>
> -obj-$(CONFIG_FDT_SIMPLEFB) += fdt_simplefb.o
> obj-$(CONFIG_MII) += miiphyutil.o
> obj-$(CONFIG_CMD_MII) += miiphyutil.o
> obj-$(CONFIG_PHYLIB) += miiphyutil.o
Re: [PATCH 08/19] boot: Move fdt_support to boot/
Hi Simon,
On 25/08/23 01:28, Simon Glass wrote:
> This relates to booting since it fixes up the devicetree for the OS. Move
> it into the boot/ directory.
>
> Signed-off-by: Simon Glass
> ---
>
> boot/Makefile | 3 +++
> {common => boot}/fdt_support.c | 0
> common/Makefile| 2 --
> 3 files changed, 3 insertions(+), 2 deletions(-)
> rename {common => boot}/fdt_support.c (100%)
>
> diff --git a/boot/Makefile b/boot/Makefile
> index 10f015722378..f15a161614ff 100644
> --- a/boot/Makefile
> +++ b/boot/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_QFW) += bootmeth_qfw.o
> endif
>
> obj-y += image.o image-board.o
> +
> obj-$(CONFIG_ANDROID_AB) += android_ab.o
> obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o image-android-dt.o
>
> @@ -37,6 +38,8 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o
> obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
> endif
>
> +obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
> +
> obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
Can this be,
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o image-fdt.o ?
Regards
Devarsh
> obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
> obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
> diff --git a/common/fdt_support.c b/boot/fdt_support.c
> similarity index 100%
> rename from common/fdt_support.c
> rename to boot/fdt_support.c
> diff --git a/common/Makefile b/common/Makefile
> index 0a3f75f2f1c8..0948721d0b47 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -18,7 +18,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
> obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
>
> obj-$(CONFIG_FDT_SIMPLEFB) += fdt_simplefb.o
> -obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
> obj-$(CONFIG_MII) += miiphyutil.o
> obj-$(CONFIG_CMD_MII) += miiphyutil.o
> obj-$(CONFIG_PHYLIB) += miiphyutil.o
> @@ -51,7 +50,6 @@ ifdef CONFIG_SPL_DFU
> obj-$(CONFIG_DFU_OVER_USB) += dfu.o
> endif
> obj-$(CONFIG_SPL_NET) += miiphyutil.o
> -obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
>
> obj-$(CONFIG_SPL_USB_HOST) += usb.o usb_hub.o
> obj-$(CONFIG_SPL_USB_STORAGE) += usb_storage.o
Re: [PATCH 04/19] video: Move BMP options and code to video directory
On 25/08/23 01:28, Simon Glass wrote:
> Put the options and the common BMP code with the other related Kconfig
> options in the drivers/video directory.
>
> Signed-off-by: Simon Glass
Reviewed-by: Devarsh Thakkar
> ---
>
> common/Kconfig | 11 ---
> common/Makefile | 1 -
> drivers/video/Kconfig | 11 +++
> drivers/video/Makefile | 2 ++
> {common => drivers/video}/bmp.c | 0
> 5 files changed, 13 insertions(+), 12 deletions(-)
> rename {common => drivers/video}/bmp.c (100%)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 844531a59eda..2f46fdb3f62c 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -1167,14 +1167,3 @@ config FDT_SIMPLEFB
>
> config IO_TRACE
> bool
> -
> -config BMP
> - bool # Enable bmp image display
> - help
> - Enable bmp functions to display bmp image and get bmp info.
> -
> -config SPL_BMP
> - bool # Enable bmp image display at SPL
> - depends on SPL_VIDEO
> - help
> - Enable bmp functions to display bmp image and get bmp info at SPL.
> diff --git a/common/Makefile b/common/Makefile
> index f5c3d90f0675..0a3f75f2f1c8 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -45,7 +45,6 @@ endif # !CONFIG_SPL_BUILD
>
> obj-$(CONFIG_$(SPL_TPL_)BOOTSTAGE) += bootstage.o
> obj-$(CONFIG_$(SPL_TPL_)BLOBLIST) += bloblist.o
> -obj-$(CONFIG_$(SPL_)BMP) += bmp.o
>
> ifdef CONFIG_SPL_BUILD
> ifdef CONFIG_SPL_DFU
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 09f2cb1a7321..a4befd6b655c 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -682,6 +682,11 @@ config BACKLIGHT_LM3533
> LM3533 Lighting Power chip. Only Bank A is supported as for now.
> Supported backlight level range is from 2 to 255 with step of 1.
>
> +config BMP
> + bool # Enable bmp image display
> + help
> + Enable bmp functions to display bmp image and get bmp info.
> +
> source "drivers/video/ti/Kconfig"
>
> source "drivers/video/exynos/Kconfig"
> @@ -1117,6 +1122,12 @@ config SPL_VIDEO_REMOVE
> if this option is enabled video driver will be removed at the end of
> SPL stage, before loading the next stage.
>
> +config SPL_BMP
> + bool # Enable bmp image display at SPL
> + depends on SPL_VIDEO
> + help
> + Enable bmp functions to display bmp image and get bmp info at SPL.
> +
> if SPL_SPLASH_SCREEN
>
> config SPL_SPLASH_SCREEN_ALIGN
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index d13af9f3b19b..a3182dca734b 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -3,6 +3,8 @@
> # (C) Copyright 2000-2007
> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>
> +obj-$(CONFIG_$(SPL_)BMP) += bmp.o
> +
> ifdef CONFIG_DM
> obj-$(CONFIG_$(SPL_TPL_)BACKLIGHT) += backlight-uclass.o
> obj-$(CONFIG_BACKLIGHT_GPIO) += backlight_gpio.o
> diff --git a/common/bmp.c b/drivers/video/bmp.c
> similarity index 100%
> rename from common/bmp.c
> rename to drivers/video/bmp.c
Re: [RFC] make sandbox UT more generic
Hi Simon, On Wed, Aug 30, 2023 at 08:49:05PM -0600, Simon Glass wrote: > Hi, > > On Wed, 30 Aug 2023 at 18:38, AKASHI Takahiro > wrote: > > > > Hi, > > > > I'm working on implementing SCMI-based pinctrl/gpio driver, > > and want to re-use sandbox UT to test the code. However, > > It is somehow sandbox-specific (with additional DT nodes). > > How can/should we make it more generic for other targets/drivers > > rather than just by copying the test code? > > (I have already created a test for pinmux since there is only > > one existing scenario, but gpio test has many.) > > > > Even if I say 'generic', my case may be special since real > > hardware (device drivers) cannot always run all the test cases, > > while SCMI-based drivers potentially can with a dummy SCMI server > > for sandbox. > > See: > > drivers/firmware/scmi/sandbox-scmi_agent.c > > We don't have a good way to test drivers that talk to hardware, in general. > > For I2C, SPI and some PCI devices you can sometimes write an emulator > for the chip and then your driver can talk to the emulator as if it > were talking to the hardware. Sandbox does actually support that with > memory-mapped I/O too, although it is fairly rarely used. Well, I don't want or need to emulate some *real* hardware. Instead, I would like to emulate what the current sandbox drivers (pinctrl-sandbox.c and gpio/sandbox.c) emulate so that we can re-use (some portion of) test cases for sandbox (test/dm/pinmux.c and gpio.c). As you might know, SCMI protocol with associated drivers on U-Boot is so generic that it would be able to talk to any of real pinctrl/gpio drivers/firmware (say, run on OPTEE or SCP). By implementing/mimicking protocol messages in sandbox-scmi_agent.c, SCMI drivers are expected to provide *virtual* pinctrl/gpio devices similar to what sandbox does. I have already implemented pinmux test with some tweaks by copying test/dm/pinmux.c and duplicating almost the same DT nodes as "pinctrl-gpio" in test.dts. But I'm looking for any other means without test code duplication. Did I clarify my question a bit? -Takahiro Akashi > We have done this a lot with Zephyr, as well[1] and achieved 90% code > coverage on some boards. > > But I'm not quite sure I am answering the right question, so I will stop here. > > Regards, > Simon > > [1] https://www.youtube.com/watch?v=usXCAXR2G_c
Re: [PATCH v2] cmd: dm: allow for selecting uclass and device
On Wed, Aug 30, 2023 at 09:48:48PM -0600, Simon Glass wrote:
> Hi AKASHI,
>
> On Tue, 22 Aug 2023 at 19:50, AKASHI Takahiro
> wrote:
> >
> > The output from "dm tree" or "dm uclass" is a bit annoying
> > if the number of devices available on the system is huge.
> > (This is especially true on sandbox when I debug some DM code.)
> >
> > With this patch, we can specify the uclass name or the device
> > name that we are interested in in order to limit the output.
> >
> > For instance,
> >
> > => dm uclass usb
> > uclass 121: usb
> > 0 usb@1 @ 0bcff8b0, seq 1
> >
> > uclass 124: usb
> >
> > => dm tree usb:usb@1
> > Class Index Probed DriverName
> > ---
> > usb 0 [ ] usb_sandbox usb@1
> > usb_hub 0 [ ] usb_hub `-- hub
> > usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
> > usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
> > usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
> > usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
> > usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
> >
> > If you want forward-matching against a uclass or udevice name,
> > you can specify "-e" option.
>
> I don't really know what 'forward matching' means.
Really? I believed that forward-matching was a common word.
I meant that it searches for any string starting with
a specific sub-string. In other words, it would be
"^" in a regular expression.
So, for example, "usb" should match with "usbABC", "usb-DEF",
"usb_GHI" and so on, but not match with "ABCusb".
> Please use forward instead of forword in the code
>
> >
> > => dm uclass -e usb
> > uclass 15: usb_emul
> > 0 hub-emul @ 0bcffb00, seq 0
> > 1 flash-stick@0 @ 0bcffc30, seq 1
> > 2 flash-stick@1 @ 0bcffdc0, seq 2
> > 3 flash-stick@2 @ 0bcfff50, seq 3
> > 4 keyb@3 @ 0bd000e0, seq 4
> >
> > uclass 64: usb_mass_storage
> >
> > uclass 121: usb
> > 0 usb@1 @ 0bcff8b0, seq 1
> >
> > uclass 122: usb_dev_generic
> >
> > uclass 123: usb_hub
> > 0 hub @ 0bcff9b0, seq 0
> >
> > uclass 124: usb
> >
> > => dm tree -e usb
> > Class Index Probed DriverName
> > ---
> > usb 0 [ ] usb_sandbox usb@1
> > usb_hub 0 [ ] usb_hub `-- hub
> > usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
> > usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
> > usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
> > usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
> > usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > v2
> > - allow for forward-matching against the name
> > - update command doc
> > ---
> > cmd/dm.c | 48 ++
> > doc/usage/cmd/dm.rst | 30 ++-
> > drivers/core/dump.c | 116 ---
> > include/dm/util.h| 15 --
> > 4 files changed, 165 insertions(+), 44 deletions(-)
>
> Reviewed-by: Simon Glass
>
> Thanks for doing this. It will be a big time-saver. I also wonder if
> it would be better if the default were to do a substring search and
Initially, I implemented so, but felt it is annoying to see
(sometimes many) unexpected matched devices, especially
when you know the exact name of device.
See my example "dm uclass -e usb".
> you have to add a flag to search for a single device?
Does 'single' mean the first matched word or exactly-same one?
Either way, I don't have a strong opinion here, though.
Thanks,
-Takahiro Akashi
>
> See below
>
> >
> > diff --git a/cmd/dm.c b/cmd/dm.c
> > index 3263547cbec6..1aa86aab9c1c 100644
> > --- a/cmd/dm.c
> > +++ b/cmd/dm.c
> > @@ -59,11 +59,26 @@ static int do_dm_dump_static_driver_info(struct cmd_tbl
> > *cmdtp, int flag,
> > static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int flag, int argc,
> >char *const argv[])
> > {
> > - bool sort;
> > -
> > - sort = argc > 1 && !strcmp(argv[1], "-s");
> > -
> > - dm_dump_tree(sort);
> > + bool extended = false, sort = false;
> > + char *device = NULL;
> > +
> > + for (; argc > 1; argc--, argv++) {
> > + if (argv[1][0] != '-')
> > + break;
> > +
> > + if (!strcmp(argv[1], "-e")) {
> > + extended = true;
> > + } else if (!strcmp(argv[1], "-s")) {
> > + sort = true;
> > + } else {
> > + printf("Unknown parameter: %s\n", argv[1]);
> > + return 0;
> > + }
> > + }
> > + if (argc > 1)
> > + device = argv[1];
> > +
> > +
Re: [PATCH v2 03/19] video: Hide the BMP options
Am 31. August 2023 05:52:57 MESZ schrieb Simon Glass : >These appear prominently in the main menu at present. However they are >selected when needed so do not need to be visible. > >Make them hidden. > >Signed-off-by: Simon Glass >--- > >(no changes since v1) > > common/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/common/Kconfig b/common/Kconfig >index 0b09bd68bd13..844531a59eda 100644 >--- a/common/Kconfig >+++ b/common/Kconfig >@@ -1169,12 +1169,12 @@ config IO_TRACE > bool > > config BMP >- bool "Enable bmp image display" >+ bool # Enable bmp image display This must depend on video. > help > Enable bmp functions to display bmp image and get bmp info. > > config SPL_BMP >- bool "Enable bmp image display at SPL" >+ bool # Enable bmp image display at SPL Why should I not be able to deactivate the logo display? Just move the entries to submenus related to video, please. Best regards Heinrich > depends on SPL_VIDEO > help > Enable bmp functions to display bmp image and get bmp info at SPL.
Re: [RFC PATCH 9/9] upl: Add initial documentation
Am 31. August 2023 01:29:23 MESZ schrieb Simon Glass : >Add some placeholder documentation to explain the basic concept. Once the >spec is published, more can be added and this series applied. > >Signed-off-by: Simon Glass >--- > > doc/usage/index.rst | 1 + > doc/usage/upl.rst | 27 +++ > 2 files changed, 28 insertions(+) > create mode 100644 doc/usage/upl.rst > >diff --git a/doc/usage/index.rst b/doc/usage/index.rst >index ed896dfb3a0..78665fd5759 100644 >--- a/doc/usage/index.rst >+++ b/doc/usage/index.rst >@@ -13,6 +13,7 @@ Use U-Boot >partitions >cmdline >semihosting >+ upl > > Shell commands > -- >diff --git a/doc/usage/upl.rst b/doc/usage/upl.rst >new file mode 100644 >index 000..2ae4d4a1178 >--- /dev/null >+++ b/doc/usage/upl.rst >@@ -0,0 +1,27 @@ >+Universal Payload >+~ >+ >+Universal Payload (UPL) is an upcoming Industry Standard for firmware >+components. UPL is designed to improve interoperability within the firmware >+industry, allowing mixing and matching of projects with less friction and >fewer >+project-specific implementations. UPL is cross-platform, supporting ARM, x86 >and >+RISC-V initially. Please, provide a link to the specification. >+ >+UPL is defined in termns of two firmware components: terms >+ >+`Platform Init` >+ Perhaps initial setup of the hardware and jumps to the payload. %s/Perhaps/Possible/ >+ >+`Payload` >+ Selects the OS to boot IIRC the UPL payload typically is not the OS but other firmware or a boot loader. Best regards Heinrich >+ >+In practice UPL can be used to handle any number of handoffs through the >+firmware startup process, with one program acting as platform init and another >+acting as the payload. >+ >+UPL provides a standard for three main pieces: >+ >+- file format for the payload, which may comprise multiple images to load >+- handoff format for the information the payload needs, such as serial port, >+ memory layout, etc. >+- machine state and register settings at the point of handoff
[PATCH v2 19/19] boot: Join ARCH_FIXUP_FDT_MEMORY with related options
Move this to be with the other devicetree-fixup options. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 023446130282..257f4cc085e1 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -693,14 +693,6 @@ config SUPPORT_RAW_INITRD address of the initrd must be augmented by it's size, in the following format: ":". -config ARCH_FIXUP_FDT_MEMORY - bool "Enable arch_fixup_memory_banks() call" - default y - help - Enable FDT memory map syncup before OS boot. This feature can be - used for booting OS with different memory setup where the part of - the memory location should be used for different purpose. - config CHROMEOS bool "Support booting Chrome OS" help @@ -1492,6 +1484,14 @@ config FDT_SIMPLEFB the presence of the simple frame buffer with associated reserved memory +config ARCH_FIXUP_FDT_MEMORY + bool "Enable arch_fixup_memory_banks() call" + default y + help + Enable FDT memory map syncup before OS boot. This feature can be + used for booting OS with different memory setup where the part of + the memory location should be used for different purpose. + endmenu endif # OF_LIBFDT -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 18/19] boot: Join FDT_FIXUP_PARTITIONS with related options
Move this to be with the other devicetree-fixup options. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 8 lib/Kconfig | 9 - 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index a7dea0a0623b..023446130282 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -1476,6 +1476,14 @@ config OF_STDOUT_VIA_ALIAS incorrect when used with device tree as this option does not exist / should not be used. +config FDT_FIXUP_PARTITIONS + bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" + depends on CMD_MTDPARTS + help + Allow overwriting defined partitions in the device tree blob + using partition info defined in the 'mtdparts' environment + variable. + config FDT_SIMPLEFB bool "FDT tools for simplefb support" help diff --git a/lib/Kconfig b/lib/Kconfig index bfab2f3165a7..eb2b10161824 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -953,15 +953,6 @@ config VPL_OF_LIBFDT_ASSUME_MASK 0xff means all assumptions are made and any invalid data may cause unsafe execution. See FDT_ASSUME_PERFECT, etc. in libfdt_internal.h -config FDT_FIXUP_PARTITIONS - bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" - depends on OF_LIBFDT - depends on CMD_MTDPARTS - help - Allow overwriting defined partitions in the device tree blob - using partition info defined in the 'mtdparts' environment - variable. - menu "System tables" depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER) -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 17/19] Mark DISTRO_DEFAULTS as deprecated
Standard boot has been in place for a while now. Quite a few problems have been found and fixed. It seems like a good time to mark the script-based approach as deprecated and encourage people to use standard boot. Update the DISTRO_DEFAULTS Kconfig to encourage people to move to standard boot, which is able to boot Linux distributions automatically. Add a short migration guide to make this easier. Signed-off-by: Simon Glass --- Changes in v2: - Mention in the DISTRO_DEFAULTS option that it is script-based - Expand and rewrite the commit message - Use the word 'Mark' instead of 'Make' to improve the English boot/Kconfig| 7 ++- doc/develop/bootstd.rst | 23 +++ 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 458512a4ade2..a7dea0a0623b 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -784,7 +784,7 @@ config SYS_BOOT_RAMDISK_HIGH endmenu# Boot images config DISTRO_DEFAULTS - bool "Select defaults suitable for booting general purpose Linux distributions" + bool "(deprecated) 'Script-based booting of Linux distributions" select BOOT_DEFAULTS select AUTO_COMPLETE select CMDLINE_EDITING @@ -792,6 +792,11 @@ config DISTRO_DEFAULTS select HUSH_PARSER select SYS_LONGHELP help + Note: These scripts have been replaced by Standard Boot. Do not use + them on new boards. See 'Migrating from distro_boot' at + doc/develop/bootstd.rst + + Select this to enable various options and commands which are suitable for building u-boot for booting general purpose Linux distributions. diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst index c01e0971dc84..ddcd05f931ad 100644 --- a/doc/develop/bootstd.rst +++ b/doc/develop/bootstd.rst @@ -458,6 +458,28 @@ readyFile was loaded and is ready for use. In this state the bootflow is === === +Migrating from distro_boot +-- + +To migrate from distro_boot: + +#. Update your board header files to remove the BOOTENV and BOOT_TARGET_xxx + defines. Standard boot finds available boot devices automatically. + +#. Remove the "boot_targets" variable unless you need it. Standard boot uses a + default order from fastest to slowest, which generally matches the order used + by boards. + +#. Make sure that CONFIG_BOOTSTD_DEFAULTS is enabled by your board, so it can + boot common Linux distributions. + +An example patch is at migrate_patch_. + +If you are using custom boot scripts for your board, consider creating your +own bootmeth to hold the logic. There are various examples at +`boot/bootmeth_...`. + + Theory of operation --- @@ -769,3 +791,4 @@ Other ideas: .. _BootLoaderSpec: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ .. _distro_boot: https://github.com/u-boot/u-boot/blob/master/boot/distro.c .. _bootflow_h: https://github.com/u-boot/u-boot/blob/master/include/bootflow.h +.. _migrate_patch: https://patchwork.ozlabs.org/project/uboot/patch/20230727215433.578830-2-...@chromium.org/ -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 16/19] Kconfig: Move TEXT_BASE et al under general setup
These don't relate to booting. Move them out of there and into the same place as the other related settings. Signed-off-by: Simon Glass --- (no changes since v1) Kconfig | 65 boot/Kconfig | 65 2 files changed, 65 insertions(+), 65 deletions(-) diff --git a/Kconfig b/Kconfig index 0a2e97578dfc..2d4b82149860 100644 --- a/Kconfig +++ b/Kconfig @@ -585,6 +585,71 @@ config MP This provides an option to bringup different processors in multiprocessor cases. +config HAVE_TEXT_BASE + bool + depends on !NIOS2 && !XTENSA + depends on !EFI_APP + default y + +config TEXT_BASE + depends on HAVE_TEXT_BASE + default 0x0 if POSITION_INDEPENDENT + default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3 + default 0x8170 if MACH_SUNIV + default 0x2a00 if MACH_SUN9I + default 0x4a00 if SUNXI_MINIMUM_DRAM_MB >= 256 + default 0x42e0 if SUNXI_MINIMUM_DRAM_MB >= 64 + hex "Text Base" + help + The address in memory that U-Boot will be running from, initially. + +config HAVE_SYS_MONITOR_BASE + bool + depends on ARC || MIPS || M68K || NIOS2 || PPC || XTENSA || X86 \ + || ENV_IS_IN_FLASH || MTD_NOR_FLASH + depends on !EFI_APP + default y + +config SYS_MONITOR_BASE + depends on HAVE_SYS_MONITOR_BASE + hex "Physical start address of boot monitor code" + default TEXT_BASE + help + The physical start address of boot monitor code (which is the same as + CONFIG_TEXT_BASE when linking) and the same as CFG_SYS_FLASH_BASE + when booting from flash. + +config SPL_SYS_MONITOR_BASE + depends on MPC85xx && SPL && HAVE_SYS_MONITOR_BASE + hex "Physical start address of SPL monitor code" + default SPL_TEXT_BASE + +config TPL_SYS_MONITOR_BASE + depends on MPC85xx && TPL && HAVE_SYS_MONITOR_BASE + hex "Physical start address of TPL monitor code" + +config DYNAMIC_SYS_CLK_FREQ + bool "Determine CPU clock frequency at run-time" + help + Implement a get_board_sys_clk function that will determine the CPU + clock frequency at run time, rather than define it statically. + +config SYS_CLK_FREQ + depends on !DYNAMIC_SYS_CLK_FREQ + int "CPU clock frequency" + default 12500 if ARCH_LS1012A + default 1 if ARCH_P2020 || ARCH_T1024 || ARCH_T1042 || \ +ARCH_LS1021A || FSL_LSCH2 || FSL_LSCH3 + default if ARCH_P1010 || ARCH_P1020 || ARCH_T4240 + default if ARCH_T2080 + default if RCAR_GEN3 + default 2400 if ARCH_EXYNOS + default 2000 if RCAR_GEN2 + default 0 + help + A static value for the CPU frequency. Note that if not required + for a given SoC, this can be left at 0. + source "api/Kconfig" endmenu# General setup diff --git a/boot/Kconfig b/boot/Kconfig index 17f54b926f05..458512a4ade2 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -693,71 +693,6 @@ config SUPPORT_RAW_INITRD address of the initrd must be augmented by it's size, in the following format: ":". -config HAVE_TEXT_BASE - bool - depends on !NIOS2 && !XTENSA - depends on !EFI_APP - default y - -config TEXT_BASE - depends on HAVE_TEXT_BASE - default 0x0 if POSITION_INDEPENDENT - default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3 - default 0x8170 if MACH_SUNIV - default 0x2a00 if MACH_SUN9I - default 0x4a00 if SUNXI_MINIMUM_DRAM_MB >= 256 - default 0x42e0 if SUNXI_MINIMUM_DRAM_MB >= 64 - hex "Text Base" - help - The address in memory that U-Boot will be running from, initially. - -config HAVE_SYS_MONITOR_BASE - bool - depends on ARC || MIPS || M68K || NIOS2 || PPC || XTENSA || X86 \ - || ENV_IS_IN_FLASH || MTD_NOR_FLASH - depends on !EFI_APP - default y - -config SYS_MONITOR_BASE - depends on HAVE_SYS_MONITOR_BASE - hex "Physical start address of boot monitor code" - default TEXT_BASE - help - The physical start address of boot monitor code (which is the same as - CONFIG_TEXT_BASE when linking) and the same as CFG_SYS_FLASH_BASE - when booting from flash. - -config SPL_SYS_MONITOR_BASE - depends on MPC85xx && SPL && HAVE_SYS_MONITOR_BASE - hex "Physical start address of SPL monitor code" - default SPL_TEXT_BASE - -config TPL_SYS_MONITOR_BASE - depends on MPC85xx && TPL && HAVE_SYS_MONITOR_BASE - hex "Physical start address of TPL monitor code" - -config DYNAMIC_SYS_CLK_FREQ - bool "Determine CPU clock frequency at run-time" - help - Implement a get_board_sys_clk function that will determine the CPU - c
[PATCH v2 15/19] boot: Make standard boot a menu
Collect these options into a menu for easier viewing. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index c9b7d3f710b6..17f54b926f05 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -372,8 +372,8 @@ config BOOT_DEFAULTS of U-Boot to boot various images. Currently much functionality is tied to enabling the command that exercises it. -config BOOTSTD - bool "Standard boot support" +menuconfig BOOTSTD + bool "Standard boot" default y depends on DM && OF_CONTROL && BLK help @@ -393,6 +393,8 @@ config BOOTSTD U-Boot) - bootflow - a description of how to boot (owned by the distro) +if BOOTSTD + config SPL_BOOTSTD bool "Standard boot support in SPL" depends on SPL && SPL_DM && SPL_OF_CONTROL && SPL_BLK @@ -413,8 +415,6 @@ config VPL_BOOTSTD boot. It is enabled by default since the main purpose of VPL is to handle the firmware part of VBE. -if BOOTSTD - config BOOTSTD_FULL bool "Enhanced features for standard boot" default y if SANDBOX @@ -673,7 +673,7 @@ config BOOTMETH_SCRIPT This provides a way to try out standard boot on an existing boot flow. It is not enabled by default to save space. -endif +endif # BOOTSTD config LEGACY_IMAGE_FORMAT bool "Enable support for the legacy image format" -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 14/19] spl: Tidy up load address in spl_ram
This CONFIG is used but is not given a value by some boards. Use
a default value of 0 explicitly, rather than relying on the 0 value
provided by CONFIG_SPL_LOAD_FIT_ADDRESS
This will allow us to make SPL_LOAD_FIT_ADDRESS depend on SPL_LOAD_FIT
as it should.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/spl/spl_ram.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
index 93cf420d810a..4158ed1c32d7 100644
--- a/common/spl/spl_ram.c
+++ b/common/spl/spl_ram.c
@@ -20,12 +20,16 @@
static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
ulong count, void *buf)
{
- ulong addr;
+ ulong addr = 0;
debug("%s: sector %lx, count %lx, buf %lx\n",
__func__, sector, count, (ulong)buf);
- addr = (ulong)CONFIG_SPL_LOAD_FIT_ADDRESS + sector;
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT)) {
+ addr = IF_ENABLED_INT(CONFIG_SPL_LOAD_FIT,
+ CONFIG_SPL_LOAD_FIT_ADDRESS);
+ }
+ addr += sector;
if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD))
addr += image_load_offset;
@@ -38,20 +42,23 @@ static int spl_ram_load_image(struct spl_image_info
*spl_image,
struct spl_boot_device *bootdev)
{
struct legacy_img_hdr *header;
+ ulong addr = 0;
int ret;
- header = (struct legacy_img_hdr *)CONFIG_SPL_LOAD_FIT_ADDRESS;
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT)) {
+ addr = IF_ENABLED_INT(CONFIG_SPL_LOAD_FIT,
+ CONFIG_SPL_LOAD_FIT_ADDRESS);
+ }
if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD)) {
- unsigned long addr = (unsigned long)header;
ret = image_pre_load(addr);
if (ret)
return ret;
addr += image_load_offset;
- header = (struct legacy_img_hdr *)addr;
}
+ header = map_sysmem(addr, 0);
#if CONFIG_IS_ENABLED(DFU)
if (bootdev->boot_device == BOOT_DEVICE_DFU)
@@ -84,7 +91,7 @@ static int spl_ram_load_image(struct spl_image_info
*spl_image,
u_boot_pos =
(ulong)spl_get_load_buffer(-sizeof(*header),
sizeof(*header));
}
- header = (struct legacy_img_hdr *)map_sysmem(u_boot_pos, 0);
+ header = map_sysmem(u_boot_pos, 0);
ret = spl_parse_image_header(spl_image, bootdev, header);
}
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 13/19] Kconfig: Move SPL_FIT under FIT
This option already depends on FIT, so put it under the same umbrella, so that it appears in the FIT menu. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 467bca706782..c9b7d3f710b6 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -140,11 +140,9 @@ config FIT_PRINT help Support printing the content of the fitImage in a verbose manner. -endif # FIT - config SPL_FIT bool "Support Flattened Image Tree within SPL" - depends on SPL && FIT + depends on SPL select SPL_HASH select SPL_OF_LIBFDT @@ -195,7 +193,7 @@ config SPL_FIT_RSASSA_PSS config SPL_LOAD_FIT bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)" - depends on SPL && FIT + depends on SPL select SPL_FIT help Normally with the SPL framework a legacy image is generated as part @@ -243,7 +241,6 @@ config SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ config SPL_LOAD_FIT_FULL bool "Enable SPL loading U-Boot as a FIT (full fitImage features)" - depends on FIT select SPL_FIT help Normally with the SPL framework a legacy image is generated as part @@ -341,6 +338,8 @@ config VPL_FIT_SIGNATURE_MAX_SIZE endif # VPL +endif # FIT + config PXE_UTILS bool select MENU -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 12/19] Kconfig: Create a menu for FIT
This is a major feature with a lot of options. Give it its own menu to tidy up the 'make menuconfig' display. Drop the 'depends on FIT' pieces which are now unnecessary, since they are now bracketed by an 'if FIT'. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index f603a64a23de..467bca706782 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -9,8 +9,8 @@ config ANDROID_BOOT_IMAGE This enables support for booting images which use the Android image format header. -config FIT - bool "Support Flattened Image Tree" +menuconfig FIT + bool "Flattened Image Tree (FIT)" select HASH select MD5 select SHA1 @@ -25,6 +25,8 @@ config FIT multiple configurations, verification through hashing and also verified boot (secure boot using RSA). +if FIT + config TIMESTAMP bool "Show image date and time when displaying image information" default y if CMD_DATE @@ -38,7 +40,6 @@ config TIMESTAMP config FIT_EXTERNAL_OFFSET hex "FIT external data offset" - depends on FIT default 0x0 help This specifies a data offset in fit image. @@ -49,7 +50,6 @@ config FIT_EXTERNAL_OFFSET config FIT_FULL_CHECK bool "Do a full check of the FIT before using it" - depends on FIT default y help Enable this do a full check of the FIT to make sure it is valid. This @@ -59,7 +59,7 @@ config FIT_FULL_CHECK config FIT_SIGNATURE bool "Enable signature verification of FIT uImages" - depends on DM && FIT + depends on DM select HASH imply RSA imply RSA_VERIFY @@ -97,7 +97,7 @@ config FIT_RSASSA_PSS config FIT_CIPHER bool "Enable ciphering data in a FIT uImages" - depends on DM && FIT + depends on DM select AES help Enable the feature of data ciphering/unciphering in the tool mkimage @@ -105,7 +105,6 @@ config FIT_CIPHER config FIT_VERBOSE bool "Show verbose messages when FIT images fail" - depends on FIT help Generally a system will have valid FIT images so debug messages are a waste of code space. If you are debugging your images then @@ -114,7 +113,6 @@ config FIT_VERBOSE config FIT_BEST_MATCH bool "Select the best match for the kernel device tree" - depends on FIT help When no configuration is explicitly selected, default to the one whose fdt's compatibility field best matches that of @@ -124,7 +122,6 @@ config FIT_BEST_MATCH config FIT_IMAGE_POST_PROCESS bool "Enable post-processing of FIT artifacts after loading by U-Boot" - depends on FIT depends on SOCFPGA_SECURE_VAB_AUTH help Allows doing any sort of manipulation to blobs after they got extracted @@ -139,11 +136,12 @@ config FIT_IMAGE_POST_PROCESS config FIT_PRINT bool "Support FIT printing" - depends on FIT default y help Support printing the content of the fitImage in a verbose manner. +endif # FIT + config SPL_FIT bool "Support Flattened Image Tree within SPL" depends on SPL && FIT -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 11/19] boot: Rename Android-boot text
Phrases like 'Enable support for' are pointless since this is an option which enables things. Drop that part so it is easier to follow. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 70cbcc38fdd4..f603a64a23de 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -3,7 +3,7 @@ menu "Boot options" menu "Boot images" config ANDROID_BOOT_IMAGE - bool "Enable support for Android Boot Images" + bool "Android Boot Images" default y if FASTBOOT help This enables support for booting images which use the Android -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 10/19] boot: Move some other fdt-fixup options to the same menu
Move more options relating to fixing up a device tree into the new devicetree-fixup menu. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 55 +--- 1 file changed, 26 insertions(+), 29 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 025fa01d782c..70cbcc38fdd4 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -696,35 +696,6 @@ config SUPPORT_RAW_INITRD address of the initrd must be augmented by it's size, in the following format: ":". -config OF_BOARD_SETUP - bool "Set up board-specific details in device tree before boot" - depends on OF_LIBFDT - help - This causes U-Boot to call ft_board_setup() before booting into - the Operating System. This function can set up various - board-specific information in the device tree for use by the OS. - The device tree is then passed to the OS. - -config OF_SYSTEM_SETUP - bool "Set up system-specific details in device tree before boot" - depends on OF_LIBFDT - help - This causes U-Boot to call ft_system_setup() before booting into - the Operating System. This function can set up various - system-specific information in the device tree for use by the OS. - The device tree is then passed to the OS. - -config OF_STDOUT_VIA_ALIAS - bool "Update the device-tree stdout alias from U-Boot" - depends on OF_LIBFDT - help - This uses U-Boot's serial alias from the aliases node to update - the device tree passed to the OS. The "linux,stdout-path" property - in the chosen node is set to point to the correct serial node. - This option currently references CONFIG_CONS_INDEX, which is - incorrect when used with device tree as this option does not - exist / should not be used. - config HAVE_TEXT_BASE bool depends on !NIOS2 && !XTENSA @@ -1542,6 +1513,32 @@ if OF_LIBFDT menu "Devicetree fixup" +config OF_BOARD_SETUP + bool "Set up board-specific details in device tree before boot" + help + This causes U-Boot to call ft_board_setup() before booting into + the Operating System. This function can set up various + board-specific information in the device tree for use by the OS. + The device tree is then passed to the OS. + +config OF_SYSTEM_SETUP + bool "Set up system-specific details in device tree before boot" + help + This causes U-Boot to call ft_system_setup() before booting into + the Operating System. This function can set up various + system-specific information in the device tree for use by the OS. + The device tree is then passed to the OS. + +config OF_STDOUT_VIA_ALIAS + bool "Update the device-tree stdout alias from U-Boot" + help + This uses U-Boot's serial alias from the aliases node to update + the device tree passed to the OS. The "linux,stdout-path" property + in the chosen node is set to point to the correct serial node. + This option currently references CONFIG_CONS_INDEX, which is + incorrect when used with device tree as this option does not + exist / should not be used. + config FDT_SIMPLEFB bool "FDT tools for simplefb support" help -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 09/19] Move fdt_simplefb to boot/
This relates to booting, so move it there. Create a new Kconfig menu for
things related to devicetree fixup.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/Kconfig| 16
boot/Makefile | 1 +
{common => boot}/fdt_simplefb.c | 0
common/Kconfig | 9 -
common/Makefile | 1 -
5 files changed, 17 insertions(+), 10 deletions(-)
rename {common => boot}/fdt_simplefb.c (100%)
diff --git a/boot/Kconfig b/boot/Kconfig
index 86ccfd780312..025fa01d782c 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -1538,6 +1538,22 @@ config SPL_IMAGE_PRE_LOAD_SIG
endmenu
+if OF_LIBFDT
+
+menu "Devicetree fixup"
+
+config FDT_SIMPLEFB
+ bool "FDT tools for simplefb support"
+ help
+ Enable the fdt tools to manage the simple fb nodes in device tree.
+ These functions can be used by board to indicate to the OS
+ the presence of the simple frame buffer with associated reserved
+ memory
+
+endmenu
+
+endif # OF_LIBFDT
+
config USE_BOOTARGS
bool "Enable boot arguments"
help
diff --git a/boot/Makefile b/boot/Makefile
index f15a161614ff..6ce983b83fa4 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
endif
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
+obj-$(CONFIG_$(SPL_TPL_)FDT_SIMPLEFB) += fdt_simplefb.o
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
diff --git a/common/fdt_simplefb.c b/boot/fdt_simplefb.c
similarity index 100%
rename from common/fdt_simplefb.c
rename to boot/fdt_simplefb.c
diff --git a/common/Kconfig b/common/Kconfig
index 2f46fdb3f62c..9693c0ac426f 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1156,14 +1156,5 @@ config VPL_IMAGE_SIGN_INFO
endif
-config FDT_SIMPLEFB
- bool "FDT tools for simplefb support"
- depends on OF_LIBFDT
- help
- Enable the fdt tools to manage the simple fb nodes in device tree.
- These functions can be used by board to indicate to the OS
- the presence of the simple frame buffer with associated reserved
- memory
-
config IO_TRACE
bool
diff --git a/common/Makefile b/common/Makefile
index 0948721d0b47..5c1617206f07 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -17,7 +17,6 @@ obj-y += board_r.o
obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
-obj-$(CONFIG_FDT_SIMPLEFB) += fdt_simplefb.o
obj-$(CONFIG_MII) += miiphyutil.o
obj-$(CONFIG_CMD_MII) += miiphyutil.o
obj-$(CONFIG_PHYLIB) += miiphyutil.o
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 08/19] boot: Move fdt_support to boot/
This relates to booting since it fixes up the devicetree for the OS. Move
it into the boot/ directory.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/Makefile | 3 +++
{common => boot}/fdt_support.c | 0
common/Makefile| 2 --
3 files changed, 3 insertions(+), 2 deletions(-)
rename {common => boot}/fdt_support.c (100%)
diff --git a/boot/Makefile b/boot/Makefile
index 10f015722378..f15a161614ff 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_QFW) += bootmeth_qfw.o
endif
obj-y += image.o image-board.o
+
obj-$(CONFIG_ANDROID_AB) += android_ab.o
obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o image-android-dt.o
@@ -37,6 +38,8 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o
obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
endif
+obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
+
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
diff --git a/common/fdt_support.c b/boot/fdt_support.c
similarity index 100%
rename from common/fdt_support.c
rename to boot/fdt_support.c
diff --git a/common/Makefile b/common/Makefile
index 0a3f75f2f1c8..0948721d0b47 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
obj-$(CONFIG_FDT_SIMPLEFB) += fdt_simplefb.o
-obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
obj-$(CONFIG_MII) += miiphyutil.o
obj-$(CONFIG_CMD_MII) += miiphyutil.o
obj-$(CONFIG_PHYLIB) += miiphyutil.o
@@ -51,7 +50,6 @@ ifdef CONFIG_SPL_DFU
obj-$(CONFIG_DFU_OVER_USB) += dfu.o
endif
obj-$(CONFIG_SPL_NET) += miiphyutil.o
-obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += fdt_support.o
obj-$(CONFIG_SPL_USB_HOST) += usb.o usb_hub.o
obj-$(CONFIG_SPL_USB_STORAGE) += usb_storage.o
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 07/19] test: Move POST under a renamed Testing section
Rename Unit tests to Testing, since it is a stretch to describe some of the tests as unit tests. Move POST there as well, so it doesn't show up by itself in the top-level menu. Signed-off-by: Simon Glass --- (no changes since v1) test/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/test/Kconfig b/test/Kconfig index 6e859fb7d0db..830245b6f9a9 100644 --- a/test/Kconfig +++ b/test/Kconfig @@ -1,9 +1,4 @@ -config POST - bool "Power On Self Test support" - help - See doc/README.POST for more details - -menu "Unit tests" +menu "Testing" config UNIT_TEST bool "Unit tests" @@ -110,4 +105,9 @@ source "test/lib/Kconfig" source "test/optee/Kconfig" source "test/overlay/Kconfig" +config POST + bool "Power On Self Test support" + help + See doc/README.POST for more details + endmenu -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 04/19] video: Move BMP options and code to video directory
Put the options and the common BMP code with the other related Kconfig
options in the drivers/video directory.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/Kconfig | 11 ---
common/Makefile | 1 -
drivers/video/Kconfig | 11 +++
drivers/video/Makefile | 2 ++
{common => drivers/video}/bmp.c | 0
5 files changed, 13 insertions(+), 12 deletions(-)
rename {common => drivers/video}/bmp.c (100%)
diff --git a/common/Kconfig b/common/Kconfig
index 844531a59eda..2f46fdb3f62c 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1167,14 +1167,3 @@ config FDT_SIMPLEFB
config IO_TRACE
bool
-
-config BMP
- bool # Enable bmp image display
- help
- Enable bmp functions to display bmp image and get bmp info.
-
-config SPL_BMP
- bool # Enable bmp image display at SPL
- depends on SPL_VIDEO
- help
- Enable bmp functions to display bmp image and get bmp info at SPL.
diff --git a/common/Makefile b/common/Makefile
index f5c3d90f0675..0a3f75f2f1c8 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -45,7 +45,6 @@ endif # !CONFIG_SPL_BUILD
obj-$(CONFIG_$(SPL_TPL_)BOOTSTAGE) += bootstage.o
obj-$(CONFIG_$(SPL_TPL_)BLOBLIST) += bloblist.o
-obj-$(CONFIG_$(SPL_)BMP) += bmp.o
ifdef CONFIG_SPL_BUILD
ifdef CONFIG_SPL_DFU
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 09f2cb1a7321..a4befd6b655c 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -682,6 +682,11 @@ config BACKLIGHT_LM3533
LM3533 Lighting Power chip. Only Bank A is supported as for now.
Supported backlight level range is from 2 to 255 with step of 1.
+config BMP
+ bool # Enable bmp image display
+ help
+ Enable bmp functions to display bmp image and get bmp info.
+
source "drivers/video/ti/Kconfig"
source "drivers/video/exynos/Kconfig"
@@ -1117,6 +1122,12 @@ config SPL_VIDEO_REMOVE
if this option is enabled video driver will be removed at the end of
SPL stage, before loading the next stage.
+config SPL_BMP
+ bool # Enable bmp image display at SPL
+ depends on SPL_VIDEO
+ help
+ Enable bmp functions to display bmp image and get bmp info at SPL.
+
if SPL_SPLASH_SCREEN
config SPL_SPLASH_SCREEN_ALIGN
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index d13af9f3b19b..a3182dca734b 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -3,6 +3,8 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+obj-$(CONFIG_$(SPL_)BMP) += bmp.o
+
ifdef CONFIG_DM
obj-$(CONFIG_$(SPL_TPL_)BACKLIGHT) += backlight-uclass.o
obj-$(CONFIG_BACKLIGHT_GPIO) += backlight_gpio.o
diff --git a/common/bmp.c b/drivers/video/bmp.c
similarity index 100%
rename from common/bmp.c
rename to drivers/video/bmp.c
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 06/19] FWU: Avoid showing an unselectable menu option
Use a menuconfig to avoid showing a menu which cannot be selected in many cases. This option should really go with the other 'Update support'. Perhaps we should even consider a top-level update/ directory? Signed-off-by: Simon Glass Acked-by: Sughosh Ganu --- Changes in v2: - Fix FMU typo in the subject - Drop now-unnecessary depends on FWU_MULTI_BANK_UPDATE lib/Kconfig | 4 lib/fwu_updates/Kconfig | 9 + 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/lib/Kconfig b/lib/Kconfig index 9addcfab3734..bfab2f3165a7 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -1118,8 +1118,4 @@ config PHANDLE_CHECK_SEQ endmenu -menu "FWU Multi Bank Updates" - source lib/fwu_updates/Kconfig - -endmenu diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig index 71f34793d926..d35247d0e5d4 100644 --- a/lib/fwu_updates/Kconfig +++ b/lib/fwu_updates/Kconfig @@ -1,4 +1,4 @@ -config FWU_MULTI_BANK_UPDATE +menuconfig FWU_MULTI_BANK_UPDATE bool "Enable FWU Multi Bank Update Feature" depends on EFI_CAPSULE_ON_DISK select PARTITION_TYPE_GUID @@ -10,24 +10,25 @@ config FWU_MULTI_BANK_UPDATE multiple banks(copies) of the firmware images. One of the bank is selected for updating all the firmware components +if FWU_MULTI_BANK_UPDATE + config FWU_NUM_BANKS int "Number of Banks defined by the platform" - depends on FWU_MULTI_BANK_UPDATE help Define the number of banks of firmware images on a platform config FWU_NUM_IMAGES_PER_BANK int "Number of firmware images per bank" - depends on FWU_MULTI_BANK_UPDATE help Define the number of firmware images per bank. This value should be the same for all the banks. config FWU_TRIAL_STATE_CNT int "Number of times system boots in Trial State" - depends on FWU_MULTI_BANK_UPDATE default 3 help With FWU Multi Bank Update feature enabled, number of times the platform is allowed to boot in Trial State after an update. + +endif -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 05/19] net: Move SYS_RX_ETH_BUFFER into the network menu
Move this Kconfig option into the correct place, so it doesn't show up in the top-level menu. Unfortunately this makes the CONFIG undefined on some boards which don't enable CONFIG_NET but do include the net.h header file. In fact that header is included from a lot of common places. So use a fallback in the header file. Signed-off-by: Simon Glass --- (no changes since v1) include/net.h | 9 ++--- net/Kconfig | 4 ++-- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/include/net.h b/include/net.h index e254df7d7f43..f70396c74ba5 100644 --- a/include/net.h +++ b/include/net.h @@ -31,11 +31,14 @@ struct udevice; #define DEBUG_INT_STATE 0 /* Internal network state changes */ /* - * The number of receive packet buffers, and the required packet buffer - * alignment in memory. - * + * The number of receive packet buffers, and the required packet buffer + * alignment in memory. */ +#ifdef CONFIG_SYS_RX_ETH_BUFFER #define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER +#else +#define PKTBUFSRX 4 +#endif #define PKTALIGN ARCH_DMA_MINALIGN /* Number of packets processed together */ diff --git a/net/Kconfig b/net/Kconfig index 4215889127c9..a13ab1d80a0d 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -252,8 +252,6 @@ config IPV6 ip6addr, serverip6. If a u-boot command is capable to parse an IPv6 address and find it, it will force using IPv6 in the network stack. -endif # if NET - config SYS_RX_ETH_BUFFER int "Number of receive packet buffers" default 4 @@ -262,3 +260,5 @@ config SYS_RX_ETH_BUFFER controllers it is recommended to set this value to 8 or even higher, since all buffers can be full shortly after enabling the interface on high Ethernet traffic. + +endif # if NET -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 03/19] video: Hide the BMP options
These appear prominently in the main menu at present. However they are selected when needed so do not need to be visible. Make them hidden. Signed-off-by: Simon Glass --- (no changes since v1) common/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index 0b09bd68bd13..844531a59eda 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -1169,12 +1169,12 @@ config IO_TRACE bool config BMP - bool "Enable bmp image display" + bool # Enable bmp image display help Enable bmp functions to display bmp image and get bmp info. config SPL_BMP - bool "Enable bmp image display at SPL" + bool # Enable bmp image display at SPL depends on SPL_VIDEO help Enable bmp functions to display bmp image and get bmp info at SPL. -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 02/19] Kconfig: Move API into general setup
This is perhaps not a commonly used feature so should not have its own option in the main menu. Move it under general setup. Signed-off-by: Simon Glass --- (no changes since v1) Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Kconfig b/Kconfig index 91170bf8d223..0a2e97578dfc 100644 --- a/Kconfig +++ b/Kconfig @@ -585,10 +585,10 @@ config MP This provides an option to bringup different processors in multiprocessor cases. -endmenu# General setup - source "api/Kconfig" +endmenu# General setup + source "boot/Kconfig" source "common/Kconfig" -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 01/19] lib: rational: Move the Kconfigs into the correct place
These should not be part of the 'system tables' menu. Move them outside
on their own.
Signed-off-by: Simon Glass
Fixes: 7d0f3fbb93c ("lib: rational: copy the rational fraction lib...")
---
(no changes since v1)
lib/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index 42e559ad0b51..9addcfab3734 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -989,6 +989,8 @@ config GENERATE_SMBIOS_TABLE
See also SMBIOS_SYSINFO which allows SMBIOS values to be provided in
the devicetree.
+endmenu
+
config LIB_RATIONAL
bool "enable continued fraction calculation routines"
@@ -996,8 +998,6 @@ config SPL_LIB_RATIONAL
bool "enable continued fraction calculation routines for SPL"
depends on SPL
-endmenu
-
config ASN1_COMPILER
bool
help
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 00/19] Kconfig: Tidy up some options
The view from 'make menuconfig' is confusing in places. This series aims
to improve the top-level menu and also the boot menu.
It also groups FDT-fixup options tegether, at least the ones I could fine.
Finally this series marks the distro scripts as deprecated, so people have
a pointer to standard boot.
Changes in v2:
- Fix FMU typo in the subject
- Drop now-unnecessary depends on FWU_MULTI_BANK_UPDATE
- Mention in the DISTRO_DEFAULTS option that it is script-based
- Expand and rewrite the commit message
- Use the word 'Mark' instead of 'Make' to improve the English
Simon Glass (19):
lib: rational: Move the Kconfigs into the correct place
Kconfig: Move API into general setup
video: Hide the BMP options
video: Move BMP options and code to video directory
net: Move SYS_RX_ETH_BUFFER into the network menu
FWU: Avoid showing an unselectable menu option
test: Move POST under a renamed Testing section
boot: Move fdt_support to boot/
Move fdt_simplefb to boot/
boot: Move some other fdt-fixup options to the same menu
boot: Rename Android-boot text
Kconfig: Create a menu for FIT
Kconfig: Move SPL_FIT under FIT
spl: Tidy up load address in spl_ram
boot: Make standard boot a menu
Kconfig: Move TEXT_BASE et al under general setup
Mark DISTRO_DEFAULTS as deprecated
boot: Join FDT_FIXUP_PARTITIONS with related options
boot: Join ARCH_FIXUP_FDT_MEMORY with related options
Kconfig | 67 ++-
boot/Kconfig| 202 +---
boot/Makefile | 4 +
{common => boot}/fdt_simplefb.c | 0
{common => boot}/fdt_support.c | 0
common/Kconfig | 20
common/Makefile | 4 -
common/spl/spl_ram.c| 19 ++-
doc/develop/bootstd.rst | 23
drivers/video/Kconfig | 11 ++
drivers/video/Makefile | 2 +
{common => drivers/video}/bmp.c | 0
include/net.h | 9 +-
lib/Kconfig | 17 +--
lib/fwu_updates/Kconfig | 9 +-
net/Kconfig | 4 +-
test/Kconfig| 12 +-
17 files changed, 220 insertions(+), 183 deletions(-)
rename {common => boot}/fdt_simplefb.c (100%)
rename {common => boot}/fdt_support.c (100%)
rename {common => drivers/video}/bmp.c (100%)
--
2.42.0.rc2.253.gd59a3bf2b4-goog
Re: [RFX PATCH 0/9] Universal Payload initial series
Am 31. August 2023 01:28:37 MESZ schrieb Simon Glass : >Universal Payload (UPL) is an upcoming Industry Standard for firmware >components. UPL is designed to improve interoperability within the >firmware industry, allowing mixing and matching of projects with less >friction and fewer project-specific implementations. UPL is >cross-platform, supporting ARM, x86 and RISC-V initially. > >This series provides some initial support for this, for comment only. > > >Simon Glass (9): > upl: Add support for reading a upl handoff > upl: Add support for writing a upl handoff > upl: Add basic tests > upl: Add a command > upl: Add support for Universal Payload in SPL > spl: Plumb in the Universal Payload handoff > Plumb in universal payload to the init process > sandbox_vpl: Enable Universal Payload > upl: Add initial documentation > > boot/Kconfig | 72 +++- > boot/Makefile | 4 + > boot/upl_common.c | 51 +++ > boot/upl_common.h | 24 ++ > boot/upl_read.c | 607 + > boot/upl_write.c | 623 ++ > cmd/Kconfig | 7 + > cmd/Makefile | 1 + > cmd/upl.c | 99 + > common/board_f.c | 22 ++ > common/board_r.c | 2 + > common/spl/Makefile | 2 + > common/spl/spl.c | 6 + > common/spl/spl_fit.c | 22 ++ > common/spl/spl_upl.c | 153 > configs/sandbox_defconfig | 6 +- > configs/sandbox_vpl_defconfig | 4 + > doc/usage/cmd/upl.rst | 149 +++ > doc/usage/index.rst | 2 + > doc/usage/upl.rst | 27 ++ /doc/usage/spl_boot.rst should be updated, too. Best regards Heinrich > include/asm-generic/global_data.h | 15 + > include/spl.h | 11 + > include/upl.h | 361 + > test/boot/Makefile| 2 + > test/boot/upl.c | 457 ++ > test/py/tests/test_upl.py | 25 ++ > 26 files changed, 2750 insertions(+), 4 deletions(-) > create mode 100644 boot/upl_common.c > create mode 100644 boot/upl_common.h > create mode 100644 boot/upl_read.c > create mode 100644 boot/upl_write.c > create mode 100644 cmd/upl.c > create mode 100644 common/spl/spl_upl.c > create mode 100644 doc/usage/cmd/upl.rst > create mode 100644 doc/usage/upl.rst > create mode 100644 include/upl.h > create mode 100644 test/boot/upl.c > create mode 100644 test/py/tests/test_upl.py >
Re: [PATCH v2] cmd: dm: allow for selecting uclass and device
Hi AKASHI,
On Tue, 22 Aug 2023 at 19:50, AKASHI Takahiro
wrote:
>
> The output from "dm tree" or "dm uclass" is a bit annoying
> if the number of devices available on the system is huge.
> (This is especially true on sandbox when I debug some DM code.)
>
> With this patch, we can specify the uclass name or the device
> name that we are interested in in order to limit the output.
>
> For instance,
>
> => dm uclass usb
> uclass 121: usb
> 0 usb@1 @ 0bcff8b0, seq 1
>
> uclass 124: usb
>
> => dm tree usb:usb@1
> Class Index Probed DriverName
> ---
> usb 0 [ ] usb_sandbox usb@1
> usb_hub 0 [ ] usb_hub `-- hub
> usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
> usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
> usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
> usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
> usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
>
> If you want forward-matching against a uclass or udevice name,
> you can specify "-e" option.
I don't really know what 'forward matching' means.
Please use forward instead of forword in the code
>
> => dm uclass -e usb
> uclass 15: usb_emul
> 0 hub-emul @ 0bcffb00, seq 0
> 1 flash-stick@0 @ 0bcffc30, seq 1
> 2 flash-stick@1 @ 0bcffdc0, seq 2
> 3 flash-stick@2 @ 0bcfff50, seq 3
> 4 keyb@3 @ 0bd000e0, seq 4
>
> uclass 64: usb_mass_storage
>
> uclass 121: usb
> 0 usb@1 @ 0bcff8b0, seq 1
>
> uclass 122: usb_dev_generic
>
> uclass 123: usb_hub
> 0 hub @ 0bcff9b0, seq 0
>
> uclass 124: usb
>
> => dm tree -e usb
> Class Index Probed DriverName
> ---
> usb 0 [ ] usb_sandbox usb@1
> usb_hub 0 [ ] usb_hub `-- hub
> usb_emul 0 [ ] usb_sandbox_hub `-- hub-emul
> usb_emul 1 [ ] usb_sandbox_flash |-- flash-stick@0
> usb_emul 2 [ ] usb_sandbox_flash |-- flash-stick@1
> usb_emul 3 [ ] usb_sandbox_flash |-- flash-stick@2
> usb_emul 4 [ ] usb_sandbox_keyb `-- keyb@3
>
> Signed-off-by: AKASHI Takahiro
> ---
> v2
> - allow for forward-matching against the name
> - update command doc
> ---
> cmd/dm.c | 48 ++
> doc/usage/cmd/dm.rst | 30 ++-
> drivers/core/dump.c | 116 ---
> include/dm/util.h| 15 --
> 4 files changed, 165 insertions(+), 44 deletions(-)
Reviewed-by: Simon Glass
Thanks for doing this. It will be a big time-saver. I also wonder if
it would be better if the default were to do a substring search and
you have to add a flag to search for a single device?
See below
>
> diff --git a/cmd/dm.c b/cmd/dm.c
> index 3263547cbec6..1aa86aab9c1c 100644
> --- a/cmd/dm.c
> +++ b/cmd/dm.c
> @@ -59,11 +59,26 @@ static int do_dm_dump_static_driver_info(struct cmd_tbl
> *cmdtp, int flag,
> static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
> {
> - bool sort;
> -
> - sort = argc > 1 && !strcmp(argv[1], "-s");
> -
> - dm_dump_tree(sort);
> + bool extended = false, sort = false;
> + char *device = NULL;
> +
> + for (; argc > 1; argc--, argv++) {
> + if (argv[1][0] != '-')
> + break;
> +
> + if (!strcmp(argv[1], "-e")) {
> + extended = true;
> + } else if (!strcmp(argv[1], "-s")) {
> + sort = true;
> + } else {
> + printf("Unknown parameter: %s\n", argv[1]);
> + return 0;
> + }
> + }
> + if (argc > 1)
> + device = argv[1];
> +
> + dm_dump_tree(device, extended, sort);
>
> return 0;
> }
> @@ -71,7 +86,20 @@ static int do_dm_dump_tree(struct cmd_tbl *cmdtp, int
> flag, int argc,
> static int do_dm_dump_uclass(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[])
> {
> - dm_dump_uclass();
> + bool extended = false;
> + char *uclass = NULL;
> +
> + if (argc > 1) {
> + if (!strcmp(argv[1], "-e")) {
> + extended = true;
> + argc--;
> + argv++;
> + }
> + if (argc > 1)
> + uclass = argv[1];
> + }
> +
> + dm_dump_uclass(uclass, extended);
>
> return 0;
> }
> @@ -91,8 +119,8 @@ static char dm_help_text[] =
> "dm drivers Dump list of drivers with uclass and instances\n"
> DM_MEM_HELP
> "dm staticDump list of driver
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Peter, On Wed, 30 Aug 2023 at 02:19, Peter Robinson wrote: > > > > > > > I have started the process to upstream the binman bindings. > > > > > > > > > > I don't think they should be in DT at all, they don't describe > > > > > anything to do with hardware, or generally even the runtime of a > > > > > device, they don't even describe the boot/runtime state of the > > > > > firmware, they describe build time, so I don't see what that has to do > > > > > with device tree? Can you explain that? To me those sorts of things > > > > > should live in a build time style config file. > > > > > > > > I beg to differ. Devicetree is more than just hardware and always has > > > > been. See, for example the /chosen and /options nodes. > > > > > > Can you give me an example of "options" as grep doesn't give me a > > > single one in the kernel tree? I think we can just agree to disagree > > > here. > > > > See here: > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml > > All of those options look to me like they would work just fine in a > .env file like you've added board/raspberrypi/rpi/rpi.env But that is built into U-Boot. How can it be controlled by another previous progress in the firmware stack? > > > I don't mind disagreeing, so long as it doesn't result in any > > restrictions on using devicetree in firmware. But it is very important > > to the success of firmware that we can make full use of the > > devicetree. > > That statement doesn't make sense, of course the firmware makes full > use of the DT because it needs it to instantiate the HW. You don't > actually answer my question though. I think I tried to answer your question but we are not on the same page. Please don't say that DT is just for hardware, since that is a sore point with me. It helf back U-Boot for many years, to no useful purpose. Perhaps you could restate the question? Also, why are you trying to keep things out of the DT? > > > > > We need run-time configuration here, since we cannot know at build > > > > time what we will be asked to do by a previous firmware phase. > > > > > > Can you provide an example as to how that is used during runtime? Do > > > you mean runtime during the build process or runtime on the device? > > > > I mean runtime on the device. An example is that we might want to > > control whether the serial UART is enabled, without having to rebuild > > each program in the firmware stack. > > That is describing the HW though, such as whether a serial port is > enabled or not, it's not how the binman pieces you're adding to DT are > used during runtime which is the question I was asking. There is: 1. whether the serial device is enabled in the DT 2. whether it emits character or not Often we always want 1, in case we need to emit something. But for 2 we want to control it with a global setting that applies to all programs in the firmware flow. Another example would be a framebuffer address, where we want to provide it in the DT so that all programs can use the same one. > > > > > > > > > > > > > > > Perhaps we should use the issue tracker[1] to follow progress on all > > > > > > of this. We need to clean it up. > > > > > > > > > > > > > > > > > > > > > Instead of this, how about working on bringing the DT > > > > > > > > validation into > > > > > > > > U-Boot so we can see what state things are in? > > > > > > > > > > > > > > > > Please send the bindings for Linaro's recent series (which I > > > > > > > > suspect > > > > > > > > are motivating this series) so we can start the process. > > > > > > > > > > > > Regards, > > > > > > Simon > > > > > > > > > > > > [1] https://source.denx.de/u-boot/u-boot/-/issues Regards, Simon
Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image
Hi Ferass, On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi wrote: > > Hi Simon, > > > So I wonder how best to move this forward so that we can build things > > using binman and everything works? > > It's still not ready yet, but I'm working on porting U-Boot SPL to some > Amlogic SoCs [1]. I'm currently working on Amlogic S905 boards, but > eventually I'll work on Amlogic S905X devices too. And speaking of > signing, Jonas Karlman wrote amlimage, and integrated it into mkimage, > and I applied his patch to my tree. There's a few things to be aware of > about Amlogic signing and binaries in general, however. > > amlimage was intended for use with U-Boot SPL, which obviously has > no support for Amlogic's FIP format and as such amlimage will only do as > little as possible to get the bootROM to load U-Boot SPL. Most of the > packaging format is handled by BL2. The fact that the signing process is > completly different across SoC generations makes it difficult to > implement them all into one single tool (and by which I mean all of it, > not just signing BL2 for the bootROM to run it, that's mostly the same > across SoCs). amlimage has been confirmed to work on GXBB (ODROID-C2 and > the KII Pro set-top box), GXL (librecomputer lepotato), and SM1 (ODROID-C4). > > My U-Boot SPL port is still rather incomplete. As of today, it still > can't boot anything from any storage device. The goal eventually is to > be able to load upstream TF-A BL31 and U-Boot+linux. > > While Amlogic distributes proprietary BL31 binaries upstream Trusted > Firmware-A has a port for some Amlogic SoCs [2], but as far as I know > SM1 (which is the SoC generation your ODROID-C4 is using) is still > unsupported. GXBB, GXL, AXG, and G12A are all supported however, but the > overall port still lacks some features the proprietary implementation > has. > > As for the SCP firmware (aka. BL30) I'm not aware of any > reverse-engineering efforts for that. > Thanks for your efforts on this. I look forward to seeing where it ends up. > Honestly, in my opinion, including proprietary and poorly-written > Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea. With Binman, we don't really include them in U-Boot; we allow them to be fetched easily so that a complete build can be produced. I don't like it either, but for users it is better than doing the build manually. > > [1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl > [2]: > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic > > Cheers. > Regards, Simon
[PATCH v2 2/2] x86: Prevent from missing the FADT chaining
From: Andy Shevchenko
Recent approach with FADT writer shows that there is
a room for subtle errors. Prevent this from happening
again by introducing acpi_add_fadt() helper.
Signed-off-by: Andy Shevchenko
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/apollolake/acpi.c | 6 +-
arch/x86/cpu/baytrail/acpi.c | 6 +-
arch/x86/cpu/quark/acpi.c | 6 +-
arch/x86/cpu/tangier/acpi.c| 6 +-
include/acpi/acpi_table.h | 7 +++
5 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/x86/cpu/apollolake/acpi.c b/arch/x86/cpu/apollolake/acpi.c
index 16aaed7238a..c610a7f4477 100644
--- a/arch/x86/cpu/apollolake/acpi.c
+++ b/arch/x86/cpu/apollolake/acpi.c
@@ -158,11 +158,7 @@ static int apl_write_fadt(struct acpi_ctx *ctx, const
struct acpi_writer *entry)
header = &fadt->header;
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", apl_write_fadt, 0);
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index 4c526ff2731..4378846f8b0 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -142,11 +142,7 @@ static int baytrail_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", baytrail_write_fadt, 0);
diff --git a/arch/x86/cpu/quark/acpi.c b/arch/x86/cpu/quark/acpi.c
index 92fa5bc30c3..9a2d682451b 100644
--- a/arch/x86/cpu/quark/acpi.c
+++ b/arch/x86/cpu/quark/acpi.c
@@ -137,11 +137,7 @@ static int quark_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", quark_write_fadt, 0);
diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index ffaa56ab6f8..1c667c7d569 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -52,11 +52,7 @@ static int tangier_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", tangier_write_fadt, 0);
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 7ed0443c821..1f85de091d3 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -883,6 +883,13 @@ void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
*/
int acpi_add_table(struct acpi_ctx *ctx, void *table);
+static inline int acpi_add_fadt(struct acpi_ctx *ctx, struct acpi_fadt *fadt)
+{
+ acpi_add_table(ctx, fadt);
+ acpi_inc(ctx, sizeof(struct acpi_fadt));
+ return 0;
+}
+
/**
* acpi_write_rsdp() - Write out an RSDP indicating where the ACPI tables are
*
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v2 1/2] Reland "x86: Move FACP table into separate functions""
Each board has its own way of creating this table. Rather than calling the
acpi_create_fadt() function for each one from a common acpi_write_fadt()
function, just move the writer into the board-specific code.
Signed-off-by: Simon Glass
Signed-off-by: Andy Shevchenko
---
(Now fixed - thank you Andy!)
Make another attempt to land this. It apparently breaks Edison but I
cannot test that board, nor can I work out what is wrong with the code.
Previous test report is here:
https://lore.kernel.org/all/yga9z7sbfaev6...@smile.fi.intel.com/
Looking at the image, the method is definitely present:
$ nm /tmp/b/edison/u-boot |grep acpi_writer
0115fde0 D _u_boot_list_2_acpi_writer_2_0base
0115fdf0 D _u_boot_list_2_acpi_writer_2_1facs
0115fe00 D _u_boot_list_2_acpi_writer_2_3dsdt
0115fe10 D _u_boot_list_2_acpi_writer_2_4gnvs
0115fe20 D _u_boot_list_2_acpi_writer_2_5csrt
0115fe30 D _u_boot_list_2_acpi_writer_2_5fadt
0115fe40 D _u_boot_list_2_acpi_writer_2_5mcfg
0115fe50 D _u_boot_list_2_acpi_writer_2_5spcr
0115fe60 D _u_boot_list_2_acpi_writer_2_5tcpa
0115fe70 D _u_boot_list_2_acpi_writer_2_5tpm2
0115fe80 D _u_boot_list_2_acpi_writer_2_5x86
0115fe90 D _u_boot_list_2_acpi_writer_2_6ssdt
0115fea0 D _u_boot_list_2_acpi_writer_2_8dev
I wonder if the code in quark_write_fadt() is not being called?
'acpi list' shows what tables are installed. On minnowmax there is no
difference with or without this patch. Perhaps someone with sharper eyes
than me can figure this out?
The mechanism is that the functions to be called are put in a linker list,
each element being declared using ACPI_WRITER(function_name).
Then acpi_write_all() is called to write each one. Debugging could be
added to that function, perhaps?
Changes in v2:
- Squash in the fix from Andy Shevchenko
arch/x86/cpu/apollolake/acpi.c| 17 +
arch/x86/cpu/baytrail/acpi.c | 27 +++
arch/x86/cpu/quark/acpi.c | 27 +++
arch/x86/cpu/tangier/acpi.c | 27 +++
arch/x86/include/asm/acpi_table.h | 2 --
arch/x86/lib/acpi_table.c | 15 ---
6 files changed, 70 insertions(+), 45 deletions(-)
diff --git a/arch/x86/cpu/apollolake/acpi.c b/arch/x86/cpu/apollolake/acpi.c
index fd21c0b4968..16aaed7238a 100644
--- a/arch/x86/cpu/apollolake/acpi.c
+++ b/arch/x86/cpu/apollolake/acpi.c
@@ -146,16 +146,25 @@ void fill_fadt(struct acpi_fadt *fadt)
fadt->x_pm_tmr_blk.addrl = IOMAP_ACPI_BASE + PM1_TMR;
}
-void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
- void *dsdt)
+static int apl_write_fadt(struct acpi_ctx *ctx, const struct acpi_writer
*entry)
{
- struct acpi_table_header *header = &fadt->header;
+ struct acpi_table_header *header;
+ struct acpi_fadt *fadt;
- acpi_fadt_common(fadt, facs, dsdt);
+ fadt = ctx->current;
+ acpi_fadt_common(fadt, ctx->facs, ctx->dsdt);
intel_acpi_fill_fadt(fadt);
fill_fadt(fadt);
+ header = &fadt->header;
header->checksum = table_compute_checksum(fadt, header->length);
+
+ acpi_add_table(ctx, fadt);
+
+ acpi_inc(ctx, sizeof(struct acpi_fadt));
+
+ return 0;
}
+ACPI_WRITER(5fadt, "FADT", apl_write_fadt, 0);
int apl_acpi_fill_dmar(struct acpi_ctx *ctx)
{
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index 07757b88a30..4c526ff2731 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -15,20 +15,24 @@
#include
#include
-void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
- void *dsdt)
+static int baytrail_write_fadt(struct acpi_ctx *ctx,
+ const struct acpi_writer *entry)
{
- struct acpi_table_header *header = &(fadt->header);
+ struct acpi_table_header *header;
+ struct acpi_fadt *fadt;
+
+ fadt = ctx->current;
+ header = &fadt->header;
u16 pmbase = ACPI_BASE_ADDRESS;
- memset((void *)fadt, 0, sizeof(struct acpi_fadt));
+ memset(fadt, '\0', sizeof(struct acpi_fadt));
acpi_fill_header(header, "FACP");
header->length = sizeof(struct acpi_fadt);
header->revision = 4;
- fadt->firmware_ctrl = (u32)facs;
- fadt->dsdt = (u32)dsdt;
+ fadt->firmware_ctrl = (u32)ctx->facs;
+ fadt->dsdt = (u32)ctx->dsdt;
fadt->preferred_pm_profile = ACPI_PM_MOBILE;
fadt->sci_int = 9;
fadt->smi_cmd = 0;
@@ -75,9 +79,9 @@ void acpi_create_fadt(struct acpi_fadt *fadt, struct
acpi_facs *facs,
fadt->reset_reg.addrh = 0;
fadt->reset_value = SYS_RST | RST_CPU | FULL_RST;
- fadt->x_firmware_ctl_l = (u32)facs;
+ fadt->x_firmware_ctl_l = (u32)ctx->facs;
fadt->x_firmware_ctl_h = 0;
- fadt->x_dsdt_l = (u32)dsdt;
+ fadt->x_dsdt_l = (u32)ctx->dsdt;
fadt->x_dsdt_h = 0;
Re: [RFC PATCH 1/2] Makefile: Run defconfig files through the C preprocessor
Hi Andrew, On Tue, 29 Aug 2023 at 16:15, Andrew Davis wrote: > > This allows us to use some of the normal preprocessor directives inside > defconfig files. Such as #define and #include. > > Signed-off-by: Andrew Davis > --- > scripts/kconfig/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 12e525ee31f..16db9b7cf60 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -93,7 +93,8 @@ endif > endif > > %_defconfig: $(obj)/conf > - $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig) > + $(Q)$(CPP) -nostdinc -I $(srctree) -undef -x assembler-with-cpp > $(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig > + $(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig) > > # Added for U-Boot (backward compatibility) > %_config: %_defconfig > -- > 2.39.2 > Reviewed-by: Simon Glass Can you please check what happens if the file has an error flagged by CPP? Is it obvious what is wrong? Regards, Simon
Re: [PATCH v5 11/13] video: Use VIDEO_DAMAGE for VIDEO_COPY
Hi Alper,
On Wed, 30 Aug 2023 at 13:07, Alper Nebi Yasak wrote:
>
> On 2023-08-21 23:06 +03:00, Alexander Graf wrote:
> >
> > On 21.08.23 21:11, Simon Glass wrote:
> >> Hi Alper,
> >>
> >> On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak
> >> wrote:
> >>> From: Alexander Graf
> >>>
> >>> CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
> >>> print a single character, it will always copy the full range of bytes
> >>> from the top left corner of the character to the lower right onto the
> >>> uncached frame buffer. This includes pretty much the full line contents
> >>> of the printed character.
> >>>
> >>> Since we now have proper damage tracking, let's make use of that to reduce
> >>> the amount of data we need to copy. With this patch applied, we will only
> >>> copy the tiny rectangle surrounding characters when we print them,
> >>> speeding up the video console.
> >> I suppose for rotated consoles it copies whole lines, but otherwise it
> >> does a lot of small copies?
> >
> >
> > I tried to keep the code as simple as possible and only track an "upper
> > left" and "lower right" corner of modifications. So sync will always
> > copy/flush a single rectangle.
>
> Yep, see patch 06/13 for size of the regions. E.g. for putc_xy()s it's
> fontdata->height * fontdata->width, for rows it's like fontdata->height
> * vid_priv->xsize * count...
>
> >>
> >>> After this, changes to the main frame buffer are not immediately copied
> >>> to the copy frame buffer, but postponed until the next video device
> >>> sync. So issue an explicit sync before inspecting the copy frame buffer
> >>> contents for the video tests.
> >> So how does the sync get done in this case?
> >
> > It gets called as part of video_sync():
> >
> > +static void video_flush_copy(struct udevice *vid)
> > +{
> > + struct video_priv *priv = dev_get_uclass_priv(vid);
> > +
> > + if (!priv->copy_fb)
> > + return;
> > +
> > + if (priv->damage.xend && priv->damage.yend) {
> > + int lstart = priv->damage.xstart * VNBYTES(priv->bpix);
> > + int lend = priv->damage.xend * VNBYTES(priv->bpix);
> > + int y;
> > +
> > + for (y = priv->damage.ystart; y < priv->damage.yend; y++) {
> > + ulong offset = (y * priv->line_length) + lstart;
> > + ulong len = lend - lstart;
> > +
> > + memcpy(priv->copy_fb + offset, priv->fb + offset,
> > len);
> > + }
> > + }
> > +}
>
> I think Simon was asking how and when video_sync() is called outside the
> tests. The tests use lower-level functions that are ops->putc_xy() in
> each console, and normally vidconsole calls higher on the call-chain
> also maybe do a video_sync() when they think it's worth updating the
> display.
>
> >>
> >>> Signed-off-by: Alexander Graf
> >>> [Alper: Rebase for fontdata->height/w, fill_part(), fix memmove(dev),
> >>> drop from defconfig, use damage.xstart/yend, use IS_ENABLED(),
> >>> call video_sync() before copy_fb check, update video_copy test]
> >>> Co-developed-by: Alper Nebi Yasak
> >>> Signed-off-by: Alper Nebi Yasak
> >>> ---
> >>>
> >>> Changes in v5:
> >>> - Remove video_sync_copy() also from video_fill(), video_fill_part()
> >>> - Fix memmove() calls by removing the extra dev argument
> >>> - Call video_sync() before checking copy_fb in video tests
> >>> - Use xstart, ystart, xend, yend as names for damage region
> >>> - Use met->baseline instead of priv->baseline
> >>> - Use fontdata->height/width instead of VIDEO_FONT_HEIGHT/WIDTH
> >>> - Use xstart, ystart, xend, yend as names for damage region
> >>> - Use IS_ENABLED() instead of CONFIG_IS_ENABLED()
> >>> - Drop VIDEO_DAMAGE from sandbox defconfig added in a new patch
> >>> - Update dm_test_video_copy test added in a new patch
> >>>
> >>> Changes in v3:
> >>> - Make VIDEO_COPY always select VIDEO_DAMAGE
> >>>
> >>> Changes in v2:
> >>> - Add patch "video: Use VIDEO_DAMAGE for VIDEO_COPY"
> >>>
> >>> configs/sandbox_defconfig | 1 -
> >>> drivers/video/Kconfig | 5 ++
> >>> drivers/video/console_normal.c| 13 +
> >>> drivers/video/console_rotate.c| 44 +++---
> >>> drivers/video/console_truetype.c | 16 +
> >>> drivers/video/vidconsole-uclass.c | 16 -
> >>> drivers/video/video-uclass.c | 97 ---
> >>> drivers/video/video_bmp.c | 7 ---
> >>> include/video.h | 37
> >>> include/video_console.h | 52 -
> >>> test/dm/video.c | 3 +-
> >>> 11 files changed, 43 insertions(+), 248 deletions(-)
> >>>
> >>> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> >>> index 51b820f13121..259f31f26cee 100644
> >>> --- a/configs/sandbox_defconfig
> >>> +++ b/configs/sandbox_defconfig
> >>> @@ -307,7 +307,6 @@ CONFIG_USB_ETH_CDC=y
> >>> CONFIG_VIDEO=y
> >>> CONFIG_VI
Re: [RFC PATCH 2/2] configs: Add am62x_beagleplay_* defconfigs
Hi, On Wed, 30 Aug 2023 at 09:17, Andrew Davis wrote: > > On 8/30/23 9:59 AM, Nishanth Menon wrote: > > On 09:31-20230830, Andrew Davis wrote: > >> On 8/30/23 7:31 AM, Nishanth Menon wrote: > >>> On 17:14-20230829, Andrew Davis wrote: > >>>> Add am62x_beagleplay_r5_defconfig for R5 SPL and > >>>> am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support. > >>>> > >>>> These defconfigs are composite defconfigs built from the config fragment > >>>> board/ti/am62x/beagleplay_*.config applied onto the base > >>>> am62x_evm_*_defconfig. > >>>> > >>>> Signed-off-by: Andrew Davis > >>>> --- > >>>>configs/am62x_beagleplay_a53_defconfig | 3 +++ > >>>>configs/am62x_beagleplay_r5_defconfig | 3 +++ > >>>>2 files changed, 6 insertions(+) > >>>>create mode 100644 configs/am62x_beagleplay_a53_defconfig > >>>>create mode 100644 configs/am62x_beagleplay_r5_defconfig > >>>> > >>>> diff --git a/configs/am62x_beagleplay_a53_defconfig > >>>> b/configs/am62x_beagleplay_a53_defconfig > >>>> new file mode 100644 > >>>> index 000..ad708e15397 > >>>> --- /dev/null > >>>> +++ b/configs/am62x_beagleplay_a53_defconfig > >>>> @@ -0,0 +1,3 @@ > >>>> +// The BeaglePlay defconfig for A53 core > >>>> +#include "configs/am62x_evm_a53_defconfig" > >>>> +#include "board/ti/am62x/beagleplay_a53.config" > >>>> diff --git a/configs/am62x_beagleplay_r5_defconfig > >>>> b/configs/am62x_beagleplay_r5_defconfig > >>>> new file mode 100644 > >>>> index 000..276b1f81a3e > >>>> --- /dev/null > >>>> +++ b/configs/am62x_beagleplay_r5_defconfig > >>>> @@ -0,0 +1,3 @@ > >>>> +// The BeaglePlay defconfig for R5 core > >>>> +#include "configs/am62x_evm_r5_defconfig" > >>>> +#include "board/ti/am62x/beagleplay_r5.config" > >>>> -- > >>>> 2.39.2 > >>>> > >>> > >>> my only complaint is that if we add lets say > >>> board/ti/am62x/dfu.config, Then: > >>> > >>> R5: > >>> 1. am62x_evm_r5_defconfig = am62x_evm_r5_defconfig > >>> 2. am62x_beagleplay_r5_defconfig = am62x_evm_r5_defconfig + > >>> beagleplay_r5.config > >>> 3. am62x_evm_r5_dfu_defconfig = am62x_evm_r5_defconfig + dfu.config > >>> 4. am62x_beagleplay_r5_dfu_defconfig = am62x_evm_r5_defconfig + > >>> beagleplay_r5.config + dfu.config > >>> > >>> This information can be in a single txt file Rather than have a > >>> defconfig file for each combination. > >>> > >> > >> Having every combination in a text file vs in a directory of files doesn't > >> seem like much difference to me. `cat combinations.txt` vs `ls -l > >> configs/`. > >> But using a file would mean extra tooling and non-standard usage. > > > > The .config usage is a standard already in kernel - nothing new there. > > > > What we are attempting to solve is CI build coverage and test aspect of > > things. > > > > Exactly, when I say "standard" I mean CI standard, which is to take all > the configs/* and build them. No parsing these new combination files needed. > Just add a new configs/xx_defconfig for a combination you want to be > CI tested and you are done. > > > Thinking aloud here: > > some sort of board///ci.conf yaml could probably be a better > > approach with description of build, automated test information, > > potentially board revisions etc. > > > >> Let's simply try to avoid these combinatorial problems by avoiding adding > >> too many fragments that apply broadly. That adds testing burden. When > >> features > > > > The combinations will be valid since the intent is a supported > > configuration. > > > > In theory anything you do in menuconfig should result in a valid configuration > (if we have our kconfig symbol dependencies in order). And randomconfig > testing > can handle that. The combinations we want always tested should be limited, and > making each have a dedicated configs/ file does that. I think this is a reasonable solution to what I see as the problem (we don't know what we can build) but I am very open to others. Reviewed-by: Simon Glass Regards, Simon
Re: [RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal
Hi Ilias, On Wed, 30 Aug 2023 at 01:25, Ilias Apalodimas wrote: > > Hi Tom > > On Mon, 28 Aug 2023 at 21:39, Tom Rini wrote: > > > > On Tue, Aug 29, 2023 at 12:04:53AM +0530, Sughosh Ganu wrote: > > > hi Simon, > > > > > > On Mon, 28 Aug 2023 at 23:25, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > > wrote: > > > > > > > > > > Add a document explaining the need for removal of non-compliant > > > > > devicetree nodes and properties. Also describe in brief, the macros > > > > > that can be used for this removal. > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > +++ > > > > > 1 file changed, 64 insertions(+) > > > > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > > > > > diff --git a/doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > b/doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > new file mode 100644 > > > > > index 00..c3a8feab5b > > > > > --- /dev/null > > > > > +++ b/doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > @@ -0,0 +1,64 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > + > > > > > +Removal of non-compliant nodes and properties > > > > > += > > > > > + > > > > > +The devicetree used in U-Boot might contain nodes and properties > > > > > which > > > > > +are specific only to U-Boot, and are not necessarily being used to > > > > > +describe hardware but to pass information to U-Boot. An example of > > > > > +such a property would be the public key being passed to U-Boot for > > > > > +verification. > > > > > > > > It has nothing to do with describing hardware. The DT can describe > > > > other things too. See the /options node, for example. > > > > > > > > Please don't bring this highly misleading language into U-Boot. > > > > > > Please point out what is misleading in the above paragraph. What is > > > being emphasised in the above paragraph is that certain nodes and > > > properties in the devicetree are relevant only in u-boot, and not the > > > kernel. And this is precisely what the devicetree maintainers are > > > saying [1]. > > > > > > > > > > > > + > > > > > +This devicetree can then be passed to the OS. Since certain nodes and > > > > > +properties are not really describing hardware, and more importantly, > > > > > +these are only relevant to U-Boot, bindings for these cannot be > > > > > +upstreamed into the devicetree repository. There have been instances > > > > > +of attempts being made to upstream such bindings, and these deemed > > > > > not > > > > > +fit for upstreaming. > > > > > > > > Then either they should not be in U-Boot, or there is a problem with > > > > the process. > > > > > > > > > Not having a binding for these nodes and > > > > > +properties means that the devicetree fails the schema compliance > > > > > tests > > > > > +[1]. This also means that the platform cannot get certifications like > > > > > +SystemReady [2] which, among other things require a devicetree which > > > > > +passes the schema compliance tests. > > > > > + > > > > > +For such nodes and properties, it has been suggested by the > > > > > devicetree > > > > > +maintainers that the right thing to do is to remove them from the > > > > > +devicetree before it gets passed on to the OS [3]. > > > > > > > > Hard NAK. If we go this way, then no one will ever have an incentive > > > > to do the right thing. > > > > > > > > Please send bindings for Linaro's work, instead. If something is > > > > entirely U-Boot-specific, then it can go in /options/u-boot but it > > > > still must be in the dt-schema. > > > > > > Please re-read the document including the last link [1]. If you go > > > through that entire thread, you will notice that this is precisely > > > what Linaro was trying to do here -- upstream the binding for the > > > fwu-mdata node. It is only based on the feedback of the devicetree > > > maintainers that this patchset was required. > > > > > > -sughosh > > > > > > [1] - > > > https://lore.kernel.org/u-boot/cal_jsqjn4fehoml7z3yj0wj9bpx1ose7zf26l_gv2os6cg-...@mail.gmail.com/#t > > > > Please note that this right here, that the explanation of why we need to > > delete this node, not being a bright shiny visible object is one of the > > big problems with this patchset and implementation. It cannot be > > footnotes in email threads as to why such-and-such node/property isn't > > upstream, it needs to be documented and visible in the code base / > > documentation and an obvious you must do this for future cases. > > I thought we agreed that deleting nodes that won't be accepted > upstream is the right approach since that would break the systemready > 2.0 compatibility. Isn't that controlled by ARM/Linaros, as are the devicetree bindings? What am I missing? Let's just fix the bindings so they can be a
Re: [PATCH] driver: rng: Add DM_RNG interface for ARMv8.5 RNDR registers
Hi Andre,
On Wed, 30 Aug 2023 at 05:32, Andre Przywara wrote:
>
> The ARMv8.5 architecture extension defines architectural RNDR/RNDRRS
> system registers, that provide 64 bits worth of randomness on every
> read. Since it's an extension, and implementing it is optional, there is
> a field in the ID_AA64ISAR0_EL1 ID register to query the availability
> of those registers.
>
> Add a UCLASS_RNG driver that returns entropy via repeated reads from
> those system registers, if the extension is implemented.
> The driver always binds, but checks the availability in the probe()
> routine.
>
> This helps systems which suffer from low boot entropy, since U-Boot can
> provide entropy via the generic UEFI entropy gathering protocol to the OS,
> at an early stage.
>
> Signed-off-by: Andre Przywara
> ---
> Hi Simon,
>
> not sure if this is the expected way to model a driver which autodetects
> its device at runtime. It somewhat works, but always lists the bound
> device, even if the registers are not supported. If I do the check in bind
> instead, it fails booting when this returns -ENODEV, since it expects
> the fixed device to always bind successfully, I guess?
> Is there any other way of modeling this? And before you say your
> favourite two letters: this is not a DT job, since it can be safely
> auto-detected in an architectural way.
>
> Thanks,
> Andre
>
> arch/arm/include/asm/system.h | 1 +
> drivers/rng/Kconfig | 6 +++
> drivers/rng/Makefile | 1 +
> drivers/rng/arm_rndr.c| 82 +++
> 4 files changed, 90 insertions(+)
> create mode 100644 drivers/rng/arm_rndr.c
Reviewed-by: Simon Glass
nit below
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 87d1c77e8b1..0eae857e73a 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -84,6 +84,7 @@
> #define HCR_EL2_HCD_DIS(1 << 29) /* Hypervisor Call disabled
> */
> #define HCR_EL2_AMO_EL2(1 << 5) /* Route SErrors to EL2
> */
>
> +#define ID_AA64ISAR0_EL1_RNDR (0xFUL << 60) /* RNDR random registers */
> /*
> * ID_AA64ISAR1_EL1 bits definitions
> */
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> index 5deb5db5b71..72788d479cc 100644
> --- a/drivers/rng/Kconfig
> +++ b/drivers/rng/Kconfig
> @@ -76,6 +76,12 @@ config RNG_SMCCC_TRNG
> Enable random number generator for platforms that support Arm
> SMCCC TRNG interface.
>
> +config RNG_ARM_RNDR
> + bool "Generic ARMv8.5 RNDR register"
> + depends on DM_RNG && ARM64
> + help
> + Use the ARMv8.5 RNDR register to provide random numbers.
> +
> config TPM_RNG
> bool "Enable random number generator on TPM device"
> depends on TPM
> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> index 78f61051acf..572fa7a0c66 100644
> --- a/drivers/rng/Makefile
> +++ b/drivers/rng/Makefile
> @@ -13,4 +13,5 @@ obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
> obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
> obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
> +obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
> obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> diff --git a/drivers/rng/arm_rndr.c b/drivers/rng/arm_rndr.c
> new file mode 100644
> index 000..55989743eae
> --- /dev/null
> +++ b/drivers/rng/arm_rndr.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023, Arm Ltd.
> + *
> + * Use the (optional) ARMv8.5 RNDR register to provide random numbers to
> + * U-Boot's UCLASS_RNG users.
> + * Detection is done at runtime using the CPU ID registers.
> + */
> +
> +#define LOG_CATEGORY UCLASS_RNG
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME"arm-rndr"
> +
> +static bool cpu_has_rndr(void)
> +{
> + uint64_t reg;
> +
> + __asm__ volatile("mrs %0, ID_AA64ISAR0_EL1\n" : "=r" (reg));
> + return !!(reg & ID_AA64ISAR0_EL1_RNDR);
> +}
> +
> +/*
> + * The system register name is RNDR, but this isn't widely known among older
> + * toolchains, and also triggers errors because of it being an architecture
> + * extension. Since we check the availability of the register before, it's
> + * fine to use here, though.
> + */
> +#define RNDR "S3_3_C2_C4_0"
> +
> +static uint64_t read_rndr(void)
> +{
> + uint64_t reg;
> +
> + __asm__ volatile("mrs %0, " RNDR "\n" : "=r" (reg));
> +
> + return reg;
> +}
> +
> +static int arm_rndr_read(struct udevice *dev, void *data, size_t len)
> +{
> + uint64_t random;
> +
> + while (len) {
> + int tocopy = min(sizeof(uint64_t), len);
> +
> + random = read_rndr();
> + memcpy(data, &random, tocopy);
> + len -= tocopy;
> + data += tocopy;
> + }
> +
> + return 0;
> +}
> +
> +static const struct dm_rng_ops arm_rndr
Re: [PATCH v2] spl: bootstage: move bootstage_stash before jumping to image
Hi Chanho,
On Tue, 29 Aug 2023 at 23:10, Chanho Park wrote:
>
> Hi Simon,
>
> > -Original Message-
> > From: Simon Glass
> > Sent: Wednesday, August 30, 2023 1:38 AM
> > To: Chanho Park
> > Cc: Nikhil M Jain ; Marek Vasut ; u-
> > b...@lists.denx.de
> > Subject: Re: [PATCH v2] spl: bootstage: move bootstage_stash before
> > jumping to image
> >
> > Hi Chanho,
> >
> > On Mon, 28 Aug 2023 at 22:28, Chanho Park
> > wrote:
> > >
> > > Regarding IH_OS_OPENSBI, IH_OS_LINUX and IH_OS_TEE, there is no chance
> > > to stash bootstage record because they do not return to SPL after
> > > jumping to the image.
> > > Hence, this patch separates the final stage bootstage code into
> > > spl_bootstage_finish and call the function before jumping to the image.
> > >
> > > Signed-off-by: Chanho Park
> > > ---
> > > Changes from v1
> > > - Separate the final stage bootstage code into spl_bootstage_finish.
> > > - As Simon suggests, call the function before jumping to the image.
> >
> > I think you misunderstood me here. I mean, you cannot jump off somewhere
> > in your board code. You must change it so it returns correctly, and the
> > jump happens from spl.c's board_init_r() function.
> > The way it works is you set up the spl_image structure, then it SPL jumps
> > to it at the end of the functions.
>
> I feel like I'm still not clear on what you mean. Sorry.
>
> switch (spl_image.os) {
> case IH_OS_U_BOOT:
> case IH_OS_ARM_TRUSTED_FIRMWARE:
> case IH_OS_TEE:
> case IH_OS_OPENSBI:
> case IH_OS_LINUX:
> }
>
> Regarding ATF/TEE/OPENSBI and Linux, they need different number of arguments
> and formats to jump to the image, respectively.
> I think that's why they can't go to the final stage and can't use
> jump_to_image_no_args.
OK, so let's move that code into spl.c and have it do the right thing...
>
> Do you want to move jump codes at the end of the board_init_r function?
> The easiest way is that we just move the whole switch statements to the final
> stage of the function.
> Otherwise, the arguments can be prepared from switch statement and make
> jump_to_image function to support variable length of arguments.
> (Or we can put switch statement there to support various jump of the image)
>
> Can you elaborate a bit more?
Basically SPL should have one place where it jumps to the next phase.
If you do it willy nilly, then generic features like bloblist and
bootstage cannot work, as you have found.
The way SPL board_init_r() is set up is something like this:
- do some init
- work through the boot devices until one is found that can boot
- prepare to jump (thjis is where the bloblist and bootstage are finalised)
- jump
So we should keep this approach, even if it means putting a switch at
the end like:
switch (how_to_jump) {
case way1: ...
case way2: ...
}
Regards,
Simon
Re: [PATCH v2 4/4] dm: core: Modify default for OFNODE_MULTI_TREE
On Tue, 29 Aug 2023 at 14:37, wrote: > > From: Sean Edmond > > There is a preference to use the "ofnode" API for FDT fixups > moving forward. The FDT fixup will usually be for the kernel FDT. To > fixup the kernel FDT with the ofnode API, it's required to set the > OFNODE_MULTI_TREE option. > > To ensure existing users of kaslr fdt fixup are not impacted, Let's modify > the default value for OFNODE_MULTI_TREE to ensure it's always set if > !OF_LIVE. This will cause a 1007 byte increase in the code size. Interestingly, this option is not needed if we can pass the control DTB to Linux, But at least for now, we don't know that a priori. > > Signed-off-by: Sean Edmond > --- > drivers/core/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass > > diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig > index f0d848f45d..38e44ef6fc 100644 > --- a/drivers/core/Kconfig > +++ b/drivers/core/Kconfig > @@ -424,7 +424,7 @@ config DM_DEV_READ_INLINE > > config OFNODE_MULTI_TREE > bool "Allow the ofnode interface to access any tree" > - default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE > + default y if !OF_LIVE > help > Normally U-Boot makes use of its control FDT, the one used to bind > devices and provide options. In some cases, U-Boot must also process > -- > 2.40.0 > Regards, Simon
[PATCH] am33xx: ignore return value from usb_ether_init()
In 2cb43ef1c223 ("usb: ether: Fix error handling in usb_ether_init") the error
handling of usb_ether_init() was changed. Not a single other call site of this
function checks its return value, therefore follow suit in the am33xx code.
Do not cause the boot to halt if the usb gadget ethernet initialization fails:
initcall sequence 9ffdbd84 failed at call 808024b9 (err=-19)
### ERROR ### Please RESET the board ###
Signed-off-by: Trevor Woerner
---
arch/arm/mach-omap2/am33xx/board.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/am33xx/board.c
b/arch/arm/mach-omap2/am33xx/board.c
index ecc0a592e993..8f772310a1a7 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -270,11 +270,7 @@ int arch_misc_init(void)
return ret;
#if defined(CONFIG_DM_ETH) && defined(CONFIG_USB_ETHER)
- ret = usb_ether_init();
- if (ret) {
- pr_err("USB ether init failed\n");
- return ret;
- }
+ usb_ether_init();
#endif
return 0;
--
2.41.0.327.gaa9166bcc0ba
Re: [PATCH v5 04/13] dm: video: Add damage tracking API
Hi Alper, On Wed, 30 Aug 2023 at 13:15, Alper Nebi Yasak wrote: > > > > On 2023-08-21 22:11 +03:00, Simon Glass wrote: > > On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak > > wrote: > >> > >> From: Alexander Graf > >> > >> We are going to introduce image damage tracking to fasten up screen > >> refresh on large displays. This patch adds damage tracking for up to > >> one rectangle of the screen which is typically enough to hold blt or > >> text print updates. Callers into this API and a reduced dcache flush > >> code path will follow in later patches. > >> > >> Signed-off-by: Alexander Graf > >> Reported-by: Da Xue > >> [Alper: Use xstart/yend, document new fields, return void from > >> video_damage(), declare priv, drop headers, use IS_ENABLED()] > >> Co-developed-by: Alper Nebi Yasak > >> Signed-off-by: Alper Nebi Yasak > >> --- > >> > >> Changes in v5: > >> - Use xstart, ystart, xend, yend as names for damage region > >> - Document damage struct and fields in struct video_priv comment > >> - Return void from video_damage() > >> - Fix undeclared priv error in video_sync() > >> - Drop unused headers from video-uclass.c > >> - Use IS_ENABLED() instead of CONFIG_IS_ENABLED() > >> > >> Changes in v4: > >> - Move damage clear to patch "dm: video: Add damage tracking API" > >> - Simplify first damage logic > >> - Remove VIDEO_DAMAGE default for ARM > >> > >> Changes in v3: > >> - Adapt to always assume DM is used > >> > >> Changes in v2: > >> - Remove ifdefs > >> > >> drivers/video/Kconfig| 13 > >> drivers/video/video-uclass.c | 41 +--- > >> include/video.h | 32 ++-- > >> 3 files changed, 81 insertions(+), 5 deletions(-) > >> > > > > Reviewed-by: Simon Glass > > > > But I suggest an empty static inline in the case where the feature is > > disabled? > > You mean with something like #ifdef CONFIG_VIDEO_DAMAGE, right? Yes Regards, Simon
Re: [RFC] make sandbox UT more generic
Hi, On Wed, 30 Aug 2023 at 18:38, AKASHI Takahiro wrote: > > Hi, > > I'm working on implementing SCMI-based pinctrl/gpio driver, > and want to re-use sandbox UT to test the code. However, > It is somehow sandbox-specific (with additional DT nodes). > How can/should we make it more generic for other targets/drivers > rather than just by copying the test code? > (I have already created a test for pinmux since there is only > one existing scenario, but gpio test has many.) > > Even if I say 'generic', my case may be special since real > hardware (device drivers) cannot always run all the test cases, > while SCMI-based drivers potentially can with a dummy SCMI server > for sandbox. > See: > drivers/firmware/scmi/sandbox-scmi_agent.c We don't have a good way to test drivers that talk to hardware, in general. For I2C, SPI and some PCI devices you can sometimes write an emulator for the chip and then your driver can talk to the emulator as if it were talking to the hardware. Sandbox does actually support that with memory-mapped I/O too, although it is fairly rarely used. We have done this a lot with Zephyr, as well[1] and achieved 90% code coverage on some boards. But I'm not quite sure I am answering the right question, so I will stop here. Regards, Simon [1] https://www.youtube.com/watch?v=usXCAXR2G_c
RE: [PATCH] fpga: define dummy fpga_load function for debug build
> On 8/16/23 08:54, Chanho Park wrote: > > This fixes below build error when CC_OPTIMIZE_FOR_DEBUG is enabled and > > CONFIG_SPL_FPGA is not enabled. > > I would rewrite this because the connection to SPL_FPGA is just one part > of it. > It is also taken when CONFIG_FPGA is not enabled. Sure. Will you rewrite while you pick this patch in your tree or do you want me to post v2 patch? Best Regards, Chanho Park
[RFC] make sandbox UT more generic
Hi, I'm working on implementing SCMI-based pinctrl/gpio driver, and want to re-use sandbox UT to test the code. However, It is somehow sandbox-specific (with additional DT nodes). How can/should we make it more generic for other targets/drivers rather than just by copying the test code? (I have already created a test for pinmux since there is only one existing scenario, but gpio test has many.) Even if I say 'generic', my case may be special since real hardware (device drivers) cannot always run all the test cases, while SCMI-based drivers potentially can with a dummy SCMI server for sandbox. See: drivers/firmware/scmi/sandbox-scmi_agent.c Thanks, -Takahiro Akashi
[RFC PATCH 9/9] upl: Add initial documentation
Add some placeholder documentation to explain the basic concept. Once the spec is published, more can be added and this series applied. Signed-off-by: Simon Glass --- doc/usage/index.rst | 1 + doc/usage/upl.rst | 27 +++ 2 files changed, 28 insertions(+) create mode 100644 doc/usage/upl.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index ed896dfb3a0..78665fd5759 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -13,6 +13,7 @@ Use U-Boot partitions cmdline semihosting + upl Shell commands -- diff --git a/doc/usage/upl.rst b/doc/usage/upl.rst new file mode 100644 index 000..2ae4d4a1178 --- /dev/null +++ b/doc/usage/upl.rst @@ -0,0 +1,27 @@ +Universal Payload +~ + +Universal Payload (UPL) is an upcoming Industry Standard for firmware +components. UPL is designed to improve interoperability within the firmware +industry, allowing mixing and matching of projects with less friction and fewer +project-specific implementations. UPL is cross-platform, supporting ARM, x86 and +RISC-V initially. + +UPL is defined in termns of two firmware components: + +`Platform Init` + Perhaps initial setup of the hardware and jumps to the payload. + +`Payload` + Selects the OS to boot + +In practice UPL can be used to handle any number of handoffs through the +firmware startup process, with one program acting as platform init and another +acting as the payload. + +UPL provides a standard for three main pieces: + +- file format for the payload, which may comprise multiple images to load +- handoff format for the information the payload needs, such as serial port, + memory layout, etc. +- machine state and register settings at the point of handoff -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[RFC PATCH 8/9] sandbox_vpl: Enable Universal Payload
Use the sandbox_vpl build to test UPL since it supports a real devicetree
in SPL. The sandbox_spl build uses OF_PLATDATA.
Enable writing the UPL handoff in SPL and reading it in U-Boot proper.
Provide a test to check that this handoff works.
Note that the test uses the standard devicetree rather than the test one,
since it is a lot smaller and fits in the existing bloblist.
Signed-off-by: Simon Glass
---
configs/sandbox_vpl_defconfig | 4
test/py/tests/test_upl.py | 25 +
2 files changed, 29 insertions(+)
create mode 100644 test/py/tests/test_upl.py
diff --git a/configs/sandbox_vpl_defconfig b/configs/sandbox_vpl_defconfig
index 27354b8b5ed..598ec9620b0 100644
--- a/configs/sandbox_vpl_defconfig
+++ b/configs/sandbox_vpl_defconfig
@@ -27,6 +27,9 @@ CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_FIT_BEST_MATCH=y
CONFIG_SPL_LOAD_FIT=y
+CONFIG_UPL=y
+CONFIG_UPL_IN=y
+CONFIG_SPL_UPL_OUT=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
@@ -36,6 +39,7 @@ CONFIG_BOOTSTAGE_STASH_SIZE=0x4096
CONFIG_CONSOLE_RECORD=y
CONFIG_CONSOLE_RECORD_OUT_SIZE=0x1000
CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_BLOBLIST_SIZE=0x5000
CONFIG_SPL_NO_BSS_LIMIT=y
CONFIG_HANDOFF=y
CONFIG_SPL_BOARD_INIT=y
diff --git a/test/py/tests/test_upl.py b/test/py/tests/test_upl.py
new file mode 100644
index 000..0b24053e222
--- /dev/null
+++ b/test/py/tests/test_upl.py
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Google LLC
+#
+# Test addition of Universal Payload
+
+import os
+
+import pytest
+import u_boot_utils
+
+@pytest.mark.boardspec('sandbox_vpl')
+def test_upl_handoff(u_boot_console):
+cons = u_boot_console
+ram = os.path.join(cons.config.build_dir, 'ram.bin')
+fdt = os.path.join(cons.config.build_dir, 'u-boot.dtb')
+
+# Remove any existing RAM file, so we don't have old data present
+if os.path.exists(ram):
+os.remove(ram)
+flags = ['-m', ram, '-d', fdt]
+cons.restart_uboot_with_flags(flags, use_dtb=False)
+
+# Make sure that Universal Payload is detected in U-Boot proper
+output = cons.run_command('upl info')
+assert output == 'UPL state: active'
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[RFC PATCH 7/9] Plumb in universal payload to the init process
Read the UPL early in boot so that it is available. For now none of the
information is used.
Signed-off-by: Simon Glass
---
boot/Kconfig | 12 +++-
common/board_f.c | 22 ++
common/board_r.c | 2 ++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig
index 1cefa7d6873..b4b78a8b5b5 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -694,7 +694,9 @@ config UPL_READ
help
Provides support for decoding a UPL-format payload into a C structure
which can be used elsewhere in U-Boot. This is just the reading
- implementation, useful for trying it out.
+ implementation, useful for trying it out. See UPL_IN for how
+ to tell U-Boot to actually read it on startup and use it for memory
+ and device information, etc.
config UPL_WRITE
bool "upl - Support writing a Universal Payload handoff"
@@ -705,6 +707,14 @@ config UPL_WRITE
for how to tell U-Boot SPL to actually write it before jumping to
the next phase.
+config UPL_IN
+ bool "upl - Read the UPL handoff on startup"
+ select UPL_READ
+ help
+ Read an SPL handoff when U-Boot starts and use it to provide
+ devices, memory layout, etc. required by U-Boot. This allows U-Boot
+ to function as a payload in the meaning of the specification.
+
if SPL
config SPL_UPL
diff --git a/common/board_f.c b/common/board_f.c
index 76ae415487d..716025601c5 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -841,6 +842,26 @@ static int misc_init_f(void)
return event_notify_null(EVT_MISC_INIT_F);
}
+static int initf_upl(void)
+{
+ struct upl *upl;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_UPL_IN))
+ return 0;
+
+ upl = malloc(sizeof(struct upl));
+ if (upl)
+ ret = upl_read_handoff(upl, oftree_default());
+ if (ret) {
+ printf("UPL handoff: read failure (err=%dE)\n", ret);
+ return ret;
+ }
+ gd_set_upl(upl);
+
+ return 0;
+}
+
static const init_fnc_t init_sequence_f[] = {
setup_mon_len,
#ifdef CONFIG_OF_CONTROL
@@ -850,6 +871,7 @@ static const init_fnc_t init_sequence_f[] = {
trace_early_init,
#endif
initf_malloc,
+ initf_upl,
log_init,
initf_bootstage,/* uses its own timer, so does not need DM */
event_init,
diff --git a/common/board_r.c b/common/board_r.c
index 598155c7753..1c1f139430b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -549,6 +549,8 @@ static int dm_announce(void)
uclass_count);
if (CONFIG_IS_ENABLED(OF_REAL))
printf(", devicetree: %s", fdtdec_get_srcname());
+ if (CONFIG_IS_ENABLED(UPL))
+ printf(", universal payload active");
printf("\n");
if (IS_ENABLED(CONFIG_OF_HAS_PRIOR_STAGE) &&
(gd->fdt_src == FDTSRC_SEPARATE ||
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[RFC PATCH 6/9] spl: Plumb in the Universal Payload handoff
Specify the FIT and include information about each loaded image, as
required by the UPL handoff.
Write the UPL handoff into the bloblist before jumping to the next phase.
Signed-off-by: Simon Glass
---
common/spl/spl.c | 6 ++
common/spl/spl_fit.c | 22 ++
include/spl.h| 11 +++
3 files changed, 39 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0a9fea4f22d..1bfefaafd93 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -792,6 +792,12 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
printf(SPL_TPL_PROMPT
"SPL hand-off write failed (err=%d)\n", ret);
}
+ if (CONFIG_IS_ENABLED(UPL_OUT)) {
+ ret = spl_write_upl_handoff(&spl_image);
+ if (ret)
+ printf(SPL_TPL_PROMPT
+ "UPL hand-off write failed (err=%d)\n", ret);
+ }
if (CONFIG_IS_ENABLED(BLOBLIST)) {
ret = bloblist_finish();
if (ret)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 03ff9a5db9a..89b5f624340 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -621,6 +622,8 @@ static int spl_fit_load_fpga(struct spl_fit_info *ctx,
printf("%s: Cannot load the FPGA: %i\n", __func__, ret);
return ret;
}
+ upl_add_image(node, fpga_image.load_addr, fpga_image.size,
+ fdt_getprop(ctx->fit, node, FIT_DESC_PROP, NULL));
return spl_fit_upload_fpga(ctx, node, &fpga_image);
}
@@ -745,6 +748,9 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (ret)
return ret;
+ upl_add_image(node, spl_image->load_addr, spl_image->size,
+ fdt_getprop(ctx.fit, node, FIT_DESC_PROP, NULL));
+
/*
* For backward compatibility, we treat the first node that is
* as a U-Boot image, if no OS-type has been declared.
@@ -788,6 +794,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
__func__, index, ret);
return ret;
}
+ upl_add_image(node, image_info.load_addr, image_info.size,
+ fdt_getprop(ctx.fit, node, FIT_DESC_PROP, NULL));
if (spl_fit_image_is_fpga(ctx.fit, node))
spl_fit_upload_fpga(&ctx, node, &image_info);
@@ -824,6 +832,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
spl_image->entry_point = spl_image->load_addr;
spl_image->flags |= SPL_FIT_FOUND;
+ upl_set_fit_info(map_to_sysmem(ctx.fit), ctx.conf_node,
+spl_image->entry_point);
return 0;
}
@@ -868,6 +878,9 @@ int spl_load_fit_image(struct spl_image_info *spl_image,
if (ret < 0)
return ret;
+ upl_add_image(ret, fw_data, fw_len,
+ fdt_getprop((void *)header, ret, FIT_DESC_PROP, NULL));
+
spl_image->size = fw_len;
spl_image->entry_point = fw_data;
spl_image->load_addr = fw_data;
@@ -887,6 +900,9 @@ int spl_load_fit_image(struct spl_image_info *spl_image,
if (ret >= 0) {
spl_image->fdt_addr = (void *)dt_data;
+ upl_add_image(ret, dt_data, dt_len,
+ fdt_getprop((void *)header, ret, FIT_DESC_PROP, NULL));
+
if (spl_image->os == IH_OS_U_BOOT) {
/* HACK: U-Boot expects FDT at a specific address */
fdt_hack = spl_image->load_addr + spl_image->size;
@@ -916,7 +932,13 @@ int spl_load_fit_image(struct spl_image_info *spl_image,
&img_data, &img_len);
if (ret < 0)
return ret;
+ upl_add_image(ret, img_data, img_len,
+ fdt_getprop((void *)header, ret, FIT_DESC_PROP, NULL));
}
+ spl_image->flags |= SPL_FIT_FOUND;
+ upl_set_fit_info(map_to_sysmem(header), conf_noffset,
+spl_image->entry_point);
+
return 0;
}
diff --git a/include/spl.h b/include/spl.h
index e958ace2cc6..ed51e6c862d 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -250,6 +250,9 @@ struct spl_image_info {
uintptr_t entry_point;
#if CONFIG_IS_ENABLED(LOAD_FIT) || CONFIG_IS_ENABLED(LOAD_FIT_FULL)
void *fdt_addr;
+#endif
+#if CONFIG_IS_ENABLED(UPL)
+ int conf_node; /* FDT offset to selected configuration node */
#endif
u32 boot_device;
u32 offset;
@@ -921,4 +924,12 @@ void spl_save_restore_data(void);
int spl_load_fit_image(struct spl_image_info *spl_image,
const struct legacy_img_hdr *header);
+/**
+ * spl_write_upl_handoff() - Write a Universal Payload hand-off stru
[RFC PATCH 3/9] upl: Add basic tests
Add some unit tests to check that we can write a UPL handoff and read it
back.
Signed-off-by: Simon Glass
---
test/boot/Makefile | 2 +
test/boot/upl.c| 420 +
2 files changed, 422 insertions(+)
create mode 100644 test/boot/upl.c
diff --git a/test/boot/Makefile b/test/boot/Makefile
index 52947580ae6..9f97223eed3 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -12,3 +12,5 @@ ifdef CONFIG_OF_LIVE
obj-$(CONFIG_BOOTMETH_VBE_SIMPLE) += vbe_simple.o
endif
obj-$(CONFIG_BOOTMETH_VBE) += vbe_fixup.o
+
+obj-$(CONFIG_UPL) += upl.o
diff --git a/test/boot/upl.c b/test/boot/upl.c
new file mode 100644
index 000..8319a93e057
--- /dev/null
+++ b/test/boot/upl.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UPL handoff testing
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bootstd_common.h"
+
+void upl_get_test_data(struct upl *upl)
+{
+ memset(upl, '\0', sizeof(struct upl));
+ upl->addr_cells = 1;
+ upl->size_cells = 1;
+ upl->smbios = 0x123;
+ upl->acpi = 0x456;
+ upl->bootmode = BIT(UPLBM_DEFAULT) | BIT(UPLBM_S3);
+ upl->fit = 0x789;
+ upl->conf_offset = 0x234;
+ upl->addr_width = 46;
+ upl->acpi_nvs_size = 0x100;
+
+ upl->num_images = 2;
+ upl->image[0].load = 0x1;
+ upl->image[0].size = 0x2;
+ upl->image[0].offset = 0x3;
+ upl->image[0].description = "U-Boot";
+ upl->image[1].load = 0x4;
+ upl->image[1].size = 0x5;
+ upl->image[1].offset = 0x6;
+ upl->image[1].description = "ATF";
+
+ upl->num_mems = 2;
+ upl->mem[0].num_regions = 3;
+ upl->mem[0].region[0].base = 0x10;
+ upl->mem[0].region[0].size = 0x20;
+ upl->mem[0].region[1].base = 0x30;
+ upl->mem[0].region[1].size = 0x40;
+ upl->mem[0].region[2].base = 0x50;
+ upl->mem[0].region[2].size = 0x60;
+ upl->mem[1].num_regions = 1;
+ upl->mem[1].region[0].base = 0x70;
+ upl->mem[1].region[0].size = 0x80;
+ upl->mem[1].hotpluggable = true;
+
+ upl->num_memmaps = 5;
+ upl->memmap[0].num_regions = 5;
+ upl->memmap[0].name = "acpi";
+ upl->memmap[0].usage = BIT(UPLUS_ACPI_RECLAIM);
+ upl->memmap[0].region[0].base = 0x11;
+ upl->memmap[0].region[0].size = 0x12;
+ upl->memmap[0].region[1].base = 0x13;
+ upl->memmap[0].region[1].size = 0x14;
+ upl->memmap[0].region[2].base = 0x15;
+ upl->memmap[0].region[2].size = 0x16;
+ upl->memmap[0].region[3].base = 0x17;
+ upl->memmap[0].region[3].size = 0x18;
+ upl->memmap[0].region[4].base = 0x19;
+ upl->memmap[0].region[4].size = 0x1a;
+ upl->memmap[1].name = "u-boot";
+ upl->memmap[1].num_regions = 1;
+ upl->memmap[1].usage = BIT(UPLUS_BOOT_DATA);
+ upl->memmap[1].region[0].base = 0x21;
+ upl->memmap[1].region[0].size = 0x22;
+ upl->memmap[2].name = "efi";
+ upl->memmap[2].num_regions = 1;
+ upl->memmap[2].usage = BIT(UPLUS_RUNTIME_CODE);
+ upl->memmap[2].region[0].base = 0x23;
+ upl->memmap[2].region[0].size = 0x24;
+ upl->memmap[3].num_regions = 2;
+ upl->memmap[3].name = "empty";
+ upl->memmap[3].usage = 0;
+ upl->memmap[3].region[0].base = 0x25;
+ upl->memmap[3].region[0].size = 0x26;
+ upl->memmap[3].region[1].base = 0x27;
+ upl->memmap[3].region[1].size = 0x28;
+ upl->memmap[4].name = "acpi-things";
+ upl->memmap[4].num_regions = 1;
+ upl->memmap[4].usage = BIT(UPLUS_RUNTIME_CODE) | BIT(UPLUS_ACPI_NVS);
+ upl->memmap[4].region[0].base = 0x29;
+ upl->memmap[4].region[0].base = 0x2a;
+
+ upl->num_memres = 2;
+ upl->memres[0].num_regions = 1;
+ upl->memres[0].name = "mmio";
+ upl->memres[0].region[0].base = 0x2b;
+ upl->memres[0].region[0].size = 0x2c;
+ upl->memres[1].num_regions = 2;
+ upl->memres[1].name = "memory";
+ upl->memres[1].region[0].base = 0x2d;
+ upl->memres[1].region[0].size = 0x2e;
+ upl->memres[1].region[1].base = 0x2f;
+ upl->memres[1].region[1].size = 0x30;
+ upl->memres[1].no_map = true;
+
+ upl->serial.compatible = "ns16550a";
+ upl->serial.clock_frequency = 1843200;
+ upl->serial.current_speed = 115200;
+ upl->serial.reg.base = 0xf1de;
+ upl->serial.reg.size = 0x100;
+ upl->serial.reg_io_shift = 2;
+ upl->serial.reg_offset = 0x40;
+ upl->serial.reg_io_width = 1;
+ upl->serial.virtual_reg = 0x2000;
+ upl->serial.access_type = UPLSAT_MMIO;
+
+ upl->graphics.reg.base = 0xd000;
+ upl->graphics.reg.size = 0x1000;
+ upl->graphics.width = 1280;
+ upl->graphics.height = 1280;
+ upl->graphics.stride = upl->graphics.width * 4;
+ upl->graphic
[RFC PATCH 4/9] upl: Add a command
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass
---
boot/Kconfig | 1 +
cmd/Kconfig | 7 ++
cmd/Makefile | 1 +
cmd/upl.c | 99
doc/usage/cmd/upl.rst | 149 ++
doc/usage/index.rst | 1 +
include/asm-generic/global_data.h | 15 +++
test/boot/upl.c | 37
8 files changed, 310 insertions(+)
create mode 100644 cmd/upl.c
create mode 100644 doc/usage/cmd/upl.rst
diff --git a/boot/Kconfig b/boot/Kconfig
index d44684aaa04..b8b1032ca63 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -678,6 +678,7 @@ config BOOTMETH_SCRIPT
config UPL
bool "upl - Universal Payload Specification"
+ imply CMD_UPL
imply UPL_READ
imply UPL_WRITE
help
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3f14923b5ef..105d2647b88 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -351,6 +351,13 @@ config CMD_SEAMA
help
Support reading NAND Seattle Image (SEAMA) images.
+config CMD_UPL
+ bool "upl - Universal Payload Specification"
+ help
+ Provides commands to deal with UPL payloads and handoff information.
+ U-Boot supports generating and accepting handoff information. The
+ mkimage tool will eventually support creating payloads.
+
config CMD_VBE
bool "vbe - Verified Boot for Embedded"
depends on BOOTMETH_VBE
diff --git a/cmd/Makefile b/cmd/Makefile
index 9bebf321c39..877eb0be9ef 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_CMD_UBIFS) += ubifs.o
obj-$(CONFIG_CMD_UNIVERSE) += universe.o
obj-$(CONFIG_CMD_UNLZ4) += unlz4.o
obj-$(CONFIG_CMD_UNZIP) += unzip.o
+obj-$(CONFIG_CMD_UPL) += upl.o
obj-$(CONFIG_CMD_VIRTIO) += virtio.o
obj-$(CONFIG_CMD_WDT) += wdt.o
obj-$(CONFIG_CMD_LZMADEC) += lzmadec.o
diff --git a/cmd/upl.c b/cmd/upl.c
new file mode 100644
index 000..d84c2bef354
--- /dev/null
+++ b/cmd/upl.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Commands for UPL handoff generation
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int do_upl_info(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ printf("UPL state: %sactive\n", gd_upl() ? "" : "in");
+
+ return 0;
+}
+
+static int do_upl_write(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct upl s_upl, *upl = &s_upl;
+ struct abuf buf;
+ oftree tree;
+ ulong addr;
+ int ret;
+
+ upl_get_test_data(upl);
+
+ log_debug("Writing UPL\n");
+ ret = upl_create_handoff_tree(upl, &tree);
+ if (ret) {
+ log_err("Failed to write (err=%dE)\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ log_debug("Flattening\n");
+ ret = oftree_to_fdt(tree, &buf);
+ if (ret) {
+ log_err("Failed to write (err=%dE)\n", ret);
+ return CMD_RET_FAILURE;
+ }
+ addr = map_to_sysmem(abuf_data(&buf));
+ printf("UPL handoff written to %lx size %lx\n", addr, abuf_size(&buf));
+ if (env_set_hex("upladdr", addr) ||
+ env_set_hex("uplsize", abuf_size(&buf))) {
+ printf("Cannot set env var\n");
+ return CMD_RET_FAILURE;
+ }
+
+ log_debug("done\n");
+
+ return 0;
+}
+
+static int do_upl_read(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct upl s_upl, *upl = &s_upl;
+ oftree tree;
+ ulong addr;
+ int ret;
+
+ if (argc < 1)
+ return CMD_RET_USAGE;
+ addr = hextoul(argv[1], NULL);
+
+ printf("Reading UPL at %lx\n", addr);
+ tree = oftree_from_fdt(map_sysmem(addr, 0));
+ ret = upl_read_handoff(upl, tree);
+ if (ret) {
+ log_err("Failed to read (err=%dE)\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_SYS_LONGHELP
+static char upl_help_text[] =
+ "info - Check UPL status\n"
+ "upl read- Read handoff information\n"
+ "upl write - Write handoff information";
+#endif
+
+U_BOOT_CMD_WITH_SUBCMDS(upl, "Universal Payload support", upl_help_text,
+ U_BOOT_SUBCMD_MKENT(info, 1, 1, do_upl_info),
+ U_BOOT_SUBCMD_MKENT(read, 2, 1, do_upl_read),
+ U_BOOT_SUBCMD_MKENT(write, 1, 1, do_upl_write));
diff --git a/doc/usage/cmd/upl.rst b/doc/usage/cmd/upl.rst
new file mode 100644
index 000..8b41220dff6
--- /dev/null
+++ b/doc/usage/cmd/upl.rst
@@ -0,0 +1,149 @@
+.. SP
[RFC PATCH 5/9] upl: Add support for Universal Payload in SPL
Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.
Signed-off-by: Simon Glass
---
boot/Kconfig | 32 +
common/spl/Makefile | 2 +
common/spl/spl_upl.c | 153 +++
3 files changed, 187 insertions(+)
create mode 100644 common/spl/spl_upl.c
diff --git a/boot/Kconfig b/boot/Kconfig
index b8b1032ca63..1cefa7d6873 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -681,6 +681,7 @@ config UPL
imply CMD_UPL
imply UPL_READ
imply UPL_WRITE
+ imply SPL_UPL if SPL
help
Provides support for UPL payloads and handoff information. U-Boot
supports generating and accepting handoff information. The mkimage
@@ -697,11 +698,42 @@ config UPL_READ
config UPL_WRITE
bool "upl - Support writing a Universal Payload handoff"
+ help
+ Provides support for encoding a UPL-format payload from a C structure
+ so it can be passed to another program. This is just the writing
+ implementation, useful for trying it out. See SPL_UPL_OUT
+ for how to tell U-Boot SPL to actually write it before jumping to
+ the next phase.
+
+if SPL
+
+config SPL_UPL
+ bool "Write a UPL handoff in SPL"
+ imply SPL_UPL_OUT
+ help
+ This tells SPL to write a UPL handoff and pass it to the next phase
+ (e.g. to U-Boot or another program which SPL loads and runs). THis
+ provides information to help that program run correctly and
+ efficiently on the machine.
+
+config SPL_UPL_WRITE
+ bool # upl - Support writing a Universal Payload handoff in SPL
+ select SPL_BLOBLIST
help
Provides support for encoding a UPL-format payload from a C structure
so it can be passed to another program. This is just the writing
implementation, useful for trying it out.
+config SPL_UPL_OUT
+ bool "upl - Support writing a Universal Payload handoff in SPL"
+ select SPL_UPL_WRITE
+ help
+ Provides support for encoding a UPL-format payload and passing it to
+ the next firmware phase. This allows U-Boot SPL to function as
+ Platform Init in the meaning of the specification.
+
+endif # SPL
+
endif # UPL
endif # BOOTSTD
diff --git a/common/spl/Makefile b/common/spl/Makefile
index bad2bbf6cf1..8e34933230c 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -36,3 +36,5 @@ obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
obj-$(CONFIG_$(SPL_TPL_)RAM_SUPPORT) += spl_ram.o
obj-$(CONFIG_$(SPL_TPL_)USB_SDP_SUPPORT) += spl_sdp.o
endif
+
+obj-$(CONFIG_$(SPL_TPL_)UPL) += spl_upl.o
diff --git a/common/spl/spl_upl.c b/common/spl/spl_upl.c
new file mode 100644
index 000..1b284974736
--- /dev/null
+++ b/common/spl/spl_upl.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UPL handoff parsing
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_DEBUG
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct upl s_upl;
+
+void upl_set_fit_info(ulong fit, int conf_offset, ulong entry_addr)
+{
+ struct upl *upl = &s_upl;
+
+ upl->fit = fit;
+ upl->conf_offset = conf_offset;
+}
+
+int upl_add_image(int node, ulong load_addr, ulong size, const char *desc)
+{
+ struct upl *upl = &s_upl;
+ struct upl_image *img;
+
+ if (upl->num_images == UPL_MAX_IMAGES)
+ return log_msg_ret("img", -E2BIG);
+ img = &upl->image[upl->num_images++];
+ img->load = load_addr;
+ img->size = size;
+ img->offset = node;
+ img->description = desc;
+
+ return 0;
+}
+
+static int write_serial(struct upl_serial *ser)
+{
+ struct udevice *dev = gd->cur_serial_dev;
+ struct serial_device_info info;
+ int ret;
+
+ if (!dev)
+ return log_msg_ret("ser", -ENOENT);
+ ret = serial_getinfo(dev, &info);
+ if (ret)
+ return log_msg_ret("inf", ret);
+
+ ser->compatible = ofnode_read_string(dev_ofnode(dev), "compatible");
+ ser->clock_frequency = info.clock;
+ ser->current_speed = gd->baudrate;
+ ser->reg.base = info.addr;
+ ser->reg.size = info.size;
+ ser->reg_io_shift = info.reg_shift;
+ ser->reg_offset = info.reg_offset;
+ ser->reg_io_width = info.reg_width;
+ ser->virtual_reg = 0;
+ ser->access_type = info.addr_space;
+
+ return 0;
+}
+
+static int write_graphics(struct upl_graphics *gra)
+{
+ struct video_uc_plat *plat;
+ struct video_priv *priv;
+ struct udevice *dev;
+
+ uclass_find_first_device(UCLASS_VIDEO, &dev);
+ if (!dev || !device_active(dev))
+ return -ENOENT;
+
+ plat = dev
[RFC PATCH 2/9] upl: Add support for writing a upl handoff
Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for writing the handoff information from
a structure.
Signed-off-by: Simon Glass
---
boot/Kconfig | 8 +
boot/Makefile| 1 +
boot/upl_write.c | 623 +++
3 files changed, 632 insertions(+)
create mode 100644 boot/upl_write.c
diff --git a/boot/Kconfig b/boot/Kconfig
index e4625cc5fcb..d44684aaa04 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -679,6 +679,7 @@ config BOOTMETH_SCRIPT
config UPL
bool "upl - Universal Payload Specification"
imply UPL_READ
+ imply UPL_WRITE
help
Provides support for UPL payloads and handoff information. U-Boot
supports generating and accepting handoff information. The mkimage
@@ -693,6 +694,13 @@ config UPL_READ
which can be used elsewhere in U-Boot. This is just the reading
implementation, useful for trying it out.
+config UPL_WRITE
+ bool "upl - Support writing a Universal Payload handoff"
+ help
+ Provides support for encoding a UPL-format payload from a C structure
+ so it can be passed to another program. This is just the writing
+ implementation, useful for trying it out.
+
endif # UPL
endif # BOOTSTD
diff --git a/boot/Makefile b/boot/Makefile
index e50f3f91430..45f06b43c30 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -39,6 +39,7 @@ endif
obj-$(CONFIG_$(SPL_TPL_)UPL) += upl_common.o
obj-$(CONFIG_$(SPL_TPL_)UPL_READ) += upl_read.o
+obj-$(CONFIG_$(SPL_TPL_)UPL_WRITE) += upl_write.o
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
diff --git a/boot/upl_write.c b/boot/upl_write.c
new file mode 100644
index 000..74219da6f41
--- /dev/null
+++ b/boot/upl_write.c
@@ -0,0 +1,623 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UPL handoff generation
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include "upl_common.h"
+
+/**
+ * write_addr() - Write an address
+ *
+ * Writes an address in the correct format, either 32- or 64-bit
+ *
+ * @upl: UPL state
+ * @node: Node to write to
+ * @prop: Property name to write
+ * @addr: Address to write
+ * Return: 0 if OK, -ve on error
+ */
+static int write_addr(const struct upl *upl, ofnode node, const char *prop,
+ ulong addr)
+{
+ int ret;
+
+ if (upl->addr_cells == 1)
+ ret = ofnode_write_u32(node, prop, addr);
+ else
+ ret = ofnode_write_u64(node, prop, addr);
+
+ return ret;
+}
+
+/**
+ * write_size() - Write a size
+ *
+ * Writes a size in the correct format, either 32- or 64-bit
+ *
+ * @upl: UPL state
+ * @node: Node to write to
+ * @prop: Property name to write
+ * @size: Size to write
+ * Return: 0 if OK, -ve on error
+ */
+static int write_size(const struct upl *upl, ofnode node, const char *prop,
+ ulong size)
+{
+ int ret;
+
+ if (upl->size_cells == 1)
+ ret = ofnode_write_u32(node, prop, size);
+ else
+ ret = ofnode_write_u64(node, prop, size);
+
+ return ret;
+}
+
+/**
+ * ofnode_write_bitmask() - Write a bit mask as a string list
+ *
+ * @node: Node to write to
+ * @prop: Property name to write
+ * @names: Array of names for each bit
+ * @count: Number of array entries
+ * @value: Bit-mask value to write
+ * Return: 0 if OK, -EINVAL if a bit number is not defined, -ENOSPC if the
+ * string is too long for the (internal) buffer
+ */
+static int ofnode_write_bitmask(ofnode node, const char *prop,
+ const char *const names[], uint count,
+ uint value)
+{
+ char buf[128];
+ char *ptr, *end = buf + sizeof(buf);
+ uint bit;
+ int ret;
+
+ ptr = buf;
+ for (bit = 0; bit < count; bit++) {
+ if (value & BIT(bit)) {
+ const char *str = names[bit];
+ uint len;
+
+ if (!str) {
+ log_debug("Unnamed bit number %d\n", bit);
+ return log_msg_ret("bit", -EINVAL);
+ }
+ len = strlen(str) + 1;
+ if (ptr + len > end) {
+ log_debug("String array too long\n");
+ return log_msg_ret("bit", -ENOSPC);
+ }
+
+ memcpy(ptr, str, len);
+ ptr += len;
+ }
+ }
+
+ ret = ofnode_write_prop(node, prop, buf, ptr - buf, true);
+ if (ret)
+ return log_msg_ret("wri", ret);
+
+ return 0;
+}
+
+/**
+ * ofnode_write_value() - Write an int as a string value using a lookup
+ *
+ * @node: Node to writ
[RFC PATCH 1/9] upl: Add support for reading a upl handoff
Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for reading the handoff information into
a structure.
Signed-off-by: Simon Glass
---
boot/Kconfig | 21 +-
boot/Makefile | 3 +
boot/upl_common.c | 51
boot/upl_common.h | 24 ++
boot/upl_read.c | 607 ++
configs/sandbox_defconfig | 6 +-
include/upl.h | 361 +++
7 files changed, 1069 insertions(+), 4 deletions(-)
create mode 100644 boot/upl_common.c
create mode 100644 boot/upl_common.h
create mode 100644 boot/upl_read.c
create mode 100644 include/upl.h
diff --git a/boot/Kconfig b/boot/Kconfig
index 86ccfd78031..e4625cc5fcb 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -676,7 +676,26 @@ config BOOTMETH_SCRIPT
This provides a way to try out standard boot on an existing boot flow.
It is not enabled by default to save space.
-endif
+config UPL
+ bool "upl - Universal Payload Specification"
+ imply UPL_READ
+ help
+ Provides support for UPL payloads and handoff information. U-Boot
+ supports generating and accepting handoff information. The mkimage
+ tool will eventually support creating payloads.
+
+if UPL
+
+config UPL_READ
+ bool "upl - Support reading a Universal Payload handoff"
+ help
+ Provides support for decoding a UPL-format payload into a C structure
+ which can be used elsewhere in U-Boot. This is just the reading
+ implementation, useful for trying it out.
+
+endif # UPL
+
+endif # BOOTSTD
config LEGACY_IMAGE_FORMAT
bool "Enable support for the legacy image format"
diff --git a/boot/Makefile b/boot/Makefile
index 10f01572237..e50f3f91430 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -37,6 +37,9 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o
obj-$(CONFIG_$(SPL_TPL_)CEDIT) += cedit.o
endif
+obj-$(CONFIG_$(SPL_TPL_)UPL) += upl_common.o
+obj-$(CONFIG_$(SPL_TPL_)UPL_READ) += upl_read.o
+
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
diff --git a/boot/upl_common.c b/boot/upl_common.c
new file mode 100644
index 000..a541d14b387
--- /dev/null
+++ b/boot/upl_common.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UPL handoff command functions
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+
+/* Names of bootmodes */
+const char *const bootmode_names[UPLBM_COUNT] = {
+ [UPLBM_FULL]= "full",
+ [UPLBM_MINIMAL] = "minimal",
+ [UPLBM_FAST]= "fast",
+ [UPLBM_DIAG]= "diag",
+ [UPLBM_DEFAULT] = "default",
+ [UPLBM_S2] = "s2",
+ [UPLBM_S3] = "s3",
+ [UPLBM_S4] = "s4",
+ [UPLBM_S5] = "s5",
+ [UPLBM_FACTORY] = "factory",
+ [UPLBM_FLASH] = "flash",
+ [UPLBM_RECOVERY] = "recovery",
+};
+
+/* Names of memory usages */
+const char *const usage_names[UPLUS_COUNT] = {
+ [UPLUS_ACPI_RECLAIM]= "acpi-reclaim",
+ [UPLUS_ACPI_NVS]= "acpi-nvs",
+ [UPLUS_BOOT_CODE] = "boot-code",
+ [UPLUS_BOOT_DATA] = "boot-data",
+ [UPLUS_RUNTIME_CODE]= "runtime-code",
+ [UPLUS_RUNTIME_DATA]= "runtime-data",
+};
+
+/* Names of access types */
+const char *const access_types[UPLUS_COUNT] = {
+ [UPLAT_MMIO]= "mmio",
+ [UPLAT_IO] = "io",
+};
+
+/* Names of graphics formats */
+const char *const graphics_formats[UPLUS_COUNT] = {
+ [UPLGF_ARGB32] = "a8r8g8b8",
+ [UPLGF_ABGR32] = "a8b8g8r8",
+ [UPLGF_ABGR64] = "a16b16g16r16",
+};
diff --git a/boot/upl_common.h b/boot/upl_common.h
new file mode 100644
index 000..0f134c0393f
--- /dev/null
+++ b/boot/upl_common.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * UPL handoff command functions
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#ifndef __UPL_COMMON_H
+#define __UPL_COMMON_H
+
+/* Names of bootmodes */
+extern const char *const bootmode_names[UPLBM_COUNT];
+
+/* Names of memory usages */
+extern const char *const usage_names[UPLUS_COUNT];
+
+/* Names of access types */
+extern const char *const access_types[UPLUS_COUNT];
+
+/* Names of graphics formats */
+extern const char *const graphics_formats[UPLUS_COUNT];
+
+#endif /* __UPL_COMMON_H */
diff --git a/boot/upl_read.c b/boot/upl_read.c
new file mode 100644
index 000..4d7c9602fcf
--- /dev/null
+++ b/boot/upl_read.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UPL handoff parsing
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include "upl_common.h"
+
+/**
+ * read_addr() - Read
[RFC PATCH 0/9] Universal Payload initial series
Universal Payload (UPL) is an upcoming Industry Standard for firmware components. UPL is designed to improve interoperability within the firmware industry, allowing mixing and matching of projects with less friction and fewer project-specific implementations. UPL is cross-platform, supporting ARM, x86 and RISC-V initially. This series provides some initial support for this, for comment only. Simon Glass (9): upl: Add support for reading a upl handoff upl: Add support for writing a upl handoff upl: Add basic tests upl: Add a command upl: Add support for Universal Payload in SPL spl: Plumb in the Universal Payload handoff Plumb in universal payload to the init process sandbox_vpl: Enable Universal Payload upl: Add initial documentation boot/Kconfig | 72 +++- boot/Makefile | 4 + boot/upl_common.c | 51 +++ boot/upl_common.h | 24 ++ boot/upl_read.c | 607 + boot/upl_write.c | 623 ++ cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/upl.c | 99 + common/board_f.c | 22 ++ common/board_r.c | 2 + common/spl/Makefile | 2 + common/spl/spl.c | 6 + common/spl/spl_fit.c | 22 ++ common/spl/spl_upl.c | 153 configs/sandbox_defconfig | 6 +- configs/sandbox_vpl_defconfig | 4 + doc/usage/cmd/upl.rst | 149 +++ doc/usage/index.rst | 2 + doc/usage/upl.rst | 27 ++ include/asm-generic/global_data.h | 15 + include/spl.h | 11 + include/upl.h | 361 + test/boot/Makefile| 2 + test/boot/upl.c | 457 ++ test/py/tests/test_upl.py | 25 ++ 26 files changed, 2750 insertions(+), 4 deletions(-) create mode 100644 boot/upl_common.c create mode 100644 boot/upl_common.h create mode 100644 boot/upl_read.c create mode 100644 boot/upl_write.c create mode 100644 cmd/upl.c create mode 100644 common/spl/spl_upl.c create mode 100644 doc/usage/cmd/upl.rst create mode 100644 doc/usage/upl.rst create mode 100644 include/upl.h create mode 100644 test/boot/upl.c create mode 100644 test/py/tests/test_upl.py -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[RFX PATCH 0/9] Universal Payload initial series
Universal Payload (UPL) is an upcoming Industry Standard for firmware components. UPL is designed to improve interoperability within the firmware industry, allowing mixing and matching of projects with less friction and fewer project-specific implementations. UPL is cross-platform, supporting ARM, x86 and RISC-V initially. This series provides some initial support for this, for comment only. Simon Glass (9): upl: Add support for reading a upl handoff upl: Add support for writing a upl handoff upl: Add basic tests upl: Add a command upl: Add support for Universal Payload in SPL spl: Plumb in the Universal Payload handoff Plumb in universal payload to the init process sandbox_vpl: Enable Universal Payload upl: Add initial documentation boot/Kconfig | 72 +++- boot/Makefile | 4 + boot/upl_common.c | 51 +++ boot/upl_common.h | 24 ++ boot/upl_read.c | 607 + boot/upl_write.c | 623 ++ cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/upl.c | 99 + common/board_f.c | 22 ++ common/board_r.c | 2 + common/spl/Makefile | 2 + common/spl/spl.c | 6 + common/spl/spl_fit.c | 22 ++ common/spl/spl_upl.c | 153 configs/sandbox_defconfig | 6 +- configs/sandbox_vpl_defconfig | 4 + doc/usage/cmd/upl.rst | 149 +++ doc/usage/index.rst | 2 + doc/usage/upl.rst | 27 ++ include/asm-generic/global_data.h | 15 + include/spl.h | 11 + include/upl.h | 361 + test/boot/Makefile| 2 + test/boot/upl.c | 457 ++ test/py/tests/test_upl.py | 25 ++ 26 files changed, 2750 insertions(+), 4 deletions(-) create mode 100644 boot/upl_common.c create mode 100644 boot/upl_common.h create mode 100644 boot/upl_read.c create mode 100644 boot/upl_write.c create mode 100644 cmd/upl.c create mode 100644 common/spl/spl_upl.c create mode 100644 doc/usage/cmd/upl.rst create mode 100644 doc/usage/upl.rst create mode 100644 include/upl.h create mode 100644 test/boot/upl.c create mode 100644 test/py/tests/test_upl.py -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v5 3/4] schemas: Add some common reserved-memory usages
The Devicetree specification skips over handling of a logical view of
the memory map, pointing users to the UEFI specification.
It is common to split firmware into 'Platform Init', which does the
initial hardware setup and a "Payload" which selects the OS to be booted.
Thus an handover interface is required between these two pieces.
Where UEFI boot-time services are not available, but UEFI firmware is
present on either side of this interface, information about memory usage
and attributes must be presented to the "Payload" in some form.
This aims to provide an small schema addition for this mapping.
For now, no attempt is made to create an exhaustive binding, so there are
some example types listed. More can be added later.
The compatible string is not included, since the node name is enough to
indicate the purpose of a node, as per the existing reserved-memory
schema.
This binding does not include a binding for the memory 'attribute'
property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
to have that as well, but perhaps not as a bit mask.
Signed-off-by: Simon Glass
---
Changes in v5:
- Drop the memory-map node (should have done that in v4)
- Tidy up schema a bit
Changes in v4:
- Make use of the reserved-memory node instead of creating a new one
Changes in v3:
- Reword commit message again
- cc a lot more people, from the FFI patch
- Split out the attributes into the /memory nodes
Changes in v2:
- Reword commit message
.../reserved-memory/common-reserved.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml
diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml
b/dtschema/schemas/reserved-memory/common-reserved.yaml
new file mode 100644
index 000..d1b466b
--- /dev/null
+++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common memory reservations
+
+description: |
+ Specifies that the reserved memory region can be used for the purpose
+ indicated by its node name.
+
+ Clients may reuse this reserved memory if they understand what it is for.
+
+maintainers:
+ - Simon Glass
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ $nodename:
+enum:
+ - acpi-reclaim
+ - acpi-nvs
+ - boot-code
+ - boot-data
+ - runtime-code
+ - runtime-data
+
+ reg:
+description: region of memory that is reserved for the purpose indicated
+ by the node name.
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <1>;
+#size-cells = <1>;
+
+boot-code@1234 {
+reg = <0x1234 0x0080>;
+};
+
+boot-data@4321 {
+reg = <0x4321 0x0080>;
+};
+};
--
2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v5 2/4] Bring in some other reserved-memory files
Add schema yaml files from v6.5 which are not vendor-specific, nor
Linux-specific.
Signed-off-by: Simon Glass
---
Changes in v5:
- Trim back to just a subset of mostly generic schemas
Changes in v4:
- New patch
.../schemas/reserved-memory/framebuffer.yaml | 52 ++
.../reserved-memory/memory-region.yaml| 40
.../reserved-memory/shared-dma-pool.yaml | 97 +++
3 files changed, 189 insertions(+)
create mode 100644 dtschema/schemas/reserved-memory/framebuffer.yaml
create mode 100644 dtschema/schemas/reserved-memory/memory-region.yaml
create mode 100644 dtschema/schemas/reserved-memory/shared-dma-pool.yaml
diff --git a/dtschema/schemas/reserved-memory/framebuffer.yaml
b/dtschema/schemas/reserved-memory/framebuffer.yaml
new file mode 100644
index 000..851ec24
--- /dev/null
+++ b/dtschema/schemas/reserved-memory/framebuffer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory framebuffer node
+
+maintainers:
+ - devicetree-s...@vger.kernel.org
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+const: framebuffer
+description: >
+ This indicates a region of memory meant to be used as a framebuffer for
+ a set of display devices. It can be used by an operating system to keep
+ the framebuffer from being overwritten and use it as the backing memory
+ for a display device (such as simple-framebuffer).
+
+unevaluatedProperties: false
+
+examples:
+ - |
+/ {
+compatible = "foo";
+model = "foo";
+#address-cells = <1>;
+#size-cells = <1>;
+
+chosen {
+framebuffer {
+compatible = "simple-framebuffer";
+memory-region = <&fb>;
+};
+};
+
+reserved-memory {
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+fb: framebuffer@8000 {
+compatible = "framebuffer";
+reg = <0x8000 0x007e9000>;
+};
+};
+};
+...
diff --git a/dtschema/schemas/reserved-memory/memory-region.yaml
b/dtschema/schemas/reserved-memory/memory-region.yaml
new file mode 100644
index 000..592f180
--- /dev/null
+++ b/dtschema/schemas/reserved-memory/memory-region.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reserved Memory Region
+
+maintainers:
+ - devicetree-s...@vger.kernel.org
+
+description: |
+ Regions in the /reserved-memory node may be referenced by other device
+ nodes by adding a memory-region property to the device node.
+
+select: true
+
+properties:
+ memory-region:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: >
+ Phandle to a /reserved-memory child node assigned to the device.
+
+ memory-region-names:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: >
+ A list of names, one for each corresponding entry in the
+ memory-region property
+
+additionalProperties: true
+
+examples:
+ - |
+fb0: video@1230 {
+/* ... */
+reg = <0x1230 0x1000>;
+memory-region = <&display_reserved>;
+};
+
+...
diff --git a/dtschema/schemas/reserved-memory/shared-dma-pool.yaml
b/dtschema/schemas/reserved-memory/shared-dma-pool.yaml
new file mode 100644
index 000..457de09
--- /dev/null
+++ b/dtschema/schemas/reserved-memory/shared-dma-pool.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/shared-dma-pool.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory DMA pool
+
+maintainers:
+ - devicetree-s...@vger.kernel.org
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+oneOf:
+ - const: shared-dma-pool
+description: >
+ This indicates a region of memory meant to be used as a shared
+ pool of DMA buffers for a set of devices. It can be used by an
+ operating system to instantiate the necessary pool management
+ subsystem if necessary.
+
+ - const: restricted-dma-pool
+description: >
+ This indicates a region of memory meant to be used as a pool
+ of restricted DMA buffers for a set of devices. The memory
+ region would be the only region accessible to those devices.
+ When using this, the no-map and reusable properties must not
+ be set, so the operating system can create a virtual mapping
+ that will be used for synchronization. The main purpose for
+ restricted DMA is to m
[PATCH v5 4/4] memory: Add ECC properties
Some memories provide ECC detection and/or correction. For software which wants to check memory, it is helpful to see which regions provide this feature. Add this as a property of the /memory nodes, since it presumably follows the hardware-level memory system. Signed-off-by: Simon Glass --- Changes in v5: - Redo to make this property specific to ECC - Provide properties both for detection and correction Changes in v3: - Add new patch to update the /memory nodes dtschema/schemas/memory.yaml | 30 ++ 1 file changed, 30 insertions(+) diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml index 1d74410..944aa9f 100644 --- a/dtschema/schemas/memory.yaml +++ b/dtschema/schemas/memory.yaml @@ -34,7 +34,37 @@ patternProperties: description: For the purpose of identification, each NUMA node is associated with a unique token known as a node id. + ecc-detection: +$ref: /schemas/types.yaml#/definitions/string +enum: + - none + - single-bit + - multi-bit +description: | + If present, this inidcates the type of memory errors which can be + detected and reported by the Error-Correction Code (ECC) memory + subsystem: +none - No error detection is possible +single-bit - Detects and reports single-bit ECC errors +multi-bit - Detects and reports multiple-bit ECC errors + + If not present, this is equivalent to 'none'. + ecc-correction: +$ref: /schemas/types.yaml#/definitions/string +enum: + - none + - single-bit + - multi-bit +description: | + If present, this inidcates the type of memory errors which can be + corrected by the Error-Correction Code (ECC) memory subsystem: + +none - No error correction is possible +single-bit - Corrects single-bit ECC errors +multi-bit - Corrects multiple-bit ECC errors + + If not present, this is equivalent to 'none'. required: - device_type -- 2.42.0.rc2.253.gd59a3bf2b4-goog
[PATCH v5 1/4] Add reserved-memory
Bring in this file from Linux v6.5 Signed-off-by: Simon Glass --- (no changes since v4) Changes in v4: - New patch .../reserved-memory/reserved-memory.yaml | 181 ++ 1 file changed, 181 insertions(+) create mode 100644 dtschema/schemas/reserved-memory/reserved-memory.yaml diff --git a/dtschema/schemas/reserved-memory/reserved-memory.yaml b/dtschema/schemas/reserved-memory/reserved-memory.yaml new file mode 100644 index 000..c680e39 --- /dev/null +++ b/dtschema/schemas/reserved-memory/reserved-memory.yaml @@ -0,0 +1,181 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /reserved-memory Child Node Common + +maintainers: + - devicetree-s...@vger.kernel.org + +description: > + Reserved memory is specified as a node under the /reserved-memory node. The + operating system shall exclude reserved memory from normal usage one can + create child nodes describing particular reserved (excluded from normal use) + memory regions. Such memory regions are usually designed for the special + usage by various device drivers. + + Each child of the reserved-memory node specifies one or more regions + of reserved memory. Each child node may either use a 'reg' property to + specify a specific range of reserved memory, or a 'size' property with + optional constraints to request a dynamically allocated block of + memory. + + Following the generic-names recommended practice, node names should + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). + Unit address (@) should be appended to the name if the node + is a static allocation. + +properties: + reg: true + + size: +oneOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - $ref: /schemas/types.yaml#/definitions/uint64 +description: > + Length based on parent's \#size-cells. Size in bytes of memory to + reserve. + + alignment: +oneOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - $ref: /schemas/types.yaml#/definitions/uint64 +description: > + Length based on parent's \#size-cells. Address boundary for + alignment of allocation. + + alloc-ranges: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: > + Address and Length pairs. Specifies regions of memory that are + acceptable to allocate from. + + iommu-addresses: +$ref: /schemas/types.yaml#/definitions/phandle-array +description: > + A list of phandle and specifier pairs that describe static IO virtual + address space mappings and carveouts associated with a given reserved + memory region. The phandle in the first cell refers to the device for + which the mapping or carveout is to be created. + + The specifier consists of an address/size pair and denotes the IO + virtual address range of the region for the given device. The exact + format depends on the values of the "#address-cells" and "#size-cells" + properties of the device referenced via the phandle. + + When used in combination with a "reg" property, an IOVA mapping is to + be established for this memory region. One example where this can be + useful is to create an identity mapping for physical memory that the + firmware has configured some hardware to access (such as a bootsplash + framebuffer). + + If no "reg" property is specified, the "iommu-addresses" property + defines carveout regions in the IOVA space for the given device. This + can be useful if a certain memory region should not be mapped through + the IOMMU. + + no-map: +type: boolean +description: > + Indicates the operating system must not create a virtual mapping + of the region as part of its standard mapping of system memory, + nor permit speculative access to it under any circumstances other + than under the control of the device driver using the region. + + reusable: +type: boolean +description: > + The operating system can use the memory in this region with the + limitation that the device driver(s) owning the region need to be + able to reclaim it back. Typically that means that the operating + system can use that region to store volatile or cached data that + can be otherwise regenerated or migrated elsewhere. + +allOf: + - if: + required: +- no-map + +then: + not: +required: + - reusable + + - if: + required: +- reusable + +then: + not: +required: + - no-map + +oneOf: + - oneOf: + - required: + - reg + + - required: + - size + + - oneOf: + # IOMMU reservations + - required: + - iommu-addresses + + # IOMMU mappings + - required: + - reg + - iommu-addresses + +additional
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
On Wed, Aug 30, 2023 at 11:29:34PM +0200, Pali Rohár wrote: > There were no answers. > > On Wednesday 30 August 2023 17:26:20 Tom Rini wrote: > > I'm trimming the CC list. All of those points you list were addressed > > and answered in your last long running argument. You need to decide what > > is best for you moving forward and I would ask that it not involve > > complaining that you're being asked to review code that you're a listed > > maintainer of. > > > > On Wed, Aug 30, 2023 at 11:13:16PM +0200, Pali Rohár wrote: > > > Seems that you completely miss the point of the argument, then the only > > > option for such people is to repeat them. Or have I repeat you again > > > that you have not answered the first question, why you are asking for > > > review from somebody who you are ignoring and not taking into account? > > > You do not want to answer this question, right? So you rather change a > > > topic and talking about something totally different. > > > > > > On Wednesday 30 August 2023 17:08:42 Tom Rini wrote: > > > > I don't think it's worth re-hashing the same arguments over and over. > > > > There is no "my persons", there is the public community. If you no > > > > longer wish to participate, I can remove you from the maintainers > > > > entries you're listed in. But please stop with the long arguments > > > > unrelated to the patches at hand when there's a dozen people and other > > > > lists on CC. > > > > > > > > On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > > > > > So lets recap what you and your persons have done in last 6 months: > > > > > > > > > > * Ignored my changes > > > > > * Ignored my reviews > > > > > * Ignored my reminders Not ignored, changes requested and refused. Compromises refused. Apologies from others who had said they would pick up the platform and push it, but did not have time ignored. > > > > > * Ignored my regression reports Not ignored, debugged, problems with your platform implementation reported and questions asked, patches provided to help you debug the problem on the single place that seems to show a problem which no one else can reproduce ignored. -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/32] spl: Avoid an #ifdef when printing gd->malloc_ptr
On Wed, Aug 30, 2023 at 12:04:40PM -0600, Simon Glass wrote:
> Use an accessor in the header file to avoid this.
>
> Signed-off-by: Simon Glass
> ---
>
> common/spl/spl.c | 9 +
> include/asm-generic/global_data.h | 7 +++
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index f0a90c280da..f5cef81000c 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -876,10 +876,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> } else {
> debug("Unsupported OS image.. Jumping nevertheless..\n");
> }
> -#if CONFIG_VAL(SYS_MALLOC_F_LEN) && !defined(CONFIG_SPL_SYS_MALLOC_SIZE)
> - debug("SPL malloc() used 0x%lx bytes (%ld KB)\n", gd->malloc_ptr,
> - gd->malloc_ptr / 1024);
> -#endif
> + if (IS_ENABLED(CONFIG_SYS_MALLOC_F) &&
> + !IS_ENABLED(CONFIG_SPL_SYS_MALLOC_SIZE))
> + debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> + gd_malloc_ptr(), gd_malloc_ptr() / 1024);
> +
> bootstage_mark_name(get_bootstage_id(false), "end phase");
> #ifdef CONFIG_BOOTSTAGE_STASH
> ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index 8fc205ded1a..edf9ff6823f 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -573,6 +573,13 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
> #define gd_malloc_start()0
> #define gd_set_malloc_start(val)
> #endif
> +
> +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
> +#define gd_malloc_ptr() gd->malloc_ptr
> +#else
> +#define gd_malloc_ptr() 0L
> +#endif
> +
> /**
> * enum gd_flags - global data flags
> *
This is another case where readability is not improved. I also have a
bad feeling that changing that exact area had some unintended
consequences from the compiler, that totally should not have happened.
But maybe that was something in a similar code section instead.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 03/32] spl: Rename SYS_SPL_ARGS_ADDR to SPL_SYS_ARGS_ADDR
On Wed, Aug 30, 2023 at 12:04:34PM -0600, Simon Glass wrote: > Rename this so that SPL is first, as per U-Boot convention. > > Signed-off-by: Simon Glass [snip] > diff --git a/doc/develop/falcon.rst b/doc/develop/falcon.rst > index a569d1a2951..fbf8c10e47e 100644 > --- a/doc/develop/falcon.rst > +++ b/doc/develop/falcon.rst > @@ -63,7 +63,7 @@ CONFIG_CMD_SPL > Enable the "spl export" command. > The command "spl export" is then available in U-Boot mode. > > -CONFIG_SYS_SPL_ARGS_ADDR > +CONFIG_SPL_SYS_ARGS_ADDR > Address in RAM where the parameters must be copied by SPL. > In most cases, it is + 0x100. This was intentionally "CONFIG_SYS_SPL_ARGS_ADDR" and not the other way around, for semi-dubious reasons. We should instead try and give this perhaps a better name to describe that it is where in memory the parameters for our payload have been stored. -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/32] spl: Avoid #ifdef with CONFIG_SPL_SYS_ARGS_ADDR
On Wed, Aug 30, 2023 at 12:04:38PM -0600, Simon Glass wrote:
> Use IF_ENABLED_INT() to avoid needing to use the preprocessor. Give the
> Kconfig option a default since we try to avoid hex values without
> defaults.
>
> Signed-off-by: Simon Glass
> ---
>
> common/spl/Kconfig | 1 +
> common/spl/spl.c | 18 ++
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index c23a1f7750b..e863aac2b34 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -1067,6 +1067,7 @@ config SPL_SYS_ARGS_ADDR
> hex "Address in memory to load 'args' file for Falcon Mode to"
> depends on SPL_OS_BOOT
> default 0x8800 if ARCH_OMAP2PLUS
> + default 0
No, we don't do this. We do not put fake address defaults on questions
that must be answered. Further, default 0 on a hex is wrong.
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 77fe4cdb053..2da5bc0c4f5 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -814,9 +814,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> }
>
> memset(&spl_image, '\0', sizeof(spl_image));
> -#ifdef CONFIG_SPL_SYS_ARGS_ADDR
> - spl_image.arg = (void *)CONFIG_SPL_SYS_ARGS_ADDR;
> -#endif
> + if (IS_ENABLED(CONFIG_SPL_SYS_ARGS_ADDR)) {
> + spl_image.arg =
> + map_sysmem(IF_ENABLED_INT(CONFIG_SPL_OS_BOOT,
> + CONFIG_SPL_SYS_ARGS_ADDR), 0);
> + }
> spl_image.boot_device = BOOT_DEVICE_NONE;
> board_boot_order(spl_boot_list);
>
> @@ -873,8 +875,16 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> #if CONFIG_IS_ENABLED(OS_BOOT)
> case IH_OS_LINUX:
> debug("Jumping to Linux\n");
> + if (IS_ENABLED(CONFIG_SPL_SYS_ARGS_ADDR)) {
> + ulong addr;
> +
> + addr = IF_ENABLED_INT(CONFIG_SPL_OS_BOOT,
> + CONFIG_SPL_SYS_ARGS_ADDR);
> + spl_fixup_fdt(map_sysmem(addr, 0));
> + }
> + }
> +
> #if defined(CONFIG_SPL_SYS_ARGS_ADDR)
> - spl_fixup_fdt((void *)CONFIG_SPL_SYS_ARGS_ADDR);
> #endif
> spl_board_prepare_for_linux();
> jump_to_image_linux(&spl_image);
This is also not more readable. The CONFIG option is oddly named, and
this doesn't help.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 04/32] spl: Avoid #ifdef with CONFIG_SPL_SYS_MALLOC
On Wed, Aug 30, 2023 at 12:04:35PM -0600, Simon Glass wrote:
> Use IF_ENABLED_INT() to avoid needing to use the preprocessor.
>
> Signed-off-by: Simon Glass
> ---
>
> common/spl/spl.c | 12
> include/system-constants.h | 5 -
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 27266b393ea..78db9ef5318 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -754,10 +754,14 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>
> spl_set_bd();
>
> -#if defined(CONFIG_SPL_SYS_MALLOC)
> - mem_malloc_init(SPL_SYS_MALLOC_START, CONFIG_SPL_SYS_MALLOC_SIZE);
> - gd->flags |= GD_FLG_FULL_MALLOC_INIT;
> -#endif
> + if (IS_ENABLED(CONFIG_SPL_SYS_MALLOC)) {
> + ulong size;
> +
> + size = IF_ENABLED_INT(CONFIG_SPL_SYS_MALLOC,
> + CONFIG_SPL_SYS_MALLOC_SIZE);
> + mem_malloc_init(SPL_SYS_MALLOC_START, size);
> + gd->flags |= GD_FLG_FULL_MALLOC_INIT;
> + }
> if (!(gd->flags & GD_FLG_SPL_INIT)) {
> if (spl_init())
> hang();
> diff --git a/include/system-constants.h b/include/system-constants.h
> index f0a191be590..aa02c48f49d 100644
> --- a/include/system-constants.h
> +++ b/include/system-constants.h
> @@ -24,9 +24,12 @@
> */
> #ifdef CONFIG_SPL_HAS_CUSTOM_MALLOC_START
> #define SPL_SYS_MALLOC_START CONFIG_SPL_CUSTOM_SYS_MALLOC_ADDR
> -#else
> +#elif defined(CONFIG_SPL_BSS_START_ADDR)
> #define SPL_SYS_MALLOC_START (CONFIG_SPL_BSS_START_ADDR + \
>CONFIG_SPL_BSS_MAX_SIZE)
> +#else
> +/* feature not enabled: this value avoids compiler errors but is not used */
> +#define SPL_SYS_MALLOC_START 0
> #endif
>
> #endif
Does this become relevant later? It decreases, rather than increases
readability of the code to me.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
There were no answers. On Wednesday 30 August 2023 17:26:20 Tom Rini wrote: > I'm trimming the CC list. All of those points you list were addressed > and answered in your last long running argument. You need to decide what > is best for you moving forward and I would ask that it not involve > complaining that you're being asked to review code that you're a listed > maintainer of. > > On Wed, Aug 30, 2023 at 11:13:16PM +0200, Pali Rohár wrote: > > Seems that you completely miss the point of the argument, then the only > > option for such people is to repeat them. Or have I repeat you again > > that you have not answered the first question, why you are asking for > > review from somebody who you are ignoring and not taking into account? > > You do not want to answer this question, right? So you rather change a > > topic and talking about something totally different. > > > > On Wednesday 30 August 2023 17:08:42 Tom Rini wrote: > > > I don't think it's worth re-hashing the same arguments over and over. > > > There is no "my persons", there is the public community. If you no > > > longer wish to participate, I can remove you from the maintainers > > > entries you're listed in. But please stop with the long arguments > > > unrelated to the patches at hand when there's a dozen people and other > > > lists on CC. > > > > > > On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > > > > So lets recap what you and your persons have done in last 6 months: > > > > > > > > * Ignored my changes > > > > * Ignored my reviews > > > > * Ignored my regression reports > > > > * Ignored my reminders > > > > > > > > And now you complaining that I'm not going to do another review? Then > > > > you should be the first who step down there as incompetent person. I was > > > > interesting in developing there for a very long time (10+ years I was > > > > active there?). > > > > > > > > I think I have already wrote many times that I would not do any new > > > > stuff here for you until you start processing existing reports. Seems > > > > that you have been ignoring these my warnings. And when I starting > > > > applying my statements, you are not happy with it? You should have been > > > > thinking about it year ago. > > > > > > > > On Wednesday 30 August 2023 21:44:09 Pali Rohár wrote: > > > > > And you too. That was at the time when you and your people were > > > > > interested in reviews from others. > > > > > > > > > > On Wednesday 30 August 2023 15:41:57 Tom Rini wrote: > > > > > > Then you should probably remove yourself from the places you've > > > > > > listed > > > > > > yourself as an interested maintainer, thanks. > > > > > > > > > > > > On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote: > > > > > > > You have already decided, what is the point? You are not taking > > > > > > > any my > > > > > > > objections into account, so stop writing to me and to others > > > > > > > these your > > > > > > > stupids bullshits. I'm not an idiot who is interesting for them. > > > > > > > > > > > > > > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote: > > > > > > > > You're a listed maintainer for a file being changed. If you > > > > > > > > objected to > > > > > > > > the changes, your objection would matter. If you don't object, > > > > > > > > you can > > > > > > > > just ignore it, or review it, whatever you like. You need to > > > > > > > > decide > > > > > > > > what you want to do about code you're volunteering to maintain. > > > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote: > > > > > > > > > And what? How it is related to the statements that my reviews > > > > > > > > > would also > > > > > > > > > ignored? And what you want from me now? > > > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote: > > > > > > > > > > Pali, > > > > > > > > > > > > > > > > > > > > You are specifically listed as a maintainer for > > > > > > > > > > drivers/pci/pci_mvebu.c > > > > > > > > > > and that is changed by this patch. > > > > > > > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote: > > > > > > > > > > > Simon, why you are contacting me? You have wrote to me > > > > > > > > > > > that you would > > > > > > > > > > > ignore my reviews here, so what you want now? Could you > > > > > > > > > > > please explain > > > > > > > > > > > what you are trying to achieve? I'm not going to review > > > > > > > > > > > this or any > > > > > > > > > > > other your changes. > > > > > > > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote: > > > > > > > > > > > > The PCI helpers read only the base address for a PCI > > > > > > > > > > > > region. In some cases > > > > > > > > > > > > the size is needed as well, e.g. to pass along to a > > > > > > > > > > > > driver which needs to > > > > > > > > > > > > know the size of its register area. > > > > > > > > > > > > > > > > > >
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
I'm trimming the CC list. All of those points you list were addressed and answered in your last long running argument. You need to decide what is best for you moving forward and I would ask that it not involve complaining that you're being asked to review code that you're a listed maintainer of. On Wed, Aug 30, 2023 at 11:13:16PM +0200, Pali Rohár wrote: > Seems that you completely miss the point of the argument, then the only > option for such people is to repeat them. Or have I repeat you again > that you have not answered the first question, why you are asking for > review from somebody who you are ignoring and not taking into account? > You do not want to answer this question, right? So you rather change a > topic and talking about something totally different. > > On Wednesday 30 August 2023 17:08:42 Tom Rini wrote: > > I don't think it's worth re-hashing the same arguments over and over. > > There is no "my persons", there is the public community. If you no > > longer wish to participate, I can remove you from the maintainers > > entries you're listed in. But please stop with the long arguments > > unrelated to the patches at hand when there's a dozen people and other > > lists on CC. > > > > On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > > > So lets recap what you and your persons have done in last 6 months: > > > > > > * Ignored my changes > > > * Ignored my reviews > > > * Ignored my regression reports > > > * Ignored my reminders > > > > > > And now you complaining that I'm not going to do another review? Then > > > you should be the first who step down there as incompetent person. I was > > > interesting in developing there for a very long time (10+ years I was > > > active there?). > > > > > > I think I have already wrote many times that I would not do any new > > > stuff here for you until you start processing existing reports. Seems > > > that you have been ignoring these my warnings. And when I starting > > > applying my statements, you are not happy with it? You should have been > > > thinking about it year ago. > > > > > > On Wednesday 30 August 2023 21:44:09 Pali Rohár wrote: > > > > And you too. That was at the time when you and your people were > > > > interested in reviews from others. > > > > > > > > On Wednesday 30 August 2023 15:41:57 Tom Rini wrote: > > > > > Then you should probably remove yourself from the places you've listed > > > > > yourself as an interested maintainer, thanks. > > > > > > > > > > On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote: > > > > > > You have already decided, what is the point? You are not taking any > > > > > > my > > > > > > objections into account, so stop writing to me and to others these > > > > > > your > > > > > > stupids bullshits. I'm not an idiot who is interesting for them. > > > > > > > > > > > > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote: > > > > > > > You're a listed maintainer for a file being changed. If you > > > > > > > objected to > > > > > > > the changes, your objection would matter. If you don't object, > > > > > > > you can > > > > > > > just ignore it, or review it, whatever you like. You need to > > > > > > > decide > > > > > > > what you want to do about code you're volunteering to maintain. > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote: > > > > > > > > And what? How it is related to the statements that my reviews > > > > > > > > would also > > > > > > > > ignored? And what you want from me now? > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote: > > > > > > > > > Pali, > > > > > > > > > > > > > > > > > > You are specifically listed as a maintainer for > > > > > > > > > drivers/pci/pci_mvebu.c > > > > > > > > > and that is changed by this patch. > > > > > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote: > > > > > > > > > > Simon, why you are contacting me? You have wrote to me that > > > > > > > > > > you would > > > > > > > > > > ignore my reviews here, so what you want now? Could you > > > > > > > > > > please explain > > > > > > > > > > what you are trying to achieve? I'm not going to review > > > > > > > > > > this or any > > > > > > > > > > other your changes. > > > > > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote: > > > > > > > > > > > The PCI helpers read only the base address for a PCI > > > > > > > > > > > region. In some cases > > > > > > > > > > > the size is needed as well, e.g. to pass along to a > > > > > > > > > > > driver which needs to > > > > > > > > > > > know the size of its register area. > > > > > > > > > > > > > > > > > > > > > > Update the functions to allow the size to be returned. > > > > > > > > > > > For serial, record > > > > > > > > > > > the information and provided it with the serial_info() > > > > > > > > > > > call. > > > > > > > > > > > > > > > > > > > > > > A limitation still
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
Seems that you completely miss the point of the argument, then the only option for such people is to repeat them. Or have I repeat you again that you have not answered the first question, why you are asking for review from somebody who you are ignoring and not taking into account? You do not want to answer this question, right? So you rather change a topic and talking about something totally different. On Wednesday 30 August 2023 17:08:42 Tom Rini wrote: > I don't think it's worth re-hashing the same arguments over and over. > There is no "my persons", there is the public community. If you no > longer wish to participate, I can remove you from the maintainers > entries you're listed in. But please stop with the long arguments > unrelated to the patches at hand when there's a dozen people and other > lists on CC. > > On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > > So lets recap what you and your persons have done in last 6 months: > > > > * Ignored my changes > > * Ignored my reviews > > * Ignored my regression reports > > * Ignored my reminders > > > > And now you complaining that I'm not going to do another review? Then > > you should be the first who step down there as incompetent person. I was > > interesting in developing there for a very long time (10+ years I was > > active there?). > > > > I think I have already wrote many times that I would not do any new > > stuff here for you until you start processing existing reports. Seems > > that you have been ignoring these my warnings. And when I starting > > applying my statements, you are not happy with it? You should have been > > thinking about it year ago. > > > > On Wednesday 30 August 2023 21:44:09 Pali Rohár wrote: > > > And you too. That was at the time when you and your people were > > > interested in reviews from others. > > > > > > On Wednesday 30 August 2023 15:41:57 Tom Rini wrote: > > > > Then you should probably remove yourself from the places you've listed > > > > yourself as an interested maintainer, thanks. > > > > > > > > On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote: > > > > > You have already decided, what is the point? You are not taking any my > > > > > objections into account, so stop writing to me and to others these > > > > > your > > > > > stupids bullshits. I'm not an idiot who is interesting for them. > > > > > > > > > > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote: > > > > > > You're a listed maintainer for a file being changed. If you > > > > > > objected to > > > > > > the changes, your objection would matter. If you don't object, you > > > > > > can > > > > > > just ignore it, or review it, whatever you like. You need to decide > > > > > > what you want to do about code you're volunteering to maintain. > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote: > > > > > > > And what? How it is related to the statements that my reviews > > > > > > > would also > > > > > > > ignored? And what you want from me now? > > > > > > > > > > > > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote: > > > > > > > > Pali, > > > > > > > > > > > > > > > > You are specifically listed as a maintainer for > > > > > > > > drivers/pci/pci_mvebu.c > > > > > > > > and that is changed by this patch. > > > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote: > > > > > > > > > Simon, why you are contacting me? You have wrote to me that > > > > > > > > > you would > > > > > > > > > ignore my reviews here, so what you want now? Could you > > > > > > > > > please explain > > > > > > > > > what you are trying to achieve? I'm not going to review this > > > > > > > > > or any > > > > > > > > > other your changes. > > > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote: > > > > > > > > > > The PCI helpers read only the base address for a PCI > > > > > > > > > > region. In some cases > > > > > > > > > > the size is needed as well, e.g. to pass along to a driver > > > > > > > > > > which needs to > > > > > > > > > > know the size of its register area. > > > > > > > > > > > > > > > > > > > > Update the functions to allow the size to be returned. For > > > > > > > > > > serial, record > > > > > > > > > > the information and provided it with the serial_info() call. > > > > > > > > > > > > > > > > > > > > A limitation still exists in that the size is not available > > > > > > > > > > when OF_LIVE > > > > > > > > > > is enabled, so take account of that in the tests. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > arch/sandbox/dts/test.dts | 6 +++--- > > > > > > > > > > drivers/core/fdtaddr.c | 6 +++--- > > > > > > > > > > drivers/core/ofnode.c | 11 --- > > > > > > > > > > drivers/core/read.c | 6 -- > > > > > > > > > > drivers/core/util.c | 2 +- > > > > > > > > > >
Re: [PATCH v3 1/2] schemas: Add a schema for memory map
Hi Ard, On Tue, 29 Aug 2023 at 15:32, Ard Biesheuvel wrote: > > On Tue, 29 Aug 2023 at 21:18, Simon Glass wrote: > > > > Hi Ard, > > > > On Thu, 24 Aug 2023 at 03:10, Ard Biesheuvel wrote: > > > > > > On Wed, 23 Aug 2023 at 22:04, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel wrote: > > > > > > > > > > On Wed, 23 Aug 2023 at 10:59, Mark Rutland > > > > > wrote: > > > > > > > > > > > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote: > > > > > > > The Devicetree specification skips over handling of a logical > > > > > > > view of > > > > > > > the memory map, pointing users to the UEFI specification. > > > > > > > > > > > > > > It is common to split firmware into 'Platform Init', which does > > > > > > > the > > > > > > > initial hardware setup and a "Payload" which selects the OS to be > > > > > > > booted. > > > > > > > Thus an handover interface is required between these two pieces. > > > > > > > > > > > > > > Where UEFI boot-time services are not available, but UEFI > > > > > > > firmware is > > > > > > > present on either side of this interface, information about > > > > > > > memory usage > > > > > > > and attributes must be presented to the "Payload" in some form. > > > > > > > > > > Not quite. > > > > > > > > > > This seems to be intended for consumption by Linux booting in ACPI > > > > > mode, but not via UEFI, right? > > > > > > > > Actually, this is for consumption by firmware. The goal is to allow > > > > edk2 to boot into U-Boot and vice versa, i.e. provide some > > > > interoperability between firmware projects. I will use the "Platform > > > > Init" and "Payload" terminology here too. > > > > > > > > > > OK. It was the cc to linux-acpi@ and the authors of the > > > ACPI/SMBIOS-without-UEFI patches that threw me off here. > > > > > > If we are talking about an internal interface for firmware components, > > > I'd be inclined to treat this as an implementation detail, as long as > > > the OS is not expected to consume these DT nodes. > > > > > > However, I struggle to see the point of framing this information as a > > > 'UEFI memory map'. Neither EDK2 nor u-boot consume this information > > > natively, and there is already prior art in both projects to consume > > > nodes following the existing bindings for device_type=memory and the > > > /reserved-memory node. UEFI runtime memory is generally useless > > > without UEFI runtime services, and UEFI boot services memory is just > > > free memory. > > > > > > There is also an overlap with the handover between secure and > > > non-secure firmware on arm64, which is also DT based, and communicates > > > available memory as well as RAM regions that are reserved for firmware > > > use. > > > > > > In summary, I don't see why a non-UEFI payload would care about UEFI > > > semantics for pre-existing memory reservations, or vice versa. Note > > > that EDK2 will manage its own memory map, and expose it via UEFI boot > > > services and not via DT. > > > > Bear in mind that one or both sides of this interface may be UEFI. > > There is no boot-services link between the two parts that I have > > outlined. > > > > I don't understand what this means. > > UEFI specifies how one component invokes another, and it is not based > on a DT binding. If the second component calls UEFI boot or runtime > services, it should be invoked in this manner. If it doesn't, then it > doesn't care about these memory reservations (and the OS will not be > booted via UEFI either) > > So I feel I am missing something here. Perhaps a practical example > would be helpful? Let's say we want to support these combinations: Platform Init -> Payload U-Boot -> Tianocore coreboot -> U-Boot Tianocore -> U-Boot Tianocore -> Tianocore U-Boot -> U-Boot Some of the above things have UEFI interfaces, some don't. But in the case of Tianocore -> Tianocore we want things to work as if it were Tianocore -> (its own handoff mechanism) Tiancore. Some Platform Init may create runtime code which needs to accessible later. The way I think of it is that we need to generalise the memory map a bit. Saying that you must use UEFI boot services to discover it is too UEFI-specific. > > > > > > > > ... > > > > > > > > There is no intent to implement the UEFI spec, here. It is simply that > > > > some payloads (EDK2) are used to having this information. > > > > > > > > Imagine splitting EDK2 into two parts, one of which does platform init > > > > and the other which (the payload) boots the OS. The payload wants > > > > information from Platform Init and it needs to be in a devicetree, > > > > since that is what we have chosen for this interface. So to some > > > > extent this is unrelated to whether you have EFI boot services. We > > > > just need to be able to pass the information across the interface. > > > > Note that the user can (without recompilation, etc.) replace the > > > > second part with U
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
I don't think it's worth re-hashing the same arguments over and over. There is no "my persons", there is the public community. If you no longer wish to participate, I can remove you from the maintainers entries you're listed in. But please stop with the long arguments unrelated to the patches at hand when there's a dozen people and other lists on CC. On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > So lets recap what you and your persons have done in last 6 months: > > * Ignored my changes > * Ignored my reviews > * Ignored my regression reports > * Ignored my reminders > > And now you complaining that I'm not going to do another review? Then > you should be the first who step down there as incompetent person. I was > interesting in developing there for a very long time (10+ years I was > active there?). > > I think I have already wrote many times that I would not do any new > stuff here for you until you start processing existing reports. Seems > that you have been ignoring these my warnings. And when I starting > applying my statements, you are not happy with it? You should have been > thinking about it year ago. > > On Wednesday 30 August 2023 21:44:09 Pali Rohár wrote: > > And you too. That was at the time when you and your people were > > interested in reviews from others. > > > > On Wednesday 30 August 2023 15:41:57 Tom Rini wrote: > > > Then you should probably remove yourself from the places you've listed > > > yourself as an interested maintainer, thanks. > > > > > > On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote: > > > > You have already decided, what is the point? You are not taking any my > > > > objections into account, so stop writing to me and to others these your > > > > stupids bullshits. I'm not an idiot who is interesting for them. > > > > > > > > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote: > > > > > You're a listed maintainer for a file being changed. If you objected > > > > > to > > > > > the changes, your objection would matter. If you don't object, you > > > > > can > > > > > just ignore it, or review it, whatever you like. You need to decide > > > > > what you want to do about code you're volunteering to maintain. > > > > > > > > > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote: > > > > > > And what? How it is related to the statements that my reviews would > > > > > > also > > > > > > ignored? And what you want from me now? > > > > > > > > > > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote: > > > > > > > Pali, > > > > > > > > > > > > > > You are specifically listed as a maintainer for > > > > > > > drivers/pci/pci_mvebu.c > > > > > > > and that is changed by this patch. > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote: > > > > > > > > Simon, why you are contacting me? You have wrote to me that you > > > > > > > > would > > > > > > > > ignore my reviews here, so what you want now? Could you please > > > > > > > > explain > > > > > > > > what you are trying to achieve? I'm not going to review this or > > > > > > > > any > > > > > > > > other your changes. > > > > > > > > > > > > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote: > > > > > > > > > The PCI helpers read only the base address for a PCI region. > > > > > > > > > In some cases > > > > > > > > > the size is needed as well, e.g. to pass along to a driver > > > > > > > > > which needs to > > > > > > > > > know the size of its register area. > > > > > > > > > > > > > > > > > > Update the functions to allow the size to be returned. For > > > > > > > > > serial, record > > > > > > > > > the information and provided it with the serial_info() call. > > > > > > > > > > > > > > > > > > A limitation still exists in that the size is not available > > > > > > > > > when OF_LIVE > > > > > > > > > is enabled, so take account of that in the tests. > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > --- > > > > > > > > > > > > > > > > > > arch/sandbox/dts/test.dts | 6 +++--- > > > > > > > > > drivers/core/fdtaddr.c | 6 +++--- > > > > > > > > > drivers/core/ofnode.c | 11 --- > > > > > > > > > drivers/core/read.c | 6 -- > > > > > > > > > drivers/core/util.c | 2 +- > > > > > > > > > drivers/pci/pci-uclass.c| 2 +- > > > > > > > > > drivers/pci/pci_mvebu.c | 3 ++- > > > > > > > > > drivers/pci/pci_tegra.c | 2 +- > > > > > > > > > drivers/pci/pcie_mediatek.c | 4 ++-- > > > > > > > > > drivers/serial/ns16550.c| 15 ++- > > > > > > > > > include/dm/fdtaddr.h| 3 ++- > > > > > > > > > include/dm/ofnode.h | 4 +++- > > > > > > > > > include/dm/read.h | 8 +--- > > > > > > > > > include/ns16550.h | 4 +++- > > > > > > > > > include/serial.h| 2 ++ > > > > > > > > > test/dm/pci.c | 14 ++ > > > > > > > > > 16 files ch
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
So lets recap what you and your persons have done in last 6 months:
* Ignored my changes
* Ignored my reviews
* Ignored my regression reports
* Ignored my reminders
And now you complaining that I'm not going to do another review? Then
you should be the first who step down there as incompetent person. I was
interesting in developing there for a very long time (10+ years I was
active there?).
I think I have already wrote many times that I would not do any new
stuff here for you until you start processing existing reports. Seems
that you have been ignoring these my warnings. And when I starting
applying my statements, you are not happy with it? You should have been
thinking about it year ago.
On Wednesday 30 August 2023 21:44:09 Pali Rohár wrote:
> And you too. That was at the time when you and your people were
> interested in reviews from others.
>
> On Wednesday 30 August 2023 15:41:57 Tom Rini wrote:
> > Then you should probably remove yourself from the places you've listed
> > yourself as an interested maintainer, thanks.
> >
> > On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote:
> > > You have already decided, what is the point? You are not taking any my
> > > objections into account, so stop writing to me and to others these your
> > > stupids bullshits. I'm not an idiot who is interesting for them.
> > >
> > > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote:
> > > > You're a listed maintainer for a file being changed. If you objected to
> > > > the changes, your objection would matter. If you don't object, you can
> > > > just ignore it, or review it, whatever you like. You need to decide
> > > > what you want to do about code you're volunteering to maintain.
> > > >
> > > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote:
> > > > > And what? How it is related to the statements that my reviews would
> > > > > also
> > > > > ignored? And what you want from me now?
> > > > >
> > > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> > > > > > Pali,
> > > > > >
> > > > > > You are specifically listed as a maintainer for
> > > > > > drivers/pci/pci_mvebu.c
> > > > > > and that is changed by this patch.
> > > > > >
> > > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > > > > > > Simon, why you are contacting me? You have wrote to me that you
> > > > > > > would
> > > > > > > ignore my reviews here, so what you want now? Could you please
> > > > > > > explain
> > > > > > > what you are trying to achieve? I'm not going to review this or
> > > > > > > any
> > > > > > > other your changes.
> > > > > > >
> > > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > > > > > > The PCI helpers read only the base address for a PCI region. In
> > > > > > > > some cases
> > > > > > > > the size is needed as well, e.g. to pass along to a driver
> > > > > > > > which needs to
> > > > > > > > know the size of its register area.
> > > > > > > >
> > > > > > > > Update the functions to allow the size to be returned. For
> > > > > > > > serial, record
> > > > > > > > the information and provided it with the serial_info() call.
> > > > > > > >
> > > > > > > > A limitation still exists in that the size is not available
> > > > > > > > when OF_LIVE
> > > > > > > > is enabled, so take account of that in the tests.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > ---
> > > > > > > >
> > > > > > > > arch/sandbox/dts/test.dts | 6 +++---
> > > > > > > > drivers/core/fdtaddr.c | 6 +++---
> > > > > > > > drivers/core/ofnode.c | 11 ---
> > > > > > > > drivers/core/read.c | 6 --
> > > > > > > > drivers/core/util.c | 2 +-
> > > > > > > > drivers/pci/pci-uclass.c| 2 +-
> > > > > > > > drivers/pci/pci_mvebu.c | 3 ++-
> > > > > > > > drivers/pci/pci_tegra.c | 2 +-
> > > > > > > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > > > > > > drivers/serial/ns16550.c| 15 ++-
> > > > > > > > include/dm/fdtaddr.h| 3 ++-
> > > > > > > > include/dm/ofnode.h | 4 +++-
> > > > > > > > include/dm/read.h | 8 +---
> > > > > > > > include/ns16550.h | 4 +++-
> > > > > > > > include/serial.h| 2 ++
> > > > > > > > test/dm/pci.c | 14 ++
> > > > > > > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/sandbox/dts/test.dts
> > > > > > > > b/arch/sandbox/dts/test.dts
> > > > > > > > index a413cbe4989..961e8895a49 100644
> > > > > > > > --- a/arch/sandbox/dts/test.dts
> > > > > > > > +++ b/arch/sandbox/dts/test.dts
> > > > > > > > @@ -1087,8 +1087,8 @@
> > > > > > > > pci@1,0 {
> > > > > > > > compatible = "pci-generic";
> > > > > > > > /* reg 0 is at 0x14, using
> > > > > > > > FDT_PCI_SPACE_MEM32 */
> > > > > > > > - reg = <0x02000814 0 0
Re: [PATCH v5 10/13] video: Only dcache flush damaged lines
On 30.08.23 21:12, Alper Nebi Yasak wrote: On 2023-08-22 02:03 +03:00, Simon Glass wrote: Hi Alex, On Mon, 21 Aug 2023 at 16:44, Alexander Graf wrote: On 22.08.23 00:10, Simon Glass wrote: Hi Alex, On Mon, 21 Aug 2023 at 13:59, Alexander Graf wrote: On 21.08.23 21:11, Simon Glass wrote: Hi Alper, On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote: From: Alexander Graf Now that we have a damage area tells us which parts of the frame buffer actually need updating, let's only dcache flush those on video_sync() calls. With this optimization in place, frame buffer updates - especially on large screen such as 4k displays - speed up significantly. Signed-off-by: Alexander Graf Reported-by: Da Xue [Alper: Use damage.xstart/yend, IS_ENABLED()] Co-developed-by: Alper Nebi Yasak Signed-off-by: Alper Nebi Yasak --- Changes in v5: - Use xstart, ystart, xend, yend as names for damage region - Use IS_ENABLED() instead of CONFIG_IS_ENABLED() Changes in v2: - Fix dcache range; we were flushing too much before - Remove ifdefs drivers/video/video-uclass.c | 41 +++- 1 file changed, 36 insertions(+), 5 deletions(-) This is a little strange, since flushing the whole cache will only actually write out data that was actually written (to the display). Is there a benefit to this patch, in terms of performance? I'm happy to see you go through the same thought process I went through when writing these: "This surely can't be the problem, can it?". The answer is "simple" in hindsight: Have a look at the ARMv8 cache flush function. It does the only "safe" thing you can expect it to do: Clean+Invalidate to POC because we use it for multiple things, clearing modified code among others: ENTRY(__asm_flush_dcache_range) mrs x3, ctr_el0 ubfxx3, x3, #16, #4 mov x2, #4 lsl x2, x2, x3 /* cache line size */ /* x2 <- minimal cache line size in cache system */ sub x3, x2, #1 bic x0, x0, x3 1: dc civac, x0 /* clean & invalidate data or unified cache */ add x0, x0, x2 cmp x0, x1 b.lo1b dsb sy ret ENDPROC(__asm_flush_dcache_range) Looking at the "dc civac" call, we find this documentation page from ARM: https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Instructions/DC-CIVAC--Data-or-unified-Cache-line-Clean-and-Invalidate-by-VA-to-PoC This says we're writing any dirtyness of this cache line up to the POC and then invalidate (remove the cache line) also up to POC. That means when you look at a typical SBC, this will either be L2 or system level cache. Every read afterwards needs to go and pull it all the way back to L1 to modify it (or not) on the next character write and then flush it again. Even worse: Because of the invalidate, we may even evict it from caches that the display controller uses to read the frame buffer. So depending on the SoC's cache topology and implementation, we may force the display controller to refetch the full FB content on its next screen refresh cycle. I faintly remember that I tried to experiment with CVAC instead to only flush without invalidating. I don't fully remember the results anymore though. I believe CVAC just behaved identical to CIVAC on the A53 platform I was working on. And then I looked at Cortex-A53 errata like [1] and just accepted that doing anything but restricting the flushing range is a waste of time :) Yuck I didn't know it was invalidating too. That is horrible. Is there no way to fix it? Before building all of this damage logic, I tried, but failed. I'd welcome anyone else to try again :). I'm not even convinced yet that it is actually fixable: Depending on the SoC's internal cache logic, it may opt to always invalidate I think. Wow, that is crazy! How is anyone supposed to make the system run well with logic like that??! That said, this patch set really also makes sense outside of the particular invalidate problem. It creates a generic abstraction between the copy and non-copy code path and allows us to reduce the amount of work spent for both, generically for any video sync operation. Sure...my question was really why it helps so much, given what I understood the caches to be doing. If they are invalidating, then it is amazing anything gets done... I don't really know cache mechanisms and terminology, but AFAIU there's nothing actionable for this patch regarding this discussion, right? Meanwhile I noticed this patch only flushes priv->fb, and think it also needs to flush priv->copy_fb if VIDEO_COPY. The reason was mostly that copy_fb is really only used on x86 where we don't have the cache flush problem/code :). So nobody bothered to add flushing to that code path. Alex
Re: [PATCH v5 00/13] Add video damage tracking
On 29.08.23 11:19, Mark Kettenis wrote: Date: Tue, 29 Aug 2023 08:20:49 +0200 From: Alexander Graf On 28.08.23 23:54, Heinrich Schuchardt wrote: On 8/28/23 22:24, Alexander Graf wrote: On 28.08.23 19:54, Simon Glass wrote: Hi Alex, On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote: Hey Simon, On 22.08.23 20:56, Simon Glass wrote: Hi Alex, On Tue, 22 Aug 2023 at 01:47, Alexander Graf wrote: On 22.08.23 01:03, Simon Glass wrote: Hi Alex, On Mon, 21 Aug 2023 at 16:40, Alexander Graf wrote: On 22.08.23 00:10, Simon Glass wrote: Hi Alex, On Mon, 21 Aug 2023 at 14:20, Alexander Graf wrote: On 21.08.23 21:57, Simon Glass wrote: Hi Alex, On Mon, 21 Aug 2023 at 13:33, Alexander Graf wrote: On 21.08.23 21:11, Simon Glass wrote: Hi Alper, On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote: This is a rebase of Alexander Graf's video damage tracking series, with some tests and other changes. The original cover letter is as follows: This patch set speeds up graphics output on ARM by a factor of 60x. On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached, but need it accessible by the display controller which reads directly from a later point of consistency. Hence, we flush the frame buffer to DRAM on every change. The full frame buffer. It should not, see below. Unfortunately, with the advent of 4k displays, we are seeing frame buffers that can take a while to flush out. This was reported by Da Xue with grub, which happily print 1000s of spaces on the screen to draw a menu. Every printed space triggers a cache flush. That is a bug somewhere in EFI. Unfortunately not :). You may call it a bug in grub: It literally prints over space characters for every character in its menu that it wants cleared. On every text screen draw. This wouldn't be a big issue if we only flush the reactangle that gets modified. But without this patch set, we're flushing the full DRAM buffer on every u-boot text console character write, which means for every character (as that's the only API UEFI has). As a nice side effect, we speed up the normal U-Boot text console as well with this patch set, because even "normal" text prints that write for example a single line of text on the screen today flush the full frame buffer to DRAM. No, I mean that it is a bug that U-Boot (apparently) flushes the cache after every character. It doesn't do that for normal character output and I don't think it makes sense to do it for EFI either. I see. Let's trace the calls: efi_cout_output_string() -> fputs() -> vidconsole_puts() -> video_sync() -> flush_dcache_range() Unfortunately grub abstracts character backends down to the "print character" level, so it calls UEFI's sopisticated "output_string" callback with single characters at a time, which means we do a full dcache flush for every character that we print: https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165 This patch set implements the easiest mitigation against this problem: Damage tracking. We remember the lowest common denominator region that was touched since the last video_sync() call and only flush that. The most typical writer to the frame buffer is the video console, which always writes rectangles of characters on the screen and syncs afterwards. With this patch set applied, we reduce drawing a large grub menu (with serial console attached for size information) on an RK3399-ROC system at 1440p from 55 seconds to less than 1 second. Version 2 also implements VIDEO_COPY using this mechanism, reducing its overhead compared to before as well. So even x86 systems should be faster with this now :). Alternatives considered: 1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever so often. We are missing timers to do this generically. 2) Double buffering - We could try to identify whether anything changed at all and only draw to the FB if it did. That would require maintaining a second buffer that we need to scan. 3) Text buffer - Maintain a buffer of all text printed on the screen with respective location. Don't write if the old and new character are identical. This would limit applicability to text only and is an optimization on top of this patch set. 4) Hash screen lines - Create a hash (sha256?) over every line when it changes. Only flush when it does. I'm not sure if this would waste more time, memory and cache than the current approach. It would make full screen updates much more expensive. 5) Fix the bug mentioned above? Changes in v5: - Add patch "video: test: Split copy frame buffer check into a function" - Add patch "video: test: Support checking copy frame buffer contents" - Add patch "video: test: Test partial updates of hardware frame buffer" - Use xstart, ystart, xend, yend as names for damage region - Document damage struct and f
Re: [PATCH 1/5] drivers: rtc: add rv3032 driver
Hi,
> On 30. Aug 2023, at 21:43, Alexandre Belloni
> wrote:
>
> Hello,
>
> On 30/08/2023 16:03:30+0200, Steffen Dirkwinkel wrote:
>> From: Steffen Dirkwinkel
>>
>> Based on linux driver, with these differences:
>> - no support for trickle charger
>> - no support for hwmon
>> - no support for battery backed memory
>> - dm_i2c instead of regmap
>> - different tm_year and tm_mon
>>
>> read/write access the user eeprom. The read and write functions access
>> the user eeprom so it can be used for nvmem-cells. (like in
>> arch/sandbox/dts/test.dts). This is currently different from linux as
>> you'd get nvram using nvmem-cells. I'm hoping to switch the order there
>
> I'm not sure I get this as both nvram and eeprom are exposed through
> nvmem. The solution is not to reorder but instead to fix the nvmem core
> so you can expose both using nvmem-cells as there are users that access
> the nvram to handle A/B updates (bootcount, rescue mode,...)
How does one set the nvmem location to be in eeprom on the linux driver?
Maybe I just don’t understand the binding correctly?
Currently I have this:
rv3032: rtc@51 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "microcrystal,rv3032”;
reg = <0x51>;
interrupt-parent = <&gpio>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
gem2_mac_address: mac-address@0 {
reg = <0x0 6>;
};
};
On Linux that would read from battery backed ram.
Is there some way to specify it is in eeprom?
>
>> too (there are currently no users) or to make a more specific binding.
>> Currently this would also just work as is if used for mac addresses, as
>> u-boot will put these into fdt before booting linux and linux will then
>> prefer the u-boot provided mac.
>>
>> Signed-off-by: Steffen Dirkwinkel
>>
>> ---
>>
>> drivers/rtc/Kconfig | 10 ++
>> drivers/rtc/Makefile | 1 +
>> drivers/rtc/rv3032.c | 334 +++
>> 3 files changed, 345 insertions(+)
>> create mode 100644 drivers/rtc/rv3032.c
>>
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index 23173139e0..a41ec9b6cc 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -172,6 +172,16 @@ config RTC_RV3029
>> This driver supports reading and writing the RTC/calendar and the
>> battery-baced SRAM section.
>>
>> +config RTC_RV3032
>> + bool "Enable RV3032 driver"
>> + depends on DM_RTC
>> + help
>> + The MicroCrystal RV3032 is a I2C Real Time Clock (RTC) with a 16-byte
>> + battery-backed SRAM and a 32-byte user eeprom.
>> +
>> + This driver supports reading and writing the RTC/calendar and the
>> + user eeprom.
>> +
>> config RTC_RV8803
>> bool "Enable RV8803 driver"
>> depends on DM_RTC
>> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
>> index 308fab8da9..9c2d8c7aa9 100644
>> --- a/drivers/rtc/Makefile
>> +++ b/drivers/rtc/Makefile
>> @@ -31,6 +31,7 @@ obj-$(CONFIG_RTC_PL031) += pl031.o
>> obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
>> obj-$(CONFIG_RTC_RV3028) += rv3028.o
>> obj-$(CONFIG_RTC_RV3029) += rv3029.o
>> +obj-$(CONFIG_RTC_RV3032) += rv3032.o
>> obj-$(CONFIG_RTC_RV8803) += rv8803.o
>> obj-$(CONFIG_RTC_RX8025) += rx8025.o
>> obj-$(CONFIG_RTC_RX8010SJ) += rx8010sj.o
>> diff --git a/drivers/rtc/rv3032.c b/drivers/rtc/rv3032.c
>> new file mode 100644
>> index 00..8d5d860c0a
>> --- /dev/null
>> +++ b/drivers/rtc/rv3032.c
>> @@ -0,0 +1,334 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * RTC driver for the Micro Crystal RV3032
>> + *
>> + * based on linux driver from
>> + * Copyright (C) 2020 Micro Crystal SA
>> + *
>> + * Alexandre Belloni
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define RV3032_SEC 0x01
>> +#define RV3032_MIN 0x02
>> +#define RV3032_HOUR 0x03
>> +#define RV3032_WDAY 0x04
>> +#define RV3032_DAY 0x05
>> +#define RV3032_MONTH 0x06
>> +#define RV3032_YEAR 0x07
>> +#define RV3032_ALARM_MIN 0x08
>> +#define RV3032_ALARM_HOUR 0x09
>> +#define RV3032_ALARM_DAY 0x0A
>> +#define RV3032_STATUS 0x0D
>> +#define RV3032_TLSB 0x0E
>> +#define RV3032_TMSB 0x0F
>> +#define RV3032_CTRL1 0x10
>> +#define RV3032_CTRL2 0x11
>> +#define RV3032_CTRL3 0x12
>> +#define RV3032_TS_CTRL 0x13
>> +#define RV3032_CLK_IRQ 0x14
>> +#define RV3032_EEPROM_ADDR 0x3D
>> +#define RV3032_EEPROM_DATA 0x3E
>> +#define RV3032_EEPROM_CMD 0x3F
>> +#define RV3032_RAM1 0x40
>> +#define RV3032_PMU 0xC0
>> +#define RV3032_OFFSET 0xC1
>> +#define RV3032_CLKOUT1 0xC2
>> +#define RV3032_CLKOUT2 0xC3
>> +#define RV3032_TREF0 0xC4
>> +#define RV3032_TREF1 0xC5
>> +
>> +#define RV3032_STATUS_VLF BIT(0)
>> +#define RV3032_STATUS_PORF BIT(1)
>> +#define RV3032_STATUS_EVF BIT(2)
>> +#define RV3032_STATUS_AF BIT(3)
>> +#define RV3032_STATUS_TF BIT(4)
>> +#define RV3032_STATUS_UF BIT(5)
>> +#define RV3032_STATUS_TLF BIT(6)
>> +#define RV3032_STATUS_THF BIT(7)
>> +
>> +#define RV3032_TLSB_CLKF BIT(1)
>> +#define RV3032_TLSB_EEBUSY BIT(2)
>> +#define RV3032_TLSB_TEMP GENMASK(7, 4)
>> +
>> +#define RV3032_CLKOUT2_HF
Re: [PATCH v5 00/13] Add video damage tracking
On 30.08.23 20:27, Alper Nebi Yasak wrote: Hi all, On 2023-08-29 09:27 +03:00, Alexander Graf wrote: On 29.08.23 00:08, Simon Glass wrote: On Mon, 28 Aug 2023 at 14:24, Alexander Graf wrote: On 28.08.23 19:54, Simon Glass wrote: U-Boot does have video_sync() but it doesn't know when to call it. If it does not call it, then any amount of single-threaded code can run after that, which may update the framebuffer. In other words, U-Boot is in exactly the same boat as UEFI. It has to decide whether to call video_sync() based on some sort of heuristic. That is the only point I am trying to make here. Does that make sense? Oh, I thought you mentioned above that U-Boot is in a better spot or "has it solved already". I agree - it's in the same boat and the only safe thing it can really do today that is fully cross-platform compatible is to call video_sync() after every character. I don't understand what you mean by "any amount of single-threaded code can run after that, which may update the framebuffer". Any framebuffer modification is U-Boot internal code which then again can apply video_sync() to tell the system "I want what I wrote to screen actually be on screen now". I don't think that's necessarily bad design. A bit clunky, but we're in a pre-boot environment after all. Since we're aligned now: What exactly did you refer to with "but we have managed to work out something"? So now we are on the same page about that point. The next step is my heuristic point: vidconsole_putc_xy() - does not call video_sync() vidconsole_newline() - does I am simply suggesting that UEFI should do the same thing. I think the better analogy is with vidconsole_puts() - does and that's exactly the function that the UEFI code calls. The UEFI interface is "write this long string to screen". All the UEFI code does is call vidconsole_puts() to do that which then (rightfully) calls video_sync(). The reason we flush after every character with grub is grub: Grub abuses the "write long string to screen" function and instead only writes a single character on each call, which then means we flush on every character write. There's another reason I discovered empirically as I tried to implement cyclic video_sync()s instead of calling it whenever. The writes will go through eventually (as the cache is filled by other work?) even if *we* don't explicitly flush it. That means partial data gets pushed to the display in an uncontrolled way, resulting in bad graphical artifacts. And I mean very noticeable things like a blocky waterfall effect when filling a blue rectangle background in GRUB menu, or half-rendered letters in U-Boot console (very obvious if I get it to panic-and-hang). I think that locks it down, and there's two reasonable things we can do: - Write and immediately flush to fb (hardware) every time - Batch writes in fb, periodically write-and-flush to copy_fb (hardware) Both can utilize a damage tracking feature to minimize the amount of copy/flush done. And maybe we can implement the two simultaneously if we skip flushing when damaged region is zero-sized already-flushed. There's a flaw with the second approach though, EFI can have direct access to the hardware copy_fb. When it has directly written to the framebuffer, we would need to at least stop overwriting that, and ideally copy backwards to the non-hardware fb. Is there some kind of a locking API that EFI apps use to get/release the framebuffer? We could hook that into something like that. Edk2 also has a shadow frame buffer that it uses for VGA because otherwise the NC read accesses from VRAM would be too expensive. I don't believe there's any UEFI locking mechanism, but clear understanding that if you want to access the frame buffer while anything else but you could potentially access it too, you better use the UEFI APIs instead of scribbling on it yourself. Note that I've been using "flush" and not "sync" to avoid talking about when a driver ops->video_sync() should be called. Is that fundamentally incompatible with EFI, can we even call that after e.g. ExitBootServices where the OS wants to use it as efifb? Maybe we should always call that periodically at 60Hz (1us) or so? If you actually need to do something actively frequently, then that won't work anymore after ExitBootServices. At that point, all "normal" U-Boot code is gone. (I'm testing on rk3399-gru-kevin with a 2400x1600 eDP screen by the way, and attaching some WIP patches if you want to test. Debian arm64 netinst iso uses text-mode GRUB by default, in case you need a payload to test.) Also I notice that EFI calls notify? all the time, so U-Boot probably does have the ability to sync the video every 10ms if we wanted to. BTW, with attached cyclic patch on chromebook_kevin, I immediately get a warning that it takes too long, at 2-8ms without/with VIDEO_COPY. It's about 11ms for both on sandbox on my PC. I would expect explicit damage flushes like the patch set o
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
And you too. That was at the time when you and your people were
interested in reviews from others.
On Wednesday 30 August 2023 15:41:57 Tom Rini wrote:
> Then you should probably remove yourself from the places you've listed
> yourself as an interested maintainer, thanks.
>
> On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote:
> > You have already decided, what is the point? You are not taking any my
> > objections into account, so stop writing to me and to others these your
> > stupids bullshits. I'm not an idiot who is interesting for them.
> >
> > On Wednesday 30 August 2023 15:04:22 Tom Rini wrote:
> > > You're a listed maintainer for a file being changed. If you objected to
> > > the changes, your objection would matter. If you don't object, you can
> > > just ignore it, or review it, whatever you like. You need to decide
> > > what you want to do about code you're volunteering to maintain.
> > >
> > > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote:
> > > > And what? How it is related to the statements that my reviews would also
> > > > ignored? And what you want from me now?
> > > >
> > > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> > > > > Pali,
> > > > >
> > > > > You are specifically listed as a maintainer for
> > > > > drivers/pci/pci_mvebu.c
> > > > > and that is changed by this patch.
> > > > >
> > > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > > > > > Simon, why you are contacting me? You have wrote to me that you
> > > > > > would
> > > > > > ignore my reviews here, so what you want now? Could you please
> > > > > > explain
> > > > > > what you are trying to achieve? I'm not going to review this or any
> > > > > > other your changes.
> > > > > >
> > > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > > > > > The PCI helpers read only the base address for a PCI region. In
> > > > > > > some cases
> > > > > > > the size is needed as well, e.g. to pass along to a driver which
> > > > > > > needs to
> > > > > > > know the size of its register area.
> > > > > > >
> > > > > > > Update the functions to allow the size to be returned. For
> > > > > > > serial, record
> > > > > > > the information and provided it with the serial_info() call.
> > > > > > >
> > > > > > > A limitation still exists in that the size is not available when
> > > > > > > OF_LIVE
> > > > > > > is enabled, so take account of that in the tests.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass
> > > > > > > ---
> > > > > > >
> > > > > > > arch/sandbox/dts/test.dts | 6 +++---
> > > > > > > drivers/core/fdtaddr.c | 6 +++---
> > > > > > > drivers/core/ofnode.c | 11 ---
> > > > > > > drivers/core/read.c | 6 --
> > > > > > > drivers/core/util.c | 2 +-
> > > > > > > drivers/pci/pci-uclass.c| 2 +-
> > > > > > > drivers/pci/pci_mvebu.c | 3 ++-
> > > > > > > drivers/pci/pci_tegra.c | 2 +-
> > > > > > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > > > > > drivers/serial/ns16550.c| 15 ++-
> > > > > > > include/dm/fdtaddr.h| 3 ++-
> > > > > > > include/dm/ofnode.h | 4 +++-
> > > > > > > include/dm/read.h | 8 +---
> > > > > > > include/ns16550.h | 4 +++-
> > > > > > > include/serial.h| 2 ++
> > > > > > > test/dm/pci.c | 14 ++
> > > > > > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > > > > > > index a413cbe4989..961e8895a49 100644
> > > > > > > --- a/arch/sandbox/dts/test.dts
> > > > > > > +++ b/arch/sandbox/dts/test.dts
> > > > > > > @@ -1087,8 +1087,8 @@
> > > > > > > pci@1,0 {
> > > > > > > compatible = "pci-generic";
> > > > > > > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32
> > > > > > > */
> > > > > > > - reg = <0x02000814 0 0 0 0
> > > > > > > -0x01000810 0 0 0 0>;
> > > > > > > + reg = <0x02000814 0 0 0x80 0
> > > > > > > +0x01000810 0 0 0xc0 0>;
> > > > > > > sandbox,emul = <&swap_case_emul0_1>;
> > > > > > > };
> > > > > > > p2sb-pci@2,0 {
> > > > > > > @@ -1115,7 +1115,7 @@
> > > > > > > pci@1f,0 {
> > > > > > > compatible = "pci-generic";
> > > > > > > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > > > > > > - reg = <0x0100f810 0 0 0 0>;
> > > > > > > + reg = <0x0100f810 0 0 0x100 0>;
> > > > > > > sandbox,emul = <&swap_case_emul0_1f>;
> > > > > > > };
> > > > > > > };
> > > > > > > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > > > > > > index 546db675aaf..b79d138c419 100644
> > > > > > > --- a/drivers/core/fdtaddr.c
> > > > > > > +++ b/drivers/core/fdtaddr.c
> >
Re: [PATCH 1/5] drivers: rtc: add rv3032 driver
Hello, On 30/08/2023 16:03:30+0200, Steffen Dirkwinkel wrote: > From: Steffen Dirkwinkel > > Based on linux driver, with these differences: > - no support for trickle charger > - no support for hwmon > - no support for battery backed memory > - dm_i2c instead of regmap > - different tm_year and tm_mon > > read/write access the user eeprom. The read and write functions access > the user eeprom so it can be used for nvmem-cells. (like in > arch/sandbox/dts/test.dts). This is currently different from linux as > you'd get nvram using nvmem-cells. I'm hoping to switch the order there I'm not sure I get this as both nvram and eeprom are exposed through nvmem. The solution is not to reorder but instead to fix the nvmem core so you can expose both using nvmem-cells as there are users that access the nvram to handle A/B updates (bootcount, rescue mode,...) > too (there are currently no users) or to make a more specific binding. > Currently this would also just work as is if used for mac addresses, as > u-boot will put these into fdt before booting linux and linux will then > prefer the u-boot provided mac. > > Signed-off-by: Steffen Dirkwinkel > > --- > > drivers/rtc/Kconfig | 10 ++ > drivers/rtc/Makefile | 1 + > drivers/rtc/rv3032.c | 334 +++ > 3 files changed, 345 insertions(+) > create mode 100644 drivers/rtc/rv3032.c > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 23173139e0..a41ec9b6cc 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -172,6 +172,16 @@ config RTC_RV3029 > This driver supports reading and writing the RTC/calendar and the > battery-baced SRAM section. > > +config RTC_RV3032 > + bool "Enable RV3032 driver" > + depends on DM_RTC > + help > + The MicroCrystal RV3032 is a I2C Real Time Clock (RTC) with a 16-byte > + battery-backed SRAM and a 32-byte user eeprom. > + > + This driver supports reading and writing the RTC/calendar and the > + user eeprom. > + > config RTC_RV8803 > bool "Enable RV8803 driver" > depends on DM_RTC > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile > index 308fab8da9..9c2d8c7aa9 100644 > --- a/drivers/rtc/Makefile > +++ b/drivers/rtc/Makefile > @@ -31,6 +31,7 @@ obj-$(CONFIG_RTC_PL031) += pl031.o > obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o > obj-$(CONFIG_RTC_RV3028) += rv3028.o > obj-$(CONFIG_RTC_RV3029) += rv3029.o > +obj-$(CONFIG_RTC_RV3032) += rv3032.o > obj-$(CONFIG_RTC_RV8803) += rv8803.o > obj-$(CONFIG_RTC_RX8025) += rx8025.o > obj-$(CONFIG_RTC_RX8010SJ) += rx8010sj.o > diff --git a/drivers/rtc/rv3032.c b/drivers/rtc/rv3032.c > new file mode 100644 > index 00..8d5d860c0a > --- /dev/null > +++ b/drivers/rtc/rv3032.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * RTC driver for the Micro Crystal RV3032 > + * > + * based on linux driver from > + * Copyright (C) 2020 Micro Crystal SA > + * > + * Alexandre Belloni > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define RV3032_SEC 0x01 > +#define RV3032_MIN 0x02 > +#define RV3032_HOUR 0x03 > +#define RV3032_WDAY 0x04 > +#define RV3032_DAY 0x05 > +#define RV3032_MONTH 0x06 > +#define RV3032_YEAR 0x07 > +#define RV3032_ALARM_MIN 0x08 > +#define RV3032_ALARM_HOUR0x09 > +#define RV3032_ALARM_DAY 0x0A > +#define RV3032_STATUS0x0D > +#define RV3032_TLSB 0x0E > +#define RV3032_TMSB 0x0F > +#define RV3032_CTRL1 0x10 > +#define RV3032_CTRL2 0x11 > +#define RV3032_CTRL3 0x12 > +#define RV3032_TS_CTRL 0x13 > +#define RV3032_CLK_IRQ 0x14 > +#define RV3032_EEPROM_ADDR 0x3D > +#define RV3032_EEPROM_DATA 0x3E > +#define RV3032_EEPROM_CMD0x3F > +#define RV3032_RAM1 0x40 > +#define RV3032_PMU 0xC0 > +#define RV3032_OFFSET0xC1 > +#define RV3032_CLKOUT1 0xC2 > +#define RV3032_CLKOUT2 0xC3 > +#define RV3032_TREF0 0xC4 > +#define RV3032_TREF1 0xC5 > + > +#define RV3032_STATUS_VLFBIT(0) > +#define RV3032_STATUS_PORF BIT(1) > +#define RV3032_STATUS_EVFBIT(2) > +#define RV3032_STATUS_AF BIT(3) > +#define RV3032_STATUS_TF BIT(4) > +#define RV3032_STATUS_UF BIT(5) > +#define RV3032_STATUS_TLFBIT(6) > +#define RV3032_STATUS_THFBIT(7) > + > +#define RV3032_TLSB_CLKF BIT(1) > +#define RV3032_TLSB_EEBUSY BIT(2) > +#define RV3032_TLSB_TEMP GENMASK(7, 4) > + > +#define RV3032_CLKOUT2_HFD_MSK
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
Then you should probably remove yourself from the places you've listed
yourself as an interested maintainer, thanks.
On Wed, Aug 30, 2023 at 09:10:36PM +0200, Pali Rohár wrote:
> You have already decided, what is the point? You are not taking any my
> objections into account, so stop writing to me and to others these your
> stupids bullshits. I'm not an idiot who is interesting for them.
>
> On Wednesday 30 August 2023 15:04:22 Tom Rini wrote:
> > You're a listed maintainer for a file being changed. If you objected to
> > the changes, your objection would matter. If you don't object, you can
> > just ignore it, or review it, whatever you like. You need to decide
> > what you want to do about code you're volunteering to maintain.
> >
> > On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote:
> > > And what? How it is related to the statements that my reviews would also
> > > ignored? And what you want from me now?
> > >
> > > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> > > > Pali,
> > > >
> > > > You are specifically listed as a maintainer for drivers/pci/pci_mvebu.c
> > > > and that is changed by this patch.
> > > >
> > > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > > > > Simon, why you are contacting me? You have wrote to me that you would
> > > > > ignore my reviews here, so what you want now? Could you please explain
> > > > > what you are trying to achieve? I'm not going to review this or any
> > > > > other your changes.
> > > > >
> > > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > > > > The PCI helpers read only the base address for a PCI region. In
> > > > > > some cases
> > > > > > the size is needed as well, e.g. to pass along to a driver which
> > > > > > needs to
> > > > > > know the size of its register area.
> > > > > >
> > > > > > Update the functions to allow the size to be returned. For serial,
> > > > > > record
> > > > > > the information and provided it with the serial_info() call.
> > > > > >
> > > > > > A limitation still exists in that the size is not available when
> > > > > > OF_LIVE
> > > > > > is enabled, so take account of that in the tests.
> > > > > >
> > > > > > Signed-off-by: Simon Glass
> > > > > > ---
> > > > > >
> > > > > > arch/sandbox/dts/test.dts | 6 +++---
> > > > > > drivers/core/fdtaddr.c | 6 +++---
> > > > > > drivers/core/ofnode.c | 11 ---
> > > > > > drivers/core/read.c | 6 --
> > > > > > drivers/core/util.c | 2 +-
> > > > > > drivers/pci/pci-uclass.c| 2 +-
> > > > > > drivers/pci/pci_mvebu.c | 3 ++-
> > > > > > drivers/pci/pci_tegra.c | 2 +-
> > > > > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > > > > drivers/serial/ns16550.c| 15 ++-
> > > > > > include/dm/fdtaddr.h| 3 ++-
> > > > > > include/dm/ofnode.h | 4 +++-
> > > > > > include/dm/read.h | 8 +---
> > > > > > include/ns16550.h | 4 +++-
> > > > > > include/serial.h| 2 ++
> > > > > > test/dm/pci.c | 14 ++
> > > > > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > > > > > index a413cbe4989..961e8895a49 100644
> > > > > > --- a/arch/sandbox/dts/test.dts
> > > > > > +++ b/arch/sandbox/dts/test.dts
> > > > > > @@ -1087,8 +1087,8 @@
> > > > > > pci@1,0 {
> > > > > > compatible = "pci-generic";
> > > > > > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32
> > > > > > */
> > > > > > - reg = <0x02000814 0 0 0 0
> > > > > > - 0x01000810 0 0 0 0>;
> > > > > > + reg = <0x02000814 0 0 0x80 0
> > > > > > + 0x01000810 0 0 0xc0 0>;
> > > > > > sandbox,emul = <&swap_case_emul0_1>;
> > > > > > };
> > > > > > p2sb-pci@2,0 {
> > > > > > @@ -1115,7 +1115,7 @@
> > > > > > pci@1f,0 {
> > > > > > compatible = "pci-generic";
> > > > > > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > > > > > - reg = <0x0100f810 0 0 0 0>;
> > > > > > + reg = <0x0100f810 0 0 0x100 0>;
> > > > > > sandbox,emul = <&swap_case_emul0_1f>;
> > > > > > };
> > > > > > };
> > > > > > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > > > > > index 546db675aaf..b79d138c419 100644
> > > > > > --- a/drivers/core/fdtaddr.c
> > > > > > +++ b/drivers/core/fdtaddr.c
> > > > > > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice
> > > > > > *dev, unsigned long size)
> > > > > > return map_physmem(addr, size, MAP_NOCACHE);
> > > > > > }
> > > > > >
> > > > > > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > > > > > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev,
Re: [PATCH v5 04/13] dm: video: Add damage tracking API
On 2023-08-21 22:11 +03:00, Simon Glass wrote: > On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak > wrote: >> >> From: Alexander Graf >> >> We are going to introduce image damage tracking to fasten up screen >> refresh on large displays. This patch adds damage tracking for up to >> one rectangle of the screen which is typically enough to hold blt or >> text print updates. Callers into this API and a reduced dcache flush >> code path will follow in later patches. >> >> Signed-off-by: Alexander Graf >> Reported-by: Da Xue >> [Alper: Use xstart/yend, document new fields, return void from >> video_damage(), declare priv, drop headers, use IS_ENABLED()] >> Co-developed-by: Alper Nebi Yasak >> Signed-off-by: Alper Nebi Yasak >> --- >> >> Changes in v5: >> - Use xstart, ystart, xend, yend as names for damage region >> - Document damage struct and fields in struct video_priv comment >> - Return void from video_damage() >> - Fix undeclared priv error in video_sync() >> - Drop unused headers from video-uclass.c >> - Use IS_ENABLED() instead of CONFIG_IS_ENABLED() >> >> Changes in v4: >> - Move damage clear to patch "dm: video: Add damage tracking API" >> - Simplify first damage logic >> - Remove VIDEO_DAMAGE default for ARM >> >> Changes in v3: >> - Adapt to always assume DM is used >> >> Changes in v2: >> - Remove ifdefs >> >> drivers/video/Kconfig| 13 >> drivers/video/video-uclass.c | 41 +--- >> include/video.h | 32 ++-- >> 3 files changed, 81 insertions(+), 5 deletions(-) >> > > Reviewed-by: Simon Glass > > But I suggest an empty static inline in the case where the feature is > disabled? You mean with something like #ifdef CONFIG_VIDEO_DAMAGE, right?
Re: [PATCH v5 10/13] video: Only dcache flush damaged lines
On 2023-08-22 02:03 +03:00, Simon Glass wrote: > Hi Alex, > > On Mon, 21 Aug 2023 at 16:44, Alexander Graf wrote: >> >> >> On 22.08.23 00:10, Simon Glass wrote: >>> Hi Alex, >>> >>> On Mon, 21 Aug 2023 at 13:59, Alexander Graf wrote: On 21.08.23 21:11, Simon Glass wrote: > Hi Alper, > > On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak > wrote: >> From: Alexander Graf >> >> Now that we have a damage area tells us which parts of the frame buffer >> actually need updating, let's only dcache flush those on video_sync() >> calls. With this optimization in place, frame buffer updates - especially >> on large screen such as 4k displays - speed up significantly. >> >> Signed-off-by: Alexander Graf >> Reported-by: Da Xue >> [Alper: Use damage.xstart/yend, IS_ENABLED()] >> Co-developed-by: Alper Nebi Yasak >> Signed-off-by: Alper Nebi Yasak >> --- >> >> Changes in v5: >> - Use xstart, ystart, xend, yend as names for damage region >> - Use IS_ENABLED() instead of CONFIG_IS_ENABLED() >> >> Changes in v2: >> - Fix dcache range; we were flushing too much before >> - Remove ifdefs >> >>drivers/video/video-uclass.c | 41 +++- >>1 file changed, 36 insertions(+), 5 deletions(-) > This is a little strange, since flushing the whole cache will only > actually write out data that was actually written (to the display). Is > there a benefit to this patch, in terms of performance? I'm happy to see you go through the same thought process I went through when writing these: "This surely can't be the problem, can it?". The answer is "simple" in hindsight: Have a look at the ARMv8 cache flush function. It does the only "safe" thing you can expect it to do: Clean+Invalidate to POC because we use it for multiple things, clearing modified code among others: ENTRY(__asm_flush_dcache_range) mrs x3, ctr_el0 ubfxx3, x3, #16, #4 mov x2, #4 lsl x2, x2, x3 /* cache line size */ /* x2 <- minimal cache line size in cache system */ sub x3, x2, #1 bic x0, x0, x3 1: dc civac, x0 /* clean & invalidate data or unified cache */ add x0, x0, x2 cmp x0, x1 b.lo1b dsb sy ret ENDPROC(__asm_flush_dcache_range) Looking at the "dc civac" call, we find this documentation page from ARM: https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Instructions/DC-CIVAC--Data-or-unified-Cache-line-Clean-and-Invalidate-by-VA-to-PoC This says we're writing any dirtyness of this cache line up to the POC and then invalidate (remove the cache line) also up to POC. That means when you look at a typical SBC, this will either be L2 or system level cache. Every read afterwards needs to go and pull it all the way back to L1 to modify it (or not) on the next character write and then flush it again. Even worse: Because of the invalidate, we may even evict it from caches that the display controller uses to read the frame buffer. So depending on the SoC's cache topology and implementation, we may force the display controller to refetch the full FB content on its next screen refresh cycle. I faintly remember that I tried to experiment with CVAC instead to only flush without invalidating. I don't fully remember the results anymore though. I believe CVAC just behaved identical to CIVAC on the A53 platform I was working on. And then I looked at Cortex-A53 errata like [1] and just accepted that doing anything but restricting the flushing range is a waste of time :) >>> Yuck I didn't know it was invalidating too. That is horrible. Is there >>> no way to fix it? >> >> >> Before building all of this damage logic, I tried, but failed. I'd >> welcome anyone else to try again :). I'm not even convinced yet that it >> is actually fixable: Depending on the SoC's internal cache logic, it may >> opt to always invalidate I think. > > Wow, that is crazy! How is anyone supposed to make the system run well > with logic like that??! > >> >> That said, this patch set really also makes sense outside of the >> particular invalidate problem. It creates a generic abstraction between >> the copy and non-copy code path and allows us to reduce the amount of >> work spent for both, generically for any video sync operation. > > Sure...my question was really why it helps so much, given what I > understood the caches to be doing. If they are invalidating, then it > is amazing anything gets done... I don't really know cache mechanisms and terminology, but AFAIU there's nothing actionable for this
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
You have already decided, what is the point? You are not taking any my
objections into account, so stop writing to me and to others these your
stupids bullshits. I'm not an idiot who is interesting for them.
On Wednesday 30 August 2023 15:04:22 Tom Rini wrote:
> You're a listed maintainer for a file being changed. If you objected to
> the changes, your objection would matter. If you don't object, you can
> just ignore it, or review it, whatever you like. You need to decide
> what you want to do about code you're volunteering to maintain.
>
> On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote:
> > And what? How it is related to the statements that my reviews would also
> > ignored? And what you want from me now?
> >
> > On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> > > Pali,
> > >
> > > You are specifically listed as a maintainer for drivers/pci/pci_mvebu.c
> > > and that is changed by this patch.
> > >
> > > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > > > Simon, why you are contacting me? You have wrote to me that you would
> > > > ignore my reviews here, so what you want now? Could you please explain
> > > > what you are trying to achieve? I'm not going to review this or any
> > > > other your changes.
> > > >
> > > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > > > The PCI helpers read only the base address for a PCI region. In some
> > > > > cases
> > > > > the size is needed as well, e.g. to pass along to a driver which
> > > > > needs to
> > > > > know the size of its register area.
> > > > >
> > > > > Update the functions to allow the size to be returned. For serial,
> > > > > record
> > > > > the information and provided it with the serial_info() call.
> > > > >
> > > > > A limitation still exists in that the size is not available when
> > > > > OF_LIVE
> > > > > is enabled, so take account of that in the tests.
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > > > ---
> > > > >
> > > > > arch/sandbox/dts/test.dts | 6 +++---
> > > > > drivers/core/fdtaddr.c | 6 +++---
> > > > > drivers/core/ofnode.c | 11 ---
> > > > > drivers/core/read.c | 6 --
> > > > > drivers/core/util.c | 2 +-
> > > > > drivers/pci/pci-uclass.c| 2 +-
> > > > > drivers/pci/pci_mvebu.c | 3 ++-
> > > > > drivers/pci/pci_tegra.c | 2 +-
> > > > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > > > drivers/serial/ns16550.c| 15 ++-
> > > > > include/dm/fdtaddr.h| 3 ++-
> > > > > include/dm/ofnode.h | 4 +++-
> > > > > include/dm/read.h | 8 +---
> > > > > include/ns16550.h | 4 +++-
> > > > > include/serial.h| 2 ++
> > > > > test/dm/pci.c | 14 ++
> > > > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > > > >
> > > > > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > > > > index a413cbe4989..961e8895a49 100644
> > > > > --- a/arch/sandbox/dts/test.dts
> > > > > +++ b/arch/sandbox/dts/test.dts
> > > > > @@ -1087,8 +1087,8 @@
> > > > > pci@1,0 {
> > > > > compatible = "pci-generic";
> > > > > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32
> > > > > */
> > > > > - reg = <0x02000814 0 0 0 0
> > > > > -0x01000810 0 0 0 0>;
> > > > > + reg = <0x02000814 0 0 0x80 0
> > > > > +0x01000810 0 0 0xc0 0>;
> > > > > sandbox,emul = <&swap_case_emul0_1>;
> > > > > };
> > > > > p2sb-pci@2,0 {
> > > > > @@ -1115,7 +1115,7 @@
> > > > > pci@1f,0 {
> > > > > compatible = "pci-generic";
> > > > > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > > > > - reg = <0x0100f810 0 0 0 0>;
> > > > > + reg = <0x0100f810 0 0 0x100 0>;
> > > > > sandbox,emul = <&swap_case_emul0_1f>;
> > > > > };
> > > > > };
> > > > > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > > > > index 546db675aaf..b79d138c419 100644
> > > > > --- a/drivers/core/fdtaddr.c
> > > > > +++ b/drivers/core/fdtaddr.c
> > > > > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice
> > > > > *dev, unsigned long size)
> > > > > return map_physmem(addr, size, MAP_NOCACHE);
> > > > > }
> > > > >
> > > > > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > > > > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t
> > > > > *sizep)
> > > > > {
> > > > > ulong addr;
> > > > >
> > > > > @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct
> > > > > udevice *dev)
> > > > > int ret;
> > > > >
> > > > > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> > > > > FDT_PCI_SPACE_MEM32,
> > >
Re: [PATCH v5 11/13] video: Use VIDEO_DAMAGE for VIDEO_COPY
On 2023-08-21 23:06 +03:00, Alexander Graf wrote:
>
> On 21.08.23 21:11, Simon Glass wrote:
>> Hi Alper,
>>
>> On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak
>> wrote:
>>> From: Alexander Graf
>>>
>>> CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
>>> print a single character, it will always copy the full range of bytes
>>> from the top left corner of the character to the lower right onto the
>>> uncached frame buffer. This includes pretty much the full line contents
>>> of the printed character.
>>>
>>> Since we now have proper damage tracking, let's make use of that to reduce
>>> the amount of data we need to copy. With this patch applied, we will only
>>> copy the tiny rectangle surrounding characters when we print them,
>>> speeding up the video console.
>> I suppose for rotated consoles it copies whole lines, but otherwise it
>> does a lot of small copies?
>
>
> I tried to keep the code as simple as possible and only track an "upper
> left" and "lower right" corner of modifications. So sync will always
> copy/flush a single rectangle.
Yep, see patch 06/13 for size of the regions. E.g. for putc_xy()s it's
fontdata->height * fontdata->width, for rows it's like fontdata->height
* vid_priv->xsize * count...
>>
>>> After this, changes to the main frame buffer are not immediately copied
>>> to the copy frame buffer, but postponed until the next video device
>>> sync. So issue an explicit sync before inspecting the copy frame buffer
>>> contents for the video tests.
>> So how does the sync get done in this case?
>
> It gets called as part of video_sync():
>
> +static void video_flush_copy(struct udevice *vid)
> +{
> + struct video_priv *priv = dev_get_uclass_priv(vid);
> +
> + if (!priv->copy_fb)
> + return;
> +
> + if (priv->damage.xend && priv->damage.yend) {
> + int lstart = priv->damage.xstart * VNBYTES(priv->bpix);
> + int lend = priv->damage.xend * VNBYTES(priv->bpix);
> + int y;
> +
> + for (y = priv->damage.ystart; y < priv->damage.yend; y++) {
> + ulong offset = (y * priv->line_length) + lstart;
> + ulong len = lend - lstart;
> +
> + memcpy(priv->copy_fb + offset, priv->fb + offset, len);
> + }
> + }
> +}
I think Simon was asking how and when video_sync() is called outside the
tests. The tests use lower-level functions that are ops->putc_xy() in
each console, and normally vidconsole calls higher on the call-chain
also maybe do a video_sync() when they think it's worth updating the
display.
>>
>>> Signed-off-by: Alexander Graf
>>> [Alper: Rebase for fontdata->height/w, fill_part(), fix memmove(dev),
>>> drop from defconfig, use damage.xstart/yend, use IS_ENABLED(),
>>> call video_sync() before copy_fb check, update video_copy test]
>>> Co-developed-by: Alper Nebi Yasak
>>> Signed-off-by: Alper Nebi Yasak
>>> ---
>>>
>>> Changes in v5:
>>> - Remove video_sync_copy() also from video_fill(), video_fill_part()
>>> - Fix memmove() calls by removing the extra dev argument
>>> - Call video_sync() before checking copy_fb in video tests
>>> - Use xstart, ystart, xend, yend as names for damage region
>>> - Use met->baseline instead of priv->baseline
>>> - Use fontdata->height/width instead of VIDEO_FONT_HEIGHT/WIDTH
>>> - Use xstart, ystart, xend, yend as names for damage region
>>> - Use IS_ENABLED() instead of CONFIG_IS_ENABLED()
>>> - Drop VIDEO_DAMAGE from sandbox defconfig added in a new patch
>>> - Update dm_test_video_copy test added in a new patch
>>>
>>> Changes in v3:
>>> - Make VIDEO_COPY always select VIDEO_DAMAGE
>>>
>>> Changes in v2:
>>> - Add patch "video: Use VIDEO_DAMAGE for VIDEO_COPY"
>>>
>>> configs/sandbox_defconfig | 1 -
>>> drivers/video/Kconfig | 5 ++
>>> drivers/video/console_normal.c| 13 +
>>> drivers/video/console_rotate.c| 44 +++---
>>> drivers/video/console_truetype.c | 16 +
>>> drivers/video/vidconsole-uclass.c | 16 -
>>> drivers/video/video-uclass.c | 97 ---
>>> drivers/video/video_bmp.c | 7 ---
>>> include/video.h | 37
>>> include/video_console.h | 52 -
>>> test/dm/video.c | 3 +-
>>> 11 files changed, 43 insertions(+), 248 deletions(-)
>>>
>>> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
>>> index 51b820f13121..259f31f26cee 100644
>>> --- a/configs/sandbox_defconfig
>>> +++ b/configs/sandbox_defconfig
>>> @@ -307,7 +307,6 @@ CONFIG_USB_ETH_CDC=y
>>> CONFIG_VIDEO=y
>>> CONFIG_VIDEO_FONT_SUN12X22=y
>>> CONFIG_VIDEO_COPY=y
>>> -CONFIG_VIDEO_DAMAGE=y
>>> CONFIG_CONSOLE_ROTATION=y
>>> CONFIG_CONSOLE_TRUETYPE=y
>>> CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 97f494a1340b..b3fbd9d7d9ca 100644
>>>
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
You're a listed maintainer for a file being changed. If you objected to
the changes, your objection would matter. If you don't object, you can
just ignore it, or review it, whatever you like. You need to decide
what you want to do about code you're volunteering to maintain.
On Wed, Aug 30, 2023 at 08:39:13PM +0200, Pali Rohár wrote:
> And what? How it is related to the statements that my reviews would also
> ignored? And what you want from me now?
>
> On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> > Pali,
> >
> > You are specifically listed as a maintainer for drivers/pci/pci_mvebu.c
> > and that is changed by this patch.
> >
> > On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > > Simon, why you are contacting me? You have wrote to me that you would
> > > ignore my reviews here, so what you want now? Could you please explain
> > > what you are trying to achieve? I'm not going to review this or any
> > > other your changes.
> > >
> > > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > > The PCI helpers read only the base address for a PCI region. In some
> > > > cases
> > > > the size is needed as well, e.g. to pass along to a driver which needs
> > > > to
> > > > know the size of its register area.
> > > >
> > > > Update the functions to allow the size to be returned. For serial,
> > > > record
> > > > the information and provided it with the serial_info() call.
> > > >
> > > > A limitation still exists in that the size is not available when OF_LIVE
> > > > is enabled, so take account of that in the tests.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > ---
> > > >
> > > > arch/sandbox/dts/test.dts | 6 +++---
> > > > drivers/core/fdtaddr.c | 6 +++---
> > > > drivers/core/ofnode.c | 11 ---
> > > > drivers/core/read.c | 6 --
> > > > drivers/core/util.c | 2 +-
> > > > drivers/pci/pci-uclass.c| 2 +-
> > > > drivers/pci/pci_mvebu.c | 3 ++-
> > > > drivers/pci/pci_tegra.c | 2 +-
> > > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > > drivers/serial/ns16550.c| 15 ++-
> > > > include/dm/fdtaddr.h| 3 ++-
> > > > include/dm/ofnode.h | 4 +++-
> > > > include/dm/read.h | 8 +---
> > > > include/ns16550.h | 4 +++-
> > > > include/serial.h| 2 ++
> > > > test/dm/pci.c | 14 ++
> > > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > > >
> > > > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > > > index a413cbe4989..961e8895a49 100644
> > > > --- a/arch/sandbox/dts/test.dts
> > > > +++ b/arch/sandbox/dts/test.dts
> > > > @@ -1087,8 +1087,8 @@
> > > > pci@1,0 {
> > > > compatible = "pci-generic";
> > > > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32
> > > > */
> > > > - reg = <0x02000814 0 0 0 0
> > > > - 0x01000810 0 0 0 0>;
> > > > + reg = <0x02000814 0 0 0x80 0
> > > > + 0x01000810 0 0 0xc0 0>;
> > > > sandbox,emul = <&swap_case_emul0_1>;
> > > > };
> > > > p2sb-pci@2,0 {
> > > > @@ -1115,7 +1115,7 @@
> > > > pci@1f,0 {
> > > > compatible = "pci-generic";
> > > > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > > > - reg = <0x0100f810 0 0 0 0>;
> > > > + reg = <0x0100f810 0 0 0x100 0>;
> > > > sandbox,emul = <&swap_case_emul0_1f>;
> > > > };
> > > > };
> > > > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > > > index 546db675aaf..b79d138c419 100644
> > > > --- a/drivers/core/fdtaddr.c
> > > > +++ b/drivers/core/fdtaddr.c
> > > > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
> > > > unsigned long size)
> > > > return map_physmem(addr, size, MAP_NOCACHE);
> > > > }
> > > >
> > > > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > > > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t
> > > > *sizep)
> > > > {
> > > > ulong addr;
> > > >
> > > > @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct
> > > > udevice *dev)
> > > > int ret;
> > > >
> > > > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> > > > FDT_PCI_SPACE_MEM32,
> > > > - "reg", &pci_addr);
> > > > + "reg", &pci_addr, sizep);
> > > > if (ret) {
> > > > /* try if there is any i/o-mapped register */
> > > > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> > > >FDT_PCI_SPACE_IO,
> > > > "reg",
> > > > -
Re: [PATCH v2 2/2] armv8: Disable SYS_DCACHE_OFF & SYS_ICACHE_OFF for ARM64
On Tue, Aug 22, 2023 at 01:21:12PM +0530, Bhupesh Sharma wrote: > Ideally SYS_ICACHE_OFF and SYS_DCACHE_OFF should never be set for > ARM64 (ARMv8) platforms, as it makes booting u-boot slower on these > platforms. > > However, if some platforms require ICACHE or DCACHE to be disabled > only for the smaller SPL stage, we should support such configurations > in u-boot as well. > > Compile-tested for: > - qemu arm64 > - imx8 > - stm32 > > and run-tested on: > - Qualcomm RB3 platform > > Cc: Tom Rini > Cc: Simon Glass > Cc: Peng Fan > Signed-off-by: Bhupesh Sharma > Reviewed-by: Tom Rini > --- > arch/arm/Kconfig| 2 ++ > arch/arm/cpu/armv8/Makefile | 4 ++-- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 36ee1e9a3c..92bff715e3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -141,6 +141,7 @@ config THUMB2_KERNEL > > config SYS_ICACHE_OFF > bool "Do not enable icache" > + depends on !ARM64 > help > Do not enable instruction cache in U-Boot. > > @@ -153,6 +154,7 @@ config SPL_SYS_ICACHE_OFF > > config SYS_DCACHE_OFF > bool "Do not enable dcache" > + depends on !ARM64 > help > Do not enable data cache in U-Boot. > > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile > index bba4f570db..0d0c1728e4 100644 > --- a/arch/arm/cpu/armv8/Makefile > +++ b/arch/arm/cpu/armv8/Makefile > @@ -5,13 +5,13 @@ > > extra-y := start.o > > +obj-y+= cache_v8.o > obj-y+= cpu.o > ifndef CONFIG_$(SPL_TPL_)TIMER > obj-$(CONFIG_SYS_ARCH_TIMER) += generic_timer.o > endif > ifndef CONFIG_$(SPL_)SYS_DCACHE_OFF > -obj-y+= cache_v8.o > -obj-y+= cache.o > +obj-y += cache.o > endif > ifdef CONFIG_SPL_BUILD > obj-$(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) += exceptions.o I'm adding Michal here because this changes the behavior on xilinx platforms that had the icache off. I was under the impression that at the levels U-Boot runs at on aarch64, we just couldn't have icache/dcache off, but I guess that's wrong? -- Tom signature.asc Description: PGP signature
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
And what? How it is related to the statements that my reviews would also
ignored? And what you want from me now?
On Wednesday 30 August 2023 14:17:50 Tom Rini wrote:
> Pali,
>
> You are specifically listed as a maintainer for drivers/pci/pci_mvebu.c
> and that is changed by this patch.
>
> On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> > Simon, why you are contacting me? You have wrote to me that you would
> > ignore my reviews here, so what you want now? Could you please explain
> > what you are trying to achieve? I'm not going to review this or any
> > other your changes.
> >
> > On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > > The PCI helpers read only the base address for a PCI region. In some cases
> > > the size is needed as well, e.g. to pass along to a driver which needs to
> > > know the size of its register area.
> > >
> > > Update the functions to allow the size to be returned. For serial, record
> > > the information and provided it with the serial_info() call.
> > >
> > > A limitation still exists in that the size is not available when OF_LIVE
> > > is enabled, so take account of that in the tests.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > arch/sandbox/dts/test.dts | 6 +++---
> > > drivers/core/fdtaddr.c | 6 +++---
> > > drivers/core/ofnode.c | 11 ---
> > > drivers/core/read.c | 6 --
> > > drivers/core/util.c | 2 +-
> > > drivers/pci/pci-uclass.c| 2 +-
> > > drivers/pci/pci_mvebu.c | 3 ++-
> > > drivers/pci/pci_tegra.c | 2 +-
> > > drivers/pci/pcie_mediatek.c | 4 ++--
> > > drivers/serial/ns16550.c| 15 ++-
> > > include/dm/fdtaddr.h| 3 ++-
> > > include/dm/ofnode.h | 4 +++-
> > > include/dm/read.h | 8 +---
> > > include/ns16550.h | 4 +++-
> > > include/serial.h| 2 ++
> > > test/dm/pci.c | 14 ++
> > > 16 files changed, 60 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > > index a413cbe4989..961e8895a49 100644
> > > --- a/arch/sandbox/dts/test.dts
> > > +++ b/arch/sandbox/dts/test.dts
> > > @@ -1087,8 +1087,8 @@
> > > pci@1,0 {
> > > compatible = "pci-generic";
> > > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
> > > - reg = <0x02000814 0 0 0 0
> > > -0x01000810 0 0 0 0>;
> > > + reg = <0x02000814 0 0 0x80 0
> > > +0x01000810 0 0 0xc0 0>;
> > > sandbox,emul = <&swap_case_emul0_1>;
> > > };
> > > p2sb-pci@2,0 {
> > > @@ -1115,7 +1115,7 @@
> > > pci@1f,0 {
> > > compatible = "pci-generic";
> > > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > > - reg = <0x0100f810 0 0 0 0>;
> > > + reg = <0x0100f810 0 0 0x100 0>;
> > > sandbox,emul = <&swap_case_emul0_1f>;
> > > };
> > > };
> > > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > > index 546db675aaf..b79d138c419 100644
> > > --- a/drivers/core/fdtaddr.c
> > > +++ b/drivers/core/fdtaddr.c
> > > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
> > > unsigned long size)
> > > return map_physmem(addr, size, MAP_NOCACHE);
> > > }
> > >
> > > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t
> > > *sizep)
> > > {
> > > ulong addr;
> > >
> > > @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct udevice
> > > *dev)
> > > int ret;
> > >
> > > ret = ofnode_read_pci_addr(dev_ofnode(dev), FDT_PCI_SPACE_MEM32,
> > > -"reg", &pci_addr);
> > > +"reg", &pci_addr, sizep);
> > > if (ret) {
> > > /* try if there is any i/o-mapped register */
> > > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> > > FDT_PCI_SPACE_IO, "reg",
> > > -&pci_addr);
> > > +&pci_addr, sizep);
> > > if (ret)
> > > return FDT_ADDR_T_NONE;
> > > }
> > > diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> > > index 2ef4114cb6f..c9cec456f43 100644
> > > --- a/drivers/core/ofnode.c
> > > +++ b/drivers/core/ofnode.c
> > > @@ -1270,7 +1270,8 @@ const uint8_t *ofnode_read_u8_array_ptr(ofnode
> > > node, const char *propname,
> > > }
> > >
> > > int ofnode_read_pci_addr(ofnode node, enum fdt_pci_space type,
> > > - const char *propname, struct fdt_pci_addr *addr)
> > > + const char *propname, struct fdt_pci_addr *addr,
>
Re: [PATCH v5 00/13] Add video damage tracking
Hi all, On 2023-08-29 09:27 +03:00, Alexander Graf wrote: > On 29.08.23 00:08, Simon Glass wrote: >> On Mon, 28 Aug 2023 at 14:24, Alexander Graf wrote: >>> On 28.08.23 19:54, Simon Glass wrote: U-Boot does have video_sync() but it doesn't know when to call it. If it does not call it, then any amount of single-threaded code can run after that, which may update the framebuffer. In other words, U-Boot is in exactly the same boat as UEFI. It has to decide whether to call video_sync() based on some sort of heuristic. That is the only point I am trying to make here. Does that make sense? >>> >>> Oh, I thought you mentioned above that U-Boot is in a better spot or >>> "has it solved already". I agree - it's in the same boat and the only >>> safe thing it can really do today that is fully cross-platform >>> compatible is to call video_sync() after every character. >>> >>> I don't understand what you mean by "any amount of single-threaded code >>> can run after that, which may update the framebuffer". Any framebuffer >>> modification is U-Boot internal code which then again can apply >>> video_sync() to tell the system "I want what I wrote to screen actually >>> be on screen now". I don't think that's necessarily bad design. A bit >>> clunky, but we're in a pre-boot environment after all. >>> >>> Since we're aligned now: What exactly did you refer to with "but we have >>> managed to work out something"? So now we are on the same page about that point. The next step is my >> heuristic point: >> >> vidconsole_putc_xy() - does not call video_sync() >> vidconsole_newline() - does >> >> I am simply suggesting that UEFI should do the same thing. > > > I think the better analogy is with > > vidconsole_puts() - does > > and that's exactly the function that the UEFI code calls. The UEFI > interface is "write this long string to screen". All the UEFI code does > is call vidconsole_puts() to do that which then (rightfully) calls > video_sync(). > > The reason we flush after every character with grub is grub: Grub abuses > the "write long string to screen" function and instead only writes a > single character on each call, which then means we flush on every > character write. There's another reason I discovered empirically as I tried to implement cyclic video_sync()s instead of calling it whenever. The writes will go through eventually (as the cache is filled by other work?) even if *we* don't explicitly flush it. That means partial data gets pushed to the display in an uncontrolled way, resulting in bad graphical artifacts. And I mean very noticeable things like a blocky waterfall effect when filling a blue rectangle background in GRUB menu, or half-rendered letters in U-Boot console (very obvious if I get it to panic-and-hang). I think that locks it down, and there's two reasonable things we can do: - Write and immediately flush to fb (hardware) every time - Batch writes in fb, periodically write-and-flush to copy_fb (hardware) Both can utilize a damage tracking feature to minimize the amount of copy/flush done. And maybe we can implement the two simultaneously if we skip flushing when damaged region is zero-sized already-flushed. There's a flaw with the second approach though, EFI can have direct access to the hardware copy_fb. When it has directly written to the framebuffer, we would need to at least stop overwriting that, and ideally copy backwards to the non-hardware fb. Is there some kind of a locking API that EFI apps use to get/release the framebuffer? We could hook that into something like that. Note that I've been using "flush" and not "sync" to avoid talking about when a driver ops->video_sync() should be called. Is that fundamentally incompatible with EFI, can we even call that after e.g. ExitBootServices where the OS wants to use it as efifb? Maybe we should always call that periodically at 60Hz (1us) or so? (I'm testing on rk3399-gru-kevin with a 2400x1600 eDP screen by the way, and attaching some WIP patches if you want to test. Debian arm64 netinst iso uses text-mode GRUB by default, in case you need a payload to test.) >> Also I notice that EFI calls notify? all the time, so U-Boot probably >> does have the ability to sync the video every 10ms if we wanted to. BTW, with attached cyclic patch on chromebook_kevin, I immediately get a warning that it takes too long, at 2-8ms without/with VIDEO_COPY. It's about 11ms for both on sandbox on my PC. > I fail to see how invalidating the frame buffer for the screen every > 10ms is any better than doing flush+invalidate operations only on screen > areas that changed? It's more fragile, more difficult to understand and > also significantly more expensive given that most of the time very > little on the screen actually changes. I am not suggesting it is better, at all. I am just trying to explain that the U-Boot EFI implementation should not be calling video_sync
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
Pali,
You are specifically listed as a maintainer for drivers/pci/pci_mvebu.c
and that is changed by this patch.
On Wed, Aug 30, 2023 at 08:14:59PM +0200, Pali Rohár wrote:
> Simon, why you are contacting me? You have wrote to me that you would
> ignore my reviews here, so what you want now? Could you please explain
> what you are trying to achieve? I'm not going to review this or any
> other your changes.
>
> On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > The PCI helpers read only the base address for a PCI region. In some cases
> > the size is needed as well, e.g. to pass along to a driver which needs to
> > know the size of its register area.
> >
> > Update the functions to allow the size to be returned. For serial, record
> > the information and provided it with the serial_info() call.
> >
> > A limitation still exists in that the size is not available when OF_LIVE
> > is enabled, so take account of that in the tests.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > arch/sandbox/dts/test.dts | 6 +++---
> > drivers/core/fdtaddr.c | 6 +++---
> > drivers/core/ofnode.c | 11 ---
> > drivers/core/read.c | 6 --
> > drivers/core/util.c | 2 +-
> > drivers/pci/pci-uclass.c| 2 +-
> > drivers/pci/pci_mvebu.c | 3 ++-
> > drivers/pci/pci_tegra.c | 2 +-
> > drivers/pci/pcie_mediatek.c | 4 ++--
> > drivers/serial/ns16550.c| 15 ++-
> > include/dm/fdtaddr.h| 3 ++-
> > include/dm/ofnode.h | 4 +++-
> > include/dm/read.h | 8 +---
> > include/ns16550.h | 4 +++-
> > include/serial.h| 2 ++
> > test/dm/pci.c | 14 ++
> > 16 files changed, 60 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > index a413cbe4989..961e8895a49 100644
> > --- a/arch/sandbox/dts/test.dts
> > +++ b/arch/sandbox/dts/test.dts
> > @@ -1087,8 +1087,8 @@
> > pci@1,0 {
> > compatible = "pci-generic";
> > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
> > - reg = <0x02000814 0 0 0 0
> > - 0x01000810 0 0 0 0>;
> > + reg = <0x02000814 0 0 0x80 0
> > + 0x01000810 0 0 0xc0 0>;
> > sandbox,emul = <&swap_case_emul0_1>;
> > };
> > p2sb-pci@2,0 {
> > @@ -1115,7 +1115,7 @@
> > pci@1f,0 {
> > compatible = "pci-generic";
> > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > - reg = <0x0100f810 0 0 0 0>;
> > + reg = <0x0100f810 0 0 0x100 0>;
> > sandbox,emul = <&swap_case_emul0_1f>;
> > };
> > };
> > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > index 546db675aaf..b79d138c419 100644
> > --- a/drivers/core/fdtaddr.c
> > +++ b/drivers/core/fdtaddr.c
> > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
> > unsigned long size)
> > return map_physmem(addr, size, MAP_NOCACHE);
> > }
> >
> > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t
> > *sizep)
> > {
> > ulong addr;
> >
> > @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct udevice
> > *dev)
> > int ret;
> >
> > ret = ofnode_read_pci_addr(dev_ofnode(dev), FDT_PCI_SPACE_MEM32,
> > - "reg", &pci_addr);
> > + "reg", &pci_addr, sizep);
> > if (ret) {
> > /* try if there is any i/o-mapped register */
> > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> >FDT_PCI_SPACE_IO, "reg",
> > - &pci_addr);
> > + &pci_addr, sizep);
> > if (ret)
> > return FDT_ADDR_T_NONE;
> > }
> > diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> > index 2ef4114cb6f..c9cec456f43 100644
> > --- a/drivers/core/ofnode.c
> > +++ b/drivers/core/ofnode.c
> > @@ -1270,7 +1270,8 @@ const uint8_t *ofnode_read_u8_array_ptr(ofnode node,
> > const char *propname,
> > }
> >
> > int ofnode_read_pci_addr(ofnode node, enum fdt_pci_space type,
> > -const char *propname, struct fdt_pci_addr *addr)
> > +const char *propname, struct fdt_pci_addr *addr,
> > +fdt_size_t *size)
> > {
> > const fdt32_t *cell;
> > int len;
> > @@ -1298,14 +1299,18 @@ int ofnode_read_pci_addr(ofnode node, enum
> > fdt_pci_space type,
> > (ulong)fdt32_to_cpu(cell[1]),
> > (ulong)fdt32_to_cpu(cell[2]));
> >
[PATCH 00/32] spl: Preparation for Universal Payload
This series tidies up SPL a little and adds some core ofnode functions needed to support Universal Payload. It also includes a few minor fix-ups for sandbox. For SPL the changes include CONFIG naming, removing various #ifdefs and tidying up the FIT code. One notable piece of the ofnode improvements is support for flattening a livetree. This should be useful in future as we move FDT fixups to use the ofnode API. Michal Simek (1): dm: core: support reading a single indexed u64 value Simon Glass (31): spl: Use CONFIG_SPL... instead of CONFIG_..._SPL_... spl: Rename SYS_SPL_ARGS_ADDR to SPL_SYS_ARGS_ADDR spl: Avoid #ifdef with CONFIG_SPL_SYS_MALLOC spl: mx6: powerpc: Drop the condition on timer_init() spl: Drop #ifdefs for BOARD_INIT and watchdog spl: Avoid #ifdef with CONFIG_SPL_SYS_ARGS_ADDR spl: Drop the switch() statement for OS selection spl: Avoid an #ifdef when printing gd->malloc_ptr spl: Remove #ifdefs with BOOTSTAGE spl: Rename spl_load_fit_image() to load_simple_fit() spl: Move the full FIT code to spl_fit.c spl: Use the correct FIT_..._PROP constants spl: Move bloblist writing until the image is known dm: core: Reverse the argument order in ofnode_copy_props() dm: core: Ensure we run flattree tests on ofnode dm: core: Tidy up comments in the ofnode tests dm: core: Add a function to create an empty tree dm: core: Add a way to copy a node dm: core: Add a way to delete a node dm: core: Add a way to convert a devicetree to a dtb dm: core: Support writing a boolean dm: core: Support writing a 64-bit value dm: core: Add tests for oftree_path() sandbox: Move reading the RAM buffer into a better place sandbox: Init the EC properly even if no state file is available sandbox: Only read the state if we have a state file sandbox: Move the bloblist down a little in memory bloblist: Support initing from multiple places fdt: Allow the devicetree to come from a bloblist command: Include a required header in command.h pci: serial: Support reading PCI-register size with base Kconfig | 2 +- README| 2 +- arch/arm/cpu/armv7/ls102xa/fdt.c | 2 +- .../armv8/fsl-layerscape/doc/README.falcon| 2 +- arch/sandbox/cpu/start.c | 27 +- arch/sandbox/cpu/state.c | 2 + arch/sandbox/dts/test.dts | 7 +- boot/vbe_request.c| 2 +- boot/vbe_simple_os.c | 2 +- common/Kconfig| 2 +- common/bloblist.c | 15 +- common/board_f.c | 4 +- common/spl/Kconfig| 17 +- common/spl/Kconfig.nxp| 2 +- common/spl/spl.c | 234 --- common/spl/spl_ext.c | 4 +- common/spl/spl_fat.c | 4 +- common/spl/spl_fit.c | 127 +++-- common/spl/spl_mmc.c | 2 +- common/spl/spl_nand.c | 10 +- common/spl/spl_nor.c | 8 +- common/spl/spl_spi.c | 2 +- common/spl/spl_ubi.c | 2 +- common/spl/spl_xip.c | 2 +- configs/am335x_baltos_defconfig | 4 +- configs/am335x_boneblack_vboot_defconfig | 4 +- configs/am335x_evm_defconfig | 4 +- configs/am335x_evm_spiboot_defconfig | 4 +- configs/am335x_guardian_defconfig | 4 +- configs/am335x_hs_evm_defconfig | 4 +- configs/am335x_hs_evm_uart_defconfig | 4 +- configs/am335x_igep003x_defconfig | 4 +- configs/am335x_pdu001_defconfig | 4 +- configs/am335x_shc_defconfig | 4 +- configs/am335x_shc_ict_defconfig | 4 +- configs/am335x_shc_netboot_defconfig | 4 +- configs/am335x_shc_sdboot_defconfig | 4 +- configs/am335x_sl50_defconfig | 4 +- configs/am3517_evm_defconfig | 6 +- configs/am43xx_evm_defconfig | 4 +- configs/am43xx_evm_rtconly_defconfig | 4 +- configs/am43xx_evm_usbhost_boot_defconfig | 4 +- configs/am43xx_hs_evm_defconfig | 4 +- configs/am57xx_evm_defconfig | 4 +- configs/am57xx_hs_evm_defconfig | 4 +- configs/am57xx_hs_evm_usb_defconfig | 4 +- configs/am62ax_evm_r5_defconfig | 6 +- configs/am62x_evm_r5_defconfig| 8 +- configs/am64x_evm_a53_defconfig | 4 +- configs/am64x_evm_r5_defconfig| 8 +- configs/am65x_evm_a53_defconfig | 4 +- configs/am65x_evm_r5_defconfig| 8 +
[PATCH 4/5] xilinx: zynqmp: add Beckhoff CX8200
From: Steffen Dirkwinkel
This adds support for the Beckhoff CX8200 series of industrial embedded PCs.
There is some information about the device and features here:
https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/cx8200-arm-cortex-a53/
Currently supported/tested:
- Boot from microSD
- Ethernet
- USB
- rtc / rtc eeprom
- tpm access
- uart
Open points:
- adding the psgtr usb phy doesn't work in linux (failed to get pll
lock)
- fpga loading currently only as u-boot script or pre launch cmd (type
may be stored in eeprom of rtc so this could be made generic)
Signed-off-by: Steffen Dirkwinkel
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/zynqmp-beckhoff-cx8200.dts | 247 +++
.../zynqmp-beckhoff-cx8200/psu_init_gpl.c | 1960 +
configs/xilinx_zynqmp_virt_defconfig |2 +-
4 files changed, 2209 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/zynqmp-beckhoff-cx8200.dts
create mode 100644 board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/psu_init_gpl.c
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 85fd5b1157..c5b5615362 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -393,6 +393,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
dtb-$(CONFIG_ARCH_ZYNQMP) += \
avnet-ultra96-rev1.dtb \
zynqmp-a2197-revA.dtb \
+ zynqmp-beckhoff-cx8200.dtb \
zynqmp-dlc21-revA.dtb \
zynqmp-e-a2197-00-revA.dtb \
zynqmp-g-a2197-00-revA.dtb \
diff --git a/arch/arm/dts/zynqmp-beckhoff-cx8200.dts
b/arch/arm/dts/zynqmp-beckhoff-cx8200.dts
new file mode 100644
index 00..9ed54b29b9
--- /dev/null
+++ b/arch/arm/dts/zynqmp-beckhoff-cx8200.dts
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Beckhoff CX8200
+ *
+ * (C) Copyright 2023, Beckhoff Automation GmbH & Co. KG
+ *
+ * Steffen Dirkwinkel
+ */
+
+/dts-v1/;
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ model = "Beckhoff CX8200";
+ compatible = "beckhoff,cx8200-rev1", "beckhoff,cx8200",
+"xlnx,zynqmp";
+
+ aliases {
+ ethernet0 = &gem2;
+ rtc0 = &rv3032;
+ serial0 = &uart1;
+ usb0 = &usb1;
+ };
+
+ chosen {
+ bootargs = "earlycon";
+ stdout-path = "serial0:115200n8";
+ };
+
+ cpus {
+ /delete-node/ cpu@2 ;
+ /delete-node/ cpu@3 ;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x3ff0>;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupt-parent = <&gic>;
+ interrupts = <0 143 4>,
+<0 144 4>,
+<0 145 4>,
+<0 146 4>;
+ interrupt-affinity = <&cpu0>,
+<&cpu1>;
+ };
+
+ usb1_clk: usb1_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+};
+
+&fpd_dma_chan1 {
+ status = "okay";
+};
+
+&fpd_dma_chan2 {
+ status = "okay";
+};
+
+&fpd_dma_chan3 {
+ status = "okay";
+};
+
+&fpd_dma_chan4 {
+ status = "okay";
+};
+
+&fpd_dma_chan5 {
+ status = "okay";
+};
+
+&fpd_dma_chan6 {
+ status = "okay";
+};
+
+&fpd_dma_chan7 {
+ status = "okay";
+};
+
+&fpd_dma_chan8 {
+ status = "okay";
+};
+
+&gem2 {
+ status = "okay";
+ nvmem-cells = <&gem2_mac_address>;
+ nvmem-cell-names = "mac-address";
+ phy-handle = <&phy0>;
+ phy-mode = "rgmii-id";
+ phy0: ethernet-phy@0 { /* Broadcom B50212E */
+ reg = <0>;
+ };
+};
+
+&gpio {
+ status = "okay";
+
+ /* USB_EN */
+ enable-hog {
+ gpio-hog;
+ gpios = <47 0>;
+ output-high;
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <20>;
+ scl-gpios = <&gpio 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio 33 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1_default>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+
+ rv3032: rtc@51 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "microcrystal,rv3032";
+ reg = <0x51>;
+ interrupt-parent = <&gpio>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ gem2_mac_address: mac-address@0 {
+ reg = <0x0 6>;
+ };
+ };
+};
+
+&pinctrl0 {
+ status = "okay";
+
+ pinctrl_usb1_default: usb1-default {
+ mux {
+
[PATCH 5/5] xilinx: zynqmp: beckhoff cx8200: setup inner cache broadcasting
From: Steffen Dirkwinkel We need it for coherent access between pl and ps. >From xilinx documentation: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842098/Zynq+UltraScale+MPSoC+Cache+Coherency Inner Cache Broadcasting Linux sets up the MMU for cacheable memory to be inner shareable as that supports SMP operation. As modifying the MMU tables from kernel or userspace is not a straightforwards task, the inner cache broadcasting feature can be used to allow inner cacheble transactions be broadcasted. Outside the APU, in the outer domain, the CCI handles coherency across the system. The brdc_inner bit of the lpd_apu register within the LPD_SLCR module must be written while the APU is in reset. The requirement to alter the register while the APU is in reset can be accomplished using the register initialization feature in the boot image. .set. 0xFF41A040 = 0x3; Signed-off-by: Steffen Dirkwinkel --- board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init | 1 + 1 file changed, 1 insertion(+) create mode 100644 board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init diff --git a/board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init b/board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init new file mode 100644 index 00..e7038dd80a --- /dev/null +++ b/board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init @@ -0,0 +1 @@ +0xFF41A040 0x3 \ No newline at end of file -- 2.42.0
[PATCH 3/5] xilinx: zynqmp: move fdt_addr so we can use devices with less memory
From: Steffen Dirkwinkel With the current config we'd put the fdt outside of memory. Signed-off-by: Steffen Dirkwinkel --- include/configs/xilinx_zynqmp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 74264b7bee..334fe95d66 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -50,7 +50,7 @@ #endif #define ENV_MEM_LAYOUT_SETTINGS \ - "fdt_addr_r=0x4000\0" \ + "fdt_addr_r=0x2800\0" \ "fdt_size_r=0x40\0" \ "pxefile_addr_r=0x1000\0" \ "kernel_addr_r=0x1800\0" \ -- 2.42.0
[PATCH 1/5] drivers: rtc: add rv3032 driver
From: Steffen Dirkwinkel Based on linux driver, with these differences: - no support for trickle charger - no support for hwmon - no support for battery backed memory - dm_i2c instead of regmap - different tm_year and tm_mon read/write access the user eeprom. The read and write functions access the user eeprom so it can be used for nvmem-cells. (like in arch/sandbox/dts/test.dts). This is currently different from linux as you'd get nvram using nvmem-cells. I'm hoping to switch the order there too (there are currently no users) or to make a more specific binding. Currently this would also just work as is if used for mac addresses, as u-boot will put these into fdt before booting linux and linux will then prefer the u-boot provided mac. Signed-off-by: Steffen Dirkwinkel --- drivers/rtc/Kconfig | 10 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rv3032.c | 334 +++ 3 files changed, 345 insertions(+) create mode 100644 drivers/rtc/rv3032.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 23173139e0..a41ec9b6cc 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -172,6 +172,16 @@ config RTC_RV3029 This driver supports reading and writing the RTC/calendar and the battery-baced SRAM section. +config RTC_RV3032 + bool "Enable RV3032 driver" + depends on DM_RTC + help + The MicroCrystal RV3032 is a I2C Real Time Clock (RTC) with a 16-byte + battery-backed SRAM and a 32-byte user eeprom. + + This driver supports reading and writing the RTC/calendar and the + user eeprom. + config RTC_RV8803 bool "Enable RV8803 driver" depends on DM_RTC diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 308fab8da9..9c2d8c7aa9 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_RTC_PL031) += pl031.o obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o obj-$(CONFIG_RTC_RV3028) += rv3028.o obj-$(CONFIG_RTC_RV3029) += rv3029.o +obj-$(CONFIG_RTC_RV3032) += rv3032.o obj-$(CONFIG_RTC_RV8803) += rv8803.o obj-$(CONFIG_RTC_RX8025) += rx8025.o obj-$(CONFIG_RTC_RX8010SJ) += rx8010sj.o diff --git a/drivers/rtc/rv3032.c b/drivers/rtc/rv3032.c new file mode 100644 index 00..8d5d860c0a --- /dev/null +++ b/drivers/rtc/rv3032.c @@ -0,0 +1,334 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * RTC driver for the Micro Crystal RV3032 + * + * based on linux driver from + * Copyright (C) 2020 Micro Crystal SA + * + * Alexandre Belloni + * + */ + +#include +#include +#include +#include +#include +#include + +#define RV3032_SEC 0x01 +#define RV3032_MIN 0x02 +#define RV3032_HOUR0x03 +#define RV3032_WDAY0x04 +#define RV3032_DAY 0x05 +#define RV3032_MONTH 0x06 +#define RV3032_YEAR0x07 +#define RV3032_ALARM_MIN 0x08 +#define RV3032_ALARM_HOUR 0x09 +#define RV3032_ALARM_DAY 0x0A +#define RV3032_STATUS 0x0D +#define RV3032_TLSB0x0E +#define RV3032_TMSB0x0F +#define RV3032_CTRL1 0x10 +#define RV3032_CTRL2 0x11 +#define RV3032_CTRL3 0x12 +#define RV3032_TS_CTRL 0x13 +#define RV3032_CLK_IRQ 0x14 +#define RV3032_EEPROM_ADDR 0x3D +#define RV3032_EEPROM_DATA 0x3E +#define RV3032_EEPROM_CMD 0x3F +#define RV3032_RAM10x40 +#define RV3032_PMU 0xC0 +#define RV3032_OFFSET 0xC1 +#define RV3032_CLKOUT1 0xC2 +#define RV3032_CLKOUT2 0xC3 +#define RV3032_TREF0 0xC4 +#define RV3032_TREF1 0xC5 + +#define RV3032_STATUS_VLF BIT(0) +#define RV3032_STATUS_PORF BIT(1) +#define RV3032_STATUS_EVF BIT(2) +#define RV3032_STATUS_AF BIT(3) +#define RV3032_STATUS_TF BIT(4) +#define RV3032_STATUS_UF BIT(5) +#define RV3032_STATUS_TLF BIT(6) +#define RV3032_STATUS_THF BIT(7) + +#define RV3032_TLSB_CLKF BIT(1) +#define RV3032_TLSB_EEBUSY BIT(2) +#define RV3032_TLSB_TEMP GENMASK(7, 4) + +#define RV3032_CLKOUT2_HFD_MSK GENMASK(4, 0) +#define RV3032_CLKOUT2_FD_MSK GENMASK(6, 5) +#define RV3032_CLKOUT2_OS BIT(7) + +#define RV3032_CTRL1_EERD BIT(3) +#define RV3032_CTRL1_WADA BIT(5) + +#define RV3032_CTRL2_STOP BIT(0) +#define RV3032_CTRL2_EIE BIT(2) +#define RV3032_CTRL2_AIE BIT(3) +#define RV3032_CTRL2_TIE BIT(4) +#define RV3032_CTRL2_UIE BIT(5) +#define RV3032_CTRL2_CLKIE BIT(6) +#define RV3032_CTRL2_TSE BIT(7) + +#def
[PATCH 2/5] drivers/usb/dwc3: zynqmp: only free reset gpio if we have one
From: Steffen Dirkwinkel
This gpio is optional so undonditionally freeing it will crash.
Signed-off-by: Steffen Dirkwinkel
---
drivers/usb/dwc3/dwc3-generic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 7f0af05855..dcc342ed04 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -149,7 +149,9 @@ static int dwc3_generic_remove(struct udevice *dev,
priv->ulpi_reset) {
struct gpio_desc *ulpi_reset = priv->ulpi_reset;
- dm_gpio_free(ulpi_reset->dev, ulpi_reset);
+ if (priv->ulpi_reset) {
+ dm_gpio_free(ulpi_reset->dev, ulpi_reset);
+ }
}
dwc3_remove(dwc3);
--
2.42.0
[PATCH 0/5] board: xilinx: zyqmp: add Beckhoff CX8200
From: Steffen Dirkwinkel This adds support for the Beckhoff CX8200 series of industrial embedded PCs. There is some information about the device and features here: https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/cx8200-arm-cortex-a53/ We also add the rtc rv3032 driver from linux, as it is required for mac address loading, fix usb without reset gpios on zynqmp and move the fdt loadaddr to be compatible with less memory. Steffen Dirkwinkel (5): drivers: rtc: add rv3032 driver drivers/usb/dwc3: zynqmp: only free reset gpio if we have one xilinx: zynqmp: move fdt_addr so we can use devices with less memory xilinx: zynqmp: add Beckhoff CX8200 xilinx: zynqmp: beckhoff cx8200: setup inner cache broadcasting arch/arm/dts/Makefile |1 + arch/arm/dts/zynqmp-beckhoff-cx8200.dts | 247 +++ .../zynqmp-beckhoff-cx8200/psu_init_gpl.c | 1960 + .../zynqmp/zynqmp-beckhoff-cx8200/regs.init |1 + configs/xilinx_zynqmp_virt_defconfig |2 +- drivers/rtc/Kconfig | 10 + drivers/rtc/Makefile |1 + drivers/rtc/rv3032.c | 334 +++ drivers/usb/dwc3/dwc3-generic.c |4 +- include/configs/xilinx_zynqmp.h |2 +- 10 files changed, 2559 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/zynqmp-beckhoff-cx8200.dts create mode 100644 board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/psu_init_gpl.c create mode 100644 board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/regs.init create mode 100644 drivers/rtc/rv3032.c -- 2.42.0
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
Simon, why you are contacting me? You have wrote to me that you would
ignore my reviews here, so what you want now? Could you please explain
what you are trying to achieve? I'm not going to review this or any
other your changes.
On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> The PCI helpers read only the base address for a PCI region. In some cases
> the size is needed as well, e.g. to pass along to a driver which needs to
> know the size of its register area.
>
> Update the functions to allow the size to be returned. For serial, record
> the information and provided it with the serial_info() call.
>
> A limitation still exists in that the size is not available when OF_LIVE
> is enabled, so take account of that in the tests.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/sandbox/dts/test.dts | 6 +++---
> drivers/core/fdtaddr.c | 6 +++---
> drivers/core/ofnode.c | 11 ---
> drivers/core/read.c | 6 --
> drivers/core/util.c | 2 +-
> drivers/pci/pci-uclass.c| 2 +-
> drivers/pci/pci_mvebu.c | 3 ++-
> drivers/pci/pci_tegra.c | 2 +-
> drivers/pci/pcie_mediatek.c | 4 ++--
> drivers/serial/ns16550.c| 15 ++-
> include/dm/fdtaddr.h| 3 ++-
> include/dm/ofnode.h | 4 +++-
> include/dm/read.h | 8 +---
> include/ns16550.h | 4 +++-
> include/serial.h| 2 ++
> test/dm/pci.c | 14 ++
> 16 files changed, 60 insertions(+), 32 deletions(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index a413cbe4989..961e8895a49 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1087,8 +1087,8 @@
> pci@1,0 {
> compatible = "pci-generic";
> /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
> - reg = <0x02000814 0 0 0 0
> -0x01000810 0 0 0 0>;
> + reg = <0x02000814 0 0 0x80 0
> +0x01000810 0 0 0xc0 0>;
> sandbox,emul = <&swap_case_emul0_1>;
> };
> p2sb-pci@2,0 {
> @@ -1115,7 +1115,7 @@
> pci@1f,0 {
> compatible = "pci-generic";
> /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> - reg = <0x0100f810 0 0 0 0>;
> + reg = <0x0100f810 0 0 0x100 0>;
> sandbox,emul = <&swap_case_emul0_1f>;
> };
> };
> diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> index 546db675aaf..b79d138c419 100644
> --- a/drivers/core/fdtaddr.c
> +++ b/drivers/core/fdtaddr.c
> @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
> unsigned long size)
> return map_physmem(addr, size, MAP_NOCACHE);
> }
>
> -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t *sizep)
> {
> ulong addr;
>
> @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct udevice
> *dev)
> int ret;
>
> ret = ofnode_read_pci_addr(dev_ofnode(dev), FDT_PCI_SPACE_MEM32,
> -"reg", &pci_addr);
> +"reg", &pci_addr, sizep);
> if (ret) {
> /* try if there is any i/o-mapped register */
> ret = ofnode_read_pci_addr(dev_ofnode(dev),
> FDT_PCI_SPACE_IO, "reg",
> -&pci_addr);
> +&pci_addr, sizep);
> if (ret)
> return FDT_ADDR_T_NONE;
> }
> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> index 2ef4114cb6f..c9cec456f43 100644
> --- a/drivers/core/ofnode.c
> +++ b/drivers/core/ofnode.c
> @@ -1270,7 +1270,8 @@ const uint8_t *ofnode_read_u8_array_ptr(ofnode node,
> const char *propname,
> }
>
> int ofnode_read_pci_addr(ofnode node, enum fdt_pci_space type,
> - const char *propname, struct fdt_pci_addr *addr)
> + const char *propname, struct fdt_pci_addr *addr,
> + fdt_size_t *size)
> {
> const fdt32_t *cell;
> int len;
> @@ -1298,14 +1299,18 @@ int ofnode_read_pci_addr(ofnode node, enum
> fdt_pci_space type,
> (ulong)fdt32_to_cpu(cell[1]),
> (ulong)fdt32_to_cpu(cell[2]));
> if ((fdt32_to_cpu(*cell) & type) == type) {
> + const unaligned_fdt64_t *ptr;
> +
> addr->phys_hi = fdt32_to_cpu(cell[0]);
> addr->phys_mid = fdt32_to_cpu(cell[1]);
> addr->phys_lo =
[PATCH 32/32] pci: serial: Support reading PCI-register size with base
The PCI helpers read only the base address for a PCI region. In some cases
the size is needed as well, e.g. to pass along to a driver which needs to
know the size of its register area.
Update the functions to allow the size to be returned. For serial, record
the information and provided it with the serial_info() call.
A limitation still exists in that the size is not available when OF_LIVE
is enabled, so take account of that in the tests.
Signed-off-by: Simon Glass
---
arch/sandbox/dts/test.dts | 6 +++---
drivers/core/fdtaddr.c | 6 +++---
drivers/core/ofnode.c | 11 ---
drivers/core/read.c | 6 --
drivers/core/util.c | 2 +-
drivers/pci/pci-uclass.c| 2 +-
drivers/pci/pci_mvebu.c | 3 ++-
drivers/pci/pci_tegra.c | 2 +-
drivers/pci/pcie_mediatek.c | 4 ++--
drivers/serial/ns16550.c| 15 ++-
include/dm/fdtaddr.h| 3 ++-
include/dm/ofnode.h | 4 +++-
include/dm/read.h | 8 +---
include/ns16550.h | 4 +++-
include/serial.h| 2 ++
test/dm/pci.c | 14 ++
16 files changed, 60 insertions(+), 32 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index a413cbe4989..961e8895a49 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1087,8 +1087,8 @@
pci@1,0 {
compatible = "pci-generic";
/* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
- reg = <0x02000814 0 0 0 0
- 0x01000810 0 0 0 0>;
+ reg = <0x02000814 0 0 0x80 0
+ 0x01000810 0 0 0xc0 0>;
sandbox,emul = <&swap_case_emul0_1>;
};
p2sb-pci@2,0 {
@@ -1115,7 +1115,7 @@
pci@1f,0 {
compatible = "pci-generic";
/* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
- reg = <0x0100f810 0 0 0 0>;
+ reg = <0x0100f810 0 0 0x100 0>;
sandbox,emul = <&swap_case_emul0_1f>;
};
};
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 546db675aaf..b79d138c419 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
unsigned long size)
return map_physmem(addr, size, MAP_NOCACHE);
}
-fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
+fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t *sizep)
{
ulong addr;
@@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
int ret;
ret = ofnode_read_pci_addr(dev_ofnode(dev), FDT_PCI_SPACE_MEM32,
- "reg", &pci_addr);
+ "reg", &pci_addr, sizep);
if (ret) {
/* try if there is any i/o-mapped register */
ret = ofnode_read_pci_addr(dev_ofnode(dev),
FDT_PCI_SPACE_IO, "reg",
- &pci_addr);
+ &pci_addr, sizep);
if (ret)
return FDT_ADDR_T_NONE;
}
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 2ef4114cb6f..c9cec456f43 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -1270,7 +1270,8 @@ const uint8_t *ofnode_read_u8_array_ptr(ofnode node,
const char *propname,
}
int ofnode_read_pci_addr(ofnode node, enum fdt_pci_space type,
-const char *propname, struct fdt_pci_addr *addr)
+const char *propname, struct fdt_pci_addr *addr,
+fdt_size_t *size)
{
const fdt32_t *cell;
int len;
@@ -1298,14 +1299,18 @@ int ofnode_read_pci_addr(ofnode node, enum
fdt_pci_space type,
(ulong)fdt32_to_cpu(cell[1]),
(ulong)fdt32_to_cpu(cell[2]));
if ((fdt32_to_cpu(*cell) & type) == type) {
+ const unaligned_fdt64_t *ptr;
+
addr->phys_hi = fdt32_to_cpu(cell[0]);
addr->phys_mid = fdt32_to_cpu(cell[1]);
addr->phys_lo = fdt32_to_cpu(cell[2]);
+ ptr = (const unaligned_fdt64_t *)(cell + 3);
+ if (size)
+ *size = fdt64_to_cpu(*ptr);
break;
}
- cell += (FDT_PCI_ADDR_CELLS +
-FDT_PCI_SIZE_CELLS);
+ cell +=
[PATCH 31/32] command: Include a required header in command.h
This uses ARRAY_SIZE() but does not include the header file which declares it. Fix this, so that command.h can be included without common.h Signed-off-by: Simon Glass --- include/command.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/command.h b/include/command.h index c4e3170967d..7a0ab8c90b1 100644 --- a/include/command.h +++ b/include/command.h @@ -15,6 +15,9 @@ #include +/* For ARRAY_SIZE() */ +#include + #ifndef NULL #define NULL 0 #endif -- 2.42.0.rc2.253.gd59a3bf2b4-goog
