[PATCH v1] configs: arbel: Use generic timer and npcm reset driver
Modify defconfig to use generic timer and npcm reset driver Signed-off-by: Jim Liu --- configs/arbel_evb_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/configs/arbel_evb_defconfig b/configs/arbel_evb_defconfig index 45fafe790c..08753aebc0 100644 --- a/configs/arbel_evb_defconfig +++ b/configs/arbel_evb_defconfig @@ -80,7 +80,6 @@ CONFIG_PINCONF=y CONFIG_PINCTRL_NPCM8XX=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_NPCM8XX=y -CONFIG_RESET_SYSCON=y CONFIG_RNG_NPCM=y CONFIG_DM_SERIAL=y CONFIG_NPCM_SERIAL=y @@ -90,8 +89,6 @@ CONFIG_NPCM_FIU_SPI=y CONFIG_NPCM_PSPI=y CONFIG_TEE=y CONFIG_OPTEE=y -CONFIG_TIMER=y -CONFIG_NPCM_TIMER=y CONFIG_TPM2_FTPM_TEE=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -- 2.25.1
Re: [PATCH 1/1] api: add missing cookie checks for network access
On 4/10/24 02:43, Tom Rini wrote:
On Tue, Apr 09, 2024 at 03:16:55PM +0200, Heinrich Schuchardt wrote:
dev_write_net() and dev_read_net() should validate the provided cookie.
Signed-off-by: Heinrich Schuchardt
---
api/api_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/api/api_net.c b/api/api_net.c
index 7515c26e8b4..0b931a80787 100644
--- a/api/api_net.c
+++ b/api/api_net.c
@@ -72,14 +72,16 @@ int dev_enum_net(struct device_info *di)
int dev_write_net(void *cookie, void *buf, int len)
{
- /* XXX verify that cookie points to a valid net device??? */
+ if (!dev_valid_net(cookie))
+ return API_ENODEV;
return eth_send(buf, len);
}
int dev_read_net(void *cookie, void *buf, int len)
{
- /* XXX verify that cookie points to a valid net device??? */
+ if (!dev_valid_net(cookie))
+ return API_ENODEV;
return eth_receive(buf, len);
}
Is this right? Probably. But what triggered looking in to this to start
with? I don't think anything is enabling the API support these days
even.
We should either properly test the API in our CI or or remove it.
What once was done via the API could be done via an EFI payload in a
more portable way today.
Best regards
Heinrich
Re: [PATCH v2 3/3] mtd: spi-nor-id: Add S25FS064S, S25FS128S, S25FS256S IDs
On 4/9/2024 8:54 PM, Pratyush Yadav wrote:
> On Tue, Apr 09 2024, tkuw584...@gmail.com wrote:
>
>> From: Takahiro Kuwano
>>
>> The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
>> Flash devices with S25FS512S. Some difference depending on the device
>> densities are taken care in post SFDP fixup.
>>
>> Signed-off-by: Takahiro Kuwano
>> ---
>> drivers/mtd/spi/spi-nor-core.c | 24 ++--
>> drivers/mtd/spi/spi-nor-ids.c | 3 +++
>> 2 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index 9620852817..9b81b31e8e 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -3356,12 +3356,24 @@ static int s25fs_s_post_bfpt_fixup(struct spi_nor
>> *nor,
>> static void s25fs_s_post_sfdp_fixup(struct spi_nor *nor,
>> struct spi_nor_flash_parameter *params)
>> {
>> -/* READ_1_1_2 is not supported */
>> -params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
>> -/* READ_1_1_4 is not supported */
>> -params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
>> -/* PP_1_1_4 is not supported */
>> -params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
>> +/*
>> + * The S25FS064S(8MB) supports 1-1-2 and 1-1-4 commands, but params for
>> + * read ops in SFDP are wrong. The other density parts do not support
>> + * 1-1-2 and 1-1-4 commands.
>> + */
>> +if (params->size == SZ_8M) {
>> +spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_2],
>> + 0, 8, SPINOR_OP_READ_1_1_2,
>> + SNOR_PROTO_1_1_2);
>> +spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_4],
>> + 0, 8, SPINOR_OP_READ_1_1_4,
>> + SNOR_PROTO_1_1_4);
>> +} else {
>> +params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
>> +params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
>> +params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
>> +}
>> +
>
> Reviewed-by: Pratyush Yadav
>
> BTW (not directly related to this patch), I looked at the datasheet you
> provided in the cover letter and it says dual and quad I/O is supported
> for the 16 MB and 32 MB parts as well. Why do you mask them out here
> then?
>
In the datasheet,
1-2-2 and 1-4-4 read are named as dual and quad I/O read.
1-1-2 and 1-1-4 read are named as dual and quad output read.
Dual and quad I/O read (1-2-2 and 1-4-4) is supported in all S25FS-S parts.
Dual and quad output read (1-1-2 and 1-1-4) is only supported in S25FS064S.
Thank you for reviewing!
Takahiro
Re: [PATCH] riscv: dts: jh7110: Enable PLL node in SPL
Original speed class SD cards fail with this change "unable to change mode". On Tue, Mar 12, 2024 at 4:12 AM Hal Feng wrote: > > > On 06.03.24 11:00, Bo Gan wrote: > > > > Previously PLL node was missing from SPL dts. This caused BUS_ROOT to stay > > on > > OSC clock (24Mhz). As a result, all peripherals have to run at a much lower > > frequency, and loading from sdcard/emmc is slow. > > Thus, enabling PLL node in dts to fix this. > > > > Signed-off-by: Bo Gan > > Reviewed-by: Hal Feng >
Re: [PATCH v2 02/16] board: am64x: Define capsule update firmware info
On Tue, Apr 09, 2024 at 06:31:02AM +0200, Heinrich Schuchardt wrote: > On 4/9/24 00:31, Jonathan Humphreys wrote: [snip] > The series has been assigned to me in Patchwork. > > But changes should be tested and reviewed by the respective board > maintainers (Vignesh, Tom for AM64x) as I have no access to TI boards. I'll pick it up once you're happy with the capsule side of things if you like, but in my mind it's more important to emphasize that this is what capsule support looks like as it rolls out to more platforms, is everyone happy with this? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] api: add missing cookie checks for network access
On Tue, Apr 09, 2024 at 03:16:55PM +0200, Heinrich Schuchardt wrote:
> dev_write_net() and dev_read_net() should validate the provided cookie.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> api/api_net.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/api/api_net.c b/api/api_net.c
> index 7515c26e8b4..0b931a80787 100644
> --- a/api/api_net.c
> +++ b/api/api_net.c
> @@ -72,14 +72,16 @@ int dev_enum_net(struct device_info *di)
>
> int dev_write_net(void *cookie, void *buf, int len)
> {
> - /* XXX verify that cookie points to a valid net device??? */
> + if (!dev_valid_net(cookie))
> + return API_ENODEV;
>
> return eth_send(buf, len);
> }
>
> int dev_read_net(void *cookie, void *buf, int len)
> {
> - /* XXX verify that cookie points to a valid net device??? */
> + if (!dev_valid_net(cookie))
> + return API_ENODEV;
>
> return eth_receive(buf, len);
> }
Is this right? Probably. But what triggered looking in to this to start
with? I don't think anything is enabling the API support these days
even.
--
Tom
signature.asc
Description: PGP signature
Re: [GIT PULL] u-boot-riscv/master
On Tue, Apr 09, 2024 at 04:25:36PM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit 069d07396e30aa9be396c1dd3fc158ac199e6843: > > Merge tag 'efi-2024-07-rc1' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-08 14:33:59 > -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to c1f78a4f632276bb4d77f8c79fe203709a9fa397: > > doc: describe Milk-V Mars board (2024-04-09 11:30:37 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/20256 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/7] dts: j721e: binman: Include firmware capsules binman nodes
On 4/8/24 5:17 PM, Jonathan Humphreys wrote:
Signed-off-by: Jonathan Humphreys
---
arch/arm/dts/k3-j721e-binman.dtsi | 32 +++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..9169551c422 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -207,6 +207,29 @@
};
};
};
+
+#include "k3-binman-capsule-r5.dtsi"
+
+// Capsue update GUIDs. See ti_armv7_common.h.
+#define K3_SYSFW_IMAGE_UUID_STR "6fd10680-361b-431f-80aa-899455819e11"
+
+ {
+ capsule-sysfw {
+ filename = "sysfw-capsule.bin";
+ efi-capsule {
+ image-index = <0x4>;
+ image-guid = K3_SYSFW_IMAGE_UUID_STR;
+ private-key = "arch/arm/mach-k3/keys/custMpk.pem";
+ public-key-cert = "arch/arm/mach-k3/keys/custMpk.crt";
+ monotonic-count = <0x1>;
+
+ blob {
+ filename = "sysfw.itb";
+ };
+ };
+ };
+};
+
#endif
#ifdef CONFIG_TARGET_J721E_A72_EVM
@@ -585,4 +608,13 @@
};
};
};
+
+#include "k3-binman-capsule.dtsi"
+_name {
+ filename = "tispl.bin_unsigned";
Why use the _unsigned images here? HS devices cannot boot unsigned GP images,
but both GP and HS devices *can* boot the normal signed images (GP just strips
the signatures off). So no need to use the _unsigned images anymore (I'm
planning to just remove them at some point to prevent this confusion).
Andrew
+};
+_name {
+ filename = "u-boot.img_unsigned";
+};
+
#endif
Re: [PATCH 01/13] ti:keys Add EFI signature list
On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:
On 4/9/24 14:14, Andrew Davis wrote:
On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
On 4/8/24 23:33, Jonathan Humphreys wrote:
EFI signature list using TI dummy keys.
Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.
The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).
Andrew
Why should we create signed capsules which are already compromised by
publishing the private key?
If you buy these devices you have two options, you can burn real
keys, or you can burn these dummy keys. If you burn dummy keys
then these images will boot and so will any image you or anyone
else wants to boot on the device. (since the keys are published
anyone can make images for them, that is how we do GP (general
purpose) devices these days)
If you burn your own keys, then you switch out these keys here
and your device will only boot images that you permit by signing
with your keys.
You'll find plenty of open source projects do the same and
give out example keys to show how to use real keys, even
official GNU projects.
https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys
Andrew
Best regards
Heinrich
Best regards
Heinrich
Signed-off-by: Jonathan Humphreys
---
arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
diff --git a/arch/arm/mach-k3/keys/custMpk.esl
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};xRCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h
Re: [PATCH v2 02/16] board: am64x: Define capsule update firmware info
Heinrich Schuchardt writes:
> On 4/9/24 00:31, Jonathan Humphreys wrote:
>> Define the firmwares updatable via EFI capsule update.
>
> Nits:
>
> %s/firmwares/firmware/ (firmware is uncountable).
>
>>
>> Signed-off-by: Jonathan Humphreys
>> ---
>> board/ti/am64x/evm.c | 33 +
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
>> index b8de69da06c..876c5c25d42 100644
>> --- a/board/ti/am64x/evm.c
>> +++ b/board/ti/am64x/evm.c
>> @@ -7,6 +7,7 @@
>>*
>>*/
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -27,6 +28,38 @@
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> +#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
>> +struct efi_fw_image fw_images[] = {
>> +{
>> +.image_type_id = K3_TIBOOT3_IMAGE_GUID,
>> +.fw_name = u"K3_TIBOOT3",
>> +.image_index = 1,
>> +},
>> +{
>> +.image_type_id = K3_SPL_IMAGE_GUID,
>> +.fw_name = u"K3_SPL",
>> +.image_index = 2,
>> +},
>> +{
>> +.image_type_id = K3_UBOOT_IMAGE_GUID,
>> +.fw_name = u"K3_UBOOT",
>> +.image_index = 3,
>> +}
>> +};
>> +
>> +struct efi_capsule_update_info update_info = {
>> +.dfu_string = "sf 0:0=tiboot3.bin raw 0 10;tispl.bin raw 10
>> 20;u-boot.img raw 30 40",
>
> Is TI using other addresses than Phytec?
>
> doc/board/phytec/phycore-am64x.rst:
>
>fatload mmc 1 ${loadaddr} tiboot3.bin
>sf update $loadaddr 0x0 $filesize
>fatload mmc 1 ${loadaddr} tispl.bin
>sf update $loadaddr 0x8 $filesize
>fatload mmc 1 ${loadaddr} u-boot.img
>sf update $loadaddr 0x28 $filesize
>
This patch has the correct offsets for am64x, so I guess phycore defined
the offsets differently.
> Please, add documentation in doc/board/ for all boards in the series
> specifying the location of the firmware in flash memory and how to
> update it(cf. section OSPI in doc/board/ti/am65x_evm.rst).
>
Yes, I will add patches to document OSPI layouts where missing.
>> +.num_images = ARRAY_SIZE(fw_images),
>> +.images = fw_images,
>> +};
>
> The series has been assigned to me in Patchwork.
>
> But changes should be tested and reviewed by the respective board
> maintainers (Vignesh, Tom for AM64x) as I have no access to TI boards.
>
> Best regards
>
> Heinrich
>
>> +
>> +void set_dfu_alt_info(char *interface, char *devstr)
>> +{
>> +env_set("dfu_alt_info", update_info.dfu_string);
>> +}
>> +
>> +#endif /* EFI_HAVE_CAPSULE_SUPPORT */
>> +
>> int board_init(void)
>> {
>> return 0;
Re: [PATCH v2 01/16] board: Define GUIDs for firmware images
Heinrich Schuchardt writes: > On 4/9/24 00:31, Jonathan Humphreys wrote: >> Define GUIDs for the different firmware images (tiboot3.bin, tispl.bin, >> u-boot.img, sysfw). > >> Signed-off-by: Jonathan Humphreys >> --- >> include/configs/ti_armv7_common.h | 17 + >> 1 file changed, 17 insertions(+) >> >> diff --git a/include/configs/ti_armv7_common.h >> b/include/configs/ti_armv7_common.h >> index 3def7b1027e..4ce14a9b84c 100644 >> --- a/include/configs/ti_armv7_common.h >> +++ b/include/configs/ti_armv7_common.h >> @@ -16,6 +16,23 @@ >> #ifndef __CONFIG_TI_ARMV7_COMMON_H__ >> #define __CONFIG_TI_ARMV7_COMMON_H__ >> >> +/* GUIDs for capsule updatable firmware images */ > > Please, provide code comments for the GUIDs, e.g. > > /** > * define K3_TIBOOT3_IMAGE_GUID - firmware GUID for K3 tiboot3.bin > * > * This GUID is used in capsules updates to identify the tiboot3.bin > * binary. > */ > > Cf. > https://docs.kernel.org/doc-guide/kernel-doc.html#object-like-macro-documentation > > Best regards > > Heinrich > Heinrich, thanks for reviewing! I modelled the GUID macros after how other boards and even core code defined there's. (eg, include/configs/kontron-sl-mx8mm.h or include/efi_api.h). However, if this is the new direction, I will format as you suggest. Please confirm. thanks Jon >> +#define K3_TIBOOT3_IMAGE_GUID \ >> +EFI_GUID(0xe672b518, 0x7cd7, 0x4014, 0xbd, 0x8d, \ >> + 0x40, 0x72, 0x4d, 0x0a, 0xd4, 0xdc) >> + >> +#define K3_SPL_IMAGE_GUID \ >> +EFI_GUID(0x86f710ad, 0x10cf, 0x46ea, 0xac, 0x67, \ >> + 0x85, 0x6a, 0xe0, 0x6e, 0xfa, 0xd2) >> + >> +#define K3_UBOOT_IMAGE_GUID \ >> +EFI_GUID(0x81b58fb0, 0x3b00, 0x4add, 0xa2, 0x0a, \ >> + 0xc1, 0x85, 0xbb, 0xac, 0xa1, 0xed) >> + >> +#define K3_SYSFW_IMAGE_GUID \ >> +EFI_GUID(0x6fd10680, 0x361b, 0x431f, 0x80, 0xaa, \ >> + 0x89, 0x94, 0x55, 0x81, 0x9e, 0x11) >> + >> /* >>* We setup defaults based on constraints from the Linux kernel, which >> should >>* also be safe elsewhere. We have the default load at 32MB into DDR (for
[PATCH 1/1] efi_loader: 'EFI using ACPI tables at' should be debug message
The message "EFI using ACPI tables at %lx\n" is only of interest when
debugging. Make it a debug message.
Fixes: 085f8db6b98d ("efi: Use the installed ACPI tables")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
index 67bbd2a01c0..67bd7f8ca24 100644
--- a/lib/efi_loader/efi_acpi.c
+++ b/lib/efi_loader/efi_acpi.c
@@ -41,7 +41,7 @@ efi_status_t efi_acpi_register(void)
}
addr = gd_acpi_start();
- printf("EFI using ACPI tables at %lx\n", addr);
+ log_debug("EFI using ACPI tables at %lx\n", addr);
/* And expose them to our EFI payload */
return efi_install_configuration_table(_guid,
--
2.43.0
[PATCH 1/1] fs: fat: fill creation and change date
The FAT specification requires that the change date is set.
If a DM RTC device exists, set the creation and change date to the current
date when updating the directory entry. Otherwise use the date 2020-01-01.
Signed-off-by: Heinrich Schuchardt
---
fs/fat/fat_write.c | 44
1 file changed, 44 insertions(+)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 8b5d669b005..c8e0fbf1a3b 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include "fat.c"
@@ -1151,6 +1152,41 @@ getit:
return 0;
}
+/**
+ * dentry_set_time() - set change time
+ *
+ * @dentptr: directory entry
+ */
+static void dentry_set_time(dir_entry *dentptr)
+{
+ if (CONFIG_IS_ENABLED(DM_RTC)) {
+ struct udevice *dev;
+ struct rtc_time tm;
+ u16 date;
+ u16 time;
+
+ uclass_first_device(UCLASS_RTC, );
+ if (!dev)
+ goto err;
+ if (dm_rtc_get(dev, ))
+ goto err;
+ if (tm.tm_year < 1980 || tm.tm_year > 2107)
+ goto err;
+ date = (tm.tm_mday & 0x1f) |
+ ((tm.tm_mon & 0xf) << 5) |
+ ((tm.tm_year - 1980) << 9);
+ time = (tm.tm_sec > 1) |
+ ((tm.tm_min & 0x3f) << 5) |
+ (tm.tm_hour << 11);
+ dentptr->date = date;
+ dentptr->time = time;
+ return;
+ }
+err:
+ dentptr->date = 0x2821; /* 2000-01-01 */
+ dentptr->time = 0;
+}
+
/**
* fill_dentry() - fill directory entry with shortname
*
@@ -1171,6 +1207,12 @@ static void fill_dentry(fsdata *mydata, dir_entry
*dentptr,
dentptr->attr = attr;
+ /* Set change date */
+ dentry_set_time(dentptr);
+ /* Set creation date */
+ dentptr->cdate = dentptr->date;
+ dentptr->ctime = dentptr->time;
+
memcpy(>nameext, shortname, SHORT_NAME_SIZE);
}
@@ -1376,6 +1418,8 @@ int file_fat_write_at(const char *filename, loff_t pos,
void *buffer,
/* Update file size in a directory entry */
retdent->size = cpu_to_le32(pos + size);
+ /* Update change date */
+ dentry_set_time(retdent);
} else {
/* Create a new file */
char shortname[SHORT_NAME_SIZE];
--
2.43.0
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hello Jonas, On 2024-04-09 18:30, Jonas Karlman wrote: On 2024-04-09 18:02, Quentin Schulz wrote: On 4/9/24 17:58, Jonas Karlman wrote: On 2024-04-09 17:27, Quentin Schulz wrote: On 4/8/24 23:06, Jonas Karlman wrote: eMMC nodes in linux device tree files typically only contain a mmc-hs400 prop to signal support for both HS400 and HS200. However, U-Boot require an explicit mmc-hs200 prop to signal support for the HS200 mode. > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled using a mmc-hs400 prop. Technically speaking, the DT binding should be the one and only source of truth and should be implementation-agnostic. There it says: """ mmc-hs400-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.2V I/O) is supported. mmc-hs400-1_8v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.8V I/O) is supported. """ So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it makes sense. The point of the DT/DT binding is to be system-agnostic and representative of the **HW** implementation. At least that's what the DT people want it to be. If the eMMC standard doesn't allow to have HS400 without HS200, then I think this change is acceptable as is, because it is the reality of the HW standard. Couldn't find this implied in the standard though (but I just skimmed through). It's also quite surprising, as it's not because the eMMC works with HS400 that it necessarily does with HS200 or that it's desired (EMI, signal integrity/stability, etc...)? Now, it wouldn't be the first time U-Boot follows whatever is done in Linux, so... up to you/the maintainers :) Agree that implying HS200 does not fully make sense, however it was part of the original Linux binding when HS400 was added in v3.16-rc1 [1] so I think that this is the expected behavior and changing it may be an ABI breakage. I'm not advocating undoing the kernel "hack", but rather make it so that we add hs200 to DTs where it's actually supported instead of doing the same hack the kernel does. In that case, we wouldn't need the hack anymore. I will add a patch that adds the missing mmc-hs200 props to affected rk3588 boards, nanopc-t4 and quartzpro64 in v2 of the "rockchip: rk35xx: Miscellaneous fixes and updates" series. Also turns out the issue with those boards was because of my other "mmc: rockchip_sdhci: Revert 4 blocks PIO mode read limit for RK35xx" patch, so will need to rework that revert some more before posting a v2 of that patch. For this patch it is fully up to the maintainers if U-Boot wants to mimic Linux kernel or not. I think that the logic used in the Linux kernel should be followed, because one of the goals should be to add as few "touches" to the upstream DT files in U-Boot as possible. If the kernel binding patch that I mentioned in my earlier email [1] becomes accepted, that should be another reason to do so. [1] https://lore.kernel.org/u-boot/9b62bbedf2c6d52b76a8ce1ce57dd...@manjaro.org/
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hello Quentin, On 2024-04-09 18:02, Quentin Schulz wrote: On 4/9/24 17:58, Jonas Karlman wrote: On 2024-04-09 17:27, Quentin Schulz wrote: On 4/8/24 23:06, Jonas Karlman wrote: eMMC nodes in linux device tree files typically only contain a mmc-hs400 prop to signal support for both HS400 and HS200. However, U-Boot require an explicit mmc-hs200 prop to signal support for the HS200 mode. > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled using a mmc-hs400 prop. Technically speaking, the DT binding should be the one and only source of truth and should be implementation-agnostic. There it says: """ mmc-hs400-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.2V I/O) is supported. mmc-hs400-1_8v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.8V I/O) is supported. """ So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it makes sense. Good point, but I think that the descriptions in this Linux kernel binding should be fixed instead, to eliminate this ambiguity. I'll explain this further below. The point of the DT/DT binding is to be system-agnostic and representative of the **HW** implementation. At least that's what the DT people want it to be. If the eMMC standard doesn't allow to have HS400 without HS200, then I think this change is acceptable as is, because it is the reality of the HW standard. Couldn't find this implied in the standard though (but I just skimmed through). It's also quite surprising, as it's not because the eMMC works with HS400 that it necessarily does with HS200 or that it's desired (EMI, signal integrity/stability, etc...)? Now, it wouldn't be the first time U-Boot follows whatever is done in Linux, so... up to you/the maintainers :) Agree that implying HS200 does not fully make sense, however it was part of the original Linux binding when HS400 was added in v3.16-rc1 [1] so I think that this is the expected behavior and changing it may be an ABI breakage. I'm not advocating undoing the kernel "hack", but rather make it so that we add hs200 to DTs where it's actually supported instead of doing the same hack the kernel does. In that case, we wouldn't need the hack anymore. (well maybe it isn't a hack per-se, but for lack of more info on that, I call the kernel implementation this :) ) Let's keep in mind that the troublesome DT properties describe the capabilities of the MMC controller and the board, not the capabilities of the MMC storage device. As we know, eMMC devices provide automatic detection capabilities, to allow the host to determine its supported modes, and match them with the ones the host is configured to support. It's all described in the JEDEC standards. Having that in mind, I find the approach in the Linux kernel rather reasonable, because I highly doubt that some MMC controllers support, for example, HS400 without supporting DDR52, or HS400 without supporting DDR52. A reasonable approach for an MMC IP block is to make it capable of supporting all the speeds below its highest supported speed, to make itself capable of supporting more, if not all, MMC storage devices. In fact, I'll probably go ahead and submit a Linux kernel patch that updates the descriptions in the binding, to hopefully eliminate any ambiguities like these. I hope you agree.
Re: [PATCH 01/13] ti:keys Add EFI signature list
On 4/9/24 14:14, Andrew Davis wrote:
On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
On 4/8/24 23:33, Jonathan Humphreys wrote:
EFI signature list using TI dummy keys.
Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.
The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).
Andrew
Why should we create signed capsules which are already compromised by
publishing the private key?
Best regards
Heinrich
Best regards
Heinrich
Signed-off-by: Jonathan Humphreys
---
arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
diff --git a/arch/arm/mach-k3/keys/custMpk.esl
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};xRCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h
FIT image parameters question - kernel load address, entry point.
Hi List, My board - Armada 3720 Expressobin extended with marvell switch and couple of other network interfaces, running Linux 4.19 Our platform has 2GB RAM, TIM-1.0 WTMI-armada-17.10.5-7de3572 WTMI: system early-init DDR topology parameters: ddr type DDR3 ddr speedbin 12 bus width 16-bits cs num 2 cs[0] - group num0 cs[0] - bank num 8 cs[0] - capacity 1024MiB cs[1] - group num0 cs[1] - bank num 8 cs[1] - capacity 1024MiB SVC REV: 5, CPU VDD voltage: 1.143V DRAM windows: = WIN[0] - base addr 0x6000 WIN[0] - size 0x4000 WIN[1] - base addr 0xa000 WIN[1] - size 0x2000 === Recently I spent several days trying to figure out what kernel load address and entry point to use as FIT image parameters. I started by adding printk to arch/arm64/mm/mmu.c:436 and got kernel start address 0x8 when board was booted from /boot/Image I then put FIT image into memory 0x50 and applied bootm with a single argument - bootm 0x500 Uboot successfully verified signature but freeze after messages >Loading Kernel Image ... OK >Using Device Tree in place at 04f0, end > 04f05c7e > > Starting kernel ... Kernel is compiled with RELOCATABLE config on, Some uboot specialists make claim that the memory is corrupted, but there are no other running actors So I return to my questions : Question 1. What is the magic, how load address and entry could be figured ? I tried more then 20 different addresses to no success, except thet some addresses immediately reset board Question 2. What should I choose as load fdt address? Question 3. On what address FIT image should be loaded, I load it with tftp command? Question 4. What form of bootm command to use; cause bootm may accept 3 parameters (fortunately IU do not have initrd) Question 5. I cconfused by DRAM windows base adddr & size that uboot reports (see 30 lines above) Should I just ignore it, cause higher up I see 2 banks of 1GB each and I am OK with It.
[PATCH 1/1] reboot-mode: must depend on CONFIG_DM_RTC
Reading the boot mode from RTC memory requires a real time clock.
Add the missing Kconfig dependency.
Fixes: c74675bd904b ("reboot-mode: read the boot mode from RTC memory")
Signed-off-by: Heinrich Schuchardt
---
drivers/reboot-mode/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reboot-mode/Kconfig b/drivers/reboot-mode/Kconfig
index d57baacc93d..bb518935188 100644
--- a/drivers/reboot-mode/Kconfig
+++ b/drivers/reboot-mode/Kconfig
@@ -24,6 +24,7 @@ config DM_REBOOT_MODE_GPIO
config DM_REBOOT_MODE_RTC
bool "Use RTC as reboot mode backend"
+ depends on DM_RTC
depends on DM_REBOOT_MODE
help
Use RTC non volatile memory to control the reboot mode. This
will allow users to boot
--
2.43.0
[PATCH 1/1] fs: fat: convert change month correctly
The month is stored in 5 - 8. We need to shift it by 5 bits.
Cf. Microsoft FAT Specification, 2005-08-30
Fixes: 13c11c665320 ("fs: fat: add file attributes to struct fs_dirent")
Signed-off-by: Heinrich Schuchardt
---
fs/fat/fat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 14e53cf2d5a..2dd9d4e72dc 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1254,7 +1254,7 @@ out:
static void __maybe_unused fat2rtc(u16 date, u16 time, struct rtc_time *tm)
{
tm->tm_mday = date & 0x1f;
- tm->tm_mon = (date & 0x1e0) >> 4;
+ tm->tm_mon = (date & 0x1e0) >> 5;
tm->tm_year = (date >> 9) + 1980;
tm->tm_sec = (time & 0x1f) << 1;
--
2.43.0
[PATCH 7/7] dts: sdm845-db845c-u-boot: adjust MMC clocks
Remove the reference to the xo clock which is on the unsupported rpmhcc
clock controller. It isn't needed for MMC functionality.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/sdm845-db845c-u-boot.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi
b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
index 906f9faa5451..9e4533e603c5 100644
--- a/arch/arm/dts/sdm845-db845c-u-boot.dtsi
+++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
@@ -6,4 +6,11 @@
*/
_3p3v_dual {
regulator-always-on;
};
+
+_2 {
+ /* Remove the unsupported rpmhcc xo clock reference */
+ clocks = < GCC_SDCC2_AHB_CLK>,
+< GCC_SDCC2_APPS_CLK>;
+ clock-names = "iface", "core";
+};
--
2.44.0
[PATCH 6/7] pinctrl: qcom: sdm845: add special pin names
Adjust sdm845_get_pin_name() to return the correct names for the special
pins. This fixes a non-fatal -ENOSYS error when probing MMC.
Signed-off-by: Caleb Connolly
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 459a4329ec80..c1e5cc01fded 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
@@ -65,9 +65,20 @@ static const char *sdm845_get_function_name(struct udevice
*dev,
static const char *sdm845_get_pin_name(struct udevice *dev,
unsigned int selector)
{
- snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
+ static const char *special_pins_names[] = {
+ "ufs_reset",
+ "sdc2_clk",
+ "sdc2_cmd",
+ "sdc2_data",
+ };
+
+ if (selector >= 150 && selector <= 154)
+ snprintf(pin_name, MAX_PIN_NAME_LEN,
special_pins_names[selector - 150]);
+ else
+ snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
+
return pin_name;
}
static unsigned int sdm845_get_function_mux(__maybe_unused unsigned int pin,
--
2.44.0
[PATCH 5/7] clk/qcom: sdm845: enable SDCC2 core clock
Allow setting the clock rate for the SD card core clock. This is
required for SD card support on SDM845 devices.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-qcom.h | 1 +
drivers/clk/qcom/clock-sdm845.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
index cc170d8e3f9e..f6445c8f566f 100644
--- a/drivers/clk/qcom/clock-qcom.h
+++ b/drivers/clk/qcom/clock-qcom.h
@@ -12,8 +12,9 @@
#define CFG_CLK_SRC_GPLL0_AUX2 (2 << 8)
#define CFG_CLK_SRC_GPLL9 (2 << 8)
#define CFG_CLK_SRC_GPLL6 (4 << 8)
#define CFG_CLK_SRC_GPLL7 (3 << 8)
+#define CFG_CLK_SRC_GPLL4 (5 << 8)
#define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
#define CFG_CLK_SRC_MASK (7 << 8)
#define RCG_CFG_REG0x4
diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index e9c61eb480de..782df7da8444 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -23,8 +23,9 @@
#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf018
#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf030
#define USB3_PRIM_PHY_AUX_CMD_RCGR 0xf05c
+#define SDCC2_APPS_CLK_CMD_RCGR 0x1400c
static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
@@ -43,8 +44,19 @@ static const struct freq_tbl
ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
{ }
};
+static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
+ F(40, CFG_CLK_SRC_CXO, 12, 1, 4),
+ F(960, CFG_CLK_SRC_CXO, 2, 0, 0),
+ F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+ F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
+ F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
+ F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
+ F(20150, CFG_CLK_SRC_GPLL4, 4, 0, 0),
+ { }
+};
+
static ulong sdm845_clk_set_rate(struct clk *clk, ulong rate)
{
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
const struct freq_tbl *freq;
@@ -54,8 +66,13 @@ static ulong sdm845_clk_set_rate(struct clk *clk, ulong rate)
freq = qcom_find_freq(ftbl_gcc_qupv3_wrap0_s0_clk_src, rate);
clk_rcg_set_rate_mnd(priv->base, SE9_UART_APPS_CMD_RCGR,
freq->pre_div, freq->m, freq->n,
freq->src, 16);
return freq->freq;
+ case GCC_SDCC2_APPS_CLK:
+ freq = qcom_find_freq(ftbl_gcc_sdcc2_apps_clk_src, rate);
+ clk_rcg_set_rate_mnd(priv->base, SDCC2_APPS_CLK_CMD_RCGR,
+freq->pre_div, freq->m, freq->n,
freq->src, 8);
+ return freq->freq;
default:
return 0;
}
}
--
2.44.0
[PATCH 4/7] mmc: msm_sdhci: use a more sensible default clock rate
We currently default to the lowest rate but this actually doesn't work
on most platforms. Default to the HS400 speed instead which is most
common on Qualcomm platforms.
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index ea5d6b4cbbee..2144772ac325 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -61,9 +61,9 @@ static int msm_sdc_clk_init(struct udevice *dev)
const char *clk_name;
ret = ofnode_read_u32(node, "clock-frequency", (uint *)(_rate));
if (ret)
- clk_rate = 40;
+ clk_rate = 20150;
ret = clk_get_bulk(dev, >clks);
if (ret) {
log_warning("Couldn't get mmc clocks: %d\n", ret);
--
2.44.0
[PATCH 3/7] mmc: msm_sdhci: print core version
This is useful for debugging.
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 5689b4765122..ea5d6b4cbbee 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -172,8 +172,10 @@ static int msm_sdc_probe(struct udevice *dev)
core_major >>= SDCC_VERSION_MAJOR_SHIFT;
core_minor = core_version & SDCC_VERSION_MINOR_MASK;
+ log_debug("SDCC version %d.%d\n", core_major, core_minor);
+
/*
* Support for some capabilities is not advertised by newer
* controller versions and must be explicitly enabled.
*/
--
2.44.0
[PATCH 2/7] mmc: msm_sdhci: use modern DT handling
using fdtdec_* functions is incompatible with OF_LIVE and generally
offers a less friendly interface. Update to use dev_read_* functions
instead.
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index f23d425144ef..5689b4765122 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -205,9 +205,9 @@ static int msm_sdc_remove(struct udevice *dev)
var_info = (void *)dev_get_driver_data(dev);
/* Disable host-controller mode */
- if (!var_info->mci_removed)
+ if (!var_info->mci_removed && priv->base)
writel(0, priv->base + SDCC_MCI_HC_MODE);
clk_release_bulk(>clks);
@@ -215,23 +215,33 @@ static int msm_sdc_remove(struct udevice *dev)
}
static int msm_of_to_plat(struct udevice *dev)
{
- struct udevice *parent = dev->parent;
struct msm_sdhc *priv = dev_get_priv(dev);
+ const struct msm_sdhc_variant_info *var_info;
struct sdhci_host *host = >host;
- int node = dev_of_offset(dev);
+ int ret;
+
+ var_info = (void*)dev_get_driver_data(dev);
host->name = strdup(dev->name);
host->ioaddr = dev_read_addr_ptr(dev);
- host->bus_width = fdtdec_get_int(gd->fdt_blob, node, "bus-width", 4);
- host->index = fdtdec_get_uint(gd->fdt_blob, node, "index", 0);
- priv->base = (void *)fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
- dev_of_offset(parent), node, "reg", 1, NULL, false);
- if (priv->base == (void *)FDT_ADDR_T_NONE ||
- host->ioaddr == (void *)FDT_ADDR_T_NONE)
+ ret = dev_read_u32(dev, "bus-width", >bus_width);
+ if (ret)
+ host->bus_width = 4;
+ ret = dev_read_u32(dev, "index", >index);
+ if (ret)
+ host->index = 0;
+ priv->base = dev_read_addr_index_ptr(dev, 1);
+
+ if (!host->ioaddr)
return -EINVAL;
+ if (!var_info->mci_removed && !priv->base) {
+ printf("msm_sdhci: MCI base address not found\n");
+ return -EINVAL;
+ }
+
return 0;
}
static int msm_sdc_bind(struct udevice *dev)
--
2.44.0
[PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5
The V4 and V5 controllers have quite varied register layouts. Inherit
the register offsets and naming from the Linux driver. More version
specific offsets can be inherited from Linux as needed.
Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 059cb3da77c5..f23d425144ef 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -32,11 +32,8 @@
#define SDCC_MCI_STATUS2 0x6C
#define SDCC_MCI_STATUS2_MCI_ACT 0x1
#define SDCC_MCI_HC_MODE 0x78
-/* Non standard (?) SDHCI register */
-#define SDHCI_VENDOR_SPEC_CAPABILITIES0 0x11c
-
struct msm_sdhc_plat {
struct mmc_config cfg;
struct mmc mmc;
};
@@ -48,8 +45,10 @@ struct msm_sdhc {
};
struct msm_sdhc_variant_info {
bool mci_removed;
+
+ u32 core_vendor_spec_capabilities0;
};
DECLARE_GLOBAL_DATA_PTR;
@@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
*/
if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
- writel(caps, host->ioaddr + SDHCI_VENDOR_SPEC_CAPABILITIES0);
+ writel(caps, host->ioaddr +
var_info->core_vendor_spec_capabilities0);
}
ret = mmc_of_parse(dev, >cfg);
if (ret)
@@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
}
static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
.mci_removed = false,
+
+ .core_vendor_spec_capabilities0 = 0x21c,
};
static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
.mci_removed = true,
+
+ .core_vendor_spec_capabilities0 = 0x11c,
};
static const struct udevice_id msm_mmc_ids[] = {
{ .compatible = "qcom,sdhci-msm-v4", .data = (ulong)_sdhc_mci_var },
--
2.44.0
[PATCH 0/7] qcom: mmc fixes and sdm845 support
This series does some long overdue cleanup to the msm_sdhci driver, fixes v5 support, and adds the necessary clock configuration to get the sdcard up and running on the RB3. --- Caleb Connolly (7): mmc: msm_sdhci: correct vendor_spec_cap0 register for v5 mmc: msm_sdhci: use modern DT handling mmc: msm_sdhci: print core version mmc: msm_sdhci: use a more sensible default clock rate clk/qcom: sdm845: enable SDCC2 core clock pinctrl: qcom: sdm845: add special pin names dts: sdm845-db845c-u-boot: adjust MMC clocks arch/arm/dts/sdm845-db845c-u-boot.dtsi | 7 ++ drivers/clk/qcom/clock-qcom.h | 1 + drivers/clk/qcom/clock-sdm845.c| 17 ++ drivers/mmc/msm_sdhci.c| 43 +++--- drivers/pinctrl/qcom/pinctrl-sdm845.c | 13 +- 5 files changed, 66 insertions(+), 15 deletions(-) --- change-id: 20240409-b4-qcom-mmc-fixes-d30782746f4a base-commit: b40edaf6383b1494222ea9c043d7c1716d4d118f // Caleb (they/them)
Re: [PATCH v2 05/14] rockchip: rk3308: Enable random generator
Hello Quentin,
On 2024-04-09 17:45, Quentin Schulz wrote:
Hi Jonas,
On 4/8/24 20:14, Jonas Karlman wrote:
The RK3308 SoC contain a crypto engine block that can generate random
numbers.
Add rng node to soc u-boot.dtsi and enable Kconfig options to take
advantage of the random generator.
Signed-off-by: Jonas Karlman
---
v2: No change
---
arch/arm/dts/rk3308-u-boot.dtsi | 5 +
arch/arm/mach-rockchip/Kconfig | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/dts/rk3308-u-boot.dtsi
b/arch/arm/dts/rk3308-u-boot.dtsi
index 436f66d1b87d..fa31c838d34d 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -26,6 +26,11 @@
reg = <0x07 0x10>;
};
};
+
+ rng: rng@ff2f {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xff2f 0x0 0x4000>;
Downstream says something different:
https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3308.dtsi#L1007-L1020
I couldn't quickly find the TRM for the RK3308 so cannot check myself
:/
The RK3308 TRM can be found on the link below. BTW, there's also
a rather interesting PDF file that describes a node shrink of the
RK3308, the so-called S-version chip.
https://dl.radxa.com/rockpis/docs/hw/datasheets/
Also seems to be missing clocks and resets?
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi Quentin, On 2024-04-09 18:02, Quentin Schulz wrote: > Hi Jonas, > > On 4/9/24 17:58, Jonas Karlman wrote: >> Hi Quentin, >> >> On 2024-04-09 17:27, Quentin Schulz wrote: >>> Hi Jonas, >>> >>> On 4/8/24 23:06, Jonas Karlman wrote: eMMC nodes in linux device tree files typically only contain a mmc-hs400 prop to signal support for both HS400 and HS200. However, U-Boot require an explicit mmc-hs200 prop to signal support for the HS200 mode. > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled using a mmc-hs400 prop. >>> >>> Technically speaking, the DT binding should be the one and only source >>> of truth and should be implementation-agnostic. >>> >>> There it says: >>> """ >>> mmc-hs400-1_2v: >>> $ref: /schemas/types.yaml#/definitions/flag >>> description: >>> eMMC HS400 mode (1.2V I/O) is supported. >>> >>> mmc-hs400-1_8v: >>> $ref: /schemas/types.yaml#/definitions/flag >>> description: >>> eMMC HS400 mode (1.8V I/O) is supported. >>> """ >>> >>> So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it >>> makes sense. >>> >>> The point of the DT/DT binding is to be system-agnostic and >>> representative of the **HW** implementation. At least that's what the DT >>> people want it to be. >>> >>> If the eMMC standard doesn't allow to have HS400 without HS200, then I >>> think this change is acceptable as is, because it is the reality of the >>> HW standard. Couldn't find this implied in the standard though (but I >>> just skimmed through). >>> >>> It's also quite surprising, as it's not because the eMMC works with >>> HS400 that it necessarily does with HS200 or that it's desired (EMI, >>> signal integrity/stability, etc...)? >>> >>> Now, it wouldn't be the first time U-Boot follows whatever is done in >>> Linux, so... up to you/the maintainers :) >> >> Agree that implying HS200 does not fully make sense, however it was part >> of the original Linux binding when HS400 was added in v3.16-rc1 [1] so I >> think that this is the expected behavior and changing it may be an ABI >> breakage. >> > > I'm not advocating undoing the kernel "hack", but rather make it so that > we add hs200 to DTs where it's actually supported instead of doing the > same hack the kernel does. In that case, we wouldn't need the hack anymore. I will add a patch that adds the missing mmc-hs200 props to affected rk3588 boards, nanopc-t4 and quartzpro64 in v2 of the "rockchip: rk35xx: Miscellaneous fixes and updates" series. Also turns out the issue with those boards was because of my other "mmc: rockchip_sdhci: Revert 4 blocks PIO mode read limit for RK35xx" patch, so will need to rework that revert some more before posting a v2 of that patch. For this patch it is fully up to the maintainers if U-Boot wants to mimic Linux kernel or not. Regards, Jonas > > (well maybe it isn't a hack per-se, but for lack of more info on that, I > call the kernel implementation this :) ) > > Cheers, > Quentin
Re: [PATCH v2 05/14] rockchip: rk3308: Enable random generator
Hi Quentin,
On 2024-04-09 17:45, Quentin Schulz wrote:
> Hi Jonas,
>
> On 4/8/24 20:14, Jonas Karlman wrote:
>> The RK3308 SoC contain a crypto engine block that can generate random
>> numbers.
>>
>> Add rng node to soc u-boot.dtsi and enable Kconfig options to take
>> advantage of the random generator.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> v2: No change
>> ---
>> arch/arm/dts/rk3308-u-boot.dtsi | 5 +
>> arch/arm/mach-rockchip/Kconfig | 2 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3308-u-boot.dtsi
>> b/arch/arm/dts/rk3308-u-boot.dtsi
>> index 436f66d1b87d..fa31c838d34d 100644
>> --- a/arch/arm/dts/rk3308-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3308-u-boot.dtsi
>> @@ -26,6 +26,11 @@
>> reg = <0x07 0x10>;
>> };
>> };
>> +
>> +rng: rng@ff2f {
>> +compatible = "rockchip,cryptov2-rng";
>> +reg = <0x0 0xff2f 0x0 0x4000>;
>
> Downstream says something different:
>
> https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3308.dtsi#L1007-L1020
>
> I couldn't quickly find the TRM for the RK3308 so cannot check myself :/
RK3308TRM Part1 mention following under address mapping:
ff2f CRYPTO 64K
And RK3308TRM Part2 mention following under crypto regs:
CRYPTO_CLK_CTL 0x W 0x0001 Clock Control Register
[...]
CRYPTO_RNG_CTL 0x0400 W 0x000c RNG Control Register
[...]
CRYPTO_SRAM_ADDR 0x1000 W 0x SRAM Base Address
And the U-Boot driver:
/* start of CRYPTO V2 register define */
#define CRYPTO_V2_RNG_CTL 0x0400
So 0xff2f should be correct for the crypto block on RK3308. And the
rng cmd also gives me proper random numbers on my Rock Pi S board.
>
> Also seems to be missing clocks and resets?
Yeah, this is just a minimal node to get the rng driver in U-Boot
working and like most other clocks they are enabled and running at an
acceptable rate by default.
Regards,
Jonas
>
> Cheers,
> Quentin
Re: [PATCH v2 04/14] rockchip: rk3308: Generate ethaddr based on cpu id
Hi Quentin,
On 2024-04-09 17:41, Quentin Schulz wrote:
> Hi Jonas,
>
> On 4/8/24 20:14, Jonas Karlman wrote:
>> Like other Rockchip SoCs the RK3308 has cpu id programmed into OTP
>> memory. The rockchip_otp driver already support the RK3308 variant.
>> However, the device tree is missing a node to enable use of OTP.
>>
>> Add the missing otp node to soc u-boot.dtsi, enable the rockchip_otp
>> driver and enable use of misc_init_r() to set ethaddr based on cpu id.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> v2: Add clocks and resets props
>> ---
>> arch/arm/dts/rk3308-u-boot.dtsi | 16
>> arch/arm/mach-rockchip/Kconfig | 3 +++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3308-u-boot.dtsi
>> b/arch/arm/dts/rk3308-u-boot.dtsi
>> index db2c20a7055e..436f66d1b87d 100644
>> --- a/arch/arm/dts/rk3308-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3308-u-boot.dtsi
>> @@ -10,6 +10,22 @@
>> mmc0 =
>> mmc1 =
>> };
>> +
>> +otp: nvmem@ff21 {
>> +compatible = "rockchip,rk3308-otp";
>> +reg = <0x0 0xff21 0x0 0x4000>;
>> +clocks = < SCLK_OTP_USR>, < PCLK_OTP_NS>,
>> + < PCLK_OTP_PHY>;
>> +clock-names = "otp", "apb_pclk", "phy";
>> +resets = < SRST_OTP_PHY>;
>> +reset-names = "phy";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +cpu_id: id@7 {
>> +reg = <0x07 0x10>;
>> +};
>> +};
>
> Any plan upstreaming this to the Linux kernel so we can avoid
> maintaining it in U-Boot?
Yes, I want to get this and some other fixes sent upstream. Will
probably not happen until I have finished up v2 of my other U-Boot
rk3xxx series.
Regards,
Jonas
>
> It seems supported (the compatible is matched by a driver and there's a
> DT binding already).
>
> Reviewed-by: Quentin Schulz
>
> Cheers,
> Quentin
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi Jonas, On 4/9/24 17:58, Jonas Karlman wrote: Hi Quentin, On 2024-04-09 17:27, Quentin Schulz wrote: Hi Jonas, On 4/8/24 23:06, Jonas Karlman wrote: eMMC nodes in linux device tree files typically only contain a mmc-hs400 prop to signal support for both HS400 and HS200. However, U-Boot require an explicit mmc-hs200 prop to signal support for the HS200 mode. > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled using a mmc-hs400 prop. Technically speaking, the DT binding should be the one and only source of truth and should be implementation-agnostic. There it says: """ mmc-hs400-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.2V I/O) is supported. mmc-hs400-1_8v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.8V I/O) is supported. """ So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it makes sense. The point of the DT/DT binding is to be system-agnostic and representative of the **HW** implementation. At least that's what the DT people want it to be. If the eMMC standard doesn't allow to have HS400 without HS200, then I think this change is acceptable as is, because it is the reality of the HW standard. Couldn't find this implied in the standard though (but I just skimmed through). It's also quite surprising, as it's not because the eMMC works with HS400 that it necessarily does with HS200 or that it's desired (EMI, signal integrity/stability, etc...)? Now, it wouldn't be the first time U-Boot follows whatever is done in Linux, so... up to you/the maintainers :) Agree that implying HS200 does not fully make sense, however it was part of the original Linux binding when HS400 was added in v3.16-rc1 [1] so I think that this is the expected behavior and changing it may be an ABI breakage. I'm not advocating undoing the kernel "hack", but rather make it so that we add hs200 to DTs where it's actually supported instead of doing the same hack the kernel does. In that case, we wouldn't need the hack anymore. (well maybe it isn't a hack per-se, but for lack of more info on that, I call the kernel implementation this :) ) Cheers, Quentin
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi Quentin, On 2024-04-09 17:27, Quentin Schulz wrote: > Hi Jonas, > > On 4/8/24 23:06, Jonas Karlman wrote: >> eMMC nodes in linux device tree files typically only contain a mmc-hs400 >> prop to signal support for both HS400 and HS200. However, U-Boot require >> an explicit mmc-hs200 prop to signal support for the HS200 mode. >> > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled >> using a mmc-hs400 prop. >> > > Technically speaking, the DT binding should be the one and only source > of truth and should be implementation-agnostic. > > There it says: > """ >mmc-hs400-1_2v: > $ref: /schemas/types.yaml#/definitions/flag > description: >eMMC HS400 mode (1.2V I/O) is supported. > >mmc-hs400-1_8v: > $ref: /schemas/types.yaml#/definitions/flag > description: >eMMC HS400 mode (1.8V I/O) is supported. > """ > > So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it > makes sense. > > The point of the DT/DT binding is to be system-agnostic and > representative of the **HW** implementation. At least that's what the DT > people want it to be. > > If the eMMC standard doesn't allow to have HS400 without HS200, then I > think this change is acceptable as is, because it is the reality of the > HW standard. Couldn't find this implied in the standard though (but I > just skimmed through). > > It's also quite surprising, as it's not because the eMMC works with > HS400 that it necessarily does with HS200 or that it's desired (EMI, > signal integrity/stability, etc...)? > > Now, it wouldn't be the first time U-Boot follows whatever is done in > Linux, so... up to you/the maintainers :) Agree that implying HS200 does not fully make sense, however it was part of the original Linux binding when HS400 was added in v3.16-rc1 [1] so I think that this is the expected behavior and changing it may be an ABI breakage. The original Linux commit [1] mention: "Specially, if host can support HS400, it means that host can also support HS200." [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c373eb489b27b268c9b8c267b212d10864bc8cdd Regards, Jonas > > Reviewed-by: Quentin Schulz > > Cheers, > Quentin
Re: [PATCH v2 05/14] rockchip: rk3308: Enable random generator
Hi Jonas,
On 4/8/24 20:14, Jonas Karlman wrote:
The RK3308 SoC contain a crypto engine block that can generate random
numbers.
Add rng node to soc u-boot.dtsi and enable Kconfig options to take
advantage of the random generator.
Signed-off-by: Jonas Karlman
---
v2: No change
---
arch/arm/dts/rk3308-u-boot.dtsi | 5 +
arch/arm/mach-rockchip/Kconfig | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/dts/rk3308-u-boot.dtsi b/arch/arm/dts/rk3308-u-boot.dtsi
index 436f66d1b87d..fa31c838d34d 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -26,6 +26,11 @@
reg = <0x07 0x10>;
};
};
+
+ rng: rng@ff2f {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xff2f 0x0 0x4000>;
Downstream says something different:
https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3308.dtsi#L1007-L1020
I couldn't quickly find the TRM for the RK3308 so cannot check myself :/
Also seems to be missing clocks and resets?
Cheers,
Quentin
Re: [PATCH v2 04/14] rockchip: rk3308: Generate ethaddr based on cpu id
Hi Jonas,
On 4/8/24 20:14, Jonas Karlman wrote:
Like other Rockchip SoCs the RK3308 has cpu id programmed into OTP
memory. The rockchip_otp driver already support the RK3308 variant.
However, the device tree is missing a node to enable use of OTP.
Add the missing otp node to soc u-boot.dtsi, enable the rockchip_otp
driver and enable use of misc_init_r() to set ethaddr based on cpu id.
Signed-off-by: Jonas Karlman
---
v2: Add clocks and resets props
---
arch/arm/dts/rk3308-u-boot.dtsi | 16
arch/arm/mach-rockchip/Kconfig | 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/dts/rk3308-u-boot.dtsi b/arch/arm/dts/rk3308-u-boot.dtsi
index db2c20a7055e..436f66d1b87d 100644
--- a/arch/arm/dts/rk3308-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-u-boot.dtsi
@@ -10,6 +10,22 @@
mmc0 =
mmc1 =
};
+
+ otp: nvmem@ff21 {
+ compatible = "rockchip,rk3308-otp";
+ reg = <0x0 0xff21 0x0 0x4000>;
+ clocks = < SCLK_OTP_USR>, < PCLK_OTP_NS>,
+< PCLK_OTP_PHY>;
+ clock-names = "otp", "apb_pclk", "phy";
+ resets = < SRST_OTP_PHY>;
+ reset-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpu_id: id@7 {
+ reg = <0x07 0x10>;
+ };
+ };
Any plan upstreaming this to the Linux kernel so we can avoid
maintaining it in U-Boot?
It seems supported (the compatible is matched by a driver and there's a
DT binding already).
Reviewed-by: Quentin Schulz
Cheers,
Quentin
Re: [PATCH 1/2] mmc: Imply HS200 cap with mmc-hs400 prop to match linux
Hi Jonas, On 4/8/24 23:06, Jonas Karlman wrote: eMMC nodes in linux device tree files typically only contain a mmc-hs400 prop to signal support for both HS400 and HS200. However, U-Boot require an explicit mmc-hs200 prop to signal support for the HS200 mode. > Fix this by follow linux and imply HS200 cap when HS400 cap is signaled using a mmc-hs400 prop. Technically speaking, the DT binding should be the one and only source of truth and should be implementation-agnostic. There it says: """ mmc-hs400-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.2V I/O) is supported. mmc-hs400-1_8v: $ref: /schemas/types.yaml#/definitions/flag description: eMMC HS400 mode (1.8V I/O) is supported. """ So I'd say, the DTs should be fixed to add mmc-hs200 as well wherever it makes sense. The point of the DT/DT binding is to be system-agnostic and representative of the **HW** implementation. At least that's what the DT people want it to be. If the eMMC standard doesn't allow to have HS400 without HS200, then I think this change is acceptable as is, because it is the reality of the HW standard. Couldn't find this implied in the standard though (but I just skimmed through). It's also quite surprising, as it's not because the eMMC works with HS400 that it necessarily does with HS200 or that it's desired (EMI, signal integrity/stability, etc...)? Now, it wouldn't be the first time U-Boot follows whatever is done in Linux, so... up to you/the maintainers :) Reviewed-by: Quentin Schulz Cheers, Quentin
Re: [PATCH] MAINTAINERS: add Qualcomm mailing list
On 09/04/2024 17:02, Caleb Connolly wrote: Add the newly created u-boot-qcom mailing list to keep track of Qualcomm patches. Additionally, link to the U-Boot Snapdragon custodian tree. Signed-off-by: Caleb Connolly --- Cc: Neil Armstrong Cc: Sumit Garg Cc: u-boot@lists.denx.de --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0462ade4ac60..c0d2b5138fca 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -602,9 +602,11 @@ F: arch/arm/dts/am335x-sancloud* ARM SNAPDRAGON M:Caleb Connolly M:Neil Armstrong R:Sumit Garg +L: u-boot-q...@groups.io S:Maintained +T: git https://source.denx.de/u-boot/custodians/u-boot-snapdragon.git F:arch/arm/dts/msm8*.dtsi F:arch/arm/dts/pm8???.dtsi F:arch/arm/dts/pms405.dtsi F:arch/arm/dts/sdm845.dtsi Reviewed-by: Neil Armstrong
[PATCH v1 25/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index b38e816f888..7c0d1bab11a 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -12,7 +12,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
};
@@ -36,6 +36,10 @@
led {
compatible = "gpio-leds";
+ led-blue {
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 21/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 09cfe9bc246..d93359f967c 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -14,7 +14,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
};
@@ -61,6 +61,10 @@
led {
compatible = "gpio-leds";
+ led-blue {
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 20/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index edcbfee0fc7..09cfe9bc246 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -15,7 +15,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
};
@@ -59,10 +59,10 @@
};
led {
- red {
- label = "error";
+ compatible = "gpio-leds";
+
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 22/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ button-user-2 for fastboot mode activation.
Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 4d763bd3a2c..84920f53496 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -3,6 +3,7 @@
* Copyright : STMicroelectronics 2022
*/
+#include
#include "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -14,8 +15,22 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "u-boot-env";
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
};
led {
--
2.25.1
[PATCH v1 24/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 2abd512e297..b38e816f888 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -13,7 +13,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
};
@@ -34,10 +34,10 @@
};
led {
- red {
- label = "error";
+ compatible = "gpio-leds";
+
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 84920f53496..2abd512e297 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -37,7 +37,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 18/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ button-user-2 for fastboot mode activation.
Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index ef91088aa37..e6a452c9d8e 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "stm32mp15-u-boot.dtsi"
#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
@@ -16,8 +17,6 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
};
#if defined(CONFIG_STM32MP15X_STM32IMAGE) || defined(CONFIG_SPL)
@@ -43,6 +42,22 @@
};
#endif
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+ };
+
led {
red {
label = "error";
--
2.25.1
[PATCH v1 19/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index e6a452c9d8e..edcbfee0fc7 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -62,7 +62,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 17/25] ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 92153b2a657..f97debaa0e4 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -15,7 +15,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
@@ -64,6 +64,10 @@
};
led {
+ led-blue {
+ /delete-property/label;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 16/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index ee9b51d42b7..92153b2a657 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -16,7 +16,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
};
@@ -64,10 +64,8 @@
};
led {
- red {
- label = "error";
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 15/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 6bf6136c5fd..ee9b51d42b7 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -67,7 +67,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 14/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index a16358266a2..6bf6136c5fd 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "stm32mp15-u-boot.dtsi"
#include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
@@ -18,8 +19,6 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
};
#if defined(CONFIG_STM32MP15X_STM32IMAGE) || defined(CONFIG_SPL)
@@ -48,6 +47,22 @@
};
#endif
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+ };
+
led {
red {
label = "error";
--
2.25.1
[PATCH v1 11/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 5d49b09c35d..8760d6c7d93 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -39,7 +39,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 12/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 8760d6c7d93..e61814fd66e 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -14,7 +14,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
};
@@ -36,10 +36,8 @@
};
led {
- red {
- label = "error";
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 10/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 20728f27ee1..5d49b09c35d 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -3,6 +3,7 @@
* Copyright : STMicroelectronics 2022
*/
+#include
#include "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -16,8 +17,22 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
};
led {
--
2.25.1
[PATCH v1 13/25] ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index e61814fd66e..a5158fec7ef 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -13,7 +13,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
@@ -36,6 +36,10 @@
};
led {
+ led-blue {
+ /delete-property/label;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 09/25] ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot
Remove "color" property from led-red node which is not supported
by U-Boot.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index 8f42735609a..f004e9840a2 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -35,7 +35,6 @@
};
led-red {
- color = ;
gpios = < 13 GPIO_ACTIVE_LOW>;
};
};
--
2.25.1
[PATCH v1 05/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp13_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index db09e63100e..caaabf39ef3 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -52,6 +52,8 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=-1 CONFIG_ENV_MMC_USE_DT=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 06/25] board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()
Instead of using gpio directly to detect key pressed on button
dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS.
Signed-off-by: Patrice Chotard
---
board/st/stm32mp1/stm32mp1.c | 68 +---
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index a17c314daeb..82f7d4ff4ea 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -38,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -150,45 +152,55 @@ int checkboard(void)
static void board_key_check(void)
{
- ofnode node;
- struct gpio_desc gpio;
+ struct udevice *button1 = NULL, *button2 = NULL;
enum forced_boot_mode boot_mode = BOOT_NORMAL;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_BUTTON))
+ return;
if (!IS_ENABLED(CONFIG_FASTBOOT) && !IS_ENABLED(CONFIG_CMD_STM32PROG))
return;
- node = ofnode_path("/config");
- if (!ofnode_valid(node)) {
- log_debug("no /config node?\n");
+ if (IS_ENABLED(CONFIG_CMD_STM32PROG))
+ button_get_by_label("User-1", );
+
+ if (IS_ENABLED(CONFIG_FASTBOOT))
+ button_get_by_label("User-2", );
+
+ if (!button1 && !button2)
return;
- }
- if (IS_ENABLED(CONFIG_FASTBOOT)) {
- if (gpio_request_by_name_nodev(node, "st,fastboot-gpios", 0,
- , GPIOD_IS_IN)) {
- log_debug("could not find a
/config/st,fastboot-gpios\n");
- } else {
- udelay(20);
- if (dm_gpio_get_value()) {
- log_notice("Fastboot key pressed, ");
- boot_mode = BOOT_FASTBOOT;
- }
- dm_gpio_free(NULL, );
+ if (button2) {
+ if (button_get_state(button2) == BUTTON_ON) {
+ log_notice("Fastboot key pressed, ");
+ boot_mode = BOOT_FASTBOOT;
}
+ /*
+* On some boards, same gpio is shared betwwen gpio-keys and
+* leds, remove the button device to free the gpio for led
+* usage
+*/
+ ret = device_remove(button2, DM_REMOVE_NORMAL);
+ if (ret)
+ log_err("Can't remove button2 (%d)\n", ret);
}
- if (IS_ENABLED(CONFIG_CMD_STM32PROG)) {
- if (gpio_request_by_name_nodev(node, "st,stm32prog-gpios", 0,
- , GPIOD_IS_IN)) {
- log_debug("could not find a
/config/st,stm32prog-gpios\n");
- } else {
- udelay(20);
- if (dm_gpio_get_value()) {
- log_notice("STM32Programmer key pressed, ");
- boot_mode = BOOT_STM32PROG;
- }
- dm_gpio_free(NULL, );
+
+ if (button1) {
+ if (button_get_state(button1) == BUTTON_ON) {
+ log_notice("STM32Programmer key pressed, ");
+ boot_mode = BOOT_STM32PROG;
}
+ /*
+* On some boards, same gpio is shared betwwen gpio-keys and
+* leds, remove the button device to free the gpio for led
+* usage
+*/
+ ret = device_remove(button1, DM_REMOVE_NORMAL);
+ if (ret)
+ log_err("Can't remove button1 (%d)\n", ret);
}
+
if (boot_mode != BOOT_NORMAL) {
log_notice("entering download mode...\n");
clrsetbits_le32(TAMP_BOOT_CONTEXT,
--
2.25.1
[PATCH v1 07/25] ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ update button-user's label (defined in kernel DT) to match label
requested in board_key_check() for fastboot mode activation.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index ba0c02489d1..e64ded13462 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -16,6 +16,19 @@
u-boot,mmc-env-partition = "u-boot-env";
};
+ gpio-keys {
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user {
+ /* update label to match the label requested in
board_key_check() */
+ label = "User-2";
+ };
+ };
+
leds {
led-red {
color = ;
--
2.25.1
[PATCH v1 08/25] ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from led-red and
led-blue led's node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index e64ded13462..8f42735609a 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -30,10 +30,13 @@
};
leds {
+ led-blue {
+ /delete-property/default-state;
+ };
+
led-red {
color = ;
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
};
};
};
--
2.25.1
[PATCH v1 03/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_basic_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 005f1d55f80..2e22bf86000 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -97,6 +97,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0xC000 -- 2.25.1
[PATCH v1 04/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_trusted_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 84b0854b557..74deaaba2e4 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -70,6 +70,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 02/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index 3302b306996..ffe7512650e 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -69,6 +69,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 00/25] stm32mp: Fix keys & leds management
Adding FASTBOOT support for stm32mp13 shows issues when entering in fastboot mode using a dedicated key. On several STM32MP boards, same gpio is shared between key and led. Restore the fastboot/stm32prog activation using a dedicated key. Restore the led-blue which indicates U-Boot entering / exit. Make usage of BUTTON-UCLASS for key management on STM32MP1. Patrice Chotard (25): configs: stm32mp13: Enable FASTBOOT configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check() ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update u-boot,boot-led for stm32mp157a-dk1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 19 +- arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 34 +++--- arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 34 +++--- board/st/stm32mp1/stm32mp1.c | 68 +++ configs/stm32mp13_defconfig | 11 ++- configs/stm32mp15_basic_defconfig | 2 + configs/stm32mp15_defconfig | 2 + configs/stm32mp15_trusted_defconfig | 2 + 10 files changed, 173 insertions(+), 63 deletions(-) -- 2.25.1
[PATCH v1 01/25] configs: stm32mp13: Enable FASTBOOT
Enable FASTBOOT relative flags for stm32mp13_defconfig. Signed-off-by: Patrice Chotard --- configs/stm32mp13_defconfig | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index c893e272db9..db09e63100e 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -15,6 +15,7 @@ CONFIG_CMD_STM32PROG=y CONFIG_SYS_LOAD_ADDR=0xc200 CONFIG_SYS_MEMTEST_START=0xc000 CONFIG_SYS_MEMTEST_END=0xc400 +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_DISTRO_DEFAULTS=y @@ -53,6 +54,13 @@ CONFIG_SYS_MMC_ENV_DEV=-1 CONFIG_ENV_MMC_USE_DT=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0xc000 +CONFIG_FASTBOOT_BUF_SIZE=0x0200 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y CONFIG_GPIO_HOG=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_STM32F7=y @@ -92,7 +100,6 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y -CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_ERRNO_STR=y # CONFIG_LMB_USE_MAX_REGIONS is not set CONFIG_LMB_MEMORY_REGIONS=2 -- 2.25.1
[PATCH] MAINTAINERS: add Qualcomm mailing list
Add the newly created u-boot-qcom mailing list to keep track of Qualcomm patches. Additionally, link to the U-Boot Snapdragon custodian tree. Signed-off-by: Caleb Connolly --- Cc: Neil Armstrong Cc: Sumit Garg Cc: u-boot@lists.denx.de --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0462ade4ac60..c0d2b5138fca 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -602,9 +602,11 @@ F: arch/arm/dts/am335x-sancloud* ARM SNAPDRAGON M: Caleb Connolly M: Neil Armstrong R: Sumit Garg +L: u-boot-q...@groups.io S: Maintained +T: git https://source.denx.de/u-boot/custodians/u-boot-snapdragon.git F: arch/arm/dts/msm8*.dtsi F: arch/arm/dts/pm8???.dtsi F: arch/arm/dts/pms405.dtsi F: arch/arm/dts/sdm845.dtsi -- 2.44.0
[PATCH v3 1/2] dt-bindings: drop generic headers
Drop all the subsystem headers that are compatible with the headers in dts/upstream. Signed-off-by: Caleb Connolly --- include/dt-bindings/ata/ahci.h | 20 - include/dt-bindings/gpio/gpio.h| 42 -- include/dt-bindings/input/gpio-keys.h | 13 - include/dt-bindings/input/input.h | 17 - include/dt-bindings/input/linux-event-codes.h | 806 - include/dt-bindings/interrupt-controller/irq.h | 19 - include/dt-bindings/leds/common.h | 106 include/dt-bindings/mux/mux.h | 17 - include/dt-bindings/phy/phy.h | 26 - include/dt-bindings/pwm/pwm.h | 14 - include/dt-bindings/spmi/spmi.h| 10 - include/dt-bindings/thermal/thermal.h | 15 - include/dt-bindings/usb/pd.h | 88 --- 13 files changed, 1193 deletions(-) diff --git a/include/dt-bindings/ata/ahci.h b/include/dt-bindings/ata/ahci.h deleted file mode 100644 index b3f3b7cf9af8.. --- a/include/dt-bindings/ata/ahci.h +++ /dev/null @@ -1,20 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ -/* - * This header provides constants for most AHCI bindings. - */ - -#ifndef _DT_BINDINGS_ATA_AHCI_H -#define _DT_BINDINGS_ATA_AHCI_H - -/* Host Bus Adapter generic platform capabilities */ -#define HBA_SSS(1 << 27) -#define HBA_SMPS (1 << 28) - -/* Host Bus Adapter port-specific platform capabilities */ -#define HBA_PORT_HPCP (1 << 18) -#define HBA_PORT_MPSP (1 << 19) -#define HBA_PORT_CPD (1 << 20) -#define HBA_PORT_ESP (1 << 21) -#define HBA_PORT_FBSCP (1 << 22) - -#endif diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h deleted file mode 100644 index c029467e828b.. --- a/include/dt-bindings/gpio/gpio.h +++ /dev/null @@ -1,42 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * This header provides constants for most GPIO bindings. - * - * Most GPIO bindings include a flags cell as part of the GPIO specifier. - * In most cases, the format of the flags cell uses the standard values - * defined in this header. - */ - -#ifndef _DT_BINDINGS_GPIO_GPIO_H -#define _DT_BINDINGS_GPIO_GPIO_H - -/* Bit 0 express polarity */ -#define GPIO_ACTIVE_HIGH 0 -#define GPIO_ACTIVE_LOW 1 - -/* Bit 1 express single-endedness */ -#define GPIO_PUSH_PULL 0 -#define GPIO_SINGLE_ENDED 2 - -/* Bit 2 express Open drain or open source */ -#define GPIO_LINE_OPEN_SOURCE 0 -#define GPIO_LINE_OPEN_DRAIN 4 - -/* - * Open Drain/Collector is the combination of single-ended open drain interface. - * Open Source/Emitter is the combination of single-ended open source interface. - */ -#define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) -#define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE) - -/* Bit 3 express GPIO suspend/resume and reset persistence */ -#define GPIO_PERSISTENT 0 -#define GPIO_TRANSITORY 8 - -/* Bit 4 express pull up */ -#define GPIO_PULL_UP 16 - -/* Bit 5 express pull down */ -#define GPIO_PULL_DOWN 32 - -#endif diff --git a/include/dt-bindings/input/gpio-keys.h b/include/dt-bindings/input/gpio-keys.h deleted file mode 100644 index 8962df79e753.. --- a/include/dt-bindings/input/gpio-keys.h +++ /dev/null @@ -1,13 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * This header provides constants for gpio keys bindings. - */ - -#ifndef _DT_BINDINGS_GPIO_KEYS_H -#define _DT_BINDINGS_GPIO_KEYS_H - -#define EV_ACT_ANY 0x00/* asserted or deasserted */ -#define EV_ACT_ASSERTED0x01/* asserted */ -#define EV_ACT_DEASSERTED 0x02/* deasserted */ - -#endif /* _DT_BINDINGS_GPIO_KEYS_H */ diff --git a/include/dt-bindings/input/input.h b/include/dt-bindings/input/input.h deleted file mode 100644 index a21413324a3f.. --- a/include/dt-bindings/input/input.h +++ /dev/null @@ -1,17 +0,0 @@ -/* - * This header provides constants for most input bindings. - * - * Most input bindings include key code, matrix key code format. - * In most cases, key code and matrix key code format uses - * the standard values/macro defined in this header. - */ - -#ifndef _DT_BINDINGS_INPUT_INPUT_H -#define _DT_BINDINGS_INPUT_INPUT_H - -#include "linux-event-codes.h" - -#define MATRIX_KEY(row, col, code) \ - row) & 0xFF) << 24) | (((col) & 0xFF) << 16) | ((code) & 0x)) - -#endif /* _DT_BINDINGS_INPUT_INPUT_H */ diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h deleted file mode 100644 index 331458c0e710.. --- a/include/dt-bindings/input/linux-event-codes.h +++ /dev/null @@ -1,806 +0,0 @@ -/* - * Input event codes - * - **** IMPORTANT *** - * This file is not only included from C-code but also from devicetree source - * files. As such this file MUST only contain comments and defines. - * - * Copyright (c) 1999-2002 Vojtech Pavlik - * Copyright
[PATCH v3 2/2] dts: support building all dtb files for a specific vendor
This adjusts OF_UPSTREAM to behave more like the kernel by allowing for all the devicetree files for a given vendor to be compiled. This is useful for Qualcomm in particular as most boards are supported by a single U-Boot build just provided with a different DT. Signed-off-by: Caleb Connolly --- dts/Kconfig | 24 scripts/Makefile.dts | 13 + 2 files changed, 37 insertions(+) diff --git a/dts/Kconfig b/dts/Kconfig index b9b6367154ef..6883a000a052 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -100,8 +100,32 @@ config OF_UPSTREAM However, newer boards whose devicetree source files haven't landed in the dts/upstream subtree, they can override this option to have the DT build from existing U-Boot tree location instead. +config OF_UPSTREAM_BUILD_VENDOR + bool "Build all devicetree files for a particular vendor" + depends on OF_UPSTREAM + help + Enable building all devicetree files for a particular vendor. This + is useful for generic U-Boot configurations where many boards can + be supported with a single binary. + + This is only available for platforms using upstream devicetree. + +config OF_UPSTREAM_VENDOR + string "Vendor to build all upstream devicetree files for" + depends on OF_UPSTREAM_BUILD_VENDOR + default "qcom" if ARCH_SNAPDRAGON + default "rockchip" if ARCH_ROCKCHIP + default "amlogic" if ARCH_MESON + default "allwinner" if ARCH_SUNXI + default "mediatek" if ARCH_MEDIATEK + default "marvell" if ARCH_MVEBU || ARCH_KIRKWOOD + default "xilinx" if ARCH_VERSAL || ARCH_ZYNQ + default "nvidia" if ARCH_TEGRA + help + Select the vendor to build all devicetree files for. + choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 5e2429c6170c..790f3c508f19 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,3 +1,16 @@ # SPDX-License-Identifier: GPL-2.0+ dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) + +ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := $(srctree)/dts/upstream/src/arm64 +else +dt_dir := $(srctree)/dts/upstream/src/$(ARCH) +endif + +dtb-vendor_dts := $(patsubst %.dts,%.dtb,$(wildcard $(dt_dir)/$(subst ",,$(CONFIG_OF_UPSTREAM_VENDOR))/*.dts)) + +dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts)) + +endif -- 2.44.0
[PATCH v3 0/2] upstream DT compatibility
This is a subset of [1]. With more platform maintainers switching to OF_UPSTREAM I didn't want to get in the way (it has also proven more difficult than I hoped to remove only the fully compatible header files). This series removes only the dt-bindings headers which contain generic data like GPIO flags, input event codes, etc. It then implements support for building all DTBs for a vendor with OF_UPSTREAM_BUILD_VENDOR. This removes the need to maintain a set list of DTBs that can be built by U-Boot and opens up the possibility of new boards becoming supported "by default" just by landing their DT upstream. [1]: https://lore.kernel.org/u-boot/20240321-b4-upstream-dt-headers-v2-0-1eac0df87...@linaro.org --- Caleb Connolly (2): dt-bindings: drop generic headers dts: support building all dtb files for a specific vendor dts/Kconfig| 24 + include/dt-bindings/ata/ahci.h | 20 - include/dt-bindings/gpio/gpio.h| 42 -- include/dt-bindings/input/gpio-keys.h | 13 - include/dt-bindings/input/input.h | 17 - include/dt-bindings/input/linux-event-codes.h | 806 - include/dt-bindings/interrupt-controller/irq.h | 19 - include/dt-bindings/leds/common.h | 106 include/dt-bindings/mux/mux.h | 17 - include/dt-bindings/phy/phy.h | 26 - include/dt-bindings/pwm/pwm.h | 14 - include/dt-bindings/spmi/spmi.h| 10 - include/dt-bindings/thermal/thermal.h | 15 - include/dt-bindings/usb/pd.h | 88 --- scripts/Makefile.dts | 13 + 15 files changed, 37 insertions(+), 1193 deletions(-) --- change-id: 20240409-b4-of-upstream-build-vendor-dc74b4f72e9a base-commit: eb1aaf535683880a4ac3517fc568792fc20cfe3a // Caleb (they/them)
Re: [PATCH v3 1/1] fastboot: introduce 'oem board' subcommand
Hi Alexey, On 4/8/24 12:15, Alexey Romanov wrote: Currently, fastboot protocol in U-Boot has no opportunity to execute vendor custom code with verifed boot. This patch introduce new fastboot subcommand fastboot oem board:, which allow to run custom oem_board function. Default implementation is __weak. Vendor must redefine it in board/ folder with his own logic. For example, some vendors have their custom nand/emmc partition flashing or erasing. Here some typical command for such use cases: - flashing: $ fastboot stage bootloader.img $ fastboot oem board:write_bootloader - erasing: $ fastboot oem board:erase_env Signed-off-by: Alexey Romanov --- doc/android/fastboot.rst | 18 ++ drivers/fastboot/Kconfig | 7 +++ drivers/fastboot/fb_command.c | 30 ++ include/fastboot.h| 1 + 4 files changed, 56 insertions(+) diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst index 05d8f77759..2020590657 100644 --- a/doc/android/fastboot.rst +++ b/doc/android/fastboot.rst @@ -30,6 +30,7 @@ The following OEM commands are supported (if enabled): - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC - ``oem run`` - this executes an arbitrary U-Boot command - ``oem console`` - this dumps U-Boot console record buffer +- ``oem board`` - this executes an custom board function which is defined by vendor s/an/a/ +the vendor? (missing "the") Support for both eMMC and NAND devices is included. @@ -246,6 +247,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit code of the command you ran. +Running Custom Vendor Code +^^ + +U-Boot allows you to execute custom fastboot logic, which can be defined +in board/ files. It can still be used for production devices with verified +boot, because vendor define logic at compile time by overriding weak s/vendor define/the vendor defines/ Suggestion: Replace "by overriding weak implementation of fastboot_oem_board()" with "by implementing fastboot_oem_board()", the weak symbol is an implementation detail I don't think we need to keep in the documentation? +implementation of fastboot_oem_board() function. The attacker will +not able to execute his commands / code. For example, this can be useful +be able (missing be) s/his/custom/ or s/his/their/ +for custom flashing or erasing protocols:: + +$ fastboot stage bootloader.img +$ fastboot oem board:write_bootloader + +In this case, ``cmd_parameter`` argument of the function ``fastboot_oem_board()`` +will contain string "write_bootloader" and ``data`` argument is a pointer to +fastboot input buffer, which containing the contents of bootloader.img file. + Either -which (remove "which") s/which containing/which contains/ Cheers, Quentin
[PATCH 2/2] disk: expose partition type flags
GPT partition tables include two bytes worth of vendor defined
attributes, per partition. ChromeOS and Qualcomm both use these (with
different encoding!) to handle A/B slot switching with a retry counter.
Expose these via the disk_partition struct so that they can be parsed by
the relevant board code.
This will be used on Qualcomm boards to determine which slot we're
booting on so that we can flash capsule updates to the correct one.
Signed-off-by: Caleb Connolly
---
disk/part_efi.c | 1 +
include/part.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 4ce9243ef25c..d3ce4dd01dcd 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -292,8 +292,9 @@ int part_get_info_efi(struct blk_desc *desc, int part,
snprintf((char *)info->name, sizeof(info->name), "%s",
print_efiname(_pte[part - 1]));
strcpy((char *)info->type, "U-Boot");
info->bootable = get_bootable(_pte[part - 1]);
+ info->type_flags = gpt_pte[part -
1].attributes.fields.type_guid_specific;
if (CONFIG_IS_ENABLED(PARTITION_UUIDS)) {
uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b,
(char *)disk_partition_uuid(info),
UUID_STR_FORMAT_GUID);
diff --git a/include/part.h b/include/part.h
index 32ee40488563..afae51f1b933 100644
--- a/include/part.h
+++ b/include/part.h
@@ -68,8 +68,9 @@ struct disk_partition {
* PART_BOOTABLEthe MBR bootable flag is set
* PART_EFI_SYSTEM_PARTITIONthe partition is an EFI system partition
*/
int bootable;
+ u16 type_flags; /* top 16 bits of GPT partition attributes
*/
#if CONFIG_IS_ENABLED(PARTITION_UUIDS)
charuuid[UUID_STR_LEN + 1]; /* filesystem UUID as string, if exists
*/
#endif
#ifdef CONFIG_PARTITION_TYPE_GUID
--
2.44.0
[PATCH 0/2] qcom: capsule update prep (DFU scsi + GPT part type flags)
This series adds two missing features necessary for Capsule updates to work on Qualcomm platforms. It introduces a DFU SCSI backend, necessary to support capsule updates on devices with UFS storage. It also adjusts the partition framework to export the GPT vendor attribute bits for each partition. These bits are used on Qualcomm Android and IoT platforms to encode the A/B slot data. They are used on Chromebooks for roughly the same purpose but with an entirely incompatible encoding. --- Caleb Connolly (2): dfu: add scsi backend disk: expose partition type flags disk/part_efi.c| 1 + doc/usage/dfu.rst | 31 drivers/dfu/Kconfig| 7 + drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c | 5 +- drivers/dfu/dfu_scsi.c | 437 + include/dfu.h | 26 +++ include/part.h | 1 + 8 files changed, 508 insertions(+), 1 deletion(-) --- change-id: 20240409-b4-dfu-scsi-9d460ff99796 base-commit: a96a91644cdd9d58596908edc38b5d934d99fc34 Caleb Connolly
[PATCH 1/2] dfu: add scsi backend
This is extremely similar to the MMC backend, but there are some notable
differences.
Works with a DFU string like
scsi 4=u-boot-bin part 11
Where "4" is the SCSI dev number (sequential LUN across all SCSI devices)
and "11" is the partition number.
Signed-off-by: Caleb Connolly
---
doc/usage/dfu.rst | 31
drivers/dfu/Kconfig| 7 +
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 5 +-
drivers/dfu/dfu_scsi.c | 437 +
include/dfu.h | 26 +++
6 files changed, 506 insertions(+), 1 deletion(-)
diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index 8cc09c308d82..dc4f8d672f99 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -166,8 +166,38 @@ mmc
Please note that this means the user will be able to execute any
arbitrary commands just like in the u-boot's shell.
+scsi
+for UFS storage::
+
+dfu 0 scsi
+
+each element in *dfu_alt_info* being
+
+* raw raw access to SCSI LUN
+* part raw access to partition
+* fatfile in FAT partition
+* ext4 file in EXT4 partition
+* skip 0 0ignore flashed data
+* script 0 0 execute commands in shell
+
+with
+
+size
+is the size of the access area (hexadecimal without "0x")
+or 0 which means whole device
+partid
+is the GPT or DOS partition index.
+dev
+is the SCSI LU (Logical Unit) index (decimal only)
+
+A value of environment variable *dfu_alt_info* for UFS could be::
+
+u-boot part 4;bl2 raw 0x1e 0x1d
+
+See mmc section above for details on the skip and script types.
+
nand
raw slc nand device::
dfu 0 nand
@@ -277,8 +307,9 @@ alternate list separated by '&' with the same format for
each ::
mmc =;;
nand =;;
ram =;;
+scsi =;;
sf =;;
mtd =;;
virt =;;
diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
index 0360d9da1427..158c660e6c4e 100644
--- a/drivers/dfu/Kconfig
+++ b/drivers/dfu/Kconfig
@@ -86,8 +86,15 @@ config DFU_VIRT
This option enables using DFU to read and write to VIRTUAL device
used at board level to manage specific behavior
(OTP update for example).
+config DFU_SCSI
+ bool "SCSI flash back end for DFU"
+ help
+ This option enables using DFU to read and write to SCSI devices
+ used at board level to manage specific behavior
+ (OTP update for example).
+
config SET_DFU_ALT_INFO
bool "Dynamic set of DFU alternate information"
help
This option allows to call the function set_dfu_alt_info to
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index dfbf64da6677..3b3ba0994b3a 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o
obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o
obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o
obj-$(CONFIG_$(SPL_)DFU_WRITE_ALT) += dfu_alt.o
obj-$(CONFIG_$(SPL_)DFU_VIRT) += dfu_virt.o
+obj-$(CONFIG_$(SPL_)DFU_SCSI) += dfu_scsi.o
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 2adf26e2fe24..8024ad98a7dc 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -548,8 +548,11 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char
*s, int alt,
return -1;
} else if (strcmp(interface, "virt") == 0) {
if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
return -1;
+ } else if (strcmp(interface, "scsi") == 0) {
+ if (dfu_fill_entity_scsi(dfu, devstr, argv, argc))
+ return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
__func__, interface);
return -1;
@@ -644,9 +647,9 @@ int dfu_config_entities(char *env, char *interface, char
*devstr)
const char *dfu_get_dev_type(enum dfu_device_type t)
{
const char *const dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM",
-"SF", "MTD", "VIRT"};
+"SF", "MTD", "VIRT", "SCSI"};
return dev_t[t];
}
const char *dfu_get_layout(enum dfu_layout l)
diff --git a/drivers/dfu/dfu_scsi.c b/drivers/dfu/dfu_scsi.c
new file mode 100644
index ..63c3bcffe769
--- /dev/null
+++ b/drivers/dfu/dfu_scsi.c
@@ -0,0 +1,437 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DFU SCSI backend (based on MMC backend).
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#define LOG_DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static unsigned char *dfu_file_buf;
+static u64 dfu_file_buf_len;
+static u64 dfu_file_buf_offset;
+
+#define scsi_get_blk_desc(dev)
Re: [PATCH v4] tools: copyfile: use 64k instead of 512 buffer
On 2024-04-09 14:14, Ahelenia Ziemiańska wrote:
This is a trivial but significant optimization:
mkimage took >200ms (and 49489 writes (of which 49456 512)),
now it takes 110ms (and 419 writes (of which 386 64k)).
sendfile is much more appropriate for this and is done in one syscall,
but doesn't bring any significant speedups over 64k r/w
at the 13M size ranges, so there's no need to introduce
#if __linux__
while((size = sendfile(fd_dst, fd_src, NULL, 128 * 1024 * 1024)) > 0)
;
if(size != -1) {
ret = 0;
goto out;
}
#endif
Also extract the buffer size to a macro.
Signed-off-by: Ahelenia Ziemiańska
Looking good to me, thanks for the v4.
Reviewed-by: Dragan Simic
---
tools/fit_common.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/fit_common.c b/tools/fit_common.c
index 2d417d47..d1cde16c 100644
--- a/tools/fit_common.c
+++ b/tools/fit_common.c
@@ -23,6 +23,8 @@
#include
#include
+#define COPYFILE_BUFSIZE (64 * 1024)
+
void fit_print_header(const void *fit, struct image_tool_params
*params)
{
fit_print_contents(fit);
@@ -145,14 +147,14 @@ int copyfile(const char *src, const char *dst)
goto out;
}
- buf = calloc(1, 512);
+ buf = calloc(1, COPYFILE_BUFSIZE);
if (!buf) {
printf("Can't allocate buffer to copy file\n");
goto out;
}
while (1) {
- size = read(fd_src, buf, 512);
+ size = read(fd_src, buf, COPYFILE_BUFSIZE);
if (size < 0) {
printf("Can't read file %s\n", src);
goto out;
[PATCH 1/1] api: add missing cookie checks for network access
dev_write_net() and dev_read_net() should validate the provided cookie.
Signed-off-by: Heinrich Schuchardt
---
api/api_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/api/api_net.c b/api/api_net.c
index 7515c26e8b4..0b931a80787 100644
--- a/api/api_net.c
+++ b/api/api_net.c
@@ -72,14 +72,16 @@ int dev_enum_net(struct device_info *di)
int dev_write_net(void *cookie, void *buf, int len)
{
- /* XXX verify that cookie points to a valid net device??? */
+ if (!dev_valid_net(cookie))
+ return API_ENODEV;
return eth_send(buf, len);
}
int dev_read_net(void *cookie, void *buf, int len)
{
- /* XXX verify that cookie points to a valid net device??? */
+ if (!dev_valid_net(cookie))
+ return API_ENODEV;
return eth_receive(buf, len);
}
--
2.43.0
[PATCH v4] tools: copyfile: use 64k instead of 512 buffer
This is a trivial but significant optimization:
mkimage took >200ms (and 49489 writes (of which 49456 512)),
now it takes 110ms (and 419 writes (of which 386 64k)).
sendfile is much more appropriate for this and is done in one syscall,
but doesn't bring any significant speedups over 64k r/w
at the 13M size ranges, so there's no need to introduce
#if __linux__
while((size = sendfile(fd_dst, fd_src, NULL, 128 * 1024 * 1024)) > 0)
;
if(size != -1) {
ret = 0;
goto out;
}
#endif
Also extract the buffer size to a macro.
Signed-off-by: Ahelenia Ziemiańska
---
tools/fit_common.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/fit_common.c b/tools/fit_common.c
index 2d417d47..d1cde16c 100644
--- a/tools/fit_common.c
+++ b/tools/fit_common.c
@@ -23,6 +23,8 @@
#include
#include
+#define COPYFILE_BUFSIZE (64 * 1024)
+
void fit_print_header(const void *fit, struct image_tool_params *params)
{
fit_print_contents(fit);
@@ -145,14 +147,14 @@ int copyfile(const char *src, const char *dst)
goto out;
}
- buf = calloc(1, 512);
+ buf = calloc(1, COPYFILE_BUFSIZE);
if (!buf) {
printf("Can't allocate buffer to copy file\n");
goto out;
}
while (1) {
- size = read(fd_src, buf, 512);
+ size = read(fd_src, buf, COPYFILE_BUFSIZE);
if (size < 0) {
printf("Can't read file %s\n", src);
goto out;
--
2.39.2
signature.asc
Description: PGP signature
Re: [PATCH v2 3/3] mtd: spi-nor-id: Add S25FS064S, S25FS128S, S25FS256S IDs
On Tue, Apr 09 2024, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
> Flash devices with S25FS512S. Some difference depending on the device
> densities are taken care in post SFDP fixup.
>
> Signed-off-by: Takahiro Kuwano
> ---
> drivers/mtd/spi/spi-nor-core.c | 24 ++--
> drivers/mtd/spi/spi-nor-ids.c | 3 +++
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 9620852817..9b81b31e8e 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3356,12 +3356,24 @@ static int s25fs_s_post_bfpt_fixup(struct spi_nor
> *nor,
> static void s25fs_s_post_sfdp_fixup(struct spi_nor *nor,
> struct spi_nor_flash_parameter *params)
> {
> - /* READ_1_1_2 is not supported */
> - params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
> - /* READ_1_1_4 is not supported */
> - params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
> - /* PP_1_1_4 is not supported */
> - params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
> + /*
> + * The S25FS064S(8MB) supports 1-1-2 and 1-1-4 commands, but params for
> + * read ops in SFDP are wrong. The other density parts do not support
> + * 1-1-2 and 1-1-4 commands.
> + */
> + if (params->size == SZ_8M) {
> + spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_2],
> + 0, 8, SPINOR_OP_READ_1_1_2,
> + SNOR_PROTO_1_1_2);
> + spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_4],
> + 0, 8, SPINOR_OP_READ_1_1_4,
> + SNOR_PROTO_1_1_4);
> + } else {
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
> + params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
> + }
> +
Reviewed-by: Pratyush Yadav
BTW (not directly related to this patch), I looked at the datasheet you
provided in the cover letter and it says dual and quad I/O is supported
for the 16 MB and 32 MB parts as well. Why do you mask them out here
then?
> /* Use volatile register to enable quad */
> params->quad_enable = s25fs_s_quad_enable;
> }
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index a3dca506a3..9ca1f244f0 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -341,6 +341,9 @@ const struct flash_info spi_nor_ids[] = {
> { INFO6("s25fl256s0", 0x010219, 0x4d0080, 256 * 1024, 128,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> { INFO6("s25fl256s1", 0x010219, 0x4d0180, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> { INFO6("s25fl512s", 0x010220, 0x4d0080, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> + { INFO6("s25fs064s", 0x010217, 0x4d0181, 64 * 1024, 128,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> + { INFO6("s25fs128s", 0x012018, 0x4d0181, 64 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> + { INFO6("s25fs256s", 0x010219, 0x4d0181, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> { INFO6("s25fs512s", 0x010220, 0x4d0081, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> { INFO("s25fl512s_256k", 0x010220, 0x4d00, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> { INFO("s25fl512s_64k", 0x010220, 0x4d01, 64 * 1024, 1024,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
--
Regards,
Pratyush Yadav
Re: [PATCH v2 2/3] mtd: spi-nor-id: Use INFO6 macro for S25FL-S
On Tue, Apr 09 2024, tkuw584...@gmail.com wrote: > From: Takahiro Kuwano > > The 6th ID byte is needed to distiguish S25FL-S and S25FS-S families. > > Signed-off-by: Takahiro Kuwano Reviewed-by: Pratyush Yadav -- Regards, Pratyush Yadav
Re: [PATCH v2 1/3] mtd: spi-nore-core: Fix 4KB erase opcode for s25fs-s
On Tue, Apr 09 2024, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> The correct 4KB erase opcode should be selected based on the address width
> currently used.
>
> Fixes: 562d166a13 ("mtd: spi-nor-core: Add fixups for s25fs512s")
> Signed-off-by: Takahiro Kuwano
Reviewed-by: Pratyush Yadav
--
Regards,
Pratyush Yadav
Re: [PATCH 01/13] ti:keys Add EFI signature list
On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:
On 4/8/24 23:33, Jonathan Humphreys wrote:
EFI signature list using TI dummy keys.
Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.
The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).
Andrew
Best regards
Heinrich
Signed-off-by: Jonathan Humphreys
---
arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-k3/keys/custMpk.esl
diff --git a/arch/arm/mach-k3/keys/custMpk.esl
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};xRCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h
Re: [PATCH v4 2/3] imx: imx93_evk: add rtc PCF2131
Hi Joy,
On Sun, Apr 7, 2024 at 5:57 AM Joy Zou wrote:
>
> support rtc PCF2131 for imx93.
Please improve the commit log:
- Start with a capital letter.
- You are adding the RTC support for the imx93-evk board, not for imx93.
> +
> + aliases {
> + rtc0 =
> + };
> +
There is no need for this extra blank line. Please drop it.
BTW, you should also add the alias in the patch you sent to Linux.
> + pcf2131: rtc@53 {
> + compatible = "nxp,pcf2131";
> + reg = <0x53>;
> + interrupt-parent = <>;
> + interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> + status = "okay";
The status should be dropped as per the feedback you received in the
kernel submission.
Re: [PATCH] doc: build: update docker image to latest
Hi Tom,
Thank you for the review.
On lun., avril 08, 2024 at 14:11, Tom Rini wrote:
> On Fri, Apr 05, 2024 at 08:16:19AM +0200, Mattijs Korpershoek wrote:
>
>
>> commit cacc0b2678c0 ("CI: Move to latest container image") updated the
>> docker container image.
>>
>> Reflect the change in the documentation.
>>
>> Signed-off-by: Mattijs Korpershoek
>
> I'm fine with updating this for now, so:
>
> Reviewed-by: Tom Rini
>
> But I think longer term we/I should reword the section to be clear
> that's an example syntax not a "recreate the current tag" since only I
> can push that result.
I agree. I will do another reword later to explain where to find the
reference image (pointing to .gitlab-ci.yml)
>
> --
> Tom
[PATCH v2] configs: zynqmp_kria: Deactivate CONFIG_SPI_FLASH_BAR
The Kria board features a recovery application that activates when the FW_EN button is pressed. Upon power-up flash operates in 3B mode, However, the recovery application changes it back to 4B mode. Currently, after a reset, u-boot activates CONFIG_SPI_FLASH_BAR and assumes the flash is in 3B mode. However, there's no code or reset lines connected to the flash that could return it to 3B mode. To resolve this issue, changes were made to disable CONFIG_SPI_FLASH_BAR, which activates 4-byte opcodes. Signed-off-by: Tejas Bhumkar --- Changes in v2: Updated commit message. configs/xilinx_zynqmp_kria_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index 7cb8b62d32..7af8b27be9 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -155,7 +155,6 @@ CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_DM_MTD=y -CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y -- 2.27.0
Re: [PATCH v3 1/1] fastboot: introduce 'oem board' subcommand
Hi Alexey,
Thank you for the patch.
On lun., avril 08, 2024 at 13:15, Alexey Romanov
wrote:
> Currently, fastboot protocol in U-Boot has no opportunity
> to execute vendor custom code with verifed boot. This patch
> introduce new fastboot subcommand fastboot oem board:,
> which allow to run custom oem_board function.
>
> Default implementation is __weak. Vendor must redefine it in
> board/ folder with his own logic.
>
> For example, some vendors have their custom nand/emmc partition
> flashing or erasing. Here some typical command for such use cases:
>
> - flashing:
>
> $ fastboot stage bootloader.img
> $ fastboot oem board:write_bootloader
>
> - erasing:
>
> $ fastboot oem board:erase_env
>
> Signed-off-by: Alexey Romanov
Reviewed-by: Mattijs Korpershoek
Thank you for being patient on this topic!
I'll be awaiting 2 more days and will apply to the u-boot-dfu if no
other remarks have been made.
> ---
> doc/android/fastboot.rst | 18 ++
> drivers/fastboot/Kconfig | 7 +++
> drivers/fastboot/fb_command.c | 30 ++
> include/fastboot.h| 1 +
> 4 files changed, 56 insertions(+)
>
> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
> index 05d8f77759..2020590657 100644
> --- a/doc/android/fastboot.rst
> +++ b/doc/android/fastboot.rst
> @@ -30,6 +30,7 @@ The following OEM commands are supported (if enabled):
> - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
> - ``oem run`` - this executes an arbitrary U-Boot command
> - ``oem console`` - this dumps U-Boot console record buffer
> +- ``oem board`` - this executes an custom board function which is defined by
> vendor
>
> Support for both eMMC and NAND devices is included.
>
> @@ -246,6 +247,23 @@ including multiple commands (using e.g. ``;`` or ``&&``)
> and control structures
> (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the
> exit
> code of the command you ran.
>
> +Running Custom Vendor Code
> +^^
> +
> +U-Boot allows you to execute custom fastboot logic, which can be defined
> +in board/ files. It can still be used for production devices with verified
> +boot, because vendor define logic at compile time by overriding weak
> +implementation of fastboot_oem_board() function. The attacker will
> +not able to execute his commands / code. For example, this can be useful
> +for custom flashing or erasing protocols::
> +
> +$ fastboot stage bootloader.img
> +$ fastboot oem board:write_bootloader
> +
> +In this case, ``cmd_parameter`` argument of the function
> ``fastboot_oem_board()``
> +will contain string "write_bootloader" and ``data`` argument is a pointer to
> +fastboot input buffer, which containing the contents of bootloader.img file.
> +
> References
> --
>
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index 5e5855a76c..937a39f54a 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -249,6 +249,13 @@ config FASTBOOT_CMD_OEM_CONSOLE
> Add support for the "oem console" command to input and read console
> record buffer.
>
> +config FASTBOOT_OEM_BOARD
> + bool "Enable the 'oem board' command"
> + help
> + This extends the fastboot protocol with an "oem board" command. This
> + command allows running vendor custom code defined in board/ files.
> + Otherwise, it will do nothing and send fastboot fail.
> +
> endif # FASTBOOT
>
> endmenu
> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> index f95f4e4ae1..96c27afc60 100644
> --- a/drivers/fastboot/fb_command.c
> +++ b/drivers/fastboot/fb_command.c
> @@ -42,6 +42,7 @@ static void oem_format(char *, char *);
> static void oem_partconf(char *, char *);
> static void oem_bootbus(char *, char *);
> static void oem_console(char *, char *);
> +static void oem_board(char *, char *);
> static void run_ucmd(char *, char *);
> static void run_acmd(char *, char *);
>
> @@ -113,6 +114,10 @@ static const struct {
> .command = "oem console",
> .dispatch = CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_CONSOLE,
> (oem_console), (NULL))
> },
> + [FASTBOOT_COMMAND_OEM_BOARD] = {
> + .command = "oem board",
> + .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board),
> (NULL))
> + },
> [FASTBOOT_COMMAND_UCMD] = {
> .command = "UCmd",
> .dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
> (NULL))
> @@ -542,3 +547,28 @@ static void __maybe_unused oem_console(char
> *cmd_parameter, char *response)
> else
> fastboot_response(FASTBOOT_MULTIRESPONSE_START, response, NULL);
> }
> +
> +/**
> + * fastboot_oem_board() - Execute the OEM board command. This is default
> + * weak implementation, which may be overwritten in board/ files.
> + *
> + * @cmd_parameter: Pointer to
Re: [PATCH 1/1] test: typo curren
On Tue, Apr 9, 2024 at 9:56 AM Heinrich Schuchardt
wrote:
>
> Fix typos in test_eficonfig.py: %s/curren/current/
>
> Signed-off-by: Heinrich Schuchardt
> ---
> test/py/tests/test_eficonfig/test_eficonfig.py | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py
> b/test/py/tests/test_eficonfig/test_eficonfig.py
> index b0a6cc47df2..1d8e033f75d 100644
> --- a/test/py/tests/test_eficonfig/test_eficonfig.py
> +++ b/test/py/tests/test_eficonfig/test_eficonfig.py
> @@ -224,7 +224,7 @@ def test_efi_eficonfig(u_boot_console,
> efi_eficonfig_data):
>
> # Change the Boot Order
> press_up_down_enter_and_wait(0, 2, True, None)
> -# Check the curren BootOrder
> +# Check the current BootOrder
> for i in ('test 2', 'test 1', 'host 0:1', 'Save', 'Quit'):
> u_boot_console.p.expect([i])
> # move 'test 2' to the second entry
> @@ -269,7 +269,7 @@ def test_efi_eficonfig(u_boot_console,
> efi_eficonfig_data):
> u_boot_console.run_command('eficonfig', wait_for_prompt=False)
> # Select 'Edit Boot Option'
> press_up_down_enter_and_wait(0, 1, True, None)
> -# Check the curren BootOrder
> +# Check the current BootOrder
> for i in ('test 1', 'Quit'):
> u_boot_console.p.expect([i])
> press_up_down_enter_and_wait(0, 0, True, None)
> @@ -326,7 +326,7 @@ def test_efi_eficonfig(u_boot_console,
> efi_eficonfig_data):
>
> # Select 'Delete Boot Option'
> press_up_down_enter_and_wait(0, 3, True, None)
> -# Check the curren BootOrder
> +# Check the current BootOrder
> for i in ('test 3', 'Quit'):
> u_boot_console.p.expect([i])
>
> --
> 2.43.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
[GIT PULL] u-boot-riscv/master
Hi Tom, The following changes since commit 069d07396e30aa9be396c1dd3fc158ac199e6843: Merge tag 'efi-2024-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-08 14:33:59 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-riscv.git for you to fetch changes up to c1f78a4f632276bb4d77f8c79fe203709a9fa397: doc: describe Milk-V Mars board (2024-04-09 11:30:37 +0800) CI result shows no issue: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/20256 - RISC-V: Support backtrace and improve isa extension parsing - cpu: Add cv1800b SoC support - board: Add Milk-V Mars board support - board: Add Milk-V Duo SD card support Ben Dooks (1): riscv: add backtrace support Conor Dooley (2): riscv: don't read riscv, isa in the riscv cpu's get_desc() riscv: support extension probing using riscv, isa-extensions Heinrich Schuchardt (7): riscv: starfive: MMC card detect riscv: do not set default fdt for VisionFive 2 eeprom: starfive: function get_product_id_from_eeprom() riscv: set fdtfile on Milk-V Mars board: starfive: support Milk-V Mars board riscv: starfive: avoid including common.h doc: describe Milk-V Mars board Kongyang Liu (5): riscv: cpu: cv1800b: Add support for cv1800b SoC riscv: cache: Implement dcache for cv1800b mmc: cv1800b: Add sdhci driver support for cv1800b SoC riscv: dts: sophgo: Add clk node and sdhci node configs: milkv_duo: Add SD card configs Łukasz Stelmach (1): riscv: Move virtio scan to board_late_init() arch/riscv/Kconfig | 22 arch/riscv/Makefile| 4 + arch/riscv/cpu/cpu.c | 60 +++ arch/riscv/cpu/cv1800b/Kconfig | 12 +++ arch/riscv/cpu/cv1800b/Makefile| 7 ++ arch/riscv/cpu/cv1800b/cache.c | 45 arch/riscv/cpu/cv1800b/cpu.c | 9 ++ arch/riscv/cpu/cv1800b/dram.c | 21 arch/riscv/cpu/start.S | 1 + arch/riscv/dts/cv1800b-milkv-duo.dts | 8 ++ arch/riscv/dts/cv1800b.dtsi| 4 + arch/riscv/dts/cv18xx.dtsi | 22 arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 2 +- arch/riscv/include/asm/arch-jh7110/eeprom.h| 9 ++ arch/riscv/lib/interrupts.c| 35 +++ board/emulation/qemu-riscv/qemu-riscv.c| 12 +-- board/sophgo/milkv_duo/Kconfig | 4 +- board/starfive/visionfive2/spl.c | 100 +++--- board/starfive/visionfive2/starfive_visionfive2.c | 48 ++--- .../starfive/visionfive2/visionfive2-i2c-eeprom.c | 9 +- configs/milkv_duo_defconfig| 10 ++ configs/starfive_visionfive2_defconfig | 1 - doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars.rst | 111 doc/board/starfive/visionfive2.rst | 18 drivers/cpu/riscv_cpu.c| 8 +- drivers/mmc/Kconfig| 13 +++ drivers/mmc/Makefile | 1 + drivers/mmc/cv1800b_sdhci.c| 116 + 29 files changed, 649 insertions(+), 64 deletions(-) create mode 100644 arch/riscv/cpu/cv1800b/Kconfig create mode 100644 arch/riscv/cpu/cv1800b/Makefile create mode 100644 arch/riscv/cpu/cv1800b/cache.c create mode 100644 arch/riscv/cpu/cv1800b/cpu.c create mode 100644 arch/riscv/cpu/cv1800b/dram.c create mode 100644 doc/board/starfive/milk-v_mars.rst create mode 100644 drivers/mmc/cv1800b_sdhci.c Best regards, Leo
[PATCH 1/1] test: typo curren
Fix typos in test_eficonfig.py: %s/curren/current/
Signed-off-by: Heinrich Schuchardt
---
test/py/tests/test_eficonfig/test_eficonfig.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py
b/test/py/tests/test_eficonfig/test_eficonfig.py
index b0a6cc47df2..1d8e033f75d 100644
--- a/test/py/tests/test_eficonfig/test_eficonfig.py
+++ b/test/py/tests/test_eficonfig/test_eficonfig.py
@@ -224,7 +224,7 @@ def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
# Change the Boot Order
press_up_down_enter_and_wait(0, 2, True, None)
-# Check the curren BootOrder
+# Check the current BootOrder
for i in ('test 2', 'test 1', 'host 0:1', 'Save', 'Quit'):
u_boot_console.p.expect([i])
# move 'test 2' to the second entry
@@ -269,7 +269,7 @@ def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
u_boot_console.run_command('eficonfig', wait_for_prompt=False)
# Select 'Edit Boot Option'
press_up_down_enter_and_wait(0, 1, True, None)
-# Check the curren BootOrder
+# Check the current BootOrder
for i in ('test 1', 'Quit'):
u_boot_console.p.expect([i])
press_up_down_enter_and_wait(0, 0, True, None)
@@ -326,7 +326,7 @@ def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
# Select 'Delete Boot Option'
press_up_down_enter_and_wait(0, 3, True, None)
-# Check the curren BootOrder
+# Check the current BootOrder
for i in ('test 3', 'Quit'):
u_boot_console.p.expect([i])
--
2.43.0
[PATCH v2 3/3] mtd: spi-nor-id: Add S25FS064S, S25FS128S, S25FS256S IDs
From: Takahiro Kuwano
The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
Flash devices with S25FS512S. Some difference depending on the device
densities are taken care in post SFDP fixup.
Signed-off-by: Takahiro Kuwano
---
drivers/mtd/spi/spi-nor-core.c | 24 ++--
drivers/mtd/spi/spi-nor-ids.c | 3 +++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 9620852817..9b81b31e8e 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3356,12 +3356,24 @@ static int s25fs_s_post_bfpt_fixup(struct spi_nor *nor,
static void s25fs_s_post_sfdp_fixup(struct spi_nor *nor,
struct spi_nor_flash_parameter *params)
{
- /* READ_1_1_2 is not supported */
- params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
- /* READ_1_1_4 is not supported */
- params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
- /* PP_1_1_4 is not supported */
- params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
+ /*
+* The S25FS064S(8MB) supports 1-1-2 and 1-1-4 commands, but params for
+* read ops in SFDP are wrong. The other density parts do not support
+* 1-1-2 and 1-1-4 commands.
+*/
+ if (params->size == SZ_8M) {
+ spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_2],
+ 0, 8, SPINOR_OP_READ_1_1_2,
+ SNOR_PROTO_1_1_2);
+ spi_nor_set_read_settings(>reads[SNOR_CMD_READ_1_1_4],
+ 0, 8, SPINOR_OP_READ_1_1_4,
+ SNOR_PROTO_1_1_4);
+ } else {
+ params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_2;
+ params->hwcaps.mask &= ~SNOR_HWCAPS_READ_1_1_4;
+ params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
+ }
+
/* Use volatile register to enable quad */
params->quad_enable = s25fs_s_quad_enable;
}
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3dca506a3..9ca1f244f0 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -341,6 +341,9 @@ const struct flash_info spi_nor_ids[] = {
{ INFO6("s25fl256s0", 0x010219, 0x4d0080, 256 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO6("s25fl256s1", 0x010219, 0x4d0180, 64 * 1024, 512,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO6("s25fl512s", 0x010220, 0x4d0080, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+ { INFO6("s25fs064s", 0x010217, 0x4d0181, 64 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+ { INFO6("s25fs128s", 0x012018, 0x4d0181, 64 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+ { INFO6("s25fs256s", 0x010219, 0x4d0181, 64 * 1024, 512,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO6("s25fs512s", 0x010220, 0x4d0081, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_256k", 0x010220, 0x4d00, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_64k", 0x010220, 0x4d01, 64 * 1024, 1024,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
--
2.34.1
[PATCH v2 2/3] mtd: spi-nor-id: Use INFO6 macro for S25FL-S
From: Takahiro Kuwano
The 6th ID byte is needed to distiguish S25FL-S and S25FS-S families.
Signed-off-by: Takahiro Kuwano
---
drivers/mtd/spi/spi-nor-ids.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..a3dca506a3 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -338,8 +338,8 @@ const struct flash_info spi_nor_ids[] = {
*/
{ INFO("s25sl032p", 0x010215, 0x4d00, 64 * 1024, 64,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
- { INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+ { INFO6("s25fl256s0", 0x010219, 0x4d0080, 256 * 1024, 128,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+ { INFO6("s25fl256s1", 0x010219, 0x4d0180, 64 * 1024, 512,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO6("s25fl512s", 0x010220, 0x4d0080, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO6("s25fs512s", 0x010220, 0x4d0081, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_256k", 0x010220, 0x4d00, 256 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
--
2.34.1
[PATCH v2 1/3] mtd: spi-nore-core: Fix 4KB erase opcode for s25fs-s
From: Takahiro Kuwano
The correct 4KB erase opcode should be selected based on the address width
currently used.
Fixes: 562d166a13 ("mtd: spi-nor-core: Add fixups for s25fs512s")
Signed-off-by: Takahiro Kuwano
---
drivers/mtd/spi/spi-nor-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index f86003ca8c..9620852817 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3299,8 +3299,10 @@ static int s25fs_s_quad_enable(struct spi_nor *nor)
static int s25fs_s_erase_non_uniform(struct spi_nor *nor, loff_t addr)
{
+ u8 opcode = nor->addr_width == 4 ? SPINOR_OP_BE_4K_4B : SPINOR_OP_BE_4K;
+
/* Support 8 x 4KB sectors at bottom */
- return spansion_erase_non_uniform(nor, addr, SPINOR_OP_BE_4K_4B, 0,
SZ_32K);
+ return spansion_erase_non_uniform(nor, addr, opcode, 0, SZ_32K);
}
static int s25fs_s_setup(struct spi_nor *nor, const struct flash_info *info,
--
2.34.1
[PATCH v2 0/3] mtd: spi-nor: Add support for S25FS-S family
From: Takahiro Kuwano The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR Flash devices with S25FS512S. Datasheets: https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_Multi-I_O_1-DataSheet-v10_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed526b25412 https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Peripheral_Interface_with_Multi-I_O_MirrorBit(R)_Non-Volatile_Flash-DataSheet-v15_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed6b5ab5758 Takahiro Kuwano (3): mtd: spi-nore-core: Fix 4KB erase opcode in s25fs-s mtd: spi-nor-id: Use INFO6 for S25FL-S mtd: spi-nor: Add support for Infineon S25FS-S family drivers/mtd/spi/spi-nor-core.c | 28 +--- drivers/mtd/spi/spi-nor-ids.c | 7 +-- 2 files changed, 26 insertions(+), 9 deletions(-) -- 2.34.1
