Re: [PATCHv7 00/15] net/lwip: add lwip library for the network stack
On 9/7/23 21:23, Tom Rini wrote: On Thu, Sep 07, 2023 at 05:21:18PM +0200, Michal Simek wrote: Hi, út 22. 8. 2023 v 11:38 odesílatel Maxim Uvarov napsal: Hello, I'm sending v7, with all v6 comments getting fixed. The only thing left is a pointer to timeout callback which 2 applications use. I will rework this timeout in next v8. I started take a look at it, and want to fix this together with background applications support in v8. changelog: v7: - more review fixes. - support of multiply eth devices, were "ethact" selects the active device. v6: - fixed review comments for v5 (thanks Ilias and Simon). - lwip is not under /net, so prior applying patch following commit is needed to create lwIP merge into U-Boot: git subtree add --prefix net/lwip/lwip-external https://git.savannah.nongnu.org/git/lwip.git master --squash I think you should integrate it via .gitmodules as is done for example in qemu. I _think_ I am leaning towards subtree, but it sounds like we need to make the initial build easier, perhaps some Makefile logic to see we haven't added, and then do what's needed? Definitely it has to solved without any manual step. And this is enabled by default for all platforms. I pretty much think that it should be disabled now and when tested properly it can become default y. Thanks, Michal
Re: [PATCH v2 4/7] drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up
Hi Manorit On 08/09/23 10:47, Manorit Chawdhry wrote: Hi Neha, On 09:04-20230908, Neha Malcom Francis wrote: Hi Nishanth On 07/09/23 20:35, Nishanth Menon wrote: On 19:44-20230907, Neha Malcom Francis wrote: While setting up necessary dependent clocks and power domains, we end up probing the ti_sci driver before TIFS/SYSFW has been loaded in the case of legacy boot flow devices. This leads to panic when getting the SCI revision. Return the revision only if it is combined boot flow. Also Not clear description of the problem. Hmm okay I will modify this and the earlier commit message to give a clearer picture. I still don't understand why we are coming to the TISCI driver to contact M4/DM for setting up the power domains and clocks, if this would have been the case then even the normal J721E wouldn't have been working and it shouldn't have been dependent on the DT Sync to uncover this issue. Could you elaborate more w.r.t this patch? We were using /delete-property/ to remove every instance of k3_clks and k3_pds before TIFS/SYSFW came up so it was never probing the TISCI driver. From what I understand is that even if we end up coming here, we shouldn't be hitting the panic as the previous patch sets up the necessary clock (mcu_timer0) and at the worst - we would just end up polling to get a response and if we don't, we would fail and we shouldn't be getting a panic. I believe this is how the J721E would've So earlier we never reached here because of above mentioned reason, now we do with the last patch. While probing ti_sci we invoke ti_sci_cmd_get_revision that returns -61 (ENODATA) and we reach panic like this: get_timer --> get_ticks --> dm_timer_init (tries to get timer, fails for above reason) --> panic been working before the sync but am not sure what is breaking after the sync. Maybe this helps in uncovering the real issue that we still have, I believe we should still be looking at why the timer is failing and causing this probe to fail. Regards, Manorit ensure that after TIFS/SYSFW comes up we run ti_sci_cmd_get_revision again so we print the revision right. Signed-off-by: Neha Malcom Francis --- drivers/firmware/ti_sci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index 72f572d824..6a85d202f2 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -2703,6 +2703,9 @@ struct ti_sci_handle *ti_sci_get_handle_from_sysfw(struct udevice *sci_dev) if (!handle) return ERR_PTR(-EINVAL); + /* May have been skipped in case TIFS/SYSFW had come up later */ Very confusing comment. Understood, will change that. + ti_sci_cmd_get_revision(handle); should this be protected with if (IS_ENABLED(CONFIG_K3_DM_FW) ? Since getting the handle is where the entire flow happens, why not do it here always? This is a valid point, I am in the process of making sure there's no other consequences to getting the revision this late for platforms with other boot devices, if this gets an all clear, I will push it here for the next version, else I will explain why I couldn't. what if ti_sci_cmd_get_revision fails? there is no error handling here. Yes that would be a consequence since ti_sci_probe, the logic it was written; used reading the version as an "all okay return 0" for the TIFS/SYSFW binary. But now after moving, ti_sci_get_handle_from_sysfw happens after k3_sysfw_loader so we're not checking binary sanity early on in the case of combined boot I'm hesitant that we are checking version way later after k3_sysfw_loader for combined platforms and if that is something we want? But there is an advantage(?) that it will run every time someone tries to get a handle for doing anything with TISCI and that would be a kind of check (?) if the binary is good? Correct me if I'm wrong in thinking that. + return handle; } @@ -2825,7 +2828,11 @@ static int ti_sci_probe(struct udevice *dev) list_add_tail(&info->list, &ti_sci_list); ti_sci_setup_ops(info); - ret = ti_sci_cmd_get_revision(&info->handle); + /* Get SCI revision ONLY if we are real */ + if (!IS_ENABLED(CONFIG_K3_DM_FW)) + ret = ti_sci_cmd_get_revision(&info->handle); + else + ret = 0; INIT_LIST_HEAD(&info->dev_list); -- 2.34.1 -- Thanking You Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v2 4/7] drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up
Hi Neha, On 09:04-20230908, Neha Malcom Francis wrote: > Hi Nishanth > > On 07/09/23 20:35, Nishanth Menon wrote: > > On 19:44-20230907, Neha Malcom Francis wrote: > > > While setting up necessary dependent clocks and power domains, we end up > > > probing the ti_sci driver before TIFS/SYSFW has been loaded in the case > > > of legacy boot flow devices. This leads to panic when getting the SCI > > > revision. Return the revision only if it is combined boot flow. Also > > > > Not clear description of the problem. > > Hmm okay I will modify this and the earlier commit message to give a clearer > picture. > I still don't understand why we are coming to the TISCI driver to contact M4/DM for setting up the power domains and clocks, if this would have been the case then even the normal J721E wouldn't have been working and it shouldn't have been dependent on the DT Sync to uncover this issue. Could you elaborate more w.r.t this patch? >From what I understand is that even if we end up coming here, we shouldn't be hitting the panic as the previous patch sets up the necessary clock (mcu_timer0) and at the worst - we would just end up polling to get a response and if we don't, we would fail and we shouldn't be getting a panic. I believe this is how the J721E would've been working before the sync but am not sure what is breaking after the sync. Maybe this helps in uncovering the real issue that we still have, I believe we should still be looking at why the timer is failing and causing this probe to fail. Regards, Manorit > > > > > ensure that after TIFS/SYSFW comes up we run ti_sci_cmd_get_revision > > > again so we print the revision right. > > > > > > Signed-off-by: Neha Malcom Francis > > > --- > > > drivers/firmware/ti_sci.c | 9 - > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c > > > index 72f572d824..6a85d202f2 100644 > > > --- a/drivers/firmware/ti_sci.c > > > +++ b/drivers/firmware/ti_sci.c > > > @@ -2703,6 +2703,9 @@ struct ti_sci_handle > > > *ti_sci_get_handle_from_sysfw(struct udevice *sci_dev) > > > if (!handle) > > > return ERR_PTR(-EINVAL); > > > + /* May have been skipped in case TIFS/SYSFW had come up later */ > > Very confusing comment. > > > > Understood, will change that. > > > > + ti_sci_cmd_get_revision(handle); > > > > should this be protected with if (IS_ENABLED(CONFIG_K3_DM_FW) ? > > > > Since getting the handle is where the entire flow happens, why not do it > > here always? > > > > This is a valid point, I am in the process of making sure there's no other > consequences to getting the revision this late for platforms with other boot > devices, if this gets an all clear, I will push it here for the next > version, else I will explain why I couldn't. > > > what if ti_sci_cmd_get_revision fails? there is no error handling here. > > Yes that would be a consequence since ti_sci_probe, the logic it was > written; used reading the version as an "all okay return 0" for the > TIFS/SYSFW binary. > > But now after moving, ti_sci_get_handle_from_sysfw happens after > k3_sysfw_loader so we're not checking binary sanity early on in the case of > combined boot > > I'm hesitant that we are checking version way later after k3_sysfw_loader > for combined platforms and if that is something we want? But there is an > advantage(?) that it will run every time someone tries to get a handle for > doing anything with TISCI and that would be a kind of check (?) if the > binary is good? Correct me if I'm wrong in thinking that. > > > > + > > > return handle; > > > } > > > @@ -2825,7 +2828,11 @@ static int ti_sci_probe(struct udevice *dev) > > > list_add_tail(&info->list, &ti_sci_list); > > > ti_sci_setup_ops(info); > > > - ret = ti_sci_cmd_get_revision(&info->handle); > > > + /* Get SCI revision ONLY if we are real */ > > > + if (!IS_ENABLED(CONFIG_K3_DM_FW)) > > > + ret = ti_sci_cmd_get_revision(&info->handle); > > > + else > > > + ret = 0; > > > INIT_LIST_HEAD(&info->dev_list); > > > -- > > > 2.34.1 > > > > > > > -- > Thanking You > Neha Malcom Francis
Re: [RFC 4/6] gpio: add scmi driver based on pinctrl
Hi Simon,
On Thu, Sep 07, 2023 at 06:23:05AM -0600, Simon Glass wrote:
> Hi AKASHI,
>
> On Tue, 5 Sept 2023 at 20:41, AKASHI Takahiro
> wrote:
> >
> > This DM-compliant driver deals with SCMI pinctrl protocol and presents
> > gpio devices exposed by SCMI firmware (server).
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > drivers/pinctrl/pinctrl-scmi.c | 544 -
> > 1 file changed, 539 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
> > index 3ebdad57b86c..73d385bdbfcc 100644
> > --- a/drivers/pinctrl/pinctrl-scmi.c
> > +++ b/drivers/pinctrl/pinctrl-scmi.c
> > @@ -11,21 +11,20 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > +#include
> > #include
> >
> [..]
>
> > +
> > +U_BOOT_DRIVER(scmi_gpio) = {
> > + .name = "scmi_gpio",
> > + .id = UCLASS_GPIO,
> > + .of_match = scmi_gpio_ids,
> > + .of_to_plat = scmi_gpio_probe,
> > + .ops = &scmi_gpio_ops,
> > + .plat_auto = sizeof(struct scmi_pinctrl_gpio_plat),
> > +};
> > +
> > +/**
> > + * scmi_gpiochip_register - Create a pinctrl-controlled gpio device
> > + * @parent:SCMI pinctrl device
> > + *
> > + * Create a pinctrl-controlled gpio device
> > + *
> > + * Return: 0 on success, error code on failure
> > + */
> > +static int scmi_gpiochip_register(struct udevice *parent)
> > +{
> > + ofnode node;
> > + struct driver *drv;
> > + struct udevice *gpio_dev;
> > + int ret;
> > +
> > + /* TODO: recovery if failed */
> > + dev_for_each_subnode(node, parent) {
> > + if (!ofnode_is_enabled(node))
> > + continue;
>
> Can we not rely on the normal driver model binding to bind these
> devices? Why does it need to be done manually here?
First, please take a look at the cover letter.
In this RFC, I basically assume two patterns of DT bindings,
(A) and (B) in the cover letter (or sandbox's test.dts in patch#5).
In (B), a DT node as a gpio device, which is essentially a child
of pinctrl device, is located *under* a pinctrl device. It need
to be probed manually as there is no implicit method to enumerate
it as a DM device automatically.
On the other hand, in (A), the same node can be put anywhere in a DT
as it contains a "compatible" property to identify itself.
So if we want to only support (A), scmi_gpiochip_register() and
scmi_pinctrl_bind() are not necessary.
Since there is no discussion about bindings for GPIO managed by SCMI
pinctrl device yet on the kernel side, I have left two solutions
in this RFC.
Thanks,
-Takakahiro Akashi
> > +
> > + if (!ofnode_read_prop(node, "gpio-controller", NULL))
> > + /* not a GPIO node */
> > + continue;
> > +
> > + drv = DM_DRIVER_GET(scmi_gpio);
> > + if (!drv) {
> > + dev_err(parent, "No gpio driver?\n");
> > + return -ENODEV;
> > + }
> > +
> > + ret = device_bind(parent, drv, ofnode_get_name(node), NULL,
> > + node, &gpio_dev);
> > + if (ret) {
> > + dev_err(parent, "failed to bind %s to gpio (%d)\n",
> > + ofnode_get_name(node), ret);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > + }
> > +
> > + return -ENODEV;
> > +}
> > +
>
> Regards,
> Simon
Re: [PATCH v2 5/7] configs: j721e: Remove HBMC_AM654 config
Hi Nishanth
On 07/09/23 20:37, Nishanth Menon wrote:
On 19:44-20230907, Neha Malcom Francis wrote:
Remove config as kernel commit d93036b47f35 ("arm64: dts: ti:
k3-j721e-mcu-wakeup: Add HyperBus node") is impacting boot. Its
dependent patch [1] has not yet been merged to kernel, similar fix will
be needed in U-Boot.
[1] https://lore.kernel.org/all/20230424184810.29453-1-...@ti.com/
So, fix the kernel, why do this in u-boot? The rationale in the commit
message should clearly state why we do in u-boot.
Will explain better in the commit message.
Signed-off-by: Neha Malcom Francis
---
configs/j721e_evm_a72_defconfig | 1 -
configs/j721e_evm_r5_defconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 214fa8b2f3..beea948c4e 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -140,7 +140,6 @@ CONFIG_CFI_FLASH=y
CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index cf7bc872b5..d974be275f 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -127,7 +127,6 @@ CONFIG_CFI_FLASH=y
CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_STMICRO=y
--
2.34.1
--
Thanking You
Neha Malcom Francis
Re: [PATCH v2 4/7] drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up
Hi Nishanth On 07/09/23 20:35, Nishanth Menon wrote: On 19:44-20230907, Neha Malcom Francis wrote: While setting up necessary dependent clocks and power domains, we end up probing the ti_sci driver before TIFS/SYSFW has been loaded in the case of legacy boot flow devices. This leads to panic when getting the SCI revision. Return the revision only if it is combined boot flow. Also Not clear description of the problem. Hmm okay I will modify this and the earlier commit message to give a clearer picture. ensure that after TIFS/SYSFW comes up we run ti_sci_cmd_get_revision again so we print the revision right. Signed-off-by: Neha Malcom Francis --- drivers/firmware/ti_sci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c index 72f572d824..6a85d202f2 100644 --- a/drivers/firmware/ti_sci.c +++ b/drivers/firmware/ti_sci.c @@ -2703,6 +2703,9 @@ struct ti_sci_handle *ti_sci_get_handle_from_sysfw(struct udevice *sci_dev) if (!handle) return ERR_PTR(-EINVAL); + /* May have been skipped in case TIFS/SYSFW had come up later */ Very confusing comment. Understood, will change that. + ti_sci_cmd_get_revision(handle); should this be protected with if (IS_ENABLED(CONFIG_K3_DM_FW) ? Since getting the handle is where the entire flow happens, why not do it here always? This is a valid point, I am in the process of making sure there's no other consequences to getting the revision this late for platforms with other boot devices, if this gets an all clear, I will push it here for the next version, else I will explain why I couldn't. what if ti_sci_cmd_get_revision fails? there is no error handling here. Yes that would be a consequence since ti_sci_probe, the logic it was written; used reading the version as an "all okay return 0" for the TIFS/SYSFW binary. But now after moving, ti_sci_get_handle_from_sysfw happens after k3_sysfw_loader so we're not checking binary sanity early on in the case of combined boot I'm hesitant that we are checking version way later after k3_sysfw_loader for combined platforms and if that is something we want? But there is an advantage(?) that it will run every time someone tries to get a handle for doing anything with TISCI and that would be a kind of check (?) if the binary is good? Correct me if I'm wrong in thinking that. + return handle; } @@ -2825,7 +2828,11 @@ static int ti_sci_probe(struct udevice *dev) list_add_tail(&info->list, &ti_sci_list); ti_sci_setup_ops(info); - ret = ti_sci_cmd_get_revision(&info->handle); + /* Get SCI revision ONLY if we are real */ + if (!IS_ENABLED(CONFIG_K3_DM_FW)) + ret = ti_sci_cmd_get_revision(&info->handle); + else + ret = 0; INIT_LIST_HEAD(&info->dev_list); -- 2.34.1 -- Thanking You Neha Malcom Francis
Re: [PATCH v2 3/7] arm: mach-k3: j721e_init: Move clk_k3 probe before loading TIFS
Hi Nishanth
On 07/09/23 20:33, Nishanth Menon wrote:
On 19:44-20230907, Neha Malcom Francis wrote:
Since we need to configure required clocks before TIFS is loaded, move
clk_k3 driver probe before k3_sysfw_loader.
This needs further elaboration. what kind of clocks are we talking
about? what is the call sequence that is involved that this is solving?
When setting up our boot media to take in the TIFS binary (sysfw.itb) in legacy
boot flow (followed by J721E) what we end up doing is a get_timer() which by
call stack will eventually call dm_timer_init() and then get our "tick-timer" in
our case mcu_timer0. Now mcu_timer0 uses k3_clks (clock-controller) and k3_pds
(power controller) from the dmsc node that forces probe of the ti_sci driver
(for TIFS that hasn't been loaded yet!).
So we have two issues that need to be solved here, one of not having set the
required devices and clocks before we even stat to probe their dependent
devices, and two of handling how ti_sci reacts when TIFS is not even up yet.
This patch solves the former.
Would this be excessive detailing for a commit message?
Signed-off-by: Neha Malcom Francis
---
arch/arm/mach-k3/j721e_init.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b6164575b7..b1f7e25ed0 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -228,6 +228,18 @@ void board_init_f(ulong dummy)
if (!ret)
pinctrl_select_state(dev, "default");
+ /*
+* Force probe of clk_k3 driver here to ensure basic default clock
+* configuration is always done.
+*/
+ if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
+ ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(ti_clk),
+ &dev);
+ if (ret)
+ panic("Failed to initialize clk-k3!\n");
+ }
+
/*
* Load, start up, and configure system controller firmware. Provide
* the U-Boot console init function to the SYSFW post-PM configuration
@@ -241,18 +253,6 @@ void board_init_f(ulong dummy)
do_dt_magic();
#endif
- /*
-* Force probe of clk_k3 driver here to ensure basic default clock
-* configuration is always done.
-*/
- if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
- ret = uclass_get_device_by_driver(UCLASS_CLK,
- DM_DRIVER_GET(ti_clk),
- &dev);
- if (ret)
- panic("Failed to initialize clk-k3!\n");
- }
-
/* Prepare console output */
preloader_console_init();
--
2.34.1
--
Thanking You
Neha Malcom Francis
Re: [PATCH v2 1/7] drivers: misc: k3_avs: Add linux compatible to maintain sync
Hi Reid
On 07/09/23 23:39, reidt wrote:
On 10:08-20230907, Nishanth Menon wrote:
On 19:44-20230907, Neha Malcom Francis wrote:
The U-Boot AVS driver works on the VTM (Voltage and Thermal Management)
module, also used by the Linux TI Bandgap temperature sensor driver
(drivers/thermal/k3_j72xx_bandgap.c). Although the purpose and
functionalities that these two implement are different, the hardware is
the same, so ensure that their compatibles are in sync. Thus, add
ti,j721e-vtm compatible to the AVS driver.
Signed-off-by: Neha Malcom Francis
---
drivers/misc/k3_avs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 840148d090..3008cf9810 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -382,6 +382,7 @@ static struct vd_config am654_vd_config = {
static const struct udevice_id k3_avs_ids[] = {
{ .compatible = "ti,am654-avs", .data = (ulong)&am654_vd_config },
{ .compatible = "ti,j721e-avs", .data = (ulong)&j721e_vd_config },
+ { .compatible = "ti,j721e-vtm", .data = (ulong)&j721e_vd_config },
{}
};
--
2.34.1
https://lore.kernel.org/all/52a7c0b2-7a87-c74e-e63f-d07821ffc...@ti.com/
we are going to end up creating a dependency nightmare.
Can we just do a single series(might be just a single patch) for
compatible additions for k3_avs.c and make the dts syncs dependent on this?
I submitted one here if this works:
https://lore.kernel.org/u-boot/20230907180635.89011-1-re...@ti.com/T/#u
-Reid
Thanks for sending the patch! I'll omit this patch from the next version.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
--
Thanking You
Neha Malcom Francis
[PATCH v3 13/13] test: dm: add scmi command test
In this test, "scmi" command is tested against different sub-commands.
Please note that scmi command is for debug purpose and is not intended
in production system.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
v3
* change char to u8 in vendor/agent names
v2
* use helper functions, removing direct uses of ops
---
test/dm/scmi.c | 62 ++
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/test/dm/scmi.c b/test/dm/scmi.c
index 0785948186f0..423b6ef70b29 100644
--- a/test/dm/scmi.c
+++ b/test/dm/scmi.c
@@ -104,8 +104,7 @@ static int dm_test_scmi_base(struct unit_test_state *uts)
struct scmi_agent_priv *priv;
u32 version, num_agents, num_protocols, impl_version;
u32 attributes, agent_id;
- char *vendor, *agent_name;
- u8 *protocols;
+ u8 *vendor, *agent_name, *protocols;
int ret;
/* preparation */
@@ -134,9 +133,9 @@ static int dm_test_scmi_base(struct unit_test_state *uts)
free(vendor);
/* message attributes */
- ret = scmi_protocol_message_attrs(base,
- SCMI_BASE_DISCOVER_SUB_VENDOR,
- &attributes);
+ ret = scmi_base_protocol_message_attrs(base,
+ SCMI_BASE_DISCOVER_SUB_VENDOR,
+ &attributes);
ut_assertok(ret);
ut_assertok(attributes);
@@ -207,6 +206,59 @@ static int dm_test_scmi_base(struct unit_test_state *uts)
DM_TEST(dm_test_scmi_base, UT_TESTF_SCAN_FDT);
+static int dm_test_scmi_cmd(struct unit_test_state *uts)
+{
+ struct udevice *agent_dev;
+
+ /* preparation */
+ ut_assertok(uclass_get_device_by_name(UCLASS_SCMI_AGENT, "scmi",
+ &agent_dev));
+ ut_assertnonnull(agent_dev);
+
+ /* scmi info */
+ ut_assertok(run_command("scmi info", 0));
+
+ ut_assert_nextline("SCMI device: scmi");
+ ut_assert_nextline(" protocol version: 0x2");
+ ut_assert_nextline(" # of agents: 2");
+ ut_assert_nextline(" 0: platform");
+ ut_assert_nextline("> 1: OSPM");
+ ut_assert_nextline(" # of protocols: 3");
+ ut_assert_nextline(" Clock management");
+ ut_assert_nextline(" Reset domain management");
+ ut_assert_nextline(" Voltage domain management");
+ ut_assert_nextline(" vendor: U-Boot");
+ ut_assert_nextline(" sub vendor: Sandbox");
+ ut_assert_nextline(" impl version: 0x1");
+
+ ut_assert_console_end();
+
+ /* scmi perm_dev */
+ ut_assertok(run_command("scmi perm_dev 1 0 1", 0));
+ ut_assert_console_end();
+
+ ut_assert(run_command("scmi perm_dev 1 0 0", 0));
+ ut_assert_nextline("Denying access to device:0 failed (-13)");
+ ut_assert_console_end();
+
+ /* scmi perm_proto */
+ ut_assertok(run_command("scmi perm_proto 1 0 14 1", 0));
+ ut_assert_console_end();
+
+ ut_assert(run_command("scmi perm_proto 1 0 14 0", 0));
+ ut_assert_nextline("Denying access to protocol:0x14 on device:0 failed
(-13)");
+ ut_assert_console_end();
+
+ /* scmi reset */
+ ut_assert(run_command("scmi reset 1 1", 0));
+ ut_assert_nextline("Reset failed (-13)");
+ ut_assert_console_end();
+
+ return 0;
+}
+
+DM_TEST(dm_test_scmi_cmd, UT_TESTF_SCAN_FDT);
+
static int dm_test_scmi_clocks(struct unit_test_state *uts)
{
struct sandbox_scmi_agent *agent;
--
2.34.1
[PATCH v3 12/13] doc: cmd: add documentation for scmi
This is a help text for scmi command. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass Reviewed-by: Etienne Carriere --- v2 * add more descriptions about SCMI --- doc/usage/cmd/scmi.rst | 126 + 1 file changed, 126 insertions(+) create mode 100644 doc/usage/cmd/scmi.rst diff --git a/doc/usage/cmd/scmi.rst b/doc/usage/cmd/scmi.rst new file mode 100644 index ..aebcfe95101d --- /dev/null +++ b/doc/usage/cmd/scmi.rst @@ -0,0 +1,126 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +scmi command + + +Synopsis + + +:: + +scmi info +scmi perm_dev +scmi perm_proto +scmi reset + +Description +--- + +Arm System Control and Management Interface (SCMI hereafter) is a set of +standardised interfaces to manage system resources, like clocks, power +domains, pin controls, reset and so on, in a system-wide manner. + +An entity which provides those services is called a SCMI firmware (or +SCMI server if you like) may be placed/implemented by EL3 software or +by a dedicated system control processor (SCP) or else. + +A user of SCMI interfaces, including U-Boot, is called a SCMI agent and +may issues commands, which are defined in each protocol for specific system +resources, to SCMI server via a communication channel, called a transport. +Those interfaces are independent from the server's implementation thanks to +a tranport layer. + +For more details, see the `SCMI specification`_. + +While most of system resources managed under SCMI protocols are implemented +and handled as standard U-Boot devices, for example clk_scmi, scmi command +provides additional management functionality against SCMI server. + +scmi info +~ +Show base information about SCMI server and supported protocols + +scmi perm_dev +~ +Allow or deny access permission to the device + +scmi perm_proto +~~~ +Allow or deny access to the protocol on the device + +scmi reset +~~ +Reset the already-configured permissions against the device + +Parameters are used as follows: + + +SCMI Agent ID, hex value + + +SCMI Device ID, hex value + +Please note that what a device means is not defined +in the specification. + + +SCMI Protocol ID, hex value + +It must not be 0x10 (base protocol) + + +Flags to control the action, hex value + +0 to deny, 1 to allow. The other values are reserved and allowed +values may depend on the implemented version of SCMI server in +the future. See SCMI specification for more details. + +Example +--- + +Obtain basic information about SCMI server: + +:: + +=> scmi info +SCMI device: scmi + protocol version: 0x2 + # of agents: 3 + 0: platform +> 1: OSPM + 2: PSCI + # of protocols: 4 + Power domain management + Performance domain management + Clock management + Sensor management + vendor: Linaro + sub vendor: PMWG + impl version: 0x20b + +Ask for access permission to device#0: + +:: + +=> scmi perm_dev 1 0 1 + +Reset configurations with all access permission settings retained: + +:: + +=> scmi reset 1 0 + +Configuration +- + +The scmi command is only available if CONFIG_CMD_SCMI=y. +Default n because this command is mainly for debug purpose. + +Return value + + +The return value ($?) is set to 0 if the operation succeeded, +1 if the operation failed or -1 if the operation failed due to +a syntax error. + +.. _`SCMI specification`: https://developer.arm.com/documentation/den0056/e/?lang=en -- 2.34.1
[PATCH v3 11/13] cmd: add scmi command for SCMI firmware
This command, "scmi", may provide a command line interface to various SCMI
protocols. It supports at least initially SCMI base protocol and is
intended mainly for debug purpose.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
v3
* describe that arguments are in hex at a help message
* modify the code for dynamically allocated agent names
v2
* remove sub command category, 'scmi base', for simplicity
---
cmd/Kconfig | 9 ++
cmd/Makefile | 1 +
cmd/scmi.c | 337 +++
3 files changed, 347 insertions(+)
create mode 100644 cmd/scmi.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 43ca10f69ccf..f46152ace7d8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2533,6 +2533,15 @@ config CMD_CROS_EC
a number of sub-commands for performing EC tasks such as
updating its flash, accessing a small saved context area
and talking to the I2C bus behind the EC (if there is one).
+
+config CMD_SCMI
+ bool "Enable scmi command"
+ depends on SCMI_FIRMWARE
+ default n
+ help
+ This command provides user interfaces to several SCMI (System
+ Control and Management Interface) protocols available on Arm
+ platforms to manage system resources.
endmenu
menu "Filesystem commands"
diff --git a/cmd/Makefile b/cmd/Makefile
index 9bebf321c397..ad3810b17e93 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_CMD_SATA) += sata.o
obj-$(CONFIG_CMD_NVME) += nvme.o
obj-$(CONFIG_SANDBOX) += sb.o
obj-$(CONFIG_CMD_SF) += sf.o
+obj-$(CONFIG_CMD_SCMI) += scmi.o
obj-$(CONFIG_CMD_SCSI) += scsi.o disk.o
obj-$(CONFIG_CMD_SHA1SUM) += sha1sum.o
obj-$(CONFIG_CMD_SEAMA) += seama.o
diff --git a/cmd/scmi.c b/cmd/scmi.c
new file mode 100644
index ..5efec8ad87fd
--- /dev/null
+++ b/cmd/scmi.c
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SCMI (System Control and Management Interface) utility command
+ *
+ * Copyright (c) 2023 Linaro Limited
+ * Author: AKASHI Takahiro
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include /* uclass_get_device */
+#include
+#include
+
+static struct udevice *agent;
+static struct udevice *base_proto;
+
+struct {
+ enum scmi_std_protocol id;
+ const char *name;
+} protocol_name[] = {
+ {SCMI_PROTOCOL_ID_BASE, "Base"},
+ {SCMI_PROTOCOL_ID_POWER_DOMAIN, "Power domain management"},
+ {SCMI_PROTOCOL_ID_SYSTEM, "System power management"},
+ {SCMI_PROTOCOL_ID_PERF, "Performance domain management"},
+ {SCMI_PROTOCOL_ID_CLOCK, "Clock management"},
+ {SCMI_PROTOCOL_ID_SENSOR, "Sensor management"},
+ {SCMI_PROTOCOL_ID_RESET_DOMAIN, "Reset domain management"},
+ {SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN, "Voltage domain management"},
+};
+
+/**
+ * get_proto_name() - get the name of SCMI protocol
+ *
+ * @id:SCMI Protocol ID
+ *
+ * Get the printable name of the protocol, @id
+ *
+ * Return: Name string on success, NULL on failure
+ */
+static const char *get_proto_name(enum scmi_std_protocol id)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(protocol_name); i++)
+ if (id == protocol_name[i].id)
+ return protocol_name[i].name;
+
+ return NULL;
+}
+
+/**
+ * do_scmi_info() - get the information of SCMI services
+ *
+ * @cmdtp: Command table
+ * @flag: Command flag
+ * @argc: Number of arguments
+ * @argv: Argument array
+ *
+ * Get the information of SCMI services using various interfaces
+ * provided by the Base protocol.
+ *
+ * Return: CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on failure
+ */
+static int do_scmi_info(struct cmd_tbl *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ u32 agent_id, num_protocols;
+ u8 *agent_name, *protocols;
+ int i, ret;
+
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ printf("SCMI device: %s\n", agent->name);
+ printf(" protocol version: 0x%x\n", scmi_version(agent));
+ printf(" # of agents: %d\n", scmi_num_agents(agent));
+ for (i = 0; i < scmi_num_agents(agent); i++) {
+ ret = scmi_base_discover_agent(base_proto, i, &agent_id,
+ &agent_name);
+ if (ret) {
+ if (ret != -EOPNOTSUPP)
+ printf("base_discover_agent() failed for id: %d
(%d)\n",
+ i, ret);
+ break;
+ }
+ printf("%c%2d: %s\n", i == scmi_agent_id(agent) ? '>' : ' ',
+ i, agent_name);
+ free(agent_name);
+ }
+ printf(" # of protocols: %d\n", scmi_num_protocols(agent));
+ num_protocols = scmi_num_protocols(agent);
+ protocols = scmi_protocols
[PATCH v3 10/13] test: dm: add SCMI base protocol test
Added is a new unit test for SCMI base protocol, which will exercise all
the commands provided by the protocol, except SCMI_BASE_NOTIFY_ERRORS.
$ ut dm scmi_base
It is assumed that test.dtb is used as sandbox's device tree.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Etienne Carriere
---
v3
* typo: s/scmi_base_protocol_attrs/scmi_base_protocol_message_attrs/
* modify the code for dynamically allocated vendor/agent names
v2
* use helper functions, removing direct uses of ops
---
test/dm/scmi.c | 112 +
1 file changed, 112 insertions(+)
diff --git a/test/dm/scmi.c b/test/dm/scmi.c
index 881be3171b7c..0785948186f0 100644
--- a/test/dm/scmi.c
+++ b/test/dm/scmi.c
@@ -16,6 +16,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -95,6 +98,115 @@ static int dm_test_scmi_sandbox_agent(struct
unit_test_state *uts)
}
DM_TEST(dm_test_scmi_sandbox_agent, UT_TESTF_SCAN_FDT);
+static int dm_test_scmi_base(struct unit_test_state *uts)
+{
+ struct udevice *agent_dev, *base;
+ struct scmi_agent_priv *priv;
+ u32 version, num_agents, num_protocols, impl_version;
+ u32 attributes, agent_id;
+ char *vendor, *agent_name;
+ u8 *protocols;
+ int ret;
+
+ /* preparation */
+ ut_assertok(uclass_get_device_by_name(UCLASS_SCMI_AGENT, "scmi",
+ &agent_dev));
+ ut_assertnonnull(agent_dev);
+ ut_assertnonnull(priv = dev_get_uclass_plat(agent_dev));
+ ut_assertnonnull(base = scmi_get_protocol(agent_dev,
+ SCMI_PROTOCOL_ID_BASE));
+
+ /* version */
+ ret = scmi_base_protocol_version(base, &version);
+ ut_assertok(ret);
+ ut_asserteq(priv->version, version);
+
+ /* protocol attributes */
+ ret = scmi_base_protocol_attrs(base, &num_agents, &num_protocols);
+ ut_assertok(ret);
+ ut_asserteq(priv->num_agents, num_agents);
+ ut_asserteq(priv->num_protocols, num_protocols);
+
+ /* discover vendor */
+ ret = scmi_base_discover_vendor(base, &vendor);
+ ut_assertok(ret);
+ ut_asserteq_str(priv->vendor, vendor);
+ free(vendor);
+
+ /* message attributes */
+ ret = scmi_protocol_message_attrs(base,
+ SCMI_BASE_DISCOVER_SUB_VENDOR,
+ &attributes);
+ ut_assertok(ret);
+ ut_assertok(attributes);
+
+ /* discover sub vendor */
+ ret = scmi_base_discover_sub_vendor(base, &vendor);
+ ut_assertok(ret);
+ ut_asserteq_str(priv->sub_vendor, vendor);
+ free(vendor);
+
+ /* impl version */
+ ret = scmi_base_discover_impl_version(base, &impl_version);
+ ut_assertok(ret);
+ ut_asserteq(priv->impl_version, impl_version);
+
+ /* discover agent (my self) */
+ ret = scmi_base_discover_agent(base, 0x, &agent_id,
+ &agent_name);
+ ut_assertok(ret);
+ ut_asserteq(priv->agent_id, agent_id);
+ ut_asserteq_str(priv->agent_name, agent_name);
+ free(agent_name);
+
+ /* discover protocols */
+ ret = scmi_base_discover_list_protocols(base, &protocols);
+ ut_asserteq(num_protocols, ret);
+ ut_asserteq_mem(priv->protocols, protocols, sizeof(u8) * num_protocols);
+ free(protocols);
+
+ /*
+* NOTE: Sandbox SCMI driver handles device-0 only. It supports setting
+* access and protocol permissions, but doesn't allow unsetting them nor
+* resetting the configurations.
+*/
+ /* set device permissions */
+ ret = scmi_base_set_device_permissions(base, agent_id, 0,
+
SCMI_BASE_SET_DEVICE_PERMISSIONS_ACCESS);
+ ut_assertok(ret); /* SCMI_SUCCESS */
+ ret = scmi_base_set_device_permissions(base, agent_id, 1,
+
SCMI_BASE_SET_DEVICE_PERMISSIONS_ACCESS);
+ ut_asserteq(-ENOENT, ret); /* SCMI_NOT_FOUND */
+ ret = scmi_base_set_device_permissions(base, agent_id, 0, 0);
+ ut_asserteq(-EACCES, ret); /* SCMI_DENIED */
+
+ /* set protocol permissions */
+ ret = scmi_base_set_protocol_permissions(base, agent_id, 0,
+SCMI_PROTOCOL_ID_CLOCK,
+
SCMI_BASE_SET_PROTOCOL_PERMISSIONS_ACCESS);
+ ut_assertok(ret); /* SCMI_SUCCESS */
+ ret = scmi_base_set_protocol_permissions(base, agent_id, 1,
+SCMI_PROTOCOL_ID_CLOCK,
+
SCMI_BASE_SET_PROTOCOL_PERMISSIONS_ACCESS);
+ ut_asserteq(-ENOENT, ret); /* SCMI_NOT_FOUND */
+ ret = scmi_base_set_protocol_permissions(base, agent_id, 0,
+
[PATCH v3 09/13] test: dm: simplify SCMI unit test on sandbox
Adding SCMI base protocol makes it inconvenient to hold the agent instance
(udevice) locally since the agent device will be re-created per each test.
Just remove it and simplify the test flows.
The test scenario is not changed at all.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
arch/sandbox/include/asm/scmi_test.h | 7 ++-
drivers/firmware/scmi/sandbox-scmi_agent.c | 20 +--
drivers/firmware/scmi/scmi_agent-uclass.c | 3 -
test/dm/scmi.c | 64 +++---
4 files changed, 26 insertions(+), 68 deletions(-)
diff --git a/arch/sandbox/include/asm/scmi_test.h
b/arch/sandbox/include/asm/scmi_test.h
index c72ec1e1cb25..2718336a9a50 100644
--- a/arch/sandbox/include/asm/scmi_test.h
+++ b/arch/sandbox/include/asm/scmi_test.h
@@ -89,10 +89,11 @@ struct sandbox_scmi_devices {
#ifdef CONFIG_SCMI_FIRMWARE
/**
- * sandbox_scmi_service_ctx - Get the simulated SCMI services context
+ * sandbox_scmi_agent_ctx - Get the simulated SCMI agent context
+ * @dev: Reference to the test agent
* @return:Reference to backend simulated resources state
*/
-struct sandbox_scmi_service *sandbox_scmi_service_ctx(void);
+struct sandbox_scmi_agent *sandbox_scmi_agent_ctx(struct udevice *dev);
/**
* sandbox_scmi_devices_ctx - Get references to devices accessed through SCMI
@@ -101,7 +102,7 @@ struct sandbox_scmi_service *sandbox_scmi_service_ctx(void);
*/
struct sandbox_scmi_devices *sandbox_scmi_devices_ctx(struct udevice *dev);
#else
-static inline struct sandbox_scmi_service *sandbox_scmi_service_ctx(void)
+static struct sandbox_scmi_agent *sandbox_scmi_agent_ctx(struct udevice *dev)
{
return NULL;
}
diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c
b/drivers/firmware/scmi/sandbox-scmi_agent.c
index 42a5a1f37f8b..27d17809be43 100644
--- a/drivers/firmware/scmi/sandbox-scmi_agent.c
+++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
@@ -66,11 +66,9 @@ static struct sandbox_scmi_voltd scmi_voltd[] = {
{ .id = 1, .voltage_uv = 180 },
};
-static struct sandbox_scmi_service sandbox_scmi_service_state;
-
-struct sandbox_scmi_service *sandbox_scmi_service_ctx(void)
+struct sandbox_scmi_agent *sandbox_scmi_agent_ctx(struct udevice *dev)
{
- return &sandbox_scmi_service_state;
+ return dev_get_priv(dev);
}
static void debug_print_agent_state(struct udevice *dev, char *str)
@@ -898,16 +896,8 @@ static int sandbox_scmi_test_process_msg(struct udevice
*dev,
static int sandbox_scmi_test_remove(struct udevice *dev)
{
- struct sandbox_scmi_agent *agent = dev_get_priv(dev);
-
- if (agent != sandbox_scmi_service_ctx()->agent)
- return -EINVAL;
-
debug_print_agent_state(dev, "removed");
- /* We only need to dereference the agent in the context */
- sandbox_scmi_service_ctx()->agent = NULL;
-
return 0;
}
@@ -915,9 +905,6 @@ static int sandbox_scmi_test_probe(struct udevice *dev)
{
struct sandbox_scmi_agent *agent = dev_get_priv(dev);
- if (sandbox_scmi_service_ctx()->agent)
- return -EINVAL;
-
*agent = (struct sandbox_scmi_agent){
.clk = scmi_clk,
.clk_count = ARRAY_SIZE(scmi_clk),
@@ -929,9 +916,6 @@ static int sandbox_scmi_test_probe(struct udevice *dev)
debug_print_agent_state(dev, "probed");
- /* Save reference for tests purpose */
- sandbox_scmi_service_ctx()->agent = agent;
-
return 0;
};
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index 54e17992af00..b37acbb9f9db 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -455,9 +455,6 @@ static int scmi_bind_protocols(struct udevice *dev)
}
}
- if (!ret)
- scmi_agent = dev;
-
return ret;
}
diff --git a/test/dm/scmi.c b/test/dm/scmi.c
index d87e2731ce42..881be3171b7c 100644
--- a/test/dm/scmi.c
+++ b/test/dm/scmi.c
@@ -23,22 +23,11 @@
#include
#include
-static int ut_assert_scmi_state_preprobe(struct unit_test_state *uts)
-{
- struct sandbox_scmi_service *scmi_ctx = sandbox_scmi_service_ctx();
-
- ut_assertnonnull(scmi_ctx);
- ut_assertnull(scmi_ctx->agent);
-
- return 0;
-}
-
static int ut_assert_scmi_state_postprobe(struct unit_test_state *uts,
+ struct sandbox_scmi_agent *agent,
struct udevice *dev)
{
struct sandbox_scmi_devices *scmi_devices;
- struct sandbox_scmi_service *scmi_ctx;
- struct sandbox_scmi_agent *agent;
/* Device references to check context against test sequence */
scmi_devices = sandbox_scmi_devices_ctx(dev);
@@ -48,10 +37,6 @@ static int ut_assert_scmi_state_postprobe(struct
unit_test_state *uts,
ut_asserteq(2, scmi_devices
[PATCH v3 08/13] firmware: scmi: fake base protocol commands on sandbox
This is a simple implementation of SCMI base protocol for sandbox.
The main use is in SCMI unit test.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
v3
* type fixes: s/udevice/dev/ in function descriptions
---
drivers/firmware/scmi/sandbox-scmi_agent.c | 359 -
1 file changed, 358 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c
b/drivers/firmware/scmi/sandbox-scmi_agent.c
index 031882998dfa..42a5a1f37f8b 100644
--- a/drivers/firmware/scmi/sandbox-scmi_agent.c
+++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
@@ -14,11 +14,14 @@
#include
#include
#include
+#include
+#include
/*
* The sandbox SCMI agent driver simulates to some extend a SCMI message
* processing. It simulates few of the SCMI services for some of the
* SCMI protocols embedded in U-Boot. Currently:
+ * - SCMI base protocol
* - SCMI clock protocol emulates an agent exposing 2 clocks
* - SCMI reset protocol emulates an agent exposing a reset controller
* - SCMI voltage domain protocol emulates an agent exposing 2 regulators
@@ -33,6 +36,21 @@
* various uclass devices, as clocks and reset controllers.
*/
+#define SANDBOX_SCMI_BASE_PROTOCOL_VERSION SCMI_BASE_PROTOCOL_VERSION
+#define SANDBOX_SCMI_VENDOR "U-Boot"
+#define SANDBOX_SCMI_SUB_VENDOR "Sandbox"
+#define SANDBOX_SCMI_IMPL_VERSION 0x1
+#define SANDBOX_SCMI_AGENT_NAME "OSPM"
+#define SANDBOX_SCMI_PLATFORM_NAME "platform"
+
+static u8 protocols[] = {
+ SCMI_PROTOCOL_ID_CLOCK,
+ SCMI_PROTOCOL_ID_RESET_DOMAIN,
+ SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN,
+};
+
+#define NUM_PROTOCOLS ARRAY_SIZE(protocols)
+
static struct sandbox_scmi_clk scmi_clk[] = {
{ .rate = 333 },
{ .rate = 200 },
@@ -114,6 +132,316 @@ static struct sandbox_scmi_voltd
*get_scmi_voltd_state(uint domain_id)
* Sandbox SCMI agent ops
*/
+/* Base Protocol */
+
+/**
+ * sandbox_scmi_base_protocol_version - implement SCMI_BASE_PROTOCOL_VERSION
+ * @dev: SCMI device
+ * @msg: SCMI message
+ *
+ * Implement SCMI_BASE_PROTOCOL_VERSION command.
+ */
+static int sandbox_scmi_base_protocol_version(struct udevice *dev,
+ struct scmi_msg *msg)
+{
+ struct scmi_protocol_version_out *out = NULL;
+
+ if (!msg->out_msg || msg->out_msg_sz < sizeof(*out))
+ return -EINVAL;
+
+ out = (struct scmi_protocol_version_out *)msg->out_msg;
+ out->version = SANDBOX_SCMI_BASE_PROTOCOL_VERSION;
+ out->status = SCMI_SUCCESS;
+
+ return 0;
+}
+
+/**
+ * sandbox_scmi_base_protocol_attrs - implement SCMI_BASE_PROTOCOL_ATTRIBUTES
+ * @dev: SCMI device
+ * @msg: SCMI message
+ *
+ * Implement SCMI_BASE_PROTOCOL_ATTRIBUTES command.
+ */
+static int sandbox_scmi_base_protocol_attrs(struct udevice *dev,
+ struct scmi_msg *msg)
+{
+ struct scmi_protocol_attrs_out *out = NULL;
+
+ if (!msg->out_msg || msg->out_msg_sz < sizeof(*out))
+ return -EINVAL;
+
+ out = (struct scmi_protocol_attrs_out *)msg->out_msg;
+ out->attributes = FIELD_PREP(0xff00, 2) | NUM_PROTOCOLS;
+ out->status = SCMI_SUCCESS;
+
+ return 0;
+}
+
+/**
+ * sandbox_scmi_base_message_attrs - implement
+ * SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES
+ * @dev: SCMI device
+ * @msg: SCMI message
+ *
+ * Implement SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES command.
+ */
+static int sandbox_scmi_base_message_attrs(struct udevice *dev,
+ struct scmi_msg *msg)
+{
+ u32 message_id;
+ struct scmi_protocol_msg_attrs_out *out = NULL;
+
+ if (!msg->in_msg || msg->in_msg_sz < sizeof(message_id) ||
+ !msg->out_msg || msg->out_msg_sz < sizeof(*out))
+ return -EINVAL;
+
+ message_id = *(u32 *)msg->in_msg;
+ out = (struct scmi_protocol_msg_attrs_out *)msg->out_msg;
+
+ if (message_id >= SCMI_PROTOCOL_VERSION &&
+ message_id <= SCMI_BASE_RESET_AGENT_CONFIGURATION &&
+ message_id != SCMI_BASE_NOTIFY_ERRORS) {
+ out->attributes = 0;
+ out->status = SCMI_SUCCESS;
+ } else {
+ out->status = SCMI_NOT_FOUND;
+ }
+
+ return 0;
+}
+
+/**
+ * sandbox_scmi_base_discover_vendor - implement SCMI_BASE_DISCOVER_VENDOR
+ * @dev: SCMI device
+ * @msg: SCMI message
+ *
+ * Implement SCMI_BASE_DISCOVER_VENDOR command
+ */
+static int sandbox_scmi_base_discover_vendor(struct udevice *dev,
+struct scmi_msg *msg)
+{
+ struct scmi_base_discover_vendor_out *out = NULL;
+
+ if (!msg->out_msg || msg->out_msg_sz < sizeof(*out))
+ return -EINVAL;
+
+ out = (struct scmi_base_discover_vendor_out *)msg->out_msg;
+ strcpy(out->vendor_identifier, SANDBOX_SCMI_VENDOR)
[PATCH v3 07/13] sandbox: remove SCMI base node definition from test.dts
SCMI base protocol is mandatory and doesn't need to be listed in a device
tree.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
arch/sandbox/dts/test.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f351d5cb84b0..dc0bfdfb6e4b 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -693,10 +693,6 @@
#address-cells = <1>;
#size-cells = <0>;
- protocol@10 {
- reg = <0x10>;
- };
-
clk_scmi: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
--
2.34.1
[PATCH v3 06/13] firmware: scmi: add a check against availability of protocols
Now that we have Base protocol support, we will be able to check if a given
protocol is really supported by the SCMI server (firmware).
Signed-off-by: AKASHI Takahiro
Reviewed-by: Etienne Carriere
---
v3
* new; import this patch from my followup patch set
---
drivers/firmware/scmi/scmi_agent-uclass.c | 41 +--
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index 87a667d60124..54e17992af00 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -44,6 +44,38 @@ static const struct error_code scmi_linux_errmap[] = {
*/
struct udevice *scmi_agent;
+/**
+ * scmi_protocol_is_supported - check availability of protocol
+ * @dev: SCMI agent device
+ * @proto_id: Identifier of protocol
+ *
+ * check if the protocol, @proto_id, is provided by the SCMI agent,
+ * @dev.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static bool scmi_protocol_is_supported(struct udevice *dev,
+ enum scmi_std_protocol proto_id)
+{
+ struct scmi_agent_priv *priv;
+ int i;
+
+ if (proto_id == SCMI_PROTOCOL_ID_BASE)
+ return true;
+
+ priv = dev_get_uclass_plat(dev);
+ if (!priv) {
+ dev_err(dev, "No priv data found\n");
+ return false;
+ }
+
+ for (i = 0; i < priv->num_protocols; i++)
+ if (priv->protocols[i] == proto_id)
+ return true;
+
+ return false;
+}
+
struct udevice *scmi_get_protocol(struct udevice *dev,
enum scmi_std_protocol id)
{
@@ -380,15 +412,18 @@ static int scmi_bind_protocols(struct udevice *dev)
name = ofnode_get_name(node);
switch (protocol_id) {
case SCMI_PROTOCOL_ID_CLOCK:
- if (CONFIG_IS_ENABLED(CLK_SCMI))
+ if (CONFIG_IS_ENABLED(CLK_SCMI) &&
+ scmi_protocol_is_supported(dev, protocol_id))
drv = DM_DRIVER_GET(scmi_clock);
break;
case SCMI_PROTOCOL_ID_RESET_DOMAIN:
- if (IS_ENABLED(CONFIG_RESET_SCMI))
+ if (IS_ENABLED(CONFIG_RESET_SCMI) &&
+ scmi_protocol_is_supported(dev, protocol_id))
drv = DM_DRIVER_GET(scmi_reset_domain);
break;
case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
- if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI)) {
+ if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI) &&
+ scmi_protocol_is_supported(dev, protocol_id)) {
node = ofnode_find_subnode(node, "regulators");
if (!ofnode_valid(node)) {
dev_err(dev, "no regulators node\n");
--
2.34.1
[PATCH v3 05/13] firmware: scmi: install base protocol to SCMI agent
SCMI base protocol is mandatory, and once SCMI node is found in a device
tree, the protocol handle (udevice) is unconditionally installed to
the agent. Then basic information will be retrieved from SCMI server via
the protocol and saved into the agent instance's local storage.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
v3
* typo fix: add '@' for argument name in function description
* eliminate dev_get_uclass_plat()'s repeated in inline
* modify the code for dynamically allocated sub-vendor/agent names
v2
* use helper functions, removing direct uses of ops
---
drivers/firmware/scmi/scmi_agent-uclass.c | 116 ++
include/scmi_agent-uclass.h | 66
2 files changed, 182 insertions(+)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index e823d105a3eb..87a667d60124 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -57,6 +57,9 @@ struct udevice *scmi_get_protocol(struct udevice *dev,
}
switch (id) {
+ case SCMI_PROTOCOL_ID_BASE:
+ proto = priv->base_dev;
+ break;
case SCMI_PROTOCOL_ID_CLOCK:
proto = priv->clock_dev;
break;
@@ -101,6 +104,9 @@ static int scmi_add_protocol(struct udevice *dev,
}
switch (proto_id) {
+ case SCMI_PROTOCOL_ID_BASE:
+ priv->base_dev = proto;
+ break;
case SCMI_PROTOCOL_ID_CLOCK:
priv->clock_dev = proto;
break;
@@ -237,6 +243,83 @@ int devm_scmi_process_msg(struct udevice *dev, struct
scmi_msg *msg)
return scmi_process_msg(protocol->parent, priv->channel, msg);
}
+/**
+ * scmi_fill_base_info - get base information about SCMI server
+ * @agent: SCMI agent device
+ * @dev: SCMI protocol device
+ *
+ * By using Base protocol commands, collect the base information
+ * about SCMI server.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int scmi_fill_base_info(struct udevice *agent, struct udevice *dev)
+{
+ struct scmi_agent_priv *priv = dev_get_uclass_plat(agent);
+ int ret;
+
+ ret = scmi_base_protocol_version(dev, &priv->version);
+ if (ret) {
+ dev_err(dev, "protocol_version() failed (%d)\n", ret);
+ return ret;
+ }
+ /* check for required version */
+ if (priv->version < SCMI_BASE_PROTOCOL_VERSION) {
+ dev_err(dev, "base protocol version (%d) lower than expected\n",
+ priv->version);
+ return -EPROTO;
+ }
+
+ ret = scmi_base_protocol_attrs(dev, &priv->num_agents,
+ &priv->num_protocols);
+ if (ret) {
+ dev_err(dev, "protocol_attrs() failed (%d)\n", ret);
+ return ret;
+ }
+ ret = scmi_base_discover_vendor(dev, &priv->vendor);
+ if (ret) {
+ dev_err(dev, "base_discover_vendor() failed (%d)\n", ret);
+ return ret;
+ }
+ ret = scmi_base_discover_sub_vendor(dev, &priv->sub_vendor);
+ if (ret) {
+ if (ret != -EOPNOTSUPP) {
+ dev_err(dev, "base_discover_sub_vendor() failed (%d)\n",
+ ret);
+ return ret;
+ }
+ priv->sub_vendor = "NA";
+ }
+ ret = scmi_base_discover_impl_version(dev, &priv->impl_version);
+ if (ret) {
+ dev_err(dev, "base_discover_impl_version() failed (%d)\n",
+ ret);
+ return ret;
+ }
+
+ priv->agent_id = 0x; /* to avoid false claim */
+ ret = scmi_base_discover_agent(dev, 0x,
+ &priv->agent_id, &priv->agent_name);
+ if (ret) {
+ if (ret != -EOPNOTSUPP) {
+ dev_err(dev,
+ "base_discover_agent() failed for myself
(%d)\n",
+ ret);
+ return ret;
+ }
+ priv->agent_name = "NA";
+ }
+
+ ret = scmi_base_discover_list_protocols(dev, &priv->protocols);
+ if (ret != priv->num_protocols) {
+ dev_err(dev, "base_discover_list_protocols() failed (%d)\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
/*
* SCMI agent devices binds devices of various uclasses depeding on
* the FDT description. scmi_bind_protocol() is a generic bind sequence
@@ -251,6 +334,39 @@ static int scmi_bind_protocols(struct udevice *dev)
struct driver *drv;
struct udevice *proto;
+ if (!uclass_get_device(UCLASS_SCMI_AGENT, 1, &agent)) {
+ /* This is a second SCMI agent */
+ dev_err(dev, "Cannot have mor
[PATCH v3 04/13] firmware: scmi: framework for installing additional protocols
This framework allows SCMI protocols to be installed and bound to the agent
so that the agent can manage and utilize them later.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
v3
* move "per_device_plat_auto" from a earlier patch
* fix comments in "scmi_agent_priv"
* modify an order of include files in scmi_agent.h
v2
* check for availability of protocols
---
drivers/firmware/scmi/scmi_agent-uclass.c | 101 +-
include/scmi_agent-uclass.h | 15 +++-
include/scmi_agent.h | 14 +++
3 files changed, 126 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index 94e54eeb066b..e823d105a3eb 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -38,6 +38,86 @@ static const struct error_code scmi_linux_errmap[] = {
{ .scmi = SCMI_PROTOCOL_ERROR, .errno = -EPROTO, },
};
+/*
+ * NOTE: The only one instance should exist according to
+ * the current specification and device tree bindings.
+ */
+struct udevice *scmi_agent;
+
+struct udevice *scmi_get_protocol(struct udevice *dev,
+ enum scmi_std_protocol id)
+{
+ struct scmi_agent_priv *priv;
+ struct udevice *proto;
+
+ priv = dev_get_uclass_plat(dev);
+ if (!priv) {
+ dev_err(dev, "No priv data found\n");
+ return NULL;
+ }
+
+ switch (id) {
+ case SCMI_PROTOCOL_ID_CLOCK:
+ proto = priv->clock_dev;
+ break;
+ case SCMI_PROTOCOL_ID_RESET_DOMAIN:
+ proto = priv->resetdom_dev;
+ break;
+ case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
+ proto = priv->voltagedom_dev;
+ break;
+ default:
+ dev_err(dev, "Protocol not supported\n");
+ proto = NULL;
+ break;
+ }
+ if (proto && device_probe(proto))
+ dev_err(dev, "Probe failed\n");
+
+ return proto;
+}
+
+/**
+ * scmi_add_protocol - add protocol to agent
+ * @dev: SCMI agent device
+ * @proto_id: SCMI protocol ID
+ * @proto: SCMI protocol device
+ *
+ * Associate the protocol instance, @proto, to the agent, @dev,
+ * for later use.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int scmi_add_protocol(struct udevice *dev,
+enum scmi_std_protocol proto_id,
+struct udevice *proto)
+{
+ struct scmi_agent_priv *priv;
+
+ priv = dev_get_uclass_plat(dev);
+ if (!priv) {
+ dev_err(dev, "No priv data found\n");
+ return -ENODEV;
+ }
+
+ switch (proto_id) {
+ case SCMI_PROTOCOL_ID_CLOCK:
+ priv->clock_dev = proto;
+ break;
+ case SCMI_PROTOCOL_ID_RESET_DOMAIN:
+ priv->resetdom_dev = proto;
+ break;
+ case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
+ priv->voltagedom_dev = proto;
+ break;
+ default:
+ dev_err(dev, "Protocol not supported\n");
+ return -EPROTO;
+ }
+
+ return 0;
+}
+
int scmi_to_linux_errno(s32 scmi_code)
{
int n;
@@ -164,12 +244,14 @@ int devm_scmi_process_msg(struct udevice *dev, struct
scmi_msg *msg)
*/
static int scmi_bind_protocols(struct udevice *dev)
{
+ struct udevice *agent;
int ret = 0;
ofnode node;
const char *name;
+ struct driver *drv;
+ struct udevice *proto;
dev_for_each_subnode(node, dev) {
- struct driver *drv = NULL;
u32 protocol_id;
if (!ofnode_is_enabled(node))
@@ -178,6 +260,7 @@ static int scmi_bind_protocols(struct udevice *dev)
if (ofnode_read_u32(node, "reg", &protocol_id))
continue;
+ drv = NULL;
name = ofnode_get_name(node);
switch (protocol_id) {
case SCMI_PROTOCOL_ID_CLOCK:
@@ -208,11 +291,22 @@ static int scmi_bind_protocols(struct udevice *dev)
continue;
}
- ret = device_bind(dev, drv, name, NULL, node, NULL);
- if (ret)
+ ret = device_bind(dev, drv, name, NULL, node, &proto);
+ if (ret) {
+ dev_err(dev, "failed to bind %s protocol\n", drv->name);
break;
+ }
+ ret = scmi_add_protocol(dev, protocol_id, proto);
+ if (ret) {
+ dev_err(dev, "failed to add protocol: %s, ret: %d\n",
+ proto->name, ret);
+ break;
+ }
}
+ if (!ret)
+ scmi_agent = dev;
+
return ret;
}
@@ -220,5 +314,6 @@ UCLASS_
[PATCH v3 03/13] firmware: scmi: move scmi_bind_protocols() backward
Move the location of scmi_bind_protocols() backward for changes
in later patches.
There is no change in functionality.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
Reviewed-by: Etienne Carriere
---
drivers/firmware/scmi/scmi_agent-uclass.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index feb31809e715..94e54eeb066b 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -157,6 +157,65 @@ int devm_scmi_process_msg(struct udevice *dev, struct
scmi_msg *msg)
return scmi_process_msg(protocol->parent, priv->channel, msg);
}
+/*
+ * SCMI agent devices binds devices of various uclasses depeding on
+ * the FDT description. scmi_bind_protocol() is a generic bind sequence
+ * called by the uclass at bind stage, that is uclass post_bind.
+ */
+static int scmi_bind_protocols(struct udevice *dev)
+{
+ int ret = 0;
+ ofnode node;
+ const char *name;
+
+ dev_for_each_subnode(node, dev) {
+ struct driver *drv = NULL;
+ u32 protocol_id;
+
+ if (!ofnode_is_enabled(node))
+ continue;
+
+ if (ofnode_read_u32(node, "reg", &protocol_id))
+ continue;
+
+ name = ofnode_get_name(node);
+ switch (protocol_id) {
+ case SCMI_PROTOCOL_ID_CLOCK:
+ if (CONFIG_IS_ENABLED(CLK_SCMI))
+ drv = DM_DRIVER_GET(scmi_clock);
+ break;
+ case SCMI_PROTOCOL_ID_RESET_DOMAIN:
+ if (IS_ENABLED(CONFIG_RESET_SCMI))
+ drv = DM_DRIVER_GET(scmi_reset_domain);
+ break;
+ case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
+ if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI)) {
+ node = ofnode_find_subnode(node, "regulators");
+ if (!ofnode_valid(node)) {
+ dev_err(dev, "no regulators node\n");
+ return -ENXIO;
+ }
+ drv = DM_DRIVER_GET(scmi_voltage_domain);
+ }
+ break;
+ default:
+ break;
+ }
+
+ if (!drv) {
+ dev_dbg(dev, "Ignore unsupported SCMI protocol %#x\n",
+ protocol_id);
+ continue;
+ }
+
+ ret = device_bind(dev, drv, name, NULL, node, NULL);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
UCLASS_DRIVER(scmi_agent) = {
.id = UCLASS_SCMI_AGENT,
.name = "scmi_agent",
--
2.34.1
[PATCH v3 02/13] firmware: scmi: implement SCMI base protocol
SCMI base protocol is mandatory according to the SCMI specification.
With this patch, SCMI base protocol can be accessed via SCMI transport
layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
This is because U-Boot doesn't support interrupts and the current transport
layers are not able to handle asynchronous messages properly.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
v3
* strncpy (TODO)
* remove a duplicated function prototype
* use newly-allocated memory when return vendor name or agent name
* revise function descriptions in a header
v2
* add helper functions, removing direct uses of ops
* add function descriptions for each of functions in ops
---
drivers/firmware/scmi/Makefile | 1 +
drivers/firmware/scmi/base.c | 656 +
include/dm/uclass-id.h | 1 +
include/scmi_protocols.h | 351 ++
4 files changed, 1009 insertions(+)
create mode 100644 drivers/firmware/scmi/base.c
diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
index b2ff483c75a1..1a23d4981709 100644
--- a/drivers/firmware/scmi/Makefile
+++ b/drivers/firmware/scmi/Makefile
@@ -1,4 +1,5 @@
obj-y += scmi_agent-uclass.o
+obj-y += base.o
obj-y += smt.o
obj-$(CONFIG_SCMI_AGENT_SMCCC) += smccc_agent.o
obj-$(CONFIG_SCMI_AGENT_MAILBOX) += mailbox_agent.o
diff --git a/drivers/firmware/scmi/base.c b/drivers/firmware/scmi/base.c
new file mode 100644
index ..6b99f36d0697
--- /dev/null
+++ b/drivers/firmware/scmi/base.c
@@ -0,0 +1,656 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SCMI Base protocol as U-Boot device
+ *
+ * Copyright (C) 2023 Linaro Limited
+ * author: AKASHI Takahiro
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * scmi_generic_protocol_version - get protocol version
+ * @dev: SCMI device
+ * @id:SCMI protocol ID
+ * @version: Pointer to SCMI protocol version
+ *
+ * Obtain the protocol version number in @version.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+int scmi_generic_protocol_version(struct udevice *dev,
+ enum scmi_std_protocol id, u32 *version)
+{
+ struct scmi_protocol_version_out out;
+ struct scmi_msg msg = {
+ .protocol_id = id,
+ .message_id = SCMI_PROTOCOL_VERSION,
+ .out_msg = (u8 *)&out,
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev, &msg);
+ if (ret)
+ return ret;
+ if (out.status)
+ return scmi_to_linux_errno(out.status);
+
+ *version = out.version;
+
+ return 0;
+}
+
+/**
+ * scmi_base_protocol_version_int - get Base protocol version
+ * @dev: SCMI device
+ * @version: Pointer to SCMI protocol version
+ *
+ * Obtain the protocol version number in @version for Base protocol.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int scmi_base_protocol_version_int(struct udevice *dev, u32 *version)
+{
+ return scmi_generic_protocol_version(dev, SCMI_PROTOCOL_ID_BASE,
+version);
+}
+
+/**
+ * scmi_protocol_attrs_int - get protocol attributes
+ * @dev: SCMI device
+ * @num_agents:Number of SCMI agents
+ * @num_protocols: Number of SCMI protocols
+ *
+ * Obtain the protocol attributes, the number of agents and the number
+ * of protocols, in @num_agents and @num_protocols respectively, that
+ * the device provides.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int scmi_protocol_attrs_int(struct udevice *dev, u32 *num_agents,
+ u32 *num_protocols)
+{
+ struct scmi_protocol_attrs_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_BASE,
+ .message_id = SCMI_PROTOCOL_ATTRIBUTES,
+ .out_msg = (u8 *)&out,
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev, &msg);
+ if (ret)
+ return ret;
+ if (out.status)
+ return scmi_to_linux_errno(out.status);
+
+ *num_agents = SCMI_PROTOCOL_ATTRS_NUM_AGENTS(out.attributes);
+ *num_protocols = SCMI_PROTOCOL_ATTRS_NUM_PROTOCOLS(out.attributes);
+
+ return 0;
+}
+
+/**
+ * scmi_protocol_message_attrs_int - get message-specific attributes
+ * @dev: SCMI device
+ * @message_id:SCMI message ID
+ * @attributes:Message-specific attributes
+ *
+ * Obtain the message-specific attributes in @attributes.
+ * This command succeeds if the message is implemented and available.
+ *
+ * Return: 0 on success, error code otherwise
+ */
+static int scmi_protocol_message_attrs_int(struct udevice *dev, u32 message_id,
+
[PATCH v3 01/13] scmi: refactor the code to hide a channel from devices
The commit 85dc58289238 ("firmware: scmi: prepare uclass to pass channel
reference") added an explicit parameter, channel, but it seems to make
the code complex.
Hiding this parameter will allow for adding a generic (protocol-agnostic)
helper function, i.e. for PROTOCOL_VERSION, in a later patch.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
v3
* fix an issue on ST board (reported by Etienne)
by taking care of cases where probed devices are children of
SCMI protocol device (i.e. clock devices under CCF)
See find_scmi_protocol_device().
* move "per_device_plato_auto" to a succeeding right patch
v2
* new patch
---
drivers/clk/clk_scmi.c| 27 +---
drivers/firmware/scmi/scmi_agent-uclass.c | 160 +++---
drivers/power/regulator/scmi_regulator.c | 27 +---
drivers/reset/reset-scmi.c| 19 +--
include/scmi_agent.h | 15 +-
5 files changed, 103 insertions(+), 145 deletions(-)
diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
index d172fed24c9d..34a49363a51a 100644
--- a/drivers/clk/clk_scmi.c
+++ b/drivers/clk/clk_scmi.c
@@ -13,17 +13,8 @@
#include
#include
-/**
- * struct scmi_clk_priv - Private data for SCMI clocks
- * @channel: Reference to the SCMI channel to use
- */
-struct scmi_clk_priv {
- struct scmi_channel *channel;
-};
-
static int scmi_clk_get_num_clock(struct udevice *dev, size_t *num_clocks)
{
- struct scmi_clk_priv *priv = dev_get_priv(dev);
struct scmi_clk_protocol_attr_out out;
struct scmi_msg msg = {
.protocol_id = SCMI_PROTOCOL_ID_CLOCK,
@@ -33,7 +24,7 @@ static int scmi_clk_get_num_clock(struct udevice *dev, size_t
*num_clocks)
};
int ret;
- ret = devm_scmi_process_msg(dev, priv->channel, &msg);
+ ret = devm_scmi_process_msg(dev, &msg);
if (ret)
return ret;
@@ -44,7 +35,6 @@ static int scmi_clk_get_num_clock(struct udevice *dev, size_t
*num_clocks)
static int scmi_clk_get_attibute(struct udevice *dev, int clkid, char **name)
{
- struct scmi_clk_priv *priv = dev_get_priv(dev);
struct scmi_clk_attribute_in in = {
.clock_id = clkid,
};
@@ -59,7 +49,7 @@ static int scmi_clk_get_attibute(struct udevice *dev, int
clkid, char **name)
};
int ret;
- ret = devm_scmi_process_msg(dev, priv->channel, &msg);
+ ret = devm_scmi_process_msg(dev, &msg);
if (ret)
return ret;
@@ -70,7 +60,6 @@ static int scmi_clk_get_attibute(struct udevice *dev, int
clkid, char **name)
static int scmi_clk_gate(struct clk *clk, int enable)
{
- struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
struct scmi_clk_state_in in = {
.clock_id = clk->id,
.attributes = enable,
@@ -81,7 +70,7 @@ static int scmi_clk_gate(struct clk *clk, int enable)
in, out);
int ret;
- ret = devm_scmi_process_msg(clk->dev, priv->channel, &msg);
+ ret = devm_scmi_process_msg(clk->dev, &msg);
if (ret)
return ret;
@@ -100,7 +89,6 @@ static int scmi_clk_disable(struct clk *clk)
static ulong scmi_clk_get_rate(struct clk *clk)
{
- struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
struct scmi_clk_rate_get_in in = {
.clock_id = clk->id,
};
@@ -110,7 +98,7 @@ static ulong scmi_clk_get_rate(struct clk *clk)
in, out);
int ret;
- ret = devm_scmi_process_msg(clk->dev, priv->channel, &msg);
+ ret = devm_scmi_process_msg(clk->dev, &msg);
if (ret < 0)
return ret;
@@ -123,7 +111,6 @@ static ulong scmi_clk_get_rate(struct clk *clk)
static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
{
- struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
struct scmi_clk_rate_set_in in = {
.clock_id = clk->id,
.flags = SCMI_CLK_RATE_ROUND_CLOSEST,
@@ -136,7 +123,7 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
in, out);
int ret;
- ret = devm_scmi_process_msg(clk->dev, priv->channel, &msg);
+ ret = devm_scmi_process_msg(clk->dev, &msg);
if (ret < 0)
return ret;
@@ -149,12 +136,11 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong
rate)
static int scmi_clk_probe(struct udevice *dev)
{
- struct scmi_clk_priv *priv = dev_get_priv(dev);
struct clk *clk;
size_t num_clocks, i;
int ret;
- ret = devm_scmi_of_get_channel(dev, &priv->channel);
+ ret = devm_scmi_of_get_channel(dev);
if (ret)
return ret;
@@ -205,5 +191,4 @@ U_BOOT_DRIVER(scmi_clock) = {
.id = UCLASS_CLK,
.ops = &scmi_clk_ops,
.probe = scmi_clk_probe,
- .priv_auto = sizeof(struct
[PATCH v3 00/13] firmware: scmi: add SCMI base protocol support
This patch series allows users to access SCMI base protocol provided by SCMI server (platform). It will also be utilized in separate patches in the future to add sanity/validity checks for other protocols. See SCMI specification document v3.2 beta[1] for more details about SCMI base protocol. What is currently not implemented is - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism This feature won't be very useful in the current U-Boot environment. [1] https://developer.arm.com/documentation/den0056/e/?lang=en Test The patch series was tested on the following platforms: * sandbox * qemu-arm64 with OPTEE as SCMI server Prerequisite: = * This patch series is based on v2023.10-rc3. Patches: Patch#1-#6: Add SCMI base protocol driver Patch#7-#10: Add SCMI base protocol device unit test Patch#11-#13: Add scmi command Change history: === v3 (Sep 8, 2023) * import patch#6 (protocol availability check) from my followup patch * fix an issue on ST board (reported by Etienne) (patch#1) * minor code improvements * fix various typos pointed out by Etienne * revise function descriptions/comments (Each commit message has more details.) v2 (Jul, 26, 2023) * refactor devm_scmi_of_get_channel()/process_msg(), removing uses of ops (patch#1) * use helper functions, removing uses of ops (patch#2,#9,#10) * add more descriptions in scmi command doc (patch#11) * remove 'scmi base' sub-command (patch#10,#12) v1 (Jun, 28, 2023) * initial release AKASHI Takahiro (13): scmi: refactor the code to hide a channel from devices firmware: scmi: implement SCMI base protocol firmware: scmi: move scmi_bind_protocols() backward firmware: scmi: framework for installing additional protocols firmware: scmi: install base protocol to SCMI agent firmware: scmi: add a check against availability of protocols sandbox: remove SCMI base node definition from test.dts firmware: scmi: fake base protocol commands on sandbox test: dm: simplify SCMI unit test on sandbox test: dm: add SCMI base protocol test cmd: add scmi command for SCMI firmware doc: cmd: add documentation for scmi test: dm: add scmi command test arch/sandbox/dts/test.dts | 4 - arch/sandbox/include/asm/scmi_test.h | 7 +- cmd/Kconfig| 9 + cmd/Makefile | 1 + cmd/scmi.c | 337 +++ doc/usage/cmd/scmi.rst | 126 drivers/clk/clk_scmi.c | 27 +- drivers/firmware/scmi/Makefile | 1 + drivers/firmware/scmi/base.c | 656 + drivers/firmware/scmi/sandbox-scmi_agent.c | 379 +++- drivers/firmware/scmi/scmi_agent-uclass.c | 416 +++-- drivers/power/regulator/scmi_regulator.c | 27 +- drivers/reset/reset-scmi.c | 19 +- include/dm/uclass-id.h | 1 + include/scmi_agent-uclass.h| 81 ++- include/scmi_agent.h | 29 +- include/scmi_protocols.h | 351 +++ test/dm/scmi.c | 228 +-- 18 files changed, 2506 insertions(+), 193 deletions(-) create mode 100644 cmd/scmi.c create mode 100644 doc/usage/cmd/scmi.rst create mode 100644 drivers/firmware/scmi/base.c -- 2.34.1
Re: [PATCH] clk: Add GPIO-controlled clock gate driver
On 8/13/23 19:51, Marek Vasut wrote:
Add driver which implements GPIO-controlled clock. The GPIO is used
as a gate to enable/disable the clock. This matches linux clk-gpio.c
driver, however this does not implement the GPIO mux part, which in
U-Boot DM would be better fit in separate driver.
Signed-off-by: Marek Vasut
---
Cc: Lukasz Majewski
Cc: Sean Anderson
---
drivers/clk/Kconfig| 13 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-gpio.c | 66 ++
3 files changed, 80 insertions(+)
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 29859cdfa15..bfd23a99046 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -83,6 +83,19 @@ config CLK_COMPOSITE_CCF
Enable this option if you want to (re-)use the Linux kernel's Common
Clock Framework [CCF] composite code in U-Boot's clock driver.
+config CLK_GPIO
+ bool "GPIO-controlled clock gate driver"
+ depends on CLK
+ help
+ Enable this option to add GPIO-controlled clock gate driver.
+
+config SPL_CLK_GPIO
+ bool "GPIO-controlled clock gate driver in SPL"
+ depends on SPL_CLK
+ help
+ Enable this option to add GPIO-controlled clock gate driver
+ in U-Boot SPL.
+
config CLK_BCM6345
bool "Clock controller driver for BCM6345"
depends on CLK && ARCH_BMIPS
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e22c8cf291f..26bf429acbc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_GPIO) += clk-gpio.o
obj-y += analogbits/
obj-y += imx/
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 000..26d795b9783
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Marek Vasut
+ */
+
+#include
+#include
+#include
+#include
+
+struct clk_gpio_priv {
+ struct gpio_descenable;
+};
+
+static int clk_gpio_enable(struct clk *clk)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+
+ dm_gpio_set_value(&priv->enable, 1);
+
+ return 0;
+}
+
+static int clk_gpio_disable(struct clk *clk)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+
+ dm_gpio_set_value(&priv->enable, 0);
+
+ return 0;
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable= clk_gpio_disable,
+};
+
+static int clk_gpio_probe(struct udevice *dev)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(dev);
+
+ return gpio_request_by_name(dev, "enable-gpios", 0,
+ &priv->enable, GPIOD_IS_OUT);
+}
+
+/*
+ * When implementing clk-mux-clock, use gpio_request_list_by_name
+ * and implement get_rate/set_rate/set_parent ops. This should be
+ * in a separate driver and with separate Kconfig option to enable
+ * that driver, since unlike Linux implementation, the U-Boot DM
+ * integration would be orthogonal to this driver.
+ */
+static const struct udevice_id clk_gpio_match[] = {
+ { .compatible = "gpio-gate-clock" },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(gpio_gate_clock) = {
+ .name = "gpio_clock",
+ .id = UCLASS_CLK,
+ .of_match = clk_gpio_match,
+ .probe = clk_gpio_probe,
+ .priv_auto = sizeof(struct clk_gpio_priv),
+ .ops= &clk_gpio_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
Reviewed-by: Sean Anderson
Re: [RFC PATCH 0/4] mtd: ubi: Enable accessing RO filesystems in UBI vols
Hi Heiko and Simon, Thought I'd follow-up to keep this discussion going. The main thing I would like to decide first (as it lets me start relying on it in boot scripts) would be the UBI access syntax: => ls ubi 0:rootfs /boot => ls ubi 0:2 /boot Do those look good? Should I be trying to mimic the accepted syntax of fs/ubifs/super.c:open_ubi()? Perhaps "ubi 0!rootfs" and/or "ubi 0_2"? Not using ':' leaves open the possibility for logical volumes (LVM2/UBI) to contain partitions - not that I expect anyone will want that. :) Cheers, Sam
[PATCH v6 2/2] schemas: 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 v6: - Use a number of bits instead of a string property - Fix inidcates typo 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 | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/dtschema/schemas/memory.yaml b/dtschema/schemas/memory.yaml index 1d74410..1a48b1c 100644 --- a/dtschema/schemas/memory.yaml +++ b/dtschema/schemas/memory.yaml @@ -31,10 +31,21 @@ patternProperties: numa-node-id: $ref: types.yaml#/definitions/uint32 -description: +description: | For the purpose of identification, each NUMA node is associated with a unique token known as a node id. - + ecc-detection-bits: +default: 0 +description: | + If present, this indicates the number of bits of memory error which + can be detected and reported by the Error-Correction Code (ECC) memory + subsystem (typically 0, 1 or 2). + ecc-correction-bits: +default: 0 +description: | + If present, this indicates the number of bits of memory error which + can be corrected by the Error-Correction Code (ECC) memory subsystem + (typically 0, 1 or 2). required: - device_type -- 2.42.0.283.g2d96d420d3-goog
[PATCH v6 1/2] schemas: Add some common reserved-memory usages
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.
This aims to provide an small schema addition for the memory mapping
needed to keep these two pieces working together well.
Signed-off-by: Simon Glass
---
Changes in v6:
- Drop mention of UEFI
- Use compatible strings instead of node names
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 | 71 +++
1 file changed, 71 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..4889f59
--- /dev/null
+++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
@@ -0,0 +1,71 @@
+# 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 compatible string.
+
+ Clients may reuse this reserved memory if they understand what it is for,
+ subject to the notes below.
+
+maintainers:
+ - Simon Glass
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+description: |
+ This describes some common memory reservations:
+
+ acpi-reclaim: Contains ACPI tables; memory may be reclaimed when the
+ tables are no-longer needed
+ acpi-nvs: Contains ACPI Non-volatile-storage data; memory may be
+ reclaimed when the tables are no-longer needed
+ boot-code: Contains code used for booting; memory may be reclaimed by
+ the OS when it is running
+ boot-code: Contains data used for booting; memory may be reclaimed by
+ the OS when it is running
+ runtime-code: Contains code used for interacting with the system when
+ running; memory may be reclaimed if this code is not called
+ runtime-data: Contains data used for interacting with the system when
+ running; memory may be reclaimed if the runtime code is not used
+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 compatible string.
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <1>;
+#size-cells = <1>;
+
+reserved@1234 {
+compatible = "boot-code";
+reg = <0x1234 0x0080>;
+};
+
+reserved@4321 {
+compatible = "boot-data";
+reg = <0x4321 0x0080>;
+};
+};
--
2.42.0.283.g2d96d420d3-goog
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
Hi Ard, On Thu, 7 Sept 2023 at 10:19, Ard Biesheuvel wrote: > > On Thu, 7 Sept 2023 at 17:57, Simon Glass wrote: > > > > Hi Ard, > > > > On Thu, 7 Sept 2023 at 09:07, Ard Biesheuvel wrote: > > > > > > On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote: > > > > > > > > Hi Ard, > > > > > > > > On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel wrote: > > > > > > > > > > On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote: > > > > > > > > > > > > Hi Ard, > > > > > > > > > > > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel > > > > > > wrote: > > > > > > > > ... > > > > > > > > > > > > > > I'm happy to help flesh this out, but you still have not provided > > > > > > > us > > > > > > > with an actual use case, so I can only draw from my own experience > > > > > > > putting together firmware for virtual and physical ARM machines. > > > > > > > > > > > > I did explain that this is needed when Tianocore is on both sides of > > > > > > the interface, since Platform Init places some things in memory and > > > > > > the Payload needs to preserve them there, and/or know where they > > > > > > are. > > > > > > > > > > > > I think the problem might be that you don't agree with that, but it > > > > > > seems to be a fact, so I am not sure how I can alter it. > > > > > > > > > > > > Please can you clearly explain which part of the use case you are > > > > > > missing. > > > > > > > > > > > > > > > > 'Tianocore on both sides of the interface' means that Tianocore runs > > > > > as the platform init code, and uses a bespoke DT based protocol to > > > > > launch another instance of Tianocore as the payload, right? > > > > > > > > Not another instance, no. Just the other half of Tianocore. The first > > > > half does platform init and the second half does the loading of the > > > > OS. > > > > > > > > > > That doesn't make any sense to me. > > > > > > > > > > > > > Tianocore/EDK2 already implements methods to reinvoke itself if needed > > > > > (e.g., during a firmware update), and does so by launching a new DXE > > > > > core. So the boot sequence looks like > > > > > > > > > > SEC -> PEI -> DXE -> BDS -> app that invokes UpdateCapsule() -> DXE -> > > > > > firmware update > > > > > > > > > > So please elaborate on how this Tianocore on both sides of the > > > > > interface is put together when it uses this DT based handover. We > > > > > really need a better understanding of this in order to design a DT > > > > > binding that meets its needs. > > > > > > > > Are you familiar with building Tianocore as a coreboot payload, for > > > > example? That shows Tianocore running as just the Payload, with > > > > coreboot doing the platform init. So the use case I am talking about > > > > is similar to that. > > > > > > > > > > Yes I am familiar with that, and it is a completely different thing. > > > > Right, but that is my use case. > > > > OK. You alluded to Tianocore <-> Tianocore being your use case, which > is why I kept asking for clarification, as using a DT with this > binding seems unusual at the very least. Nevertheless, that is the goal. > > So coreboot does the platform init, and then hands over to Tianocore. > > I take it we are not talking about x86 here, so there are no Intel FSP > blobs that may have dependencies on Tianocore/EDK2 pieces, right? So > there are no UEFI semantics in the memory descriptions that coreboot > provides to Tianocore. > > So coreboot provides information to TIanocore about > - the platform topology (DT as usual) > - DRAM memory banks > - memory reservations > - secure firmware services perhaps? > - anything else? Please don't widen the discussion as we are having enough trouble as it is. Let's focus on the memory reservations. > > > > > > > > As i explained before, there is already prior art for this in > > > Tianocore, i.e., launching a Tianocore build based on a DT description > > > of the platform, including /memory and /reserved-memory nodes. > > > > By prior art do you mean code, or an existing binding? In either case, > > can you please point me to it? Is this a generic binding used on x86 > > as well, or just for ARM? > > > > My goal here is to augment the binding. > > > > No I mean code. > > There is > > https://github.com/tianocore/edk2/tree/master/EmbeddedPkg/Drivers/FdtClientDxe > > which encapsulates the DT received from the previous boot stage, and > exposes it as a DXE protocol. > > There are other drivers that depend on this protocol, e.g., to > discover additional memory nodes, virtio-mmio drivers and PCI host > bridges. > > https://github.com/tianocore/edk2/tree/master/OvmfPkg/Fdt That looks like Tianocore internals rather than a binding, so far as I can tell. I do need a binding. > > The bindings used are the ones documented in the Linux kernel tree - > no ad-hoc bindings are being used as far as I know. > > But the point I was making before re prior art was really about using > existing bindings rather than inventing new ones. Since we are now > talking about augmenting
[PATCH v2] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
Changes in v2:
- set devtype to sata in bootmeth_script for non-scsi SATA device
boot/bootmeth_script.c | 12 ++--
drivers/ata/Makefile | 1 +
drivers/ata/sata.c | 25 +++
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 1 +
5 files changed, 99 insertions(+), 2 deletions(-)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index a4050c384d..3113183fb0 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
bootflow *bflow)
ulong addr;
int ret;
- if (desc->uclass_id == UCLASS_USB)
+ if (desc->uclass_id == UCLASS_USB) {
ret = env_set("devtype", "usb");
- else
+ } else {
ret = env_set("devtype", blk_get_devtype(bflow->blk));
+
+ /* If the parent uclass is AHCI, but the driver is ATA
+* (not scsi), set devtype to sata
+*/
+ if (!ret && IS_ENABLED(CONFIG_SATA) &&
+ !strcmp("ahci", env_get("devtype")))
+ ret = env_set("devtype", "sata");
+ }
if (!ret)
ret = env_set_hex("devnum", desc->devnum);
if (!ret)
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..c1b51b5444 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..9da7218564 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ struct udevice *dev;
+ int devnum = 0;
+ int ret;
+
+ /* Find and probing the SATA controller */
+ ret = uclass_get_device(UCLASS_AHCI, devnum, &dev);
+
+ /* Sanity check */
+ if (ret)
+ ret = uclass_find_first_device(UCLASS_AHCI, &dev);
+ if (ret) {
+ printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
+ return -ENOSYS;
+ }
+ if (!dev) {
+ printf("No SATA device found!\n");
+ return -ENOSYS;
+ }
+ return 0;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= &sata_bootdev_ops,
+ .bind = sata_bootdev_bind,
+ .of_match = sata_bootdev_ids,
+};
+
+BOOTDEV_HUNTER(sata_bootdev_hunter) = {
+ .prio = BOOTDEVP_4_SCAN_FAST,
+ .uclass = UCLASS_AHCI,
+ .hunt = sata_bootdev_hunt,
+ .drv= DM_DRIVER_REF(sata_bootdev),
+};
diff --git a/include/sata.h b/include/sata.h
index d89f7a8a29..0495744bad 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
int sata_probe(int devnum);
int sata_remove(int devnum);
+int sata_rescan(bool verbose);
#endif
--
2.39.2
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
Hi Tom,
On Thu, 7 Sept 2023 at 13:40, Tom Rini wrote:
>
> On Thu, Sep 07, 2023 at 06:23:06AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 6 Sept 2023 at 11:58, Tom Rini wrote:
> > >
> > > On Tue, Sep 05, 2023 at 12:16:56PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 3 Sept 2023 at 13:25, Tom Rini wrote:
> > > > >
> > > > > On Sun, Sep 03, 2023 at 12:06:13PM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sun, 3 Sept 2023 at 10:42, Tom Rini wrote:
> > > > > > >
> > > > > > > On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Wed, 23 Aug 2023 at 09:14, Tom Rini
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> > > > > > > > >
> > > > > > > > > > When lmb runs out of space in its internal tables, it gives
> > > > errors on
> > > > > > > > > > every fs load operation. This is horribly confusing, as the
> > > > poor user
> > > > > > > > > > tries different memory regions one at a time.
> > > > > > > > > >
> > > > > > > > > > Use the updated API to check the error code and print a
> > > > > > > > > > helpful
> > > > message.
> > > > > > > > > > Also, allow the operation to proceed.
> > > > > > > > > >
> > > > > > > > > > Update the tests accordingly.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > > [snip]
> > > > > > > > > > + if (ret == -E2BIG) {
> > > > > > > > > > + log_warning("Reservation tables exhausted: see
> > > > CONFIG_LMB_USE_MAX_REGIONS\n");
> > > > > > > > > > + return 0;
> > > > > > > > > > + }
> > > > > > > > >
> > > > > > > > > This isn't the right option. Everyone has
> > > > CONFIG_LMB_USE_MAX_REGIONS
> > > > > > > > > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> > > > > > > > >
> > > > > > > > > But it sounds like what you've found and fixed is an
> > > > > > > > > underlying
> > > > problem
> > > > > > > > > as to why 16 regions isn't enough in some common cases now?
> > > > > > > > > So
> > > > we could
> > > > > > > >
> > > > > > > > I don't think I have fixed anything. But I'll send v2 and
> > > > > > > > perhaps it
> > > > > > > > will be clearer what is going on here.
> > > > > > > >
> > > > > > > > > possibly avoid the string size growth here and have a comment
> > > > that also
> > > > > > > > > matches up with the help under LMB_MAX_REGIONS?
> > > > > > > >
> > > > > > > > I don't know, sorry. The size of struct(lmb) on 64-bit sandbox
> > > > > > > > is
> > > > > > > > about 400 bytes. There seems to be a lot of code to save not
> > > > > > > > much
> > > > > > > > memory.
> > > > > > >
> > > > > > > What do you mean here? The alternative is not unlimited ranges
> > > > > > > but
> > > > > > > instead to define the limit of memory regions and limit of
> > > > > > > reserved
> > > > > > > ranges.
> > > > > >
> > > > > > A better alternative would be not to limit the number of regions,
> > > > > > IMO,
> > > > > > i.e. have an array of regions that can grow as needed.
> > > > >
> > > > > That's not something that we have in the code today, however.
> > > >
> > > > No, I do have an arraylist thing that I plan to upstream, which could
> > > > handle that.
> > > >
> > > > But for this series, what do you think of the memregion idea? I am still
> > > > unsure of the saming we should use - see Heinrich's comments too.
> > >
> > > My biggest worry here is that we're papering over a real issue, and
> > > should either dig at that and see what's going on (should something be
> > > coalescing adjacent allocations? Were many platforms just right at the
> > > previous limit?) or just bump the default from 16 to "64 if EFI_LOADER"
> > > and then see if anything else really needs tweaking / cleaning up in the
> > > code itself. I know Heinrich has previously said the LMB system could
> > > be better (or something to that effect, I'm going from memory, sorry if
> > > I'm mis-stating things) and I don't object to replacing what we have
> > > with something more robust/smarter/etc.
> >
> > I am not sure...my series was designed to rename the code to reduce
> > confusion, and print a useful message when we run out of regions. It
> > does not paper over the problem, but actually makes it more visible.
>
> Well, "papering over" maybe wasn't the best choice of words on my part.
> But since the series of events was something like:
> - We nee to use LMB to cover my U-Boot regions to address a handful of
> CVEs over arbitrarily overwriting U-Boot at run-time.
> - AFAICT no platforms suddenly ran out of LMB reservation space, but
> maybe I'm wrong?
> - Someone noted that the EFI subsystem was exposing the same kind of
> issue.
> - Heinrich adds logic for EFI_LOADER (iirc) to also add allocations
> there to LMB
> - Assorted platforms start changing the max allocation to 64 to fix the
> problems that ge
[PATCH v1] doc: Update path to source_file_format.rst
Previously, the file extension was .txt, and it referenced the uImage.FIT directory, which no longer exists. This commit updates the path accordingly. Signed-off-by: Joao Marcos Costa --- doc/usage/fit/howto.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/fit/howto.rst b/doc/usage/fit/howto.rst index c933703d1d..8b38cd534d 100644 --- a/doc/usage/fit/howto.rst +++ b/doc/usage/fit/howto.rst @@ -22,7 +22,7 @@ for its latest version. mkimage (together with dtc) takes as input an image source file, which describes the contents of the image and defines its various properties used during booting. By convention, image source file has the ".its" extension, also, the details of its format are given in -doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in +doc/usage/fit/source_file_format.rst. The actual data that is to be included in the uImage (kernel, ramdisk, etc.) is specified in the image source file in the form of paths to appropriate data files. The outcome of the image creation process is a binary file (by convention with the ".itb" extension) that -- 2.41.0
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
On Thu, Sep 07, 2023 at 06:23:06AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 6 Sept 2023 at 11:58, Tom Rini wrote:
> >
> > On Tue, Sep 05, 2023 at 12:16:56PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 3 Sept 2023 at 13:25, Tom Rini wrote:
> > > >
> > > > On Sun, Sep 03, 2023 at 12:06:13PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sun, 3 Sept 2023 at 10:42, Tom Rini wrote:
> > > > > >
> > > > > > On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 23 Aug 2023 at 09:14, Tom Rini wrote:
> > > > > > > >
> > > > > > > > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > When lmb runs out of space in its internal tables, it gives
> > > errors on
> > > > > > > > > every fs load operation. This is horribly confusing, as the
> > > poor user
> > > > > > > > > tries different memory regions one at a time.
> > > > > > > > >
> > > > > > > > > Use the updated API to check the error code and print a
> > > > > > > > > helpful
> > > message.
> > > > > > > > > Also, allow the operation to proceed.
> > > > > > > > >
> > > > > > > > > Update the tests accordingly.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > [snip]
> > > > > > > > > + if (ret == -E2BIG) {
> > > > > > > > > + log_warning("Reservation tables exhausted: see
> > > CONFIG_LMB_USE_MAX_REGIONS\n");
> > > > > > > > > + return 0;
> > > > > > > > > + }
> > > > > > > >
> > > > > > > > This isn't the right option. Everyone has
> > > CONFIG_LMB_USE_MAX_REGIONS
> > > > > > > > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> > > > > > > >
> > > > > > > > But it sounds like what you've found and fixed is an underlying
> > > problem
> > > > > > > > as to why 16 regions isn't enough in some common cases now? So
> > > we could
> > > > > > >
> > > > > > > I don't think I have fixed anything. But I'll send v2 and perhaps
> > > > > > > it
> > > > > > > will be clearer what is going on here.
> > > > > > >
> > > > > > > > possibly avoid the string size growth here and have a comment
> > > that also
> > > > > > > > matches up with the help under LMB_MAX_REGIONS?
> > > > > > >
> > > > > > > I don't know, sorry. The size of struct(lmb) on 64-bit sandbox is
> > > > > > > about 400 bytes. There seems to be a lot of code to save not much
> > > > > > > memory.
> > > > > >
> > > > > > What do you mean here? The alternative is not unlimited ranges but
> > > > > > instead to define the limit of memory regions and limit of reserved
> > > > > > ranges.
> > > > >
> > > > > A better alternative would be not to limit the number of regions, IMO,
> > > > > i.e. have an array of regions that can grow as needed.
> > > >
> > > > That's not something that we have in the code today, however.
> > >
> > > No, I do have an arraylist thing that I plan to upstream, which could
> > > handle that.
> > >
> > > But for this series, what do you think of the memregion idea? I am still
> > > unsure of the saming we should use - see Heinrich's comments too.
> >
> > My biggest worry here is that we're papering over a real issue, and
> > should either dig at that and see what's going on (should something be
> > coalescing adjacent allocations? Were many platforms just right at the
> > previous limit?) or just bump the default from 16 to "64 if EFI_LOADER"
> > and then see if anything else really needs tweaking / cleaning up in the
> > code itself. I know Heinrich has previously said the LMB system could
> > be better (or something to that effect, I'm going from memory, sorry if
> > I'm mis-stating things) and I don't object to replacing what we have
> > with something more robust/smarter/etc.
>
> I am not sure...my series was designed to rename the code to reduce
> confusion, and print a useful message when we run out of regions. It
> does not paper over the problem, but actually makes it more visible.
Well, "papering over" maybe wasn't the best choice of words on my part.
But since the series of events was something like:
- We nee to use LMB to cover my U-Boot regions to address a handful of
CVEs over arbitrarily overwriting U-Boot at run-time.
- AFAICT no platforms suddenly ran out of LMB reservation space, but
maybe I'm wrong?
- Someone noted that the EFI subsystem was exposing the same kind of
issue.
- Heinrich adds logic for EFI_LOADER (iirc) to also add allocations
there to LMB
- Assorted platforms start changing the max allocation to 64 to fix the
problems that get reported sometimes by booting.
- Heinrich notes that our memory reservation system (LMB) could be
better designed than it is today.
- And, iirc, EFI_LOADER or similar has something maybe we can
leverage?
Which brings me to what I was trying to say. I'm not sure it's worth
cleaning up the code a little, or refactoring/renaming things within it
without both:
- Understanding why EFI_LO
Re: [PATCHv7 00/15] net/lwip: add lwip library for the network stack
On Thu, Sep 07, 2023 at 05:21:18PM +0200, Michal Simek wrote: > Hi, > > út 22. 8. 2023 v 11:38 odesílatel Maxim Uvarov > napsal: > > > > Hello, > > > > I'm sending v7, with all v6 comments getting fixed. The only thing left is > > a pointer > > to timeout callback which 2 applications use. I will rework this timeout > > in next v8. I started take a look at it, and want to fix this together > > with background applications support in v8. > > > > changelog: > > v7: - more review fixes. > > - support of multiply eth devices, were "ethact" selects the > > active device. > > v6: - fixed review comments for v5 (thanks Ilias and Simon). > > - lwip is not under /net, so prior applying patch following > > commit is needed to create lwIP merge into U-Boot: > > git subtree add --prefix net/lwip/lwip-external > > https://git.savannah.nongnu.org/git/lwip.git master --squash > > I think you should integrate it via .gitmodules as is done for example in > qemu. I _think_ I am leaning towards subtree, but it sounds like we need to make the initial build easier, perhaps some Makefile logic to see we haven't added, and then do what's needed? -- Tom signature.asc Description: PGP signature
Re: sandbox trace errors in CI loop
On Thu, Sep 07, 2023 at 05:30:03PM +0200, Michal Simek wrote: > Hi Simon and Tom, > > I am preparing pull request and I see that CI loop is reporting issue with > sandbox trace and I have no idea what's going wrong here. > > This is the first problematic commit but have no clue what it has to do with > trace. > > https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/commit/8c5f80d11b29536979ac41a6087fb8938f45bbf2 > > If you have an access you can take a look at my queue to see that only this > job is failing. > https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines > > Thanks, > Michal > > collected 1152 items / 1151 deselected / 1 selected > test/py/tests/test_trace.py F > [100%] > === FAILURES > === > __ test_trace > __ > test/py/tests/test_trace.py:292: in test_trace > check_function(cons, fname, proftool, map_fname, trace_dat) > test/py/tests/test_trace.py:117: in check_function > out = util.run_and_log(cons, ['sh', '-c', cmd]) > test/py/u_boot_utils.py:181: in run_and_log > output = runner.run(cmd, ignore_errors=ignore_errors, stdin=stdin, > env=env) > test/py/multiplexed_log.py:183: in run > raise exception > E ValueError: Exit code: 1 > Captured stdout setup > - > /u-boot > trace: early enable at 0010 > sandbox_serial serial: pinctrl_select_state_full: > uclass_get_device_by_phandle_id: err=-19 > => I don't get it either since I see this on master with trace options enabled per CI: $ ./u-boot -T arch/sandbox/dts/test.dtb trace: early enable at 0010 sandbox_serial serial: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ... rest of boot proceeds ... So the test should be failing already if that was the problem. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/7] drivers: misc: k3_avs: Add linux compatible to maintain sync
On 10:08-20230907, Nishanth Menon wrote:
> On 19:44-20230907, Neha Malcom Francis wrote:
> > The U-Boot AVS driver works on the VTM (Voltage and Thermal Management)
> > module, also used by the Linux TI Bandgap temperature sensor driver
> > (drivers/thermal/k3_j72xx_bandgap.c). Although the purpose and
> > functionalities that these two implement are different, the hardware is
> > the same, so ensure that their compatibles are in sync. Thus, add
> > ti,j721e-vtm compatible to the AVS driver.
> >
> > Signed-off-by: Neha Malcom Francis
> > ---
> > drivers/misc/k3_avs.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
> > index 840148d090..3008cf9810 100644
> > --- a/drivers/misc/k3_avs.c
> > +++ b/drivers/misc/k3_avs.c
> > @@ -382,6 +382,7 @@ static struct vd_config am654_vd_config = {
> > static const struct udevice_id k3_avs_ids[] = {
> > { .compatible = "ti,am654-avs", .data = (ulong)&am654_vd_config },
> > { .compatible = "ti,j721e-avs", .data = (ulong)&j721e_vd_config },
> > + { .compatible = "ti,j721e-vtm", .data = (ulong)&j721e_vd_config },
> > {}
> > };
> >
> > --
> > 2.34.1
> >
> https://lore.kernel.org/all/52a7c0b2-7a87-c74e-e63f-d07821ffc...@ti.com/
>
> we are going to end up creating a dependency nightmare.
>
> Can we just do a single series(might be just a single patch) for
> compatible additions for k3_avs.c and make the dts syncs dependent on this?
>
I submitted one here if this works:
https://lore.kernel.org/u-boot/20230907180635.89011-1-re...@ti.com/T/#u
-Reid
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
[PATCH] drivers: misc: k3_avs: Add Linux compatibles to maintain sync
The ti,j7200-vtm and ti,j721e-vtm compatibles are used for voltage
and thermal monitoring (VTM) by (drivers/thermal/k3_j72xx_bandgap.c)
in Linux, but the same hardware is used for adaptive voltage scaling
(AVS) in u-boot, This brings both drivers in line with the same
compatibles.
Since the j7200 uses the config as the j721e, the data is inherited
from j721e vs creating a duplicate
Signed-off-by: Neha Francis
Signed-off-by: Reid Tonking
---
In preparation for syncing k3 socs j721e & j7200, a single patch is
being submitted to avoid having dependency complications [0]. This
patch will be a dependency for the following series [1] [2], each
with another version to follow.
[0]
https://lore.kernel.org/u-boot/20230907150858.3l6q2yxyfgdx3jvn@mulled/T/#mf52d9105756329549871144fe93c1149d1c26ef3
[1]
https://lore.kernel.org/u-boot/20230907150858.3l6q2yxyfgdx3jvn@mulled/T/#m878091acccecbf29e27e400b3acbfd35c025e396
[2]
https://lore.kernel.org/u-boot/20230905181309.61666-1-re...@ti.com/T/#m8d254c1d912aae3b636fadb23a0c8aacdd9ea484
drivers/misc/k3_avs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 840148d090..acfc731845 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -382,6 +382,8 @@ static struct vd_config am654_vd_config = {
static const struct udevice_id k3_avs_ids[] = {
{ .compatible = "ti,am654-avs", .data = (ulong)&am654_vd_config },
{ .compatible = "ti,j721e-avs", .data = (ulong)&j721e_vd_config },
+ { .compatible = "ti,j721e-vtm", .data = (ulong)&j721e_vd_config },
+ { .compatible = "ti,j7200-vtm", .data = (ulong)&j721e_vd_config },
{}
};
--
2.34.1
[PATCH 7/7] ARM: dts: stm32: add RNG node for STM32MP13x platforms
Add RNG node for STM32MP13x platforms.
Signed-off-by: Gatien Chevallier
---
arch/arm/dts/stm32mp131.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index d23bbc3639..bd7285053d 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -1208,6 +1208,14 @@
};
};
+ rng: rng@54004000 {
+ compatible = "st,stm32mp13-rng";
+ reg = <0x54004000 0x400>;
+ clocks = <&rcc RNG1_K>;
+ resets = <&rcc RNG1_R>;
+ status = "disabled";
+ };
+
mdma: dma-controller@5800 {
compatible = "st,stm32h7-mdma";
reg = <0x5800 0x1000>;
--
2.25.1
[PATCH 5/7] rng: stm32: add error concealment sequence
Seed errors can occur when using the hardware RNG. Implement the
sequences to handle them. This avoids irrecoverable RNG state.
Try to conceal seed errors when possible. If, despite the error
concealing tries, a seed error is still present, then return an error.
A clock error does not compromise the hardware block and data can
still be read from RNG_DR. Just warn that the RNG clock is too slow
and clear RNG_SR.
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 163 ++--
1 file changed, 140 insertions(+), 23 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index f943acd7d2..b1a790b217 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -32,6 +32,8 @@
#define RNG_DR 0x08
+#define RNG_NB_RECOVER_TRIES 3
+
/*
* struct stm32_rng_data - RNG compat data
*
@@ -52,45 +54,160 @@ struct stm32_rng_plat {
bool ced;
};
+/*
+ * Extracts from the STM32 RNG specification when RNG supports CONDRST.
+ *
+ * When a noise source (or seed) error occurs, the RNG stops generating
+ * random numbers and sets to “1” both SEIS and SECS bits to indicate
+ * that a seed error occurred. (...)
+ *
+ * 1. Software reset by writing CONDRST at 1 and at 0 (see bitfield
+ * description for details). This step is needed only if SECS is set.
+ * Indeed, when SEIS is set and SECS is cleared it means RNG performed
+ * the reset automatically (auto-reset).
+ * 2. If SECS was set in step 1 (no auto-reset) wait for CONDRST
+ * to be cleared in the RNG_CR register, then confirm that SEIS is
+ * cleared in the RNG_SR register. Otherwise just clear SEIS bit in
+ * the RNG_SR register.
+ * 3. If SECS was set in step 1 (no auto-reset) wait for SECS to be
+ * cleared by RNG. The random number generation is now back to normal.
+ */
+static int stm32_rng_conceal_seed_error_cond_reset(struct stm32_rng_plat
*pdata)
+{
+ u32 sr = readl_relaxed(pdata->base + RNG_SR);
+ u32 cr = readl_relaxed(pdata->base + RNG_CR);
+ int err;
+
+ if (sr & RNG_SR_SECS) {
+ /* Conceal by resetting the subsystem (step 1.) */
+ writel_relaxed(cr | RNG_CR_CONDRST, pdata->base + RNG_CR);
+ writel_relaxed(cr & ~RNG_CR_CONDRST, pdata->base + RNG_CR);
+ } else {
+ /* RNG auto-reset (step 2.) */
+ writel_relaxed(sr & ~RNG_SR_SEIS, pdata->base + RNG_SR);
+ return 0;
+ }
+
+ err = readl_relaxed_poll_timeout(pdata->base + RNG_SR, sr, !(sr &
RNG_CR_CONDRST), 10);
+ if (err) {
+ log_err("%s: timeout %x\n", __func__, sr);
+ return err;
+ }
+
+ /* Check SEIS is cleared (step 2.) */
+ if (readl_relaxed(pdata->base + RNG_SR) & RNG_SR_SEIS)
+ return -EINVAL;
+
+ err = readl_relaxed_poll_timeout(pdata->base + RNG_SR, sr, !(sr &
RNG_SR_SECS), 10);
+ if (err) {
+ log_err("%s: timeout %x\n", __func__, sr);
+ return err;
+ }
+
+ return 0;
+}
+
+/*
+ * Extracts from the STM32 RNG specification, when CONDRST is not supported
+ *
+ * When a noise source (or seed) error occurs, the RNG stops generating
+ * random numbers and sets to “1” both SEIS and SECS bits to indicate
+ * that a seed error occurred. (...)
+ *
+ * The following sequence shall be used to fully recover from a seed
+ * error after the RNG initialization:
+ * 1. Clear the SEIS bit by writing it to “0”.
+ * 2. Read out 12 words from the RNG_DR register, and discard each of
+ * them in order to clean the pipeline.
+ * 3. Confirm that SEIS is still cleared. Random number generation is
+ * back to normal.
+ */
+static int stm32_rng_conceal_seed_error_sw_reset(struct stm32_rng_plat *pdata)
+{
+ uint i = 0;
+ u32 sr = readl_relaxed(pdata->base + RNG_SR);
+
+ writel_relaxed(sr & ~RNG_SR_SEIS, pdata->base + RNG_SR);
+
+ for (i = 12; i != 0; i--)
+ (void)readl_relaxed(pdata->base + RNG_DR);
+
+ if (readl_relaxed(pdata->base + RNG_SR) & RNG_SR_SEIS)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int stm32_rng_conceal_seed_error(struct stm32_rng_plat *pdata)
+{
+ log_debug("Concealing RNG seed error\n");
+
+ if (pdata->data->has_cond_reset)
+ return stm32_rng_conceal_seed_error_cond_reset(pdata);
+ else
+ return stm32_rng_conceal_seed_error_sw_reset(pdata);
+};
+
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
{
- int retval, i;
- u32 sr, count, reg;
+ int retval;
+ u32 sr, reg;
size_t increment;
struct stm32_rng_plat *pdata = dev_get_plat(dev);
+ uint tries = 0;
while (len > 0) {
retval = readl_poll_timeout(pdata->base + RNG_SR, sr,
- sr & RNG_SR_DRDY, 1);
- if (retval)
+
[PATCH 6/7] rng: stm32: Implement custom RNG configuration support
STM32 RNG configuration should best fit the requirements of the
platform. Therefore, put a platform-specific RNG configuration
field in the platform data. Default RNG configuration for STM32MP13
is the NIST certified configuration [1].
While there, fix and the RNG init sequence to support all RNG
versions.
[1]
https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/53
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 54 ++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index b1a790b217..c397b4d95c 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -21,8 +21,15 @@
#define RNG_CR 0x00
#define RNG_CR_RNGEN BIT(2)
#define RNG_CR_CED BIT(5)
+#define RNG_CR_CONFIG1 GENMASK(11, 8)
+#define RNG_CR_NISTC BIT(12)
+#define RNG_CR_CONFIG2 GENMASK(15, 13)
#define RNG_CR_CLKDIV_SHIFT16
+#define RNG_CR_CLKDIV GENMASK(19, 16)
+#define RNG_CR_CONFIG3 GENMASK(25, 20)
#define RNG_CR_CONDRST BIT(30)
+#define RNG_CR_ENTROPY_SRC_MASK(RNG_CR_CONFIG1 | RNG_CR_NISTC |
RNG_CR_CONFIG2 | RNG_CR_CONFIG3)
+#define RNG_CR_CONFIG_MASK (RNG_CR_ENTROPY_SRC_MASK | RNG_CR_CED |
RNG_CR_CLKDIV)
#define RNG_SR 0x04
#define RNG_SR_SEISBIT(6)
@@ -32,17 +39,28 @@
#define RNG_DR 0x08
+#define RNG_NSCR 0x0C
+#define RNG_NSCR_MASK GENMASK(17, 0)
+
+#define RNG_HTCR 0x10
+
#define RNG_NB_RECOVER_TRIES 3
/*
* struct stm32_rng_data - RNG compat data
*
* @max_clock_rate:Max RNG clock frequency, in Hertz
+ * @cr:Entropy source configuration
+ * @nscr: Noice sources control configuration
+ * @htcr: Health tests configuration
* @has_cond_reset:True if conditionnal reset is supported
*
*/
struct stm32_rng_data {
uint max_clock_rate;
+ u32 cr;
+ u32 nscr;
+ u32 htcr;
bool has_cond_reset;
};
@@ -244,28 +262,48 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
- if (pdata->data->has_cond_reset) {
+ /*
+* Keep default RNG configuration if none was specified, that is when
conf.cr is set to 0.
+*/
+ if (pdata->data->has_cond_reset && pdata->data->cr) {
uint clock_div = stm32_rng_clock_freq_restrain(pdata);
- cr |= RNG_CR_CONDRST | (clock_div << RNG_CR_CLKDIV_SHIFT);
+ cr &= ~RNG_CR_CONFIG_MASK;
+ cr |= RNG_CR_CONDRST | (pdata->data->cr &
RNG_CR_ENTROPY_SRC_MASK) |
+ (clock_div << RNG_CR_CLKDIV_SHIFT);
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
+
+ /* Health tests and noise control registers */
+ writel_relaxed(pdata->data->htcr, pdata->base + RNG_HTCR);
+ writel_relaxed(pdata->data->nscr & RNG_NSCR_MASK, pdata->base +
RNG_NSCR);
+
cr &= ~RNG_CR_CONDRST;
cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
- if (err)
+ if (err) {
+ log_err("%s: Timeout!", __func__);
return err;
+ }
} else {
+ if (pdata->data->has_cond_reset)
+ cr |= RNG_CR_CONDRST;
+
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
cr |= RNG_CR_CED;
+ writel(cr, pdata->base + RNG_CR);
+
+ if (pdata->data->has_cond_reset)
+ cr &= ~RNG_CR_CONDRST;
+
cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
@@ -276,6 +314,9 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
+ if (err)
+ log_err("%s: Timeout!", __func__);
+
return err;
}
@@ -335,11 +376,18 @@ static const struct dm_rng_ops stm32_rng_ops = {
static const struct stm32_rng_data stm32mp13_rng_data = {
.has_cond_reset = true,
.max_clock_rate = 4800,
+ .htcr = 0x969D,
+ .nscr = 0x2B5BB,
+ .cr = 0xF00D00,
};
static const struct stm32_rng_data stm32_rng_data = {
.has_cond_reset = false,
.max_clock_rate = 300,
+ /* Not supported */
+ .htcr = 0,
+ .nscr = 0,
+ .cr = 0,
};
static const struct udevice_id stm32_rng_m
[PATCH 3/7] rng: stm32: Implement configurable RNG clock error detection
RNG clock error detection is now enabled if the "clock-error-detect"
property is set in the device tree.
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index 89da78c6c8..ada5d92214 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -40,6 +40,7 @@ struct stm32_rng_plat {
struct clk clk;
struct reset_ctl rst;
const struct stm32_rng_data *data;
+ bool ced;
};
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
@@ -97,25 +98,34 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
- /* Disable CED */
- cr |= RNG_CR_CED;
if (pdata->data->has_cond_reset) {
cr |= RNG_CR_CONDRST;
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
cr &= ~RNG_CR_CONDRST;
+ cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
if (err)
return err;
+ } else {
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
+
+ cr |= RNG_CR_RNGEN;
+
+ writel(cr, pdata->base + RNG_CR);
}
/* clear error indicators */
writel(0, pdata->base + RNG_SR);
- cr |= RNG_CR_RNGEN;
- writel(cr, pdata->base + RNG_CR);
-
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
return err;
@@ -165,6 +175,8 @@ static int stm32_rng_of_to_plat(struct udevice *dev)
if (err)
return err;
+ pdata->ced = dev_read_bool(dev, "clock-error-detect");
+
return 0;
}
--
2.25.1
[PATCH 4/7] rng: stm32: add RNG clock frequency restraint
In order to ensure a good RNG quality and compatibility with
certified RNG configuration, add RNG clock frequency restraint.
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 43 -
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index ada5d92214..f943acd7d2 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -18,10 +18,11 @@
#include
#include
-#define RNG_CR 0x00
-#define RNG_CR_RNGEN BIT(2)
-#define RNG_CR_CED BIT(5)
-#define RNG_CR_CONDRST BIT(30)
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+#define RNG_CR_CED BIT(5)
+#define RNG_CR_CLKDIV_SHIFT16
+#define RNG_CR_CONDRST BIT(30)
#define RNG_SR 0x04
#define RNG_SR_SEISBIT(6)
@@ -31,7 +32,15 @@
#define RNG_DR 0x08
+/*
+ * struct stm32_rng_data - RNG compat data
+ *
+ * @max_clock_rate:Max RNG clock frequency, in Hertz
+ * @has_cond_reset:True if conditionnal reset is supported
+ *
+ */
struct stm32_rng_data {
+ uint max_clock_rate;
bool has_cond_reset;
};
@@ -87,6 +96,26 @@ static int stm32_rng_read(struct udevice *dev, void *data,
size_t len)
return 0;
}
+static uint stm32_rng_clock_freq_restrain(struct stm32_rng_plat *pdata)
+{
+ ulong clock_rate = 0;
+ uint clock_div = 0;
+
+ clock_rate = clk_get_rate(&pdata->clk);
+
+ /*
+* Get the exponent to apply on the CLKDIV field in RNG_CR register.
+* No need to handle the case when clock-div > 0xF as it is physically
+* impossible.
+*/
+ while ((clock_rate >> clock_div) > pdata->data->max_clock_rate)
+ clock_div++;
+
+ log_debug("RNG clk rate : %lu\n", clk_get_rate(&pdata->clk) >>
clock_div);
+
+ return clock_div;
+}
+
static int stm32_rng_init(struct stm32_rng_plat *pdata)
{
int err;
@@ -99,7 +128,9 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
if (pdata->data->has_cond_reset) {
- cr |= RNG_CR_CONDRST;
+ uint clock_div = stm32_rng_clock_freq_restrain(pdata);
+
+ cr |= RNG_CR_CONDRST | (clock_div << RNG_CR_CLKDIV_SHIFT);
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
@@ -186,10 +217,12 @@ static const struct dm_rng_ops stm32_rng_ops = {
static const struct stm32_rng_data stm32mp13_rng_data = {
.has_cond_reset = true,
+ .max_clock_rate = 4800,
};
static const struct stm32_rng_data stm32_rng_data = {
.has_cond_reset = false,
+ .max_clock_rate = 300,
};
static const struct udevice_id stm32_rng_match[] = {
--
2.25.1
[PATCH 1/7] rng: stm32: rename STM32 RNG driver
Rename the RNG driver as it is usable by other STM32 platforms
than the STM32MP1x ones. Rename CONFIG_RNG_STM32MP1 to
CONFIG_RNG_STM32
Signed-off-by: Gatien Chevallier
---
MAINTAINERS | 2 +-
configs/stm32mp15_basic_defconfig | 2 +-
configs/stm32mp15_defconfig | 2 +-
configs/stm32mp15_trusted_defconfig | 2 +-
drivers/rng/Kconfig | 6 +++---
drivers/rng/Makefile| 2 +-
drivers/rng/{stm32mp1_rng.c => stm32_rng.c} | 0
7 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/rng/{stm32mp1_rng.c => stm32_rng.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0a10a436bc..a3bffa63d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -621,7 +621,7 @@ F: drivers/ram/stm32mp1/
F: drivers/remoteproc/stm32_copro.c
F: drivers/reset/stm32-reset.c
F: drivers/rng/optee_rng.c
-F: drivers/rng/stm32mp1_rng.c
+F: drivers/rng/stm32_rng.c
F: drivers/rtc/stm32_rtc.c
F: drivers/serial/serial_stm32.*
F: drivers/spi/stm32_qspi.c
diff --git a/configs/stm32mp15_basic_defconfig
b/configs/stm32mp15_basic_defconfig
index 9ea5aaa714..29b869cf34 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -150,7 +150,7 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y
CONFIG_DM_REGULATOR_STPMIC1=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index 4d0a81f8a8..b061a83f9d 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -123,7 +123,7 @@ CONFIG_DM_REGULATOR_SCMI=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/configs/stm32mp15_trusted_defconfig
b/configs/stm32mp15_trusted_defconfig
index 0a7d862485..b51eefe652 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -123,7 +123,7 @@ CONFIG_DM_REGULATOR_STPMIC1=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index 5deb5db5b7..1563ff3ab8 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -48,11 +48,11 @@ config RNG_OPTEE
accessible to normal world but reserved and used by the OP-TEE
to avoid the weakness of a software PRNG.
-config RNG_STM32MP1
- bool "Enable random number generator for STM32MP1"
+config RNG_STM32
+ bool "Enable random number generator for STM32"
depends on ARCH_STM32MP
help
- Enable STM32MP1 rng driver.
+ Enable STM32 rng driver.
config RNG_ROCKCHIP
bool "Enable random number generator for rockchip crypto rng"
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 78f61051ac..192f911e15 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
obj-$(CONFIG_RNG_MSM) += msm_rng.o
obj-$(CONFIG_RNG_NPCM) += npcm_rng.o
obj-$(CONFIG_RNG_OPTEE) += optee_rng.o
-obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
+obj-$(CONFIG_RNG_STM32) += stm32_rng.o
obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
diff --git a/drivers/rng/stm32mp1_rng.c b/drivers/rng/stm32_rng.c
similarity index 100%
rename from drivers/rng/stm32mp1_rng.c
rename to drivers/rng/stm32_rng.c
--
2.25.1
[PATCH 2/7] configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms
Default embed this configuration. If OP-TEE PTA RNG is present as well, the priority will be given to it instead of the U-Boot driver. Signed-off-by: Gatien Chevallier --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 82b62744f6..4a899c85de 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -65,6 +65,7 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_SCMI=y CONFIG_RESET_SCMI=y CONFIG_DM_RNG=y +CONFIG_RNG_STM32=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y -- 2.25.1
Re: [PATCH v2 3/4] cmd: kaslrseed: Use common API to fixup FDT
On Thu, Aug 31, 2023 at 01:02:02PM -0600, Simon Glass wrote:
> Hi Sean,
>
> On Tue, 29 Aug 2023 at 14:37, wrote:
> >
> > From: Sean Edmond
> >
> > Use the newly introduced common API fdt_fixup_kaslr_seed() in the
> > kaslrseed command.
> >
> > Signed-off-by: Sean Edmond
> > ---
> > cmd/kaslrseed.c | 22 --
> > 1 file changed, 8 insertions(+), 14 deletions(-)
> >
> > diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
> > index 8a1d8120cd..c65607619b 100644
> > --- a/cmd/kaslrseed.c
> > +++ b/cmd/kaslrseed.c
> > @@ -19,7 +19,7 @@ static int do_kaslr_seed(struct cmd_tbl *cmdtp, int flag,
> > int argc, char *const
> > size_t n = 0x8;
> > struct udevice *dev;
> > u64 *buf;
> > - int nodeoffset;
> > + ofnode root;
> > int ret = CMD_RET_SUCCESS;
> >
> > if (uclass_get_device(UCLASS_RNG, 0, &dev) || !dev) {
> > @@ -45,21 +45,15 @@ static int do_kaslr_seed(struct cmd_tbl *cmdtp, int
> > flag, int argc, char *const
> > return CMD_RET_FAILURE;
> > }
> >
> > - ret = fdt_check_header(working_fdt);
> > - if (ret < 0) {
> > - printf("fdt_chosen: %s\n", fdt_strerror(ret));
> > - return CMD_RET_FAILURE;
> > - }
> > -
> > - nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
> > - if (nodeoffset < 0) {
> > - printf("Reading chosen node failed\n");
> > - return CMD_RET_FAILURE;
> > + ret = root_ofnode_from_fdt(working_fdt, &root);
> > + if (ret) {
> > + printf("ERROR: Unable to get root ofnode\n");
> > + goto CMD_RET_FAILURE;
> > }
> >
> > - ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
> > sizeof(buf));
> > - if (ret < 0) {
> > - printf("Unable to set kaslr-seed on chosen node: %s\n",
> > fdt_strerror(ret));
> > + ret = fdt_fixup_kaslr_seed(root, buf, sizeof(buf));
> > + if (ret) {
> > + printf("ERROR: failed to add kaslr-seed to fdt\n");
> > return CMD_RET_FAILURE;
> > }
>
> Reviewed-by: Simon Glass
>
> So this command is intended to be used in a script? I am just trying
> to understand why we have the fixup code as well as this.
>
> Regards,
> Simon
This command is intended to be used in a script, I wrote it as a
command a while ago and thought it might be useful for others so I
pushed it upstream. Since then I've started applying a kaslrseed value
with a fixup (basically copying what the rng-seed fixup does) so I
don't have to do anything special with my boot.scr files.
I'm perfectly fine with either eliminating this command all together,
or making it use a software RNG (again I can't speak to the security
implications of this, as I'm not a security guy). I can just start
adding the kaslr-seed in the board files anyway.
Thank you,
Chris
[PATCH v2 7/7] arm: dts: k3-j721e: Sync with v6.5-rc1
Sync k3-j721e DTS with kernel.org v6.5-rc1.
Signed-off-by: Neha Malcom Francis
---
.../k3-j721e-common-proc-board-u-boot.dtsi| 146 +--
arch/arm/dts/k3-j721e-common-proc-board.dts | 483 ++---
arch/arm/dts/k3-j721e-main.dtsi | 974 --
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 280 -
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 302 +-
arch/arm/dts/k3-j721e-r5-sk.dts | 522 +-
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 177 +---
arch/arm/dts/k3-j721e-sk.dts | 663 +---
arch/arm/dts/k3-j721e-som-p0.dtsi | 226 ++--
arch/arm/dts/k3-j721e-thermal.dtsi| 75 ++
arch/arm/dts/k3-j721e.dtsi| 32 +-
11 files changed, 2365 insertions(+), 1515 deletions(-)
create mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 540c847eb3..4cca01be61 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -7,15 +7,7 @@
#include "k3-j721e-binman.dtsi"
/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer = &timer1;
- };
-
aliases {
- ethernet0 = &cpsw_port1;
- spi0 = &ospi0;
- spi1 = &ospi1;
remoteproc0 = &mcu_r5fss0_core0;
remoteproc1 = &mcu_r5fss0_core1;
remoteproc2 = &main_r5fss0_core0;
@@ -25,61 +17,49 @@
remoteproc6 = &c66_0;
remoteproc7 = &c66_1;
remoteproc8 = &c71_0;
- i2c0 = &wkup_i2c0;
- i2c1 = &mcu_i2c0;
- i2c2 = &mcu_i2c1;
- i2c3 = &main_i2c0;
};
};
-&cbass_main{
+&cbass_main {
bootph-pre-ram;
+};
- main_navss: bus@3000 {
- bootph-pre-ram;
- };
+&main_navss {
+ bootph-pre-ram;
};
&cbass_mcu_wakeup {
bootph-pre-ram;
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
+ chipid@4314 {
bootph-pre-ram;
};
+};
- mcu_navss: bus@2838 {
- bootph-pre-ram;
+&mcu_navss {
+ bootph-pre-ram;
+};
- ringacc@2b80 {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg",
"proxy_target", "cfg";
- bootph-pre-ram;
- };
-
- dma-controller@285c {
- reg = <0x0 0x285c 0x0 0x100>,
- <0x0 0x284c 0x0 0x4000>,
- <0x0 0x2a80 0x0 0x4>,
- <0x0 0x284a 0x0 0x4000>,
- <0x0 0x2aa0 0x0 0x4>,
- <0x0 0x2840 0x0 0x2000>;
- reg-names = "gcfg", "rchan", "rchanrt", "tchan",
- "tchanrt", "rflow";
- bootph-pre-ram;
- };
- };
+&mcu_ringacc {
+ reg = <0x0 0x2b80 0x0 0x40>,
+ <0x0 0x2b00 0x0 0x40>,
+ <0x0 0x2859 0x0 0x100>,
+ <0x0 0x2a50 0x0 0x4>,
+ <0x0 0x2844 0x0 0x4>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
+ bootph-pre-ram;
+};
- chipid@4314 {
- bootph-pre-ram;
- };
+&mcu_udmap {
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x284c 0x0 0x4000>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x284a 0x0 0x4000>,
+ <0x0 0x2aa0 0x0 0x4>,
+ <0x0 0x2840 0x0 0x2000>;
+ reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+ "tchanrt", "rflow";
+ bootph-pre-ram;
};
&secure_proxy_main {
@@ -130,9 +110,16 @@
bootph-pre-ram;
};
-&wiz3_pll1_refclk {
- assigned-clocks = <&wiz3_pll1_refclk>, <&wiz3_pll0_refclk>;
- assigned-clock-parents = <&k3_clks 295 0>, <&k3_clks 295 9>;
+&wkup_uart0_pins_default {
+ bootph-pre-ram;
+};
+
+&mcu_uart0_pins_default {
+ bootph-pre-ram;
+};
+
+&main_uart0_pins_default {
+ bootph-pre-ram;
};
&main_usbss0_pins_default {
@@ -148,19 +135,6 @@
bootph-pre-ram;
};
-&mcu_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0
Re: [PATCH v2 1/4] buildman: Keep all common output files
On Thu, Sep 07, 2023 at 10:00:17AM -0600, Simon Glass wrote: > Make a list of common output extensions and use it to ensure that the -k > option preserves all of these. > > Signed-off-by: Simon Glass > Suggested-by: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 4/4] memory: Add ECC properties
On Wed, Aug 30, 2023 at 6:18 PM Simon Glass wrote: > > 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 typo > + 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 I don't think 'multi' is specific enough. Perhaps this should be an int instead with how many bits. (And '-bits' is a standard unit suffix so a type isn't needed) > + > + If not present, this is equivalent to 'none'. Can be expressed as schema: default: none Though if that's the default why have it as a value? (It's fine though) > + 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 typo > + 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'. One issue is with 2 properties nonsensical combinations are allowed. Not really any way to handle that in the schema though. Rob
[PATCH 1/1] test: build dependency for event unit tests
The test_event_base and test_event_probe unit tests use function
event_register() which depends on CONFIG_EVENT_DYNAMIC=y.
Fixes: 7d02645fe4c0 ("event: Add a simple test")
Signed-off-by: Heinrich Schuchardt
---
test/common/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/common/Makefile b/test/common/Makefile
index a5ab10f6f6..12c65f8c95 100644
--- a/test/common/Makefile
+++ b/test/common/Makefile
@@ -2,5 +2,5 @@
obj-y += cmd_ut_common.o
obj-$(CONFIG_AUTOBOOT) += test_autoboot.o
obj-$(CONFIG_CYCLIC) += cyclic.o
-obj-$(CONFIG_EVENT) += event.o
+obj-$(CONFIG_EVENT_DYNAMIC) += event.o
obj-y += cread.o
--
2.40.1
Re: [PATCH v5 1/4] Add reserved-memory
On Wed, Aug 30, 2023 at 6:18 PM Simon Glass wrote: > > 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 I've applied this one and patch 2. Rob
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
On Thu, 7 Sept 2023 at 17:57, Simon Glass wrote: > > Hi Ard, > > On Thu, 7 Sept 2023 at 09:07, Ard Biesheuvel wrote: > > > > On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote: > > > > > > Hi Ard, > > > > > > On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel wrote: > > > > > > > > On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote: > > > > > > > > > > Hi Ard, > > > > > > > > > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel wrote: > > > > > > ... > > > > > > > > > > > > I'm happy to help flesh this out, but you still have not provided us > > > > > > with an actual use case, so I can only draw from my own experience > > > > > > putting together firmware for virtual and physical ARM machines. > > > > > > > > > > I did explain that this is needed when Tianocore is on both sides of > > > > > the interface, since Platform Init places some things in memory and > > > > > the Payload needs to preserve them there, and/or know where they are. > > > > > > > > > > I think the problem might be that you don't agree with that, but it > > > > > seems to be a fact, so I am not sure how I can alter it. > > > > > > > > > > Please can you clearly explain which part of the use case you are > > > > > missing. > > > > > > > > > > > > > 'Tianocore on both sides of the interface' means that Tianocore runs > > > > as the platform init code, and uses a bespoke DT based protocol to > > > > launch another instance of Tianocore as the payload, right? > > > > > > Not another instance, no. Just the other half of Tianocore. The first > > > half does platform init and the second half does the loading of the > > > OS. > > > > > > > That doesn't make any sense to me. > > > > > > > > > > Tianocore/EDK2 already implements methods to reinvoke itself if needed > > > > (e.g., during a firmware update), and does so by launching a new DXE > > > > core. So the boot sequence looks like > > > > > > > > SEC -> PEI -> DXE -> BDS -> app that invokes UpdateCapsule() -> DXE -> > > > > firmware update > > > > > > > > So please elaborate on how this Tianocore on both sides of the > > > > interface is put together when it uses this DT based handover. We > > > > really need a better understanding of this in order to design a DT > > > > binding that meets its needs. > > > > > > Are you familiar with building Tianocore as a coreboot payload, for > > > example? That shows Tianocore running as just the Payload, with > > > coreboot doing the platform init. So the use case I am talking about > > > is similar to that. > > > > > > > Yes I am familiar with that, and it is a completely different thing. > > Right, but that is my use case. > OK. You alluded to Tianocore <-> Tianocore being your use case, which is why I kept asking for clarification, as using a DT with this binding seems unusual at the very least. So coreboot does the platform init, and then hands over to Tianocore. I take it we are not talking about x86 here, so there are no Intel FSP blobs that may have dependencies on Tianocore/EDK2 pieces, right? So there are no UEFI semantics in the memory descriptions that coreboot provides to Tianocore. So coreboot provides information to TIanocore about - the platform topology (DT as usual) - DRAM memory banks - memory reservations - secure firmware services perhaps? - anything else? > > > > As i explained before, there is already prior art for this in > > Tianocore, i.e., launching a Tianocore build based on a DT description > > of the platform, including /memory and /reserved-memory nodes. > > By prior art do you mean code, or an existing binding? In either case, > can you please point me to it? Is this a generic binding used on x86 > as well, or just for ARM? > > My goal here is to augment the binding. > No I mean code. There is https://github.com/tianocore/edk2/tree/master/EmbeddedPkg/Drivers/FdtClientDxe which encapsulates the DT received from the previous boot stage, and exposes it as a DXE protocol. There are other drivers that depend on this protocol, e.g., to discover additional memory nodes, virtio-mmio drivers and PCI host bridges. https://github.com/tianocore/edk2/tree/master/OvmfPkg/Fdt The bindings used are the ones documented in the Linux kernel tree - no ad-hoc bindings are being used as far as I know. But the point I was making before re prior art was really about using existing bindings rather than inventing new ones. Since we are now talking about augmenting /reserved-memory, I think we're already on the same page in this regard (with the caveat that the EDK2 code does not actually honour /reserved-memory at this point, but this is because none of the platforms it is being used on today uses that node) > > > > I argued that Tianocore never consumes memory reservations with UEFI > > semantics, given that it supplants whatever UEFI functionality the > > previous stage may have provided. But it shouldn't step on the code > > and data regions used by the previous stage if it is still running in > > the background (e.g., OS at EL1 and PSCI a
[PATCH v2 4/4] kontron_sl28: Use u-boot-update.bin instead of u-boot.update
A '.update' extension does not get preserved by buildman, so change it.
Signed-off-by: Simon Glass
Acked-by: Michael Walle
---
(no changes since v1)
arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 2 +-
doc/board/kontron/sl28.rst| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 83750ab001b2..aacf181e2dd0 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -64,7 +64,7 @@
&binman {
u-boot-update {
- filename = "u-boot.update";
+ filename = "u-boot-update.bin";
fit {
description = "FIT update image";
diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst
index 44435d90c624..2cb8ec62be42 100644
--- a/doc/board/kontron/sl28.rst
+++ b/doc/board/kontron/sl28.rst
@@ -39,12 +39,12 @@ Update image
After the build finished, there will be an update image called
-u-boot.update. This can either be used in the DFU mode (which isn't
+u-boot-update.bin. This can either be used in the DFU mode (which isn't
supported yet) or encapsulated in an EFI UpdateCapsule.
To build the capsule use the following command
- $ tools/mkeficapsule -f u-boot.update -i 1 UpdateUboot
+ $ tools/mkeficapsule -f u-boot-update.bin -i 1 UpdateUboot
Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/
folder. On the next EFI boot this will automatically update your
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 2/4] buildman: Show progress when regenerating the board.cfg file
This can take a while, so show a message when starting.
Signed-off-by: Simon Glass
Reported-by Tom Rini
---
(no changes since v1)
tools/buildman/boards.py | 15 ---
tools/buildman/control.py | 3 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index eef3f19f7ad6..341a5056dfd2 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -19,6 +19,7 @@ import time
from buildman import board
from buildman import kconfiglib
+from u_boot_pylib.terminal import print_clear, tprint
### constant variables ###
OUTPUT_FILE = 'boards.cfg'
@@ -863,11 +864,19 @@ class Boards:
Returns:
bool: True if all is well, False if there were warnings
"""
-if not force and output_is_new(output, CONFIG_DIR, '.'):
+if not force:
if not quiet:
-print(f'{output} is up to date. Nothing to do.')
-return True
+tprint('\rChecking for Kconfig changes...', newline=False)
+is_new = output_is_new(output, CONFIG_DIR, '.')
+print_clear()
+if is_new:
+if not quiet:
+print(f'{output} is up to date. Nothing to do.')
+return True
+if not quiet:
+tprint('\rGenerating board list...', newline=False)
params_list, warnings = self.build_board_list(CONFIG_DIR, '.', jobs)
+print_clear()
for warn in warnings:
print(warn, file=sys.stderr)
self.format_and_output(params_list, output)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index f2ffb7f5b4aa..8f6850c52113 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -621,7 +621,8 @@ def do_buildman(args, toolchains=None, make_func=None,
brds=None,
if not brds:
brds = get_boards_obj(output_dir, args.regen_board_list,
args.maintainer_check, args.full_check,
- args.threads, args.verbose)
+ args.threads, args.verbose and
+ not args.print_arch and not args.print_prefix)
if isinstance(brds, int):
return brds
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 1/4] buildman: Keep all common output files
Make a list of common output extensions and use it to ensure that the -k
option preserves all of these.
Signed-off-by: Simon Glass
Suggested-by: Tom Rini
---
Changes in v2:
- Redo patch based on dropping the binman restriction
tools/buildman/builderthread.py | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 25f460c207db..6a61f64da1d4 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -23,6 +23,9 @@ from u_boot_pylib import command
RETURN_CODE_RETRY = -1
BASE_ELF_FILENAMES = ['u-boot', 'spl/u-boot-spl', 'tpl/u-boot-tpl']
+# Common extensions for images
+COMMON_EXTS = ['.bin', '.rom', '.itb', '.img']
+
def mkdir(dirname, parents=False):
"""Make a directory if it doesn't already exist.
@@ -636,10 +639,11 @@ class BuilderThread(threading.Thread):
# Now write the actual build output
if keep_outputs:
-copy_files(
-result.out_dir, build_dir, '',
-['u-boot*', '*.bin', '*.map', '*.img', 'MLO', 'SPL',
- 'include/autoconf.mk', 'spl/u-boot-spl*'])
+to_copy = ['u-boot*', '*.map', 'MLO', 'SPL',
+ 'include/autoconf.mk', 'spl/u-boot-spl*',
+ 'tpl/u-boot-tpl*', 'vpl/u-boot-vpl*']
+to_copy += [f'*{ext}' for ext in COMMON_EXTS]
+copy_files(result.out_dir, build_dir, '', to_copy)
def _send_result(self, result):
"""Send a result to the builder for processing
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 3/4] buildman: Start the clock when the build starts
The Kconfig and maintainer processing can take a while, sometimes 5
seconds or more. This skews the timing printed by buildmand when the build
completes. Start the clock when the threads start to avoid this problem.
Signed-off-by: Simon Glass
Suggested-by: Tom Rini
---
(no changes since v1)
tools/buildman/builder.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index ecbd368c47a5..5305477c5be6 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -328,7 +328,7 @@ class Builder:
self._build_period_us = None
self._complete_delay = None
self._next_delay_update = datetime.now()
-self._start_time = datetime.now()
+self._start_time = None
self._step = step
self._error_lines = 0
self.no_subdirs = no_subdirs
@@ -1778,6 +1778,7 @@ class Builder:
self._prepare_output_space()
if not self._ide:
tprint('\rStarting build...', newline=False)
+self._start_time = datetime.now()
self.setup_build(board_selected, commits)
self.process_result(None)
self.thread_exceptions = []
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 0/4] Attempt to collect standard extensions for build output
We would like 'buildman -k' to keep the build outputs. This series tries to do this by adding more common extensions to the list. It also includes a few minor fixes. Changes in v2: - Redo patch based on dropping the binman restriction Simon Glass (4): buildman: Keep all common output files buildman: Show progress when regenerating the board.cfg file buildman: Start the clock when the build starts kontron_sl28: Use u-boot-update.bin instead of u-boot.update arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 2 +- doc/board/kontron/sl28.rst| 4 ++-- tools/buildman/boards.py | 15 --- tools/buildman/builder.py | 3 ++- tools/buildman/builderthread.py | 12 tools/buildman/control.py | 3 ++- 6 files changed, 27 insertions(+), 12 deletions(-) -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 22/22] 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 v3) Changes in v3: - Drop patch 'Move SYS_RX_ETH_BUFFER into the network menu' boot/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 235c5a7a9933..a01e6cb8aafe 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 if OF_LIBFDT - 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 @@ -1490,6 +1482,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.283.g2d96d420d3-goog
[PATCH v4 21/22] boot: Drop CMD_MTDPARTS condition for FDT_FIXUP_PARTITIONS
This is not needed, so drop it. Also use a capital 'O' for the option, while we are here. Signed-off-by: Simon Glass Suggested-by: Tom Rini --- (no changes since v3) Changes in v3: - Add new patch to drop CMD_MTDPARTS condition for FDT_FIXUP_PARTITIONS boot/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index a1592a74e624..235c5a7a9933 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -1476,8 +1476,7 @@ config OF_STDOUT_VIA_ALIAS exist / should not be used. config FDT_FIXUP_PARTITIONS - bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" - depends on CMD_MTDPARTS + bool "Overwrite MTD partitions in DTS through defined in 'mtdparts'" help Allow overwriting defined partitions in the device tree blob using partition info defined in the 'mtdparts' environment -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 20/22] 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 2dd05e2e1661..a1592a74e624 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -1475,6 +1475,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.283.g2d96d420d3-goog
[PATCH v4 19/22] Make ARCH_FIXUP_FDT_MEMORY depend on OF_LIBFDT
We need CONFIG_OF_LIBFDT to be able to do fdt fixups, so add that condition. Signed-off-by: Simon Glass --- Changes in v4: - Add new patch to make ARCH_FIXUP_FDT_MEMORY depend on OF_LIBFDT boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 7ef44a26fb92..2dd05e2e1661 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -695,7 +695,7 @@ config SUPPORT_RAW_INITRD config ARCH_FIXUP_FDT_MEMORY bool "Enable arch_fixup_memory_banks() call" - default y + default y if OF_LIBFDT 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 -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 18/22] 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 --- (no changes since v3) Changes in v3: - Drop extra newline and quote 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| 6 +- doc/develop/bootstd.rst | 23 +++ 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 4ebcf3109113..7ef44a26fb92 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,10 @@ 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 e8b90752f083..6172dc906bde 100644 --- a/doc/develop/bootstd.rst +++ b/doc/develop/bootstd.rst @@ -464,6 +464,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 --- @@ -775,3 +797,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.283.g2d96d420d3-goog
[PATCH v4 17/22] 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 a885fea692f6..4ebcf3109113 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 v4 16/22] 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 9b09d636d057..a885fea692f6 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.283.g2d96d420d3-goog
[PATCH v4 15/22] 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 f564cb8dd84c..9b09d636d057 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.283.g2d96d420d3-goog
[PATCH v4 14/22] spl: Drop SPL/TPL_RAM_SUPPORT option for SPL_LOAD_FIT_ADDRESS
All boards which actually define this address enable SPL_LOAD_FIT, or at least just rely on the default value of 0. So drop the dependency. Signed-off-by: Simon Glass --- Changes in v4: - Add new patch to drop SPL/TPL_RAM_SUPPORT option for SPL_LOAD_FIT_ADDRESS boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 99a2ffca2fc6..f564cb8dd84c 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -217,7 +217,7 @@ config SPL_LOAD_FIT config SPL_LOAD_FIT_ADDRESS hex "load address of fit image" - depends on SPL_LOAD_FIT || SPL_RAM_SUPPORT || TPL_RAM_SUPPORT + depends on SPL_LOAD_FIT default 0x0 help Specify the load address of the fit image that will be loaded -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 11/22] 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 f8b8d6089511..017f7117d57f 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.283.g2d96d420d3-goog
[PATCH v4 13/22] 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.283.g2d96d420d3-goog
[PATCH v4 12/22] 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'. Leave CONFIG_TIMESTAMP out since it affects legacy images too. Signed-off-by: Simon Glass --- Changes in v4: - Allow TIMESTAMP without FIT boot/Kconfig | 38 ++ 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 017f7117d57f..99a2ffca2fc6 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -9,8 +9,19 @@ config ANDROID_BOOT_IMAGE This enables support for booting images which use the Android image format header. -config FIT - bool "Support Flattened Image Tree" +config TIMESTAMP + bool "Show image date and time when displaying image information" + default y if CMD_DATE + help + When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of + an image is printed by image commands like bootm or iminfo. This + is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is + enabled, then U-Boot requires FITs to have a timestamp. If a FIT is + loaded that does not, the message 'Wrong FIT format: no timestamp' + is shown. + +menuconfig FIT + bool "Flattened Image Tree (FIT)" select HASH select MD5 select SHA1 @@ -25,20 +36,10 @@ config FIT multiple configurations, verification through hashing and also verified boot (secure boot using RSA). -config TIMESTAMP - bool "Show image date and time when displaying image information" - default y if CMD_DATE - help - When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of - an image is printed by image commands like bootm or iminfo. This - is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is - enabled, then U-Boot requires FITs to have a timestamp. If a FIT is - loaded that does not, the message 'Wrong FIT format: no timestamp' - is shown. +if FIT 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.283.g2d96d420d3-goog
[PATCH v4 10/22] 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 39c51e9e2fe8..f8b8d6089511 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.283.g2d96d420d3-goog
[PATCH v4 09/22] 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 0a98f1e22207..39c51e9e2fe8 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 d11292f52c2b..21eaa5e815f9 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1157,14 +1157,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.283.g2d96d420d3-goog
[PATCH v4 08/22] 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.283.g2d96d420d3-goog
[PATCH v4 07/22] 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.283.g2d96d420d3-goog
[PATCH v4 06/22] FWU: Avoid showing an unselectable menu option
Use a menuconfig to avoid showing a menu which cannot be selected in many cases. Signed-off-by: Simon Glass Acked-by: Sughosh Ganu Reviewed-by: Tom Rini --- (no changes since v3) Changes in v3: - Drop comment about an update/ directory 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.283.g2d96d420d3-goog
[PATCH v4 05/22] 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) drivers/video/Kconfig | 11 +++ drivers/video/Makefile | 2 ++ 2 files changed, 13 insertions(+) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index ab927641bb7a..1ea820c68869 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" @@ -1125,6 +1130,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 6841d8965842..88b37b1855c6 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 -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 04/22] video: Move the BMP options
These appear prominently in the main menu at present. Move them to the video Kconfig where they belong. Signed-off-by: Simon Glass --- Changes in v4: - Just move these options to driver/video for later consideration common/Kconfig| 11 --- drivers/video/Kconfig | 16 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index d916194b9423..d11292f52c2b 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -1168,14 +1168,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/drivers/video/Kconfig b/drivers/video/Kconfig index 09f2cb1a7321..ab927641bb7a 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -959,6 +959,14 @@ config SPLASH_SOURCE endif # SPLASH_SCREEN +config BMP + bool "Enable bmp image display" + help + Enable bmp functions to display bmp image and get bmp info. + + BMP is a simple graphics-image file format designed to store bitmap + images. It is primarily used on Windows devices. + config VIDEO_BMP_GZIP bool "Gzip compressed BMP image support" depends on BMP || SPLASH_SCREEN @@ -1162,6 +1170,14 @@ config SPL_SPLASH_SOURCE endif # SPL_SPLASH_SCREEN +config SPL_BMP + bool "Enable bmp image display at SPL" + help + Enable bmp functions to display bmp image and get bmp info in SPL. + + BMP is a simple graphics-image file format designed to store bitmap + images. It is primarily used on Windows devices. + config SPL_VIDEO_BMP_GZIP bool "Gzip compressed BMP image support at SPL" depends on SPL_SPLASH_SCREEN || SPL_BMP -- 2.42.0.283.g2d96d420d3-goog
[PATCH v4 03/22] video: Move bmp code to drivers/video
This relates to graphics which is only active when CONFIG_VIDEO is
enabled. Move it into that directory.
There is no harm in compiling it always, since it if not used it will
be dropped by the linker. So drop use of the BMP Kconfig.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add new patch to move bmp code to drivers/video
common/Makefile | 1 -
drivers/video/Makefile | 1 +
{common => drivers/video}/bmp.c | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename {common => drivers/video}/bmp.c (100%)
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/Makefile b/drivers/video/Makefile
index d13af9f3b19b..6841d8965842 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PANEL_HX8238D) += hx8238d.o
obj-$(CONFIG_$(SPL_TPL_)SIMPLE_PANEL) += simple_panel.o
obj-$(CONFIG_VIDEO_LOGO) += u_boot_logo.o
+obj-y += bmp.o
endif
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.283.g2d96d420d3-goog
[PATCH v4 01/22] 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.283.g2d96d420d3-goog
[PATCH v4 02/22] 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.283.g2d96d420d3-goog
[PATCH v4 00/22] 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 v4:
- Just move these options to driver/video for later consideration
- Allow TIMESTAMP without FIT
- Add new patch to drop SPL/TPL_RAM_SUPPORT option for SPL_LOAD_FIT_ADDRESS
- Add new patch to make ARCH_FIXUP_FDT_MEMORY depend on OF_LIBFDT
Changes in v3:
- Drop comment about an update/ directory
- Drop extra newline and quote
- Add new patch to drop CMD_MTDPARTS condition for FDT_FIXUP_PARTITIONS
- Drop patch 'Move SYS_RX_ETH_BUFFER into the network menu'
Changes in v2:
- Add new patch to move bmp code to drivers/video
- 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 (22):
lib: rational: Move the Kconfigs into the correct place
Kconfig: Move API into general setup
video: Move bmp code to drivers/video
video: Move the BMP options
video: Move BMP options and code to video directory
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
spl: Tidy up load address in spl_ram
spl: Drop SPL/TPL_RAM_SUPPORT option for SPL_LOAD_FIT_ADDRESS
Kconfig: Move SPL_FIT under FIT
boot: Make standard boot a menu
Kconfig: Move TEXT_BASE et al under general setup
Mark DISTRO_DEFAULTS as deprecated
Make ARCH_FIXUP_FDT_MEMORY depend on OF_LIBFDT
boot: Join FDT_FIXUP_PARTITIONS with related options
boot: Drop CMD_MTDPARTS condition for FDT_FIXUP_PARTITIONS
boot: Join ARCH_FIXUP_FDT_MEMORY with related options
Kconfig | 67 +-
boot/Kconfig| 222 +---
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 | 27
drivers/video/Makefile | 3 +
{common => drivers/video}/bmp.c | 0
lib/Kconfig | 17 +--
lib/fwu_updates/Kconfig | 9 +-
test/Kconfig| 12 +-
15 files changed, 238 insertions(+), 189 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.283.g2d96d420d3-goog
[PATCH v2 9/9] x86: doc: Update the list of supported Chromebooks
One is missing, so add it. Also mention the SoC used in each. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) doc/arch/x86.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst index 725a1ae58639..89d3e7ba0e4b 100644 --- a/doc/arch/x86.rst +++ b/doc/arch/x86.rst @@ -25,12 +25,13 @@ are supported: - Bayley Bay CRB - Cherry Hill CRB - Congatec QEVAL 2.0 & conga-QA3/E3845 + - Coral (Apollo Lake - Chromebook 2017) - Cougar Canyon 2 CRB - Crown Bay CRB - Galileo - - Link (Chromebook Pixel) + - Link (Ivy Bridge - Chromebook Pixel) - Minnowboard MAX - - Samus (Chromebook Pixel 2015) + - Samus (Broadwell - Chromebook Pixel 2015) - QEMU x86 (32-bit & 64-bit) As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit -- 2.42.0.283.g2d96d420d3-goog
[PATCH v2 8/9] x86: dm: Mark driver model as dead when disabling CAR
When turning off CAR, set the flag to make sure that nothing tries to use
driver model in SPL before jumping to U-Bot proper, since its tables are
in CAR.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to mark driver model as dead when disabling CAR
arch/x86/lib/spl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index 335dacf47fd0..c15f11f8cdf4 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -230,6 +230,9 @@ void board_init_f_r(void)
mtrr_commit(false);
init_cache();
gd->flags &= ~GD_FLG_SERIAL_READY;
+
+ /* make sure driver model is not accessed from now on */
+ gd->flags |= GD_FLG_DM_DEAD;
debug("cache status %d\n", dcache_status());
board_init_r(gd, 0);
}
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 4/9] x86: samus_tpl: Correct text base and alloc sizes
Make sure that CONFIG_X86_OFFSET_U_BOOT is the same as CONFIG_TEXT_BASE as it is changing CONFIG_X86_OFFSET_U_BOOT Samus boots into U-Boot proper in flash, not RAM. Also expand the SPL malloc() size a little, to avoid an error. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v2: - Reword commit message for clarity and to fix typo configs/chromebook_samus_tpl_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/chromebook_samus_tpl_defconfig b/configs/chromebook_samus_tpl_defconfig index 33ada9fe4f93..9dd29401ef12 100644 --- a/configs/chromebook_samus_tpl_defconfig +++ b/configs/chromebook_samus_tpl_defconfig @@ -1,6 +1,8 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0xffed CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_TPL_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x3000 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x3F8000 @@ -19,7 +21,7 @@ CONFIG_HAVE_MRC=y CONFIG_HAVE_REFCODE=y CONFIG_SMP=y CONFIG_HAVE_VGA_BIOS=y -CONFIG_X86_OFFSET_U_BOOT=0xffee +CONFIG_X86_OFFSET_U_BOOT=0xffed CONFIG_SYS_MONITOR_BASE=0xFFED CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y -- 2.42.0.283.g2d96d420d3-goog
[PATCH v2 7/9] x86: broadwell: Set up MTRRs
The current condition does not handle the samus_tpl case where it sets
up the RAM in SPL but needs to commit the MTRRs in U-Boot proper.
Add another case to handle this and update the comment.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/lib/init_helpers.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 60a2707dcf1b..bf0c921577d1 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -15,7 +15,8 @@ DECLARE_GLOBAL_DATA_PTR;
int init_cache_f_r(void)
{
bool do_mtrr = CONFIG_IS_ENABLED(X86_32BIT_INIT) ||
-IS_ENABLED(CONFIG_FSP_VERSION2);
+IS_ENABLED(CONFIG_FSP_VERSION2) ||
+(IS_ENABLED(CONFIG_TPL) && IS_ENABLED(CONFIG_HAVE_MRC));
int ret;
/*
@@ -23,11 +24,9 @@ int init_cache_f_r(void)
*
* booting from slimbootloader - MTRRs are already set up
* booting with FSPv1 - MTRRs are already set up
-* booting with FSPv2 - MTRRs must be set here
+* booting with FSPv2 or MRC - MTRRs must be set here
* booting from coreboot - in this case there is no SPL, so we set up
* the MTRRs here
-* Note: if there is an SPL, then it has already set up MTRRs so we
-* don't need to do that here
*/
do_mtrr &= !IS_ENABLED(CONFIG_FSP_VERSION1) &&
!IS_ENABLED(CONFIG_SYS_SLIMBOOTLOADER);
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 6/9] x86: broadwell: Avoid initing the CPU twice
When TPL has already set up the CPU, don't do it again. This existing
code actually has this backwards, so fix it.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
(no changes since v1)
arch/x86/cpu/broadwell/cpu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
index 560b1f7893f6..cbd4a3b67973 100644
--- a/arch/x86/cpu/broadwell/cpu.c
+++ b/arch/x86/cpu/broadwell/cpu.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -67,12 +68,11 @@ int arch_cpu_init(void)
{
post_code(POST_CPU_INIT);
-#ifdef CONFIG_TPL
/* Do a mini-init if TPL has already done the full init */
- return x86_cpu_reinit_f();
-#else
- return x86_cpu_init_f();
-#endif
+ if (IS_ENABLED(CONFIG_TPL) && spl_phase() != PHASE_TPL)
+ return x86_cpu_reinit_f();
+ else
+ return x86_cpu_init_f();
}
int checkcpu(void)
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 5/9] x86: spl: Change the condition for copying U-Boot to RAM
Make this depend on whether the address matches the offset, rather than
a particular board build. For samus_tpl we don't need to copy, for
example.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
(no changes since v1)
arch/x86/lib/spl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index 58fa572b71ae..335dacf47fd0 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -258,7 +258,7 @@ static int spl_board_load_image(struct spl_image_info
*spl_image,
spl_image->os = IH_OS_U_BOOT;
spl_image->name = "U-Boot";
- if (!IS_ENABLED(CONFIG_SYS_COREBOOT)) {
+ if (spl_image->load_addr != spl_get_image_pos()) {
/* Copy U-Boot from ROM */
memcpy((void *)spl_image->load_addr,
(void *)spl_get_image_pos(), spl_get_image_size());
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 3/9] x86: Add some log categories
Add some missing log categories to a few files. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) arch/x86/cpu/broadwell/sdram.c | 2 ++ arch/x86/lib/tpl.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/x86/cpu/broadwell/sdram.c b/arch/x86/cpu/broadwell/sdram.c index f477d513efce..d30ebee021ea 100644 --- a/arch/x86/cpu/broadwell/sdram.c +++ b/arch/x86/cpu/broadwell/sdram.c @@ -5,6 +5,8 @@ * From coreboot src/soc/intel/broadwell/romstage/raminit.c */ +#define LOG_CATEGORY UCLASS_RAM + #include #include #include diff --git a/arch/x86/lib/tpl.c b/arch/x86/lib/tpl.c index 18b05b2f6720..273e9c8e1ca1 100644 --- a/arch/x86/lib/tpl.c +++ b/arch/x86/lib/tpl.c @@ -3,6 +3,8 @@ * Copyright (c) 2018 Google, Inc */ +#define LOG_CATEGORY LOGC_BOOT + #include #include #include -- 2.42.0.283.g2d96d420d3-goog
[PATCH v2 2/9] x86: broadwell: Show the memory delay
Samus only takes 7 seconds but it is long enough to think it has hung. Add
a message about what it is doing, similar to the approach on coral.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
(no changes since v1)
arch/x86/cpu/intel_common/mrc.c | 18 +-
arch/x86/dts/chromebook_samus.dts | 1 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/intel_common/mrc.c b/arch/x86/cpu/intel_common/mrc.c
index 56cc253831aa..ff959d1bd8d8 100644
--- a/arch/x86/cpu/intel_common/mrc.c
+++ b/arch/x86/cpu/intel_common/mrc.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -251,13 +252,28 @@ static int sdram_initialise(struct udevice *dev, struct
udevice *me_dev,
int mrc_common_init(struct udevice *dev, void *pei_data, bool use_asm_linkage)
{
struct udevice *me_dev;
- int ret;
+ int ret, delay;
ret = syscon_get_by_driver_data(X86_SYSCON_ME, &me_dev);
if (ret)
return ret;
+ delay = dev_read_u32_default(dev, "fspm,training-delay", 0);
+ if (spl_phase() == PHASE_SPL) {
+ if (delay)
+ printf("SDRAM training (%d seconds)...", delay);
+ else
+ log_debug("SDRAM init...");
+ } else {
+ if (delay)
+ printf("(%d seconds)...", delay);
+ }
+
ret = sdram_initialise(dev, me_dev, pei_data, use_asm_linkage);
+ if (delay)
+ printf("done\n");
+ else
+ log_debug("done\n");
if (ret)
return ret;
quick_ram_check();
diff --git a/arch/x86/dts/chromebook_samus.dts
b/arch/x86/dts/chromebook_samus.dts
index 96705ceed074..ddff277046a4 100644
--- a/arch/x86/dts/chromebook_samus.dts
+++ b/arch/x86/dts/chromebook_samus.dts
@@ -266,6 +266,7 @@
board-id-gpios = <&gpio_c 5 0>, <&gpio_c 4 0>,
<&gpio_c 3 0>, <&gpio_c 1 0>;
bootph-all;
+ fspm,training-delay = <7>;
spd {
#address-cells = <1>;
#size-cells = <0>;
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 1/9] dm: core: Allow marking driver model as dead
On x86 devices we use CAR (Cache-As-RAM) to hold the malloc() region in
SPL, since SDRAM is not set up yet. This means that driver model stores
its tables in this region.
When preparing to jump from SPL to U-Boot proper, we must disable CAR, so
that the CPU can uses the caches normally. This means that driver model
tables become inaccessible. From there until we jump to U-Boot proper, we
must avoid using driver model.
This is only a problem on boards which operate this way, for example
chromebook_link64
Add a flag to indicate that driver model is dead and should not be used.
It can be used in SPL to avoid hanging the machine.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to allow marking driver model as dead
common/spl/spl.c | 2 +-
include/asm-generic/global_data.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0062f3f45d9a..045a5e89625d 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -800,7 +800,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
IS_ENABLED(CONFIG_SPL_ATF))
dram_init_banksize();
- if (CONFIG_IS_ENABLED(PCI)) {
+ if (CONFIG_IS_ENABLED(PCI) && !(gd->flags & GD_FLG_DM_DEAD)) {
ret = pci_init();
if (ret)
puts(SPL_TPL_PROMPT "Cannot initialize PCI\n");
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 8fc205ded1a3..5b11cb17ac03 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -667,6 +667,11 @@ enum gd_flags {
* @GD_FLG_OF_TAG_MIGRATE: Device tree has old u-boot,dm- tags
*/
GD_FLG_OF_TAG_MIGRATE = 0x20,
+ /**
+* @GD_FLG_DM_DEAD: Driver model is not accessible. This can be set when
+* the memory used to holds its tables has been mapped out.
+*/
+ GD_FLG_DM_DEAD = 0x40,
};
#endif /* __ASSEMBLY__ */
--
2.42.0.283.g2d96d420d3-goog
[PATCH v2 0/9] x86: Fixes for chromebook_link64 and chromebook_samus_tpl
These boards have various problems which prevent them from booting. In the case of link there was a recent regression with PCI probing added to SPL. For samus_tpl it needs a few tweaks to get things back up and running. This series resolves all known issues. For v2, the 'Avoid starting up PCI automatically in SPL' patch has been replaced with a global_data flag. Changes in v2: - Add new patch to allow marking driver model as dead - Reword commit message for clarity and to fix typo - Add new patch to mark driver model as dead when disabling CAR Simon Glass (9): dm: core: Allow marking driver model as dead x86: broadwell: Show the memory delay x86: Add some log categories x86: samus_tpl: Correct text base and alloc sizes x86: spl: Change the condition for copying U-Boot to RAM x86: broadwell: Avoid initing the CPU twice x86: broadwell: Set up MTRRs x86: dm: Mark driver model as dead when disabling CAR x86: doc: Update the list of supported Chromebooks arch/x86/cpu/broadwell/cpu.c | 10 +- arch/x86/cpu/broadwell/sdram.c | 2 ++ arch/x86/cpu/intel_common/mrc.c| 18 +- arch/x86/dts/chromebook_samus.dts | 1 + arch/x86/lib/init_helpers.c| 7 +++ arch/x86/lib/spl.c | 5 - arch/x86/lib/tpl.c | 2 ++ common/spl/spl.c | 2 +- configs/chromebook_samus_tpl_defconfig | 4 +++- doc/arch/x86.rst | 5 +++-- include/asm-generic/global_data.h | 5 + 11 files changed, 46 insertions(+), 15 deletions(-) -- 2.42.0.283.g2d96d420d3-goog
Re: [PATCH 3/3] arm: dts: j7200: dtb sync with Linux 6.5-rc1
On 10:03-20230907, Manorit Chawdhry wrote:
> Hi Reid,
>
> On 13:13-20230905, Reid Tonking wrote:
> > Sync j7200 device tree files with Linux 6.5-rc1
> >
> > - k3-j7200-r5-common-proc-board.dts now inherits from
> > k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
> > allows us to trim down the r5 file considerably by using existing
> > properties.
> >
> > - remove pimux nodes from r5 file
> >
> > - remove duplicate nodes & node properties from r5/u-boot files
> >
> > - mcu_timer0 now used instead of timer1
> >
> > mcu_timer0 device id added to dev-data.c file in order to work
> >
> > - remove cpsw node
> >
> > This node is no longer required since the compatible is now fixed
> >
> > - remove dummy_clock_19_2_mhz
> >
> > This node wasn't being used anyhere, so it was removed.
> >
> > - remove dummy_clock_200mhz
> >
> > main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD
> >
> > - fix secure proxy node
> >
> > mcu_secproxy changed to used secure_prxy_mcu which is already
> > defined in k3-j7200-mcu-wakeup.dtsi
> >
> > Signed-off-by: Reid Tonking
> > ---
> > .../k3-j7200-common-proc-board-u-boot.dtsi| 160 +++---
> > arch/arm/dts/k3-j7200-common-proc-board.dts | 170 --
> > arch/arm/dts/k3-j7200-main.dtsi | 512 +-
> > arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 265 -
> > .../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +-
> > arch/arm/dts/k3-j7200-som-p0.dtsi | 153 --
> > arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++
> > arch/arm/dts/k3-j7200.dtsi| 30 +-
> > 8 files changed, 1150 insertions(+), 488 deletions(-)
> > create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
> >
> > diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > index f25c7136c9..c32df00e9c 100644
> > --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
[...]
> > @@ -78,10 +63,6 @@
> >
> > &dmsc {
> > bootph-pre-ram;
> > - k3_sysreset: sysreset-controller {
> > - compatible = "ti,sci-sysreset";
> > - bootph-pre-ram;
> > - };
>
> This is required for resetting the board in U-boot I believe, can only
> see the compatible present in U-boot.
>
> Regards,
> Manorit
>
Thanks for catching that, I'll add that back in for v3.
Thanks,
Reid
Re: [PATCH v2 3/4] cmd: kaslrseed: Use common API to fixup FDT
Hi Chris,
On Thu, 7 Sept 2023 at 09:45, Chris Morgan wrote:
>
> On Thu, Aug 31, 2023 at 01:02:02PM -0600, Simon Glass wrote:
> > Hi Sean,
> >
> > On Tue, 29 Aug 2023 at 14:37, wrote:
> > >
> > > From: Sean Edmond
> > >
> > > Use the newly introduced common API fdt_fixup_kaslr_seed() in the
> > > kaslrseed command.
> > >
> > > Signed-off-by: Sean Edmond
> > > ---
> > > cmd/kaslrseed.c | 22 --
> > > 1 file changed, 8 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
> > > index 8a1d8120cd..c65607619b 100644
> > > --- a/cmd/kaslrseed.c
> > > +++ b/cmd/kaslrseed.c
> > > @@ -19,7 +19,7 @@ static int do_kaslr_seed(struct cmd_tbl *cmdtp, int
> > > flag, int argc, char *const
> > > size_t n = 0x8;
> > > struct udevice *dev;
> > > u64 *buf;
> > > - int nodeoffset;
> > > + ofnode root;
> > > int ret = CMD_RET_SUCCESS;
> > >
> > > if (uclass_get_device(UCLASS_RNG, 0, &dev) || !dev) {
> > > @@ -45,21 +45,15 @@ static int do_kaslr_seed(struct cmd_tbl *cmdtp, int
> > > flag, int argc, char *const
> > > return CMD_RET_FAILURE;
> > > }
> > >
> > > - ret = fdt_check_header(working_fdt);
> > > - if (ret < 0) {
> > > - printf("fdt_chosen: %s\n", fdt_strerror(ret));
> > > - return CMD_RET_FAILURE;
> > > - }
> > > -
> > > - nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
> > > - if (nodeoffset < 0) {
> > > - printf("Reading chosen node failed\n");
> > > - return CMD_RET_FAILURE;
> > > + ret = root_ofnode_from_fdt(working_fdt, &root);
> > > + if (ret) {
> > > + printf("ERROR: Unable to get root ofnode\n");
> > > + goto CMD_RET_FAILURE;
> > > }
> > >
> > > - ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
> > > sizeof(buf));
> > > - if (ret < 0) {
> > > - printf("Unable to set kaslr-seed on chosen node: %s\n",
> > > fdt_strerror(ret));
> > > + ret = fdt_fixup_kaslr_seed(root, buf, sizeof(buf));
> > > + if (ret) {
> > > + printf("ERROR: failed to add kaslr-seed to fdt\n");
> > > return CMD_RET_FAILURE;
> > > }
> >
> > Reviewed-by: Simon Glass
> >
> > So this command is intended to be used in a script? I am just trying
> > to understand why we have the fixup code as well as this.
> >
> > Regards,
> > Simon
>
> This command is intended to be used in a script, I wrote it as a
> command a while ago and thought it might be useful for others so I
> pushed it upstream. Since then I've started applying a kaslrseed value
> with a fixup (basically copying what the rng-seed fixup does) so I
> don't have to do anything special with my boot.scr files.
>
> I'm perfectly fine with either eliminating this command all together,
> or making it use a software RNG (again I can't speak to the security
> implications of this, as I'm not a security guy). I can just start
> adding the kaslr-seed in the board files anyway.
The command seems fine to me.
Regards,
Simon
Re: [PATCH] cmd: xxd: move xxd into shell commands
On Thu, 7 Sept 2023 at 08:52, Roger Knecht wrote: > > Move xxd into shell command section. > > Signed-off-by: Roger Knecht > --- > cmd/Kconfig | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] global: Use proper project name U-Boot (next2)
On Thu, 7 Sept 2023 at 07:00, Michal Simek wrote:
>
> Use proper project name in README, rst and comment.
> Done in connection to commit bb922ca3eb4b ("global: Use proper project name
> U-Boot (next)").
>
> Signed-off-by: Michal Simek
> ---
>
> board/cobra5272/README | 18 +-
> board/emulation/qemu-ppce500/qemu-ppce500.c | 2 +-
> doc/board/xilinx/zynq.rst | 2 +-
> doc/board/xilinx/zynqmp-r5.rst | 4 ++--
> doc/imx/mkimage/imximage.txt| 2 +-
> doc/usage/environment.rst | 2 +-
> doc/usage/semihosting.rst | 2 +-
> tools/binman/entries.rst| 2 +-
> 8 files changed, 17 insertions(+), 17 deletions(-)
[..]
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index e7dfe6b2a363..a8c7423c4005 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -2505,7 +2505,7 @@ Properties / Entry arguments:
> See Entry_u_boot_ucode for full details of the three entries involved in
> this process. This entry updates U-Boot with the offset and size of the
> microcode, to allow early x86 boot code to find it without doing anything
> -complicated. Otherwise it is the same as the u-boot entry.
> +complicated. Otherwise it is the same as the U-Boot entry.
This is actually correct already, since it is the name of an entry type.
Regards,
Simon
Re: [PATCH] sandbox: test: Fix typo in test.dts
On Thu, 7 Sept 2023 at 06:56, Michal Simek wrote: > > s/parititon/partition/ > > Signed-off-by: Michal Simek > --- > > arch/sandbox/dts/test.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
Hi Mark,
On Thu, 7 Sept 2023 at 07:08, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Thu, 7 Sep 2023 06:23:10 -0600
> >
> > Hi Mark,
> >
> > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis wrote:
> > >
> > > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > > variable is set.
> > >
> > > Signed-off-by: Mark Kettenis
> > > ---
> > >
> > > ChangeLog:
> > >
> > > v2: - Initialize EFI subsystem to populate EFI variables
> > >
> > >
> > > boot/bootmeth_efi_mgr.c | 17 -
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > index e9d973429f..e6c42d41fb 100644
> > > --- a/boot/bootmeth_efi_mgr.c
> > > +++ b/boot/bootmeth_efi_mgr.c
> > > @@ -14,6 +14,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > >
> > > /**
> > > * struct efi_mgr_priv - private info for the efi-mgr driver
> > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct
> > > bootflow_iter *iter)
> > > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow
> > > *bflow)
> > > {
> > > struct efi_mgr_priv *priv = dev_get_priv(dev);
> > > + efi_status_t ret;
> > > + efi_uintn_t size;
> > > + u16 *bootorder;
> > >
> > > if (priv->fake_dev) {
> > > bflow->state = BOOTFLOWST_READY;
> > > return 0;
> > > }
> > >
> > > - /* To be implemented */
> > > + ret = efi_init_obj_list();
> >
> > Doesn't this start up the whole EFI system? Is there a cheaper way to
> > see if the variable subsystem exists, or can work?
>
> A fair bit of it at least. With the possible exception of launching
> EFI capsules (which shouldn't happen for a "normal" boot), I don't
> think this is very expensive though.
>
> There currently isn't a way to only initialize the variable subsystem;
> we can't just call efi_init_variables() here since we have to also
> call efi_disks_register() and a later efi_init_obj_list() call would
> call efi_init_variables() again, which would leak memory.
>
> Alternatively we could just unconditionally declare the efi_mgr
> bootmeth as "ready" (like you already do for sandbox). That would
> postpone initialization of the EFI subsystem until we actually execute
> this bootmeth.
>
> But we need to do something before we switch more targets to standard
> boot since otherwise booting through the EFI boot manager is just
> plain broken.
Yes...
I don't have any great ideas on this. If we could get the EFI code
better integrated into U-Boot then perhaps we would not need this
'monolithm' init?
Regards,
Simon
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
Hi Ard, On Thu, 7 Sept 2023 at 09:07, Ard Biesheuvel wrote: > > On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote: > > > > Hi Ard, > > > > On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel wrote: > > > > > > On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote: > > > > > > > > Hi Ard, > > > > > > > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel wrote: > > > > > > > > > > On Wed, 6 Sept 2023 at 18:50, Simon Glass wrote: > > > > > > > > > > > > Hi Ard, > > > > > > > > > > > > On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel wrote: > > > > > >> > > > > > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass > > > > > >> wrote: > > > > > >> > > > > > > >> > Hi Rob, Ard, > > > > > >> > > > > > > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring > > > > > >> > wrote: > > > > > >> > > > > > > > >> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel > > > > > >> > > wrote: > > > > > >> > > > > > > > > >> > > > On Thu, 31 Aug 2023 at 01:18, 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. > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > I don't think the UEFI references are needed or helpful here. > > > > > >> > > > > > > > > >> > > > > 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. > > > > > >> > > > > > > > >> > > Node names reflect the 'class', but not what's specifically in > > > > > >> > > the > > > > > >> > > node. So really, all reserved-memory nodes should have the > > > > > >> > > same name, > > > > > >> > > but that ship already sailed for existing users. 'compatible' > > > > > >> > > is the > > > > > >> > > right thing here. As to what the node name should be, well, we > > > > > >> > > haven't > > > > > >> > > defined that. I think we just used 'memory' on some platforms. > > > > > >> > > > > > > >> > OK > > > > > >> > > > > > > >> > > > > > > > >> > > > > 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-
Re: [PATCHv7 00/15] net/lwip: add lwip library for the network stack
On Thu, 7 Sept 2023 at 21:21, Michal Simek wrote: > Hi, > > út 22. 8. 2023 v 11:38 odesílatel Maxim Uvarov > napsal: > > > > Hello, > > > > I'm sending v7, with all v6 comments getting fixed. The only thing left > is a pointer > > to timeout callback which 2 applications use. I will rework this timeout > > in next v8. I started take a look at it, and want to fix this together > > with background applications support in v8. > > > > changelog: > > v7: - more review fixes. > > - support of multiply eth devices, were "ethact" selects the > > active device. > > v6: - fixed review comments for v5 (thanks Ilias and Simon). > > - lwip is not under /net, so prior applying patch following > > commit is needed to create lwIP merge into U-Boot: > > git subtree add --prefix net/lwip/lwip-external > https://git.savannah.nongnu.org/git/lwip.git master --squash > > I think you should integrate it via .gitmodules as is done for example in > qemu. > > The next part. I tried to use buildmain to build the whole series and > I am getting a lot of errors. > You should fix pretty much all of these errors to make sure that the > tree is bisectable. > > Thanks, > Michal > > Hello Michal, the first version was with .gitmodules. To run buildman you need to create a subtree commit with the above line first, and only then run buildman for patches. And I think these series of patches are not friendly with sequential per patch builds. It's split into logical pieces for easier review. >From the log below I can say that subtree commit was not created. lwIP library files are missing in your set up. BR, Maxim. > [u-boot](lwip)$ ./tools/buildman/buildman -C -b `git rev-parse > --abbrev-ref HEAD` xilinx_zynqmp_virt -o /run/shm/ -sSed > Summary of 18 commits for 1 boards (1 thread, 12 jobs per thread) > 01: Merge branch 'master' of > https://gitlab.denx.de/u-boot/custodians/u-boot-usb >aarch64: w+ xilinx_zynqmp_virt > += WARNING == > +This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate > +to binman instead, to avoid the proliferation of > +arch-specific scripts with no tests. > + > 02: net/lwip: add doc/develop/net_lwip.rst > 03: net/lwip: integrate lwIP library >aarch64: + xilinx_zynqmp_virt > -= WARNING == > -This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate > -to binman instead, to avoid the proliferation of > -arch-specific scripts with no tests. > - > +make[3]: *** No rule to make target > 'net/lwip/lwip-external/src/core/init.o', needed by > 'net/lwip/built-in.o'. Stop. > +make[2]: *** [../scripts/Makefile.build:397: net/lwip] Error 2 > +../net/net.c:128:23: fatal error: net/ulwip.h: No such file or directory > + #include > + ^ > +compilation terminated. > +make[2]: *** [../scripts/Makefile.build:256: net/net.o] Error 1 > +make[1]: *** [Makefile:1857: net] Error 2 > +make: *** [Makefile:177: sub-make] Error 2 > 04: net/lwip: implement dns cmd > -make[2]: *** [../scripts/Makefile.build:256: net/net.o] Error 1 > +make[2]: *** [../scripts/Makefile.build:257: net/net.o] Error 1 > 05: net/lwip: implement dhcp cmd > 06: net/lwip: implement tftp cmd > +cp: cannot stat '../net/lwip/lwip-external/src/apps/tftp/tftp.c': No > such file or directory > +make[4]: *** [../net/lwip/apps/tftp/Makefile:9: > net/lwip/apps/tftp/tftp.c] Error 1 > +../net/lwip/apps/tftp/lwip-tftp.c:12:35: fatal error: > lwip/apps/tftp_client.h: No such file or directory > + #include "lwip/apps/tftp_client.h" > + ^ > +make[4]: *** [../scripts/Makefile.build:257: > net/lwip/apps/tftp/lwip-tftp.o] Error 1 > +make[3]: *** [../scripts/Makefile.build:397: net/lwip/apps/tftp] Error 2 > 07: net/lwip: implement wget cmd > 08: net/lwip: implement ping cmd > +cp: cannot stat '../net/lwip/lwip-external/contrib/apps/ping/ping.c': > No such file or directory > +make[4]: *** [../net/lwip/apps/ping/Makefile:8: > net/lwip/apps/ping/ping.c] Error 1 > +../net/lwip/apps/ping/lwip_ping.c:7:22: fatal error: lwip/opt.h: No > such file or directory > + #include "lwip/opt.h" > + ^ > +make[4]: *** [../scripts/Makefile.build:257: > net/lwip/apps/ping/lwip_ping.o] Error 1 > +make[3]: *** [../scripts/Makefile.build:397: net/lwip/apps/ping] Error 2 > 09: net/lwip: add lwIP configuration > 10: net/lwip: implement lwIP port to U-Boot > -../net/lwip/apps/ping/lwip_ping.c:7:22: fatal error: lwip/opt.h: No > such file or directory > - #include "lwip/opt.h" > - ^ > -make[4]: *** [../scripts/Makefile.build:257: > net/lwip/apps/ping/lwip_ping.o] Error 1 > -../net/lwip/apps/tftp/lwip-tftp.c:12:35: fatal error: > lwip/apps/tftp_client.h: No such file or directory > - #include "lwip/apps/tftp_client.h" > -
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
On Thu, Sep 7, 2023 at 8:56 AM Simon Glass wrote: > > Hi Ard, > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel wrote: > > > > On Wed, 6 Sept 2023 at 18:50, Simon Glass wrote: > > > > > > Hi Ard, > > > > > > On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel wrote: > > >> > > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass wrote: > > >> > > > >> > Hi Rob, Ard, > > >> > > > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring wrote: > > >> > > > > >> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel > > >> > > wrote: > > >> > > > > > >> > > > On Thu, 31 Aug 2023 at 01:18, 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. > > >> > > > > > > >> > > > > > >> > > > I don't think the UEFI references are needed or helpful here. > > >> > > > > > >> > > > > 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. > > >> > > > > >> > > Node names reflect the 'class', but not what's specifically in the > > >> > > node. So really, all reserved-memory nodes should have the same name, > > >> > > but that ship already sailed for existing users. 'compatible' is the > > >> > > right thing here. As to what the node name should be, well, we > > >> > > haven't > > >> > > defined that. I think we just used 'memory' on some platforms. > > >> > > > >> > OK > > >> > > > >> > > > > >> > > > > 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: > > >> > > > > + $nodena
sandbox trace errors in CI loop
Hi Simon and Tom, I am preparing pull request and I see that CI loop is reporting issue with sandbox trace and I have no idea what's going wrong here. This is the first problematic commit but have no clue what it has to do with trace. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/commit/8c5f80d11b29536979ac41a6087fb8938f45bbf2 If you have an access you can take a look at my queue to see that only this job is failing. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines Thanks, Michal collected 1152 items / 1151 deselected / 1 selected test/py/tests/test_trace.py F[100%] === FAILURES === __ test_trace __ test/py/tests/test_trace.py:292: in test_trace check_function(cons, fname, proftool, map_fname, trace_dat) test/py/tests/test_trace.py:117: in check_function out = util.run_and_log(cons, ['sh', '-c', cmd]) test/py/u_boot_utils.py:181: in run_and_log output = runner.run(cmd, ignore_errors=ignore_errors, stdin=stdin, env=env) test/py/multiplexed_log.py:183: in run raise exception E ValueError: Exit code: 1 Captured stdout setup - /u-boot trace: early enable at 0010 sandbox_serial serial: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 => - Captured stdout call - => Call list dumped to 0200, size 0xde3b30 => +/tmp/sandbox/tools/proftool -t /tmp/test_trace/trace -o /tmp/test_trace/trace.dat -m /tmp/sandbox/System.map dump-ftrace 9842 functions found in map file, start addr 3e000 call count: 1213676 +trace-cmd dump /tmp/test_trace/trace.dat Tracing meta data in file /tmp/test_trace/trace.dat: [Initial format] 6 [Version] 0 [Little endian] 4 [Bytes in a long] 4096[Page size, bytes] [Header page, 205 bytes] [Header event, 205 bytes] [Ftrace format, 3 events] [Events format, 0 systems] [Kallsyms, 370293 bytes] [Trace printk, 0 bytes] [Saved command lines, 9 bytes] 1 [CPUs with tracing data] [6 options] [Flyrecord tracing data] [Tracing clock] [local] global counter uptime perf mono mono_raw boot x86-tsc +sh -c trace-cmd report /tmp/test_trace/trace.dat |grep -E '(initf_|initr_)' failed to init data Exit code: 1 === short test summary info FAILED test/py/tests/test_trace.py::test_trace - ValueError: Exit code: 1 == 1 failed, 1151 deselected in 3.32s == -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCHv7 00/15] net/lwip: add lwip library for the network stack
Hi, út 22. 8. 2023 v 11:38 odesílatel Maxim Uvarov napsal: > > Hello, > > I'm sending v7, with all v6 comments getting fixed. The only thing left is a > pointer > to timeout callback which 2 applications use. I will rework this timeout > in next v8. I started take a look at it, and want to fix this together > with background applications support in v8. > > changelog: > v7: - more review fixes. > - support of multiply eth devices, were "ethact" selects the > active device. > v6: - fixed review comments for v5 (thanks Ilias and Simon). > - lwip is not under /net, so prior applying patch following > commit is needed to create lwIP merge into U-Boot: > git subtree add --prefix net/lwip/lwip-external > https://git.savannah.nongnu.org/git/lwip.git master --squash I think you should integrate it via .gitmodules as is done for example in qemu. The next part. I tried to use buildmain to build the whole series and I am getting a lot of errors. You should fix pretty much all of these errors to make sure that the tree is bisectable. Thanks, Michal [u-boot](lwip)$ ./tools/buildman/buildman -C -b `git rev-parse --abbrev-ref HEAD` xilinx_zynqmp_virt -o /run/shm/ -sSed Summary of 18 commits for 1 boards (1 thread, 12 jobs per thread) 01: Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-usb aarch64: w+ xilinx_zynqmp_virt += WARNING == +This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate +to binman instead, to avoid the proliferation of +arch-specific scripts with no tests. + 02: net/lwip: add doc/develop/net_lwip.rst 03: net/lwip: integrate lwIP library aarch64: + xilinx_zynqmp_virt -= WARNING == -This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate -to binman instead, to avoid the proliferation of -arch-specific scripts with no tests. - +make[3]: *** No rule to make target 'net/lwip/lwip-external/src/core/init.o', needed by 'net/lwip/built-in.o'. Stop. +make[2]: *** [../scripts/Makefile.build:397: net/lwip] Error 2 +../net/net.c:128:23: fatal error: net/ulwip.h: No such file or directory + #include + ^ +compilation terminated. +make[2]: *** [../scripts/Makefile.build:256: net/net.o] Error 1 +make[1]: *** [Makefile:1857: net] Error 2 +make: *** [Makefile:177: sub-make] Error 2 04: net/lwip: implement dns cmd -make[2]: *** [../scripts/Makefile.build:256: net/net.o] Error 1 +make[2]: *** [../scripts/Makefile.build:257: net/net.o] Error 1 05: net/lwip: implement dhcp cmd 06: net/lwip: implement tftp cmd +cp: cannot stat '../net/lwip/lwip-external/src/apps/tftp/tftp.c': No such file or directory +make[4]: *** [../net/lwip/apps/tftp/Makefile:9: net/lwip/apps/tftp/tftp.c] Error 1 +../net/lwip/apps/tftp/lwip-tftp.c:12:35: fatal error: lwip/apps/tftp_client.h: No such file or directory + #include "lwip/apps/tftp_client.h" + ^ +make[4]: *** [../scripts/Makefile.build:257: net/lwip/apps/tftp/lwip-tftp.o] Error 1 +make[3]: *** [../scripts/Makefile.build:397: net/lwip/apps/tftp] Error 2 07: net/lwip: implement wget cmd 08: net/lwip: implement ping cmd +cp: cannot stat '../net/lwip/lwip-external/contrib/apps/ping/ping.c': No such file or directory +make[4]: *** [../net/lwip/apps/ping/Makefile:8: net/lwip/apps/ping/ping.c] Error 1 +../net/lwip/apps/ping/lwip_ping.c:7:22: fatal error: lwip/opt.h: No such file or directory + #include "lwip/opt.h" + ^ +make[4]: *** [../scripts/Makefile.build:257: net/lwip/apps/ping/lwip_ping.o] Error 1 +make[3]: *** [../scripts/Makefile.build:397: net/lwip/apps/ping] Error 2 09: net/lwip: add lwIP configuration 10: net/lwip: implement lwIP port to U-Boot -../net/lwip/apps/ping/lwip_ping.c:7:22: fatal error: lwip/opt.h: No such file or directory - #include "lwip/opt.h" - ^ -make[4]: *** [../scripts/Makefile.build:257: net/lwip/apps/ping/lwip_ping.o] Error 1 -../net/lwip/apps/tftp/lwip-tftp.c:12:35: fatal error: lwip/apps/tftp_client.h: No such file or directory - #include "lwip/apps/tftp_client.h" - ^ -make[4]: *** [../scripts/Makefile.build:257: net/lwip/apps/tftp/lwip-tftp.o] Error 1 +../net/eth-uclass.c:35:2: error: unknown type name ‘ulwip’ + ulwip ulwip; + ^ + return &priv->ulwip; + ^~~~ +make[2]: *** [../scripts/Makefile.build:257: net/eth-uclass.o] Error 1 w+../net/eth-uclass.c: In function ‘eth_lwip_priv’: w+../net/eth-uclass.c:355:9: warning: return from incompatible pointer type [-Wincompatible-pointer-types] 11: net/lwip: update .gitignore with lwIP +../net/lwip/apps/ping/lwip_ping.c:7:22: fatal error: lwip/opt.h: No such file or directory + #include "lwip/opt.h" + ^ +make[4]: *** [../scripts/Makefile.build:2
Re: [PATCH v2 1/7] drivers: misc: k3_avs: Add linux compatible to maintain sync
On 19:44-20230907, Neha Malcom Francis wrote:
> The U-Boot AVS driver works on the VTM (Voltage and Thermal Management)
> module, also used by the Linux TI Bandgap temperature sensor driver
> (drivers/thermal/k3_j72xx_bandgap.c). Although the purpose and
> functionalities that these two implement are different, the hardware is
> the same, so ensure that their compatibles are in sync. Thus, add
> ti,j721e-vtm compatible to the AVS driver.
>
> Signed-off-by: Neha Malcom Francis
> ---
> drivers/misc/k3_avs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
> index 840148d090..3008cf9810 100644
> --- a/drivers/misc/k3_avs.c
> +++ b/drivers/misc/k3_avs.c
> @@ -382,6 +382,7 @@ static struct vd_config am654_vd_config = {
> static const struct udevice_id k3_avs_ids[] = {
> { .compatible = "ti,am654-avs", .data = (ulong)&am654_vd_config },
> { .compatible = "ti,j721e-avs", .data = (ulong)&j721e_vd_config },
> + { .compatible = "ti,j721e-vtm", .data = (ulong)&j721e_vd_config },
> {}
> };
>
> --
> 2.34.1
>
https://lore.kernel.org/all/52a7c0b2-7a87-c74e-e63f-d07821ffc...@ti.com/
we are going to end up creating a dependency nightmare.
Can we just do a single series(might be just a single patch) for
compatible additions for k3_avs.c and make the dts syncs dependent on this?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
On Thu, 7 Sept 2023 at 16:50, Simon Glass wrote: > > Hi Ard, > > On Thu, 7 Sept 2023 at 08:12, Ard Biesheuvel wrote: > > > > On Thu, 7 Sept 2023 at 15:56, Simon Glass wrote: > > > > > > Hi Ard, > > > > > > On Thu, 7 Sept 2023 at 07:31, Ard Biesheuvel wrote: > > > > > > > > On Wed, 6 Sept 2023 at 18:50, Simon Glass wrote: > > > > > > > > > > Hi Ard, > > > > > > > > > > On Wed, Sep 6, 2023, 10:09 Ard Biesheuvel wrote: > > > > >> > > > > >> On Wed, 6 Sept 2023 at 16:54, Simon Glass wrote: > > > > >> > > > > > >> > Hi Rob, Ard, > > > > >> > > > > > >> > On Wed, 6 Sept 2023 at 08:34, Rob Herring wrote: > > > > >> > > > > > > >> > > On Tue, Sep 5, 2023 at 4:44 PM Ard Biesheuvel > > > > >> > > wrote: > > > > >> > > > > > > > >> > > > On Thu, 31 Aug 2023 at 01:18, 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. > > > > >> > > > > > > > > >> > > > > > > > >> > > > I don't think the UEFI references are needed or helpful here. > > > > >> > > > > > > > >> > > > > 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. > > > > >> > > > > > > >> > > Node names reflect the 'class', but not what's specifically in > > > > >> > > the > > > > >> > > node. So really, all reserved-memory nodes should have the same > > > > >> > > name, > > > > >> > > but that ship already sailed for existing users. 'compatible' is > > > > >> > > the > > > > >> > > right thing here. As to what the node name should be, well, we > > > > >> > > haven't > > > > >> > > defined that. I think we just used 'memory' on some platforms. > > > > >> > > > > > >> > OK > > > > >> > > > > > >> > > > > > > >> > > > > 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: ht
