Re: [PATCH 8/9] clang: efi payload: Silence unaligned access warning
Hi
On Thu, 6 Apr 2023 at 09:16, Heinrich Schuchardt wrote:
>
> On 4/6/23 01:48, Tom Rini wrote:
> > When building with clang we see this warning:
> > field guid within 'struct efi_hii_keyboard_layout' is less aligned than
> > 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
> > packed, which can lead to unaligned accesses [-Wunaligned-access]
> >
> > Which is correct and true as EFI payloads are by specification allowed
> > to do unaligned access. And so to silence the warning here and only
> > here, we make use of #pragma to push/pop turning off the warning.
> >
> > Signed-off-by: Tom Rini
> > ---
> > Cc: Heinrich Schuchardt
> > Cc: Ilias Apalodimas
> > ---
> > include/efi_api.h | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index dc6e5ce236c9..f3bcbf593bea 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -1168,9 +1168,21 @@ struct efi_key_descriptor {
> > u16 affected_attribute;
> > } __packed;
> >
> > +/* The warniing:
> > + * field guid within 'struct efi_hii_keyboard_layout' is less aligned than
> > 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
> > packed, which can lead to unaligned accesses [-Wunaligned-access]
> > + * is intentional due to EFI requiring unaligned access to be supported.
> > + */
> > struct efi_hii_keyboard_layout {
> > u16 layout_length;
> > +#ifdef CONFIG_CC_IS_CLANG
> > +#pragma clang diagnostic push
> > +#pragma clang diagnostic ignored "-Wunaligned-access"
> > +#endif
> > efi_guid_t guid;
> > +#ifdef CONFIG_CC_IS_CLANG
> > +#pragma clang diagnostic pop
> > +#endif
>
> I don't think that the clang warning should be suppressed. We should
> replace efi_guid_t by u8[16] instead. This will force us to take the
> missing alignment into account when accessing the component in future.
>
> - efi_guid_t guid;
> + u8 guid[16];
I think what Heinrich suggests is fine, the EFI spec itself says that
efi_guid must be 8-byte aligned unless otherwise specified.
But we have another issue here. We aren't supposed to include structs
that contain flexible length arrays into another array or struct.
Quoting the C spec [0]
Such a structure (and any union containing, possibly recursively, a
member that is such a structure) shall not be a member of a structure
or an
element of an array. IOW efi_hii_keyboard_layout should not include
struct efi_key_descriptor descriptors[]; since we include it at
efi_hii_keyboard_package
Regards
/Ilias
[0] https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf
chapter 6.7.2.1
>
> Best regards
>
> Heinrich
>
> > +
> > u32 layout_descriptor_string_offset;
> > u8 descriptor_count;
> > struct efi_key_descriptor descriptors[];
>
Re: [PATCH 0/9] Update clang support for ARM
On 4/6/23 01:48, Tom Rini wrote: Hey all, I decided to take a look again at what's needed to build and boot ARM platforms when building with clang. The good news is that this generally works now. Some size-constrained platforms don't build right now but I was able to test a reasonable part of my lab. This series also depends on: https://patchwork.ozlabs.org/project/uboot/patch/20200604203515.12971-1-tr...@konsulko.com/ to fix the warning there. At this point LTO + clang requires a bit more work, and to use llvm-ld. As the platform I was trying was still too large to link even with this, I've set that investigation aside for now. I've boot tested clang-16 on Pi 3 (32bit, 64bit, arm64) and libretech-cc, and I'll be testing pine64_plus soon along with maybe mx6cuboxi and seeing what the failures are on am65x_evm / j721e_evm (these platforms require a bit more scripting on my part to make build and test clean). I tried to build qemu_arm64_defconfig with origin/WIP/update-clang-for-arm. CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=clang CC="clang make-target aarch64-linux-gnu" -j$(nproc) I see a bunch of warnings and a build failure due to examples/standalone/hello_world.c:15: undefined reference to `printf' Best regards Heinrich
Re: [PATCH V6 08/13] cmd: bmp: Split bmp commands and functions
Hi Simon,
On 06/04/23 00:07, Simon Glass wrote:
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote:
To enable splash screen at SPL, need to compile cmd/bmp.c which also
includes bmp commands, since SPL doesn't use commands split bmp.c into
common/bmp.c which includes all bmp functions and cmd/bmp.c which only
contains bmp commands.
Add function delclaration for bmp_info in video.h.
Signed-off-by: Nikhil M Jain
---
V6:
- Fix commit message.
- Remove unused header files.
V5:
- Rename cmd/bmp_cmd to cmd/bmp.
V4:
- No change.
V3 (patch introduced):
- Split bmp functions and commands.
cmd/bmp.c | 162 +---
common/bmp.c| 152 +
include/video.h | 7 +++
3 files changed, 161 insertions(+), 160 deletions(-)
create mode 100644 common/bmp.c
Reviewed-by: Simon Glass
Please see below
diff --git a/common/bmp.c b/common/bmp.c
new file mode 100644
index 00..6134ada5a7
--- /dev/null
+++ b/common/bmp.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2002
+ * Detlev Zundel, DENX Software Engineering, d...@denx.de.
+ */
+
+/*
+ * BMP handling routines
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Allocate and decompress a BMP image using gunzip().
+ *
+ * Returns a pointer to the decompressed image data. This pointer is
+ * aligned to 32-bit-aligned-address + 2.
+ * See doc/README.displaying-bmps for explanation.
+ *
+ * The allocation address is passed to 'alloc_addr' and must be freed
+ * by the caller after use.
+ *
+ * Returns NULL if decompression failed, or if the decompressed data
+ * didn't contain a valid BMP signature.
+ */
+#ifdef CONFIG_VIDEO_BMP_GZIP
You can drop this #ifdef and see below
+struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+void **alloc_addr)
+{
+ void *dst;
+ unsigned long len;
+ struct bmp_image *bmp;
+
if (!IS_ENABLED(CONFIG_VIDEO_BMP_GZIP))
return NULL;
I preferred to use #if to avoid compilation of code when not required.
For example, if someone doesn't want to display a gzip bmp image they
wouldn't want the code to be compiled, so that binary size doesn't
increase.
+ /*
+* Decompress bmp image
+*/
+ len = CONFIG_VIDEO_LOGO_MAX_SIZE;
+ /* allocate extra 3 bytes for 32-bit-aligned-address + 2 alignment */
+ dst = malloc(CONFIG_VIDEO_LOGO_MAX_SIZE + 3);
+ if (!dst) {
+ puts("Error: malloc in gunzip failed!\n");
+ return NULL;
+ }
+
+ /* align to 32-bit-aligned-address + 2 */
+ bmp = dst + 2;
+
+ if (gunzip(bmp, CONFIG_VIDEO_LOGO_MAX_SIZE, map_sysmem(addr, 0),
+ &len)) {
+ free(dst);
+ return NULL;
+ }
+ if (len == CONFIG_VIDEO_LOGO_MAX_SIZE)
+ puts("Image could be truncated (increase
CONFIG_VIDEO_LOGO_MAX_SIZE)!\n");
+
+ /*
+* Check for bmp mark 'BM'
+*/
+ if (!((bmp->header.signature[0] == 'B') &&
+ (bmp->header.signature[1] == 'M'))) {
+ free(dst);
+ return NULL;
+ }
+
+ debug("Gzipped BMP image detected!\n");
+
+ *alloc_addr = dst;
+ return bmp;
+}
+#else
+struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+void **alloc_addr)
+{
+ return NULL;
+}
+#endif
+
+
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+void bmp_reloc(void) {
+ fixup_cmdtable(cmd_bmp_sub, ARRAY_SIZE(cmd_bmp_sub));
+}
+#endif
+
+int bmp_info(ulong addr)
+{
+ struct bmp_image *bmp = (struct bmp_image *)map_sysmem(addr, 0);
+ void *bmp_alloc_addr = NULL;
+ unsigned long len;
+
+ if (!((bmp->header.signature[0]=='B') &&
+ (bmp->header.signature[1]=='M')))
+ bmp = gunzip_bmp(addr, &len, &bmp_alloc_addr);
+
+ if (bmp == NULL) {
+ printf("There is no valid bmp file at the given address\n");
+ return 1;
+ }
+
+ printf("Image size: %d x %d\n", le32_to_cpu(bmp->header.width),
+ le32_to_cpu(bmp->header.height));
+ printf("Bits per pixel: %d\n", le16_to_cpu(bmp->header.bit_count));
+ printf("Compression : %d\n", le32_to_cpu(bmp->header.compression));
+
+ if (bmp_alloc_addr)
+ free(bmp_alloc_addr);
+
+ return(0);
+}
+
+int bmp_display(ulong addr, int x, int y)
+{
+ struct udevice *dev;
+ int ret;
+ struct bmp_image *bmp = map_sysmem(addr, 0);
+ void *bmp_alloc_addr = NULL;
+ unsigned long len;
+
+ if (!((bmp->header.signature[0]=='B') &&
+ (bmp->header.signature[1]=='M')))
+ bmp = gunzip_bmp(addr, &len, &bmp_alloc_addr);
+
+ if (!bmp) {
+ printf("There is no valid bmp file at th
[PATCH] board: ti: am64x: Add support for AM64B SK
From: Judith Mendez
The AM64x SR2.0 SK board uses "AM64B-SKEVM" as the EEPROM identifier.
This board is similar to the AM64x SKEVM except that it has a new
PMIC that will be enabled in the future and consequently could use a
different device tree file in the future.
For now we treat the board same as an AM64x SK.
Signed-off-by: Judith Mendez
Acked-by: Andrew Davis
Signed-off-by: Vignesh Raghavendra
---
board/ti/am64x/evm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index c88139ac7acc..9aead2bc3345 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -20,7 +20,9 @@
#include "../common/board_detect.h"
#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
-#define board_is_am64x_skevm() board_ti_k3_is("AM64-SKEVM")
+
+#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
+ board_ti_k3_is("AM64B-SKEVM"))
DECLARE_GLOBAL_DATA_PTR;
--
2.40.0
Re: [PATCH 8/9] clang: efi payload: Silence unaligned access warning
On 4/6/23 01:48, Tom Rini wrote:
When building with clang we see this warning:
field guid within 'struct efi_hii_keyboard_layout' is less aligned than
'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
packed, which can lead to unaligned accesses [-Wunaligned-access]
Which is correct and true as EFI payloads are by specification allowed
to do unaligned access. And so to silence the warning here and only
here, we make use of #pragma to push/pop turning off the warning.
Signed-off-by: Tom Rini
---
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
include/efi_api.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index dc6e5ce236c9..f3bcbf593bea 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1168,9 +1168,21 @@ struct efi_key_descriptor {
u16 affected_attribute;
} __packed;
+/* The warniing:
+ * field guid within 'struct efi_hii_keyboard_layout' is less aligned than
'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
packed, which can lead to unaligned accesses [-Wunaligned-access]
+ * is intentional due to EFI requiring unaligned access to be supported.
+ */
struct efi_hii_keyboard_layout {
u16 layout_length;
+#ifdef CONFIG_CC_IS_CLANG
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wunaligned-access"
+#endif
efi_guid_t guid;
+#ifdef CONFIG_CC_IS_CLANG
+#pragma clang diagnostic pop
+#endif
I don't think that the clang warning should be suppressed. We should
replace efi_guid_t by u8[16] instead. This will force us to take the
missing alignment into account when accessing the component in future.
- efi_guid_t guid;
+ u8 guid[16];
Best regards
Heinrich
+
u32 layout_descriptor_string_offset;
u8 descriptor_count;
struct efi_key_descriptor descriptors[];
Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
Am 5. April 2023 23:56:59 MESZ schrieb Mark Kettenis : >> Date: Wed, 5 Apr 2023 10:47:59 -0400 >> From: Tom Rini >> >> On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote: >> > Hi Tom, >> > >> > On Tue, 4 Apr 2023, 02:17 Tom Rini, wrote: >> > >> > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote: >> > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote: >> > > > > Hi Tom, >> > > > > >> > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini wrote: >> > > > > > >> > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: >> > > > > > >> > > > > > > The current EFI implementation has a strange quirk where it >> > > > > > > watches >> > > > > > > loaded files and uses the last-loaded file to determine the >> > > > > > > device >> > > that >> > > > > > > is being booted from. >> > > > > > > >> > > > > > > This is confusing with bootstd, where multiple options may exist. >> > > Even >> > > > > > > loading a device tree will cause it to go wrong. There is no API >> > > for >> > > > > > > passing this information, since the only entry into booting an >> > > > > > > EFI >> > > image >> > > > > > > is the 'bootefi' command. >> > > > > > > >> > > > > > > To work around this, call efi_set_bootdev() for EFI images, if >> > > possible, >> > > > > > > just before booting. >> > > > > > > >> > > > > > > Signed-off-by: Simon Glass >> > > > > > >> > > > > > Shouldn't this all be a simple wrapper around the EFI Standard >> > > > > > BootDeviceOrder or whatever that's called? >> > > > > >> > > > > I think you are referring to boot manager, which isn't used here. >> > > > > This >> > > > > is replicating the existing distroboot functionality in standard >> > > > > boot. >> > > > >> > > > The distroboot functionality *was* trying to behave like the EFI spec >> > > > expects the bootmanager to behave. Unfortunately I haven't had time to >> > > > review the distroboot patches closely, but back when this started, my >> > > point >> > > > was that EFI doesn't need anything. Whenever the EFI flow is added >> > > bootstd >> > > > should 'just' call the bootmanager. >> > > >> > > Yes, this. We're trying make things cleaner overall, so the EFI portion >> > > of bootstd distro boot should just be "call EFI bootmanager" as that has >> > > a well defined standard way to specify what devices to try in what >> > > order. >> > > >> > >> > We already call bootmgr in standard boot, if it is enabled. >> > >> > But I am not sure how widely that is used... >> > >> > This patch is about corner cases in the distro scripts. If we are to turn >> > these down we do need to try to do the same thing. >> >> We probably need some distro people to chime in about what they're doing >> / expecting at this point in time? I would have sworn that the long term >> part of EFI "distro boot" would be using bootmgr since that's the >> standards based way to set boot order. And if you don't have a device >> tree in U-Boot, and want the distribution one, aren't you then using >> something like grub which has a "dtb" keyword to handle that on its own? >> That's not saying that "distro boot" doesn't need to load the device >> tree, for when it's then calling booti/bootz/bootm, but not for the EFI >> case these days? Or no? > >The short anserwer is no. > >The long answer: > >OpenBSD requires EFI (booti/bootz/bootm only support booting Linux >kernels in various forms) but also relies on a proper device tree >being provided to its EFI bootloader. While we have made significant >progress in having U-Boot provide a fully synched up device tree for >most of the SoCs that OpenBSD supports, we're not quite there yet, so >some people rely on U-Boot loading (and tweaking) an updated >device-tree from the EFI System Partition. > >Our bootloader does have a "mach dtb" command to load a device tree >from the OpenBSD root partition, but this is considered to be a >debugging command and can't load a device tree from the EFI System >Partition. Loading a device tree this way means the device tree does >not get tweaked by U-Boot, which is problematic on some SoCs/boards. > >We now have the EFI_DT_FIXUP_PROTOCOL, but our bootloader doesn't use >this yet. If the consensus is that distroboot-with-efiboot needs to >deprecated I can work on supporting that protocol in our bootloader. >But a release of OpenBSD with support for that will not be available >until november 2023. Ubuntu has patched GRUB's devicetree command to call the protocol. > >Alternatively bootmgr could implement the device tree loading and >fixup. Or the bootstd stuff could do this before starting bootmgr. I >understand the concerns about loading device trees from disk when >secure boot is enabled. So maybe this should only be done when secure >boot is disabled. Currently a U-Boot boot option can define a kernel and an initrd to load. We could add the dtb location to the boot option in U-Boot. > >Also note that setting the BootOrder EFI variable from
Re: [PATCH] arm: dts: k3-j721e-sk-u-boot: Resync dts file and binding with Linux Kernel
Hi,
On Fri, Mar 31, 2023 at 12:09 PM Sinthu Raja
wrote:
>
> From: Sinthu Raja
>
> This resyncs the dts file of j721e-sk with the currently in-tree K3
> platforms. Of note are that the main-navss/mcu-navss nodes were renamed
> to main_navss / mcu_navss and so the u-boot.dtsi file needed to be
> updated to match.
>
> Also, disable the HBMC which is not supported in the j721e-sk board.
>
> Fixes: 58d61fb5a7 ("arm: dts: k3-j721e-sk: Add initial A72 specific dts
> support")
> Signed-off-by: Sinthu Raja
> ---
> arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> index 0949caa129..31f979f3bb 100644
> --- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> @@ -33,7 +33,7 @@
> &cbass_main{
> bootph-pre-ram;
>
> - main_navss {
> + main_navss: bus@3000 {
> bootph-pre-ram;
> };
> };
> @@ -49,7 +49,7 @@
> bootph-pre-ram;
> };
>
> - mcu-navss {
> + mcu_navss: bus@2838 {
> bootph-pre-ram;
>
> ringacc@2b80 {
> @@ -237,6 +237,10 @@
> bootph-pre-ram;
> };
>
> +&hbmc {
> + status = "disabled";
> +};
> +
Please review and let me know your comments.
> &ospi0 {
> bootph-pre-ram;
>
> --
> 2.36.1
>
--
With Regards
Sinthu Raja
[PATCH 1/1] pytest: Use --lazy with umount
Sometimes when doing tests on real hardware we sometimes run in to the
case where some of these mounts haven't been fully flushed. Using the
--lazy option with umount will allow us to continue while letting the OS
handle flushing the data out still.
Signed-off-by: Tom Rini
---
test/py/tests/test_ut.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py
index e8c8a6d6bd59..0b45863b4385 100644
--- a/test/py/tests/test_ut.py
+++ b/test/py/tests/test_ut.py
@@ -213,7 +213,7 @@ booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
str(exc))
finally:
if mounted:
-u_boot_utils.run_and_log(cons, 'sudo umount %s' % mnt)
+u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt)
if loop:
u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop)
@@ -274,7 +274,7 @@ label Fedora-Workstation-armhfp-31-1.9
(5.3.7-301.fc31.armv7hl)
str(exc))
finally:
if mounted:
-u_boot_utils.run_and_log(cons, 'sudo umount %s' % mnt)
+u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt)
if loop:
u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop)
--
2.34.1
[GIT PULL] please pull fsl-qoriq-2023-4-6 for 2023.07-rc1
Hi Tom, Please pull fsl-qoriq-2023-4-6 --- convert NXP LS1028A RDB and QDS to DM_SERIAL enable DM_SERIAL for ls1088a sync serial nodes with linux for lx2160a/ls1088a --- CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/15890 Thanks, Peng. The following changes since commit 02f8486b9f9fd27c1ad7fdda78c3c892431285a9: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-04-03 20:49:03 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git tags/fsl-qoriq-2023-4-6 for you to fetch changes up to 8ac04e9062fc65bb09754cefefc096d554c6881c: board: freescale: lx2160a: remove the PL01X device instantiation (2023-04-04 17:31:47 +0800) Ioana Ciornei (10): arch: arm: dts: fsl-ls1088a.dtsi: add an 'soc' node arch: arm: dts: fsl-ls1088a.dtsi: move the serial nodes under soc arch: arm: dts: fsl-ls1088a.dtsi: sync serial nodes with Linux arch: arm: dts: fsl-ls1088a.dtsi: tag serial nodes with bootph-all configs: ls1088a: enable DM_SERIAL arch: arm: dts: fsl-lx2160a.dtsi: add an 'soc' node arch: arm: dts: fsl-lx2160a.dtsi: move the serial nodes under soc arch: arm: dts: fsl-lx2160a.dtsi: sync serial nodes with Linux arch: arm: dts: fsl-lx2160a.dtsi: tag serial nodes with bootph-all board: freescale: lx2160a: remove the PL01X device instantiation Vladimir Oltean (1): configs: convert NXP LS1028A RDB and QDS to DM_SERIAL arch/arm/dts/fsl-ls1088a-qds.dtsi| 8 arch/arm/dts/fsl-ls1088a-rdb.dts | 8 arch/arm/dts/fsl-ls1088a-ten64.dts | 6 -- arch/arm/dts/fsl-ls1088a.dtsi| 61 - arch/arm/dts/fsl-lx2160a-qds.dtsi| 11 ++- arch/arm/dts/fsl-lx2160a-rdb.dts | 11 ++- arch/arm/dts/fsl-lx2160a.dtsi| 74 +- board/freescale/lx2160a/lx2160a.c| 34 -- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 3 ++- configs/ls1028aqds_tfa_defconfig | 3 ++- configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 3 ++- configs/ls1028ardb_tfa_defconfig | 3 ++- configs/ls1088aqds_tfa_defconfig | 4 +++- configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 4 +++- configs/ls1088ardb_tfa_defconfig | 4 +++- 15 files changed, 146 insertions(+), 91 deletions(-)
Re: [PATCH] riscv: Correct a comment in io.h
> From: Bin Meng > Sent: Monday, April 03, 2023 11:38 AM > To: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > Cc: u-boot@lists.denx.de > Subject: [PATCH] riscv: Correct a comment in io.h > > Replace NDS32 with RISC-V in the comments. > > Signed-off-by: Bin Meng > --- > > arch/riscv/include/asm/io.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h index > 220266e76f..b16e6dfa37 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -180,7 +180,7 @@ static inline u64 readq(const volatile void __iomem *addr) > * IO port access primitives > * - > * > - * The NDS32 doesn't have special IO access instructions just like ARM; > + * The RISC-V doesn't have special IO access instructions just like > + ARM; > * all IO is memory mapped. > * Note that these are defined to perform little endian accesses > * only. Their primary purpose is to access PCI and ISA peripherals. Reviewed-by: Rick Chen
Re: imx7d-sabresd: Cannot access the SD card
On Wed, Apr 5, 2023 at 10:21 PM Fabio Estevam wrote: > > Hi Peng and Ye Li, > > The following SDHC error is seen when running top of tree U-Boot on an > imx7d-sabresd board: > > U-Boot 2023.04-00652-g487e42f7bc5e (Apr 05 2023 - 22:14:21 -0300) > > CPU: Freescale i.MX7D rev1.0 1000 MHz (running at 792 MHz) > CPU: Commercial temperature grade (0C to 95C) at 35C > Reset cause: POR > Model: Freescale i.MX7 SabreSD Board > Board: i.MX7D SABRESD in non-secure mode > DRAM: 1 GiB > Core: 100 devices, 19 uclasses, devicetree: separate > PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x10 > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... Card did not respond to voltage select! : -110 > *** Warning - No block device, using default environment Reverting the commit below makes the SD card work again: commit 1a7904fdfa7d1974410e9dc9b9bfe8aad7fb1311 Author: Adam Ford Date: Wed Jan 12 07:53:56 2022 -0600 mmc: fsl_esdhc_imx: Use esdhc_soc_data flags to set host caps The Linux driver automatically can detect and enable UHS, HS200, HS400 and HS400_ES automatically without extra flags being placed into the device tree. Right now, for U-Boot to use UHS, HS200 or HS400, the extra flags are needed in the device tree. Instead, go through the esdhc_soc_data flags and enable the host caps where applicable to automatically enable higher speeds. Suggested-by: Fabio Estevam Signed-off-by: Adam Ford Any suggestions?
imx7d-sabresd: Cannot access the SD card
Hi Peng and Ye Li, The following SDHC error is seen when running top of tree U-Boot on an imx7d-sabresd board: U-Boot 2023.04-00652-g487e42f7bc5e (Apr 05 2023 - 22:14:21 -0300) CPU: Freescale i.MX7D rev1.0 1000 MHz (running at 792 MHz) CPU: Commercial temperature grade (0C to 95C) at 35C Reset cause: POR Model: Freescale i.MX7 SabreSD Board Board: i.MX7D SABRESD in non-secure mode DRAM: 1 GiB Core: 100 devices, 19 uclasses, devicetree: separate PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Card did not respond to voltage select! : -110 *** Warning - No block device, using default environment In:serial Out: serial Err: serial SEC0: RNG instantiated Net: eth0: ethernet@30be Hit any key to stop autoboot: 0 => saveenv Saving Environment to MMC... Card did not respond to voltage select! : -110 No block device Failed (1) I cannot use the SD card anymore. If I do the following change: diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig index 26e68d30d267..4c81d1f167e9 100644 --- a/configs/mx7dsabresd_defconfig +++ b/configs/mx7dsabresd_defconfig @@ -49,9 +49,6 @@ CONFIG_DM_74X164=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MXC=y CONFIG_SUPPORT_EMMC_BOOT=y -CONFIG_MMC_IO_VOLTAGE=y -CONFIG_MMC_UHS_SUPPORT=y -CONFIG_MMC_HS200_SUPPORT=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y CONFIG_PHY_BROADCOM=y Then the SD card works again. Any ideas on how this can be properly fixed? Thanks
Re: [PATCH 7/9] usb: gadget: f_mass_storage: Rework do_request_sense slightly
On 4/6/23 01:48, Tom Rini wrote: When building with clang, it notes that sdinfo may be unused uninitialized in some cases. This appears to be true from reading the code, and we can simply set the variable to zero to start with and be as correct as before. Signed-off-by: Tom Rini --- I'm honestly not sure why gcc isn't complaining here as this seems to be a real issue. It seems this also isn't the first issue where gcc isn't complaining and it should be complaining. IIRC there was one more case in spl_mmc.c too . Reviewed-by: Marek Vasut
Re: [BUG] issues with new bootflow, uefi and virtio
Hi Vincent, On Thu, Apr 6, 2023, at 1:04 AM, Vincent Stehlé wrote: > Hi, > > I am hitting an issue with the new bootflow when booting with UEFI from a > virtio device on Qemu Arm. > > It seems the device number computation in efiload_read_file() does not work > in the general virtio case, where it will pick the virtio device number > instead of the block device index. On Qemu arm virt machine, many virtio > mmio devices are provisioned in the memory map and no assumption can be > made on the number of the actual virtio device in use in the general case. > > This is an extract of the output of `dm tree' on this platform, focused on > the virtio device from which I would like to boot: > > virtio31 [ + ] virtio-mmio |-- virtio_mmio@a003e00 > blk0 [ + ] virtio-blk | |-- virtio-blk#31 > partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1 > partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2 > bootdev2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev > > In this extract the actual virtio device number is 31, as will be picked by > efiload_read_file(), but the desired block device index is zero, as would > be used with e.g. `ls virtio 0'. I came across the exact same issue a few days ago. Below is a patch which I believe fixes the problem, by using the devnum of blk uclass (virtio 0) instead of the sequence number of the parent udevice (e.g virtio-blk#35). Separately, the devnum was previously being parsed as a hex which meant "virtio_blk#35" was actually being parsed as "virtio_blk#23". That confused me for a while. If the patch looks good I can re-post it directly to the ML. I'm not 100% sure that I got it right. In case the email mangles the patch, you can grab a diff here as well: https://gitlab.com/traversetech/ls1088firmware/u-boot/-/commit/5ed3315b4a297f143fb84f44117b5b31e5617af5 - Matt >From 5ed3315b4a297f143fb84f44117b5b31e5617af5 Mon Sep 17 00:00:00 2001 From: Mathew McBride Date: Wed, 5 Apr 2023 02:44:48 + Subject: [PATCH] bootstd: use blk uclass device numbers to set efi bootdev When loading a file from a block device, efiload_read_file was using the seq_num of the device (e.g "35" of virtio_blk#35) instead of the block device id (e.g what you get from running the corresponding device scan command, like "virtio 0") This cause EFI booting from these devices to fail as an invalid device number is passed to blk_get_device_part_str: Scanning bootdev 'virtio-blk#35.bootdev': distro_efi_read_bootflow_file start (efi,fname=) distro_efi_read_bootflow_file start (efi,fname=) setting bootdev virtio, 35, efi/boot/bootaa64.efi, beef9a40, 170800 efi_dp_from_name calling blk_get_device_part_str dev=virtio devnr=35 path=efi/boot/bootaa64.efi blk_get_device_part_str (virtio,35) blk_get_device_by_str (virtio, 35) ** Bad device specification virtio 35 ** Using default device tree: dtb/qemu-arm.dtb No device tree available 0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi ** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi blk_get_device_part_str (virtio,0:1) blk_get_device_by_str (virtio, 0) No UEFI binary known at beef9a40 (image buf=beef9a40,addr=) Boot failed (err=-22) Signed-off-by: Mathew McBride --- boot/bootmeth_efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 6a97ac02ff..bc106aa736 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -117,7 +117,7 @@ static int efiload_read_file(struct blk_desc *desc, struct bootflow *bflow) * this can go away. */ media_dev = dev_get_parent(bflow->dev); - snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev)); + snprintf(devnum_str, sizeof(devnum_str), "%d", desc->devnum); strlcpy(dirname, bflow->fname, sizeof(dirname)); last_slash = strrchr(dirname, '/'); -- 2.30.1
[PATCH] ARM: configs: imx8mm: Sync i.MX8M Mini Toradex Verdin and Menlo board configs
Synchronize the i.MX8M Mini Toradex Verdin based Menlo board config with i.MX8M Mini Toradex Verdin carrier board. This enables DM MDIO, eMMC HS modes, TMU for thermal monitoring, LTO and multiple commands (hexdump, pmic, read, time). Signed-off-by: Marek Vasut --- Cc: Marek Vasut Cc: Olaf Mandel Cc: Peng Fan Cc: Stefano Babic --- configs/imx8mm-mx8menlo_defconfig | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/configs/imx8mm-mx8menlo_defconfig b/configs/imx8mm-mx8menlo_defconfig index 0a374aab06d..0bd852a77b9 100644 --- a/configs/imx8mm-mx8menlo_defconfig +++ b/configs/imx8mm-mx8menlo_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx8mm-mx8menlo" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_MX8MENLO=y CONFIG_SYS_PROMPT="Verdin iMX8MM # " +CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y @@ -24,6 +25,7 @@ CONFIG_ENV_OFFSET_REDUND=0xDE00 CONFIG_SYS_LOAD_ADDR=0x4048 CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 +CONFIG_LTO=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_FIT=y CONFIG_FIT_EXTERNAL_OFFSET=0x3000 @@ -61,18 +63,23 @@ CONFIG_SYS_PBSIZE=2081 CONFIG_CMD_ASKENV=y # CONFIG_CMD_EXPORTENV is not set # CONFIG_CMD_CRC32 is not set +CONFIG_CMD_MD5SUM=y +CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_CLK=y CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_READ=y CONFIG_CMD_USB=y CONFIG_CMD_USB_SDP=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_BOOTCOUNT=y CONFIG_CMD_CACHE=y +CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y +CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y CONFIG_CMD_BTRFS=y CONFIG_CMD_EXT4_WRITE=y @@ -87,7 +94,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_PART=1 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_USE_ETHPRIME=y -CONFIG_ETHPRIME="FEC" +CONFIG_ETHPRIME="eth0" CONFIG_VERSION_VARIABLE=y CONFIG_IP_DEFRAG=y CONFIG_TFTP_BLOCKSIZE=4096 @@ -104,11 +111,19 @@ CONFIG_DM_I2C=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_SPL_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_SPL_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y +CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_DM_MDIO=y CONFIG_FEC_MXC=y CONFIG_MII=y CONFIG_SPL_PHY=y @@ -131,6 +146,7 @@ CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y +CONFIG_IMX_TMU=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_MXC_USB_OTG_HACTIVE=y @@ -143,4 +159,4 @@ CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x4040 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y -CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_HEXDUMP=y -- 2.39.2
[PATCH 8/9] clang: efi payload: Silence unaligned access warning
When building with clang we see this warning:
field guid within 'struct efi_hii_keyboard_layout' is less aligned than
'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
packed, which can lead to unaligned accesses [-Wunaligned-access]
Which is correct and true as EFI payloads are by specification allowed
to do unaligned access. And so to silence the warning here and only
here, we make use of #pragma to push/pop turning off the warning.
Signed-off-by: Tom Rini
---
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
include/efi_api.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index dc6e5ce236c9..f3bcbf593bea 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1168,9 +1168,21 @@ struct efi_key_descriptor {
u16 affected_attribute;
} __packed;
+/* The warniing:
+ * field guid within 'struct efi_hii_keyboard_layout' is less aligned than
'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being
packed, which can lead to unaligned accesses [-Wunaligned-access]
+ * is intentional due to EFI requiring unaligned access to be supported.
+ */
struct efi_hii_keyboard_layout {
u16 layout_length;
+#ifdef CONFIG_CC_IS_CLANG
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wunaligned-access"
+#endif
efi_guid_t guid;
+#ifdef CONFIG_CC_IS_CLANG
+#pragma clang diagnostic pop
+#endif
+
u32 layout_descriptor_string_offset;
u8 descriptor_count;
struct efi_key_descriptor descriptors[];
--
2.34.1
[PATCH 9/9] doc: clang: Update and correct support notes
At this point, clang can be used on both 32bit and 64bit targets without issue. Signed-off-by: Tom Rini --- doc/build/clang.rst | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/doc/build/clang.rst b/doc/build/clang.rst index 1d35616eb5ef..222487032ce0 100644 --- a/doc/build/clang.rst +++ b/doc/build/clang.rst @@ -11,14 +11,6 @@ The ARM backend can be instructed not to use the r9 and x18 registers using supported inline assembly is needed to get and set the r9 or x18 value. This leads to larger code then strictly necessary, but at least works. -**NOTE:** target compilation only work for _some_ ARM boards at the moment. -Also AArch64 is not supported currently due to a lack of private libgcc -support. Boards which reassign gd in c will also fail to compile, but there is -in no strict reason to do so in the ARM world, since crt0.S takes care of this. -These assignments can be avoided by changing the init calls but this is not in -mainline yet. - - Debian based @@ -28,14 +20,14 @@ Required packages can be installed via apt, e.g. sudo apt-get install clang -Note that we still use binutils for some tools so we must continue to set -CROSS_COMPILE. To compile U-Boot with Clang on Linux without IAS use e.g. +Note that we make use of the CROSS_COMPILE variable to determine what to tell +clang to use as the build target. +To compile U-Boot with Clang on Linux without IAS use e.g. .. code-block:: bash make HOSTCC=clang rpi_2_defconfig -make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ - CC="clang -target arm-linux-gnueabi" -j8 +make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- CC=clang -j8 It can also be used to compile sandbox: -- 2.34.1
[PATCH 7/9] usb: gadget: f_mass_storage: Rework do_request_sense slightly
When building with clang, it notes that sdinfo may be unused
uninitialized in some cases. This appears to be true from reading the
code, and we can simply set the variable to zero to start with and be as
correct as before.
Signed-off-by: Tom Rini
---
I'm honestly not sure why gcc isn't complaining here as this seems to be
a real issue.
Cc: Lukasz Majewski
Cc: Marek Vasut
---
drivers/usb/gadget/f_mass_storage.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 45f0504b6e8a..f46829eb7adb 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -1117,7 +1117,7 @@ static int do_request_sense(struct fsg_common *common,
struct fsg_buffhd *bh)
{
struct fsg_lun *curlun = &common->luns[common->lun];
u8 *buf = (u8 *) bh->buf;
- u32 sd, sdinfo;
+ u32 sd, sdinfo = 0;
int valid;
/*
@@ -1145,7 +1145,6 @@ static int do_request_sense(struct fsg_common *common,
struct fsg_buffhd *bh)
if (!curlun) { /* Unsupported LUNs are okay */
common->bad_lun_okay = 1;
sd = SS_LOGICAL_UNIT_NOT_SUPPORTED;
- sdinfo = 0;
valid = 0;
} else {
sd = curlun->sense_data;
--
2.34.1
[PATCH 6/9] boot/image-board.c: Silence warning in select_ramdisk
When building with clang we get a warning that rdaddr could be
uninitialized in one case. While this cannot functionally happen, we can
easily silence the warning.
Signed-off-by: Tom Rini
---
boot/image-board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/image-board.c b/boot/image-board.c
index c602832249e3..d500da1b4b91 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -328,7 +328,7 @@ static int select_ramdisk(struct bootm_headers *images,
const char *select, u8 a
bool done_select = !select;
bool done = false;
int rd_noffset;
- ulong rd_addr;
+ ulong rd_addr = 0;
char *buf;
if (CONFIG_IS_ENABLED(FIT)) {
--
2.34.1
[PATCH 5/9] armv7: Use isb/dsb directly in start.S
Toolchains which do not directly support using "isb" and "dsb" directly are no longer functionally supported in U-Boot. Furthermore, clang has for a long time warned about using the alternate form that we were. Update the code. Signed-off-by: Tom Rini --- arch/arm/cpu/armv7/start.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 7d7aac021e22..69e281b086af 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -134,8 +134,8 @@ ENTRY(c_runtime_cpu_setup) */ #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF) mcr p15, 0, r0, c7, c5, 0 @ invalidate icache - mcr p15, 0, r0, c7, c10, 4 @ DSB - mcr p15, 0, r0, c7, c5, 4 @ ISB + dsb + isb #endif bx lr @@ -188,8 +188,8 @@ ENTRY(cpu_init_cp15) mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs mcr p15, 0, r0, c7, c5, 0 @ invalidate icache mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array - mcr p15, 0, r0, c7, c10, 4 @ DSB - mcr p15, 0, r0, c7, c5, 4 @ ISB + dsb + isb /* * disable MMU stuff and caches -- 2.34.1
[PATCH 4/9] arm: Centralize fixed register logic
When building for ARM64, we need to pass -ffixed-x18 and otherwise pass -ffixed-r9. Rather than having this logic in two places, we can do this once in arch/arm/config.mk. Further, while gcc will ignore being passed both -ffixed-r9 and -ffixed-x18 and simply use -ffixed-x18, clang will note that -ffixed-r9 is not used. Remove this duplication to also remove the warning. Signed-off-by: Tom Rini --- arch/arm/config.mk | 10 -- arch/arm/cpu/armv8/config.mk | 1 - 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index bf781f102620..5530d02b66c4 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -3,7 +3,13 @@ # (C) Copyright 2000-2002 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections \ +ifeq ($(CONFIG_ARM64),y) +FIXED_REG := -ffixed-x18 +else +FIXED_REG := -ffixed-r9 +endif + +CFLAGS_NON_EFI := -fno-pic $(FIXED_REG) -ffunction-sections -fdata-sections \ -fstack-protector-strong CFLAGS_EFI := -fpic -fshort-wchar @@ -15,7 +21,7 @@ ifneq ($(LTO_ENABLE),y) PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections endif -PLATFORM_RELFLAGS += -fno-common -ffixed-r9 +PLATFORM_RELFLAGS += -fno-common $(FIXED_REG) PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ $(call cc-option,-mgeneral-regs-only) \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk index ca06ed3d4f92..4d74b2a533e0 100644 --- a/arch/arm/cpu/armv8/config.mk +++ b/arch/arm/cpu/armv8/config.mk @@ -2,7 +2,6 @@ # # (C) Copyright 2002 # Gary Jennejohn, DENX Software Engineering, -PLATFORM_RELFLAGS += -fno-common -ffixed-x18 PLATFORM_RELFLAGS += $(call cc-option,-mbranch-protection=none) PF_NO_UNALIGNED := $(call cc-option, -mstrict-align) -- 2.34.1
[PATCH 3/9] clang: Don't look for libgcc
In the case of using clang to build, and having not already enabled the private libgcc, do not look for it, as it will not be found nor required. Signed-off-by: Tom Rini --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 97a84ae3131e..b5063446ff85 100644 --- a/Makefile +++ b/Makefile @@ -894,8 +894,10 @@ u-boot-main := $(libs-y) ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a else +ifndef CONFIG_CC_IS_CLANG PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc endif +endif PLATFORM_LIBS += $(PLATFORM_LIBGCC) ifdef CONFIG_CC_COVERAGE -- 2.34.1
[PATCH 2/9] clang: Add $(CLANG_TARGET) to LDPPFLAGS
When we invoke $(CPP) to make u-boot.lds we have LDPPFLAGS available to set other required flags here. As this file is for the target and not the host, we must ensure that CPP knows what the target architecture is. For this, pass in $(CLANG_TARGET). Signed-off-by: Tom Rini --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 5083beae359a..97a84ae3131e 100644 --- a/Makefile +++ b/Makefile @@ -437,6 +437,7 @@ KBUILD_LDFLAGS := ifeq ($(cc-name),clang) ifneq ($(CROSS_COMPILE),) CLANG_TARGET := --target=$(notdir $(CROSS_COMPILE:%-=%)) +LDPPFLAGS += $(CLANG_TARGET) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD))) CLANG_PREFIX := --prefix=$(GCC_TOOLCHAIN_DIR) GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) -- 2.34.1
[PATCH 1/9] arm: Only support ARM64_CRC32 when using GCC
Today, only gcc has __builtin_aarch64_crc32b (clang-16 does not, for example). Make this option depend on CC_IS_GCC. Signed-off-by: Tom Rini --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f0118e225419..d7e657806051 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -12,7 +12,7 @@ config ARM64 config ARM64_CRC32 bool "Enable support for CRC32 instruction" - depends on ARM64 + depends on ARM64 && CC_IS_GCC default y help ARMv8 implements dedicated crc32 instruction for crc32 calculation. -- 2.34.1
[PATCH 0/9] Update clang support for ARM
Hey all, I decided to take a look again at what's needed to build and boot ARM platforms when building with clang. The good news is that this generally works now. Some size-constrained platforms don't build right now but I was able to test a reasonable part of my lab. This series also depends on: https://patchwork.ozlabs.org/project/uboot/patch/20200604203515.12971-1-tr...@konsulko.com/ to fix the warning there. At this point LTO + clang requires a bit more work, and to use llvm-ld. As the platform I was trying was still too large to link even with this, I've set that investigation aside for now. I've boot tested clang-16 on Pi 3 (32bit, 64bit, arm64) and libretech-cc, and I'll be testing pine64_plus soon along with maybe mx6cuboxi and seeing what the failures are on am65x_evm / j721e_evm (these platforms require a bit more scripting on my part to make build and test clean). -- Tom
Re: [PATCH v2 0/9] blk: blkmap: Composable virtual block devices
On Thu, 16 Feb 2023 16:33:46 +0100, Tobias Waldekranz wrote: > Block maps are a way of looking at various sources of data through the > lens of a regular block device. It lets you treat devices that are not > block devices, like RAM, as if they were. It also lets you export a > slice of an existing block device, which does not have to correspond to > a partition boundary, as a new block device. > > This is primarily useful because U-Boot's filesystem drivers only > operate on block devices, so a block map lets you access filesystems > wherever they might be located. > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH] configs: am62x: enable secure device configs by default
Enable the CONFIG_TI_SECURE_DEVICE by default Non-HS devices will continue to boot due to runtime device type detection. TI's security enforcing SoCs will authenticate each binary it loads by comparing it's signature with keys etched into the SoC during the boot up process. The am62x family of SoCs by default will have some level of security enforcement checking. To keep things as simple as possible, enable the CONFIG_TI_SECURE_DEVICE options by default so all levels of secure SoCs will work out of the box Signed-off-by: Praneeth Bajjuri Signed-off-by: Kamlesh Gurudasani Signed-off-by: Bryan Brattlof --- configs/am62x_evm_a53_defconfig | 1 + configs/am62x_evm_r5_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index cc9c8eab3e..fc76d88727 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig index 44a9130d99..cab8c820f9 100644 --- a/configs/am62x_evm_r5_defconfig +++ b/configs/am62x_evm_r5_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_LEN=0x0800 CONFIG_SYS_MALLOC_F_LEN=0x9000 CONFIG_SPL_LIBCOMMON_SUPPORT=y -- 2.17.1
Re: [PATCH v2 1/1] RFC: Move Odroid-C2 to use binman to produce the image
> From: Simon Glass > Date: Thu, 6 Apr 2023 06:38:19 +1200 > > Hi Neil, > > On Mon, 3 Apr 2023 at 19:31, Neil Armstrong wrote: > > > > Hi Simon ! > > > > On 01/04/2023 20:54, Simon Glass wrote: > > > This shows how binman can be used to replace the long and complicated > > > instructions with an automated build. It is still complicated to read > > > but users don't have to worry about the details. > > > > > > It needs some tidying up and only supports Odroid-C2 at present. > > > > Like the v1, the work is really nice, but the dependency on vendor > > binary-only tools doesn't make feel confident about merging this. > > So long as we can download it from somewhere, that is OK, or at least > better than nothing. Is there a standard download location for the > tools? The tools are Linux x86-64 only, so... > > We have open source implementation for all boards, but still dependeing on > > tools we must manually build isn't optimal. > > > > What would be optimal would be to re-implement those tools into python > > libraries and merge them into the u-boot tree then use them from binman. > > Or C, perhaps? Then binman can call the tools. ...this would be preferable. > > But this could be merged as first step, them the python libaray could be > > modified to support the binary tools & a probable python re-implementation. > > Yes I think it would good to get this in, even if it only supports a > few boards. It is easy to add more, when possible. > > Regards, > SImon >
Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
> Date: Wed, 5 Apr 2023 10:47:59 -0400 > From: Tom Rini > > On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 4 Apr 2023, 02:17 Tom Rini, wrote: > > > > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote: > > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini wrote: > > > > > > > > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: > > > > > > > > > > > > > The current EFI implementation has a strange quirk where it > > > > > > > watches > > > > > > > loaded files and uses the last-loaded file to determine the device > > > that > > > > > > > is being booted from. > > > > > > > > > > > > > > This is confusing with bootstd, where multiple options may exist. > > > Even > > > > > > > loading a device tree will cause it to go wrong. There is no API > > > for > > > > > > > passing this information, since the only entry into booting an EFI > > > image > > > > > > > is the 'bootefi' command. > > > > > > > > > > > > > > To work around this, call efi_set_bootdev() for EFI images, if > > > possible, > > > > > > > just before booting. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > Shouldn't this all be a simple wrapper around the EFI Standard > > > > > > BootDeviceOrder or whatever that's called? > > > > > > > > > > I think you are referring to boot manager, which isn't used here. This > > > > > is replicating the existing distroboot functionality in standard boot. > > > > > > > > The distroboot functionality *was* trying to behave like the EFI spec > > > > expects the bootmanager to behave. Unfortunately I haven't had time to > > > > review the distroboot patches closely, but back when this started, my > > > point > > > > was that EFI doesn't need anything. Whenever the EFI flow is added > > > bootstd > > > > should 'just' call the bootmanager. > > > > > > Yes, this. We're trying make things cleaner overall, so the EFI portion > > > of bootstd distro boot should just be "call EFI bootmanager" as that has > > > a well defined standard way to specify what devices to try in what > > > order. > > > > > > > We already call bootmgr in standard boot, if it is enabled. > > > > But I am not sure how widely that is used... > > > > This patch is about corner cases in the distro scripts. If we are to turn > > these down we do need to try to do the same thing. > > We probably need some distro people to chime in about what they're doing > / expecting at this point in time? I would have sworn that the long term > part of EFI "distro boot" would be using bootmgr since that's the > standards based way to set boot order. And if you don't have a device > tree in U-Boot, and want the distribution one, aren't you then using > something like grub which has a "dtb" keyword to handle that on its own? > That's not saying that "distro boot" doesn't need to load the device > tree, for when it's then calling booti/bootz/bootm, but not for the EFI > case these days? Or no? The short anserwer is no. The long answer: OpenBSD requires EFI (booti/bootz/bootm only support booting Linux kernels in various forms) but also relies on a proper device tree being provided to its EFI bootloader. While we have made significant progress in having U-Boot provide a fully synched up device tree for most of the SoCs that OpenBSD supports, we're not quite there yet, so some people rely on U-Boot loading (and tweaking) an updated device-tree from the EFI System Partition. Our bootloader does have a "mach dtb" command to load a device tree from the OpenBSD root partition, but this is considered to be a debugging command and can't load a device tree from the EFI System Partition. Loading a device tree this way means the device tree does not get tweaked by U-Boot, which is problematic on some SoCs/boards. We now have the EFI_DT_FIXUP_PROTOCOL, but our bootloader doesn't use this yet. If the consensus is that distroboot-with-efiboot needs to deprecated I can work on supporting that protocol in our bootloader. But a release of OpenBSD with support for that will not be available until november 2023. Alternatively bootmgr could implement the device tree loading and fixup. Or the bootstd stuff could do this before starting bootmgr. I understand the concerns about loading device trees from disk when secure boot is enabled. So maybe this should only be done when secure boot is disabled. Also note that setting the BootOrder EFI variable from inside the OS isn't supported by most (all?) boards currently supported by U-Boot. So a convenient way to set the BootOrder EFI variable from within U-Boot is needed. Cheers, Mark P.S. Does grub support the EFI_DT_FIXUP_PROTOCOL these days? If not (or if your Linux distro still ships with an older version of grub) you'll face the same issue as OpenBSD regarding the lack of fixups for loaded devictrees.
[RFC PATCH] sunxi: arm64: boot0.h: runtime check for RVBAR address
Some SoCs of the H616 family use a die variant, that puts some CPU power
and reset control registers at a different address. There are examples
of two instances of the same board, using different die revisions of the
otherwise same H313 SoC. We need to write to a register in that block
*very* early in the SPL boot, to switch the core to AArch64.
Since the devices are otherwise indistinguishable, let the SPL code read
that die variant and use the respective RVBAR address based on that.
That is a bit tricky, since we need to do that in hand-coded AArch32
machine language, shared by all 64-bit SoCs. To avoid build dependencies
in this mess, we always provide two addresses to choose from, and just
give identical values for all other SoCs. This allows the same code to
run on all 64-bit SoCs, and controls this switch behaviour purely from
Kconfig.
Signed-off-by: Andre Przywara
---
Hi,
this patch goes on top of the two patches I sent earlier, that
introduce CONFIG_SUNXI_RVBAR_ADDRESS. I don't have a device with that
die variant, so just roughly tested this by inverting the ldrne and
swapping the addresses.
Please let me know if you have such a device and can confirm that this
code works on the original and alternative die alike.
Cheers,
Andre
arch/arm/include/asm/arch-sunxi/boot0.h | 14 ++
arch/arm/mach-sunxi/Kconfig | 17 -
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
b/arch/arm/include/asm/arch-sunxi/boot0.h
index 1a396f78488..b27df3b9b5e 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++ b/arch/arm/include/asm/arch-sunxi/boot0.h
@@ -20,8 +20,8 @@
b reset
.space 0x7c
- .word 0xe28f0058 // add r0, pc, #88
- .word 0xe59f1054 // ldr r1, [pc, #84]
+ .word 0xe28f0070 // add r0, pc, #112 // @(fel_stash - .)
+ .word 0xe59f106c // ldr r1, [pc, #108] // fel_stash - .
.word 0xe081 // add r0, r0, r1
.word 0xe580d000 // str sp, [r0]
.word 0xe580e004 // str lr, [r0, #4]
@@ -32,8 +32,12 @@
.word 0xee1cef10 // mrc 15, 0, lr, cr12, cr0, {0}
.word 0xe580e010 // str lr, [r0, #16]
- .word 0xe59f1024 // ldr r1, [pc, #36] ; 0x17a0
- .word 0xe59f0024 // ldr r0, [pc, #36] ; CONFIG_*_TEXT_BASE
+ .word 0xe59f1034 // ldr r1, [pc, #52] ; RVBAR_ADDRESS
+ .word 0xe59f0034 // ldr r0, [pc, #52] ; SUNXI_SRAMC_BASE
+ .word 0xe5900024 // ldr r0, [r0, #36] ; SRAM_VER_REG
+ .word 0xe21000ff // andsr0, r0, #255; 0xff
+ .word 0x159f102c // ldrne r1, [pc, #44] ; RVBAR_ALTERNATIVE
+ .word 0xe59f002c // ldr r0, [pc, #44] ; CONFIG_*TEXT_BASE
.word 0xe581 // str r0, [r1]
.word 0xf57ff04f // dsb sy
.word 0xf57ff06f // isb sy
@@ -45,6 +49,8 @@
.word 0xeafd // b @wfi
.word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR mapping addr
+ .word SUNXI_SRAMC_BASE
+ .word CONFIG_SUNXI_RVBAR_ALTERNATIVE // address for die variant
#ifdef CONFIG_SPL_BUILD
.word CONFIG_SPL_TEXT_BASE
#else
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 0527b3863a7..be0910499bb 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -111,7 +111,7 @@ config SUNXI_SRAM_ADDRESS
SRAM to a different address.
config SUNXI_RVBAR_ADDRESS
- hex "RVBAR address"
+ hex
depends on ARM64
default 0x09010040 if SUN50I_GEN_H6
default 0x017000a0
@@ -122,6 +122,21 @@ config SUNXI_RVBAR_ADDRESS
entry point when switching to AArch64. This store is on different
addresses, depending on the SoC.
+config SUNXI_RVBAR_ALTERNATIVE
+ hex
+ depends on ARM64
+ default 0x8140 if MACH_SUN50I_H616
+ default 0x09010040 if SUN50I_GEN_H6
+ default 0x017000a0
+ ---help---
+ The H616 die exists is at least two variants, with one having the
+ RVBAR registers at a different address. If the SoC variant ID
+ (stored in SRAM_VER_REG[7:0]) is not 0, we need to use the
+ other address.
+ Set this alternative address to the same as the normal address
+ for all other SoCs, so the content of the SRAM_VER_REG becomes
+ irrelevant there, and we can use the same code.
+
config SUNXI_A64_TIMER_ERRATUM
bool
--
2.35.7
Re: [PATCH v2 08/12] arm: mach-k3: Add weak do_board_detect() to common file
On 4/5/23 3:09 PM, Christian Gmeiner wrote:
Hi
This matches how it was done for pre-K3 TI platforms and it allows
us to move the forward declaration out of sys_proto.h.
It also removes the need for K3_BOARD_DETECT as one is free to simply
override the weak function in their board files as needed.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 5 -
arch/arm/mach-k3/am642_init.c | 4 ++--
arch/arm/mach-k3/am654_init.c | 4 ++--
arch/arm/mach-k3/common.c | 10 ++
arch/arm/mach-k3/common.h | 2 ++
arch/arm/mach-k3/include/mach/sys_proto.h | 2 --
arch/arm/mach-k3/j721e_init.c | 8
board/ti/common/Kconfig | 1 -
8 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 7edbac26ccc..a8c3a593d57 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -187,11 +187,6 @@ config K3_X509_SWRV
help
SWRV for X509 certificate used for boot images
-config K3_BOARD_DETECT
- bool "Support for Board detection"
- help
- Support for board detection.
-
source "board/ti/am65x/Kconfig"
source "board/ti/am64x/Kconfig"
source "board/ti/am62x/Kconfig"
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index c7720cbaf35..9a34a3f9451 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -100,8 +100,8 @@ void do_dt_magic(void)
{
int ret, rescan;
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
Can we remove that comment as it is not true? I use this to
perform an fpga based board detection on a am642 platform.
That comment goes for every occurance of that line in this patch.
Sure, I'll drop it if this needs a v3, otherwise I can fix in a follow up.
Andrew
+ do_board_detect();
/*
* Board detection has been done.
diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c
index 12d74635cb0..5a9a780f521 100644
--- a/arch/arm/mach-k3/am654_init.c
+++ b/arch/arm/mach-k3/am654_init.c
@@ -245,8 +245,8 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
#if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 4f2e14c3105..115f5959734 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -636,3 +636,13 @@ int misc_init_r(void)
return 0;
}
+
+/**
+ * do_board_detect() - Detect board description
+ *
+ * Function to detect board description. This is expected to be
+ * overridden in the SoC family board file where desired.
+ */
+void __weak do_board_detect(void)
+{
+}
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index 531be0be54c..130f5021123 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -35,3 +35,5 @@ void mmr_unlock(phys_addr_t base, u32 partition);
bool is_rom_loaded_sysfw(struct rom_extended_boot_data *data);
enum k3_device_type get_device_type(void);
void ti_secure_image_post_process(void **p_image, size_t *p_size);
+struct ti_sci_handle *get_ti_sci_handle(void);
+void do_board_detect(void);
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 8cc75b636b5..939de0f79b4 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -10,8 +10,6 @@
void sdelay(unsigned long loops);
u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
u32 bound);
-struct ti_sci_handle *get_ti_sci_handle(void);
-int do_board_detect(void);
int fdt_disable_node(void *blob, char *node_path);
void k3_spl_init(void);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b5a69255f76..3fda2dfaa1b 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -160,8 +160,8 @@ void do_dt_magic(void)
int ret, rescan, mmc_dev = -1;
static struct mmc *mmc;
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
/*
* Board detection has been done.
@@ -287,8 +287,8 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+
Re: [PATCH v2 08/12] arm: mach-k3: Add weak do_board_detect() to common file
Hi
>
> This matches how it was done for pre-K3 TI platforms and it allows
> us to move the forward declaration out of sys_proto.h.
>
> It also removes the need for K3_BOARD_DETECT as one is free to simply
> override the weak function in their board files as needed.
>
> Signed-off-by: Andrew Davis
> ---
> arch/arm/mach-k3/Kconfig | 5 -
> arch/arm/mach-k3/am642_init.c | 4 ++--
> arch/arm/mach-k3/am654_init.c | 4 ++--
> arch/arm/mach-k3/common.c | 10 ++
> arch/arm/mach-k3/common.h | 2 ++
> arch/arm/mach-k3/include/mach/sys_proto.h | 2 --
> arch/arm/mach-k3/j721e_init.c | 8
> board/ti/common/Kconfig | 1 -
> 8 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index 7edbac26ccc..a8c3a593d57 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -187,11 +187,6 @@ config K3_X509_SWRV
> help
> SWRV for X509 certificate used for boot images
>
> -config K3_BOARD_DETECT
> - bool "Support for Board detection"
> - help
> - Support for board detection.
> -
> source "board/ti/am65x/Kconfig"
> source "board/ti/am64x/Kconfig"
> source "board/ti/am62x/Kconfig"
> diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
> index c7720cbaf35..9a34a3f9451 100644
> --- a/arch/arm/mach-k3/am642_init.c
> +++ b/arch/arm/mach-k3/am642_init.c
> @@ -100,8 +100,8 @@ void do_dt_magic(void)
> {
> int ret, rescan;
>
> - if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
> - do_board_detect();
> + /* Perform EEPROM-based board detection */
Can we remove that comment as it is not true? I use this to
perform an fpga based board detection on a am642 platform.
That comment goes for every occurance of that line in this patch.
> + do_board_detect();
>
> /*
> * Board detection has been done.
> diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c
> index 12d74635cb0..5a9a780f521 100644
> --- a/arch/arm/mach-k3/am654_init.c
> +++ b/arch/arm/mach-k3/am654_init.c
> @@ -245,8 +245,8 @@ void board_init_f(ulong dummy)
> /* Output System Firmware version info */
> k3_sysfw_print_ver();
>
> - if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
> - do_board_detect();
> + /* Perform EEPROM-based board detection */
> + do_board_detect();
>
> #if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
> ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index 4f2e14c3105..115f5959734 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -636,3 +636,13 @@ int misc_init_r(void)
>
> return 0;
> }
> +
> +/**
> + * do_board_detect() - Detect board description
> + *
> + * Function to detect board description. This is expected to be
> + * overridden in the SoC family board file where desired.
> + */
> +void __weak do_board_detect(void)
> +{
> +}
> diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
> index 531be0be54c..130f5021123 100644
> --- a/arch/arm/mach-k3/common.h
> +++ b/arch/arm/mach-k3/common.h
> @@ -35,3 +35,5 @@ void mmr_unlock(phys_addr_t base, u32 partition);
> bool is_rom_loaded_sysfw(struct rom_extended_boot_data *data);
> enum k3_device_type get_device_type(void);
> void ti_secure_image_post_process(void **p_image, size_t *p_size);
> +struct ti_sci_handle *get_ti_sci_handle(void);
> +void do_board_detect(void);
> diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
> b/arch/arm/mach-k3/include/mach/sys_proto.h
> index 8cc75b636b5..939de0f79b4 100644
> --- a/arch/arm/mach-k3/include/mach/sys_proto.h
> +++ b/arch/arm/mach-k3/include/mach/sys_proto.h
> @@ -10,8 +10,6 @@
> void sdelay(unsigned long loops);
> u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
> u32 bound);
> -struct ti_sci_handle *get_ti_sci_handle(void);
> -int do_board_detect(void);
> int fdt_disable_node(void *blob, char *node_path);
>
> void k3_spl_init(void);
> diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
> index b5a69255f76..3fda2dfaa1b 100644
> --- a/arch/arm/mach-k3/j721e_init.c
> +++ b/arch/arm/mach-k3/j721e_init.c
> @@ -160,8 +160,8 @@ void do_dt_magic(void)
> int ret, rescan, mmc_dev = -1;
> static struct mmc *mmc;
>
> - if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
> - do_board_detect();
> + /* Perform EEPROM-based board detection */
> + do_board_detect();
>
> /*
> * Board detection has been done.
> @@ -287,8 +287,8 @@ void board_init_f(ulong dummy)
> /* Output System Firmware version info */
> k3_sysfw_print_ver();
>
> - if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
> - do_boa
Re: [PATCH] nand: raw: octeontx: Make list static
Hi
On Wed, Apr 5, 2023 at 4:38 PM Bin Meng wrote:
>
> octeontx_bch_devices and octeontx_pci_nand_deferred_devices are only
> referenced in the files where they are defined. Make them static.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/mtd/nand/raw/octeontx_bch.c | 2 +-
> drivers/mtd/nand/raw/octeontx_nand.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/octeontx_bch.c
> b/drivers/mtd/nand/raw/octeontx_bch.c
> index fc16b77416..056a685782 100644
> --- a/drivers/mtd/nand/raw/octeontx_bch.c
> +++ b/drivers/mtd/nand/raw/octeontx_bch.c
> @@ -27,7 +27,7 @@
> #include
> #include "octeontx_bch.h"
>
> -LIST_HEAD(octeontx_bch_devices);
> +static LIST_HEAD(octeontx_bch_devices);
> static unsigned int num_vfs = BCH_NR_VF;
> static void *bch_pf;
> static void *bch_vf;
> diff --git a/drivers/mtd/nand/raw/octeontx_nand.c
> b/drivers/mtd/nand/raw/octeontx_nand.c
> index 1ffadad9ca..65a03d22c1 100644
> --- a/drivers/mtd/nand/raw/octeontx_nand.c
> +++ b/drivers/mtd/nand/raw/octeontx_nand.c
> @@ -354,7 +354,7 @@ struct octeontx_probe_device {
>
> static struct bch_vf *bch_vf;
> /** Deferred devices due to BCH not being ready */
> -LIST_HEAD(octeontx_pci_nand_deferred_devices);
> +static LIST_HEAD(octeontx_pci_nand_deferred_devices);
>
> /** default parameters used for probing chips */
> #define MAX_ONFI_MODE 5
> --
Acked-by: Michael Trimarchi
Michael
> 2.34.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] binman: Use unsigned long over typedef ulong
On Wed, 5 Apr 2023 at 06:45, Andrew Davis wrote: > > The header binman_sym.h depends on ulong typedef but does not include > types.h. This means the header must be included after including types.h > or a header that includes it. > > We could include types.h but instead let's just switch from ulong > to directly using unsigned long. This removes the need for typedef'ing > it in some of the tests, so also remove those. > > Signed-off-by: Andrew Davis > --- > include/binman_sym.h| 8 > tools/binman/test/blob_syms.c | 2 -- > tools/binman/test/u_boot_binman_syms.c | 2 -- > tools/binman/test/u_boot_binman_syms_size.c | 2 -- > 4 files changed, 4 insertions(+), 10 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH V6 03/13] drivers: Makefile: Add rule to compile video driver
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > Compile video driver at SPL using CONFIG_SPL_VIDEO. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Add Reviewed-by tag > - Commit message updated. > > V5: > - Add rule to build video at SPL using CONFIG_SPL_VIDEO and retain > obj-y +=video for u-boot proper. > > V4: > - No change > > V3 (patch introduced): > - Add rule to compile video driver at SPL. > > drivers/Makefile | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass Tested-by: Simon Glass # qemu-x86_64
Re: [PATCH V6 08/13] cmd: bmp: Split bmp commands and functions
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote:
>
> To enable splash screen at SPL, need to compile cmd/bmp.c which also
> includes bmp commands, since SPL doesn't use commands split bmp.c into
> common/bmp.c which includes all bmp functions and cmd/bmp.c which only
> contains bmp commands.
>
> Add function delclaration for bmp_info in video.h.
>
> Signed-off-by: Nikhil M Jain
> ---
> V6:
> - Fix commit message.
> - Remove unused header files.
>
> V5:
> - Rename cmd/bmp_cmd to cmd/bmp.
>
> V4:
> - No change.
>
> V3 (patch introduced):
> - Split bmp functions and commands.
>
> cmd/bmp.c | 162 +---
> common/bmp.c| 152 +
> include/video.h | 7 +++
> 3 files changed, 161 insertions(+), 160 deletions(-)
> create mode 100644 common/bmp.c
Reviewed-by: Simon Glass
Please see below
> diff --git a/common/bmp.c b/common/bmp.c
> new file mode 100644
> index 00..6134ada5a7
> --- /dev/null
> +++ b/common/bmp.c
> @@ -0,0 +1,152 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2002
> + * Detlev Zundel, DENX Software Engineering, d...@denx.de.
> + */
> +
> +/*
> + * BMP handling routines
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * Allocate and decompress a BMP image using gunzip().
> + *
> + * Returns a pointer to the decompressed image data. This pointer is
> + * aligned to 32-bit-aligned-address + 2.
> + * See doc/README.displaying-bmps for explanation.
> + *
> + * The allocation address is passed to 'alloc_addr' and must be freed
> + * by the caller after use.
> + *
> + * Returns NULL if decompression failed, or if the decompressed data
> + * didn't contain a valid BMP signature.
> + */
> +#ifdef CONFIG_VIDEO_BMP_GZIP
You can drop this #ifdef and see below
> +struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
> +void **alloc_addr)
> +{
> + void *dst;
> + unsigned long len;
> + struct bmp_image *bmp;
> +
if (!IS_ENABLED(CONFIG_VIDEO_BMP_GZIP))
return NULL;
> + /*
> +* Decompress bmp image
> +*/
> + len = CONFIG_VIDEO_LOGO_MAX_SIZE;
> + /* allocate extra 3 bytes for 32-bit-aligned-address + 2 alignment */
> + dst = malloc(CONFIG_VIDEO_LOGO_MAX_SIZE + 3);
> + if (!dst) {
> + puts("Error: malloc in gunzip failed!\n");
> + return NULL;
> + }
> +
> + /* align to 32-bit-aligned-address + 2 */
> + bmp = dst + 2;
> +
> + if (gunzip(bmp, CONFIG_VIDEO_LOGO_MAX_SIZE, map_sysmem(addr, 0),
> + &len)) {
> + free(dst);
> + return NULL;
> + }
> + if (len == CONFIG_VIDEO_LOGO_MAX_SIZE)
> + puts("Image could be truncated (increase
> CONFIG_VIDEO_LOGO_MAX_SIZE)!\n");
> +
> + /*
> +* Check for bmp mark 'BM'
> +*/
> + if (!((bmp->header.signature[0] == 'B') &&
> + (bmp->header.signature[1] == 'M'))) {
> + free(dst);
> + return NULL;
> + }
> +
> + debug("Gzipped BMP image detected!\n");
> +
> + *alloc_addr = dst;
> + return bmp;
> +}
> +#else
> +struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
> +void **alloc_addr)
> +{
> + return NULL;
> +}
> +#endif
> +
> +
> +#ifdef CONFIG_NEEDS_MANUAL_RELOC
> +void bmp_reloc(void) {
> + fixup_cmdtable(cmd_bmp_sub, ARRAY_SIZE(cmd_bmp_sub));
> +}
> +#endif
> +
> +int bmp_info(ulong addr)
> +{
> + struct bmp_image *bmp = (struct bmp_image *)map_sysmem(addr, 0);
> + void *bmp_alloc_addr = NULL;
> + unsigned long len;
> +
> + if (!((bmp->header.signature[0]=='B') &&
> + (bmp->header.signature[1]=='M')))
> + bmp = gunzip_bmp(addr, &len, &bmp_alloc_addr);
> +
> + if (bmp == NULL) {
> + printf("There is no valid bmp file at the given address\n");
> + return 1;
> + }
> +
> + printf("Image size: %d x %d\n", le32_to_cpu(bmp->header.width),
> + le32_to_cpu(bmp->header.height));
> + printf("Bits per pixel: %d\n", le16_to_cpu(bmp->header.bit_count));
> + printf("Compression : %d\n", le32_to_cpu(bmp->header.compression));
> +
> + if (bmp_alloc_addr)
> + free(bmp_alloc_addr);
> +
> + return(0);
> +}
> +
> +int bmp_display(ulong addr, int x, int y)
> +{
> + struct udevice *dev;
> + int ret;
> + struct bmp_image *bmp = map_sysmem(addr, 0);
> + void *bmp_alloc_addr = NULL;
> + unsigned long len;
> +
> + if (!((bmp->header.signature[0]=='B') &&
> + (bmp->header.signature[1]=='M')))
> + bmp = gunzip_bmp(addr, &len, &bmp_alloc_addr);
> +
> + if (!bmp) {
> + p
Re: [BUG] issues with new bootflow, uefi and virtio
Hi Vincent, On Thu, 6 Apr 2023 at 03:05, Vincent Stehlé wrote: > > Hi, > > I am hitting an issue with the new bootflow when booting with UEFI from a > virtio device on Qemu Arm. > > It seems the device number computation in efiload_read_file() does not work > in the general virtio case, where it will pick the virtio device number > instead of the block device index. On Qemu arm virt machine, many virtio > mmio devices are provisioned in the memory map and no assumption can be > made on the number of the actual virtio device in use in the general case. > > This is an extract of the output of `dm tree' on this platform, focused on > the virtio device from which I would like to boot: > > virtio31 [ + ] virtio-mmio |-- virtio_mmio@a003e00 > blk0 [ + ] virtio-blk | |-- virtio-blk#31 > partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1 > partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2 > bootdev2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev > > In this extract the actual virtio device number is 31, as will be picked by > efiload_read_file(), but the desired block device index is zero, as would > be used with e.g. `ls virtio 0'. This is strange. Can you try 'dm uclass' to see the sequence number for the virtio device? I would expect it to be 0, but I might not fully understand virtio. > > This can be reproduced for example with Buildroot > qemu_aarch64_ebbr_defconfig or qemu_arm_ebbr_defconfig and updating the > U-Boot version to v2023.04. This was working properly with U-Boot versions > up to v2023.01. > > This seems to be very specific to virtio, as the numbers align much more > nicely for e.g. USB mass storage or NVMe. > > To help debugging, the following patch forces the device number to zero in > the case of virtio, which allows to boot again with UEFI and virtio on Qemu > Arm. Hopefully this should give a hint of what is going on. > > I tried to create a fix by looking for the first child device of > UCLASS_BLK, and use its devnum instead in the case of virtio. Sadly, I am > not able to confirm if this is a proper fix as I am hitting other boot > issues in the case of multiple boot devices of the same class it seems... Please also see this: https://patchwork.ozlabs.org/project/uboot/patch/20230402140231.v7.3.Ifa423a8f295b3c11e50821222b0db1e869d0c051@changeid/ (or the whole series) > > Vincent. > > [1]: https://buildroot.org > > --- > boot/bootmeth_efi.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c > index 6a97ac02ff5..e5b0d8614ff 100644 > --- a/boot/bootmeth_efi.c > +++ b/boot/bootmeth_efi.c > @@ -117,7 +117,9 @@ static int efiload_read_file(struct blk_desc *desc, > struct bootflow *bflow) > * this can go away. > */ > media_dev = dev_get_parent(bflow->dev); > - snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev)); > + snprintf(devnum_str, sizeof(devnum_str), "%x", > +device_get_uclass_id(media_dev) == UCLASS_VIRTIO ? 0 : > +dev_seq(media_dev)); > > strlcpy(dirname, bflow->fname, sizeof(dirname)); > last_slash = strrchr(dirname, '/'); > -- > 2.39.2 > Regards, Simon
Re: [PATCH V6 09/13] common: Makefile: Rule to compile bmp.c
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > Add rule to compile bmp.c at SPL and u-boot proper when CONFIG_SPL_BMP > and CONFIG_BMP are defined. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Add Reviewed-by tag. > > V5: > - Remove obj-y+= read.o. > > V4: > - No change. > > V3 (patch introduced): > - Rule to compile common/bmp. > > common/Makefile | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass Tested-by: Simon Glass # qemu-x86_64
Re: [PATCH V6 10/13] drivers: video: Enable necessary video functions at SPL
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > To support video driver at SPL use CONFIG_IS_ENABLED and CONFIG_VAL, > which checks for stage specific configs and thus enables video support > at respective stage. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - No change. > > V5: > - Add Reviewed-By tag. > - Use COFIG_IS_ENABLED in console_core in place of console_normal. > > V4: > - No change. > > V3 (patch introduced): > - Enable necessary video functions at SPL. > > drivers/video/console_core.c | 6 +++--- > drivers/video/vidconsole-uclass.c | 2 +- > drivers/video/video-uclass.c | 14 +++--- > drivers/video/video_bmp.c | 8 > 4 files changed, 15 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass Tested-by: Simon Glass # qemu-x86_64
Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image
Hi Christian, On Mon, 3 Apr 2023 at 20:10, Christian Hewitt wrote: > > > On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > > > Hi Mark, > > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Sun, 2 Apr 2023 06:54:57 +1200 > > > > > > > > The Odroid-C2 is quite a complicated image with many steps. It is an > > > > ideal > > > > example for how Binman can be used. > > > > > > You say Odroid-C2, but the patches seem to address the Odroid-C4... > > > > Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3 > > on the C4. I wonder if that affects the image makeup? > > There are currently four different signing recipes that depend on the > board family that you are building for: > > - GXBB > - GXL/GXM > - G12A/SM1 > - G12B > > The G12A/SM1 and G12B recipes are identical except for a different > signing binary used. The latest Amlogic boards (S905X4, T7, etc.) > also have incremental changes, but none are currently supported in > Linux or u-boot. > > One of the challenges for binman will be the signing tools. Currently > this patchset depends upon Amlogic binaries. Apart from them being > closed-source and thus undesirable, they are also x86_64 only and > there are quite a few users (and at least one major distro) needing > to build on arm64 hardware. > > There is an open-source tool called gxlimg which supports GXL and newer > boards. IMHO it would make a lot of sense for u-boot to absorb the > functionality of gxlimg (and extend support backwards to GXBB) as this > would remove the dependency on Amlogic binaries and allow u-boot build > and binman signing to be done anywhere. > > https://github.com/repk/gxlimg Fair enough, but another option would be to allow 'binman tool -f gxlimg' to work, which should be easy. Then we can make use of the existing C code, using binary tools for the unsupported ones. > > > The patch is for testing by Christian, who I hope can help get this landed > > for all the Amlogic boards. > > I will try to find the time to test this, but it’s not something I > could do more with (as only supporting 1/4 of the board families > that I need to build for, bu I do appreciate it’s a POC). Yes, it's a start. > > In case you’re not aware, Makefile based signing is implemented in > the amlogic-boot-fip repo that I’m currently tooled around: > > https://github.com/LibreELEC/amlogic-boot-fip > > This is the “competition” so to speak. It’s quite simple and widely > used by most of the Amlogic supporting distros right now. Well at least that provides the recipes. Regards, Simon
Re: [PATCH v2 1/1] RFC: Move Odroid-C2 to use binman to produce the image
Hi Neil, On Mon, 3 Apr 2023 at 19:31, Neil Armstrong wrote: > > Hi Simon ! > > On 01/04/2023 20:54, Simon Glass wrote: > > This shows how binman can be used to replace the long and complicated > > instructions with an automated build. It is still complicated to read > > but users don't have to worry about the details. > > > > It needs some tidying up and only supports Odroid-C2 at present. > > Like the v1, the work is really nice, but the dependency on vendor binary-only > tools doesn't make feel confident about merging this. So long as we can download it from somewhere, that is OK, or at least better than nothing. Is there a standard download location for the tools? > > We have open source implementation for all boards, but still dependeing on > tools we must manually build isn't optimal. > > What would be optimal would be to re-implement those tools into python > libraries and merge them into the u-boot tree then use them from binman. Or C, perhaps? Then binman can call the tools. > > But this could be merged as first step, them the python libaray could be > modified to support the binary tools & a probable python re-implementation. Yes I think it would good to get this in, even if it only supports a few boards. It is easy to add more, when possible. Regards, SImon
Re: [PATCH V6 06/13] common: Makefile: Add rule to compile splash and splash_source at SPL
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > To enable splash screen and loading bmp from boot media, add rules to > compile splash.c and splash_source.c at SPL stage only when > CONFIG_SPL_SPLASH_SCREEN and CONFIG_SPL_SPLASH_SOURCE are defined. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Add Reviewed-by tag. > > V5: > - No change > > V4: > - No change > > V3 (patch introduced): > - Rule to compile splash.c and splash_source.c. > > common/Makefile | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 2/2] test: hush_if_test: Add hush variable test
On Tue, 4 Apr 2023 at 01:50, Stefan Herbrechtsmeier wrote: > > From: Stefan Herbrechtsmeier > > Add a test for the hush shell variable assignment and clear. > > Signed-off-by: Stefan Herbrechtsmeier > --- > > (no changes since v1) > > test/py/tests/test_hush_if_test.py | 13 + > 1 file changed, 13 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH 1/1] common: static fdt_simplefb_enable_existing_node()
On Tue, 4 Apr 2023 at 06:47, Heinrich Schuchardt wrote: > > Function fdt_simplefb_enable_existing_node() should be static as it is not > used outside common/fdt_simplefb.c. > > Signed-off-by: Heinrich Schuchardt > --- > common/fdt_simplefb.c | 8 +++- > include/fdt_simplefb.h | 1 - > 2 files changed, 7 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 01/18] binman: Add support for generating TI Board config binaries
Hi Neha,
On Wed, 5 Apr 2023 at 00:13, Neha Malcom Francis wrote:
>
> 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 generated binaries to be packed into the final
> system firmware images.
>
> Signed-off-by: Neha Malcom Francis
> ---
> tools/binman/entries.rst | 50
> tools/binman/etype/ti_board_config.py | 246 ++
> tools/binman/ftest.py | 11 +
> tools/binman/test/277_ti_board_cfg.dts| 11 +
> .../binman/test/278_ti_board_cfg_combined.dts | 25 ++
> tools/binman/test/yaml/config.yaml| 11 +
> tools/binman/test/yaml/schema.yaml| 26 ++
> 7 files changed, 380 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/yaml/config.yaml
> create mode 100644 tools/binman/test/yaml/schema.yaml
This looks pretty good. Some things to fix:
The first line of a function comment should fit on that line. Add a
blank line afterwards. Add full comments to all functions, describing
the purpose / type of each arg (you have done many of them).
Use 'binman entry-docs >tools/binman/entries.rst' to generate the docs
rather than hand editing. Try 'make htmldocs' as this fails for your
updates.
Some test coverage is missing - use 'binman test -T' to try it. You
will need to add tests for failing cases as well as success, perhaps
adding new .dts files for your tests.
The jsonschema module is now required. That needs to be added to the
'dependencies' line of tools/binman/pyproject.toml
A few minor nits below
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index b71af801fd..7cfe61dd09 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -2423,3 +2423,53 @@ may be used instead.
>
>
>
> +.. _etype_ti_board_config:
> +
> +Entry: ti-board-config: Texas Instruments board config binary
> +-
> +
> +Support for generation of TI schema validated board configuration
> +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
> +
> +These above parameters are used only when the generated binary is
> +intended to be a single board configuration binary. Example::
> +
> +/* generate a my-ti-board-config.bin generated from a YAML configuration
> +file validated against the schema*/
> +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. For example::
> +
> +/* generate a my-combined-ti-board-config.bin packed with a header
> +(containing details about the included board config binaries), along
> +with the YAML schema validated binaries themselves*/
> +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";
> +};
> +};
> +};
> +
> +
> diff --git a/tools/binman/etype/ti_board_config.py
> b/tools/binman/etype/ti_board_config.py
> new file mode 100644
> index 00..0a9be44afc
> --- /dev/null
> +++ b/tools/binman/etype/ti_board_config.py
> @@ -0,0 +1,246 @@
> +# 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 tempfile
> +import yaml
> +
> +from collections import OrderedDict
> +from jsonschema import validate
> +from shutil import copyfileobj
> +from shutil import rmtree
> +
> +from binman.entry import Entry
> +from binman.etype.section import Entry_section
> +from binman.etype.blob_ext import Entry_blob_ext
> +from binman.etype.blob_ext_list import Entry_blob_ext_list
> +from dtoc import fdt_util
> +from u_boot_pylib import tools, tout
> +
> +BOARDCFG = 0xB
> +BOARDCFG_SEC = 0xD
> +BOARDCFG_PM = 0xE
> +BOARDCFG_RM = 0xC
> +BOARDCFG_NUM_ELEMS = 4
> +
> +class Entry_ti_board_config(Entry_section):
> +"""
> +Sup
Re: [PATCH 1/1] test: move unit tests into a sub-menu
On Tue, 4 Apr 2023 at 06:28, Heinrich Schuchardt wrote: > > The main configuration menu should not contain detail settings. > > Signed-off-by: Heinrich Schuchardt > --- > test/Kconfig | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH V6 11/13] common: Enable splash functions at SPL
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > To support splash screen at both u-boot proper and SPL use > CONFIG_IS_ENABLED and CONFIG_VAL to check for video related Kconfigs at > respective stages. > > Replace CONFIG_CMD_BMP with CONFIG_BMP to enable splash_display function > at u-boot proper and SPL. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Fix commit message. > - Add Reviewed-by tag. > > V5: > - Replace CONFIG_CMD_BMP with CONFIG_BMP. > > V4: > - No change > > V3 (patch introduced): > - Enable splash functions at SPL > > common/bmp.c| 10 +- > common/splash.c | 10 +- > 2 files changed, 10 insertions(+), 10 deletions(-) > Reviewed-by: Simon Glass Some of these #ifdefs look like they could be converted to if() while you are here.
Re: [PATCH 1/1] test: improve configuration for Kconfig test options
On Mon, 3 Apr 2023 at 22:04, Heinrich Schuchardt
wrote:
>
> * Fix dependencies
> * Provide labels that are easier to grasp.
> * Fix typo %s/whgch/which/
> * Fix type %s/Is/is/
>
> Fixes: 29784d62eded ("test: Add some tests for kconfig.h")
> Signed-off-by: Heinrich Schuchardt
> ---
> test/lib/Kconfig | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH V6 01/13] drivers: video: Kconfig: Add configs for enabling video at SPL
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > Add Kconfigs which enable the video driver and splash screen at SPL > stage only and not at u-boot proper. The existing Kconfigs from u-boot > proper were not used to make SPL splash screen independent to them. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Replace CMD_BMP with BMP. > > V5: > - Added Reviewed-by tag. > > V4: > - No change. > > V3: > - Add separate SPL video and splash configs. > - Reviewed-by tag not added due to additional changes in V3. > > V2: > - No change. > > drivers/video/Kconfig | 223 +- > 1 file changed, 222 insertions(+), 1 deletion(-) > Reviewed-by: Simon Glass Tested-by: Simon Glass # qemu-x86_64
Re: [PATCH v2 02/18] binman: ti-secure: Add support for TI signing
kHi Neha,
On Wed, 5 Apr 2023 at 00:13, Neha Malcom Francis wrote:
>
> 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
> ---
> board/ti/keys/custMpk.pem | 51
> board/ti/keys/ti-degenerate-key.pem | 10 +
> tools/binman/btool/openssl.py | 244 ++
> tools/binman/entries.rst | 25 ++
> tools/binman/etype/ti_secure.py | 83 ++
> tools/binman/etype/ti_secure_rom.py | 233 +
> tools/binman/etype/x509_cert.py | 87 ++-
> tools/binman/ftest.py | 46
> 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 ++
> 11 files changed, 830 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
> diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> index 3a4dbdd6d7..aad3b61ae2 100644
> --- a/tools/binman/btool/openssl.py
> +++ b/tools/binman/btool/openssl.py
> @@ -15,6 +15,13 @@ import hashlib
> from binman import bintool
> from u_boot_pylib import tools
>
> +
> +VALID_SHAS = [256, 384, 512, 224]
> +SHA_OIDS = {256:'2.16.840.1.101.3.4.2.1',
> +384:'2.16.840.1.101.3.4.2.2',
> +512:'2.16.840.1.101.3.4.2.3',
> +224:'2.16.840.1.101.3.4.2.4'}
> +
> class Bintoolopenssl(bintool.Bintool):
> """openssl tool
>
> @@ -74,6 +81,243 @@ imageSize = INTEGER:{len(indata)}
> '-sha512']
> return self.run_cmd(*args)
>
> +def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
> + config_fname, req_dist_name_dict):
> +"""Create a certificate to be booted by system firmware
> +
> +Args:
> +cert_fname (str): Filename of certificate to create
> +input_fname (str): Filename containing data to sign
> +key_fname (str): Filename of .pem file
> +sw_rev (int): Software revision
> +config_fname (str): Filename to write fconfig into
> +req_dist_name_dict (dict): Dictionary containing key-value pairs
> of
> +req_distinguished_name section extensions, must contain
> extensions for
> +C, ST, L, O, OU, CN and emailAddress
> +
> +Returns:
> +str: Tool output
> +"""
> +indata = tools.read_file(input_fname)
> +hashval = hashlib.sha512(indata).hexdigest()
> +with open(config_fname, 'w', encoding='utf-8') as outf:
> +print(f'''[ req ]
> +distinguished_name = req_distinguished_name
> +x509_extensions= v3_ca
> +prompt = no
> +dirstring_type = nobmp
> +
> +[ req_distinguished_name ]
> +C = {req_dist_name_dict['C']}
> +ST = {req_dist_name_dict['ST']}
> +L = {req_dist_name_dict['L']}
> +O = {req_dist_name_dict['O']}
> +OU = {req_dist_name_dict['OU']}
> +CN = {req_dist_name_dict['CN']}
> +emailAddress = {req_dist_name_dict['emailAddress']}
> +
> +[ v3_ca ]
> +basicConstraints = CA:true
> +1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
> +1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
> +1.3.6.1.4.1.294.1.35 = ASN1:SEQUENCE:sysfw_image_load
> +
> +[ swrv ]
> +swrv = INTEGER:{sw_rev}
> +
> +[ sysfw_image_integrity ]
> +shaType= OID:2.16.840.1.101.3.4.2.3
> +shaValue = FORMAT:HEX,OCT:{hashval}
> +imageSize = INTEGER:{len(indata)}
There's a lot of duplication here, but at least it is in one file.
Would it make sense, for example, to have a function like
add_dn(buf, dict)
which adds the req_distinguished_name to a stringio buffer? Then that
could be calls from multiple places.
Also, please check test coverage (binman test -T). That should be 100%
so you will need to add tests for failing cases as well.
Regards,
Simon
Re: [PATCH V6 12/13] include: Enable video related global data variable and splash at SPL
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > To include video related global data variables and splash functions at > SPL and u-boot proper, use CONFIG_IS_ENABLED. > > Replace CONFIG_CMD_BMP with CONFIG_BMP to enable splash_display function > at u-boot proper and SPL. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Fix commit message. > - Add Reviewed-by tag. > > V5: > - Replace CONFIG_CMD_BMP with CONFIG_BMP. > > V4: > - No change > > V3 (patch introduced): > - Enable splash functions at SPL > > include/asm-generic/global_data.h | 4 ++-- > include/splash.h | 6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH V6 04/13] drivers: video: Makefile: Rule to compile necessary video driver files
On Wed, 5 Apr 2023 at 01:06, Nikhil M Jain wrote: > > To enable video driver at SPL, need to compile video-uclass, > vidconsole-uclass, backlight-uclass, panel-uclass, simple-panel, add > rules to compile them at SPL and u-boot proper. To support > splash_display at SPL, need to compile video-bmp, add rule to compile at > SPL and u-boot proper. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V6: > - Fix CONFIG_$(SPL_TPL)CONSOLE_NORMAL to CONFIG_$(SPL_TPL_)CONSOLE_NORMAL > - Add rule to compile simple_panel at SPL and u-boot proper. > > V5: > - Use $(SPL_TPL_) to check for stage specific configs and compile at > specific stages. > - Removed ifdef CONFIG_SPL_BUILD > > V4: > - No change > > V3: > - Rule to compile backlight, console and panel files > - Not added Reiewed-by tag due to changes > > V2: > - No change > > drivers/video/Makefile | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > Reviewed-by: Simon Glass Tested-by: Simon Glass # qemu-x86_64
Re: [PATCH v2 1/2] common: cli_hush: Restore clear local variable support
On Tue, 4 Apr 2023 at 01:50, Stefan Herbrechtsmeier
wrote:
>
> From: Stefan Herbrechtsmeier
>
> The u-boot hush shell doesn’t support the unset command to clear a
> variable and therefore an empty value ("c=") should be a valid value
> for the set_local_var function to clear the variable. This partial
> reverts commit aa722529635c ("common: cli_hush: avoid dead code") and
> only checks for a `=` in the string. Additionally explicit call the
> unset_local_var function to remove the variable if the value is empty.
>
> Signed-off-by: Stefan Herbrechtsmeier
>
> ---
>
> Changes in v2:
> - Use `!var` instead of `var == NULL`
>
> common/cli_hush.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass
Re: Newer U-Boot version throwing "Bootstage space exhasuted" with FIT image
Hi,
[please try to avoid top posting]
On Wed, 5 Apr 2023 at 19:20, wrote:
>
> Hi Simon,
>
> even with CONFIG_BOOTSTAGE disabled I still get this data abort:
>
> Starting kernel ...
>
> data abort
> pc : [] lr : [<>]
> reloc pc : []lr : []
> sp : fbbefafc ip : fp : 0001
> r10: c2d8 r9 : fbbffec0 r8 :
> r7 : r6 : r5 : e28ff010 r4 :
> r3 : r2 : 0a10 r1 : fdfab018 r0 : 2ffc0020
> Flags: nzCv IRQs off FIQs off Mode SVC_32 (T)
> Code: f891 f03c f891 f05c (f891) f07c
> Resetting CPU ...
>
> resetting ...
>
> How can I debug this any further?
OK so it is not related to bootstage. Perhaps Linux is crashing due to
something being in the wrong place?
I suggest copying some STM32 people here. You might be able to add a
'console=' or 'earlycon=' line to get a log from Linux.
Regards,
Simon
>
> Best regards
>
>
>
> Hi,
>
> On Mon, 3 Apr 2023 at 00:43, wrote:
> >
> > Hi Simon,
> >
> > it's an STM32MP1, here's a bdinfo and the full boot log. Btw, OPTEE OS is
> > active:
> >
> > STM32MP> bdinfo
> > boot_params = 0x
> > DRAM bank = 0x
> > -> start= 0xc000
> > -> size = 0x4000
> > flashstart = 0x
> > flashsize = 0x
> > flashoffset = 0x
> > baudrate= 115200 bps
> > relocaddr = 0xfdf3a000
> > reloc off = 0x3de3a000
> > Build = 32-bit
> > current eth = ethernet@5800a000
> > ethaddr = 00:00:00:00:00:00
> > IP addr =
> > fdt_blob= 0xfbf27e10
> > new_fdt = 0xfbf27e10
> > fdt_size= 0x000100a0
> > lmb_dump_all:
> > memory.cnt = 0x1
> > memory[0] [0xc000-0x], 0x4000 bytes flags: 0
> > reserved.cnt = 0x5
> > reserved[0][0x1000-0x10047fff], 0x00048000 bytes flags: 4
> > reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
> > reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
> > reserved[3][0xfbf23940-0xfdff], 0x020dc6c0 bytes flags: 0
> > reserved[4][0xfe00-0x], 0x0200 bytes flags: 4
> > devicetree = board
> > arch_number = 0x
> > TLB addr= 0xfdff
> > irq_sp = 0xfbf27b80
> > sp start= 0xfbf27b70
> > Early malloc usage: 11f8 / 3000
> > STM32MP> ext4load mmc ${boot_instance}:${boot_part} ${kernel_addr_r}
> > ${linux}; bootm ${kernel_addr_r}
> > 10590706 bytes read in 542 ms (18.6 MiB/s)
> > ## Loading kernel from FIT Image at c200 ...
> >Using 'config' configuration
> >Trying 'kernel' kernel subimage
> > Description: Linux kernel - base
> > Created: 2023-03-31 12:45:20 UTC
> > Type: Kernel Image
> > Compression: uncompressed
> > Data Start: 0xc2d8
> > Data Size:7527552 Bytes = 7.2 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: 0xc0008000
> > Entry Point: 0xc0008000
> > Hash algo:sha256
> > Hash value:
> > b0ca7e8de523721697b6990e67f142159845f1b5e2a52a4fef4da8f6754d49a7
> > Sign algo:sha256,rsa2048:board
> > Sign value: unavailable
> > Timestamp:unavailable
> >Verifying Hash Integrity ... sha256+ OK
> >kernel data at 0xc2d8, len = 0x0072dc80 (7527552)
> > ## Loading ramdisk from FIT Image at c200 ...
> >Using 'config' configuration
> >Trying 'ramdisk' ramdisk subimage
> > Description: ramdisk
> > Created: 2023-03-31 12:45:20 UTC
> > Type: RAMDisk Image
> > Compression: uncompressed
> > Data Start: 0xc273d318
> > Data Size:2998533 Bytes = 2.9 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: unavailable
> > Entry Point: unavailable
> > Hash algo:sha256
> > Hash value:
> > 3d9201eee8e91a161719ea35b630d9d09dc6be204fcda3390ecd7a540e322048
> > Sign algo:sha256,rsa2048:board
> > Sign value: unavailable
> > Timestamp:unavailable
> >Verifying Hash Integrity ... sha256+ OK
> > ## Loading fdt from FIT Image at c200 ...
> > Bootstage space exhasuted
> >Using 'config' configuration
> >Trying 'dtb' fdt subimage
> > Description: DeviceTree blob - base
> > Created: 2023-03-31 12:45:20 UTC
> > Type: Flat Device Tree
> > Compression: uncompressed
> > Data Start: 0xc272de94
> > Data Size:62326 Bytes = 60.9 KiB
> > Architecture: ARM
> > Load Address: 0xc400
> > Hash algo:sha256
> > Hash value:
> > 2b1df931402fd642c8a1618aa140630e22fed4c095deed4df201637f008630ea
> > Sign algo:sha256,rsa2048:board
> > Sign value: unavailable
> > Timestamp:unavailable
> >Verifying Hash Integrity ... sha256+ OK
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> > Bootstage space exh
Re: [PATCH 1/1] MAINTAINERS: assign include/os.h
On Wed, 5 Apr 2023 at 21:27, Heinrich Schuchardt wrote: > > os.h is only used by the sandbox. > > Signed-off-by: Heinrich Schuchardt > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass
Re: [PATCH v2 1/1] sandbox: fix return type of os_filesize()
On Wed, 5 Apr 2023 at 21:34, Heinrich Schuchardt wrote: > > Given a file ../img of size 4294967296 with GPT partition table and > partitions: > > => host bind 0 ../img > => part list host 0 > Disk host-0.blk not ready > > The cause is os_filesize() returning int. File sizes must use off_t. > > Correct all uses of os_filesize() too. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > avoid different signedness when comparing numbers > --- > arch/sandbox/cpu/os.c| 8 ++-- > drivers/block/host_dev.c | 3 ++- > include/os.h | 2 +- > 3 files changed, 9 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] dm: core: Make aliases_lookup static
On Thu, 6 Apr 2023 at 02:38, Bin Meng wrote: > > aliases_lookup is only referenced in of_access.c > > Signed-off-by: Bin Meng > --- > > drivers/core/of_access.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: RISC-V FIT image type
Hi Bin, On Sun, 2 Apr 2023 at 15:33, Bin Meng wrote: > > Hi Simon, > > On Sat, Apr 1, 2023 at 2:31 PM Simon Glass wrote: > > > > Hi Bin, > > > > On Fri, 31 Mar 2023 at 19:22, Bin Meng wrote: > > > > > > On Fri, Mar 31, 2023 at 5:36 AM Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > I notice that in image.h we have IH_ARCH_RISCV but no mention of > > > > IH_ARCH_RISCV64. Should we not have two separate image types, as we do > > > > with ARM and x86? Otherwise, how would a loader know the word size of > > > > the target machine? > > > > > > I think that's because in RISC-V it is always the same bit-width > > > U-Boot to load the same bit-width kernel. There is no support of > > > 32-bit U-Boot to load 64-bit kernel and vice versa. > > > > Yes, understood, but in this case we can't be sure that it is possible > > load a FIT, e.g. if someone makes a mistake. > > > > Would it be OK to create a new "riscv64" type? This has come up in the > > universal payload discussions. > > > > I think so. But I will leave this to the RISC-V maintainers to make a call. OK thanks. I'll send a patch. Regards, Simon
[PATCH v2 11/12] arm: mach-k3: Move J721s2 SPL init functions to mach-k3
This matches AM64 and J721e and removes the need to forward
declare k3_spl_init(), k3_mem_init(), and check_rom_loaded_sysfw()
in sys_proto.h.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/include/mach/sys_proto.h | 3 --
arch/arm/mach-k3/j721s2_init.c| 64 +++
board/ti/j721s2/evm.c | 63 --
3 files changed, 64 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 4b4e2a5be39..5638c6f8c8a 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -7,7 +7,4 @@
#ifndef _SYS_PROTO_H_
#define _SYS_PROTO_H_
-void k3_spl_init(void);
-void k3_mem_init(void);
-bool check_rom_loaded_sysfw(void);
#endif
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index 4785a747bf3..175ac4028a0 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -182,6 +183,69 @@ void k3_mem_init(void)
spl_enable_dcache();
}
+/* Support for the various EVM / SK families */
+#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
+void do_dt_magic(void)
+{
+ int ret, rescan, mmc_dev = -1;
+ static struct mmc *mmc;
+
+ do_board_detect();
+
+ /*
+* Board detection has been done.
+* Let us see if another dtb wouldn't be a better match
+* for our board
+*/
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ ret = fdtdec_resetup(&rescan);
+ if (!ret && rescan) {
+ dm_uninit();
+ dm_init_and_scan(true);
+ }
+ }
+
+ /*
+* Because of multi DTB configuration, the MMC device has
+* to be re-initialized after reconfiguring FDT inorder to
+* boot from MMC. Do this when boot mode is MMC and ROM has
+* not loaded SYSFW.
+*/
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC1:
+ mmc_dev = 0;
+ break;
+ case BOOT_DEVICE_MMC2:
+ case BOOT_DEVICE_MMC2_2:
+ mmc_dev = 1;
+ break;
+ }
+
+ if (mmc_dev > 0 && !check_rom_loaded_sysfw()) {
+ ret = mmc_init_device(mmc_dev);
+ if (!ret) {
+ mmc = find_mmc_device(mmc_dev);
+ if (mmc) {
+ ret = mmc_init(mmc);
+ if (ret)
+ printf("mmc init failed with error:
%d\n", ret);
+ }
+ }
+ }
+}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+ k3_spl_init();
+#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
+ do_dt_magic();
+#endif
+ k3_mem_init();
+}
+#endif
+
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
switch (boot_device) {
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 9b130c141ac..d3f9a655899 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -192,66 +192,3 @@ int board_late_init(void)
void spl_board_init(void)
{
}
-
-/* Support for the various EVM / SK families */
-#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
-void do_dt_magic(void)
-{
- int ret, rescan, mmc_dev = -1;
- static struct mmc *mmc;
-
- do_board_detect();
-
- /*
-* Board detection has been done.
-* Let us see if another dtb wouldn't be a better match
-* for our board
-*/
- if (IS_ENABLED(CONFIG_CPU_V7R)) {
- ret = fdtdec_resetup(&rescan);
- if (!ret && rescan) {
- dm_uninit();
- dm_init_and_scan(true);
- }
- }
-
- /*
-* Because of multi DTB configuration, the MMC device has
-* to be re-initialized after reconfiguring FDT inorder to
-* boot from MMC. Do this when boot mode is MMC and ROM has
-* not loaded SYSFW.
-*/
- switch (spl_boot_device()) {
- case BOOT_DEVICE_MMC1:
- mmc_dev = 0;
- break;
- case BOOT_DEVICE_MMC2:
- case BOOT_DEVICE_MMC2_2:
- mmc_dev = 1;
- break;
- }
-
- if (mmc_dev > 0 && !check_rom_loaded_sysfw()) {
- ret = mmc_init_device(mmc_dev);
- if (!ret) {
- mmc = find_mmc_device(mmc_dev);
- if (mmc) {
- ret = mmc_init(mmc);
- if (ret)
- printf("mmc init failed with error:
%d\n", ret);
- }
- }
- }
-}
-#endif
-
-#ifdef CONFIG_SPL_BUILD
-void boa
[PATCH v2 12/12] arm: mach-k3: Remove empty sys_proto.h include
This header file is now empty, remove it. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/am642_init.c | 2 -- arch/arm/mach-k3/am654_init.c | 1 - arch/arm/mach-k3/common.c | 1 - arch/arm/mach-k3/include/mach/sys_proto.h | 10 -- arch/arm/mach-k3/j721e_init.c | 1 - arch/arm/mach-k3/j721s2_init.c| 1 - arch/arm/mach-k3/security.c | 1 - arch/arm/mach-k3/sysfw-loader.c | 1 - board/siemens/iot2050/board.c | 1 - board/ti/am62ax/evm.c | 1 - board/ti/am62x/evm.c | 1 - board/ti/am64x/evm.c | 1 - board/ti/am65x/evm.c | 2 -- board/ti/j721e/evm.c | 2 -- board/ti/j721s2/evm.c | 2 -- drivers/phy/phy-ti-am654.c| 1 - drivers/ram/k3-am654-ddrss.c | 1 - 17 files changed, 30 deletions(-) delete mode 100644 arch/arm/mach-k3/include/mach/sys_proto.h diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c index 9a34a3f9451..22d4be3d94f 100644 --- a/arch/arm/mach-k3/am642_init.c +++ b/arch/arm/mach-k3/am642_init.c @@ -13,9 +13,7 @@ #include #include #include "sysfw-loader.h" -#include #include "common.h" -#include #include #include #include diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c index 5a9a780f521..b5021069d62 100644 --- a/arch/arm/mach-k3/am654_init.c +++ b/arch/arm/mach-k3/am654_init.c @@ -14,7 +14,6 @@ #include #include #include "sysfw-loader.h" -#include #include "common.h" #include #include diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c index 9f2f5a98771..e29e51b7042 100644 --- a/arch/arm/mach-k3/common.c +++ b/arch/arm/mach-k3/common.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #include #include diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h b/arch/arm/mach-k3/include/mach/sys_proto.h deleted file mode 100644 index 5638c6f8c8a..000 --- a/arch/arm/mach-k3/include/mach/sys_proto.h +++ /dev/null @@ -1,10 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ - * Andreas Dannenberg - */ - -#ifndef _SYS_PROTO_H_ -#define _SYS_PROTO_H_ - -#endif diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c index 3fda2dfaa1b..5d7a6f7e9c9 100644 --- a/arch/arm/mach-k3/j721e_init.c +++ b/arch/arm/mach-k3/j721e_init.c @@ -14,7 +14,6 @@ #include #include "sysfw-loader.h" #include "common.h" -#include #include #include #include diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c index 175ac4028a0..001d9466c20 100644 --- a/arch/arm/mach-k3/j721s2_init.c +++ b/arch/arm/mach-k3/j721s2_init.c @@ -14,7 +14,6 @@ #include #include "sysfw-loader.h" #include "common.h" -#include #include #include #include diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c index 092588f4b5e..6179f7373aa 100644 --- a/arch/arm/mach-k3/security.c +++ b/arch/arm/mach-k3/security.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include "common.h" diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c index c4c5c371100..9be2d9eaea2 100644 --- a/arch/arm/mach-k3/sysfw-loader.c +++ b/arch/arm/mach-k3/sysfw-loader.c @@ -23,7 +23,6 @@ #include #include -#include #include "common.h" DECLARE_GLOBAL_DATA_PTR; diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c index 1ba3e90c6fc..2653e107450 100644 --- a/board/siemens/iot2050/board.c +++ b/board/siemens/iot2050/board.c @@ -21,7 +21,6 @@ #include #include #include -#include #include #include #include diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c index beef3f2f3da..f2dd3b4192e 100644 --- a/board/ti/am62ax/evm.c +++ b/board/ti/am62ax/evm.c @@ -7,7 +7,6 @@ */ #include -#include #include #include #include diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c index 20b2a701223..034fbed3aa4 100644 --- a/board/ti/am62x/evm.c +++ b/board/ti/am62x/evm.c @@ -15,7 +15,6 @@ #include #include #include -#include #include DECLARE_GLOBAL_DATA_PTR; diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c index c88139ac7ac..b63792e 100644 --- a/board/ti/am64x/evm.c +++ b/board/ti/am64x/evm.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #include "../common/board_detect.h" diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c index 4053b8333cf..706b2198183 100644 --- a/board/ti/am65x/evm.c +++ b/board/ti/am65x/evm.c @@ -13,7 +13,6 @@ #include #include #include -#include #include #include #include @@ -21,7 +20,6 @@ #include #include #include -#include #include "../common/board_detect.h" diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index 00
[PATCH v2 06/12] arm: mach-k3: Make release_resources_for_core_shutdown() common
This function is the same for each device when it needs to shutdown
the R5 core. Move this to the common section and move the remaining
device specific ID list to the device hardware include.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am642_init.c | 51 -
arch/arm/mach-k3/am654_init.c | 51 -
arch/arm/mach-k3/common.c | 32 ++-
arch/arm/mach-k3/include/mach/am62_hardware.h | 8 +++
.../arm/mach-k3/include/mach/am62a_hardware.h | 8 +++
arch/arm/mach-k3/include/mach/am64_hardware.h | 24
arch/arm/mach-k3/include/mach/am6_hardware.h | 19 +++
.../arm/mach-k3/include/mach/j721e_hardware.h | 19 +++
.../mach-k3/include/mach/j721s2_hardware.h| 19 +++
arch/arm/mach-k3/include/mach/sys_proto.h | 1 -
arch/arm/mach-k3/j721e_init.c | 55 ---
arch/arm/mach-k3/j721s2_init.c| 54 --
12 files changed, 127 insertions(+), 214 deletions(-)
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 1bf7e163cc4..86aced54646 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -346,54 +346,3 @@ u32 spl_boot_device(void)
else
return __get_backup_bootmedia(devstat);
}
-
-#if defined(CONFIG_SYS_K3_SPL_ATF)
-
-#define AM64X_DEV_RTI8 127
-#define AM64X_DEV_RTI9 128
-#define AM64X_DEV_R5FSS0_CORE0 121
-#define AM64X_DEV_R5FSS0_CORE1 122
-
-void release_resources_for_core_shutdown(void)
-{
- struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- struct ti_sci_dev_ops *dev_ops = &ti_sci->ops.dev_ops;
- struct ti_sci_proc_ops *proc_ops = &ti_sci->ops.proc_ops;
- int ret;
- u32 i;
-
- const u32 put_device_ids[] = {
- AM64X_DEV_RTI9,
- AM64X_DEV_RTI8,
- };
-
- /* Iterate through list of devices to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
- u32 id = put_device_ids[i];
-
- ret = dev_ops->put_device(ti_sci, id);
- if (ret)
- panic("Failed to put device %u (%d)\n", id, ret);
- }
-
- const u32 put_core_ids[] = {
- AM64X_DEV_R5FSS0_CORE1,
- AM64X_DEV_R5FSS0_CORE0, /* Handle CPU0 after CPU1 */
- };
-
- /* Iterate through list of cores to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
- u32 id = put_core_ids[i];
-
- /*
-* Queue up the core shutdown request. Note that this call
-* needs to be followed up by an actual invocation of an WFE
-* or WFI CPU instruction.
-*/
- ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
- if (ret)
- panic("Failed sending core %u shutdown message (%d)\n",
- id, ret);
- }
-}
-#endif
diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c
index 70059edb039..abd0c0bccbc 100644
--- a/arch/arm/mach-k3/am654_init.c
+++ b/arch/arm/mach-k3/am654_init.c
@@ -353,54 +353,3 @@ u32 spl_boot_device(void)
else
return __get_backup_bootmedia(devstat);
}
-
-#ifdef CONFIG_SYS_K3_SPL_ATF
-
-#define AM6_DEV_MCU_RTI0 134
-#define AM6_DEV_MCU_RTI1 135
-#define AM6_DEV_MCU_ARMSS0_CPU0159
-#define AM6_DEV_MCU_ARMSS0_CPU1245
-
-void release_resources_for_core_shutdown(void)
-{
- struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- struct ti_sci_dev_ops *dev_ops = &ti_sci->ops.dev_ops;
- struct ti_sci_proc_ops *proc_ops = &ti_sci->ops.proc_ops;
- int ret;
- u32 i;
-
- const u32 put_device_ids[] = {
- AM6_DEV_MCU_RTI0,
- AM6_DEV_MCU_RTI1,
- };
-
- /* Iterate through list of devices to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
- u32 id = put_device_ids[i];
-
- ret = dev_ops->put_device(ti_sci, id);
- if (ret)
- panic("Failed to put device %u (%d)\n", id, ret);
- }
-
- const u32 put_core_ids[] = {
- AM6_DEV_MCU_ARMSS0_CPU1,
- AM6_DEV_MCU_ARMSS0_CPU0,/* Handle CPU0 after CPU1 */
- };
-
- /* Iterate through list of cores to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
- u32 id = put_core_ids[i];
-
- /*
-* Queue up the core shutdown request. Note that this call
-* needs to be followed up by an actual invocation of an WFE
-* or WFI CPU instruction.
-*/
- ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
-
[PATCH v2 08/12] arm: mach-k3: Add weak do_board_detect() to common file
This matches how it was done for pre-K3 TI platforms and it allows
us to move the forward declaration out of sys_proto.h.
It also removes the need for K3_BOARD_DETECT as one is free to simply
override the weak function in their board files as needed.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 5 -
arch/arm/mach-k3/am642_init.c | 4 ++--
arch/arm/mach-k3/am654_init.c | 4 ++--
arch/arm/mach-k3/common.c | 10 ++
arch/arm/mach-k3/common.h | 2 ++
arch/arm/mach-k3/include/mach/sys_proto.h | 2 --
arch/arm/mach-k3/j721e_init.c | 8
board/ti/common/Kconfig | 1 -
8 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 7edbac26ccc..a8c3a593d57 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -187,11 +187,6 @@ config K3_X509_SWRV
help
SWRV for X509 certificate used for boot images
-config K3_BOARD_DETECT
- bool "Support for Board detection"
- help
- Support for board detection.
-
source "board/ti/am65x/Kconfig"
source "board/ti/am64x/Kconfig"
source "board/ti/am62x/Kconfig"
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index c7720cbaf35..9a34a3f9451 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -100,8 +100,8 @@ void do_dt_magic(void)
{
int ret, rescan;
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
/*
* Board detection has been done.
diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c
index 12d74635cb0..5a9a780f521 100644
--- a/arch/arm/mach-k3/am654_init.c
+++ b/arch/arm/mach-k3/am654_init.c
@@ -245,8 +245,8 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
#if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 4f2e14c3105..115f5959734 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -636,3 +636,13 @@ int misc_init_r(void)
return 0;
}
+
+/**
+ * do_board_detect() - Detect board description
+ *
+ * Function to detect board description. This is expected to be
+ * overridden in the SoC family board file where desired.
+ */
+void __weak do_board_detect(void)
+{
+}
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index 531be0be54c..130f5021123 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -35,3 +35,5 @@ void mmr_unlock(phys_addr_t base, u32 partition);
bool is_rom_loaded_sysfw(struct rom_extended_boot_data *data);
enum k3_device_type get_device_type(void);
void ti_secure_image_post_process(void **p_image, size_t *p_size);
+struct ti_sci_handle *get_ti_sci_handle(void);
+void do_board_detect(void);
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 8cc75b636b5..939de0f79b4 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -10,8 +10,6 @@
void sdelay(unsigned long loops);
u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
u32 bound);
-struct ti_sci_handle *get_ti_sci_handle(void);
-int do_board_detect(void);
int fdt_disable_node(void *blob, char *node_path);
void k3_spl_init(void);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b5a69255f76..3fda2dfaa1b 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -160,8 +160,8 @@ void do_dt_magic(void)
int ret, rescan, mmc_dev = -1;
static struct mmc *mmc;
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
/*
* Board detection has been done.
@@ -287,8 +287,8 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
- if (IS_ENABLED(CONFIG_K3_BOARD_DETECT))
- do_board_detect();
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
#if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index f03357cc751..49edd98014a 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -1,6 +1,5 @@
config TI_I2C_BOARD_
[PATCH v2 10/12] arm: mach-k3: Move sdelay() and wait_on_value() declaration
These probably should be in some system wide header given their use. Until then move them out of K3 sys_proto.h so we can finish cleaning that header out. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/include/mach/sys_proto.h | 4 drivers/ram/k3-am654-ddrss.c | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h b/arch/arm/mach-k3/include/mach/sys_proto.h index bbe57718e1a..4b4e2a5be39 100644 --- a/arch/arm/mach-k3/include/mach/sys_proto.h +++ b/arch/arm/mach-k3/include/mach/sys_proto.h @@ -7,10 +7,6 @@ #ifndef _SYS_PROTO_H_ #define _SYS_PROTO_H_ -void sdelay(unsigned long loops); -u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr, - u32 bound); - void k3_spl_init(void); void k3_mem_init(void); bool check_rom_loaded_sysfw(void); diff --git a/drivers/ram/k3-am654-ddrss.c b/drivers/ram/k3-am654-ddrss.c index 4453c247b29..adac14f9464 100644 --- a/drivers/ram/k3-am654-ddrss.c +++ b/drivers/ram/k3-am654-ddrss.c @@ -18,6 +18,10 @@ #include #include "k3-am654-ddrss.h" +void sdelay(unsigned long loops); +u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr, + u32 bound); + #define LDELAY 1 /* DDRSS PHY configuration register fixed values */ -- 2.39.2
[PATCH v2 09/12] arm: mach-k3: Remove unused fdt_disable_node()
This function is not used currently; remove it.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c | 19 ---
arch/arm/mach-k3/include/mach/sys_proto.h | 1 -
2 files changed, 20 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 115f5959734..9f2f5a98771 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -395,25 +395,6 @@ int fdt_fixup_msmc_ram(void *blob, char *parent_path, char
*node_name)
return 0;
}
-int fdt_disable_node(void *blob, char *node_path)
-{
- int offs;
- int ret;
-
- offs = fdt_path_offset(blob, node_path);
- if (offs < 0) {
- printf("Node %s not found.\n", node_path);
- return offs;
- }
- ret = fdt_setprop_string(blob, offs, "status", "disabled");
- if (ret < 0) {
- printf("Could not add status property to node %s: %s\n",
- node_path, fdt_strerror(ret));
- return ret;
- }
- return 0;
-}
-
#if defined(CONFIG_OF_SYSTEM_SETUP)
int ft_system_setup(void *blob, struct bd_info *bd)
{
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 939de0f79b4..bbe57718e1a 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -10,7 +10,6 @@
void sdelay(unsigned long loops);
u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
u32 bound);
-int fdt_disable_node(void *blob, char *node_path);
void k3_spl_init(void);
void k3_mem_init(void);
--
2.39.2
[PATCH v2 04/12] configs: j721x_evm: Remove unneeded check for SYS_K3_SPL_ATF
The TARGET_x_R5_EVM check is already enough to limit these defines to
only the correct builds. Remove the extra outer check.
Signed-off-by: Andrew Davis
---
board/ti/j721e/j721e.env | 2 --
board/ti/j721s2/j721s2.env | 2 --
2 files changed, 4 deletions(-)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 446395adfa5..f442d155842 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -21,7 +21,6 @@ args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
-#if CONFIG_SYS_K3_SPL_ATF
#if CONFIG_TARGET_J721E_R5_EVM
addr_mcur5f0_0load=0x8900
name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw
@@ -29,7 +28,6 @@ name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw
addr_mcur5f0_0load=0x8900
name_mcur5f0_0fw=/lib/firmware/j7200-mcu-r5f0_0-fw
#endif
-#endif
boot=mmc
mmcdev=1
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 2152f8849f9..f4467770e40 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -25,12 +25,10 @@ boot=mmc
mmcdev=1
bootpart=1:2
bootdir=/boot
-#if CONFIG_SYS_K3_SPL_ATF
#if CONFIG_TARGET_J721S2_R5_EVM
addr_mcur5f0_0load=0x8900
name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw
#endif
-#endif
rd_spec=-
init_mmc=run args_all args_mmc
get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
--
2.39.2
[PATCH v2 03/12] soc: soc_ti_k3: Use hardware.h to remove definition duplication
The K3 JTAG and SoC ID information is already stored in the K3 arch
hardware file, include that and use its definitions here.
Signed-off-by: Andrew Davis
---
drivers/soc/Kconfig | 2 +-
drivers/soc/soc_ti_k3.c | 30 +-
2 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index acf555baaec..85dac9de78a 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -10,7 +10,7 @@ config SOC_DEVICE
specific device variant in use.
config SOC_DEVICE_TI_K3
- depends on SOC_DEVICE
+ depends on SOC_DEVICE && ARCH_K3
bool "Enable SoC Device ID driver for TI K3 SoCs"
help
This allows Texas Instruments Keystone 3 SoCs to identify
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 8af0ac70519..42430d79a7a 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -8,21 +8,9 @@
#include
#include
+#include
#include
-#define AM65X 0xbb5a
-#define J721E 0xbb64
-#define J7200 0xbb6d
-#define AM64X 0xbb38
-#define J721S2 0xbb75
-#define AM62X 0xbb7e
-#define AM62AX 0xbb8d
-
-#define JTAG_ID_VARIANT_SHIFT 28
-#define JTAG_ID_VARIANT_MASK (0xf << 28)
-#define JTAG_ID_PARTNO_SHIFT 12
-#define JTAG_ID_PARTNO_MASK(0x << 12)
-
struct soc_ti_k3_plat {
const char *family;
const char *revision;
@@ -36,25 +24,25 @@ static const char *get_family_string(u32 idreg)
soc = (idreg & JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
switch (soc) {
- case AM65X:
+ case JTAG_ID_PARTNO_AM65X:
family = "AM65X";
break;
- case J721E:
+ case JTAG_ID_PARTNO_J721E:
family = "J721E";
break;
- case J7200:
+ case JTAG_ID_PARTNO_J7200:
family = "J7200";
break;
- case AM64X:
+ case JTAG_ID_PARTNO_AM64X:
family = "AM64X";
break;
- case J721S2:
+ case JTAG_ID_PARTNO_J721S2:
family = "J721S2";
break;
- case AM62X:
+ case JTAG_ID_PARTNO_AM62X:
family = "AM62X";
break;
- case AM62AX:
+ case JTAG_ID_PARTNO_AM62AX:
family = "AM62AX";
break;
default:
@@ -81,7 +69,7 @@ static const char *get_rev_string(u32 idreg)
soc = (idreg & JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
switch (soc) {
- case J721E:
+ case JTAG_ID_PARTNO_J721E:
if (rev > ARRAY_SIZE(j721e_rev_string_map))
goto bail;
return j721e_rev_string_map[rev];
--
2.39.2
[PATCH v2 02/12] arm: mach-k3: Move J721e SoC detection out of common section
This belongs in the J721e specific file as it is the only place
this is used. Any board level users should use the SOC driver.
While here, move the J721e and J7200 SoC IDs out of sys_proto.h
and into hardware.h. Add the rest of the SoC IDs for completeness
and later use.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c | 20
arch/arm/mach-k3/common.h | 3 ---
arch/arm/mach-k3/include/mach/hardware.h | 8
arch/arm/mach-k3/include/mach/sys_proto.h | 3 ---
arch/arm/mach-k3/j721e_init.c | 20
5 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 6870f13c520..6e084de692c 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -488,26 +488,6 @@ int print_cpuinfo(void)
}
#endif
-bool soc_is_j721e(void)
-{
- u32 soc;
-
- soc = (readl(CTRLMMR_WKUP_JTAG_ID) &
- JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
-
- return soc == J721E;
-}
-
-bool soc_is_j7200(void)
-{
- u32 soc;
-
- soc = (readl(CTRLMMR_WKUP_JTAG_ID) &
- JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
-
- return soc == J7200;
-}
-
#ifdef CONFIG_ARM64
void board_prep_linux(struct bootm_headers *images)
{
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index 8f38fcef7f0..531be0be54c 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -9,9 +9,6 @@
#include
#include
-#define J721E 0xbb64
-#define J7200 0xbb6d
-
struct fwl_data {
const char *name;
u16 fwl_id;
diff --git a/arch/arm/mach-k3/include/mach/hardware.h
b/arch/arm/mach-k3/include/mach/hardware.h
index 2c60ef85432..f87b4c6e5a7 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -36,6 +36,14 @@
#define JTAG_ID_VARIANT_MASK (0xf << 28)
#define JTAG_ID_PARTNO_SHIFT 12
#define JTAG_ID_PARTNO_MASK(0x << 12)
+#define JTAG_ID_PARTNO_AM65X 0xbb5a
+#define JTAG_ID_PARTNO_J721E 0xbb64
+#define JTAG_ID_PARTNO_J7200 0xbb6d
+#define JTAG_ID_PARTNO_AM64X 0xbb38
+#define JTAG_ID_PARTNO_J721S2 0xbb75
+#define JTAG_ID_PARTNO_AM62X 0xbb7e
+#define JTAG_ID_PARTNO_AM62AX 0xbb8d
+
#define K3_SEC_MGR_SYS_STATUS 0x44234100
#define SYS_STATUS_DEV_TYPE_SHIFT 0
#define SYS_STATUS_DEV_TYPE_MASK (0xf)
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 0b5d606eaa2..d5d4b787b7d 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -15,9 +15,6 @@ int do_board_detect(void);
void release_resources_for_core_shutdown(void);
int fdt_disable_node(void *blob, char *node_path);
-bool soc_is_j721e(void);
-bool soc_is_j7200(void);
-
void k3_spl_init(void);
void k3_mem_init(void);
bool check_rom_loaded_sysfw(void);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 9cae3ac67e9..432cbc6a992 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -63,6 +63,26 @@ struct fwl_data cbass_hc_cfg0_fwls[] = {
};
#endif
+bool soc_is_j721e(void)
+{
+ u32 soc;
+
+ soc = (readl(CTRLMMR_WKUP_JTAG_ID) &
+ JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
+
+ return soc == JTAG_ID_PARTNO_J721E;
+}
+
+bool soc_is_j7200(void)
+{
+ u32 soc;
+
+ soc = (readl(CTRLMMR_WKUP_JTAG_ID) &
+ JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
+
+ return soc == JTAG_ID_PARTNO_J7200;
+}
+
static void ctrl_mmr_unlock(void)
{
/* Unlock all WKUP_CTRL_MMR0 module registers */
--
2.39.2
[PATCH v2 05/12] configs: j721s2_evm.h: Remove refrences to J7200 EVM
The J7200 EVM will not include this file, this J7200 checks look to be a copy/paste errora from j721e_evm.h, which J7200 *can* include. Signed-off-by: Andrew Davis --- include/configs/j721s2_evm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h index 2fa93b79614..1e0da9f96c5 100644 --- a/include/configs/j721s2_evm.h +++ b/include/configs/j721s2_evm.h @@ -16,7 +16,7 @@ #define CFG_SYS_SDRAM_BASE10x88000 /* SPL Loader Configuration */ -#if defined(CONFIG_TARGET_J721S2_A72_EVM) || defined(CONFIG_TARGET_J7200_A72_EVM) +#if defined(CONFIG_TARGET_J721S2_A72_EVM) #define CFG_SYS_UBOOT_BASE 0x5028 /* Image load address in RAM for DFU boot*/ #else -- 2.39.2
[PATCH v2 00/12] Remove K3 misc sys_proto.h header
Hello all,
Some minor cleanups with end patch removing sys_proto.h.
Why? Becouse I don't like headers of "miscellaneous".
Thanks,
Andrew
Changes from v1:
- Added reviewed by tag
- Rebased on latest
Andrew Davis (12):
arm: mach-k3: Move MSMC fixup to SoC level
arm: mach-k3: Move J721e SoC detection out of common section
soc: soc_ti_k3: Use hardware.h to remove definition duplication
configs: j721x_evm: Remove unneeded check for SYS_K3_SPL_ATF
configs: j721s2_evm.h: Remove refrences to J7200 EVM
arm: mach-k3: Make release_resources_for_core_shutdown() common
arm: mach-k3: Move sysfw-loader.h out of mach includes
arm: mach-k3: Add weak do_board_detect() to common file
arm: mach-k3: Remove unused fdt_disable_node()
arm: mach-k3: Move sdelay() and wait_on_value() declaration
arm: mach-k3: Move J721s2 SPL init functions to mach-k3
arm: mach-k3: Remove empty sys_proto.h include
arch/arm/mach-k3/Kconfig | 5 -
arch/arm/mach-k3/am625_init.c | 2 +-
arch/arm/mach-k3/am62a7_init.c| 2 +-
arch/arm/mach-k3/am642_init.c | 59 +
arch/arm/mach-k3/am654_init.c | 58 +
arch/arm/mach-k3/common.c | 88 +++--
arch/arm/mach-k3/common.h | 5 +-
arch/arm/mach-k3/include/mach/am62_hardware.h | 8 ++
.../arm/mach-k3/include/mach/am62a_hardware.h | 8 ++
arch/arm/mach-k3/include/mach/am64_hardware.h | 24
arch/arm/mach-k3/include/mach/am6_hardware.h | 19 +++
arch/arm/mach-k3/include/mach/hardware.h | 8 ++
.../arm/mach-k3/include/mach/j721e_hardware.h | 19 +++
.../mach-k3/include/mach/j721s2_hardware.h| 19 +++
arch/arm/mach-k3/include/mach/sys_proto.h | 25
arch/arm/mach-k3/j721e_init.c | 86 -
arch/arm/mach-k3/j721s2_init.c| 121 ++
arch/arm/mach-k3/security.c | 1 -
arch/arm/mach-k3/sysfw-loader.c | 1 -
.../mach-k3/{include/mach => }/sysfw-loader.h | 0
board/siemens/iot2050/board.c | 12 +-
board/ti/am62ax/evm.c | 1 -
board/ti/am62x/evm.c | 1 -
board/ti/am64x/evm.c | 1 -
board/ti/am65x/evm.c | 20 ---
board/ti/common/Kconfig | 1 -
board/ti/j721e/evm.c | 13 +-
board/ti/j721e/j721e.env | 2 -
board/ti/j721s2/evm.c | 81
board/ti/j721s2/j721s2.env| 2 -
configs/am65x_evm_a53_defconfig | 2 +-
configs/am65x_hs_evm_a53_defconfig| 2 +-
configs/iot2050_pg1_defconfig | 1 +
configs/iot2050_pg2_defconfig | 1 +
configs/j7200_evm_a72_defconfig | 1 +
configs/j7200_hs_evm_a72_defconfig| 1 +
configs/j721e_evm_a72_defconfig | 1 +
configs/j721e_hs_evm_a72_defconfig| 1 +
configs/j721s2_evm_a72_defconfig | 2 +-
configs/j721s2_hs_evm_a72_defconfig | 2 +-
drivers/phy/phy-ti-am654.c| 1 -
drivers/ram/k3-am654-ddrss.c | 5 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/soc_ti_k3.c | 30 ++---
include/configs/j721s2_evm.h | 2 +-
45 files changed, 283 insertions(+), 463 deletions(-)
delete mode 100644 arch/arm/mach-k3/include/mach/sys_proto.h
rename arch/arm/mach-k3/{include/mach => }/sysfw-loader.h (100%)
--
2.39.2
[PATCH v2 07/12] arm: mach-k3: Move sysfw-loader.h out of mach includes
This header is only used locally by K3 init files, no need to have it
up with the global mach includes. Move into local includes.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am625_init.c | 2 +-
arch/arm/mach-k3/am62a7_init.c | 2 +-
arch/arm/mach-k3/am642_init.c | 2 +-
arch/arm/mach-k3/am654_init.c | 2 +-
arch/arm/mach-k3/j721e_init.c | 2 +-
arch/arm/mach-k3/j721s2_init.c | 2 +-
arch/arm/mach-k3/{include/mach => }/sysfw-loader.h | 0
7 files changed, 6 insertions(+), 6 deletions(-)
rename arch/arm/mach-k3/{include/mach => }/sysfw-loader.h (100%)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index a91c15ca4e1..026c4f9c02d 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -9,7 +9,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include "common.h"
#include
#include
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index 02da24a3d6f..a89a9b4ae3a 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include "common.h"
#include
#include
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 86aced54646..c7720cbaf35 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include
#include "common.h"
#include
diff --git a/arch/arm/mach-k3/am654_init.c b/arch/arm/mach-k3/am654_init.c
index abd0c0bccbc..12d74635cb0 100644
--- a/arch/arm/mach-k3/am654_init.c
+++ b/arch/arm/mach-k3/am654_init.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include
#include "common.h"
#include
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 6d848239399..b5a69255f76 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include "common.h"
#include
#include
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb95984c1ab..4785a747bf3 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include "sysfw-loader.h"
#include "common.h"
#include
#include
diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h
b/arch/arm/mach-k3/sysfw-loader.h
similarity index 100%
rename from arch/arm/mach-k3/include/mach/sysfw-loader.h
rename to arch/arm/mach-k3/sysfw-loader.h
--
2.39.2
[PATCH v2 01/12] arm: mach-k3: Move MSMC fixup to SoC level
The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.
We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.
Signed-off-by: Andrew Davis
Reviewed-by: Christian Gmeiner
---
arch/arm/mach-k3/common.c | 16
arch/arm/mach-k3/include/mach/sys_proto.h | 1 -
board/siemens/iot2050/board.c | 11 +--
board/ti/am65x/evm.c | 18 --
board/ti/j721e/evm.c | 11 +--
board/ti/j721s2/evm.c | 16
configs/am65x_evm_a53_defconfig | 2 +-
configs/am65x_hs_evm_a53_defconfig| 2 +-
configs/iot2050_pg1_defconfig | 1 +
configs/iot2050_pg2_defconfig | 1 +
configs/j7200_evm_a72_defconfig | 1 +
configs/j7200_hs_evm_a72_defconfig| 1 +
configs/j721e_evm_a72_defconfig | 1 +
configs/j721e_hs_evm_a72_defconfig| 1 +
configs/j721s2_evm_a72_defconfig | 2 +-
configs/j721s2_hs_evm_a72_defconfig | 2 +-
16 files changed, 28 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index a2adb791f6c..6870f13c520 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -386,6 +386,22 @@ int fdt_disable_node(void *blob, char *node_path)
return 0;
}
+#if defined(CONFIG_OF_SYSTEM_SETUP)
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+ int ret;
+
+ ret = fdt_fixup_msmc_ram(blob, "/bus@10", "sram@7000");
+ if (ret < 0)
+ ret = fdt_fixup_msmc_ram(blob, "/interconnect@10",
+"sram@7000");
+ if (ret)
+ printf("%s: fixing up msmc ram failed %d\n", __func__, ret);
+
+ return ret;
+}
+#endif
+
#endif
#ifndef CONFIG_SYSRESET
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 3d3d90d02d6..0b5d606eaa2 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -11,7 +11,6 @@ void sdelay(unsigned long loops);
u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
u32 bound);
struct ti_sci_handle *get_ti_sci_handle(void);
-int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name);
int do_board_detect(void);
void release_resources_for_core_shutdown(void);
int fdt_disable_node(void *blob, char *node_path);
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index df705b7c971..1ba3e90c6fc 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -482,19 +482,10 @@ fixup_error:
int ft_board_setup(void *blob, struct bd_info *bd)
{
- int ret;
-
- ret = fdt_fixup_msmc_ram(blob, "/bus@10", "sram@7000");
- if (ret < 0)
- ret = fdt_fixup_msmc_ram(blob, "/interconnect@10",
-"sram@7000");
- if (ret)
- pr_err("%s: fixing up msmc ram failed %d\n", __func__, ret);
-
if (board_is_m2())
m2_fdt_fixup(blob);
- return ret;
+ return 0;
}
#endif
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index b266ccb4b82..4053b8333cf 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -101,24 +101,6 @@ int board_fit_config_name_match(const char *name)
}
#endif
-#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
-int ft_board_setup(void *blob, struct bd_info *bd)
-{
- int ret;
-
- ret = fdt_fixup_msmc_ram(blob, "/bus@10", "sram@7000");
- if (ret < 0)
- ret = fdt_fixup_msmc_ram(blob, "/interconnect@10",
-"sram@7000");
- if (ret) {
- printf("%s: fixing up msmc ram failed %d\n", __func__, ret);
- return ret;
- }
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_TI_I2C_BOARD_DETECT
int do_board_detect(void)
{
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index d4e672a7acd..00ce009d3e8 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -144,18 +144,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
- int ret;
-
- ret = fdt_fixup_msmc_ram(blob, "/bus@10", "sram@7000");
- if (ret < 0)
- ret = fdt_fixup_msmc_ram(blob, "/interconnect@10",
-"sram@7000");
- if (ret)
- printf("%s:
[BUG] issues with new bootflow, uefi and virtio
Hi, I am hitting an issue with the new bootflow when booting with UEFI from a virtio device on Qemu Arm. It seems the device number computation in efiload_read_file() does not work in the general virtio case, where it will pick the virtio device number instead of the block device index. On Qemu arm virt machine, many virtio mmio devices are provisioned in the memory map and no assumption can be made on the number of the actual virtio device in use in the general case. This is an extract of the output of `dm tree' on this platform, focused on the virtio device from which I would like to boot: virtio31 [ + ] virtio-mmio |-- virtio_mmio@a003e00 blk0 [ + ] virtio-blk | |-- virtio-blk#31 partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1 partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2 bootdev2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev In this extract the actual virtio device number is 31, as will be picked by efiload_read_file(), but the desired block device index is zero, as would be used with e.g. `ls virtio 0'. This can be reproduced for example with Buildroot qemu_aarch64_ebbr_defconfig or qemu_arm_ebbr_defconfig and updating the U-Boot version to v2023.04. This was working properly with U-Boot versions up to v2023.01. This seems to be very specific to virtio, as the numbers align much more nicely for e.g. USB mass storage or NVMe. To help debugging, the following patch forces the device number to zero in the case of virtio, which allows to boot again with UEFI and virtio on Qemu Arm. Hopefully this should give a hint of what is going on. I tried to create a fix by looking for the first child device of UCLASS_BLK, and use its devnum instead in the case of virtio. Sadly, I am not able to confirm if this is a proper fix as I am hitting other boot issues in the case of multiple boot devices of the same class it seems... Vincent. [1]: https://buildroot.org --- boot/bootmeth_efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 6a97ac02ff5..e5b0d8614ff 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -117,7 +117,9 @@ static int efiload_read_file(struct blk_desc *desc, struct bootflow *bflow) * this can go away. */ media_dev = dev_get_parent(bflow->dev); - snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev)); + snprintf(devnum_str, sizeof(devnum_str), "%x", +device_get_uclass_id(media_dev) == UCLASS_VIRTIO ? 0 : +dev_seq(media_dev)); strlcpy(dirname, bflow->fname, sizeof(dirname)); last_slash = strrchr(dirname, '/'); -- 2.39.2
Re: [PATCH 2/4] net: e1000: move all rx data structures to hw instance
On Wed, Apr 05, 2023 at 09:50:08AM +0200, Christian Gmeiner wrote: > Hi all > > > > > Preparation for per driver instance allocated data structures. > > > > Signed-off-by: Christian Gmeiner > > gentle ping - what can I do better to get some feedback, RBs, etc > faster? This experience is > quite frustrating and it happens for me from time to time for U-Boot patches > :( > > Patch 1 of this series got a RB few days ago and the others are still open. Unfortunately there's a number of areas where we just don't have a lot of maintainers. Now that v2023.04 is out I expect to be picking up assorted patches that look right, soon. Sorry for the delay. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote: > Hi Tom, > > On Tue, 4 Apr 2023, 02:17 Tom Rini, wrote: > > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote: > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini wrote: > > > > > > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: > > > > > > > > > > > The current EFI implementation has a strange quirk where it watches > > > > > > loaded files and uses the last-loaded file to determine the device > > that > > > > > > is being booted from. > > > > > > > > > > > > This is confusing with bootstd, where multiple options may exist. > > Even > > > > > > loading a device tree will cause it to go wrong. There is no API > > for > > > > > > passing this information, since the only entry into booting an EFI > > image > > > > > > is the 'bootefi' command. > > > > > > > > > > > > To work around this, call efi_set_bootdev() for EFI images, if > > possible, > > > > > > just before booting. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > Shouldn't this all be a simple wrapper around the EFI Standard > > > > > BootDeviceOrder or whatever that's called? > > > > > > > > I think you are referring to boot manager, which isn't used here. This > > > > is replicating the existing distroboot functionality in standard boot. > > > > > > The distroboot functionality *was* trying to behave like the EFI spec > > > expects the bootmanager to behave. Unfortunately I haven't had time to > > > review the distroboot patches closely, but back when this started, my > > point > > > was that EFI doesn't need anything. Whenever the EFI flow is added > > bootstd > > > should 'just' call the bootmanager. > > > > Yes, this. We're trying make things cleaner overall, so the EFI portion > > of bootstd distro boot should just be "call EFI bootmanager" as that has > > a well defined standard way to specify what devices to try in what > > order. > > > > We already call bootmgr in standard boot, if it is enabled. > > But I am not sure how widely that is used... > > This patch is about corner cases in the distro scripts. If we are to turn > these down we do need to try to do the same thing. We probably need some distro people to chime in about what they're doing / expecting at this point in time? I would have sworn that the long term part of EFI "distro boot" would be using bootmgr since that's the standards based way to set boot order. And if you don't have a device tree in U-Boot, and want the distribution one, aren't you then using something like grub which has a "dtb" keyword to handle that on its own? That's not saying that "distro boot" doesn't need to load the device tree, for when it's then calling booti/bootz/bootm, but not for the EFI case these days? Or no? -- Tom signature.asc Description: PGP signature
[PATCH] fs: yaffs2: Make yaffsfs_deviceList static
yaffsfs_deviceList is only referenced in yaffsfs.c Signed-off-by: Bin Meng --- fs/yaffs2/yaffsfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/yaffs2/yaffsfs.c b/fs/yaffs2/yaffsfs.c index 510faaeed1..d615f02d3f 100644 --- a/fs/yaffs2/yaffsfs.c +++ b/fs/yaffs2/yaffsfs.c @@ -468,7 +468,7 @@ static int yaffsfs_alt_dir_path(const YCHAR *path, YCHAR **ret_path) return 0; } -LIST_HEAD(yaffsfs_deviceList); +static LIST_HEAD(yaffsfs_deviceList); /* * yaffsfs_FindDevice -- 2.34.1
[PATCH] nand: raw: octeontx: Make list static
octeontx_bch_devices and octeontx_pci_nand_deferred_devices are only
referenced in the files where they are defined. Make them static.
Signed-off-by: Bin Meng
---
drivers/mtd/nand/raw/octeontx_bch.c | 2 +-
drivers/mtd/nand/raw/octeontx_nand.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/octeontx_bch.c
b/drivers/mtd/nand/raw/octeontx_bch.c
index fc16b77416..056a685782 100644
--- a/drivers/mtd/nand/raw/octeontx_bch.c
+++ b/drivers/mtd/nand/raw/octeontx_bch.c
@@ -27,7 +27,7 @@
#include
#include "octeontx_bch.h"
-LIST_HEAD(octeontx_bch_devices);
+static LIST_HEAD(octeontx_bch_devices);
static unsigned int num_vfs = BCH_NR_VF;
static void *bch_pf;
static void *bch_vf;
diff --git a/drivers/mtd/nand/raw/octeontx_nand.c
b/drivers/mtd/nand/raw/octeontx_nand.c
index 1ffadad9ca..65a03d22c1 100644
--- a/drivers/mtd/nand/raw/octeontx_nand.c
+++ b/drivers/mtd/nand/raw/octeontx_nand.c
@@ -354,7 +354,7 @@ struct octeontx_probe_device {
static struct bch_vf *bch_vf;
/** Deferred devices due to BCH not being ready */
-LIST_HEAD(octeontx_pci_nand_deferred_devices);
+static LIST_HEAD(octeontx_pci_nand_deferred_devices);
/** default parameters used for probing chips */
#define MAX_ONFI_MODE 5
--
2.34.1
[PATCH] dm: core: Make aliases_lookup static
aliases_lookup is only referenced in of_access.c Signed-off-by: Bin Meng --- drivers/core/of_access.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c index 85f7da5a49..81a307992c 100644 --- a/drivers/core/of_access.c +++ b/drivers/core/of_access.c @@ -33,7 +33,7 @@ DECLARE_GLOBAL_DATA_PTR; /* list of struct alias_prop aliases */ -LIST_HEAD(aliases_lookup); +static LIST_HEAD(aliases_lookup); /* "/aliaes" node */ static struct device_node *of_aliases; -- 2.34.1
[PATCH 5/5] efi: loader: Make efi_runtime_mmio static
efi_runtime_mmio is only referenced in efi_boottime.c
Signed-off-by: Bin Meng
---
lib/efi_loader/efi_runtime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index cee96bfc7f..bf54d6ad87 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -32,7 +32,7 @@ struct efi_runtime_mmio_list {
};
/* This list contains all runtime available mmio regions */
-LIST_HEAD(efi_runtime_mmio);
+static LIST_HEAD(efi_runtime_mmio);
static efi_status_t __efi_runtime EFIAPI efi_unimplemented(void);
--
2.34.1
[PATCH 4/5] efi: loader: Make efi_mem static
efi_mem is only referenced in efi_memory.c
Signed-off-by: Bin Meng
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index b7bee98f79..219b520a0d 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -33,7 +33,7 @@ struct efi_mem_list {
#define EFI_CARVE_OVERLAPS_NONRAM -3
/* This list contains all memory map items */
-LIST_HEAD(efi_mem);
+static LIST_HEAD(efi_mem);
#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
void *efi_bounce_buffer;
--
2.34.1
[PATCH 3/5] efi: loader: Make efi_event_queue and efi_register_notify_events static
efi_event_queue and efi_register_notify_events are only referenced
in efi_boottime.c
Signed-off-by: Bin Meng
---
include/efi_loader.h | 3 ---
lib/efi_loader/efi_boottime.c | 4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 1542b4b625..0a2083c39a 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -509,9 +509,6 @@ struct efi_register_notify_event {
struct list_head handles;
};
-/* List of all events registered by RegisterProtocolNotify() */
-extern struct list_head efi_register_notify_events;
-
/* called at pre-initialization */
int efi_init_early(void);
/* Initialize efi execution environment */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index caaab685ee..d5065f296a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -35,7 +35,7 @@ LIST_HEAD(efi_obj_list);
__efi_runtime_data LIST_HEAD(efi_events);
/* List of queued events */
-LIST_HEAD(efi_event_queue);
+static LIST_HEAD(efi_event_queue);
/* Flag to disable timer activity in ExitBootServices() */
static bool timers_enabled = true;
@@ -44,7 +44,7 @@ static bool timers_enabled = true;
bool efi_st_keep_devices;
/* List of all events registered by RegisterProtocolNotify() */
-LIST_HEAD(efi_register_notify_events);
+static LIST_HEAD(efi_register_notify_events);
/* Handle of the currently executing image */
static efi_handle_t current_image;
--
2.34.1
[PATCH 2/5] efi: selftest: Make load_file() and load_file2() static
load_file() and load_file2() are only referenced in
efi_selftest_load_file.c
Signed-off-by: Bin Meng
---
lib/efi_selftest/efi_selftest_load_file.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_load_file.c
b/lib/efi_selftest/efi_selftest_load_file.c
index 8784a76172..14df761172 100644
--- a/lib/efi_selftest/efi_selftest_load_file.c
+++ b/lib/efi_selftest/efi_selftest_load_file.c
@@ -206,11 +206,11 @@ static efi_status_t decompress(u8 **image)
* @buffer_size: (required) buffer size
* @buffer:buffer to which the file is to be loaded
*/
-efi_status_t EFIAPI load_file(struct efi_load_file_protocol *this,
- struct efi_device_path *file_path,
- bool boot_policy,
- efi_uintn_t *buffer_size,
- void *buffer)
+static efi_status_t EFIAPI load_file(struct efi_load_file_protocol *this,
+struct efi_device_path *file_path,
+bool boot_policy,
+efi_uintn_t *buffer_size,
+void *buffer)
{
++load_file_call_count;
if (memcmp(file_path, dp_lf_file_remainder,
@@ -243,11 +243,11 @@ efi_status_t EFIAPI load_file(struct
efi_load_file_protocol *this,
* @buffer_size: (required) buffer size
* @buffer:buffer to which the file is to be loaded
*/
-efi_status_t EFIAPI load_file2(struct efi_load_file_protocol *this,
- struct efi_device_path *file_path,
- bool boot_policy,
- efi_uintn_t *buffer_size,
- void *buffer)
+static efi_status_t EFIAPI load_file2(struct efi_load_file_protocol *this,
+ struct efi_device_path *file_path,
+ bool boot_policy,
+ efi_uintn_t *buffer_size,
+ void *buffer)
{
++load_file2_call_count;
if (memcmp(file_path, dp_lf2_file_remainder,
--
2.34.1
[PATCH 1/5] efi: selftest: Make record static
record is only referenced in efi_selftest_exitbootservices.c
Signed-off-by: Bin Meng
---
lib/efi_selftest/efi_selftest_exitbootservices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_exitbootservices.c
b/lib/efi_selftest/efi_selftest_exitbootservices.c
index 11b43fdd90..b090ce74d2 100644
--- a/lib/efi_selftest/efi_selftest_exitbootservices.c
+++ b/lib/efi_selftest/efi_selftest_exitbootservices.c
@@ -27,7 +27,7 @@ struct notification_context {
static struct efi_boot_services *boottime;
static struct efi_event *efi_st_event_notify;
-struct notification_record record;
+static struct notification_record record;
struct notification_context context_before = {
.record = &record,
--
2.34.1
Re: [PATCH 08/12] arm: mach-k3: Add weak do_board_detect() to common file
On 4/2/23 5:44 AM, Christian Gmeiner wrote: Hi Andrew Am Do., 30. März 2023 um 22:30 Uhr schrieb Andrew Davis : This matches how it was done for pre-K3 TI platforms and it allows us to move the forward declaration out of sys_proto.h. It also removes the need to check for TI_I2C_BOARD_DETECT before calling this function, which might not be the right guard ifdef should a board use a different method for board detection. Signed-off-by: Andrew Davis This change is conflicting with what is u-boot/next: https://source.denx.de/u-boot/u-boot/-/commit/e44657ed744d1b4e216d8dda5d528ff0d0a6234e Thanks for the heads up, will rebase on latest and resend. Andrew
Re: [PATCH v3 00/19] Support android boot image v3/v4
On Mon, 06 Feb 2023 00:50:02 +0100, Safae Ouajih wrote: > * This is based on Roman Stratiienko's work to support boot image header > version 3 and 4. > > * This supports the new boot image headers v3, v4 and bootconfig feature. > https://source.android.com/docs/core/architecture/bootloader/boot-image-header > https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig > > - Tested on Amlogic Khadas vim3l, a reference board for Android Open Source > Project > https://www.khadas.com/vim3l > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH 2/2] sunxi: remove support for boot0 header reservation
In the early days of the Allwinner A64 U-Boot support, we relied on a vendor provided "boot0" binary to perform the DRAM initialisation. This replaced the SPL, and required to equip the U-Boot (proper) binary with a vendor specific header to be recognised as a valid boot0 payload. Fortunately these days are long gone (we gained SPL and DRAM support in early 2017!), and we never needed to use that hack on any later 64-bit Allwinner SoC. Since this is highly obsolete by now, remove the Kconfig option and the small pieces of "code" associated with it. Provide some comments about the purpose of the remaining boot0 code on the way. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/boot0.h | 18 +++--- arch/arm/mach-sunxi/Kconfig | 9 - configs/a64-olinuxino-emmc_defconfig| 1 - configs/a64-olinuxino_defconfig | 1 - configs/amarula_a64_relic_defconfig | 1 - configs/bananapi_m64_defconfig | 1 - configs/nanopi_a64_defconfig| 1 - configs/oceanic_5205_5inmfd_defconfig | 1 - configs/orangepi_win_defconfig | 1 - configs/pine64_plus_defconfig | 1 - configs/sopine_baseboard_defconfig | 1 - 11 files changed, 11 insertions(+), 25 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h b/arch/arm/include/asm/arch-sunxi/boot0.h index 59ea75a96b5..1a396f78488 100644 --- a/arch/arm/include/asm/arch-sunxi/boot0.h +++ b/arch/arm/include/asm/arch-sunxi/boot0.h @@ -1,13 +1,17 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Configuration settings for the Allwinner A64 (sun50i) CPU + * Very early code for Allwinner 64-bit CPUs. + * + * The BROM runs entirely in AArch32 state, so the SPL is entered using this + * ISA. Depending on the rest of the firmware stack, this may also be true + * for U-Boot proper. + * Provide the "RMR reset into 64-bit" sequence, in AArch32 machine language, + * so that we can have all of U-Boot in AArch64. The first instruction is + * chosen so that if the CPU is already using AArch64, it will skip the code + * and jump straight to the reset vector. */ -#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) && !defined(CONFIG_SPL_BUILD) -/* reserve space for BOOT0 header information */ - b reset - .space 1532 -#elif defined(CONFIG_ARM_BOOT_HOOK_RMR) +#ifdef CONFIG_ARM_BOOT_HOOK_RMR /* * Switch into AArch64 if needed. * Refer to arch/arm/mach-sunxi/rmr_switch.S for the original source. @@ -47,7 +51,7 @@ .word CONFIG_TEXT_BASE #endif .word fel_stash - . -#else +#else /* !CONFIG_ARM_BOOT_HOOK_RMR */ /* normal execution */ b reset #endif diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index b46667ce01e..0527b3863a7 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -386,15 +386,6 @@ config MACH_SUN8I default y if MACH_SUN8I_R40 default y if MACH_SUN8I_V3S -config RESERVE_ALLWINNER_BOOT0_HEADER - bool "reserve space for Allwinner boot0 header" - select ENABLE_ARM_SOC_BOOT0_HOOK - ---help--- - Prepend a 1536 byte (empty) header to the U-Boot image file, to be - filled with magic values post build. The Allwinner provided boot0 - blob relies on this information to load and execute U-Boot. - Only needed on 64-bit Allwinner boards so far when using boot0. - config ARM_BOOT_HOOK_RMR bool depends on ARM64 diff --git a/configs/a64-olinuxino-emmc_defconfig b/configs/a64-olinuxino-emmc_defconfig index 8ec9eb3e9c2..a5989fab1c6 100644 --- a/configs/a64-olinuxino-emmc_defconfig +++ b/configs/a64-olinuxino-emmc_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino-emmc" CONFIG_SPL=y CONFIG_MACH_SUN50I=y -CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SUPPORT_EMMC_BOOT=y diff --git a/configs/a64-olinuxino_defconfig b/configs/a64-olinuxino_defconfig index 16cef18beef..0b469c25d0d 100644 --- a/configs/a64-olinuxino_defconfig +++ b/configs/a64-olinuxino_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino" CONFIG_SPL=y CONFIG_MACH_SUN50I=y -CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SUN8I_EMAC=y diff --git a/configs/amarula_a64_relic_defconfig b/configs/amarula_a64_relic_defconfig index ae44b66d109..292af6e372e 100644 --- a/configs/amarula_a64_relic_defconfig +++ b/configs/amarula_a64_relic_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" CONFIG_SPL=y CONFIG_MACH_SUN50I=y -CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 # CONFIG_VIDEO_DE2 is not set # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/bananapi_m64_defconfig b/configs/bananapi_m64_defconfig in
[PATCH 1/2] sunxi: boot0.h: allow RVBAR MMIO address customisation
To switch the ARMv8 Allwinner SoCs into the 64-bit AArch64 ISA, we need to program the 64-bit start code address into an MMIO mapped register that shadows the architectural RVBAR register. This address is SoC specific, with just two versions out there so far. Now a third address emerged, on a *variant* of an existing SoC (H616). Change the boot0.h start code to make this address a Kconfig selectable option, to allow easier maintenance. We make this address user-visible (even though it shouldn't be), to allow putting this in defconfig. This is needed because there are apparently revisions of the H616 SoC out there using different addresses, so this becomes a per-board decision. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/boot0.h | 7 ++- arch/arm/mach-sunxi/Kconfig | 12 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h b/arch/arm/include/asm/arch-sunxi/boot0.h index 46b7e073b59..59ea75a96b5 100644 --- a/arch/arm/include/asm/arch-sunxi/boot0.h +++ b/arch/arm/include/asm/arch-sunxi/boot0.h @@ -39,11 +39,8 @@ .word 0xf57ff06f // isb sy .word 0xe320f003 // wfi .word 0xeafd // b @wfi -#ifndef CONFIG_SUN50I_GEN_H6 - .word 0x017000a0 // writeable RVBAR mapping address -#else - .word 0x09010040 // writeable RVBAR mapping address -#endif + + .word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR mapping addr #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 6417aee944b..b46667ce01e 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -110,6 +110,18 @@ config SUNXI_SRAM_ADDRESS Some newer SoCs map the boot ROM at address 0 instead and move the SRAM to a different address. +config SUNXI_RVBAR_ADDRESS + hex "RVBAR address" + depends on ARM64 + default 0x09010040 if SUN50I_GEN_H6 + default 0x017000a0 + ---help--- + The read-only RVBAR system register holds the address of the first + instruction to execute after a reset. Allwinner cores provide a + writable MMIO backing store for this register, to allow to set the + entry point when switching to AArch64. This store is on different + addresses, depending on the SoC. + config SUNXI_A64_TIMER_ERRATUM bool -- 2.25.1
Re: [PATCH 5/5] efi: loader: Make efi_runtime_mmio static
On Wed, Apr 05, 2023 at 08:15:19PM +0800, Bin Meng wrote:
> efi_runtime_mmio is only referenced in efi_boottime.c
>
> Signed-off-by: Bin Meng
> ---
>
> lib/efi_loader/efi_runtime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index cee96bfc7f..bf54d6ad87 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -32,7 +32,7 @@ struct efi_runtime_mmio_list {
> };
>
> /* This list contains all runtime available mmio regions */
> -LIST_HEAD(efi_runtime_mmio);
> +static LIST_HEAD(efi_runtime_mmio);
>
> static efi_status_t __efi_runtime EFIAPI efi_unimplemented(void);
>
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 4/5] efi: loader: Make efi_mem static
On Wed, Apr 05, 2023 at 08:15:18PM +0800, Bin Meng wrote:
> efi_mem is only referenced in efi_memory.c
>
> Signed-off-by: Bin Meng
> ---
>
> lib/efi_loader/efi_memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index b7bee98f79..219b520a0d 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -33,7 +33,7 @@ struct efi_mem_list {
> #define EFI_CARVE_OVERLAPS_NONRAM-3
>
> /* This list contains all memory map items */
> -LIST_HEAD(efi_mem);
> +static LIST_HEAD(efi_mem);
>
> #ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
> void *efi_bounce_buffer;
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 3/5] efi: loader: Make efi_event_queue and efi_register_notify_events static
On Wed, Apr 05, 2023 at 08:15:17PM +0800, Bin Meng wrote:
> efi_event_queue and efi_register_notify_events are only referenced
> in efi_boottime.c
>
> Signed-off-by: Bin Meng
> ---
>
> include/efi_loader.h | 3 ---
> lib/efi_loader/efi_boottime.c | 4 ++--
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 1542b4b625..0a2083c39a 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -509,9 +509,6 @@ struct efi_register_notify_event {
> struct list_head handles;
> };
>
> -/* List of all events registered by RegisterProtocolNotify() */
> -extern struct list_head efi_register_notify_events;
> -
> /* called at pre-initialization */
> int efi_init_early(void);
> /* Initialize efi execution environment */
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index caaab685ee..d5065f296a 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -35,7 +35,7 @@ LIST_HEAD(efi_obj_list);
> __efi_runtime_data LIST_HEAD(efi_events);
>
> /* List of queued events */
> -LIST_HEAD(efi_event_queue);
> +static LIST_HEAD(efi_event_queue);
>
> /* Flag to disable timer activity in ExitBootServices() */
> static bool timers_enabled = true;
> @@ -44,7 +44,7 @@ static bool timers_enabled = true;
> bool efi_st_keep_devices;
>
> /* List of all events registered by RegisterProtocolNotify() */
> -LIST_HEAD(efi_register_notify_events);
> +static LIST_HEAD(efi_register_notify_events);
>
> /* Handle of the currently executing image */
> static efi_handle_t current_image;
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 2/5] efi: selftest: Make load_file() and load_file2() static
On Wed, Apr 05, 2023 at 08:15:16PM +0800, Bin Meng wrote:
> load_file() and load_file2() are only referenced in
> efi_selftest_load_file.c
>
> Signed-off-by: Bin Meng
> ---
>
> lib/efi_selftest/efi_selftest_load_file.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/lib/efi_selftest/efi_selftest_load_file.c
> b/lib/efi_selftest/efi_selftest_load_file.c
> index 8784a76172..14df761172 100644
> --- a/lib/efi_selftest/efi_selftest_load_file.c
> +++ b/lib/efi_selftest/efi_selftest_load_file.c
> @@ -206,11 +206,11 @@ static efi_status_t decompress(u8 **image)
> * @buffer_size: (required) buffer size
> * @buffer: buffer to which the file is to be loaded
> */
> -efi_status_t EFIAPI load_file(struct efi_load_file_protocol *this,
> - struct efi_device_path *file_path,
> - bool boot_policy,
> - efi_uintn_t *buffer_size,
> - void *buffer)
> +static efi_status_t EFIAPI load_file(struct efi_load_file_protocol *this,
> + struct efi_device_path *file_path,
> + bool boot_policy,
> + efi_uintn_t *buffer_size,
> + void *buffer)
> {
> ++load_file_call_count;
> if (memcmp(file_path, dp_lf_file_remainder,
> @@ -243,11 +243,11 @@ efi_status_t EFIAPI load_file(struct
> efi_load_file_protocol *this,
> * @buffer_size: (required) buffer size
> * @buffer: buffer to which the file is to be loaded
> */
> -efi_status_t EFIAPI load_file2(struct efi_load_file_protocol *this,
> -struct efi_device_path *file_path,
> -bool boot_policy,
> -efi_uintn_t *buffer_size,
> -void *buffer)
> +static efi_status_t EFIAPI load_file2(struct efi_load_file_protocol *this,
> + struct efi_device_path *file_path,
> + bool boot_policy,
> + efi_uintn_t *buffer_size,
> + void *buffer)
> {
> ++load_file2_call_count;
> if (memcmp(file_path, dp_lf2_file_remainder,
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 1/5] efi: selftest: Make record static
On Wed, Apr 05, 2023 at 08:15:15PM +0800, Bin Meng wrote:
> record is only referenced in efi_selftest_exitbootservices.c
>
> Signed-off-by: Bin Meng
> ---
>
> lib/efi_selftest/efi_selftest_exitbootservices.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_selftest/efi_selftest_exitbootservices.c
> b/lib/efi_selftest/efi_selftest_exitbootservices.c
> index 11b43fdd90..b090ce74d2 100644
> --- a/lib/efi_selftest/efi_selftest_exitbootservices.c
> +++ b/lib/efi_selftest/efi_selftest_exitbootservices.c
> @@ -27,7 +27,7 @@ struct notification_context {
>
> static struct efi_boot_services *boottime;
> static struct efi_event *efi_st_event_notify;
> -struct notification_record record;
> +static struct notification_record record;
>
> struct notification_context context_before = {
> .record = &record,
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
[PATCH] arm64: zynqmp: Fix issue of apps executing from R5 core 1
From: Ashok Reddy Soma
In current implementation, applications can execute only on R5 core 0.
The boot address for R5 core 1 is not supplied. Pass TCM address for
R5 core 1 based on the argument to fix the issue.
Remove incomplete comment.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/mp.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-zynqmp/mp.c b/arch/arm/mach-zynqmp/mp.c
index d98c34ea8a5a..7a12f4b2b6c7 100644
--- a/arch/arm/mach-zynqmp/mp.c
+++ b/arch/arm/mach-zynqmp/mp.c
@@ -32,7 +32,8 @@
#define ZYNQMP_CRLAPB_RST_LPD_R51_RST_MASK 0x02
#define ZYNQMP_CRLAPB_CPU_R5_CTRL_CLKACT_MASK 0x100
-#define ZYNQMP_TCM_START_ADDRESS 0xFFE0
+#define ZYNQMP_R5_0_TCM_START_ADDR 0xFFE0
+#define ZYNQMP_R5_1_TCM_START_ADDR 0xFFE9
#define ZYNQMP_TCM_BOTH_SIZE 0x4
#define ZYNQMP_CORE_APU0 0
@@ -215,9 +216,14 @@ static void set_r5_start(u8 high)
writel(tmp, &rpu_base->rpu1_cfg);
}
-static void write_tcm_boot_trampoline(u32 boot_addr)
+static void write_tcm_boot_trampoline(u32 nr, u32 boot_addr)
{
if (boot_addr) {
+ u64 tcm_start_addr = ZYNQMP_R5_0_TCM_START_ADDR;
+
+ if (nr == ZYNQMP_CORE_RPU1)
+ tcm_start_addr = ZYNQMP_R5_1_TCM_START_ADDR;
+
/*
* Boot trampoline is simple ASM code below.
*
@@ -229,12 +235,12 @@ static void write_tcm_boot_trampoline(u32 boot_addr)
* bx r1
*/
debug("Write boot trampoline for %x\n", boot_addr);
- writel(0xea00, ZYNQMP_TCM_START_ADDRESS);
- writel(boot_addr, ZYNQMP_TCM_START_ADDRESS + 0x4);
- writel(0xe59f0004, ZYNQMP_TCM_START_ADDRESS + 0x8);
- writel(0xe5901000, ZYNQMP_TCM_START_ADDRESS + 0xc);
- writel(0xe12fff11, ZYNQMP_TCM_START_ADDRESS + 0x10);
- writel(0x0004, ZYNQMP_TCM_START_ADDRESS + 0x14); // address
for
+ writel(0xea00, tcm_start_addr);
+ writel(boot_addr, tcm_start_addr + 0x4);
+ writel(0xe59f0004, tcm_start_addr + 0x8);
+ writel(0xe5901000, tcm_start_addr + 0xc);
+ writel(0xe12fff11, tcm_start_addr + 0x10);
+ writel(0x0004, tcm_start_addr + 0x14);
}
}
@@ -328,7 +334,7 @@ int cpu_release(u32 nr, int argc, char *const argv[])
enable_clock_r5();
release_r5_reset(nr, LOCK);
dcache_disable();
- write_tcm_boot_trampoline(boot_addr_uniq);
+ write_tcm_boot_trampoline(nr, boot_addr_uniq);
dcache_enable();
set_r5_halt_mode(nr, RELEASE, LOCK);
mark_r5_used(nr, LOCK);
@@ -341,7 +347,7 @@ int cpu_release(u32 nr, int argc, char *const argv[])
enable_clock_r5();
release_r5_reset(nr, SPLIT);
dcache_disable();
- write_tcm_boot_trampoline(boot_addr_uniq);
+ write_tcm_boot_trampoline(nr, boot_addr_uniq);
dcache_enable();
set_r5_halt_mode(nr, RELEASE, SPLIT);
mark_r5_used(nr, SPLIT);
--
2.36.1
[PATCH] drivers: tee: sandbox: Fix SCP03 control emulator
Fix and document the Secure Channel Protocol03 emulator.
Fixes: 5a8783c80c39 ("drivers: tee: sandbox: SCP03 control emulator")
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/sandbox.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
index 35e8542fa3..8e32b69f5b 100644
--- a/drivers/tee/sandbox.c
+++ b/drivers/tee/sandbox.c
@@ -119,6 +119,7 @@ static u32 pta_scp03_invoke_func(struct udevice *dev, u32
func, uint num_params,
{
u32 res;
static bool enabled;
+ static bool provision;
switch (func) {
case PTA_CMD_ENABLE_SCP03:
@@ -130,12 +131,18 @@ static u32 pta_scp03_invoke_func(struct udevice *dev, u32
func, uint num_params,
if (res)
return res;
- if (!enabled) {
+ /* If SCP03 was not enabled, enable it */
+ if (!enabled)
enabled = true;
- } else {
- }
+ /* If SCP03 was not provisioned, provision new keys */
if (params[0].u.value.a)
+ provision = true;
+
+ /*
+* Either way, we asume both operations succeeded and that
+* the communication channel has now been stablished
+*/
return TEE_SUCCESS;
default:
--
2.34.1
[PATCH v2] watchdog: arm_smc_wdt: add watchdog support
Implement a ARM SMCCC based driver that allow to use
a secure watchdog on the platform.
Signed-off-by: Lionel Debieve
Reviewed-by: Patrick Delaunay
Tested-by: Patrick Delaunay
---
(no changes since v1)
drivers/watchdog/Kconfig | 8 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/arm_smc_wdt.c | 121 +
3 files changed, 130 insertions(+)
create mode 100644 drivers/watchdog/arm_smc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b5ac8f7f50d..3a0341f609d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,14 @@ config WDT_TANGIER
Intel Tangier SoC. If you're using a board with Intel Tangier
SoC, say Y here.
+config WDT_ARM_SMC
+ bool "ARM SMC watchdog timer support"
+ depends on WDT && ARM_SMCCC
+ imply WATCHDOG
+ help
+ Select this to enable Arm SMC watchdog timer. This watchdog will
manage
+ a watchdog based on ARM SMCCC communication.
+
config SPL_WDT
bool "Enable driver model for watchdog timer drivers in SPL"
depends on SPL_DM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d2..a4633c0d2fa 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
obj-$(CONFIG_WDT_ALARM_SANDBOX) += sandbox_alarm-wdt.o
obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
+obj-$(CONFIG_WDT_ARM_SMC) += arm_smc_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
diff --git a/drivers/watchdog/arm_smc_wdt.c b/drivers/watchdog/arm_smc_wdt.c
new file mode 100644
index 000..70ab99bdbfb
--- /dev/null
+++ b/drivers/watchdog/arm_smc_wdt.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ARM Secure Monitor Call watchdog driver
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ * This file is based on Linux driver drivers/watchdog/arm_smc_wdt.c
+ */
+
+#define LOG_CATEGORY UCLASS_WDT
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "arm_smc_wdt"
+
+#define WDT_TIMEOUT_SECS(TIMEOUT) ((TIMEOUT) / 1000)
+
+enum smcwd_call {
+ SMCWD_INIT = 0,
+ SMCWD_SET_TIMEOUT = 1,
+ SMCWD_ENABLE= 2,
+ SMCWD_PET = 3,
+ SMCWD_GET_TIMELEFT = 4,
+};
+
+struct smcwd_priv_data {
+ u32 smc_id;
+ unsigned int min_timeout;
+ unsigned int max_timeout;
+};
+
+static int smcwd_call(struct udevice *dev, enum smcwd_call call,
+ unsigned long arg, struct arm_smccc_res *res)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ struct arm_smccc_res local_res;
+
+ if (!res)
+ res = &local_res;
+
+ arm_smccc_smc(priv->smc_id, call, arg, 0, 0, 0, 0, 0, res);
+
+ if (res->a0 == PSCI_RET_NOT_SUPPORTED)
+ return -ENODEV;
+ if (res->a0 == PSCI_RET_INVALID_PARAMS)
+ return -EINVAL;
+ if (res->a0 != PSCI_RET_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int smcwd_reset(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_PET, 0, NULL);
+}
+
+static int smcwd_stop(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_ENABLE, 0, NULL);
+}
+
+static int smcwd_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ u64 timeout_sec = WDT_TIMEOUT_SECS(timeout_ms);
+ int err;
+
+ if (timeout_sec < priv->min_timeout || timeout_sec > priv->max_timeout)
{
+ dev_err(dev, "Timeout value not supported\n");
+ return -EINVAL;
+ }
+
+ err = smcwd_call(dev, SMCWD_SET_TIMEOUT, timeout_sec, NULL);
+ if (err) {
+ dev_err(dev, "Timeout out configuration failed\n");
+ return err;
+ }
+
+ return smcwd_call(dev, SMCWD_ENABLE, 1, NULL);
+}
+
+static int smcwd_probe(struct udevice *dev)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ struct arm_smccc_res res;
+ int err;
+
+ priv->smc_id = dev_read_u32_default(dev, "arm,smc-id", 0x82003D06);
+
+ err = smcwd_call(dev, SMCWD_INIT, 0, &res);
+ if (err < 0)
+ return err;
+
+ priv->min_timeout = res.a1;
+ priv->max_timeout = res.a2;
+
+ return 0;
+}
+
+static const struct wdt_ops smcwd_ops = {
+ .start = smcwd_start,
+ .stop = smcwd_stop,
+ .reset = smcwd_reset,
+};
+
+static const struct udevice_id smcwd_dt_ids[] = {
+ { .compatible = "arm,smc-wdt" },
+ {}
+};
+
+U_BOOT_DRIVER(wdt_sandbox) = {
+ .name = "smcwd",
+ .id = UCLASS_WDT,
+ .of_match = smcwd_dt_ids,
+ .priv_auto = sizeof
[PATCH] k3: pmic: Clear ESM masks
ESM MCU masks must be set to 0h so that PMIC can handle errors
that require attention for example SYS_SAFETY_ERRn. The required bits
must be cleared: ESM_MCU_RST_MASK, ESM_MCU_FAIL_MASK, ESM_MCU_PIN_MASK.
If PMIC expected to handle errors, make sure EVM is configured to
connect SOC_SAFETY_ERRz (Main) to the PMIC.
Note that even though the User Guide for TPS65941 for J721E mentions
that these bits are reset to 0h; it is not reflected once board boots to
kernel, possibly due to NVM configurations. Eithercase, it is best to
account for this from R5 SPL side as well.
Signed-off-by: Neha Malcom Francis
---
drivers/misc/esm_pmic.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/misc/esm_pmic.c b/drivers/misc/esm_pmic.c
index a195dc5eb1d..b971f32f6a1 100644
--- a/drivers/misc/esm_pmic.c
+++ b/drivers/misc/esm_pmic.c
@@ -26,6 +26,9 @@
#define ESM_MCU_EN BIT(6)
#define ESM_MCU_ENDRV BIT(5)
+#define ESM_MCU_MASK_REG 0x59
+#define ESM_MCU_MASK 0x7
+
/**
* pmic_esm_probe: configures and enables PMIC ESM functionality
*
@@ -48,6 +51,12 @@ static int pmic_esm_probe(struct udevice *dev)
return ret;
}
+ ret = pmic_reg_write(dev->parent, ESM_MCU_MASK_REG, ESM_MCU_MASK);
+ if (ret) {
+ dev_err(dev, "clearing ESM masks failed: %d\n", ret);
+ return ret;
+ }
+
ret = pmic_reg_write(dev->parent, ESM_MCU_START_REG, ESM_MCU_START);
if (ret) {
dev_err(dev, "starting ESM failed: %d\n", ret);
--
2.34.1
[PATCH v2 1/1] sandbox: fix return type of os_filesize()
Given a file ../img of size 4294967296 with GPT partition table and
partitions:
=> host bind 0 ../img
=> part list host 0
Disk host-0.blk not ready
The cause is os_filesize() returning int. File sizes must use off_t.
Correct all uses of os_filesize() too.
Signed-off-by: Heinrich Schuchardt
---
v2:
avoid different signedness when comparing numbers
---
arch/sandbox/cpu/os.c| 8 ++--
drivers/block/host_dev.c | 3 ++-
include/os.h | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 5e66304e2b..f8ad208e46 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -166,7 +166,7 @@ int os_write_file(const char *fname, const void *buf, int
size)
return 0;
}
-int os_filesize(int fd)
+off_t os_filesize(int fd)
{
off_t size;
@@ -218,7 +218,7 @@ err:
int os_map_file(const char *pathname, int os_flags, void **bufp, int *sizep)
{
void *ptr;
- int size;
+ off_t size;
int ifd;
ifd = os_open(pathname, os_flags);
@@ -231,6 +231,10 @@ int os_map_file(const char *pathname, int os_flags, void
**bufp, int *sizep)
printf("Cannot get file size of '%s'\n", pathname);
return -EIO;
}
+ if ((unsigned long long)size > (unsigned long long)SIZE_MAX) {
+ printf("File '%s' too large to map\n", pathname);
+ return -EIO;
+ }
ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, ifd, 0);
if (ptr == MAP_FAILED) {
diff --git a/drivers/block/host_dev.c b/drivers/block/host_dev.c
index 5885fc358a..64422417b7 100644
--- a/drivers/block/host_dev.c
+++ b/drivers/block/host_dev.c
@@ -24,7 +24,8 @@ static int host_sb_attach_file(struct udevice *dev, const
char *filename)
struct host_sb_plat *plat = dev_get_plat(dev);
struct blk_desc *desc;
struct udevice *blk;
- int ret, fd, size;
+ int ret, fd;
+ off_t size;
char *fname;
if (!filename)
diff --git a/include/os.h b/include/os.h
index 0415f0f0e7..968412b0a8 100644
--- a/include/os.h
+++ b/include/os.h
@@ -64,7 +64,7 @@ off_t os_lseek(int fd, off_t offset, int whence);
* @fd:File descriptor as returned by os_open()
* Return: file size or negative error code
*/
-int os_filesize(int fd);
+off_t os_filesize(int fd);
/**
* Access to the OS open() system call
--
2.39.2
[PATCH 1/1] MAINTAINERS: assign include/os.h
os.h is only used by the sandbox. Signed-off-by: Heinrich Schuchardt --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 91d40ea4b6..a0e20ba7c6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1338,6 +1338,7 @@ F:arch/sandbox/ F: doc/arch/sandbox.rst F: drivers/*/*sandbox*.c F: include/dt-bindings/*/sandbox*.h +F: include/os.h SEAMA M: Linus Walleij -- 2.39.2
Re: [PATCH 2/2] thermal: imx_tmu: Move architecture code into driver
> > Stop polluting the architecture directory with driver specific code, > > move it into driver where it should be. Split the code slightly so > > the MX8MM/MX8MN fuse readout and programming and MX8MP fuse readout > > and programming are in their separate functions, and called in case > > of matching SoC. > > > > Signed-off-by: Marek Vasut > > Reviewed-by: Fabio Estevam Reviewed-by: Andrejs Cainikovs
Re: [PATCH 1/2] thermal: imx_tmu: Clean up all prints
> > Use dev_(dev, ...) for all printing and debug logging, since this > > already includes the device name. Drop device name where duplicate. > > > > Signed-off-by: Marek Vasut > Reviewed-by: Fabio Estevam Reviewed-by: Andrejs Cainikovs
[PATCH 1/1] sandbox: fix return type of os_filesize()
Given a file ../img of size 4294967296 with GPT partition table and
partitions:
=> host bind 0 ../img
=> part list host 0
Disk host-0.blk not ready
The cause is os_filesize() returning int. 4294967296 converted to int32_t
gives 0. File sizes must use off_t.
Correct all uses of os_filesize() too.
Signed-off-by: Heinrich Schuchardt
---
arch/sandbox/cpu/os.c| 8 ++--
drivers/block/host_dev.c | 3 ++-
include/os.h | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 5e66304e2b..f8ad208e46 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -166,7 +166,7 @@ int os_write_file(const char *fname, const void *buf, int
size)
return 0;
}
-int os_filesize(int fd)
+off_t os_filesize(int fd)
{
off_t size;
@@ -218,7 +218,7 @@ err:
int os_map_file(const char *pathname, int os_flags, void **bufp, int *sizep)
{
void *ptr;
- int size;
+ off_t size;
int ifd;
ifd = os_open(pathname, os_flags);
@@ -231,6 +231,10 @@ int os_map_file(const char *pathname, int os_flags, void
**bufp, int *sizep)
printf("Cannot get file size of '%s'\n", pathname);
return -EIO;
}
+ if (size > SIZE_MAX) {
+ printf("File '%s' too large to map\n", pathname);
+ return -EIO;
+ }
ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, ifd, 0);
if (ptr == MAP_FAILED) {
diff --git a/drivers/block/host_dev.c b/drivers/block/host_dev.c
index 5885fc358a..64422417b7 100644
--- a/drivers/block/host_dev.c
+++ b/drivers/block/host_dev.c
@@ -24,7 +24,8 @@ static int host_sb_attach_file(struct udevice *dev, const
char *filename)
struct host_sb_plat *plat = dev_get_plat(dev);
struct blk_desc *desc;
struct udevice *blk;
- int ret, fd, size;
+ int ret, fd;
+ off_t size;
char *fname;
if (!filename)
diff --git a/include/os.h b/include/os.h
index 0415f0f0e7..968412b0a8 100644
--- a/include/os.h
+++ b/include/os.h
@@ -64,7 +64,7 @@ off_t os_lseek(int fd, off_t offset, int whence);
* @fd:File descriptor as returned by os_open()
* Return: file size or negative error code
*/
-int os_filesize(int fd);
+off_t os_filesize(int fd);
/**
* Access to the OS open() system call
--
2.39.2
