[PATCH] zynqmp: config: Add proper dependency for CONFIG_DFU_MMC
When CONFIG_CMD_MMC and CONFIG_MMC are disabled, still some compilation errors are seen as below due to unresolved symbols. drivers/dfu/dfu_mmc.o: in function `mmc_block_op': drivers/dfu/dfu_mmc.c:32: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:54: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:67: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:70: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.o: in function `dfu_fill_entity_mmc': drivers/dfu/dfu_mmc.c:369: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:376: undefined reference to `mmc_init' drivers/dfu/dfu_mmc.c:403: undefined reference to `mmc_get_blk_desc' gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-ld.bfd: line 4: 31661 Segmentation fault (core dumped) $CC --sysroot=$LIBC --no-warn-rwx-segment "$@" Makefile:1760: recipe for target 'u-boot' failed make: *** [u-boot] Error 139 make: *** Deleting file 'u-boot' Add dependency of CONFIG_MMC for CONFIG_DFU_MMC config to fix the errors. Signed-off-by: Ashok Reddy Soma --- drivers/dfu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig index 8d7f13dcb0..8e9e8eb4fe 100644 --- a/drivers/dfu/Kconfig +++ b/drivers/dfu/Kconfig @@ -35,6 +35,7 @@ config DFU_TIMEOUT config DFU_MMC bool "MMC back end for DFU" + depends on MMC help This option enables using DFU to read and write to MMC based storage. -- 2.17.1
Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
On Fri, Jul 07, 2023 at 08:29:12AM +0200, Heinrich Schuchardt wrote: > On 7/7/23 06:00, Masahisa Kojima wrote: > > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > > > Now U-Boot can download the distro installer ISO image > > via wget or tftpboot commands, but U-Boot can not mount > > the downloaded ISO image. > > By calling EFI_RAM_DISK_PROTOCOL->register API, user can > > mount the ISO image and boot the distro installer. > > If I understand you correctly, with your design RAM disks will only > exist in the EFI sub-system. Probably, not. As Kojima-san's "dm tree" shows, there is a U-Boot block device (and associated partition devices) thanks to your efi_driver framework. > We strive to synchronize what is happening on the driver model level and > on the UEFI level. I would prefer a design where we have a UCLASS_BLK > driver ram disks and the EFI_RAM_DISK_PROTOCOL is a one method of > managing ram disk devices. That said, I agree to starting with U-Boot block device implementation, UEFI_DISK comes automatically. It benefits both U-Boot proper and UEFI subsystem equally as well. (That is also what I meant to say in my first response.) > A big issue we have is RAM management. malloc() can only assign limited > amount of memory which is probably too small for the RAM disk you are > looking at. We manage page sized memory in the EFI sub-system but this > is not integrated with the LMB memory checks. Not sure, is it enough simply to add some restrictions on the start size and the size when a memory region is specified for a raw disk? -Takahiro Akashi > The necessary sequence of development is probably: > > * Rework memory management > * Implement ramdisks as UCLASS_BLK driver > * Implement the EFI_RAM_DISK_PROTOCOL based on the UCLASS_BLK driver. > > Best regards > > Heinrich > > > > > Note that the installation process may not proceed > > after the distro installer calls ExitBootServices() > > since there is no hand-off process for the block device of > > memory mapped ISO image. > > > > The EFI_RAM_DISK_PROTOCOL was tested with the > > debian network installer[1] on qemu_arm64 platform. > > The example procedure is as follows. > > => tftpboot 4100 mini.iso > > => efidebug disk load 4100 $filesize > > > > After these commands, ISO image is mounted like: > > > > => efidebug dh > > > > 7eec5910 (efiblk#0) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) > >Block IO > > > > 7eec6140 (efiblk#0:1) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) > >Block IO > > > > 7eec62b0 (efiblk#0:2) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) > >Block IO > >System Partition > >Simple File System > > > >=> dm tree > > > > blk 0 [ + ] efi_blk `-- efiblk#0 > > partition 0 [ + ] blk_partition |-- efiblk#0:1 > > partition 1 [ + ] blk_partition `-- efiblk#0:2 > > > > Debian can be successfully installed with this RAM disk on QEMU. > > > > [TODO] > > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() > >are not removed when the efi_handle is removed. > >So after unload the RAM disk, udevices still exist. > >I plan to add a udevice removal process in > > ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). > >In addition, I also plan to add unbind() callback in struct > > efi_driver_ops. > > > > > > [1] > > https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso > > > > Masahisa Kojima (4): > >efi_loader: add RAM disk device path > >efi_loader: add EFI_RAM_DISK_PROTOCOL implementation > >cmd: efidebug: add RAM disk mount command > >efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest > > > > cmd/efidebug.c | 117 ++ > > include/efi_api.h| 32 ++ > > include/efi_loader.h | 4 + > > lib/efi_driver/efi_uclass.c | 7 +- > > lib/efi_loader/Kconfig | 6 + > > lib/efi_loader/Makefile | 1 + > > lib/efi_loader/efi_device_path_to_text.c | 14 + > > lib/efi_loader/efi_ram_disk.c| 334 +++ > > lib/efi_loader/efi_setup.c | 6 + > > lib/efi_selftest/Makefile| 1 + > > lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++ > > lib/uuid.c | 4 + > > 12 files changed, 1035 insertions(+), 2 deletions(-) > > create mode 100644 lib/efi_loader/efi_ram_disk.c > > create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c > > > > > > base-commit: e2
Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
Hi Heinrich, On Fri, 7 Jul 2023 at 15:34, Heinrich Schuchardt wrote: > > On 7/7/23 06:00, Masahisa Kojima wrote: > > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > > > Now U-Boot can download the distro installer ISO image > > via wget or tftpboot commands, but U-Boot can not mount > > the downloaded ISO image. > > By calling EFI_RAM_DISK_PROTOCOL->register API, user can > > mount the ISO image and boot the distro installer. > > If I understand you correctly, with your design RAM disks will only > exist in the EFI sub-system. Yes, RAM disk can be accessed through the EFI sub-system. > > We strive to synchronize what is happening on the driver model level and > on the UEFI level. I would prefer a design where we have a UCLASS_BLK > driver ram disks and the EFI_RAM_DISK_PROTOCOL is a one method of > managing ram disk devices. The current EFI_RAM_DIISK_PROTOCOL implementation is the same as what EDK2 reference implementation does, and I'm not yet fully convinced how much the native U-Boot gets the benefit of RAM disk support. > > A big issue we have is RAM management. malloc() can only assign limited > amount of memory which is probably too small for the RAM disk you are > looking at. We manage page sized memory in the EFI sub-system but this > is not integrated with the LMB memory checks. OK, when we think about EFI HTTP boot and hand-off the RAM disk to the kernel, we need to consider the memory allocation for the big ISO image. But as far as EFI_RAM_DISK_PROTOCOL is concerned, can we leave the memory management issue? Thanks, Masahisa Kojima > > The necessary sequence of development is probably: > > * Rework memory management > * Implement ramdisks as UCLASS_BLK driver > * Implement the EFI_RAM_DISK_PROTOCOL based on the UCLASS_BLK driver. > > Best regards > > Heinrich > > > > > Note that the installation process may not proceed > > after the distro installer calls ExitBootServices() > > since there is no hand-off process for the block device of > > memory mapped ISO image. > > > > The EFI_RAM_DISK_PROTOCOL was tested with the > > debian network installer[1] on qemu_arm64 platform. > > The example procedure is as follows. > > => tftpboot 4100 mini.iso > > => efidebug disk load 4100 $filesize > > > > After these commands, ISO image is mounted like: > > > > => efidebug dh > > > > 7eec5910 (efiblk#0) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) > >Block IO > > > > 7eec6140 (efiblk#0:1) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) > >Block IO > > > > 7eec62b0 (efiblk#0:2) > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) > >Block IO > >System Partition > >Simple File System > > > >=> dm tree > > > > blk 0 [ + ] efi_blk `-- efiblk#0 > > partition 0 [ + ] blk_partition |-- efiblk#0:1 > > partition 1 [ + ] blk_partition `-- efiblk#0:2 > > > > Debian can be successfully installed with this RAM disk on QEMU. > > > > [TODO] > > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() > >are not removed when the efi_handle is removed. > >So after unload the RAM disk, udevices still exist. > >I plan to add a udevice removal process in > > ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). > >In addition, I also plan to add unbind() callback in struct > > efi_driver_ops. > > > > > > [1] > > https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso > > > > Masahisa Kojima (4): > >efi_loader: add RAM disk device path > >efi_loader: add EFI_RAM_DISK_PROTOCOL implementation > >cmd: efidebug: add RAM disk mount command > >efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest > > > > cmd/efidebug.c | 117 ++ > > include/efi_api.h| 32 ++ > > include/efi_loader.h | 4 + > > lib/efi_driver/efi_uclass.c | 7 +- > > lib/efi_loader/Kconfig | 6 + > > lib/efi_loader/Makefile | 1 + > > lib/efi_loader/efi_device_path_to_text.c | 14 + > > lib/efi_loader/efi_ram_disk.c| 334 +++ > > lib/efi_loader/efi_setup.c | 6 + > > lib/efi_selftest/Makefile| 1 + > > lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++ > > lib/uuid.c | 4 + > > 12 files changed, 1035 insertions(+), 2 deletions(-) > > create mode 100644 lib/efi_loader/efi_ram_disk.c > > create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c > > > > > > base-commit: e2e2aea5733f0d23cd9593bbe
[PATCH v2] lib: sparse: allocate FASTBOOT_MAX_BLK_WRITE instead of small number
Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
fixed cache alignment for systems with a D-CACHE.
However it introduced some performance regressions [1] on system
flashing huge images, such as Android.
On AM62x SK EVM, we also observe such performance penalty:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
Writing 'super'OKAY [ 75.926s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
Writing 'super'OKAY [ 62.849s]
Finished. Total time: 182.474s
The reason for this is that we use an arbitrary small buffer
(info->blksz * 100) for transferring.
Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
as suggested in the original's patch review [2].
With this patch, performance impact is mitigated:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
Writing 'super'OKAY [ 15.780s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
Writing 'super'OKAY [ 17.192s]
Finished. Total time: 76.569s
[1]
https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
[2] https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
Signed-off-by: Mattijs Korpershoek
---
Changes in v2:
- Use FASTBOOT_MAX_BLK_WRITE instead of blkcnt (Qianfan)
- Link to v1:
https://lore.kernel.org/r/20230616-sparse-flash-fix-v1-1-6bafeacc5...@baylibre.com
---
drivers/fastboot/fb_mmc.c | 2 --
include/image-sparse.h| 2 ++
lib/image-sparse.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 9d25c402028a..060918e49109 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -19,8 +19,6 @@
#include
#include
-#define FASTBOOT_MAX_BLK_WRITE 16384
-
#define BOOT_PARTITION_NAME "boot"
struct fb_mmc_sparse {
diff --git a/include/image-sparse.h b/include/image-sparse.h
index 0572dbd0a283..282a0b256498 100644
--- a/include/image-sparse.h
+++ b/include/image-sparse.h
@@ -7,6 +7,8 @@
#include
#include
+#define FASTBOOT_MAX_BLK_WRITE 16384
+
#define ROUNDUP(x, y) (((x) + ((y) - 1)) & ~((y) - 1))
struct sparse_storage {
diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index 5ec0f94ab3eb..8f8a67e15804 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -55,7 +55,8 @@ static lbaint_t write_sparse_chunk_raw(struct sparse_storage
*info,
void *data,
char *response)
{
- lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
+ lbaint_t n = blkcnt, write_blks, blks = 0;
+ lbaint_t aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE;
uint32_t *aligned_buf = NULL;
if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
---
base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
change-id: 20230616-sparse-flash-fix-9c2852aa8d16
Best regards,
--
Mattijs Korpershoek
Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
Hi Akashi-san, On Fri, 7 Jul 2023 at 16:16, AKASHI Takahiro wrote: > > On Fri, Jul 07, 2023 at 08:29:12AM +0200, Heinrich Schuchardt wrote: > > On 7/7/23 06:00, Masahisa Kojima wrote: > > > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > > > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > > > > > Now U-Boot can download the distro installer ISO image > > > via wget or tftpboot commands, but U-Boot can not mount > > > the downloaded ISO image. > > > By calling EFI_RAM_DISK_PROTOCOL->register API, user can > > > mount the ISO image and boot the distro installer. > > > > If I understand you correctly, with your design RAM disks will only > > exist in the EFI sub-system. > > Probably, not. As Kojima-san's "dm tree" shows, there is a U-Boot > block device (and associated partition devices) thanks to your > efi_driver framework. Read/Write the RAM disk is expected to be called from the EFI context, so native U-Boot can not access the RAM disk. # Honestly speaking, I'm not sure how U-Boot prohibits the access to the EFI RAM disk because the udevices are created for the RAM disk. Thanks, Masahisa Kojima > > > We strive to synchronize what is happening on the driver model level and > > on the UEFI level. I would prefer a design where we have a UCLASS_BLK > > driver ram disks and the EFI_RAM_DISK_PROTOCOL is a one method of > > managing ram disk devices. > > That said, I agree to starting with U-Boot block device implementation, > UEFI_DISK comes automatically. It benefits both U-Boot proper and > UEFI subsystem equally as well. > (That is also what I meant to say in my first response.) > > > A big issue we have is RAM management. malloc() can only assign limited > > amount of memory which is probably too small for the RAM disk you are > > looking at. We manage page sized memory in the EFI sub-system but this > > is not integrated with the LMB memory checks. > > Not sure, is it enough simply to add some restrictions on the start size > and the size when a memory region is specified for a raw disk? > > -Takahiro Akashi > > > The necessary sequence of development is probably: > > > > * Rework memory management > > * Implement ramdisks as UCLASS_BLK driver > > * Implement the EFI_RAM_DISK_PROTOCOL based on the UCLASS_BLK driver. > > > > Best regards > > > > Heinrich > > > > > > > > Note that the installation process may not proceed > > > after the distro installer calls ExitBootServices() > > > since there is no hand-off process for the block device of > > > memory mapped ISO image. > > > > > > The EFI_RAM_DISK_PROTOCOL was tested with the > > > debian network installer[1] on qemu_arm64 platform. > > > The example procedure is as follows. > > > => tftpboot 4100 mini.iso > > > => efidebug disk load 4100 $filesize > > > > > > After these commands, ISO image is mounted like: > > > > > > => efidebug dh > > > > > > 7eec5910 (efiblk#0) > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) > > >Block IO > > > > > > 7eec6140 (efiblk#0:1) > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) > > >Block IO > > > > > > 7eec62b0 (efiblk#0:2) > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) > > >Block IO > > >System Partition > > >Simple File System > > > > > >=> dm tree > > > > > > blk 0 [ + ] efi_blk `-- efiblk#0 > > > partition 0 [ + ] blk_partition |-- efiblk#0:1 > > > partition 1 [ + ] blk_partition `-- efiblk#0:2 > > > > > > Debian can be successfully installed with this RAM disk on QEMU. > > > > > > [TODO] > > > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() > > >are not removed when the efi_handle is removed. > > >So after unload the RAM disk, udevices still exist. > > >I plan to add a udevice removal process in > > > ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). > > >In addition, I also plan to add unbind() callback in struct > > > efi_driver_ops. > > > > > > > > > [1] > > > https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso > > > > > > Masahisa Kojima (4): > > >efi_loader: add RAM disk device path > > >efi_loader: add EFI_RAM_DISK_PROTOCOL implementation > > >cmd: efidebug: add RAM disk mount command > > >efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest > > > > > > cmd/efidebug.c | 117 ++ > > > include/efi_api.h| 32 ++ > > > include/efi_loader.h | 4 + > > > lib/efi_driver/efi_uclass.c | 7 +- > > > lib/efi_loader/Kconfig | 6 + > > > lib/efi_loader/Makefile | 1 + > > > lib/efi_lo
Re: [PATCH] zynqmp: config: Add proper dependency for CONFIG_DFU_MMC
Grrr. Patch subject prefix should be fixed. The rest looks good to me. M On 7/7/23 08:59, Ashok Reddy Soma wrote: When CONFIG_CMD_MMC and CONFIG_MMC are disabled, still some compilation errors are seen as below due to unresolved symbols. drivers/dfu/dfu_mmc.o: in function `mmc_block_op': drivers/dfu/dfu_mmc.c:32: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:54: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:67: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:70: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.o: in function `dfu_fill_entity_mmc': drivers/dfu/dfu_mmc.c:369: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:376: undefined reference to `mmc_init' drivers/dfu/dfu_mmc.c:403: undefined reference to `mmc_get_blk_desc' gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-ld.bfd: line 4: 31661 Segmentation fault (core dumped) $CC --sysroot=$LIBC --no-warn-rwx-segment "$@" Makefile:1760: recipe for target 'u-boot' failed make: *** [u-boot] Error 139 make: *** Deleting file 'u-boot' Add dependency of CONFIG_MMC for CONFIG_DFU_MMC config to fix the errors. Signed-off-by: Ashok Reddy Soma --- drivers/dfu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig index 8d7f13dcb0..8e9e8eb4fe 100644 --- a/drivers/dfu/Kconfig +++ b/drivers/dfu/Kconfig @@ -35,6 +35,7 @@ config DFU_TIMEOUT config DFU_MMC bool "MMC back end for DFU" + depends on MMC help This option enables using DFU to read and write to MMC based storage.
[PATCH v2] dfu: Add proper dependency for CONFIG_DFU_MMC
When CONFIG_CMD_MMC and CONFIG_MMC are disabled, still some compilation errors are seen as below due to unresolved symbols. drivers/dfu/dfu_mmc.o: in function `mmc_block_op': drivers/dfu/dfu_mmc.c:32: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:54: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:67: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.c:70: undefined reference to `mmc_get_blk_desc' drivers/dfu/dfu_mmc.o: in function `dfu_fill_entity_mmc': drivers/dfu/dfu_mmc.c:369: undefined reference to `find_mmc_device' drivers/dfu/dfu_mmc.c:376: undefined reference to `mmc_init' drivers/dfu/dfu_mmc.c:403: undefined reference to `mmc_get_blk_desc' gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-ld.bfd: line 4: 31661 Segmentation fault (core dumped) $CC --sysroot=$LIBC --no-warn-rwx-segment "$@" Makefile:1760: recipe for target 'u-boot' failed make: *** [u-boot] Error 139 make: *** Deleting file 'u-boot' Add dependency of CONFIG_MMC for CONFIG_DFU_MMC config to fix the errors. Signed-off-by: Ashok Reddy Soma --- Changes in v2: - Changed patch subject prefix to dfu from zynqmp: config drivers/dfu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig index 8d7f13dcb0..8e9e8eb4fe 100644 --- a/drivers/dfu/Kconfig +++ b/drivers/dfu/Kconfig @@ -35,6 +35,7 @@ config DFU_TIMEOUT config DFU_MMC bool "MMC back end for DFU" + depends on MMC help This option enables using DFU to read and write to MMC based storage. -- 2.17.1
Re: [PATCH] lzma: Fix decompression speed regression
Hi Simon,
Hi Christophe,
On 7/6/23 17:57, Simon Glass wrote:
On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
wrote:
Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
approx 7s on a powerpc 8xx.
The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
is disabled.
During that decompression, LzmaDec_DecodeReal() calls schedule
1.6 million times, that is every 4µs in average.
In the past it used to be a call to WATCHDOG_RESET() which was
just calling hw_watchdog_reset().
But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
mpc8xxx: Make it generic") results in an heavier processing.
However, there is absolutely no point in calling schedule() that
often.
By moving and keeping only one call to schedule() in the main
loop the number of calls is reduced to 1.2 million which is still
too much. So add logic to only call schedule every 1024 times.
That leads to a call to schedule approx every 6ms which is still
far enough to entertain the watchdog which has a 1s timeout on
powerpc 8xx.
powerpc 8xx being one of the slowest targets we have today in
U-boot, and most other watchdogs having a timeout of one minutes
instead of one second like the 8xx, this fix should not have
negative impact on other targets.
Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()")
Signed-off-by: Christophe Leroy
---
lib/lzma/LzmaDec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Reviewed-by: Simon Glass
+Stefan Roese I wonder if we need a more general fix?
IIRC, we already have some code in the watchdog IF making sure, that the
WDT reset is not called too often. I need to re-check here. And yes, we
should probably either move this code to the common schedule() function
or add it here. Best by adding a new Kconfig option, configuring the max
schedule frequency, e.g. 1000 Hz.
Thanks,
Stefan
Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
On Fri, Jul 07, 2023 at 05:19:33PM +0900, Masahisa Kojima wrote: > Hi Akashi-san, > > On Fri, 7 Jul 2023 at 16:16, AKASHI Takahiro > wrote: > > > > On Fri, Jul 07, 2023 at 08:29:12AM +0200, Heinrich Schuchardt wrote: > > > On 7/7/23 06:00, Masahisa Kojima wrote: > > > > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > > > > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > > > > > > > Now U-Boot can download the distro installer ISO image > > > > via wget or tftpboot commands, but U-Boot can not mount > > > > the downloaded ISO image. > > > > By calling EFI_RAM_DISK_PROTOCOL->register API, user can > > > > mount the ISO image and boot the distro installer. > > > > > > If I understand you correctly, with your design RAM disks will only > > > exist in the EFI sub-system. > > > > Probably, not. As Kojima-san's "dm tree" shows, there is a U-Boot > > block device (and associated partition devices) thanks to your > > efi_driver framework. > > Read/Write the RAM disk is expected to be called from the EFI context, so An associated U-Boot block device should work as well on top of your RAW_DISK_PROTOCOL via a generated RAM disk object (efi_disk). That is why SYMPLE_FILE_SYSTEM_PROTOCOL, which solely relies on U-Boot's proper filesystem subsystem, is installed to the RAM disk object. > native U-Boot can not access the RAM disk. I believe that, in theory, "fatls efidisk 0 1" (or efi_disk as an interface?) should work even under your current implementation. -Takahiro Akashi > # Honestly speaking, I'm not sure how U-Boot prohibits the access to > the EFI RAM disk > because the udevices are created for the RAM disk. > > Thanks, > Masahisa Kojima > > > > > > We strive to synchronize what is happening on the driver model level and > > > on the UEFI level. I would prefer a design where we have a UCLASS_BLK > > > driver ram disks and the EFI_RAM_DISK_PROTOCOL is a one method of > > > managing ram disk devices. > > > > That said, I agree to starting with U-Boot block device implementation, > > UEFI_DISK comes automatically. It benefits both U-Boot proper and > > UEFI subsystem equally as well. > > (That is also what I meant to say in my first response.) > > > > > A big issue we have is RAM management. malloc() can only assign limited > > > amount of memory which is probably too small for the RAM disk you are > > > looking at. We manage page sized memory in the EFI sub-system but this > > > is not integrated with the LMB memory checks. > > > > Not sure, is it enough simply to add some restrictions on the start size > > and the size when a memory region is specified for a raw disk? > > > > -Takahiro Akashi > > > > > The necessary sequence of development is probably: > > > > > > * Rework memory management > > > * Implement ramdisks as UCLASS_BLK driver > > > * Implement the EFI_RAM_DISK_PROTOCOL based on the UCLASS_BLK driver. > > > > > > Best regards > > > > > > Heinrich > > > > > > > > > > > Note that the installation process may not proceed > > > > after the distro installer calls ExitBootServices() > > > > since there is no hand-off process for the block device of > > > > memory mapped ISO image. > > > > > > > > The EFI_RAM_DISK_PROTOCOL was tested with the > > > > debian network installer[1] on qemu_arm64 platform. > > > > The example procedure is as follows. > > > > => tftpboot 4100 mini.iso > > > > => efidebug disk load 4100 $filesize > > > > > > > > After these commands, ISO image is mounted like: > > > > > > > > => efidebug dh > > > > > > > > 7eec5910 (efiblk#0) > > > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) > > > >Block IO > > > > > > > > 7eec6140 (efiblk#0:1) > > > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) > > > >Block IO > > > > > > > > 7eec62b0 (efiblk#0:2) > > > > > > > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) > > > >Block IO > > > >System Partition > > > >Simple File System > > > > > > > >=> dm tree > > > > > > > > blk 0 [ + ] efi_blk `-- efiblk#0 > > > > partition 0 [ + ] blk_partition |-- efiblk#0:1 > > > > partition 1 [ + ] blk_partition `-- efiblk#0:2 > > > > > > > > Debian can be successfully installed with this RAM disk on QEMU. > > > > > > > > [TODO] > > > > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() > > > >are not removed when the efi_handle is removed. > > > >So after unload the RAM disk, udevices still exist. > > > >I plan to add a udevice removal process in > > > > ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). > > > >In addition, I also plan to add unbind() callback in struct > > > > efi_driver_ops. > > > > > > > > > > > > [1] > > > > h
Re: [PATCH] lzma: Fix decompression speed regression
Le 07/07/2023 à 11:09, Stefan Roese a écrit :
> [Vous ne recevez pas souvent de courriers de s...@denx.de. Découvrez
> pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Simon,
> Hi Christophe,
>
> On 7/6/23 17:57, Simon Glass wrote:
>> On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
>> wrote:
>>>
>>> Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
>>> approx 7s on a powerpc 8xx.
>>> The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
>>> is disabled.
>>>
>>> During that decompression, LzmaDec_DecodeReal() calls schedule
>>> 1.6 million times, that is every 4µs in average.
>>>
>>> In the past it used to be a call to WATCHDOG_RESET() which was
>>> just calling hw_watchdog_reset().
>>>
>>> But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
>>> instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
>>> mpc8xxx: Make it generic") results in an heavier processing.
>>>
>>> However, there is absolutely no point in calling schedule() that
>>> often.
>>>
>>> By moving and keeping only one call to schedule() in the main
>>> loop the number of calls is reduced to 1.2 million which is still
>>> too much. So add logic to only call schedule every 1024 times.
>>> That leads to a call to schedule approx every 6ms which is still
>>> far enough to entertain the watchdog which has a 1s timeout on
>>> powerpc 8xx.
>>>
>>> powerpc 8xx being one of the slowest targets we have today in
>>> U-boot, and most other watchdogs having a timeout of one minutes
>>> instead of one second like the 8xx, this fix should not have
>>> negative impact on other targets.
>>>
>>> Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of
>>> WATCHDOG_RESET()")
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> lib/lzma/LzmaDec.c | 18 --
>>> 1 file changed, 4 insertions(+), 14 deletions(-)
>>
>> Reviewed-by: Simon Glass
>>
>> +Stefan Roese I wonder if we need a more general fix?
>
> IIRC, we already have some code in the watchdog IF making sure, that the
> WDT reset is not called too often. I need to re-check here. And yes, we
> should probably either move this code to the common schedule() function
> or add it here. Best by adding a new Kconfig option, configuring the max
> schedule frequency, e.g. 1000 Hz.
Yes we may add a ratelimitation inside schedule() but if we only do that
it will only be a plaster. It will still use a huge amount of CPU just
for reading the time and checking the limit.
A caller shouldn't call schedule() million of times per second, I think
the root cause need to be fixed anyway. LZMA has this problem, ZLIB has
not. I didn't check other decompressors.
The best would be that schedule() throw a WARN_ONCE() when that happens
so that we can identify frantic callers.
Christophe
Re: [PATCH] lzma: Fix decompression speed regression
Hi Christophe,
On 7/7/23 11:27, Christophe Leroy wrote:
Le 07/07/2023 à 11:09, Stefan Roese a écrit :
[Vous ne recevez pas souvent de courriers de s...@denx.de. Découvrez
pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
Hi Simon,
Hi Christophe,
On 7/6/23 17:57, Simon Glass wrote:
On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
wrote:
Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
approx 7s on a powerpc 8xx.
The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
is disabled.
During that decompression, LzmaDec_DecodeReal() calls schedule
1.6 million times, that is every 4µs in average.
In the past it used to be a call to WATCHDOG_RESET() which was
just calling hw_watchdog_reset().
But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
mpc8xxx: Make it generic") results in an heavier processing.
However, there is absolutely no point in calling schedule() that
often.
By moving and keeping only one call to schedule() in the main
loop the number of calls is reduced to 1.2 million which is still
too much. So add logic to only call schedule every 1024 times.
That leads to a call to schedule approx every 6ms which is still
far enough to entertain the watchdog which has a 1s timeout on
powerpc 8xx.
powerpc 8xx being one of the slowest targets we have today in
U-boot, and most other watchdogs having a timeout of one minutes
instead of one second like the 8xx, this fix should not have
negative impact on other targets.
Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of
WATCHDOG_RESET()")
Signed-off-by: Christophe Leroy
---
lib/lzma/LzmaDec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Reviewed-by: Simon Glass
+Stefan Roese I wonder if we need a more general fix?
IIRC, we already have some code in the watchdog IF making sure, that the
WDT reset is not called too often. I need to re-check here. And yes, we
should probably either move this code to the common schedule() function
or add it here. Best by adding a new Kconfig option, configuring the max
schedule frequency, e.g. 1000 Hz.
Yes we may add a ratelimitation inside schedule() but if we only do that
it will only be a plaster. It will still use a huge amount of CPU just
for reading the time and checking the limit.
A caller shouldn't call schedule() million of times per second, I think
the root cause need to be fixed anyway. LZMA has this problem, ZLIB has
not. I didn't check other decompressors.
Agreed. We should do both, change schedule() and also fix the high
frequent callers.
The best would be that schedule() throw a WARN_ONCE() when that happens
so that we can identify frantic callers.
Good idea. Let me see if I can come up with such a patch. Will take a
few days though as I'm traveling the next few days.
Thanks,
Stefan
Re: [PATCH 12/12] binman: Support simple templates
On 05.07.23 00:14, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
>>
>> Hi Simon,
>>
>> On 28.06.23 13:41, Simon Glass wrote:
>>> Collections can used to collect the contents of other entries into a
>>> single entry, but they result in a single entry, with the original entries
>>> 'left behind' in their old place.
>>>
>>> It is useful to be able to specific a set of entries ones and have it used
>>> in multiple images, or parts of an image.
>>>
>>> Implement this mechanism.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> tools/binman/binman.rst | 80
>>> tools/binman/control.py | 9 +++
>>> tools/binman/etype/section.py| 3 +-
>>> tools/binman/ftest.py| 8 +++
>>> tools/binman/test/286_entry_template.dts | 42 +
>>> 5 files changed, 141 insertions(+), 1 deletion(-)
>>> create mode 100644 tools/binman/test/286_entry_template.dts
>>>
>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
>>> index a4b31fe5397b..9be979ae1c5b 100644
>>> --- a/tools/binman/binman.rst
>>> +++ b/tools/binman/binman.rst
>>> @@ -727,6 +727,13 @@ optional:
>>> Note that missing, optional blobs do not produce a non-zero exit code
>>> from
>>> binman, although it does show a warning about the missing external
>>> blob.
>>>
>>> +insert-template:
>>> +This is not strictly speaking an entry property, since it is processed
>>> early
>>> +in Binman before the entries are read. It is a list of phandles of
>>> nodes to
>>> +include in the current (target) node. For each node, its subnodes and
>>> their
>>> +properties are brought into the target node. See Templates_ below for
>>> +more information.
>>> +
>>> The attributes supported for images and sections are described below.
>>> Several
>>> are similar to those for entries.
>>>
>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is going
>>> on, you can use
>>> arch/arm/dts/u-boot.dtsi ... found: "arch/arm/dts/juno-r2-u-boot.dtsi"
>>>
>>>
>>> +Templates
>>> +=
>>> +
>>> +Sometimes multiple images need to be created which have all have a common
>>> +part. For example, a board may generate SPI and eMMC images which both
>>> include
>>> +a FIT. Since the FIT includes many entries, it is tedious to repeat them
>>> twice
>>> +in the image description.
>>> +
>>> +Templates provide a simple way to handle this::
>>> +
>>> +binman {
>>> +multiple-images;
>>> +common_part: template-1 {
>>> +fit {
>>> +... lots of entries in here
>>> +};
>>> +
>>> +text {
>>> +text = "base image";
>>> +};
>>> +};
>>> +
>>> +spi-image {
>>> +filename = "image-spi.bin";
>>> +insert-template = <&fit>;
>>> +
>>> +/* things specific to SPI follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "SPI image";
>>> +};
>>> +};
>>> +
>>> +mmc-image {
>>> +filename = "image-mmc.bin";
>>> +insert-template = <&fit>;
>>> +
>>> +/* things specific to MMC follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "MMC image";
>>> +};
>>> +};
>>> +};
>>> +
>>> +The template node name must start with 'template', so it is not considered
>>> to be
>>> +an image itself.
>>> +
>>> +The mechanism is very simple. For each phandle in the 'insert-templates'
>>> +property, the source node is looked up. Then the subnodes of that source
>>> node
>>> +are copied into the target node, i.e. the one containing the
>>> `insert-template`
>>> +property.
>>> +
>>> +If the target node has a node with the same name as a template, its
>>> properties
>>> +override corresponding properties in the template. This allows the
>>> template to
>>> +be uses as a base, with the node providing updates to the properties as
>>> needed.
>>> +The overriding happens recursively.
>>> +
>>> +At present there is an unpleasant limitation on this feature: it works by
>>> +appending the template nodes after any existing subnodes to the target
>>> node.
>>> +This means that if the target node includes any subnodes, these appear in
>>> order
>>> +before the template node. In the above example, 'header' becomes the first
>>> +subnode of each image, followed by `fit` and `text`. If this is not what is
>>> +desired, there is no way to adjust it.
>>> +
>>> +Note: The above limitation will likely be removed in future, so that the
>>> +template subnodes appear before the target subnodes.
>>> +
>>> +
>>> Updating an ELF file
>>>
>>>
>>> diff --git a/tools/binman/control.py b/tools/binman/control.py
>>> index 68597c4e7792..e7faca78e9aa 100644
>>> --- a/tools/binman/control.py
>>> ++
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Thu, Jul 06, 2023 at 11:51:54PM +, Anne Macedo wrote:
> On Wed, Jul 05, 2023 at 02:15:43PM -0300, Fabio Estevam wrote:
> > On Wed, Jul 5, 2023 at 1:31 PM Anne Macedo wrote:
> >
> > > I think I'm on the right path :)
> > >
> > > 1. Included SUNXI_SETUP_REGULATORS=0 to the bl31 make
> > > 2. Changed the phy mode on arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > >From rgmii-id to rgmii
> >
> > This does not look like the correct fix. Please see this commit from Linux:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.4.1&id=544cc3f8573bf9a82e8f348741f2f68d2a8376fb
> >
> > >More info on [1][2][3]
> > > 3. Added this configs to configs/orangepi_one_plus_defconfig:
> > >CONFIG_SPL_SPI_SUNXI=y
> > >CONFIG_SUNXI_NO_PMIC=y
> >e>CONFIG_SUN8I_EMAC=y
> > >
> > > Result:
> > >
> > > U-Boot 2023.04-gfd4ed6b (Apr 03 2023 - 20:38:50 +) Allwinner
> > > Technology
> > >
> > > CPU: Allwinner H6 (SUN50I)
> > > Model: OrangePi One Plus
> > > DRAM: 1 GiB
> > > Core: 55 devices, 17 uclasses, devicetree: separate
> > > WDT: Not starting watchdog@7020400
> > > MMC: mmc@402: 0
> > > Loading Environment from FAT... Unable to read "uboot.env" from
> > > mmc0:1...
> > > In:serial@500
> > > Out: serial@500
> > > Err: serial@500
> > > Net: eth0: ethernet@502
> > >
> > > => dhcp
> > > sun8i_emac_eth_start: Timeout
> > > => mdio list
> > > ethernet@502:
> > > 1 - Generic PHY <--> ethernet@502
> >
> > What about using the Realtek PHY driver instead of the Generic one?
> >
> > --- a/configs/orangepi_one_plus_defconfig
> > +++ b/configs/orangepi_one_plus_defconfig
> > @@ -8,3 +8,6 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y
> > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > CONFIG_USB_EHCI_HCD=y
> > CONFIG_USB_OHCI_HCD=y
> > +CONFIG_PHY_REALTEK=y
> > +CONFIG_RGMII=y
> > +CONFIG_MII=y
> >
> > Does this help?
>
> Sorry for the delay, life came in the way.
>
> u-boot config:
> CONFIG_PHY_REALTEK=y
> CONFIG_RGMII=y
> CONFIG_MII=y
>
> tfa config:
> SUNXI_SETUP_REGULATORS=0
>
> result:
> => dhcp
> No ethernet found.
>
> u-boot config:
> CONFIG_SPL_SPI_SUNXI=y
> CONFIG_SUNXI_NO_PMIC=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_PHY_REALTEK=y
> CONFIG_RGMII=y
> CONFIG_MII=y
>
> tfa config:
> SUNXI_SETUP_REGULATORS=0
>
> result:
> Net: PHY reset timed out
> eth0: ethernet@502
> => dhcp
> sun8i_emac_eth_start: Timeout
> => mdio list
> ethernet@502:
> 1 - Generic PHY <--> ethernet@502
>
> It's interesting that it keeps using Generic PHY.
>
> Regards,
> Anne
>
OH! I believe I discovered something I overlooked:
On arch/arm/dts/sun50i-h6-orangepi-one-plus.dts:
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
regulator-name = "vcc-gmac-3v3";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
startup-delay-us = <10>;
enable-active-high;
gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
vin-supply = <®_aldo2>;
};
After I connected GPIO 3 to GPIO 6, the Ethernet LED turned on!
I still see:
=> dhcp
sun8i_emac_eth_start: Timeout
And
Net: PHY reset timed out
eth0: ethernet@502
Regards,
Anne
[PATCH] x86: Update docs link in bootparam header
After Linux commit ff61f0791ce9, x86 documentation was moved to
arch/x86 and the link in bootparam.h was broken.
Signed-off-by: Paul Barker
---
arch/x86/include/asm/bootparam.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index ea816ca74698..1f8ca569b880 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -62,7 +62,7 @@ struct setup_indirect {
/**
* struct setup_header - Information needed by Linux to boot
*
- * See https://www.kernel.org/doc/html/latest/x86/boot.html
+ * See https://docs.kernel.org/arch/x86/boot.html
*/
struct setup_header {
__u8setup_sects;
base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
--
2.34.1
Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver
Hello, Simon! On Thu, Jul 06, 2023 at 09:58:02AM -0600, Simon Glass wrote: > Hi Alexey, > > On Thu, 6 Jul 2023 at 14:16, Alexey Romanov wrote: > > > > At the moment, only smc API is a set of functions in > > arch/arm/mach-meson/sm.c. This approach is hard to configure > > and also doesni't contain any generic API for calling smc. > > > > This patch add Meson SM driver with generic API (struct meson_sm_ops): > > > > - sm_call() > > - sm_call_write() > > - sm_call_read() > > > > A typical driver usage example is shown here: > > > > 1. uclass_get_device_by_driver(UCLASS_FIRMWARE, "secure-monitor", &dev); > > 2. handle = meson_sm_get_handle(dev); > > 3. handle->ops.sm_call(dev, cmd, ...); > > > > Signed-off-by: Alexey Romanov > > --- > > arch/arm/mach-meson/Kconfig | 1 + > > drivers/firmware/Kconfig | 10 ++ > > drivers/firmware/Makefile | 1 + > > drivers/firmware/meson/Kconfig| 6 + > > drivers/firmware/meson/Makefile | 3 + > > drivers/firmware/meson/meson_sm.c | 217 ++ > > include/meson/sm_handle.h | 38 ++ > > 7 files changed, 276 insertions(+) > > create mode 100644 drivers/firmware/meson/Kconfig > > create mode 100644 drivers/firmware/meson/Makefile > > create mode 100644 drivers/firmware/meson/meson_sm.c > > create mode 100644 include/meson/sm_handle.h > > Please can you use the remoteproc uclass for this and add a proper driver? > I don't see it architecturally well. Can you explain please? This driver is just ARM SMC fw interface. There seems to be nothing to do here for remoteproc uclass. > Regards, > SImon -- Thank you, Alexey
[PATCH] doc: fix typo in README.usb
Signed-off-by: Enguerrand de Ribaucourt --- doc/README.usb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.usb b/doc/README.usb index ef1d6ba36..b4c3ef522 100644 --- a/doc/README.usb +++ b/doc/README.usb @@ -63,7 +63,7 @@ Common USB Commands: Storage USB Commands: - usb scan:scans the USB for storage devices.The USB must be running for this command (usb start) -- usb device [dev]: show or set current USB staorage device +- usb device [dev]: show or set current USB storage device - usb part [dev]: print partition table of one or all USB storage devices - usb read addr blk# cnt: -- 2.34.1
[PATCH v1 0/5] Make the clock dt-bindings and DT nodes consistent with Linux
The clock dt-bindings and DT nodes are not consistent with Linux now. Let's sync them with Linux, so the same dtb can work for Linux & U-Boot. To achieve this goal, the PLL clock driver is separated and some clock IDs conversion is needed in clock drivers. For the motivation, please see the discussion in the link below. [1] https://patchwork.kernel.org/project/linux-riscv/patch/20230512022036.97987-2-xingyu...@starfivetech.com/ Xingyu Wu (5): clk: starfive: jh7110: Separate the PLL driver riscv: dts: jh7110: Add PLL clock controller node riscv: dts: jh7110: Add clock source from PLL dt-bindings: clock: jh7110: Modify clock id to be same with Linux clk: starfive: jh7110: Add of_xlate ops and macros for clock id conversion .../dts/jh7110-starfive-visionfive-2.dtsi | 6 +- arch/riscv/dts/jh7110-u-boot.dtsi | 1 - arch/riscv/dts/jh7110.dtsi| 16 +- drivers/clk/starfive/clk-jh7110-pll.c | 103 +- drivers/clk/starfive/clk-jh7110.c | 306 +++--- drivers/clk/starfive/clk.h| 58 +--- .../dt-bindings/clock/starfive,jh7110-crg.h | 101 +++--- 7 files changed, 365 insertions(+), 226 deletions(-) base-commit: e1bebc16e1d9aa0ddd56c53c0b781f7186dce557 -- 2.38.1
[PATCH v1 3/5] riscv: dts: jh7110: Add clock source from PLL
From: Xingyu Wu
Change the PLL clock source from syscrg to sys_syscon child node.
Signed-off-by: Xingyu Wu
Signed-off-by: Hal Feng
---
arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 6 +++---
arch/riscv/dts/jh7110-u-boot.dtsi| 1 -
arch/riscv/dts/jh7110.dtsi | 8 ++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index c6b6dfa940..fe8ae4ebee 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -305,9 +305,9 @@
<&syscrg JH7110_SYSCLK_BUS_ROOT>,
<&syscrg JH7110_SYSCLK_PERH_ROOT>,
<&syscrg JH7110_SYSCLK_QSPI_REF>;
- assigned-clock-parents = <&syscrg JH7110_SYSCLK_PLL0_OUT>,
-<&syscrg JH7110_SYSCLK_PLL2_OUT>,
-<&syscrg JH7110_SYSCLK_PLL2_OUT>,
+ assigned-clock-parents = <&pllclk JH7110_SYSCLK_PLL0_OUT>,
+<&pllclk JH7110_SYSCLK_PLL2_OUT>,
+<&pllclk JH7110_SYSCLK_PLL2_OUT>,
<&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;
assigned-clock-rates = <0>, <0>, <0>, <0>;
};
diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi
b/arch/riscv/dts/jh7110-u-boot.dtsi
index c22119518c..2f560e7296 100644
--- a/arch/riscv/dts/jh7110-u-boot.dtsi
+++ b/arch/riscv/dts/jh7110-u-boot.dtsi
@@ -83,7 +83,6 @@
&syscrg {
bootph-pre-ram;
- starfive,sys-syscon = <&sys_syscon>;
};
&stgcrg {
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index 3e5bddccc5..20433c766f 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -480,12 +480,16 @@
<&gmac1_rgmii_rxin>,
<&i2stx_bclk_ext>, <&i2stx_lrck_ext>,
<&i2srx_bclk_ext>, <&i2srx_lrck_ext>,
-<&tdm_ext>, <&mclk_ext>;
+<&tdm_ext>, <&mclk_ext>,
+<&pllclk JH7110_SYSCLK_PLL0_OUT>,
+<&pllclk JH7110_SYSCLK_PLL1_OUT>,
+<&pllclk JH7110_SYSCLK_PLL2_OUT>;
clock-names = "osc", "gmac1_rmii_refin",
"gmac1_rgmii_rxin",
"i2stx_bclk_ext", "i2stx_lrck_ext",
"i2srx_bclk_ext", "i2srx_lrck_ext",
- "tdm_ext", "mclk_ext";
+ "tdm_ext", "mclk_ext",
+ "pll0_out", "pll1_out", "pll2_out";
#clock-cells = <1>;
#reset-cells = <1>;
};
--
2.38.1
[PATCH v1 4/5] dt-bindings: clock: jh7110: Modify clock id to be same with Linux
From: Xingyu Wu The clock id needs to be changed to be consistent with Linux. Signed-off-by: Xingyu Wu Signed-off-by: Hal Feng --- .../dt-bindings/clock/starfive,jh7110-crg.h | 101 +- 1 file changed, 51 insertions(+), 50 deletions(-) diff --git a/include/dt-bindings/clock/starfive,jh7110-crg.h b/include/dt-bindings/clock/starfive,jh7110-crg.h index 77b70e7a83..b51e3829ff 100644 --- a/include/dt-bindings/clock/starfive,jh7110-crg.h +++ b/include/dt-bindings/clock/starfive,jh7110-crg.h @@ -8,6 +8,11 @@ #ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_H__ #define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_H__ +#define JH7110_SYSCLK_PLL0_OUT 0 +#define JH7110_SYSCLK_PLL1_OUT 1 +#define JH7110_SYSCLK_PLL2_OUT 2 +#define JH7110_PLLCLK_END 3 + #define JH7110_SYSCLK_CPU_ROOT 0 #define JH7110_SYSCLK_CPU_CORE 1 #define JH7110_SYSCLK_CPU_BUS 2 @@ -199,59 +204,55 @@ #define JH7110_SYSCLK_TDM_CLK_TDM_N188 #define JH7110_SYSCLK_JTAG_CERTIFICATION_TRNG 189 -#define JH7110_SYSCLK_PLL0_OUT 190 -#define JH7110_SYSCLK_PLL1_OUT 191 -#define JH7110_SYSCLK_PLL2_OUT 192 - -#define JH7110_SYSCLK_END 193 +#define JH7110_SYSCLK_END 190 -#define JH7110_AONCLK_OSC_DIV4 (JH7110_SYSCLK_END + 0) -#define JH7110_AONCLK_APB_FUNC (JH7110_SYSCLK_END + 1) -#define JH7110_AONCLK_GMAC0_AHB(JH7110_SYSCLK_END + 2) -#define JH7110_AONCLK_GMAC0_AXI(JH7110_SYSCLK_END + 3) -#define JH7110_AONCLK_GMAC0_RMII_RTX (JH7110_SYSCLK_END + 4) -#define JH7110_AONCLK_GMAC0_TX (JH7110_SYSCLK_END + 5) -#define JH7110_AONCLK_GMAC0_TX_INV (JH7110_SYSCLK_END + 6) -#define JH7110_AONCLK_GMAC0_RX (JH7110_SYSCLK_END + 7) -#define JH7110_AONCLK_GMAC0_RX_INV (JH7110_SYSCLK_END + 8) -#define JH7110_AONCLK_OTPC_APB (JH7110_SYSCLK_END + 9) -#define JH7110_AONCLK_RTC_APB (JH7110_SYSCLK_END + 10) -#define JH7110_AONCLK_RTC_INTERNAL (JH7110_SYSCLK_END + 11) -#define JH7110_AONCLK_RTC_32K (JH7110_SYSCLK_END + 12) -#define JH7110_AONCLK_RTC_CAL (JH7110_SYSCLK_END + 13) +#define JH7110_AONCLK_OSC_DIV4 0 +#define JH7110_AONCLK_APB_FUNC 1 +#define JH7110_AONCLK_GMAC0_AHB2 +#define JH7110_AONCLK_GMAC0_AXI3 +#define JH7110_AONCLK_GMAC0_RMII_RTX 4 +#define JH7110_AONCLK_GMAC0_TX 5 +#define JH7110_AONCLK_GMAC0_TX_INV 6 +#define JH7110_AONCLK_GMAC0_RX 7 +#define JH7110_AONCLK_GMAC0_RX_INV 8 +#define JH7110_AONCLK_OTPC_APB 9 +#define JH7110_AONCLK_RTC_APB 10 +#define JH7110_AONCLK_RTC_INTERNAL 11 +#define JH7110_AONCLK_RTC_32K 12 +#define JH7110_AONCLK_RTC_CAL 13 -#define JH7110_AONCLK_END (JH7110_SYSCLK_END + 14) +#define JH7110_AONCLK_END 14 -#define JH7110_STGCLK_HIFI4_CORE (JH7110_AONCLK_END + 0) -#define JH7110_STGCLK_USB_APB (JH7110_AONCLK_END + 1) -#define JH7110_STGCLK_USB_UTMI_APB (JH7110_AONCLK_END + 2) -#define JH7110_STGCLK_USB_AXI (JH7110_AONCLK_END + 3) -#define JH7110_STGCLK_USB_LPM (JH7110_AONCLK_END + 4) -#define JH7110_STGCLK_USB_STB (JH7110_AONCLK_END + 5) -#define JH7110_STGCLK_USB_APP_125 (JH7110_AONCLK_END + 6) -#define JH7110_STGCLK_USB_REFCLK (JH7110_AONCLK_END + 7) -#define JH7110_STGCLK_PCIE0_AXI(JH7110_AONCLK_END + 8) -#define JH7110_STGCLK_PCIE0_APB(JH7110_AONCLK_END + 9) -#define JH7110_STGCLK_PCIE0_TL (JH7110_AONCLK_END + 10) -#define JH7110_STGCLK_PCIE1_AXI(JH7110_AONCLK_END + 11) -#define JH7110_STGCLK_PCIE1_APB(JH7110_AONCLK_END + 12) -#define JH7110_STGCLK_PCIE1_TL (JH7110_AONCLK_END + 13) -#define JH7110_STGCLK_PCIE01_MAIN (JH7110_AONCLK_END + 14) -#define JH7110_STGCLK_SEC_HCLK (JH7110_AONCLK_END + 15) -#define JH7110_STGCLK_SEC_MISCAHB (JH7110_AONCLK_END + 16) -#define JH7110_STGCLK_MTRX_GRP0_MAIN (JH7110_AONCLK_END + 17) -#define JH7110_STGCLK_MTRX_GRP0_BUS(JH7110_AONCLK_END + 18) -#define JH7110_STGCLK_MTRX_GRP0_STG(JH7110_AONCLK_END + 19) -#define JH7110_STGCLK_MTRX_GRP1_MAIN (JH7110_AONCLK_END + 20) -#define JH7110_STGCLK_MTRX_GRP1_BUS(JH7110_AONCLK_END + 21) -#define JH7110_STGCLK_MTRX_GRP1_STG(JH7110_AONCLK_END + 22) -#define JH7110_STGCLK_MTRX_GRP1_HIFI (JH7110_AONCLK_END + 23) -#define JH7110_STGCLK_E2_RTC (JH7110_AONCLK_END + 24) -#define JH7110_STGCLK_E2_CORE (JH7110_AONCLK_END + 25) -#define JH7110_STGCLK_E2_DBG (JH7110_AONCLK_END + 26) -#define JH7110_STGCLK_DMA1P_AXI(JH7110_AONCLK_END + 27) -#define JH7110_STGCLK_DMA1P_AHB(JH7110_AONCLK_END + 28) +#defi
[PATCH v1 5/5] clk: starfive: jh7110: Add of_xlate ops and macros for clock id conversion
From: Xingyu Wu
Modify the drivers to add of_xlate ops and transform clock id.
Signed-off-by: Xingyu Wu
Signed-off-by: Hal Feng
---
drivers/clk/starfive/clk-jh7110-pll.c | 29 ++-
drivers/clk/starfive/clk-jh7110.c | 287 +-
drivers/clk/starfive/clk.h| 25 +++
3 files changed, 235 insertions(+), 106 deletions(-)
create mode 100644 drivers/clk/starfive/clk.h
diff --git a/drivers/clk/starfive/clk-jh7110-pll.c
b/drivers/clk/starfive/clk-jh7110-pll.c
index 48c08bbe95..57c9660f08 100644
--- a/drivers/clk/starfive/clk-jh7110-pll.c
+++ b/drivers/clk/starfive/clk-jh7110-pll.c
@@ -19,6 +19,8 @@
#include
#include
+#include "clk.h"
+
#define UBOOT_DM_CLK_JH7110_PLLX "jh7110_clk_pllx"
#define PLL_PD_OFF 1
@@ -31,6 +33,8 @@
#define CLK_DDR_BUS_PLL1_DIV4 2
#define CLK_DDR_BUS_PLL1_DIV8 3
+#define JH7110_PLL_ID_TRANS(id)((id) + JH7110_EXTCLK_END)
+
enum starfive_pll_type {
PLL0 = 0,
PLL1,
@@ -371,29 +375,46 @@ static int jh7110_pll_clk_probe(struct udevice *dev)
if (sysreg == FDT_ADDR_T_NONE)
return -EINVAL;
- clk_dm(JH7110_SYSCLK_PLL0_OUT,
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL0_OUT),
starfive_jh7110_pll("pll0_out", "oscillator", reg,
(void __iomem *)sysreg,
&starfive_jh7110_pll0));
- clk_dm(JH7110_SYSCLK_PLL1_OUT,
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL1_OUT),
starfive_jh7110_pll("pll1_out", "oscillator", reg,
(void __iomem *)sysreg,
&starfive_jh7110_pll1));
- clk_dm(JH7110_SYSCLK_PLL2_OUT,
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL2_OUT),
starfive_jh7110_pll("pll2_out", "oscillator", reg,
(void __iomem *)sysreg,
&starfive_jh7110_pll2));
return 0;
}
+static int jh7110_pll_clk_of_xlate(struct clk *clk, struct ofnode_phandle_args
*args)
+{
+ if (args->args_count > 1) {
+ debug("Invalid args_count: %d\n", args->args_count);
+ return -EINVAL;
+ }
+
+ if (args->args_count)
+ clk->id = JH7110_PLL_ID_TRANS(args->args[0]);
+ else
+ clk->id = 0;
+
+ return 0;
+}
+
static const struct udevice_id jh7110_pll_clk_of_match[] = {
{ .compatible = "starfive,jh7110-pll", },
{ }
};
+JH7110_CLK_OPS(pll);
+
/* PLL clk device */
U_BOOT_DRIVER(jh7110_pll_clk) = {
.name = "jh7110_pll_clk",
.id = UCLASS_CLK,
.of_match = jh7110_pll_clk_of_match,
.probe = jh7110_pll_clk_probe,
- .ops= &ccf_clk_ops,
+ .ops= &jh7110_pll_clk_ops,
};
diff --git a/drivers/clk/starfive/clk-jh7110.c
b/drivers/clk/starfive/clk-jh7110.c
index d2aea8d7d1..31aaf3340f 100644
--- a/drivers/clk/starfive/clk-jh7110.c
+++ b/drivers/clk/starfive/clk-jh7110.c
@@ -17,14 +17,18 @@
#include
#include
+#include "clk.h"
+
#define STARFIVE_CLK_ENABLE_SHIFT 31 /* [31] */
#define STARFIVE_CLK_INVERT_SHIFT 30 /* [30] */
#define STARFIVE_CLK_MUX_SHIFT 24 /* [29:24] */
#define STARFIVE_CLK_DIV_SHIFT 0 /* [23:0] */
#define OFFSET(id) ((id) * 4)
-#define AONOFFSET(id) (((id) - JH7110_SYSCLK_END) * 4)
-#define STGOFFSET(id) (((id) - JH7110_AONCLK_END) * 4)
+
+#define JH7110_SYS_ID_TRANS(id) ((id) + JH7110_PLLCLK_END + JH7110_EXTCLK_END)
+#define JH7110_AON_ID_TRANS(id) ((id) + JH7110_SYS_ID_TRANS(JH7110_SYSCLK_END))
+#define JH7110_STG_ID_TRANS(id) ((id) + JH7110_AON_ID_TRANS(JH7110_AONCLK_END))
typedef int (*jh1710_init_fn)(struct udevice *dev);
@@ -231,202 +235,202 @@ static int jh7110_syscrg_init(struct udevice *dev)
struct jh7110_clk_priv *priv = dev_get_priv(dev);
struct clk *pclk;
- clk_dm(JH7110_SYSCLK_CPU_ROOT,
+ clk_dm(JH7110_SYS_ID_TRANS(JH7110_SYSCLK_CPU_ROOT),
starfive_clk_mux(priv->reg, "cpu_root",
OFFSET(JH7110_SYSCLK_CPU_ROOT), 1,
cpu_root_sels, ARRAY_SIZE(cpu_root_sels)));
- clk_dm(JH7110_SYSCLK_CPU_CORE,
+ clk_dm(JH7110_SYS_ID_TRANS(JH7110_SYSCLK_CPU_CORE),
starfive_clk_divider(priv->reg,
"cpu_core", "cpu_root",
OFFSET(JH7110_SYSCLK_CPU_CORE), 3));
- clk_dm(JH7110_SYSCLK_CPU_BUS,
+ clk_dm(JH7110_SYS_ID_TRANS(JH7110_SYSCLK_CPU_BUS),
starfive_clk_divider(priv->reg,
"cpu_bus", "cpu_core",
OFFSET(JH7110_SYSCLK_CPU_BUS), 2));
- clk_dm(JH7110_SYSCLK_PERH_ROOT,
+ clk_dm(JH7110_SYS_ID_TRANS(JH7110_SYSCLK_PERH_ROOT),
starfive_clk_composite(priv->reg,
"perh_root",
perh_root_sels,
ARRAY_SIZE(perh_root_sels),
[PATCH v1 1/5] clk: starfive: jh7110: Separate the PLL driver
From: Xingyu Wu
Drop the PLL part in SYSCRG driver and separate to be a single
PLL driver of which the compatible is "starfive,jh7110-pll".
Signed-off-by: Xingyu Wu
Signed-off-by: Hal Feng
---
drivers/clk/starfive/clk-jh7110-pll.c | 86 +--
drivers/clk/starfive/clk-jh7110.c | 25 +---
drivers/clk/starfive/clk.h| 57 --
3 files changed, 84 insertions(+), 84 deletions(-)
delete mode 100644 drivers/clk/starfive/clk.h
diff --git a/drivers/clk/starfive/clk-jh7110-pll.c
b/drivers/clk/starfive/clk-jh7110-pll.c
index 02e6d9000e..48c08bbe95 100644
--- a/drivers/clk/starfive/clk-jh7110-pll.c
+++ b/drivers/clk/starfive/clk-jh7110-pll.c
@@ -3,6 +3,7 @@
* Copyright (C) 2022-23 StarFive Technology Co., Ltd.
*
* Author: Yanhong Wang
+ * Xingyu Wu
*/
#include
@@ -11,13 +12,13 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#include
-#include "clk.h"
-
#define UBOOT_DM_CLK_JH7110_PLLX "jh7110_clk_pllx"
#define PLL_PD_OFF 1
@@ -30,6 +31,45 @@
#define CLK_DDR_BUS_PLL1_DIV4 2
#define CLK_DDR_BUS_PLL1_DIV8 3
+enum starfive_pll_type {
+ PLL0 = 0,
+ PLL1,
+ PLL2,
+ PLL_MAX = PLL2
+};
+
+struct starfive_pllx_rate {
+ u64 rate;
+ u32 prediv;
+ u32 fbdiv;
+ u32 frac;
+};
+
+struct starfive_pllx_offset {
+ u32 pd;
+ u32 prediv;
+ u32 fbdiv;
+ u32 frac;
+ u32 postdiv1;
+ u32 dacpd;
+ u32 dsmpd;
+ u32 pd_mask;
+ u32 prediv_mask;
+ u32 fbdiv_mask;
+ u32 frac_mask;
+ u32 postdiv1_mask;
+ u32 dacpd_mask;
+ u32 dsmpd_mask;
+};
+
+struct starfive_pllx_clk {
+ enum starfive_pll_type type;
+ const struct starfive_pllx_offset *offset;
+ const struct starfive_pllx_rate *rate_table;
+ int rate_count;
+ int flags;
+};
+
struct clk_jh7110_pllx {
struct clk clk;
void __iomem*base;
@@ -271,7 +311,7 @@ static ulong jh7110_pllx_set_rate(struct clk *clk, ulong
drate)
return jh7110_pllx_recalc_rate(clk);
}
-static const struct clk_ops clk_jh7110_ops = {
+static const struct clk_ops jh7110_clk_pllx_ops = {
.set_rate = jh7110_pllx_set_rate,
.get_rate = jh7110_pllx_recalc_rate,
};
@@ -314,8 +354,46 @@ struct clk *starfive_jh7110_pll(const char *name, const
char *parent_name,
return clk;
}
+/* PLLx clock implementation */
U_BOOT_DRIVER(jh7110_clk_pllx) = {
.name = UBOOT_DM_CLK_JH7110_PLLX,
.id = UCLASS_CLK,
- .ops= &clk_jh7110_ops,
+ .ops= &jh7110_clk_pllx_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+
+static int jh7110_pll_clk_probe(struct udevice *dev)
+{
+ void __iomem *reg = (void __iomem *)dev_read_addr_ptr(dev->parent);
+ fdt_addr_t sysreg = ofnode_get_addr(ofnode_by_compatible(ofnode_null(),
+ "starfive,jh7110-syscrg"));
+
+ if (sysreg == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ clk_dm(JH7110_SYSCLK_PLL0_OUT,
+ starfive_jh7110_pll("pll0_out", "oscillator", reg,
+ (void __iomem *)sysreg,
&starfive_jh7110_pll0));
+ clk_dm(JH7110_SYSCLK_PLL1_OUT,
+ starfive_jh7110_pll("pll1_out", "oscillator", reg,
+ (void __iomem *)sysreg,
&starfive_jh7110_pll1));
+ clk_dm(JH7110_SYSCLK_PLL2_OUT,
+ starfive_jh7110_pll("pll2_out", "oscillator", reg,
+ (void __iomem *)sysreg,
&starfive_jh7110_pll2));
+
+ return 0;
+}
+
+static const struct udevice_id jh7110_pll_clk_of_match[] = {
+ { .compatible = "starfive,jh7110-pll", },
+ { }
+};
+
+/* PLL clk device */
+U_BOOT_DRIVER(jh7110_pll_clk) = {
+ .name = "jh7110_pll_clk",
+ .id = UCLASS_CLK,
+ .of_match = jh7110_pll_clk_of_match,
+ .probe = jh7110_pll_clk_probe,
+ .ops= &ccf_clk_ops,
};
diff --git a/drivers/clk/starfive/clk-jh7110.c
b/drivers/clk/starfive/clk-jh7110.c
index a74b70906a..d2aea8d7d1 100644
--- a/drivers/clk/starfive/clk-jh7110.c
+++ b/drivers/clk/starfive/clk-jh7110.c
@@ -3,6 +3,7 @@
* Copyright (C) 2022-23 StarFive Technology Co., Ltd.
*
* Author: Yanhong Wang
+ * Xingyu Wu
*/
#include
@@ -16,8 +17,6 @@
#include
#include
-#include "clk.h"
-
#define STARFIVE_CLK_ENABLE_SHIFT 31 /* [31] */
#define STARFIVE_CLK_INVERT_SHIFT 30 /* [30] */
#define STARFIVE_CLK_MUX_SHIFT 24 /* [29:24] */
@@ -230,28 +229,8 @@ static struct clk *starfive_clk_gate_divider(void __iomem
*reg,
static int jh7110_syscrg_init(struct udevice *dev)
{
struct jh7110_clk_priv *priv = dev_get_priv(dev);
- struct ofnode_phandle_args args;
- fdt_addr_t addr;
struct clk *pclk;
- int ret;
-
- ret = ofnode_
[PATCH v1 2/5] riscv: dts: jh7110: Add PLL clock controller node
From: Xingyu Wu
Add child node about PLL clock controller in sys_syscon node.
Signed-off-by: Xingyu Wu
Signed-off-by: Hal Feng
---
arch/riscv/dts/jh7110.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index bd60879615..3e5bddccc5 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -491,8 +491,14 @@
};
sys_syscon: sys_syscon@1303 {
- compatible = "starfive,jh7110-sys-syscon","syscon";
+ compatible = "starfive,jh7110-sys-syscon","syscon",
"simple-mfd";
reg = <0x0 0x1303 0x0 0x1000>;
+
+ pllclk: clock-controller {
+ compatible = "starfive,jh7110-pll";
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
};
sysgpio: pinctrl@1304 {
--
2.38.1
Re: [PATCH v2] lib: sparse: allocate FASTBOOT_MAX_BLK_WRITE instead of small number
在 2023/7/7 16:13, Mattijs Korpershoek 写道:
Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
fixed cache alignment for systems with a D-CACHE.
However it introduced some performance regressions [1] on system
flashing huge images, such as Android.
On AM62x SK EVM, we also observe such performance penalty:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
Writing 'super'OKAY [ 75.926s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
Writing 'super'OKAY [ 62.849s]
Finished. Total time: 182.474s
The reason for this is that we use an arbitrary small buffer
(info->blksz * 100) for transferring.
Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
as suggested in the original's patch review [2].
With this patch, performance impact is mitigated:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
Writing 'super'OKAY [ 15.780s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
Writing 'super'OKAY [ 17.192s]
Finished. Total time: 76.569s
[1]
https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
[2] https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
Signed-off-by: Mattijs Korpershoek
---
Changes in v2:
- Use FASTBOOT_MAX_BLK_WRITE instead of blkcnt (Qianfan)
- Link to v1:
https://lore.kernel.org/r/20230616-sparse-flash-fix-v1-1-6bafeacc5...@baylibre.com
---
drivers/fastboot/fb_mmc.c | 2 --
include/image-sparse.h| 2 ++
lib/image-sparse.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 9d25c402028a..060918e49109 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -19,8 +19,6 @@
#include
#include
-#define FASTBOOT_MAX_BLK_WRITE 16384
-
#define BOOT_PARTITION_NAME "boot"
struct fb_mmc_sparse {
diff --git a/include/image-sparse.h b/include/image-sparse.h
index 0572dbd0a283..282a0b256498 100644
--- a/include/image-sparse.h
+++ b/include/image-sparse.h
@@ -7,6 +7,8 @@
#include
#include
+#define FASTBOOT_MAX_BLK_WRITE 16384
Hi:
Just a personal suggestion, define sometings like FASTBOOT_MAX_BLK_WRITE in
image-sparse.c is very strange.
Or maybe define a marco such as SPARSE_MAX_BLK_WRITE and set a default
value to 16384, and leave some comments for why we choice this value.
Thanks.
+
#define ROUNDUP(x, y) (((x) + ((y) - 1)) & ~((y) - 1))
struct sparse_storage {
diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index 5ec0f94ab3eb..8f8a67e15804 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -55,7 +55,8 @@ static lbaint_t write_sparse_chunk_raw(struct sparse_storage
*info,
void *data,
char *response)
{
- lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
+ lbaint_t n = blkcnt, write_blks, blks = 0;
+ lbaint_t aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE;
uint32_t *aligned_buf = NULL;
if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
---
base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
change-id: 20230616-sparse-flash-fix-9c2852aa8d16
Best regards,
[WIP] AXP313A(for Mango Pi MQ-Quad) support
Hello, Now I am trying to run U-Boot on Mango Pi MQ-Quad board. This board requires AXP313A driver and it is implemented. The diff is at GitHub, https://github.com/u-boot/u-boot/compare/master...jg1uaa:u-boot:mq Before submitting the diff, I want to know board configuration (configs/mangopi_mq_quad_defconfig and arch/arm/dts/sun50i-h616-mangopi-mq-quad.dts) is correct. At least OpenBSD for Allwinner H616 (RAMDISK kernel for installer) looks working like this: U-Boot SPL 2023.07-rc6-gdc29b21fc2 (Jul 07 2023 - 20:19:06 +0900) DRAM: 1024 MiB Trying to boot from MMC1 NOTICE: BL31: lts-v2.8.4(debug): NOTICE: BL31: Built : 19:29:55, Apr 22 2023 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a08d048, model: MangoPi MQ-Quad INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO:Could not init RSB: -65539 INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: cortex_a53: CPU workaround for 1530924 was applied INFO:PSCI: Suspend is unavailable INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 INFO:Changed devicetree. U-Boot 2023.07-rc6-gdc29b21fc2 (Jul 07 2023 - 20:19:06 +0900) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: MangoPi MQ-Quad DRAM: 1 GiB Core: 45 devices, 18 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@402: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:serial@500 Out: serial@500 Err: serial@500 Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 18104 bytes read in 4 ms (4.3 MiB/s) No EFI system partition No EFI system partition Failed to persist EFI variables BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 219050 bytes read in 12 ms (17.4 MiB/s) Booting /efi\boot\bootaa64.efi disks: sd0* >> OpenBSD/arm64 BOOTAA64 1.18 boot> boot bsd.rd cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:bsd.rd: 2858428+1077500+12724624+631888 [1705467+791232+168+26848]=0x1560490 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (RAMDISK) #56: Fri Jul 7 19:28:38 JST 2023 u...@openbsd-current-vm.uaa.org.uk:/usr/src/sys/arch/arm64/compile/RAMDISK real mem = 1072021504 (1022MB) avail mem = 1000779776 (954MB) random: boothowto does not indicate good seed mainbus0 at root: MangoPi MQ-Quad psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16 efi0 at mainbus0: UEFI 2.10 efi0: Das U-Boot rev 0x20230700 smbios0 at efi0: SMBIOS 3.0 smbios0: vendor U-Boot version "2023.07-rc6-gdc29b21fc2" date 07/01/2023 smbios0: Unknown Unknown Product "secmon" at mainbus0 not configured "osc24M-clk" at mainbus0 not configured "pmu" at mainbus0 not configured agtimer0 at mainbus0: 24000 kHz simplebus0 at mainbus0: "soc" sxisyscon0 at simplebus0 sxiccmu0 at simplebus0 sxipio0 at simplebus0: 85 pins ampintc0 at simplebus0 nirq 192, ncpu 4: "interrupt-controller" sxiccmu1 at simplebus0 sxipio1 at simplebus0: 2 pins sxitwi0 at simplebus0 iic0 at sxitwi0 "x-powers,axp313a" at iic0 addr 0x36 not configured sxidog0 at simplebus0 sximmc0 at simplebus0 sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma com0 at simplebus0: dw16550 com0: console "usb" at simplebus0 not configured "phy" at simplebus0 not configured ehci0 at simplebus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci0 at simplebus0: version 1.0 "rtc" at simplebus0 not configured gpio0 at sxipio0: 32 pins gpio1 at sxipio0: 32 pins gpio2 at sxipio0: 32 pins gpio3 at sxipio0: 32 pins gpio4 at sxipio0: 32 pins gpio5 at sxipio0: 32 pins gpio6 at sxipio0: 32 pins gpio7 at sxipio0: 32 pins gpio8 at sxipio0: 32 pins gpio9 at sxipio1: 32 pins usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1 "leds" at mainbus0 not configured "vcc5v" at mainbus0 not configured "vcc3v3" at mainbus0 not configured "binman" at mainbus0 not configured scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 14768MB, 512 bytes/sector, 30244864 sectors softraid0 at root scsibus1 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b WARNING: CHECK AND RESET THE DATE! er
[PATCH v5 00/23] Migration to using binman for bootloader
This series aims to eliminate the use of additional custom repositories
such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3
Security Development Tools) that was plumbed into the U-Boot build flow
to generate boot images for TI K3 platform devices. And instead, we move
towards using binman that aligns better with the community standard build
flow.
This series uses binman for all K3 platforms supported on U-Boot currently;
both HS (High Security, both SE and FS) and GP (General Purpose) devices.
Background on using k3-image-gen:
* TI K3 devices require a SYSFW (System Firmware) image consisting
of a signed system firmware image and board configuration binaries,
this is needed to bring up system firmware during U-Boot R5 SPL
startup.
* Board configuration data contain board-specific information
such as resource management, power management and security.
Background on using core-secdev-k3:
* Contains resources to sign x509 certificates for HS devices
Series intends to use binman to take over the packaging and signing for
the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined
boot flow) instead of k3-image-gen.
Series also packages the A72/A53 bootloader images (tispl.bin and
u-boot.img) using ATF, OPTEE and DM (Device Manager)
Changes in v5:
- updated all board configurations to latest
- changed output binary filenames
- fixed multiple certificate generation leading to packaging
inconsistency in ti-secure*.py
- added patch to overwrite symlink if exists, patch 21/23
("binman: Overwrite symlink if it already exists")
Changes in v4:
- added support for iot2050
- documentation fixes
- move to using self.Raise in ti-board-config etype
- introduced common k3-binman.dtsi (further reduction in code
duplication can be targeted, this as first step)
Changes in v3:
- added support for HS-FS devices
- added support for AM68-sk
- added back dropped documentation patch
- changed prefix for SYSFW and DM files to expected directory
name
- extended test coverage to 100%
- documentation fixes
- corrected formatting changes
Changes in v2:
- removed all external scripts
- created ti-board-config etype to support generation of board
config binaries
- created ti-secure and ti-secure-rom etypes to handle signing
instead of using external TI_SECURE_DEV_PKG
- updated openssl btool to support x509 certificate generation
- dropped Makefile changes to obtain external binary components,
moving to using BINMAN_INDIRS to achieve the same
CI/CD passes 100% (with series rebased on -master, current series based
on -next) [1]
v1:
https://patchwork.ozlabs.org/project/uboot/cover/20230120101903.179959-1-n-fran...@ti.com/
v2:
https://patchwork.ozlabs.org/project/uboot/cover/20230404121342.446935-1-n-fran...@ti.com/
v3:
https://patchwork.ozlabs.org/project/uboot/cover/20230421123203.1315330-1-n-fran...@ti.com/
v4:
https://patchwork.ozlabs.org/project/uboot/cover/20230518142713.184164-1-n-fran...@ti.com/
[1] https://github.com/u-boot/u-boot/pull/341
Andrew Davis (1):
binman: Overwrite symlink if it already exists
Neha Malcom Francis (20):
binman: ti-board-config: Add support for TI board config binaries
binman: ti-secure: Add support for TI signing
arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
j721e: schema: yaml: Add general schema and J721E board config files
j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin,
u-boot.img
j7200: yaml: Add J7200 board config files
j7200: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
am65x: yaml: Add AM65x board config files
am65: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin,
u-boot.img
am64x: yaml: Add board configs for AM64x
am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
j721s2: yaml: Add board configs for J721S2
j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
am62: yaml: Add board configs for AM62
am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
am62a: yaml: Add board configs for AM62ax
am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
k3: tools: config.mk: Update makefile and remove scripts
doc: board: ti: Update documentation for binman flow
Tom Rini (2):
buildman: Create a requirements.txt file
CI: Make use of buildman requirements.txt
.azure-pipelines.yml |4 +
.gitlab-ci.yml|4 +
arch/arm/dts/k3-am625-r5-sk.dts |1 +
arch/arm/dts/k3-am625-sk-binman.dtsi | 463 +++
arch/arm/dts/k3-am625-sk-u-boot.dtsi |2 +
arch/arm/dts/k3-am62a-sk-binman.dtsi
[PATCH v5 01/23] binman: ti-board-config: Add support for TI board config binaries
The ti-board-config entry loads and validates a given YAML config file
against a given schema, and generates the board config binary. K3
devices require these binaries to be packed into the final system
firmware images.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
tools/binman/entries.rst | 48
tools/binman/etype/ti_board_config.py | 259 ++
tools/binman/ftest.py | 20 ++
tools/binman/test/277_ti_board_cfg.dts| 14 +
.../binman/test/278_ti_board_cfg_combined.dts | 25 ++
.../binman/test/279_ti_board_cfg_no_type.dts | 11 +
tools/binman/test/yaml/config.yaml| 19 ++
tools/binman/test/yaml/schema.yaml| 51
tools/binman/test/yaml/schema_notype.yaml | 40 +++
9 files changed, 487 insertions(+)
create mode 100644 tools/binman/etype/ti_board_config.py
create mode 100644 tools/binman/test/277_ti_board_cfg.dts
create mode 100644 tools/binman/test/278_ti_board_cfg_combined.dts
create mode 100644 tools/binman/test/279_ti_board_cfg_no_type.dts
create mode 100644 tools/binman/test/yaml/config.yaml
create mode 100644 tools/binman/test/yaml/schema.yaml
create mode 100644 tools/binman/test/yaml/schema_notype.yaml
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b71af801fd..14a2d03fad 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1658,6 +1658,54 @@ by setting the size of the entry to something larger
than the text.
+.. _etype_ti_board_config:
+
+Entry: ti-board-config: An entry containing a TI schema validated board config
binary
+-
+
+This etype supports generation of two kinds of board configuration
+binaries: singular board config binary as well as combined board config
+binary.
+
+Properties / Entry arguments:
+- config-file: File containing board configuration data in YAML
+- schema-file: File containing board configuration YAML schema against
+ which the config file is validated
+
+Output files:
+- board config binary: File containing board configuration binary
+
+These above parameters are used only when the generated binary is
+intended to be a single board configuration binary. Example::
+
+my-ti-board-config {
+ti-board-config {
+config = "board-config.yaml";
+schema = "schema.yaml";
+};
+};
+
+To generate a combined board configuration binary, we pack the
+needed individual binaries into a ti-board-config binary. In this case,
+the available supported subnode names are board-cfg, pm-cfg, sec-cfg and
+rm-cfg. The final binary is prepended with a header containing details about
+the included board config binaries. Example::
+
+my-combined-ti-board-config {
+ti-board-config {
+board-cfg {
+config = "board-cfg.yaml";
+schema = "schema.yaml";
+};
+sec-cfg {
+config = "sec-cfg.yaml";
+schema = "schema.yaml";
+};
+}
+}
+
+
+
.. _etype_u_boot:
Entry: u-boot: U-Boot flat binary
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
new file mode 100644
index 00..0799e5dc59
--- /dev/null
+++ b/tools/binman/etype/ti_board_config.py
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis
+#
+# Entry-type module for generating schema validated TI board
+# configuration binary
+#
+
+import os
+import struct
+import yaml
+
+from collections import OrderedDict
+from jsonschema import validate
+from shutil import copyfileobj
+
+from binman.entry import Entry
+from binman.etype.section import Entry_section
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+BOARDCFG = 0xB
+BOARDCFG_SEC = 0xD
+BOARDCFG_PM = 0xE
+BOARDCFG_RM = 0xC
+BOARDCFG_NUM_ELEMS = 4
+
+class Entry_ti_board_config(Entry_section):
+"""An entry containing a TI schema validated board config binary
+
+This etype supports generation of two kinds of board configuration
+binaries: singular board config binary as well as combined board config
+binary.
+
+Properties / Entry arguments:
+- config-file: File containing board configuration data in YAML
+- schema-file: File containing board configuration YAML schema against
+ which the config file is validated
+
+Output files:
+- board config binary: File containing board configuration binary
+
+These above parameters are used only when the generated binary is
+intended to be a single board configuration binary. Example::
+
+my-ti-board-config {
+ti-board-config {
+config = "board-config.yaml";
+schema = "schema.yaml";
+};
+};
+
+To
[PATCH v5 02/23] binman: ti-secure: Add support for TI signing
The ti-secure entry contains certificate for binaries that will be loaded or booted by system firmware whereas the ti-secure-rom entry contains certificate for binaries that will be booted by ROM. Support for both these types of certificates is necessary for booting of K3 devices. Signed-off-by: Neha Malcom Francis Reviewed-by: Simon Glass [vigne...@ti.com: fixed inconsist cert generation by multiple packing] Signed-off-by: Vignesh Raghavendra --- board/ti/keys/custMpk.pem | 51 board/ti/keys/ti-degenerate-key.pem | 10 + tools/binman/btool/openssl.py | 244 + tools/binman/entries.rst | 65 + tools/binman/etype/ti_secure.py | 78 ++ tools/binman/etype/ti_secure_rom.py | 249 ++ tools/binman/etype/x509_cert.py | 87 +- tools/binman/ftest.py | 52 tools/binman/test/279_ti_secure.dts | 17 ++ tools/binman/test/280_ti_secure_rom.dts | 17 ++ .../test/281_ti_secure_rom_combined.dts | 25 ++ tools/binman/test/288_ti_secure_rom_a.dts | 19 ++ tools/binman/test/289_ti_secure_rom_b.dts | 18 ++ 13 files changed, 924 insertions(+), 8 deletions(-) create mode 100644 board/ti/keys/custMpk.pem create mode 100644 board/ti/keys/ti-degenerate-key.pem create mode 100644 tools/binman/etype/ti_secure.py create mode 100644 tools/binman/etype/ti_secure_rom.py create mode 100644 tools/binman/test/279_ti_secure.dts create mode 100644 tools/binman/test/280_ti_secure_rom.dts create mode 100644 tools/binman/test/281_ti_secure_rom_combined.dts create mode 100644 tools/binman/test/288_ti_secure_rom_a.dts create mode 100644 tools/binman/test/289_ti_secure_rom_b.dts diff --git a/board/ti/keys/custMpk.pem b/board/ti/keys/custMpk.pem new file mode 100644 index 00..adba378c80 --- /dev/null +++ b/board/ti/keys/custMpk.pem @@ -0,0 +1,51 @@ +-BEGIN RSA PRIVATE KEY- +MIIJKQIBAAKCAgEAvxSuSdh/ctNrI83rSA5l3CJN8g5PgvbttfLd23yR+m5Z/9X3 +tt4EHYrM0pXZ0eDEwfhQv/9IDJEiUJpMe4vzlgooJrOk2eCpVUEa+z5bJ2y/ysBx +ry9yIu5GASVirT7HBPaxGLYswBJuD+KbPuWmoKgGRQNBF04WH6l01oRO1nmnELgR +qQ6SHyXdf7Hy0bnyaNgzWUuCfXfM0Zz6I7T7WIjyzerVFvIsdS36YsPBCW7gBnDg +tQcJmWLZ1uTnbG3IggdQk/fi2O3RX+PQns+TVNlf3V3ON2DxqxSKBHtlp7p/30VF +fEuhW65OxpQ9jE6H0pQ8pPOf2vzyNnznDa1aQjfxKoHQbqGnZwMeh+0Au3NKaCgx +ooKaowTB6If/RX6qwZ/UOwXHg/0hcf69fzjJFhlSDuYDM40dHsk2HM1OnYIpiM2b +Kr5sX3uysjp5AGp99a0anR7NWCrPXvROgKs7T9341N40osQg2VkZLYUCXh9osUyN +uREG6S12tViMUKg3bmZ4b4MwRk00n7QYSrm7+nvFrtYyEISEbD+agDM1/E281W5g +VFDPfm2AlwT6jwsg/b2YK6E3vVn9SuxFoQmLF8lyFDO3BV4SXeJaHc4hVPbh6tVV +qifrTQnfGUCCLmaJF2XZbrPWOE6NYRbWdNTeFl9RGdVCuIPSyN5LqWmXto0CAwEA +AQKCAgAzkAwcJ0z1GnId/lJQZno8NhGckRoJuEKbR8dwlCP8VUz6Ca5H7Y9kvXDa +Hs/hn+rYgP6hYOz7XyrIX2rmJ/T6dxEwqGeC1+o59FConcIRWHpE5zuGT6JYJL5F +TuZa48bm4v8VMQvQZOjIZpkIFwao8c6HTwKAnHTB5IN/48I2hCt+Cn3RhfoOZ7Rm +4gkpaSkt+7GXlhXHb82YfujNO+hbktEamhUYlQ9EK70Wa8aqmf3gHxO0JgsEFjW8 +lJaSnultlTW8SDcx3LMUUjCYumECk4oX/VlJfmKYjPlVjkr3QQ+Cm3nNucb4K4hc +c+JL+2ERhSj8RjXL7VgbNgdPnIjvQDJuTNqecTU8xWPYrkOLQpNibbLjnutLkhJz +fMyRtmDtrsey8WiCDuCHkPJ8/f8RjL2zWI9fzTDDIzdlEKouUFGOovaHVnbua6pn +hymcu9d9FV3p2rcbj0ivCs7e8j+vhSxFJEJoAbcQdXCTi/n2uR7pLtoMNiUzsejy +d46Uz+KEU920NTwE2z6JJq8I2vegnxjc7PDDrV3/5rK04B93aXiqvwWseCpxelrI +xaMkRHbXrIXRO6MXQ3N+zNq8Dg3hjGTTvaBKuwgvqLwlXY8+Aa3ooFzEOInIOSsI +XcWqXxt/tgZgsj9RwpC42t8kbA+BkbNk9EIUa+P5kEr2P/fO7QKCAQEA4EtArnOX +D6tQF8uTw8USOZC2P9s/ez1z4jRq3oKP0Kv4tJiuIObJ/dUvGVD7aM5v2xaCfhm8 +xpk09VPUgghfG5jR5qVvQr75kCNToJQudWi4ngk1HwKJzzTO11giFEdybvTUA+Pj +fmxCM0dYYqRWZoj0hLqXlUCwxE74BFIhJVjeYbf+nTQrqpllTLoW7MTZHzGx5SXx +4dNzyVAUH49Yt2D8mgXXCkf5sGLh762wj34b/rR10Kr4O5utGMZrfTRIbuQ1pNjU +m66baPzq+mC0BzqZEW70TgEb7lOr8rcVXLOi3r36omfd9/MHx7iZD6o3K1axSO15 +grD4ZrN7Ac3QJwKCAQEA2heCoBdpvy6YUk8AO2k8qDygTdmPQRuwjjT+Z2fMslBt +D7DkpKwZ6Bl9OclcpiiLHmH+hv65KqYg+tR0RRb7PcogB9El9x7yKkGTPZEYWGky +n8P84rJpKwjnwWQvPQktI1cs3YGvZA9DQTFBavRrwuzgd1oSJq5aPQ2tme0kMvWp +l1/B/cPK+PKCi/Wfisaze1TjijP9qIeUwkdNN6WLrLU3QgsGppcg2I7RQtAIikT6 +GkuiOQAvWMsrJVV6PNrVKz4fJDJ59Rz6jbDHZNi1MEYNxQoB/Pl7QIakbfjWpHLv +8Ey7cB2JKxjQy8tmyl8WNQVbXbE6daPXcMTUmaRAKwKCAQBv1lYMJmq+T2eCVen6 +BbvOpE+bi5EdvEiaFBTtmiBnpjg+pJq+oRU60h/H+c9CNR0lGxY6Fk9An4f+g6xE +ojP6KLsQzJCrsVny+wpp2TlJJcxYULMCIVvhy60PR0zG29E9biqBPhJjKUvhEcQK +e3LxcXyq6fdHXphFajLUxLbuTl+kTgBRFoBnclFGbsubh5PTsA3J+p+fQLZNPPar +veg4l82cZykQYU8pGkUaI3sUMYd3+zd7sqRP5JHs9pMGPRmY4YW2CsAIWIn5UZNB +ARMDP76vKKn8cyUgMuxb+9pU/OVLN2NPs4bEaZQJjAwV+YPEwldny7F47xEM9JVz +EtKlAoIBAQDUt62u3GdGE/p5/ZgqWoDRTyDEDfmN9aYFbmbdEP80xQE7FrxMaZhz +K7laja6SWmUm40nQ/c45bQQp4uLtKHcxU15egX7YRBTLZl5o5IasZR79ebnEm2O8 +l9kEZeU1USf3mmWmP4GExOZCRfqaiYA6BbUCdJXTqKdXeWnkAssV8UrS3JFoJHpq +yo7OWGqefyQ8nRW6jO9SW7uaqtUD+7H6aF5XSk3YWvusfdBZrHNH+fM/hpnZovaL +Us7ogTDS/laA8PyK37jYfMVdQhmZoU1Iomt3zkUWK3gt/aWPpfAlQf4Jka4YspZB +tNiijefaZ1hPqsPs5Joyd/YAhdsfaHc1AoIBAQCn/9j6RRjRaw0ip756oad4AXHz +XBwVB2CrY96qT6Hj9Sq7tGgdskqGkOQkAivBLBizUdcWv0t1yenOsSgasQeMlvlh +B8md9cLvpKXPB
[PATCH v5 03/23] arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
Board config binary artifacts must be generated to be used by binman to
package sysfw.itb and tiboot3.bin for all K3 devices.
For devices that follow combined flow, these board configuration
binaries must again be packaged into a combined board configuration
blobs to be used by binman to package tiboot3.bin.
Add common k3-binman.dtsi to generate all the board configuration
binaries needed.
Also add custMpk.pem and ti-degenerate-key.pem needed for signing GP and
HS bootloader images common to all K3 devices.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-binman.dtsi | 116
1 file changed, 116 insertions(+)
create mode 100644 arch/arm/dts/k3-binman.dtsi
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
new file mode 100644
index 00..97a3573bdb
--- /dev/null
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+&binman {
+ custMpk {
+ filename = "custMpk.pem";
+ blob-ext {
+ filename = "../keys/custMpk.pem";
+ };
+ };
+
+ ti-degenerate-key {
+ filename = "ti-degenerate-key.pem";
+ blob-ext {
+ filename = "../keys/ti-degenerate-key.pem";
+ };
+ };
+};
+
+#ifndef CONFIG_ARM64
+
+&binman {
+ board-cfg {
+ filename = "board-cfg.bin";
+ bcfg_yaml: ti-board-config {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ pm-cfg {
+ filename = "pm-cfg.bin";
+ rcfg_yaml: ti-board-config {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ rm-cfg {
+ filename = "rm-cfg.bin";
+ pcfg_yaml: ti-board-config {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ sec-cfg {
+ filename = "sec-cfg.bin";
+ scfg_yaml: ti-board-config {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ combined-tifs-cfg {
+ filename = "combined-tifs-cfg.bin";
+ ti-board-config {
+ bcfg_yaml_tifs: board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ scfg_yaml_tifs: sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ pcfg_yaml_tifs: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rcfg_yaml_tifs: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+ combined-dm-cfg {
+ filename = "combined-dm-cfg.bin";
+ ti-board-config {
+ pcfg_yaml_dm: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rcfg_yaml_dm: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+ combined-sysfw-cfg {
+ filename = "combined-sysfw-cfg.bin";
+ ti-board-config {
+ board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+};
+
+#endif
--
2.34.1
[PATCH v5 05/23] j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
By providing entries in the binman node of the device tree, binman will
be able to find and package board config artifacts generated by
TIBoardConfig with sysfw.bin and generate the final image sysfw.itb.
It will also pick out the R5 SPL and sign it with the help of TI signing
entry and generate the final tiboot3.bin.
Entries for A72 build have been added to k3-j721e-binman.dtsi to
generate tispl.bin and u-boot.img.
Support has been added for both HS-SE(SR 1.1), HS-FS(SR 2.0) and GP images
In HS-SE, the encrypted system firmware binary must be signed along with
the signed certificate binary.
HS-SE:
* tiboot3-j721e_sr1_1-hs-evm.bin
* sysfw-j721e_sr1_1-hs-evm.itb
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-j721e_sr2-hs-fs-evm.bin
* sysfw-j721e_sr2-hs-fs-evm.itb
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin -->tiboot3-j721e-gp-evm.bin
* sysfw.itb --> sysfw-j721e-gp-evm.itb
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by J721E requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
sysfw.itb:
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-j721e-binman.dtsi | 701 ++
.../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 1 +
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 1 +
board/ti/j721e/Kconfig| 2 +
5 files changed, 706 insertions(+)
create mode 100644 arch/arm/dts/k3-j721e-binman.dtsi
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
new file mode 100644
index 00..0455deb6ca
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -0,0 +1,701 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J721E_R5_EVM
+
+&binman {
+ tiboot3-j721e_sr1_1-hs-evm.bin {
+ filename = "tiboot3-j721e_sr1_1-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>;
+ core = "public";
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw {
+ filename = "sysfw.bin";
+ ti-secure-rom {
+ content = <&ti_fs_cert>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_fs_cert: ti-fs-cert.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e_sr1_1-hs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb {
+ filename = "sysfw-j721e_sr1_1-hs-evm.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <&board_cfg>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg: board-cfg {
+ filename = "board-cfg.bin";
+
[PATCH v5 06/23] j7200: yaml: Add J7200 board config files
Added YAML configs for J7200 Signed-off-by: Neha Malcom Francis --- board/ti/j721e/board-cfg_j7200.yaml | 36 + board/ti/j721e/pm-cfg_j7200.yaml| 12 + board/ti/j721e/rm-cfg_j7200.yaml| 2065 +++ board/ti/j721e/sec-cfg_j7200.yaml | 380 + 4 files changed, 2493 insertions(+) create mode 100644 board/ti/j721e/board-cfg_j7200.yaml create mode 100644 board/ti/j721e/pm-cfg_j7200.yaml create mode 100644 board/ti/j721e/rm-cfg_j7200.yaml create mode 100644 board/ti/j721e/sec-cfg_j7200.yaml diff --git a/board/ti/j721e/board-cfg_j7200.yaml b/board/ti/j721e/board-cfg_j7200.yaml new file mode 100644 index 00..1453317ecb --- /dev/null +++ b/board/ti/j721e/board-cfg_j7200.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for J7200 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/j721e/pm-cfg_j7200.yaml b/board/ti/j721e/pm-cfg_j7200.yaml new file mode 100644 index 00..588a1d530d --- /dev/null +++ b/board/ti/j721e/pm-cfg_j7200.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for J7200 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/j721e/rm-cfg_j7200.yaml b/board/ti/j721e/rm-cfg_j7200.yaml new file mode 100644 index 00..66b589f370 --- /dev/null +++ b/board/ti/j721e/rm-cfg_j7200.yaml @@ -0,0 +1,2065 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for J7200 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 35 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x
[PATCH v5 07/23] j7200: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
Support has been added for both HS-SE(SR 2.0), HS-FS(SR 2.0) and GP
images.
HS-SE:
* tiboot3-j7200_sr2-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-j7200_sr2-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-j7200-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by J7200 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-j7200-binman.dtsi | 502 ++
.../k3-j7200-common-proc-board-u-boot.dtsi| 2 +
board/ti/j721e/Kconfig| 2 +
3 files changed, 506 insertions(+)
create mode 100644 arch/arm/dts/k3-j7200-binman.dtsi
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
new file mode 100644
index 00..61bf576970
--- /dev/null
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -0,0 +1,502 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J7200_R5_EVM
+
+&bcfg_yaml {
+ config = "board-cfg_j7200.yaml";
+};
+
+&rcfg_yaml {
+ config = "rm-cfg_j7200.yaml";
+};
+
+&pcfg_yaml {
+ config = "pm-cfg_j7200.yaml";
+};
+
+&scfg_yaml {
+ config = "sec-cfg_j7200.yaml";
+};
+
+&bcfg_yaml_tifs {
+ config = "board-cfg_j7200.yaml";
+};
+
+&rcfg_yaml_tifs {
+ config = "rm-cfg_j7200.yaml";
+};
+
+&pcfg_yaml_tifs {
+ config = "pm-cfg_j7200.yaml";
+};
+
+&scfg_yaml_tifs {
+ config = "sec-cfg_j7200.yaml";
+};
+
+&rcfg_yaml_dm {
+ config = "rm-cfg_j7200.yaml";
+};
+
+&pcfg_yaml_dm {
+ config = "pm-cfg_j7200.yaml";
+};
+
+&binman {
+ tiboot3-j7200_sr2-hs-evm.bin {
+ filename = "tiboot3-j7200_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>, <&ti_fs_enc>,
<&combined_tifs_cfg>,
+ <&combined_dm_cfg>, <&sysfw_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl>;
+ content-sysfw = <&ti_fs_enc>;
+ content-sysfw-data = <&combined_tifs_cfg>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert>;
+ content-dm-data = <&combined_dm_cfg>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j7200_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-fs-firmware-j7200_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+&binman {
+ tiboot3-j7200_sr2-hs-fs-evm.bin {
+ filename = "tiboot3-j7200_sr2-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl_fs>, <&ti_fs_enc_fs>,
<&combined_tifs_cfg_fs>,
+ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl_fs>;
+ content-sysfw = <&ti_fs_enc_fs>;
+ content-sysfw-data = <&combined_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert_fs>;
+ content-dm-data = <&combined_dm_cfg_fs>;
+ load = <0x41c0>
[PATCH v5 08/23] am65x: yaml: Add AM65x board config files
Added YAML configs for AM65x Signed-off-by: Neha Malcom Francis --- board/ti/am65x/board-cfg.yaml | 36 + board/ti/am65x/pm-cfg.yaml| 12 + board/ti/am65x/rm-cfg.yaml| 2068 + board/ti/am65x/sec-cfg.yaml | 379 ++ 4 files changed, 2495 insertions(+) create mode 100644 board/ti/am65x/board-cfg.yaml create mode 100644 board/ti/am65x/pm-cfg.yaml create mode 100644 board/ti/am65x/rm-cfg.yaml create mode 100644 board/ti/am65x/sec-cfg.yaml diff --git a/board/ti/am65x/board-cfg.yaml b/board/ti/am65x/board-cfg.yaml new file mode 100644 index 00..133720ec3e --- /dev/null +++ b/board/ti/am65x/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM65x +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am65x/pm-cfg.yaml b/board/ti/am65x/pm-cfg.yaml new file mode 100644 index 00..4b1ce475cd --- /dev/null +++ b/board/ti/am65x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM65x +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am65x/rm-cfg.yaml b/board/ti/am65x/rm-cfg.yaml new file mode 100644 index 00..61acd0aa60 --- /dev/null +++ b/board/ti/am65x/rm-cfg.yaml @@ -0,0 +1,2068 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM65x +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowe
[PATCH v5 09/23] am65: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
Support has been added for both HS-SE(SR 2.0) and GP(SR 2.0) images.
HS-SE:
* tiboot3-am65x_sr2-hs-evm.bin
* sysfw-am65x_sr2-hs-evm.itb
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am65x_sr2-gp-evm.bin
* sysfw.itb --> sysfw-am65x_sr2-gp-evm.itb
* tispl.bin_unsigned
* u-boot.img_unsigned
Note that the bootflow followed by AM65x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
sysfw.itb:
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 1 +
.../dts/k3-am654-r5-base-board-u-boot.dtsi| 1 +
arch/arm/dts/k3-am65x-binman.dtsi | 518 ++
board/ti/am65x/Kconfig| 2 +
4 files changed, 522 insertions(+)
create mode 100644 arch/arm/dts/k3-am65x-binman.dtsi
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 0c1305df7e..e4cbc47c2a 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include "k3-am654-r5-base-board-u-boot.dtsi"
+#include "k3-am65x-binman.dtsi"
&pru0_0 {
remoteproc-name = "pru0_0";
diff --git a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
index 4516ab1437..949320c91d 100644
--- a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
@@ -5,6 +5,7 @@
#include
#include
+#include "k3-am65x-binman.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
b/arch/arm/dts/k3-am65x-binman.dtsi
new file mode 100644
index 00..6535b9fec2
--- /dev/null
+++ b/arch/arm/dts/k3-am65x-binman.dtsi
@@ -0,0 +1,518 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM654_R5_EVM
+
+&binman {
+ tiboot3-am65x_sr2-hs-evm.bin {
+ filename = "tiboot3-am65x_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>;
+ core = "public";
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw {
+ filename = "sysfw.bin";
+ ti-secure-rom {
+ content = <&ti_sci_cert>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_sci_cert: ti-sci-cert.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am65x_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-sci-firmware-am65x-hs-enc.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am65x_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb {
+ filename = "sysfw-am65x_sr2-hs-evm.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <&board_cfg>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg: board-cfg {
+ filename = "board-cfg.bin";
+
[PATCH v5 10/23] am64x: yaml: Add board configs for AM64x
Added YAML configs for AM64xx Signed-off-by: Neha Malcom Francis --- board/ti/am64x/board-cfg.yaml | 37 + board/ti/am64x/pm-cfg.yaml| 12 + board/ti/am64x/rm-cfg.yaml| 1400 + board/ti/am64x/sec-cfg.yaml | 380 + 4 files changed, 1829 insertions(+) create mode 100644 board/ti/am64x/board-cfg.yaml create mode 100644 board/ti/am64x/pm-cfg.yaml create mode 100644 board/ti/am64x/rm-cfg.yaml create mode 100644 board/ti/am64x/sec-cfg.yaml diff --git a/board/ti/am64x/board-cfg.yaml b/board/ti/am64x/board-cfg.yaml new file mode 100644 index 00..f1f7c68d50 --- /dev/null +++ b/board/ti/am64x/board-cfg.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM64x +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 + diff --git a/board/ti/am64x/pm-cfg.yaml b/board/ti/am64x/pm-cfg.yaml new file mode 100644 index 00..c97495f482 --- /dev/null +++ b/board/ti/am64x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM64x +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am64x/rm-cfg.yaml b/board/ti/am64x/rm-cfg.yaml new file mode 100644 index 00..1e6b07aef6 --- /dev/null +++ b/board/ti/am64x/rm-cfg.yaml @@ -0,0 +1,1400 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM64x +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 38 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 41 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +
[PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
Support added for HS and GP boot binaries for AM64x.
HS-SE:
* tiboot3-am64x_sr2-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am64x_sr2-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am64x-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
Note that the bootflow followed by AM64x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 +
arch/arm/dts/k3-am642-r5-evm.dts | 1 +
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 +
arch/arm/dts/k3-am64x-binman.dtsi | 515 ++
board/ti/am64x/Kconfig| 2 +
5 files changed, 522 insertions(+)
create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b0909..73577e8cfd 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-am64x-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index e870492a69..b49064181a 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -8,6 +8,7 @@
#include "k3-am642.dtsi"
#include "k3-am64-evm-ddr4-1600MTs.dtsi"
#include "k3-am64-ddr.dtsi"
+#include "k3-am64x-binman.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 69dbe943bd..3d6be025bd 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-am64x-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-am64x-binman.dtsi
b/arch/arm/dts/k3-am64x-binman.dtsi
new file mode 100644
index 00..e6ca2457b4
--- /dev/null
+++ b/arch/arm/dts/k3-am64x-binman.dtsi
@@ -0,0 +1,515 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM642_R5_EVM
+
+&binman {
+ tiboot3-am64x_sr2-hs-evm.bin {
+ filename = "tiboot3-am64x_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>, <&ti_sci_enc>,
+ <&combined_sysfw_cfg>, <&sysfw_inner_cert>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl>;
+ content-sysfw = <&ti_sci_enc>;
+ content-sysfw-data = <&combined_sysfw_cfg>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert>;
+ load = <0x7000>;
+ load-sysfw = <0x44000>;
+ load-sysfw-data = <0x7b000>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_sci_enc: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_sysfw_cfg: combined-sysfw-cfg.bin {
+ filename = "combined-sysfw-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+
+ };
+};
+
+&binman {
+ tiboot3-am64x_sr2-hs-fs-evm.bin {
+ filename = "tiboot3-am64x_sr2-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl_fs>, <&ti_sci_enc_fs>,
+ <&combined_sysfw_cfg_fs>,
<&sysfw_inner_cert_fs>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl_fs>;
+ content-sysfw = <&ti_sci_enc_fs>;
+
[PATCH v5 13/23] j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support has been added for both HS-SE, HS-FS and GP images.
HS-SE:
* tiboot3-j721s2-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-j721s2-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-j721s2-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by J721S2 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
.../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 2 +
arch/arm/dts/k3-j721s2-binman.dtsi| 546 ++
.../k3-j721s2-common-proc-board-u-boot.dtsi | 2 +
.../dts/k3-j721s2-r5-common-proc-board.dts| 1 +
board/ti/j721s2/Kconfig | 2 +
5 files changed, 553 insertions(+)
create mode 100644 arch/arm/dts/k3-j721s2-binman.dtsi
diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
index ee31b1ebe7..79faa1b573 100644
--- a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-j721s2-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi
b/arch/arm/dts/k3-j721s2-binman.dtsi
new file mode 100644
index 00..7fd7ba8e5d
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-binman.dtsi
@@ -0,0 +1,546 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J721S2_R5_EVM
+
+&binman {
+ tiboot3-j721s2-hs-evm.bin {
+ filename = "tiboot3-j721s2-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>, <&ti_fs_enc>,
<&combined_tifs_cfg>,
+ <&combined_dm_cfg>, <&sysfw_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl>;
+ content-sysfw = <&ti_fs_enc>;
+ content-sysfw-data = <&combined_tifs_cfg>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert>;
+ content-dm-data = <&combined_dm_cfg>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+&binman {
+ tiboot3-j721s2-hs-fs-evm.bin {
+ filename = "tiboot3-j721s2-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl_fs>, <&ti_fs_enc_fs>,
<&combined_tifs_cfg_fs>,
+ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl_fs>;
+ content-sysfw = <&ti_fs_enc_fs>;
+ content-sysfw-data = <&combined_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert_fs>;
+ content-dm-data = <&combined_dm_cfg_fs>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+
[PATCH v5 12/23] j721s2: yaml: Add board configs for J721S2
Added YAML configs for J721S2 Signed-off-by: Neha Malcom Francis --- board/ti/j721s2/board-cfg.yaml | 37 + board/ti/j721s2/pm-cfg.yaml| 12 + board/ti/j721s2/rm-cfg.yaml| 2901 board/ti/j721s2/sec-cfg.yaml | 379 + 4 files changed, 3329 insertions(+) create mode 100644 board/ti/j721s2/board-cfg.yaml create mode 100644 board/ti/j721s2/pm-cfg.yaml create mode 100644 board/ti/j721s2/rm-cfg.yaml create mode 100644 board/ti/j721s2/sec-cfg.yaml diff --git a/board/ti/j721s2/board-cfg.yaml b/board/ti/j721s2/board-cfg.yaml new file mode 100644 index 00..d80f308ca6 --- /dev/null +++ b/board/ti/j721s2/board-cfg.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for J721S2 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 + diff --git a/board/ti/j721s2/pm-cfg.yaml b/board/ti/j721s2/pm-cfg.yaml new file mode 100644 index 00..45994e23cc --- /dev/null +++ b/board/ti/j721s2/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for J721S2 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/j721s2/rm-cfg.yaml b/board/ti/j721s2/rm-cfg.yaml new file mode 100644 index 00..6058f3b35c --- /dev/null +++ b/board/ti/j721s2/rm-cfg.yaml @@ -0,0 +1,2901 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for J721S2 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 21 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #6 +host_id: 23 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #7 +host_id: 35 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #8 +host_id: 37 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #9 +host_id: 40 +allowed_atype : 0x2A +
[PATCH v5 14/23] am62: yaml: Add board configs for AM62
Added YAML configs for AM62 Signed-off-by: Neha Malcom Francis --- board/ti/am62x/board-cfg.yaml | 36 ++ board/ti/am62x/pm-cfg.yaml| 12 + board/ti/am62x/rm-cfg.yaml| 1088 + board/ti/am62x/sec-cfg.yaml | 379 4 files changed, 1515 insertions(+) create mode 100644 board/ti/am62x/board-cfg.yaml create mode 100644 board/ti/am62x/pm-cfg.yaml create mode 100644 board/ti/am62x/rm-cfg.yaml create mode 100644 board/ti/am62x/sec-cfg.yaml diff --git a/board/ti/am62x/board-cfg.yaml b/board/ti/am62x/board-cfg.yaml new file mode 100644 index 00..a26ef55bd4 --- /dev/null +++ b/board/ti/am62x/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62x/pm-cfg.yaml b/board/ti/am62x/pm-cfg.yaml new file mode 100644 index 00..aa94097e97 --- /dev/null +++ b/board/ti/am62x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62x/rm-cfg.yaml b/board/ti/am62x/rm-cfg.yaml new file mode 100644 index 00..1e8678c30b --- /dev/null +++ b/board/ti/am62x/rm-cfg.yaml @@ -0,0 +1,1088 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +
[PATCH v5 15/23] am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support added for HS-SE, HS-FS and GP boot binaries for AM62.
HS-SE:
* tiboot3-am62x-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am62x-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am62x-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by AM62 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am625-r5-sk.dts | 1 +
arch/arm/dts/k3-am625-sk-binman.dtsi | 463 +++
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 2 +
board/ti/am62x/Kconfig | 2 +
4 files changed, 468 insertions(+)
create mode 100644 arch/arm/dts/k3-am625-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 78df7cec3f..3ec5bad735 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -9,6 +9,7 @@
#include "k3-am62-ddr.dtsi"
#include "k3-am625-sk-u-boot.dtsi"
+#include "k3-am625-sk-binman.dtsi"
/ {
aliases {
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
new file mode 100644
index 00..c5bd9e48d0
--- /dev/null
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_R5_EVM
+
+&binman {
+ tiboot3-am62x-hs-evm.bin {
+ filename = "tiboot3-am62x-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>, <&ti_fs_enc>,
<&combined_tifs_cfg>,
+ <&combined_dm_cfg>, <&sysfw_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl>;
+ content-sysfw = <&ti_fs_enc>;
+ content-sysfw-data = <&combined_tifs_cfg>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert>;
+ content-dm-data = <&combined_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+&binman {
+ tiboot3-am62x-hs-fs-evm.bin {
+ filename = "tiboot3-am62x-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl_fs>, <&ti_fs_enc_fs>,
<&combined_tifs_cfg_fs>,
+ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl_fs>;
+ content-sysfw = <&ti_fs_enc_fs>;
+ content-sysfw-data = <&combined_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert_fs>;
+ content-dm-data = <&combined_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+
[PATCH v5 17/23] am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
Support added for HS-SE, HS-FS and GP boot binaries for AM62ax.
HS-SE:
* tiboot3-am62ax-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am62ax-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am62ax-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by AM62ax requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am62a-sk-binman.dtsi | 466 +++
arch/arm/dts/k3-am62a7-r5-sk.dts | 1 +
arch/arm/dts/k3-am62a7-sk.dts| 1 +
board/ti/am62ax/Kconfig | 2 +
4 files changed, 470 insertions(+)
create mode 100644 arch/arm/dts/k3-am62a-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
new file mode 100644
index 00..abbac8f084
--- /dev/null
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -0,0 +1,466 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM62A7_R5_EVM
+
+&rcfg_yaml_tifs {
+ config = "tifs-rm-cfg.yaml";
+};
+
+&binman {
+ tiboot3-am62ax-hs-evm.bin {
+ filename = "tiboot3-am62ax-hs-evm.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl>, <&ti_fs_enc>,
<&combined_tifs_cfg>,
+ <&combined_dm_cfg>, <&sysfw_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl>;
+ content-sysfw = <&ti_fs_enc>;
+ content-sysfw-data = <&combined_tifs_cfg>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert>;
+ content-dm-data = <&combined_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+&binman {
+ tiboot3-am62ax-hs-fs-evm.bin {
+ filename = "tiboot3-am62ax-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <&u_boot_spl_fs>, <&ti_fs_enc_fs>,
<&combined_tifs_cfg_fs>,
+ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <&u_boot_spl_fs>;
+ content-sysfw = <&ti_fs_enc_fs>;
+ content-sysfw-data = <&combined_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <&sysfw_inner_cert_fs>;
+ content-dm-data = <&combined_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-am62ax-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs: com
[PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
Move to using binman to generate tispl.bin which is used to generate the
final flash.bin bootloader for iot2050 boards.
Signed-off-by: Neha Malcom Francis
Cc: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++-
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 03ccc54329..9d83898d33 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -26,9 +26,81 @@
missing-msg = "iot2050-seboot";
};
- blob@0x18 {
+ fit@0x18 {
offset = <0x18>;
- filename = "tispl.bin";
+ pad-byte = <0xff>;
+ description = "Configuration to load ATF and SPL";
+
+ images {
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = ;
+ entry = ;
+ atf: atf-bl31 {
+ };
+ };
+
+ tee {
+ description = "OPTEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <0x9e80>;
+ entry = <0x9e80>;
+ tee: tee-os {
+ };
+ };
+
+ dm {
+ description = "DM binary";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0x8900>;
+ entry = <0x8900>;
+ blob-ext {
+ filename = "/dev/null";
+ };
+ };
+
+ spl {
+ description = "SPL (64-bit)";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+ u_boot_spl_nodtb: blob-ext {
+ filename =
"spl/u-boot-spl-nodtb.bin";
+ };
+ };
+
+ fdt-0 {
+ description = "k3-am65-iot2050-spl.dtb";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ spl_am65x_evm_dtb: blob-ext {
+ filename =
"spl/dts/k3-am65-iot2050-spl.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x38 {
--
2.34.1
[PATCH v5 16/23] am62a: yaml: Add board configs for AM62ax
Added YAML configs for AM62ax Signed-off-by: Neha Malcom Francis --- board/ti/am62ax/board-cfg.yaml | 36 + board/ti/am62ax/pm-cfg.yaml | 12 + board/ti/am62ax/rm-cfg.yaml | 1151 ++ board/ti/am62ax/sec-cfg.yaml | 379 ++ board/ti/am62ax/tifs-rm-cfg.yaml | 1011 ++ 5 files changed, 2589 insertions(+) create mode 100644 board/ti/am62ax/board-cfg.yaml create mode 100644 board/ti/am62ax/pm-cfg.yaml create mode 100644 board/ti/am62ax/rm-cfg.yaml create mode 100644 board/ti/am62ax/sec-cfg.yaml create mode 100644 board/ti/am62ax/tifs-rm-cfg.yaml diff --git a/board/ti/am62ax/board-cfg.yaml b/board/ti/am62ax/board-cfg.yaml new file mode 100644 index 00..6e45b494e0 --- /dev/null +++ b/board/ti/am62ax/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62ax +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62ax/pm-cfg.yaml b/board/ti/am62ax/pm-cfg.yaml new file mode 100644 index 00..a491f11260 --- /dev/null +++ b/board/ti/am62ax/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62ax +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml new file mode 100644 index 00..0e11bd3e3c --- /dev/null +++ b/board/ti/am62ax/rm-cfg.yaml @@ -0,0 +1,1151 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62ax +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +
[PATCH v5 19/23] k3: tools: config.mk: Update makefile and remove scripts
Since binman is used to package bootloader images for all K3 devices, we
do not have to rely on the earlier methods to package them.
Scripts that were used to generate x509 certificate for tiboot3.bin and
generate tispl.bin, u-boot.img have been removed.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/mach-k3/config.mk | 103 ---
tools/k3_fit_atf.sh| 123 -
tools/k3_gen_x509_cert.sh | 262 -
3 files changed, 488 deletions(-)
delete mode 100644 arch/arm/mach-k3/config.mk
delete mode 100755 tools/k3_fit_atf.sh
delete mode 100755 tools/k3_gen_x509_cert.sh
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
deleted file mode 100644
index cbf9c10210..00
--- a/arch/arm/mach-k3/config.mk
+++ /dev/null
@@ -1,103 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
-# Lokesh Vutla
-
-ifdef CONFIG_SPL_BUILD
-
-# Openssl is required to generate x509 certificate.
-# Error out if openssl is not available.
-ifeq ($(shell which openssl),)
-$(error "No openssl in $(PATH), consider installing openssl")
-endif
-
-IMAGE_SIZE= $(shell cat $(obj)/u-boot-spl.bin | wc -c)
-MAX_SIZE= $(shell printf "%d" $(CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE))
-
-ifeq ($(CONFIG_SYS_K3_KEY), "")
-KEY=""
-# On HS use real key or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
-KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
-else
-$(warning "WARNING: signing key not found. Random key will NOT work on HS
hardware!")
-endif
-endif
-else
-KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
-endif
-
-# X509 SWRV default
-SWRV = $(CONFIG_K3_X509_SWRV)
-# On HS use SECDEV provided software revision or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/swrv.txt),)
-SWRV= $(shell cat $(TI_SECURE_DEV_PKG)/keys/swrv.txt)
-else
-$(warning "WARNING: Software revision file not found. Default may not work on
HS hardware.")
-endif
-endif
-
-# tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
-# So restrict tiboot3.bin creation for CPU_V7R.
-ifdef CONFIG_CPU_V7R
-image_check: $(obj)/u-boot-spl.bin FORCE
- @if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \
- echo "===" >&2; \
- echo "ERROR: Final Image too big. " >&2;\
- echo "$< size = $(IMAGE_SIZE), max size = $(MAX_SIZE)" >&2; \
- echo "===" >&2; \
- exit 1; \
- fi
-
-tiboot3.bin: image_check FORCE
- $(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \
- -o $@ -l $(CONFIG_SPL_TEXT_BASE) -r $(SWRV) -k
$(KEY)
-
-INPUTS-y += tiboot3.bin
-endif
-
-ifdef CONFIG_ARM64
-
-ifeq ($(CONFIG_SOC_K3_J721E),)
-export DM := /dev/null
-endif
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-SPL_ITS := u-boot-spl-k3_HS.its
-$(SPL_ITS): export IS_HS=1
-INPUTS-y += tispl.bin_HS
-INPUTS-y += tispl.bin
-tispl.bin: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst
%,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST)))
-else
-SPL_ITS := u-boot-spl-k3.its
-INPUTS-y += tispl.bin
-endif
-
-ifeq ($(CONFIG_SPL_OF_LIST),)
-LIST_OF_DTB := $(CONFIG_DEFAULT_DEVICE_TREE)
-else
-LIST_OF_DTB := $(CONFIG_SPL_OF_LIST)
-endif
-
-quiet_cmd_k3_mkits = MKITS $@
-cmd_k3_mkits = \
- $(srctree)/tools/k3_fit_atf.sh \
- $(CONFIG_K3_ATF_LOAD_ADDR) \
- $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(LIST_OF_DTB))) > $@
-
-$(SPL_ITS): FORCE
- $(call cmd,k3_mkits)
-endif
-
-else
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-INPUTS-y += u-boot.img_HS
-else
-INPUTS-y += u-boot.img
-endif
-endif
-
-include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
deleted file mode 100755
index 7bc07ad074..00
--- a/tools/k3_fit_atf.sh
+++ /dev/null
@@ -1,123 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0+
-#
-# script to generate FIT image source for K3 Family boards with
-# ATF, OPTEE, SPL and multiple device trees (given on the command line).
-# Inspired from board/sunxi/mksunxi_fit_atf.sh
-#
-# usage: $0 [ [&2
- ATF=/dev/null
-fi
-
-[ -z "$TEE" ] && TEE="bl32.bin"
-
-if [ ! -f $TEE ]; then
- echo "WARNING OPTEE file $TEE NOT found, resulting might be
non-functional" >&2
- TEE=/dev/null
-fi
-
-[ -z "$DM" ] && DM="dm.bin"
-
-if [ ! -e $DM ]; then
- echo "WARNING DM file $DM NOT found, resulting might be non-functional"
>&2
- DM=/dev/null
-fi
-
-if [ ! -z "$IS_HS" ]; then
- HS_APPEND=_HS
-fi
-
-cat << __HEADER_EOF
-/dts-v1/;
-
-/ {
- description = "Configuration to load A
[PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
Earlier documentation specified builds for generating bootloader images using an external TI repository k3-image-gen and core-secdev-k3. Modify this to using the binman flow so that user understands how to build the final boot images. Signed-off-by: Neha Malcom Francis Reviewed-by: Simon Glass --- doc/board/ti/am62x_sk.rst | 42 - doc/board/ti/j721e_evm.rst | 50 +--- doc/board/ti/k3.rst| 95 +- 3 files changed, 73 insertions(+), 114 deletions(-) diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index 27d7b527c6..e4d58b4958 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -115,23 +115,19 @@ Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master -5. TI Linux Firmware: +4. TI Linux Firmware: Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git Branch: ti-linux-firmware @@ -139,35 +135,37 @@ Build procedure: 1. ATF: -.. code-block:: text +.. code-block:: bash - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=lite SPD=opteed + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=lite SPD=opteed 2. OPTEE: -.. code-block:: text +.. code-block:: bash - $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- CROSS_COMPILE64=aarch64-none-linux-gnu- + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- \ +CROSS_COMPILE64=aarch64-none-linux-gnu- 3. U-Boot: * 3.1 R5: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am62x_evm_r5_defconfig O=/tmp/r5 - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 - $ cd - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=/ti-sysfw/ti-fs-firmware-am62x-gp.bin - -Use the tiboot3.bin generated from last command + $ make ARCH=arm am62x_evm_r5_defconfig + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ +BINMAN_INDIRS= * 3.2 A53: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am62x_evm_a53_defconfig O=/tmp/a53 - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=/build/k3/lite/release/bl31.bin TEE=/out/arm-plat-k3/core/tee-pager_v2.bin DM=/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f O=/tmp/a53 + $ make ARCH=arm am62x_evm_a53_defconfig + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ +BL31=/build/k3/lite/release/bl31.bin \ +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ +BINMAN_INDIRS= Target Images -- diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst index feaa2da5e9..9e604f6f12 100644 --- a/doc/board/ti/j721e_evm.rst +++ b/doc/board/ti/j721e_evm.rst @@ -130,67 +130,61 @@ support. Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. DM Firmware: - Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git - Branch: ti-linux-firmware - -5. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master +4. TI Linux Firmware: + Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git + Branch: ti-linux-firmware + Build procedure: -1. SYSFW: - -.. code-block:: bash - -make CROSS_COMPILE=arm-linux-gnueabihf- SOC=j721e - -2. ATF: +1. ATF: .. code-block:: bash -make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed + $ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=generic SPD=opteed -3. OPTEE: +2. OPTEE: .. code-block:: bash -make PLATFORM=k3-j721e CFG_ARM64_core=y + $ make PLATFORM=k3-j721e CFG_ARM64_core=y -4. U-Boot: +3. U-Boot: * 4.1 R5: .. code-block:: bash -make CROSS_COMPILE=arm-linux-gnueabihf- j721e_evm_r5_defconfig O=build/r5 -make CROSS_COMPILE=arm-linux-gnueabihf- O=build/r5 + $ make j721e_evm_r5_defconfig + $ make CROSS_COMPILE=arm-linux-gnueabihf- \ +BINMAN_INDIRS= * 4.2 A72: .. code-block:: bash -make CROSS_COMP
[PATCH v5 21/23] binman: Overwrite symlink if it already exists
From: Andrew Davis Without this re-building will fail with an error when trying to create the symlink for the second time with an already exists error. Signed-off-by: Andrew Davis Signed-off-by: Neha Malcom Francis --- tools/binman/image.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/binman/image.py b/tools/binman/image.py index 8ebf71d61a..e77b5d0d97 100644 --- a/tools/binman/image.py +++ b/tools/binman/image.py @@ -182,6 +182,8 @@ class Image(section.Entry_section): # Create symlink to file if symlink given if self._symlink is not None: sname = tools.get_output_filename(self._symlink) +if os.path.islink(sname): +os.remove(sname) os.symlink(fname, sname) def WriteMap(self): -- 2.34.1
[PATCH v5 22/23] buildman: Create a requirements.txt file
From: Tom Rini At this point, buildman requires a few different modules and so we need a requirements.txt to track what modules are needed. Cc: Simon Glass Cc: Neha Malcom Francis Signed-off-by: Tom Rini Reviewed-by: Simon Glass Signed-off-by: Neha Malcom Francis --- tools/buildman/requirements.txt | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 tools/buildman/requirements.txt diff --git a/tools/buildman/requirements.txt b/tools/buildman/requirements.txt new file mode 100644 index 00..a1efcb9d4b --- /dev/null +++ b/tools/buildman/requirements.txt @@ -0,0 +1,2 @@ +jsonschema==4.17.3 +pyyaml==6.0 -- 2.34.1
[PATCH v5 23/23] CI: Make use of buildman requirements.txt
From: Tom Rini
Now that buildman has a requirements.txt file we need to make use of it.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
[n-fran...@ti.com: Adding missing command from .azure-pipelines.yml]
Signed-off-by: Neha Malcom Francis
---
.azure-pipelines.yml | 4
.gitlab-ci.yml | 4
2 files changed, 8 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 06c46b681c..8626b27d4b 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -162,6 +162,7 @@ stages:
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl
export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt
export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}
@@ -209,6 +210,7 @@ stages:
git config --global --add safe.directory $(work_dir)
export USER=azure
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
pip install asteval pylint==2.12.2 pyopenssl
export PATH=${PATH}:~/.local/bin
echo "[MASTER]" >> .pylintrc
@@ -404,6 +406,7 @@ stages:
if [ -n "${BUILD_ENV}" ]; then
export ${BUILD_ENV};
fi
+ pip install -r tools/buildman/requirements.txt
tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W -e
--board ${TEST_PY_BD} ${OVERRIDE}
cp ~/grub_x86.efi ${UBOOT_TRAVIS_BUILD_DIR}/
cp ~/grub_x64.efi ${UBOOT_TRAVIS_BUILD_DIR}/
@@ -583,6 +586,7 @@ stages:
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
git config --global --add safe.directory ${WORK_DIR}
+ pip install -r tools/buildman/requirements.txt
EOF
cat << "EOF" >> build.sh
if [[ "${BUILDMAN}" != "" ]]; then
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cfd58513c3..07d8ba5ac2 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -97,6 +97,7 @@ build all 32bit ARM platforms:
script:
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM arm -x aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -110,6 +111,7 @@ build all 64bit ARM platforms:
- . /tmp/venv/bin/activate
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -208,6 +210,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
virtualenv -p /usr/bin/python3 /tmp/venv;
. /tmp/venv/bin/activate;
pip install -r test/py/requirements.txt;
+ pip install -r tools/buildman/requirements.txt;
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
@@ -240,6 +243,7 @@ Run pylint:
script:
- git config --global --add safe.directory "${CI_PROJECT_DIR}"
- pip install -r test/py/requirements.txt
+- pip install -r tools/buildman/requirements.txt
- pip install asteval pylint==2.12.2 pyopenssl
- export PATH=${PATH}:~/.local/bin
- echo "[MASTER]" >> .pylintrc
--
2.34.1
[PATCH] binman: Support templating with multiple images
Allow a template to appear in the top level description when using
multiple images.
Signed-off-by: Simon Glass
---
tools/binman/control.py | 5 ++--
tools/binman/ftest.py| 12 ++
tools/binman/test/287_template_multi.dts | 29
3 files changed, 44 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/287_template_multi.dts
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 0f98e9904fb1..b334fbc8ac8f 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
images = OrderedDict()
if 'multiple-images' in binman_node.props:
for node in binman_node.subnodes:
-images[node.name] = Image(node.name, node,
- use_expanded=use_expanded)
+if 'template' not in node.name:
+images[node.name] = Image(node.name, node,
+ use_expanded=use_expanded)
else:
images['image'] = Image('image', binman_node,
use_expanded=use_expanded)
return images
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 389d3906371a..c783424c91da 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6771,6 +6771,18 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
+def testEntryTemplateBlobMulti(self):
+"""Test using a template with 'multiple-images' enabled"""
+TestFunctional._MakeInputFile('my-blob.bin', b'blob')
+TestFunctional._MakeInputFile('my-blob2.bin', b'other')
+retcode = self._DoTestFile('287_template_multi.dts')
+
+self.assertEqual(0, retcode)
+image = control.images['image']
+image_fname = tools.get_output_filename('my-image.bin')
+data = tools.read_file(image_fname)
+self.assertEqual(b'blobother', data)
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/287_template_multi.dts
b/tools/binman/test/287_template_multi.dts
new file mode 100644
index ..15bd8701c671
--- /dev/null
+++ b/tools/binman/test/287_template_multi.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/dts-v1/;
+/ {
+ binman: binman {
+ multiple-images;
+
+ my_template: template {
+ blob-ext@0 {
+ filename = "my-blob.bin";
+ offset = <0>;
+ };
+ blob-ext@8 {
+ offset = <8>;
+ };
+ };
+
+ image {
+ pad-byte = <0x40>;
+ filename = "my-image.bin";
+ insert-template = <&my_template>;
+ blob-ext@8 {
+ filename = "my-blob2.bin";
+ };
+ };
+ };
+};
--
2.41.0.390.g38632f3daf-goog
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>
> On 05.07.23 00:14, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
> >>
> >> Hi Simon,
> >>
> >> On 28.06.23 13:41, Simon Glass wrote:
> >>> Collections can used to collect the contents of other entries into a
> >>> single entry, but they result in a single entry, with the original entries
> >>> 'left behind' in their old place.
> >>>
> >>> It is useful to be able to specific a set of entries ones and have it used
> >>> in multiple images, or parts of an image.
> >>>
> >>> Implement this mechanism.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>> tools/binman/binman.rst | 80
> >>> tools/binman/control.py | 9 +++
> >>> tools/binman/etype/section.py| 3 +-
> >>> tools/binman/ftest.py| 8 +++
> >>> tools/binman/test/286_entry_template.dts | 42 +
> >>> 5 files changed, 141 insertions(+), 1 deletion(-)
> >>> create mode 100644 tools/binman/test/286_entry_template.dts
> >>>
> >>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> >>> index a4b31fe5397b..9be979ae1c5b 100644
> >>> --- a/tools/binman/binman.rst
> >>> +++ b/tools/binman/binman.rst
> >>> @@ -727,6 +727,13 @@ optional:
> >>> Note that missing, optional blobs do not produce a non-zero exit
> >>> code from
> >>> binman, although it does show a warning about the missing external
> >>> blob.
> >>>
> >>> +insert-template:
> >>> +This is not strictly speaking an entry property, since it is
> >>> processed early
> >>> +in Binman before the entries are read. It is a list of phandles of
> >>> nodes to
> >>> +include in the current (target) node. For each node, its subnodes
> >>> and their
> >>> +properties are brought into the target node. See Templates_ below for
> >>> +more information.
> >>> +
> >>> The attributes supported for images and sections are described below.
> >>> Several
> >>> are similar to those for entries.
> >>>
> >>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> >>> going on, you can use
> >>> arch/arm/dts/u-boot.dtsi ... found:
> >>> "arch/arm/dts/juno-r2-u-boot.dtsi"
> >>>
> >>>
> >>> +Templates
> >>> +=
> >>> +
> >>> +Sometimes multiple images need to be created which have all have a common
> >>> +part. For example, a board may generate SPI and eMMC images which both
> >>> include
> >>> +a FIT. Since the FIT includes many entries, it is tedious to repeat them
> >>> twice
> >>> +in the image description.
> >>> +
> >>> +Templates provide a simple way to handle this::
> >>> +
> >>> +binman {
> >>> +multiple-images;
> >>> +common_part: template-1 {
> >>> +fit {
> >>> +... lots of entries in here
> >>> +};
> >>> +
> >>> +text {
> >>> +text = "base image";
> >>> +};
> >>> +};
> >>> +
> >>> +spi-image {
> >>> +filename = "image-spi.bin";
> >>> +insert-template = <&fit>;
> >>> +
> >>> +/* things specific to SPI follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "SPI image";
> >>> +};
> >>> +};
> >>> +
> >>> +mmc-image {
> >>> +filename = "image-mmc.bin";
> >>> +insert-template = <&fit>;
> >>> +
> >>> +/* things specific to MMC follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "MMC image";
> >>> +};
> >>> +};
> >>> +};
> >>> +
> >>> +The template node name must start with 'template', so it is not
> >>> considered to be
> >>> +an image itself.
> >>> +
> >>> +The mechanism is very simple. For each phandle in the 'insert-templates'
> >>> +property, the source node is looked up. Then the subnodes of that source
> >>> node
> >>> +are copied into the target node, i.e. the one containing the
> >>> `insert-template`
> >>> +property.
> >>> +
> >>> +If the target node has a node with the same name as a template, its
> >>> properties
> >>> +override corresponding properties in the template. This allows the
> >>> template to
> >>> +be uses as a base, with the node providing updates to the properties as
> >>> needed.
> >>> +The overriding happens recursively.
> >>> +
> >>> +At present there is an unpleasant limitation on this feature: it works by
> >>> +appending the template nodes after any existing subnodes to the target
> >>> node.
> >>> +This means that if the target node includes any subnodes, these appear
> >>> in order
> >>> +before the template node. In the above example, 'header' becomes the
> >>> first
> >>> +subnode of each image, followed by `fit` and `text`. If this is not what
> >>> is
> >>> +desired, there is no way to adjust it.
> >>> +
> >>
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 18:04-20230707, Neha Malcom Francis wrote: > Earlier documentation specified builds for generating bootloader images > using an external TI repository k3-image-gen and core-secdev-k3. Modify > this to using the binman flow so that user understands how to build the > final boot images. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > --- > doc/board/ti/am62x_sk.rst | 42 - > doc/board/ti/j721e_evm.rst | 50 +--- > doc/board/ti/k3.rst| 95 +- > 3 files changed, 73 insertions(+), 114 deletions(-) > [...] > > Sources: > > -1. SYSFW: > - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git > - Branch: master > - > -2. ATF: > +1. ATF: Minor nitpick: ATF was the old name https://community.arm.com/oss-platforms/w/docs/483/trusted-firmware-a Trusted Firmware-A is the new name. > Tree: https://github.com/ARM-software/arm-trusted-firmware.git I believe the official repo is https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 7/7/23 14:34, Neha Malcom Francis wrote: > Earlier documentation specified builds for generating bootloader images > using an external TI repository k3-image-gen and core-secdev-k3. Modify > this to using the binman flow so that user understands how to build the > final boot images. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > --- > doc/board/ti/am62x_sk.rst | 42 - > doc/board/ti/j721e_evm.rst | 50 +--- > doc/board/ti/k3.rst| 95 +- > 3 files changed, 73 insertions(+), 114 deletions(-) > > diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst > index 27d7b527c6..e4d58b4958 100644 > --- a/doc/board/ti/am62x_sk.rst > +++ b/doc/board/ti/am62x_sk.rst [...] > @@ -139,35 +135,37 @@ Build procedure: > > 1. ATF: > > -.. code-block:: text > +.. code-block:: bash > > - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 > TARGET_BOARD=lite SPD=opteed > + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ > +TARGET_BOARD=lite SPD=opteed > > 2. OPTEE: > > -.. code-block:: text > +.. code-block:: bash > > - $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- > CROSS_COMPILE64=aarch64-none-linux-gnu- > + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- > \ > +CROSS_COMPILE64=aarch64-none-linux-gnu- > > 3. U-Boot: > > * 3.1 R5: > > -.. code-block:: text > +.. code-block:: bash > > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- > am62x_evm_r5_defconfig O=/tmp/r5 > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 > - $ cd > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x > SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH= ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin > - > -Use the tiboot3.bin generated from last command > + $ make ARCH=arm am62x_evm_r5_defconfig > + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ > +BINMAN_INDIRS= > > * 3.2 A53: > > -.. code-block:: text > +.. code-block:: bash > > - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- > am62x_evm_a53_defconfig O=/tmp/a53 > - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF= dir>/build/k3/lite/release/bl31.bin TEE= dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM= ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f > O=/tmp/a53 > + $ make ARCH=arm am62x_evm_a53_defconfig > + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ > +BL31=/build/k3/lite/release/bl31.bin \ > +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used instead of tee-pager_v2.bin. Indeed when the "pager" feature is not enabled, the two binaries are identical, and the newer name is hopefully less confusing. -- Jerome
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 07.07.23 14:34, Neha Malcom Francis wrote:
> Move to using binman to generate tispl.bin which is used to generate the
> final flash.bin bootloader for iot2050 boards.
>
> Signed-off-by: Neha Malcom Francis
> Cc: Jan Kiszka
> ---
> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++-
> 1 file changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> index 03ccc54329..9d83898d33 100644
> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> @@ -26,9 +26,81 @@
> missing-msg = "iot2050-seboot";
> };
>
> - blob@0x18 {
> + fit@0x18 {
> offset = <0x18>;
> - filename = "tispl.bin";
> + pad-byte = <0xff>;
> + description = "Configuration to load ATF and SPL";
> +
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf: atf-bl31 {
> + };
> + };
> +
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee: tee-os {
> + };
> + };
> +
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + blob-ext {
> + filename = "/dev/null";
> + };
> + };
> +
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u_boot_spl_nodtb: blob-ext {
> + filename =
> "spl/u-boot-spl-nodtb.bin";
> + };
> + };
> +
> + fdt-0 {
> + description = "k3-am65-iot2050-spl.dtb";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + spl_am65x_evm_dtb: blob-ext {
> + filename =
> "spl/dts/k3-am65-iot2050-spl.dtb";
> + };
> + };
> + };
> +
> + configurations {
> + default = "spl";
> + spl {
> + fdt = "fdt-0";
> + firmware = "atf";
> + loadables = "tee", "dm", "spl";
> + };
> + };
> };
>
> fit@0x38 {
Looks ok (will have to test), but this lacks adjustment of
tools/iot2050-sign-fw.sh, probably something around
s/tispl.bin/fit@0x18/g.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 07.07.23 15:30, Jerome Forissier wrote: > > > On 7/7/23 14:34, Neha Malcom Francis wrote: >> Earlier documentation specified builds for generating bootloader images >> using an external TI repository k3-image-gen and core-secdev-k3. Modify >> this to using the binman flow so that user understands how to build the >> final boot images. >> >> Signed-off-by: Neha Malcom Francis >> Reviewed-by: Simon Glass >> --- >> doc/board/ti/am62x_sk.rst | 42 - >> doc/board/ti/j721e_evm.rst | 50 +--- >> doc/board/ti/k3.rst| 95 +- >> 3 files changed, 73 insertions(+), 114 deletions(-) >> >> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >> index 27d7b527c6..e4d58b4958 100644 >> --- a/doc/board/ti/am62x_sk.rst >> +++ b/doc/board/ti/am62x_sk.rst > [...] >> @@ -139,35 +135,37 @@ Build procedure: >> >> 1. ATF: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 >> TARGET_BOARD=lite SPD=opteed >> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ >> +TARGET_BOARD=lite SPD=opteed >> >> 2. OPTEE: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- >> CROSS_COMPILE64=aarch64-none-linux-gnu- >> + $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +CROSS_COMPILE64=aarch64-none-linux-gnu- >> >> 3. U-Boot: >> >> * 3.1 R5: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >> am62x_evm_r5_defconfig O=/tmp/r5 >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 >> - $ cd >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x >> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >> - >> -Use the tiboot3.bin generated from last command >> + $ make ARCH=arm am62x_evm_r5_defconfig >> + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +BINMAN_INDIRS= >> >> * 3.2 A53: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >> am62x_evm_a53_defconfig O=/tmp/a53 >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=> dir>/build/k3/lite/release/bl31.bin TEE=> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f >> O=/tmp/a53 >> + $ make ARCH=arm am62x_evm_a53_defconfig >> + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ >> +BL31=/build/k3/lite/release/bl31.bin \ >> +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ > > Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used instead of > tee-pager_v2.bin. Indeed when the "pager" feature is not enabled, the two > binaries are identical, and the newer name is hopefully less confusing. > Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and our integration recipes). Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH] MAINTAINERS: correct at91 tree link
This was not done when the tree name was changed, fix it now. Signed-off-by: Eugen Hristev --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d724b6467344..2477923a5201 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -409,7 +409,7 @@ F: configs/uDPU_defconfig ARM MICROCHIP/ATMEL AT91 M: Eugen Hristev S: Maintained -T: git https://source.denx.de/u-boot/custodians/u-boot-atmel.git +T: git https://source.denx.de/u-boot/custodians/u-boot-at91.git F: arch/arm/mach-at91/ F: board/atmel/ F: drivers/cpu/at91_cpu.c -- 2.34.1
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 07, 2023 at 08:42:33AM -0300, Anne Macedo wrote:
> On Thu, Jul 06, 2023 at 11:51:54PM +, Anne Macedo wrote:
> > On Wed, Jul 05, 2023 at 02:15:43PM -0300, Fabio Estevam wrote:
> > > On Wed, Jul 5, 2023 at 1:31 PM Anne Macedo wrote:
> > >
> > > > I think I'm on the right path :)
> > > >
> > > > 1. Included SUNXI_SETUP_REGULATORS=0 to the bl31 make
> > > > 2. Changed the phy mode on arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > >From rgmii-id to rgmii
> > >
> > > This does not look like the correct fix. Please see this commit from
> > > Linux:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.4.1&id=544cc3f8573bf9a82e8f348741f2f68d2a8376fb
> > >
> > > >More info on [1][2][3]
> > > > 3. Added this configs to configs/orangepi_one_plus_defconfig:
> > > >CONFIG_SPL_SPI_SUNXI=y
> > > >CONFIG_SUNXI_NO_PMIC=y
> > >e>CONFIG_SUN8I_EMAC=y
> > > >
> > > > Result:
> > > >
> > > > U-Boot 2023.04-gfd4ed6b (Apr 03 2023 - 20:38:50 +) Allwinner
> > > > Technology
> > > >
> > > > CPU: Allwinner H6 (SUN50I)
> > > > Model: OrangePi One Plus
> > > > DRAM: 1 GiB
> > > > Core: 55 devices, 17 uclasses, devicetree: separate
> > > > WDT: Not starting watchdog@7020400
> > > > MMC: mmc@402: 0
> > > > Loading Environment from FAT... Unable to read "uboot.env" from
> > > > mmc0:1...
> > > > In:serial@500
> > > > Out: serial@500
> > > > Err: serial@500
> > > > Net: eth0: ethernet@502
> > > >
> > > > => dhcp
> > > > sun8i_emac_eth_start: Timeout
> > > > => mdio list
> > > > ethernet@502:
> > > > 1 - Generic PHY <--> ethernet@502
> > >
> > > What about using the Realtek PHY driver instead of the Generic one?
> > >
> > > --- a/configs/orangepi_one_plus_defconfig
> > > +++ b/configs/orangepi_one_plus_defconfig
> > > @@ -8,3 +8,6 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y
> > > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > CONFIG_USB_EHCI_HCD=y
> > > CONFIG_USB_OHCI_HCD=y
> > > +CONFIG_PHY_REALTEK=y
> > > +CONFIG_RGMII=y
> > > +CONFIG_MII=y
> > >
> > > Does this help?
> >
> > Sorry for the delay, life came in the way.
> >
> > u-boot config:
> > CONFIG_PHY_REALTEK=y
> > CONFIG_RGMII=y
> > CONFIG_MII=y
> >
> > tfa config:
> > SUNXI_SETUP_REGULATORS=0
> >
> > result:
> > => dhcp
> > No ethernet found.
> >
> > u-boot config:
> > CONFIG_SPL_SPI_SUNXI=y
> > CONFIG_SUNXI_NO_PMIC=y
> > CONFIG_SUN8I_EMAC=y
> > CONFIG_PHY_REALTEK=y
> > CONFIG_RGMII=y
> > CONFIG_MII=y
> >
> > tfa config:
> > SUNXI_SETUP_REGULATORS=0
> >
> > result:
> > Net: PHY reset timed out
> > eth0: ethernet@502
> > => dhcp
> > sun8i_emac_eth_start: Timeout
> > => mdio list
> > ethernet@502:
> > 1 - Generic PHY <--> ethernet@502
> >
> > It's interesting that it keeps using Generic PHY.
> >
> > Regards,
> > Anne
> >
>
> OH! I believe I discovered something I overlooked:
>
> On arch/arm/dts/sun50i-h6-orangepi-one-plus.dts:
>
> reg_gmac_3v3: gmac-3v3 {
> compatible = "regulator-fixed";
> regulator-name = "vcc-gmac-3v3";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> startup-delay-us = <10>;
> enable-active-high;
> gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> vin-supply = <®_aldo2>;
> };
>
> After I connected GPIO 3 to GPIO 6, the Ethernet LED turned on!
Okay, I completely misunderstood this... and I lost the combination that
turned the LED on :(
It seems that PD6 is not exposed on the GPIO header [1]. It is defined
on the FBGA on the pin map session of the datasheet [2]. So, I don't
believe I need to short the pins to get it working, but somehow it at
least powered on the Ethernet port. I wish I remember the combination.
[1]
https://forum.armbian.com/uploads/monthly_2020_04/873961756_Opioneplusgpio.jpg.e28c37c0f66189dc68e86a428a5a8b95.jpg
[2]
https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf
UPDATE: I did it!
On u-boot shell:
gpio set pd6
then dhcp command works :). However, it doesn't get an IP and with
static IP pinging doesn't work.
It seems to be able to send BOOTP broadcasts but it doesn't get an IP...
Combination was:
u-boot config:
CONFIG_SPL_SPI_SUNXI=y
CONFIG_SUN8I_EMAC=y
tfa config:
SUNXI_SETUP_REGULATORS=1 (or just unset this)
>
> I still see:
>
> => dhcp
> sun8i_emac_eth_start: Timeout
>
> And
>
> Net: PHY reset timed out
> eth0: ethernet@502
>
> Regards,
> Anne
Regards,
Anne
RE: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
>On 07.07.23 15:30, Jerome Forissier wrote: >> >> >> On 7/7/23 14:34, Neha Malcom Francis wrote: >>> Earlier documentation specified builds for generating bootloader >>> images using an external TI repository k3-image-gen and >>> core-secdev-k3. Modify this to using the binman flow so that user >>> understands how to build the final boot images. >>> >>> Signed-off-by: Neha Malcom Francis >>> Reviewed-by: Simon Glass >>> --- >>> doc/board/ti/am62x_sk.rst | 42 - >>> doc/board/ti/j721e_evm.rst | 50 +--- >>> doc/board/ti/k3.rst| 95 +- >>> 3 files changed, 73 insertions(+), 114 deletions(-) >>> >>> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >>> index 27d7b527c6..e4d58b4958 100644 >>> --- a/doc/board/ti/am62x_sk.rst >>> +++ b/doc/board/ti/am62x_sk.rst >> [...] >>> @@ -139,35 +135,37 @@ Build procedure: >>> >>> 1. ATF: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 >>> TARGET_BOARD=lite SPD=opteed >>> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 \ >>> +TARGET_BOARD=lite SPD=opteed >>> >>> 2. OPTEE: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make PLATFORM=k3 CFG_ARM64_core=y >>> CROSS_COMPILE=arm-none-linux-gnueabihf- >>> CROSS_COMPILE64=aarch64-none-linux-gnu- >>> + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none- >linux-gnueabihf- \ >>> +CROSS_COMPILE64=aarch64-none-linux-gnu- >>> >>> 3. U-Boot: >>> >>> * 3.1 R5: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >>> am62x_evm_r5_defconfig O=/tmp/r5 >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >O=/tmp/r5 >>> - $ cd >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >SOC=am62x >>> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=>> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >>> - >>> -Use the tiboot3.bin generated from last command >>> + $ make ARCH=arm am62x_evm_r5_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=arm-none-linux-gnueabihf- \ >>> +BINMAN_INDIRS= >>> >>> * 3.2 A53: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >>> am62x_evm_a53_defconfig O=/tmp/a53 >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=to >>> ATF dir>/build/k3/lite/release/bl31.bin TEE=>> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=>> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.x >>> er5f O=/tmp/a53 >>> + $ make ARCH=arm am62x_evm_a53_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=aarch64-none-linux-gnu- \ >>> +BL31=/build/k3/lite/release/bl31.bin \ >>> +TEE=>> + dir>/out/arm-plat-k3/core/tee-pager_v2.bin \ >> >> Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used >> instead of tee-pager_v2.bin. Indeed when the "pager" feature is not >> enabled, the two binaries are identical, and the newer name is hopefully >less confusing. >> > >Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and >our integration recipes). And J7200 docs as well, however this doc is on next https://github.com/u-boot/u-boot/blob/next/doc/board/ti/j7200_evm.rst > >Jan > >-- >Siemens AG, Technology >Competence Center Embedded Linux
[RFC] riscv: (visionfive2:) device tree binding for riscv_timer
Hi,
following the existing device tree binding[1], here is a draft to use it
in drivers/timer/riscv_timer.c. This would also fix the regression we see
with commit 55171aedda8 ("dm: Emit the arch_cpu_init_dm() even only
before relocation"), at least on the VisionFive2, as sketched out below.
The device tree addition suits the Linux kernel dirver
| riscv-timer: riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [3]
The of_match, along with the "timebase-frequency" property, provides
a working timer (again) on the VF2.
If this is the way to go, I'll turn this into a nicer patch series.
Comments welcome!
Torsten
[1] linux/Documentation/devicetree/bindings/timer/riscv,timer.yaml
---
arch/riscv/dts/jh7110.dtsi | 10 ++
configs/starfive_visionfive2_defconfig |1 -
drivers/timer/riscv_timer.c| 21 ++---
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 3627ed79b8..03dda12f73 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,9 +54,18 @@ u64 notrace timer_early_get_count(void)
static int riscv_timer_probe(struct udevice *dev)
{
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
/* clock frequency was passed from the cpu driver as driver data */
- uc_priv->clock_rate = dev->driver_data;
+ u32 rate = dev->driver_data;
+
+ if (!rate && gd->fdt_blob) {/* not called from CPU driver?
*/
+ rate = fdt_getprop_u32_default(gd->fdt_blob,
+ "/cpus", "timebase-frequency",
0);
+ }
+ uc_priv->clock_rate = rate;
+
+ /* timer uclass post_probe will later fail with -EINVAL. Hint at the
cause! */
+ if (!rate)
+ log_err("riscv_timer_probe with clock rate 0\n");
return 0;
}
@@ -64,10 +74,15 @@ static const struct timer_ops riscv_timer_ops = {
.get_count = riscv_timer_get_count,
};
+static const struct udevice_id riscv_timer_ids[] = {
+{ .compatible = "riscv,timer", },
+{ }
+};
+
U_BOOT_DRIVER(riscv_timer) = {
.name = "riscv_timer",
.id = UCLASS_TIMER,
+ .of_match = of_match_ptr(riscv_timer_ids),
.probe = riscv_timer_probe,
.ops = &riscv_timer_ops,
- .flags = DM_FLAG_PRE_RELOC,
};
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index c61730e8d1..9944f261b3 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include
#include
+#include
/ {
compatible = "starfive,jh7110";
@@ -204,6 +205,15 @@
};
};
+ timer {
+ compatible = "riscv,timer";
+ interrupts-extended = <&cpu0_intc HART_INT_S_TIMER>,
+ <&cpu1_intc HART_INT_S_TIMER>,
+ <&cpu2_intc HART_INT_S_TIMER>,
+ <&cpu3_intc HART_INT_S_TIMER>,
+ <&cpu4_intc HART_INT_S_TIMER>;
+ };
+
osc: oscillator {
compatible = "fixed-clock";
clock-output-names = "osc";
diff --git a/configs/starfive_visionfive2_defconfig
b/configs/starfive_visionfive2_defconfig
index 570a1f53a1..3a213b2601 100644
--- a/configs/starfive_visionfive2_defconfig
+++ b/configs/starfive_visionfive2_defconfig
@@ -102,4 +102,3 @@ CONFIG_PINCTRL_STARFIVE=y
# CONFIG_RAM_SIFIVE is not set
CONFIG_SYS_NS16550=y
CONFIG_CADENCE_QSPI=y
-CONFIG_TIMER_EARLY=y
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 7, 2023 at 10:46 AM Anne Macedo wrote: > On u-boot shell: > > gpio set pd6 Good point. You should pass the following options: CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y so that the GPIO3_6 turns on by default and then you would not need to run the "gpio set pd6" command. > then dhcp command works :). However, it doesn't get an IP and with > static IP pinging doesn't work.
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 14:42, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>>
>> On 05.07.23 00:14, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
Hi Simon,
On 28.06.23 13:41, Simon Glass wrote:
> Collections can used to collect the contents of other entries into a
> single entry, but they result in a single entry, with the original entries
> 'left behind' in their old place.
>
> It is useful to be able to specific a set of entries ones and have it used
> in multiple images, or parts of an image.
>
> Implement this mechanism.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/binman.rst | 80
> tools/binman/control.py | 9 +++
> tools/binman/etype/section.py| 3 +-
> tools/binman/ftest.py| 8 +++
> tools/binman/test/286_entry_template.dts | 42 +
> 5 files changed, 141 insertions(+), 1 deletion(-)
> create mode 100644 tools/binman/test/286_entry_template.dts
>
> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> index a4b31fe5397b..9be979ae1c5b 100644
> --- a/tools/binman/binman.rst
> +++ b/tools/binman/binman.rst
> @@ -727,6 +727,13 @@ optional:
> Note that missing, optional blobs do not produce a non-zero exit
> code from
> binman, although it does show a warning about the missing external
> blob.
>
> +insert-template:
> +This is not strictly speaking an entry property, since it is
> processed early
> +in Binman before the entries are read. It is a list of phandles of
> nodes to
> +include in the current (target) node. For each node, its subnodes
> and their
> +properties are brought into the target node. See Templates_ below for
> +more information.
> +
> The attributes supported for images and sections are described below.
> Several
> are similar to those for entries.
>
> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> going on, you can use
> arch/arm/dts/u-boot.dtsi ... found:
> "arch/arm/dts/juno-r2-u-boot.dtsi"
>
>
> +Templates
> +=
> +
> +Sometimes multiple images need to be created which have all have a common
> +part. For example, a board may generate SPI and eMMC images which both
> include
> +a FIT. Since the FIT includes many entries, it is tedious to repeat them
> twice
> +in the image description.
> +
> +Templates provide a simple way to handle this::
> +
> +binman {
> +multiple-images;
> +common_part: template-1 {
> +fit {
> +... lots of entries in here
> +};
> +
> +text {
> +text = "base image";
> +};
> +};
> +
> +spi-image {
> +filename = "image-spi.bin";
> +insert-template = <&fit>;
> +
> +/* things specific to SPI follow */
> +header {
> +];
> +
> +text {
> +text = "SPI image";
> +};
> +};
> +
> +mmc-image {
> +filename = "image-mmc.bin";
> +insert-template = <&fit>;
> +
> +/* things specific to MMC follow */
> +header {
> +];
> +
> +text {
> +text = "MMC image";
> +};
> +};
> +};
> +
> +The template node name must start with 'template', so it is not
> considered to be
> +an image itself.
> +
> +The mechanism is very simple. For each phandle in the 'insert-templates'
> +property, the source node is looked up. Then the subnodes of that source
> node
> +are copied into the target node, i.e. the one containing the
> `insert-template`
> +property.
> +
> +If the target node has a node with the same name as a template, its
> properties
> +override corresponding properties in the template. This allows the
> template to
> +be uses as a base, with the node providing updates to the properties as
> needed.
> +The overriding happens recursively.
> +
> +At present there is an unpleasant limitation on this feature: it works by
> +appending the template nodes after any existing subnodes to the target
> node.
> +This means that if the target node includes any subnodes, these appear
> in order
> +before the template node. In the above example, 'header' becomes the
> first
> +subnode of each image, followed by `fit` and `text`. If this is not what
> is
> +desir
Re: [PATCH v2] lib: sparse: allocate FASTBOOT_MAX_BLK_WRITE instead of small number
Hi Qianfan,
Thank you for your review.
On ven., juil. 07, 2023 at 18:54, qianfan wrote:
> 在 2023/7/7 16:13, Mattijs Korpershoek 写道:
>> Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>> fixed cache alignment for systems with a D-CACHE.
>>
>> However it introduced some performance regressions [1] on system
>> flashing huge images, such as Android.
>>
>> On AM62x SK EVM, we also observe such performance penalty:
>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
>> Writing 'super'OKAY [ 75.926s]
>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
>> Writing 'super'OKAY [ 62.849s]
>> Finished. Total time: 182.474s
>>
>> The reason for this is that we use an arbitrary small buffer
>> (info->blksz * 100) for transferring.
>>
>> Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
>> as suggested in the original's patch review [2].
>>
>> With this patch, performance impact is mitigated:
>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
>> Writing 'super'OKAY [ 15.780s]
>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
>> Writing 'super'OKAY [ 17.192s]
>> Finished. Total time: 76.569s
>>
>> [1]
>> https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
>> [2]
>> https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
>>
>> Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>> Signed-off-by: Mattijs Korpershoek
>> ---
>> Changes in v2:
>> - Use FASTBOOT_MAX_BLK_WRITE instead of blkcnt (Qianfan)
>> - Link to v1:
>> https://lore.kernel.org/r/20230616-sparse-flash-fix-v1-1-6bafeacc5...@baylibre.com
>> ---
>> drivers/fastboot/fb_mmc.c | 2 --
>> include/image-sparse.h| 2 ++
>> lib/image-sparse.c| 3 ++-
>> 3 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
>> index 9d25c402028a..060918e49109 100644
>> --- a/drivers/fastboot/fb_mmc.c
>> +++ b/drivers/fastboot/fb_mmc.c
>> @@ -19,8 +19,6 @@
>> #include
>> #include
>>
>> -#define FASTBOOT_MAX_BLK_WRITE 16384
>> -
>> #define BOOT_PARTITION_NAME "boot"
>>
>> struct fb_mmc_sparse {
>> diff --git a/include/image-sparse.h b/include/image-sparse.h
>> index 0572dbd0a283..282a0b256498 100644
>> --- a/include/image-sparse.h
>> +++ b/include/image-sparse.h
>> @@ -7,6 +7,8 @@
>> #include
>> #include
>>
>> +#define FASTBOOT_MAX_BLK_WRITE 16384
> Hi:
>
> Just a personal suggestion, define sometings like FASTBOOT_MAX_BLK_WRITE in
> image-sparse.c is very strange.
>
> Or maybe define a marco such as SPARSE_MAX_BLK_WRITE and set a default
> value to 16384, and leave some comments for why we choice this value.
I don't agree with having a duplicating between SPARSE_MAX_BLK_WRITE
and FASTBOOT_MAX_BLK_WRITE. code comments can rot as well.
And FASTBOOT_MAX_BLK_WRITE is used for both sparse and unsparsed image,
which is why I chose to not rename it.
>
> Thanks.
>> +
>> #define ROUNDUP(x, y) (((x) + ((y) - 1)) & ~((y) - 1))
>>
>> struct sparse_storage {
>> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
>> index 5ec0f94ab3eb..8f8a67e15804 100644
>> --- a/lib/image-sparse.c
>> +++ b/lib/image-sparse.c
>> @@ -55,7 +55,8 @@ static lbaint_t write_sparse_chunk_raw(struct
>> sparse_storage *info,
>> void *data,
>> char *response)
>> {
>> -lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
>> +lbaint_t n = blkcnt, write_blks, blks = 0;
>> +lbaint_t aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE;
>> uint32_t *aligned_buf = NULL;
>>
>> if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
>>
>> ---
>> base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
>> change-id: 20230616-sparse-flash-fix-9c2852aa8d16
>>
>> Best regards,
Re: [PATCH] binman: Support templating with multiple images
On 07.07.23 14:40, Simon Glass wrote:
> Allow a template to appear in the top level description when using
> multiple images.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/control.py | 5 ++--
> tools/binman/ftest.py| 12 ++
> tools/binman/test/287_template_multi.dts | 29
> 3 files changed, 44 insertions(+), 2 deletions(-)
> create mode 100644 tools/binman/test/287_template_multi.dts
>
> diff --git a/tools/binman/control.py b/tools/binman/control.py
> index 0f98e9904fb1..b334fbc8ac8f 100644
> --- a/tools/binman/control.py
> +++ b/tools/binman/control.py
> @@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
> images = OrderedDict()
> if 'multiple-images' in binman_node.props:
> for node in binman_node.subnodes:
> -images[node.name] = Image(node.name, node,
> - use_expanded=use_expanded)
> +if 'template' not in node.name:
> +images[node.name] = Image(node.name, node,
> + use_expanded=use_expanded)
> else:
> images['image'] = Image('image', binman_node,
> use_expanded=use_expanded)
> return images
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 389d3906371a..c783424c91da 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6771,6 +6771,18 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
> self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
>
> +def testEntryTemplateBlobMulti(self):
> +"""Test using a template with 'multiple-images' enabled"""
> +TestFunctional._MakeInputFile('my-blob.bin', b'blob')
> +TestFunctional._MakeInputFile('my-blob2.bin', b'other')
> +retcode = self._DoTestFile('287_template_multi.dts')
> +
> +self.assertEqual(0, retcode)
> +image = control.images['image']
> +image_fname = tools.get_output_filename('my-image.bin')
> +data = tools.read_file(image_fname)
> +self.assertEqual(b'blobother', data)
> +
>
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/287_template_multi.dts
> b/tools/binman/test/287_template_multi.dts
> new file mode 100644
> index ..15bd8701c671
> --- /dev/null
> +++ b/tools/binman/test/287_template_multi.dts
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/dts-v1/;
Duplicate.
> +/ {
> + binman: binman {
> + multiple-images;
> +
> + my_template: template {
> + blob-ext@0 {
> + filename = "my-blob.bin";
> + offset = <0>;
> + };
> + blob-ext@8 {
> + offset = <8>;
> + };
> + };
> +
> + image {
> + pad-byte = <0x40>;
> + filename = "my-image.bin";
> + insert-template = <&my_template>;
> + blob-ext@8 {
> + filename = "my-blob2.bin";
> + };
> + };
> + };
> +};
For the sake of context:
echo 1234 > my-blob.bin
echo 5678 > my-blob2.bin
dtc tools/binman/test/287_template_multi.dts -o binman-test.dtb
tools/binman/binman build -d binman-test.dtb -O .
binman: Node '/binman/image/blob-ext@0': Offset 0x0 (0) overlaps with previous
entry '/binman/image/blob-ext@8' ending at 0xd (13)
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [RESEND PATCH v1 1/4] riscv: t-head: licheepi4a: initial support added
Hi Leo
On 02:55 Thu 29 Jun , Leo Liang wrote:
> Hi YiXun,
> On Fri, May 26, 2023 at 08:41:04PM +0800, Yixun Lan wrote:
> > Add support for Sipeed's Lichee Pi 4A board which based on
> > T-HEAD's TH1520 SoC, only minimal device tree and serial onsole are enabled,
> > so it's capable of chain booting from T-HEAD's vendor u-boot.
> >
> > Reviewed-by: Wei Fu
> > Signed-off-by: Yixun Lan
> > ...
> > diff --git a/board/thead/th1520_lpi4a/board.c
> > b/board/thead/th1520_lpi4a/board.c
> > new file mode 100644
> > index 00..378bab098b
> > --- /dev/null
> > +++ b/board/thead/th1520_lpi4a/board.c
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2023, Yixun Lan
> > + *
> > + */
> > +
> > +#include
> > +
> > +int board_init(void)
> > +{
> > + enable_caches();
>
> There is a compilation warining here at "enable_caches"
> (probably due to cpu_func.h not being included to provide this function)
>
thanks, will fix in v2
>
> Best regards,
> Leo
> > +
> > + return 0;
> > +}
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 07, 2023 at 10:54:00AM -0300, Fabio Estevam wrote: > On Fri, Jul 7, 2023 at 10:46 AM Anne Macedo wrote: > > > On u-boot shell: > > > > gpio set pd6 > > Good point. You should pass the following options: > > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > > so that the GPIO3_6 turns on by default and then you would not need to > run the "gpio set pd6" command. That didn't work. I still had to enable with "gpio set pd6". Also, when it gets to the kernel, ethernet shuts down. I also don't see the device in my router, so I believe even though eth0 is up, something may not be working yet. > > > then dhcp command works :). However, it doesn't get an IP and with > > static IP pinging doesn't work.
[PATCH v14 00/11] introduce Arm FF-A support
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A]. FF-A specifies interfaces that enable a pair of software execution environments aka partitions to communicate with each other. A partition could be a VM in the Normal or Secure world, an application in S-EL0, or a Trusted OS in S-EL1. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. => dm tree Class Index Probed DriverName --- ... firmware 0 [ + ] psci |-- psci ffa 0 [ ] arm_ffa | `-- arm_ffa ... Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). This implementation of the specification provides support for Aarch64. The FF-A driver uses the SMC ABIs defined by the FF-A specification to: - Discover the presence of secure partitions (SPs) of interest - Access an SP's service through communication protocols (e.g: EFI MM communication protocol) The FF-A support provides the following features: - Being generic by design and can be used by any Arm 64-bit platform - FF-A support can be compiled and used without EFI - Support for SMCCCv1.2 x0-x17 registers - Support for SMC32 calling convention - Support for 32-bit and 64-bit FF-A direct messaging - Support for FF-A MM communication (compatible with EFI boot time) - Enabling FF-A and MM communication in Corstone1000 platform as a use case - A Uclass driver providing generic FF-A methods. - An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods. - A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides FF-A ABIs inspection methods. - An FF-A sandbox device driver for FF-A communication with the emulated Secure World. The driver leverages the FF-A Uclass to establish FF-A communication. - Sandbox FF-A test cases. - A new command called armffa is provided as an example of how to access the FF-A bus For more details about the FF-A support please refer to [B] and refer to [C] for how to use the armffa command. Please find at [D] an example of the expected boot logs when enabling FF-A support for a platform. In this example the platform is Corstone1000. But it can be any Arm 64-bit platform. Changelog of changes: === v14: Simon: * add to log.h a generic physical address formatting Ilias: * armffa command: in do_ffa_ping() reject the SP ID if it's 0 * MM comms: drop truncating var_payload->size when using FF-A * MM comms: map the MM SP return codes to errnos * address nits v13: [13] Ilias: * remove FF-A and Optee ifdefs in efi_variable_tee.c * doc minor change: specify in the readme that the user should call ffa_rxtx_unmap() driver operation to unmap the RX/TX buffers on demand. v12: [12] * remove the global variable (dscvry_info), use uc_priv instead * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn (user drivers can override it) * improve FFA_PARTITION_INFO_GET implementation (clients no longer need to calloc a buffer) * remove reparenting by making the sandbox emulator parent of the FF-A device in the DT * improve argument checks for the armffa command * address nits v11: [11] * move ffa_try_discovery() from the uclass to the Arm FF-A driver * rename ffa_try_discovery() to arm_ffa_discover() * add arm_ prefix to the Arm FF-A driver functions * use U_BOOT_CMD_WITH_SUBCMDS for armffa command * store the sandbox emulator pointer in the FF-A device uc_priv (struct ffa_priv) * set the emulator as parent of the sandbox FF-A device * rename select_ffa_mm_comms() to select_mm_comms() * improve the logic of MM transport selection in mm_communicate() * use ut_asserteq_mem() in uuid_str_to_le_bin test case * address nits v10: [10] * provide the FF-A driver operations through the Uclass (arm-ffa-uclass.c) * move the generic FF-A methods to the Uclass * keep Arm specific methods in the Arm driver (arm-ffa.c renamed from core.c) * split the FF-A sandbox support into an emulator (ffa-emul-uclass.c) and a driver (sandbox_ffa.c) * use the FF-A driver Uclass operations by clients (armffa command, tests, MM comms) * use uclass_first_device to search and probe the FF-A device (whether it is on Arm or on sandbox) * address nits v9: [9] * integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for binding * align FF-A sandbox driver with FF-A discovery through DM * use DM class APIs to probe and interact with the FF-A bus (in FF-A MM comms, armffa command, sandbox tests) * add documentation for the armffa command: doc/usage/cmd/armffa.rst * introduce testcase for uuid_str_to_le_bin v8: [8] * pass
[PATCH v14 01/11] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers
add support for x0-x17 registers used by the SMC calls In SMCCC v1.2 [1] arguments are passed in registers x1-x17. Results are returned in x0-x17. This work is inspired from the following kernel commit: arm64: smccc: Add support for SMCCCv1.2 extended input/output registers [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token= Signed-off-by: Abdellatif El Khlifi Reviewed-by: Ilias Apalodimas Reviewed-by: Jens Wiklander Reviewed-by: Simon Glass Cc: Tom Rini --- Changelog: === v9: * update the copyright string v7: * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS v4: * rename the commit title and improve description new commit title: the current v3: * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2 commit title: arm64: smccc: add Xn registers support used by SMC calls arch/arm/cpu/armv8/smccc-call.S | 57 - arch/arm/lib/asm-offsets.c | 16 + include/linux/arm-smccc.h | 45 ++ 3 files changed, 117 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S index dc92b28777..93f66d3366 100644 --- a/arch/arm/cpu/armv8/smccc-call.S +++ b/arch/arm/cpu/armv8/smccc-call.S @@ -1,7 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015, Linaro Limited - */ + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi +*/ #include #include #include @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc) ENTRY(__arm_smccc_hvc) SMCCC hvc ENDPROC(__arm_smccc_hvc) + +#ifdef CONFIG_ARM64 + + .macro SMCCC_1_2 instr + /* Save `res` and free a GPR that won't be clobbered */ + stp x1, x19, [sp, #-16]! + + /* Ensure `args` won't be clobbered while loading regs in next step */ + mov x19, x0 + + /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */ + ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + \instr #0 + + /* Load the `res` from the stack */ + ldr x19, [sp] + + /* Store the registers x0 - x17 into the result structure */ + stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + /* Restore original x19 */ + ldp xzr, x19, [sp], #16 + ret + .endm + +/* + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, + * struct arm_smccc_1_2_regs *res); + */ +ENTRY(arm_smccc_1_2_smc) + SMCCC_1_2 smc +ENDPROC(arm_smccc_1_2_smc) + +#endif diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c index 6de0ce9152..181a8ac4c2 100644 --- a/arch/arm/lib/asm-offsets.c +++ b/arch/arm/lib/asm-offsets.c @@ -9,6 +9,11 @@ * generate asm statements containing #defines, * compile this file to assembler, and then extract the * #defines from the assembly-language output. + * + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi */ #include @@ -90,6 +95,17 @@ int main(void) DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2)); DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id)); DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, state)); +#ifdef CONFIG_ARM64 + DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS, offsetof(struct arm_smccc_1_2_regs, a0)); + DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS, offsetof(struct arm_smccc_1_2_regs, a2)); + DEFINE(ARM_SMCCC_1_2_REGS_X4_OFFS, offsetof(struct arm_smccc_1_2_regs, a4)); + DEFINE(ARM_SMCCC_1_2_REGS_X6_OFFS, offsetof(struct arm_smccc_1_2_regs, a6)); + DEFINE(ARM_SMCCC_1_2_REGS_X8_OFFS, offsetof(struct arm_smccc_1_2_regs, a8)); + DEFINE(ARM_SMCCC_1_2_REGS_X10_OFFS, offsetof(struct arm_smccc_1_2_regs, a10)); + DEFINE(ARM_SMCCC_1_2_REGS_X12_OFFS, offsetof(struct arm_smccc_1_2_regs, a12)); + DEFINE(ARM_SM
[PATCH v14 02/11] lib: uuid: introduce uuid_str_to_le_bin function
convert UUID string to little endian binary data
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v9:
* add a full function prototype description in uuid.h
v8:
* use simple_strtoull() in uuid_str_to_le_bin() to support 32-bit platforms
v7:
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* make uuid_str_to_le_bin() implementation similar to uuid_str_to_bin()
by using same APIs
v4:
* rename ffa_uuid_str_to_bin to be_uuid_str_to_le_bin and put in
a standalone commit (the current)
v3:
* introduce ffa_uuid_str_to_bin (provided by
arm_ffa: introduce Arm FF-A low-level driver)
include/uuid.h | 15 +++
lib/uuid.c | 48
2 files changed, 63 insertions(+)
diff --git a/include/uuid.h b/include/uuid.h
index 4a4883d3b5..89b93e642b 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -2,6 +2,10 @@
/*
* Copyright (C) 2014 Samsung Electronics
* Przemyslaw Marczak
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#ifndef __UUID_H__
#define __UUID_H__
@@ -44,4 +48,15 @@ int uuid_guid_get_bin(const char *guid_str, unsigned char
*guid_bin);
const char *uuid_guid_get_str(const unsigned char *guid_bin);
void gen_rand_uuid(unsigned char *uuid_bin);
void gen_rand_uuid_str(char *uuid_str, int str_format);
+
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ * Return:
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin);
+
#endif
diff --git a/lib/uuid.c b/lib/uuid.c
index 96e1af3c8b..45f325d964 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -1,6 +1,10 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2011 Calxeda, Inc.
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#include
@@ -354,6 +358,50 @@ int uuid_str_to_bin(const char *uuid_str, unsigned char
*uuid_bin,
return 0;
}
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ *
+ * UUID string is 36 characters (36 bytes):
+ *
+ * ----
+ *
+ * where x is a hexadecimal character. Fields are separated by '-'s.
+ * When converting to a little endian binary UUID, the string fields are
reversed.
+ *
+ * Return:
+ *
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin)
+{
+ u16 tmp16;
+ u32 tmp32;
+ u64 tmp64;
+
+ if (!uuid_str_valid(uuid_str) || !uuid_bin)
+ return -EINVAL;
+
+ tmp32 = cpu_to_le32(hextoul(uuid_str, NULL));
+ memcpy(uuid_bin, &tmp32, 4);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 9, NULL));
+ memcpy(uuid_bin + 4, &tmp16, 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 14, NULL));
+ memcpy(uuid_bin + 6, &tmp16, 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 19, NULL));
+ memcpy(uuid_bin + 8, &tmp16, 2);
+
+ tmp64 = cpu_to_le64(simple_strtoull(uuid_str + 24, NULL, 16));
+ memcpy(uuid_bin + 10, &tmp64, 6);
+
+ return 0;
+}
+
/*
* uuid_bin_to_str() - convert big endian binary data to string UUID or GUID.
*
--
2.25.1
[PATCH v14 03/11] lib: uuid: introduce testcase for uuid_str_to_le_bin
provide a test case
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
---
Changelog:
===
v11:
* use ut_asserteq_mem()
MAINTAINERS | 5 +
test/lib/Makefile | 1 +
test/lib/uuid.c | 41 +
3 files changed, 47 insertions(+)
create mode 100644 test/lib/uuid.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d724b64673..a1e34ab63a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1634,3 +1634,8 @@ S:Maintained
F: arch/arm/dts/ls1021a-twr-u-boot.dtsi
F: drivers/crypto/fsl/
F: include/fsl_sec.h
+
+UUID testing
+M: Abdellatif El Khlifi
+S: Maintained
+F: test/lib/uuid.c
diff --git a/test/lib/Makefile b/test/lib/Makefile
index e0bd9e04e8..e75a263e6a 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AES) += test_aes.o
obj-$(CONFIG_GETOPT) += getopt.o
obj-$(CONFIG_CRC8) += test_crc8.o
obj-$(CONFIG_UT_LIB_CRYPT) += test_crypt.o
+obj-$(CONFIG_LIB_UUID) += uuid.o
else
obj-$(CONFIG_SANDBOX) += kconfig_spl.o
endif
diff --git a/test/lib/uuid.c b/test/lib/uuid.c
new file mode 100644
index 00..e24331a136
--- /dev/null
+++ b/test/lib/uuid.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* test UUID */
+#define TEST_SVC_UUID "ed32d533-4209-99e6-2d72-cdd998a79cc0"
+
+#define UUID_SIZE 16
+
+/* The UUID binary data (little-endian format) */
+static const u8 ref_uuid_bin[UUID_SIZE] = {
+ 0x33, 0xd5, 0x32, 0xed,
+ 0x09, 0x42, 0xe6, 0x99,
+ 0x72, 0x2d, 0xc0, 0x9c,
+ 0xa7, 0x98, 0xd9, 0xcd
+};
+
+static int lib_test_uuid_to_le(struct unit_test_state *uts)
+{
+ const char *uuid_str = TEST_SVC_UUID;
+ u8 ret_uuid_bin[UUID_SIZE] = {0};
+
+ ut_assertok(uuid_str_to_le_bin(uuid_str, ret_uuid_bin));
+ ut_asserteq_mem(ref_uuid_bin, ret_uuid_bin, UUID_SIZE);
+
+ return 0;
+}
+
+LIB_TEST(lib_test_uuid_to_le, 0);
--
2.25.1
[PATCH v14 05/11] log: select physical address formatting in a generic way
sets the log formatting according to the platform (64-bit vs 32-bit) Signed-off-by: Abdellatif El Khlifi Cc: Simon Glass --- include/log.h | 8 1 file changed, 8 insertions(+) diff --git a/include/log.h b/include/log.h index 3bab40b617..689cef905b 100644 --- a/include/log.h +++ b/include/log.h @@ -686,4 +686,12 @@ static inline int log_get_default_format(void) (IS_ENABLED(CONFIG_LOGF_FUNC) ? BIT(LOGF_FUNC) : 0); } +/* Select the right physical address formatting according to the platform */ +#ifdef CONFIG_PHYS_64BIT +#define PhysAddrLength "ll" +#else +#define PhysAddrLength "" +#endif +#define PHYS_ADDR_LN "%" PhysAddrLength "x" +#define PHYS_ADDR_LNU "%" PhysAddrLength "u" #endif -- 2.25.1
[PATCH v14 04/11] arm_ffa: introduce Arm FF-A support
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v13:
* doc minor change: specify in the readme that the user
should call ffa_rxtx_unmap() driver operation to unmap
the RX/TX buffers on demand.
v12:
* remove dscvry_info
* replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn
(user drivers can override it)
* improve FFA_PARTITION_INFO_GET implementation
(clients no longer need to calloc a buffer)
* address nits
v11:
* move ffa_try_discovery() from the uclass to the Arm FF-A driver
* rename ffa_try_discovery() to arm_ffa_discover()
* pass dev as an argument of arm_ffa_discover()
* add arm_ prefix to the Arm FF-A driver functions
* add emul field in struct ffa_discovery_info
* address nits
v10:
* provide the driver operations through the Uclass
* move the generic FF-A methods to the Uclass
* keep Arm specific methods in the Arm driver (arm-ffa.c)
* rename core.c to arm-ffa.c
* address nits
v9:
* integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for
binding
v8:
* make ffa_get_partitions_info() second argument to be an SP count in both
modes
* update ffa_bus_prvdata_get() to return a pointer rather than a pointer
address
* remove packing from ffa_partition_info and ffa_send_direct_data structures
* pass the FF-A bus device to the bus operations
v7:
* add support for 32-bit direct messaging
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* improve the declaration of error handling mapping
* stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
v6:
* drop use of EFI runtime support (We decided with Linaro to add this later)
* drop discovery from initcalls (discovery will be on demand by FF-A users)
* set the alignment of the RX/TX buffers to the larger translation granule size
* move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
* update the documentation and move it to doc/arch/arm64.ffa.rst
v4:
* add doc/README.ffa.drv
* moving the FF-A driver work to drivers/firmware/arm-ffa
* use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
#if defined by #if CONFIG_IS_ENABLED
* improving error handling by mapping the FF-A errors to standard errors
and logs
* replacing panics with an error log and returning an error code
* improving features discovery in FFA_FEATURES by introducing
rxtx_min_pages private data field
* add ffa_remove and ffa_unbind functions
* improve how the driver behaves when bus discovery is done more than
once
v3:
* align the interfaces of the U-Boot FF-A driver with those in the linux
FF-A driver
* remove the FF-A helper layer
* make the U-Boot FF-A driver independent from EFI
* provide an optional config that enables copying the driver data to EFI
runtime section at ExitBootServices service
* use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
v2:
* make FF-A bus discoverable using device_{bind, probe} APIs
* remove device tree support
v1:
* introduce FF-A bus driver with device tree support
MAINTAINERS |8 +
doc/arch/arm64.ffa.rst
[PATCH v14 07/11] arm_ffa: introduce sandbox FF-A support
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi
Cc: Tom Rini
Cc: Simon Glass
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove reparenting by making the emulator parent of the FF-A device in the DT
* add invoke_ffa_fn()
* address nits
v11:
* rename ffa_try_discovery() to sandbox_ffa_discover()
* rename sandbox_ffa_query_core_state() to sandbox_query_ffa_emul_state()
* store the sandbox emulator pointer in the FF-A device uc_priv (struct
ffa_priv)
* set the emulator as parent of the sandbox FF-A device
v10:
* split the FF-A sandbox support into an emulator and a driver
* read FFA_VERSION and FFA_PARTITION_INFO_GET state using
sandbox_ffa_query_core_state()
* drop CONFIG_SANDBOX_FFA config
* address nits
v9: align FF-A sandbox driver with FF-A discovery through DM
v8: update ffa_bus_prvdata_get() to return a pointer rather than
a pointer address
v7: state that sandbox driver supports only 64-bit direct messaging
v4: align sandbox driver with the new FF-A driver interfaces
and new way of error handling
v1: introduce the sandbox driver
MAINTAINERS | 3 +-
arch/sandbox/dts/sandbox.dtsi | 9 +
arch/sandbox/dts/test.dts | 8 +
arch/sandbox/include/asm/sandbox_arm_ffa.h| 72 ++
.../include/asm/sandbox_arm_ffa_priv.h| 121 +++
configs/sandbox64_defconfig | 1 +
configs/sandbox_defconfig | 1 +
doc/arch/arm64.ffa.rst| 19 +-
doc/arch/sandbox/sandbox.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 13 +-
drivers/firmware/arm-ffa/Makefile | 10 +-
drivers/firmware/arm-ffa/ffa-emul-uclass.c| 720 ++
.../firmware/arm-ffa/sandbox_arm_ffa_priv.h | 14 -
drivers/firmware/arm-ffa/sandbox_ffa.c| 110 +++
include/dm/uclass-id.h| 1 +
15 files changed, 1081 insertions(+), 22 deletions(-)
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa.h
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/ffa-emul-uclass.c
delete mode 100644 drivers/firmware/arm-ffa/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/sandbox_ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ff6a222960..f8948b7635 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,12 +269,13 @@ F:configs/cortina_presidio-asic-pnand_defconfig
ARM FF-A
M: Abdellatif El Khlifi
S: Maintained
+F: arch/sandbox/include/asm/sandbox_arm_ffa.h
+F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
F: cmd/armffa.c
F: doc/arch/arm64.ffa.rst
F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
-F: include/sandbox_arm_ffa.h
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 30a305c4d2..94a08814b8 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -445,6 +445,15 @@
thermal {
compatible = "sandbox,thermal";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
+
};
&cros_ec {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6..96b5404991 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1820,6 +1820,14 @@
extcon {
compatible = "sandbox,extcon";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/arch/sandbox/include/asm/sandbox_arm_ffa.h
b/arch/sandbox/include/asm/sandbox_arm_ffa.h
new file mode 100644
index 00..be2790f496
--- /dev/null
+++ b/arch/sandbox/include/asm/sandbox_arm_ffa.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#ifndef __SANDBOX_ARM_FFA_H
+#define __SANDBOX_ARM_FFA_H
+
+#include
+
+/*
+ * This header provides public sandbox FF-A emulator declarations
+ * and declarations needed by FF-A sandbox clients
+ */
+
+/* UUIDs strings of the emulated services */
+#define SANDBOX_SERVICE1_UUID "ed32d533-4209-99e6-2
[PATCH v14 06/11] arm_ffa: introduce armffa command
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v14:
Ilias:
* address nits
* in do_ffa_ping() reject the SP ID if it's 0
* use PHYS_ADDR_LN in formatting the physical addresses
v12:
* add subcommands argument checks
* usage documentation: update command return codes
* remove calloc when querying SPs
* address nits
v11:
* use U_BOOT_CMD_WITH_SUBCMDS
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* address nits
v9:
* remove manual FF-A discovery and use DM
* use DM class APIs to probe and interact with the FF-A bus
* add doc/usage/cmd/armffa.rst
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7:
* adapt do_ffa_dev_list() following the recent update on
uclass_first_device/uclass_next_device functions (they return void now)
* set armffa command to use 64-bit direct messaging
v4:
* remove pattern data in do_ffa_msg_send_direct_req
v3:
* use the new driver interfaces (partition_info_get, sync_send_receive)
in armffa command
v2:
* replace use of ffa_helper_init_device function by
ffa_helper_bus_discover
v1:
* introduce armffa command
MAINTAINERS | 2 +
cmd/Kconfig | 10 ++
cmd/Makefile | 1 +
cmd/armffa.c | 194 +++
doc/arch/arm64.ffa.rst | 7 ++
doc/usage/cmd/armffa.rst | 93 +++
doc/usage/index.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 1 +
8 files changed, 309 insertions(+)
create mode 100644 cmd/armffa.c
create mode 100644 doc/usage/cmd/armffa.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index b3a16ed802..ff6a222960 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,7 +269,9 @@ F: configs/cortina_presidio-asic-pnand_defconfig
ARM FF-A
M: Abdellatif El Khlifi
S: Maintained
+F: cmd/armffa.c
F: doc/arch/arm64.ffa.rst
+F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
F: include/sandbox_arm_ffa.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 02e54f1e50..79b4f8367a 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -935,6 +935,16 @@ endmenu
menu "Device access commands"
+config CMD_ARMFFA
+ bool "Arm FF-A test command"
+ depends on ARM_FFA_TRANSPORT
+ help
+ Provides a test command for the FF-A support
+ supported options:
+ - Listing the partition(s) info
+ - Sending a data pattern to the specified partition
+ - Displaying the arm_ffa device info
+
config CMD_ARMFLASH
#depends on FLASH_CFI_DRIVER
bool "armflash"
diff --git a/cmd/Makefile b/cmd/Makefile
index 6c37521b4e..7d20a85a46 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,7 @@ obj-y += panic.o
obj-y += version.o
# command
+obj-$(CONFIG_CMD_ARMFFA) += armffa.o
obj-$(CONFIG_CMD_2048) += 2048.o
obj-$(CONFIG_CMD_ACPI) += acpi.o
obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
diff --git a/cmd/armffa.c b/cmd/armffa.c
new file mode 100644
index 00..ab0fd54d97
--- /dev/null
+++ b/cmd/armffa.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * ffa_get_dev() - Return the FF-A device
+ * @devp: pointer to the FF-A device
+ *
+ * Search for the FF-A device.
+ *
+ * Return:
+ * 0 on success. Otherwise, failure
+ */
+static int ffa_get_dev(struct udevice **devp)
+{
+ int ret;
+
+ ret = uclass_first_device_err(UCLASS_FFA, devp);
+ if (ret) {
+ log_err("Cannot find FF-A bus device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * do_ffa_getpart() - implementation of the getpart subcommand
+ * @cmdtp: Command Table
+ * @flag: flags
+ * @argc: number of arguments
+ * @argv: arguments
+ *
+ * Query a secure partition information. The secure partition UUID is provided
+ * as an argument. The function uses the arm_ffa driver
+ * partition_info_get operation which implements FFA_PARTITION_INFO_GET
+ * ABI to retrieve the data. The input UUID string is expec
[PATCH v14 09/11] arm_ffa: introduce armffa command Sandbox test
Add Sandbox test for the armffa command
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v12:
* address nits
v10:
* replace CMD_RET_SUCCESS with 0
* replace CONFIG_SANDBOX_FFA with CONFIG_ARM_FFA_TRANSPORT
v9: align the test with FF-A discovery through DM
v4: drop use of helper APIs
v1: introduce armffa command sandbox test
MAINTAINERS | 1 +
test/cmd/Makefile | 2 ++
test/cmd/armffa.c | 33 +
3 files changed, 36 insertions(+)
create mode 100644 test/cmd/armffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a8b3a5419..30d1b87149 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -276,6 +276,7 @@ F: doc/arch/arm64.ffa.rst
F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/cmd/armffa.c
F: test/dm/ffa.c
ARM FREESCALE IMX
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index a3cf983739..6e3d7e919e 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2013 Google, Inc
+# Copyright 2022-2023 Arm Limited and/or its affiliates
ifdef CONFIG_HUSH_PARSER
obj-$(CONFIG_CONSOLE_RECORD) += test_echo.o
@@ -24,6 +25,7 @@ obj-$(CONFIG_CMD_SEAMA) += seama.o
ifdef CONFIG_SANDBOX
obj-$(CONFIG_CMD_READ) += rw.o
obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += armffa.o
endif
obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
obj-$(CONFIG_CMD_WGET) += wget.o
diff --git a/test/cmd/armffa.c b/test/cmd/armffa.c
new file mode 100644
index 00..9a44a397e8
--- /dev/null
+++ b/test/cmd/armffa.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for armffa command
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Basic test of 'armffa' command */
+static int dm_test_armffa_cmd(struct unit_test_state *uts)
+{
+ /* armffa getpart */
+ ut_assertok(run_command("armffa getpart " SANDBOX_SERVICE1_UUID, 0));
+
+ /* armffa ping */
+ ut_assertok(run_commandf("armffa ping 0x%x", SANDBOX_SP1_ID));
+
+ /* armffa devlist */
+ ut_assertok(run_command("armffa devlist", 0));
+
+ return 0;
+}
+
+DM_TEST(dm_test_armffa_cmd, UT_TESTF_SCAN_FDT | UT_TESTF_CONSOLE_REC);
--
2.25.1
[PATCH v14 08/11] arm_ffa: introduce sandbox test cases for UCLASS_FFA
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove use of dscvry_info
* drop use of calloc when querying SPs
* address nits
v11:
* drop unmapping test (taken care of by the DM when removing the device)
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* replace CONFIG_SANDBOX_FFA with CONFIG_ARM_FFA_TRANSPORT
* address nits
v9: align FF-A sandbox tests with FF-A discovery through DM
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7: set the tests to use 64-bit direct messaging
v4: align sandbox tests with the new FF-A driver interfaces
and new way of error handling
v1: introduce sandbox tests
MAINTAINERS| 1 +
doc/arch/arm64.ffa.rst | 1 +
test/dm/Makefile | 3 +-
test/dm/ffa.c | 261 +
4 files changed, 265 insertions(+), 1 deletion(-)
create mode 100644 test/dm/ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f8948b7635..4a8b3a5419 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -276,6 +276,7 @@ F: doc/arch/arm64.ffa.rst
F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/dm/ffa.c
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
index b7c754fa3d..325fb80346 100644
--- a/doc/arch/arm64.ffa.rst
+++ b/doc/arch/arm64.ffa.rst
@@ -37,6 +37,7 @@ The U-Boot FF-A support provides the following parts:
FF-A ABIs inspection methods.
- An FF-A sandbox device driver for FF-A communication with the emulated
Secure World.
The driver leverages the FF-A Uclass to establish FF-A communication.
+- Sandbox FF-A test cases.
FF-A and SMC specifications
---
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 3799b1ae8f..7ed00733c1 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2013 Google, Inc
-# Copyright 2023 Arm Limited and/or its affiliates
+# Copyright 2022-2023 Arm Limited and/or its affiliates
obj-$(CONFIG_UT_DM) += test-dm.o
@@ -92,6 +92,7 @@ obj-$(CONFIG_POWER_DOMAIN) += power-domain.o
obj-$(CONFIG_ACPI_PMC) += pmc.o
obj-$(CONFIG_DM_PMIC) += pmic.o
obj-$(CONFIG_DM_PWM) += pwm.o
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += ffa.o
obj-$(CONFIG_QFW) += qfw.o
obj-$(CONFIG_RAM) += ram.o
obj-y += regmap.o
diff --git a/test/dm/ffa.c b/test/dm/ffa.c
new file mode 100644
index 00..6912666bb4
--- /dev/null
+++ b/test/dm/ffa.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Functional tests for the UCLASS_FFA */
+
+static int check_fwk_version(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ struct ffa_sandbox_data func_data;
+ u32 fwk_version = 0;
+
+ func_data.data0 = &fwk_version;
+ func_data.data0_size = sizeof(fwk_version);
+ ut_assertok(sandbox_query_ffa_emul_state(FFA_VERSION, &func_data));
+ ut_asserteq(uc_priv->fwk_version, fwk_version);
+
+ return 0;
+}
+
+static int check_endpoint_id(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, uc_priv->id);
+
+ return 0;
+}
+
+static int check_rxtxbuf(struct ffa_priv *uc_priv, struct unit_test_state *uts)
+{
+ ut_assertnonnull(uc_priv->pair.rxbuf);
+ ut_assertnonnull(uc_priv->pair.txbuf);
+
+ return 0;
+}
+
+static int check_features(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_assert(uc_priv->pair.rxtx_min_pages == RXTX_4K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_16K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_64K);
+
+ return 0;
+}
+
+static int check_rxbuf_mapped_flag(u32 queried_func_id,
+ u8 rxbuf_mapped,
+ struct unit_test_state *uts)
+{
+ switch (queried_func_id) {
+ case FFA_RXTX_MAP:
+ ut_asserteq(1, rxbuf_mapped);
+ break;
+ case FFA_RXTX_UNMAP:
+ ut_asserteq(0, rxbuf_mapped);
+ break;
+ default:
+ ut_assert(false);
+ }
+
+ return 0;
+}
+
+static int check_rxbuf_release_flag(u8 rxbuf_owned, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, rxbuf_owned);
+
+ return 0;
+}
+
+static int test_f
[PATCH v14 10/11] arm_ffa: efi: introduce FF-A MM communication
Add MM communication support using FF-A transport
This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.
An MM shared buffer and a door bell event are used to exchange
the data.
The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.
The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).
On such event, MM SP can read the data and updates the MM shared
buffer with the response data.
The response data is copied back to the communication buffer and
consumed by the EFI subsystem.
MM communication protocol supports FF-A 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi
Tested-by: Gowtham Suresh Kumar
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v14:
Ilias:
* drop truncating var_payload->size when using FF-A
* map the MM SP return codes to errnos
v13:
* remove FF-A and Optee ifdefs
v12:
* drop use of calloc when querying SPs
* address nits
v11:
* rename select_ffa_mm_comms() to select_mm_comms()
* improve the logic of MM transport selection in mm_communicate()
* addressing nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* addressing nits
v9: align how FF-A is used with FF-A discovery through DM
v8:
* isolate the compilation choices between FF-A and OP-TEE
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7:
* set the MM door bell event to use 64-bit direct messaging
* issue a compile time error when one of these macros are not found :
FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET,
FFA_SHARED_MM_BUFFER_ADDR
* make mm_sp_svc_uuid static
* replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails
* improve use of unmap_sysmem() in ffa_mm_communicate()
v6:
* add FF-A runtime discovery at MM communication level
* drop EFI runtime support for FF-A MM communication
* revert the changes in include/mm_communication.h for
efi_mm_communicate_header and smm_variable_access structures
v4:
* use the new FF-A driver interfaces
* discover MM partitions at runtime
* copy FF-A driver private data to EFI runtime section at
ExitBootServices()
* drop use of FFA_ERR_STAT_SUCCESS error code
* replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES
in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore
* revert the error log in mm_communicate() in case of failure
* remove packed attribute from efi_mm_communicate_header and
smm_variable_communicate_header
v2:
* set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE,
FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings
v1:
* introduce FF-A MM communication
include/mm_communication.h| 13 ++
lib/efi_loader/Kconfig| 16 +-
lib/efi_loader/efi_variable_tee.c | 272 +-
3 files changed, 294 insertions(+), 7 deletions(-)
diff --git a/include/mm_communication.h b/include/mm_communication.h
index e65fbde60d..f17847583b 100644
--- a/include/mm_communication.h
+++ b/include/mm_communication.h
@@ -6,6 +6,9 @@
* Copyright (c) 2017, Intel Corporation. All rights reserved.
* Copyright (C) 2020 Linaro Ltd.
* Copyright (C) 2020 Linaro Ltd.
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *Authors:
+ * Abdellatif El Khlifi
*/
#ifndef _MM_COMMUNICATION_H_
@@ -13,6 +16,9 @@
#include
+/* MM service UUID string (big-endian format). This UUID is common across all
MM SPs */
+#define MM_SP_UUID "33d532ed-e699-0942-c09c-a798d9cd722d"
+
/*
* Interface to the pseudo Trusted Application (TA), which provides a
* communication channel with the Standalone MM (Management Mode)
@@ -248,4 +254,11 @@ struct smm_variable_var_check_property {
u16 name[];
};
+/* supported MM transports */
+enum mm_comms_select {
+ MM_COMMS_UNDEFINED,
+ MM_COMMS_FFA,
+ MM_COMMS_OPTEE
+};
+
#endif /* _MM_COMMUNICATION_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c5835e6ef6..cb26e110fd 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -55,13 +55,25 @@ config EFI_VARIABLE_FILE_STORE
stored as file /ubootefi.var on the EFI system partition.
config EFI_MM_COMM_TEE
- bool "UEFI variables storage service via OP-TEE"
- depends on OPTEE
+ bool "UEFI variables storage service via the trusted world"
+ select ARM_FFA_TRANSPORT
+ select TEE
+ select OPTEE
help
+ Allowing access to the MM SP services (SPs such as StandAlonneMM,
smm-gateway).
+ When using the u-boot OP-TEE driver, StandAlonneMM is supported.
+ When using th
[PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
turn on EFI MM communication On corstone1000 platform MM communication between u-boot and the secure world (Optee) is done using the FF-A bus. Signed-off-by: Abdellatif El Khlifi Cc: Tom Rini Cc: Simon Glass Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === v13: * remove FF-A config in the defconfig (because it's enabled automatically by CONFIG_EFI_MM_COMM_TEE) v9: * update copyright string v8: * drop OP-TEE configs from Corstone-1000 defconfig v7: * improve the definition of FFA_SHARED_MM_BUFFER_ADDR and FFA_SHARED_MM_BUFFER_OFFSET * update FFA_SHARED_MM_BUFFER_ADDR value v6: * corstone-1000: enable optee driver * corstone-1000: remove CONFIG_ARM_FFA_EFI_RUNTIME_MODE from the defconfig v4: * corstone-1000: turn on EFI MM communication configs/corstone1000_defconfig | 1 + include/configs/corstone1000.h | 15 +-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig index a8a79fd105..b57e2322c4 100644 --- a/configs/corstone1000_defconfig +++ b/configs/corstone1000_defconfig @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_IGNORE_OSINDICATIONS=y CONFIG_FWU_MULTI_BANK_UPDATE=y CONFIG_ERRNO_STR=y +CONFIG_EFI_MM_COMM_TEE=y diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h index 3347c11792..4ef1f05e40 100644 --- a/include/configs/corstone1000.h +++ b/include/configs/corstone1000.h @@ -1,9 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * (C) Copyright 2022 ARM Limited * (C) Copyright 2022 Linaro * Rui Miguel Silva - * Abdellatif El Khlifi + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi * * Configuration for Corstone1000. Parts were derived from other ARM * configurations. @@ -14,6 +16,15 @@ #include +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ + +/* + * shared buffer physical address used for communication between + * u-boot and the MM SP + */ +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL +#define FFA_SHARED_MM_BUFFER_OFFSET0 + #define V2M_BASE 0x8000 #define CFG_PL011_CLOCK5000 -- 2.25.1
Re: [PATCH] binman: Support templating with multiple images
Hi Jan,
On Fri, 7 Jul 2023 at 15:04, Jan Kiszka wrote:
>
> On 07.07.23 14:40, Simon Glass wrote:
> > Allow a template to appear in the top level description when using
> > multiple images.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/binman/control.py | 5 ++--
> > tools/binman/ftest.py| 12 ++
> > tools/binman/test/287_template_multi.dts | 29
> > 3 files changed, 44 insertions(+), 2 deletions(-)
> > create mode 100644 tools/binman/test/287_template_multi.dts
> >
> > diff --git a/tools/binman/control.py b/tools/binman/control.py
> > index 0f98e9904fb1..b334fbc8ac8f 100644
> > --- a/tools/binman/control.py
> > +++ b/tools/binman/control.py
> > @@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
> > images = OrderedDict()
> > if 'multiple-images' in binman_node.props:
> > for node in binman_node.subnodes:
> > -images[node.name] = Image(node.name, node,
> > - use_expanded=use_expanded)
> > +if 'template' not in node.name:
> > +images[node.name] = Image(node.name, node,
> > + use_expanded=use_expanded)
> > else:
> > images['image'] = Image('image', binman_node,
> > use_expanded=use_expanded)
> > return images
> > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> > index 389d3906371a..c783424c91da 100644
> > --- a/tools/binman/ftest.py
> > +++ b/tools/binman/ftest.py
> > @@ -6771,6 +6771,18 @@ fdt fdtmapExtract the
> > devicetree blob from the fdtmap
> > second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
> > self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
> >
> > +def testEntryTemplateBlobMulti(self):
> > +"""Test using a template with 'multiple-images' enabled"""
> > +TestFunctional._MakeInputFile('my-blob.bin', b'blob')
> > +TestFunctional._MakeInputFile('my-blob2.bin', b'other')
> > +retcode = self._DoTestFile('287_template_multi.dts')
> > +
> > +self.assertEqual(0, retcode)
> > +image = control.images['image']
> > +image_fname = tools.get_output_filename('my-image.bin')
> > +data = tools.read_file(image_fname)
> > +self.assertEqual(b'blobother', data)
> > +
> >
> > if __name__ == "__main__":
> > unittest.main()
> > diff --git a/tools/binman/test/287_template_multi.dts
> > b/tools/binman/test/287_template_multi.dts
> > new file mode 100644
> > index ..15bd8701c671
> > --- /dev/null
> > +++ b/tools/binman/test/287_template_multi.dts
> > @@ -0,0 +1,29 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/dts-v1/;
> > +
> > +/dts-v1/;
>
> Duplicate.
>
> > +/ {
> > + binman: binman {
> > + multiple-images;
> > +
> > + my_template: template {
> > + blob-ext@0 {
> > + filename = "my-blob.bin";
> > + offset = <0>;
> > + };
> > + blob-ext@8 {
> > + offset = <8>;
> > + };
> > + };
> > +
> > + image {
> > + pad-byte = <0x40>;
> > + filename = "my-image.bin";
> > + insert-template = <&my_template>;
> > + blob-ext@8 {
> > + filename = "my-blob2.bin";
> > + };
> > + };
> > + };
> > +};
>
> For the sake of context:
>
> echo 1234 > my-blob.bin
> echo 5678 > my-blob2.bin
> dtc tools/binman/test/287_template_multi.dts -o binman-test.dtb
> tools/binman/binman build -d binman-test.dtb -O .
>
> binman: Node '/binman/image/blob-ext@0': Offset 0x0 (0) overlaps with
> previous entry '/binman/image/blob-ext@8' ending at 0xd (13)
Hi Jan,
I don't get that error when I try these exact commands:
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> echo 1234 > my-blob.bin
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> echo 5678 > my-blob2.bin
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> dtc
tools/binman/test/287_template_multi.dts -o binman-test.dtb
tools/binman/test/287_template_multi.dts:11.15-14.6: Warning
(unit_address_vs_reg): /binman/template/blob-ext@0: node has a unit
name, but no reg or ranges property
tools/binman/test/287_template_multi.dts:15.15-17.6: Warning
(unit_address_vs_reg): /binman/template/blob-ext@8: node has a unit
name, but no reg or ranges property
tools/binman/test/287_template_multi.dts:24.15-26.6: Warning
(unit_address_vs_reg): /binman/image/blob-ext@8: node has a unit name,
but no reg or ranges property
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> tools/binman/binman
build -d binman-test.dtb -O .
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> hd my-image.bin
31 32 33 34 0a 40 40 40 35 36 37 38 0a |123
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
>
> On 07.07.23 14:42, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
> >>
> >> On 05.07.23 00:14, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
>
> Hi Simon,
>
> On 28.06.23 13:41, Simon Glass wrote:
> > Collections can used to collect the contents of other entries into a
> > single entry, but they result in a single entry, with the original
> > entries
> > 'left behind' in their old place.
> >
> > It is useful to be able to specific a set of entries ones and have it
> > used
> > in multiple images, or parts of an image.
> >
> > Implement this mechanism.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/binman/binman.rst | 80
> > tools/binman/control.py | 9 +++
> > tools/binman/etype/section.py| 3 +-
> > tools/binman/ftest.py| 8 +++
> > tools/binman/test/286_entry_template.dts | 42 +
> > 5 files changed, 141 insertions(+), 1 deletion(-)
> > create mode 100644 tools/binman/test/286_entry_template.dts
> >
> > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > index a4b31fe5397b..9be979ae1c5b 100644
> > --- a/tools/binman/binman.rst
> > +++ b/tools/binman/binman.rst
> > @@ -727,6 +727,13 @@ optional:
> > Note that missing, optional blobs do not produce a non-zero exit
> > code from
> > binman, although it does show a warning about the missing external
> > blob.
> >
> > +insert-template:
> > +This is not strictly speaking an entry property, since it is
> > processed early
> > +in Binman before the entries are read. It is a list of phandles of
> > nodes to
> > +include in the current (target) node. For each node, its subnodes
> > and their
> > +properties are brought into the target node. See Templates_ below
> > for
> > +more information.
> > +
> > The attributes supported for images and sections are described below.
> > Several
> > are similar to those for entries.
> >
> > @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> > going on, you can use
> > arch/arm/dts/u-boot.dtsi ... found:
> > "arch/arm/dts/juno-r2-u-boot.dtsi"
> >
> >
> > +Templates
> > +=
> > +
> > +Sometimes multiple images need to be created which have all have a
> > common
> > +part. For example, a board may generate SPI and eMMC images which both
> > include
> > +a FIT. Since the FIT includes many entries, it is tedious to repeat
> > them twice
> > +in the image description.
> > +
> > +Templates provide a simple way to handle this::
> > +
> > +binman {
> > +multiple-images;
> > +common_part: template-1 {
> > +fit {
> > +... lots of entries in here
> > +};
> > +
> > +text {
> > +text = "base image";
> > +};
> > +};
> > +
> > +spi-image {
> > +filename = "image-spi.bin";
> > +insert-template = <&fit>;
> > +
> > +/* things specific to SPI follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "SPI image";
> > +};
> > +};
> > +
> > +mmc-image {
> > +filename = "image-mmc.bin";
> > +insert-template = <&fit>;
> > +
> > +/* things specific to MMC follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "MMC image";
> > +};
> > +};
> > +};
> > +
> > +The template node name must start with 'template', so it is not
> > considered to be
> > +an image itself.
> > +
> > +The mechanism is very simple. For each phandle in the
> > 'insert-templates'
> > +property, the source node is looked up. Then the subnodes of that
> > source node
> > +are copied into the target node, i.e. the one containing the
> > `insert-template`
> > +property.
> > +
> > +If the target node has a node with the same name as a template, its
> > properties
> > +override corresponding properties in the template. This allows the
> > template to
> > +be uses as a base, with the node providing updates to the properties
> > as needed.
> > +The overriding happens recursively.
> > +
> > +At present there is an unpleasant limitation on this feature: it works
> >
Re: [PATCH] x86: Update docs link in bootparam header
On Fri, Jul 07, 2023 at 07:51:42AM +0100, Paul Barker wrote:
> After Linux commit ff61f0791ce9, x86 documentation was moved to
> arch/x86 and the link in bootparam.h was broken.
>
> Signed-off-by: Paul Barker
> ---
> arch/x86/include/asm/bootparam.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/bootparam.h
> b/arch/x86/include/asm/bootparam.h
> index ea816ca74698..1f8ca569b880 100644
> --- a/arch/x86/include/asm/bootparam.h
> +++ b/arch/x86/include/asm/bootparam.h
> @@ -62,7 +62,7 @@ struct setup_indirect {
> /**
> * struct setup_header - Information needed by Linux to boot
> *
> - * See https://www.kernel.org/doc/html/latest/x86/boot.html
> + * See https://docs.kernel.org/arch/x86/boot.html
This is also now:
https://www.kernel.org/doc/html/latest/arch/x86/boot.html
And tree-wide we have two examples of docs.kernel.org and the rest are
www.kernel.org/doc/html/latest for the base. We should be consistent
here, so I'm deferring to Heinrich.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 17:35, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
>>
>> On 07.07.23 14:42, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
On 05.07.23 00:14, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
>>
>> Hi Simon,
>>
>> On 28.06.23 13:41, Simon Glass wrote:
>>> Collections can used to collect the contents of other entries into a
>>> single entry, but they result in a single entry, with the original
>>> entries
>>> 'left behind' in their old place.
>>>
>>> It is useful to be able to specific a set of entries ones and have it
>>> used
>>> in multiple images, or parts of an image.
>>>
>>> Implement this mechanism.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> tools/binman/binman.rst | 80
>>> tools/binman/control.py | 9 +++
>>> tools/binman/etype/section.py| 3 +-
>>> tools/binman/ftest.py| 8 +++
>>> tools/binman/test/286_entry_template.dts | 42 +
>>> 5 files changed, 141 insertions(+), 1 deletion(-)
>>> create mode 100644 tools/binman/test/286_entry_template.dts
>>>
>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
>>> index a4b31fe5397b..9be979ae1c5b 100644
>>> --- a/tools/binman/binman.rst
>>> +++ b/tools/binman/binman.rst
>>> @@ -727,6 +727,13 @@ optional:
>>> Note that missing, optional blobs do not produce a non-zero exit
>>> code from
>>> binman, although it does show a warning about the missing external
>>> blob.
>>>
>>> +insert-template:
>>> +This is not strictly speaking an entry property, since it is
>>> processed early
>>> +in Binman before the entries are read. It is a list of phandles of
>>> nodes to
>>> +include in the current (target) node. For each node, its subnodes
>>> and their
>>> +properties are brought into the target node. See Templates_ below
>>> for
>>> +more information.
>>> +
>>> The attributes supported for images and sections are described below.
>>> Several
>>> are similar to those for entries.
>>>
>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
>>> going on, you can use
>>> arch/arm/dts/u-boot.dtsi ... found:
>>> "arch/arm/dts/juno-r2-u-boot.dtsi"
>>>
>>>
>>> +Templates
>>> +=
>>> +
>>> +Sometimes multiple images need to be created which have all have a
>>> common
>>> +part. For example, a board may generate SPI and eMMC images which both
>>> include
>>> +a FIT. Since the FIT includes many entries, it is tedious to repeat
>>> them twice
>>> +in the image description.
>>> +
>>> +Templates provide a simple way to handle this::
>>> +
>>> +binman {
>>> +multiple-images;
>>> +common_part: template-1 {
>>> +fit {
>>> +... lots of entries in here
>>> +};
>>> +
>>> +text {
>>> +text = "base image";
>>> +};
>>> +};
>>> +
>>> +spi-image {
>>> +filename = "image-spi.bin";
>>> +insert-template = <&fit>;
>>> +
>>> +/* things specific to SPI follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "SPI image";
>>> +};
>>> +};
>>> +
>>> +mmc-image {
>>> +filename = "image-mmc.bin";
>>> +insert-template = <&fit>;
>>> +
>>> +/* things specific to MMC follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "MMC image";
>>> +};
>>> +};
>>> +};
>>> +
>>> +The template node name must start with 'template', so it is not
>>> considered to be
>>> +an image itself.
>>> +
>>> +The mechanism is very simple. For each phandle in the
>>> 'insert-templates'
>>> +property, the source node is looked up. Then the subnodes of that
>>> source node
>>> +are copied into the target node, i.e. the one containing the
>>> `insert-template`
>>> +property.
>>> +
>>> +If the target node has a node with the same name as a template, its
>>> properties
>>> +override corresponding properties in the template. This allows the
>>> template to
>>> +be uses as a base, with the node providing updates to the properties
>>> as needed.
>>> +The overriding happens recursively.
>>> +
>>> +At present there is an unpleasant
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
> > > > function better understandable, rewrite it via explicit switch-case code
> > > > pattern.
> > > >
> > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > user to
> > > > value which is not suitable for eMMC booting and SPL do not know how to
> > > > interpret it.
> > > >
> > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > explicitly disabled then SPL still loads and boots from this eMMC device
> > > > from User Area partition. This behavior was not changed in this commit
> > > > and
> > > > should be revisited in the future.
> > > >
> > > > Signed-off-by: Pali Rohár
> > > > ---
> > > > Changes in v2:
> > > > * Disable showing warning on sama5d2_xplained due to size restrictions
> > > > ---
> > > > This patch depends on another patch:
> > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > ---
> > > > common/spl/Kconfig | 7 +++
> > > > common/spl/spl_mmc.c | 46
> > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > index 865571d4579c..0574d22b3b25 100644
> > > > --- a/common/spl/Kconfig
> > > > +++ b/common/spl/Kconfig
> > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > help
> > > > Enable write access to MMC and SD Cards in SPL
> > > >
> > > > +config SPL_MMC_WARNINGS
> > > > + bool "Print MMC warnings"
> > > > + depends on SPL_MMC
> > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > + help
> > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > SPL size.
> > > > +
> > > >
> > > > config SPL_MPC8XXX_INIT_DDR
> > > > bool "Support MPC8XXX DDR init"
> > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > index f7a42a11477d..ec424ceded0e 100644
> > > > --- a/common/spl/spl_mmc.c
> > > > +++ b/common/spl/spl_mmc.c
> > > > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct
> > > > mmc *mmc)
> > > > *
> > > > * Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > value.
> > > > -*
> > > > -* FIXME: When booting from this eMMC device is explicitly
> > > > -* disabled then we use User area for booting. This is
> > > > incorrect.
> > > > -* Probably we should skip this eMMC device and select the next
> > > > -* one for booting. Or at least throw warning about this
> > > > fallback.
> > > > */
> > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > - if (part == 7)
> > > > - part = 0;
> > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > + part = 0; /* If partitions are not supported then we
> > > > have only User Area partition */
> > > > + else {
> > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > + puts("spl: WARNING: Booting from this eMMC
> > > > device is disabled in EXT_CSD[179] register\n");
> > > > + puts("spl: WARNING: Continuing anyway and
> > > > selecting User Area partition for booting\n");
> > > > +#else
> > > > + puts("spl: mmc: fallback to user area\n");
> > > > +#endif
> > > > +#endif
> > > > + /* FIXME: This is incorrect and probably we
> > > > should select next eMMC device for booting */
> > > > + part = 0;
> > > > + break;
> > > > + case 1: /* Boot partition 1 is used for booting */
> > > > + part = 1;
> > > > + break;
> > > > + case 2: /* Boot partition 2 is used for booting */
> > > > + part = 2;
> > > > + break;
> > > > + case 7: /* User area is used for booting */
> > > > + part = 0;
> > > > + break;
> > > > + default: /* Other values are reserved */
> > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > + puts("spl: WARNING: EXT_CSD[179] register is
> > > > configured to boot from Reserved value\n");
> > > > +
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > To make eMMC partition choosing in
> > > > > default_spl_mmc_emmc_boot_partition()
> > > > > function better understandable, rewrite it via explicit switch-case
> > > > > code
> > > > > pattern.
> > > > >
> > > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > > user to
> > > > > value which is not suitable for eMMC booting and SPL do not know how
> > > > > to
> > > > > interpret it.
> > > > >
> > > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > device
> > > > > from User Area partition. This behavior was not changed in this
> > > > > commit and
> > > > > should be revisited in the future.
> > > > >
> > > > > Signed-off-by: Pali Rohár
> > > > > ---
> > > > > Changes in v2:
> > > > > * Disable showing warning on sama5d2_xplained due to size restrictions
> > > > > ---
> > > > > This patch depends on another patch:
> > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > ---
> > > > > common/spl/Kconfig | 7 +++
> > > > > common/spl/spl_mmc.c | 46
> > > > >
> > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > --- a/common/spl/Kconfig
> > > > > +++ b/common/spl/Kconfig
> > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > help
> > > > > Enable write access to MMC and SD Cards in SPL
> > > > >
> > > > > +config SPL_MMC_WARNINGS
> > > > > + bool "Print MMC warnings"
> > > > > + depends on SPL_MMC
> > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > + help
> > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > SPL size.
> > > > > +
> > > > >
> > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > bool "Support MPC8XXX DDR init"
> > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > --- a/common/spl/spl_mmc.c
> > > > > +++ b/common/spl/spl_mmc.c
> > > > > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct
> > > > > mmc *mmc)
> > > > >*
> > > > >* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > value.
> > > > > - *
> > > > > - * FIXME: When booting from this eMMC device is explicitly
> > > > > - * disabled then we use User area for booting. This is
> > > > > incorrect.
> > > > > - * Probably we should skip this eMMC device and select the next
> > > > > - * one for booting. Or at least throw warning about this
> > > > > fallback.
> > > > >*/
> > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > - if (part == 7)
> > > > > - part = 0;
> > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > + part = 0; /* If partitions are not supported then we
> > > > > have only User Area partition */
> > > > > + else {
> > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > selecting User Area partition for booting\n");
> > > > > +#else
> > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > +#endif
> > > > > +#endif
> > > > > + /* FIXME: This is incorrect and probably we
> > > > > should select next eMMC device for booting */
> > > > > + part = 0;
> > > > > + break;
> > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > + part = 1;
> > > > > + break;
> > > > > + case 2: /* Boot partition 2 is used for booting */
> > > > > + part = 2;
> > > > > + break;
> > > > > + case 7: /* User area is used for booting */
> > > > > + part = 0;
> > > > > + break;
> > > > > + default: /* Other values are reserved *
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > To make eMMC partition choosing in
> > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > function better understandable, rewrite it via explicit switch-case
> > > > > > code
> > > > > > pattern.
> > > > > >
> > > > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > > > user to
> > > > > > value which is not suitable for eMMC booting and SPL do not know
> > > > > > how to
> > > > > > interpret it.
> > > > > >
> > > > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > > device
> > > > > > from User Area partition. This behavior was not changed in this
> > > > > > commit and
> > > > > > should be revisited in the future.
> > > > > >
> > > > > > Signed-off-by: Pali Rohár
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > restrictions
> > > > > > ---
> > > > > > This patch depends on another patch:
> > > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > ---
> > > > > > common/spl/Kconfig | 7 +++
> > > > > > common/spl/spl_mmc.c | 46
> > > > > >
> > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > --- a/common/spl/Kconfig
> > > > > > +++ b/common/spl/Kconfig
> > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > help
> > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > >
> > > > > > +config SPL_MMC_WARNINGS
> > > > > > + bool "Print MMC warnings"
> > > > > > + depends on SPL_MMC
> > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > + help
> > > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > > SPL size.
> > > > > > +
> > > > > >
> > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > bool "Support MPC8XXX DDR init"
> > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > --- a/common/spl/spl_mmc.c
> > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > @@ -408,15 +408,45 @@ int
> > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > *
> > > > > > * Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > > value.
> > > > > > -*
> > > > > > -* FIXME: When booting from this eMMC device is explicitly
> > > > > > -* disabled then we use User area for booting. This is
> > > > > > incorrect.
> > > > > > -* Probably we should skip this eMMC device and select the next
> > > > > > -* one for booting. Or at least throw warning about this
> > > > > > fallback.
> > > > > > */
> > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > - if (part == 7)
> > > > > > - part = 0;
> > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > + part = 0; /* If partitions are not supported then we
> > > > > > have only User Area partition */
> > > > > > + else {
> > > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > > selecting User Area partition for booting\n");
> > > > > > +#else
> > > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > > +#endif
> > > > > > +#endif
> > > > > > + /* FIXME: This is incorrect and probably we
> > > > > > should select next eMMC device for booting */
> > > > > > + part = 0;
> > > > > > + break;
> > > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > > + part = 1;
> > > > > > + break;
> > > > > > + case 2: /* Boot partition 2 is used for booting */
> > > > > > + part = 2;
> > > > > > + break;
> > > > > > +
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Fri, Jul 07, 2023 at 07:05:45PM +0200, Pali Rohár wrote:
> On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> > On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > > To make eMMC partition choosing in
> > > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > > function better understandable, rewrite it via explicit
> > > > > > > switch-case code
> > > > > > > pattern.
> > > > > > >
> > > > > > > Also add a warning when eMMC EXT_CSD[179] register is configured
> > > > > > > by user to
> > > > > > > value which is not suitable for eMMC booting and SPL do not know
> > > > > > > how to
> > > > > > > interpret it.
> > > > > > >
> > > > > > > Note that when booting from eMMC device via EXT_CSD[179] register
> > > > > > > is
> > > > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > > > device
> > > > > > > from User Area partition. This behavior was not changed in this
> > > > > > > commit and
> > > > > > > should be revisited in the future.
> > > > > > >
> > > > > > > Signed-off-by: Pali Rohár
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > > restrictions
> > > > > > > ---
> > > > > > > This patch depends on another patch:
> > > > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > > ---
> > > > > > > common/spl/Kconfig | 7 +++
> > > > > > > common/spl/spl_mmc.c | 46
> > > > > > >
> > > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > > >
> > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > > --- a/common/spl/Kconfig
> > > > > > > +++ b/common/spl/Kconfig
> > > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > > help
> > > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > > >
> > > > > > > +config SPL_MMC_WARNINGS
> > > > > > > + bool "Print MMC warnings"
> > > > > > > + depends on SPL_MMC
> > > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > > + help
> > > > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > > > SPL size.
> > > > > > > +
> > > > > > >
> > > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > > bool "Support MPC8XXX DDR init"
> > > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > > --- a/common/spl/spl_mmc.c
> > > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > > @@ -408,15 +408,45 @@ int
> > > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > >*
> > > > > > >* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > > > value.
> > > > > > > - *
> > > > > > > - * FIXME: When booting from this eMMC device is explicitly
> > > > > > > - * disabled then we use User area for booting. This is
> > > > > > > incorrect.
> > > > > > > - * Probably we should skip this eMMC device and select the next
> > > > > > > - * one for booting. Or at least throw warning about this
> > > > > > > fallback.
> > > > > > >*/
> > > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > > - if (part == 7)
> > > > > > > - part = 0;
> > > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > > + part = 0; /* If partitions are not supported then we
> > > > > > > have only User Area partition */
> > > > > > > + else {
> > > > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > > > selecting User Area partition for booting\n");
> > > > > > > +#else
> > > > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > > > +#endif
> > > > > > > +#endif
> > > > > > > + /* FIXME: This is incorrect and probably we
> > > > > > > should select next eMMC device for booting */
> > > > > > > + part = 0;
> > > > > > > + break;
> > > > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > > > + part = 1;
Re: [PATCH v14 05/11] log: select physical address formatting in a generic way
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > sets the log formatting according to the platform (64-bit vs 32-bit) > > Signed-off-by: Abdellatif El Khlifi > Cc: Simon Glass > --- > include/log.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/include/log.h b/include/log.h > index 3bab40b617..689cef905b 100644 > --- a/include/log.h > +++ b/include/log.h > @@ -686,4 +686,12 @@ static inline int log_get_default_format(void) >(IS_ENABLED(CONFIG_LOGF_FUNC) ? BIT(LOGF_FUNC) : 0); > } > > +/* Select the right physical address formatting according to the platform */ > +#ifdef CONFIG_PHYS_64BIT > +#define PhysAddrLength "ll" > +#else > +#define PhysAddrLength "" Shouldn't this be "l" ? We normally use ulong for addresses. > +#endif > +#define PHYS_ADDR_LN "%" PhysAddrLength "x" > +#define PHYS_ADDR_LNU "%" PhysAddrLength "u" > #endif > -- > 2.25.1 > Regards, Simon
Re: [PATCH v14 07/11] arm_ffa: introduce sandbox FF-A support
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support > > Features of the sandbox FF-A support: > > - Introduce an FF-A emulator > - Introduce an FF-A device driver for FF-A comms with emulated Secure World > - Provides test methods allowing to read the status of the inspected ABIs > > The sandbox FF-A emulator supports only 64-bit direct messaging. > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > Cc: Heinrich Schuchardt > > --- > > Changelog: > === > > v12: > > * remove reparenting by making the emulator parent of the FF-A device in the > DT > * add invoke_ffa_fn() > * address nits > > v11: > > * rename ffa_try_discovery() to sandbox_ffa_discover() > * rename sandbox_ffa_query_core_state() to sandbox_query_ffa_emul_state() > * store the sandbox emulator pointer in the FF-A device uc_priv (struct > ffa_priv) > * set the emulator as parent of the sandbox FF-A device > > v10: > > * split the FF-A sandbox support into an emulator and a driver > * read FFA_VERSION and FFA_PARTITION_INFO_GET state using >sandbox_ffa_query_core_state() > * drop CONFIG_SANDBOX_FFA config > * address nits > > v9: align FF-A sandbox driver with FF-A discovery through DM > > v8: update ffa_bus_prvdata_get() to return a pointer rather than > a pointer address > > v7: state that sandbox driver supports only 64-bit direct messaging > > v4: align sandbox driver with the new FF-A driver interfaces > and new way of error handling > > v1: introduce the sandbox driver > > MAINTAINERS | 3 +- > arch/sandbox/dts/sandbox.dtsi | 9 + > arch/sandbox/dts/test.dts | 8 + > arch/sandbox/include/asm/sandbox_arm_ffa.h| 72 ++ > .../include/asm/sandbox_arm_ffa_priv.h| 121 +++ > configs/sandbox64_defconfig | 1 + > configs/sandbox_defconfig | 1 + > doc/arch/arm64.ffa.rst| 19 +- > doc/arch/sandbox/sandbox.rst | 1 + > drivers/firmware/arm-ffa/Kconfig | 13 +- > drivers/firmware/arm-ffa/Makefile | 10 +- > drivers/firmware/arm-ffa/ffa-emul-uclass.c| 720 ++ > .../firmware/arm-ffa/sandbox_arm_ffa_priv.h | 14 - > drivers/firmware/arm-ffa/sandbox_ffa.c| 110 +++ > include/dm/uclass-id.h| 1 + > 15 files changed, 1081 insertions(+), 22 deletions(-) > create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa.h > create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa_priv.h > create mode 100644 drivers/firmware/arm-ffa/ffa-emul-uclass.c > delete mode 100644 drivers/firmware/arm-ffa/sandbox_arm_ffa_priv.h > create mode 100644 drivers/firmware/arm-ffa/sandbox_ffa.c Reviewed-by: Simon Glass
Re: [PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > turn on EFI MM communication > > On corstone1000 platform MM communication between u-boot > and the secure world (Optee) is done using the FF-A bus. > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > > --- > > Changelog: > === > > v13: > > * remove FF-A config in the defconfig >(because it's enabled automatically by CONFIG_EFI_MM_COMM_TEE) > > v9: > > * update copyright string > > v8: > > * drop OP-TEE configs from Corstone-1000 defconfig > > v7: > > * improve the definition of FFA_SHARED_MM_BUFFER_ADDR and > FFA_SHARED_MM_BUFFER_OFFSET > * update FFA_SHARED_MM_BUFFER_ADDR value > > v6: > > * corstone-1000: enable optee driver > * corstone-1000: remove CONFIG_ARM_FFA_EFI_RUNTIME_MODE from the defconfig > > v4: > > * corstone-1000: turn on EFI MM communication > > configs/corstone1000_defconfig | 1 + > include/configs/corstone1000.h | 15 +-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig > index a8a79fd105..b57e2322c4 100644 > --- a/configs/corstone1000_defconfig > +++ b/configs/corstone1000_defconfig > @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y > CONFIG_EFI_IGNORE_OSINDICATIONS=y > CONFIG_FWU_MULTI_BANK_UPDATE=y > CONFIG_ERRNO_STR=y > +CONFIG_EFI_MM_COMM_TEE=y > diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h > index 3347c11792..4ef1f05e40 100644 > --- a/include/configs/corstone1000.h > +++ b/include/configs/corstone1000.h > @@ -1,9 +1,11 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * (C) Copyright 2022 ARM Limited > * (C) Copyright 2022 Linaro > * Rui Miguel Silva > - * Abdellatif El Khlifi > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > + * > + * Authors: > + * Abdellatif El Khlifi > * > * Configuration for Corstone1000. Parts were derived from other ARM > * configurations. > @@ -14,6 +16,15 @@ > > #include > > +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ > + > +/* > + * shared buffer physical address used for communication between > + * u-boot and the MM SP > + */ > +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL > +#define FFA_SHARED_MM_BUFFER_OFFSET0 > + These should be in devicetree properties, shouldn't they? We don't want things in board config.h files anymore. > #define V2M_BASE 0x8000 > > #define CFG_PL011_CLOCK5000 > -- > 2.25.1 > Regards, Simon
Re: [PATCH v2 1/3] binman: Add support for externally encrypted blobs
Hi Christian,
On Tue, 4 Jul 2023 at 10:03, wrote:
>
> From: Christian Taedcke
>
> This adds a new etype encrypted that is derived from collection.
>
> It creates a new cipher node in the related image similar to the
> cipher node used by u-boot, see boot/image-cipher.c.
>
> Signed-off-by: Christian Taedcke
> ---
>
> Changes in v2:
> - remove global /cipher node
> - replace key-name-hint with key-source property
> - add entry documentation
>
> tools/binman/etype/encrypted.py | 149
> 1 file changed, 149 insertions(+)
> create mode 100644 tools/binman/etype/encrypted.py
Please can you regenerate entries.rst in the same patch?
Also please rebase your series on u-boot-dm/mkim-working as it has a
fix to section.py (if that is a pain for you to do, I can do it).
>
> diff --git a/tools/binman/etype/encrypted.py b/tools/binman/etype/encrypted.py
> new file mode 100644
> index 00..feb2b4f1de
> --- /dev/null
> +++ b/tools/binman/etype/encrypted.py
> @@ -0,0 +1,149 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright 2023 Weidmüller Interface GmbH & Co. KG
> +# Written by Christian Taedcke
> +#
> +# Entry-type module for cipher information of encrypted blobs/binaries
> +#
> +
> +from binman.etype.collection import Entry_collection
> +from dtoc import fdt_util
> +from u_boot_pylib import tools
> +
> +# This is imported if needed
> +state = None
> +
> +
> +class Entry_encrypted(Entry_collection):
> +"""Externally built encrypted binary blob
> +
> +This entry provides the functionality to include information about how to
> +decrypt an encrypted binary. This information is added to the
> +resulting device tree by adding a new cipher node in the entry's parent
> +node (i.e. the binary).
> +
> +The key that must be used to decrypt the binary is either directly
> embedded
> +in the device tree or indirectly by specifying a key source. The key
> source
> +can be used as an id of a key that is stored in an external device.
> +
> +Using an embedded key
> +~
> +
> +This is an example using an embedded key::
> +
> +encrypted_blob: blob-ext {
> +filename = "encrypted-blob.bin";
> +};
> +
> +encrypted {
> +content = <&encrypted_blob>;
> +algo = "aes256-gcm";
> +iv-filename = "encrypted-blob.bin.iv";
> +key-filename = "encrypted-blob.bin.key";
> +};
> +
> +This entry generates the following device tree structure form the example
> +above::
> +
> +data = [...]
> +cipher {
> +algo = "aes256-gcm";
> +key = <0x...>;
> +iv = <0x...>;
> +};
> +
> +The data property is generated by the blob-ext etype, the cipher node and
> +its content is generated by this etype.
> +
> +Using an external key
> +~
> +
> +Instead of embedding the key itself into the device tree, it is also
> +possible to address an externally stored key by specifying a 'key-source'
> +instead of the 'key'::
> +
> +encrypted_blob: blob-ext {
> +filename = "encrypted-blob.bin";
> +};
> +
> +encrypted {
> +content = <&encrypted_blob>;
> +algo = "aes256-gcm";
> +iv-filename = "encrypted-blob.bin.iv";
> +key-source = "external-key-id";
> +};
> +
> +This entry generates the following device tree structure form the example
> +above::
> +
> +data = [...]
> +cipher {
> +algo = "aes256-gcm";
> +key-source = "external-key-id";
> +iv = <0x...>;
> +};
> +
> +Properties
> +~~
> +
> +In addition to the inherited 'collection' for Properties / Entry
> arguments:
> +- algo: The encryption algorithm. Currently no algorithm is supported
> +out-of-the-box. Certain algorithms will be added in future
> +patches.
> +- iv-filename: The name of the file containing the initialization
> + vector (in short iv). See
> + https://en.wikipedia.org/wiki/Initialization_vector
> +- key-filename: The name of the file containing the key. Either
> +key-filename or key-source must be provided.
> +- key-source: The key that should be used. Either key-filename or
> + key-source must be provided.
> +"""
> +
> +def __init__(self, section, etype, node):
> +# Put this here to allow entry-docs and help to work without libfdt
> +global state
> +from binman import state
> +
> +super().__init__(section, etype, node)
> +self.required_props = ['algo', 'iv-filename']
> +self._algo = None
> +self._iv_filename = None
> +self._key_name_hint = None
> +self._key_filename = None
> +
> +def ReadNode(
Re: [PATCH v2 2/3] binman: Allow cipher node as special section
On Tue, 4 Jul 2023 at 10:03, wrote: > > From: Christian Taedcke > > The new encrypted etype generates a cipher node in the device tree > that should not be evaluated by binman, but still be kept in the > output device tree. > > Signed-off-by: Christian Taedcke > --- > > (no changes since v1) > > tools/binman/etype/section.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Although this patch needs to change once rebased to u-boot-dm/mkim-working
Re: [PATCH v2 3/3] binman: Add tests for etype encrypted
Hi Christian,
On Tue, 4 Jul 2023 at 10:03, wrote:
>
> From: Christian Taedcke
>
> Add tests to reach 100% code coverage for the added etype encrypted.
>
> Signed-off-by: Christian Taedcke
> ---
>
> Changes in v2:
> - adapt tests for changed entry implementation
>
> tools/binman/ftest.py | 52 +++
> .../binman/test/282_encrypted_no_content.dts | 15 ++
> tools/binman/test/283_encrypted_no_algo.dts | 19 +++
> .../test/284_encrypted_invalid_iv_file.dts| 23
> .../binman/test/285_encrypted_missing_key.dts | 28 ++
> .../binman/test/286_encrypted_key_source.dts | 29 +++
> tools/binman/test/287_encrypted_key_file.dts | 29 +++
> 7 files changed, 195 insertions(+)
> create mode 100644 tools/binman/test/282_encrypted_no_content.dts
> create mode 100644 tools/binman/test/283_encrypted_no_algo.dts
> create mode 100644 tools/binman/test/284_encrypted_invalid_iv_file.dts
> create mode 100644 tools/binman/test/285_encrypted_missing_key.dts
> create mode 100644 tools/binman/test/286_encrypted_key_source.dts
> create mode 100644 tools/binman/test/287_encrypted_key_file.dts
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 43b4f850a6..d51139799f 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -94,6 +94,8 @@ ROCKCHIP_TPL_DATA = b'rockchip-tpl'
> TEST_FDT1_DATA= b'fdt1'
> TEST_FDT2_DATA= b'test-fdt2'
> ENV_DATA = b'var1=1\nvar2="2"'
> +ENCRYPTED_IV_DATA = b'123456'
> +ENCRYPTED_KEY_DATA= b'1234567890123456'
Can you make that different, e.g. abcd, since at present one is a
subset of the other. Does the length matter? If not, shorter is better
for the second one, so we can visually look at the output.
> PRE_LOAD_MAGIC= b'UBSH'
> PRE_LOAD_VERSION = 0x11223344.to_bytes(4, 'big')
> PRE_LOAD_HDR_SIZE = 0x1000.to_bytes(4, 'big')
> @@ -226,6 +228,10 @@ class TestFunctional(unittest.TestCase):
> # Newer OP_TEE file in v1 binary format
> cls.make_tee_bin('tee.bin')
>
> +# test files for encrypted tests
> +TestFunctional._MakeInputFile('encrypted-file.iv', ENCRYPTED_IV_DATA)
> +TestFunctional._MakeInputFile('encrypted-file.key',
> ENCRYPTED_KEY_DATA)
> +
> cls.comp_bintools = {}
> for name in COMP_BINTOOLS:
> cls.comp_bintools[name] = bintool.Bintool.create(name)
> @@ -6676,6 +6682,52 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> ['fit'])
> self.assertIn("Node '/fit': Missing tool: 'mkimage'",
> str(e.exception))
>
> +def testEncryptedNoContent(self):
"""Test for missing content property"""
Please add a comment to following test functions
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('282_encrypted_no_content.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted':
> Collection must have a 'content' property", str(e.exception))
Please wrap to 80cols. It is OK not to split strings though, but
otherwise, please keep to 80.
self.assertIn(
"Node '/binman/fit/images/u-boot/encrypted': Collection must have
a 'content' property",
str(e.exception))
same below
> +
> +def testEncryptedNoAlgo(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('283_encrypted_no_algo.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted':
> 'encrypted' entry is missing properties: algo iv-filename", str(e.exception))
> +
> +def testEncryptedInvalidIvfile(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('284_encrypted_invalid_iv_file.dts')
> +self.assertIn("Filename 'invalid-iv-file' not found in input path",
> + str(e.exception))
> +
> +def testEncryptedMissingKey(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('285_encrypted_missing_key.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted': Provide
> either 'key-filename' or 'key-source'",
> + str(e.exception))
> +
> +def testEncryptedKeySource(self):
> +data = self._DoReadFileDtb('286_encrypted_key_source.dts')[0]
> +
> +dtb = fdt.Fdt.FromData(data)
> +dtb.Scan()
> +
> +node = dtb.GetNode('/images/u-boot/cipher')
> +self.assertEqual('algo-name', node.props['algo'].value)
> +self.assertEqual('key-source-value', node.props['key-source'].value)
> +self.assertEqual(ENCRYPTED_IV_DATA,
> tools.to_bytes(''.join(node.props['iv'].value)))
> +self.assertNotIn('key', node.props)
> +
> +def testEncryptedKeyFile(self):
> +data = self._DoReadFileDtb('287_encrypted_key_file.dts')[0]
> +
> +dtb = fdt.Fdt.FromData(data)
> +dtb.Scan()
> +
> +node
Re: [PATCH v2 01/11] binman: elf: Check for ELF_TOOLS availability and remove extra semicolon
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
> Check if elf tools are available when running DecodeElf(). Also
> remove superfuous semicolon at line ending.
>
> Signed-off-by: Lukas Funke
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v1)
>
> tools/binman/elf.py | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/tools/binman/elf.py b/tools/binman/elf.py
> index 5816284c32..a53f4b9c4f 100644
> --- a/tools/binman/elf.py
> +++ b/tools/binman/elf.py
> @@ -438,13 +438,15 @@ def DecodeElf(data, location):
> Returns:
> ElfInfo object containing information about the decoded ELF file
> """
> +if not ELF_TOOLS:
> +raise ValueError("Python: No module named 'elftools'")
Actually this is missing test coverage. See testEmbedFail() for an
example of how to add it for this function.
Use 'binman test -T' to see test coverage.
> file_size = len(data)
> with io.BytesIO(data) as fd:
> elf = ELFFile(fd)
> -data_start = 0x;
> -data_end = 0;
> -mem_end = 0;
> -virt_to_phys = 0;
> +data_start = 0x
> +data_end = 0
> +mem_end = 0
> +virt_to_phys = 0
>
> for i in range(elf.num_segments()):
> segment = elf.get_segment(i)
> --
> 2.30.2
>
Regards,
Simon
Re: [PATCH v2 10/11] binman: ftest: Add test for xilinx_fsbl_auth etype
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
> Add test for the 'xilinx_fsbl_auth' etype
>
> Signed-off-by: Lukas Funke
>
> ---
>
> Changes in v2:
> - Fixed typo in dts name
>
> tools/binman/ftest.py | 8
> tools/binman/test/280_xilinx_fsbl_auth.dts | 23 ++
> 2 files changed, 31 insertions(+)
> create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 0ee0ce1155..27a8a37864 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6686,6 +6686,14 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> ['fit'])
> self.assertIn("Node '/fit': Missing tool: 'mkimage'",
> str(e.exception))
>
> +def testXilinxFsblAuth(self):
> +"""Test xilinx_fsbl_auth etype"""
> +data = tools.read_file(self.TestFile("key.key"))
> +self._MakeInputFile("psk.pem", data)
> +self._MakeInputFile("ssk.pem", data)
> +self._SetupPmuFwlElf()
> +self._SetupSplElf()
> +self._DoReadFileRealDtb('280_xilinx_fsbl_auth.dts')
Can you check something in the image to see it is there?
>
> def testSplPubkeyDtb(self):
> """Test u_boot_spl_pubkey_dtb etype"""
> diff --git a/tools/binman/test/280_xilinx_fsbl_auth.dts
> b/tools/binman/test/280_xilinx_fsbl_auth.dts
> new file mode 100644
> index 00..a37c5aa072
> --- /dev/null
> +++ b/tools/binman/test/280_xilinx_fsbl_auth.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + xilinx-fsbl-auth {
> + filename = "boot.bin";
> +
> + psk-filename = "psk.pem";
> + ssk-filename = "ssk.pem";
> + auth-params = "ppk_select=0", "spk_id=0x";
> +
> + u-boot-spl-nodtb {
> + };
> + u-boot-spl-dtb {
> + };
> + };
> + };
> +};
> --
> 2.30.2
>
Regards,
Simon
Re: [PATCH v2 09/11] binman: btool: Add Xilinx Bootgen btool
Hi Lukas, On Thu, 6 Jul 2023 at 09:38, wrote: > > From: Lukas Funke > > Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create > bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The > btool creates a signed version of the SPL. Additionally to signing the > key source for the decryption engine can be passend to the boot image. > > Signed-off-by: Lukas Funke > > --- > > Changes in v2: > - Pass additional 'keysrc_enc' parameter to Bootgen > - Added more information and terms to documentation > > tools/binman/btool/bootgen.py | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 tools/binman/btool/bootgen.py > This does not work for me: binman tool -f missing Fetching tools: bootgen bzip2 cbfstool fdt_add_pubkey fiptool futility gzip ifwitool lz4 lzma_alone lzop mkimage openssl xz zstd Fetch: bootgen - trying method: binary download - trying method: build from source - clone git repo 'https://github.com/Xilinx/bootgen' to '/tmp/binmanf.qq6wo7tw' - build target 'all' - File '/tmp/binmanf.qq6wo7tw/build/bootgen/bootgen' was not produced - failed to fetch with all methods Otherwise it looks good. > diff --git a/tools/binman/btool/bootgen.py b/tools/binman/btool/bootgen.py > new file mode 100644 > index 00..a30268c964 > --- /dev/null > +++ b/tools/binman/btool/bootgen.py > @@ -0,0 +1,136 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2023 Weidmüller Interface GmbH & Co. KG > +# Lukas Funke > +# > +"""Bintool implementation for bootgen > + > +bootgen allows creating bootable SPL for Zynq(MP) > + > +Documentation is available via:: > +https://www.xilinx.com/support/documents/sw_manuals/xilinx2022_1/ug1283-bootgen-user-guide.pdf > + > +Source code is available at: > + > +https://github.com/Xilinx/bootgen > + > +""" > +import tempfile > + > +from binman import bintool > +from u_boot_pylib import tools > + > +# pylint: disable=C0103 > +class Bintoolbootgen(bintool.Bintool): > +"""Generate bootable fsbl image for zynq/zynqmp > + > +This bintools supports running Xilinx "bootgen" in order > +to generate a bootable, authenticated image form an SPL. > + > +""" > +def __init__(self, name): > +super().__init__(name, 'Xilinx Bootgen', > + version_regex=r'^\*\*\*\*\*\* Xilinx Bootgen', > + version_args='') > + > +# pylint: disable=R0913 > +def sign(self, arch, spl_elf_fname, pmufw_elf_fname, > + psk_fname, ssk_fname, fsbl_config, auth_params, keysrc_enc, > + output_fname): > +""" Sign SPL elf file and bundle it PMU firmware into an image > + > +The method bundels the SPL together with a 'Platform Management Unit' > +(PMU)[1] firmware into a single bootable image. The image in turn is > +signed with the provided 'secondary secret key' (ssk), which in turn > is > +signed with the 'primary secret key' (ppk). In order to verify the > +authenticity of the ppk, it's hash has to be fused into the device > +itself. > + > +In Xilinx terms the SPL is usually called 'FSBL' > +(First Stage Boot Loder). The jobs of the SPL and the FSBL are mostly > +the same: load bitstream, bootstrap u-boot. > + > +Args: > +arch (str): Xilinx SoC architecture. Currently only 'zynqmp' is > +supported. > +spl_elf_fname (str): Filename of SPL ELF file. The filename must > end > +with '.elf' in order for bootgen to recognized it as an ELF > +file. Otherwise the start address field is missinterpreted. > +pmufw_elf_fname (str): Filename PMU ELF firmware. > +psk_fname (str): Filename of the primary secret key (psk). The > psk > +is a .pem file which holds the RSA private key used for > signing > +the secondardy secret key. > +ssk_fname (str): Filename of the secondary secret key. The ssk > +is a .pem file which holds the RSA private key used for > signing > +the aktual boot firmware. > +fsbl_config (str): FSBL config options. A string list of fsbl > config > +options. Valid values according to [2] are: > +"bh_auth_enable": Boot Header Authentication Enable: RSA > +authentication of the bootimage is done > +excluding the verification of PPK hash and SPK ID. This > is > +useful for debugging before bricking a device. > +"auth_only": Boot image is only RSA signed. FSBL should not > be > +decrypted. See the > +Zynq UltraScale+ Device Technical Reference Manual > (UG1085) > +for more information. > +There are more options which relate to PUF (physical > unclonable > +function
Re: [PATCH v5 03/23] arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
On Fri, 7 Jul 2023 at 13:35, Neha Malcom Francis wrote: > > Board config binary artifacts must be generated to be used by binman to > package sysfw.itb and tiboot3.bin for all K3 devices. > > For devices that follow combined flow, these board configuration > binaries must again be packaged into a combined board configuration > blobs to be used by binman to package tiboot3.bin. > > Add common k3-binman.dtsi to generate all the board configuration > binaries needed. > > Also add custMpk.pem and ti-degenerate-key.pem needed for signing GP and > HS bootloader images common to all K3 devices. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/dts/k3-binman.dtsi | 116 > 1 file changed, 116 insertions(+) > create mode 100644 arch/arm/dts/k3-binman.dtsi > Reviewed-by: Simon Glass
Re: [PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
Hi Neha, On Fri, 7 Jul 2023 at 13:36, Neha Malcom Francis wrote: > > Support added for HS and GP boot binaries for AM64x. > > HS-SE: > * tiboot3-am64x_sr2-hs-evm.bin > * tispl.bin > * u-boot.img > > HS-FS: > * tiboot3-am64x_sr2-hs-fs-evm.bin > * tispl.bin > * u-boot.img > > GP: > * tiboot3.bin --> tiboot3-am64x-gp-evm.bin > * tispl.bin_unsigned > * u-boot.img_unsigned > > Note that the bootflow followed by AM64x requires: > > tiboot3.bin: > * R5 SPL > * R5 SPL dtbs > * sysfw > * board-cfg > * pm-cfg > * sec-cfg > * rm-cfg > > tispl.bin: > * ATF > * OPTEE > * A53 SPL > * A53 SPL dtbs > > u-boot.img: > * A53 U-Boot > * A53 U-Boot dtbs > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > [a...@ti.com: changed output binary names appropriately] > Signed-off-by: Andrew Davis > --- > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 + > arch/arm/dts/k3-am642-r5-evm.dts | 1 + > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 + > arch/arm/dts/k3-am64x-binman.dtsi | 515 ++ > board/ti/am64x/Kconfig| 2 + > 5 files changed, 522 insertions(+) > create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi It looks like the template feature (see pending patches) might help reduce the size of the .dtsi, but we can worry about that later. Regards, Simon
Re: [PATCH v5 21/23] binman: Overwrite symlink if it already exists
Hi Neha, On Fri, 7 Jul 2023 at 13:37, Neha Malcom Francis wrote: > > From: Andrew Davis > > Without this re-building will fail with an error when trying to create > the symlink for the second time with an already exists error. > > Signed-off-by: Andrew Davis > Signed-off-by: Neha Malcom Francis > --- > tools/binman/image.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/binman/image.py b/tools/binman/image.py > index 8ebf71d61a..e77b5d0d97 100644 > --- a/tools/binman/image.py > +++ b/tools/binman/image.py > @@ -182,6 +182,8 @@ class Image(section.Entry_section): > # Create symlink to file if symlink given > if self._symlink is not None: > sname = tools.get_output_filename(self._symlink) > +if os.path.islink(sname): > +os.remove(sname) > os.symlink(fname, sname) > > def WriteMap(self): > -- > 2.34.1 > This breaks test coverage. Please add a test to ftest.py. You can probably run _DoTestFile() on an output directory with a in it? Regards, Simon
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On Fri, 7 Jul 2023 at 13:36, Neha Malcom Francis wrote: > > Move to using binman to generate tispl.bin which is used to generate the > final flash.bin bootloader for iot2050 boards. > > Signed-off-by: Neha Malcom Francis > Cc: Jan Kiszka > --- > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++- > 1 file changed, 74 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 09/10] doc: cmd: add documentation for scmi
Hi, On Tue, 4 Jul 2023 at 03:05, AKASHI Takahiro wrote: > > Hi Simon, > > On Mon, Jul 03, 2023 at 02:30:55PM +0100, Simon Glass wrote: > > Hi , > > > > On Mon, 3 Jul 2023 at 02:19, AKASHI Takahiro > > wrote: > > > > > > On Thu, Jun 29, 2023 at 08:10:02PM +0100, Simon Glass wrote: > > > > Hi AKASHI, > > > > > > > > On Wed, 28 Jun 2023 at 01:49, AKASHI Takahiro > > > > wrote: > > > > > > > > > > This is a help text for scmi command. > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > --- > > > > > doc/usage/cmd/scmi.rst | 98 > > > > > ++ > > > > > 1 file changed, 98 insertions(+) > > > > > create mode 100644 doc/usage/cmd/scmi.rst > > > > > > > > > > diff --git a/doc/usage/cmd/scmi.rst b/doc/usage/cmd/scmi.rst > > > > > new file mode 100644 > > > > > index ..20cdae4b877d > > > > > --- /dev/null > > > > > +++ b/doc/usage/cmd/scmi.rst > > > > > @@ -0,0 +1,98 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0+: > > > > > + > > > > > +scmi command > > > > > + > > > > > + > > > > > +Synopsis > > > > > + > > > > > + > > > > > +:: > > > > > + > > > > > +scmi base info > > > > > +scmi base perm_dev > > > > > +scmi base perm_proto > > > > > +scmi base reset > > > > > + > > > > > +Description > > > > > +--- > > > > > + > > > > > +The scmi command is used to access and operate on SCMI server. > > > > > + > > > > > +scmi base info > > > > > +~~ > > > > > +Show base information about SCMI server and supported protocols > > > > > + > > > > > +scmi base perm_dev > > > > > +~~ > > > > > +Allow or deny access permission to the device > > > > > + > > > > > +scmi base perm_proto > > > > > + > > > > > +Allow or deny access to the protocol on the device > > > > > + > > > > > +scmi base reset > > > > > +~~~ > > > > > +Reset the existing configurations > > > > > + > > > > > +Parameters are used as follows: > > > > > + > > > > > + > > > > > +Agent ID > > > > > > > > what is this? > > > > > > I thought that the meaning was trivial in SCMI context. > > > Will change it to "SCMI Agent ID". > > > > What is SCMI? Really you should explain and link to information about > > things you mention in documentation. How else is anyone supposed to > > Generally yes, but please note that SCMI and related drivers are already > there in U-Boot. For instance, see drivers/firmware/scmi/Kconfig. > I don't think we need any more explanation about what is SCMI everywhere > the word, "SCMI", appears. > > > figure out what you are talking about? > > Again, those who don't know about SCMI and if SCMI server is installed > on their systems will never use this command. > > > > > "SCMI Agent ID" doesn't tell us much. What form does it take? Is it a > > string? How do you find it out? > > While I still believe that What SCMI agent ID means is trivial for > those who read the SCMI specification, I will give a short description > about possible values. > > > > > > > > > > > > + > > > > > + > > > > > +Device ID > > > > > > > > what is this? > > > > > > Again, will change it to "SCMI Device ID". > > > > That doesn't help much. The purpose of documentation is to explain > > things for people who don't already know it. We need to try to be as > > helpful as possible. > > The same above. > Please note that the definition of "device (ID)", except its data type, > is out of scope of SCMI specification. > It doesn't describe any means by which values be identified/retrieved. > > > > > > > > > + > > > > > + > > > > > +Protocol ID, should not be 0x10 (base protocol) > > > > > > > > what is this? Please add more detail > > > > > > Again, will change it to "SCMI Protocol ID". > > > I think that users should be familiar with those terms > > > if they want to use these interfaces. > > > > Maybe, but it still isn't clear what it is. A string? > > Will add a short description about its data type/format. > > > It is confusing > > that the command ID is also a protocol ID. > > Yes, I know, but the confusion exists in SCMI specification. > It sometimes seems to use both words almost interchangeably, even > in a single context. For instance, the section 4.2.2.11 of [1] > says, > > 4.2.2.11 BASE_SET_PROTOCOL_PERMISSIONS > ... > This command BASE_SET_PROTOCOL_PERMISSIONS is used to ... > (This "command" has a yet another meaning.) > > Parameters > uint32_t command_id Bits[31:8] Reserved, must be zero > Bits[7:0] Protocol ID > > [1] https://developer.arm.com/documentation/den0056/e/?lang=en > > So using "command_id" for a parameter name and "Protocol ID" > as a (part of) value is very much aligned with the specification. > > That said, I will change "command_id" to "protocol_id" for now. > > > > > > > > > + > > > > > + > > > > > +Flags to control the action. See SCMI specification for > > > > > +defined values. > > > > > > > > ? > > > > >
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 17:03, Jan Kiszka wrote:
>
> On 07.07.23 17:35, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
> >>
> >> On 07.07.23 14:42, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>
> On 05.07.23 00:14, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
> >>
> >> Hi Simon,
> >>
> >> On 28.06.23 13:41, Simon Glass wrote:
> >>> Collections can used to collect the contents of other entries into a
> >>> single entry, but they result in a single entry, with the original
> >>> entries
> >>> 'left behind' in their old place.
> >>>
> >>> It is useful to be able to specific a set of entries ones and have it
> >>> used
> >>> in multiple images, or parts of an image.
> >>>
> >>> Implement this mechanism.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>> tools/binman/binman.rst | 80
> >>>
> >>> tools/binman/control.py | 9 +++
> >>> tools/binman/etype/section.py| 3 +-
> >>> tools/binman/ftest.py| 8 +++
> >>> tools/binman/test/286_entry_template.dts | 42 +
> >>> 5 files changed, 141 insertions(+), 1 deletion(-)
> >>> create mode 100644 tools/binman/test/286_entry_template.dts
> >>>
> >>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> >>> index a4b31fe5397b..9be979ae1c5b 100644
> >>> --- a/tools/binman/binman.rst
> >>> +++ b/tools/binman/binman.rst
> >>> @@ -727,6 +727,13 @@ optional:
> >>> Note that missing, optional blobs do not produce a non-zero exit
> >>> code from
> >>> binman, although it does show a warning about the missing
> >>> external blob.
> >>>
> >>> +insert-template:
> >>> +This is not strictly speaking an entry property, since it is
> >>> processed early
> >>> +in Binman before the entries are read. It is a list of phandles
> >>> of nodes to
> >>> +include in the current (target) node. For each node, its
> >>> subnodes and their
> >>> +properties are brought into the target node. See Templates_
> >>> below for
> >>> +more information.
> >>> +
> >>> The attributes supported for images and sections are described
> >>> below. Several
> >>> are similar to those for entries.
> >>>
> >>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> >>> going on, you can use
> >>> arch/arm/dts/u-boot.dtsi ... found:
> >>> "arch/arm/dts/juno-r2-u-boot.dtsi"
> >>>
> >>>
> >>> +Templates
> >>> +=
> >>> +
> >>> +Sometimes multiple images need to be created which have all have a
> >>> common
> >>> +part. For example, a board may generate SPI and eMMC images which
> >>> both include
> >>> +a FIT. Since the FIT includes many entries, it is tedious to repeat
> >>> them twice
> >>> +in the image description.
> >>> +
> >>> +Templates provide a simple way to handle this::
> >>> +
> >>> +binman {
> >>> +multiple-images;
> >>> +common_part: template-1 {
> >>> +fit {
> >>> +... lots of entries in here
> >>> +};
> >>> +
> >>> +text {
> >>> +text = "base image";
> >>> +};
> >>> +};
> >>> +
> >>> +spi-image {
> >>> +filename = "image-spi.bin";
> >>> +insert-template = <&fit>;
> >>> +
> >>> +/* things specific to SPI follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "SPI image";
> >>> +};
> >>> +};
> >>> +
> >>> +mmc-image {
> >>> +filename = "image-mmc.bin";
> >>> +insert-template = <&fit>;
> >>> +
> >>> +/* things specific to MMC follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "MMC image";
> >>> +};
> >>> +};
> >>> +};
> >>> +
> >>> +The template node name must start with 'template', so it is not
> >>> considered to be
> >>> +an image itself.
> >>> +
> >>> +The mechanism is very simple. For each phandle in the
> >>> 'insert-templates'
> >>> +property, the source node is looked up. Then the subnodes of that
> >>> source node
> >>> +are copied into the target node, i.e. the one containing the
> >>> `insert-template`
> >>> +property.
> >>> +
> >>> +If the target node has a node with the
Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver
Hi Alexey, On Fri, 7 Jul 2023 at 09:43, Alexey Romanov wrote: > > Hello, Simon! > > On Thu, Jul 06, 2023 at 09:58:02AM -0600, Simon Glass wrote: > > Hi Alexey, > > > > On Thu, 6 Jul 2023 at 14:16, Alexey Romanov > > wrote: > > > > > > At the moment, only smc API is a set of functions in > > > arch/arm/mach-meson/sm.c. This approach is hard to configure > > > and also doesni't contain any generic API for calling smc. > > > > > > This patch add Meson SM driver with generic API (struct meson_sm_ops): > > > > > > - sm_call() > > > - sm_call_write() > > > - sm_call_read() > > > > > > A typical driver usage example is shown here: > > > > > > 1. uclass_get_device_by_driver(UCLASS_FIRMWARE, "secure-monitor", &dev); > > > 2. handle = meson_sm_get_handle(dev); > > > 3. handle->ops.sm_call(dev, cmd, ...); > > > > > > Signed-off-by: Alexey Romanov > > > --- > > > arch/arm/mach-meson/Kconfig | 1 + > > > drivers/firmware/Kconfig | 10 ++ > > > drivers/firmware/Makefile | 1 + > > > drivers/firmware/meson/Kconfig| 6 + > > > drivers/firmware/meson/Makefile | 3 + > > > drivers/firmware/meson/meson_sm.c | 217 ++ > > > include/meson/sm_handle.h | 38 ++ > > > 7 files changed, 276 insertions(+) > > > create mode 100644 drivers/firmware/meson/Kconfig > > > create mode 100644 drivers/firmware/meson/Makefile > > > create mode 100644 drivers/firmware/meson/meson_sm.c > > > create mode 100644 include/meson/sm_handle.h > > > > Please can you use the remoteproc uclass for this and add a proper driver? > > > > I don't see it architecturally well. Can you explain please? > > This driver is just ARM SMC fw interface. There seems to be nothing to > do here for remoteproc uclass. Well you seem to be implementing a remote CPU interface, which is what remoteproc is for. How does Linux do this? Also there is a pending series on FFA - is that related? It uses smc from what I can tell. Regards, Simon
Re: [PATCH v2 00/11] Sign Xilinx ZynqMP SPL/FSBL boot images using binman
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
>
> This series adds two etypes to create a verified boot chain for
> Xilinx ZynqMP devices. The first etype 'xilinx_fsbl_auth' is used to
> create a bootable, signed image for ZynqMP boards using the Xilinx
> Bootgen tool. The second etype 'u_boot_spl_pubkey_dtb' is used to add
> a '/signature' node to the SPL. The public key in the signature is read
> from a certificate file and added using the 'fdt_add_pubkey' tool. The
> series also contains the corresponding btool for calling 'bootgen' and
> 'fdt_add_pubkey'
>
> The following block shows an example on how to use this functionality:
>
> spl {
> filename = "boot.signed.bin";
>
> xilinx_fsbl_auth {
> psk-filename = "psk0.pem";
> ssk-filename = "ssk0.pem";
> auth-params = "ppk_select=0", "spk_id=0x";
>
> u_boot_spl_nodtb {
> };
> u_boot_spl_pubkey_dtb {
> algo = "sha384,rsa4096";
> required = "conf";
> key-name = "dev";
> };
> };
> };
>
>
> Changes in v2:
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb
> - Improved rst/python documentation
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb in example
> - Pass additional 'keysrc_enc' parameter to Bootgen
> - Added more information and terms to documentation
> - Fixed typo in dts name
> - Add 'keysrc-enc' property to pass down to Bootgen
> - Improved documentation
> - Use predictable output names for intermediated results
>
> Lukas Funke (11):
> binman: elf: Check for ELF_TOOLS availability and remove extra
> semicolon
> binman: Don't decompress data while signing
> binman: blob_dtb: Add fake_size argument to ObtainContents()
> binman: doc: Add documentation for fdt_add_pubkey bintool
> binman: ftest: Add test for u_boot_spl_pubkey_dtb
> binman: btool: Add fdt_add_pubkey as btool
> binman: etype: Add u_boot_spl_pubkey_dtb etype
> binman: doc: Add documentation for Xilinx Bootgen bintool
> binman: btool: Add Xilinx Bootgen btool
> binman: ftest: Add test for xilinx_fsbl_auth etype
> binman: etype: Add xilinx_fsbl_auth etype
>
> tools/binman/bintools.rst | 22 ++
> tools/binman/btool/bootgen.py | 136 +
> tools/binman/btool/fdt_add_pubkey.py| 67 ++
> tools/binman/control.py | 2 +-
> tools/binman/elf.py | 10 +-
> tools/binman/entries.rst| 92 +
> tools/binman/etype/blob_dtb.py | 2 +-
> tools/binman/etype/u_boot_spl_pubkey_dtb.py | 109 ++
> tools/binman/etype/xilinx_fsbl_auth.py | 213
> tools/binman/ftest.py | 42 +++-
> tools/binman/test/280_xilinx_fsbl_auth.dts | 23 +++
> tools/binman/test/281_spl_pubkey_dtb.dts| 16 ++
> 12 files changed, 727 insertions(+), 7 deletions(-)
> create mode 100644 tools/binman/btool/bootgen.py
> create mode 100644 tools/binman/btool/fdt_add_pubkey.py
> create mode 100644 tools/binman/etype/u_boot_spl_pubkey_dtb.py
> create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
> create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
> create mode 100644 tools/binman/test/281_spl_pubkey_dtb.dts
>
> --
> 2.30.2
>
This looks pretty good to me. I've made comments on individual
patches. Please do make sure that the docs are enough to understand
the feature - e.g. describing each field. You may need to link to some
'forever' docs somewhere too.
Regards,
Simon
