Re: [PATCH 3/5] arm: mach-k3: Add note to auto-generated files
On 11/08/21 1:19 am, Dave Gerlach wrote: > Add a note to the automatically generated clk-data and dev-data files > for j721e and j7200 to indicate that they are in fact auto-generated and > should not be hand edited. > > Signed-off-by: Dave Gerlach Are there any guidelines/README to do this autogeneration? Thanks and regards, Lokesh > --- > arch/arm/mach-k3/j7200/clk-data.c | 2 ++ > arch/arm/mach-k3/j7200/dev-data.c | 2 ++ > arch/arm/mach-k3/j721e/clk-data.c | 2 ++ > arch/arm/mach-k3/j721e/dev-data.c | 2 ++ > 4 files changed, 8 insertions(+) > > diff --git a/arch/arm/mach-k3/j7200/clk-data.c > b/arch/arm/mach-k3/j7200/clk-data.c > index 49145bbfc8cd..649d28b1db0b 100644 > --- a/arch/arm/mach-k3/j7200/clk-data.c > +++ b/arch/arm/mach-k3/j7200/clk-data.c > @@ -2,6 +2,8 @@ > /* > * J7200 specific clock platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-clk.h" > diff --git a/arch/arm/mach-k3/j7200/dev-data.c > b/arch/arm/mach-k3/j7200/dev-data.c > index c68bcc58e9a7..f7b7892da97b 100644 > --- a/arch/arm/mach-k3/j7200/dev-data.c > +++ b/arch/arm/mach-k3/j7200/dev-data.c > @@ -2,6 +2,8 @@ > /* > * J7200 specific device platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-dev.h" > diff --git a/arch/arm/mach-k3/j721e/clk-data.c > b/arch/arm/mach-k3/j721e/clk-data.c > index ff9262d7bcee..aa3f50a02f59 100644 > --- a/arch/arm/mach-k3/j721e/clk-data.c > +++ b/arch/arm/mach-k3/j721e/clk-data.c > @@ -2,6 +2,8 @@ > /* > * J721E specific clock platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-clk.h" > diff --git a/arch/arm/mach-k3/j721e/dev-data.c > b/arch/arm/mach-k3/j721e/dev-data.c > index 96393c713278..a8bc6ce20d1d 100644 > --- a/arch/arm/mach-k3/j721e/dev-data.c > +++ b/arch/arm/mach-k3/j721e/dev-data.c > @@ -2,6 +2,8 @@ > /* > * J721E specific device platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-dev.h" >
Re: [PATCH 1/3] aristainetos2: Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS
Hello Tom, On 10.08.21 23:34, Tom Rini wrote: > Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS to EXTRA_ENV_BOARD_SETTINGS in > order to not further add to the CONFIG namespace. > > Cc: Heiko Schocher > Signed-off-by: Tom Rini > --- > include/configs/aristainetos2.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Heiko Schocher Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Fabio,
It might work. But why? I mean the imx8mm-evk has already switched to
binman on the mainline.
So we should do the same. If you can't get into U-boot prompt using binman
I can give you more detailed information.
Yours,
Paul
On Wed, 11 Aug 2021 at 07:13, Fabio Estevam wrote:
> Hi Paul,
>
> Thanks for your response.
>
> On Thu, Jul 1, 2021 at 6:38 PM Paul Liu wrote:
> >
> > Hi Fabio,
> >
> > We have dfu_alt_info set. So that we can capsule update from UEFI.
> > First, "setenv -e -nv -bs -rt -v OsIndications =0x04"
> > And then we can "efidebug capsule update -v ${loadaddr}".
> >
> > To make the capsule binary, we need to create a capsule1.itb with the
> following content:
> > /dts-v1/;
> >
> > / {
> >description = "Automatic U-Boot environment update";
> >#address-cells = <2>;
> >
> >images {
> >flash-bin {
> >description = "U-Boot binary on SPI Flash";
> >data = /incbin/("flash.bin");
> >compression = "none";
> >type = "firmware";
> >arch = "arm64";
> >load = <0>;
> >hash-1 {
> >algo = "sha1";
> >};
> >};
> >u-boot-itb {
> >description = "U-Boot binary";
> >data = /incbin/("u-boot.itb");
> >compression = "none";
> >type = "firmware";
> > arch = "arm64";
> >load = <0>;
> >hash-1 {
> >algo = "sha1";
> >};
> >};
> >};
> > };
> >
> > And then "./tools/mkimage -f capsule1.its capsule1.itb"
> > "./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"
> >
> > And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule
> update.
>
> In my case, I have the original U-Boot 2020.04 version from Compulab
> on the IoT Gateway board.
>
> Would it be possible to run a patch like this
> https://pastebin.com/raw/Rq1Yv6ka
>
> And then just load flash.bin via TFTP and flash it to offset 33K of the
> eMMC?
>
> Would that work?
>
> Thanks,
>
> Fabio Estevam
>
Re: [PATCH v3 2/5] efi_loader: add boot variable measurement
On Tue, 10 Aug 2021 at 11:19, AKASHI Takahiro
wrote:
>
> On Fri, Aug 06, 2021 at 04:02:12PM +0900, Masahisa Kojima wrote:
> > TCG PC Client PFP spec requires to measure "Boot"
> > and "BootOrder" variables, EV_SEPARATOR event prior
> > to the Ready to Boot invocation.
> > Since u-boot does not implement Ready to Boot event,
> > these measurements are performed when efi_start_image() is called.
> >
> > TCG spec also requires to measure "Calling EFI Application from
> > Boot Option" for each boot attempt, and "Returning from EFI
> > Application from Boot Option" if a boot device returns control
> > back to the Boot Manager.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v3:
> > - modify log output
> >
> > Changes in v2:
> > - use efi_create_indexed_name() for "Boot" variable
> >
> > include/efi_loader.h | 4 ++
> > include/tpm-v2.h | 18 -
> > lib/efi_loader/efi_boottime.c | 20 ++
> > lib/efi_loader/efi_tcg2.c | 121 ++
> > 4 files changed, 162 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index a120d94431..345cbb72c4 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -499,6 +499,10 @@ efi_status_t efi_run_image(void *source_buffer,
> > efi_uintn_t source_size);
> > efi_status_t efi_init_variables(void);
> > /* Notify ExitBootServices() is called */
> > void efi_variables_boot_exit_notify(void);
> > +/* Measure efi application invocation */
> > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
> > +/* Measure efi application exit */
> > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
>
> I don't think that we need to have EFIAPI specifiers for those functions
> as they are not api's.
Yes, I will remove EFIAPI specifiers.
>
> > /* Called by bootefi to initialize root node */
> > efi_status_t efi_root_node_register(void);
> > /* Called by bootefi to initialize runtime */
> > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > index 247b386967..325c73006e 100644
> > --- a/include/tpm-v2.h
> > +++ b/include/tpm-v2.h
> > @@ -73,7 +73,7 @@ struct udevice;
> > /*
> > * event types, cf.
> > * "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
> > - * rev 1.04, June 3, 2019
> > + * Level 00 Version 1.05 Revision 23, May 7, 2021
> > */
> > #define EV_EFI_EVENT_BASE((u32)0x8000)
> > #define EV_EFI_VARIABLE_DRIVER_CONFIG((u32)0x8001)
> > @@ -85,8 +85,24 @@ struct udevice;
> > #define EV_EFI_ACTION((u32)0x8007)
> > #define EV_EFI_PLATFORM_FIRMWARE_BLOB((u32)0x8008)
> > #define EV_EFI_HANDOFF_TABLES((u32)0x8009)
> > +#define EV_EFI_PLATFORM_FIRMWARE_BLOB2 ((u32)0x800A)
> > +#define EV_EFI_HANDOFF_TABLES2 ((u32)0x800B)
> > +#define EV_EFI_VARIABLE_BOOT2((u32)0x800C)
> > #define EV_EFI_HCRTM_EVENT ((u32)0x8010)
> > #define EV_EFI_VARIABLE_AUTHORITY((u32)0x80E0)
> > +#define EV_EFI_SPDM_FIRMWARE_BLOB((u32)0x80E1)
> > +#define EV_EFI_SPDM_FIRMWARE_CONFIG ((u32)0x80E2)
> > +
> > +#define EFI_CALLING_EFI_APPLICATION \
> > + "Calling EFI Application from Boot Option"
> > +#define EFI_RETURNING_FROM_EFI_APPLICATION \
> > + "Returning from EFI Application from Boot Option"
> > +#define EFI_EXIT_BOOT_SERVICES_INVOCATION \
> > + "Exit Boot Services Invocation"
> > +#define EFI_EXIT_BOOT_SERVICES_FAILED \
> > + "Exit Boot Services Returned with Failure"
> > +#define EFI_EXIT_BOOT_SERVICES_SUCCEEDED\
> > + "Exit Boot Services Returned with Success"
> >
> > /* TPMS_TAGGED_PROPERTY Structure */
> > struct tpms_tagged_property {
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 0b98e91813..13ab139222 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -2994,6 +2994,16 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
> > image_handle,
> > image_obj->exit_status = _status;
> > image_obj->exit_jmp = _jmp;
> >
> > + if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
> > + if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION)
> > {
> > + ret = efi_tcg2_measure_efi_app_invocation();
> > + if (ret != EFI_SUCCESS) {
> > + log_warning("tcg2 measurement fails(0x%lx)\n",
> > + ret);
> > + }
> > + }
> > + }
> > +
> > /* call the image! */
> > if (setjmp(_jmp)) {
> > /*
> > @@ -3252,6 +3262,16 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t
> > image_handle,
> > exit_status != EFI_SUCCESS)
> >
Re: [PATCH v3 1/5] efi_loader: add secure boot variable measurement
Hi Akashi-san,
Thank you for your comment.
On Tue, 10 Aug 2021 at 10:44, AKASHI Takahiro
wrote:
>
> Kojima-san,
>
> On Fri, Aug 06, 2021 at 04:02:11PM +0900, Masahisa Kojima wrote:
> > TCG PC Client PFP spec requires to measure the secure
> > boot policy before validating the UEFI image.
> > This commit adds the secure boot variable measurement
> > of "SecureBoot", "PK", "KEK", "db", "dbx", "dbt", and "dbr".
> >
> > Note that this implementation assumes that secure boot
> > variables are pre-configured and not be set/updated in runtime.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v3:
> > - add "dbt" and "dbr" measurement
> > - accept empty variable measurement for "SecureBoot", "PK",
> > "KEK", "db" and "dbx" as TCG2 spec requires
> > - fix comment format
> >
> > Changes in v2:
> > - missing null check for getting variable data
> > - some minor fix for readability
> >
> > include/efi_tcg2.h| 20 +
> > lib/efi_loader/efi_tcg2.c | 165 ++
> > 2 files changed, 185 insertions(+)
> >
> > diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> > index bcfb98168a..497ba3ce94 100644
> > --- a/include/efi_tcg2.h
> > +++ b/include/efi_tcg2.h
> > @@ -142,6 +142,26 @@ struct efi_tcg2_final_events_table {
> > struct tcg_pcr_event2 event[];
> > };
> >
> > +/**
> > + * struct tdUEFI_VARIABLE_DATA - event log structure of UEFI variable
> > + * @variable_name: The vendorGUID parameter in the
> > + * GetVariable() API.
> > + * @unicode_name_length: The length in CHAR16 of the Unicode name of
> > + * the variable.
> > + * @variable_data_length:The size of the variable data.
> > + * @unicode_name:The CHAR16 unicode name of the variable
> > + * without NULL-terminator.
> > + * @variable_data: The data parameter of the efi variable
> > + * in the GetVariable() API.
> > + */
> > +struct efi_tcg2_uefi_variable_data {
> > + efi_guid_t variable_name;
> > + u64 unicode_name_length;
> > + u64 variable_data_length;
> > + u16 unicode_name[1];
> > + u8 variable_data[1];
> > +};
> > +
> > struct efi_tcg2_protocol {
> > efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
> > struct
> > efi_tcg2_boot_service_capability *capability);
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index 1319a8b378..a2e9587cd0 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -78,6 +78,19 @@ static const struct digest_info hash_algo_list[] = {
> > },
> > };
> >
> > +struct variable_info {
> > + u16 *name;
> > + const efi_guid_t*guid;
> > +};
> > +
> > +static struct variable_info secure_variables[] = {
> > + {L"SecureBoot", _global_variable_guid},
> > + {L"PK", _global_variable_guid},
> > + {L"KEK", _global_variable_guid},
> > + {L"db", _guid_image_security_database},
> > + {L"dbx", _guid_image_security_database},
> > +};
> > +
> > #define MAX_HASH_COUNT ARRAY_SIZE(hash_algo_list)
> >
> > /**
> > @@ -1264,6 +1277,39 @@ free_pool:
> > return ret;
> > }
> >
> > +/**
> > + * tcg2_measure_event() - common function to add event log and extend PCR
> > + *
> > + * @dev: TPM device
> > + * @pcr_index: PCR index
> > + * @event_type: type of event added
> > + * @size:event size
> > + * @event: event data
> > + *
> > + * Return: status code
> > + */
> > +static efi_status_t EFIAPI
> > +tcg2_measure_event(struct udevice *dev, u32 pcr_index, u32 event_type,
> > +u32 size, u8 event[])
> > +{
> > + struct tpml_digest_values digest_list;
> > + efi_status_t ret;
> > +
> > + ret = tcg2_create_digest(event, size, _list);
> > + if (ret != EFI_SUCCESS)
> > + goto out;
> > +
> > + ret = tcg2_pcr_extend(dev, pcr_index, _list);
> > + if (ret != EFI_SUCCESS)
> > + goto out;
> > +
> > + ret = tcg2_agile_log_append(pcr_index, event_type, _list,
> > + size, event);
> > +
> > +out:
> > + return ret;
> > +}
> > +
> > /**
> > * efi_append_scrtm_version - Append an S-CRTM EV_S_CRTM_VERSION event on
> > the
> > * eventlog and extend the PCRs
> > @@ -1294,6 +1340,118 @@ out:
> > return ret;
> > }
> >
> > +/**
> > + * tcg2_measure_variable() - add variable event log and extend PCR
> > + *
> > + * @dev: TPM device
> > + * @pcr_index: PCR index
> > + * @event_type: type of event added
> > + * @var_name:variable name
> > + * @guid:guid
> > + * @data_size: variable data size
> > + * @data:variable data
> > + *
> > + * Return: status code
> > + */
> > +static
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Paul, On Tue, Aug 10, 2021 at 10:06 PM Paul Liu wrote: > > Hi Fabio, > > It might work. But why? I mean the imx8mm-evk has already switched to binman > on the mainline. > So we should do the same. If you can't get into U-boot prompt using binman I > can give you more detailed information. The reason I removed binman support was only for debugging purposes, as I don't plan to use fip.bin. I would appreciate it if you could share more detailed information on how to flash mainline U-Boot on a IoT Gateway board that contains the original U-Boot 2020.04 version from Compulab. Thanks, Fabio Estevam
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Paul,
Thanks for your response.
On Thu, Jul 1, 2021 at 6:38 PM Paul Liu wrote:
>
> Hi Fabio,
>
> We have dfu_alt_info set. So that we can capsule update from UEFI.
> First, "setenv -e -nv -bs -rt -v OsIndications =0x04"
> And then we can "efidebug capsule update -v ${loadaddr}".
>
> To make the capsule binary, we need to create a capsule1.itb with the
> following content:
> /dts-v1/;
>
> / {
>description = "Automatic U-Boot environment update";
>#address-cells = <2>;
>
>images {
>flash-bin {
>description = "U-Boot binary on SPI Flash";
>data = /incbin/("flash.bin");
>compression = "none";
>type = "firmware";
>arch = "arm64";
>load = <0>;
>hash-1 {
>algo = "sha1";
>};
>};
>u-boot-itb {
>description = "U-Boot binary";
>data = /incbin/("u-boot.itb");
>compression = "none";
>type = "firmware";
> arch = "arm64";
>load = <0>;
>hash-1 {
>algo = "sha1";
>};
>};
>};
> };
>
> And then "./tools/mkimage -f capsule1.its capsule1.itb"
> "./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"
>
> And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule
> update.
In my case, I have the original U-Boot 2020.04 version from Compulab
on the IoT Gateway board.
Would it be possible to run a patch like this
https://pastebin.com/raw/Rq1Yv6ka
And then just load flash.bin via TFTP and flash it to offset 33K of the eMMC?
Would that work?
Thanks,
Fabio Estevam
[PATCH 3/3] exynos: Update environment macros a bit
Rework the default environment a bit to not use non-standard
CONFIG_ENV_... names and similar one-off CONFIG names.
Cc: Jaehoon Chung
Signed-off-by: Tom Rini
---
include/configs/exynos4-common.h| 2 +-
include/configs/s5pc210_universal.h | 26 +-
include/configs/trats.h | 9 +++--
include/configs/trats2.h| 2 +-
4 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/include/configs/exynos4-common.h b/include/configs/exynos4-common.h
index 5e2aca371e7e..2ca14d0b86e3 100644
--- a/include/configs/exynos4-common.h
+++ b/include/configs/exynos4-common.h
@@ -32,7 +32,7 @@
#define CONFIG_USB_GADGET_DWC2_OTG_PHY
/* Common environment variables */
-#define CONFIG_EXTRA_ENV_ITB \
+#define ENV_ITB \
"loadkernel=load mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} " \
"${kernelname}\0" \
"loadinitrd=load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} " \
diff --git a/include/configs/s5pc210_universal.h
b/include/configs/s5pc210_universal.h
index 0b679f437482..8ee667e69306 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -44,16 +44,6 @@
",100M(swap)"\
",-(UMS)\0"
-#define CONFIG_ENV_UBI_MTD " ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7"
-#define CONFIG_BOOTBLOCK "10"
-#define CONFIG_UBIBLOCK"9"
-
-#define CONFIG_ENV_UBIFS_OPTION" rootflags=bulk_read,no_chk_data_crc "
-#define CONFIG_ENV_FLASHBOOT CONFIG_ENV_UBI_MTD CONFIG_ENV_UBIFS_OPTION \
- "${mtdparts}"
-
-#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}"
-
#define CONFIG_EXTRA_ENV_SETTINGS \
"updateb=" \
"onenand erase 0x0 0x10;" \
@@ -71,18 +61,20 @@
"lpj=lpj=3981312\0" \
"ubifsboot=" \
"set bootargs root=ubi0!rootfs rootfstype=ubifs ${lpj} " \
- CONFIG_ENV_FLASHBOOT " ${opts} ${lcdinfo} " \
- CONFIG_ENV_COMMON_BOOT "; run bootk\0" \
+ "ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7 " \
+ "rootflags=bulk_read,no_chk_data_crc ${mtdparts} ${opts} " \
+ "${lcdinfo} ${console} ${meminfo}; run bootk\0" \
"tftpboot=" \
"set bootargs root=ubi0!rootfs rootfstype=ubifs " \
- CONFIG_ENV_FLASHBOOT " ${opts} ${lcdinfo} " \
- CONFIG_ENV_COMMON_BOOT \
+ "ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7 " \
+ "rootflags=bulk_read,no_chk_data_crc ${mtdparts} ${opts} " \
+ "${lcdinfo} ${console} ${meminfo}" \
"; tftp 0x40007FC0 uImage; bootm 0x40007FC0\0" \
"nfsboot=" \
"set bootargs root=/dev/nfs rw " \
"nfsroot=${nfsroot},nolock,tcp " \
"ip=${ipaddr}:${serverip}:${gatewayip}:" \
- "${netmask}:generic:usb0:off " CONFIG_ENV_COMMON_BOOT \
+ "${netmask}:generic:usb0:off ${console} ${meminfo}" \
"; run bootk\0" \
"ramfsboot=" \
"set bootargs root=/dev/ram0 rw rootfstype=ext2 " \
@@ -102,8 +94,8 @@
"mbrparts=" MBRPARTS_DEFAULT \
"meminfo=crashkernel=32M@0x5000\0" \
"nfsroot=/nfsroot/arm\0" \
- "bootblock=" CONFIG_BOOTBLOCK "\0" \
- "ubiblock=" CONFIG_UBIBLOCK" \0" \
+ "bootblock=10\0" \
+ "ubiblock=9\0" \
"ubi=enabled\0" \
"loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
"mmcdev=0\0" \
diff --git a/include/configs/trats.h b/include/configs/trats.h
index a44792d85764..c3f891ae53d8 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -40,9 +40,6 @@
#define CONFIG_SYS_MONITOR_BASE0x
-#define CONFIG_BOOTBLOCK "10"
-#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}"
-
/* Tizen - partitions definitions */
#define PARTS_CSA "csa-mmc"
#define PARTS_BOOT "boot"
@@ -94,7 +91,7 @@
"setenv bootargs root=/dev/nfs rw " \
"nfsroot=${nfsroot},nolock,tcp " \
"ip=${ipaddr}:${serverip}:${gatewayip}:" \
- "${netmask}:generic:usb0:off " CONFIG_ENV_COMMON_BOOT \
+ "${netmask}:generic:usb0:off ${console} ${meminfo}" \
"; run bootk\0" \
"ramfsboot=" \
"setenv bootargs root=/dev/ram0 rw rootfstype=ext2 " \
@@ -112,7 +109,7 @@
"console=console=ttySAC2,115200n8\0" \
"meminfo=crashkernel=32M@0x5000\0" \
"nfsroot=/nfsroot/arm\0" \
- "bootblock=" CONFIG_BOOTBLOCK "\0" \
+ "bootblock=10\0" \
"loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
"loaddtb=ext4load mmc ${mmcdev}:${mmcbootpart} ${fdtaddr} " \
"${fdtfile}\0" \
@@ -141,7 +138,7 @@
[PATCH 2/3] arm: keystone2: Rename CONFIG_ENV_KS2_BOARD_SETTINGS
Rename CONFIG_ENV_KS2_BOARD_SETTINGS to ENV_KS2_BOARD_SETTINGS so that it better fits with the rest of the environment addition macros. Cc: Vitaly Andrianov Signed-off-by: Tom Rini --- include/configs/k2e_evm.h| 2 +- include/configs/k2g_evm.h| 2 +- include/configs/k2hk_evm.h | 2 +- include/configs/k2l_evm.h| 2 +- include/configs/ti_armv7_keystone2.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index 716ae3b0d4aa..65bf646f3fb2 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -23,7 +23,7 @@ #endif /* U-Boot general configuration */ -#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ +#define ENV_KS2_BOARD_SETTINGS \ DEFAULT_FW_INITRAMFS_BOOT_ENV \ DEFAULT_SEC_BOOT_ENV\ "boot=ubi\0"\ diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h index 4471eb4f6a84..17245ab15861 100644 --- a/include/configs/k2g_evm.h +++ b/include/configs/k2g_evm.h @@ -16,7 +16,7 @@ #define CONFIG_SOC_K2G /* U-Boot general configuration */ -#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ +#define ENV_KS2_BOARD_SETTINGS \ DEFAULT_MMC_TI_ARGS \ DEFAULT_PMMC_BOOT_ENV \ DEFAULT_FW_INITRAMFS_BOOT_ENV \ diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h index d90b2648185a..1fdecd60e769 100644 --- a/include/configs/k2hk_evm.h +++ b/include/configs/k2hk_evm.h @@ -23,7 +23,7 @@ #endif /* U-Boot general configuration */ -#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ +#define ENV_KS2_BOARD_SETTINGS \ DEFAULT_FW_INITRAMFS_BOOT_ENV \ DEFAULT_SEC_BOOT_ENV\ "boot=ubi\0"\ diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h index 152cea01b55b..97512c9903de 100644 --- a/include/configs/k2l_evm.h +++ b/include/configs/k2l_evm.h @@ -23,7 +23,7 @@ #endif /* U-Boot general configuration */ -#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ +#define ENV_KS2_BOARD_SETTINGS \ DEFAULT_FW_INITRAMFS_BOOT_ENV \ DEFAULT_SEC_BOOT_ENV\ "boot=ubi\0"\ diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index cfc2be7b9f07..fc2b3431ddba 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -187,7 +187,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ - CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS \ + ENV_KS2_BOARD_SETTINGS \ DFUARGS \ "bootdir=/boot\0" \ "tftp_root=/\0" \ -- 2.17.1
[PATCH 1/3] aristainetos2: Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS
Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS to EXTRA_ENV_BOARD_SETTINGS in order to not further add to the CONFIG namespace. Cc: Heiko Schocher Signed-off-by: Tom Rini --- include/configs/aristainetos2.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/aristainetos2.h b/include/configs/aristainetos2.h index 78fa1a969e7f..69398787d9e7 100644 --- a/include/configs/aristainetos2.h +++ b/include/configs/aristainetos2.h @@ -93,13 +93,13 @@ #endif #if (CONFIG_SYS_BOARD_VERSION == 5) -#define CONFIG_EXTRA_ENV_BOARD_SETTINGS \ +#define EXTRA_ENV_BOARD_SETTINGS \ "dead=while true; do; " \ "led led_red on; sleep 1;" \ "led led_red off; sleep 1;" \ "done\0" #elif (CONFIG_SYS_BOARD_VERSION == 6) -#define CONFIG_EXTRA_ENV_BOARD_SETTINGS \ +#define EXTRA_ENV_BOARD_SETTINGS \ "dead=while true; do; " \ "led led_red on; led led_red2 on; sleep 1;" \ "led led_red off; led led_red2 off;; sleep 1;" \ @@ -414,7 +414,7 @@ "run main_rescue_boot;" \ "fi; \0"\ HAB_EXTRA_SETTINGS \ - CONFIG_EXTRA_ENV_BOARD_SETTINGS + EXTRA_ENV_BOARD_SETTINGS #define CONFIG_ARP_TIMEOUT 200UL -- 2.17.1
Re: [PATCH 1/1] arm: socfpga: Migrate CONFIG_HPS namespace to HPS
On Tue, Aug 10, 2021 at 10:53:02PM +0200, Marek Vasut wrote: > On 8/10/21 10:47 PM, Tom Rini wrote: > > On Tue, Aug 10, 2021 at 10:11:08PM +0200, Marek Vasut wrote: > > > On 8/10/21 10:05 PM, Tom Rini wrote: > > > > None of the CONFIG_HPS namespace options are changed via the board > > > > config.h file, nor does it make sense to move them to Kconfig. Rename > > > > these options to the HPS namespace instead. > > > > > > > > Cc: Marek Vasut > > > > Cc: Simon Goldschmidt > > > > Cc: Tien Fong Chee > > > > Signed-off-by: Tom Rini > > > > --- > > > > Note, this patch is complete as the changes to the regex qts-filter.sh > > > > are such a long line that git send-email fails. This patch was > > > > generated by: > > > > $ git grep -l CONFIG_HPS_ | xargs sed -i -e 's/CONFIG_HPS_/HPS_/g' > > > > and I will re-run that before applying. > > > > > > The problem is, it is the altera tools which generate all those CONFIG_* > > > symbols which are processed by the qts-filter.sh and placed into those > > > qts/ > > > board directories, so this patch breaks all that. You'd have to fix the > > > qts-filter to scrub the CONFIG_ prefixes first. > > > > Or rather, ugh, are there out of tree tools we need to deal with here? > > Perhaps someone with the tools could pick up and v2 something tested if > > so as it'll probably be a bit tricky getting it all right. > > See doc/README.socfpga . The out of tree tools generate board/bitstream > specific input header files which you plug into the qts-filter.sh script , > those files contain the CONFIG_* macros and those files get converted by the > qts-filter.sh script into the output header files in board/*/qts/*.h . The > output header files are what is used by U-Boot then. So doc/README.socfpga needs to be updated to rST as well, when someone that can run the tools and test the scripts work as expected and don't use the CONFIG_HPS namespace. Thanks for explaining a bit more. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] arm: socfpga: Migrate CONFIG_HPS namespace to HPS
On 8/10/21 10:47 PM, Tom Rini wrote: On Tue, Aug 10, 2021 at 10:11:08PM +0200, Marek Vasut wrote: On 8/10/21 10:05 PM, Tom Rini wrote: None of the CONFIG_HPS namespace options are changed via the board config.h file, nor does it make sense to move them to Kconfig. Rename these options to the HPS namespace instead. Cc: Marek Vasut Cc: Simon Goldschmidt Cc: Tien Fong Chee Signed-off-by: Tom Rini --- Note, this patch is complete as the changes to the regex qts-filter.sh are such a long line that git send-email fails. This patch was generated by: $ git grep -l CONFIG_HPS_ | xargs sed -i -e 's/CONFIG_HPS_/HPS_/g' and I will re-run that before applying. The problem is, it is the altera tools which generate all those CONFIG_* symbols which are processed by the qts-filter.sh and placed into those qts/ board directories, so this patch breaks all that. You'd have to fix the qts-filter to scrub the CONFIG_ prefixes first. Or rather, ugh, are there out of tree tools we need to deal with here? Perhaps someone with the tools could pick up and v2 something tested if so as it'll probably be a bit tricky getting it all right. See doc/README.socfpga . The out of tree tools generate board/bitstream specific input header files which you plug into the qts-filter.sh script , those files contain the CONFIG_* macros and those files get converted by the qts-filter.sh script into the output header files in board/*/qts/*.h . The output header files are what is used by U-Boot then.
Re: [PATCH 1/1] arm: socfpga: Migrate CONFIG_HPS namespace to HPS
On Tue, Aug 10, 2021 at 10:11:08PM +0200, Marek Vasut wrote: > On 8/10/21 10:05 PM, Tom Rini wrote: > > None of the CONFIG_HPS namespace options are changed via the board > > config.h file, nor does it make sense to move them to Kconfig. Rename > > these options to the HPS namespace instead. > > > > Cc: Marek Vasut > > Cc: Simon Goldschmidt > > Cc: Tien Fong Chee > > Signed-off-by: Tom Rini > > --- > > Note, this patch is complete as the changes to the regex qts-filter.sh > > are such a long line that git send-email fails. This patch was > > generated by: > > $ git grep -l CONFIG_HPS_ | xargs sed -i -e 's/CONFIG_HPS_/HPS_/g' > > and I will re-run that before applying. > > The problem is, it is the altera tools which generate all those CONFIG_* > symbols which are processed by the qts-filter.sh and placed into those qts/ > board directories, so this patch breaks all that. You'd have to fix the > qts-filter to scrub the CONFIG_ prefixes first. Or rather, ugh, are there out of tree tools we need to deal with here? Perhaps someone with the tools could pick up and v2 something tested if so as it'll probably be a bit tricky getting it all right. -- Tom signature.asc Description: PGP signature
Re: RFC: Support for U-Boot phases in Kconfig
Hi Sean,
On Mon, 9 Aug 2021 at 16:31, Sean Anderson wrote:
>
>
>
> On 8/7/21 6:23 PM, Simon Glass wrote:
> > Hi,
> >
> > U-Boot can be configured to build the source multiple times to product
multiple
> > 'phases'. The main phase is the full U-Boot, but an 'SPL' (Secondary
Program
> > Loader) build can produce a cut-down image only suitable for loading
U-Boot
> > proper.
> >
> > SPL does not want to use the same Kconfig options, since that would
produce the
> > same binary. Instead we have two copies of some options, one with an
SPL prefix,
> > that can be configured independently. In the source code we can use a
macro to
> > see if code should be run:
> >
> > if (CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)) {
> > ...
> > }
> >
> > This expands to check either checking SYS_STDIO_DEREGISTER or
> > SPL_SYS_STDIO_DEREGISTER, depending on which phase is being built.
> >
> > U-Boot also has TPL (Tertiary Program Loader) which works a similar
way. This
> > is causing quite an expansion of the Kconfig source, with quite a bit of
> > duplication. Each time a new feature needs to be supported in SPL, it
involves
> > a patch to add the same options again but for SPL.
> >
> >
> > Here are some proposed changes to make it easier to deal with SPL/TPL:
> >
> > 1. Kconfig support
[..]
> > 4. Add macros to help avoid more #ifdefs
> >
> > We sometimes have to use #ifdefs in structs or drivers:
> >
> > struct spl_image_loader {
> > #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > const char *name;
> > #endif
> > ...
> > };
> >
> > UCLASS_DRIVER(spi) = {
> > .id = UCLASS_SPI,
> > .name = "spi",
> > .flags = DM_UC_FLAG_SEQ_ALIAS,
> > #if CONFIG_IS_ENABLED(OF_CONTROL) &&
!CONFIG_IS_ENABLED(OF_PLATDATA)
> > .post_bind = dm_scan_fdt_dev,
> > #endif
> > ...
> > };
> >
> > This is a pain. We can add an IF_CONFIG macro to help with this:
> >
> > struct spl_image_loader {
> > IF_CONFIG(LIBCOMMON_SUPPORT, const char *name;)
> > ...
> > };
> >
> > UCLASS_DRIVER(spi) = {
> > .id = UCLASS_SPI,
> > .name = "spi",
> > .flags = DM_UC_FLAG_SEQ_ALIAS,
> > IF_CONFIG(REAL, .post_bind = dm_scan_fdt_dev,)
>
> Wouldn't cpp eat the trailing comma here? This seems pretty tricky to
> use. And of course, you still need something like
Yes you're right. The comma is a pain. Needs more thought.
>
> struct spl_image_loader *loader;
> loader = ... ;
> #if CONFIG(LIBCOMMON_SUPPORT)
> foo(loader->name);
> #endif
>
> unless you have some other macro to wrap the name access.
Yes that's the other side of it that I forgot. I think a macro that
converts the member to NULL or something might work. Needs more thought.
[..]
> > 6. Discarding static functions
> >
> > We sometimes see code like this:
> >
> > #if CONFIG_IS_ENABLED(OF_REAL)
> > static const struct udevice_id apl_ns16550_serial_ids[] = {
> > { .compatible = "intel,apl-ns16550" },
> > { },
> > };
> > #endif
> >
> > U_BOOT_DRIVER(intel_apl_ns16550) = {
> > .name = "intel_apl_ns16550",
> > .id = UCLASS_SERIAL,
> > .of_match = of_match_ptr(apl_ns16550_serial_ids),
> > .plat_auto = sizeof(struct apl_ns16550_plat),
> > .priv_auto = sizeof(struct ns16550),
> > ...
> > };
> >
> > The of_match_ptr() avoids an #ifdef in the driver declaration since it
evaluates
> > to NULL if !CONFIG_IS_ENABLED(OF_REAL) but we still need an #ifdef
around the
> > function, since it is static and would otherwise produce a warning.
> >
> > One solution is to drop the 'static'. But this is not very nice, since
the
> > structure clearly should not be used from another file.
> >
> > We can add STATIC_IF_CONFIG() to help with this:
> >
> > STATIC_IF_CONFIG(OF_REAL) const struct udevice_id
> > apl_ns16550_serial_ids[] = {
> > { .compatible = "intel,apl-ns16550" },
> > { },
> > };
> > #endif
> >
> > It expands to 'static' if CONFIG(OF_REAL) is enabled, otherwise it
expand to
> > nothing, in the hope that the compiler drops the data. Failing that it
would
> > also be possible to have it expand to '__section(".discard.config")' so
at least
> > the struct is discarded, even if the compatible string is not. The
behaviour of
> > gcc/binutils in this area is not always as might be hoped.
> >
>
> What about __maybe_unused? Do functions marked that way get GC'd?
Yes but not that well. Making the macro expand to 'static __maybe_unused'
seems like a good idea to me.
Regards,
SImon
Re: [PATCH 1/1] arm: socfpga: Migrate CONFIG_HPS namespace to HPS
On Tue, Aug 10, 2021 at 10:11:08PM +0200, Marek Vasut wrote: > On 8/10/21 10:05 PM, Tom Rini wrote: > > None of the CONFIG_HPS namespace options are changed via the board > > config.h file, nor does it make sense to move them to Kconfig. Rename > > these options to the HPS namespace instead. > > > > Cc: Marek Vasut > > Cc: Simon Goldschmidt > > Cc: Tien Fong Chee > > Signed-off-by: Tom Rini > > --- > > Note, this patch is complete as the changes to the regex qts-filter.sh > > are such a long line that git send-email fails. This patch was > > generated by: > > $ git grep -l CONFIG_HPS_ | xargs sed -i -e 's/CONFIG_HPS_/HPS_/g' > > and I will re-run that before applying. > > The problem is, it is the altera tools which generate all those CONFIG_* > symbols which are processed by the qts-filter.sh and placed into those qts/ > board directories, so this patch breaks all that. You'd have to fix the > qts-filter to scrub the CONFIG_ prefixes first. Do you mean the in-tree qts-filter.sh file needs to be changed, or something else? -- Tom signature.asc Description: PGP signature
[PATCH] aristainetos2: Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS
Rename CONFIG_EXTRA_ENV_BOARD_SETTINGS to EXTRA_ENV_BOARD_SETTINGS in order to not further add to the CONFIG namespace. Cc: Heiko Schocher Signed-off-by: Tom Rini --- include/configs/aristainetos2.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/aristainetos2.h b/include/configs/aristainetos2.h index 78fa1a969e7f..69398787d9e7 100644 --- a/include/configs/aristainetos2.h +++ b/include/configs/aristainetos2.h @@ -93,13 +93,13 @@ #endif #if (CONFIG_SYS_BOARD_VERSION == 5) -#define CONFIG_EXTRA_ENV_BOARD_SETTINGS \ +#define EXTRA_ENV_BOARD_SETTINGS \ "dead=while true; do; " \ "led led_red on; sleep 1;" \ "led led_red off; sleep 1;" \ "done\0" #elif (CONFIG_SYS_BOARD_VERSION == 6) -#define CONFIG_EXTRA_ENV_BOARD_SETTINGS \ +#define EXTRA_ENV_BOARD_SETTINGS \ "dead=while true; do; " \ "led led_red on; led led_red2 on; sleep 1;" \ "led led_red off; led led_red2 off;; sleep 1;" \ @@ -414,7 +414,7 @@ "run main_rescue_boot;" \ "fi; \0"\ HAB_EXTRA_SETTINGS \ - CONFIG_EXTRA_ENV_BOARD_SETTINGS + EXTRA_ENV_BOARD_SETTINGS #define CONFIG_ARP_TIMEOUT 200UL -- 2.17.1
[PATCH] usb: dwc2: Rename CONFIG_DWC2 namespace to DWC2
There are a number of DWC2 configuration options that are set in dwc2.h
and referenced in dwc2.c only. Move these out of the CONFIG_DWC2
namespace and in to the DWC2 namespace. Note that hikey was defining an
option that was already always enabled, so we can remove that hunk.
Cc: Marek Vasut
Signed-off-by: Tom Rini
---
drivers/usb/host/dwc2.c | 52 ++--
drivers/usb/host/dwc2.h | 42 ++---
include/configs/hikey.h | 4 ---
scripts/config_whitelist.txt | 20 --
4 files changed, 47 insertions(+), 71 deletions(-)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 43cc2e04339c..23060fc369c0 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -86,14 +86,14 @@ static void init_fslspclksel(struct dwc2_core_regs *regs)
{
uint32_t phyclk;
-#if (CONFIG_DWC2_PHY_TYPE == DWC2_PHY_TYPE_FS)
+#if (DWC2_PHY_TYPE == DWC2_PHY_TYPE_FS)
phyclk = DWC2_HCFG_FSLSPCLKSEL_48_MHZ; /* Full speed PHY */
#else
/* High speed PHY running at full speed or high speed */
phyclk = DWC2_HCFG_FSLSPCLKSEL_30_60_MHZ;
#endif
-#ifdef CONFIG_DWC2_ULPI_FS_LS
+#ifdef DWC2_ULPI_FS_LS
uint32_t hwcfg2 = readl(>ghwcfg2);
uint32_t hval = (ghwcfg2 & DWC2_HWCFG2_HS_PHY_TYPE_MASK) >>
DWC2_HWCFG2_HS_PHY_TYPE_OFFSET;
@@ -257,28 +257,28 @@ static void dwc_otg_core_host_init(struct udevice *dev,
/* Initialize Host Configuration Register */
init_fslspclksel(regs);
-#ifdef CONFIG_DWC2_DFLT_SPEED_FULL
+#ifdef DWC2_DFLT_SPEED_FULL
setbits_le32(>host_regs.hcfg, DWC2_HCFG_FSLSSUPP);
#endif
/* Configure data FIFO sizes */
-#ifdef CONFIG_DWC2_ENABLE_DYNAMIC_FIFO
+#ifdef DWC2_ENABLE_DYNAMIC_FIFO
if (readl(>ghwcfg2) & DWC2_HWCFG2_DYNAMIC_FIFO) {
/* Rx FIFO */
- writel(CONFIG_DWC2_HOST_RX_FIFO_SIZE, >grxfsiz);
+ writel(DWC2_HOST_RX_FIFO_SIZE, >grxfsiz);
/* Non-periodic Tx FIFO */
- nptxfifosize |= CONFIG_DWC2_HOST_NPERIO_TX_FIFO_SIZE <<
+ nptxfifosize |= DWC2_HOST_NPERIO_TX_FIFO_SIZE <<
DWC2_FIFOSIZE_DEPTH_OFFSET;
- nptxfifosize |= CONFIG_DWC2_HOST_RX_FIFO_SIZE <<
+ nptxfifosize |= DWC2_HOST_RX_FIFO_SIZE <<
DWC2_FIFOSIZE_STARTADDR_OFFSET;
writel(nptxfifosize, >gnptxfsiz);
/* Periodic Tx FIFO */
- ptxfifosize |= CONFIG_DWC2_HOST_PERIO_TX_FIFO_SIZE <<
+ ptxfifosize |= DWC2_HOST_PERIO_TX_FIFO_SIZE <<
DWC2_FIFOSIZE_DEPTH_OFFSET;
- ptxfifosize |= (CONFIG_DWC2_HOST_RX_FIFO_SIZE +
- CONFIG_DWC2_HOST_NPERIO_TX_FIFO_SIZE) <<
+ ptxfifosize |= (DWC2_HOST_RX_FIFO_SIZE +
+ DWC2_HOST_NPERIO_TX_FIFO_SIZE) <<
DWC2_FIFOSIZE_STARTADDR_OFFSET;
writel(ptxfifosize, >hptxfsiz);
}
@@ -340,7 +340,7 @@ static void dwc_otg_core_init(struct udevice *dev)
struct dwc2_core_regs *regs = priv->regs;
uint32_t ahbcfg = 0;
uint32_t usbcfg = 0;
- uint8_t brst_sz = CONFIG_DWC2_DMA_BURST_SIZE;
+ uint8_t brst_sz = DWC2_DMA_BURST_SIZE;
/* Common Initialization */
usbcfg = readl(>gusbcfg);
@@ -357,7 +357,7 @@ static void dwc_otg_core_init(struct udevice *dev)
}
/* Set external TS Dline pulsing */
-#ifdef CONFIG_DWC2_TS_DLINE
+#ifdef DWC2_TS_DLINE
usbcfg |= DWC2_GUSBCFG_TERM_SEL_DL_PULSE;
#else
usbcfg &= ~DWC2_GUSBCFG_TERM_SEL_DL_PULSE;
@@ -371,8 +371,8 @@ static void dwc_otg_core_init(struct udevice *dev)
* This programming sequence needs to happen in FS mode before
* any other programming occurs
*/
-#if defined(CONFIG_DWC2_DFLT_SPEED_FULL) && \
- (CONFIG_DWC2_PHY_TYPE == DWC2_PHY_TYPE_FS)
+#if defined(DWC2_DFLT_SPEED_FULL) && \
+ (DWC2_PHY_TYPE == DWC2_PHY_TYPE_FS)
/* If FS mode with FS PHY */
setbits_le32(>gusbcfg, DWC2_GUSBCFG_PHYSEL);
@@ -387,7 +387,7 @@ static void dwc_otg_core_init(struct udevice *dev)
if (readl(>gintsts) & DWC2_GINTSTS_CURMODE_HOST)
init_fslspclksel(regs);
-#ifdef CONFIG_DWC2_I2C_ENABLE
+#ifdef DWC2_I2C_ENABLE
/* Program GUSBCFG.OtgUtmifsSel to I2C */
setbits_le32(>gusbcfg, DWC2_GUSBCFG_OTGUTMIFSSEL);
@@ -407,16 +407,16 @@ static void dwc_otg_core_init(struct udevice *dev)
* immediately after setting phyif.
*/
usbcfg &= ~(DWC2_GUSBCFG_ULPI_UTMI_SEL | DWC2_GUSBCFG_PHYIF);
- usbcfg |= CONFIG_DWC2_PHY_TYPE << DWC2_GUSBCFG_ULPI_UTMI_SEL_OFFSET;
+ usbcfg |= DWC2_PHY_TYPE << DWC2_GUSBCFG_ULPI_UTMI_SEL_OFFSET;
if (usbcfg & DWC2_GUSBCFG_ULPI_UTMI_SEL) { /* ULPI interface */
-#ifdef
Re: [PATCH 1/1] arm: socfpga: Migrate CONFIG_HPS namespace to HPS
On 8/10/21 10:05 PM, Tom Rini wrote: None of the CONFIG_HPS namespace options are changed via the board config.h file, nor does it make sense to move them to Kconfig. Rename these options to the HPS namespace instead. Cc: Marek Vasut Cc: Simon Goldschmidt Cc: Tien Fong Chee Signed-off-by: Tom Rini --- Note, this patch is complete as the changes to the regex qts-filter.sh are such a long line that git send-email fails. This patch was generated by: $ git grep -l CONFIG_HPS_ | xargs sed -i -e 's/CONFIG_HPS_/HPS_/g' and I will re-run that before applying. The problem is, it is the altera tools which generate all those CONFIG_* symbols which are processed by the qts-filter.sh and placed into those qts/ board directories, so this patch breaks all that. You'd have to fix the qts-filter to scrub the CONFIG_ prefixes first.
U-boot doesn't start anymore
Hi,
I have an U_Boot tailored for a specific board.
In this U_Boot we have a command: “*myperipheral*"
U_BOOT_CMD(
myperipheral, 6, 0, do_my_periph,
"my peripheral info",
/* */"info - important hw
info\n"
" myperipheral [disable/enable]- disable/enable
system\n"
" myperipheral stop - stop the
driver\n"
" myperipheral reapply-clocks - reapply clock
setting \n"
" myperipheral reg - read
register\n"
);
Everything works fine so far.
Then I changed this command by adding a new parameter : *test*
U_BOOT_CMD(
myperipheral, 6, 0, do_my_periph,
"my peripheral info",
/* */"info - important hw
info\n"
" myperipheral [disable/enable]- disable/enable
system\n"
" myperipheral stop - stop the
driver\n"
" myperipheral reapply-clocks - reapply clock
setting \n"
" myperipheral reg - read
register\n"
*" myperipheral test- periph
test"*
);
So I added a function *my_test_func(),* which is called when “myperipheral
test” command is issued on u_boot cmd line.
void *my_test_func* (void) {
int i=0;
printf("Test nr %d\n", i++);
printf("Test nr %d\n", i++);
printf("Test nr %d\n", i++);
printf("Test nr %d\n", i++);
printf("Test nr %d\n", i++);
// and more 20 lines with printf("Test nr %d\n", i++);
}
Again everything works fine when I issue “myperipheral test" , I can see 25
time of prints .
But when I add another 25 lines of prints in my_test_func, rebuild and
reflash, the U_Boot does not start anymore.
Does anyone knows why ?
I mention that I’ve tried to add this my_test_function() (on both variants
with 25 and 50 prints) in myperipheral_probe() and got the same results:
with 25 U_boot starts and prints, and with 50 u_boot doesn’t start!
Of course I have real problem to solve, but my real problem leads me to
this test, because something like this I need to do in my real problem.
Best regards,
Claudiu
[PATCH] rpi: Conditionally add simple-framebuffer node
It appears that RPi firmware has already added framebuffer
node under /chosen, at least on RPi 2 versions. So check
for this and don't add duplicate node.
Signed-off-by: Ivan T. Ivanov
---
board/raspberrypi/rpi/rpi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..372b26b6f2 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -497,12 +497,11 @@ void *board_fdt_blob_setup(void)
int ft_board_setup(void *blob, struct bd_info *bd)
{
- /*
-* For now, we simply always add the simplefb DT node. Later, we
-* should be more intelligent, and e.g. only do this if no enabled DT
-* node exists for the "real" graphics driver.
-*/
- lcd_dt_simplefb_add_node(blob);
+ int node;
+
+ node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
+ if (node < 0)
+ lcd_dt_simplefb_add_node(blob);
#ifdef CONFIG_EFI_LOADER
/* Reserve the spin table */
--
2.32.0
[PATCH 5/5] clk: ti: k3: Update driver to account for divider flags
From: Suman Anna
The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in
turn serve as inputs to other HSDIV output clocks. These clocks use
the actual value to compute the divider clock rate, and need to be
registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk
driver and data lacks the infrastructure to pass in divider flags.
Update the driver and data to account for these divider flags.
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
arch/arm/mach-k3/j7200/clk-data.c | 85 ---
arch/arm/mach-k3/j721e/clk-data.c | 111 +++---
drivers/clk/ti/clk-k3.c | 4 +-
include/k3-clk.h | 30
4 files changed, 118 insertions(+), 112 deletions(-)
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
index 649d28b1db0b..7a8e6bad57e3 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -6,6 +6,7 @@
*
* Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/
*/
+#include
#include "k3-clk.h"
static const char * const gluelogic_hfosc0_clkout_parents[] = {
@@ -321,18 +322,18 @@ static const struct clk_data clk_list[] = {
CLK_MUX("wkup_fref_clksel_out0", wkup_fref_clksel_out0_parents, 2,
0x43008050, 8, 1, 0),
CLK_MUX("main_pll_hfosc_sel_out1", main_pll_hfosc_sel_out1_parents, 2,
0x43008084, 0, 1, 0),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_main_1_foutvcop_clk",
"main_pll_hfosc_sel_out1", 0x681000, 0, 192000),
- CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681038, 16, 3, 0),
- CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x681038, 24, 3, 0),
+ CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681038, 16, 3, 0,
CLK_DIVIDER_ONE_BASED),
+ CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x681038, 24, 3, 0,
CLK_DIVIDER_ONE_BASED),
CLK_PLL("pllfracf_ssmod_16fft_mcu_0_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d0, 0),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_mcu_1_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d01000, 0, 24),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_mcu_2_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d02000, 0, 20),
- CLK_DIV("postdiv2_16fft_main_1_hsdivout5_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk", 0x681094, 0, 7, 0),
- CLK_DIV("hsdiv1_16fft_mcu_0_hsdivout0_clk",
"pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 0x40d00080, 0, 7, 0),
- CLK_DIV("hsdiv4_16fft_mcu_1_hsdivout3_clk",
"pllfracf_ssmod_16fft_mcu_1_foutvcop_clk", 0x40d0108c, 0, 7, 0),
- CLK_DIV("hsdiv4_16fft_mcu_1_hsdivout4_clk",
"pllfracf_ssmod_16fft_mcu_1_foutvcop_clk", 0x40d01090, 0, 7, 0),
- CLK_DIV_DEFFREQ("hsdiv4_16fft_mcu_2_hsdivout4_clk",
"pllfracf_ssmod_16fft_mcu_2_foutvcop_clk", 0x40d02090, 0, 7, 0, 1),
+ CLK_DIV("postdiv2_16fft_main_1_hsdivout5_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk", 0x681094, 0, 7, 0, 0),
+ CLK_DIV("hsdiv1_16fft_mcu_0_hsdivout0_clk",
"pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 0x40d00080, 0, 7, 0, 0),
+ CLK_DIV("hsdiv4_16fft_mcu_1_hsdivout3_clk",
"pllfracf_ssmod_16fft_mcu_1_foutvcop_clk", 0x40d0108c, 0, 7, 0, 0),
+ CLK_DIV("hsdiv4_16fft_mcu_1_hsdivout4_clk",
"pllfracf_ssmod_16fft_mcu_1_foutvcop_clk", 0x40d01090, 0, 7, 0, 0),
+ CLK_DIV_DEFFREQ("hsdiv4_16fft_mcu_2_hsdivout4_clk",
"pllfracf_ssmod_16fft_mcu_2_foutvcop_clk", 0x40d02090, 0, 7, 0, 0, 1),
CLK_MUX_PLLCTRL("k3_pll_ctrl_wrap_wkup_0_sysclkout_clk",
k3_pll_ctrl_wrap_wkup_0_sysclkout_clk_parents, 2, 0x4201, 0),
- CLK_DIV("k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
"k3_pll_ctrl_wrap_wkup_0_sysclkout_clk", 0x42010118, 0, 5, 0),
+ CLK_DIV("k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
"k3_pll_ctrl_wrap_wkup_0_sysclkout_clk", 0x42010118, 0, 5, 0, 0),
CLK_MUX("mcu_ospi_ref_clk_sel_out0", mcu_ospi_ref_clk_sel_out0_parents,
2, 0x40f08030, 0, 1, 0),
CLK_MUX("mcuusart_clk_sel_out0", mcuusart_clk_sel_out0_parents, 2,
0x40f081c0, 0, 1, 0),
CLK_MUX("wkup_gpio0_clksel_out0", wkup_gpio0_clksel_out0_parents, 4,
0x43008070, 0, 2, 0),
@@ -353,46 +354,46 @@ static const struct clk_data clk_list[] = {
CLK_FIXED_RATE("board_0_mcu_i2c0_scl_out", 0, 0),
CLK_FIXED_RATE("board_0_wkup_lf_clkin_out", 0, 0),
CLK_FIXED_RATE("emmcsd4ss_main_0_emmcsdss_io_clk_o", 0, 0),
- CLK_DIV_DEFFREQ("hsdiv4_16fft_main_1_hsdivout0_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681080, 0, 7, 0, 19200),
- CLK_DIV("hsdiv4_16fft_main_1_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681088, 0, 7, 0),
- CLK_DIV("hsdiv4_16fft_mcu_1_hsdivout1_clk",
[PATCH 1/5] arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocks
From: Suman Anna
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.
The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.
Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
arch/arm/mach-k3/j721e/clk-data.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/j721e/clk-data.c
b/arch/arm/mach-k3/j721e/clk-data.c
index 953ac457130b..ff9262d7bcee 100644
--- a/arch/arm/mach-k3/j721e/clk-data.c
+++ b/arch/arm/mach-k3/j721e/clk-data.c
@@ -463,8 +463,8 @@ static const struct clk_data clk_list[] = {
CLK_MUX("wkup_fref_clksel_out0", wkup_fref_clksel_out0_parents, 2,
0x43008050, 8, 1, 0),
CLK_MUX("main_pll_hfosc_sel_out1", main_pll_hfosc_sel_out1_parents, 2,
0x43008084, 0, 1, 0),
CLK_PLL_DEFFREQ("pllfrac2_ssmod_16fft_main_1_foutvcop_clk",
"main_pll_hfosc_sel_out1", 0x681000, 0, 192000),
- CLK_DIV("pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfrac2_ssmod_16fft_main_1_foutvcop_clk", 0x680038, 24, 3, 0),
- CLK_DIV("pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfrac2_ssmod_16fft_main_1_foutvcop_clk", 0x681038, 16, 3, 0),
+ CLK_DIV("pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfrac2_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x681038, 24, 3, 0),
CLK_PLL("pllfrac2_ssmod_16fft_mcu_0_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d0, 0),
CLK_PLL_DEFFREQ("pllfrac2_ssmod_16fft_mcu_1_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d01000, 0, 24),
CLK_PLL_DEFFREQ("pllfrac2_ssmod_16fft_mcu_2_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d02000, 0, 20),
@@ -523,8 +523,8 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_mcu_2_hsdivout3_clk",
"pllfrac2_ssmod_16fft_mcu_2_foutvcop_clk", 0x40d0208c, 0, 7, 0),
CLK_FIXED_RATE("j7_wakeup_16ff_wkup_0_wkup_rcosc_32k_clk", 32000, 0),
CLK_PLL("pllfrac2_ssmod_16fft_main_0_foutvcop_clk",
"main_pll_hfosc_sel_out0", 0x68, 0),
- CLK_DIV("pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk_subdiv",
"pllfrac2_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 24, 3, 0),
- CLK_DIV("pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk",
"pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk_subdiv",
"pllfrac2_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk",
"pllfrac2_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 0x680038, 24, 3, 0),
CLK_PLL("pllfrac2_ssmod_16fft_main_13_foutvcop_clk",
"main_pll_hfosc_sel_out13", 0x68d000, 0),
CLK_PLL("pllfrac2_ssmod_16fft_main_14_foutvcop_clk",
"main_pll_hfosc_sel_out14", 0x68e000, 0),
CLK_PLL("pllfrac2_ssmod_16fft_main_16_foutvcop_clk",
"main_pll_hfosc_sel_out16", 0x69, 0),
--
2.28.0
[PATCH 2/5] arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocks
From: Suman Anna
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.
The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.
Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna
Signed-off-by: Dave Gerlach
---
arch/arm/mach-k3/j7200/clk-data.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
index 93c067079ab6..49145bbfc8cd 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -319,8 +319,8 @@ static const struct clk_data clk_list[] = {
CLK_MUX("wkup_fref_clksel_out0", wkup_fref_clksel_out0_parents, 2,
0x43008050, 8, 1, 0),
CLK_MUX("main_pll_hfosc_sel_out1", main_pll_hfosc_sel_out1_parents, 2,
0x43008084, 0, 1, 0),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_main_1_foutvcop_clk",
"main_pll_hfosc_sel_out1", 0x681000, 0, 192000),
- CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x680038, 24, 3, 0),
- CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681038, 16, 3, 0),
+ CLK_DIV("pllfracf_ssmod_16fft_main_1_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_1_foutpostdiv_clk_subdiv", 0x681038, 24, 3, 0),
CLK_PLL("pllfracf_ssmod_16fft_mcu_0_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d0, 0),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_mcu_1_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d01000, 0, 24),
CLK_PLL_DEFFREQ("pllfracf_ssmod_16fft_mcu_2_foutvcop_clk",
"wkup_fref_clksel_out0", 0x40d02000, 0, 20),
@@ -360,8 +360,8 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_mcu_2_hsdivout2_clk",
"pllfracf_ssmod_16fft_mcu_2_foutvcop_clk", 0x40d02088, 0, 7, 0),
CLK_DIV("hsdiv4_16fft_mcu_2_hsdivout3_clk",
"pllfracf_ssmod_16fft_mcu_2_foutvcop_clk", 0x40d0208c, 0, 7, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_0_foutvcop_clk",
"main_pll_hfosc_sel_out0", 0x68, 0),
- CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 24, 3, 0),
- CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv",
"pllfracf_ssmod_16fft_main_0_foutvcop_clk", 0x680038, 16, 3, 0),
+ CLK_DIV("pllfracf_ssmod_16fft_main_0_foutpostdiv_clk",
"pllfracf_ssmod_16fft_main_0_foutpostdiv_clk_subdiv", 0x680038, 24, 3, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_12_foutvcop_clk",
"main_pll_hfosc_sel_out12", 0x68c000, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_14_foutvcop_clk",
"main_pll_hfosc_sel_out14", 0x68e000, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_2_foutvcop_clk",
"main_pll_hfosc_sel_out2", 0x682000, 0),
--
2.28.0
[PATCH 4/5] clk: ti: k3-pll: Change DIV_CTRL programming to read-modify-write
There are three different divider values in the DIV_CTRL register
controlled by the k3-pll driver. Currently the ti_pll_clk_set_rate
function writes the entire register when programming plld, even though
plld only resides in the lower 6 bits.
Change the plld programming to read-modify-write to only affect the
relevant bits for plld and to preserve the other two divider values
present in the upper 16 bits, otherwise they will always get set to zero
when programming plld.
Fixes: 0aa2930ca192 ("clk: add support for TI K3 SoC PLL")
Signed-off-by: Dave Gerlach
---
drivers/clk/ti/clk-k3-pll.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/ti/clk-k3-pll.c b/drivers/clk/ti/clk-k3-pll.c
index bf2407a020a3..bf762c558ef0 100644
--- a/drivers/clk/ti/clk-k3-pll.c
+++ b/drivers/clk/ti/clk-k3-pll.c
@@ -2,7 +2,7 @@
/*
* Texas Instruments K3 SoC PLL clock driver
*
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/
* Tero Kristo
*/
@@ -122,6 +122,7 @@ static ulong ti_pll_clk_set_rate(struct clk *clk, ulong
rate)
unsigned long pllm;
u32 pllfm = 0;
unsigned long plld;
+ u32 div_ctrl;
u32 rem;
int shift;
@@ -175,7 +176,15 @@ static ulong ti_pll_clk_set_rate(struct clk *clk, ulong
rate)
writel(pllm, pll->reg + PLL_16FFT_FREQ_CTRL0);
writel(pllfm, pll->reg + PLL_16FFT_FREQ_CTRL1);
- writel(plld, pll->reg + PLL_16FFT_DIV_CTRL);
+
+ /*
+* div_ctrl register contains other divider values, so rmw
+* only plld and leave existing values alone
+*/
+ div_ctrl = readl(pll->reg + PLL_16FFT_DIV_CTRL);
+ div_ctrl &= ~PLL_16FFT_DIV_CTRL_REF_DIV_MASK;
+ div_ctrl |= plld;
+ writel(div_ctrl, pll->reg + PLL_16FFT_DIV_CTRL);
ctrl &= ~PLL_16FFT_CTRL_BYPASS_EN;
ctrl |= PLL_16FFT_CTRL_PLL_EN;
--
2.28.0
[PATCH 0/5] arm: mach-k3: Fixes for j721e/j7200 clock data and drivers
Hi, This series contains several fixes for TI j721e and j7200 platforms data and also some fixes for TI clock drivers that make use of this data. All fixes are related to PLL post dividers reporting the wrong frequency, and now the new frequencies for below clocks match what registers are actually configured for. Clock: Old Frequency -> New Frequency - postdiv2_16fft_main_0_hsdivout6_clk: 6667 -> 2 postdiv2_16fft_main_1_hsdivout5_clk: 32000 -> 96000 postdiv2_16fft_main_1_hsdivout7_clk: 32000 -> 96000 Regards, Dave Dave Gerlach (2): arm: mach-k3: Add note to auto-generated files clk: ti: k3-pll: Change DIV_CTRL programming to read-modify-write Suman Anna (3): arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocks arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocks clk: ti: k3: Update driver to account for divider flags arch/arm/mach-k3/j7200/clk-data.c | 87 --- arch/arm/mach-k3/j7200/dev-data.c | 2 + arch/arm/mach-k3/j721e/clk-data.c | 113 +++--- arch/arm/mach-k3/j721e/dev-data.c | 2 + drivers/clk/ti/clk-k3-pll.c | 13 +++- drivers/clk/ti/clk-k3.c | 4 +- include/k3-clk.h | 30 7 files changed, 137 insertions(+), 114 deletions(-) -- 2.28.0
[PATCH 3/5] arm: mach-k3: Add note to auto-generated files
Add a note to the automatically generated clk-data and dev-data files for j721e and j7200 to indicate that they are in fact auto-generated and should not be hand edited. Signed-off-by: Dave Gerlach --- arch/arm/mach-k3/j7200/clk-data.c | 2 ++ arch/arm/mach-k3/j7200/dev-data.c | 2 ++ arch/arm/mach-k3/j721e/clk-data.c | 2 ++ arch/arm/mach-k3/j721e/dev-data.c | 2 ++ 4 files changed, 8 insertions(+) diff --git a/arch/arm/mach-k3/j7200/clk-data.c b/arch/arm/mach-k3/j7200/clk-data.c index 49145bbfc8cd..649d28b1db0b 100644 --- a/arch/arm/mach-k3/j7200/clk-data.c +++ b/arch/arm/mach-k3/j7200/clk-data.c @@ -2,6 +2,8 @@ /* * J7200 specific clock platform data * + * This file is auto generated. Please do not edit directly. + * * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/ */ #include "k3-clk.h" diff --git a/arch/arm/mach-k3/j7200/dev-data.c b/arch/arm/mach-k3/j7200/dev-data.c index c68bcc58e9a7..f7b7892da97b 100644 --- a/arch/arm/mach-k3/j7200/dev-data.c +++ b/arch/arm/mach-k3/j7200/dev-data.c @@ -2,6 +2,8 @@ /* * J7200 specific device platform data * + * This file is auto generated. Please do not edit directly. + * * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/ */ #include "k3-dev.h" diff --git a/arch/arm/mach-k3/j721e/clk-data.c b/arch/arm/mach-k3/j721e/clk-data.c index ff9262d7bcee..aa3f50a02f59 100644 --- a/arch/arm/mach-k3/j721e/clk-data.c +++ b/arch/arm/mach-k3/j721e/clk-data.c @@ -2,6 +2,8 @@ /* * J721E specific clock platform data * + * This file is auto generated. Please do not edit directly. + * * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/ */ #include "k3-clk.h" diff --git a/arch/arm/mach-k3/j721e/dev-data.c b/arch/arm/mach-k3/j721e/dev-data.c index 96393c713278..a8bc6ce20d1d 100644 --- a/arch/arm/mach-k3/j721e/dev-data.c +++ b/arch/arm/mach-k3/j721e/dev-data.c @@ -2,6 +2,8 @@ /* * J721E specific device platform data * + * This file is auto generated. Please do not edit directly. + * * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/ */ #include "k3-dev.h" -- 2.28.0
Re: RFC: Support for U-Boot phases in Kconfig
On Tue, Aug 10, 2021 at 08:58:46AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 9 Aug 2021 at 13:11, Tom Rini wrote:
> >
> > On Sat, Aug 07, 2021 at 04:23:36PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > U-Boot can be configured to build the source multiple times to product
> > > multiple
> > > 'phases'. The main phase is the full U-Boot, but an 'SPL' (Secondary
> > > Program
> > > Loader) build can produce a cut-down image only suitable for loading
> > > U-Boot
> > > proper.
> > >
> > > SPL does not want to use the same Kconfig options, since that would
> > > produce the
> > > same binary. Instead we have two copies of some options, one with an SPL
> > > prefix,
> > > that can be configured independently. In the source code we can use a
> > > macro to
> > > see if code should be run:
> > >
> > >if (CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)) {
> > >...
> > >}
> > >
> > > This expands to check either checking SYS_STDIO_DEREGISTER or
> > > SPL_SYS_STDIO_DEREGISTER, depending on which phase is being built.
> > >
> > > U-Boot also has TPL (Tertiary Program Loader) which works a similar way.
> > > This
> > > is causing quite an expansion of the Kconfig source, with quite a bit of
> > > duplication. Each time a new feature needs to be supported in SPL, it
> > > involves
> > > a patch to add the same options again but for SPL.
> > >
> > >
> > > Here are some proposed changes to make it easier to deal with SPL/TPL:
> > >
> > > 1. Kconfig support
> > >
> > > At present we do things like this when we need to control an option
> > > separately
> > > in U-Boot proper and SPL:
> > >
> > > config SYS_STDIO_DEREGISTER
> > > bool "Allow deregistering stdio devices"
> > > depends on DM_DEVICE_REMOVE
> > > default y if USB_KEYBOARD
> > > help
> > > Generally there is no need to deregister stdio devices since they
> > > are never deactivated. But if a stdio device is used which can be
> > > removed (for example a USB keyboard) then this option can be
> > > enabled to ensure this is handled correctly.
> > >
> > > config SPL_SYS_STDIO_DEREGISTER
> > > bool "Allow deregistering stdio devices in SPL"
> > > depends on SPL_DM_DEVICE_REMOVE
> > > help
> > > Generally there is no need to deregister stdio devices since they
> > > are never deactivated. But if a stdio device is used which can be
> > > removed (for example a USB keyboard) then this option can be
> > > enabled to ensure this is handled correctly. This is very rarely
> > > needed in SPL.
> > >
> > > This is a pain. Apart from the duplication, sometimes the SPL version is
> > > in a
> > > different file or a different part of the file, making it hard to find
> > > related
> > > options or update them in sync.
> > >
> > > Instead, we can add a 'phase' command to the Kconfig language, so we can
> > > do:
> > >
> > > config SYS_STDIO_DEREGISTER
> > > bool "Allow deregistering stdio devices"
> > > phases
> > > depends on p.DM_DEVICE_REMOVE
> > > phase MAIN default y if USB_KEYBOARD
> > > help
> > > Generally there is no need to deregister stdio devices since they
> > > are never deactivated. But if a stdio device is used which can be
> > > removed (for example a USB keyboard) then this option can be
> > > enabled to ensure this is handled correctly.
> > >
> > > 'phases' means this Kconfig option exists in all phases. You can also say
> > > 'phases MAIN SPL' to select just MAIN (U-Boot) and SPL.
> > >
> > > 'p.DM_DEVICE_REMOVE' means to prefix the phase with each symbol, so for
> > > U-Boot
> > > (which uses SYS_STDIO_DEREGISTER) this means DM_DEVICE_REMOVE (p is
> > > empty) and
> > > for SPL (which uses SPL_SYS_STDIO_DEREGISTER) it means
> > > SPL_DM_DEVICE_REMOVE
> > > (p is SPL_). This is somewhat similar in style to the special-case
> > > 'depends on m' in Kconfig.
> > >
> > > To make this work, we tell Kconfig that SPL is a phase with 'def_phase':
> > >
> > > config SPL
> > > def_phase
> > > depends on SUPPORT_SPL
> > > prompt "Enable SPL"
> > > help
> > > If you want to build SPL as well as the normal image, say Y.
> > >
> > > It works just the same as a bool, but kconfig also uses it to
> > > automatically add
> > > new Kconfigs for each phase. In the above example it creates both
> > > SYS_STDIO_DEREGISTER and SPL_SYS_STDIO_DEREGISTER. The option name has
> > > the text
> > > '(SPL) ' shown before the SPL option.
> > >
> > > This can easily handle Kconfigs with similar dependencies and even
> > > different
> > > ones. If the Kconfig options are not actually very similar we can still
> > > create two separate copies instead, as now.
> > >
> > > This allows us to substantially reduce the size and duplication in the
> > > Kconfig
> > > defintions. It also reduces the pain of adding another phase to U-Boot.
>
[PATCH 2/2] doc: imx: psb: Add documentation for MX8MM behavior with Fast Boot fuse blown
On iMX8MM with Fast Boot fuse blown, the SIT and A-copy image are placed at different offset than on iMX8MM with Fast Boot fuse NOT blown. List both options and both offsets to avoid confusion. Signed-off-by: Marek Vasut Cc: Marcel Ziswiler Cc: Peng Fan Cc: Stefano Babic Cc: Ye Li Cc: uboot-imx --- doc/imx/misc/psb.rst | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/doc/imx/misc/psb.rst b/doc/imx/misc/psb.rst index 3533c916405..2eccdcfccd9 100644 --- a/doc/imx/misc/psb.rst +++ b/doc/imx/misc/psb.rst @@ -75,13 +75,15 @@ offset 0x1 means 512 Bytes from the start of SD/eMMC card data partition). For details on the addition of two numbers in recommended B-copy offset, see SIT format below. -+--++---+-+ -| SoC| SIT offset (fixed) | A-copy offset (fixed) | B-copy offset (recommended) | -+--++---+-+ -| iMX7D| 0x1| 0x2 | 0x800+0x2 | -+--++---+-+ -| iMX8MM |0x41| 0x42 | 0x1000+0x42 | -+--++---+-+ ++--+-++---+-+ +| SoC| Boot Device Type| SIT offset (fixed) | A-copy offset (fixed) | B-copy offset (recommended) | ++--+-++---+-+ +| iMX7D| | 0x1| 0x2 | 0x800+0x2 | ++--+-++---+-+ +| iMX8MM | SD/eSD/MMC/eMMC normal boot |0x41| 0x42 | 0x1000+0x42 | ++--+-++---+-+ +| iMX8MM | eMMC Fast boot fuse blown | 0x1| 0x2 | 0x1000+0x2 | ++--+-++---+-+ SIT format ~~ -- 2.30.2
[PATCH 1/2] doc: imx: psb: Fix PERSIST_SECONDARY_BOOT bit location in GPR10
The PERSIST_SECONDARY_BOOT is in GPR10 address 0x30390098, adjust the text which currently says it is in GPR0 while using the correct address of GPR10. Signed-off-by: Marek Vasut Cc: Marcel Ziswiler Cc: Peng Fan Cc: Stefano Babic Cc: Ye Li Cc: uboot-imx --- doc/imx/misc/psb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/imx/misc/psb.rst b/doc/imx/misc/psb.rst index 71ac09fac8d..3533c916405 100644 --- a/doc/imx/misc/psb.rst +++ b/doc/imx/misc/psb.rst @@ -159,7 +159,7 @@ WARM reset into B-copy using WDT To perform a reboot into B-copy, the PERSIST_SECONDARY_BOOT must be set -in SRC_GPR0 register. Example on iMX8MM:: +in SRC_GPR10 register. Example on iMX8MM:: => mw 0x30390098 0x4000 -- 2.30.2
Re: [PATCH] x86: Ensure the e820 map is installed in all cases
Simon. Sorry for the late reply.
Tested on Virtualbox and on real hardware (DFI GHF51).
Works for me.
On 7/11/21 5:15 AM, Simon Glass wrote:
> This is a revert of a recent logic change in setup_zimage(). We do
> actually need to install this information always. Change it to install
> from the Coreboot tables if available, else the normal source.
>
> Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from
> coreboot")
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/lib/zimage.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 90fc8a466d7..cf4210cd4ba 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -313,12 +313,12 @@ int setup_zimage(struct boot_params *setup_base, char
> *cmd_line, int auto_boot,
> int bootproto = get_boot_protocol(hdr, false);
>
> log_debug("Setup E820 entries\n");
> - if (ll_boot_init()) {
> - setup_base->e820_entries = install_e820_map(
> - ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> - } else if (IS_ENABLED(CONFIG_COREBOOT_SYSINFO)) {
> + if (IS_ENABLED(CONFIG_COREBOOT_SYSINFO)) {
> setup_base->e820_entries = cb_install_e820_map(
> ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> + } else {
> + setup_base->e820_entries = install_e820_map(
> + ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> }
>
> if (bootproto == 0x0100) {
>
Re: RFC: Support for U-Boot phases in Kconfig
Hi Tom,
On Mon, 9 Aug 2021 at 13:11, Tom Rini wrote:
>
> On Sat, Aug 07, 2021 at 04:23:36PM -0600, Simon Glass wrote:
> > Hi,
> >
> > U-Boot can be configured to build the source multiple times to product
> > multiple
> > 'phases'. The main phase is the full U-Boot, but an 'SPL' (Secondary Program
> > Loader) build can produce a cut-down image only suitable for loading U-Boot
> > proper.
> >
> > SPL does not want to use the same Kconfig options, since that would produce
> > the
> > same binary. Instead we have two copies of some options, one with an SPL
> > prefix,
> > that can be configured independently. In the source code we can use a macro
> > to
> > see if code should be run:
> >
> >if (CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)) {
> >...
> >}
> >
> > This expands to check either checking SYS_STDIO_DEREGISTER or
> > SPL_SYS_STDIO_DEREGISTER, depending on which phase is being built.
> >
> > U-Boot also has TPL (Tertiary Program Loader) which works a similar way.
> > This
> > is causing quite an expansion of the Kconfig source, with quite a bit of
> > duplication. Each time a new feature needs to be supported in SPL, it
> > involves
> > a patch to add the same options again but for SPL.
> >
> >
> > Here are some proposed changes to make it easier to deal with SPL/TPL:
> >
> > 1. Kconfig support
> >
> > At present we do things like this when we need to control an option
> > separately
> > in U-Boot proper and SPL:
> >
> > config SYS_STDIO_DEREGISTER
> > bool "Allow deregistering stdio devices"
> > depends on DM_DEVICE_REMOVE
> > default y if USB_KEYBOARD
> > help
> > Generally there is no need to deregister stdio devices since they
> > are never deactivated. But if a stdio device is used which can be
> > removed (for example a USB keyboard) then this option can be
> > enabled to ensure this is handled correctly.
> >
> > config SPL_SYS_STDIO_DEREGISTER
> > bool "Allow deregistering stdio devices in SPL"
> > depends on SPL_DM_DEVICE_REMOVE
> > help
> > Generally there is no need to deregister stdio devices since they
> > are never deactivated. But if a stdio device is used which can be
> > removed (for example a USB keyboard) then this option can be
> > enabled to ensure this is handled correctly. This is very rarely
> > needed in SPL.
> >
> > This is a pain. Apart from the duplication, sometimes the SPL version is in
> > a
> > different file or a different part of the file, making it hard to find
> > related
> > options or update them in sync.
> >
> > Instead, we can add a 'phase' command to the Kconfig language, so we can do:
> >
> > config SYS_STDIO_DEREGISTER
> > bool "Allow deregistering stdio devices"
> > phases
> > depends on p.DM_DEVICE_REMOVE
> > phase MAIN default y if USB_KEYBOARD
> > help
> > Generally there is no need to deregister stdio devices since they
> > are never deactivated. But if a stdio device is used which can be
> > removed (for example a USB keyboard) then this option can be
> > enabled to ensure this is handled correctly.
> >
> > 'phases' means this Kconfig option exists in all phases. You can also say
> > 'phases MAIN SPL' to select just MAIN (U-Boot) and SPL.
> >
> > 'p.DM_DEVICE_REMOVE' means to prefix the phase with each symbol, so for
> > U-Boot
> > (which uses SYS_STDIO_DEREGISTER) this means DM_DEVICE_REMOVE (p is empty)
> > and
> > for SPL (which uses SPL_SYS_STDIO_DEREGISTER) it means SPL_DM_DEVICE_REMOVE
> > (p is SPL_). This is somewhat similar in style to the special-case
> > 'depends on m' in Kconfig.
> >
> > To make this work, we tell Kconfig that SPL is a phase with 'def_phase':
> >
> > config SPL
> > def_phase
> > depends on SUPPORT_SPL
> > prompt "Enable SPL"
> > help
> > If you want to build SPL as well as the normal image, say Y.
> >
> > It works just the same as a bool, but kconfig also uses it to automatically
> > add
> > new Kconfigs for each phase. In the above example it creates both
> > SYS_STDIO_DEREGISTER and SPL_SYS_STDIO_DEREGISTER. The option name has the
> > text
> > '(SPL) ' shown before the SPL option.
> >
> > This can easily handle Kconfigs with similar dependencies and even different
> > ones. If the Kconfig options are not actually very similar we can still
> > create two separate copies instead, as now.
> >
> > This allows us to substantially reduce the size and duplication in the
> > Kconfig
> > defintions. It also reduces the pain of adding another phase to U-Boot.
> >
> > Note: This change needs to be done in Linux, which owns Kconfig upstream.
> >
> >
> > 2.Rename SPL_TPL_
> >
> > This Makefile variable is used to reduce the number of duplicate rules in
> > makefiles:
> >
> > obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
> >
> > The SPL_TPL_ expands to empty for U-Boot and
[PATCH] crypto/fsl: fix missed dma_addr_t -> caam_dma_addr_t conversion
One of the "dma_addr_t" instances was left out when
converting to "caam_dma_addr_t".
Fixes: 2ff17d2f74c5 ("crypto: fsl: refactor for 32 bit version CAAM support on
ARM64")
Signed-off-by: Horia Geantă
---
drivers/crypto/fsl/jobdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index d23541553181..c350b3285616 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -300,7 +300,7 @@ void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc,
int handle)
void inline_cnstr_jobdesc_rng(u32 *desc, void *data_out, u32 size)
{
- dma_addr_t dma_data_out = virt_to_phys(data_out);
+ caam_dma_addr_t dma_data_out = virt_to_phys(data_out);
init_job_desc(desc, 0);
append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
--
2.17.1
[PATCH] cmd: pwm: Remove additional pwm description
The first name is taken from command name that's why shouldn't be listed in help. And commands shouldn't be listed with <> which means value but value itself is command name. Also add description for commands to make it clear what it does. Before pwm pwm pwm ... After: pwm invert- invert polarity pwm config - config PWM pwm enable - enable PWM output pwm disable - disable PWM output Signed-off-by: Michal Simek --- cmd/pwm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/cmd/pwm.c b/cmd/pwm.c index 87d840a2b9bd..7947e61aeedb 100644 --- a/cmd/pwm.c +++ b/cmd/pwm.c @@ -108,7 +108,8 @@ static int do_pwm(struct cmd_tbl *cmdtp, int flag, int argc, U_BOOT_CMD(pwm, 6, 0, do_pwm, "control pwm channels", - "pwm\n" - "pwm \n" - "pwm \n" + "invert- invert polarity\n" + "pwm config - config PWM\n" + "pwm enable - enable PWM output\n" + "pwm disable - eisable PWM output\n" "Note: All input values are in decimal"); -- 2.32.0
[PATCH 4/4] xilinx: Enable config to display cpuinfo
From: T Karthik Reddy Enable CONFIG_DISPLAY_CPUINFO to display SoC family & revision. Signed-off-by: T Karthik Reddy Reviewed-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- configs/xilinx_versal_virt_defconfig | 1 - configs/xilinx_zynqmp_virt_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 15fa5b9900c9..590a2171c114 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -16,7 +16,6 @@ CONFIG_FIT_VERBOSE=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_BOOTDELAY=5 CONFIG_USE_PREBOOT=y -# CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y CONFIG_SYS_PROMPT="Versal> " CONFIG_CMD_BOOTMENU=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 5b2f2f69e461..2d3402857f48 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -24,7 +24,6 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="scsi reset;usb reset" -# CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_SPL_FPGA=y -- 2.32.0
[PATCH 3/4] xilinx: common: Add function to print SoC info
From: T Karthik Reddy
Add print_cpuinfo() to print SoC info like family & revision.
This function depends on CONFIG_DISPLAY_CPUINFO config.
Signed-off-by: T Karthik Reddy
Reviewed-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 92b61d83ca47..90c87bab5cff 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "fru.h"
@@ -440,3 +441,28 @@ int __maybe_unused board_fit_config_name_match(const char
*name)
return -1;
}
+
+#if defined(CONFIG_DISPLAY_CPUINFO) && !defined(CONFIG_ARCH_ZYNQ)
+int print_cpuinfo(void)
+{
+ struct udevice *soc;
+ char name[SOC_MAX_STR_SIZE];
+ int ret;
+
+ ret = soc_get();
+ if (ret) {
+ printf("CPU: UNKNOWN\n");
+ return 0;
+ }
+
+ ret = soc_get_family(soc, name, SOC_MAX_STR_SIZE);
+ if (ret)
+ printf("CPU: %s\n", name);
+
+ ret = soc_get_revision(soc, name, SOC_MAX_STR_SIZE);
+ if (ret)
+ printf("Silicon: %s\n", name);
+
+ return 0;
+}
+#endif
--
2.32.0
[PATCH 1/4] soc: xilinx: zynqmp: Add soc_xilinx_zynqmp driver
From: T Karthik Reddy
soc_xilinx_zynqmp driver allows identification of family & revision
of zynqmp SoC. This driver is selected by CONFIG_SOC_XILINX_ZYNQMP.
Add this config to xilinx_zynqmp_virt_defconfig file.
Probe this driver using platdata U_BOOT_DEVICE structure which is
specified in mach-zynqmp/cpu.c.
Signed-off-by: T Karthik Reddy
Reviewed-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 1 +
arch/arm/mach-zynqmp/cpu.c | 5 ++
arch/arm/mach-zynqmp/include/mach/hardware.h | 3 +
configs/xilinx_zynqmp_virt_defconfig | 1 +
drivers/soc/Kconfig | 8 ++
drivers/soc/Makefile | 1 +
drivers/soc/soc_xilinx_zynqmp.c | 78
8 files changed, 98 insertions(+)
create mode 100644 drivers/soc/soc_xilinx_zynqmp.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 868d4e145ca2..af5a1fedf1d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -602,6 +602,7 @@ F: drivers/net/zynq_gem.c
F: drivers/serial/serial_zynq.c
F: drivers/reset/reset-zynqmp.c
F: drivers/rtc/zynqmp_rtc.c
+F: drivers/soc/soc_xilinx_zynqmp.c
F: drivers/spi/zynq_qspi.c
F: drivers/spi/zynq_spi.c
F: drivers/timer/cadence-ttc.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3a745ce126aa..3e8a31f8ad56 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1133,6 +1133,7 @@ config ARCH_ZYNQMP
select SPL_SEPARATE_BSS if SPL
select SUPPORT_SPL
select ZYNQMP_IPI
+ select SOC_DEVICE
imply BOARD_LATE_INIT
imply CMD_DM
imply ENV_VARS_UBOOT_RUNTIME_CONFIG
diff --git a/arch/arm/mach-zynqmp/cpu.c b/arch/arm/mach-zynqmp/cpu.c
index 29743cae5aab..26e285c24fe0 100644
--- a/arch/arm/mach-zynqmp/cpu.c
+++ b/arch/arm/mach-zynqmp/cpu.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#define ZYNQ_SILICON_VER_MASK 0xF000
#define ZYNQ_SILICON_VER_SHIFT 12
@@ -218,3 +219,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value)
return ret;
}
+
+U_BOOT_DRVINFO(soc_xilinx_zynqmp) = {
+ .name = "soc_xilinx_zynqmp",
+};
diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
b/arch/arm/mach-zynqmp/include/mach/hardware.h
index 37764990707c..eebf38551c2f 100644
--- a/arch/arm/mach-zynqmp/include/mach/hardware.h
+++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
@@ -69,6 +69,9 @@ struct iou_scntr_secure {
#define iou_scntr_secure ((struct iou_scntr_secure *)ZYNQMP_IOU_SCNTR_SECURE)
+#define ZYNQMP_PS_VERSION 0xFFCA0044
+#define ZYNQMP_PS_VER_MASK GENMASK(1, 0)
+
/* Bootmode setting values */
#define BOOT_MODES_MASK0x000F
#define QSPI_MODE_24BIT0x0001
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index 2c888130fa59..5b2f2f69e461 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -160,6 +160,7 @@ CONFIG_DM_SCSI=y
CONFIG_ARM_DCC=y
CONFIG_XILINX_UARTLITE=y
CONFIG_ZYNQ_SERIAL=y
+CONFIG_SOC_XILINX_ZYNQMP=y
CONFIG_SPI=y
CONFIG_ZYNQ_SPI=y
CONFIG_ZYNQMP_GQSPI=y
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 864d00a88538..17fb4c4d65e5 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -16,6 +16,14 @@ config SOC_DEVICE_TI_K3
This allows Texas Instruments Keystone 3 SoCs to identify
specifics about the SoC in use.
+config SOC_XILINX_ZYNQMP
+ bool "Enable SoC Device ID driver for Xilinx ZynqMP"
+ depends on SOC_DEVICE && ARCH_ZYNQMP
+ help
+ Enable this option to select SoC device id driver for Xilinx ZynqMP.
+ This allows other drivers to verify the SoC familiy & revision
+ using matching SoC attributes.
+
source "drivers/soc/ti/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 9ef20ca5066f..9b26573c71c8 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o
obj-$(CONFIG_SANDBOX) += soc_sandbox.o
+obj-$(CONFIG_SOC_XILINX_ZYNQMP) += soc_xilinx_zynqmp.o
diff --git a/drivers/soc/soc_xilinx_zynqmp.c b/drivers/soc/soc_xilinx_zynqmp.c
new file mode 100644
index ..7d33ce2163d8
--- /dev/null
+++ b/drivers/soc/soc_xilinx_zynqmp.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx ZynqMP SOC driver
+ *
+ * Copyright (C) 2021 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Zynqmp has 4 silicon revisions
+ * v0 -> 0(XCZU9EG-ES1)
+ * v1 -> 1(XCZU3EG-ES1, XCZU15EG-ES1)
+ * v2 -> 2(XCZU7EV-ES1, XCZU9EG-ES2, XCZU19EG-ES1)
+ * v3 -> 3(Production Level)
+ */
+static const char zynqmp_family[] = "ZynqMP";
+
+struct soc_xilinx_zynqmp_priv {
+ const char *family;
+ char
[PATCH 2/4] soc: xilinx: versal: Add soc_xilinx_versal driver
From: T Karthik Reddy
soc_xilinx_versal driver allows identification of family & revision
of versal SoC. This driver is selected by CONFIG_SOC_XILINX_VERSAL.
Probe this driver using platdata U_BOOT_DEVICE structure which is
defined at mach-versal/cpu.c.
Add this config to xilinx_versal_virt_defconfig &
xilinx_versal_mini_ospi_defconfig file to select this driver.
Signed-off-by: T Karthik Reddy
Reviewed-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
MAINTAINERS | 1 +
arch/arm/Kconfig | 1 +
arch/arm/mach-versal/cpu.c | 5 ++
arch/arm/mach-versal/include/mach/hardware.h | 4 ++
configs/xilinx_versal_virt_defconfig | 1 +
drivers/soc/Kconfig | 8 +++
drivers/soc/Makefile | 1 +
drivers/soc/soc_xilinx_versal.c | 76
8 files changed, 97 insertions(+)
create mode 100644 drivers/soc/soc_xilinx_versal.c
diff --git a/MAINTAINERS b/MAINTAINERS
index af5a1fedf1d3..4cf0c33c5d58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -546,6 +546,7 @@ S: Maintained
T: git https://source.denx.de/u-boot/custodians/u-boot-microblaze.git
F: arch/arm/mach-versal/
F: drivers/net/xilinx_axi_mrmac.*
+F: drivers/soc/soc_xilinx_versal.c
F: drivers/watchdog/xilinx_wwdt.c
N: (?
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -120,3 +121,7 @@ int arm_reserve_mmu(void)
return 0;
}
#endif
+
+U_BOOT_DRVINFO(soc_xilinx_versal) = {
+ .name = "soc_xilinx_versal",
+};
diff --git a/arch/arm/mach-versal/include/mach/hardware.h
b/arch/arm/mach-versal/include/mach/hardware.h
index 9af5afd3f3f4..7b728ac11018 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -65,6 +65,10 @@ struct crp_regs {
#define crp_base ((struct crp_regs *)VERSAL_CRP_BASEADDR)
+#define VERSAL_PS_PMC_VERSION 0xF11A0004
+#define VERSAL_PS_VER_MASK GENMASK(7, 0)
+#define VERSAL_PS_VER_SHIFT12
+
/* Bootmode setting values */
#define BOOT_MODES_MASK0x000F
#define QSPI_MODE_24BIT0x0001
diff --git a/configs/xilinx_versal_virt_defconfig
b/configs/xilinx_versal_virt_defconfig
index c894d32a9259..15fa5b9900c9 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -96,6 +96,7 @@ CONFIG_ZYNQ_GEM=y
CONFIG_ARM_DCC=y
CONFIG_PL01X_SERIAL=y
CONFIG_XILINX_UARTLITE=y
+CONFIG_SOC_XILINX_VERSAL=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_ZYNQ_SPI=y
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 17fb4c4d65e5..292dc41b6fa2 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -24,6 +24,14 @@ config SOC_XILINX_ZYNQMP
This allows other drivers to verify the SoC familiy & revision
using matching SoC attributes.
+config SOC_XILINX_VERSAL
+ bool "Enable SoC Device ID driver for Xilinx Versal"
+ depends on SOC_DEVICE && ARCH_VERSAL
+ help
+ Enable this option to select SoC device id driver for Xilinx Versal.
+ This allows other drivers to verify the SoC familiy & revision using
+ matching SoC attributes.
+
source "drivers/soc/ti/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 9b26573c71c8..031fa7612f48 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o
obj-$(CONFIG_SANDBOX) += soc_sandbox.o
obj-$(CONFIG_SOC_XILINX_ZYNQMP) += soc_xilinx_zynqmp.o
+obj-$(CONFIG_SOC_XILINX_VERSAL) += soc_xilinx_versal.o
diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
new file mode 100644
index ..f8bcd9ab404d
--- /dev/null
+++ b/drivers/soc/soc_xilinx_versal.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Versal SOC driver
+ *
+ * Copyright (C) 2021 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * v1 -> 0x10 - ES1
+ * v2 -> 0x20 - Production
+ */
+static const char versal_family[] = "Versal";
+
+struct soc_xilinx_versal_priv {
+ const char *family;
+ char revision;
+};
+
+static int soc_xilinx_versal_get_family(struct udevice *dev, char *buf, int
size)
+{
+ struct soc_xilinx_versal_priv *priv = dev_get_priv(dev);
+
+ return snprintf(buf, size, "%s", priv->family);
+}
+
+static int soc_xilinx_versal_get_revision(struct udevice *dev, char *buf, int
size)
+{
+ struct soc_xilinx_versal_priv *priv = dev_get_priv(dev);
+
+ return snprintf(buf, size, "v%d", priv->revision);
+}
+
+static const struct soc_ops soc_xilinx_versal_ops = {
+ .get_family = soc_xilinx_versal_get_family,
+ .get_revision = soc_xilinx_versal_get_revision,
+};
+
+static int soc_xilinx_versal_probe(struct udevice *dev)
+{
+ struct soc_xilinx_versal_priv *priv =
[PATCH 0/4] xilinx: Add SoC Xilinx driver for zynqmp & versal
Hi, This patch series adds support for SoC Xilinx driver to get SoC family and revision. Print SoC info using print_cpuinfo() at booting stage. Thanks, Michal T Karthik Reddy (4): soc: xilinx: zynqmp: Add soc_xilinx_zynqmp driver soc: xilinx: versal: Add soc_xilinx_versal driver xilinx: common: Add function to print SoC info xilinx: Enable config to display cpuinfo MAINTAINERS | 2 + arch/arm/Kconfig | 2 + arch/arm/mach-versal/cpu.c | 5 ++ arch/arm/mach-versal/include/mach/hardware.h | 4 + arch/arm/mach-zynqmp/cpu.c | 5 ++ arch/arm/mach-zynqmp/include/mach/hardware.h | 3 + board/xilinx/common/board.c | 26 +++ configs/xilinx_versal_virt_defconfig | 2 +- configs/xilinx_zynqmp_virt_defconfig | 2 +- drivers/soc/Kconfig | 16 drivers/soc/Makefile | 2 + drivers/soc/soc_xilinx_versal.c | 76 +++ drivers/soc/soc_xilinx_zynqmp.c | 78 13 files changed, 221 insertions(+), 2 deletions(-) create mode 100644 drivers/soc/soc_xilinx_versal.c create mode 100644 drivers/soc/soc_xilinx_zynqmp.c -- 2.32.0
Re: [PATCH] am33xx: Fix USB for am335x boards
On Tue, Aug 10, 2021 at 12:04:23PM +0200, Harald Seiler wrote:
> Hi,
>
> On Sat, 2021-08-07 at 14:17 +0300, Matwey V. Kornilov wrote:
> > USB nodes were mistakenly disabled in
> >
> > commit 942853dd96df ("arm: dts: Resync BeagleBone device trees")
>
> To be precise, the problem is that only half of the device tree files
> were synced. am33xx.dtsi (and seemingly some more) were skipped,
> leading to the symptoms you found. I think it is likely that the
> upstream changes in am33xx.dtsi which we are missing right now will lead
> to more regressions of similar nature.
>
> So I'd say we should dig deeper into the problems you encountered while
> attempting to just sync the entirety of am33xx.dtsi. The end goal is
> that all device-tree files not ending in `-uboot` match what is in
> Linux, so it is inevitable that someone needs to look into this anyway.
Yes, there is a general need to re-sync all of the TI dts files with
upstream. It's unclear to me right now if a full resync on the am33xx
line will produce the same set of total failure that resyncing the rest
of the omap5/j6/am57xx and later families have.
--
Tom
signature.asc
Description: PGP signature
[PATCH 1/1] rtc: ds1307: Fix incorrect clock reset for DS13xx
The ds1307 driver also supports the DS1339 and DS1340.
However, in ds1307_rtc_reset the register writes assume that the chip
is a DS1307. This is evident in the writing of bits SQWE, RS1, RS0 to
the control register. While this applies correctly to the DS1307, on a
DS1340 the control register doesn't contain those bits (instead, the
register is used for clock calibration). By writing these bits the
clock calibration will be changed and the chip can become
non-functional after a reset call.
Signed-off-by: Callum Sinclair
---
drivers/rtc/ds1307.c | 69 +++-
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/ds1307.c b/drivers/rtc/ds1307.c
index 2015ce9bbc..3be97c9d93 100644
--- a/drivers/rtc/ds1307.c
+++ b/drivers/rtc/ds1307.c
@@ -43,11 +43,21 @@ enum ds_type {
#define RTC_SEC_BIT_CH 0x80/* Clock Halt (in Register 0) */
+/* DS1307-specific bits */
#define RTC_CTL_BIT_RS00x01/* Rate select 0
*/
#define RTC_CTL_BIT_RS10x02/* Rate select 1
*/
#define RTC_CTL_BIT_SQWE 0x10/* Square Wave Enable */
#define RTC_CTL_BIT_OUT0x80/* Output Control
*/
+/* DS1337-specific bits */
+#define DS1337_CTL_BIT_RS1 0x08/* Rate select 1*/
+#define DS1337_CTL_BIT_RS2 0x10/* Rate select 2*/
+#define DS1337_CTL_BIT_EOSC0x80/* Enable Oscillator*/
+
+/* DS1340-specific bits */
+#define DS1340_SEC_BIT_EOSC0x80/* Enable Oscillator*/
+#define DS1340_CTL_BIT_OUT 0x80/* Output Control */
+
/* MCP7941X-specific bits */
#define MCP7941X_BIT_ST0x80
#define MCP7941X_BIT_VBATEN0x08
@@ -261,9 +271,25 @@ read_rtc:
buf[RTC_SEC_REG_ADDR]);
return -1;
}
- }
-
- if (type == m41t11) {
+ } else if (type == ds_1337) {
+ if (buf[RTC_CTL_REG_ADDR] & DS1337_CTL_BIT_EOSC) {
+ printf("### Warning: RTC oscillator has stopped\n");
+ /* clear the not oscillator enable (~EOSC) flag */
+ buf[RTC_CTL_REG_ADDR] &= ~DS1337_CTL_BIT_EOSC;
+ dm_i2c_reg_write(dev, RTC_CTL_REG_ADDR,
+buf[RTC_CTL_REG_ADDR]);
+ return -1;
+ }
+ } else if (type == ds_1340) {
+ if (buf[RTC_SEC_REG_ADDR] & DS1340_SEC_BIT_EOSC) {
+ printf("### Warning: RTC oscillator has stopped\n");
+ /* clear the not oscillator enable (~EOSC) flag */
+ buf[RTC_SEC_REG_ADDR] &= ~DS1340_SEC_BIT_EOSC;
+ dm_i2c_reg_write(dev, RTC_SEC_REG_ADDR,
+buf[RTC_SEC_REG_ADDR]);
+ return -1;
+ }
+ } else if (type == m41t11) {
/* clock halted? turn it on, so clock can tick. */
if (buf[RTC_SEC_REG_ADDR] & RTC_SEC_BIT_CH) {
buf[RTC_SEC_REG_ADDR] &= ~RTC_SEC_BIT_CH;
@@ -273,9 +299,7 @@ read_rtc:
buf[RTC_SEC_REG_ADDR]);
goto read_rtc;
}
- }
-
- if (type == mcp794xx) {
+ } else if (type == mcp794xx) {
/* make sure that the backup battery is enabled */
if (!(buf[RTC_DAY_REG_ADDR] & MCP7941X_BIT_VBATEN)) {
dm_i2c_reg_write(dev, RTC_DAY_REG_ADDR,
@@ -314,18 +338,37 @@ read_rtc:
static int ds1307_rtc_reset(struct udevice *dev)
{
int ret;
+ enum ds_type type = dev_get_driver_data(dev);
- /* clear Clock Halt */
+ /*
+* reset clock/oscillator in the seconds register:
+* on DS1307 bit 7 enables Clock Halt (CH),
+* on DS1340 bit 7 disables the oscillator (not EOSC)
+* on MCP794xx bit 7 enables Start Oscillator (ST)
+*/
ret = dm_i2c_reg_write(dev, RTC_SEC_REG_ADDR, 0x00);
if (ret < 0)
return ret;
- ret = dm_i2c_reg_write(dev, RTC_CTL_REG_ADDR,
- RTC_CTL_BIT_SQWE | RTC_CTL_BIT_RS1 |
- RTC_CTL_BIT_RS0);
- if (ret < 0)
- return ret;
- return 0;
+ if (type == ds_1307) {
+ /* Write control register in order to enable square-wave
+* output (SQWE) and set a default rate of 32.768kHz (RS1|RS0).
+*/
+ ret = dm_i2c_reg_write(dev, RTC_CTL_REG_ADDR,
+ RTC_CTL_BIT_SQWE | RTC_CTL_BIT_RS1 |
+ RTC_CTL_BIT_RS0);
+ } else if (type == ds_1337) {
+ /* Write control register in order to enable
[PATCH 0/1] rtc: ds1307: Fix incorrect clock reset for DS13xx
The DS1307 driver also supports the DS1337, DS1339 and DS1340 rtc. However the reset registers between these rtc devices are not the same. This means calling the rtc reset routine for a DS1307 clock on a DS1340 device will cause the clock to be calibrated incorrectly rather than correctly reset. Define different reset routines for the different clock variants to prevent a rtc reset causing the clock to become incorrectly calibrated rather than reset. Callum Sinclair (1): rtc: ds1307: Fix incorrect clock reset for DS13xx drivers/rtc/ds1307.c | 69 +++- 1 file changed, 56 insertions(+), 13 deletions(-) -- 2.32.0
Re: [PATCH] xilinx: Disable ARCH_FIXUP_FDT_MEMORY
On 8/9/21 6:31 PM, Tom Rini wrote:
> On Mon, Aug 09, 2021 at 08:24:48AM +0200, Michal Simek wrote:
>>
>>
>> On 8/6/21 8:46 PM, Tom Rini wrote:
>>> On Fri, Aug 06, 2021 at 02:22:56PM +0200, Michal Simek wrote:
>>>
Based on DT spec you can have one memory node which multiple ranges or
multiple nodes.
fdt_fixup_memory_banks() is not implemented in a correct way when multiple
memory nodes are present because all ranges are put it to the first memory
node found. And next memory nodes are kept in DT which ends up in the same
range specification in the same DT.
Here is what it is happening.
Origin DT.
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
};
memory@8 {
device_type = "memory";
reg = <0x8 0x 0x0 0x8000>;
};
After fdt_fixup_memory_banks()
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
};
memory@8 {
device_type = "memory";
reg = <0x8 0x 0x0 0x8000>;
};
As is visible memory@0 node got second range but there is still
memory@8 node present and 2G range is listed twice.
The solution can't be that second node is removed because it can be
referenced already that's why it is better for us to disable this option
for now.
>>>
>>> I don't object to the patch at all. The main use of
>>> fdt_fixup_memory_banks() is for the (at least used to be most common)
>>> case of device trees that didn't fill in memory size, so that it could
>>> be done at run-time, depending on the amount found. I do wonder if
>>> CONFIG_ARCH_FIXUP_FDT_MEMORY being default makes the most sense these
>>> days. Or maybe we just need some comments on fdt_fixup_memory_banks
>>> making it clear which way we implement the spec as it does allow for as
>>> you note, either way.
>>
>> The multi memory node configuration is not that common and the most of
>> SOC are using one node with multiple ranges. It means I would say a lot
>> of SOCs are not affected.
>
> OK.
>
>> Not sure how many SOCs are really using this feature that at run time
>> you detect amount of memory. I remember freescale powerquicks with
>> reading SPD eeprom on DIMMs and then one custom board with xilinx soc
>> which was produced with two memory sizes where detection was performed.
>
> I think there's still a large number of platforms that don't describe
> the amount of memory in the device tree and let it be figured out at
> "run time", even if there's not nearly the level of SPD EEPROM related
> smarts as there are in some environments. U-Boot's get_ram_size() is
> usually good enough for those cases. But it's been a long time since I
> checked a wide variety of dts files, and that it gets the more than 4GB
> case wrong too is why there are a number of platforms that opt-out.
>
>> But anyway if you want me to add comment to that function to describe
>> what it is implemented now I can do it.
>> And of course the best would be to update this function handle both ways
>> but for us is it better to disable this for now till we have real need
>> to use it.
>> We have also done internally one implementation but I don't think it
>> works in generic way.
>
> A comment for now would be a great start, thanks!
>
Just for a record. Here it is send.
https://lists.denx.de/pipermail/u-boot/2021-August/457629.html
Thanks,
Michal
Re: [PATCH v2 1/3] arm64: arch/arm/lib: Add optimized memset/memcpy functions
On 10.08.21 13:30, Rasmus Villemoes wrote: On 10/08/2021 09.13, Stefan Roese wrote: +/* This implementation handles overlaps and supports both memcpy and memmove + from a single entry point. It uses unaligned accesses and branchless Any reason not to take advantage of that, i.e. provide memmove as an alias for memcpy and thus get a fast(er) memmove for free? It would even reduce .text a little by not needing to include the lib/ provided memmove implementation. Makes absolute sense, thanks. I'll change v3 accordingly. Thanks, Stefan
Re: [PATCH v2 1/3] arm64: arch/arm/lib: Add optimized memset/memcpy functions
On 10/08/2021 09.13, Stefan Roese wrote: > +/* This implementation handles overlaps and supports both memcpy and memmove > + from a single entry point. It uses unaligned accesses and branchless Any reason not to take advantage of that, i.e. provide memmove as an alias for memcpy and thus get a fast(er) memmove for free? It would even reduce .text a little by not needing to include the lib/ provided memmove implementation. Rasmus
[PATCH] configs: fsl: migrate FMAN/QE specific defines to Kconfig
Use moveconfig.py script to convert CONFIG_SYS_FMAN_FW_ADDR, CONFIG_SYS_QE_FW_ADDR and CONFIG_SYS_QE_FMAN_FW_LENGTH to Kconfig and move these entries to defconfigs. Signed-off-by: Rajesh Bhagat --- configs/P2041RDB_NAND_defconfig | 1 + configs/P2041RDB_SDCARD_defconfig | 1 + configs/P2041RDB_SPIFLASH_defconfig | 1 + configs/P2041RDB_defconfig| 1 + configs/P3041DS_NAND_defconfig| 1 + configs/P3041DS_SDCARD_defconfig | 1 + configs/P3041DS_SPIFLASH_defconfig| 1 + configs/P3041DS_defconfig | 1 + configs/P4080DS_SDCARD_defconfig | 1 + configs/P4080DS_SPIFLASH_defconfig| 1 + configs/P4080DS_defconfig | 1 + configs/P5040DS_NAND_defconfig| 1 + configs/P5040DS_SDCARD_defconfig | 1 + configs/P5040DS_SPIFLASH_defconfig| 1 + configs/P5040DS_defconfig | 1 + configs/T1024RDB_NAND_defconfig | 2 + configs/T1024RDB_SDCARD_defconfig | 2 + configs/T1024RDB_SPIFLASH_defconfig | 2 + configs/T1024RDB_defconfig| 2 + configs/T1042D4RDB_NAND_defconfig | 2 + configs/T1042D4RDB_SDCARD_defconfig | 2 + configs/T1042D4RDB_SPIFLASH_defconfig | 2 + configs/T1042D4RDB_defconfig | 2 + configs/T2080QDS_NAND_defconfig | 1 + configs/T2080QDS_SDCARD_defconfig | 1 + configs/T2080QDS_SECURE_BOOT_defconfig| 1 + configs/T2080QDS_SPIFLASH_defconfig | 1 + configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 1 + configs/T2080QDS_defconfig| 1 + configs/T2080RDB_NAND_defconfig | 1 + configs/T2080RDB_SDCARD_defconfig | 1 + configs/T2080RDB_SPIFLASH_defconfig | 1 + configs/T2080RDB_defconfig| 1 + configs/T2080RDB_revD_NAND_defconfig | 1 + configs/T2080RDB_revD_SDCARD_defconfig| 1 + configs/T2080RDB_revD_SPIFLASH_defconfig | 1 + configs/T2080RDB_revD_defconfig | 1 + configs/T4240RDB_SDCARD_defconfig | 1 + configs/T4240RDB_defconfig| 1 + configs/kmcent2_defconfig | 2 + configs/kmtegr1_defconfig | 1 + configs/ls1021aiot_qspi_defconfig | 1 + configs/ls1021aiot_sdcard_defconfig | 1 + configs/ls1021aqds_ddr4_nor_defconfig | 1 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + configs/ls1021aqds_nand_defconfig | 1 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021aqds_nor_defconfig | 1 + configs/ls1021aqds_nor_lpuart_defconfig | 1 + configs/ls1021aqds_qspi_defconfig | 1 + configs/ls1021aqds_sdcard_ifc_defconfig | 1 + configs/ls1021aqds_sdcard_qspi_defconfig | 1 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_nor_defconfig | 1 + configs/ls1021atwr_nor_lpuart_defconfig | 1 + configs/ls1021atwr_qspi_defconfig | 1 + ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_sdcard_ifc_defconfig | 1 + configs/ls1021atwr_sdcard_qspi_defconfig | 1 + configs/ls1043aqds_defconfig | 2 + configs/ls1043aqds_lpuart_defconfig | 2 + configs/ls1043aqds_nand_defconfig | 1 + configs/ls1043aqds_nor_ddr3_defconfig | 2 + configs/ls1043aqds_qspi_defconfig | 1 + configs/ls1043aqds_sdcard_ifc_defconfig | 2 + configs/ls1043aqds_sdcard_qspi_defconfig | 2 + configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 2 + configs/ls1043aqds_tfa_defconfig | 2 + configs/ls1043ardb_SECURE_BOOT_defconfig | 2 + configs/ls1043ardb_defconfig | 2 + configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 1 + configs/ls1043ardb_nand_defconfig | 1 + .../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 2 + configs/ls1043ardb_sdcard_defconfig | 2 + configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 2 + configs/ls1043ardb_tfa_defconfig | 2 + configs/ls1046aqds_SECURE_BOOT_defconfig | 1 + configs/ls1046aqds_defconfig | 1 + configs/ls1046aqds_lpuart_defconfig | 1 + configs/ls1046aqds_nand_defconfig | 1 + configs/ls1046aqds_qspi_defconfig | 1 + configs/ls1046aqds_sdcard_ifc_defconfig | 1 + configs/ls1046aqds_sdcard_qspi_defconfig | 1 + configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1046aqds_tfa_defconfig | 1 + configs/ls1046ardb_emmc_defconfig | 1 + configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1046ardb_qspi_defconfig | 1 + configs/ls1046ardb_qspi_spl_defconfig
Re: [PATCH] am33xx: Fix USB for am335x boards
Hi,
On Sat, 2021-08-07 at 14:17 +0300, Matwey V. Kornilov wrote:
> USB nodes were mistakenly disabled in
>
> commit 942853dd96df ("arm: dts: Resync BeagleBone device trees")
To be precise, the problem is that only half of the device tree files
were synced. am33xx.dtsi (and seemingly some more) were skipped,
leading to the symptoms you found. I think it is likely that the
upstream changes in am33xx.dtsi which we are missing right now will lead
to more regressions of similar nature.
So I'd say we should dig deeper into the problems you encountered while
attempting to just sync the entirety of am33xx.dtsi. The end goal is
that all device-tree files not ending in `-uboot` match what is in
Linux, so it is inevitable that someone needs to look into this anyway.
--
Harald
> This commit is to fix the following issue:
>
> starting USB...
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> starting USB...
> No working controllers found
>
> Reference:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0782e8572ce43f521ed6ff15e4a7ab9aa5acdc85
> Fixes: 942853dd96df ("arm: dts: Resync BeagleBone device trees")
> Signed-off-by: Matwey V. Kornilov
> ---
> arch/arm/dts/am33xx.dtsi | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
> index ce07cec846..b5093020ee 100644
> --- a/arch/arm/dts/am33xx.dtsi
> +++ b/arch/arm/dts/am33xx.dtsi
> @@ -380,28 +380,24 @@
> #address-cells = <1>;
> #size-cells = <1>;
> ti,hwmods = "usb_otg_hs";
> - status = "disabled";
>
> usb_ctrl_mod: control@44e10620 {
> compatible = "ti,am335x-usb-ctrl-module";
> reg = <0x44e10620 0x10
> 0x44e10648 0x4>;
> reg-names = "phy_ctrl", "wakeup";
> - status = "disabled";
> };
>
> usb0_phy: usb-phy@47401300 {
> compatible = "ti,am335x-usb-phy";
> reg = <0x47401300 0x100>;
> reg-names = "phy";
> - status = "disabled";
> ti,ctrl_mod = <_ctrl_mod>;
> #phy-cells = <0>;
> };
>
> usb0: usb@47401000 {
> compatible = "ti,musb-am33xx";
> - status = "disabled";
> reg = <0x47401400 0x400
> 0x47401000 0x200>;
> reg-names = "mc", "control";
> @@ -443,14 +439,12 @@
> compatible = "ti,am335x-usb-phy";
> reg = <0x47401b00 0x100>;
> reg-names = "phy";
> - status = "disabled";
> ti,ctrl_mod = <_ctrl_mod>;
> #phy-cells = <0>;
> };
>
> usb1: usb@47401800 {
> compatible = "ti,musb-am33xx";
> - status = "disabled";
> reg = <0x47401c00 0x400
> 0x47401800 0x200>;
> reg-names = "mc", "control";
--
Harald
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 2/3] arm64: memset-arm64: Use simple memset when cache is disabled
On 10.08.21 11:27, Rasmus Villemoes wrote:
On 10/08/2021 09.13, Stefan Roese wrote:
The optimized memset uses the dc opcode, which causes problems when the
cache is disabled. This patch adds a check if the cache is disabled and
uses a very simple memset implementation in this case. Otherwise the
optimized version is used.
Signed-off-by: Stefan Roese
---
Changes in v2:
- New patch
arch/arm/lib/memset-arm64.S | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S
index 710f6f582cad..a474dcb53c83 100644
--- a/arch/arm/lib/memset-arm64.S
+++ b/arch/arm/lib/memset-arm64.S
@@ -11,6 +11,7 @@
*
*/
+#include
#include "asmdefs.h"
#define dstin x0
@@ -25,6 +26,35 @@ ENTRY (memset)
PTR_ARG (0)
SIZE_ARG (2)
+ /*
+* The optimized memset uses the dc opcode, which causes problems
+* when the cache is disabled. Let's check if the cache is disabled
+* and use a very simple memset implementation in this case. Otherwise
+* jump to the optimized version.
+*/
+ switch_el x6, 3f, 2f, 1f
+3: mrs x6, sctlr_el3
+ b 0f
+2: mrs x6, sctlr_el2
+ b 0f
+1: mrs x6, sctlr_el1
+0:
+ tst x6, #CR_C
+ bne 9f
How costly is this switch_el and access to a control register? For a
"big" memset of several 100s of bytes I'm sure it's a net win
regardless. But smaller memsets are much more common, and no individual
memset would show up in any boot time "profiling", but it is possible
that the extra cost added to those smaller memsets adds up to some
significant penalty.
I can do some further analysis on how costly this additional check is.
Another good test would perhaps be, if you (and any other interested
developers with ARM64 boards) apply this patchset and test booting to
the U-Boot prompt or even better into the OS with and without this
patchset. To check if it has a positive effect.
In my current case, clearing 256MiB of RAM for the NXP MC firmware
memory is roughly 4 times as fast as using the original implementation.
Saving a few 100 milliseconds in boot-time is quite crucial in this
project.
+ /*
+* A very "simple" memset implementation without the use of the
+* dc opcode. Can be run with caches disabled.
+*/
+ mov x3, #0x0
+4: strbw1, [x0, x3]
+ add x3, x3, #0x1
+ cmp x2, x3
+ bne 4b
+ ret
+9:
+
So I can hardly claim to be fluent in aarch64, but AFAICT this does
return the destination pointer as it must (because it leaves x0
untouched throughout). However, it fails (by writing over all of memory)
when the size is 0, since it is essentially a do{}while and not a while{}.
Thanks for catching. I'll add a size = 0 check to the next version.
Thanks,
Stefan
Re: [PATCH v2 2/3] arm64: memset-arm64: Use simple memset when cache is disabled
On 10/08/2021 09.13, Stefan Roese wrote:
> The optimized memset uses the dc opcode, which causes problems when the
> cache is disabled. This patch adds a check if the cache is disabled and
> uses a very simple memset implementation in this case. Otherwise the
> optimized version is used.
>
> Signed-off-by: Stefan Roese
>
> ---
>
> Changes in v2:
> - New patch
>
> arch/arm/lib/memset-arm64.S | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S
> index 710f6f582cad..a474dcb53c83 100644
> --- a/arch/arm/lib/memset-arm64.S
> +++ b/arch/arm/lib/memset-arm64.S
> @@ -11,6 +11,7 @@
> *
> */
>
> +#include
> #include "asmdefs.h"
>
> #define dstinx0
> @@ -25,6 +26,35 @@ ENTRY (memset)
> PTR_ARG (0)
> SIZE_ARG (2)
>
> + /*
> + * The optimized memset uses the dc opcode, which causes problems
> + * when the cache is disabled. Let's check if the cache is disabled
> + * and use a very simple memset implementation in this case. Otherwise
> + * jump to the optimized version.
> + */
> + switch_el x6, 3f, 2f, 1f
> +3: mrs x6, sctlr_el3
> + b 0f
> +2: mrs x6, sctlr_el2
> + b 0f
> +1: mrs x6, sctlr_el1
> +0:
> + tst x6, #CR_C
> + bne 9f
How costly is this switch_el and access to a control register? For a
"big" memset of several 100s of bytes I'm sure it's a net win
regardless. But smaller memsets are much more common, and no individual
memset would show up in any boot time "profiling", but it is possible
that the extra cost added to those smaller memsets adds up to some
significant penalty.
> + /*
> + * A very "simple" memset implementation without the use of the
> + * dc opcode. Can be run with caches disabled.
> + */
> + mov x3, #0x0
> +4: strbw1, [x0, x3]
> + add x3, x3, #0x1
> + cmp x2, x3
> + bne 4b
> + ret
> +9:
> +
So I can hardly claim to be fluent in aarch64, but AFAICT this does
return the destination pointer as it must (because it leaves x0
untouched throughout). However, it fails (by writing over all of memory)
when the size is 0, since it is essentially a do{}while and not a while{}.
Rasmus
Re: [PATCH 0/9] meson64_android: Android boot flow using abootimg
On 05/08/2021 17:17, Mattijs Korpershoek wrote: > The SEI-610 and SEI-510 boards are well supported in the > Android Open Source project via the yukawa [1] platform. > > Their U-Boot version, despite being public [2] is not in mainline. > > Android 10 and higher have significantly reworked the bootloader > requirements: > > * bootloader should pass slot information in case of A/B > * bootloader should perform AVB verification in case it's supported > * bootloader should read and apply dtb overlays from a dtbo partition > > These series add support for all the above. > > [1] https://android.googlesource.com/device/amlogic/yukawa > [2] > https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ > > Guillaume La Roque (2): > configs: meson64_android: boot android via abootimg > configs: sei510/610: android bootflow via abootimg > > Mattijs Korpershoek (7): > configs: meson64: permit redefining SYS_MALLOC_LEN > configs: meson64_android: increase SYS_MALLOC_LEN to 128M for AVB > configs: meson64_android: implement AVB support > configs: meson64_android: implement A/B slot support > configs: meson64_android: define BOOT_CMD macro > configs: sei510/sei610: reformat PARTS_default > configs: sei510/sei610: don't use hard-coded gpt uuids > > configs/sei510_defconfig | 5 ++ > configs/sei610_defconfig | 5 ++ > include/configs/meson64.h | 2 + > include/configs/meson64_android.h | 139 -- > include/configs/sei510.h | 23 +++-- > include/configs/sei610.h | 23 +++-- > 6 files changed, 165 insertions(+), 32 deletions(-) > Applied to u-boot-amlogic Thanks, Neil
Re: [PATCH 0/9] meson64_android: Android boot flow using abootimg
Hi, On 06/08/2021 17:56, Tom Rini wrote: > On Fri, Aug 06, 2021 at 05:36:41PM +0200, Mattijs Korpershoek wrote: >> Hi Neil, Tom, >> >> Neil Armstrong writes: >> >>> On 05/08/2021 19:23, Tom Rini wrote: On Thu, Aug 05, 2021 at 05:17:19PM +0200, Mattijs Korpershoek wrote: > The SEI-610 and SEI-510 boards are well supported in the > Android Open Source project via the yukawa [1] platform. > > Their U-Boot version, despite being public [2] is not in mainline. > > Android 10 and higher have significantly reworked the bootloader > requirements: > > * bootloader should pass slot information in case of A/B > * bootloader should perform AVB verification in case it's supported > * bootloader should read and apply dtb overlays from a dtbo partition > > These series add support for all the above. > > [1] https://android.googlesource.com/device/amlogic/yukawa > [2] > https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ My high level concern with this series is that it takes what I assume is the Android-only boot path, and adds further abstractions to it, it looks like. Can we just say "Here is the Android 10 boot path" (since AVB has been around for a while) and here is the generic distro boot path for non-Android? Reading this over it looks like it becomes "Here is the Android + AVB boot path", "Here is the Androidd non-AVB boot path" and then I assume "Here is the generic distro boot path". >> Not exactly. Android supports multiple combinations: >> - non-AVB + no-A/B (legacy, no security). This is usually used for >> development builds >> - AVB + no-A/B >> - AVB + A/B >> Here, we should be supporting all of the above using compile flags. I'd also like to know if in general we can make some generic environment macros for "Here is Android AVB boot path", so that we don't need to duplicate this between SoCs. At the very high level, something like the generic distro boot framework, but that does Android instead. >> I agree. It would be really nice if we could have a generic "boot android" >> framework >> >> TI has a ti_omap5_common.h which seems to support similar things. >> However, it does not support the "no-A/B" mode. >> In that file, we can also see board specific logic: namely the mapping >> between the $board_name and the dtbo index passed to "abootimg". >> >> Google has another approach via the boot_android[1] command. > > I guess I'm a little disappointed that there was no follow up to the > question about boot_android. I would like to see the Android support > made easier to work with. > We share the same disappointment, the Android boot flow is incredibly hard to implement and test. And completely changes in incompatible ways between new releases. Neil
[PATCH] fdt_support: Add kernel-doc for fdt_fixup_memory_banks()
Add kernel-doc description for fdt_fixup_memory_banks() because it is
implemented in one specific way and this information should be available
for others to decide if their SoC conforms to it.
If you don't want U-Boot to update your memory DT layout please disable
CONFIG_ARCH_FIXUP_FDT_MEMORY.
Signed-off-by: Michal Simek
---
common/fdt_support.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 4341d84bd5ec..8992ac5d3fca 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -420,6 +420,24 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64
*address, u64 *size,
#else
#define MEMORY_BANKS_MAX 4
#endif
+
+/**
+ * fdt_fixup_memory_banks - Update DT memory node
+ * @blob: Pointer to DT blob
+ * @start: Pointer to memory start addresses array
+ * @size: Pointer to memory sizes array
+ * @banks: Number of memory banks
+ *
+ * Return: 0 on success, negative value on failure
+ *
+ * Based on the passed number of banks and arrays, the function is able to
+ * update existing DT memory nodes to match run time detected/changed memory
+ * configuration. Implementation is handling one specific case with only one
+ * memory node where multiple tuples could be added/updated.
+ * The case where multiple memory nodes with a single tuple (base, size) are
+ * used, this function is only updating the first memory node without removing
+ * others.
+ */
int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
{
int err, nodeoffset;
--
2.32.0
[PATCH v2 3/3] arm64: Kconfig: Enable usage of optimized memset/memcpy
This patch enables the use of the optimized memset() & memcpy() versions recently added on ARM64. Signed-off-by: Stefan Roese --- (no changes since v1) arch/arm/Kconfig | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index caa8a71c6cfd..d64a46c87d11 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -457,7 +457,6 @@ config ARM_CORTEX_CPU_IS_UP config USE_ARCH_MEMCPY bool "Use an assembly optimized implementation of memcpy" default y - depends on !ARM64 help Enable the generation of an optimized version of memcpy. Such an implementation may be faster under some conditions @@ -466,7 +465,7 @@ config USE_ARCH_MEMCPY config SPL_USE_ARCH_MEMCPY bool "Use an assembly optimized implementation of memcpy for SPL" default y if USE_ARCH_MEMCPY - depends on !ARM64 && SPL + depends on SPL help Enable the generation of an optimized version of memcpy. Such an implementation may be faster under some conditions @@ -475,7 +474,7 @@ config SPL_USE_ARCH_MEMCPY config TPL_USE_ARCH_MEMCPY bool "Use an assembly optimized implementation of memcpy for TPL" default y if USE_ARCH_MEMCPY - depends on !ARM64 && TPL + depends on TPL help Enable the generation of an optimized version of memcpy. Such an implementation may be faster under some conditions @@ -484,7 +483,6 @@ config TPL_USE_ARCH_MEMCPY config USE_ARCH_MEMSET bool "Use an assembly optimized implementation of memset" default y - depends on !ARM64 help Enable the generation of an optimized version of memset. Such an implementation may be faster under some conditions @@ -493,7 +491,7 @@ config USE_ARCH_MEMSET config SPL_USE_ARCH_MEMSET bool "Use an assembly optimized implementation of memset for SPL" default y if USE_ARCH_MEMSET - depends on !ARM64 && SPL + depends on SPL help Enable the generation of an optimized version of memset. Such an implementation may be faster under some conditions @@ -502,7 +500,7 @@ config SPL_USE_ARCH_MEMSET config TPL_USE_ARCH_MEMSET bool "Use an assembly optimized implementation of memset for TPL" default y if USE_ARCH_MEMSET - depends on !ARM64 && TPL + depends on TPL help Enable the generation of an optimized version of memset. Such an implementation may be faster under some conditions -- 2.32.0
[PATCH v2 0/3] arm64: Add optimized memset/memcpy functions
On an NXP LX2160 based platform it has been noticed, that the currently implemented memset/memcpy functions for aarch64 are suboptimal. Especially the memset() for clearing the NXP MC firmware memory is very expensive (time-wise). By using optimized functions, a speedup of ~ factor 6 has been measured. This patchset now adds the optimized functions ported from this repository: https://github.com/ARM-software/optimized-routines As the optimized memset function make use of the dc opcode, which needs the caches to be enabled, an additional check is added and a simple memset version is used in this case. Please note that checkpatch.pl complains about some issue with this imported file: arch/arm/lib/asmdefs.h Since it's imported I did explicitly not make any changes here, to make potential future sync'ing easer. Thanks, Stefan Changes in v2: - Add file names and locations and git commit ID from imported files to the commit message - New patch Stefan Roese (3): arm64: arch/arm/lib: Add optimized memset/memcpy functions arm64: memset-arm64: Use simple memset when cache is disabled arm64: Kconfig: Enable usage of optimized memset/memcpy arch/arm/Kconfig| 10 +- arch/arm/lib/Makefile | 5 + arch/arm/lib/asmdefs.h | 98 +++ arch/arm/lib/memcpy-arm64.S | 241 arch/arm/lib/memset-arm64.S | 146 ++ 5 files changed, 494 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/asmdefs.h create mode 100644 arch/arm/lib/memcpy-arm64.S create mode 100644 arch/arm/lib/memset-arm64.S -- 2.32.0
[PATCH v2 1/3] arm64: arch/arm/lib: Add optimized memset/memcpy functions
Ported from https://github.com/ARM-software/optimized-routines These files are included from this repository, including the latest git commit ID: string/aarch64/memcpy.S: afd6244a1f8d string/aarch64/memset.S: e823e3abf5f8 string/asmdefs.h: e823e3abf5f8 Please note that when adding these optimized functions as default memset memcpy functions in U-Boot, U-Boot fails to boot on the LX2160ARDB. After the initial ATF output, no U-Boot output is shown on the serial console. Some exception is triggered here in the very early boot process as some of the assembler opcodes need the caches to be enabled. Because of this, a follow-up patch will add a check to use a simple non-optimized memset for the "cache disabled" case. Note: I also integrated and tested with the Linux versions of these optimized functions. They are similar to the ones now integrated but these ARM versions are still a small bit faster. Signed-off-by: Stefan Roese --- Changes in v2: - Add file names and locations and git commit ID from imported files to the commit message arch/arm/lib/Makefile | 5 + arch/arm/lib/asmdefs.h | 98 +++ arch/arm/lib/memcpy-arm64.S | 241 arch/arm/lib/memset-arm64.S | 116 + 4 files changed, 460 insertions(+) create mode 100644 arch/arm/lib/asmdefs.h create mode 100644 arch/arm/lib/memcpy-arm64.S create mode 100644 arch/arm/lib/memset-arm64.S diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 7f6633271518..c48e1f622d3c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -39,8 +39,13 @@ obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o endif +ifdef CONFIG_ARM64 +obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset-arm64.o +obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy-arm64.o +else obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o +endif obj-$(CONFIG_SEMIHOSTING) += semihosting.o obj-y += bdinfo.o diff --git a/arch/arm/lib/asmdefs.h b/arch/arm/lib/asmdefs.h new file mode 100644 index ..d307a3a8a25c --- /dev/null +++ b/arch/arm/lib/asmdefs.h @@ -0,0 +1,98 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Macros for asm code. + * + * Copyright (c) 2019, Arm Limited. + */ + +#ifndef _ASMDEFS_H +#define _ASMDEFS_H + +#if defined(__aarch64__) + +/* Branch Target Identitication support. */ +#define BTI_C hint34 +#define BTI_J hint36 +/* Return address signing support (pac-ret). */ +#define PACIASPhint25; .cfi_window_save +#define AUTIASPhint29; .cfi_window_save + +/* GNU_PROPERTY_AARCH64_* macros from elf.h. */ +#define FEATURE_1_AND 0xc000 +#define FEATURE_1_BTI 1 +#define FEATURE_1_PAC 2 + +/* Add a NT_GNU_PROPERTY_TYPE_0 note. */ +#define GNU_PROPERTY(type, value) \ + .section .note.gnu.property, "a";\ + .p2align 3; \ + .word 4; \ + .word 16;\ + .word 5; \ + .asciz "GNU";\ + .word type; \ + .word 4; \ + .word value; \ + .word 0; \ + .text + +/* If set then the GNU Property Note section will be added to + mark objects to support BTI and PAC-RET. */ +#ifndef WANT_GNU_PROPERTY +#define WANT_GNU_PROPERTY 1 +#endif + +#if WANT_GNU_PROPERTY +/* Add property note with supported features to all asm files. */ +GNU_PROPERTY (FEATURE_1_AND, FEATURE_1_BTI|FEATURE_1_PAC) +#endif + +#define ENTRY_ALIGN(name, alignment) \ + .global name;\ + .type name,%function;\ + .align alignment;\ + name:\ + .cfi_startproc; \ + BTI_C; + +#else + +#define END_FILE + +#define ENTRY_ALIGN(name, alignment) \ + .global name;\ + .type name,%function;\ + .align alignment;\ + name:\ + .cfi_startproc; + +#endif + +#define ENTRY(name)ENTRY_ALIGN(name, 6) + +#define ENTRY_ALIAS(name) \ + .global name;\ + .type name,%function;\ + name: + +#define END(name) \ + .cfi_endproc;\ + .size name, .-name; + +#define L(l) .L ## l + +#ifdef __ILP32__ + /* Sanitize padding bits of pointer arguments as per aapcs64 */ +#define PTR_ARG(n) mov w##n, w##n +#else +#define PTR_ARG(n) +#endif + +#ifdef __ILP32__ + /* Sanitize padding bits of size arguments as per aapcs64 */ +#define SIZE_ARG(n) mov w##n, w##n +#else +#define SIZE_ARG(n) +#endif + +#endif diff --git a/arch/arm/lib/memcpy-arm64.S b/arch/arm/lib/memcpy-arm64.S new file mode 100644 index ..08f0d854868a --- /dev/null +++ b/arch/arm/lib/memcpy-arm64.S @@ -0,0 +1,241 @@ +/* SPDX-License-Identifier: MIT */
[PATCH v2 2/3] arm64: memset-arm64: Use simple memset when cache is disabled
The optimized memset uses the dc opcode, which causes problems when the cache is disabled. This patch adds a check if the cache is disabled and uses a very simple memset implementation in this case. Otherwise the optimized version is used. Signed-off-by: Stefan Roese --- Changes in v2: - New patch arch/arm/lib/memset-arm64.S | 30 ++ 1 file changed, 30 insertions(+) diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S index 710f6f582cad..a474dcb53c83 100644 --- a/arch/arm/lib/memset-arm64.S +++ b/arch/arm/lib/memset-arm64.S @@ -11,6 +11,7 @@ * */ +#include #include "asmdefs.h" #define dstin x0 @@ -25,6 +26,35 @@ ENTRY (memset) PTR_ARG (0) SIZE_ARG (2) + /* +* The optimized memset uses the dc opcode, which causes problems +* when the cache is disabled. Let's check if the cache is disabled +* and use a very simple memset implementation in this case. Otherwise +* jump to the optimized version. +*/ + switch_el x6, 3f, 2f, 1f +3: mrs x6, sctlr_el3 + b 0f +2: mrs x6, sctlr_el2 + b 0f +1: mrs x6, sctlr_el1 +0: + tst x6, #CR_C + bne 9f + + /* +* A very "simple" memset implementation without the use of the +* dc opcode. Can be run with caches disabled. +*/ + mov x3, #0x0 +4: strbw1, [x0, x3] + add x3, x3, #0x1 + cmp x2, x3 + bne 4b + ret +9: + + /* Here the optimized memset version starts */ dup v0.16B, valw add dstend, dstin, count -- 2.32.0
Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate folder
On Tue, Aug 10, 2021 at 12:55 PM Sean Anderson wrote:
>
> > Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate
> > folder
>
> nit: separate
>
Thanks for catching it. Fix it in the next version.
> On 8/3/21 12:44 AM, Zong Li wrote:
> > Put the platform-related implementation into their own folder
> > respectively. Just leave the common library in the top of lib
> > folder.
> >
> > Signed-off-by: Zong Li
> > ---
> > arch/riscv/Kconfig | 7 +++
> > arch/riscv/lib/Makefile | 9 -
> > arch/riscv/lib/andestech/Kconfig| 8
> > arch/riscv/lib/andestech/Makefile | 7 +++
> > arch/riscv/lib/{ => andestech}/andes_plic.c | 0
> > arch/riscv/lib/sifive/Kconfig | 8
> > arch/riscv/lib/sifive/Makefile | 9 +
> > arch/riscv/lib/{ => sifive}/sifive_cache.c | 0
> > arch/riscv/lib/{ => sifive}/sifive_clint.c | 0
> > 9 files changed, 43 insertions(+), 5 deletions(-)
> > create mode 100644 arch/riscv/lib/andestech/Kconfig
> > create mode 100644 arch/riscv/lib/andestech/Makefile
> > rename arch/riscv/lib/{ => andestech}/andes_plic.c (100%)
> > create mode 100644 arch/riscv/lib/sifive/Kconfig
> > create mode 100644 arch/riscv/lib/sifive/Makefile
> > rename arch/riscv/lib/{ => sifive}/sifive_cache.c (100%)
> > rename arch/riscv/lib/{ => sifive}/sifive_clint.c (100%)
>
> NAK from me. I'd much rather see organization by function (e.g.
> clint/sbi/plic together) than by vendor. Plus, the clint/plic are not
> really specific to one vendor like ccache.
>
Yes, it makes more sense to me. In this case, there are three
functionalities, so I'd like to separate clint, plic and cache at this
time, does it make sense to you?
> --Sean
>
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index ec651fe0a4..ed1bf2f6c8 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -72,6 +72,10 @@ source "arch/riscv/cpu/fu540/Kconfig"
> > source "arch/riscv/cpu/fu740/Kconfig"
> > source "arch/riscv/cpu/generic/Kconfig"
> >
> > +# library-specific options below
> > +source "arch/riscv/lib/sifive/Kconfig"
> > +source "arch/riscv/lib/andestech/Kconfig"
> > +
> > # architecture-specific options below
> >
> > choice
> > @@ -175,18 +179,21 @@ config SIFIVE_CLINT
> > config SPL_SIFIVE_CLINT
> > bool
> > depends on SPL_RISCV_MMODE
> > + select SIFIVE_LIB
> > help
> > The SiFive CLINT block holds memory-mapped control and status
> > registers
> > associated with software and timer interrupts.
> >
> > config SIFIVE_CACHE
> > bool
> > + select SIFIVE_LIB
> > help
> > This enables the operations to configure SiFive cache
> >
> > config ANDES_PLIC
> > bool
> > depends on RISCV_MMODE || SPL_RISCV_MMODE
> > + select ANDESTECH_LIB
> > select REGMAP
> > select SYSCON
> > select SPL_REGMAP if SPL
> > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> > index 06020fcc2a..f58d1f9819 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -10,11 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> > obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
> > obj-$(CONFIG_CMD_GO) += boot.o
> > obj-y += cache.o
> > -obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
> > -ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> > -obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
> > -obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
> > -else
> > +ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),)
> > obj-$(CONFIG_SBI) += sbi.o
> > obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
> > endif
> > @@ -42,3 +38,6 @@ extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
> > obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
> > obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMMOVE) += memmove.o
> > obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
> > +
> > +obj-$(CONFIG_SIFIVE_LIB) += sifive/
> > +obj-$(CONFIG_ANDESTECH_LIB) += andestech/
> > diff --git a/arch/riscv/lib/andestech/Kconfig
> > b/arch/riscv/lib/andestech/Kconfig
> > new file mode 100644
> > index 00..75f83a8123
> > --- /dev/null
> > +++ b/arch/riscv/lib/andestech/Kconfig
> > @@ -0,0 +1,8 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2021 SiFive, Inc
> > +
> > +config ANDESTECH_LIB
> > + bool
> > + help
> > + This supports the specific libraries for AndesTech platforms
> > diff --git a/arch/riscv/lib/andestech/Makefile
> > b/arch/riscv/lib/andestech/Makefile
> > new file mode 100644
> > index 00..49f45d0a29
> > --- /dev/null
> > +++ b/arch/riscv/lib/andestech/Makefile
> > @@ -0,0 +1,7 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2021 SiFive, Inc
> > +
> > +ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> > +obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
> > +endif
> > diff --git a/arch/riscv/lib/andes_plic.c
> > b/arch/riscv/lib/andestech/andes_plic.c
Re: [PATCH v2 3/6] riscv: lib: introduce cache_init interface
On Tue, Aug 10, 2021 at 12:47 PM Sean Anderson wrote:
>
> On 8/3/21 12:44 AM, Zong Li wrote:
> > Add an interface for cache initialization. Each platform can overwrite
> > this weak function by their own implementation, such as sifive_cache in
> > this patch.
>
> Can we call this enable_caches instead of cache_init? This function is
> called by initr_caches in board_r.c for ARM. There's even an
> eight-year-old TODO on the subject.
>
I had considered use it, The reason I finally used cache_init here is
that it seems to me that cache_init would be more flexible for risc-v
platforms to do not only cache enable, but also various
platform-specific initialization of cache, even they could decide the
time to invoke cache_init if there is particular initialization
sequence. If you think that cache_init is OK to you, I would prefer to
retain cache_init. I can still use enable_caches instead of cache_init
if you think that it is a better way. Please let me know your thoughts
and thanks for your review.
> >
> > Signed-off-by: Zong Li
> > ---
> > arch/riscv/Kconfig | 5 +
> > arch/riscv/include/asm/cache.h | 1 +
> > arch/riscv/lib/Makefile| 1 +
> > arch/riscv/lib/cache.c | 5 +
> > arch/riscv/lib/sifive_cache.c | 27 +++
> > 5 files changed, 39 insertions(+)
> > create mode 100644 arch/riscv/lib/sifive_cache.c
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 4b0c3dffa6..ec651fe0a4 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
> > The SiFive CLINT block holds memory-mapped control and status
> > registers
> > associated with software and timer interrupts.
> >
> > +config SIFIVE_CACHE
> > + bool
> > + help
> > + This enables the operations to configure SiFive cache
> > +
> > config ANDES_PLIC
> > bool
> > depends on RISCV_MMODE || SPL_RISCV_MMODE
> > diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
> > index ec8fe201d3..6ebb2b4329 100644
> > --- a/arch/riscv/include/asm/cache.h
> > +++ b/arch/riscv/include/asm/cache.h
> > @@ -9,6 +9,7 @@
> >
> > /* cache */
> > voidcache_flush(void);
> > +int cache_init(void);
> >
> > /*
> >* The current upper bound for RISCV L1 data cache line sizes is 32 bytes.
> > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> > index c4cc41434b..06020fcc2a 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> > obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
> > obj-$(CONFIG_CMD_GO) += boot.o
> > obj-y += cache.o
> > +obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
> > ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> > obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
> > obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
> > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> > index b1d42bcc2b..2cd66504c6 100644
> > --- a/arch/riscv/lib/cache.c
> > +++ b/arch/riscv/lib/cache.c
> > @@ -70,3 +70,8 @@ __weak int dcache_status(void)
> > {
> > return 0;
> > }
> > +
> > +__weak int cache_init(void)
> > +{
> > + return 0;
> > +}
> > diff --git a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c
> > new file mode 100644
> > index 00..94e84e024e
> > --- /dev/null
> > +++ b/arch/riscv/lib/sifive_cache.c
> > @@ -0,0 +1,27 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021 SiFive, Inc
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +int cache_init(void)
> > +{
> > + struct udevice *dev;
> > + int ret;
> > +
> > + /* Enable ways of ccache */
> > + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> > + DM_DRIVER_GET(sifive_ccache),
> > + );
> > + if (ret)
> > + return log_msg_ret("Cannot enable cache ways", ret);
> > +
> > + ret = cache_enable(dev);
> > + if (ret)
> > + return log_msg_ret("ccache enable failed", ret);
> > +
> > + return 0;
> > +}
> >
>
> Otherwise LGTM
[PATCH] arm: kirkwood: Goflex Home: Update board maintainer
Change maintainer to me. Suriyan no longer has this board and wishes to see someone maintaining it actively. Signed-off-by: Tony Dinh --- board/Seagate/goflexhome/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/Seagate/goflexhome/MAINTAINERS b/board/Seagate/goflexhome/MAINTAINERS index 6d6a1ff4e3..a71b4ba1fe 100644 --- a/board/Seagate/goflexhome/MAINTAINERS +++ b/board/Seagate/goflexhome/MAINTAINERS @@ -1,5 +1,5 @@ GOFLEXHOME BOARD -M: Suriyan Ramasami +M: Tony Dinh S: Maintained F: board/Seagate/goflexhome/ F: include/configs/goflexhome.h -- 2.20.1
Re: [PATCH v2 2/6] board: sifive: use ccache driver instead of helper function
On Tue, Aug 10, 2021 at 12:51 PM Sean Anderson wrote:
>
> On 8/3/21 12:44 AM, Zong Li wrote:
> > Invokes the generic cache_enable interface to execute the relative
> > implementation in SiFive ccache driver.
> >
> > Signed-off-by: Zong Li
> > ---
> > arch/riscv/cpu/fu540/Kconfig | 1 +
> > arch/riscv/cpu/fu540/cache.c | 54 ++-
> > arch/riscv/cpu/fu740/Kconfig | 1 +
> > arch/riscv/cpu/fu740/cache.c | 52 ++
> > arch/riscv/include/asm/arch-fu540/cache.h | 2 +-
> > arch/riscv/include/asm/arch-fu740/cache.h | 2 +-
> > board/sifive/unleashed/unleashed.c| 10 +
> > board/sifive/unmatched/unmatched.c| 9 +---
> > 8 files changed, 33 insertions(+), 98 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
> > index 05463b2625..8608741779 100644
> > --- a/arch/riscv/cpu/fu540/Kconfig
> > +++ b/arch/riscv/cpu/fu540/Kconfig
> > @@ -19,6 +19,7 @@ config SIFIVE_FU540
> > imply SMP
> > imply CLK_SIFIVE
> > imply CLK_SIFIVE_PRCI
> > + imply SIFIVE_CCACHE
> > imply SIFIVE_SERIAL
> > imply MACB
> > imply MII
> > diff --git a/arch/riscv/cpu/fu540/cache.c b/arch/riscv/cpu/fu540/cache.c
> > index 0fc4ef6c00..bc31f664b8 100644
> > --- a/arch/riscv/cpu/fu540/cache.c
> > +++ b/arch/riscv/cpu/fu540/cache.c
> > @@ -1,55 +1,29 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> > - * Copyright (C) 2020 SiFive, Inc
> > + * Copyright (C) 2020 - 2021 SiFive, Inc
> >*
> >* Authors:
> >* Pragnesh Patel
> >*/
> >
> > #include
> > -#include
> > -#include
> > -#include
> > +#include
> > +#include
> >
> > -/* Register offsets */
> > -#define L2_CACHE_CONFIG 0x000
> > -#define L2_CACHE_ENABLE 0x008
> > -
> > -#define MASK_NUM_WAYSGENMASK(15, 8)
> > -#define NUM_WAYS_SHIFT 8
> > -
> > -DECLARE_GLOBAL_DATA_PTR;
> > -
> > -int cache_enable_ways(void)
> > +int sifive_ccache_enable_ways(void)
> > {
> > - const void *blob = gd->fdt_blob;
> > - int node;
> > - fdt_addr_t base;
> > - u32 config;
> > - u32 ways;
> > -
> > - volatile u32 *enable;
> > -
> > - node = fdt_node_offset_by_compatible(blob, -1,
> > - "sifive,fu540-c000-ccache");
> > -
> > - if (node < 0)
> > - return node;
> > -
> > - base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> > - NULL, false);
> > - if (base == FDT_ADDR_T_NONE)
> > - return FDT_ADDR_T_NONE;
> > + struct udevice *dev;
> > + int ret;
> >
> > - config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
> > - ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
> > + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> > + DM_DRIVER_GET(sifive_ccache),
> > + );
> > + if (ret)
> > + return log_msg_ret("Cannot enable cache ways", ret);
> >
> > - enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
> > + ret = cache_enable(dev);
> > + if (ret)
> > + return log_msg_ret("ccache enable failed", ret);
> >
> > - /* memory barrier */
> > - mb();
> > - (*enable) = ways - 1;
> > - /* memory barrier */
> > - mb();
> > return 0;
> > }
> > diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
> > index 408195f149..b4cada0ea9 100644
> > --- a/arch/riscv/cpu/fu740/Kconfig
> > +++ b/arch/riscv/cpu/fu740/Kconfig
> > @@ -19,6 +19,7 @@ config SIFIVE_FU740
> > imply SMP
> > imply CLK_SIFIVE
> > imply CLK_SIFIVE_PRCI
> > + imply SIFIVE_CCACHE
> > imply SIFIVE_SERIAL
> > imply MACB
> > imply MII
> > diff --git a/arch/riscv/cpu/fu740/cache.c b/arch/riscv/cpu/fu740/cache.c
> > index 680955c9e3..e2782d76c0 100644
> > --- a/arch/riscv/cpu/fu740/cache.c
> > +++ b/arch/riscv/cpu/fu740/cache.c
> > @@ -7,49 +7,23 @@
> >*/
> >
> > #include
> > -#include
> > -#include
> > -#include
> > +#include
> > +#include
> >
> > -/* Register offsets */
> > -#define L2_CACHE_CONFIG 0x000
> > -#define L2_CACHE_ENABLE 0x008
> > -
> > -#define MASK_NUM_WAYSGENMASK(15, 8)
> > -#define NUM_WAYS_SHIFT 8
> > -
> > -DECLARE_GLOBAL_DATA_PTR;
> > -
> > -int cache_enable_ways(void)
> > +int sifive_ccache_enable_ways(void)
> > {
> > - const void *blob = gd->fdt_blob;
> > - int node;
> > - fdt_addr_t base;
> > - u32 config;
> > - u32 ways;
> > -
> > - volatile u32 *enable;
> > -
> > - node = fdt_node_offset_by_compatible(blob, -1,
> > - "sifive,fu740-c000-ccache");
> > -
> > - if (node < 0)
> > - return node;
> > -
> > - base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> > -
[PATCH] arm: kirkwood: Dockstar: Update board maintainer
Change maintainer to me. Eric no longer has this board and wishes to see someone maintaining it actively. Signed-off-by: Tony Dinh --- board/Seagate/dockstar/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/Seagate/dockstar/MAINTAINERS b/board/Seagate/dockstar/MAINTAINERS index f259e58ae6..0f6243e257 100644 --- a/board/Seagate/dockstar/MAINTAINERS +++ b/board/Seagate/dockstar/MAINTAINERS @@ -1,5 +1,5 @@ DOCKSTAR BOARD -M: Eric Cooper +M: Tony Dinh S: Maintained F: board/Seagate/dockstar/ F: include/configs/dockstar.h -- 2.20.1
