Re: [PATCH v2 1/1] drivers: bootcount: Add support for FAT filesystem
Hello Amoiridis,
On 10.06.24 20:51, Vasileios Amoiridis wrote:
Add support to save boot count variable in a file in a FAT filesystem.
Signed-off-by: Vasileios Amoiridis
---
doc/README.bootcount | 12 ++---
drivers/bootcount/Kconfig | 53 +--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 ++---
4 files changed, 50 insertions(+), 29 deletions(-)
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
Thanks!
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
RE: [PATCH] arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM
> Subject: [PATCH] arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM > > Migrate imx8mn_bsh_smm_s2 and imx8mn_bsh_smm_s2pro boards to > OF_UPSTREAM. > > Signed-off-by: Patrick Barsanti > Tested-by: Michael Trimarchi LGTM, Reviewed-by: Peng Fan
Re: [PATCH v2 1/1] drivers: bootcount: Add support for FAT filesystem
On Mon, Jun 10, 2024 at 01:37:47PM -0600, Tom Rini wrote: > On Mon, Jun 10, 2024 at 08:51:16PM +0200, Vasileios Amoiridis wrote: > > > Add support to save boot count variable in a file in a FAT filesystem. > > > > Signed-off-by: Vasileios Amoiridis > > Thanks for doing this. > > Reviewed-by: Tom Rini > > Would you be able to do a follow-up that converts doc/README.bootcount > to rST as say doc/api/bootcount.rst ? > > -- > Tom Hi Tom, Yes I could do that. I will send a follow-up with the change that you propose. Cheers, Vasilis
[u-boot-test-hooks PATCH 2/2] Provide some basic scripts for Labgrid integration
With Labgrid we don't need to specify the various methods, except for
the console, which simply calls labgrid-client.
This allows supporting any boards in your lab, without adding per-board
configuration to these hooks.
Provide ellesmere files as an example.
Signed-off-by: Simon Glass
---
README.md| 33
bin/console.labgrid | 42
bin/ellesmere/common-labgrid | 31 ++
bin/ellesmere/conf.all | 24 +
bin/getrole.labgrid | 25 +
bin/release.labgrid | 22 +++
bin/release.none | 22 +++
bin/u-boot-test-common | 6 +-
bin/u-boot-test-getrole | 39 +
bin/u-boot-test-release | 27 +++
10 files changed, 270 insertions(+), 1 deletion(-)
create mode 100644 bin/console.labgrid
create mode 100755 bin/ellesmere/common-labgrid
create mode 100644 bin/ellesmere/conf.all
create mode 100644 bin/getrole.labgrid
create mode 100644 bin/release.labgrid
create mode 100644 bin/release.none
create mode 100755 bin/u-boot-test-getrole
create mode 100755 bin/u-boot-test-release
diff --git a/README.md b/README.md
index 290e4d0..660ffe2 100644
--- a/README.md
+++ b/README.md
@@ -199,6 +199,39 @@ scripts must be replicated once per board instance, or
their actions somehow
serialized, since they copy files into their own directories when executing,
and
hence parallel execution would cause incorrect operation.
+## Labgrid Integration
+
+Labgrid is a python library for embedded-board-control. It includes a client
+program which is used to integrate with the U-Boot pytests.
+
+Since Labgrid has all the information necessary to build and boot on a lab,
+there is no per-board configuration required. The various flash.xxx and
+recovery.xxx scripts are not used. To set it up:
+
+- In your bin/$hostname directory, create `common-labgrid` and set your
crossbar
+ and environment information, for example:
+
+ export LG_CROSSBAR="ws://kea:20408/ws"
+ export LG_ENV="/vid/software/devel/ubtest/lab/env_rpi_try.cfg"
+
+ flash_impl=none
+ reset_impl=none
+ console_impl=labgrid
+ release_impl=labgrid
+ getrole_impl=labgrid
+
+The last five lines tell the hooks to use Labgrid for console and board release
+as well as a new 'getrole' hook which is only used by Labgrid. The flash and
+reset of boards is handled by entirely by Labgrid.
+
+Then create another file (in the same directory) called 'conf.all',
containing::
+
+.. code-block:: bash
+
+. "${bin_dir}/${hostname}/common-labgrid"
+
+That should be all that is needed.
+
## Dependencies
The example scripts depend on various external tools, the installation location
diff --git a/bin/console.labgrid b/bin/console.labgrid
new file mode 100644
index 000..9ce586f
--- /dev/null
+++ b/bin/console.labgrid
@@ -0,0 +1,42 @@
+# Copyright (c) 2024 Google LLC
+# Written by Simon Glass
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# The variables here can come from one of two places:
+#
+# 1. When using the ub-xxx scripts (e.g. ub-int) they come from those scripts,
+#set by the get_args.sh script
+#
+# 2. When running from gitlab, the variables are all empty and so take the
+#default values below, except for ${strategy} which is set in the gitlab
+#script
+
+# On input:
+# strategy: Strategy arguments to use, e.g. "-s start". Normally this is
+# "-s uboot -e off" but it can be "-s start -e off" or even empty
+# verbose: Verbose argument to use, e.g. "-v"
+#
+# These variables are set by .gitlab-ci.yml or by
+
+exec labgrid-client -V do-bootstrap ${bootstrap:-1} -V do-build ${build:-1} \
+-V do-send ${send:-0} -V do-clean ${clean:-0} \
+-V process-limit ${BUILDMAN_PROCESS_LIMIT:-0} \
+-r "${U_BOOT_BOARD_IDENTITY}"
[u-boot-test-hooks PATCH 1/2] Create a common file for test scripts
The top part of each of the u-boot-test-* files is common. Put it in
a common script file to avoid duplication and to allow it to be
replaced for the Labgrid integration.
Signed-off-by: Simon Glass
---
bin/u-boot-test-common| 31 +++
bin/u-boot-test-console | 7 +--
bin/u-boot-test-flash | 7 +--
bin/u-boot-test-power-off | 7 +--
bin/u-boot-test-power-on | 7 +--
bin/u-boot-test-reset | 7 +--
6 files changed, 36 insertions(+), 30 deletions(-)
create mode 100755 bin/u-boot-test-common
diff --git a/bin/u-boot-test-common b/bin/u-boot-test-common
new file mode 100755
index 000..fa3ad88
--- /dev/null
+++ b/bin/u-boot-test-common
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+# Copyright Google LLC
+# Written by Simon Glass
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+set -e
+
+bin_dir="`dirname $0`"
+board_type="$1"
+board_ident="$2"
+hostname="`hostname`"
+
+. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
diff --git a/bin/u-boot-test-console b/bin/u-boot-test-console
index 0b6b4ac..ad90040 100755
--- a/bin/u-boot-test-console
+++ b/bin/u-boot-test-console
@@ -20,12 +20,7 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
-set -e
-
bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "${bin_dir}/u-boot-test-common"
. "${bin_dir}/console.${console_impl:-picocom}"
diff --git a/bin/u-boot-test-flash b/bin/u-boot-test-flash
index 8dcf198..2e7d5b5 100755
--- a/bin/u-boot-test-flash
+++ b/bin/u-boot-test-flash
@@ -20,12 +20,7 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
-set -e
-
bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "${bin_dir}/u-boot-test-common"
. "${bin_dir}/flash.${flash_impl}"
diff --git a/bin/u-boot-test-power-off b/bin/u-boot-test-power-off
index b59436a..eff0370 100755
--- a/bin/u-boot-test-power-off
+++ b/bin/u-boot-test-power-off
@@ -20,12 +20,7 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
-set -e
-
bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "${bin_dir}/u-boot-test-common"
. "${bin_dir}/poweroff.${power_impl}"
diff --git a/bin/u-boot-test-power-on b/bin/u-boot-test-power-on
index ca87477..5c6b99f 100755
--- a/bin/u-boot-test-power-on
+++ b/bin/u-boot-test-power-on
@@ -20,12 +20,7 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
-set -e
-
bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "${bin_dir}/u-boot-test-common"
. "${bin_dir}/poweron.${power_impl}"
diff --git a/bin/u-boot-test-reset b/bin/u-boot-test-reset
index a160e0c..9d31a12 100755
--- a/bin/u-boot-test-reset
+++ b/bin/u-boot-test-reset
@@ -20,12 +20,7 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
-set -e
-
bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "${bin_dir}/u-boot-test-common"
. "${bin_dir}/reset.${reset_impl}"
--
2.34.1
[u-boot-test-hooks PATCH 0/2] Add support for Labgrid
This adds hooks for use with Labgrid. The only existing hook that really does anything now is the 'console' one. There is also a new 'getrole' hook which looks up a role to find various things about it, such as the U-Boot board name. Simon Glass (2): Create a common file for test scripts Provide some basic scripts for Labgrid integration README.md| 33 bin/console.labgrid | 42 bin/ellesmere/common-labgrid | 31 ++ bin/ellesmere/conf.all | 24 + bin/getrole.labgrid | 25 + bin/release.labgrid | 22 +++ bin/release.none | 22 +++ bin/u-boot-test-common | 35 ++ bin/u-boot-test-console | 7 +- bin/u-boot-test-flash| 7 +- bin/u-boot-test-getrole | 39 + bin/u-boot-test-power-off| 7 +- bin/u-boot-test-power-on | 7 +- bin/u-boot-test-release | 27 +++ bin/u-boot-test-reset| 7 +- 15 files changed, 305 insertions(+), 30 deletions(-) create mode 100644 bin/console.labgrid create mode 100755 bin/ellesmere/common-labgrid create mode 100644 bin/ellesmere/conf.all create mode 100644 bin/getrole.labgrid create mode 100644 bin/release.labgrid create mode 100644 bin/release.none create mode 100755 bin/u-boot-test-common create mode 100755 bin/u-boot-test-getrole create mode 100755 bin/u-boot-test-release -- 2.34.1
[PATCH] arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM
Migrate imx8mn_bsh_smm_s2 and imx8mn_bsh_smm_s2pro boards to OF_UPSTREAM.
Signed-off-by: Patrick Barsanti
Tested-by: Michael Trimarchi
---
Note that the patch was tested by Michael on the s2 board by applying
patch [1] before it, which fixes ddr timings.
The board otherwise doesn't boot.
Links:
- [1]
https://lore.kernel.org/u-boot/20240610063842.192786-1-mich...@amarulasolutions.com/
arch/arm/dts/Makefile | 2 -
arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi | 426 -
arch/arm/dts/imx8mn-bsh-smm-s2.dts | 48 ---
arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 170
arch/arm/mach-imx/imx8m/Kconfig| 2 +
configs/imx8mn_bsh_smm_s2_defconfig| 2 +-
configs/imx8mn_bsh_smm_s2pro_defconfig | 2 +-
7 files changed, 4 insertions(+), 648 deletions(-)
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f77a80b7dd..1196ab040a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -925,8 +925,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-phg.dtb \
imx8mm-phyboard-polis-rdk.dtb \
imx8mm-phygate-tauri-l.dtb \
- imx8mn-bsh-smm-s2.dtb \
- imx8mn-bsh-smm-s2pro.dtb \
imx8mq-cm.dtb \
imx8mn-var-som-symphony.dtb \
imx8mq-mnt-reform2.dtb \
diff --git a/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
b/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
deleted file mode 100644
index c11895d9d5..00
--- a/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
+++ /dev/null
@@ -1,426 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2021 Collabora Ltd.
- * Copyright 2021 BSH Hausgeraete GmbH
- */
-
-/dts-v1/;
-
-#include "imx8mn.dtsi"
-
-/ {
- chosen {
- stdout-path =
- };
-
- fec_supply: fec-supply-en {
- compatible = "regulator-fixed";
- vin-supply = <_reg>;
- regulator-name = "tja1101_en";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = < 20 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- usdhc2_pwrseq: usdhc2-pwrseq {
- compatible = "mmc-pwrseq-simple";
- pinctrl-names = "default";
- pinctrl-0 = <_usdhc2_pwrseq>;
- reset-gpios = < 27 GPIO_ACTIVE_LOW>;
- };
-};
-
-_0 {
- cpu-supply = <_reg>;
-};
-
-_1 {
- cpu-supply = <_reg>;
-};
-
-_2 {
- cpu-supply = <_reg>;
-};
-
-_3 {
- cpu-supply = <_reg>;
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_espi2>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_fec1>;
- phy-mode = "rmii";
- phy-handle = <>;
- phy-supply = <_supply>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy0: ethernet-phy@0 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0>;
- reset-gpios = < 29 GPIO_ACTIVE_LOW>;
- reset-assert-us = <20>;
- reset-deassert-us = <2000>;
- };
- };
-};
-
- {
- clock-frequency = <40>;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c1>;
- status = "okay";
-
- bd71847: pmic@4b {
- compatible = "rohm,bd71847";
- reg = <0x4b>;
- pinctrl-names = "default";
- pinctrl-0 = <_pmic>;
- interrupt-parent = <>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
- rohm,reset-snvs-powered;
-
- #clock-cells = <0>;
- clocks = <_32k 0>;
- clock-output-names = "clk-32k-out";
-
- regulators {
- buck1_reg: BUCK1 {
- /* PMIC_BUCK1 - VDD_SOC */
- regulator-name = "buck1";
- regulator-min-microvolt = <70>;
- regulator-max-microvolt = <130>;
- regulator-boot-on;
- regulator-always-on;
- regulator-ramp-delay = <1250>;
- };
-
- buck2_reg: BUCK2 {
- /* PMIC_BUCK2 - VDD_ARM */
- regulator-name = "buck2";
- regulator-min-microvolt = <70>;
- regulator-max-microvolt = <130>;
- regulator-boot-on;
- regulator-always-on;
-
Re: [RFC PATCH 00/31] Make U-Boot memory reservations coherent
On Sat, Jun 08, 2024 at 12:22:09AM +0530, Sughosh Ganu wrote: > The aim of this patch series is to fix the current state of > incoherence between modules when it comes to memory usage. The primary > issue that this series is trying to fix is that the EFI memory module > which is responsible for allocating and freeing memory, does not have > any visibility of the memory that is being used by the LMB > module. This is further complicated by the fact that the LMB > allocations are caller specific -- the LMB memory map is not global > nor persistent. This means that the memory "allocated" by the LMB > module might be relevant only for a given function. Hence one of the > requirements for making the memory usage visible across modules is to > make LMB allocations persistent and global, and then have means to > communicate the use of memory across modules. > > The first set of patches in this series work on making the LMB memory > map persistent and global. This is being done keeping in mind the > usage of LMB memory by platforms where the same memory region can be > used to load multiple different images. What is not allowed is to > overwrite memory that has been allocated by the other module, > currently the EFI memory module. This is being achieved by introducing > a new flag, LMB_NOOVERWRITE, which represents memory which cannot be > re-requested once allocated. > > The second set of patches are then introducing a notification > mechanism to indicate any changes to a respective module's memory > map. This way, any memory allocation/reservation by a module gets > notified to any interested listners, who then update their memory map > accordingly, thus keeping memory usage coherent. > > Todo's > -- > I have run these patches through CI, but the LMB unit tests need an > overhaul. I have currently marked these tests for manual run, as > running these would obviously tamper the LMB memory map, thus > affecting subsequent tests. The current set of LMB tests are written > with the assumption of local LMB memory maps. This needs to be > reworked. > > Secondly, there needs to be a test written for testing the various > scenarios of memory being allocated and freed by different modules, > namely LMB and EFI. I have written a couple of commands for testing > the changes that I have made -- I have also included these temporary > commands to assist anyone who might want to test these changes. But I > will be working on adding a more comprehensive test. > > Lastly, as the series touches common code, there is obviously an > increase in the size of the image, moreover since the LMB memory is > now persistent, and the variables do not reside on the stack. I want > to check if there can be ways of decreasing the size impact of the > changes. So, I think you made some changes between your last CI run and posting? A ton of platforms (basically anything with EFI_LOADER disabled) fail to build now because the two "temp" commits at the end of the series are always enabled. I took those commits out and ran my world build size check tests and the results are at: https://gist.github.com/trini/d42bd392463c39766a5f872c190ccf27 And 64bit ARM looks very reasonable, but I wonder if we can improve the 32bit ARM results? I also did an every commit run for a 32bit ARM board without EFI_LOADER (which is going to be the case for size constrained systems) and see that the series isn't bisect'able to start with, so please fix that for the next go-round. That said: Summary of 30 commits for 1 boards (1 thread, 12 jobs per thread) 01: Added arm64 assembly for examples/api crt0 02: lmb: remove the unused lmb_is_reserved() function 03: lmb: staticize __lmb_alloc_base() arm: (for 1/1 boards) all -16.0 text -16.0 omapl138_lcdk : all -16 text -16 u-boot: add: 0/-1, grow: 1/0 bytes: 172/-186 (-14) function old new delta lmb_alloc_base 40 212+172 __lmb_alloc_base 186 --186 04: lmb: make the lmb reservations persistent arm: + omapl138_lcdk +(omapl138_lcdk) lib/lmb.c: In function 'lmb_dump_all_force': +(omapl138_lcdk) lib/lmb.c:64:29: error: 'lmb' is a pointer; did you mean to use '->'? +(omapl138_lcdk)64 | lmb_dump_region(, "memory"); +(omapl138_lcdk) | ^ +(omapl138_lcdk) | -> +(omapl138_lcdk) lib/lmb.c:65:29: error: 'lmb' is a pointer; did you mean to use '->'? +(omapl138_lcdk)65 | lmb_dump_region(, "reserved"); +(omapl138_lcdk) lib/lmb.c: In function 'lmb_add': +(omapl138_lcdk) lib/lmb.c:356:39: error: 'lmb' is a pointer; did you mean to use '->'? +(omapl138_lcdk) 356 | struct lmb_region *_rgn = +(omapl138_lcdk) | ^ +(omapl138_lcdk) | ->
Re: [PATCH v2 1/1] drivers: bootcount: Add support for FAT filesystem
On Mon, Jun 10, 2024 at 10:03:25PM +0200, Vasileios Amoiridis wrote: > On Mon, Jun 10, 2024 at 01:37:47PM -0600, Tom Rini wrote: > > On Mon, Jun 10, 2024 at 08:51:16PM +0200, Vasileios Amoiridis wrote: > > > > > Add support to save boot count variable in a file in a FAT filesystem. > > > > > > Signed-off-by: Vasileios Amoiridis > > > > Thanks for doing this. > > > > Reviewed-by: Tom Rini > > > > Would you be able to do a follow-up that converts doc/README.bootcount > > to rST as say doc/api/bootcount.rst ? > > > > -- > > Tom > > Hi Tom, > > Yes I could do that. I will send a follow-up with the change that you propose. Great, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH next v3 0/8] rockchip: add support for Theobroma Systems SOM-RK3588-Q7 Tiger module
Am Montag, 10. Juni 2024, 15:13:30 CEST schrieb Quentin Schulz: > This has a dependency on > https://lore.kernel.org/u-boot/20240528170406.353616-1-liujianfeng1...@gmail.com/ > > Changes in v3: > - rebased on top of next, > - changed patch series dependency from DRAM ATAGS (merged) to RK3588 > upstream DTS cherry-picks from 6.10-rc1 (USB nodes), > - cherry-picked kernel DTS commits for Tiger between v6.9 and v6.10-rc2, > note that the "arm64: dts: rockchip: correct gpio_pwrctrl1 typos on > rk3588(s) boards" > commit triggered some git auto-merging while cherry-picking, > - support for Q7 USB P1 (micro-USB OTG) has been dropped, it requires > extcon USB GPIO driver that isn't supported in U-Boot (yet?), > - Link to v2: > https://lore.kernel.org/r/20240423-tiger-v2-1-4a3fa0a01...@theobroma-systems.com > > Changes in v2: > - removed uart controller muxing patch as not necessary until we get > open-source DRAM init, > - disabled DEBUG_UART_BOARD_INIT as it's only used for muxing the UART > controller and it's not necessary since DDR bin does this for us > already, > - added missing uart2 mux bootph in U-Boot dtsi (though not required > yet), > - switched to USB_DWC3_GENERIC from USB_XHCI_DWC3 as requested by Jonas, > - Link to v1: > https://lore.kernel.org/r/20240422-tiger-v1-0-8816b070d...@theobroma-systems.com > > Signed-off-by: Quentin Schulz Putting both the dependency and this series on top of next, still allows my tiger to boot, so Tested-by: Heiko Stuebner
Re: [PATCH] clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present
On Tue, May 14, 2024 at 3:26 PM Sam Protsenko wrote: > > On Wed, May 1, 2024 at 4:12 PM Sam Protsenko > wrote: > > > > On Wed, Apr 10, 2024 at 9:53 PM Sean Anderson wrote: > > > > > > On 3/7/24 19:04, Sam Protsenko wrote: > > > > Sometimes clocks provided to a consumer might not have .set_rate > > > > operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag > > > > set. In that case it's usually possible to find a parent up the tree > > > > which is capable of setting the rate (div, pll, etc). Implement a simple > > > > lookup procedure for such cases, to traverse the clock tree until > > > > .set_rate capable parent is found, and use that parent to actually > > > > change the rate. The search will stop once the first .set_rate capable > > > > clock is found, which is usually enough to handle most cases. > > > > > > > > Signed-off-by: Sam Protsenko > > > > --- > > > > [snip] > > > > > > > > Can you give an example of where this is needed? > > > > > > > Sure. In my case it's needed for eMMC enablement on E850-96 board. > > eMMC node in the device tree [1] is a gate clock > > (CLK_GOUT_MMC_EMBD_SDCLKIN), so the MMC driver won't be able to change > > its rate. But that clock actually has CLK_SET_RATE_PARENT flag set in > > the clock driver [2]. So the right thing to do in this case (and > > that's basically how it's done in Linux kernel too) is to traverse the > > clock tree upwards, and try to find the parent capable to do .set_rate > > (which is usually a divider clock), and use it to change the clock > > rate. I'm working on exynos_dw_mmc driver [3] right now, making it use > > CCF clocks, but I can't do that before this patch is applied. > > > > Grepping the U-Boot tree I can see the CLK_SET_RATE_PARENT flag is > > also used in various IMX clock drivers and STM32MP13 clock driver. I > > guess without this change those flags will be basically ignored. > > > > Thanks! > > > > Hi Sean, > > Just wanted to check if you think my explanation above is ok and the > patch can be applied? I'm finishing my new patch series for enabling > MMC on E850-96, but this patch has to be applied first. > > Thanks! > Hi Tom, Would it be reasonable to ask you to take care of this patch? It's been ignored for 3 months now, but it's needed for eMMC enablement on E850-96 board. Thanks! > > [1] > > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos850.dtsi#L408 > > [2] > > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/clk/exynos/clk-exynos850.c#L353 > > [3] > > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/mmc/exynos_dw_mmc.c#L117 > > > > > --Sean
Re: [PATCH v2 1/1] drivers: bootcount: Add support for FAT filesystem
On Mon, Jun 10, 2024 at 08:51:16PM +0200, Vasileios Amoiridis wrote: > Add support to save boot count variable in a file in a FAT filesystem. > > Signed-off-by: Vasileios Amoiridis Thanks for doing this. Reviewed-by: Tom Rini Would you be able to do a follow-up that converts doc/README.bootcount to rST as say doc/api/bootcount.rst ? -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/9] fdt: Correct condition for bloblist existing
Hi Simon,
On Tue, 4 Jun 2024 at 23:27, Simon Glass wrote:
> On some boards, the bloblist is created in SPL once SDRAM is ready. It
> cannot be accessed until that point, so is not available early in SPL.
>
> Add a condition to avoid a hang in this case.
>
> This fixes a hang in chromebook_coral
>
> Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
>
> Signed-off-by: Simon Glass
> ---
>
> lib/fdtdec.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index b2c59ab3818..b141244e3b9 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1669,8 +1669,16 @@ int fdtdec_setup(void)
> {
> int ret = -ENOENT;
>
> - /* If allowing a bloblist, check that first */
> - if (CONFIG_IS_ENABLED(BLOBLIST)) {
> + /*
> +* If allowing a bloblist, check that first. This would be better
> +* handled with an OF_BLOBLIST Kconfig, but that caused far too
> much
> +* argument, so add a hack here, used e.g. by chromebook_coral
>
I am a bit confused by this comment - It means you will not use OF_BLOBLIST,
but actually you are using it below. Is it a typo?
> +* The necessary test is whether the previous stage passed a
> bloblist,
> +* not whether this one creates one.
> +*/
> + if (CONFIG_IS_ENABLED(OF_BLOBLIST) &&
> + (spl_prev_phase() != PHASE_TPL ||
> +!IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
> ret = bloblist_maybe_init();
> if (!ret) {
> gd->fdt_blob =
> bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
> --
> 2.34.1
>
>
Regards,
Raymond
[PATCH v2 1/1] drivers: bootcount: Add support for FAT filesystem
Add support to save boot count variable in a file in a FAT filesystem.
Signed-off-by: Vasileios Amoiridis
---
doc/README.bootcount | 12 ++---
drivers/bootcount/Kconfig | 53 +--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 ++---
4 files changed, 50 insertions(+), 29 deletions(-)
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
diff --git a/doc/README.bootcount b/doc/README.bootcount
index f6c5f82f..0f4ffb68 100644
--- a/doc/README.bootcount
+++ b/doc/README.bootcount
@@ -23,15 +23,15 @@ It is the responsibility of some application code
(typically a Linux
application) to reset the variable "bootcount" to 0 when the system booted
successfully, thus allowing for more boot cycles.
-CONFIG_BOOTCOUNT_EXT
+CONFIG_BOOTCOUNT_FS
-This adds support for maintaining boot count in a file on an EXT filesystem.
-The file to use is defined by:
+This adds support for maintaining boot count in a file on a filesystem.
+Supported filesystems are FAT and EXT. The file to use is defined by:
-CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
-CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
-CONFIG_SYS_BOOTCOUNT_EXT_NAME
+CONFIG_SYS_BOOTCOUNT_FS_INTERFACE
+CONFIG_SYS_BOOTCOUNT_FS_DEVPART
+CONFIG_SYS_BOOTCOUNT_FS_NAME
The format of the file is:
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 3c56253b..d3679eb5 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -25,10 +25,9 @@ config BOOTCOUNT_GENERIC
Set to the address where the bootcount and bootcount magic
will be stored.
-config BOOTCOUNT_EXT
- bool "Boot counter on EXT filesystem"
- depends on FS_EXT4
- select EXT4_WRITE
+config BOOTCOUNT_FS
+ bool "Boot counter on a filesystem"
+ depends on FS_EXT4 || FS_FAT
help
Add support for maintaining boot count in a file on an EXT
filesystem.
@@ -184,26 +183,48 @@ config SYS_BOOTCOUNT_SINGLEWORD
This option enables packing boot count magic value and boot count
into single word (32 bits).
-config SYS_BOOTCOUNT_EXT_INTERFACE
- string "Interface on which to find boot counter EXT filesystem"
+if BOOTCOUNT_FS
+choice
+ prompt "Filesystem type"
+ default BOOTCOUNT_EXT
+
+config BOOTCOUNT_EXT
+ bool "Boot counter on EXT filesystem"
+ depends on FS_EXT4
+ select EXT4_WRITE
+ help
+ Add support for maintaing boot counter in a file on EXT filesystem"
+
+config BOOTCOUNT_FAT
+ bool "Boot counter on FAT filesystem"
+ depends on FS_FAT
+ select FAT_WRITE
+ help
+ Add support for maintaing boot counter in a file on FAT filesystem"
+
+endchoice
+endif
+
+config SYS_BOOTCOUNT_FS_INTERFACE
+ string "Interface on which to find boot counter filesystem"
default "mmc"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the interface to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_DEVPART
- string "Partition of the boot counter EXT filesystem"
+config SYS_BOOTCOUNT_FS_DEVPART
+ string "Partition of the boot counter filesystem"
default "0:1"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the partition to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_NAME
- string "Path and filename of the EXT filesystem based boot counter"
+config SYS_BOOTCOUNT_FS_NAME
+ string "Path and filename of the FS filesystem based boot counter"
default "/boot/failures"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the filename and path of the file used to store the boot counter.
@@ -211,18 +232,18 @@ config SYS_BOOTCOUNT_ADDR
hex "RAM address used for reading and writing the boot counter"
default 0x44E3E000 if BOOTCOUNT_AM33XX || BOOTCOUNT_AM33XX_NVMEM
default 0xE0115FF8 if ARCH_LS1043A || ARCH_LS1021A
- depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX_NVMEM
help
Set the address used for reading and writing the boot counter.
config SYS_BOOTCOUNT_MAGIC
hex "Magic value for the boot counter"
- default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
BOOTCOUNT_RAM || BOOTCOUNT_AT91 || DM_BOOTCOUNT
default 0xB0 if BOOTCOUNT_AM33XX_NVMEM
- depends on BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_GENERIC ||
[PATCH v2 0/1]: drivers: bootcount: Add support for FAT filesystem
Changes in v2:
- Use generic code by utilizing FS_TYPE_ANY
- Change filename from bootcount_ext.c to bootcount_fs.c
v1:
https://lore.kernel.org/u-boot/20240605181041.68317-1-vassilisa...@gmail.com/
This patch adds support to save the bootcount variable in a file located in
FAT filesystem. Up to now, there was support only for EXT filesystem.
The reason I put this as RFC is because the file "bootcount_ext.c" will no
longer represent the implementation for the EXT filesystem, but also for the
FAT filesystem. Should it be renamed? If not, wouldn't it be inconsistent?
Cheers,
Vasilis
P.S: Documentation has not been modified yet, I will submit in the v2 (if any).
Vasileios Amoiridis (1):
drivers: bootcount: Add support for FAT filesystem
doc/README.bootcount | 12 ++---
drivers/bootcount/Kconfig | 53 +--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 ++---
4 files changed, 50 insertions(+), 29 deletions(-)
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
--
2.25.1
[PATCH v2 0/9] Bug-fixes for a few boards
This series includes fixes to get some rockchip and nvidia boards working again. It also drops the broken Beaglebone Black config and provides a devicetree fix for coral (x86). Changes in v2: - Put the conditions under EFI_TCG2_PROTOCOL - Consider MEASURED_BOOT too - Remove the superfluous if() and drop the debug() as well - Use 'phase' instead of 'stage' - Add new patch to correct memory size in SPL - Drop patch "regulator: rk8xx: Fix incorrect parameter" - Rewrite boneblack patch to onstead drop the target and update docs Simon Glass (9): nvidia: nyan-big: Disable debug UART tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL rockchip: veyron: Add logging for power init power: regulator: Handle autoset in regulators_enable_boot_on() fdt: Correct condition for bloblist existing spl: Allow ATF to work when dcache is disabled rockchip: Ensure memory size is available in RK3399 SPL rockchip: bob: kevin: Disable dcache in SPL Drop the special am335x_boneblack_vboot target board/google/veyron/veyron.c | 30 +++ board/ti/am335x/MAINTAINERS| 1 - boot/Kconfig | 4 + common/spl/spl_atf.c | 3 +- configs/am335x_boneblack_vboot_defconfig | 94 -- configs/am335x_evm_defconfig | 3 +- configs/chromebook_bob_defconfig | 1 + configs/chromebook_kevin_defconfig | 1 + configs/nyan-big_defconfig | 1 - doc/usage/fit/beaglebone_vboot.rst | 21 +++-- drivers/power/regulator/regulator-uclass.c | 2 +- drivers/ram/rockchip/sdram_rk3399.c| 49 ++- lib/Kconfig| 4 - lib/fdtdec.c | 12 ++- 14 files changed, 70 insertions(+), 156 deletions(-) delete mode 100644 configs/am335x_boneblack_vboot_defconfig -- 2.34.1
Re: [RFC PATCH 22/31] test: lmb: run the LMB tests only on sandbox
On Sat, Jun 08, 2024 at 12:22:31AM +0530, Sughosh Ganu wrote: > The LMB memory map is now persistent and global. Running the tests for > the LMB module will result in the memory map getting reset, and this > will have side-effects on the rest of the working of the platform. Run > the LMB tests only on the sandbox platform, which is meant for running > such kinds of tests. > > Signed-off-by: Sughosh Ganu I'm not sure about this. We can reset real hardware as often as we need, too. Did you run in to problems with this test on non-sandbox? -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 08/31] lmb: replcace the lmb_init_and_reserve() function
On Sat, Jun 08, 2024 at 12:22:17AM +0530, Sughosh Ganu wrote:
> With the changes to make the Logical Memory Block(LMB) allocations
> persistent and with the common memory regions being reserved during
> board init, the lmb_init_and_reserve() API can be removed and replaced
> with a lmb_add_memory() API, which adds all the available memory to
> the LMB pool.
>
> Signed-off-by: Sughosh Ganu
> ---
> arch/arm/mach-apple/board.c | 2 +-
> arch/arm/mach-snapdragon/board.c | 2 +-
> arch/arm/mach-stm32mp/stm32mp1/cpu.c | 2 +-
> cmd/bdinfo.c | 2 +-
> cmd/load.c | 2 +-
> fs/fs.c | 2 +-
> include/lmb.h| 12 +++-
> lib/lmb.c| 15 +++
> net/tftp.c | 2 +-
> net/wget.c | 2 +-
> test/cmd/bdinfo.c| 10 +-
> 11 files changed, 31 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index c877c7b94c..2e72d03edd 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -776,7 +776,7 @@ int board_late_init(void)
> {
> u32 status = 0;
>
> - lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
> + lmb_add_memory(gd->bd);
>
> /* somewhat based on the Linux Kernel boot requirements:
>* align by 2M and maximal FDT size 2M
We already reserved gd->bd as part of the initr_lmb call. So I think
this commit needs rethinking, or am I missing something?
--
Tom
signature.asc
Description: PGP signature
Re: [RFC PATCH 07/31] lmb: remove lmb_init_and_reserve_range() function
On Sat, Jun 08, 2024 at 12:22:16AM +0530, Sughosh Ganu wrote: > With the move to make the LMB allocations persistent and the common > memory regions being reserved during board init, the > lmb_init_and_reserve_range() API can be replaced with a simple > lmb_add() call. > > Signed-off-by: Sughosh Ganu Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 06/31] lmb: reserve and add common memory regions post relocation
On Sat, Jun 08, 2024 at 12:22:15AM +0530, Sughosh Ganu wrote: > The LMB module provides API's for allocating chunks of memory. The LMB > module should not be allocating memory regions that are in use, or > that might be occupied by the U-Boot image. Prevent allocations of > memory areas used by the U-Boot image by reserving these regions once > U-Boot has been relocated. Also add the rest of the memory that is > available for allocations to the LMB's memory map. > > Signed-off-by: Sughosh Ganu Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 05/31] lmb: pass a flag to image_setup_libfdt() for lmb reservations
On Sat, Jun 08, 2024 at 12:22:14AM +0530, Sughosh Ganu wrote:
> The image_setup_libfdt() function optionally calls the LMB API to
> reserve the region of memory occupied by the FDT blob. This was
> earlier determined through the presence of the pointer to the lmb
> structure, which is no longer present. Pass a flag to the
> image_setup_libfdt() function to indicate if the region occupied by
> the FDT blob is to be marked as reserved by the LMB module.
>
> Signed-off-by: Sughosh Ganu
[snip]
> ---
> arch/mips/lib/bootm.c | 2 +-
> boot/image-board.c| 2 +-
> boot/image-fdt.c | 7 +++
> cmd/elf.c | 2 +-
> include/image.h | 5 ++---
> lib/efi_loader/efi_dt_fixup.c | 2 +-
> lib/efi_loader/efi_helper.c | 2 +-
> 7 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
> index 54d89e9cca..e4fc2e589d 100644
> --- a/arch/mips/lib/bootm.c
> +++ b/arch/mips/lib/bootm.c
> @@ -247,7 +247,7 @@ static int boot_setup_fdt(struct bootm_headers *images)
> images->initrd_start = virt_to_phys((void *)images->initrd_start);
> images->initrd_end = virt_to_phys((void *)images->initrd_end);
>
> - return image_setup_libfdt(images, images->ft_addr, >lmb);
> + return image_setup_libfdt(images, images->ft_addr, 0);
> }
>
> static void boot_prep_linux(struct bootm_headers *images)
> diff --git a/boot/image-board.c b/boot/image-board.c
> index 89ccf80066..481b333b4c 100644
> --- a/boot/image-board.c
> +++ b/boot/image-board.c
> @@ -897,7 +897,7 @@ int image_setup_linux(struct bootm_headers *images)
> }
>
> if (CONFIG_IS_ENABLED(OF_LIBFDT) && of_size) {
> - ret = image_setup_libfdt(images, *of_flat_tree, lmb);
> + ret = image_setup_libfdt(images, *of_flat_tree, 1);
> if (ret)
> return ret;
> }
> diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> index 08afde203c..4daced9e99 100644
> --- a/boot/image-fdt.c
> +++ b/boot/image-fdt.c
> @@ -567,8 +567,7 @@ __weak int arch_fixup_fdt(void *blob)
> return 0;
> }
>
> -int image_setup_libfdt(struct bootm_headers *images, void *blob,
> -struct lmb *lmb)
> +int image_setup_libfdt(struct bootm_headers *images, void *blob, bool lmb)
> {
> ulong *initrd_start = >initrd_start;
> ulong *initrd_end = >initrd_end;
Since this is a bool, please use true/false in the callers.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 3/9] rockchip: veyron: Add logging for power init
Hi Simon, On 6/10/24 4:59 PM, Simon Glass wrote: Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can be enabled. Signed-off-by: Simon Glass Reviewed-by: Quentin Schulz Thanks! Quentin
Re: [RFC PATCH 03/31] lmb: make the lmb reservations persistent
On Mon, Jun 10, 2024 at 01:23:49PM +0200, Heinrich Schuchardt wrote:
> On 1/1/70 01:00, Ilias Apalodimas wrote:
> > Hi Sughosh
> >
> > [...]
> >
> > > #define LMB_ALLOC_ANYWHERE 0
> > >
> > > +#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
> > > +struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
> > > +struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
> > > +#endif
> > > +
> > > +struct lmb lmb = {
> > > +#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
> > > + .memory.max = CONFIG_LMB_MAX_REGIONS,
> > > + .reserved.max = CONFIG_LMB_MAX_REGIONS,
> > > +#else
> > > + .memory.max = CONFIG_LMB_MEMORY_REGIONS,
> > > + .reserved.max = CONFIG_LMB_RESERVED_REGIONS,
> > > + .memory.region = memory_regions,
> > > + .reserved.region = reserved_regions,
> >
> > This is probably a good opportunity to look into why
> > CONFIG_LMB_MEMORY_REGIONS was introduced. Since we are moving towards
> > static allocations, do we still need it? Or allocating the size dynamically
> > covers all our cases.
>
> Up to now we used static arrays for saving memory allocations in LMB:
>
> include/lmb.h:67:
> struct lmb_property region[CONFIG_LMB_MAX_REGIONS];
>
> As the EFI sub-system can produce any number of non-coalescable memory
> regions we should use a linked list instead.
I think it's some historic flexibility that's I believe no longer really
relevant to how we use LMB today, let alone once this patch series is
complete. We should probably (I'm doing my size check thing now..) move
to just following Heinrich's suggestion.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Fri, May 17, 2024 at 07:13:48PM +, Brunham, Kalen wrote: > I've encountered a problem when compiling the 'examples/api' directory for > ARM64 in U-boot. The problem lies in the assembly code in > 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When > targeting ARM64, a 64-bit version is necessary. > > I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly > code as shown below. These changes have been check via > https://github.com/u-boot/u-boot/pull/538. > > Feedback is welcome. > > Signed-off-by: Kalen Brunham Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] abootimg: Add init_boot image support
On Thu, 23 May 2024 07:06:07 +, Roman Stratiienko wrote: > Quote from [1]: > > "For devices launching with Android 13, the generic ramdisk is removed > from the boot image and placed in a separate init_boot image. > This change leaves the boot image with only the GKI kernel." > > While at it, update wrong error handling message when vendor_boot > cannot be loaded. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] android: Fix ramdisk loading for bootimage v3+
On Sun, 19 May 2024 13:09:51 +, Roman Stratiienko wrote: > The boot_ramdisk and vendor_ramdisk must be both concatenated together. > Without this change, Android root is missing some of the necessary tools > to complete virtual AB OTA. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] arm: move _end to linker symbols
On Tue, 28 May 2024 09:18:27 +0300, Ilias Apalodimas wrote:
> commit 6e2228fb052b ("Merge patch series "Clean up arm linker scripts")
> was cleaning up linker scripts for armv7 and v8 but was leaving
> _end and __secure_stack_start/end.
>
> commit d0b5d9da5de2 ("arm: make _end compiler-generated")
> was moving _end to be compiler generated. _end is defined as c variable
> in its own section to force the compiler emit relative a reference.
> However, defining those in the linker script will do the same thing
> since [0].
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
Re: [PATCH] image: Set load_end on partial loads
On Thu, 23 May 2024 11:27:09 +0200, Mattijs Korpershoek wrote: > When decompressing, it's possible that the algorithm only performs > a partial decompression. > This usually happens when CONFIG_SYS_BOOTM_LEN is too small for > the uncompressed image. > > When that happens, image_decomp() returns an error and *load_end == load. > The error is then handled by handle_decomp_error(). > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] fs: relax ext4_write_file() dependency
On Wed, 15 May 2024 07:37:16 +0300, Baruch Siach wrote: > ext4_write_file() depends on CONFIG_EXT4_WRITE. Allow build without > CONFIG_CMD_EXT4_WRITE. > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] dm: use newly added linux/compat alloc functions
On Wed, 15 May 2024 23:13:30 +0300, Maxim Moskalets wrote: > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v3 0/9] efi_loader: improve device-tree loading
On Mon, Jun 10, 2024 at 06:10:08PM +0200, Heinrich Schuchardt wrote: > On 10.06.24 17:54, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 10 Jun 2024 at 08:00, Heinrich Schuchardt > > wrote: > > > > > > On 10.06.24 15:53, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Mon, 10 Jun 2024 at 03:11, Heinrich Schuchardt > > > > wrote: > > > > > > > > > > In U-Boot EFI boot options can already specify both an EFI binary and > > > > > an initrd. With this series we can additionally define the matching > > > > > device-tree to be loaded in the boot option. > > > > > > > > > > With the last patch the boot manager will fall back the device-tree > > > > > specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' > > > > > on the boot device if no device-tree is specified in the boot > > > > > option or via a bootefi command parameter. > > > > > > > > > > v3: > > > > > Add missing '@' in EFI_LP_DP_PART_FDT description. > > > > > Use calloc() instead of malloc() in > > > > > load_fdt_from_load_option(). > > > > > Add missing '@' in load_fdt_from_load_option function > > > > > description > > > > > Rename struct efi_initrd_dp to efi_lo_dp_prefix. > > > > > > > > > > v2: > > > > > Update efi_dp_concat() instead of new function > > > > > efi_dp_merge(). > > > > > Carve out a function efi_load_option_dp_join() which we can > > > > > use both for the eficonfig and the efidebug command. > > > > > Rename variables id_dp, final_dp_size. > > > > > Rename create_initrd_dp() to create_lo_dp_part(). > > > > > Use enum as parameter for create_lo_dp_part(). > > > > > Put all related changes into one patch. > > > > > > > > > > Heinrich Schuchardt (8): > > > > > efi_loader: allow concatenation with contained end node > > > > > cmd: eficonfig: add support for setting fdt > > > > > cmd: efidebug: add support for setting fdt > > > > > efi_loader: load device-tree specified in boot option > > > > > efi_loader: move distro_efi_get_fdt_name() > > > > > efi_loader: return binary from efi_dp_from_lo() > > > > > efi_loader: export efi_load_image_from_path > > > > > efi_loader: load distro dtb in bootmgr > > > > > > > > > >boot/bootmeth_efi.c| 60 +- > > > > >cmd/eficonfig.c| 83 + > > > > >cmd/efidebug.c | 130 > > > > > +++-- > > > > >include/efi_loader.h | 24 +++- > > > > >lib/efi_loader/Makefile| 1 + > > > > >lib/efi_loader/efi_bootbin.c | 2 +- > > > > >lib/efi_loader/efi_bootmgr.c | 75 +++- > > > > >lib/efi_loader/efi_boottime.c | 3 +- > > > > >lib/efi_loader/efi_device_path.c | 40 --- > > > > >lib/efi_loader/efi_device_path_utilities.c | 2 +- > > > > >lib/efi_loader/efi_fdt.c | 117 > > > > > +++ > > > > >lib/efi_loader/efi_helper.c| 44 +++ > > > > >12 files changed, 445 insertions(+), 136 deletions(-) > > > > >create mode 100644 lib/efi_loader/efi_fdt.c > > > > > > > > > > > > > Somewhat related, what work has been done to support FIT, or to locate > > > > a DT using the compatible string? > > > > > > CONFIG_BOOTM_EFI allows booting a FIT image containing an EFI binary and > > > optionally a device-tree. You can manually select a configuration when > > > invoking the bootm command. I am not aware of any automation for this > > > selection. > > > > Thanks for the info. > > > > Can we perhaps require FIT_BEST_MATCH and then provide a way? All this > > filename stuff is missing the point, really. It isn't going to get any > > easier, either. > > > > Thanks for the pointer. FIT_BEST_MATCH would allow to select a matching > device-tree from a FIT image. But any solution using FIT images will not not > be compatible to other firmware. > > As a distro I would prefer a solution that runs on any EFI firmware, e.g. > EDK II. Being able to use the same image on all boards of the same > architecture was the motivator for Suse to start U-Boot's EFI > implementation. I'm pretty sure tianocore, grub and systemd takes patches too? And everyone is going to need to do _something_ because all of the measured boot stuff that distributions want starts from "we can't check the measurement of 1 files, we need to check one file". So it's pretty handy then that there's an open and well known specification that handles that problem. I'm still frankly a little baffled as to what would prevent UKI from being "EFI application stub around a FIT image". -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 9/9] Drop the special am335x_boneblack_vboot target
On Mon, Jun 10, 2024 at 08:59:20AM -0600, Simon Glass wrote: > Now that am335x_evm boots OK on the Beaglebone black, drop the latter > and update the docs to cover the change. > > Also add a few updates about 'make fit' and drop the note about the > security review, as U-Boot's verified boot has had quite extensive > review now. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: Proposal: U-Boot memory management
On Mon, Jun 10, 2024 at 07:55:44AM -0600, Simon Glass wrote: > Hi Sughosh, > > On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > > > +Sughosh Ganu for reference > > > > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini > > > > > : > > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > > >> Hi Tom, > > > > > >> > > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini > > > > > >> wrote: > > > > > >> > > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > > > >> > > Hi, > > > > > >> > > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > > >> > > wrote: > > > > > >> > > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis > > > > > >> > > > wrote: > > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > > >> > > > > > From: Tom Rini > > > > > >> > > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > > >> > > > > > Schuchardt wrote: > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > > > >> > > > > > > : > > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon Glass > > > > > >> > > > > > > >wrote: > > > > > >> > > > > > > >> Hi, > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > > >> > > > > > > >> wrote: > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Hi, > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > This records my thoughts after a discussion with > > > > > >> > > > > > > >> > Ilias & Heinrich re > > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 1. malloc() > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > > >> > > > > > > >> > allocation. It allows memory > > > > > >> > > > > > > >> > to be freed. It is not designed for very large > > > > > >> > > > > > > >> > allocations (e.g. a > > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 2. lmb > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such as > > > > > >> > > > > > > >> > those needed for a > > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only transitory, > > > > > >> > > > > > > >> > for the purposes of > > > > > >> > > > > > > >> > loading some images and booting. If the boot > > > > > >> > > > > > > >> > fails, then all lmb > > > > > >> > > > > > > >> > allocations go away. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb is set up by getting all available memory and > > > > > >> > > > > > > >> > then removing what > > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() space, > > > > > >> > > > > > > >> > etc.) > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb reservations have a few flags so that areas > > > > > >> > > > > > > >> > of memory can be > > > > > >> > > > > > > >> > provided with attributes > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a file > > > > > >> > > > > > > >> > does an lmb > > > > > >> > > > > > > >> > allocation but only for the purpose of avoiding a > > > > > >> > > > > > > >> > file being loaded > > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is dropped > > > > > >> > > > > > > >> > immediately after the > > > > > >> > > > > > > >> > file is loaded. Within the bootm command, or when > > > > > >> > > > > > > >> > using standard boot, > > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should > > > > > >> > > > > > > >> > consider doing the same. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 3. EFI > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large > > > > > >> > > > > > > >> > allocations. But via a 'pool' > > > > > >> > > > > > > >> > function it can also do smaller allocations > > > > > >> > > > > > > >> > similar to malloc(), > > > > > >> > > > > > > >> > although each one uses at least 4KB at present. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > EFI allocations do not go away when a boot fails. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > With EFI it is possible to add allocations post > > > > > >> > > > > > > >> > facto, in which case > > > > > >> >
Re: [PATCH 2/3] avb: Implement get_preloaded_partition callback
Hi Roman,
On Sun, May 19, 2024 at 9:19 PM Roman Stratiienko
wrote:
>
> AVB can reuse already loaded images instead of loading them
> from the disk.
>
> The get_preloaded_partition now looks for the env. variables
> set by the 'abootimg load' to find the correct partition in RAM.
>
> Signed-off-by: Roman Stratiienko
> ---
> common/avb_verify.c | 53 +
> 1 file changed, 53 insertions(+)
>
> diff --git a/common/avb_verify.c b/common/avb_verify.c
> index cff9117d92..d2626e8844 100644
> --- a/common/avb_verify.c
> +++ b/common/avb_verify.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -595,6 +596,55 @@ static AvbIOResult read_from_partition(AvbOps *ops,
>num_bytes, buffer, out_num_read, IO_READ);
> }
>
> +#ifdef CONFIG_ANDROID_BOOT_IMAGE
Please use CONFIG_IS_ENABLED() macro
> +/**
> + * get_preloaded_partition() - Gets the starting pointer of a partition that
> + * is pre-loaded in memory, and save it to |out_pointer|.
> + *
> + * If the partition is not pre-loaded in memory, the out_pointer shall not be
> + * modified.
> + *
> + * @ops: contains AVB ops handlers
> + * @partition: partition name, NUL-terminated UTF-8 string
> + * @num_bytes: amount of bytes to read
> + * @out_pointer: pointer to the starting address of the partition
> + * @out_num_bytes_preloaded: amount of bytes pre-loaded in memory
> + *
> + * @return:
Please follow [1]. I know that the whole file has this type of issues,
I plan to fix it in the near future.
[1] https://www.kernel.org/doc/html/next/doc-guide/kernel-doc.html.
Should be "Return: AVB_IO_RESULT_OK, if partition was found or was not found"
> + * AVB_IO_RESULT_OK, if partition was found or was not found
> + *
> + */
> +static AvbIOResult get_preloaded_partition(AvbOps *ops, const char
> *partition, size_t num_bytes,
> + uint8_t **out_pointer, size_t
> *out_num_bytes_preloaded)
> +{
> + size_t partition_start = 0;
> + size_t partition_size = 0;
> + char env_name[64];
> +
> + sprintf(env_name, "abootimg_%s_ptr", partition);
Please use more secure version snprintf()
> + partition_start = env_get_hex(env_name, 0);
> +
> + sprintf(env_name, "abootimg_%s_size", partition);
> + partition_size = env_get_hex(env_name, 0);
> +
> + if (partition_start == 0 || partition_size == 0)
> + return AVB_IO_RESULT_OK;
> +
> + if (partition_size < num_bytes) {
> + printf("AVB: Preloaded partition %s size %zu is smaller than
> requested %zu\n",
> + partition, partition_size, num_bytes);
> + return AVB_IO_RESULT_ERROR_IO;
> + }
> +
> + *out_pointer = (uint8_t *)partition_start;
> + *out_num_bytes_preloaded = partition_size;
> +
> + printf("AVB: Using preloaded partition %s at %p\n", partition,
> *out_pointer);
> +
> + return AVB_IO_RESULT_OK;
> +}
> +#endif
> +
> /**
> * write_to_partition() - writes N bytes to a partition identified by a
> string
> * name
> @@ -1043,6 +1093,9 @@ AvbOps *avb_ops_alloc(int boot_device)
> ops_data->ops.user_data = ops_data;
>
> ops_data->ops.read_from_partition = read_from_partition;
> +#ifdef CONFIG_ANDROID_BOOT_IMAGE
Please use CONFIG_IS_ENABLED() macro
> + ops_data->ops.get_preloaded_partition = get_preloaded_partition;
> +#endif
> ops_data->ops.write_to_partition = write_to_partition;
> ops_data->ops.validate_vbmeta_public_key = validate_vbmeta_public_key;
> ops_data->ops.read_rollback_index = read_rollback_index;
> --
> 2.40.1
>
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
[PATCH] smbios: only look for a SYSINFO udevice if SYSINFO support is enabled
From: Quentin Schulz
If SYSINFO support isn't enabled, it's a given that uclass_first_device
for UCLASS_SYSINFO will not find anything, therefore let's skip the test
entirely.
This allows to get rid of the following debug message that may be
confusing:
Cannot find uclass for id 118: please add the UCLASS_DRIVER() declaration for
this UCLASS_... id
Signed-off-by: Quentin Schulz
---
lib/smbios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/smbios.c b/lib/smbios.c
index b190b010f30..a822acd48e9 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -571,7 +571,7 @@ ulong write_smbios_table(ulong addr)
int i;
ctx.node = ofnode_null();
- if (IS_ENABLED(CONFIG_OF_CONTROL)) {
+ if (IS_ENABLED(CONFIG_OF_CONTROL) && CONFIG_IS_ENABLED(SYSINFO)) {
uclass_first_device(UCLASS_SYSINFO, );
if (ctx.dev)
parent_node = dev_read_subnode(ctx.dev, "smbios");
---
base-commit: 4f836fb324ba500ecabdba4146c3ca9e1600cdf5
change-id: 20240610-smbios-sysinfo-dca17e76e11d
Best regards,
--
Quentin Schulz
[PATCH] cmd: sound: fix help text
From: Quentin Schulz
There's never been a -q or -s argument handled in the command, so let's
remove it. This was highlighted during review[1] but somehow still got
through.
While at it, slightly "reword" in the help text how the len + freq
arguments are defined. Indeed, len and freq work in pair, it is possible
to define none of either, n of both, or n - 1 of freq if there are n
len, in which case the freq that goes with the last len would be the n -
1 (and not the default of 400Hz if neither len nor freq is passed). I
assume this isn't what's expected but leaving it for another patch if
need be to fix what happens in that very odd scenario.
[1]
https://lore.kernel.org/u-boot/capnjgz0qwnqvfzfewhxrcfoa3e3grazcys77nguxkl0plp+...@mail.gmail.com/
Fixes: ea58b9a404d4 ("cmd: allow sound command to play multiple sounds")
Signed-off-by: Quentin Schulz
---
cmd/sound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/sound.c b/cmd/sound.c
index 08bf74112f1..8f67cbd96e1 100644
--- a/cmd/sound.c
+++ b/cmd/sound.c
@@ -98,7 +98,7 @@ U_BOOT_CMD(
sound, INT_MAX, 1, do_sound,
"sound sub-system",
"init - initialise the sound driver\n"
- "sound play [[[-q|-s] len [freq]] ...] - play sounds\n"
+ "sound play [len [freq [len [freq ... - play sounds\n"
" len - duration in ms\n"
" freq - frequency in Hz\n"
);
---
base-commit: 4f836fb324ba500ecabdba4146c3ca9e1600cdf5
change-id: 20240610-cmd-sound-help-cfef07dcc95a
Best regards,
--
Quentin Schulz
Re: [PATCH v3 0/9] efi_loader: improve device-tree loading
On 10.06.24 17:54, Simon Glass wrote: Hi Heinrich, On Mon, 10 Jun 2024 at 08:00, Heinrich Schuchardt wrote: On 10.06.24 15:53, Simon Glass wrote: Hi Heinrich, On Mon, 10 Jun 2024 at 03:11, Heinrich Schuchardt wrote: In U-Boot EFI boot options can already specify both an EFI binary and an initrd. With this series we can additionally define the matching device-tree to be loaded in the boot option. With the last patch the boot manager will fall back the device-tree specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' on the boot device if no device-tree is specified in the boot option or via a bootefi command parameter. v3: Add missing '@' in EFI_LP_DP_PART_FDT description. Use calloc() instead of malloc() in load_fdt_from_load_option(). Add missing '@' in load_fdt_from_load_option function description Rename struct efi_initrd_dp to efi_lo_dp_prefix. v2: Update efi_dp_concat() instead of new function efi_dp_merge(). Carve out a function efi_load_option_dp_join() which we can use both for the eficonfig and the efidebug command. Rename variables id_dp, final_dp_size. Rename create_initrd_dp() to create_lo_dp_part(). Use enum as parameter for create_lo_dp_part(). Put all related changes into one patch. Heinrich Schuchardt (8): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr boot/bootmeth_efi.c| 60 +- cmd/eficonfig.c| 83 + cmd/efidebug.c | 130 +++-- include/efi_loader.h | 24 +++- lib/efi_loader/Makefile| 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 75 +++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 --- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 +++ lib/efi_loader/efi_helper.c| 44 +++ 12 files changed, 445 insertions(+), 136 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c Somewhat related, what work has been done to support FIT, or to locate a DT using the compatible string? CONFIG_BOOTM_EFI allows booting a FIT image containing an EFI binary and optionally a device-tree. You can manually select a configuration when invoking the bootm command. I am not aware of any automation for this selection. Thanks for the info. Can we perhaps require FIT_BEST_MATCH and then provide a way? All this filename stuff is missing the point, really. It isn't going to get any easier, either. Thanks for the pointer. FIT_BEST_MATCH would allow to select a matching device-tree from a FIT image. But any solution using FIT images will not not be compatible to other firmware. As a distro I would prefer a solution that runs on any EFI firmware, e.g. EDK II. Being able to use the same image on all boards of the same architecture was the motivator for Suse to start U-Boot's EFI implementation. Best regards Heinrich
[PATCH 3/4] dm: core: migrate debug() messages to use dm_warn
From: Quentin Schulz
Prior to that, seeing the debug() messages required to enable DM_DEBUG
which defines DEBUG (and then _DEBUG) which in turn makes failing
assert() calls reset U-Boot which isn't necessarily what is desired.
Instead, let's migrate to dm_warn which is using log_debug when unset or
log_warn when set.
While at it, reword the DM_DEBUG symbol in Kconfig to explain what it
now actually does.
Signed-off-by: Quentin Schulz
---
drivers/core/device.c| 2 +-
drivers/core/fdtaddr.c | 6 ++--
drivers/core/lists.c | 2 +-
drivers/core/of_access.c | 50 +++---
drivers/core/of_addr.c | 40
drivers/core/of_extra.c | 32 +--
drivers/core/ofnode.c| 80
drivers/core/regmap.c| 56 -
drivers/core/root.c | 14 -
drivers/core/uclass.c| 4 +--
10 files changed, 143 insertions(+), 143 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 18e2bd02dd5..779f371b9d5 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -58,7 +58,7 @@ static int device_bind_common(struct udevice *parent, const
struct driver *drv,
ret = uclass_get(drv->id, );
if (ret) {
- debug("Missing uclass for driver %s\n", drv->name);
+ dm_warn("Missing uclass for driver %s\n", drv->name);
return ret;
}
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 6be8ea0c0a9..e98cc399df4 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -32,19 +32,19 @@ fdt_addr_t devfdt_get_addr_index(const struct udevice *dev,
int index)
na = fdt_address_cells(gd->fdt_blob, parent);
if (na < 1) {
- debug("bad #address-cells\n");
+ dm_warn("bad #address-cells\n");
return FDT_ADDR_T_NONE;
}
ns = fdt_size_cells(gd->fdt_blob, parent);
if (ns < 0) {
- debug("bad #size-cells\n");
+ dm_warn("bad #size-cells\n");
return FDT_ADDR_T_NONE;
}
reg = fdt_getprop(gd->fdt_blob, offset, "reg", );
if (!reg || (len <= (index * sizeof(fdt32_t) * (na + ns {
- debug("Req index out of range\n");
+ dm_warn("Req index out of range\n");
return FDT_ADDR_T_NONE;
}
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 942fe4a4e67..bd0ab4f16c9 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -144,7 +144,7 @@ int device_bind_driver_to_node(struct udevice *parent,
const char *drv_name,
drv = lists_driver_lookup_name(drv_name);
if (!drv) {
- debug("Cannot find driver '%s'\n", drv_name);
+ dm_warn("Cannot find driver '%s'\n", drv_name);
return -ENOENT;
}
ret = device_bind_with_driver_data(parent, drv, dev_name, 0 /* data */,
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 41f2e09b9c2..127d2dfc898 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -489,17 +489,17 @@ int of_read_u8(const struct device_node *np, const char
*propname, u8 *outp)
{
const u8 *val;
- debug("%s: %s: ", __func__, propname);
+ dm_warn("%s: %s: ", __func__, propname);
if (!np)
return -EINVAL;
val = of_find_property_value_of_size(np, propname, sizeof(*outp));
if (IS_ERR(val)) {
- debug("(not found)\n");
+ dm_warn("(not found)\n");
return PTR_ERR(val);
}
*outp = *val;
- debug("%#x (%d)\n", *outp, *outp);
+ dm_warn("%#x (%d)\n", *outp, *outp);
return 0;
}
@@ -508,17 +508,17 @@ int of_read_u16(const struct device_node *np, const char
*propname, u16 *outp)
{
const __be16 *val;
- debug("%s: %s: ", __func__, propname);
+ dm_warn("%s: %s: ", __func__, propname);
if (!np)
return -EINVAL;
val = of_find_property_value_of_size(np, propname, sizeof(*outp));
if (IS_ERR(val)) {
- debug("(not found)\n");
+ dm_warn("(not found)\n");
return PTR_ERR(val);
}
*outp = be16_to_cpup(val);
- debug("%#x (%d)\n", *outp, *outp);
+ dm_warn("%#x (%d)\n", *outp, *outp);
return 0;
}
@@ -533,14 +533,14 @@ int of_read_u32_array(const struct device_node *np, const
char *propname,
{
const __be32 *val;
- debug("%s: %s: ", __func__, propname);
+ dm_warn("%s: %s: ", __func__, propname);
val = of_find_property_value_of_size(np, propname,
sz * sizeof(*out_values));
[PATCH 4/4] dm: core: fix typo in SPL_DM_WARN prompt text
From: Quentin Schulz It should read "in SPL" and not "wuth SPL". Signed-off-by: Quentin Schulz --- drivers/core/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig index 1081d61fcf0..e4b1a66ecb1 100644 --- a/drivers/core/Kconfig +++ b/drivers/core/Kconfig @@ -56,7 +56,7 @@ config DM_WARN out - it will do nothing when called. config SPL_DM_WARN - bool "Enable warnings in driver model wuth SPL" + bool "Enable warnings in driver model in SPL" depends on SPL_DM help Enable this to see warnings related to driver model in SPL -- 2.45.2
[PATCH 2/4] dm: core: fix signedness in debug messages
From: Quentin Schulz
outp always point to an unsigned type in ofnode_read_u* functions but
the format specifier is currently always using signed type.
This is an issue since the signed type can only contain half of the
unsigned type values above 0.
However, this now breaks another usecase. Indeed,
ofnode_read_s32_default is actually passing an s32 but it'll be printed
as a u32 instead. But since the function is called u32, it makes more
sense to have it print an unsigned value.
This was discovered because arm,smc-id = <0x8210>; on RK3588S is
above the max signed value and therefore would return a negative signed
decimal value instead of its proper unsigned one.
Fixes: fa12dfa08a7b ("dm: core: support reading a single indexed u64 value")
Fixes: 4bb7075c830c ("dm: core: support reading a single indexed u32 value")
Fixes: 7e5196c409f1 ("dm: core: Add ofnode function to read a 64-bit int")
Fixes: 9e51204527dc ("dm: core: Add operations on device tree references")
Signed-off-by: Quentin Schulz
---
drivers/core/ofnode.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 9a5eaaa4d13..9ff46460e7d 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -326,7 +326,7 @@ int ofnode_read_u8(ofnode node, const char *propname, u8
*outp)
return -EINVAL;
}
*outp = *cell;
- debug("%#x (%d)\n", *outp, *outp);
+ debug("%#x (%u)\n", *outp, *outp);
return 0;
}
@@ -357,7 +357,7 @@ int ofnode_read_u16(ofnode node, const char *propname, u16
*outp)
return -EINVAL;
}
*outp = be16_to_cpup(cell);
- debug("%#x (%d)\n", *outp, *outp);
+ debug("%#x (%u)\n", *outp, *outp);
return 0;
}
@@ -409,7 +409,7 @@ int ofnode_read_u32_index(ofnode node, const char
*propname, int index,
}
*outp = fdt32_to_cpu(cell[index]);
- debug("%#x (%d)\n", *outp, *outp);
+ debug("%#x (%u)\n", *outp, *outp);
return 0;
}
@@ -439,7 +439,7 @@ int ofnode_read_u64_index(ofnode node, const char
*propname, int index,
}
*outp = fdt64_to_cpu(cell[index]);
- debug("%#llx (%lld)\n", *outp, *outp);
+ debug("%#llx (%llu)\n", *outp, *outp);
return 0;
}
@@ -479,7 +479,7 @@ int ofnode_read_u64(ofnode node, const char *propname, u64
*outp)
return -EINVAL;
}
*outp = fdt64_to_cpu(cell[0]);
- debug("%#llx (%lld)\n", (unsigned long long)*outp,
+ debug("%#llx (%llu)\n", (unsigned long long)*outp,
(unsigned long long)*outp);
return 0;
--
2.45.2
[PATCH 1/4] dm: core: fix misleading debug message when matching compatible
From: Quentin Schulz
A driver can have multiple compatible. When the id->compatible matches
for that driver, the first compatible supported by the driver is
currently returned, which gives the following confusing message:
- found match at 'rk3588_syscon': 'rockchip,rk3588-sys-grf' matches
'rockchip,rk3588-pmugrf'
Considering that the compatible passed in argument is necessarily the
one that exactly matched to enter this code path, there's no need to do
some elaborate logic, just print the driver name and the compatible
passed in argument.
Fixes: d3e773613b6d ("dm: core: Use U-Boot logging instead of pr_debug()")
Signed-off-by: Quentin Schulz
---
drivers/core/lists.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 2839a9b7371..942fe4a4e67 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -246,9 +246,8 @@ int lists_bind_fdt(struct udevice *parent, ofnode node,
struct udevice **devp,
}
if (entry->of_match)
- log_debug(" - found match at '%s': '%s' matches
'%s'\n",
- entry->name, entry->of_match->compatible,
- id->compatible);
+ log_debug(" - found match at driver '%s' for '%s'\n",
+ entry->name, id->compatible);
ret = device_bind_with_driver_data(parent, entry, name,
id ? id->data : 0, node,
);
--
2.45.2
[PATCH 0/4] dm: core: fix several debug messages and migrate debug() to dm_warn
Fix a few misleading or incorrect debug messages and prompt text for a Kconfig symbol. Migrate debug() messages to use dm_warn() instead so that we can print them without selecting DM_DEBUG which does too much (e.g. makes assert() reset U-boot if it fails). Tested on top of next branch but it applies without complaints on top of master as well, so up to you to which branch to merge it. Signed-off-by: Quentin Schulz --- Quentin Schulz (4): dm: core: fix misleading debug message when matching compatible dm: core: fix signedness in debug messages dm: core: migrate debug() messages to use dm_warn dm: core: fix typo in SPL_DM_WARN prompt text drivers/core/Kconfig | 2 +- drivers/core/device.c| 2 +- drivers/core/fdtaddr.c | 6 ++-- drivers/core/lists.c | 7 ++--- drivers/core/of_access.c | 50 +++--- drivers/core/of_addr.c | 40 drivers/core/of_extra.c | 32 +-- drivers/core/ofnode.c| 80 drivers/core/regmap.c| 56 - drivers/core/root.c | 14 - drivers/core/uclass.c| 4 +-- 11 files changed, 146 insertions(+), 147 deletions(-) --- base-commit: 4f836fb324ba500ecabdba4146c3ca9e1600cdf5 change-id: 20240610-misc-20240610-f9dce050186b Best regards, -- Quentin Schulz
Re: [PATCH 3/3] abootimg: Implement smart image load feature
Hi Roman,
On Sun, May 19, 2024 at 9:19 PM Roman Stratiienko
wrote:
>
> Load only part of the boot partition that contains valuable
> information, thus improving the boot time.
>
> Signed-off-by: Roman Stratiienko
> ---
> boot/image-android.c | 70
> cmd/abootimg.c | 40 ++---
> include/image.h | 12
> 3 files changed, 118 insertions(+), 4 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index da8003f370..d00a896a40 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -204,6 +204,76 @@ bool android_image_get_data(const void *boot_hdr, const
> void *vendor_boot_hdr,
> return true;
> }
>
> +/**
> + * android_image_get_valuable_size() - get the size of the android image
> + *
> + * This function checks if the image is Android boot image and returns the
> + * valuable size of the image.
> + *
> + * @hdr_addr: Boot image header address (boot or vendor_boot)
> + *
> + * @return size of the image on success, 0 on failure
> + */
> +size_t android_image_get_valuable_size(const void *hdr_addr)
> +{
> + int version, size;
> +
> + if (is_android_boot_image_header(hdr_addr)) {
> + const struct andr_boot_img_hdr_v0 *hdr = hdr_addr;
> +
> + version = ((struct andr_boot_img_hdr_v0
> *)hdr_addr)->header_version;
> + if (version > 2) {
> + const struct andr_boot_img_hdr_v3 *hdr = hdr_addr;
> +
> + size = ALIGN(hdr->header_size, ANDR_GKI_PAGE_SIZE);
> + size += ALIGN(hdr->kernel_size, ANDR_GKI_PAGE_SIZE);
> + size += ALIGN(hdr->ramdisk_size, ANDR_GKI_PAGE_SIZE);
> +
> + if (version > 3)
> + size += ALIGN(hdr->signature_size,
> ANDR_GKI_PAGE_SIZE);
> +
> + return size;
> + }
> +
> + size = hdr->page_size;
> + size += ALIGN(hdr->kernel_size, hdr->page_size);
> + size += ALIGN(hdr->ramdisk_size, hdr->page_size);
> + size += ALIGN(hdr->second_size, hdr->page_size);
> +
> + if (version > 0)
> + size += ALIGN(hdr->recovery_dtbo_size,
> hdr->page_size);
> +
> + if (version > 1)
> + size += ALIGN(hdr->dtb_size, hdr->page_size);
> +
> + return size;
> + }
> +
> + if (is_android_vendor_boot_image_header(hdr_addr)) {
> + const struct andr_vnd_boot_img_hdr *hdr = hdr_addr;
> +
> + version = ((struct andr_vnd_boot_img_hdr
> *)hdr_addr)->header_version;
> + if (version < 3) {
> + printf("Vendor boot image header version %d is not
> supported\n", version);
> +
> + return 0;
> + }
> +
> + size = ALIGN(hdr->header_size, hdr->page_size);
> + size += ALIGN(hdr->vendor_ramdisk_size, hdr->page_size);
> + size += ALIGN(hdr->dtb_size, hdr->page_size);
> +
> + if (version > 3) {
> + size += ALIGN(hdr->vendor_ramdisk_table_size,
> hdr->page_size);
> + size += ALIGN(hdr->bootconfig_size, hdr->page_size);
> + }
> +
> + return size;
> + }
> +
> + return 0;
Can we split this function on two, for example:
android_boot_image_get_valuable_size()
android_vendor_image_get_valuable_size(),
Then check image type in abootimg_smart_load() and call proper function
accordingly?
> +}
> +
> static ulong android_image_get_kernel_addr(struct andr_image_data *img_data)
> {
> /*
> diff --git a/cmd/abootimg.c b/cmd/abootimg.c
> index 808c9c4941..fe7c5c5e2c 100644
> --- a/cmd/abootimg.c
> +++ b/cmd/abootimg.c
> @@ -182,6 +182,35 @@ static int abootimg_get_dtb(int argc, char *const argv[])
> return CMD_RET_USAGE;
> }
>
> +static int abootimg_smart_load(struct blk_desc *desc, struct disk_partition
> *info, void *addr)
> +{
> + int ret, size;
> +
> + ret = blk_dread(desc, info->start, 4096 / info->blksz, addr);
> + if (ret < 0) {
> + printf("Error: Failed to read partition\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + size = android_image_get_valuable_size(addr);
> + if (size == 0)
> + return 0;
> +
> + ret = blk_dread(desc, info->start, DIV_ROUND_UP(size, info->blksz),
> addr);
> + if (ret < 0) {
> + printf("Error: Failed to read partition\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + memset(addr + size, 0, info->size * info->blksz - size);
> +
> + printf("Loaded Android boot image using smart load (%d/%d MB)\n",
> + (int)DIV_ROUND_UP(size, 1024 * 1024),
> + (int)DIV_ROUND_UP(info->size * info->blksz, 1024 * 1024));
> +
> +
Re: [PATCH] android: Fix ramdisk loading for bootimage v3+
Hi Roman,
On Sun, May 19, 2024 at 3:09 PM Roman Stratiienko
wrote:
>
> The boot_ramdisk and vendor_ramdisk must be both concatenated together.
> Without this change, Android root is missing some of the necessary tools
> to complete virtual AB OTA.
>
> Signed-off-by: Roman Stratiienko
> ---
> boot/image-android.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 04f2a8015e..499eae9bcd 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -64,7 +64,6 @@ static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3
>
> data->kcmdline = hdr->cmdline;
> data->header_version = hdr->header_version;
> - data->ramdisk_ptr = env_get_ulong("ramdisk_addr_r", 16, 0);
>
> /*
> * The header takes a full page, the remaining components are aligned
> @@ -75,6 +74,7 @@ static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3
> data->kernel_ptr = end;
> data->kernel_size = hdr->kernel_size;
> end += ALIGN(hdr->kernel_size, ANDR_GKI_PAGE_SIZE);
> + data->ramdisk_ptr = end;
> data->ramdisk_size = hdr->ramdisk_size;
> data->boot_ramdisk_size = hdr->ramdisk_size;
> end += ALIGN(hdr->ramdisk_size, ANDR_GKI_PAGE_SIZE);
> @@ -462,25 +462,24 @@ int android_image_get_ramdisk(const void *hdr, const
> void *vendor_boot_img,
> return -1;
> }
> if (img_data.header_version > 2) {
> - ramdisk_ptr = img_data.ramdisk_ptr;
> + ramdisk_ptr = img_data.ramdisk_addr;
> memcpy((void *)(ramdisk_ptr), (void
> *)img_data.vendor_ramdisk_ptr,
>img_data.vendor_ramdisk_size);
> - memcpy((void *)(ramdisk_ptr + img_data.vendor_ramdisk_size),
> - (void *)img_data.ramdisk_ptr,
> + ramdisk_ptr += img_data.vendor_ramdisk_size;
> + memcpy((void *)(ramdisk_ptr), (void *)img_data.ramdisk_ptr,
>img_data.boot_ramdisk_size);
> + ramdisk_ptr += img_data.boot_ramdisk_size;
> if (img_data.bootconfig_size) {
> memcpy((void *)
> - (ramdisk_ptr + img_data.vendor_ramdisk_size +
> - img_data.boot_ramdisk_size),
> - (void *)img_data.bootconfig_addr,
> + (ramdisk_ptr), (void
> *)img_data.bootconfig_addr,
>img_data.bootconfig_size);
> }
> }
>
> printf("RAM disk load addr 0x%08lx size %u KiB\n",
> - img_data.ramdisk_ptr, DIV_ROUND_UP(img_data.ramdisk_size,
> 1024));
> + img_data.ramdisk_addr, DIV_ROUND_UP(img_data.ramdisk_size,
> 1024));
>
> - *rd_data = img_data.ramdisk_ptr;
> + *rd_data = img_data.ramdisk_addr;
>
> *rd_len = img_data.ramdisk_size;
> return 0;
> --
> 2.40.1
>
Reviewed-by: Igor Opaniuk
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
Re: Proposal: U-Boot memory management
Hi Sughosh, On Mon, 10 Jun 2024 at 09:17, Sughosh Ganu wrote: > > hi Simon, > > On Mon, 10 Jun 2024 at 20:33, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Mon, 10 Jun 2024 at 08:40, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Mon, 10 Jun 2024 at 19:25, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > > > > > > > > > +Sughosh Ganu for reference > > > > > > > > > > > > > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > > > > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini > > > > > > > > : > > > > > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > > > > > >> Hi Tom, > > > > > > > > >> > > > > > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass > > > > > > > > >> > wrote: > > > > > > > > >> > > Hi, > > > > > > > > >> > > > > > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > > > > > >> > > wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark > > > > > > > > >> > > > Kettenis wrote: > > > > > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > > > > > >> > > > > > From: Tom Rini > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > > > > > >> > > > > > Schuchardt wrote: > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom > > > > > > > > >> > > > > > > Rini : > > > > > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon > > > > > > > > >> > > > > > > >Glass wrote: > > > > > > > > >> > > > > > > >> Hi, > > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > > > > > >> > > > > > > >> wrote: > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > Hi, > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > This records my thoughts after a discussion > > > > > > > > >> > > > > > > >> > with Ilias & Heinrich re > > > > > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > 1. malloc() > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > > > > > >> > > > > > > >> > allocation. It allows memory > > > > > > > > >> > > > > > > >> > to be freed. It is not designed for very > > > > > > > > >> > > > > > > >> > large allocations (e.g. a > > > > > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > 2. lmb > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, > > > > > > > > >> > > > > > > >> > such as those needed for a > > > > > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only > > > > > > > > >> > > > > > > >> > transitory, for the purposes of > > > > > > > > >> > > > > > > >> > loading some images and booting. If the > > > > > > > > >> > > > > > > >> > boot fails, then all lmb > > > > > > > > >> > > > > > > >> > allocations go away. > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > lmb is set up by getting all available > > > > > > > > >> > > > > > > >> > memory and then removing what > > > > > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() > > > > > > > > >> > > > > > > >> > space, etc.) > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > lmb reservations have a few flags so that > > > > > > > > >> > > > > > > >> > areas of memory can be > > > > > > > > >> > > > > > > >> > provided with attributes > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading > > > > > > > > >> > > > > > > >> > a file does an lmb > > > > > > > > >> > > > > > > >> > allocation but only for the purpose of > > > > > > > > >> > > > > > > >> > avoiding a file being loaded > > > > > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is > > > > > > > > >> > > > > > > >> > dropped immediately after the > > > > > > > > >> > > > > > > >> > file is loaded. Within the bootm command, > > > > > > > > >> > > > > > > >> > or when using standard boot, > > > > > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > > > > > >> > > > > > > >> > > > > > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We > > > > > > > > >> > > > > > > >> > should
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
Hi,
On Mon, 10 Jun 2024 at 09:42, Sughosh Ganu wrote:
>
> On Mon, 10 Jun 2024 at 20:47, Heinrich Schuchardt wrote:
> >
> > On 07.06.24 20:52, Sughosh Ganu wrote:
> > > There are events that would be used to notify other interested modules
> > > of any changes in available and occupied memory. This would happen
> > > when a module allocates or reserves memory, or frees up memory. These
> >
> > I am worried about the "frees up memory" case.
> >
> > When LMB frees memory we cannot add it back to EFI conventional memory
> > as there might still be a file image lingering around that EFI should
> > not overwrite. It has to stay marked as EfiLoaderCode or EfiLoaderData.
>
> So here is my basic doubt. Why would LMB free up memory if it still
> has a valid image. If that is the case, the lmb_free API should not be
> called?
>
> -sughosh
>
>
> >
> > How do you ensure that if a region reserved by LMB notification as
> > EfiLoaderData is coalesced with some other allocation LMB is not
> > requested to mark the coalesced region as reserved?
> >
> > @Tom
> >
> > Clinging to the existing logic that you can do anything when loading
> > files is obviously leading us into coding hell.
> >
> > If somebody wants to load two images into the same location, he should
> > be forced to unload the first image. This will allow us to have a single
> > memory management system.
It seems we really shouldn't use the words 'allocate' and 'free' when
talking about LMB. They are simply reservations. I believe we have got
into this situation due to an assumption that these two things are the
same, but in U-Boot they certainly are not. LMB is a very lighweight
and temporary reservation system to be used for a single boot process.
Regards,
Simon
> >
> > Best regards
> >
> > Heinrich
> >
> > > changes in memory map should be notified to other interested modules
> > > so that the allocated memory does not get overwritten. Add an event
> > > handler in the EFI memory module to update the EFI memory map
> > > accordingly when such changes happen. As a consequence, any subsequent
> > > memory request would honour the updated memory map and only available
> > > memory would be allocated from.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > lib/efi_loader/efi_memory.c | 70 ++---
> > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > > index 435e580fb3..93244161b0 100644
> > > --- a/lib/efi_loader/efi_memory.c
> > > +++ b/lib/efi_loader/efi_memory.c
> > > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> > > #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> > > extern bool is_addr_in_ram(uintptr_t addr);
> > >
> > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > > + int memory_type,
> > > + bool overlap_only_ram);
> > > +
> > > static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> > > {
> > > struct event_efi_mem_map_update efi_map = {0};
> > > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64 size,
> > > u8 op)
> > > if (is_addr_in_ram((uintptr_t)addr))
> > > event_notify(EVT_EFI_MEM_MAP_UPDATE, _map,
> > > sizeof(efi_map));
> > > }
> > > +
> > > +static int lmb_mem_map_update_sync(void *ctx, struct event *event)
> > > +{
> > > + u8 op;
> > > + u64 addr;
> > > + u64 pages;
> > > + efi_status_t status;
> > > + struct event_lmb_map_update *lmb_map = >data.lmb_map;
> > > +
> > > + addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > > + pages = efi_size_in_pages(lmb_map->size + (addr & EFI_PAGE_MASK));
> > > + op = lmb_map->op;
> > > + addr &= ~EFI_PAGE_MASK;
> > > +
> > > + if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > > + log_debug("Invalid map update op received (%d)\n", op);
> > > + return -1;
> > > + }
> > > +
> > > + status = __efi_add_memory_map_pg(addr, pages,
> > > + op == MAP_OP_FREE ?
> > > + EFI_CONVENTIONAL_MEMORY :
> > > + EFI_BOOT_SERVICES_DATA,
> > > + true);
> > > +
> > > + return status == EFI_SUCCESS ? 0 : -1;
> > > +}
> > > +EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
> > > #endif /* MEM_MAP_UPDATE_NOTIFY */
> > >
> > > /**
> > > @@ -275,18 +307,9 @@ static s64 efi_mem_carve_out(struct efi_mem_list
> > > *map,
> > > return EFI_CARVE_LOOP_AGAIN;
> > > }
> > >
> > > -/**
> > > - * efi_add_memory_map_pg() - add pages to the memory map
> > > - *
> > > - * @start: start address, must be a multiple of EFI_PAGE_SIZE
> > > - * @pages: number of pages to add
> > > - * @memory_type: type of memory added
> > > - * @overlap_only_ram:region may only overlap
Re: [PATCH 5/9] fdt: Correct condition for bloblist existing
Hi Ilias,
On Tue, 4 Jun 2024 at 23:33, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> On Wed, 5 Jun 2024 at 06:26, Simon Glass wrote:
> >
> > On some boards, the bloblist is created in SPL once SDRAM is ready. It
> > cannot be accessed until that point, so is not available early in SPL.
> >
> > Add a condition to avoid a hang in this case.
> >
> > This fixes a hang in chromebook_coral
> >
> > Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > lib/fdtdec.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index b2c59ab3818..b141244e3b9 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1669,8 +1669,16 @@ int fdtdec_setup(void)
> > {
> > int ret = -ENOENT;
> >
> > - /* If allowing a bloblist, check that first */
> > - if (CONFIG_IS_ENABLED(BLOBLIST)) {
> > + /*
> > +* If allowing a bloblist, check that first. This would be better
> > +* handled with an OF_BLOBLIST Kconfig, but that caused far too much
> > +* argument, so add a hack here, used e.g. by chromebook_coral
> > +* The necessary test is whether the previous stage passed a
> > bloblist,
> > +* not whether this one creates one.
> > +*/
> > + if (CONFIG_IS_ENABLED(OF_BLOBLIST) &&
> > + (spl_prev_phase() != PHASE_TPL ||
> > +!IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
>
> The same condition exists in common/bloblist.c.
> Carve out a function --e.g
>
> bool can can_enable_bloblist(void)
> return
>
> instead of open coding that
Unfortunately it looks like the conditions are different, with the one
you mention being:
if (spl_prev_phase() == PHASE_TPL && !IS_ENABLED(CONFIG_TPL_BLOBLIST))
from_addr = false;
(is that the one you mean?)
So I don't think I can combine them into a helper function.
Regards,
Simon
Re: [PATCH v3 0/9] efi_loader: improve device-tree loading
Hi Heinrich, On Mon, 10 Jun 2024 at 08:00, Heinrich Schuchardt wrote: > > On 10.06.24 15:53, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 10 Jun 2024 at 03:11, Heinrich Schuchardt > > wrote: > >> > >> In U-Boot EFI boot options can already specify both an EFI binary and > >> an initrd. With this series we can additionally define the matching > >> device-tree to be loaded in the boot option. > >> > >> With the last patch the boot manager will fall back the device-tree > >> specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' > >> on the boot device if no device-tree is specified in the boot > >> option or via a bootefi command parameter. > >> > >> v3: > >> Add missing '@' in EFI_LP_DP_PART_FDT description. > >> Use calloc() instead of malloc() in load_fdt_from_load_option(). > >> Add missing '@' in load_fdt_from_load_option function description > >> Rename struct efi_initrd_dp to efi_lo_dp_prefix. > >> > >> v2: > >> Update efi_dp_concat() instead of new function efi_dp_merge(). > >> Carve out a function efi_load_option_dp_join() which we can > >> use both for the eficonfig and the efidebug command. > >> Rename variables id_dp, final_dp_size. > >> Rename create_initrd_dp() to create_lo_dp_part(). > >> Use enum as parameter for create_lo_dp_part(). > >> Put all related changes into one patch. > >> > >> Heinrich Schuchardt (8): > >>efi_loader: allow concatenation with contained end node > >>cmd: eficonfig: add support for setting fdt > >>cmd: efidebug: add support for setting fdt > >>efi_loader: load device-tree specified in boot option > >>efi_loader: move distro_efi_get_fdt_name() > >>efi_loader: return binary from efi_dp_from_lo() > >>efi_loader: export efi_load_image_from_path > >>efi_loader: load distro dtb in bootmgr > >> > >> boot/bootmeth_efi.c| 60 +- > >> cmd/eficonfig.c| 83 + > >> cmd/efidebug.c | 130 +++-- > >> include/efi_loader.h | 24 +++- > >> lib/efi_loader/Makefile| 1 + > >> lib/efi_loader/efi_bootbin.c | 2 +- > >> lib/efi_loader/efi_bootmgr.c | 75 +++- > >> lib/efi_loader/efi_boottime.c | 3 +- > >> lib/efi_loader/efi_device_path.c | 40 --- > >> lib/efi_loader/efi_device_path_utilities.c | 2 +- > >> lib/efi_loader/efi_fdt.c | 117 +++ > >> lib/efi_loader/efi_helper.c| 44 +++ > >> 12 files changed, 445 insertions(+), 136 deletions(-) > >> create mode 100644 lib/efi_loader/efi_fdt.c > >> > > > > Somewhat related, what work has been done to support FIT, or to locate > > a DT using the compatible string? > > CONFIG_BOOTM_EFI allows booting a FIT image containing an EFI binary and > optionally a device-tree. You can manually select a configuration when > invoking the bootm command. I am not aware of any automation for this > selection. Thanks for the info. Can we perhaps require FIT_BEST_MATCH and then provide a way? All this filename stuff is missing the point, really. It isn't going to get any easier, either. Regards, Simon
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
On Mon, 10 Jun 2024 at 20:47, Heinrich Schuchardt wrote:
>
> On 07.06.24 20:52, Sughosh Ganu wrote:
> > There are events that would be used to notify other interested modules
> > of any changes in available and occupied memory. This would happen
> > when a module allocates or reserves memory, or frees up memory. These
>
> I am worried about the "frees up memory" case.
>
> When LMB frees memory we cannot add it back to EFI conventional memory
> as there might still be a file image lingering around that EFI should
> not overwrite. It has to stay marked as EfiLoaderCode or EfiLoaderData.
So here is my basic doubt. Why would LMB free up memory if it still
has a valid image. If that is the case, the lmb_free API should not be
called?
-sughosh
>
> How do you ensure that if a region reserved by LMB notification as
> EfiLoaderData is coalesced with some other allocation LMB is not
> requested to mark the coalesced region as reserved?
>
> @Tom
>
> Clinging to the existing logic that you can do anything when loading
> files is obviously leading us into coding hell.
>
> If somebody wants to load two images into the same location, he should
> be forced to unload the first image. This will allow us to have a single
> memory management system.
>
> Best regards
>
> Heinrich
>
> > changes in memory map should be notified to other interested modules
> > so that the allocated memory does not get overwritten. Add an event
> > handler in the EFI memory module to update the EFI memory map
> > accordingly when such changes happen. As a consequence, any subsequent
> > memory request would honour the updated memory map and only available
> > memory would be allocated from.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > lib/efi_loader/efi_memory.c | 70 ++---
> > 1 file changed, 58 insertions(+), 12 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > index 435e580fb3..93244161b0 100644
> > --- a/lib/efi_loader/efi_memory.c
> > +++ b/lib/efi_loader/efi_memory.c
> > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> > #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> > extern bool is_addr_in_ram(uintptr_t addr);
> >
> > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > + int memory_type,
> > + bool overlap_only_ram);
> > +
> > static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> > {
> > struct event_efi_mem_map_update efi_map = {0};
> > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64 size, u8
> > op)
> > if (is_addr_in_ram((uintptr_t)addr))
> > event_notify(EVT_EFI_MEM_MAP_UPDATE, _map,
> > sizeof(efi_map));
> > }
> > +
> > +static int lmb_mem_map_update_sync(void *ctx, struct event *event)
> > +{
> > + u8 op;
> > + u64 addr;
> > + u64 pages;
> > + efi_status_t status;
> > + struct event_lmb_map_update *lmb_map = >data.lmb_map;
> > +
> > + addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > + pages = efi_size_in_pages(lmb_map->size + (addr & EFI_PAGE_MASK));
> > + op = lmb_map->op;
> > + addr &= ~EFI_PAGE_MASK;
> > +
> > + if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > + log_debug("Invalid map update op received (%d)\n", op);
> > + return -1;
> > + }
> > +
> > + status = __efi_add_memory_map_pg(addr, pages,
> > + op == MAP_OP_FREE ?
> > + EFI_CONVENTIONAL_MEMORY :
> > + EFI_BOOT_SERVICES_DATA,
> > + true);
> > +
> > + return status == EFI_SUCCESS ? 0 : -1;
> > +}
> > +EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
> > #endif /* MEM_MAP_UPDATE_NOTIFY */
> >
> > /**
> > @@ -275,18 +307,9 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
> > return EFI_CARVE_LOOP_AGAIN;
> > }
> >
> > -/**
> > - * efi_add_memory_map_pg() - add pages to the memory map
> > - *
> > - * @start: start address, must be a multiple of EFI_PAGE_SIZE
> > - * @pages: number of pages to add
> > - * @memory_type: type of memory added
> > - * @overlap_only_ram:region may only overlap RAM
> > - * Return: status code
> > - */
> > -static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
> > - int memory_type,
> > - bool overlap_only_ram)
> > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > + int memory_type,
> > + bool overlap_only_ram)
> > {
> > struct list_head *lhandle;
> > struct efi_mem_list *newlist;
> > @@ -395,6 +418,29 @@ static efi_status_t efi_add_memory_map_pg(u64 start,
> > u64 pages,
> > }
> >
Re: [PATCH 7/9] rockchip: bob: kevin: Disable dcache in SPL
Hi Jonas, On Thu, 6 Jun 2024 at 09:04, Simon Glass wrote: > > Hi Jonas, > > On Wed, 5 Jun 2024 at 05:07, Jonas Karlman wrote: > > > > Hi Simon, > > > > On 2024-06-05 05:25, Simon Glass wrote: > > > This causes a hang, so disable it. > > > > When I initially tested this on multiple boards there was some boards > > that also hanged, that turned out to be an issue in one of the drivers. > > > > If I remember correctly such hang was related to a null pointer > > dereference or unaligned access in one of the drivers. > > > > Could there be a similar underlying issue for these boards? > > Yes it could be. I will take a look. > > But given the release date I would like to get this patch in first. I did find a bug in memory sizing, but fixing that was not enough to get the cache running. I am not sure how to debug it, since presumably the code works fine on other rk3399 boards (sadly mine broke a few days ago). Regards, Simon
Re: Proposal: U-Boot memory management
hi Simon, On Mon, 10 Jun 2024 at 20:33, Simon Glass wrote: > > Hi Sughosh, > > On Mon, 10 Jun 2024 at 08:40, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Mon, 10 Jun 2024 at 19:25, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu wrote: > > > > > > > > hi Simon, > > > > > > > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > > > > > > > +Sughosh Ganu for reference > > > > > > > > > > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini > > > > > > > : > > > > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > > > > >> Hi Tom, > > > > > > > >> > > > > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini > > > > > > > >> wrote: > > > > > > > >> > > > > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > > > > > >> > > Hi, > > > > > > > >> > > > > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > > > > >> > > wrote: > > > > > > > >> > > > > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis > > > > > > > >> > > > wrote: > > > > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > > > > >> > > > > > From: Tom Rini > > > > > > > >> > > > > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > > > > >> > > > > > Schuchardt wrote: > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > > > > > >> > > > > > > : > > > > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon > > > > > > > >> > > > > > > >Glass wrote: > > > > > > > >> > > > > > > >> Hi, > > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > > > > >> > > > > > > >> wrote: > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > Hi, > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > This records my thoughts after a discussion > > > > > > > >> > > > > > > >> > with Ilias & Heinrich re > > > > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > 1. malloc() > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > > > > >> > > > > > > >> > allocation. It allows memory > > > > > > > >> > > > > > > >> > to be freed. It is not designed for very > > > > > > > >> > > > > > > >> > large allocations (e.g. a > > > > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > 2. lmb > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such > > > > > > > >> > > > > > > >> > as those needed for a > > > > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only > > > > > > > >> > > > > > > >> > transitory, for the purposes of > > > > > > > >> > > > > > > >> > loading some images and booting. If the boot > > > > > > > >> > > > > > > >> > fails, then all lmb > > > > > > > >> > > > > > > >> > allocations go away. > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > lmb is set up by getting all available memory > > > > > > > >> > > > > > > >> > and then removing what > > > > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() > > > > > > > >> > > > > > > >> > space, etc.) > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > lmb reservations have a few flags so that > > > > > > > >> > > > > > > >> > areas of memory can be > > > > > > > >> > > > > > > >> > provided with attributes > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a > > > > > > > >> > > > > > > >> > file does an lmb > > > > > > > >> > > > > > > >> > allocation but only for the purpose of > > > > > > > >> > > > > > > >> > avoiding a file being loaded > > > > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is > > > > > > > >> > > > > > > >> > dropped immediately after the > > > > > > > >> > > > > > > >> > file is loaded. Within the bootm command, or > > > > > > > >> > > > > > > >> > when using standard boot, > > > > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should > > > > > > > >> > > > > > > >> > consider doing the same. > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > 3. EFI > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > > > > > >> > > > > > > >> > > > > > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large
Re: [PATCH 5/6] bootstd: Add a bootmeth for Android
Hi Mattijs,
On Thu, Jun 6, 2024 at 2:24 PM Mattijs Korpershoek
wrote:
>
> Android boot flow is a bit different than a regular Linux distro.
> Android relies on multiple partitions in order to boot.
>
> A typical boot flow would be:
> 1. Parse the Bootloader Control Block (BCB, misc partition)
> 2. If BCB requested bootonce-bootloader, start fastboot and wait.
> 3. If BCB requested recovery or normal android, run the following:
> 3.a. Get slot (A/B) from BCB
> 3.b. Run AVB (Android Verified Boot) on boot partitions
> 3.c. Load boot and vendor_boot partitions
> 3.d. Load device-tree, ramdisk and boot
>
> The AOSP documentation has more details at [1], [2], [3]
>
> This has been implemented via complex boot scripts such as [4].
> However, these boot script are neither very maintainable nor generic.
> Moreover, DISTRO_DEFAULTS is being deprecated [5].
>
> Add a generic Android bootflow implementation for bootstd.
> For this initial version, only boot image v4 is supported.
>
> [1] https://source.android.com/docs/core/architecture/bootloader
> [2] https://source.android.com/docs/core/architecture/partitions
> [3] https://source.android.com/docs/core/architecture/partitions/generic-boot
> [4]
> https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
> [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-...@chromium.org/
>
> Signed-off-by: Mattijs Korpershoek
> ---
> MAINTAINERS | 7 +
> boot/Kconfig| 14 ++
> boot/Makefile | 2 +
> boot/bootmeth_android.c | 522
>
> boot/bootmeth_android.h | 27 +++
> doc/develop/bootstd.rst | 6 +
> 6 files changed, 578 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 66783d636e3d..6d2b87720565 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -939,6 +939,13 @@ F: include/bootstd.h
> F: net/eth_bootdevice.c
> F: test/boot/
>
> +BOOTMETH_ANDROID
> +M: Mattijs Korpershoek
> +S: Maintained
> +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git
> +F: boot/bootmeth_android.c
> +F: boot/bootmeth_android.h
> +
> BTRFS
> M: Marek Behún
> R: Qu Wenruo
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 6f3096c15a6f..5fa6f3b8315d 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -494,6 +494,20 @@ config BOOTMETH_GLOBAL
> EFI bootmgr, since they take full control over which bootdevs are
> selected to boot.
>
> +config BOOTMETH_ANDROID
> + bool "Bootdev support for Android"
> + depends on X86 || ARM || SANDBOX
> + select ANDROID_AB
> + select ANDROID_BOOT_IMAGE
> + select CMD_BCB
> + select PARTITION_TYPE_GUID
> + select PARTITION_UUIDS
> + help
> + Enables support for booting Android using bootdevs. Android requires
> + multiple partitions (misc, boot, vbmeta, ...) in storage for
> booting.
> +
> + Note that only MMC bootdevs are supported at present.
> +
> config BOOTMETH_CROS
> bool "Bootdev support for Chromium OS"
> depends on X86 || ARM || SANDBOX
> diff --git a/boot/Makefile b/boot/Makefile
> index 84ccfeaecec4..75d1cd46fabf 100644
> --- a/boot/Makefile
> +++ b/boot/Makefile
> @@ -66,3 +66,5 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_REQUEST) +=
> vbe_request.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_OS) += vbe_simple_os.o
> +
> +obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_ANDROID) += bootmeth_android.o
> diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
> new file mode 100644
> index ..26d548d2fd6e
> --- /dev/null
> +++ b/boot/bootmeth_android.c
> @@ -0,0 +1,522 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bootmethod for Android
> + *
> + * Copyright (C) 2024 BayLibre, SAS
> + * Written by Mattijs Korpershoek
> + */
> +#define LOG_CATEGORY UCLASS_BOOTSTD
> +
> +#include
> +#include
> +#if CONFIG_IS_ENABLED(AVB_VERIFY)
> +#include
> +#endif
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "bootmeth_android.h"
> +
> +#define BCB_FIELD_COMMAND_SZ 32
> +#define BCB_PART_NAME "misc"
> +#define BOOT_PART_NAME "boot"
> +#define VENDOR_BOOT_PART_NAME "vendor_boot"
> +
> +/**
> + * struct android_priv - Private data
> + *
> + * This is read from the disk and recorded for use when the full Android
> + * kernel must be loaded and booted
> + */
> +struct android_priv {
> + int boot_mode;
> + char slot[2];
> + u32 header_version;
> +};
> +
> +static int android_check(struct udevice *dev, struct bootflow_iter *iter)
> +{
> + /* This only works on mmc devices */
> + if (bootflow_iter_check_mmc(iter))
> + return log_msg_ret("mmc", -ENOTSUPP);
> +
> + /* This only works on whole
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
On 07.06.24 20:52, Sughosh Ganu wrote:
There are events that would be used to notify other interested modules
of any changes in available and occupied memory. This would happen
when a module allocates or reserves memory, or frees up memory. These
I am worried about the "frees up memory" case.
When LMB frees memory we cannot add it back to EFI conventional memory
as there might still be a file image lingering around that EFI should
not overwrite. It has to stay marked as EfiLoaderCode or EfiLoaderData.
How do you ensure that if a region reserved by LMB notification as
EfiLoaderData is coalesced with some other allocation LMB is not
requested to mark the coalesced region as reserved?
@Tom
Clinging to the existing logic that you can do anything when loading
files is obviously leading us into coding hell.
If somebody wants to load two images into the same location, he should
be forced to unload the first image. This will allow us to have a single
memory management system.
Best regards
Heinrich
changes in memory map should be notified to other interested modules
so that the allocated memory does not get overwritten. Add an event
handler in the EFI memory module to update the EFI memory map
accordingly when such changes happen. As a consequence, any subsequent
memory request would honour the updated memory map and only available
memory would be allocated from.
Signed-off-by: Sughosh Ganu
---
lib/efi_loader/efi_memory.c | 70 ++---
1 file changed, 58 insertions(+), 12 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 435e580fb3..93244161b0 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -73,6 +73,10 @@ struct efi_pool_allocation {
#if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
extern bool is_addr_in_ram(uintptr_t addr);
+static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
+ int memory_type,
+ bool overlap_only_ram);
+
static void efi_map_update_notify(u64 addr, u64 size, u8 op)
{
struct event_efi_mem_map_update efi_map = {0};
@@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64 size, u8 op)
if (is_addr_in_ram((uintptr_t)addr))
event_notify(EVT_EFI_MEM_MAP_UPDATE, _map, sizeof(efi_map));
}
+
+static int lmb_mem_map_update_sync(void *ctx, struct event *event)
+{
+ u8 op;
+ u64 addr;
+ u64 pages;
+ efi_status_t status;
+ struct event_lmb_map_update *lmb_map = >data.lmb_map;
+
+ addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
+ pages = efi_size_in_pages(lmb_map->size + (addr & EFI_PAGE_MASK));
+ op = lmb_map->op;
+ addr &= ~EFI_PAGE_MASK;
+
+ if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
+ log_debug("Invalid map update op received (%d)\n", op);
+ return -1;
+ }
+
+ status = __efi_add_memory_map_pg(addr, pages,
+op == MAP_OP_FREE ?
+EFI_CONVENTIONAL_MEMORY :
+EFI_BOOT_SERVICES_DATA,
+true);
+
+ return status == EFI_SUCCESS ? 0 : -1;
+}
+EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
#endif /* MEM_MAP_UPDATE_NOTIFY */
/**
@@ -275,18 +307,9 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
return EFI_CARVE_LOOP_AGAIN;
}
-/**
- * efi_add_memory_map_pg() - add pages to the memory map
- *
- * @start: start address, must be a multiple of EFI_PAGE_SIZE
- * @pages: number of pages to add
- * @memory_type: type of memory added
- * @overlap_only_ram: region may only overlap RAM
- * Return: status code
- */
-static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
- int memory_type,
- bool overlap_only_ram)
+static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
+ int memory_type,
+ bool overlap_only_ram)
{
struct list_head *lhandle;
struct efi_mem_list *newlist;
@@ -395,6 +418,29 @@ static efi_status_t efi_add_memory_map_pg(u64 start, u64
pages,
}
}
+ return EFI_SUCCESS;
+}
+
+/**
+ * efi_add_memory_map_pg() - add pages to the memory map
+ *
+ * @start: start address, must be a multiple of EFI_PAGE_SIZE
+ * @pages: number of pages to add
+ * @memory_type: type of memory added
+ * @overlap_only_ram: region may only overlap RAM
+ * Return: status code
+ */
+static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
+ int memory_type,
+ bool overlap_only_ram)
+{
+
Re: [PATCH 0/3] lib: smbios: Extend driver with using sysinfo driver
Hi Michal, On Fri, 7 Jun 2024 at 01:53, Michal Simek wrote: > > > > On 5/24/24 12:07, Ilias Apalodimas wrote: > > Hi Michal > > > > > > On Fri, 24 May 2024 at 12:45, Michal Simek wrote: > >> > >> Hi Ilias, > >> > >> On 4/26/24 15:38, Michal Simek wrote: > >>> Hi, > >>> > >>> currently only DT way is supported and it is added directly to > >>> lib/smbios.c > >>> but I think DT and env is only one way how information can be found that's > >>> why this series is improving handling with using sysinfo driver which can > >>> be platform specific. > >>> At the end of day DT should be taken from smbios.c and put to sysinfo DT > >>> driver instead of implementing it directly in this generic file. > >>> > >>> Thanks, > >>> Michal > >>> > >>> > >>> Michal Simek (3): > >>> xilinx: Enable SMBIOS command > >>> lib: smbios: Let detect the system via sysinfo > >>> lib: smbios: Detect system properties via SYSINFO IDs > >>> > >>>configs/xilinx_versal_net_virt_defconfig | 1 + > >>>configs/xilinx_versal_virt_defconfig | 1 + > >>>configs/xilinx_zynqmp_kria_defconfig | 1 + > >>>configs/xilinx_zynqmp_virt_defconfig | 1 + > >>>include/sysinfo.h| 9 + > >>>lib/smbios.c | 42 +++- > >>>6 files changed, 46 insertions(+), 9 deletions(-) > >>> > >> > >> > >> Any comment on this series? > > > > It's mostly Simon that created that sysinfo stuff, so I was expecting > > him to have a look. > > I can put in on my bucket list, but that's going to take some time > > Simon: Any comment? It looks OK to me. Regards, Simon
Re: [PATCH 3/3] lib: smbios: Detect system properties via SYSINFO IDs
On Fri, 26 Apr 2024 at 07:38, Michal Simek wrote: > > Code is pretty much supports only DT properties and completely ignore > information coming from sysinfo driver. > Code is calling smbios_add_prop() which calls with > smbios_add_prop_si(SYSINFO_ID_NONE). But SYSINFO_ID_NONE can't > differentiate different entries from sysinfo driver. > That's why introduce separate SYSINFO macros which can be used in sysinfo > driver and passed to smbios structure. > > Signed-off-by: Michal Simek > --- > > include/sysinfo.h | 9 + > lib/smbios.c | 34 ++ > 2 files changed, 35 insertions(+), 8 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 2/3] lib: smbios: Let detect the system via sysinfo
On Fri, 26 Apr 2024 at 07:38, Michal Simek wrote: > > Currently code looks like that it sysinfo drivers are supported but > actually none checking that system is detected. That's why call > sysinfo_detect() to make sure that priv->detected in sysinfo uclass is > setup hence information from driver can be passed to smbios. > > Signed-off-by: Michal Simek > --- > > lib/smbios.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: Proposal: U-Boot memory management
Hi Sughosh, On Mon, 10 Jun 2024 at 08:40, Sughosh Ganu wrote: > > hi Simon, > > On Mon, 10 Jun 2024 at 19:25, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > > > > > +Sughosh Ganu for reference > > > > > > > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini > > > > > > : > > > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > > > >> Hi Tom, > > > > > > >> > > > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini > > > > > > >> wrote: > > > > > > >> > > > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > > > > >> > > Hi, > > > > > > >> > > > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > > > >> > > wrote: > > > > > > >> > > > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis > > > > > > >> > > > wrote: > > > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > > > >> > > > > > From: Tom Rini > > > > > > >> > > > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > > > >> > > > > > Schuchardt wrote: > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > > > > >> > > > > > > : > > > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon > > > > > > >> > > > > > > >Glass wrote: > > > > > > >> > > > > > > >> Hi, > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > > > >> > > > > > > >> wrote: > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > Hi, > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > This records my thoughts after a discussion > > > > > > >> > > > > > > >> > with Ilias & Heinrich re > > > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > 1. malloc() > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > > > >> > > > > > > >> > allocation. It allows memory > > > > > > >> > > > > > > >> > to be freed. It is not designed for very large > > > > > > >> > > > > > > >> > allocations (e.g. a > > > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > 2. lmb > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such as > > > > > > >> > > > > > > >> > those needed for a > > > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only > > > > > > >> > > > > > > >> > transitory, for the purposes of > > > > > > >> > > > > > > >> > loading some images and booting. If the boot > > > > > > >> > > > > > > >> > fails, then all lmb > > > > > > >> > > > > > > >> > allocations go away. > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > lmb is set up by getting all available memory > > > > > > >> > > > > > > >> > and then removing what > > > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() space, > > > > > > >> > > > > > > >> > etc.) > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > lmb reservations have a few flags so that areas > > > > > > >> > > > > > > >> > of memory can be > > > > > > >> > > > > > > >> > provided with attributes > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a > > > > > > >> > > > > > > >> > file does an lmb > > > > > > >> > > > > > > >> > allocation but only for the purpose of avoiding > > > > > > >> > > > > > > >> > a file being loaded > > > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is > > > > > > >> > > > > > > >> > dropped immediately after the > > > > > > >> > > > > > > >> > file is loaded. Within the bootm command, or > > > > > > >> > > > > > > >> > when using standard boot, > > > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should > > > > > > >> > > > > > > >> > consider doing the same. > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > 3. EFI > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large > > > > > > >> > > > > > > >> > allocations. But via a 'pool' > > > > > > >> > > > > > > >> > function it can also do smaller allocations > > > > > > >> > > > > > > >> > similar to malloc(), > > > > > > >> > > > > > > >> > although each one uses at least 4KB at present. > >
[PATCH v2 9/9] Drop the special am335x_boneblack_vboot target
Now that am335x_evm boots OK on the Beaglebone black, drop the latter and update the docs to cover the change. Also add a few updates about 'make fit' and drop the note about the security review, as U-Boot's verified boot has had quite extensive review now. Signed-off-by: Simon Glass --- Changes in v2: - Drop patch "regulator: rk8xx: Fix incorrect parameter" - Rewrite boneblack patch to onstead drop the target and update docs board/ti/am335x/MAINTAINERS | 1 - configs/am335x_boneblack_vboot_defconfig | 94 configs/am335x_evm_defconfig | 3 +- doc/usage/fit/beaglebone_vboot.rst | 21 +++--- 4 files changed, 12 insertions(+), 107 deletions(-) delete mode 100644 configs/am335x_boneblack_vboot_defconfig diff --git a/board/ti/am335x/MAINTAINERS b/board/ti/am335x/MAINTAINERS index 219c8715bf1..ed8800a2663 100644 --- a/board/ti/am335x/MAINTAINERS +++ b/board/ti/am335x/MAINTAINERS @@ -3,6 +3,5 @@ M: Tom Rini S: Maintained F: board/ti/am335x/ F: include/configs/am335x_evm.h -F: configs/am335x_boneblack_vboot_defconfig F: configs/am335x_evm_defconfig F: configs/am335x_evm_spiboot_defconfig diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig deleted file mode 100644 index d473a1a793b..000 --- a/configs/am335x_boneblack_vboot_defconfig +++ /dev/null @@ -1,94 +0,0 @@ -CONFIG_ARM=y -CONFIG_ARCH_CPU_INIT=y -# CONFIG_SPL_USE_ARCH_MEMCPY is not set -# CONFIG_SPL_USE_ARCH_MEMSET is not set -CONFIG_ARCH_OMAP2PLUS=y -CONFIG_TI_COMMON_CMD_OPTIONS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00 -CONFIG_SF_DEFAULT_SPEED=2400 -CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack" -CONFIG_AM33XX=y -CONFIG_CLOCK_SYNTHESIZER=y -CONFIG_SPL=y -CONFIG_ENV_OFFSET_REDUND=0x28 -CONFIG_TIMESTAMP=y -CONFIG_FIT_SIGNATURE=y -CONFIG_FIT_VERBOSE=y -CONFIG_SYS_BOOTM_LEN=0x100 -CONFIG_DISTRO_DEFAULTS=y -CONFIG_AUTOBOOT_KEYED=y -CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" -CONFIG_AUTOBOOT_DELAY_STR="d" -CONFIG_AUTOBOOT_STOP_STR=" " -CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd" -CONFIG_SYS_CONSOLE_INFO_QUIET=y -CONFIG_ARCH_MISC_INIT=y -CONFIG_SPL_SYS_MALLOC=y -CONFIG_SPL_SYS_MALLOC_SIZE=0x80 -CONFIG_SPL_MUSB_NEW=y -# CONFIG_SPL_NAND_SUPPORT is not set -CONFIG_SPL_NET=y -CONFIG_SPL_NET_VCI_STRING="AM33xx U-Boot SPL" -CONFIG_SPL_OS_BOOT=y -CONFIG_SPL_FALCON_BOOT_MMCSD=y -CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1700 -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR=0x1500 -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS=0x200 -CONFIG_CMD_SPL=y -CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 -# CONFIG_CMD_SETEXPR is not set -CONFIG_BOOTP_DNS2=y -CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y -CONFIG_ENV_OVERWRITE=y -CONFIG_ENV_IS_IN_MMC=y -CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_SYS_RELOC_GD_ENV_ADDR=y -CONFIG_SYS_MMC_ENV_DEV=1 -CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_VERSION_VARIABLE=y -CONFIG_NET_RETRY_COUNT=10 -CONFIG_BOOTP_SEND_HOSTNAME=y -# CONFIG_SPL_BLK is not set -CONFIG_BOOTCOUNT_LIMIT=y -CONFIG_SYS_BOOTCOUNT_BE=y -CONFIG_DFU_MMC=y -CONFIG_DFU_RAM=y -CONFIG_USB_FUNCTION_FASTBOOT=y -CONFIG_DM_I2C=y -CONFIG_MISC=y -CONFIG_SYS_I2C_EEPROM_ADDR=0x50 -# CONFIG_SPL_DM_MMC is not set -CONFIG_MMC_OMAP_HS=y -CONFIG_MTD=y -CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_WINBOND=y -CONFIG_PHY_ATHEROS=y -CONFIG_PHY_SMSC=y -CONFIG_PHY_GIGE=y -CONFIG_MII=y -CONFIG_DRIVER_TI_CPSW=y -CONFIG_DM_PMIC=y -# CONFIG_SPL_DM_PMIC is not set -CONFIG_PMIC_TPS65217=y -CONFIG_SPL_POWER_TPS65910=y -CONFIG_SPI=y -CONFIG_DM_SPI=y -CONFIG_OMAP3_SPI=y -CONFIG_TIMER=y -CONFIG_OMAP_TIMER=y -CONFIG_USB=y -CONFIG_DM_USB_GADGET=y -CONFIG_SPL_DM_USB_GADGET=y -CONFIG_USB_MUSB_HOST=y -CONFIG_USB_MUSB_GADGET=y -CONFIG_USB_MUSB_TI=y -CONFIG_USB_GADGET=y -CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" -CONFIG_USB_GADGET_VENDOR_NUM=0x0451 -CONFIG_USB_GADGET_PRODUCT_NUM=0xd022 -CONFIG_USB_ETHER=y -CONFIG_SPL_USB_ETHER=y -CONFIG_LZO=y diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index d243cb16e72..cabc181460a 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -13,6 +13,8 @@ CONFIG_AM335X_USB0_PERIPHERAL=y CONFIG_AM335X_USB1=y CONFIG_SPL=y CONFIG_TIMESTAMP=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y CONFIG_SPL_LOAD_FIT=y CONFIG_SYS_BOOTM_LEN=0x100 CONFIG_DISTRO_DEFAULTS=y @@ -119,5 +121,4 @@ CONFIG_SPL_USB_ETHER=y CONFIG_WDT=y # CONFIG_SPL_WDT is not set CONFIG_DYNAMIC_CRC_TABLE=y -CONFIG_RSA=y CONFIG_LZO=y diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index cd6bb141910..1360c71803c 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -67,18 +67,20 @@ a. Set up the environment variable to point to your toolchain. You will need export CROSS_COMPILE=arm-linux-gnueabi-
[PATCH v2 8/9] rockchip: bob: kevin: Disable dcache in SPL
This causes a hang, so disable it. Unfortunately the RAM-size fix does
not resolve the problem and I am unsure what is wrong. As soon as the
cache is enabled the board appears to hang.
Fixes: 6d8cdfd1536 ("rockchip: spl: Enable caches to speed up checksum
validation")
Signed-off-by: Simon Glass
---
(no changes since v1)
configs/chromebook_bob_defconfig | 1 +
configs/chromebook_kevin_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index acfe3934104..b2ecfa6050c 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SPL_SYS_DCACHE_OFF=y
CONFIG_COUNTER_FREQUENCY=2400
CONFIG_ARCH_ROCKCHIP=y
CONFIG_TEXT_BASE=0x0020
diff --git a/configs/chromebook_kevin_defconfig
b/configs/chromebook_kevin_defconfig
index 95fdb418d82..da748e4f022 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
CONFIG_SKIP_LOWLEVEL_INIT=y
CONFIG_COUNTER_FREQUENCY=2400
CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SPL_SYS_DCACHE_OFF=y
CONFIG_TEXT_BASE=0x0020
CONFIG_SPL_GPIO=y
CONFIG_NR_DRAM_BANKS=1
--
2.34.1
[PATCH v2 7/9] rockchip: Ensure memory size is available in RK3399 SPL
At present gd->ram_size is 0 in SPL, meaning that it is not possible to
enable the cache. Correct this by always populating the RAM size
correctly.
Part of the confusion here comes from the large blocks of code which
are #ifdefed out. Add a function phase_sdram_init() which returns
whether SDRAM init should happen in the current phase, using that as
needed to control the code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to correct memory size in SPL
drivers/ram/rockchip/sdram_rk3399.c | 49 -
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 02cc4a38cf0..2f37dd712e7 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -63,8 +64,6 @@ struct chan_info {
};
struct dram_info {
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
u32 pwrup_srefresh_exit[2];
struct chan_info chan[2];
struct clk ddr_clk;
@@ -75,7 +74,6 @@ struct dram_info {
struct rk3399_pmusgrf_regs *pmusgrf;
struct rk3399_ddr_cic_regs *cic;
const struct sdram_rk3399_ops *ops;
-#endif
struct ram_info info;
struct rk3399_pmugrf_regs *pmugrf;
};
@@ -92,9 +90,6 @@ struct sdram_rk3399_ops {
struct rk3399_sdram_params *params);
};
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
-
struct rockchip_dmc_plat {
#if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_rockchip_rk3399_dmc dtplat;
@@ -191,6 +186,17 @@ struct io_setting {
},
};
+/**
+ * phase_sdram_init() - Check if this is the phase where SDRAM init happens
+ *
+ * Returns: true to do SDRAM init in this phase, false to not
+ */
+static bool phase_sdram_init(void)
+{
+ return spl_phase() == PHASE_TPL ||
+ (!IS_ENABLED(CONFIG_TPL) && !spl_in_proper());
+}
+
static struct io_setting *
lpddr4_get_io_settings(const struct rk3399_sdram_params *params, u32 mr5)
{
@@ -3024,7 +3030,7 @@ static int rk3399_dmc_of_to_plat(struct udevice *dev)
struct rockchip_dmc_plat *plat = dev_get_plat(dev);
int ret;
- if (!CONFIG_IS_ENABLED(OF_REAL))
+ if (!CONFIG_IS_ENABLED(OF_REAL) || !phase_sdram_init())
return 0;
ret = dev_read_u32_array(dev, "rockchip,sdram-params",
@@ -3138,23 +3144,25 @@ static int rk3399_dmc_init(struct udevice *dev)
return 0;
}
-#endif
static int rk3399_dmc_probe(struct udevice *dev)
{
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
- if (rk3399_dmc_init(dev))
- return 0;
-#else
struct dram_info *priv = dev_get_priv(dev);
- priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
- debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
- priv->info.base = CFG_SYS_SDRAM_BASE;
- priv->info.size =
- rockchip_sdram_size((phys_addr_t)>pmugrf->os_reg2);
-#endif
+ if (phase_sdram_init()) {
+ if (rk3399_dmc_init(dev))
+ return 0;
+ } else {
+ priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+ debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
+ }
+
+ if (!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
+ priv->info.base = CFG_SYS_SDRAM_BASE;
+ priv->info.size =
+ rockchip_sdram_size((ulong)>pmugrf->os_reg2);
+ }
+
return 0;
}
@@ -3181,10 +3189,7 @@ U_BOOT_DRIVER(dmc_rk3399) = {
.id = UCLASS_RAM,
.of_match = rk3399_dmc_ids,
.ops = _dmc_ops,
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
.of_to_plat = rk3399_dmc_of_to_plat,
-#endif
.probe = rk3399_dmc_probe,
.priv_auto = sizeof(struct dram_info),
#if defined(CONFIG_TPL_BUILD) || \
--
2.34.1
[PATCH v2 5/9] fdt: Correct condition for bloblist existing
On some boards, the bloblist is created in SPL once SDRAM is ready. It
cannot be accessed until that point, so is not available early in SPL.
Add a condition to avoid a hang in this case.
This fixes a hang in chromebook_coral
Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Simon Glass
---
Changes in v2:
- Use 'phase' instead of 'stage'
lib/fdtdec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index b2c59ab3818..79eaa56ea39 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1669,8 +1669,16 @@ int fdtdec_setup(void)
{
int ret = -ENOENT;
- /* If allowing a bloblist, check that first */
- if (CONFIG_IS_ENABLED(BLOBLIST)) {
+ /*
+* If allowing a bloblist, check that first. This would be better
+* handled with an OF_BLOBLIST Kconfig, but that caused far too much
+* argument, so add a hack here, used e.g. by chromebook_coral
+* The necessary test is whether the previous phase passed a bloblist,
+* not whether this phase creates one.
+*/
+ if (CONFIG_IS_ENABLED(OF_BLOBLIST) &&
+ (spl_prev_phase() != PHASE_TPL ||
+!IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
ret = bloblist_maybe_init();
if (!ret) {
gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
--
2.34.1
[PATCH v2 6/9] spl: Allow ATF to work when dcache is disabled
The dcache may not be enabled in SPL. Add a check to avoid trying to use an undefined function. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- (no changes since v1) common/spl/spl_atf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c index 3bdd013a35f..9afe6456bc4 100644 --- a/common/spl/spl_atf.c +++ b/common/spl/spl_atf.c @@ -204,7 +204,8 @@ static void __noreturn bl31_entry(uintptr_t bl31_entry, uintptr_t bl32_entry, fdt_addr); raw_write_daif(SPSR_EXCEPTION_MASK); - dcache_disable(); + if (!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) + dcache_disable(); atf_entry(bl31_params, (void *)fdt_addr); } -- 2.34.1
[PATCH v2 4/9] power: regulator: Handle autoset in regulators_enable_boot_on()
With a recent change, regulators_enable_boot_on() returns an error if a
regulator is already set. Check for and handle this situation.
Fixes: d99fb64a98a power: regulator: Only run autoset once for each regulator
Reviewed-by: Jonas Karlman
Reviewed-by: Quentin Schulz
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/power/regulator/regulator-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 77d101f262e..d9e1fb68295 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -518,7 +518,7 @@ int regulators_enable_boot_on(bool verbose)
dev;
uclass_next_device()) {
ret = regulator_autoset(dev);
- if (ret == -EMEDIUMTYPE) {
+ if (ret == -EMEDIUMTYPE || ret == -EALREADY) {
ret = 0;
continue;
}
--
2.34.1
[PATCH v2 3/9] rockchip: veyron: Add logging for power init
Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can
be enabled.
Signed-off-by: Simon Glass
---
Changes in v2:
- Remove the superfluous if() and drop the debug() as well
board/google/veyron/veyron.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/board/google/veyron/veyron.c b/board/google/veyron/veyron.c
index 32dbcdc4d10..6d4c9debdee 100644
--- a/board/google/veyron/veyron.c
+++ b/board/google/veyron/veyron.c
@@ -29,44 +29,38 @@ static int veyron_init(void)
int ret;
ret = regulator_get_by_platname("vdd_arm", );
- if (ret) {
- debug("Cannot set regulator name\n");
- return ret;
- }
+ if (ret)
+ return log_msg_ret("vdd", ret);
/* Slowly raise to max CPU voltage to prevent overshoot */
ret = regulator_set_value(dev, 120);
if (ret)
- return ret;
+ return log_msg_ret("s12", ret);
udelay(175); /* Must wait for voltage to stabilize, 2mV/us */
ret = regulator_set_value(dev, 140);
if (ret)
- return ret;
+ return log_msg_ret("s14", ret);
udelay(100); /* Must wait for voltage to stabilize, 2mV/us */
ret = rockchip_get_clk();
if (ret)
- return ret;
+ return log_msg_ret("clk", ret);
clk.id = PLL_APLL;
ret = clk_set_rate(, 18);
if (IS_ERR_VALUE(ret))
- return ret;
+ return log_msg_ret("s18", ret);
ret = regulator_get_by_platname("vcc33_sd", );
- if (ret) {
- debug("Cannot get regulator name\n");
- return ret;
- }
+ if (ret)
+ return log_msg_ret("vcc", ret);
ret = regulator_set_value(dev, 330);
if (ret)
- return ret;
+ return log_msg_ret("s33", ret);
ret = regulators_enable_boot_on(false);
- if (ret) {
- debug("%s: Cannot enable boot on regulators\n", __func__);
- return ret;
- }
+ if (ret)
+ return log_msg_ret("boo", ret);
return 0;
}
@@ -81,7 +75,7 @@ int board_early_init_r(void)
if (!fdt_node_check_compatible(gd->fdt_blob, 0, "google,veyron")) {
ret = veyron_init();
if (ret)
- return ret;
+ return log_msg_ret("vey", ret);
}
#endif
/*
--
2.34.1
[PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
It does not make sense to enable all SHA algorithms unless they are needed. It bloats the code and in this case, causes chromebook_link to fail to build. That board does use the TPM, but not with measured boot, nor EFI. Since EFI_TCG2_PROTOCOL already selects these options, we just need to add them to MEASURED_BOOT as well. Note that the original commit combines refactoring and new features, which makes it hard to see what is going on. Fixes: 97707f12fda tpm: Support boot measurements Signed-off-by: Simon Glass --- Changes in v2: - Put the conditions under EFI_TCG2_PROTOCOL - Consider MEASURED_BOOT too boot/Kconfig | 4 lib/Kconfig | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 6f3096c15a6..b061891e109 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -734,6 +734,10 @@ config LEGACY_IMAGE_FORMAT config MEASURED_BOOT bool "Measure boot images and configuration when booting without EFI" depends on HASH && TPM_V2 + select SHA1 + select SHA256 + select SHA384 + select SHA512 help This option enables measurement of the boot process when booting without UEFI . Measurement involves creating cryptographic hashes diff --git a/lib/Kconfig b/lib/Kconfig index 189e6eb31aa..568892fce44 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -438,10 +438,6 @@ config TPM bool "Trusted Platform Module (TPM) Support" depends on DM imply DM_RNG - select SHA1 - select SHA256 - select SHA384 - select SHA512 help This enables support for TPMs which can be used to provide security features for your board. The TPM can be connected via LPC or I2C -- 2.34.1
[PATCH v2 1/9] nvidia: nyan-big: Disable debug UART
This cannot be enabled early in boot since some other init is needed. At this point it is unclear exactly what init is needed, so disable the debug UART to avoid a hang. Signed-off-by: Simon Glass --- (no changes since v1) configs/nyan-big_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/nyan-big_defconfig b/configs/nyan-big_defconfig index 1483d17d975..4dec710cf8d 100644 --- a/configs/nyan-big_defconfig +++ b/configs/nyan-big_defconfig @@ -17,7 +17,6 @@ CONFIG_TEGRA124=y CONFIG_TARGET_NYAN_BIG=y CONFIG_TEGRA_GPU=y CONFIG_SYS_LOAD_ADDR=0x82408000 -CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_FIT_BEST_MATCH=y CONFIG_BOOTSTAGE=y -- 2.34.1
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
On Mon, 10 Jun 2024 at 20:22, Sughosh Ganu wrote:
>
> hi Ilias,
>
> On Mon, 10 Jun 2024 at 19:48, Ilias Apalodimas
> wrote:
> >
> > Hi Sughosh
> >
> > On Mon, 10 Jun 2024 at 15:25, Sughosh Ganu wrote:
> > >
> > > On Mon, 10 Jun 2024 at 17:40, Ilias Apalodimas
> > > wrote:
> > > >
> > > > On Fri, 7 Jun 2024 at 21:54, Sughosh Ganu
> > > > wrote:
> > > > >
> > > > > There are events that would be used to notify other interested modules
> > > > > of any changes in available and occupied memory. This would happen
> > > > > when a module allocates or reserves memory, or frees up memory. These
> > > > > changes in memory map should be notified to other interested modules
> > > > > so that the allocated memory does not get overwritten. Add an event
> > > > > handler in the EFI memory module to update the EFI memory map
> > > > > accordingly when such changes happen. As a consequence, any subsequent
> > > > > memory request would honour the updated memory map and only available
> > > > > memory would be allocated from.
> > > >
> > > > So the question here, is why do we need a notifier chain overall?
> > > > Can't we change the EFI subsystem and allocate memory with lmb now?
> > > > And any special functions we have in EFI (e.g allocate aligned memory)
> > > > can migrate to lmb()
> > >
> > > Like we discussed offline, that was my initial attempt -- to use the
> > > LMB allocation API's from inside the EFI allocate pages module. But I
> > > was facing a lot of corner case issues, primarily in keeping the two
> > > memory maps the same.
> >
> > I think it would worth discussing this a bit more. I like the idea of
> > having a single allocator more than having events to update memory
> > reservations
> >
> > > Which is why I moved to the current
> > > implementation of notifying other modules, and that too only for the
> > > addresses in the RAM region.
> >
> > The notification to 'other modules' i still done by updating the
> > static memory map though no?
> > So what corner cases we couldn't solve by having a single allocator?
>
> I can re-check what were the issues that I faced when trying with a
> single allocator. But please note that we are not making any
> significant gains by having a single allocator. Even with a common
> allocator(say LMB), it would still be required to have the same
> notification mechanism to update the EFI memory map. Else the EFI
> memory map would show regions of memory as conventional memory, while
> they are being used by the other subsystem. So, all in all, I think
> that the notification mechanism is not that inefficient. Thanks.
Or rather, "the notification mechanism is not inefficient".
-sughosh
>
> -sughosh
>
> >
> > Thanks
> > /Ilias
> > >
> > > -sughosh
> > >
> > > >
> > > > Cheers
> > > > /Ilias
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > lib/efi_loader/efi_memory.c | 70
> > > > > ++---
> > > > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > > > > index 435e580fb3..93244161b0 100644
> > > > > --- a/lib/efi_loader/efi_memory.c
> > > > > +++ b/lib/efi_loader/efi_memory.c
> > > > > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> > > > > #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> > > > > extern bool is_addr_in_ram(uintptr_t addr);
> > > > >
> > > > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > > > > + int memory_type,
> > > > > + bool overlap_only_ram);
> > > > > +
> > > > > static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> > > > > {
> > > > > struct event_efi_mem_map_update efi_map = {0};
> > > > > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64
> > > > > size, u8 op)
> > > > > if (is_addr_in_ram((uintptr_t)addr))
> > > > > event_notify(EVT_EFI_MEM_MAP_UPDATE, _map,
> > > > > sizeof(efi_map));
> > > > > }
> > > > > +
> > > > > +static int lmb_mem_map_update_sync(void *ctx, struct event *event)
> > > > > +{
> > > > > + u8 op;
> > > > > + u64 addr;
> > > > > + u64 pages;
> > > > > + efi_status_t status;
> > > > > + struct event_lmb_map_update *lmb_map = >data.lmb_map;
> > > > > +
> > > > > + addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > > > > + pages = efi_size_in_pages(lmb_map->size + (addr &
> > > > > EFI_PAGE_MASK));
> > > > > + op = lmb_map->op;
> > > > > + addr &= ~EFI_PAGE_MASK;
> > > > > +
> > > > > + if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > > > > + log_debug("Invalid map update op received (%d)\n",
> > > > > op);
> > > > > + return -1;
> > > > > + }
> > > > > +
> > > > > + status = __efi_add_memory_map_pg(addr, pages,
> > > > > +op == MAP_OP_FREE ?
> > > > > +
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
hi Ilias,
On Mon, 10 Jun 2024 at 19:48, Ilias Apalodimas
wrote:
>
> Hi Sughosh
>
> On Mon, 10 Jun 2024 at 15:25, Sughosh Ganu wrote:
> >
> > On Mon, 10 Jun 2024 at 17:40, Ilias Apalodimas
> > wrote:
> > >
> > > On Fri, 7 Jun 2024 at 21:54, Sughosh Ganu wrote:
> > > >
> > > > There are events that would be used to notify other interested modules
> > > > of any changes in available and occupied memory. This would happen
> > > > when a module allocates or reserves memory, or frees up memory. These
> > > > changes in memory map should be notified to other interested modules
> > > > so that the allocated memory does not get overwritten. Add an event
> > > > handler in the EFI memory module to update the EFI memory map
> > > > accordingly when such changes happen. As a consequence, any subsequent
> > > > memory request would honour the updated memory map and only available
> > > > memory would be allocated from.
> > >
> > > So the question here, is why do we need a notifier chain overall?
> > > Can't we change the EFI subsystem and allocate memory with lmb now?
> > > And any special functions we have in EFI (e.g allocate aligned memory)
> > > can migrate to lmb()
> >
> > Like we discussed offline, that was my initial attempt -- to use the
> > LMB allocation API's from inside the EFI allocate pages module. But I
> > was facing a lot of corner case issues, primarily in keeping the two
> > memory maps the same.
>
> I think it would worth discussing this a bit more. I like the idea of
> having a single allocator more than having events to update memory
> reservations
>
> > Which is why I moved to the current
> > implementation of notifying other modules, and that too only for the
> > addresses in the RAM region.
>
> The notification to 'other modules' i still done by updating the
> static memory map though no?
> So what corner cases we couldn't solve by having a single allocator?
I can re-check what were the issues that I faced when trying with a
single allocator. But please note that we are not making any
significant gains by having a single allocator. Even with a common
allocator(say LMB), it would still be required to have the same
notification mechanism to update the EFI memory map. Else the EFI
memory map would show regions of memory as conventional memory, while
they are being used by the other subsystem. So, all in all, I think
that the notification mechanism is not that inefficient. Thanks.
-sughosh
>
> Thanks
> /Ilias
> >
> > -sughosh
> >
> > >
> > > Cheers
> > > /Ilias
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > lib/efi_loader/efi_memory.c | 70 ++---
> > > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > > > index 435e580fb3..93244161b0 100644
> > > > --- a/lib/efi_loader/efi_memory.c
> > > > +++ b/lib/efi_loader/efi_memory.c
> > > > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> > > > #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> > > > extern bool is_addr_in_ram(uintptr_t addr);
> > > >
> > > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > > > + int memory_type,
> > > > + bool overlap_only_ram);
> > > > +
> > > > static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> > > > {
> > > > struct event_efi_mem_map_update efi_map = {0};
> > > > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64
> > > > size, u8 op)
> > > > if (is_addr_in_ram((uintptr_t)addr))
> > > > event_notify(EVT_EFI_MEM_MAP_UPDATE, _map,
> > > > sizeof(efi_map));
> > > > }
> > > > +
> > > > +static int lmb_mem_map_update_sync(void *ctx, struct event *event)
> > > > +{
> > > > + u8 op;
> > > > + u64 addr;
> > > > + u64 pages;
> > > > + efi_status_t status;
> > > > + struct event_lmb_map_update *lmb_map = >data.lmb_map;
> > > > +
> > > > + addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > > > + pages = efi_size_in_pages(lmb_map->size + (addr &
> > > > EFI_PAGE_MASK));
> > > > + op = lmb_map->op;
> > > > + addr &= ~EFI_PAGE_MASK;
> > > > +
> > > > + if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > > > + log_debug("Invalid map update op received (%d)\n", op);
> > > > + return -1;
> > > > + }
> > > > +
> > > > + status = __efi_add_memory_map_pg(addr, pages,
> > > > +op == MAP_OP_FREE ?
> > > > +EFI_CONVENTIONAL_MEMORY :
> > > > +EFI_BOOT_SERVICES_DATA,
> > > > +true);
> > > > +
> > > > + return status == EFI_SUCCESS ? 0 : -1;
> > > > +}
> > > > +EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
> > > > #endif /* MEM_MAP_UPDATE_NOTIFY */
>
Re: Proposal: U-Boot memory management
hi Simon, On Mon, 10 Jun 2024 at 19:25, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > > > +Sughosh Ganu for reference > > > > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini > > > > > : > > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > > >> Hi Tom, > > > > > >> > > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini > > > > > >> wrote: > > > > > >> > > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > > > >> > > Hi, > > > > > >> > > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > > >> > > wrote: > > > > > >> > > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis > > > > > >> > > > wrote: > > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > > >> > > > > > From: Tom Rini > > > > > >> > > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > > >> > > > > > Schuchardt wrote: > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > > > >> > > > > > > : > > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon Glass > > > > > >> > > > > > > >wrote: > > > > > >> > > > > > > >> Hi, > > > > > >> > > > > > > >> > > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > > >> > > > > > > >> wrote: > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Hi, > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > This records my thoughts after a discussion with > > > > > >> > > > > > > >> > Ilias & Heinrich re > > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 1. malloc() > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > > >> > > > > > > >> > allocation. It allows memory > > > > > >> > > > > > > >> > to be freed. It is not designed for very large > > > > > >> > > > > > > >> > allocations (e.g. a > > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 2. lmb > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such as > > > > > >> > > > > > > >> > those needed for a > > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only transitory, > > > > > >> > > > > > > >> > for the purposes of > > > > > >> > > > > > > >> > loading some images and booting. If the boot > > > > > >> > > > > > > >> > fails, then all lmb > > > > > >> > > > > > > >> > allocations go away. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb is set up by getting all available memory and > > > > > >> > > > > > > >> > then removing what > > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() space, > > > > > >> > > > > > > >> > etc.) > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > lmb reservations have a few flags so that areas > > > > > >> > > > > > > >> > of memory can be > > > > > >> > > > > > > >> > provided with attributes > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a file > > > > > >> > > > > > > >> > does an lmb > > > > > >> > > > > > > >> > allocation but only for the purpose of avoiding a > > > > > >> > > > > > > >> > file being loaded > > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is dropped > > > > > >> > > > > > > >> > immediately after the > > > > > >> > > > > > > >> > file is loaded. Within the bootm command, or when > > > > > >> > > > > > > >> > using standard boot, > > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should > > > > > >> > > > > > > >> > consider doing the same. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > 3. EFI > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large > > > > > >> > > > > > > >> > allocations. But via a 'pool' > > > > > >> > > > > > > >> > function it can also do smaller allocations > > > > > >> > > > > > > >> > similar to malloc(), > > > > > >> > > > > > > >> > although each one uses at least 4KB at present. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > EFI allocations do not go away when a boot fails. > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > With EFI it is possible to add allocations post > > > > > >> > > > > > > >> > facto, in which case > > > > > >>
Re: [RFC PATCH 09/31] lmb: allow for resizing lmb regions
hi Ilias, On Mon, 10 Jun 2024 at 19:52, Ilias Apalodimas wrote: > > Hi Sughosh > > On Mon, 10 Jun 2024 at 15:57, Sughosh Ganu wrote: > > > > On Mon, 10 Jun 2024 at 18:17, Ilias Apalodimas > > wrote: > > > > > > On Mon, 10 Jun 2024 at 15:20, Sughosh Ganu > > > wrote: > > > > > > > > hi Ilias, > > > > > > > > On Mon, 10 Jun 2024 at 17:34, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Sughosh > > > > > > > > > > > > > > > On Fri, 7 Jun 2024 at 21:54, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > Allow for resizing of LMB regions if the region attributes match. > > > > > > The > > > > > > current code returns a failure status on detecting an overlapping > > > > > > address. This worked up until now since the LMB calls were not > > > > > > persistent and global -- the LMB memory map was specific and private > > > > > > to a given caller of the LMB API's. > > > > > > > > > > > > With the change in the LMB code to make the LMB reservations > > > > > > persistent, there needs to be a check on whether the memory region > > > > > > can > > > > > > be resized, and then do it if so. To distinguish between memory that > > > > > > cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a > > > > > > region > > > > > > of memory with this attribute would indicate that the region cannot > > > > > > be > > > > > > resized. > > > > > > > > > > Can you think of a memory region that needs to be protected from > > > > > resizing? > > > > > > > > Actually, I think I could use a better term instead of 'resize'. The > > > > aim of this patch is to allow re-allocation/re-reservation of the same > > > > region of memory -- this will only be relevant for the LMB > > > > reservations, as these are used for loading images into memory. All > > > > other allocations(EFI currently) are true allocations in that these > > > > should not get overwritten at all. Memory once allocated, say for > > > > loading an EFI image, cannot be re-requested. > > > > > > > > > > > > > I think we should design this a bit differently. For example, think > > > > > of someone loading a file in a memory region and then a subsystem > > > > > trying to resize its reserved memory overwriting that region. Instead > > > > > of this flag why don't we add > > > > > - A flag that indicates whether this region can be re-used (IOW > > > > > overwrites it), but only if the 'subsytem id' defined below matches > > > > > - a u32 that indicates the subsystem ID that initiated the transaction > > > > > -- e.g EFI, load command, U-Boot core .. etc > > > > > > > > > > Resizing can be enabled unconditionally in that case as long as there > > > > > is enough space. The only requirement would be that the request comes > > > > > from the same subsystem that reserved the memory in the beginning > > > > > > > > Like I mentioned above, resizing(or rather re-allocations) should only > > > > be allowed for the LMB subsystem. Any other module should not be > > > > returned an already allocated address. Which is why I mark any memory > > > > map update coming from the EFI module as no-overwrite. > > > > > > And what happens if someone tries to overwrite 'load' memory? Won't > > > you still corrupt whatever is loaded on that region as it's not marked > > > for protection? > > > > Yes, but that is the expected behavior in U-Boot for LMB memory. > > Consider the following flow, > > > > 1) load hostfs - $some_addr $some_image > > 2) fs.write $some_addr $some_destination $filesize > > 3) load hostfs - $some_addr $some_other_image > > 4) fs.write $some_addr $some_other_destination $filesize > > > > The above flow is very much valid, and this exercises the same region > > of LMB memory. Which is why we need to allow re-using the same memory > > address for LMB. This worked up until now since all LMB > > allocations/reservations were private. This is user visible behaviour, > > and used in many scripts used by platforms to read and write files. So > > even after making the LMB memory map global and persistent, this > > aspect of re-use of LMB memory must be maintained. > > I am not talking about this. I haven't gone through all the patches > yet, so I might be missing something but... > What if a user loads a file to boot and then an EFI subsystem decides > to allocate memory -- e.g the EventLog and that allocation routine > returns memory within the space you just loaded the binary from? Yes > memory should be overwritten to preserve the current behavior, but > only if you perform the same action/command In the scenario you describe above, what happens is that the file getting loaded to memory by a user is LMB memory. When this action happens, this gets notified to the EFI memory module, and the EFI memory map gets updated, and this region of memory gets marked as not EFI_CONVENTIONAL_MEMORY. So, when the EFI subsystem has to allocate memory, say for the EventLog, the efi_find_free_memory would not return that memory, as the EFI memory map has been
Re: [PATCH 4/6] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
On Thu, Jun 6, 2024 at 2:24 PM Mattijs Korpershoek
wrote:
>
> The only way to configure the load addresses for both bootimg and
> vendor_bootimg is by using the "abootimg" command.
> If we want to use the C API, there is no equivalent.
>
> Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
> specify the load address from C.
>
> This can be useful for implementing an Android bootmethod.
>
> Signed-off-by: Mattijs Korpershoek
> ---
> cmd/abootimg.c | 10 ++
> include/image.h | 14 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/cmd/abootimg.c b/cmd/abootimg.c
> index 88c77d999290..33381e22dec2 100644
> --- a/cmd/abootimg.c
> +++ b/cmd/abootimg.c
> @@ -21,11 +21,21 @@ ulong get_abootimg_addr(void)
> return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
> }
>
> +void set_abootimg_addr(ulong addr)
> +{
> + _abootimg_addr = addr;
> +}
> +
> ulong get_avendor_bootimg_addr(void)
> {
> return _avendor_bootimg_addr;
> }
>
> +void set_avendor_bootimg_addr(ulong addr)
> +{
> + _avendor_bootimg_addr = addr;
> +}
> +
> static int abootimg_get_ver(int argc, char *const argv[])
> {
> const struct andr_boot_img_hdr_v0 *hdr;
> diff --git a/include/image.h b/include/image.h
> index 18e5ced5ab42..6deaf406605e 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1977,6 +1977,13 @@ u32 android_image_get_version(const void *hdr);
> */
> ulong get_abootimg_addr(void);
>
> +/**
> + * set_abootimg_addr() - Set Android boot image address
> + *
> + * Return: no returned results
> + */
> +void set_abootimg_addr(ulong addr);
> +
> /**
> * get_avendor_bootimg_addr() - Get Android vendor boot image address
> *
> @@ -1984,6 +1991,13 @@ ulong get_abootimg_addr(void);
> */
> ulong get_avendor_bootimg_addr(void);
>
> +/**
> + * set_abootimg_addr() - Set Android vendor boot image address
> + *
> + * Return: no returned results
> + */
> +void set_avendor_bootimg_addr(ulong addr);
> +
> /**
> * board_fit_config_name_match() - Check for a matching board name
> *
>
> --
> 2.45.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
Re: [PATCH v2 12/40] mmc: dw_mmc: Replace fifoth_val property with fifo-depth
On 6/10/2024 9:11 AM, Sam Protsenko wrote:
Replace fifoth_val property with its fifo-depth counterpart in all DW
MMC drivers. fifo-depth is a common property used in upstream Linux
kernel. The FIFOTH register value will be calculated using fifo-depth
value in DW MMC core (dw_mmc.c). This change reduces code duplication in
platform drivers, and pulls common FIFOTH register value calculation
into core dw_mmc driver where it belongs.
No functional change.
Signed-off-by: Sam Protsenko
---
drivers/mmc/dw_mmc.c | 21 +
drivers/mmc/exynos_dw_mmc.c | 10 +-
drivers/mmc/ftsdc010_mci.h| 1 -
drivers/mmc/hi6220_dw_mmc.c | 7 +++
drivers/mmc/nexell_dw_mmc.c | 5 +
drivers/mmc/rockchip_dw_mmc.c | 5 +
drivers/mmc/snps_dw_mmc.c | 6 ++
drivers/mmc/socfpga_dw_mmc.c | 4 ++--
include/dwmmc.h | 4 ++--
9 files changed, 29 insertions(+), 34 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 7aa3dbbe83ad..8af665a00222 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -218,8 +218,6 @@ static unsigned int dwmci_get_timeout(struct mmc *mmc,
const unsigned int size)
static int dwmci_data_transfer_fifo(struct dwmci_host *host,
struct mmc_data *data, u32 mask)
{
- const u32 fifo_depth = (((host->fifoth_val & RX_WMARK_MASK) >>
-RX_WMARK_SHIFT) + 1) * 2;
const u32 int_rx = mask & (DWMCI_INTMSK_RXDR | DWMCI_INTMSK_DTO);
const u32 int_tx = mask & DWMCI_INTMSK_TXDR;
int ret = 0;
@@ -254,8 +252,8 @@ static int dwmci_data_transfer_fifo(struct dwmci_host *host,
if (ret < 0)
break;
- len = fifo_depth - ((len >> DWMCI_FIFO_SHIFT) &
- DWMCI_FIFO_MASK);
+ len = host->fifo_depth - ((len >> DWMCI_FIFO_SHIFT) &
+ DWMCI_FIFO_MASK);
len = min(size, len);
for (i = 0; i < len; i++)
dwmci_writel(host, DWMCI_DATA, *buf++);
@@ -656,16 +654,23 @@ static int dwmci_set_ios(struct mmc *mmc)
static void dwmci_init_fifo(struct dwmci_host *host)
{
- if (!host->fifoth_val) {
+ u32 fifo_thr, fifoth_val;
+
+ if (!host->fifo_depth) {
u32 fifo_size;
+ /*
+* Automatically detect FIFO depth from FIFOTH register.
+* Power-on value of RX_WMark is FIFO_DEPTH-1.
+*/
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
fifo_size = ((fifo_size & RX_WMARK_MASK) >> RX_WMARK_SHIFT) + 1;
- host->fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
- TX_WMARK(fifo_size / 2);
+ host->fifo_depth = fifo_size;
}
- dwmci_writel(host, DWMCI_FIFOTH, host->fifoth_val);
+ fifo_thr = host->fifo_depth / 2;
+ fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_thr - 1) | TX_WMARK(fifo_thr);
+ dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
}
static void dwmci_init_dma(struct dwmci_host *host)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 2f849c43b129..14cb0c05cb55 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -151,8 +151,8 @@ static int do_dwmci_init(struct dwmci_host *host)
return exynos_dwmci_core_init(host);
}
-static int exynos_dwmci_get_config(const void *blob, int node,
- struct dwmci_host *host,
+static int exynos_dwmci_get_config(struct udevice *dev, const void *blob,
+ int node, struct dwmci_host *host,
struct dwmci_exynos_priv_data *priv)
{
int err = 0;
@@ -201,7 +201,7 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
priv->sdr_timing = DWMMC_MMC2_SDR_TIMING_VAL;
}
- host->fifoth_val = fdtdec_get_int(blob, node, "fifoth_val", 0);
+ host->fifo_depth = dev_read_u32_default(dev, "fifo-depth", 0);
host->bus_hz = fdtdec_get_int(blob, node, "bus_hz", 0);
host->div = fdtdec_get_int(blob, node, "div", 0);
@@ -217,8 +217,8 @@ static int exynos_dwmmc_probe(struct udevice *dev)
struct dwmci_host *host = >host;
int err;
- err = exynos_dwmci_get_config(gd->fdt_blob, dev_of_offset(dev), host,
- priv);
+ err = exynos_dwmci_get_config(dev, gd->fdt_blob, dev_of_offset(dev),
+ host, priv);
if (err)
return err;
err = do_dwmci_init(host);
diff --git a/drivers/mmc/ftsdc010_mci.h b/drivers/mmc/ftsdc010_mci.h
index 782d92be2f5f..36187cfa04f6 100644
--- a/drivers/mmc/ftsdc010_mci.h
+++ b/drivers/mmc/ftsdc010_mci.h
Re: [RFC PATCH 09/31] lmb: allow for resizing lmb regions
Hi Sughosh
On Mon, 10 Jun 2024 at 15:57, Sughosh Ganu wrote:
>
> On Mon, 10 Jun 2024 at 18:17, Ilias Apalodimas
> wrote:
> >
> > On Mon, 10 Jun 2024 at 15:20, Sughosh Ganu wrote:
> > >
> > > hi Ilias,
> > >
> > > On Mon, 10 Jun 2024 at 17:34, Ilias Apalodimas
> > > wrote:
> > > >
> > > > Hi Sughosh
> > > >
> > > >
> > > > On Fri, 7 Jun 2024 at 21:54, Sughosh Ganu
> > > > wrote:
> > > > >
> > > > > Allow for resizing of LMB regions if the region attributes match. The
> > > > > current code returns a failure status on detecting an overlapping
> > > > > address. This worked up until now since the LMB calls were not
> > > > > persistent and global -- the LMB memory map was specific and private
> > > > > to a given caller of the LMB API's.
> > > > >
> > > > > With the change in the LMB code to make the LMB reservations
> > > > > persistent, there needs to be a check on whether the memory region can
> > > > > be resized, and then do it if so. To distinguish between memory that
> > > > > cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a region
> > > > > of memory with this attribute would indicate that the region cannot be
> > > > > resized.
> > > >
> > > > Can you think of a memory region that needs to be protected from
> > > > resizing?
> > >
> > > Actually, I think I could use a better term instead of 'resize'. The
> > > aim of this patch is to allow re-allocation/re-reservation of the same
> > > region of memory -- this will only be relevant for the LMB
> > > reservations, as these are used for loading images into memory. All
> > > other allocations(EFI currently) are true allocations in that these
> > > should not get overwritten at all. Memory once allocated, say for
> > > loading an EFI image, cannot be re-requested.
> > >
> > >
> > > > I think we should design this a bit differently. For example, think
> > > > of someone loading a file in a memory region and then a subsystem
> > > > trying to resize its reserved memory overwriting that region. Instead
> > > > of this flag why don't we add
> > > > - A flag that indicates whether this region can be re-used (IOW
> > > > overwrites it), but only if the 'subsytem id' defined below matches
> > > > - a u32 that indicates the subsystem ID that initiated the transaction
> > > > -- e.g EFI, load command, U-Boot core .. etc
> > > >
> > > > Resizing can be enabled unconditionally in that case as long as there
> > > > is enough space. The only requirement would be that the request comes
> > > > from the same subsystem that reserved the memory in the beginning
> > >
> > > Like I mentioned above, resizing(or rather re-allocations) should only
> > > be allowed for the LMB subsystem. Any other module should not be
> > > returned an already allocated address. Which is why I mark any memory
> > > map update coming from the EFI module as no-overwrite.
> >
> > And what happens if someone tries to overwrite 'load' memory? Won't
> > you still corrupt whatever is loaded on that region as it's not marked
> > for protection?
>
> Yes, but that is the expected behavior in U-Boot for LMB memory.
> Consider the following flow,
>
> 1) load hostfs - $some_addr $some_image
> 2) fs.write $some_addr $some_destination $filesize
> 3) load hostfs - $some_addr $some_other_image
> 4) fs.write $some_addr $some_other_destination $filesize
>
> The above flow is very much valid, and this exercises the same region
> of LMB memory. Which is why we need to allow re-using the same memory
> address for LMB. This worked up until now since all LMB
> allocations/reservations were private. This is user visible behaviour,
> and used in many scripts used by platforms to read and write files. So
> even after making the LMB memory map global and persistent, this
> aspect of re-use of LMB memory must be maintained.
I am not talking about this. I haven't gone through all the patches
yet, so I might be missing something but...
What if a user loads a file to boot and then an EFI subsystem decides
to allocate memory -- e.g the EventLog and that allocation routine
returns memory within the space you just loaded the binary from? Yes
memory should be overwritten to preserve the current behavior, but
only if you perform the same action/command
Thanks
/Ilias
>
> -sughosh
>
> >
> > /Ilias
> > >
> > > -sughosh
> > > >
> > > > Thanks
> > > > /Ilias
> > > >
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > include/lmb.h | 1 +
> > > > > lib/lmb.c | 120
> > > > > --
> > > > > 2 files changed, 107 insertions(+), 14 deletions(-)
> > > > >
> > > > > diff --git a/include/lmb.h b/include/lmb.h
> > > > > index 03bce2a50c..1d4cd255d2 100644
> > > > > --- a/include/lmb.h
> > > > > +++ b/include/lmb.h
> > > > > @@ -20,6 +20,7 @@
> > > > > enum lmb_flags {
> > > > > LMB_NONE= 0x0,
> > > > > LMB_NOMAP = 0x4,
> > > > > + LMB_NOOVERWRITE = 0x8,
> > > > > };
> > > > >
> > >
Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map
Hi Sughosh
On Mon, 10 Jun 2024 at 15:25, Sughosh Ganu wrote:
>
> On Mon, 10 Jun 2024 at 17:40, Ilias Apalodimas
> wrote:
> >
> > On Fri, 7 Jun 2024 at 21:54, Sughosh Ganu wrote:
> > >
> > > There are events that would be used to notify other interested modules
> > > of any changes in available and occupied memory. This would happen
> > > when a module allocates or reserves memory, or frees up memory. These
> > > changes in memory map should be notified to other interested modules
> > > so that the allocated memory does not get overwritten. Add an event
> > > handler in the EFI memory module to update the EFI memory map
> > > accordingly when such changes happen. As a consequence, any subsequent
> > > memory request would honour the updated memory map and only available
> > > memory would be allocated from.
> >
> > So the question here, is why do we need a notifier chain overall?
> > Can't we change the EFI subsystem and allocate memory with lmb now?
> > And any special functions we have in EFI (e.g allocate aligned memory)
> > can migrate to lmb()
>
> Like we discussed offline, that was my initial attempt -- to use the
> LMB allocation API's from inside the EFI allocate pages module. But I
> was facing a lot of corner case issues, primarily in keeping the two
> memory maps the same.
I think it would worth discussing this a bit more. I like the idea of
having a single allocator more than having events to update memory
reservations
> Which is why I moved to the current
> implementation of notifying other modules, and that too only for the
> addresses in the RAM region.
The notification to 'other modules' i still done by updating the
static memory map though no?
So what corner cases we couldn't solve by having a single allocator?
Thanks
/Ilias
>
> -sughosh
>
> >
> > Cheers
> > /Ilias
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > lib/efi_loader/efi_memory.c | 70 ++---
> > > 1 file changed, 58 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > > index 435e580fb3..93244161b0 100644
> > > --- a/lib/efi_loader/efi_memory.c
> > > +++ b/lib/efi_loader/efi_memory.c
> > > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> > > #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> > > extern bool is_addr_in_ram(uintptr_t addr);
> > >
> > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
> > > + int memory_type,
> > > + bool overlap_only_ram);
> > > +
> > > static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> > > {
> > > struct event_efi_mem_map_update efi_map = {0};
> > > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, u64 size,
> > > u8 op)
> > > if (is_addr_in_ram((uintptr_t)addr))
> > > event_notify(EVT_EFI_MEM_MAP_UPDATE, _map,
> > > sizeof(efi_map));
> > > }
> > > +
> > > +static int lmb_mem_map_update_sync(void *ctx, struct event *event)
> > > +{
> > > + u8 op;
> > > + u64 addr;
> > > + u64 pages;
> > > + efi_status_t status;
> > > + struct event_lmb_map_update *lmb_map = >data.lmb_map;
> > > +
> > > + addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > > + pages = efi_size_in_pages(lmb_map->size + (addr & EFI_PAGE_MASK));
> > > + op = lmb_map->op;
> > > + addr &= ~EFI_PAGE_MASK;
> > > +
> > > + if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > > + log_debug("Invalid map update op received (%d)\n", op);
> > > + return -1;
> > > + }
> > > +
> > > + status = __efi_add_memory_map_pg(addr, pages,
> > > +op == MAP_OP_FREE ?
> > > +EFI_CONVENTIONAL_MEMORY :
> > > +EFI_BOOT_SERVICES_DATA,
> > > +true);
> > > +
> > > + return status == EFI_SUCCESS ? 0 : -1;
> > > +}
> > > +EVENT_SPY_FULL(EVT_LMB_MAP_UPDATE, lmb_mem_map_update_sync);
> > > #endif /* MEM_MAP_UPDATE_NOTIFY */
> > >
> > > /**
> > > @@ -275,18 +307,9 @@ static s64 efi_mem_carve_out(struct efi_mem_list
> > > *map,
> > > return EFI_CARVE_LOOP_AGAIN;
> > > }
> > >
> > > -/**
> > > - * efi_add_memory_map_pg() - add pages to the memory map
> > > - *
> > > - * @start: start address, must be a multiple of EFI_PAGE_SIZE
> > > - * @pages: number of pages to add
> > > - * @memory_type: type of memory added
> > > - * @overlap_only_ram: region may only overlap RAM
> > > - * Return: status code
> > > - */
> > > -static efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
> > > - int memory_type,
> > > - bool overlap_only_ram)
> > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 pages,
Re: [PATCH v6 02/14] firmware: scmi: use a protocol's own channel if assigned
Hi,
On 10/11/23 12:06 PM, AKASHI Takahiro wrote:
SCMI specification allows any protocol to have its own channel for
the transport. While the current SCMI driver may assign its channel
from a device tree, the core function, devm_scmi_process_msg(), doesn't
use a protocol's channel, but always use an agent's channel.
With this commit, devm_scmi_process_msg() tries to find and use
a protocol's channel. If it doesn't exist, use an agent's.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Etienne Carriere
---
v5
* new commit (fixing a potential bug)
---
drivers/firmware/scmi/mailbox_agent.c | 5 +++--
drivers/firmware/scmi/optee_agent.c | 5 +++--
drivers/firmware/scmi/scmi_agent-uclass.c | 7 ---
drivers/firmware/scmi/smccc_agent.c | 5 +++--
include/scmi_agent-uclass.h | 8 +---
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/scmi/mailbox_agent.c
b/drivers/firmware/scmi/mailbox_agent.c
index 8277c1860606..7ad3e8da9f08 100644
--- a/drivers/firmware/scmi/mailbox_agent.c
+++ b/drivers/firmware/scmi/mailbox_agent.c
@@ -94,13 +94,14 @@ static int setup_channel(struct udevice *dev, struct
scmi_mbox_channel *chan)
}
static int scmi_mbox_get_channel(struct udevice *dev,
+struct udevice *protocol,
struct scmi_channel **channel)
{
struct scmi_mbox_channel *base_chan = dev_get_plat(dev);
struct scmi_mbox_channel *chan;
int ret;
- if (!dev_read_prop(dev, "shmem", NULL)) {
+ if (!dev_read_prop(protocol, "shmem", NULL)) {
/* Uses agent base channel */
*channel = container_of(base_chan, struct scmi_channel, ref);
@@ -112,7 +113,7 @@ static int scmi_mbox_get_channel(struct udevice *dev,
return -ENOMEM;
/* Setup a dedicated channel for the protocol */
- ret = setup_channel(dev, chan);
+ ret = setup_channel(protocol, chan);
if (ret) {
free(chan);
return ret;
diff --git a/drivers/firmware/scmi/optee_agent.c
b/drivers/firmware/scmi/optee_agent.c
index db927fb21405..e3e462774045 100644
--- a/drivers/firmware/scmi/optee_agent.c
+++ b/drivers/firmware/scmi/optee_agent.c
@@ -324,6 +324,7 @@ static int setup_channel(struct udevice *dev, struct
scmi_optee_channel *chan)
}
static int scmi_optee_get_channel(struct udevice *dev,
+ struct udevice *protocol,
struct scmi_channel **channel)
{
struct scmi_optee_channel *base_chan = dev_get_plat(dev);
@@ -331,7 +332,7 @@ static int scmi_optee_get_channel(struct udevice *dev,
u32 channel_id;
int ret;
- if (dev_read_u32(dev, "linaro,optee-channel-id", _id)) {
+ if (dev_read_u32(protocol, "linaro,optee-channel-id", _id)) {
/* Uses agent base channel */
*channel = container_of(base_chan, struct scmi_channel, ref);
@@ -343,7 +344,7 @@ static int scmi_optee_get_channel(struct udevice *dev,
if (!chan)
return -ENOMEM;
- ret = setup_channel(dev, chan);
+ ret = setup_channel(protocol, chan);
if (ret) {
free(chan);
return ret;
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index ec58ccd2bc5d..a28692f39f4d 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -144,13 +144,14 @@ static const struct scmi_agent_ops
*transport_dev_ops(struct udevice *dev)
* On return, @channel will be set.
* Return 0 on success and a negative errno on failure
*/
-static int scmi_of_get_channel(struct udevice *dev, struct scmi_channel
**channel)
+static int scmi_of_get_channel(struct udevice *dev, struct udevice *protocol,
+ struct scmi_channel **channel)
{
const struct scmi_agent_ops *ops;
ops = transport_dev_ops(dev);
if (ops->of_get_channel)
- return ops->of_get_channel(dev, channel);
+ return ops->of_get_channel(dev, protocol, channel);
else
return -EPROTONOSUPPORT;
}
@@ -166,7 +167,7 @@ int devm_scmi_of_get_channel(struct udevice *dev)
return -ENODEV;
priv = dev_get_parent_priv(protocol);
- ret = scmi_of_get_channel(protocol->parent, >channel);
+ ret = scmi_of_get_channel(protocol->parent, protocol, >channel);
if (ret == -EPROTONOSUPPORT) {
/* Drivers without a get_channel operator don't need a channel
ref */
priv->channel = NULL;
diff --git a/drivers/firmware/scmi/smccc_agent.c
b/drivers/firmware/scmi/smccc_agent.c
index 6a52cd75d67b..972c6addde21 100644
--- a/drivers/firmware/scmi/smccc_agent.c
+++ b/drivers/firmware/scmi/smccc_agent.c
@@ -81,6 +81,7 @@ static int setup_channel(struct udevice *dev, struct
Re: [PATCH v3 0/9] efi_loader: improve device-tree loading
On 10.06.24 15:53, Simon Glass wrote: Hi Heinrich, On Mon, 10 Jun 2024 at 03:11, Heinrich Schuchardt wrote: In U-Boot EFI boot options can already specify both an EFI binary and an initrd. With this series we can additionally define the matching device-tree to be loaded in the boot option. With the last patch the boot manager will fall back the device-tree specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' on the boot device if no device-tree is specified in the boot option or via a bootefi command parameter. v3: Add missing '@' in EFI_LP_DP_PART_FDT description. Use calloc() instead of malloc() in load_fdt_from_load_option(). Add missing '@' in load_fdt_from_load_option function description Rename struct efi_initrd_dp to efi_lo_dp_prefix. v2: Update efi_dp_concat() instead of new function efi_dp_merge(). Carve out a function efi_load_option_dp_join() which we can use both for the eficonfig and the efidebug command. Rename variables id_dp, final_dp_size. Rename create_initrd_dp() to create_lo_dp_part(). Use enum as parameter for create_lo_dp_part(). Put all related changes into one patch. Heinrich Schuchardt (8): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr boot/bootmeth_efi.c| 60 +- cmd/eficonfig.c| 83 + cmd/efidebug.c | 130 +++-- include/efi_loader.h | 24 +++- lib/efi_loader/Makefile| 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 75 +++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 --- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 +++ lib/efi_loader/efi_helper.c| 44 +++ 12 files changed, 445 insertions(+), 136 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c Somewhat related, what work has been done to support FIT, or to locate a DT using the compatible string? CONFIG_BOOTM_EFI allows booting a FIT image containing an EFI binary and optionally a device-tree. You can manually select a configuration when invoking the bootm command. I am not aware of any automation for this selection. Best regards Heinrich
Re: Proposal: U-Boot memory management
Hi Sughosh, On Thu, 6 Jun 2024 at 13:18, Sughosh Ganu wrote: > > hi Simon, > > On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > > > +Sughosh Ganu for reference > > > > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini : > > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > > >> Hi Tom, > > > > >> > > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini wrote: > > > > >> > > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > > >> > > Hi, > > > > >> > > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > > >> > > wrote: > > > > >> > > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis wrote: > > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > > >> > > > > > From: Tom Rini > > > > >> > > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > > >> > > > > > Schuchardt wrote: > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > > >> > > > > > > : > > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon Glass > > > > >> > > > > > > >wrote: > > > > >> > > > > > > >> Hi, > > > > >> > > > > > > >> > > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > > >> > > > > > > >> wrote: > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > Hi, > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > This records my thoughts after a discussion with > > > > >> > > > > > > >> > Ilias & Heinrich re > > > > >> > > > > > > >> > memory allocation in U-Boot. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > 1. malloc() > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > malloc() is used for programmatic memory > > > > >> > > > > > > >> > allocation. It allows memory > > > > >> > > > > > > >> > to be freed. It is not designed for very large > > > > >> > > > > > > >> > allocations (e.g. a > > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > 2. lmb > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such as > > > > >> > > > > > > >> > those needed for a > > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only transitory, > > > > >> > > > > > > >> > for the purposes of > > > > >> > > > > > > >> > loading some images and booting. If the boot fails, > > > > >> > > > > > > >> > then all lmb > > > > >> > > > > > > >> > allocations go away. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > lmb is set up by getting all available memory and > > > > >> > > > > > > >> > then removing what > > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() space, etc.) > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > lmb reservations have a few flags so that areas of > > > > >> > > > > > > >> > memory can be > > > > >> > > > > > > >> > provided with attributes > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a file > > > > >> > > > > > > >> > does an lmb > > > > >> > > > > > > >> > allocation but only for the purpose of avoiding a > > > > >> > > > > > > >> > file being loaded > > > > >> > > > > > > >> > over U-Boot code/data. The allocation is dropped > > > > >> > > > > > > >> > immediately after the > > > > >> > > > > > > >> > file is loaded. Within the bootm command, or when > > > > >> > > > > > > >> > using standard boot, > > > > >> > > > > > > >> > this would be fairly easy to solve. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should > > > > >> > > > > > > >> > consider doing the same. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > 3. EFI > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large > > > > >> > > > > > > >> > allocations. But via a 'pool' > > > > >> > > > > > > >> > function it can also do smaller allocations similar > > > > >> > > > > > > >> > to malloc(), > > > > >> > > > > > > >> > although each one uses at least 4KB at present. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > EFI allocations do not go away when a boot fails. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > With EFI it is possible to add allocations post > > > > >> > > > > > > >> > facto, in which case > > > > >> > > > > > > >> > they are added to the allocation table just as if > > > > >> > > > > > > >> > the memory was > > > > >> > > > > > > >> > allocated with EFI to begin with. > > > > >> > > > > > > >> > > > > > >> > > > > > > >> > The EFI allocations and the lmb allocations use the > > > > >> > > > > > > >> > same memory, so in > > > > >> > > > >
Re: [PATCH v3 0/9] efi_loader: improve device-tree loading
Hi Heinrich, On Mon, 10 Jun 2024 at 03:11, Heinrich Schuchardt wrote: > > In U-Boot EFI boot options can already specify both an EFI binary and > an initrd. With this series we can additionally define the matching > device-tree to be loaded in the boot option. > > With the last patch the boot manager will fall back the device-tree > specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' > on the boot device if no device-tree is specified in the boot > option or via a bootefi command parameter. > > v3: > Add missing '@' in EFI_LP_DP_PART_FDT description. > Use calloc() instead of malloc() in load_fdt_from_load_option(). > Add missing '@' in load_fdt_from_load_option function description > Rename struct efi_initrd_dp to efi_lo_dp_prefix. > > v2: > Update efi_dp_concat() instead of new function efi_dp_merge(). > Carve out a function efi_load_option_dp_join() which we can > use both for the eficonfig and the efidebug command. > Rename variables id_dp, final_dp_size. > Rename create_initrd_dp() to create_lo_dp_part(). > Use enum as parameter for create_lo_dp_part(). > Put all related changes into one patch. > > Heinrich Schuchardt (8): > efi_loader: allow concatenation with contained end node > cmd: eficonfig: add support for setting fdt > cmd: efidebug: add support for setting fdt > efi_loader: load device-tree specified in boot option > efi_loader: move distro_efi_get_fdt_name() > efi_loader: return binary from efi_dp_from_lo() > efi_loader: export efi_load_image_from_path > efi_loader: load distro dtb in bootmgr > > boot/bootmeth_efi.c| 60 +- > cmd/eficonfig.c| 83 + > cmd/efidebug.c | 130 +++-- > include/efi_loader.h | 24 +++- > lib/efi_loader/Makefile| 1 + > lib/efi_loader/efi_bootbin.c | 2 +- > lib/efi_loader/efi_bootmgr.c | 75 +++- > lib/efi_loader/efi_boottime.c | 3 +- > lib/efi_loader/efi_device_path.c | 40 --- > lib/efi_loader/efi_device_path_utilities.c | 2 +- > lib/efi_loader/efi_fdt.c | 117 +++ > lib/efi_loader/efi_helper.c| 44 +++ > 12 files changed, 445 insertions(+), 136 deletions(-) > create mode 100644 lib/efi_loader/efi_fdt.c > Somewhat related, what work has been done to support FIT, or to locate a DT using the compatible string? Regards, Simon
[PATCH 13/13] board: phytec: phycore-am62x: Use memory nodes in higher boot stages
There is no need to reread the EEPROM multiple times in different stages
to detect the RAM size. We can do this once at an early stage and let
higher stages decode memory nodes using fdtdec.
Make sure to pass fixup memory nodes before passing to u-boot stage.
Signed-off-by: Wadim Egorov
---
board/phytec/phycore_am62x/phycore-am62x.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/board/phytec/phycore_am62x/phycore-am62x.c
b/board/phytec/phycore_am62x/phycore-am62x.c
index 35e1bb96b8d..9f6bc736cbb 100644
--- a/board/phytec/phycore_am62x/phycore-am62x.c
+++ b/board/phytec/phycore_am62x/phycore-am62x.c
@@ -47,7 +47,12 @@ static u8 phytec_get_am62_ddr_size_default(void)
int dram_init(void)
{
- u8 ram_size = phytec_get_am62_ddr_size_default();
+ u8 ram_size;
+
+ if (!IS_ENABLED(CONFIG_CPU_V7R))
+ return fdtdec_setup_mem_size_base();
+
+ ram_size = phytec_get_am62_ddr_size_default();
/*
* HACK: ddrss driver support 2GB RAM by default
@@ -92,6 +97,9 @@ int dram_init_banksize(void)
{
u8 ram_size;
+ if (!IS_ENABLED(CONFIG_CPU_V7R))
+ return fdtdec_setup_memory_banksize();
+
ram_size = phytec_get_am62_ddr_size_default();
switch (ram_size) {
case EEPROM_RAM_SIZE_1GB:
@@ -174,6 +182,26 @@ int do_board_detect(void)
}
#endif
+#if IS_ENABLED(CONFIG_SPL_BUILD)
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+ u64 start[CONFIG_NR_DRAM_BANKS];
+ u64 size[CONFIG_NR_DRAM_BANKS];
+ int bank;
+ int ret;
+
+ dram_init();
+ dram_init_banksize();
+
+ for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+ start[bank] = gd->bd->bi_dram[bank].start;
+ size[bank] = gd->bd->bi_dram[bank].size;
+ }
+
+ ret = fdt_fixup_memory_banks(spl_image->fdt_addr, start, size,
CONFIG_NR_DRAM_BANKS);
+}
+#endif
+
#define CTRLMMR_USB0_PHY_CTRL 0x43004008
#define CTRLMMR_USB1_PHY_CTRL 0x43004018
#define CORE_VOLTAGE0x8000
--
2.34.1
[PATCH 12/13] doc: board: phytec: phycore-am6: Use mtd commands
Update Flash to SPI NOR chapter for use with mtd commands.
This is more convenient as we do not have to remember any
offsets in the SPI.
Signed-off-by: Wadim Egorov
---
doc/board/phytec/phycore-am62x.rst | 8
doc/board/phytec/phycore-am64x.rst | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/board/phytec/phycore-am62x.rst
b/doc/board/phytec/phycore-am62x.rst
index f8870657be0..a615d01474e 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -110,13 +110,13 @@ tiboot3.bin, tispl.bin and u-boot.img are stored on the
uSD card.
.. code-block:: bash
- sf probe
+ mtd list
fatload mmc 1 ${loadaddr} tiboot3.bin
- sf update $loadaddr 0x0 $filesize
+ mtd write ospi.tiboot3 ${loadaddr} 0 ${filesize}
fatload mmc 1 ${loadaddr} tispl.bin
- sf update $loadaddr 0x8 $filesize
+ mtd write ospi.tispl ${loadaddr} 0 ${filesize}
fatload mmc 1 ${loadaddr} u-boot.img
- sf update $loadaddr 0x28 $filesize
+ mtd write ospi.u-boot ${loadaddr} 0 ${filesize}
Boot Modes
diff --git a/doc/board/phytec/phycore-am64x.rst
b/doc/board/phytec/phycore-am64x.rst
index a27ad01027b..189da179534 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -111,13 +111,13 @@ tiboot3.bin, tispl.bin and u-boot.img are stored on the
uSD card.
.. code-block:: bash
- sf probe
+ mtd list
fatload mmc 1 ${loadaddr} tiboot3.bin
- sf update $loadaddr 0x0 $filesize
+ mtd write ospi.tiboot3 ${loadaddr} 0 ${filesize}
fatload mmc 1 ${loadaddr} tispl.bin
- sf update $loadaddr 0x8 $filesize
+ mtd write ospi.tispl ${loadaddr} 0 ${filesize}
fatload mmc 1 ${loadaddr} u-boot.img
- sf update $loadaddr 0x28 $filesize
+ mtd write ospi.u-boot ${loadaddr} 0 ${filesize}
Boot Modes
--
2.34.1
[PATCH 11/13] doc: board: phytec: phycore-am62x: Add USB DFU switch config
Provide boot switch config for USB DFU boot. Signed-off-by: Wadim Egorov --- doc/board/phytec/phycore-am62x.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst index bc6d5246694..f8870657be0 100644 --- a/doc/board/phytec/phycore-am62x.rst +++ b/doc/board/phytec/phycore-am62x.rst @@ -151,6 +151,10 @@ Boot switches should be changed with power off. - 11011100 - + * - USB DFU + - 11001010 + - 0010 + Further Information --- -- 2.34.1
[PATCH 10/13] configs: phycore_am6xx: Update MTD & SPI configs
Enable mtd command and remove SPI NOR flashes we do not populate on our SoMs. Signed-off-by: Wadim Egorov --- configs/phycore_am62x_a53_defconfig | 4 ++-- configs/phycore_am62x_r5_defconfig | 1 - configs/phycore_am64x_a53_defconfig | 4 ++-- configs/phycore_am64x_r5_defconfig | 1 - 4 files changed, 4 insertions(+), 6 deletions(-) diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index 5fe2c9d4422..95a48aa246b 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -63,6 +63,7 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_DFU=y CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y CONFIG_CMD_USB=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y @@ -106,10 +107,9 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y # CONFIG_SPI_FLASH_SMART_HWCAPS is not set CONFIG_SPI_FLASH_SOFT_RESET=y CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y -CONFIG_SPI_FLASH_SPANSION=y -CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MT35XU=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_TI_DP83867=y CONFIG_PHY_FIXED=y CONFIG_TI_AM65_CPSW_NUSS=y diff --git a/configs/phycore_am62x_r5_defconfig b/configs/phycore_am62x_r5_defconfig index 0062a4e3569..12ba4c06d1e 100644 --- a/configs/phycore_am62x_r5_defconfig +++ b/configs/phycore_am62x_r5_defconfig @@ -106,7 +106,6 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y # CONFIG_SPI_FLASH_SMART_HWCAPS is not set CONFIG_SPI_FLASH_SOFT_RESET=y CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MT35XU=y CONFIG_PINCTRL=y diff --git a/configs/phycore_am64x_a53_defconfig b/configs/phycore_am64x_a53_defconfig index e94d829fd8f..cf04e145372 100644 --- a/configs/phycore_am64x_a53_defconfig +++ b/configs/phycore_am64x_a53_defconfig @@ -69,6 +69,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y CONFIG_CMD_USB=y CONFIG_CMD_TIME=y CONFIG_OF_CONTROL=y @@ -120,10 +121,9 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y # CONFIG_SPI_FLASH_SMART_HWCAPS is not set CONFIG_SPI_FLASH_SOFT_RESET=y CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y -CONFIG_SPI_FLASH_SPANSION=y -CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MT35XU=y +CONFIG_SPI_FLASH_MTD=y CONFIG_MULTIPLEXER=y CONFIG_MUX_MMIO=y CONFIG_PHY_TI_DP83867=y diff --git a/configs/phycore_am64x_r5_defconfig b/configs/phycore_am64x_r5_defconfig index 15a7e7089e7..a0d78241928 100644 --- a/configs/phycore_am64x_r5_defconfig +++ b/configs/phycore_am64x_r5_defconfig @@ -121,7 +121,6 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y # CONFIG_SPI_FLASH_SMART_HWCAPS is not set CONFIG_SPI_FLASH_SOFT_RESET=y CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y -CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_MT35XU=y CONFIG_PHY_TI_DP83867=y -- 2.34.1
[PATCH 09/13] board: phytec: phycore-am62x: Pull in k3_dfu.env
Pull in ti/k3_dfu.env for dfu_alt_info_ram in SPL stage. Signed-off-by: Wadim Egorov --- board/phytec/phycore_am62x/phycore_am62x.env | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/phytec/phycore_am62x/phycore_am62x.env b/board/phytec/phycore_am62x/phycore_am62x.env index ada3a9233be..42db26a5990 100644 --- a/board/phytec/phycore_am62x/phycore_am62x.env +++ b/board/phytec/phycore_am62x/phycore_am62x.env @@ -1,3 +1,5 @@ +#include + fdtaddr=0x8800 loadaddr=0x8200 scriptaddr=0x8000 -- 2.34.1
[PATCH 08/13] configs: phycore_am62x_a53_defconfig: Enable DFU boot
Enable configs required for booting via DFU. Configs taken from the am62x_a53_usbdfu.config config fragment. Signed-off-by: Wadim Egorov --- configs/phycore_am62x_a53_defconfig | 28 1 file changed, 28 insertions(+) diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index 7476bb4a175..5fe2c9d4422 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y @@ -53,18 +54,23 @@ CONFIG_SPL_I2C=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_POWER_DOMAIN=y +CONFIG_SPL_RAM_SUPPORT=y +CONFIG_SPL_RAM_DEVICE=y # CONFIG_SPL_SPI_FLASH_TINY is not set CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 CONFIG_SPL_YMODEM_SUPPORT=y +CONFIG_CMD_DFU=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_MMC_ENV_DEV=1 @@ -73,10 +79,15 @@ CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y +CONFIG_SPL_SYSCON=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_DFU_MMC=y +CONFIG_DFU_RAM=y +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -121,4 +132,21 @@ CONFIG_CADENCE_QSPI=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y +CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_SPL_DM_USB_GADGET=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_SPL_USB_DWC3_GENERIC=y +CONFIG_SPL_USB_DWC3_AM62=y +CONFIG_USB_DWC3_AM62=y +CONFIG_USB_GADGET=y +CONFIG_SPL_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="Phytec" +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_SPL_DFU=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -- 2.34.1
[PATCH 07/13] arm: dts: k3-am625-phyboard-lyra-rdk: Enable usb port in u-boot
Enable usb0 in all boot phases for use with DFU.
Signed-off-by: Wadim Egorov
---
arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
index 7c76acc0d59..2bc5acbec23 100644
--- a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
@@ -168,6 +168,15 @@
bootph-all;
};
+ {
+ bootph-all;
+};
+
+ {
+ dr_mode = "peripheral";
+ bootph-all;
+};
+
_3v3_mmc {
bootph-all;
};
--
2.34.1
[PATCH 04/13] board: phytec: phycore-am62x: Fix CONFIG_SPL_BOARD_INIT
Make sure spl_board_init() gets compiled by enabling missing
CONFIG_SPL_BOARD_INIT and including hardware.h.
Fixes: 085cd6459dae ("board: phytec: am62x: Add PHYTEC phyCORE-AM62x SoM")
Signed-off-by: Wadim Egorov
---
board/phytec/phycore_am62x/phycore-am62x.c | 1 +
configs/phycore_am62x_a53_defconfig| 1 +
2 files changed, 2 insertions(+)
diff --git a/board/phytec/phycore_am62x/phycore-am62x.c
b/board/phytec/phycore_am62x/phycore-am62x.c
index 4a76f1343d7..35e1bb96b8d 100644
--- a/board/phytec/phycore_am62x/phycore-am62x.c
+++ b/board/phytec/phycore_am62x/phycore-am62x.c
@@ -4,6 +4,7 @@
* Author: Wadim Egorov
*/
+#include
#include
#include
#include
diff --git a/configs/phycore_am62x_a53_defconfig
b/configs/phycore_am62x_a53_defconfig
index 44f6e77b626..468c0f373b7 100644
--- a/configs/phycore_am62x_a53_defconfig
+++ b/configs/phycore_am62x_a53_defconfig
@@ -42,6 +42,7 @@ CONFIG_DEFAULT_FDT_FILE="oftree"
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
--
2.34.1
[PATCH 03/13] board: phytec: common: k3: Copy fixed partitions to OS device tree
Copy fixed-partitions nodes from U-Boot device tree to OS device tree.
Signed-off-by: Wadim Egorov
---
board/phytec/common/k3/board.c | 10 ++
configs/phycore_am62x_a53_defconfig | 1 +
2 files changed, 11 insertions(+)
diff --git a/board/phytec/common/k3/board.c b/board/phytec/common/k3/board.c
index f21e154d4fe..3d7e090ccaa 100644
--- a/board/phytec/common/k3/board.c
+++ b/board/phytec/common/k3/board.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
@@ -94,3 +95,12 @@ int board_late_init(void)
return 0;
}
#endif
+
+#if IS_ENABLED(CONFIG_OF_LIBFDT) && IS_ENABLED(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ fdt_copy_fixed_partitions(blob);
+
+ return 0;
+}
+#endif
diff --git a/configs/phycore_am62x_a53_defconfig
b/configs/phycore_am62x_a53_defconfig
index 7545bf2ea73..44f6e77b626 100644
--- a/configs/phycore_am62x_a53_defconfig
+++ b/configs/phycore_am62x_a53_defconfig
@@ -36,6 +36,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_BOOTSTD_FULL=y
CONFIG_SYS_BOOTM_LEN=0x80
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run mmcboot; bootflow scan -lb"
CONFIG_DEFAULT_FDT_FILE="oftree"
CONFIG_BOARD_LATE_INIT=y
--
2.34.1
[PATCH 05/13] configs: phycore_am62x: Update environment location
Update environment location to align with OSPI fixed-partition definitions and provide a redundant environment at a 2nd location. Signed-off-by: Wadim Egorov --- configs/phycore_am62x_a53_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index 468c0f373b7..7476bb4a175 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -11,7 +11,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_ENV_SIZE=0x2000 -CONFIG_ENV_OFFSET=0xD000 +CONFIG_ENV_OFFSET=0x68 CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am625-phyboard-lyra-rdk" CONFIG_SPL_TEXT_BASE=0x8008 @@ -26,6 +26,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x8 CONFIG_SPL_STACK_R=y CONFIG_SPL_SIZE_LIMIT=0x4 CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800 +CONFIG_ENV_OFFSET_REDUND=0x6c CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_SPL_SPI_FLASH_SUPPORT=y @@ -65,6 +66,7 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y -- 2.34.1
[PATCH 06/13] configs: phycore_am64x: Update environment location
Update environment location to align with OSPI fixed-partition definitions and provide a redundant environment at a 2nd location. Signed-off-by: Wadim Egorov --- configs/phycore_am64x_a53_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/phycore_am64x_a53_defconfig b/configs/phycore_am64x_a53_defconfig index 76bb0e53e51..e94d829fd8f 100644 --- a/configs/phycore_am64x_a53_defconfig +++ b/configs/phycore_am64x_a53_defconfig @@ -13,7 +13,7 @@ CONFIG_TARGET_PHYCORE_AM64X_A53=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 CONFIG_ENV_SIZE=0x2 -CONFIG_ENV_OFFSET=0xD000 +CONFIG_ENV_OFFSET=0x68 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am642-phyboard-electra-rdk" @@ -28,6 +28,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x80a0 CONFIG_SPL_BSS_MAX_SIZE=0x8 CONFIG_SPL_STACK_R=y +CONFIG_ENV_OFFSET_REDUND=0x6c CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_SPL_SPI_FLASH_SUPPORT=y @@ -76,6 +77,7 @@ CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y -- 2.34.1
[PATCH 02/13] arch: arm: dts: k3-am642-phyboard-electra: Add fixed partitions
From: Nathan Morrisson
Add a fixed partitions node to the AM64x device tree so that it can
be used to fixup the Linux device tree.
Signed-off-by: Nathan Morrisson
Signed-off-by: Wadim Egorov
---
.../k3-am642-phyboard-electra-rdk-u-boot.dtsi | 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
b/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
index 4677c35e2d9..8f3c3a185ae 100644
--- a/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
@@ -115,6 +115,32 @@
bootph-all;
flash@0 {
bootph-all;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "ospi.tiboot3";
+ reg = <0x0 0x8>;
+ };
+ partition@8 {
+ label = "ospi.tispl";
+ reg = <0x08 0x20>;
+ };
+ partition@28 {
+ label = "ospi.u-boot";
+ reg = <0x28 0x40>;
+ };
+ partition@68 {
+ label = "ospi.env";
+ reg = <0x68 0x4>;
+ };
+ partition@6c {
+ label = "ospi.env.backup";
+ reg = <0x6c 0x4>;
+ };
+ };
};
};
--
2.34.1
[PATCH 01/13] arch: arm: dts: k3-am625-phyboard-lyra: Add fixed partitions
From: Nathan Morrisson
Add a fixed partitions node to the AM62x device tree so that it can
be used to fixup the Linux device tree.
Signed-off-by: Nathan Morrisson
Signed-off-by: Wadim Egorov
---
.../k3-am625-phyboard-lyra-rdk-u-boot.dtsi| 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
index 94162282068..7c76acc0d59 100644
--- a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
@@ -127,6 +127,32 @@
flash@0 {
bootph-all;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "ospi.tiboot3";
+ reg = <0x0 0x8>;
+ };
+ partition@8 {
+ label = "ospi.tispl";
+ reg = <0x08 0x20>;
+ };
+ partition@28 {
+ label = "ospi.u-boot";
+ reg = <0x28 0x40>;
+ };
+ partition@68 {
+ label = "ospi.env";
+ reg = <0x68 0x4>;
+ };
+ partition@6c {
+ label = "ospi.env.backup";
+ reg = <0x6c 0x4>;
+ };
+ };
};
};
--
2.34.1
[PATCH 00/13] *** Various fixes & improvements for phycore-AM6* SoMs ***
This patch set is for u-boot/next. It includes various fixes and improvements for phyCORE-AM62x and phyCORE-AM64x SoMs. Notable is the last patch which prepares for use with future ECC memory fixups. Nathan Morrisson (2): arch: arm: dts: k3-am625-phyboard-lyra: Add fixed partitions arch: arm: dts: k3-am642-phyboard-electra: Add fixed partitions Wadim Egorov (11): board: phytec: common: k3: Copy fixed partitions to OS device tree board: phytec: phycore-am62x: Fix CONFIG_SPL_BOARD_INIT configs: phycore_am62x: Update environment location configs: phycore_am64x: Update environment location arm: dts: k3-am625-phyboard-lyra-rdk: Enable usb port in u-boot configs: phycore_am62x_a53_defconfig: Enable DFU boot board: phytec: phycore-am62x: Pull in k3_dfu.env configs: phycore_am6xx: Update MTD & SPI configs doc: board: phytec: phycore-am62x: Add USB DFU switch config doc: board: phytec: phycore-am6: Use mtd commands board: phytec: phycore-am62x: Use memory nodes in higher boot stages .../k3-am625-phyboard-lyra-rdk-u-boot.dtsi| 35 + .../k3-am642-phyboard-electra-rdk-u-boot.dtsi | 26 + board/phytec/common/k3/board.c| 10 + board/phytec/phycore_am62x/phycore-am62x.c| 31 ++- board/phytec/phycore_am62x/phycore_am62x.env | 2 + configs/phycore_am62x_a53_defconfig | 38 +-- configs/phycore_am62x_r5_defconfig| 1 - configs/phycore_am64x_a53_defconfig | 8 ++-- configs/phycore_am64x_r5_defconfig| 1 - doc/board/phytec/phycore-am62x.rst| 12 -- doc/board/phytec/phycore-am64x.rst| 8 ++-- 11 files changed, 155 insertions(+), 17 deletions(-) -- 2.34.1
[PATCH next v3 8/8] rockchip: add support for Theobroma Systems SOM-RK3588-Q7 Tiger module
From: Quentin Schulz
The RK3588-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
connector) system-on-module from Theobroma Systems, featuring the
Rockchip RK3588.
It provides the following feature set:
* up to 16GB LPDDR4x
* on-module eMMC
* SD card (on a baseboard) via edge connector
* Gigabit Ethernet with on-module GbE PHY
* HDMI/eDP
* MIPI-DSI
* 4x MIPI-CSI (3x on FPC connectors, 1x over Q7)
* HDMI input over FPC connector
* CAN
* USB
- 1x USB 3.0 dual-role (direct connection)
- 2x USB 3.0 host + 1x USB 2.0 host
* PCIe
- 1x PCIe 2.1 Gen3, 4 lanes
- 2xSATA / 2x PCIe 2.1 Gen1, 2 lanes
* on-module ATtiny816 companion controller, implementing:
- low-power RTC functionality (ISL1208 emulation)
- fan controller (AMC6821 emulation)
* on-module Secure Element with Global Platform 2.2.1 compliant
JavaCard environment
The support is added for Tiger on Haikou devkit, similarly to RK3399
Puma and PX30 Ringneck.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
Tested-by: Heiko Stuebner
---
arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi | 37 +++
arch/arm/mach-rockchip/rk3588/Kconfig | 31 ++
board/theobroma-systems/tiger_rk3588/Kconfig | 16 +++
board/theobroma-systems/tiger_rk3588/MAINTAINERS | 13 +++
board/theobroma-systems/tiger_rk3588/Makefile | 10 ++
.../theobroma-systems/tiger_rk3588/tiger_rk3588.c | 53 ++
configs/tiger-rk3588_defconfig | 113 +
doc/board/rockchip/rockchip.rst| 1 +
doc/board/theobroma-systems/index.rst | 1 +
doc/board/theobroma-systems/tiger_rk3588.rst | 102 +++
include/configs/tiger_rk3588.h | 15 +++
11 files changed, 392 insertions(+)
diff --git a/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
b/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
new file mode 100644
index 000..275ae6fdaea
--- /dev/null
+++ b/arch/arm/dts/rk3588-tiger-haikou-u-boot.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+_pwrseq {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_reset {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
+ /* U-Boot currently cannot handle anything below HS200 for eMMC on
RK3588 */
+ /delete-property/ mmc-ddr-1_8v;
+ /delete-property/ cap-mmc-highspeed;
+};
+
+_xfer {
+ bootph-all;
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 9f82e9f3371..9a35c7d9cc2 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -193,6 +193,36 @@ config TARGET_QUARTZPRO64_RK3588
Pine64 QuartzPro64 is a Rockchip RK3588 based SBC (Single Board
Computer) by Pine64.
+config TARGET_TIGER_RK3588
+ bool "Theobroma Systems SOM-RK3588-Q7 (Tiger)"
+ select BOARD_LATE_INIT
+ help
+ The RK3588-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
+ connector) system-on-module from Theobroma Systems, featuring the
+ Rockchip RK3588.
+
+ It provides the following feature set:
+ * up to 16GB LPDDR4x
+ * on-module eMMC
+ * SD card (on a baseboard) via edge connector
+ * Gigabit Ethernet with on-module GbE PHY
+ * HDMI/eDP
+ * MIPI-DSI
+ * 4x MIPI-CSI (3x on FPC connectors, 1x over Q7)
+ * HDMI input over FPC connector
+ * CAN
+ * USB
+- 1x USB 3.0 dual-role (direct connection)
+- 2x USB 3.0 host + 1x USB 2.0 host
+ * PCIe
+- 1x PCIe 2.1 Gen3, 4 lanes
+- 2xSATA / 2x PCIe 2.1 Gen1, 2 lanes
+ * on-module ATtiny816 companion controller, implementing:
+- low-power RTC functionality (ISL1208 emulation)
+- fan controller (AMC6821 emulation)
+ * on-module Secure Element with Global Platform 2.2.1 compliant
+JavaCard environment
+
config TARGET_TURINGRK1_RK3588
bool "Turing Machines RK1 RK3588 board"
select BOARD_LATE_INIT
@@ -266,5 +296,6 @@ source "board/radxa/rock5b-rk3588/Kconfig"
source "board/rockchip/evb_rk3588/Kconfig"
source "board/rockchip/toybrick_rk3588/Kconfig"
source "board/theobroma-systems/jaguar_rk3588/Kconfig"
+source "board/theobroma-systems/tiger_rk3588/Kconfig"
endif
diff --git a/board/theobroma-systems/tiger_rk3588/Kconfig
b/board/theobroma-systems/tiger_rk3588/Kconfig
new file mode 100644
index 000..2c6ac6a9a83
--- /dev/null
+++ b/board/theobroma-systems/tiger_rk3588/Kconfig
@@ -0,0 +1,16 @@
+if TARGET_TIGER_RK3588
+
+config SYS_BOARD
+ default "tiger_rk3588"
[PATCH next v3 7/8] arm64: dts: rockchip: add dual-role usb3 hosts to rk3588 Tiger-Haikou
From: Heiko Stuebner
Apart from the host-only usb3 controller (host2) the rk3588 also provides
two dual-role controllers. On the Tiger-Haikou combination these are
connected to the lower usb3-host port in host-only mode and the micro-usb3
port for dual-role operation.
Add the necessary controllers, phys to the Tiger-Haikou board and enable
the usb-id extcon.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240422163951.2604273-4-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: d7b83921d098bd76623381f75f5cd2296f1315cc ]
(cherry picked from commit 193d3b2a0a98f2dcd8c43bcbf8a766098a9fa75d)
---
.../src/arm64/rockchip/rk3588-tiger-haikou.dts | 58 ++
1 file changed, 58 insertions(+)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
index 2aa43e7430e..e4b7a0a 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
@@ -113,6 +113,16 @@
vin-supply = <_12v>;
};
+ vcc5v0_otg: vcc5v0-otg-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_vbus_drv>;
+ regulator-name = "vcc5v0_otg";
+ regulator-always-on;
+ };
+
vcc5v0_usb: vcc5v0-usb-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_usb";
@@ -137,6 +147,10 @@
status = "okay";
};
+_usb3 {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -199,6 +213,13 @@
<3 RK_PD5 RK_FUNC_GPIO _pull_up>;
};
};
+
+ usb2 {
+ otg_vbus_drv: otg-vbus-drv {
+ rockchip,pins =
+ <1 RK_PB5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
};
{
@@ -214,6 +235,23 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_otg {
+ phy-supply = <_otg>;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_otg {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -236,6 +274,13 @@
{
rts-gpios = < RK_PB3 GPIO_ACTIVE_HIGH>;
+};
+
+_phy0 {
+ status = "okay";
+};
+
+_phy1 {
status = "okay";
};
@@ -249,6 +294,13 @@
status = "okay";
};
+/* host0_xhci on Q7_USB_P1, usb3-otg port */
+_host0_xhci {
+ dr_mode = "otg";
+ extcon = <_usb3>;
+ status = "okay";
+};
+
/* host1 on Q7_USB_P3, usb2 port */
_host1_ehci {
status = "okay";
@@ -259,6 +311,12 @@
status = "okay";
};
+/* host1_xhci on Q7_USB_P0, lower usb3 port */
+_host1_xhci {
+ dr_mode = "host";
+ status = "okay";
+};
+
/* host2 on Q7_USB_P2, upper usb3 port */
_host2_xhci {
status = "okay";
--
2.45.2
[PATCH next v3 6/8] arm64: dts: rockchip: add usb-id extcon on rk3588 tiger
From: Heiko Stuebner
The Q7 standard specifies a usb-id pin on the connector to distiuish
between host and device mode. Model this via the usb-id extcon binding.
While the pin is part of the Q7 standard, so part of the module, the
extcon stays disabled in the som dtsi and will only be enabled in a
baseboard using it.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240422163951.2604273-3-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: eabb53f5dacfd643b5255f35bad30b8f914decdc ]
(cherry picked from commit 4843cec4092318ef7feb0999b0d34ef817465b33)
---
dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
index a8565720cf5..aebe1fedd2d 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
@@ -23,6 +23,14 @@
reset-gpios = < RK_PA3 GPIO_ACTIVE_HIGH>;
};
+ extcon_usb3: extcon-usb3 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = < RK_PC0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_id>;
+ status = "disabled";
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -327,6 +335,13 @@
rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO _pull_none>;
};
};
+
+ usb3 {
+ usb3_id: usb3-id {
+ rockchip,pins =
+ <3 RK_PC0 RK_FUNC_GPIO _pull_none>;
+ };
+ };
};
{
--
2.45.2
[PATCH next v3 5/8] arm64: dts: rockchip: fix comment for upper usb3 port
From: Heiko Stuebner
The comment for the host2_xhci points to the wrong port on the board.
The upper usb3 port is the correct one, so fix the comment to prevent
confusion.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240422163951.2604273-2-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: 3482efee1144262dc839792103e6a9e29defecbc ]
(cherry picked from commit 56f3031edf22d163f10bc4b631d37a9aaa82d4d4)
---
dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
index 9bdd14799ef..2aa43e7430e 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
@@ -239,12 +239,12 @@
status = "okay";
};
-/* host0 on Q7_USB_P2, lower usb3 port */
+/* host0 on Q7_USB_P2, upper usb3 port */
_host0_ehci {
status = "okay";
};
-/* host0 on Q7_USB_P2, lower usb3 port */
+/* host0 on Q7_USB_P2, upper usb3 port */
_host0_ohci {
status = "okay";
};
@@ -259,7 +259,7 @@
status = "okay";
};
-/* host2 on Q7_USB_P2, lower usb3 port */
+/* host2 on Q7_USB_P2, upper usb3 port */
_host2_xhci {
status = "okay";
};
--
2.45.2
[PATCH next v3 4/8] arm64: dts: rockchip: fix pcie-refclk frequency on rk3588 tiger
From: Heiko Stuebner
The clock-generator of course only produces a 100MHz clock rate,
not 1GHz.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240423114635.2637310-1-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: 0eb2a93518fb4728bd1d55fcd3b57fce4797ef1d ]
(cherry picked from commit b574cbafae976cf508692088944e45c9764c0048)
---
dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
index 29f8e536de1..a8565720cf5 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
@@ -46,7 +46,7 @@
pcie_refclk_gen: pcie-refclk-gen-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <10>;
+ clock-frequency = <1>;
};
pcie_refclk: pcie-refclk-clock {
--
2.45.2
[PATCH next v3 3/8] arm64: dts: rockchip: correct gpio_pwrctrl1 typos on rk3588(s) boards
From: Jing Luo
gpio_pwrctrl2 gets duplicated by both rk806_dvs1_null and rk806_dvs2_null
gpio_pwrctrl1 is unset. This typo appears in multiple files. Let's fix them.
Note: I haven't had the chance to test them all because I don't own all
of these boards (obviously). Please test if it's needed.
Signed-off-by: Jing Luo
Link: https://lore.kernel.org/r/20240420130355.639406-1-jing@jing.rocks
Signed-off-by: Heiko Stuebner
[ upstream commit: d7f2039e5321636069baa77ef2f1e5d22cb69a88 ]
(cherry picked from commit cb2b6d1d19ed10fcaec5f5859c08a3355d1c66e0)
---
dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5.dtsi | 2 +-
dts/upstream/src/arm64/rockchip/rk3588-edgeble-neu6a-common.dtsi | 2 +-
dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts| 2 +-
dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi| 2 +-
dts/upstream/src/arm64/rockchip/rk3588-turing-rk1.dtsi | 2 +-
dts/upstream/src/arm64/rockchip/rk3588s-coolpi-4b.dts| 2 +-
dts/upstream/src/arm64/rockchip/rk3588s-indiedroid-nova.dts | 2 +-
dts/upstream/src/arm64/rockchip/rk3588s-orangepi-5.dts | 2 +-
dts/upstream/src/arm64/rockchip/rk3588s-rock-5a.dts | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5.dtsi
index 94ecb9b4f98..170501a879d 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5.dtsi
@@ -357,7 +357,7 @@
vcca-supply = <_sys>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-edgeble-neu6a-common.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-edgeble-neu6a-common.dtsi
index c0d4a15323e..d9bf67525e8 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-edgeble-neu6a-common.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-edgeble-neu6a-common.dtsi
@@ -182,7 +182,7 @@
#gpio-cells = <2>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts
b/dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts
index 39d65002add..7d7303f8ecb 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts
@@ -452,7 +452,7 @@
vcca-supply = <_sys>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
index 4984e36a8c2..29f8e536de1 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
@@ -401,7 +401,7 @@
vcca-supply = <_sys>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-turing-rk1.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-turing-rk1.dtsi
index dc08da518a7..6b9206ce4a0 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-turing-rk1.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-turing-rk1.dtsi
@@ -318,7 +318,7 @@
#gpio-cells = <2>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588s-coolpi-4b.dts
b/dts/upstream/src/arm64/rockchip/rk3588s-coolpi-4b.dts
index e037bf9db75..7f4d7bb9a07 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588s-coolpi-4b.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588s-coolpi-4b.dts
@@ -479,7 +479,7 @@
vcca-supply = <_sys>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588s-indiedroid-nova.dts
b/dts/upstream/src/arm64/rockchip/rk3588s-indiedroid-nova.dts
index ce8119cbb82..a5b76e24ceb 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588s-indiedroid-nova.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588s-indiedroid-nova.dts
@@ -528,7 +528,7 @@
vcca-supply = <_sys>;
[PATCH next v3 2/8] arm64: dts: rockchip: move uart2 pinmux to dtsi on rk3588-tiger
From: Heiko Stuebner
The association of uart2 to the q7-uart pins is part of the module
itself and not the baseboard used. Therefore move the pinctrl over
to the tiger dtsi.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240422143356.2596414-1-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: 5adbad5c464a708a87cf5ade1bfe2ca947bb2f82 ]
(cherry picked from commit f8314a4fbc00a3d651a7e9b4d9462d10c6c02a12)
---
dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts | 1 -
dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi | 5 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
index d672198c6b6..9bdd14799ef 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger-haikou.dts
@@ -231,7 +231,6 @@
};
{
- pinctrl-0 = <_xfer>;
status = "okay";
};
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
index 72fe696b003..4984e36a8c2 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
@@ -688,6 +688,11 @@
status = "okay";
};
+/* Routed to UART0 on the Q7 connector */
+ {
+ pinctrl-0 = <_xfer>;
+};
+
/* Mule-ATtiny UPDI */
{
pinctrl-0 = <_xfer>;
--
2.45.2
[PATCH next v3 1/8] arm64: dts: rockchip: enable gpu on rk3588-tiger
From: Heiko Stuebner
Enable the mali gpu node and add the som-specific supply-regulator.
Signed-off-by: Heiko Stuebner
Reviewed-by: Quentin Schulz
Link: https://lore.kernel.org/r/20240327112120.1181570-2-he...@sntech.de
Signed-off-by: Heiko Stuebner
[ upstream commit: f5256f8ed4b729c3ab9d9cd7d406313773484b59 ]
(cherry picked from commit 27350b241eafea37dc94743cd9c5dd83295faca9)
---
dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
index 1eb2543a5fd..72fe696b003 100644
--- a/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3588-tiger.dtsi
@@ -139,6 +139,11 @@
snps,reset-delays-us = <0 1 10>;
};
+ {
+ mali-supply = <_gpu_s0>;
+ status = "okay";
+};
+
{
pinctrl-0 = <_xfer>;
};
--
2.45.2
