Re: [RFC PATCH v3] doc: arch: Add document for RISC-V architecture

2023-02-16 Thread Rick Chen
> From: Peter Yu-Chien Lin(林宇謙) 
> Sent: Tuesday, February 14, 2023 6:19 PM
> To: u-boot@lists.denx.de
> Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) 
> ; s...@chromium.org; xypron.g...@gmx.de; Peter Yu-Chien 
> Lin(林宇謙) ; Samuel Holland 
> Subject: [RFC PATCH v3] doc: arch: Add document for RISC-V architecture
>
> This patch adds a brief introduction to the RISC-V architecture and the 
> typical boot process used on a variety of RISC-V platforms.
>
> Signed-off-by: Yu Chien Peter Lin 
> Reviewed-by: Samuel Holland 
> Reviewed-by: Simon Glass 
> ---
> Changes v1 -> v2
> - Use 'boot phases' rather than 'boot stages'
> - Pick up Samuel and Simon's RB tags
> Changes v2 -> v3
> - Follow the suggestion by Heinrich [1]
> - Add the document as an entry of Andes maintainer in MAINTAINERS
> - Add some pointers to OpenSBI document
>
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20230212070053.14800-1-peter...@andestech.com/
> ---
>  MAINTAINERS|  1 +
>  doc/arch/index.rst |  1 +
>  doc/arch/riscv.rst | 74 ++
>  3 files changed, 76 insertions(+)
>  create mode 100644 doc/arch/riscv.rst

Reviewed-by: Rick Chen 


Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Heinrich Schuchardt




On 2/17/23 03:55, Simon Glass wrote:

" properHi Heinrich,

On Thu, 16 Feb 2023 at 14:31, Heinrich Schuchardt
 wrote:




On 2/16/23 21:17, Simon Glass wrote:

Hi Heinrich,

On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt
 wrote:


Some boards provide main U-Boot as a dedicated partition to SPL.
Currently we can define either a fixed partition number or an MBR
partition type to define which partition is to be used.

Partition numbers tend to conflict with established partitioning schemes
of Linux distros. MBR partitioning is more and more replaced by GPT
partitioning.

Allow defining a partition type GUID identifying the partition to load
main U-Boot from.

Signed-off-by: Heinrich Schuchardt 
---
v2:
  avoid if/endif in Kconfig
---
   common/spl/Kconfig   | 27 ++-
   common/spl/spl_mmc.c | 13 +
   2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 3c2af453ab..9d12b48297 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
used in raw mode

   config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
-   bool "MMC raw mode: by partition type"
+   bool "MMC raw mode: by MBR partition type"
  depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
  help
- Use partition type for specifying U-Boot partition on MMC/SD in
+ Use MBR partition type for specifying U-Boot partition on MMC/SD in
raw mode. U-Boot will be loaded from the first partition of this
type to be found.

   config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
-   hex "Partition Type on the MMC to load U-Boot from"
+   hex "MBR Partition Type on the MMC to load U-Boot from"
  depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
  help
- Partition Type on the MMC to load U-Boot from, when the MMC is being
- used in raw mode.
+ MBR Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   bool "MMC raw mode: GPT by partition type"
+   depends on PARTITION_TYPE_GUID && 
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   help
+ Use GPT partition type for specifying U-Boot partition on MMC/SD in
+ raw mode. U-Boot will be loaded from the first partition of this
+ type to be found.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
+   string "GPT Partition Type on the MMC to load U-Boot from"
+   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6


What is this? Can we have a register of these hideous things and call
them by name?


Further, I don't see any documentation on this in U-Boot. Could you at
least add a list of these things?




+   help
+ GPT Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode. The GUID must be lower case, low endian,
+ and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.

   config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
  bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b2048..69bf1d6e98 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
  struct disk_partition info;
  int err;

+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
+   err = part_get_info(mmc_get_blk_desc(mmc), i, );
+   if (err)
+   continue;
+   if (!strncmp(info.type_guid,
+
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
+UUID_STR_LEN)) {
+   partition = i;
+   break;
+   }
+   }
+#endif
   #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
  int type_part;
  /* Only support MBR so DOS_ENTRY_NUMBERS */
--
2.38.1



Is it possible to avoid using #ifdef here?


Unfortunately not. Field 'type_guid' is restricted by an #ifdef. So
unconditional compilation would fail.


Do you think it is worth adding an accessor as we have done with some
global_data things?


There are other places like disk/part_efi.c where we could trade #ifdef 
for if with such an accessor. The accessor itself would require an #ifdef.


We should be careful about the value returned for 
CONFIG_PARTITION_TYPE_GUID=n. Returning NULL would probably lead to 
warnings from GCC and Coverity. We would better return a dummy string 
like "----".








Longer term, I wonder if we can add a DT schema for all of

RE: [PATCH] configs: evb-ast2600: Enable configs to store env in SPI

2023-02-16 Thread ChiaWei Wang
Reviewed-by: Chia-Wei Wang 

Thanks.

> From: Ryan Chen 
> Sent: Friday, February 10, 2023 3:42 PM
> 
> Enable defconfigs relevant for storing env on SPI flash.
> 
> Signed-off-by: Ryan Chen 
> ---
>  configs/evb-ast2600_defconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> index 3440062156..7c09e846ac 100644
> --- a/configs/evb-ast2600_defconfig
> +++ b/configs/evb-ast2600_defconfig
> @@ -13,6 +13,8 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds"
>  CONFIG_ENV_SIZE=0x1
> +CONFIG_ENV_OFFSET=0xe
> +CONFIG_ENV_SECT_SIZE=0x1
>  CONFIG_DM_GPIO=y
>  CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb"
>  CONFIG_SPL_SERIAL=y
> @@ -74,6 +76,8 @@ CONFIG_EFI_PARTITION=y  #
> CONFIG_SPL_EFI_PARTITION is not set  CONFIG_SPL_OF_CONTROL=y
> CONFIG_ENV_OVERWRITE=y
> +CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_ENV_SECT_SIZE_AUTO=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_DM=y
> --
> 2.34.1



[PATCH] arm: mvebu: Use 4K sector for Thecus N2350 SPI flash

2023-02-16 Thread Tony Dinh
Since the SPI flash chip mx25l3205d on this board has 4K-sector
capability, enable it for the envs.

Signed-off-by: Tony Dinh 
---

 configs/n2350_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig
index dcb2c96791..b85ef0dfeb 100644
--- a/configs/n2350_defconfig
+++ b/configs/n2350_defconfig
@@ -14,7 +14,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
 CONFIG_TARGET_N2350=y
 CONFIG_ENV_SIZE=0x1
 CONFIG_ENV_OFFSET=0x10
-CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_ENV_SECT_SIZE=0x1000
 CONFIG_DEFAULT_DEVICE_TREE="armada-385-thecus-n2350"
 CONFIG_SPL_TEXT_BASE=0x4030
 CONFIG_SYS_PROMPT="N2350 > "
-- 
2.30.2



Re: [Patch] net: dwc_eth_qos - works with fixed-phy

2023-02-16 Thread Marek Vasut

On 2/16/23 17:45, Nicole Battenfeld wrote:


Am 16.02.23 um 02:39 schrieb Marek Vasut:

On 2/15/23 17:16, Elmar Psilog wrote:

Let the EQoS in imx8mp handle fixed-phy too.
Without that patch it lost track to the node to scan
speed and duplex.
Patch was created by Marek Vasut, just tested by me.

Signed-off-by: Elmar Psilog 
---
drivers/net/dwc_eth_qos.c
1 file changed


If you were to use 'git format-patch' and 'git send-email', those 
tools would generate the correct Subject and diffstat etc. for you. 
Also have a look at scripts/checkpatch.pl to validate whether a patch 
is correct.



diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index afc47b56ff..10915d8e47 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -785,9 +785,21 @@ static int eqos_start(struct udevice *dev)
  */
 if (!eqos->phy) {
 int addr = -1;
-   addr = eqos_get_phy_addr(eqos, dev);
-   eqos->phy = phy_connect(eqos->mii, addr, dev,
- eqos->config->interface(dev));
+   ofnode fixed_node;
+
+   if (IS_ENABLED(CONFIG_PHY_FIXED)) {
+   fixed_node = 
ofnode_find_subnode(dev_ofnode(dev),

+   "fixed-link");
+   if (ofnode_valid(fixed_node)) {
+   eqos->phy =
fixed_phy_create(dev_ofnode(dev));
+   eqos->phy_of_node = fixed_node;
+   }
+   }
+   if (!eqos->phy) {
+   addr = eqos_get_phy_addr(eqos, dev);
+   eqos->phy = phy_connect(eqos->mii, addr, dev,
eqos->config->interface(dev));
+   }
+
 if (!eqos->phy) {
 pr_err("phy_connect() failed");
 goto err_stop_resets;


+CC Ramon the network maintainer .



New attempt: used script to check and fix and used git format-patch.

Also base is latest trunk, not v2023.1 as before.

Hope this fits your needs, otherwise I afraid I need detailed instruction.


Basically the process is documented at length here:

https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html

which is very much identical to even lengthier Linux patch submission 
guidelines:


https://www.kernel.org/doc/html/latest/process/submitting-patches.html

If you use git send-email , that will do most of the work for you, 
including correct formatting etc. The invocation is something like:


$ git send-email --annotate --to=u-boot@lists.denx.de 
--cc=additional-per...@to.copy --cc=one@more.person -1 


Note that you do have to configure SMTP access in git-config for that to 
work.


You had the patch right very much the first time, except for a few style 
issues, like [Patch] instead of [PATCH] in the subject, patch itself was 
malformed likely due to copy-paste, and the checkpatch issues had to be 
addressed . When sending a new revision, include changelog in the patch 
below the --- below diffstat, and also make sure the Subjects reads 
[PATCH v2], git send-email -v2 does that for you (and -v3 does v3 etc.). 
You're almost there, no worries.


Wait for Ramon to review this patch and then send V2 if needed.


Re: [PATCH v2 9/9] efi_loader: device_path: support blkmap devices

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:35, Tobias Waldekranz  wrote:
>
> Create a distinct EFI device path for each blkmap device.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  include/efi_loader.h |  4 
>  lib/efi_loader/efi_device_path.c | 30 ++
>  2 files changed, 34 insertions(+)
>

Reviewed-by: Simon Glass 


Re: [PATCH v2 7/9] test: blkmap: Add test suite

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> Verify that:
>
> - Block maps can be created and destroyed
> - Mappings aren't allowed to overlap
> - Multiple mappings can be attached and be read/written from/to
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  MAINTAINERS   |   1 +
>  configs/sandbox_defconfig |   1 +
>  test/dm/Makefile  |   1 +
>  test/dm/blkmap.c  | 201 ++
>  4 files changed, 204 insertions(+)
>  create mode 100644 test/dm/blkmap.c
>

Reviewed-by: Simon Glass 


Re: [PATCH v2 3/9] blk: blkmap: Add basic infrastructure

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> blkmaps are loosely modeled on Linux's device mapper subsystem. The
> basic idea is that you can create virtual block devices whose blocks
> can be backed by a plethora of sources that are user configurable.
>
> This change just adds the basic infrastructure for creating and
> removing blkmap devices. Subsequent changes will extend this to add
> support for actual mappings.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  MAINTAINERS|   6 +
>  drivers/block/Kconfig  |  18 ++
>  drivers/block/Makefile |   1 +
>  drivers/block/blk-uclass.c |   1 +
>  drivers/block/blkmap.c | 343 +
>  include/blkmap.h   |  35 
>  include/dm/uclass-id.h |   1 +
>  7 files changed, 405 insertions(+)
>  create mode 100644 drivers/block/blkmap.c
>  create mode 100644 include/blkmap.h
>

Reviewed-by: Simon Glass 


Re: [PATCH v2 8/9] doc: blkmap: Add introduction and examples

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> Explain block maps by going through two common use-cases.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  MAINTAINERS  |   1 +
>  doc/usage/blkmap.rst | 111 +++
>  doc/usage/index.rst  |   1 +
>  3 files changed, 113 insertions(+)
>  create mode 100644 doc/usage/blkmap.rst

Reviewed-by: Simon Glass 


Re: [PATCH v2 6/6] RFC: binman: Improve allow missing for mkimage entry

2023-02-16 Thread Simon Glass
Hi Jonas,

On Wed, 15 Feb 2023 at 11:25, Jonas Karlman  wrote:
>
> Hi Simon,
>
> On 2023-02-14 20:48, Simon Glass wrote:
> > Hi Jonas,
> >
> > On Tue, 14 Feb 2023 at 03:34, Jonas Karlman  wrote:
> >>
> >> Implement CheckMissing and CheckOptional methods that is adapted to
> >> Entry_mkimage in order to improve support for allow missing flag.
> >>
> >> Use collect_contents_to_file in multiple-data-files handling to improve
> >> support for allow missing and fake blobs handling.
> >>
> >> Signed-off-by: Jonas Karlman 
> >> ---
> >> Building for RK3568 without ROCKCHIP_TPL will result in the following
> >> error message, regardless if BINMAN_ALLOW_MISSING is used or not.
> >>
> >>   binman: Filename 'rockchip-tpl' not found in input path (...)
> >>
> >> With this patch and using BINMAN_ALLOW_MISSING=1 a new external blob
> >> with no content is created and then passed to mkimage, resulting in an
> >> error from the mkimage command.
> >>
> >>   binman: Error 255 running 'mkimage -d 
> >> ./mkimage-0.simple-bin.mkimage:./mkimage-1.simple-bin.mkimage -n rk3568 -T 
> >> rksd ./idbloader.img': mkimage: Can't read ./mkimage-0.simple-bin.mkimage: 
> >> Invalid argument
> >>
> >> If the --fake-ext-blobs argument is also used I get the message I was
> >> expecting to see from the beginning.
> >>
> >>   Image 'main-section' is missing external blobs and is non-functional: 
> >> rockchip-tpl
> >>
> >>   /binman/simple-bin/mkimage/rockchip-tpl:
> >>  An external TPL is required to initialize DRAM. Get the external TPL
> >>  binary and build with ROCKCHIP_TPL=/path/to/ddr.bin. One possible 
> >> source
> >>  for the external TPL binary is 
> >> https://github.com/rockchip-linux/rkbin>>>   Image 'main-section' has 
> >> faked external blobs and is non-functional: rockchip-tpl
> >>
> >>   Some images are invalid
> >>
> >> Not sure how this should work, but I was expecting to see the message
> >> about the missing rockchip-tpl from the beginning instead of the generic
> >> "not found in input path" message. At leas with BINMAN_ALLOW_MISSING=1.
> >>
> >>  tools/binman/etype/mkimage.py | 37 +++
> >>  1 file changed, 33 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
> >> index cb264c3cad0b..44510a8c40ba 100644
> >> --- a/tools/binman/etype/mkimage.py
> >> +++ b/tools/binman/etype/mkimage.py
> >> @@ -153,10 +153,12 @@ class Entry_mkimage(Entry):
> >>  if self._multiple_data_files:
> >>  fnames = []
> >>  uniq = self.GetUniqueName()
> >> -for entry in self._mkimage_entries.values():
> >> -if not entry.ObtainContents(fake_size=fake_size):
> >> +for idx, entry in enumerate(self._mkimage_entries.values()):
> >> +entry_data, entry_fname, _ = 
> >> self.collect_contents_to_file(
> >> +[entry], 'mkimage-%s' % idx, fake_size)
> >> +if entry_data is None:
> >
> > This is OK, I suppose, but I'm not quite sure what actually changes
> > here, other than writing each entry to a file?
>
> The collect_contents_to_file function seemed to handle the
> external/missing/optional/faked entry flags. So I changed to use that
> function in order to see if that would change anything, see below.
>
> Use of this function does make it possible to use entry type other
> then external blobs, not sure if that would ever be needed/useful.
>
> >
> > Also, if you do this, please add / extend a test that checks that the
> > output files are written, since there is otherwise no coverage here.
> >
> > What test uses these optional mkimage pieces?
>
> Sorry, I was not clear enough about the reason for these changes in my
> message above.
>
> Building with --rockchip-tpl-path=/path/to/existing/tpl works as
> expected and generates a working image.
>
> I was expecting that the missing-blob-help message added in patch 1
> would be shown by binman when rockchip-tpl-path was empty/not-existing,
> or at least together with the allow-missing flag.
>
> However, whatever I tested, empty/none-existing rockchip-tpl-path,
> allow-missing, fake-ext-blobs, I was not able to see this message.
> Instead, all I could get from binman was this "Filename 'rockchip-tpl'
> not found in input path" message.
>
> Maybe my assumptions about when these missing messages should be shown
> is wrong?
>
> Trying binman with the following two dts and --allow-missing gives
> different results. First one shows the missing message, second one show
> filename not found.
>
> binman {
> rockchip-tpl {
> };
> };
>
> binman {
> mkimage {
> args = "-n rk3568 -T rksd";
> multiple-data-files;
>
> rockchip-tpl {
> };
> };
> };
>
> With the changes in this patch I instead get the missing message when I
> also add the --fake-ext-blobs flag, so it clearly needs more work or
> a 

Re: [PATCH v2 5/9] blk: blkmap: Add linear device mapping support

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> Allow a slice of an existing block device to be mapped to a
> blkmap. This means that filesystems that are not stored at exact
> partition boundaries can be accessed by remapping a slice of the
> existing device to a blkmap device.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  drivers/block/blkmap.c | 71 ++
>  include/blkmap.h   | 13 
>  2 files changed, 84 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH v2 4/9] blk: blkmap: Add memory mapping support

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> Allow a slice of RAM to be mapped to a blkmap. This means that RAM can
> now be accessed as if it was a block device, meaning that existing
> filesystem drivers can now be used to access ramdisks.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  drivers/block/blkmap.c | 105 +
>  include/blkmap.h   |  29 
>  2 files changed, 134 insertions(+)

Reviewed-by: Simon Glass 

Only nit is we normally have a blank line before the final 'return' in
a function


Re: [PATCH] binman: bintool: Add support for tool directories

2023-02-16 Thread Simon Glass
Hi Neha,

On Thu, 16 Feb 2023 at 03:49, Neha Malcom Francis  wrote:
>
> Currently, bintool supports external compilable tools as single
> executable files. Adding support for git repos that can be used to run
> non-compilable scripting tools that cannot otherwise be present in
> binman.
>
> Signed-off-by: Neha Malcom Francis 
> ---
>  tools/binman/bintool.py | 42 ++---
>  tools/patman/tools.py   |  2 ++
>  2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
> index 8fda13ff01..a1e37699aa 100644
> --- a/tools/binman/bintool.py
> +++ b/tools/binman/bintool.py
> @@ -32,12 +32,13 @@ FORMAT = '%-16.16s %-12.12s %-26.26s %s'
>  modules = {}
>
>  # Possible ways of fetching a tool (FETCH_COUNT is number of ways)
> -FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_COUNT = range(4)
> +FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_NO_BUILD, FETCH_COUNT = range(5)
>
>  FETCH_NAMES = {
>  FETCH_ANY: 'any method',
>  FETCH_BIN: 'binary download',
> -FETCH_BUILD: 'build from source'
> +FETCH_BUILD: 'build from source',
> +FETCH_NO_BUILD: 'download source without building'

How about FETCH_SOURCE ?

>  }
>
>  # Status of tool fetching
> @@ -206,7 +207,7 @@ class Bintool:
>  result = try_fetch(method)
>  if not result:
>  return FAIL
> -if result is not True:
> +if result is not True and method != FETCH_NO_BUILD:
>  fname, tmpdir = result
>  dest = os.path.join(DOWNLOAD_DESTDIR, self.name)
>  print(f"- writing to '{dest}'")
> @@ -261,7 +262,7 @@ class Bintool:
>  show_status(col.RED, 'Failures', status[FAIL])
>  return not status[FAIL]
>
> -def run_cmd_result(self, *args, binary=False, raise_on_error=True):
> +def run_cmd_result(self, *args, binary=False, raise_on_error=True, 
> add_name=True):
>  """Run the bintool using command-line arguments
>
>  Args:
> @@ -278,7 +279,10 @@ class Bintool:
>  if self.name in self.missing_list:
>  return None
>  name = os.path.expanduser(self.name)  # Expand paths containing ~
> -all_args = (name,) + args
> +if add_name:
> +all_args = (name,) + args
> +else:
> +all_args = args
>  env = tools.get_env_with_path()
>  tout.detail(f"bintool: {' '.join(all_args)}")
>  result = command.run_pipe(
> @@ -304,7 +308,7 @@ class Bintool:
>  tout.debug(result.stderr)
>  return result
>
> -def run_cmd(self, *args, binary=False):
> +def run_cmd(self, *args, binary=False, add_name=True):
>  """Run the bintool using command-line arguments
>
>  Args:
> @@ -315,7 +319,7 @@ class Bintool:
>  Returns:
>  str or bytes: Resulting stdout from the bintool
>  """
> -result = self.run_cmd_result(*args, binary=binary)
> +result = self.run_cmd_result(*args, binary=binary, add_name=add_name)
>  if result:
>  return result.stdout
>
> @@ -354,6 +358,30 @@ class Bintool:
>  return None
>  return fname, tmpdir
>
> +@classmethod
> +def fetch_from_git(cls, git_repo):
> +"""Fetch a bintool git repo
> +
> +This clones the repo and returns
> +
> +Args:
> +git_repo (str): URL of git repo
> +bintool_path (str): Relative path of the tool in the repo, after
> +build is complete
> +
> +Returns:
> +str: Directory of fetched repo
> +or None on error
> +"""
> +dir = os.path.join(DOWNLOAD_DESTDIR, cls.name)
> +os.mkdir(dir)
> +print(f"- clone git repo '{git_repo}' to '{dir}'")
> +tools.run('git', 'clone', '--depth', '1', git_repo, dir)
> +if not os.path.exists(dir):
> +print(f"- Repo '{dir}' was not produced")
> +return None
> +return dir
> +
>  @classmethod
>  def fetch_from_url(cls, url):
>  """Fetch a bintool from a URL
> diff --git a/tools/patman/tools.py b/tools/patman/tools.py
> index 2ac814d476..b8533c72b2 100644
> --- a/tools/patman/tools.py
> +++ b/tools/patman/tools.py
> @@ -399,6 +399,8 @@ def tool_find(name):
>  fname = os.path.join(path, name)
>  if os.path.isfile(fname) and os.access(fname, os.X_OK):
>  return fname
> +if os.path.isdir(fname) and os.access(fname, os.X_OK):
> +return fname

How come the duplication?

>
>  def run(name, *args, **kwargs):
>  """Run a tool with some arguments
> --
> 2.34.1
>

Please can you add a test to bintool_test.py ?

Regards,
Simon


Re: [PATCH v2 6/9] cmd: blkmap: Add blkmap command

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 08:34, Tobias Waldekranz  wrote:
>
> Add a frontend for the blkmap subsystem. In addition to the common
> block device operations, this allows users to create and destroy
> devices, and map in memory and slices of other block devices.
>
> With that we support two primary use-cases:
>
> - Being able to "distro boot" from a RAM disk. I.e., from an image
>   where the kernel is stored in /boot of some filesystem supported
>   by U-Boot.
>
> - Accessing filesystems not located on exact partition boundaries,
>   e.g. when a filesystem image is wrapped in an FIT image and stored
>   in a disk partition.
>
> Signed-off-by: Tobias Waldekranz 
> ---
>  MAINTAINERS  |   1 +
>  cmd/Kconfig  |  19 +
>  cmd/Makefile |   1 +
>  cmd/blkmap.c | 233 +++
>  disk/part.c  |   1 +
>  5 files changed, 255 insertions(+)
>  create mode 100644 cmd/blkmap.c
>

Reviewed-by: Simon Glass 

nit: If you use a single quote inside the double quotes, you can avoid
the backflashes


Re: [PATCH] binman: Avoid requiring a home directory on startup

2023-02-16 Thread Simon Glass
Hi Tom,

On Thu, 16 Feb 2023 at 17:19, Tom Rini  wrote:
>
> On Thu, Feb 16, 2023 at 05:12:33PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 14 Feb 2023 at 13:27, Tom Rini  wrote:
> > >
> > > On Tue, Feb 14, 2023 at 03:12:46PM -0500, Mike Frysinger wrote:
> > > > On Tue, Feb 14, 2023 at 3:08 PM Tom Rini  wrote:
> > > > > Downloading things from the internet and putting them in to the 
> > > > > default
> > > > > PATH always and forever is also kinda not great?
> > > >
> > > > you just described a standard distribution.  this is like literally
> > > > how all of them work.  not to mention every other language-specific
> > > > distro tool out there (e.g. Python pip, Perl cpan, Go, etc...).
> > > >
> > > > maybe you'd like more guarantees on top (e.g. signature verification)
> > > > which is reasonable.
> > > >
> > > > but to be clear, this script is already merged & in the tree, so your
> > > > feedback doesn't block this patch.
> > >
> > > Yes, exactly. This is a fix on top of what we do today, so it should go
> > > in. But modern distributions only install signed packages, and
> > > language-specific tools tend to be a hive of bad examples. Looking over
> > > binman right now, I see that we're either using apt (and oh, there's
> > > "aot" typo in one spot) or downloading from a known Google drive, for
> > > only a few less common tools.
> > >
> > > So yes, I would like to see some ideas on how to improve things in the
> > > future so we aren't putting the binaries somewhere that's not a default
> > > (or frequently common) PATH location.
> >
> > Are you thinking they should go in ~/.binman-tools or something like
> > that? Then we would need to tell people to add it to their path. But
> > we could make binman look there automatically.
>
> We should document that it's where we're putting stuff, not so much
> "tell" them, unless you mean as a note when downloading.  But yes,
> ~/.binman-tools sounds reasonable.  Maybe a flag to point elsewhere?

OK I will take a look.

Regards,
Simon


Re: [PATCH 1/2 v3] tpm: add a function that performs selftest + startup

2023-02-16 Thread Simon Glass
Hi Ilias,

On Thu, 16 Feb 2023 at 14:10, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
> Apologies for the late reply.
>
> On Tue, Feb 07, 2023 at 06:38:54AM -0700, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Mon, 6 Feb 2023 at 06:25, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi Simon,
> > > On Sat, Jan 28, 2023 at 03:01:22PM -0700, Simon Glass wrote:
> > > > Hi Ilias,
> > > >
> > > > On Thu, 26 Jan 2023 at 01:18, Ilias Apalodimas
> > > >  wrote:
> > > > >
> > > > > As described in [0] if a command requires use of an untested algorithm
> > > > > or functional module, the TPM performs the test and then completes the
> > > > > command actions.
> > > > >
> > > > > Since we don't check for TPM_RC_NEEDS_TEST (which is the return code 
> > > > > of
> > > > > the TPM in that case) and even if we would, it would complicate our 
> > > > > TPM
> > > > > code for no apparent reason,  add a wrapper function that performs 
> > > > > both
> > > > > the selftest and the startup sequence of the TPM.
> > > > >
> > > > > It's worth noting that this is implemented on TPMv2.0.  The code for
> > > > > 1.2 would look similar,  but I don't have a device available to test.
> > > > >
> > > > > [0]
> > > > > https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf
> > > > > §12.3 Self-test modes
> > > > >
> > > > > Signed-off-by: Ilias Apalodimas 
> > > > > ---
> > > > > Changes since v2:
> > > > > - add tpm_init() to auto start
> > > > >
> > > > > Changes since v1:
> > > > > - Remove a superfluous if statement
> > > > > - Move function comments to the header file
> > > > >  include/tpm-v2.h  | 19 +++
> > > > >  include/tpm_api.h |  8 
> > > > >  lib/tpm-v2.c  | 24 
> > > > >  lib/tpm_api.c |  8 
> > > > >  4 files changed, 59 insertions(+)
> > > >
> > > > I think this is a good idea, but it should be implemented at the API
> > > > level. Please see below.
> > >
> > > It is implemented at the API level.  I could try testing this in QEMU 
> > > using
> > > swtpm, but the driver I added for mmio is TPMv2 only.  So I don't really 
> > > feel
> > > comfortable adding support for a device I can't test.  If someone has a
> > > tpm1.2 and is willing to test it, I can modify the patch accordingly.
> >
> > swtpm is a bit of a pain, as we discussed and as you are showing by
> > this comment. IMO it is good enough to use the sandbox testing for
> > this function. See below.
> >
>
> The comment says the exact opposite.  It never hints on any swtpm
> limitations or problems.

Manual testing is fine but it doesn't last. It is better to invest in
automated tests.

>
> fwiw swtpm is fine.  It even offers a socket we could hook against instead of
> re-inventing the wheel with the sandbox tpm (which is missing 95% of the
> tpm functionality anyway).  The reason we can't use it is that the u-boot
> driver only implements 2.0.

I wish I could convince you that emulators are not reinventing the
wheel. They are designed for testing. They run quickly, are easy to
debug and can test failure conditions, not just the happy path.

In Chrome OS we recently took our Zephyr code base from ~35% to 90%
test coverage using emulators, without a QEMU in sight[1]. Emulators
are a long-established software technique, one that has taken U-Boot a
long way.

>
> [...]
>
> > > > > +   rc = tpm_init(dev);
> > > > > +   if (rc && rc != -EBUSY)
> > > >
> > > > Does that work, with rc being unsigned?
> > >
> > >
> > > Yes integer promotion is fine here.  As long as we don't try to do 
> > > anything
> > > silly e.g start doing math on the result or compare it against bigger 
> > > types
> > > this is fine.
> >
> > OK
> >
> > > There was a patch from Sughosh in the past that you rejected and it was
> > > converting enough of the TPM API return calls to int.  I think the reason
> > > the API works with u32, is that the spec return codes from the device
> > > itself are described as u32.  But that shouldn't affect the internal 
> > > U-Boot
> > > API.  I can send a patch afterwards moving the U-Boot TPM API functions 
> > > and
> > > return int.
> >
> > Well, the question is, what is the return value? If it is the actual
> > TPM return code, then u32 is (unfortunately) correct. If it is an
> > errno then it should be int. The challenge is that some code wants to
> > know about the TPM internals, special error codes, etc. so we cannot
> > easily move to errno. Is that right?
>
> Maybe, I'll have to take a closer look, but in principle I don't see why
> the internal API should return device error codes verbatim.  If we care
> about the tpm error that much we can pass a u32 * and still return an int.
> In any case as we discussed integer promotion is fine here.

If we don't return the 'real' error codes then I worry that it will be
impossible to implement certain things. If we plan to map TPM errors
to errno, and can document all the cases, perhaps that would work, 

Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Simon Glass
" properHi Heinrich,

On Thu, 16 Feb 2023 at 14:31, Heinrich Schuchardt
 wrote:
>
>
>
> On 2/16/23 21:17, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt
> >  wrote:
> >>
> >> Some boards provide main U-Boot as a dedicated partition to SPL.
> >> Currently we can define either a fixed partition number or an MBR
> >> partition type to define which partition is to be used.
> >>
> >> Partition numbers tend to conflict with established partitioning schemes
> >> of Linux distros. MBR partitioning is more and more replaced by GPT
> >> partitioning.
> >>
> >> Allow defining a partition type GUID identifying the partition to load
> >> main U-Boot from.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >> v2:
> >>  avoid if/endif in Kconfig
> >> ---
> >>   common/spl/Kconfig   | 27 ++-
> >>   common/spl/spl_mmc.c | 13 +
> >>   2 files changed, 35 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >> index 3c2af453ab..9d12b48297 100644
> >> --- a/common/spl/Kconfig
> >> +++ b/common/spl/Kconfig
> >> @@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> >>used in raw mode
> >>
> >>   config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> >> -   bool "MMC raw mode: by partition type"
> >> +   bool "MMC raw mode: by MBR partition type"
> >>  depends on DOS_PARTITION && 
> >> SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> >>  help
> >> - Use partition type for specifying U-Boot partition on MMC/SD in
> >> + Use MBR partition type for specifying U-Boot partition on MMC/SD 
> >> in
> >>raw mode. U-Boot will be loaded from the first partition of this
> >>type to be found.
> >>
> >>   config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
> >> -   hex "Partition Type on the MMC to load U-Boot from"
> >> +   hex "MBR Partition Type on the MMC to load U-Boot from"
> >>  depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> >>  help
> >> - Partition Type on the MMC to load U-Boot from, when the MMC is 
> >> being
> >> - used in raw mode.
> >> + MBR Partition Type on the MMC to load U-Boot from, when the MMC 
> >> is
> >> + being used in raw mode.
> >> +
> >> +config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> >> +   bool "MMC raw mode: GPT by partition type"
> >> +   depends on PARTITION_TYPE_GUID && 
> >> SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> >> +   help
> >> + Use GPT partition type for specifying U-Boot partition on MMC/SD 
> >> in
> >> + raw mode. U-Boot will be loaded from the first partition of this
> >> + type to be found.
> >> +
> >> +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
> >> +   string "GPT Partition Type on the MMC to load U-Boot from"
> >> +   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> >> +   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6
> >
> > What is this? Can we have a register of these hideous things and call
> > them by name?

Further, I don't see any documentation on this in U-Boot. Could you at
least add a list of these things?

> >
> >> +   help
> >> + GPT Partition Type on the MMC to load U-Boot from, when the MMC 
> >> is
> >> + being used in raw mode. The GUID must be lower case, low endian,
> >> + and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.
> >>
> >>   config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
> >>  bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
> >> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >> index e4135b2048..69bf1d6e98 100644
> >> --- a/common/spl/spl_mmc.c
> >> +++ b/common/spl/spl_mmc.c
> >> @@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
> >> spl_image_info *spl_image,
> >>  struct disk_partition info;
> >>  int err;
> >>
> >> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> >> +   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
> >> +   err = part_get_info(mmc_get_blk_desc(mmc), i, );
> >> +   if (err)
> >> +   continue;
> >> +   if (!strncmp(info.type_guid,
> >> +
> >> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
> >> +UUID_STR_LEN)) {
> >> +   partition = i;
> >> +   break;
> >> +   }
> >> +   }
> >> +#endif
> >>   #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> >>  int type_part;
> >>  /* Only support MBR so DOS_ENTRY_NUMBERS */
> >> --
> >> 2.38.1
> >>
> >
> > Is it possible to avoid using #ifdef here?
>
> Unfortunately not. Field 'type_guid' is restricted by an #ifdef. So
> unconditional compilation would fail.

Do you think it is worth adding an accessor as we have done with 

Re: [PATCH v3 03/11] core: remap: convert regmap_init_mem_plat() input to phys_addr_t

2023-02-16 Thread Simon Glass
Hi Johan,

On Thu, 16 Feb 2023 at 10:58, Johan Jonker  wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so convert regmap_init_mem_plat() input to phys_addr_t in files
> that use this function.
>
> Signed-off-by: Johan Jonker 
> Reviewed-by: Kever Yang 
> ---
>  drivers/core/regmap.c   | 2 +-
>  drivers/core/syscon-uclass.c| 2 +-
>  drivers/ram/rockchip/sdram_rk3066.c | 2 +-
>  drivers/ram/rockchip/sdram_rk3188.c | 2 +-
>  drivers/ram/rockchip/sdram_rk322x.c | 2 +-
>  drivers/ram/rockchip/sdram_rk3288.c | 2 +-
>  drivers/ram/rockchip/sdram_rk3328.c | 2 +-
>  drivers/ram/rockchip/sdram_rk3399.c | 2 +-
>  include/regmap.h| 2 +-
>  9 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index e33bb9d7..37da64b2 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -79,7 +79,7 @@ static struct regmap *regmap_alloc(int count)
>  }
>
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
> -int regmap_init_mem_plat(struct udevice *dev, fdt_val_t *reg, int count,
> +int regmap_init_mem_plat(struct udevice *dev, phys_addr_t *reg, int count,
>  struct regmap **mapp)
>  {
> struct regmap_range *range;
> diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
> index 25fdb66e..69b66773 100644
> --- a/drivers/core/syscon-uclass.c
> +++ b/drivers/core/syscon-uclass.c
> @@ -58,7 +58,7 @@ static int syscon_pre_probe(struct udevice *dev)
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
> struct syscon_base_plat *plat = dev_get_plat(dev);
>
> -   return regmap_init_mem_plat(dev, plat->reg, ARRAY_SIZE(plat->reg),
> +   return regmap_init_mem_plat(dev, (phys_addr_t *)plat->reg, 
> ARRAY_SIZE(plat->reg),
> >regmap);

That cast does not seem very safe. Should we add a new init function
with that type, instead?

Regards,
Simon


Re: [PATCH 11/13] imx8mm-mx8menlo: Drop SPL_BOARD_INIT

2023-02-16 Thread Marek Vasut

On 2/16/23 15:41, Tom Rini wrote:

On Thu, Feb 16, 2023 at 03:21:43PM +0100, Marek Vasut wrote:

On 2/16/23 15:13, Tom Rini wrote:

On Thu, Feb 16, 2023 at 03:04:35PM +0100, Marek Vasut wrote:

On 2/16/23 04:36, Tom Rini wrote:

On this platform spl_board_init is a call to arch_misc_init which is a
no-op, so drop the CONFIG options.

Cc: Marek Vasut 
Cc: Olaf Mandel 


btw. put those under --- next time, that way they don't end up in commit
message.


Er, did the kernel change expected behavior here?


Er ... wasn't that the case for like a year now ?


Is that a yes then?


I got repeated flak for sticking a wall of Cc: into the commit message 
recently, so I guess that's a yes .



Signed-off-by: Tom Rini 


If CAAM is enabled, ARCH_MISC_INIT brings up the CAAM , and this is needed
in SPL for U-Boot authentication using HABv4 . I believe that is why Verdin
spl.c calls it.


Then I'll put doing a follow-up on SPL_BOARD_INIT (which is another
option that shouldn't be directly asked, but select'd when used) for
that case. It fails to build in this series because CAAM isn't enabled
so there's no arch_misc_init.


Just call the arch_board_init unconditionally, the CAAM inside of it is
already conditional, so the compiler should inline the result if CAAM is
disabled.


It doesn't, and only maybe does with LTO. But we also shouldn't be
enabling unused hooks. It sounds like imx8m should follow the other
platforms that have an spl_board_init under arch/ ?


spl_BOARD_init shouldn't be in arch in the first place, but I think what 
needs to be done here in the long run is, set DM_FLAG_PROBE_AFTER_BIND 
on CAAM in SPL if CAAM is enabled. That can be done somewhere in 
arch/arm/mach-imx/imx8m early boot code. And then let DM bring the CAAM 
up. I think that's the way to go with cleaning up the CAAM and 
spl_board_init part, without breaking support for HABv4.


Re: [PATCH] binman: Avoid requiring a home directory on startup

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 05:12:33PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 14 Feb 2023 at 13:27, Tom Rini  wrote:
> >
> > On Tue, Feb 14, 2023 at 03:12:46PM -0500, Mike Frysinger wrote:
> > > On Tue, Feb 14, 2023 at 3:08 PM Tom Rini  wrote:
> > > > Downloading things from the internet and putting them in to the default
> > > > PATH always and forever is also kinda not great?
> > >
> > > you just described a standard distribution.  this is like literally
> > > how all of them work.  not to mention every other language-specific
> > > distro tool out there (e.g. Python pip, Perl cpan, Go, etc...).
> > >
> > > maybe you'd like more guarantees on top (e.g. signature verification)
> > > which is reasonable.
> > >
> > > but to be clear, this script is already merged & in the tree, so your
> > > feedback doesn't block this patch.
> >
> > Yes, exactly. This is a fix on top of what we do today, so it should go
> > in. But modern distributions only install signed packages, and
> > language-specific tools tend to be a hive of bad examples. Looking over
> > binman right now, I see that we're either using apt (and oh, there's
> > "aot" typo in one spot) or downloading from a known Google drive, for
> > only a few less common tools.
> >
> > So yes, I would like to see some ideas on how to improve things in the
> > future so we aren't putting the binaries somewhere that's not a default
> > (or frequently common) PATH location.
> 
> Are you thinking they should go in ~/.binman-tools or something like
> that? Then we would need to tell people to add it to their path. But
> we could make binman look there automatically.

We should document that it's where we're putting stuff, not so much
"tell" them, unless you mean as a note when downloading.  But yes,
~/.binman-tools sounds reasonable.  Maybe a flag to point elsewhere?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] binman: Avoid requiring a home directory on startup

2023-02-16 Thread Simon Glass
Hi Tom,

On Tue, 14 Feb 2023 at 13:27, Tom Rini  wrote:
>
> On Tue, Feb 14, 2023 at 03:12:46PM -0500, Mike Frysinger wrote:
> > On Tue, Feb 14, 2023 at 3:08 PM Tom Rini  wrote:
> > > Downloading things from the internet and putting them in to the default
> > > PATH always and forever is also kinda not great?
> >
> > you just described a standard distribution.  this is like literally
> > how all of them work.  not to mention every other language-specific
> > distro tool out there (e.g. Python pip, Perl cpan, Go, etc...).
> >
> > maybe you'd like more guarantees on top (e.g. signature verification)
> > which is reasonable.
> >
> > but to be clear, this script is already merged & in the tree, so your
> > feedback doesn't block this patch.
>
> Yes, exactly. This is a fix on top of what we do today, so it should go
> in. But modern distributions only install signed packages, and
> language-specific tools tend to be a hive of bad examples. Looking over
> binman right now, I see that we're either using apt (and oh, there's
> "aot" typo in one spot) or downloading from a known Google drive, for
> only a few less common tools.
>
> So yes, I would like to see some ideas on how to improve things in the
> future so we aren't putting the binaries somewhere that's not a default
> (or frequently common) PATH location.

Are you thinking they should go in ~/.binman-tools or something like
that? Then we would need to tell people to add it to their path. But
we could make binman look there automatically.

Regards,
Simon


Re: [PATCH v1 05/18] clk: rockchip: Add rk3588 clk support

2023-02-16 Thread Jonas Karlman
Hi Jagan,

On 2023-01-30 15:57, Jagan Teki wrote:
> Add clock driver support for Rockchip RK3588 SoC.
> 
> Signed-off-by: Elaine Zhang 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/clk/rockchip/Makefile |1 +
>  drivers/clk/rockchip/clk_rk3588.c | 1996 +
>  2 files changed, 1997 insertions(+)
>  create mode 100644 drivers/clk/rockchip/clk_rk3588.c
> 
> diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
> index f719f4e379..9e379cc2e3 100644
> --- a/drivers/clk/rockchip/Makefile
> +++ b/drivers/clk/rockchip/Makefile
> @@ -16,5 +16,6 @@ obj-$(CONFIG_ROCKCHIP_RK3328) += clk_rk3328.o
>  obj-$(CONFIG_ROCKCHIP_RK3368) += clk_rk3368.o
>  obj-$(CONFIG_ROCKCHIP_RK3399) += clk_rk3399.o
>  obj-$(CONFIG_ROCKCHIP_RK3568) += clk_rk3568.o
> +obj-$(CONFIG_ROCKCHIP_RK3588) += clk_rk3588.o
>  obj-$(CONFIG_ROCKCHIP_RV1108) += clk_rv1108.o
>  obj-$(CONFIG_ROCKCHIP_RV1126) += clk_rv1126.o
> diff --git a/drivers/clk/rockchip/clk_rk3588.c 
> b/drivers/clk/rockchip/clk_rk3588.c
> new file mode 100644
> index 00..b87b023bd7
> --- /dev/null
> +++ b/drivers/clk/rockchip/clk_rk3588.c
> @@ -0,0 +1,1996 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021 Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Elaine Zhang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define DIV_TO_RATE(input_rate, div) ((input_rate) / ((div) + 1))
> +
> +static struct rockchip_pll_rate_table rk3588_pll_rates[] = {
> + /* _mhz, _p, _m, _s, _k */
> + RK3588_PLL_RATE(15, 2, 250, 1, 0),
> + RK3588_PLL_RATE(12, 2, 200, 1, 0),
> + RK3588_PLL_RATE(118800, 2, 198, 1, 0),
> + RK3588_PLL_RATE(11, 3, 550, 2, 0),
> + RK3588_PLL_RATE(100800, 2, 336, 2, 0),
> + RK3588_PLL_RATE(10, 3, 500, 2, 0),
> + RK3588_PLL_RATE(9, 2, 300, 2, 0),
> + RK3588_PLL_RATE(85000, 3, 425, 2, 0),
> + RK3588_PLL_RATE(81600, 2, 272, 2, 0),
> + RK3588_PLL_RATE(786432000, 2, 262, 2, 9437),
> + RK3588_PLL_RATE(78600, 1, 131, 2, 0),
> + RK3588_PLL_RATE(722534400, 8, 963, 2, 24850),
> + RK3588_PLL_RATE(6, 2, 200, 2, 0),
> + RK3588_PLL_RATE(59400, 2, 198, 2, 0),
> + RK3588_PLL_RATE(2, 3, 400, 4, 0),
> + RK3588_PLL_RATE(1, 3, 400, 5, 0),
> + { /* sentinel */ },
> +};
> +
> +static struct rockchip_pll_clock rk3588_pll_clks[] = {
> + [B0PLL] = PLL(pll_rk3588, PLL_B0PLL, RK3588_B0_PLL_CON(0),
> +   RK3588_B0_PLL_MODE_CON, 0, 15, 0,
> +   rk3588_pll_rates),
> + [B1PLL] = PLL(pll_rk3588, PLL_B1PLL, RK3588_B1_PLL_CON(8),
> +   RK3588_B1_PLL_MODE_CON, 0, 15, 0,
> +   rk3588_pll_rates),
> + [LPLL] = PLL(pll_rk3588, PLL_LPLL, RK3588_LPLL_CON(16),
> +  RK3588_LPLL_MODE_CON, 0, 15, 0, rk3588_pll_rates),
> + [V0PLL] = PLL(pll_rk3588, PLL_V0PLL, RK3588_PLL_CON(88),
> +   RK3588_MODE_CON0, 4, 15, 0, rk3588_pll_rates),
> + [AUPLL] = PLL(pll_rk3588, PLL_AUPLL, RK3588_PLL_CON(96),
> +   RK3588_MODE_CON0, 6, 15, 0, rk3588_pll_rates),
> + [CPLL] = PLL(pll_rk3588, PLL_CPLL, RK3588_PLL_CON(104),
> +  RK3588_MODE_CON0, 8, 15, 0, rk3588_pll_rates),
> + [GPLL] = PLL(pll_rk3588, PLL_GPLL, RK3588_PLL_CON(112),
> +  RK3588_MODE_CON0, 2, 15, 0, rk3588_pll_rates),
> + [NPLL] = PLL(pll_rk3588, PLL_NPLL, RK3588_PLL_CON(120),
> +  RK3588_MODE_CON0, 0, 15, 0, rk3588_pll_rates),
> + [PPLL] = PLL(pll_rk3588, PLL_PPLL, RK3588_PMU_PLL_CON(128),
> +  RK3588_MODE_CON0, 10, 15, 0, rk3588_pll_rates),
> +};
> +
> +#ifndef CONFIG_SPL_BUILD
> +/*
> + *
> + * rational_best_approximation(31415, 1,
> + *   (1 << 8) - 1, (1 << 5) - 1, , );
> + *
> + * you may look at given_numerator as a fixed point number,
> + * with the fractional part size described in given_denominator.
> + *
> + * for theoretical background, see:
> + * http://en.wikipedia.org/wiki/Continued_fraction
> + */
> +static void rational_best_approximation(unsigned long given_numerator,
> + unsigned long given_denominator,
> + unsigned long max_numerator,
> + unsigned long max_denominator,
> + unsigned long *best_numerator,
> + unsigned long *best_denominator)
> +{
> + unsigned long n, d, n0, d0, n1, d1;
> +
> + n = given_numerator;
> + d = given_denominator;
> + n0 = 0;
> + d1 = 0;
> + n1 = 1;
> + d0 = 1;
> + for (;;) {
> + unsigned long t, a;
> +
> + if (n1 > max_numerator || d1 > max_denominator) {
> +   

Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Heinrich Schuchardt




On 2/16/23 21:17, Simon Glass wrote:

Hi Heinrich,

On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt
 wrote:


Some boards provide main U-Boot as a dedicated partition to SPL.
Currently we can define either a fixed partition number or an MBR
partition type to define which partition is to be used.

Partition numbers tend to conflict with established partitioning schemes
of Linux distros. MBR partitioning is more and more replaced by GPT
partitioning.

Allow defining a partition type GUID identifying the partition to load
main U-Boot from.

Signed-off-by: Heinrich Schuchardt 
---
v2:
 avoid if/endif in Kconfig
---
  common/spl/Kconfig   | 27 ++-
  common/spl/spl_mmc.c | 13 +
  2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 3c2af453ab..9d12b48297 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
   used in raw mode

  config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
-   bool "MMC raw mode: by partition type"
+   bool "MMC raw mode: by MBR partition type"
 depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 help
- Use partition type for specifying U-Boot partition on MMC/SD in
+ Use MBR partition type for specifying U-Boot partition on MMC/SD in
   raw mode. U-Boot will be loaded from the first partition of this
   type to be found.

  config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
-   hex "Partition Type on the MMC to load U-Boot from"
+   hex "MBR Partition Type on the MMC to load U-Boot from"
 depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
 help
- Partition Type on the MMC to load U-Boot from, when the MMC is being
- used in raw mode.
+ MBR Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   bool "MMC raw mode: GPT by partition type"
+   depends on PARTITION_TYPE_GUID && 
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   help
+ Use GPT partition type for specifying U-Boot partition on MMC/SD in
+ raw mode. U-Boot will be loaded from the first partition of this
+ type to be found.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
+   string "GPT Partition Type on the MMC to load U-Boot from"
+   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6


What is this? Can we have a register of these hideous things and call
them by name?


+   help
+ GPT Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode. The GUID must be lower case, low endian,
+ and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.

  config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
 bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b2048..69bf1d6e98 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
 struct disk_partition info;
 int err;

+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
+   err = part_get_info(mmc_get_blk_desc(mmc), i, );
+   if (err)
+   continue;
+   if (!strncmp(info.type_guid,
+
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
+UUID_STR_LEN)) {
+   partition = i;
+   break;
+   }
+   }
+#endif
  #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
 int type_part;
 /* Only support MBR so DOS_ENTRY_NUMBERS */
--
2.38.1



Is it possible to avoid using #ifdef here?


Unfortunately not. Field 'type_guid' is restricted by an #ifdef. So 
unconditional compilation would fail.




Longer term, I wonder if we can add a DT schema for all of
this...these CONFIG options for boot selection seem to be getting out
of hand!


Tom just moved a lot of constants hard coded in C code to Kconfig with a 
big effort. Now you want to move Kconfig values to hard coded constants 
in device-tree.


Running in circles does not sound like a winning strategy.

Best regards

Heinrich



Regards,
Simon


Re: [PATCH 1/2 v3] tpm: add a function that performs selftest + startup

2023-02-16 Thread Ilias Apalodimas
Hi Simon,

Apologies for the late reply.

On Tue, Feb 07, 2023 at 06:38:54AM -0700, Simon Glass wrote:
> Hi Ilias,
>
> On Mon, 6 Feb 2023 at 06:25, Ilias Apalodimas
>  wrote:
> >
> > Hi Simon,
> > On Sat, Jan 28, 2023 at 03:01:22PM -0700, Simon Glass wrote:
> > > Hi Ilias,
> > >
> > > On Thu, 26 Jan 2023 at 01:18, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > As described in [0] if a command requires use of an untested algorithm
> > > > or functional module, the TPM performs the test and then completes the
> > > > command actions.
> > > >
> > > > Since we don't check for TPM_RC_NEEDS_TEST (which is the return code of
> > > > the TPM in that case) and even if we would, it would complicate our TPM
> > > > code for no apparent reason,  add a wrapper function that performs both
> > > > the selftest and the startup sequence of the TPM.
> > > >
> > > > It's worth noting that this is implemented on TPMv2.0.  The code for
> > > > 1.2 would look similar,  but I don't have a device available to test.
> > > >
> > > > [0]
> > > > https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf
> > > > §12.3 Self-test modes
> > > >
> > > > Signed-off-by: Ilias Apalodimas 
> > > > ---
> > > > Changes since v2:
> > > > - add tpm_init() to auto start
> > > >
> > > > Changes since v1:
> > > > - Remove a superfluous if statement
> > > > - Move function comments to the header file
> > > >  include/tpm-v2.h  | 19 +++
> > > >  include/tpm_api.h |  8 
> > > >  lib/tpm-v2.c  | 24 
> > > >  lib/tpm_api.c |  8 
> > > >  4 files changed, 59 insertions(+)
> > >
> > > I think this is a good idea, but it should be implemented at the API
> > > level. Please see below.
> >
> > It is implemented at the API level.  I could try testing this in QEMU using
> > swtpm, but the driver I added for mmio is TPMv2 only.  So I don't really 
> > feel
> > comfortable adding support for a device I can't test.  If someone has a
> > tpm1.2 and is willing to test it, I can modify the patch accordingly.
>
> swtpm is a bit of a pain, as we discussed and as you are showing by
> this comment. IMO it is good enough to use the sandbox testing for
> this function. See below.
>

The comment says the exact opposite.  It never hints on any swtpm
limitations or problems.

fwiw swtpm is fine.  It even offers a socket we could hook against instead of
re-inventing the wheel with the sandbox tpm (which is missing 95% of the
tpm functionality anyway).  The reason we can't use it is that the u-boot
driver only implements 2.0.

[...]

> > > > +   rc = tpm_init(dev);
> > > > +   if (rc && rc != -EBUSY)
> > >
> > > Does that work, with rc being unsigned?
> >
> >
> > Yes integer promotion is fine here.  As long as we don't try to do anything
> > silly e.g start doing math on the result or compare it against bigger types
> > this is fine.
>
> OK
>
> > There was a patch from Sughosh in the past that you rejected and it was
> > converting enough of the TPM API return calls to int.  I think the reason
> > the API works with u32, is that the spec return codes from the device
> > itself are described as u32.  But that shouldn't affect the internal U-Boot
> > API.  I can send a patch afterwards moving the U-Boot TPM API functions and
> > return int.
>
> Well, the question is, what is the return value? If it is the actual
> TPM return code, then u32 is (unfortunately) correct. If it is an
> errno then it should be int. The challenge is that some code wants to
> know about the TPM internals, special error codes, etc. so we cannot
> easily move to errno. Is that right?

Maybe, I'll have to take a closer look, but in principle I don't see why
the internal API should return device error codes verbatim.  If we care
about the tpm error that much we can pass a u32 * and still return an int.
In any case as we discussed integer promotion is fine here.

>
> >
> > >
> > > > +   return rc;
> > > > +   rc = tpm2_self_test(dev, TPMI_YES);
> > >
> > > Can we call tpm_self_test_full() ? If not, please update the API as 
> > > needed.
> > >
> > > > +
> > > > +   if (rc == TPM2_RC_INITIALIZE) {
> > > > +   rc = tpm2_startup(dev, TPM2_SU_CLEAR);
> > >
> > > Should call tpm_startup()
> >
> >
> > Same logic applies to both of these.  Yes that makes sense to use the top
> > level API but only if we add support for 1.2 as well.  Otherwise the only
> > thing this is going to create is circular dependencies between the v2 code
> > and the API library.
>
> Then just add 1.2 support.

That doesn't make any sense and I personally don't agree with the comment.
The patch improves and fixes problems we have in TPM 2.0 which is what
(hopefully) all devices use the last couple of years.

Unfortunately I don't have the time to fix 1.2 and I don't see why this
should hinder our efforts for decent TPM2.0 support.

>
> >
> > >
> > > > +   if (rc)
> > > > + 

Re: [PATCH v2] efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX

2023-02-16 Thread Ilias Apalodimas
Hi Etienne,

On Thu, Feb 16, 2023 at 06:21:41PM +0100, Etienne Carriere wrote:
> Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
> EFI capsule reports. The config default value is 65535 as the index max
> value used before this change. Platforms with limited storage capacity
> can set a lower configuration value to prevent storage capacity
> overflow or even waste of storage space.
>
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1
> - Changed CONFIG_EFI_CAPSULE_MAX default value from 65535 to 15.
> ---
>  lib/efi_loader/Kconfig   |  8 ++
>  lib/efi_loader/efi_capsule.c | 48 +---
>  lib/efi_loader/efi_setup.c   |  7 +-
>  3 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index c56904afc2..727241dc9c 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -226,6 +226,14 @@ config EFI_CAPSULE_AUTHENTICATE
> Select this option if you want to enable capsule
> authentication
>
> +config EFI_CAPSULE_MAX
> + int "Max value for capsule index"
> + default 15
> + range 0 65535
> + help
> +   Select the max capsule index value used for capsule report
> +   variables. This value is used to create CapsuleMax variable.
> +
>  config EFI_DEVICE_PATH_TO_TEXT
>   bool "Device path to text protocol"
>   default y
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 0997cd248f..d5d3ede7ae 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -45,17 +45,7 @@ const efi_guid_t fwu_guid_os_request_fw_accept =
>  static struct efi_file_handle *bootdev_root;
>  #endif
>
> -/**
> - * get_last_capsule - get the last capsule index
> - *
> - * Retrieve the index of the capsule invoked last time from "CapsuleLast"
> - * variable.
> - *
> - * Return:
> - * * > 0 - the last capsule index invoked
> - * * 0x  - on error, or no capsule invoked yet
> - */
> -static __maybe_unused unsigned int get_last_capsule(void)
> +static __maybe_unused unsigned int get_capsule_index(const u16 
> *variable_name)
>  {
>   u16 value16[11]; /* "Capsule": non-null-terminated */
>   char value[5];
> @@ -65,7 +55,7 @@ static __maybe_unused unsigned int get_last_capsule(void)
>   int i;
>
>   size = sizeof(value16);
> - ret = efi_get_variable_int(u"CapsuleLast", _guid_capsule_report,
> + ret = efi_get_variable_int(variable_name, _guid_capsule_report,
>  NULL, , value16, NULL);

Variable name is now an argument, but the value16 size remains an array of
11 u16's.  We should test that before calling efi_get_variable_int()
although the code currently just uses 'CapsuleLast' and 'CapsuleMax'.

>   if (ret != EFI_SUCCESS || size != 22 ||
>   u16_strncmp(value16, u"Capsule", 7))
> @@ -84,6 +74,35 @@ err:
>   return index;
>  }
>

[...]

Cheers
/Ilias


Re: [PATCH 07/13] mvebe: Drop ARCH_MISC_INIT from alleycat 5

2023-02-16 Thread Chris Packham

On 16/02/23 16:36, Tom Rini wrote:
> In this platform, arch_misc_init doesn't perform any real function. The
> call to get_soc_type_rev has no lasting side effects.
>
> Cc: Chris Packham 
> Signed-off-by: Tom Rini \

A hangover from the Marvell code I started with. They've replaced it 
with an empty arch_misc_init() in their newer u-boot code but not 
selecting CONFIG_ARCH_MISC_INIT is a much better approach.

Reviewed-by: Chris Packham 

> ---
>   arch/arm/mach-mvebu/alleycat5/soc.c | 9 -
>   configs/mvebu_ac5_rd_defconfig  | 1 -
>   2 files changed, 10 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c 
> b/arch/arm/mach-mvebu/alleycat5/soc.c
> index efbef233a148..dc69f46eedb2 100644
> --- a/arch/arm/mach-mvebu/alleycat5/soc.c
> +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> @@ -287,12 +287,3 @@ int mach_cpu_init(void)
>   
>   return 0;
>   }
> -
> -int arch_misc_init(void)
> -{
> - u32 type, rev;
> -
> - get_soc_type_rev(, );
> -
> - return 0;
> -}
> diff --git a/configs/mvebu_ac5_rd_defconfig b/configs/mvebu_ac5_rd_defconfig
> index a27202eb23e2..4e66791dbda8 100644
> --- a/configs/mvebu_ac5_rd_defconfig
> +++ b/configs/mvebu_ac5_rd_defconfig
> @@ -22,7 +22,6 @@ CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
>   CONFIG_SYS_CONSOLE_INFO_QUIET=y
>   CONFIG_DISPLAY_BOARDINFO_LATE=y
>   CONFIG_ARCH_EARLY_INIT_R=y
> -CONFIG_ARCH_MISC_INIT=y
>   CONFIG_CMD_BOOTZ=y
>   CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10
>   CONFIG_CMD_MEMTEST=y

Re: [PATCH 07/13] mvebe: Drop ARCH_MISC_INIT from alleycat 5

2023-02-16 Thread Simon Glass
On Wed, 15 Feb 2023 at 20:38, Tom Rini  wrote:
>
> In this platform, arch_misc_init doesn't perform any real function. The
> call to get_soc_type_rev has no lasting side effects.
>
> Cc: Chris Packham 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-mvebu/alleycat5/soc.c | 9 -
>  configs/mvebu_ac5_rd_defconfig  | 1 -
>  2 files changed, 10 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 09/13] s5p: Remove empty arch_misc_init

2023-02-16 Thread Simon Glass
On Wed, 15 Feb 2023 at 20:39, Tom Rini  wrote:
>
> We don't need to provide an empty arch_misc_init function here, we can
> just not enable the hook.
>
> Cc: Stefan Bosch 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/s5p4418/cpu.c  | 7 ---
>  configs/s5p4418_nanopi2_defconfig | 1 -
>  2 files changed, 8 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 05/13] common: Make ARCH_EARLY_INIT_R be selected only

2023-02-16 Thread Simon Glass
On Wed, 15 Feb 2023 at 20:38, Tom Rini  wrote:
>
> As platforms which require this hook need this hook enabled, in order to
> function, or do not need this hook, it doesn't make sense to prompt the
> user. As all platforms that need this hook now select the symbol, remove
> the prompt text.
>
> Signed-off-by: Tom Rini 
> ---
>  common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 03/13] arm: zynq: Move to select'ing ARCH_EARLY_INIT_R if we have FPGA

2023-02-16 Thread Simon Glass
On Thu, 16 Feb 2023 at 02:54, Michal Simek  wrote:
>
>
>
> On 2/16/23 04:36, Tom Rini wrote:
> > The function arch_early_init_r only does anything on these platforms if
> > we have FPGA (or SPL and SPL_FPGA) enabled, so move the logic to select
> > based on that.
> >
> > Cc: Michal Simek 
> > Signed-off-by: Tom Rini 
> > ---
> >   arch/arm/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH 06/13] imx9: Remove ARCH_MISC_INIT

2023-02-16 Thread Simon Glass
On Wed, 15 Feb 2023 at 20:38, Tom Rini  wrote:
>
> We don't need an empty function, we can just not enable the hook we
> don't use.
>
> Cc: Peng Fan 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-imx/imx9/soc.c  | 5 -
>  configs/imx93_11x11_evk_defconfig | 1 -
>  2 files changed, 6 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 04/13] arm: rk3368: Select ARCH_EARLY_INIT_R when used

2023-02-16 Thread Simon Glass
On Wed, 15 Feb 2023 at 20:38, Tom Rini  wrote:
>
> On the lion and evb-px5 platforms, we need this function, so select it.
>
> Cc: Andy Yan 
> Cc: Quentin Schulz 
> Cc: Klaus Goger 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-rockchip/rk3368/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3368/Kconfig 
> b/arch/arm/mach-rockchip/rk3368/Kconfig
> index c3249a7be457..3de695186ed9 100644
> --- a/arch/arm/mach-rockchip/rk3368/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3368/Kconfig
> @@ -5,6 +5,7 @@ choice
Reviewed-by: Simon Glass 


Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Simon Glass
Hi Heinrich,

On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt
 wrote:
>
> Some boards provide main U-Boot as a dedicated partition to SPL.
> Currently we can define either a fixed partition number or an MBR
> partition type to define which partition is to be used.
>
> Partition numbers tend to conflict with established partitioning schemes
> of Linux distros. MBR partitioning is more and more replaced by GPT
> partitioning.
>
> Allow defining a partition type GUID identifying the partition to load
> main U-Boot from.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> avoid if/endif in Kconfig
> ---
>  common/spl/Kconfig   | 27 ++-
>  common/spl/spl_mmc.c | 13 +
>  2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 3c2af453ab..9d12b48297 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
>   used in raw mode
>
>  config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> -   bool "MMC raw mode: by partition type"
> +   bool "MMC raw mode: by MBR partition type"
> depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> help
> - Use partition type for specifying U-Boot partition on MMC/SD in
> + Use MBR partition type for specifying U-Boot partition on MMC/SD in
>   raw mode. U-Boot will be loaded from the first partition of this
>   type to be found.
>
>  config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
> -   hex "Partition Type on the MMC to load U-Boot from"
> +   hex "MBR Partition Type on the MMC to load U-Boot from"
> depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> help
> - Partition Type on the MMC to load U-Boot from, when the MMC is being
> - used in raw mode.
> + MBR Partition Type on the MMC to load U-Boot from, when the MMC is
> + being used in raw mode.
> +
> +config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> +   bool "MMC raw mode: GPT by partition type"
> +   depends on PARTITION_TYPE_GUID && 
> SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> +   help
> + Use GPT partition type for specifying U-Boot partition on MMC/SD in
> + raw mode. U-Boot will be loaded from the first partition of this
> + type to be found.
> +
> +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
> +   string "GPT Partition Type on the MMC to load U-Boot from"
> +   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> +   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6

What is this? Can we have a register of these hideous things and call
them by name?

> +   help
> + GPT Partition Type on the MMC to load U-Boot from, when the MMC is
> + being used in raw mode. The GUID must be lower case, low endian,
> + and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.
>
>  config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
> bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index e4135b2048..69bf1d6e98 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
> spl_image_info *spl_image,
> struct disk_partition info;
> int err;
>
> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> +   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
> +   err = part_get_info(mmc_get_blk_desc(mmc), i, );
> +   if (err)
> +   continue;
> +   if (!strncmp(info.type_guid,
> +
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
> +UUID_STR_LEN)) {
> +   partition = i;
> +   break;
> +   }
> +   }
> +#endif
>  #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> int type_part;
> /* Only support MBR so DOS_ENTRY_NUMBERS */
> --
> 2.38.1
>

Is it possible to avoid using #ifdef here?

Longer term, I wonder if we can add a DT schema for all of
this...these CONFIG options for boot selection seem to be getting out
of hand!

Regards,
Simon


Re: [PATCH v2] efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX

2023-02-16 Thread Etienne Carriere
On Thu, 16 Feb 2023 at 18:21, Etienne Carriere
 wrote:
>
> Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
> EFI capsule reports. The config default value is 65535 as the index max

I forgot to update the commit message.
I'll fix in v3.

> value used before this change. Platforms with limited storage capacity
> can set a lower configuration value to prevent storage capacity
> overflow or even waste of storage space.
>
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1
> - Changed CONFIG_EFI_CAPSULE_MAX default value from 65535 to 15.
> ---
>  lib/efi_loader/Kconfig   |  8 ++
>  lib/efi_loader/efi_capsule.c | 48 +---
>  lib/efi_loader/efi_setup.c   |  7 +-
>  3 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index c56904afc2..727241dc9c 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -226,6 +226,14 @@ config EFI_CAPSULE_AUTHENTICATE
>   Select this option if you want to enable capsule
>   authentication
>
> +config EFI_CAPSULE_MAX
> +   int "Max value for capsule index"
> +   default 15
> +   range 0 65535
> +   help
> + Select the max capsule index value used for capsule report
> + variables. This value is used to create CapsuleMax variable.
> +
>  config EFI_DEVICE_PATH_TO_TEXT
> bool "Device path to text protocol"
> default y
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 0997cd248f..d5d3ede7ae 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -45,17 +45,7 @@ const efi_guid_t fwu_guid_os_request_fw_accept =
>  static struct efi_file_handle *bootdev_root;
>  #endif
>
> -/**
> - * get_last_capsule - get the last capsule index
> - *
> - * Retrieve the index of the capsule invoked last time from "CapsuleLast"
> - * variable.
> - *
> - * Return:
> - * * > 0   - the last capsule index invoked
> - * * 0x- on error, or no capsule invoked yet
> - */
> -static __maybe_unused unsigned int get_last_capsule(void)
> +static __maybe_unused unsigned int get_capsule_index(const u16 
> *variable_name)
>  {
> u16 value16[11]; /* "Capsule": non-null-terminated */
> char value[5];
> @@ -65,7 +55,7 @@ static __maybe_unused unsigned int get_last_capsule(void)
> int i;
>
> size = sizeof(value16);
> -   ret = efi_get_variable_int(u"CapsuleLast", _guid_capsule_report,
> +   ret = efi_get_variable_int(variable_name, _guid_capsule_report,
>NULL, , value16, NULL);
> if (ret != EFI_SUCCESS || size != 22 ||
> u16_strncmp(value16, u"Capsule", 7))
> @@ -84,6 +74,35 @@ err:
> return index;
>  }
>
> +/**
> + * get_last_capsule - get the last capsule index
> + *
> + * Retrieve the index of the capsule invoked last time from "CapsuleLast"
> + * variable.
> + *
> + * Return:
> + * * > 0   - the last capsule index invoked
> + * * 0x- on error, or no capsule invoked yet
> + */
> +static __maybe_unused unsigned int get_last_capsule(void)
> +{
> +   return get_capsule_index(u"CapsuleLast");
> +}
> +
> +/**
> + * get_max_capsule - get the max capsule index
> + *
> + * Retrieve the max capsule index value from "CapsuleMax" variable.
> + *
> + * Return:
> + * * > 0   - the max capsule index
> + * * 0x- on error, or "CapsuleMax" variable does not exist
> + */
> +static __maybe_unused unsigned int get_max_capsule(void)
> +{
> +   return get_capsule_index(u"CapsuleMax");
> +}
> +
>  /**
>   * set_capsule_result - set a result variable
>   * @capsule:   Capsule
> @@ -1290,7 +1309,7 @@ efi_status_t efi_launch_capsules(void)
>  {
> struct efi_capsule_header *capsule = NULL;
> u16 **files;
> -   unsigned int nfiles, index, i;
> +   unsigned int nfiles, index, index_max, i;
> efi_status_t ret;
> bool capsule_update = true;
> bool update_status = true;
> @@ -1299,6 +1318,7 @@ efi_status_t efi_launch_capsules(void)
> if (check_run_capsules() != EFI_SUCCESS)
> return EFI_SUCCESS;
>
> +   index_max = get_max_capsule();
> index = get_last_capsule();
>
> /*
> @@ -1317,7 +1337,7 @@ efi_status_t efi_launch_capsules(void)
> /* Launch capsules */
> for (i = 0, ++index; i < nfiles; i++, index++) {
> log_debug("Applying %ls\n", files[i]);
> -   if (index > 0x)
> +   if (index > index_max)
> index = 0;
> ret = efi_capsule_read_file(files[i], );
> if (ret == EFI_SUCCESS) {
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index f0f01d3b1d..04da4cf14d 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -129,12 +129,17 @@ static efi_status_t 

[PATCH v3 11/11] mtd: nand: raw: rockchip_nfc: fix oobfree offset and description

2023-02-16 Thread Johan Jonker
The MTD framework reserves 1 or 2 bytes for the bad block marker
depending on the bus size. The rockchip_nfc driver currently only
supports a 8 bit bus, but reserves standard 2 bytes for the BBM.
The first free OOB byte is therefore OOB2 at offset 2.
Page address(PA) bytes are moved to the last 4 positions before
ECC. Update the description for U-boot.

Signed-off-by: Johan Jonker 
---
 drivers/mtd/nand/raw/rockchip_nfc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c 
b/drivers/mtd/nand/raw/rockchip_nfc.c
index ca5e7313..5ca7eeb8 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -487,10 +487,10 @@ static int rk_nfc_write_page_raw(struct mtd_info *mtd,
 *
 *BBM  OOB1 OOB2 OOB3 |..|  PA0  PA1  PA2  PA3
 *
-* The rk_nfc_ooblayout_free() function already has reserved
-* these 4 bytes with:
+* The oobfree structure already has reserved these 4 bytes
+* together with 2 bytes for BBM by reducing it's length:
 *
-* oob_region->offset = NFC_SYS_DATA_SIZE + 2;
+* oobfree[0].length = rknand->metadata_size - 
NFC_SYS_DATA_SIZE - 2;
 */
if (!i)
memcpy(rk_nfc_oob_ptr(chip, i),
@@ -867,7 +867,7 @@ static int rk_nfc_ecc_init(struct rk_nfc *nfc, struct 
nand_chip *chip)
ecc->layout->eccpos[i] = rknand->metadata_size + i;

ecc->layout->oobfree[0].length = rknand->metadata_size - 
NFC_SYS_DATA_SIZE - 2;
-   ecc->layout->oobfree[0].offset = NFC_SYS_DATA_SIZE + 2;
+   ecc->layout->oobfree[0].offset = 2;

return 0;
 }
--
2.20.1



[PATCH v3 10/11] mtd: nand: add support for the Sandisk SDTNQGAMA chip

2023-02-16 Thread Johan Jonker
Sandisk SDTNQGAMA is a 8GB size, 3.3V 8 bit chip with 16KB page size, 1KB write 
size and 40 bit ecc support

Signed-off-by: Paweł Jarosz 
Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
---
 drivers/mtd/nand/raw/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index d0cfacc6..22ea5e2f 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -48,6 +48,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{"TC58NVG6D2 64G 3.3V 8-bit",
{ .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
  SZ_8K, SZ_8K, SZ_2M, 0, 8, 640, NAND_ECC_INFO(40, SZ_1K) },
+   {"SDTNQGAMA 64G 3.3V 8-bit",
+   { .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x57} },
+ SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K) },
{"SDTNRGAMA 64G 3.3V 8-bit",
{ .id = {0x45, 0xde, 0x94, 0x93, 0x76, 0x50} },
  SZ_16K, SZ_8K, SZ_4M, 0, 6, 1280, NAND_ECC_INFO(40, SZ_1K) },
--
2.20.1



[PATCH v3 09/11] mtd: nand: raw: rockchip_nfc: add flash_node to chip structure

2023-02-16 Thread Johan Jonker
Add flash_node to the rockchip_nfc driver chip structure in order
to find the partitions in the add_mtd_partitions_of() function.

Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
Reviewed-by: Michael Trimarchi 
---
 drivers/mtd/nand/raw/rockchip_nfc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c 
b/drivers/mtd/nand/raw/rockchip_nfc.c
index ab13e52c..ca5e7313 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -934,6 +934,7 @@ static int rk_nfc_nand_chip_init(ofnode node, struct rk_nfc 
*nfc, int devnum)

nand_set_controller_data(chip, nfc);

+   chip->flash_node = node;
chip->chip_delay = NFC_RB_DELAY_US;
chip->select_chip = rk_nfc_select_chip;
chip->cmd_ctrl = rk_nfc_cmd;
--
2.20.1



[PATCH v3 08/11] mtd: nand: raw: rockchip_nfc: add layout structure

2023-02-16 Thread Johan Jonker
The MTD framework in U-boot is not identical for drivers ported
from Linux. The rockchip_nfc driver was ported with OOB ops functions
while the framework expects a layout structure per chip.
Fix by adding a structure with OOB data and remove unused functions.

Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
Reviewed-by: Michael Trimarchi 
---
 drivers/mtd/nand/raw/rockchip_nfc.c | 61 ++---
 1 file changed, 20 insertions(+), 41 deletions(-)

diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c 
b/drivers/mtd/nand/raw/rockchip_nfc.c
index a8ec6bfc..ab13e52c 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -814,47 +814,9 @@ static void rk_nfc_disable_clks(struct rk_nfc *nfc)
clk_disable_unprepare(nfc->ahb_clk);
 }

-static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section,
-struct mtd_oob_region *oob_region)
-{
-   struct nand_chip *chip = mtd_to_nand(mtd);
-   struct rk_nfc_nand_chip *rknand = rk_nfc_to_rknand(chip);
-
-   if (section)
-   return -ERANGE;
-
-   /*
-* The beginning of the OOB area stores the reserved data for the NFC,
-* the size of the reserved data is NFC_SYS_DATA_SIZE bytes.
-*/
-   oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2;
-   oob_region->offset = NFC_SYS_DATA_SIZE + 2;
-
-   return 0;
-}
-
-static int rk_nfc_ooblayout_ecc(struct mtd_info *mtd, int section,
-   struct mtd_oob_region *oob_region)
-{
-   struct nand_chip *chip = mtd_to_nand(mtd);
-   struct rk_nfc_nand_chip *rknand = rk_nfc_to_rknand(chip);
-
-   if (section)
-   return -ERANGE;
-
-   oob_region->length = mtd->oobsize - rknand->metadata_size;
-   oob_region->offset = rknand->metadata_size;
-
-   return 0;
-}
-
-static const struct mtd_ooblayout_ops rk_nfc_ooblayout_ops = {
-   .rfree = rk_nfc_ooblayout_free,
-   .ecc = rk_nfc_ooblayout_ecc,
-};
-
 static int rk_nfc_ecc_init(struct rk_nfc *nfc, struct nand_chip *chip)
 {
+   struct rk_nfc_nand_chip *rknand = rk_nfc_to_rknand(chip);
const u8 *strengths = nfc->cfg->ecc_strengths;
struct mtd_info *mtd = nand_to_mtd(chip);
struct nand_ecc_ctrl *ecc = >ecc;
@@ -892,6 +854,21 @@ static int rk_nfc_ecc_init(struct rk_nfc *nfc, struct 
nand_chip *chip)
ecc->steps = mtd->writesize / ecc->size;
ecc->bytes = DIV_ROUND_UP(ecc->strength * fls(8 * chip->ecc.size), 8);

+   if (ecc->bytes * ecc->steps > mtd->oobsize - rknand->metadata_size)
+   return -EINVAL;
+
+   ecc->layout = kzalloc(sizeof(*ecc->layout), GFP_KERNEL);
+   if (!ecc->layout)
+   return -ENOMEM;
+
+   ecc->layout->eccbytes = ecc->bytes * ecc->steps;
+
+   for (i = 0; i < ecc->layout->eccbytes; i++)
+   ecc->layout->eccpos[i] = rknand->metadata_size + i;
+
+   ecc->layout->oobfree[0].length = rknand->metadata_size - 
NFC_SYS_DATA_SIZE - 2;
+   ecc->layout->oobfree[0].offset = NFC_SYS_DATA_SIZE + 2;
+
return 0;
 }

@@ -969,7 +946,6 @@ static int rk_nfc_nand_chip_init(ofnode node, struct rk_nfc 
*nfc, int devnum)
chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
chip->options |= NAND_NO_SUBPAGE_WRITE | NAND_USE_BOUNCE_BUFFER;

-   mtd_set_ooblayout(mtd, _nfc_ooblayout_ops);
rk_nfc_hw_init(nfc);
ret = nand_scan_ident(mtd, nsels, NULL);
if (ret)
@@ -998,13 +974,16 @@ static int rk_nfc_nand_chip_init(ofnode node, struct 
rk_nfc *nfc, int devnum)

if (!nfc->page_buf) {
nfc->page_buf = kzalloc(NFC_MAX_PAGE_SIZE, GFP_KERNEL);
-   if (!nfc->page_buf)
+   if (!nfc->page_buf) {
+   kfree(ecc->layout);
return -ENOMEM;
+   }
}

if (!nfc->oob_buf) {
nfc->oob_buf = kzalloc(NFC_MAX_OOB_SIZE, GFP_KERNEL);
if (!nfc->oob_buf) {
+   kfree(ecc->layout);
kfree(nfc->page_buf);
nfc->page_buf = NULL;
return -ENOMEM;
--
2.20.1



[PATCH v3 07/11] mtd: nand: raw: rockchip_nfc: remove the compatible string "rockchip,rk3308-nfc"

2023-02-16 Thread Johan Jonker
The compatible string for rk3308 has as fallback string "rockchip,rv1108-nfc".
As there is no logic in probe priority between the SoC orientated string
and the fall back, so remove the compatible string "rockchip,rk3308-nfc"
from the driver.

Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
Reviewed-by: Michael Trimarchi 
---
 drivers/mtd/nand/raw/rockchip_nfc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c 
b/drivers/mtd/nand/raw/rockchip_nfc.c
index 5d444133..a8ec6bfc 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -1165,10 +1165,6 @@ static const struct udevice_id rk_nfc_id_table[] = {
.compatible = "rockchip,rv1108-nfc",
.data = (unsigned long)_v8_cfg
},
-   {
-   .compatible = "rockchip,rk3308-nfc",
-   .data = (unsigned long)_v8_cfg
-   },
{ /* sentinel */ }
 };

--
2.20.1



[PATCH v3 06/11] mtd: nand: raw: rockchip_nfc: use dev_read_addr_ptr

2023-02-16 Thread Johan Jonker
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expext 64-bit data from the device tree parser,
so use dev_read_addr_ptr in the rockchip_nfc.c file.

Signed-off-by: Johan Jonker 
---
 drivers/mtd/nand/raw/rockchip_nfc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c 
b/drivers/mtd/nand/raw/rockchip_nfc.c
index d016d255..5d444133 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -1180,9 +1180,9 @@ static int rk_nfc_probe(struct udevice *dev)
nfc->cfg = (void *)dev_get_driver_data(dev);
nfc->dev = dev;

-   nfc->regs = (void *)dev_read_addr(dev);
-   if (IS_ERR(nfc->regs)) {
-   ret = PTR_ERR(nfc->regs);
+   nfc->regs = dev_read_addr_ptr(dev);
+   if (!nfc->regs) {
+   ret = -ENODATA;
goto release_nfc;
}

--
2.20.1



[PATCH v3 05/11] rockchip: timer: dw-apb-timer: convert dev_read_addr output to phys_addr_t

2023-02-16 Thread Johan Jonker
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so convert dev_read_addr output to phys_addr_t in the
dw-apb-timer.c file.

Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
---
 drivers/timer/dw-apb-timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/timer/dw-apb-timer.c b/drivers/timer/dw-apb-timer.c
index 10f0a9f6..f55a3c54 100644
--- a/drivers/timer/dw-apb-timer.c
+++ b/drivers/timer/dw-apb-timer.c
@@ -23,7 +23,7 @@
 #define DW_APB_CTRL0x8

 struct dw_apb_timer_priv {
-   fdt_addr_t regs;
+   phys_addr_t regs;
struct reset_ctl_bulk resets;
 };

@@ -92,7 +92,7 @@ static int dw_apb_timer_of_to_plat(struct udevice *dev)
if (CONFIG_IS_ENABLED(OF_REAL)) {
struct dw_apb_timer_priv *priv = dev_get_priv(dev);

-   priv->regs = dev_read_addr(dev);
+   priv->regs = (phys_addr_t)dev_read_addr(dev);
}

return 0;
--
2.20.1



[PATCH v3 04/11] rockchip: adc: rockchip-saradc: use dev_read_addr_ptr

2023-02-16 Thread Johan Jonker
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expext 64-bit data from the device tree parser,
so use dev_read_addr_ptr in the rockchip-saradc.c file.

Signed-off-by: Johan Jonker 
---
 drivers/adc/rockchip-saradc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/adc/rockchip-saradc.c b/drivers/adc/rockchip-saradc.c
index 760f8fe6..de9298a2 100644
--- a/drivers/adc/rockchip-saradc.c
+++ b/drivers/adc/rockchip-saradc.c
@@ -145,8 +145,8 @@ int rockchip_saradc_of_to_plat(struct udevice *dev)
struct rockchip_saradc_data *data;

data = (struct rockchip_saradc_data *)dev_get_driver_data(dev);
-   priv->regs = (struct rockchip_saradc_regs *)dev_read_addr(dev);
-   if (priv->regs == (struct rockchip_saradc_regs *)FDT_ADDR_T_NONE) {
+   priv->regs = (struct rockchip_saradc_regs *)dev_read_addr_ptr(dev);
+   if (!priv->regs) {
pr_err("Dev: %s - can't get address!", dev->name);
return -ENODATA;
}
--
2.20.1



[PATCH v3 03/11] core: remap: convert regmap_init_mem_plat() input to phys_addr_t

2023-02-16 Thread Johan Jonker
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so convert regmap_init_mem_plat() input to phys_addr_t in files
that use this function.

Signed-off-by: Johan Jonker 
Reviewed-by: Kever Yang 
---
 drivers/core/regmap.c   | 2 +-
 drivers/core/syscon-uclass.c| 2 +-
 drivers/ram/rockchip/sdram_rk3066.c | 2 +-
 drivers/ram/rockchip/sdram_rk3188.c | 2 +-
 drivers/ram/rockchip/sdram_rk322x.c | 2 +-
 drivers/ram/rockchip/sdram_rk3288.c | 2 +-
 drivers/ram/rockchip/sdram_rk3328.c | 2 +-
 drivers/ram/rockchip/sdram_rk3399.c | 2 +-
 include/regmap.h| 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index e33bb9d7..37da64b2 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -79,7 +79,7 @@ static struct regmap *regmap_alloc(int count)
 }

 #if CONFIG_IS_ENABLED(OF_PLATDATA)
-int regmap_init_mem_plat(struct udevice *dev, fdt_val_t *reg, int count,
+int regmap_init_mem_plat(struct udevice *dev, phys_addr_t *reg, int count,
 struct regmap **mapp)
 {
struct regmap_range *range;
diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
index 25fdb66e..69b66773 100644
--- a/drivers/core/syscon-uclass.c
+++ b/drivers/core/syscon-uclass.c
@@ -58,7 +58,7 @@ static int syscon_pre_probe(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct syscon_base_plat *plat = dev_get_plat(dev);

-   return regmap_init_mem_plat(dev, plat->reg, ARRAY_SIZE(plat->reg),
+   return regmap_init_mem_plat(dev, (phys_addr_t *)plat->reg, 
ARRAY_SIZE(plat->reg),
>regmap);
 #else
return regmap_init_mem(dev_ofnode(dev), >regmap);
diff --git a/drivers/ram/rockchip/sdram_rk3066.c 
b/drivers/ram/rockchip/sdram_rk3066.c
index a2425f22..9bb26b64 100644
--- a/drivers/ram/rockchip/sdram_rk3066.c
+++ b/drivers/ram/rockchip/sdram_rk3066.c
@@ -801,7 +801,7 @@ static int rk3066_dmc_conv_of_plat(struct udevice *dev)
memcpy(>base, of_plat->rockchip_sdram_params, sizeof(plat->base));
/* RK3066 supports dual-channel, set default channel num to 2. */
plat->num_channels = 1;
-   ret = regmap_init_mem_plat(dev, of_plat->reg,
+   ret = regmap_init_mem_plat(dev, (phys_addr_t *)of_plat->reg,
   ARRAY_SIZE(of_plat->reg) / 2, >map);
if (ret)
return ret;
diff --git a/drivers/ram/rockchip/sdram_rk3188.c 
b/drivers/ram/rockchip/sdram_rk3188.c
index 272b1b2d..1838985c 100644
--- a/drivers/ram/rockchip/sdram_rk3188.c
+++ b/drivers/ram/rockchip/sdram_rk3188.c
@@ -867,7 +867,7 @@ static int conv_of_plat(struct udevice *dev)
memcpy(>base, of_plat->rockchip_sdram_params, sizeof(plat->base));
/* rk3188 supports dual-channel, set default channel num to 2 */
plat->num_channels = 1;
-   ret = regmap_init_mem_plat(dev, of_plat->reg,
+   ret = regmap_init_mem_plat(dev, (phys_addr_t *)of_plat->reg,
   ARRAY_SIZE(of_plat->reg) / 2, >map);
if (ret)
return ret;
diff --git a/drivers/ram/rockchip/sdram_rk322x.c 
b/drivers/ram/rockchip/sdram_rk322x.c
index 1b204fb5..33599dc5 100644
--- a/drivers/ram/rockchip/sdram_rk322x.c
+++ b/drivers/ram/rockchip/sdram_rk322x.c
@@ -769,7 +769,7 @@ static int conv_of_plat(struct udevice *dev)
memcpy(>base, of_plat->rockchip_sdram_params, sizeof(plat->base));

plat->num_channels = 1;
-   ret = regmap_init_mem_plat(dev, of_plat->reg,
+   ret = regmap_init_mem_plat(dev, (phys_addr_t *)of_plat->reg,
   ARRAY_SIZE(of_plat->reg) / 2, >map);
if (ret)
return ret;
diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
b/drivers/ram/rockchip/sdram_rk3288.c
index 83778ad1..1a548da5 100644
--- a/drivers/ram/rockchip/sdram_rk3288.c
+++ b/drivers/ram/rockchip/sdram_rk3288.c
@@ -1029,7 +1029,7 @@ static int conv_of_plat(struct udevice *dev)
memcpy(>base, of_plat->rockchip_sdram_params, sizeof(plat->base));
/* Rk3288 supports dual-channel, set default channel num to 2 */
plat->num_channels = 2;
-   ret = regmap_init_mem_plat(dev, of_plat->reg,
+   ret = regmap_init_mem_plat(dev, (phys_addr_t *)of_plat->reg,
   ARRAY_SIZE(of_plat->reg) / 2, >map);
if (ret)
return ret;
diff --git a/drivers/ram/rockchip/sdram_rk3328.c 
b/drivers/ram/rockchip/sdram_rk3328.c
index b511c6bf..2427efe0 100644
--- a/drivers/ram/rockchip/sdram_rk3328.c
+++ b/drivers/ram/rockchip/sdram_rk3328.c
@@ -54,7 +54,7 @@ static int conv_of_plat(struct udevice *dev)
struct dtd_rockchip_rk3328_dmc *dtplat = >dtplat;
int ret;

-   ret = regmap_init_mem_plat(dev, dtplat->reg,
+   ret = regmap_init_mem_plat(dev, (phys_addr_t *)dtplat->reg,

[PATCH v3 02/11] include: dm: ofnode: fix headers

2023-02-16 Thread Johan Jonker
When fdt_addr_t and phys_addr_t are split it turns out that
the header don't match the functions, so fix the headers.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 
Reviewed-by: Kever Yang 
---
 include/dm/ofnode.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index fa986560..287b0c35 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -678,8 +678,8 @@ int ofnode_read_size(ofnode node, const char *propname);
  * @size: Pointer to size of the address
  * Return: address, or FDT_ADDR_T_NONE if not present or invalid
  */
-phys_addr_t ofnode_get_addr_size_index(ofnode node, int index,
-  fdt_size_t *size);
+fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index,
+ fdt_size_t *size);

 /**
  * ofnode_get_addr_size_index_notrans() - get an address/size from a node
@@ -695,8 +695,8 @@ phys_addr_t ofnode_get_addr_size_index(ofnode node, int 
index,
  * @size: Pointer to size of the address
  * Return: address, or FDT_ADDR_T_NONE if not present or invalid
  */
-phys_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index,
-  fdt_size_t *size);
+fdt_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index,
+ fdt_size_t *size);

 /**
  * ofnode_get_addr_index() - get an address from a node
@@ -707,7 +707,7 @@ phys_addr_t ofnode_get_addr_size_index_notrans(ofnode node, 
int index,
  * @index: Index of address to read (0 for first)
  * Return: address, or FDT_ADDR_T_NONE if not present or invalid
  */
-phys_addr_t ofnode_get_addr_index(ofnode node, int index);
+fdt_addr_t ofnode_get_addr_index(ofnode node, int index);

 /**
  * ofnode_get_addr() - get an address from a node
@@ -717,7 +717,7 @@ phys_addr_t ofnode_get_addr_index(ofnode node, int index);
  * @node: node to read from
  * Return: address, or FDT_ADDR_T_NONE if not present or invalid
  */
-phys_addr_t ofnode_get_addr(ofnode node);
+fdt_addr_t ofnode_get_addr(ofnode node);

 /**
  * ofnode_get_size() - get size from a node
@@ -1055,8 +1055,8 @@ const void *ofprop_get_property(const struct ofprop *prop,
  * @sizep: place to put size value (on success)
  * Return: address value, or FDT_ADDR_T_NONE on error
  */
-phys_addr_t ofnode_get_addr_size(ofnode node, const char *propname,
-phys_size_t *sizep);
+fdt_addr_t ofnode_get_addr_size(ofnode node, const char *propname,
+   fdt_size_t *sizep);

 /**
  * ofnode_read_u8_array_ptr() - find an 8-bit array
--
2.20.1



[PATCH v3 01/11] include: fdtdec: decouple fdt_addr_t and phys_addr_t size

2023-02-16 Thread Johan Jonker
The DT specification supports CPUs with both 32-bit and 64-bit addressing
capabilities. In U-boot the fdt_addr_t and phys_addr_t size are coupled
by a typedef. The MTD NAND drivers for 32-bit CPU's can describe partitions
with a 64-bit reg property. These partitions synced from Linux end up with
the wrong offset and sizes when only the lower 32-bit is passed.
Decouple the fdt_addr_t and phys_addr_t size as they don't necessary
match.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 
Reviewed-by: Kever Yang 
---

Changed V2:
  reword

---

Note:
  Most drivers still assume that FDT and CPU capabilities are identical.
  In order to use these variables a cast is needed.
---
 Kconfig  |  8 
 include/fdtdec.h | 13 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/Kconfig b/Kconfig
index a75cce7e..7697dade 100644
--- a/Kconfig
+++ b/Kconfig
@@ -422,11 +422,19 @@ endif # EXPERT

 config PHYS_64BIT
bool "64bit physical address support"
+   select FDT_64BIT
help
  Say Y here to support 64bit physical memory address.
  This can be used not only for 64bit SoCs, but also for
  large physical address extension on 32bit SoCs.

+config FDT_64BIT
+   bool "64bit fdt address support"
+   help
+ Say Y here to support 64bit fdt addresses.
+ This can be used not only for 64bit SoCs, but also
+ for large address extensions on 32bit SoCs.
+
 config HAS_ROM
bool
select BINMAN
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 12355afd..af29ac0c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -18,15 +18,18 @@
 #include 

 /*
- * A typedef for a physical address. Note that fdt data is always big
+ * Support for 64bit fdt addresses.
+ * This can be used not only for 64bit SoCs, but also
+ * for large address extensions on 32bit SoCs.
+ * Note that fdt data is always big
  * endian even on a litle endian machine.
  */
-typedef phys_addr_t fdt_addr_t;
-typedef phys_size_t fdt_size_t;

 #define FDT_SIZE_T_NONE (-1U)

-#ifdef CONFIG_PHYS_64BIT
+#ifdef CONFIG_FDT_64BIT
+typedef u64 fdt_addr_t;
+typedef u64 fdt_size_t;
 #define FDT_ADDR_T_NONE ((ulong)(-1))

 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
@@ -35,6 +38,8 @@ typedef phys_size_t fdt_size_t;
 #define cpu_to_fdt_size(reg) cpu_to_be64(reg)
 typedef fdt64_t fdt_val_t;
 #else
+typedef u32 fdt_addr_t;
+typedef u32 fdt_size_t;
 #define FDT_ADDR_T_NONE (-1U)

 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
--
2.20.1



[PATCH v3 00/11] Fixes for Rockchip NFC driver part 1

2023-02-16 Thread Johan Jonker
This serie contains fixes for the Rockchip NFC driver,
which was ported to U-boot and merged with little review
and testing it seems.
Part 1 aims at passing the probe function without errors.

Fixed are:
  64bit FDT parsing
  compatible string removal
  add missing layout structure
  add missing flash_node pointer
  add missing chip ID

Changed V3:
  use dev_read_addr_ptr
  fix oobfree

Johan Jonker (10):
  include: fdtdec: decouple fdt_addr_t and phys_addr_t size
  include: dm: ofnode: fix headers
  core: remap: convert regmap_init_mem_plat() input to phys_addr_t
  rockchip: adc: rockchip-saradc: use dev_read_addr_ptr
  rockchip: timer: dw-apb-timer: convert dev_read_addr output to
phys_addr_t
  mtd: nand: raw: rockchip_nfc: use dev_read_addr_ptr
  mtd: nand: raw: rockchip_nfc: remove the compatible string
"rockchip,rk3308-nfc"
  mtd: nand: raw: rockchip_nfc: add layout structure
  mtd: nand: raw: rockchip_nfc: add flash_node to chip structure
  mtd: nand: raw: rockchip_nfc: fix oobfree offset and description

Paweł Jarosz (1):
  mtd: nand: add support for the Sandisk SDTNQGAMA chip

 Kconfig |  8 +++
 drivers/adc/rockchip-saradc.c   |  4 +-
 drivers/core/regmap.c   |  2 +-
 drivers/core/syscon-uclass.c|  2 +-
 drivers/mtd/nand/raw/nand_ids.c |  3 ++
 drivers/mtd/nand/raw/rockchip_nfc.c | 78 ++---
 drivers/ram/rockchip/sdram_rk3066.c |  2 +-
 drivers/ram/rockchip/sdram_rk3188.c |  2 +-
 drivers/ram/rockchip/sdram_rk322x.c |  2 +-
 drivers/ram/rockchip/sdram_rk3288.c |  2 +-
 drivers/ram/rockchip/sdram_rk3328.c |  2 +-
 drivers/ram/rockchip/sdram_rk3399.c |  2 +-
 drivers/timer/dw-apb-timer.c|  4 +-
 include/dm/ofnode.h | 16 +++---
 include/fdtdec.h| 13 +++--
 include/regmap.h|  2 +-
 16 files changed, 68 insertions(+), 76 deletions(-)

--
2.20.1



Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 06:19:11PM +0100, Heinrich Schuchardt wrote:
> 
> 
> On 2/16/23 18:01, Tom Rini wrote:
> > On Thu, Feb 16, 2023 at 04:29:56PM +0100, Heinrich Schuchardt wrote:
> > 
> > > Some boards provide main U-Boot as a dedicated partition to SPL.
> > > Currently we can define either a fixed partition number or an MBR
> > > partition type to define which partition is to be used.
> > > 
> > > Partition numbers tend to conflict with established partitioning schemes
> > > of Linux distros. MBR partitioning is more and more replaced by GPT
> > > partitioning.
> > > 
> > > Allow defining a partition type GUID identifying the partition to load
> > > main U-Boot from.
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > [snip]
> > > +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
> > > + string "GPT Partition Type on the MMC to load U-Boot from"
> > > + depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> > > + default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6
> > 
> > Is there a reason to use any other GUID value here? If not, just define,
> > or use it directly with a comment.  If there is a reason for other
> > values to be used:
> 
> Board vendors already differ in the partition GUIDs they use, e.g.
> 
> SiFive:
> SPL: 5B193300-FC78-40CD-8002-E86C45580B47
> Main U-Boot: 2E54B353-1271-4842-806F-E436D6AF6985
> 
> StarFive
> SPL: 2E54B353-1271-4842-806F-E436D6AF6985 (sic)
> 
> Microchip Icicle Board:
> SPL: 21686148-6449-6E6F-744E-656564454649
> 
> Using unique IDs per board allow to create SD card images where U-Boot for
> multiple boards is installed in parallel:
> 
> The boot ROM will select the board specific SPL via a unique ID and then SPL
> will use another unique ID to load the matching main U-Boot.
> 
> I only added a default value here to provide a formatting sample.

Thanks for elaborating.  It might be helpful to put something in a
follow-up patch about these use cases under doc/

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2] efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX

2023-02-16 Thread Etienne Carriere
Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
EFI capsule reports. The config default value is 65535 as the index max
value used before this change. Platforms with limited storage capacity
can set a lower configuration value to prevent storage capacity
overflow or even waste of storage space.

Signed-off-by: Etienne Carriere 
---
Changes since v1
- Changed CONFIG_EFI_CAPSULE_MAX default value from 65535 to 15.
---
 lib/efi_loader/Kconfig   |  8 ++
 lib/efi_loader/efi_capsule.c | 48 +---
 lib/efi_loader/efi_setup.c   |  7 +-
 3 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c56904afc2..727241dc9c 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -226,6 +226,14 @@ config EFI_CAPSULE_AUTHENTICATE
  Select this option if you want to enable capsule
  authentication
 
+config EFI_CAPSULE_MAX
+   int "Max value for capsule index"
+   default 15
+   range 0 65535
+   help
+ Select the max capsule index value used for capsule report
+ variables. This value is used to create CapsuleMax variable.
+
 config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 0997cd248f..d5d3ede7ae 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -45,17 +45,7 @@ const efi_guid_t fwu_guid_os_request_fw_accept =
 static struct efi_file_handle *bootdev_root;
 #endif
 
-/**
- * get_last_capsule - get the last capsule index
- *
- * Retrieve the index of the capsule invoked last time from "CapsuleLast"
- * variable.
- *
- * Return:
- * * > 0   - the last capsule index invoked
- * * 0x- on error, or no capsule invoked yet
- */
-static __maybe_unused unsigned int get_last_capsule(void)
+static __maybe_unused unsigned int get_capsule_index(const u16 *variable_name)
 {
u16 value16[11]; /* "Capsule": non-null-terminated */
char value[5];
@@ -65,7 +55,7 @@ static __maybe_unused unsigned int get_last_capsule(void)
int i;
 
size = sizeof(value16);
-   ret = efi_get_variable_int(u"CapsuleLast", _guid_capsule_report,
+   ret = efi_get_variable_int(variable_name, _guid_capsule_report,
   NULL, , value16, NULL);
if (ret != EFI_SUCCESS || size != 22 ||
u16_strncmp(value16, u"Capsule", 7))
@@ -84,6 +74,35 @@ err:
return index;
 }
 
+/**
+ * get_last_capsule - get the last capsule index
+ *
+ * Retrieve the index of the capsule invoked last time from "CapsuleLast"
+ * variable.
+ *
+ * Return:
+ * * > 0   - the last capsule index invoked
+ * * 0x- on error, or no capsule invoked yet
+ */
+static __maybe_unused unsigned int get_last_capsule(void)
+{
+   return get_capsule_index(u"CapsuleLast");
+}
+
+/**
+ * get_max_capsule - get the max capsule index
+ *
+ * Retrieve the max capsule index value from "CapsuleMax" variable.
+ *
+ * Return:
+ * * > 0   - the max capsule index
+ * * 0x- on error, or "CapsuleMax" variable does not exist
+ */
+static __maybe_unused unsigned int get_max_capsule(void)
+{
+   return get_capsule_index(u"CapsuleMax");
+}
+
 /**
  * set_capsule_result - set a result variable
  * @capsule:   Capsule
@@ -1290,7 +1309,7 @@ efi_status_t efi_launch_capsules(void)
 {
struct efi_capsule_header *capsule = NULL;
u16 **files;
-   unsigned int nfiles, index, i;
+   unsigned int nfiles, index, index_max, i;
efi_status_t ret;
bool capsule_update = true;
bool update_status = true;
@@ -1299,6 +1318,7 @@ efi_status_t efi_launch_capsules(void)
if (check_run_capsules() != EFI_SUCCESS)
return EFI_SUCCESS;
 
+   index_max = get_max_capsule();
index = get_last_capsule();
 
/*
@@ -1317,7 +1337,7 @@ efi_status_t efi_launch_capsules(void)
/* Launch capsules */
for (i = 0, ++index; i < nfiles; i++, index++) {
log_debug("Applying %ls\n", files[i]);
-   if (index > 0x)
+   if (index > index_max)
index = 0;
ret = efi_capsule_read_file(files[i], );
if (ret == EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index f0f01d3b1d..04da4cf14d 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -129,12 +129,17 @@ static efi_status_t efi_init_capsule(void)
efi_status_t ret = EFI_SUCCESS;
 
if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)) {
+   u16 var_name16[12];
+
+   efi_create_indexed_name(var_name16, sizeof(var_name16),
+   "Capsule", CONFIG_EFI_CAPSULE_MAX);
+
ret = efi_set_variable_int(u"CapsuleMax",

Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Heinrich Schuchardt




On 2/16/23 18:01, Tom Rini wrote:

On Thu, Feb 16, 2023 at 04:29:56PM +0100, Heinrich Schuchardt wrote:


Some boards provide main U-Boot as a dedicated partition to SPL.
Currently we can define either a fixed partition number or an MBR
partition type to define which partition is to be used.

Partition numbers tend to conflict with established partitioning schemes
of Linux distros. MBR partitioning is more and more replaced by GPT
partitioning.

Allow defining a partition type GUID identifying the partition to load
main U-Boot from.

Signed-off-by: Heinrich Schuchardt 

[snip]

+config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
+   string "GPT Partition Type on the MMC to load U-Boot from"
+   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6


Is there a reason to use any other GUID value here? If not, just define,
or use it directly with a comment.  If there is a reason for other
values to be used:


Board vendors already differ in the partition GUIDs they use, e.g.

SiFive:
SPL: 5B193300-FC78-40CD-8002-E86C45580B47
Main U-Boot: 2E54B353-1271-4842-806F-E436D6AF6985

StarFive
SPL: 2E54B353-1271-4842-806F-E436D6AF6985 (sic)

Microchip Icicle Board:
SPL: 21686148-6449-6E6F-744E-656564454649

Using unique IDs per board allow to create SD card images where U-Boot 
for multiple boards is installed in parallel:


The boot ROM will select the board specific SPL via a unique ID and then 
SPL will use another unique ID to load the matching main U-Boot.


I only added a default value here to provide a formatting sample.

Best regards

Heinrich



Reviewed-by: Tom Rini 



Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 04:29:56PM +0100, Heinrich Schuchardt wrote:

> Some boards provide main U-Boot as a dedicated partition to SPL.
> Currently we can define either a fixed partition number or an MBR
> partition type to define which partition is to be used.
> 
> Partition numbers tend to conflict with established partitioning schemes
> of Linux distros. MBR partitioning is more and more replaced by GPT
> partitioning.
> 
> Allow defining a partition type GUID identifying the partition to load
> main U-Boot from.
> 
> Signed-off-by: Heinrich Schuchardt 
[snip]
> +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
> + string "GPT Partition Type on the MMC to load U-Boot from"
> + depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> + default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6

Is there a reason to use any other GUID value here? If not, just define,
or use it directly with a comment.  If there is a reason for other
values to be used:

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX

2023-02-16 Thread Heinrich Schuchardt

On 2/16/23 17:30, Etienne Carriere wrote:

Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
EFI capsule reports. The config default value is 65535 as the index max
value used before this change. Platforms with limited storage capacity
can set a lower configuration value to prevent storage capacity
overflow or even waste of storage space.

Signed-off-by: Etienne Carriere 
---
  lib/efi_loader/Kconfig   |  8 ++
  lib/efi_loader/efi_capsule.c | 48 +---
  lib/efi_loader/efi_setup.c   |  7 +-
  3 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c56904afc2..69bb66e09c 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -226,6 +226,14 @@ config EFI_CAPSULE_AUTHENTICATE
  Select this option if you want to enable capsule
  authentication

+config EFI_CAPSULE_MAX
+   int "Max value for capsule index"
+   default 65535


This number of variables does not fit into any variable store.
CONFIG_EFI_VAR_BUF_SIZE defaults to 16 KiB. A maximum of 16 coexisting
Capsule variables would be a reasonable number. As there seems to be
no process that deletes Capsule, please, default to 15.

Best regards

Heinrich



+   range 0 65535
+   help
+ Select the max capsule index value used for capsule report
+ variables. This value is used to create CapsuleMax variable.
+
  config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 0997cd248f..d5d3ede7ae 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -45,17 +45,7 @@ const efi_guid_t fwu_guid_os_request_fw_accept =
  static struct efi_file_handle *bootdev_root;
  #endif

-/**
- * get_last_capsule - get the last capsule index
- *
- * Retrieve the index of the capsule invoked last time from "CapsuleLast"
- * variable.
- *
- * Return:
- * * > 0- the last capsule index invoked
- * * 0x- on error, or no capsule invoked yet
- */
-static __maybe_unused unsigned int get_last_capsule(void)
+static __maybe_unused unsigned int get_capsule_index(const u16 *variable_name)
  {
u16 value16[11]; /* "Capsule": non-null-terminated */
char value[5];
@@ -65,7 +55,7 @@ static __maybe_unused unsigned int get_last_capsule(void)
int i;

size = sizeof(value16);
-   ret = efi_get_variable_int(u"CapsuleLast", _guid_capsule_report,
+   ret = efi_get_variable_int(variable_name, _guid_capsule_report,
   NULL, , value16, NULL);
if (ret != EFI_SUCCESS || size != 22 ||
u16_strncmp(value16, u"Capsule", 7))
@@ -84,6 +74,35 @@ err:
return index;
  }

+/**
+ * get_last_capsule - get the last capsule index
+ *
+ * Retrieve the index of the capsule invoked last time from "CapsuleLast"
+ * variable.
+ *
+ * Return:
+ * * > 0- the last capsule index invoked
+ * * 0x- on error, or no capsule invoked yet
+ */
+static __maybe_unused unsigned int get_last_capsule(void)
+{
+   return get_capsule_index(u"CapsuleLast");
+}
+
+/**
+ * get_max_capsule - get the max capsule index
+ *
+ * Retrieve the max capsule index value from "CapsuleMax" variable.
+ *
+ * Return:
+ * * > 0- the max capsule index
+ * * 0x- on error, or "CapsuleMax" variable does not exist
+ */
+static __maybe_unused unsigned int get_max_capsule(void)
+{
+   return get_capsule_index(u"CapsuleMax");
+}
+
  /**
   * set_capsule_result - set a result variable
   * @capsule:  Capsule
@@ -1290,7 +1309,7 @@ efi_status_t efi_launch_capsules(void)
  {
struct efi_capsule_header *capsule = NULL;
u16 **files;
-   unsigned int nfiles, index, i;
+   unsigned int nfiles, index, index_max, i;
efi_status_t ret;
bool capsule_update = true;
bool update_status = true;
@@ -1299,6 +1318,7 @@ efi_status_t efi_launch_capsules(void)
if (check_run_capsules() != EFI_SUCCESS)
return EFI_SUCCESS;

+   index_max = get_max_capsule();
index = get_last_capsule();

/*
@@ -1317,7 +1337,7 @@ efi_status_t efi_launch_capsules(void)
/* Launch capsules */
for (i = 0, ++index; i < nfiles; i++, index++) {
log_debug("Applying %ls\n", files[i]);
-   if (index > 0x)
+   if (index > index_max)
index = 0;
ret = efi_capsule_read_file(files[i], );
if (ret == EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index f0f01d3b1d..04da4cf14d 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -129,12 +129,17 @@ static efi_status_t efi_init_capsule(void)
efi_status_t ret = EFI_SUCCESS;

if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)) {
+

Re: [Patch] net: dwc_eth_qos - works with fixed-phy

2023-02-16 Thread Nicole Battenfeld


Am 16.02.23 um 02:39 schrieb Marek Vasut:

On 2/15/23 17:16, Elmar Psilog wrote:

Let the EQoS in imx8mp handle fixed-phy too.
Without that patch it lost track to the node to scan
speed and duplex.
Patch was created by Marek Vasut, just tested by me.

Signed-off-by: Elmar Psilog 
---
drivers/net/dwc_eth_qos.c
1 file changed


If you were to use 'git format-patch' and 'git send-email', those 
tools would generate the correct Subject and diffstat etc. for you. 
Also have a look at scripts/checkpatch.pl to validate whether a patch 
is correct.



diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index afc47b56ff..10915d8e47 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -785,9 +785,21 @@ static int eqos_start(struct udevice *dev)
  */
 if (!eqos->phy) {
 int addr = -1;
-   addr = eqos_get_phy_addr(eqos, dev);
-   eqos->phy = phy_connect(eqos->mii, addr, dev,
- eqos->config->interface(dev));
+   ofnode fixed_node;
+
+   if (IS_ENABLED(CONFIG_PHY_FIXED)) {
+   fixed_node = 
ofnode_find_subnode(dev_ofnode(dev),

+   "fixed-link");
+   if (ofnode_valid(fixed_node)) {
+   eqos->phy =
fixed_phy_create(dev_ofnode(dev));
+   eqos->phy_of_node = fixed_node;
+   }
+   }
+   if (!eqos->phy) {
+   addr = eqos_get_phy_addr(eqos, dev);
+   eqos->phy = phy_connect(eqos->mii, addr, dev,
eqos->config->interface(dev));
+   }
+
 if (!eqos->phy) {
 pr_err("phy_connect() failed");
 goto err_stop_resets;


+CC Ramon the network maintainer .



New attempt: used script to check and fix and used git format-patch.

Also base is latest trunk, not v2023.1 as before.

Hope this fits your needs, otherwise I afraid I need detailed instruction.

--
 drivers/net/dwc_eth_qos.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 112deb546d..d04362d6c6 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -788,9 +788,21 @@ static int eqos_start(struct udevice *dev)
  */
 if (!eqos->phy) {
     int addr = -1;
-        addr = eqos_get_phy_addr(eqos, dev);
-        eqos->phy = phy_connect(eqos->mii, addr, dev,
-                    eqos->config->interface(dev));
+        ofnode fixed_node;
+
+        if (IS_ENABLED(CONFIG_PHY_FIXED)) {
+            fixed_node = ofnode_find_subnode(dev_ofnode(dev), 
"fixed-link");

+            if (ofnode_valid(fixed_node)) {
+                eqos->phy = fixed_phy_create(dev_ofnode(dev));
+                eqos->phy_of_node = fixed_node;
+            }
+        }
+
+        if (!eqos->phy) {
+            addr = eqos_get_phy_addr(eqos, dev);
+            eqos->phy = phy_connect(eqos->mii, addr, dev, 
eqos->config->interface(dev));

+        }
+
     if (!eqos->phy) {
         pr_err("phy_connect() failed");
         goto err_stop_resets;
--
2.25.1



[PATCH] efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX

2023-02-16 Thread Etienne Carriere
Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
EFI capsule reports. The config default value is 65535 as the index max
value used before this change. Platforms with limited storage capacity
can set a lower configuration value to prevent storage capacity
overflow or even waste of storage space.

Signed-off-by: Etienne Carriere 
---
 lib/efi_loader/Kconfig   |  8 ++
 lib/efi_loader/efi_capsule.c | 48 +---
 lib/efi_loader/efi_setup.c   |  7 +-
 3 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c56904afc2..69bb66e09c 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -226,6 +226,14 @@ config EFI_CAPSULE_AUTHENTICATE
  Select this option if you want to enable capsule
  authentication
 
+config EFI_CAPSULE_MAX
+   int "Max value for capsule index"
+   default 65535
+   range 0 65535
+   help
+ Select the max capsule index value used for capsule report
+ variables. This value is used to create CapsuleMax variable.
+
 config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 0997cd248f..d5d3ede7ae 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -45,17 +45,7 @@ const efi_guid_t fwu_guid_os_request_fw_accept =
 static struct efi_file_handle *bootdev_root;
 #endif
 
-/**
- * get_last_capsule - get the last capsule index
- *
- * Retrieve the index of the capsule invoked last time from "CapsuleLast"
- * variable.
- *
- * Return:
- * * > 0   - the last capsule index invoked
- * * 0x- on error, or no capsule invoked yet
- */
-static __maybe_unused unsigned int get_last_capsule(void)
+static __maybe_unused unsigned int get_capsule_index(const u16 *variable_name)
 {
u16 value16[11]; /* "Capsule": non-null-terminated */
char value[5];
@@ -65,7 +55,7 @@ static __maybe_unused unsigned int get_last_capsule(void)
int i;
 
size = sizeof(value16);
-   ret = efi_get_variable_int(u"CapsuleLast", _guid_capsule_report,
+   ret = efi_get_variable_int(variable_name, _guid_capsule_report,
   NULL, , value16, NULL);
if (ret != EFI_SUCCESS || size != 22 ||
u16_strncmp(value16, u"Capsule", 7))
@@ -84,6 +74,35 @@ err:
return index;
 }
 
+/**
+ * get_last_capsule - get the last capsule index
+ *
+ * Retrieve the index of the capsule invoked last time from "CapsuleLast"
+ * variable.
+ *
+ * Return:
+ * * > 0   - the last capsule index invoked
+ * * 0x- on error, or no capsule invoked yet
+ */
+static __maybe_unused unsigned int get_last_capsule(void)
+{
+   return get_capsule_index(u"CapsuleLast");
+}
+
+/**
+ * get_max_capsule - get the max capsule index
+ *
+ * Retrieve the max capsule index value from "CapsuleMax" variable.
+ *
+ * Return:
+ * * > 0   - the max capsule index
+ * * 0x- on error, or "CapsuleMax" variable does not exist
+ */
+static __maybe_unused unsigned int get_max_capsule(void)
+{
+   return get_capsule_index(u"CapsuleMax");
+}
+
 /**
  * set_capsule_result - set a result variable
  * @capsule:   Capsule
@@ -1290,7 +1309,7 @@ efi_status_t efi_launch_capsules(void)
 {
struct efi_capsule_header *capsule = NULL;
u16 **files;
-   unsigned int nfiles, index, i;
+   unsigned int nfiles, index, index_max, i;
efi_status_t ret;
bool capsule_update = true;
bool update_status = true;
@@ -1299,6 +1318,7 @@ efi_status_t efi_launch_capsules(void)
if (check_run_capsules() != EFI_SUCCESS)
return EFI_SUCCESS;
 
+   index_max = get_max_capsule();
index = get_last_capsule();
 
/*
@@ -1317,7 +1337,7 @@ efi_status_t efi_launch_capsules(void)
/* Launch capsules */
for (i = 0, ++index; i < nfiles; i++, index++) {
log_debug("Applying %ls\n", files[i]);
-   if (index > 0x)
+   if (index > index_max)
index = 0;
ret = efi_capsule_read_file(files[i], );
if (ret == EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index f0f01d3b1d..04da4cf14d 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -129,12 +129,17 @@ static efi_status_t efi_init_capsule(void)
efi_status_t ret = EFI_SUCCESS;
 
if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)) {
+   u16 var_name16[12];
+
+   efi_create_indexed_name(var_name16, sizeof(var_name16),
+   "Capsule", CONFIG_EFI_CAPSULE_MAX);
+
ret = efi_set_variable_int(u"CapsuleMax",
   _guid_capsule_report,
  

[PATCH v2] efi_loader: Measure the loaded DTB

2023-02-16 Thread Etienne Carriere
Measures the DTB passed to the EFI application upon new boolean config
switch CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB. For platforms where the
content of the DTB passed to the OS can change across reboots, there is
not point measuring it hence the config switch to allow platform to not
embed this feature.

Co-developed-by: Ilias Apalodimas 
Signed-off-by: Ilias Apalodimas 
Signed-off-by: Etienne Carriere 
---
Changes since v1
- Moved measurement to after DTB tweaks in efi_install_fdt() and change
  its measure to hash only populated areas in the DTB (header, structs,
  strings and reserved memory maps). efi_tcg2_measure_dtb() computes
  the hash of these concatenated areas and used it as DTB  measurement.
- Remove useless default value 'n' for EFI_TCG2_PROTOCOL_MEASURE_DTB.
- I did not add EFI_TCG2_PROTOCOL_MEASURE_DTB dependencies on
  !NET_RANDOM_ETHADDR neither on !CMD_KASLRSEED. If ethernet address
  is random but always the same at each boot as saved in environment,
  it's measure is meaningful. CMD_KASLRSEED effect in DT if already
  addressed by efi_try_purge_kaslr_seed() prior measurement.
---
 cmd/bootefi.c |  8 +
 include/efi_loader.h  |  2 ++
 include/efi_tcg2.h| 10 ++
 include/tpm-v2.h  |  2 ++
 lib/efi_loader/Kconfig| 11 ++
 lib/efi_loader/efi_tcg2.c | 73 +++
 6 files changed, 106 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 2a7d42925d..6618335ddf 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -332,6 +332,14 @@ efi_status_t efi_install_fdt(void *fdt)
 
efi_try_purge_kaslr_seed(fdt);
 
+   if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) {
+   ret = efi_tcg2_measure_dtb(fdt);
+   if (ret == EFI_SECURITY_VIOLATION) {
+   log_err("ERROR: failed to measure DTB\n");
+   return ret;
+   }
+   }
+
/* Install device tree as UEFI table */
ret = efi_install_configuration_table(_guid_fdt, fdt);
if (ret != EFI_SUCCESS) {
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 4560b0d04c..4ecfdf919b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -531,6 +531,8 @@ efi_status_t 
efi_tcg2_notify_exit_boot_services_failed(void);
 efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj 
*handle);
 /* Measure efi application exit */
 efi_status_t efi_tcg2_measure_efi_app_exit(void);
+/* Measure DTB */
+efi_status_t efi_tcg2_measure_dtb(void *dtb);
 /* Called by bootefi to initialize root node */
 efi_status_t efi_root_node_register(void);
 /* Called by bootefi to initialize runtime */
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 874306dc11..b1c3abd097 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -233,6 +233,16 @@ struct efi_gpt_data {
gpt_entry partitions[];
 } __packed;
 
+/**
+ * struct tdUEFI_PLATFORM_FIRMWARE_BLOB2
+ * @blob_description_size: Byte size of @data
+ * @data:  Description data
+ */
+struct uefi_platform_firmware_blob2 {
+   u8 blob_description_size;
+   u8 data[];
+} __packed;
+
 struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
   struct 
efi_tcg2_boot_service_capability *capability);
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 737e57551d..2df3dad553 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -105,6 +105,8 @@ struct udevice;
"Exit Boot Services Returned with Failure"
 #define EFI_EXIT_BOOT_SERVICES_SUCCEEDED\
"Exit Boot Services Returned with Success"
+#define EFI_DTB_EVENT_STRING \
+   "DTB DATA"
 
 /* TPMS_TAGGED_PROPERTY Structure */
 struct tpms_tagged_property {
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c56904afc2..c05a54df16 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -346,6 +346,17 @@ config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
this is going to be allocated twice. One for the eventlog it 
self
and one for the configuration table that is required from the 
spec
 
+config EFI_TCG2_PROTOCOL_MEASURE_DTB
+   bool "Measure DTB with EFI_TCG2_PROTOCOL"
+   depends on EFI_TCG2_PROTOCOL
+   help
+ When enabled, the DTB image passed to the booted EFI image is
+ measured using the EFI TCG2 protocol. Do not enable this feature if
+ the passed DTB contains data that change across platform reboots
+ and cannot be used has a predictable measurement. Otherwise
+ this feature allows better measurement of the system boot
+ sequence.
+
 config EFI_LOAD_FILE2_INITRD
bool "EFI_FILE_LOAD2_PROTOCOL for Linux initial ramdisk"
default y
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 918e9a2686..2dcc317157 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ 

Re: [PATCH v3 08/10] phy: socionext: Add UniPhier USB3 PHY driver

2023-02-16 Thread Kunihiko Hayashi

Hi Marek,

Sorry for late reply.

On 2023/02/14 6:06, Marek Vasut wrote:

On 2/13/23 04:08, Kunihiko Hayashi wrote:

Hi Marek,


Hello Hayashi-san,



[...]


I think so, however, when I added .exit() and executed "usb stop;usb
start",
unfortunately the command got stuck.

Currently uniphier clk doesn't support CLK_CCF and can't be nested.
I think more changes are needed.


Do you know where exactly the system hangs ?


Yes.

The controller-reset driver controls the clock/reset for the glue
in probe(). The phy driver controls the clock/reset for the glue and
the phy in init(). There is an inconsistency.

When submitting "usb stop", the phy driver disables all the clock/reset
in exit().

When submitting "usb start" again, the controller-reset driver accesses
the glue register without enabling the clock/reset, and the system hangs.


Do you expect to add the CCF support ?


Yes, first I thought the clock needed the CCF support to count the clock
function calls, but there is no support to count the reset function calls.
I need another solution.

Currently the phy driver controls all the clock/reset in init() and exit(),
however, it should control the phy clock/reset only.


If so, then add at least a FIXME code comment that the exit callback
must be implemented, so that this is not forgotten once CCF is in place.
I don't want this series to grow much further into some "rework
everything at once" thing.


As above, I should put the glue clock/reset into probe(),
and the phy clock/reset into init() without using bulk function.

Thank you,

---
Best Regards
Kunihiko Hayashi


Re: [PATCH v2 0/3] fdt: introduce "fsapply" command

2023-02-16 Thread Heinrich Schuchardt

On 2/10/23 12:02, Andre Przywara wrote:

Hi,

updating the series, basically just changing the name of the command
to "fsapply", as suggested by Simon.
The first two patches are still the same fixes, Simon said he merged
them to u-boot-dm in July already, but I don't see them there or in
master.
I am still looking into a test for fsapply, but wanted to get at least
the fixes merged now, hence this new version.

===
This is an attempt to simplify the usage of user provided devicetree
overlays. The idea is to let the user drop all desired .dtbo files into
one directory (for instance on the EFI system partition), and U-Boot just
applies all of them, with generic commands:
=> fdt move $fdtcontroladdr $fdt_addr_r
=> fdt resize
=> fdt fsapply mmc 0:1 overlays/

This would pick all files ending in .dtbo from the /overlays directory
found on the first partition of the first MMC device. Ideally the device
type, number and partition name would be provided by the distroboot
scripting, so it checks the media it scans for boot scripts anyways.

Patch 1 fixes the "fdt move" operation in the sandbox. Since hostfs does
not support fs_opendir/fs_readdir, which fsapply relies on, this cannot
be tested in the sandbox, but I figured this bug is worth fixing anyway.
Patch 2 avoids a redundant call to "fdt addr", if we just want to move
(actually copy) the DTB. This is needed when we want to build on the
control DT, since this might live in an area where it cannot be changed
or grow enough.
Patch 3 then implements the main attraction: It uses the U-Boot
filesystem API to fs_readdir() the given directory, reads all files
ending in ".dtbo" into memory, and tries to apply them to the working DT.

Please let me know what you think of the idea in general and the
implementation in particular.
The first two patches are actually bug fixes, and should be applied
regardless.

Cheers,
Andre

Changelog v1 ... v2:
- add Simon's tags
- change command name from "apply-all" to "fsapply"


Andre Przywara (3):
   cmd: fdt: move: Use map_sysmem to convert pointers
   cmd: fdt: allow standalone "fdt move"
   fdt: introduce fsapply command

  cmd/fdt.c | 121 +++---
  1 file changed, 107 insertions(+), 14 deletions(-)


Hello Andre,

We should document this change in a document doc/usage/cmd/fdt.rst.

Best regards

Heinrich


[PATCH v2 6/9] cmd: blkmap: Add blkmap command

2023-02-16 Thread Tobias Waldekranz
Add a frontend for the blkmap subsystem. In addition to the common
block device operations, this allows users to create and destroy
devices, and map in memory and slices of other block devices.

With that we support two primary use-cases:

- Being able to "distro boot" from a RAM disk. I.e., from an image
  where the kernel is stored in /boot of some filesystem supported
  by U-Boot.

- Accessing filesystems not located on exact partition boundaries,
  e.g. when a filesystem image is wrapped in an FIT image and stored
  in a disk partition.

Signed-off-by: Tobias Waldekranz 
---
 MAINTAINERS  |   1 +
 cmd/Kconfig  |  19 +
 cmd/Makefile |   1 +
 cmd/blkmap.c | 233 +++
 disk/part.c  |   1 +
 5 files changed, 255 insertions(+)
 create mode 100644 cmd/blkmap.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3e47c9b34c..316b85fed7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -796,6 +796,7 @@ F:  tools/binman/
 BLKMAP
 M: Tobias Waldekranz 
 S: Maintained
+F: cmd/blkmap.c
 F: drivers/block/blkmap.c
 F: include/blkmap.h
 
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2caa4af71c..3dd3cdc656 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1959,6 +1959,25 @@ config CMD_BLOCK_CACHE
  during development, but also allows the cache to be disabled when
  it might hurt performance (e.g. when using the ums command).
 
+config CMD_BLKMAP
+   bool "blkmap - Composable virtual block devices"
+   depends on BLKMAP
+   default y if BLKMAP
+   help
+ Create virtual block devices that are backed by various sources,
+ e.g. RAM, or parts of an existing block device. Though much more
+ rudimentary, it borrows a lot of ideas from Linux's device mapper
+ subsystem.
+
+ Example use-cases:
+ - Treat a region of RAM as a block device, i.e. a RAM disk. This let's
+you extract files from filesystem images stored in RAM (perhaps as 
a
+result of a TFTP transfer).
+ - Create a virtual partition on an existing device. This let's you
+access filesystems that aren't stored at an exact partition
+boundary. A common example is a filesystem image embedded in an FIT
+image.
+
 config CMD_BUTTON
bool "button"
depends on BUTTON
diff --git a/cmd/Makefile b/cmd/Makefile
index 36d2daf22a..837eee39b1 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CMD_BCB) += bcb.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
 obj-$(CONFIG_CMD_BIND) += bind.o
 obj-$(CONFIG_CMD_BINOP) += binop.o
+obj-$(CONFIG_CMD_BLKMAP) += blkmap.o
 obj-$(CONFIG_CMD_BLOBLIST) += bloblist.o
 obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
 obj-$(CONFIG_CMD_BMP) += bmp.o
diff --git a/cmd/blkmap.c b/cmd/blkmap.c
new file mode 100644
index 00..b34c013072
--- /dev/null
+++ b/cmd/blkmap.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 Addiva Elektronik
+ * Author: Tobias Waldekranz 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int blkmap_curr_dev;
+
+struct map_ctx {
+   struct udevice *dev;
+   lbaint_t blknr, blkcnt;
+};
+
+typedef int (*map_parser_fn)(struct map_ctx *ctx, int argc, char *const 
argv[]);
+
+struct map_handler {
+   const char *name;
+   map_parser_fn fn;
+};
+
+int do_blkmap_map_linear(struct map_ctx *ctx, int argc, char *const argv[])
+{
+   struct blk_desc *lbd;
+   int err, ldevnum;
+   lbaint_t lblknr;
+
+   if (argc < 4)
+   return CMD_RET_USAGE;
+
+   ldevnum = dectoul(argv[2], NULL);
+   lblknr = dectoul(argv[3], NULL);
+
+   lbd = blk_get_devnum_by_uclass_idname(argv[1], ldevnum);
+   if (!lbd) {
+   printf("Found no device matching \"%s %d\"\n",
+  argv[1], ldevnum);
+   return CMD_RET_FAILURE;
+   }
+
+   err = blkmap_map_linear(ctx->dev, ctx->blknr, ctx->blkcnt,
+   lbd->bdev, lblknr);
+   if (err) {
+   printf("Unable to map \"%s %d\" at block 0x" LBAF ": %d\n",
+  argv[1], ldevnum, ctx->blknr, err);
+
+   return CMD_RET_FAILURE;
+   }
+
+   printf("Block 0x" LBAF "+0x" LBAF " mapped to block 0x" LBAF " of \"%s 
%d\"\n",
+  ctx->blknr, ctx->blkcnt, lblknr, argv[1], ldevnum);
+   return CMD_RET_SUCCESS;
+}
+
+int do_blkmap_map_mem(struct map_ctx *ctx, int argc, char *const argv[])
+{
+   phys_addr_t addr;
+   int err;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   addr = hextoul(argv[1], NULL);
+
+   err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr);
+   if (err) {
+   printf("Unable to map %#llx at block 0x" LBAF ": %d\n",
+  (unsigned long long)addr, ctx->blknr, err);
+   return CMD_RET_FAILURE;
+   }
+
+   printf("Block 0x" 

[PATCH v2 9/9] efi_loader: device_path: support blkmap devices

2023-02-16 Thread Tobias Waldekranz
Create a distinct EFI device path for each blkmap device.

Signed-off-by: Tobias Waldekranz 
---
 include/efi_loader.h |  4 
 lib/efi_loader/efi_device_path.c | 30 ++
 2 files changed, 34 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index c664d6cdf2..eb3818b457 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -134,6 +134,10 @@ static inline efi_status_t efi_launch_capsules(void)
 #define U_BOOT_GUID \
EFI_GUID(0xe61d73b9, 0xa384, 0x4acc, \
 0xae, 0xab, 0x82, 0xe8, 0x28, 0xf3, 0x62, 0x8b)
+/* GUID used as root for blkmap devices */
+#define U_BOOT_BLKMAP_DEV_GUID \
+   EFI_GUID(0x4cad859d, 0xd644, 0x42ff,\
+0x87, 0x0b, 0xc0, 0x2e, 0xac, 0x05, 0x58, 0x63)
 /* GUID used as host device on sandbox */
 #define U_BOOT_HOST_DEV_GUID \
EFI_GUID(0xbbe4e671, 0x5773, 0x4ea1, \
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 3b267b713e..4b4c96bc2e 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -21,6 +21,9 @@
 #include 
 #include  /* U16_MAX */
 
+#ifdef CONFIG_BLKMAP
+const efi_guid_t efi_guid_blkmap_dev = U_BOOT_BLKMAP_DEV_GUID;
+#endif
 #ifdef CONFIG_SANDBOX
 const efi_guid_t efi_guid_host_dev = U_BOOT_HOST_DEV_GUID;
 #endif
@@ -573,6 +576,16 @@ __maybe_unused static unsigned int dp_size(struct udevice 
*dev)
  */
return dp_size(dev->parent)
+ sizeof(struct efi_device_path_vendor) + 1;
+#endif
+#ifdef CONFIG_BLKMAP
+   case UCLASS_BLKMAP:
+/*
+ * blkmap devices will be represented as a vendor
+ * device node with an extra byte for the device
+ * number.
+ */
+   return dp_size(dev->parent)
+   + sizeof(struct efi_device_path_vendor) + 1;
 #endif
default:
return dp_size(dev->parent);
@@ -631,6 +644,23 @@ __maybe_unused static void *dp_fill(void *buf, struct 
udevice *dev)
 #endif
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
+#ifdef CONFIG_BLKMAP
+   case UCLASS_BLKMAP: {
+   struct efi_device_path_vendor *dp;
+   struct blk_desc *desc = dev_get_uclass_plat(dev);
+
+   dp_fill(buf, dev->parent);
+   dp = buf;
+   ++dp;
+   dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+   dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
+   dp->dp.length = sizeof(*dp) + 1;
+   memcpy(>guid, _guid_blkmap_dev,
+  sizeof(efi_guid_t));
+   dp->vendor_data[0] = desc->devnum;
+   return >vendor_data[1];
+   }
+#endif
 #ifdef CONFIG_SANDBOX
case UCLASS_HOST: {
/* stop traversing parents at this point: */
-- 
2.34.1



[PATCH v2 3/9] blk: blkmap: Add basic infrastructure

2023-02-16 Thread Tobias Waldekranz
blkmaps are loosely modeled on Linux's device mapper subsystem. The
basic idea is that you can create virtual block devices whose blocks
can be backed by a plethora of sources that are user configurable.

This change just adds the basic infrastructure for creating and
removing blkmap devices. Subsequent changes will extend this to add
support for actual mappings.

Signed-off-by: Tobias Waldekranz 
---
 MAINTAINERS|   6 +
 drivers/block/Kconfig  |  18 ++
 drivers/block/Makefile |   1 +
 drivers/block/blk-uclass.c |   1 +
 drivers/block/blkmap.c | 343 +
 include/blkmap.h   |  35 
 include/dm/uclass-id.h |   1 +
 7 files changed, 405 insertions(+)
 create mode 100644 drivers/block/blkmap.c
 create mode 100644 include/blkmap.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f53f9c2f6..3e47c9b34c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -793,6 +793,12 @@ M: Alper Nebi Yasak 
 S: Maintained
 F: tools/binman/
 
+BLKMAP
+M: Tobias Waldekranz 
+S: Maintained
+F: drivers/block/blkmap.c
+F: include/blkmap.h
+
 BOOTDEVICE
 M: Simon Glass 
 S: Maintained
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index e95da48bdc..5a1aeb3d2b 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -67,6 +67,24 @@ config BLOCK_CACHE
  it will prevent repeated reads from directory structures and other
  filesystem data structures.
 
+config BLKMAP
+   bool "Composable virtual block devices (blkmap)"
+   depends on BLK
+   help
+ Create virtual block devices that are backed by various sources,
+ e.g. RAM, or parts of an existing block device. Though much more
+ rudimentary, it borrows a lot of ideas from Linux's device mapper
+ subsystem.
+
+ Example use-cases:
+ - Treat a region of RAM as a block device, i.e. a RAM disk. This let's
+you extract files from filesystem images stored in RAM (perhaps as 
a
+result of a TFTP transfer).
+ - Create a virtual partition on an existing device. This let's you
+access filesystems that aren't stored at an exact partition
+boundary. A common example is a filesystem image embedded in an FIT
+image.
+
 config SPL_BLOCK_CACHE
bool "Use block device cache in SPL"
depends on SPL_BLK
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index f12447d78d..a161d145fd 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_IDE) += ide.o
 endif
 obj-$(CONFIG_SANDBOX) += sandbox.o host-uclass.o host_dev.o
 obj-$(CONFIG_$(SPL_TPL_)BLOCK_CACHE) += blkcache.o
+obj-$(CONFIG_BLKMAP) += blkmap.o
 
 obj-$(CONFIG_EFI_MEDIA) += efi-media-uclass.o
 obj-$(CONFIG_EFI_MEDIA_SANDBOX) += sb_efi_media.o
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index c69fc4d518..cb73faaeda 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -32,6 +32,7 @@ static struct {
{ UCLASS_EFI_LOADER, "efiloader" },
{ UCLASS_VIRTIO, "virtio" },
{ UCLASS_PVBLOCK, "pvblock" },
+   { UCLASS_BLKMAP, "blkmap" },
 };
 
 static enum uclass_id uclass_name_to_iftype(const char *uclass_idname)
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
new file mode 100644
index 00..acfc002ceb
--- /dev/null
+++ b/drivers/block/blkmap.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 Addiva Elektronik
+ * Author: Tobias Waldekranz 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct blkmap;
+
+/**
+ * struct blkmap_slice - Region mapped to a blkmap
+ *
+ * Common data for a region mapped to a blkmap, specialized by each
+ * map type.
+ *
+ * @node: List node used to associate this slice with a blkmap
+ * @blknr: Start block number of the mapping
+ * @blkcnt: Number of blocks covered by this mapping
+ */
+struct blkmap_slice {
+   struct list_head node;
+
+   lbaint_t blknr;
+   lbaint_t blkcnt;
+
+   /**
+* @read: - Read from slice
+*
+* @read.bm: Blkmap to which this slice belongs
+* @read.bms: This slice
+* @read.blknr: Start block number to read from
+* @read.blkcnt: Number of blocks to read
+* @read.buffer: Buffer to store read data to
+*/
+   ulong (*read)(struct blkmap *bm, struct blkmap_slice *bms,
+ lbaint_t blknr, lbaint_t blkcnt, void *buffer);
+
+   /**
+* @write: - Write to slice
+*
+* @write.bm: Blkmap to which this slice belongs
+* @write.bms: This slice
+* @write.blknr: Start block number to write to
+* @write.blkcnt: Number of blocks to write
+* @write.buffer: Data to be written
+*/
+   ulong (*write)(struct blkmap *bm, struct blkmap_slice 

[PATCH v2 8/9] doc: blkmap: Add introduction and examples

2023-02-16 Thread Tobias Waldekranz
Explain block maps by going through two common use-cases.

Signed-off-by: Tobias Waldekranz 
---
 MAINTAINERS  |   1 +
 doc/usage/blkmap.rst | 111 +++
 doc/usage/index.rst  |   1 +
 3 files changed, 113 insertions(+)
 create mode 100644 doc/usage/blkmap.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index bbcb5117fe..e02dacc20a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -797,6 +797,7 @@ BLKMAP
 M: Tobias Waldekranz 
 S: Maintained
 F: cmd/blkmap.c
+F: doc/usage/blkmap.rst
 F: drivers/block/blkmap.c
 F: include/blkmap.h
 F: test/dm/blkmap.c
diff --git a/doc/usage/blkmap.rst b/doc/usage/blkmap.rst
new file mode 100644
index 00..dbfa8e5aad
--- /dev/null
+++ b/doc/usage/blkmap.rst
@@ -0,0 +1,111 @@
+.. SPDX-License-Identifier: GPL-2.0+
+..
+.. Copyright (c) 2023 Addiva Elektronik
+.. Author: Tobias Waldekranz 
+
+Block Maps (blkmap)
+===
+
+Block maps are a way of looking at various sources of data through the
+lens of a regular block device. It lets you treat devices that are not
+block devices, like RAM, as if they were. It also lets you export a
+slice of an existing block device, which does not have to correspond
+to a partition boundary, as a new block device.
+
+This is primarily useful because U-Boot's filesystem drivers only
+operate on block devices, so a block map lets you access filesystems
+wherever they might be located.
+
+The implementation is loosely modeled on Linux's "Device Mapper"
+subsystem, see `kernel documentation`_ for more information.
+
+.. _kernel documentation: 
https://docs.kernel.org/admin-guide/device-mapper/index.html
+
+
+Example: Netbooting an Ext4 Image
+-
+
+Say that our system is using an Ext4 filesystem as its rootfs, where
+the kernel is stored in ``/boot``. This image is then typically stored
+in an eMMC partition. In this configuration, we can use something like
+``load mmc 0 ${kernel_addr_r} /boot/Image`` to load the kernel image
+into the expected location, and then boot the system. No problems.
+
+Now imagine that during development, or as a recovery mechanism, we
+want to boot the same type of image by downloading it over the
+network. Getting the image to the target is easy enough:
+
+::
+
+   dhcp ${ramdisk_addr_r} rootfs.ext4
+
+But now we are faced with a predicament: how to we extract the kernel
+image? Block maps to the rescue!
+
+We start by creating a new device:
+
+::
+
+   blkmap create netboot
+
+Before setting up the mapping, we figure out the size of the
+downloaded file, in blocks:
+
+::
+
+   setexpr fileblks ${filesize} + 0x1ff
+   setexpr fileblks ${filesize} / 0x200
+
+Then we can add a mapping to the start of our device, backed by the
+memory at `${loadaddr}`:
+
+::
+
+   blkmap map netboot 0 ${fileblks} mem ${fileaddr}
+
+Now we can access the filesystem via the virtual device:
+
+::
+
+   blkmap get netboot dev devnum
+   load blkmap ${devnum} ${kernel_addr_r} /boot/Image
+
+
+Example: Accessing a filesystem inside an FIT image
+---
+
+In this example, an FIT image is stored in an eMMC partition. We would
+like to read the file ``/etc/version``, stored inside a Squashfs image
+in the FIT. Since the Squashfs image is not stored on a partition
+boundary, there is no way of accessing it via ``load mmc ...``.
+
+What we can to instead is to first figure out the offset and size of
+the filesystem:
+
+::
+
+   mmc dev 0
+   mmc read ${loadaddr} 0 0x100
+
+   fdt addr ${loadaddr}
+   fdt get value squashaddr /images/ramdisk data-position
+   fdt get value squashsize /images/ramdisk data-size
+
+   setexpr squashblk  ${squashaddr} / 0x200
+   setexpr squashsize ${squashsize} + 0x1ff
+   setexpr squashsize ${squashsize} / 0x200
+
+Then we can create a block map that maps to that slice of the full
+partition:
+
+::
+
+   blkmap create sq
+   blkmap map sq 0 ${squashsize} linear mmc 0 ${squashblk}
+
+Now we can access the filesystem:
+
+::
+
+   blkmap get sq dev devnum
+   load blkmap ${devnum} ${loadaddr} /etc/version
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index cde7dcb14a..2dfcd4b2b2 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -4,6 +4,7 @@ Use U-Boot
 .. toctree::
:maxdepth: 1
 
+   blkmap
dfu
environment
fdt_overlays
-- 
2.34.1



[PATCH v2 4/9] blk: blkmap: Add memory mapping support

2023-02-16 Thread Tobias Waldekranz
Allow a slice of RAM to be mapped to a blkmap. This means that RAM can
now be accessed as if it was a block device, meaning that existing
filesystem drivers can now be used to access ramdisks.

Signed-off-by: Tobias Waldekranz 
---
 drivers/block/blkmap.c | 105 +
 include/blkmap.h   |  29 
 2 files changed, 134 insertions(+)

diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index acfc002ceb..6d6eed889e 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -130,6 +130,111 @@ static int blkmap_slice_add(struct blkmap *bm, struct 
blkmap_slice *new)
return 0;
 }
 
+/**
+ * struct blkmap_mem - Memory mapping
+ *
+ * @slice: Common map data
+ * @addr: Target memory region of this mapping
+ * @remapped: True if @addr is backed by a physical to virtual memory
+ * mapping that must be torn down at the end of this mapping's
+ * lifetime.
+ */
+struct blkmap_mem {
+   struct blkmap_slice slice;
+   void *addr;
+   bool remapped;
+};
+
+static ulong blkmap_mem_read(struct blkmap *bm, struct blkmap_slice *bms,
+lbaint_t blknr, lbaint_t blkcnt, void *buffer)
+{
+   struct blkmap_mem *bmm = container_of(bms, struct blkmap_mem, slice);
+   struct blk_desc *bd = dev_get_uclass_plat(bm->blk);
+   char *src;
+
+   src = bmm->addr + (blknr << bd->log2blksz);
+   memcpy(buffer, src, blkcnt << bd->log2blksz);
+   return blkcnt;
+}
+
+static ulong blkmap_mem_write(struct blkmap *bm, struct blkmap_slice *bms,
+ lbaint_t blknr, lbaint_t blkcnt,
+ const void *buffer)
+{
+   struct blkmap_mem *bmm = container_of(bms, struct blkmap_mem, slice);
+   struct blk_desc *bd = dev_get_uclass_plat(bm->blk);
+   char *dst;
+
+   dst = bmm->addr + (blknr << bd->log2blksz);
+   memcpy(dst, buffer, blkcnt << bd->log2blksz);
+   return blkcnt;
+}
+
+static void blkmap_mem_destroy(struct blkmap *bm, struct blkmap_slice *bms)
+{
+   struct blkmap_mem *bmm = container_of(bms, struct blkmap_mem, slice);
+
+   if (bmm->remapped)
+   unmap_sysmem(bmm->addr);
+}
+
+int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+void *addr, bool remapped)
+{
+   struct blkmap *bm = dev_get_plat(dev);
+   struct blkmap_mem *bmm;
+   int err;
+
+   bmm = malloc(sizeof(*bmm));
+   if (!bmm)
+   return -ENOMEM;
+
+   *bmm = (struct blkmap_mem) {
+   .slice = {
+   .blknr = blknr,
+   .blkcnt = blkcnt,
+
+   .read = blkmap_mem_read,
+   .write = blkmap_mem_write,
+   .destroy = blkmap_mem_destroy,
+   },
+
+   .addr = addr,
+   .remapped = remapped,
+   };
+
+   err = blkmap_slice_add(bm, >slice);
+   if (err)
+   free(bmm);
+
+   return err;
+}
+
+int blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+  void *addr)
+{
+   return __blkmap_map_mem(dev, blknr, blkcnt, addr, false);
+}
+
+int blkmap_map_pmem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+   phys_addr_t paddr)
+{
+   struct blkmap *bm = dev_get_plat(dev);
+   struct blk_desc *bd = dev_get_uclass_plat(bm->blk);
+   void *addr;
+   int err;
+
+   addr = map_sysmem(paddr, blkcnt << bd->log2blksz);
+   if (!addr)
+   return -ENOMEM;
+
+   err = __blkmap_map_mem(dev, blknr, blkcnt, addr, true);
+   if (err)
+   unmap_sysmem(addr);
+
+   return err;
+}
+
 static ulong blkmap_blk_read_slice(struct blkmap *bm, struct blkmap_slice *bms,
   lbaint_t blknr, lbaint_t blkcnt,
   void *buffer)
diff --git a/include/blkmap.h b/include/blkmap.h
index 3c7e36efab..74baeb19f8 100644
--- a/include/blkmap.h
+++ b/include/blkmap.h
@@ -7,6 +7,35 @@
 #ifndef _BLKMAP_H
 #define _BLKMAP_H
 
+/**
+ * blkmap_map_mem() - Map region of memory
+ *
+ * @dev: Blkmap to create the mapping on
+ * @blknr: Start block number of the mapping
+ * @blkcnt: Number of blocks to map
+ * @addr: The target memory address of the mapping
+ * Returns: 0 on success, negative error code on failure
+ */
+int blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+  void *addr);
+
+/**
+ * blkmap_map_pmem() - Map region of physical memory
+ *
+ * Ensures that a valid physical to virtual memory mapping for the
+ * requested region is valid for the lifetime of the mapping, on
+ * architectures that require it (sandbox).
+ *
+ * @dev: Blkmap to create the mapping on
+ * @blknr: Start block number of the mapping
+ * @blkcnt: Number of blocks to map
+ * @paddr: The target physical memory address of the mapping
+ * Returns: 0 on success, negative error 

[PATCH v2 7/9] test: blkmap: Add test suite

2023-02-16 Thread Tobias Waldekranz
Verify that:

- Block maps can be created and destroyed
- Mappings aren't allowed to overlap
- Multiple mappings can be attached and be read/written from/to

Signed-off-by: Tobias Waldekranz 
---
 MAINTAINERS   |   1 +
 configs/sandbox_defconfig |   1 +
 test/dm/Makefile  |   1 +
 test/dm/blkmap.c  | 201 ++
 4 files changed, 204 insertions(+)
 create mode 100644 test/dm/blkmap.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 316b85fed7..bbcb5117fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -799,6 +799,7 @@ S:  Maintained
 F: cmd/blkmap.c
 F: drivers/block/blkmap.c
 F: include/blkmap.h
+F: test/dm/blkmap.c
 
 BOOTDEVICE
 M: Simon Glass 
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 34c342b6f5..06021e4902 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -145,6 +145,7 @@ CONFIG_ADC=y
 CONFIG_ADC_SANDBOX=y
 CONFIG_AXI=y
 CONFIG_AXI_SANDBOX=y
+CONFIG_BLKMAP=y
 CONFIG_SYS_IDE_MAXBUS=1
 CONFIG_SYS_ATA_BASE_ADDR=0x100
 CONFIG_SYS_ATA_STRIDE=4
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7a79b6e1a2..e15bdbf04b 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ADC) += adc.o
 obj-$(CONFIG_SOUND) += audio.o
 obj-$(CONFIG_AXI) += axi.o
 obj-$(CONFIG_BLK) += blk.o
+obj-$(CONFIG_BLKMAP) += blkmap.o
 obj-$(CONFIG_BUTTON) += button.o
 obj-$(CONFIG_DM_BOOTCOUNT) += bootcount.o
 obj-$(CONFIG_DM_REBOOT_MODE) += reboot-mode.o
diff --git a/test/dm/blkmap.c b/test/dm/blkmap.c
new file mode 100644
index 00..7a163d6eae
--- /dev/null
+++ b/test/dm/blkmap.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 Addiva Elektronik
+ * Author: Tobias Waldekranz 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BLKSZ 0x200
+
+struct mapping {
+   int src;
+   int cnt;
+   int dst;
+};
+
+const struct mapping unordered_mapping[] = {
+   { 0, 1, 3 },
+   { 1, 3, 0 },
+   { 4, 2, 6 },
+   { 6, 2, 4 },
+
+   { 0, 0, 0 }
+};
+
+const struct mapping identity_mapping[] = {
+   { 0, 8, 0 },
+
+   { 0, 0, 0 }
+};
+
+static char identity[8 * BLKSZ];
+static char unordered[8 * BLKSZ];
+static char buffer[8 * BLKSZ];
+
+static void mkblob(void *base, const struct mapping *m)
+{
+   int nr;
+
+   for (; m->cnt; m++) {
+   for (nr = 0; nr < m->cnt; nr++) {
+   memset(base + (m->dst + nr) * BLKSZ,
+  m->src + nr, BLKSZ);
+   }
+   }
+}
+
+static int dm_test_blkmap_read(struct unit_test_state *uts)
+{
+   struct udevice *dev, *blk;
+   const struct mapping *m;
+
+   ut_assertok(blkmap_create("rdtest", ));
+   ut_assertok(blk_get_from_parent(dev, ));
+
+   /* Generate an ordered and an unordered pattern in memory */
+   mkblob(unordered, unordered_mapping);
+   mkblob(identity, identity_mapping);
+
+   /* Create a blkmap that cancels out the disorder */
+   for (m = unordered_mapping; m->cnt; m++) {
+   ut_assertok(blkmap_map_mem(dev, m->src, m->cnt,
+  unordered + m->dst * BLKSZ));
+   }
+
+   /* Read out the data via the blkmap device to another area,
+* and verify that it matches the ordered pattern.
+*/
+   ut_asserteq(8, blk_read(blk, 0, 8, buffer));
+   ut_assertok(memcmp(buffer, identity, sizeof(buffer)));
+
+   ut_assertok(blkmap_destroy(dev));
+   return 0;
+}
+DM_TEST(dm_test_blkmap_read, 0);
+
+static int dm_test_blkmap_write(struct unit_test_state *uts)
+{
+   struct udevice *dev, *blk;
+   const struct mapping *m;
+
+   ut_assertok(blkmap_create("wrtest", ));
+   ut_assertok(blk_get_from_parent(dev, ));
+
+   /* Generate an ordered and an unordered pattern in memory */
+   mkblob(unordered, unordered_mapping);
+   mkblob(identity, identity_mapping);
+
+   /* Create a blkmap that mimics the disorder */
+   for (m = unordered_mapping; m->cnt; m++) {
+   ut_assertok(blkmap_map_mem(dev, m->src, m->cnt,
+  buffer + m->dst * BLKSZ));
+   }
+
+   /* Write the ordered data via the blkmap device to another
+* area, and verify that the result matches the unordered
+* pattern.
+*/
+   ut_asserteq(8, blk_write(blk, 0, 8, identity));
+   ut_assertok(memcmp(buffer, unordered, sizeof(buffer)));
+
+   ut_assertok(blkmap_destroy(dev));
+   return 0;
+}
+DM_TEST(dm_test_blkmap_write, 0);
+
+static int dm_test_blkmap_slicing(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   ut_assertok(blkmap_create("slicetest", ));
+
+   ut_assertok(blkmap_map_mem(dev, 8, 8, NULL));
+
+   /* Can't overlap on the low end */
+   ut_asserteq(-EBUSY, blkmap_map_mem(dev,  4, 5, NULL));
+   /* 

[PATCH v2 2/9] cmd: blk: Allow generic read/write operations to work in sandbox

2023-02-16 Thread Tobias Waldekranz
Ensure that the memory destination/source addresses of block
read/write operations are mapped in before access. Currently, this is
only needed on sandbox builds.

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Simon Glass 
---
 cmd/blk_common.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/cmd/blk_common.c b/cmd/blk_common.c
index 75a072caf5..9f9d4327a9 100644
--- a/cmd/blk_common.c
+++ b/cmd/blk_common.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int blk_common_cmd(int argc, char *const argv[], enum uclass_id uclass_id,
   int *cur_devnump)
@@ -63,31 +64,37 @@ int blk_common_cmd(int argc, char *const argv[], enum 
uclass_id uclass_id,
 
default: /* at least 4 args */
if (strcmp(argv[1], "read") == 0) {
-   ulong addr = hextoul(argv[2], NULL);
+   phys_addr_t paddr = hextoul(argv[2], NULL);
lbaint_t blk = hextoul(argv[3], NULL);
ulong cnt = hextoul(argv[4], NULL);
+   void *vaddr;
ulong n;
 
printf("\n%s read: device %d block # "LBAFU", count %lu 
... ",
   if_name, *cur_devnump, blk, cnt);
 
+   vaddr = map_sysmem(paddr, 512 * cnt);
n = blk_read_devnum(uclass_id, *cur_devnump, blk, cnt,
-   (ulong *)addr);
+   vaddr);
+   unmap_sysmem(vaddr);
 
printf("%ld blocks read: %s\n", n,
   n == cnt ? "OK" : "ERROR");
return n == cnt ? 0 : 1;
} else if (strcmp(argv[1], "write") == 0) {
-   ulong addr = hextoul(argv[2], NULL);
+   phys_addr_t paddr = hextoul(argv[2], NULL);
lbaint_t blk = hextoul(argv[3], NULL);
ulong cnt = hextoul(argv[4], NULL);
+   void *vaddr;
ulong n;
 
printf("\n%s write: device %d block # "LBAFU", count 
%lu ... ",
   if_name, *cur_devnump, blk, cnt);
 
+   vaddr = map_sysmem(paddr, 512 * cnt);
n = blk_write_devnum(uclass_id, *cur_devnump, blk, cnt,
-(ulong *)addr);
+vaddr);
+   unmap_sysmem(vaddr);
 
printf("%ld blocks written: %s\n", n,
   n == cnt ? "OK" : "ERROR");
-- 
2.34.1



[PATCH v2 5/9] blk: blkmap: Add linear device mapping support

2023-02-16 Thread Tobias Waldekranz
Allow a slice of an existing block device to be mapped to a
blkmap. This means that filesystems that are not stored at exact
partition boundaries can be accessed by remapping a slice of the
existing device to a blkmap device.

Signed-off-by: Tobias Waldekranz 
---
 drivers/block/blkmap.c | 71 ++
 include/blkmap.h   | 13 
 2 files changed, 84 insertions(+)

diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 6d6eed889e..2bb0acc20f 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -130,6 +130,77 @@ static int blkmap_slice_add(struct blkmap *bm, struct 
blkmap_slice *new)
return 0;
 }
 
+/**
+ * struct blkmap_linear - Linear mapping to other block device
+ *
+ * @slice: Common map data
+ * @blk: Target block device of this mapping
+ * @blknr: Start block number of the target device
+ */
+struct blkmap_linear {
+   struct blkmap_slice slice;
+
+   struct udevice *blk;
+   lbaint_t blknr;
+};
+
+static ulong blkmap_linear_read(struct blkmap *bm, struct blkmap_slice *bms,
+   lbaint_t blknr, lbaint_t blkcnt, void *buffer)
+{
+   struct blkmap_linear *bml = container_of(bms, struct blkmap_linear, 
slice);
+
+   return blk_read(bml->blk, bml->blknr + blknr, blkcnt, buffer);
+}
+
+static ulong blkmap_linear_write(struct blkmap *bm, struct blkmap_slice *bms,
+lbaint_t blknr, lbaint_t blkcnt,
+const void *buffer)
+{
+   struct blkmap_linear *bml = container_of(bms, struct blkmap_linear, 
slice);
+
+   return blk_write(bml->blk, bml->blknr + blknr, blkcnt, buffer);
+}
+
+int blkmap_map_linear(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+ struct udevice *lblk, lbaint_t lblknr)
+{
+   struct blkmap *bm = dev_get_plat(dev);
+   struct blkmap_linear *linear;
+   struct blk_desc *bd, *lbd;
+   int err;
+
+   bd = dev_get_uclass_plat(bm->blk);
+   lbd = dev_get_uclass_plat(lblk);
+   if (lbd->blksz != bd->blksz)
+   /* We could support block size translation, but we
+* don't yet.
+*/
+   return -EINVAL;
+
+   linear = malloc(sizeof(*linear));
+   if (!linear)
+   return -ENOMEM;
+
+   *linear = (struct blkmap_linear) {
+   .slice = {
+   .blknr = blknr,
+   .blkcnt = blkcnt,
+
+   .read = blkmap_linear_read,
+   .write = blkmap_linear_write,
+   },
+
+   .blk = lblk,
+   .blknr = lblknr,
+   };
+
+   err = blkmap_slice_add(bm, >slice);
+   if (err)
+   free(linear);
+
+   return err;
+}
+
 /**
  * struct blkmap_mem - Memory mapping
  *
diff --git a/include/blkmap.h b/include/blkmap.h
index 74baeb19f8..af54583c7d 100644
--- a/include/blkmap.h
+++ b/include/blkmap.h
@@ -7,6 +7,19 @@
 #ifndef _BLKMAP_H
 #define _BLKMAP_H
 
+/**
+ * blkmap_map_linear() - Map region of other block device
+ *
+ * @dev: Blkmap to create the mapping on
+ * @blknr: Start block number of the mapping
+ * @blkcnt: Number of blocks to map
+ * @lblk: The target block device of the mapping
+ * @lblknr: The start block number of the target device
+ * Returns: 0 on success, negative error code on failure
+ */
+int blkmap_map_linear(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+ struct udevice *lblk, lbaint_t lblknr);
+
 /**
  * blkmap_map_mem() - Map region of memory
  *
-- 
2.34.1



[PATCH v2 0/9] blk: blkmap: Composable virtual block devices

2023-02-16 Thread Tobias Waldekranz
Block maps are a way of looking at various sources of data through the
lens of a regular block device. It lets you treat devices that are not
block devices, like RAM, as if they were. It also lets you export a
slice of an existing block device, which does not have to correspond to
a partition boundary, as a new block device.

This is primarily useful because U-Boot's filesystem drivers only
operate on block devices, so a block map lets you access filesystems
wherever they might be located.

The implementation is loosely modeled on Linux's "Device Mapper"
subsystem, see the kernel documentation [1] for more information.

The primary use-cases are to access filesystem images stored in RAM, and
within FIT images stored on disk. See doc/usage/blkmap.rst for more
details.

The architecture is pluggable, so adding other types of mappings should
be quite easy.

[1]: https://docs.kernel.org/admin-guide/device-mapper/index.html

v1 -> v2:
 - Change internal API to use device pointers
 - Convert test suite from Python to C
 - Various cosmetic fixes

Tobias Waldekranz (9):
  image: Fix script execution from FIT images with external data
  cmd: blk: Allow generic read/write operations to work in sandbox
  blk: blkmap: Add basic infrastructure
  blk: blkmap: Add memory mapping support
  blk: blkmap: Add linear device mapping support
  cmd: blkmap: Add blkmap command
  test: blkmap: Add test suite
  doc: blkmap: Add introduction and examples
  efi_loader: device_path: support blkmap devices

 MAINTAINERS  |   9 +
 boot/image-board.c   |   3 +-
 cmd/Kconfig  |  19 ++
 cmd/Makefile |   1 +
 cmd/blk_common.c |  15 +-
 cmd/blkmap.c | 233 ++
 configs/sandbox_defconfig|   1 +
 disk/part.c  |   1 +
 doc/usage/blkmap.rst | 111 +++
 doc/usage/index.rst  |   1 +
 drivers/block/Kconfig|  18 ++
 drivers/block/Makefile   |   1 +
 drivers/block/blk-uclass.c   |   1 +
 drivers/block/blkmap.c   | 519 +++
 include/blkmap.h |  77 +
 include/dm/uclass-id.h   |   1 +
 include/efi_loader.h |   4 +
 lib/efi_loader/efi_device_path.c |  30 ++
 test/dm/Makefile |   1 +
 test/dm/blkmap.c | 201 
 20 files changed, 1242 insertions(+), 5 deletions(-)
 create mode 100644 cmd/blkmap.c
 create mode 100644 doc/usage/blkmap.rst
 create mode 100644 drivers/block/blkmap.c
 create mode 100644 include/blkmap.h
 create mode 100644 test/dm/blkmap.c

-- 
2.34.1



[PATCH v2 1/9] image: Fix script execution from FIT images with external data

2023-02-16 Thread Tobias Waldekranz
Update the script loading code to recognize when script data is stored
externally from the FIT metadata (i.e., built with `mkimage -E`).

Signed-off-by: Tobias Waldekranz 
Reviewed-by: Simon Glass 
---
 boot/image-board.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/boot/image-board.c b/boot/image-board.c
index 25b60ec30b..af693c9c08 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -,7 +,8 @@ fallback:
}
 
/* get script subimage data address and length */
-   if (fit_image_get_data(fit_hdr, noffset, _data, 
_len)) {
+   if (fit_image_get_data_and_size(fit_hdr, noffset,
+   _data, _len)) {
puts("Could not find script subimage data\n");
return 1;
}
-- 
2.34.1



[PATCH v2 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Heinrich Schuchardt
Some boards provide main U-Boot as a dedicated partition to SPL.
Currently we can define either a fixed partition number or an MBR
partition type to define which partition is to be used.

Partition numbers tend to conflict with established partitioning schemes
of Linux distros. MBR partitioning is more and more replaced by GPT
partitioning.

Allow defining a partition type GUID identifying the partition to load
main U-Boot from.

Signed-off-by: Heinrich Schuchardt 
---
v2:
avoid if/endif in Kconfig
---
 common/spl/Kconfig   | 27 ++-
 common/spl/spl_mmc.c | 13 +
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 3c2af453ab..9d12b48297 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
  used in raw mode
 
 config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
-   bool "MMC raw mode: by partition type"
+   bool "MMC raw mode: by MBR partition type"
depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
help
- Use partition type for specifying U-Boot partition on MMC/SD in
+ Use MBR partition type for specifying U-Boot partition on MMC/SD in
  raw mode. U-Boot will be loaded from the first partition of this
  type to be found.
 
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
-   hex "Partition Type on the MMC to load U-Boot from"
+   hex "MBR Partition Type on the MMC to load U-Boot from"
depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
help
- Partition Type on the MMC to load U-Boot from, when the MMC is being
- used in raw mode.
+ MBR Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   bool "MMC raw mode: GPT by partition type"
+   depends on PARTITION_TYPE_GUID && 
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   help
+ Use GPT partition type for specifying U-Boot partition on MMC/SD in
+ raw mode. U-Boot will be loaded from the first partition of this
+ type to be found.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
+   string "GPT Partition Type on the MMC to load U-Boot from"
+   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6
+   help
+ GPT Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode. The GUID must be lower case, low endian,
+ and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.
 
 config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b2048..69bf1d6e98 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
struct disk_partition info;
int err;
 
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
+   err = part_get_info(mmc_get_blk_desc(mmc), i, );
+   if (err)
+   continue;
+   if (!strncmp(info.type_guid,
+
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
+UUID_STR_LEN)) {
+   partition = i;
+   break;
+   }
+   }
+#endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
int type_part;
/* Only support MBR so DOS_ENTRY_NUMBERS */
-- 
2.38.1



Re: [PATCH 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 04:08:59PM +0100, Heinrich Schuchardt wrote:

> Some boards provide main U-Boot as a dedicated partition to SPL.
> Currently we can define either a fixed partition number or an MBR
> partition type to define which partition is to be used.
> 
> Partition numbers tend to conflict with established partitioning schemes
> of Linux distros. MBR partitioning is more and more replaced by GPT
> partitioning.
> 
> Allow defining a partition type GUID identifying the partition to load
> main U-Boot from.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/spl/Kconfig   | 33 +++--
>  common/spl/spl_mmc.c | 13 +
>  2 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 3c2af453ab..29166d8b98 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -513,20 +513,41 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> Partition on the MMC to load U-Boot from when the MMC is being
> used in raw mode
>  
> +if SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> +
>  config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> - bool "MMC raw mode: by partition type"
> - depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION

I don't like using "if" to hide Kconfig options and feel that we should
use it when a large number (double digits perhaps?) of options aren't
allowed without the symbol, please just use depends on
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION for the new option here.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 1/1] spl: allow loading via partition type GUID

2023-02-16 Thread Heinrich Schuchardt
Some boards provide main U-Boot as a dedicated partition to SPL.
Currently we can define either a fixed partition number or an MBR
partition type to define which partition is to be used.

Partition numbers tend to conflict with established partitioning schemes
of Linux distros. MBR partitioning is more and more replaced by GPT
partitioning.

Allow defining a partition type GUID identifying the partition to load
main U-Boot from.

Signed-off-by: Heinrich Schuchardt 
---
 common/spl/Kconfig   | 33 +++--
 common/spl/spl_mmc.c | 13 +
 2 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 3c2af453ab..29166d8b98 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -513,20 +513,41 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
  Partition on the MMC to load U-Boot from when the MMC is being
  used in raw mode
 
+if SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+
 config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
-   bool "MMC raw mode: by partition type"
-   depends on DOS_PARTITION && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+   bool "MMC raw mode: by MBR partition type"
+   depends on DOS_PARTITION
help
- Use partition type for specifying U-Boot partition on MMC/SD in
+ Use MBR partition type for specifying U-Boot partition on MMC/SD in
  raw mode. U-Boot will be loaded from the first partition of this
  type to be found.
 
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
-   hex "Partition Type on the MMC to load U-Boot from"
+   hex "MBR Partition Type on the MMC to load U-Boot from"
depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
help
- Partition Type on the MMC to load U-Boot from, when the MMC is being
- used in raw mode.
+ MBR Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   bool "MMC raw mode: GPT by partition type"
+   depends on PARTITION_TYPE_GUID
+   help
+ Use GPT partition type for specifying U-Boot partition on MMC/SD in
+ raw mode. U-Boot will be loaded from the first partition of this
+ type to be found.
+
+config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
+   string "GPT Partition Type on the MMC to load U-Boot from"
+   depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6
+   help
+ GPT Partition Type on the MMC to load U-Boot from, when the MMC is
+ being used in raw mode. The GUID must be lower case, low endian,
+ and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.
+
+endif
 
 config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
bool "Override eMMC EXT_CSC_PART_CONFIG by user defined partition"
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b2048..69bf1d6e98 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
struct disk_partition info;
int err;
 
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
+   for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
+   err = part_get_info(mmc_get_blk_desc(mmc), i, );
+   if (err)
+   continue;
+   if (!strncmp(info.type_guid,
+
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE,
+UUID_STR_LEN)) {
+   partition = i;
+   break;
+   }
+   }
+#endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
int type_part;
/* Only support MBR so DOS_ENTRY_NUMBERS */
-- 
2.38.1



Re: [PATCH 11/13] imx8mm-mx8menlo: Drop SPL_BOARD_INIT

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 03:21:43PM +0100, Marek Vasut wrote:
> On 2/16/23 15:13, Tom Rini wrote:
> > On Thu, Feb 16, 2023 at 03:04:35PM +0100, Marek Vasut wrote:
> > > On 2/16/23 04:36, Tom Rini wrote:
> > > > On this platform spl_board_init is a call to arch_misc_init which is a
> > > > no-op, so drop the CONFIG options.
> > > > 
> > > > Cc: Marek Vasut 
> > > > Cc: Olaf Mandel 
> > > 
> > > btw. put those under --- next time, that way they don't end up in commit
> > > message.
> > 
> > Er, did the kernel change expected behavior here?
> 
> Er ... wasn't that the case for like a year now ?

Is that a yes then?

> > > > Signed-off-by: Tom Rini 
> > > 
> > > If CAAM is enabled, ARCH_MISC_INIT brings up the CAAM , and this is needed
> > > in SPL for U-Boot authentication using HABv4 . I believe that is why 
> > > Verdin
> > > spl.c calls it.
> > 
> > Then I'll put doing a follow-up on SPL_BOARD_INIT (which is another
> > option that shouldn't be directly asked, but select'd when used) for
> > that case. It fails to build in this series because CAAM isn't enabled
> > so there's no arch_misc_init.
> 
> Just call the arch_board_init unconditionally, the CAAM inside of it is
> already conditional, so the compiler should inline the result if CAAM is
> disabled.

It doesn't, and only maybe does with LTO. But we also shouldn't be
enabling unused hooks. It sounds like imx8m should follow the other
platforms that have an spl_board_init under arch/ ?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 4/6] rockchip: mkimage: Update init size limit

2023-02-16 Thread Jonas Karlman
Hi Kever,

On 2023-02-16 08:59, Kever Yang wrote:
> Hi Jonas,
> 
> On 2023/2/14 18:33, Jonas Karlman wrote:
>> Sync init size limit from vendor u-boot and the SRAM size specified in a
>> SoCs TRM. Size is typically defined using the following expression:
>>  - 
> 
> Although most of SoC follow this rule, but not for all.
> 
> So please just do the sync from vendor u-boot, but not extra modify 
> under this rule.

Sure, I will only sync from vendor u-boot.

After such sync init size limit changes for:
px30: +2KiB -> 12KiB
rk3066: +2KiB -> 32KiB
rk3328: +2KiB -> 30KiB
rk3568: -16KiB -> 60KiB

Regards,
Jonas

> 
> Thanks,
> 
> - Kever
> 
>>
>> This makes it possible to use latest vendor TPL with RK3328 without
>> getting a size limit error running the mkimage command.
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>> v2:
>> - new patch
>>
>>   tools/rkcommon.c | 16 
>>   1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
>> index 1f1eaa16752b..7ad4780daf31 100644
>> --- a/tools/rkcommon.c
>> +++ b/tools/rkcommon.c
>> @@ -121,20 +121,20 @@ struct spl_info {
>>   };
>>   
>>   static struct spl_info spl_infos[] = {
>> -{ "px30", "RK33", 0x2800, false, RK_HEADER_V1 },
>> -{ "rk3036", "RK30", 0x1000, false, RK_HEADER_V1 },
>> +{ "px30", "RK33", 0x4000 - 0x1000, false, RK_HEADER_V1 },
>> +{ "rk3036", "RK30", 0x2000 - 0x1000, false, RK_HEADER_V1 },
>>  { "rk3066", "RK30", 0x8000 - 0x800, true, RK_HEADER_V1 },
>> -{ "rk3128", "RK31", 0x1800, false, RK_HEADER_V1 },
>> +{ "rk3128", "RK31", 0x2000 - 0x800, false, RK_HEADER_V1 },
>>  { "rk3188", "RK31", 0x8000 - 0x800, true, RK_HEADER_V1 },
>>  { "rk322x", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 },
>> -{ "rk3288", "RK32", 0x8000, false, RK_HEADER_V1 },
>> +{ "rk3288", "RK32", 0x18000 - 0x1000, false, RK_HEADER_V1 },
>>  { "rk3308", "RK33", 0x4 - 0x1000, false, RK_HEADER_V1 },
>> -{ "rk3328", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 },
>> -{ "rk3368", "RK33", 0x8000 - 0x1000, false, RK_HEADER_V1 },
>> +{ "rk3328", "RK32", 0x8000 - 0x800, false, RK_HEADER_V1 },
>> +{ "rk3368", "RK33", 0x1 - 0x1000, false, RK_HEADER_V1 },
>>  { "rk3399", "RK33", 0x3 - 0x2000, false, RK_HEADER_V1 },
>> -{ "rv1108", "RK11", 0x1800, false, RK_HEADER_V1 },
>> +{ "rv1108", "RK11", 0x2000 - 0x800, false, RK_HEADER_V1 },
>>  { "rv1126", "110B", 0x1 - 0x1000, false, RK_HEADER_V1 },
>> -{ "rk3568", "RK35", 0x14000 - 0x1000, false, RK_HEADER_V2 },
>> +{ "rk3568", "RK35", 0x1 - 0x1000, false, RK_HEADER_V2 },
>>   };
>>   
>>   /**



Re: [PATCH 11/13] imx8mm-mx8menlo: Drop SPL_BOARD_INIT

2023-02-16 Thread Marek Vasut

On 2/16/23 15:13, Tom Rini wrote:

On Thu, Feb 16, 2023 at 03:04:35PM +0100, Marek Vasut wrote:

On 2/16/23 04:36, Tom Rini wrote:

On this platform spl_board_init is a call to arch_misc_init which is a
no-op, so drop the CONFIG options.

Cc: Marek Vasut 
Cc: Olaf Mandel 


btw. put those under --- next time, that way they don't end up in commit
message.


Er, did the kernel change expected behavior here?


Er ... wasn't that the case for like a year now ?


Signed-off-by: Tom Rini 


If CAAM is enabled, ARCH_MISC_INIT brings up the CAAM , and this is needed
in SPL for U-Boot authentication using HABv4 . I believe that is why Verdin
spl.c calls it.


Then I'll put doing a follow-up on SPL_BOARD_INIT (which is another
option that shouldn't be directly asked, but select'd when used) for
that case. It fails to build in this series because CAAM isn't enabled
so there's no arch_misc_init.


Just call the arch_board_init unconditionally, the CAAM inside of it is 
already conditional, so the compiler should inline the result if CAAM is 
disabled.


Re: [PATCH v2 17/17] configs: starfive: add starfive_visionfive2_defconfig

2023-02-16 Thread Heinrich Schuchardt

On 1/18/23 09:11, Yanhong Wang wrote:

This is the initial basic config for StarFive VisionFive v2 board. It
includes consol, Norflash, sdio, ddr etc.

Signed-off-by: Yanhong Wang 
---
  configs/starfive_visionfive2_defconfig | 72 ++
  1 file changed, 72 insertions(+)
  create mode 100644 configs/starfive_visionfive2_defconfig

diff --git a/configs/starfive_visionfive2_defconfig 
b/configs/starfive_visionfive2_defconfig
new file mode 100644
index 00..54ae6b2a43
--- /dev/null
+++ b/configs/starfive_visionfive2_defconfig
@@ -0,0 +1,72 @@
+CONFIG_RISCV=y
+CONFIG_SYS_MALLOC_LEN=0x80
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="starfive_visionfive2"
+CONFIG_SPL_TEXT_BASE=0x800
+CONFIG_SYS_PROMPT="StarFive #"
+CONFIG_SPL_MMC=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_TARGET_STARFIVE_VISIONFIVE2=y
+CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000
+CONFIG_ARCH_RV64I=y
+CONFIG_CMODEL_MEDANY=y
+CONFIG_RISCV_SMODE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8000
+CONFIG_FIT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 debug rootwait earlycon=sbi"
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr ${fdtcontroladdr};"
+CONFIG_DEFAULT_FDT_FILE="starfive/starfive_visionfive2.dtb"
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_BSS_START_ADDR=0x804
+CONFIG_SPL_BSS_MAX_SIZE=0x1
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK=0x818
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000
+CONFIG_SYS_SPL_MALLOC_SIZE=0x40
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y


With this patch we get CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=1 
which means that partition 1 on the SD-card is used for main U-Boot. 
This conflicts with the usage of partition number 1 in the Ubuntu 
installer images.


The vendor U-Boot uses CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=2. 
This is not flexible either. But at least it would be compatible with 
the vendor U-Boot.


I think we should extend mmc_load_image_raw_partition() to allow 
specifying a partition type GUID identifying the partition harboring 
main U-Boot. I will send a patch for this.


This partition type GUID must not be 
2E54B353-1271-4842-806F-E436D6AF6985 as that GUID is used to identify SPL.


Best regards

Heinrich



+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_CBSIZE=256
+CONFIG_SYS_PBSIZE=276
+CONFIG_SYS_BOOTM_LEN=0x400
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_CLK_COMPOSITE_CCF=y
+CONFIG_CLK_CCF=y
+CONFIG_CLK_COMPOSITE_CCF=y
+CONFIG_SPL_CLK_JH7110=y
+# CONFIG_I2C is not set
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_SNPS=y
+CONFIG_SF_DEFAULT_SPEED=1
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_ISSI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_PINCTRL=y
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_STARFIVE=y
+# CONFIG_RAM_SIFIVE is not set
+CONFIG_DM_RESET=y
+CONFIG_SYS_NS16550=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_TIMER_EARLY=y
+CONFIG_OF_LIBFDT_OVERLAY=y




Re: [PATCH 11/13] imx8mm-mx8menlo: Drop SPL_BOARD_INIT

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 03:04:35PM +0100, Marek Vasut wrote:
> On 2/16/23 04:36, Tom Rini wrote:
> > On this platform spl_board_init is a call to arch_misc_init which is a
> > no-op, so drop the CONFIG options.
> > 
> > Cc: Marek Vasut 
> > Cc: Olaf Mandel 
> 
> btw. put those under --- next time, that way they don't end up in commit
> message.

Er, did the kernel change expected behavior here?

> > Signed-off-by: Tom Rini 
> 
> If CAAM is enabled, ARCH_MISC_INIT brings up the CAAM , and this is needed
> in SPL for U-Boot authentication using HABv4 . I believe that is why Verdin
> spl.c calls it.

Then I'll put doing a follow-up on SPL_BOARD_INIT (which is another
option that shouldn't be directly asked, but select'd when used) for
that case. It fails to build in this series because CAAM isn't enabled
so there's no arch_misc_init.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] binman: bintool: Add support for tool directories

2023-02-16 Thread Tom Rini
On Thu, Feb 16, 2023 at 04:19:11PM +0530, Neha Malcom Francis wrote:

> Currently, bintool supports external compilable tools as single
> executable files. Adding support for git repos that can be used to run
> non-compilable scripting tools that cannot otherwise be present in
> binman.
> 
> Signed-off-by: Neha Malcom Francis 
> ---
>  tools/binman/bintool.py | 42 ++---
>  tools/patman/tools.py   |  2 ++
>  2 files changed, 37 insertions(+), 7 deletions(-)

This is another reason that the download mechanic really needs to move
out of populating the users bin directory directly.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 11/13] imx8mm-mx8menlo: Drop SPL_BOARD_INIT

2023-02-16 Thread Marek Vasut

On 2/16/23 04:36, Tom Rini wrote:

On this platform spl_board_init is a call to arch_misc_init which is a
no-op, so drop the CONFIG options.

Cc: Marek Vasut 
Cc: Olaf Mandel 


btw. put those under --- next time, that way they don't end up in commit 
message.



Signed-off-by: Tom Rini 


If CAAM is enabled, ARCH_MISC_INIT brings up the CAAM , and this is 
needed in SPL for U-Boot authentication using HABv4 . I believe that is 
why Verdin spl.c calls it.


Re: [PATCH v2 1/6] binman: Add support for a rockchip-tpl entry

2023-02-16 Thread Jonas Karlman
Hi Eugen,

On 2023-02-16 12:26, Eugen Hristev wrote:
> On 2/14/23 12:33, Jonas Karlman wrote:
>> The rockchip-tpl entry can be used when an external TPL binary should be
>> used instead of the normal U-Boot TPL.
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>> v2:
>> - rename external-tpl to rockchip-tpl
>> - missing message moved to this patch
>>
>>   tools/binman/entries.rst   | 14 ++
>>   tools/binman/etype/rockchip_tpl.py | 20 
>>   tools/binman/ftest.py  |  7 +++
>>   tools/binman/missing-blob-help |  5 +
>>   tools/binman/test/277_rockchip_tpl.dts | 16 
>>   5 files changed, 62 insertions(+)
>>   create mode 100644 tools/binman/etype/rockchip_tpl.py
>>   create mode 100644 tools/binman/test/277_rockchip_tpl.dts
> 
> Hi Jonas,
> 
> Is it possible to add the filename 'rockchip-tpl' to gitignore, such 
> that it won't show up all the time when you do git status ?
> (in the case where you place the rockchip-tpl in the same dir )

You should not need to name the file 'rockchip-tpl', instead of placing a
file in your u-boot folder, use the ROCKCHIP_TPL env variable like:

export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.36.elf
export 
ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.09.bin
make

or possible a make argument:

make ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.09.bin

Regards,
Jonas

> 
> Otherwise, I tested your series:
> 
> Tested-by: Eugen Hristev 
> 
> Eugen



[PATCH v2] arm64: zynqmp: Add an OP-TEE node to the device tree

2023-02-16 Thread Ilias Apalodimas
Since the zynqmp boards can run upstream OP-TEE, and having the DT node
present doesn't cause any side effects add it in case someone tries to
load OP-TEE.

Signed-off-by: Ilias Apalodimas 
---
changes since v1:
- move the defintion to the .dtsi covering all zynqmp boards

 arch/arm/dts/zynqmp.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 0a06c73390b2..793ce59d8d94 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -147,6 +147,11 @@
};

firmware {
+   optee: optee  {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
#power-domain-cells = <1>;
--
2.38.1



[PATCH 2/2] board: rock5b-rk3588: add memory gaps into kernel's DTB

2023-02-16 Thread Eugen Hristev
RK3588 has two memory gaps when using 16 GiB DRAM size:
[0x3fc00 , 0x3fc50]
and
[0x3fff0 , 0x3]

If the kernel is agnostic to these gaps, accessing the area causes
a SError panic.

Hence, add reserved memory areas in kernel's DTB before booting.

Signed-off-by: Eugen Hristev 
---

Hi,

These memory gaps are required because the kernel crashes with a SError if
accessing that area.
It appears the ATAGs provide DDR banks that do not include those specific
two regions.
To be able to boot the kernel, those areas have to be reserved.
Maybe someone from Rockchip could have an explanation to this behavior?
Otherwise we have to block them at this level.
If those memory ranges are reserved for a dedicated purpose we can come up
with a better solution, w.r.t. the purpose of the regions.

Thanks !
Eugen

 board/radxa/rock5b-rk3588/rock5b-rk3588.c | 35 +++
 configs/rock5b-rk3588_defconfig   |  1 +
 2 files changed, 36 insertions(+)

diff --git a/board/radxa/rock5b-rk3588/rock5b-rk3588.c 
b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
index b5d74798f3b9..5c3b52b94898 100644
--- a/board/radxa/rock5b-rk3588/rock5b-rk3588.c
+++ b/board/radxa/rock5b-rk3588/rock5b-rk3588.c
@@ -2,3 +2,38 @@
 /*
  * Copyright (c) 2023 Collabora Ltd.
  */
+
+#include 
+#include 
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int rock5b_add_reserved_memory_fdt_nodes(void *new_blob)
+{
+   struct fdt_memory gap1 = {
+   .start = 0x3fc00,
+   .end = 0x3fc4f,
+   };
+   struct fdt_memory gap2 = {
+   .start = 0x3fff0,
+   .end = 0x3,
+   };
+   unsigned long flags = FDTDEC_RESERVED_MEMORY_NO_MAP;
+   unsigned int ret;
+
+   /*
+* Inject the reserved-memory nodes into the DTS
+*/
+   ret = fdtdec_add_reserved_memory(new_blob, "gap1", ,  NULL, 0,
+NULL, flags);
+   if (ret)
+   return ret;
+
+   return fdtdec_add_reserved_memory(new_blob, "gap2", ,  NULL, 0,
+ NULL, flags);
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+   return rock5b_add_reserved_memory_fdt_nodes(blob);
+}
+#endif
diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 9b7db7de64be..f3026c7ea166 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -26,6 +26,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_OF_BOARD_SETUP=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-- 
2.34.1



[PATCH 1/2] board: rockchip: add Radxa ROCK5B Rk3588 board

2023-02-16 Thread Eugen Hristev
ROCK 5B is a Rockchip RK3588 based SBC (Single Board Computer) by Radxa.

There are tree variants depending on the DRAM size : 4G, 8G and 16G.

Specification:

Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
4/8/16GB memory LPDDR4x
Mali G610MC4 GPU
MIPI CSI 2 multiple lanes connector
eMMC module connector
uSD slot (up to 128GB)
2x USB 2.0, 2x USB 3.0
2x HDMI output, 1x HDMI input
Ethernet port
40-pin IO header including UART, SPI, I2C and 5V DC power in
USB PD over USB Type-C
Size: 85mm x 54mm

Signed-off-by: Eugen Hristev 
---

This board comes on top of Jagan's series for adding the rk3588 support:
https://lists.denx.de/pipermail/u-boot/2023-January/506784.html
And Jonas' series of patches that adds support for DDR v3 :
https://lists.denx.de/pipermail/u-boot/2023-January/504923.html
and another series from Jonas about rockchip TPL
https://lists.denx.de/pipermail/u-boot/2023-February/509051.html
And a workaround to make SD-Card 400 kHz clock working from Jonas' private tree

Thanks,
Eugen

 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi   | 22 +++
 arch/arm/dts/rk3588-rock-5b.dts   | 44 ++
 arch/arm/mach-rockchip/rk3588/Kconfig | 26 +
 board/radxa/rock5b-rk3588/Kconfig | 15 +
 board/radxa/rock5b-rk3588/MAINTAINERS |  6 ++
 board/radxa/rock5b-rk3588/Makefile|  6 ++
 board/radxa/rock5b-rk3588/rock5b-rk3588.c |  4 ++
 configs/rock5b-rk3588_defconfig   | 71 +++
 doc/board/rockchip/rockchip.rst   |  1 +
 include/configs/rock5b-rk3588.h   | 15 +
 10 files changed, 210 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-rock-5b.dts
 create mode 100644 board/radxa/rock5b-rk3588/Kconfig
 create mode 100644 board/radxa/rock5b-rk3588/MAINTAINERS
 create mode 100644 board/radxa/rock5b-rk3588/Makefile
 create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c
 create mode 100644 configs/rock5b-rk3588_defconfig
 create mode 100644 include/configs/rock5b-rk3588.h

diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi 
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
new file mode 100644
index ..2386edf90deb
--- /dev/null
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   aliases {
+   mmc0 = 
+   };
+
+   chosen {
+   u-boot,spl-boot-order = 
+   };
+};
+
+ {
+   bus-width = <4>;
+   u-boot,dm-spl;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-rock-5b.dts b/arch/arm/dts/rk3588-rock-5b.dts
new file mode 100644
index ..95805cb0adfa
--- /dev/null
+++ b/arch/arm/dts/rk3588-rock-5b.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588.dtsi"
+
+/ {
+   model = "Radxa ROCK 5 Model B";
+   compatible = "radxa,rock-5b", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+ {
+   bus-width = <8>;
+   no-sdio;
+   no-sd;
+   non-removable;
+   max-frequency = <2>;
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+   status = "okay";
+};
+
+ {
+   pinctrl-0 = <_xfer>;
+   status = "okay";
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index def4094e2e44..aee71ca1dab8 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -13,6 +13,31 @@ config TARGET_RK3588_NEU6
  IO board and Neu6a needs to mount on top of this IO board in order to
  create complete Edgeble Neural Compute Module 6(Neu6) IO platform.
 
+config TARGET_ROCK5B_RK3588
+   bool "Radxa ROCK5B RK3588 board"
+   select BOARD_LATE_INIT
+   help
+ Radxa ROCK5B is a Rockchip RK3588 based SBC (Single Board Computer)
+ by Radxa.
+
+ There are tree variants depending on the DRAM size : 4G, 8G and 16G.
+
+ Specification:
+
+ Rockchip Rk3588 SoC
+ 4x ARM Cortex-A76, 4x ARM Cortex-A55
+ 4/8/16GB memory LPDDR4x
+ Mali G610MC4 GPU
+ MIPI CSI 2 multiple lanes connector
+ eMMC module connector
+ uSD slot (up to 128GB)
+ 2x USB 2.0, 2x USB 3.0
+ 2x HDMI output, 1x HDMI input
+ Ethernet port
+ 40-pin IO header including UART, SPI, I2C and 5V DC 

Re: [PATCH] arm64: zynqmp: Add an OP-TEE node to the device tree

2023-02-16 Thread Ilias Apalodimas
Hi Michal

On Thu, 16 Feb 2023 at 14:59, Michal Simek  wrote:
>
>
>
> On 2/16/23 13:44, Ilias Apalodimas wrote:
> > Since the zynqmp boards can run upstream OP-TEE, and having the DT node
> > present doesn't cause any side effects add it in case someone tries to
> > load OP-TEE.
>
> Then I would expect you will enable it for all boards. It means patch
> zynqmp.dtsi instead of only one board.

Sure

>
> >
> > Signed-off-by: Ilias Apalodimas 
> > ---
> >   arch/arm/dts/zynqmp-sm-k26-revA.dts | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts 
> > b/arch/arm/dts/zynqmp-sm-k26-revA.dts
> > index bae24aabdbd1..8f457f1a449c 100644
> > --- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
> > +++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
> > @@ -45,6 +45,13 @@
> >   stdout-path = "serial1:115200n8";
> >   };
> >
> > + firmware {
> > + optee: optee  {
> > + compatible = "linaro,optee-tz";
> > + method = "smc";
>
> indentation looks weird. Please use only tabs.

Weird, checkpatch didn't complain and I did only use tabs

Cheers
/Ilias

>
> > + };
> > + };
> > +
> >   memory@0 {
> >   device_type = "memory"; /* 4GB */
> >   reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 
> > 0x8000>;
>
> M


Re: [PATCH] arm64: zynqmp: Add an OP-TEE node to the device tree

2023-02-16 Thread Michal Simek




On 2/16/23 13:44, Ilias Apalodimas wrote:

Since the zynqmp boards can run upstream OP-TEE, and having the DT node
present doesn't cause any side effects add it in case someone tries to
load OP-TEE.


Then I would expect you will enable it for all boards. It means patch 
zynqmp.dtsi instead of only one board.




Signed-off-by: Ilias Apalodimas 
---
  arch/arm/dts/zynqmp-sm-k26-revA.dts | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts 
b/arch/arm/dts/zynqmp-sm-k26-revA.dts
index bae24aabdbd1..8f457f1a449c 100644
--- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
+++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
@@ -45,6 +45,13 @@
stdout-path = "serial1:115200n8";
};
  
+	firmware {

+   optee: optee  {
+   compatible = "linaro,optee-tz";
+   method = "smc";


indentation looks weird. Please use only tabs.


+   };
+   };
+
memory@0 {
device_type = "memory"; /* 4GB */
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;


M


[PATCH] arm64: zynqmp: Add an OP-TEE node to the device tree

2023-02-16 Thread Ilias Apalodimas
Since the zynqmp boards can run upstream OP-TEE, and having the DT node
present doesn't cause any side effects add it in case someone tries to
load OP-TEE.

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/dts/zynqmp-sm-k26-revA.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts 
b/arch/arm/dts/zynqmp-sm-k26-revA.dts
index bae24aabdbd1..8f457f1a449c 100644
--- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
+++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
@@ -45,6 +45,13 @@
stdout-path = "serial1:115200n8";
};
 
+   firmware {
+   optee: optee  {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+
memory@0 {
device_type = "memory"; /* 4GB */
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
-- 
2.38.1



Re: [PATCH 10/13] verdin-imx8mm: Remove unused SPL_BOARD_INIT

2023-02-16 Thread Marcel Ziswiler
On Wed, 2023-02-15 at 22:36 -0500, Tom Rini wrote:
> On this platform SPL_BOARD_INIT is used to call arch_misc_init which is
> in turn empty, drop the call.
> 
> Cc: Marcel Ziswiler 
> Signed-off-by: Tom Rini 

Acked-by: Marcel Ziswiler 

> ---
>  board/toradex/verdin-imx8mm/spl.c | 5 -
>  configs/verdin-imx8mm_defconfig   | 1 -
>  2 files changed, 6 deletions(-)
> 
> diff --git a/board/toradex/verdin-imx8mm/spl.c 
> b/board/toradex/verdin-imx8mm/spl.c
> index 9d54d60bb17d..3f33ff7d87a4 100644
> --- a/board/toradex/verdin-imx8mm/spl.c
> +++ b/board/toradex/verdin-imx8mm/spl.c
> @@ -51,11 +51,6 @@ void spl_dram_init(void)
> ddr_init(_timing);
>  }
>  
> -void spl_board_init(void)
> -{
> -   arch_misc_init();
> -}
> -
>  #ifdef CONFIG_SPL_LOAD_FIT
>  int board_fit_config_name_match(const char *name)
>  {
> diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
> index 5b5f7c051e54..0e7d67cf093d 100644
> --- a/configs/verdin-imx8mm_defconfig
> +++ b/configs/verdin-imx8mm_defconfig
> @@ -40,7 +40,6 @@ CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
>  CONFIG_SPL_BSS_START_ADDR=0x91
>  CONFIG_SPL_BSS_MAX_SIZE=0x2000
> -CONFIG_SPL_BOARD_INIT=y
>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>  CONFIG_SPL_STACK=0x92
>  CONFIG_SYS_SPL_MALLOC=y


Re: [PATCH v1] configs: verdin-imx8mp: Fix wrong early malloc() heap size

2023-02-16 Thread Marcel Ziswiler
On Thu, 2023-02-16 at 12:31 +0100, Francesco Dolcini wrote:
> From: Emanuele Ghidoli 
> 
> Set, previously unset, CONFIG_SPL_SYS_MALLOC_F_LEN to 0x4000 whose
> default value is 0x1.
> Early malloc() uses CRAM_S at 0x184000 (CFG_MALLOC_F_ADDR), this ram
> area end at 0x188000.
> 
> Fixes: 2bc2f817cea7 ("board: toradex: add verdin imx8m plus support")
> Signed-off-by: Emanuele Ghidoli 
> Signed-off-by: Francesco Dolcini 

Acked-by: Marcel Ziswiler 

> ---
>  configs/verdin-imx8mp_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/verdin-imx8mp_defconfig b/configs/verdin-imx8mp_defconfig
> index 153c7c15197d..90588bfbd29f 100644
> --- a/configs/verdin-imx8mp_defconfig
> +++ b/configs/verdin-imx8mp_defconfig
> @@ -51,6 +51,7 @@ CONFIG_SPL_BOOTROM_SUPPORT=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>  CONFIG_SPL_STACK=0x96
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
>  CONFIG_SYS_SPL_MALLOC=y
>  CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
>  CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220


Re: [PATCH V2 7/9] gpio/rockchip: rk_gpio support v2 gpio controller

2023-02-16 Thread FUKAUMI Naoki

hi,

On 2/14/23 07:27, Chris Morgan wrote:

From: Chris Morgan 

Add support for the newer GPIO controller used by the rk356x series,
as well as the pinctrl device for the rk356x series. The GPIOv2
controller has a write enable bit for some registers which differs
from the older versions of the GPIO controller.

Signed-off-by: Peter Geis 
Signed-off-by: Chris Morgan 
---
  arch/arm/include/asm/arch-rockchip/gpio.h |  38 ++
  drivers/gpio/rk_gpio.c|  49 +-
  drivers/pinctrl/rockchip/Makefile |   1 +
  drivers/pinctrl/rockchip/pinctrl-rk3568.c | 453 ++
  .../pinctrl/rockchip/pinctrl-rockchip-core.c  |  12 +-
  5 files changed, 540 insertions(+), 13 deletions(-)
  create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3568.c

diff --git a/arch/arm/include/asm/arch-rockchip/gpio.h 
b/arch/arm/include/asm/arch-rockchip/gpio.h
index 1aaec5faec..15f5de321b 100644
--- a/arch/arm/include/asm/arch-rockchip/gpio.h
+++ b/arch/arm/include/asm/arch-rockchip/gpio.h
@@ -6,6 +6,7 @@
  #ifndef _ASM_ARCH_GPIO_H
  #define _ASM_ARCH_GPIO_H
  
+#if !defined(CONFIG_ROCKCHIP_RK3568)

  struct rockchip_gpio_regs {
u32 swport_dr;
u32 swport_ddr;
@@ -22,7 +23,44 @@ struct rockchip_gpio_regs {
u32 reserved1[(0x60 - 0x54) / 4];
u32 ls_sync;
  };
+
  check_member(rockchip_gpio_regs, ls_sync, 0x60);
+#else
+struct rockchip_gpio_regs {
+   u32 swport_dr_l;/* ADDRESS OFFSET: 0x */
+   u32 swport_dr_h;/* ADDRESS OFFSET: 0x0004 */
+   u32 swport_ddr_l;   /* ADDRESS OFFSET: 0x0008 */
+   u32 swport_ddr_h;   /* ADDRESS OFFSET: 0x000c */
+   u32 int_en_l;   /* ADDRESS OFFSET: 0x0010 */
+   u32 int_en_h;   /* ADDRESS OFFSET: 0x0014 */
+   u32 int_mask_l; /* ADDRESS OFFSET: 0x0018 */
+   u32 int_mask_h; /* ADDRESS OFFSET: 0x001c */
+   u32 int_type_l; /* ADDRESS OFFSET: 0x0020 */
+   u32 int_type_h; /* ADDRESS OFFSET: 0x0024 */
+   u32 int_polarity_l; /* ADDRESS OFFSET: 0x0028 */
+   u32 int_polarity_h; /* ADDRESS OFFSET: 0x002c */
+   u32 int_bothedge_l; /* ADDRESS OFFSET: 0x0030 */
+   u32 int_bothedge_h; /* ADDRESS OFFSET: 0x0034 */
+   u32 debounce_l; /* ADDRESS OFFSET: 0x0038 */
+   u32 debounce_h; /* ADDRESS OFFSET: 0x003c */
+   u32 dbclk_div_en_l; /* ADDRESS OFFSET: 0x0040 */
+   u32 dbclk_div_en_h; /* ADDRESS OFFSET: 0x0044 */
+   u32 dbclk_div_con;  /* ADDRESS OFFSET: 0x0048 */
+   u32 reserved004c;   /* ADDRESS OFFSET: 0x004c */
+   u32 int_status; /* ADDRESS OFFSET: 0x0050 */
+   u32 reserved0054;   /* ADDRESS OFFSET: 0x0054 */
+   u32 int_rawstatus;  /* ADDRESS OFFSET: 0x0058 */
+   u32 reserved005c;   /* ADDRESS OFFSET: 0x005c */
+   u32 port_eoi_l; /* ADDRESS OFFSET: 0x0060 */
+   u32 port_eoi_h; /* ADDRESS OFFSET: 0x0064 */
+   u32 reserved0068[2];/* ADDRESS OFFSET: 0x0068 */
+   u32 ext_port;   /* ADDRESS OFFSET: 0x0070 */
+   u32 reserved0074;   /* ADDRESS OFFSET: 0x0074 */
+   u32 ver_id; /* ADDRESS OFFSET: 0x0078 */
+};
+
+check_member(rockchip_gpio_regs, ver_id, 0x0078);
+#endif
  
  enum gpio_pu_pd {

GPIO_PULL_NORMAL = 0,
diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 98a79b5f4d..e2653be058 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -2,12 +2,15 @@
  /*
   * (C) Copyright 2015 Google, Inc
   *
- * (C) Copyright 2008-2014 Rockchip Electronics
+ * (C) Copyright 2008-2023 Rockchip Electronics
   * Peter, Software Engineering, .
+ * Jianqun Xu, Software Engineering, .
   */
  
  #include 

  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -23,6 +26,35 @@ enum {
  
  #define OFFSET_TO_BIT(bit)	(1UL << (bit))
  
+/*

+ * Newer Rockchip devices have additional registers that must be
+ * accounted for.
+ */
+#if defined(CONFIG_ROCKCHIP_RK3568)
+#define GPIO_VER   2
+#define REG_L(R)   (R##_l)
+#define REG_H(R)   (R##_h)
+#define READ_REG(REG)  ((readl(REG_L(REG)) & 0x) | \
+   ((readl(REG_H(REG)) & 0x) << 16))
+#define WRITE_REG(REG, VAL)\
+{\
+   writel(((VAL) & 0x) | 0x, REG_L(REG)); \
+   writelVAL) & 0x) >> 16) | 0x, REG_H(REG));\
+}
+#define CLRBITS_LE32(REG, MASK)WRITE_REG(REG, 

Re: [PATCH v1 11/18] arm64: dts: rockchip: Add base DT for rk3588 SoC

2023-02-16 Thread Kever Yang



On 2023/1/30 22:57, Jagan Teki wrote:

This initial version supports CPU, dma, interrupts, timers, UART and
SDHCI (everything necessary to boot Linux on this system on chip) as
well as Ethernet, I2C, PWM and SPI.

The DT is split into rk3588 and rk3588s, which is a reduced version
(i.e. with less peripherals) of the former.

commit <9fb232e9911f> (" arm64: dts: rockchip: Add base DT for rk3588
SoC")
commit  ("arm64: dts: rockchip: Add rk3588 pinctrl data")

Signed-off-by: Jianqun Xu 
Signed-off-by: Kever Yang 
Signed-off-by: Jagan Teki 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3588-pinctrl.dtsi  |  516 +
  arch/arm/dts/rk3588.dtsi  |   58 +
  arch/arm/dts/rk3588s-pinctrl.dtsi | 3403 +
  arch/arm/dts/rk3588s.dtsi | 1703 +++
  4 files changed, 5680 insertions(+)
  create mode 100644 arch/arm/dts/rk3588-pinctrl.dtsi
  create mode 100644 arch/arm/dts/rk3588.dtsi
  create mode 100644 arch/arm/dts/rk3588s-pinctrl.dtsi
  create mode 100644 arch/arm/dts/rk3588s.dtsi

diff --git a/arch/arm/dts/rk3588-pinctrl.dtsi b/arch/arm/dts/rk3588-pinctrl.dtsi
new file mode 100644
index 00..244c66faa1
--- /dev/null
+++ b/arch/arm/dts/rk3588-pinctrl.dtsi
@@ -0,0 +1,516 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+ {
+   clk32k {
+   /omit-if-no-ref/
+   clk32k_out1: clk32k-out1 {
+   rockchip,pins =
+   /* clk32k_out1 */
+   <2 RK_PC5 1 _pull_none>;
+   };
+
+   };
+
+   eth0 {
+   /omit-if-no-ref/
+   eth0_pins: eth0-pins {
+   rockchip,pins =
+   /* eth0_refclko_25m */
+   <2 RK_PC3 1 _pull_none>;
+   };
+
+   };
+
+   fspi {
+   /omit-if-no-ref/
+   fspim1_pins: fspim1-pins {
+   rockchip,pins =
+   /* fspi_clk_m1 */
+   <2 RK_PB3 3 _pull_up_drv_level_2>,
+   /* fspi_cs0n_m1 */
+   <2 RK_PB4 3 _pull_up_drv_level_2>,
+   /* fspi_d0_m1 */
+   <2 RK_PA6 3 _pull_up_drv_level_2>,
+   /* fspi_d1_m1 */
+   <2 RK_PA7 3 _pull_up_drv_level_2>,
+   /* fspi_d2_m1 */
+   <2 RK_PB0 3 _pull_up_drv_level_2>,
+   /* fspi_d3_m1 */
+   <2 RK_PB1 3 _pull_up_drv_level_2>;
+   };
+
+   /omit-if-no-ref/
+   fspim1_cs1: fspim1-cs1 {
+   rockchip,pins =
+   /* fspi_cs1n_m1 */
+   <2 RK_PB5 3 _pull_up_drv_level_2>;
+   };
+   };
+
+   gmac0 {
+   /omit-if-no-ref/
+   gmac0_miim: gmac0-miim {
+   rockchip,pins =
+   /* gmac0_mdc */
+   <4 RK_PC4 1 _pull_none>,
+   /* gmac0_mdio */
+   <4 RK_PC5 1 _pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_clkinout: gmac0-clkinout {
+   rockchip,pins =
+   /* gmac0_mclkinout */
+   <4 RK_PC3 1 _pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_rx_bus2: gmac0-rx-bus2 {
+   rockchip,pins =
+   /* gmac0_rxd0 */
+   <2 RK_PC1 1 _pull_none>,
+   /* gmac0_rxd1 */
+   <2 RK_PC2 1 _pull_none>,
+   /* gmac0_rxdv_crs */
+   <4 RK_PC2 1 _pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_tx_bus2: gmac0-tx-bus2 {
+   rockchip,pins =
+   /* gmac0_txd0 */
+   <2 RK_PB6 1 _pull_none>,
+   /* gmac0_txd1 */
+   <2 RK_PB7 1 _pull_none>,
+   /* gmac0_txen */
+   <2 RK_PC0 1 _pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_rgmii_clk: gmac0-rgmii-clk {
+   rockchip,pins =
+   /* gmac0_rxclk */
+   <2 RK_PB0 1 _pull_none>,
+ 

Re: [U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's

2023-02-16 Thread Mary Lee Russo White
Have a good day--
Thank you,

Mary Lee Russo White


[PATCH v1] configs: verdin-imx8mp: Fix wrong early malloc() heap size

2023-02-16 Thread Francesco Dolcini
From: Emanuele Ghidoli 

Set, previously unset, CONFIG_SPL_SYS_MALLOC_F_LEN to 0x4000 whose
default value is 0x1.
Early malloc() uses CRAM_S at 0x184000 (CFG_MALLOC_F_ADDR), this ram
area end at 0x188000.

Fixes: 2bc2f817cea7 ("board: toradex: add verdin imx8m plus support")
Signed-off-by: Emanuele Ghidoli 
Signed-off-by: Francesco Dolcini 
---
 configs/verdin-imx8mp_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/verdin-imx8mp_defconfig b/configs/verdin-imx8mp_defconfig
index 153c7c15197d..90588bfbd29f 100644
--- a/configs/verdin-imx8mp_defconfig
+++ b/configs/verdin-imx8mp_defconfig
@@ -51,6 +51,7 @@ CONFIG_SPL_BOOTROM_SUPPORT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK=0x96
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
 CONFIG_SYS_SPL_MALLOC=y
 CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
 CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220
-- 
2.25.1



Re: [PATCH v2 1/6] binman: Add support for a rockchip-tpl entry

2023-02-16 Thread Eugen Hristev

On 2/14/23 12:33, Jonas Karlman wrote:

The rockchip-tpl entry can be used when an external TPL binary should be
used instead of the normal U-Boot TPL.

Signed-off-by: Jonas Karlman 
---
v2:
- rename external-tpl to rockchip-tpl
- missing message moved to this patch

  tools/binman/entries.rst   | 14 ++
  tools/binman/etype/rockchip_tpl.py | 20 
  tools/binman/ftest.py  |  7 +++
  tools/binman/missing-blob-help |  5 +
  tools/binman/test/277_rockchip_tpl.dts | 16 
  5 files changed, 62 insertions(+)
  create mode 100644 tools/binman/etype/rockchip_tpl.py
  create mode 100644 tools/binman/test/277_rockchip_tpl.dts


Hi Jonas,

Is it possible to add the filename 'rockchip-tpl' to gitignore, such 
that it won't show up all the time when you do git status ?

(in the case where you place the rockchip-tpl in the same dir )

Otherwise, I tested your series:

Tested-by: Eugen Hristev 

Eugen


[PATCH] binman: bintool: Add support for tool directories

2023-02-16 Thread Neha Malcom Francis
Currently, bintool supports external compilable tools as single
executable files. Adding support for git repos that can be used to run
non-compilable scripting tools that cannot otherwise be present in
binman.

Signed-off-by: Neha Malcom Francis 
---
 tools/binman/bintool.py | 42 ++---
 tools/patman/tools.py   |  2 ++
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 8fda13ff01..a1e37699aa 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -32,12 +32,13 @@ FORMAT = '%-16.16s %-12.12s %-26.26s %s'
 modules = {}
 
 # Possible ways of fetching a tool (FETCH_COUNT is number of ways)
-FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_COUNT = range(4)
+FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_NO_BUILD, FETCH_COUNT = range(5)
 
 FETCH_NAMES = {
 FETCH_ANY: 'any method',
 FETCH_BIN: 'binary download',
-FETCH_BUILD: 'build from source'
+FETCH_BUILD: 'build from source',
+FETCH_NO_BUILD: 'download source without building'
 }
 
 # Status of tool fetching
@@ -206,7 +207,7 @@ class Bintool:
 result = try_fetch(method)
 if not result:
 return FAIL
-if result is not True:
+if result is not True and method != FETCH_NO_BUILD:
 fname, tmpdir = result
 dest = os.path.join(DOWNLOAD_DESTDIR, self.name)
 print(f"- writing to '{dest}'")
@@ -261,7 +262,7 @@ class Bintool:
 show_status(col.RED, 'Failures', status[FAIL])
 return not status[FAIL]
 
-def run_cmd_result(self, *args, binary=False, raise_on_error=True):
+def run_cmd_result(self, *args, binary=False, raise_on_error=True, 
add_name=True):
 """Run the bintool using command-line arguments
 
 Args:
@@ -278,7 +279,10 @@ class Bintool:
 if self.name in self.missing_list:
 return None
 name = os.path.expanduser(self.name)  # Expand paths containing ~
-all_args = (name,) + args
+if add_name:
+all_args = (name,) + args
+else:
+all_args = args
 env = tools.get_env_with_path()
 tout.detail(f"bintool: {' '.join(all_args)}")
 result = command.run_pipe(
@@ -304,7 +308,7 @@ class Bintool:
 tout.debug(result.stderr)
 return result
 
-def run_cmd(self, *args, binary=False):
+def run_cmd(self, *args, binary=False, add_name=True):
 """Run the bintool using command-line arguments
 
 Args:
@@ -315,7 +319,7 @@ class Bintool:
 Returns:
 str or bytes: Resulting stdout from the bintool
 """
-result = self.run_cmd_result(*args, binary=binary)
+result = self.run_cmd_result(*args, binary=binary, add_name=add_name)
 if result:
 return result.stdout
 
@@ -354,6 +358,30 @@ class Bintool:
 return None
 return fname, tmpdir
 
+@classmethod
+def fetch_from_git(cls, git_repo):
+"""Fetch a bintool git repo
+
+This clones the repo and returns
+
+Args:
+git_repo (str): URL of git repo
+bintool_path (str): Relative path of the tool in the repo, after
+build is complete
+
+Returns:
+str: Directory of fetched repo
+or None on error
+"""
+dir = os.path.join(DOWNLOAD_DESTDIR, cls.name)
+os.mkdir(dir)
+print(f"- clone git repo '{git_repo}' to '{dir}'")
+tools.run('git', 'clone', '--depth', '1', git_repo, dir)
+if not os.path.exists(dir):
+print(f"- Repo '{dir}' was not produced")
+return None
+return dir
+
 @classmethod
 def fetch_from_url(cls, url):
 """Fetch a bintool from a URL
diff --git a/tools/patman/tools.py b/tools/patman/tools.py
index 2ac814d476..b8533c72b2 100644
--- a/tools/patman/tools.py
+++ b/tools/patman/tools.py
@@ -399,6 +399,8 @@ def tool_find(name):
 fname = os.path.join(path, name)
 if os.path.isfile(fname) and os.access(fname, os.X_OK):
 return fname
+if os.path.isdir(fname) and os.access(fname, os.X_OK):
+return fname
 
 def run(name, *args, **kwargs):
 """Run a tool with some arguments
-- 
2.34.1



[PATCH 1/2] mx6sabreauto: Convert to DM_PMIC

2023-02-16 Thread Fabio Estevam
The usage of DM_PMIC is preferred, so convert to it.

This also brings the benefit of causing a significant amount
of code removal.

Signed-off-by: Fabio Estevam 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabreauto/mx6sabreauto.c | 109 +++-
 configs/mx6sabreauto_defconfig  |  13 +--
 include/configs/mx6sabreauto.h  |   3 -
 3 files changed, 19 insertions(+), 106 deletions(-)

diff --git a/board/freescale/mx6sabreauto/mx6sabreauto.c 
b/board/freescale/mx6sabreauto/mx6sabreauto.c
index 9155dcfbd0..0ae86f42df 100644
--- a/board/freescale/mx6sabreauto/mx6sabreauto.c
+++ b/board/freescale/mx6sabreauto/mx6sabreauto.c
@@ -19,14 +19,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -49,23 +47,15 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
 
-#define I2C_PAD_CTRL   (PAD_CTL_PUS_100K_UP |  \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
-
 #define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_100K_UP)
 #define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \
PAD_CTL_SRE_FAST)
 #define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1)
 
-#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-
 #define WEIM_NOR_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |  \
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST)
 
-#define I2C_PMIC   1
-
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -78,70 +68,6 @@ static iomux_v3_cfg_t const uart4_pads[] = {
IOMUX_PADS(PAD_KEY_ROW0__UART4_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
 };
 
-
-/* I2C2 PMIC, iPod, Tuner, Codec, Touch, HDMI EDID, MIPI CSI2 card */
-static struct i2c_pads_info mx6q_i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX6Q_PAD_EIM_EB2__I2C2_SCL | PC,
-   .gpio_mode = MX6Q_PAD_EIM_EB2__GPIO2_IO30 | PC,
-   .gp = IMX_GPIO_NR(2, 30)
-   },
-   .sda = {
-   .i2c_mode = MX6Q_PAD_KEY_ROW3__I2C2_SDA | PC,
-   .gpio_mode = MX6Q_PAD_KEY_ROW3__GPIO4_IO13 | PC,
-   .gp = IMX_GPIO_NR(4, 13)
-   }
-};
-
-static struct i2c_pads_info mx6dl_i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX6DL_PAD_EIM_EB2__I2C2_SCL | PC,
-   .gpio_mode = MX6DL_PAD_EIM_EB2__GPIO2_IO30 | PC,
-   .gp = IMX_GPIO_NR(2, 30)
-   },
-   .sda = {
-   .i2c_mode = MX6DL_PAD_KEY_ROW3__I2C2_SDA | PC,
-   .gpio_mode = MX6DL_PAD_KEY_ROW3__GPIO4_IO13 | PC,
-   .gp = IMX_GPIO_NR(4, 13)
-   }
-};
-
-#ifndef CONFIG_SYS_FLASH_CFI
-/*
- * I2C3 MLB, Port Expanders (A, B, C), Video ADC, Light Sensor,
- * Compass Sensor, Accelerometer, Res Touch
- */
-static struct i2c_pads_info mx6q_i2c_pad_info2 = {
-   .scl = {
-   .i2c_mode = MX6Q_PAD_GPIO_3__I2C3_SCL | PC,
-   .gpio_mode = MX6Q_PAD_GPIO_3__GPIO1_IO03 | PC,
-   .gp = IMX_GPIO_NR(1, 3)
-   },
-   .sda = {
-   .i2c_mode = MX6Q_PAD_EIM_D18__I2C3_SDA | PC,
-   .gpio_mode = MX6Q_PAD_EIM_D18__GPIO3_IO18 | PC,
-   .gp = IMX_GPIO_NR(3, 18)
-   }
-};
-
-static struct i2c_pads_info mx6dl_i2c_pad_info2 = {
-   .scl = {
-   .i2c_mode = MX6DL_PAD_GPIO_3__I2C3_SCL | PC,
-   .gpio_mode = MX6DL_PAD_GPIO_3__GPIO1_IO03 | PC,
-   .gp = IMX_GPIO_NR(1, 3)
-   },
-   .sda = {
-   .i2c_mode = MX6DL_PAD_EIM_D18__I2C3_SDA | PC,
-   .gpio_mode = MX6DL_PAD_EIM_D18__GPIO3_IO18 | PC,
-   .gp = IMX_GPIO_NR(3, 18)
-   }
-};
-#endif
-
-static iomux_v3_cfg_t const i2c3_pads[] = {
-   IOMUX_PADS(PAD_EIM_A24__GPIO5_IO04  | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
 static iomux_v3_cfg_t const port_exp[] = {
IOMUX_PADS(PAD_SD2_DAT0__GPIO1_IO15 | MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
@@ -516,21 +442,10 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
-   /* I2C 2 and 3 setup - I2C 3 hw mux with EIM */
-   if (is_mx6dq() || is_mx6dqp())
-   setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
-   else
-   setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
/* I2C 3 Steer */
gpio_request(IMX_GPIO_NR(5, 4), "steer logic");
gpio_direction_output(IMX_GPIO_NR(5, 4), 1);
-   SETUP_IOMUX_PADS(i2c3_pads);
-#ifndef CONFIG_SYS_FLASH_CFI
-   if (is_mx6dq() || is_mx6dqp())
-   setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
-   else
-   setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
-#endif
+

[PATCH 2/2] mx6sabresd: Convert to DM_PMIC

2023-02-16 Thread Fabio Estevam
The usage of DM_PMIC is preferred, so convert to it.

This also brings the benefit of causing a significant amount
of code removal.

Signed-off-by: Fabio Estevam 
Reviewed-by: Peng Fan 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 63 +
 configs/mx6sabresd_defconfig| 11 ++---
 include/configs/mx6sabresd.h|  3 --
 3 files changed, 17 insertions(+), 60 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 8c35230855..96a76b0581 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -28,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -49,14 +47,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
  PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
 
-#define I2C_PAD_CTRL  (PAD_CTL_PUS_100K_UP |   \
-   PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE | PAD_CTL_SRE_FAST)
-
-#define I2C_PMIC   1
-
-#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL)
-
 #define DISP0_PWR_EN   IMX_GPIO_NR(1, 21)
 
 #define KEY_VOL_UP IMX_GPIO_NR(1, 4)
@@ -174,32 +164,6 @@ static void enable_lvds(struct display_info_t const *dev)
enable_backlight();
 }
 
-static struct i2c_pads_info mx6q_i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX6Q_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
-   .gpio_mode = MX6Q_PAD_KEY_COL3__GPIO4_IO12 | I2C_PAD,
-   .gp = IMX_GPIO_NR(4, 12)
-   },
-   .sda = {
-   .i2c_mode = MX6Q_PAD_KEY_ROW3__I2C2_SDA | I2C_PAD,
-   .gpio_mode = MX6Q_PAD_KEY_ROW3__GPIO4_IO13 | I2C_PAD,
-   .gp = IMX_GPIO_NR(4, 13)
-   }
-};
-
-static struct i2c_pads_info mx6dl_i2c_pad_info1 = {
-   .scl = {
-   .i2c_mode = MX6DL_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
-   .gpio_mode = MX6DL_PAD_KEY_COL3__GPIO4_IO12 | I2C_PAD,
-   .gp = IMX_GPIO_NR(4, 12)
-   },
-   .sda = {
-   .i2c_mode = MX6DL_PAD_KEY_ROW3__I2C2_SDA | I2C_PAD,
-   .gpio_mode = MX6DL_PAD_KEY_ROW3__GPIO4_IO13 | I2C_PAD,
-   .gp = IMX_GPIO_NR(4, 13)
-   }
-};
-
 static void setup_spi(void)
 {
SETUP_IOMUX_PADS(ecspi1_pads);
@@ -495,10 +459,7 @@ int board_init(void)
 #ifdef CONFIG_MXC_SPI
setup_spi();
 #endif
-   if (is_mx6dq() || is_mx6dqp())
-   setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
-   else
-   setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
+
 #if defined(CONFIG_VIDEO_IPUV3)
setup_display();
 #endif
@@ -511,29 +472,32 @@ int board_init(void)
 
 int power_init_board(void)
 {
-   struct pmic *p;
+   struct udevice *dev;
unsigned int reg;
int ret;
 
-   p = pfuze_common_init(I2C_PMIC);
-   if (!p)
-   return -ENODEV;
+   ret = pmic_get("pfuze100@8", );
+   if (ret == -ENODEV)
+   return 0;
+
+   if (ret != 0)
+   return ret;
 
-   ret = pfuze_mode_init(p, APS_PFM);
+   ret = pfuze_mode_init(dev, APS_PFM);
if (ret < 0)
return ret;
 
/* Increase VGEN3 from 2.5 to 2.8V */
-   pmic_reg_read(p, PFUZE100_VGEN3VOL, );
+   reg = pmic_reg_read(dev, PFUZE100_VGEN3VOL);
reg &= ~LDO_VOL_MASK;
reg |= LDOB_2_80V;
-   pmic_reg_write(p, PFUZE100_VGEN3VOL, reg);
+   pmic_reg_write(dev, PFUZE100_VGEN3VOL, reg);
 
/* Increase VGEN5 from 2.8 to 3V */
-   pmic_reg_read(p, PFUZE100_VGEN5VOL, );
+   reg = pmic_reg_read(dev, PFUZE100_VGEN5VOL);
reg &= ~LDO_VOL_MASK;
reg |= LDOB_3_00V;
-   pmic_reg_write(p, PFUZE100_VGEN5VOL, reg);
+   pmic_reg_write(dev, PFUZE100_VGEN5VOL, reg);
 
return 0;
 }
@@ -902,7 +866,6 @@ void board_init_f(ulong dummy)
ccgr_init();
gpr_init();
 
-   /* iomux and setup of i2c */
board_early_init_f();
 
/* setup GP timer */
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 6905850083..0033a0e50a 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -11,9 +11,6 @@ CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0xC
 CONFIG_MX6QDL=y
 CONFIG_TARGET_MX6SABRESD=y
-CONFIG_SYS_I2C_MXC_I2C1=y
-CONFIG_SYS_I2C_MXC_I2C2=y
-CONFIG_SYS_I2C_MXC_I2C3=y
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd"
 CONFIG_SPL_TEXT_BASE=0x00908000
@@ -83,7 +80,6 @@ CONFIG_FASTBOOT_BUF_SIZE=0x1000
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=2
 CONFIG_DM_I2C=y
-CONFIG_SPL_SYS_I2C_LEGACY=y
 CONFIG_SYS_I2C_MXC=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_FSL_USDHC=y
@@ -101,11 +97,12 @@ CONFIG_PCI_SCAN_SHOW=y
 CONFIG_PCIE_IMX=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y

[PATCH] efi_loader: efi_allocate_pages: check parameter pages

2023-02-16 Thread Peng Fan (OSS)
From: Peng Fan 

On i.MX8MM-EVK, when doing UEFI Capsule On Disk, we met such issue,
It will create Boot option for capsule on disk:
Boot: 
VenHw(E61D73B9-A384-4ACC-AEAB-82E828F3628B)/eMMC(0x2)/eMMC(0x1)/HD(1,GPT,F5CC8412-CD9F-4C9E-A782-0E945461E89E,0x800,0x32000)
But when capsule update finished, the updated image booting will trigger:
Loading Boot 'UEFI Capsule On Disk' failed
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
"Synchronous Abort" handler, esr 0x9604
elr: 4029f40c lr : 402802f0 (reloc)
elr: bcd8b40c lr : bcd6c2f0
x0 : 02029ee86154940e x1 : bcd95458
x2 : 0010 x3 : bad31ad0
x4 :  x5 : 02029ee86154940e
x6 : 07f0 x7 : 0007
x8 : 0009 x9 : 0008
x10: 0035 x11: 0010
x12: 0022 x13: 0001
x14: bacdedf0 x15: 0021
x16: bcd304d0 x17: 41a0
x18: bacebdb0 x19: b9c9f040
x20: bccecb28 x21: bcd95458
x22: 0001 x23: bad1f010
x24: bcdced70 x25: 1000
x26: b9c9e000 x27: 4000
x28: 0001 x29: bacdd030

If is the pages is 0, the efi_find_free_memory will return the next used
memory, check the parameter pages, and return EFI_INVALID_PARAMETER if it
is 0.

Reviewed-by: Ye Li 
Reported-by: Vincent Stehlé 
Signed-off-by: Peng Fan 
---
 lib/efi_loader/efi_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index b7bee98f79c..acca542033d 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -495,6 +495,9 @@ efi_status_t efi_allocate_pages(enum efi_allocate_type type,
if (!memory)
return EFI_INVALID_PARAMETER;
 
+   if (!pages)
+   return EFI_INVALID_PARAMETER;
+
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
-- 
2.36.0



Re: [ANN] U-Boot v2023.04-rc2 released

2023-02-16 Thread Michal Simek

Hi Tom,

On 2/14/23 00:39, Tom Rini wrote:

Hey all,

It's the scheduled day for -rc2, and I've waited until the end of my
day, to give the most time for more PRs to come in. Between -rc1 and now
I've gone over my queue, looked over a few other things and tried to
make sure everything I could take in, was taken in. I'm now going to try
and follow through on what I've said and ask that PRs from here to
release contain fixes. I can see "remove unmaintained code" as a fix,
but not "add missing platform" as a fix. With that, I'll be updating the
next branch shortly and we'll take things from there.

In terms of a changelog,
git log --merges v2023.04-rc1..v2023.04-rc2
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

Continuing on schedule now and that means the rest of the rcs every
other Monday, and with final release on April 3rd, 2023.  Thanks all!



can you please also resync defconfigs?

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs



Re: [PATCH 03/13] arm: zynq: Move to select'ing ARCH_EARLY_INIT_R if we have FPGA

2023-02-16 Thread Michal Simek




On 2/16/23 04:36, Tom Rini wrote:

The function arch_early_init_r only does anything on these platforms if
we have FPGA (or SPL and SPL_FPGA) enabled, so move the logic to select
based on that.

Cc: Michal Simek 
Signed-off-by: Tom Rini 
---
  arch/arm/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 724cbdde257c..c51f15fcf465 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1209,6 +1209,7 @@ config ARCH_VF610
  config ARCH_ZYNQ
bool "Xilinx Zynq based platform"
select ARM_TWD_TIMER
+   select ARCH_EARLY_INIT_R if FPGA || (SPL && SPL_FPGA)
select CLK
select CLK_ZYNQ
select CPU_V7A
@@ -1230,7 +1231,6 @@ config ARCH_ZYNQ
select SPL_TIMER if SPL
select SUPPORT_SPL
select TIMER
-   imply ARCH_EARLY_INIT_R
imply BOARD_LATE_INIT
imply CMD_CLK
imply CMD_DM


Reviewed-by: Michal Simek 

Thanks,
Michal


Re: [PATCH v1 05/18] clk: rockchip: Add rk3588 clk support

2023-02-16 Thread Eugen Hristev

On 2/16/23 11:02, Jagan Teki wrote:

Hi Eugen,

On Thu, 16 Feb 2023 at 14:30, Eugen Hristev  wrote:


On 1/30/23 16:57, Jagan Teki wrote:

Add clock driver support for Rockchip RK3588 SoC.

Signed-off-by: Elaine Zhang 
Signed-off-by: Jagan Teki 
---
   drivers/clk/rockchip/Makefile |1 +
   drivers/clk/rockchip/clk_rk3588.c | 1996 +
   2 files changed, 1997 insertions(+)
   create mode 100644 drivers/clk/rockchip/clk_rk3588.c

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f719f4e379..9e379cc2e3 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -16,5 +16,6 @@ obj-$(CONFIG_ROCKCHIP_RK3328) += clk_rk3328.o
   obj-$(CONFIG_ROCKCHIP_RK3368) += clk_rk3368.o
   obj-$(CONFIG_ROCKCHIP_RK3399) += clk_rk3399.o
   obj-$(CONFIG_ROCKCHIP_RK3568) += clk_rk3568.o
+obj-$(CONFIG_ROCKCHIP_RK3588) += clk_rk3588.o
   obj-$(CONFIG_ROCKCHIP_RV1108) += clk_rv1108.o
   obj-$(CONFIG_ROCKCHIP_RV1126) += clk_rv1126.o
diff --git a/drivers/clk/rockchip/clk_rk3588.c 
b/drivers/clk/rockchip/clk_rk3588.c



Hello Jagan,

Have you noticed my questions on your previous version? I don't see any
changes in your current version on these aspects:

https://patchwork.ozlabs.org/project/uboot/patch/20230125222741.303259-6-ja...@edgeble.ai/

and here

https://patchwork.ozlabs.org/project/uboot/patch/20230125222741.303259-12-ja...@edgeble.ai/


Sorry for the late response, I will respond to it on that thread.

Thanks,
Jagan.



Sorry, I was wrong, you did some changes, now the print messages are 
removed from the code, so no more errors are printed.

I don't know if this is the right way though.

I am testing your patches on the rk3588 rock5b and come back with any 
findings.


Have you figured out what to do with the SDMMC init clock (400 kHz) ? 
This still appears to be broken


Thanks,
Eugen


Re: [PATCH v3 1/7] dt-bindings: rockchip: Sync rockchip, vop2.h from Linux

2023-02-16 Thread Jagan Teki
Hi Kever,

On Thu, Feb 9, 2023 at 8:01 PM Jagan Teki  wrote:
>
> Sync rockchip,vop2.h from linux-next, and the last commit is
>
> commit <604be85547ce> ("drm/rockchip: Add VOP2 driver")
>
> Reviewed-by: Kever Yang 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - none
> Changes for v2:
> - collect Kever RB

Any comments on this series?

Jagan.


Re: [PATCH v2 2/6] rockchip: Use an external TPL binary on RK3568

2023-02-16 Thread Jagan Teki
On Tue, Feb 14, 2023 at 4:03 PM Jonas Karlman  wrote:
>
> Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps
> back to BootRom to load next stage, U-Boot SPL, into DRAM. BootRom then
> jumps to U-Boot SPL to continue the normal boot flow.
>
> However, there is no support to initialize DRAM on RK35xx SoCs using
> U-Boot TPL and instead an external TPL binary must be used to generate a
> bootable u-boot-rockchip.bin image.
>
> Add CONFIG_ROCKCHIP_EXTERNAL_TPL to indicate that an external TPL should
> be used. Build U-Boot with ROCKCHIP_TPL=/path/to/ddr.bin to generate a
> bootable u-boot-rockchip.bin image for RK3568.

Please add documentation in doc/board/rockchip/rockchip.rst and take
an example of a real DDR bin from rkbin.

Jagan.


Re: [PATCH v1 18/18] board: rockchip: Add Edgeble Neural Compute Module 6

2023-02-16 Thread Jagan Teki
On Thu, 16 Feb 2023 at 14:27, Eugen Hristev  wrote:
>
> On 1/30/23 16:57, Jagan Teki wrote:
> > Neural Compute Module 6(Neu2) is a 96boards SoM-CB compute module
> > based on Rockchip RK3588 from Edgeble AI.
> >
> > General features:
> > - Rockchip RK3588
> > - up to 32GB LPDDR4x
> > - up to 128GB eMMC
> > - 2x MIPI CSI2 FPC
> >
> > On module WiFi6/BT5 is available in the following Neu6 variants.
> >
> > Neural Compute Module 6(Neu6) IO board is an industrial form factor
> > ready-to-use IO board from Edgeble AI.
> >
> > IO board offers plenty of peripherals and connectivity options and
> > this patch enables basic eMMC and UART which is enough to successfully
> > boot Linux.
> >
> > Neu6 needs to mount on top of this IO board in order to create a
> > complete Edgeble Neural Compute Module 6(Neu6) IO platform.
> >
> > Boot log for the record,
> >
> > DDR Version V1.08 20220617
> > LPDDR4X, 2112MHz
> > channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 
> > Size=2048MB
> > channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 
> > Size=2048MB
> > channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 
> > Size=2048MB
> > channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 
> > Size=2048MB
> > Manufacturer ID:0x6
> > CH0 RX Vref:31.7%, TX Vref:21.8%,21.8%
> > CH1 RX Vref:30.7%, TX Vref:22.8%,23.8%
> > CH2 RX Vref:30.7%, TX Vref:22.8%,22.8%
> > CH3 RX Vref:30.7%, TX Vref:21.8%,21.8%
> > change to F1: 528MHz
> > change to F2: 1068MHz
> > change to F3: 1560MHz
> > change to F0: 2112MHz
> > out
> >
> > U-Boot SPL 2023.01-00952-g1d1785a516-dirty (Jan 30 2023 - 19:53:55 +0530)
> > Trying to boot from MMC1
> > INFO:Preloader serial: 2
> > NOTICE:  BL31: v2.3():v2.3-391-g856309329:derrick.huang
> > NOTICE:  BL31: Built : 14:15:50, Jul 18 2022
> > INFO:ext 32k is not valid
> > INFO:GICv3 without legacy support detected.
> > INFO:ARM GICv3 driver initialized in EL3
> > INFO:system boots from cpu-hwid-0
> > INFO:idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
> > INFO:dfs DDR fsp_params[0].freq_mhz= 2112MHz
> > INFO:dfs DDR fsp_params[1].freq_mhz= 528MHz
> > INFO:dfs DDR fsp_params[2].freq_mhz= 1068MHz
> > INFO:dfs DDR fsp_params[3].freq_mhz= 1560MHz
> > INFO:BL31: Initialising Exception Handling Framework
> > INFO:BL31: Initializing runtime services
> > WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE 
> > initialization. SMC`s destined for OPTEE will return SMC_UNK
> > ERROR:   Error initializing runtime service opteed_fast
> > INFO:BL31: Preparing for EL3 exit to normal world
> > INFO:Entry point address = 0xa0
> > INFO:SPSR = 0x3c9
> >
> > U-Boot 2023.01-00952-g1d1785a516-dirty (Jan 30 2023 - 19:53:55 +0530)
> >
> > Model: Edgeble Neu6A IO Board
> > DRAM:  7.5 GiB (effective 3.7 GiB)
> > Core:  71 devices, 15 uclasses, devicetree: separate
> > MMC:   mmc@fe2c: 0
> > Loading Environment from nowhere... OK
> > In:serial@feb5
> > Out:   serial@feb5
> > Err:   serial@feb5
> > Model: Edgeble Neu6A IO Board
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > =>
> >
> > Add support for Edgeble Neu6 Model A IO Board.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> >   .../dts/rk3588-edgeble-neu6a-io-u-boot.dtsi   | 24 +++
> >   arch/arm/mach-rockchip/rk3588/Kconfig | 15 +
> >   board/edgeble/neural-compute-module-6/Kconfig | 15 +
> >   .../neural-compute-module-6/MAINTAINERS   |  6 ++
> >   .../edgeble/neural-compute-module-6/Makefile  |  7 ++
> >   board/edgeble/neural-compute-module-6/neu6.c  |  4 ++
> >   configs/neu6a-io-rk3588_defconfig | 67 +++
> >   doc/board/rockchip/rockchip.rst   |  2 +
> >   include/configs/neural-compute-module-6.h | 15 +
> >   9 files changed, 155 insertions(+)
> >   create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
> >   create mode 100644 board/edgeble/neural-compute-module-6/Kconfig
> >   create mode 100644 board/edgeble/neural-compute-module-6/MAINTAINERS
> >   create mode 100644 board/edgeble/neural-compute-module-6/Makefile
> >   create mode 100644 board/edgeble/neural-compute-module-6/neu6.c
> >   create mode 100644 configs/neu6a-io-rk3588_defconfig
> >   create mode 100644 include/configs/neural-compute-module-6.h
>
>
>
> > diff --git a/doc/board/rockchip/rockchip.rst 
> > b/doc/board/rockchip/rockchip.rst
> > index 28c837a382..a140c1a8a4 100644
> > --- a/doc/board/rockchip/rockchip.rst
> > +++ b/doc/board/rockchip/rockchip.rst
> > @@ -86,6 +86,8 @@ List of mainline supported Rockchip boards:
> >- Radxa ROCK Pi 4 (rock-pi-4-rk3399)
> >- Rockchip Evb-RK3399 (evb_rk3399)
> >- Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399)
> > +* rk3588
> > + - Edgeble Neural Compute Module 6 SoM - Neu6a (neu6a-io-r1126)
>
> Hi Jagan,
>
> r1126 is correct on the above line ?

Typo mistake it has to be 

  1   2   >