Re: [PATCH] clk: renesas: Fix broken clocks on all Gen2 boards
On 2/9/24 22:15, Niklas Söderlund wrote:
To prepare support for multiple register layouts pointers to register
tables where added to struct cpg_mssr_info. These pointers are suppose
to be filled in at probe time and no intended change in behavior was
intended.
However the new pointers where only filled in by some paths of the
driver implemented in clk-rcar-gen3.c. The path implemented in
clk-rcar-gen2.c was not updated leaving the pointers uninitialized
leading to a crash when trying to probe the clocks.
Fix this by filling in the pointers in the Gen2 code path with the
values used before they where moved to struct cpg_mssr_info.
Fixes: d413214fb748 ("clk: renesas: Add register pointers into struct
cpg_mssr_info")
Signed-off-by: Niklas Söderlund
Acked-by: Marek Vasut
Tested-by: Marek Vasut # R8A7791 Porter
Re: [PATCH 4/4] rockchip: rk3399: regenerate defconfigs
On Sun, Feb 11, 2024 at 3:49 AM Jonas Karlman wrote: > > Hi Chen-Yu, > > On 2024-02-10 07:32, Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > > > Regenerate RK3399 defconfigs after adding imply statements. > > > > Signed-off-by: Chen-Yu Tsai > > --- > > configs/chromebook_bob_defconfig | 2 -- > > configs/chromebook_kevin_defconfig| 2 -- > > configs/firefly-rk3399_defconfig | 2 -- > > configs/nanopi-r4s-rk3399_defconfig | 2 -- > > configs/pinebook-pro-rk3399_defconfig | 2 -- > > configs/pinephone-pro-rk3399_defconfig| 2 -- > > configs/puma-rk3399_defconfig | 2 -- > > configs/roc-pc-mezzanine-rk3399_defconfig | 2 -- > > configs/roc-pc-rk3399_defconfig | 2 -- > > configs/rock-4c-plus-rk3399_defconfig | 3 --- > > configs/rock-4se-rk3399_defconfig | 3 --- > > configs/rock-pi-4-rk3399_defconfig| 3 --- > > configs/rock-pi-4c-rk3399_defconfig | 3 --- > > configs/rock-pi-n10-rk3399pro_defconfig | 1 - > > configs/rock960-rk3399_defconfig | 1 - > > configs/rockpro64-rk3399_defconfig| 2 -- > > 16 files changed, 34 deletions(-) > > > > [snip] > > > diff --git a/configs/rock-4c-plus-rk3399_defconfig > > b/configs/rock-4c-plus-rk3399_defconfig > > index 18525c8bf504..12587b1eba10 100644 > > --- a/configs/rock-4c-plus-rk3399_defconfig > > +++ b/configs/rock-4c-plus-rk3399_defconfig > > @@ -8,7 +8,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > > CONFIG_ENV_OFFSET=0x3F8000 > > CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-4c-plus" > > -CONFIG_OF_LIBFDT_OVERLAY=y > > This patch seems to also remove a few OF_LIBFDT_OVERLAY, guessing this > was unintentional? Yeah, that was unintentional. I have a local patch that enables OF_LIBFDT_OVERLAY for ARCH_ROCKCHIP by default. > If you are re-spinning this series, please also include change to: > - add CONFIG_MISC=y to ficus-rk3399_defconfig, its required for efuse I suppose we should just also imply CONFIG_MISC. > - drop CONFIG_ROCKCHIP_OTP=y from nanopi-r4s-rk3399_defconfig, soc have > efuse or otp and on rk3399 it is efuse Will add a cleanup. > And possible also drop CONFIG_NET_RANDOM_ETHADDR=y from: > - evb-rk3399_defconfig > - ficus-rk3399_defconfig > - khadas-edge-captain-rk3399_defconfig > - khadas-edge-v-rk3399_defconfig > now that these boards will have proper ethaddr. Will add a separate cleanup. ChenYu
Re: [PATCH v1] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions
On Sat, Feb 10, 2024 at 01:07:09PM +0100, Igor Opaniuk wrote: > From: Igor Opaniuk > > Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto > Extensions. The CPU should support ARMv8.2 instruction set and implement > SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions. > > This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction > Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that > indicates support for SHA512* instructions in AArch64 state. As not all > ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by > default for now. > > Tested in QEMU for ARMv8 with compiled-in SHA-2 support. > Even on emulated cpu the hashing speed increase was visible: > > With CE usage: > => time hash sha512 0x4020 0x200 > Calculate hash > Calculate hash > sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... > > time: 0.215 seconds > > Without CE usage: > => time hash sha512 0x4020 0x200 > sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... > > time: 0.356 seconds > > Real HW tests should provide much more improvement and objective results > with 10x speed increase at least. > > The implementation is based on original implementation from Ard Biesheuvel in > Linux kernel [2] > > [1] > https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0 > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S > > CC: Ard Biesheuvel > CC: Loic Poulain > Signed-off-by: Igor Opaniuk [snip] > diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig > index 9f0fb369f7..fd5c26421b 100644 > --- a/arch/arm/cpu/armv8/Kconfig > +++ b/arch/arm/cpu/armv8/Kconfig > @@ -204,6 +204,11 @@ config ARMV8_CE_SHA256 > bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)" > default y if SHA256 > > +config ARMV8_CE_SHA512 > + bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)" > + depends on SHA512 > + default n Like the sha256 one, this should be default y I think, the performance improvement is likely worth the size increase. -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: rockchip: Clarify the rkspi image format further
On Sat, Feb 10, 2024 at 07:18:10PM +0100, Dragan Simic wrote: > As discussed on the U-Boot mailing list, [1][2] only some Rockchip SoCs > suffer from a bug in their BROMs that requires a specific format for their > SPI images, which was the reason for the rkspi format to be introduced. > > Improve the description of the rkspi format a bit to mention this, for > future reference and to make understanding it easier. > > [1] > https://lore.kernel.org/u-boot/c32129ba-db25-4b9d-9a4a-032d88dfb...@kwiboo.se/ > [2] > https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=lkkyob7fzo79afkuqky0e1hbb0zyjuoo...@mail.gmail.com/ > > Signed-off-by: Dragan Simic > --- > doc/README.rockchip | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Can we please convert this content to rst under doc/board/rockchip/ then enhance it? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd: mtd: OTP access support
Sorry, pls ping
Thanks, Arseniy
On 08.01.2024 21:33, Arseniy Krasnov wrote:
> Sorry, pls ping
>
> Thanks, Arseniy
>
> On 20.12.2023 22:36, Arseniy Krasnov wrote:
>> Add access to OTP region. It supports info, dump, write and lock
>> operations.
>>
>> Signed-off-by: Arseniy Krasnov
>> ---
>> Changelog:
>> v1 -> v2:
>> * Remove warning that OTP can't be erased after write.
>>
>> cmd/Kconfig | 1 +
>> cmd/mtd.c | 224
>> 2 files changed, 225 insertions(+)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index 90e4ef93e0..c47523a03b 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -1354,6 +1354,7 @@ config CMD_MTD
>> bool "mtd"
>> depends on MTD
>> select MTD_PARTITIONS
>> +select HEXDUMP
>> help
>>MTD commands support.
>>
>> diff --git a/cmd/mtd.c b/cmd/mtd.c
>> index eb6e2d6892..1ab69b108b 100644
>> --- a/cmd/mtd.c
>> +++ b/cmd/mtd.c
>> @@ -11,6 +11,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -202,6 +203,219 @@ static bool mtd_oob_write_is_empty(struct mtd_oob_ops
>> *op)
>> return true;
>> }
>>
>> +static int do_mtd_otp_read(struct cmd_tbl *cmdtp, int flag, int argc,
>> + char *const argv[])
>> +{
>> +struct mtd_info *mtd;
>> +size_t retlen;
>> +off_t from;
>> +size_t len;
>> +bool user;
>> +int ret;
>> +u8 *buf;
>> +
>> +if (argc != 5)
>> +return CMD_RET_USAGE;
>> +
>> +if (!strcmp(argv[2], "u"))
>> +user = true;
>> +else if (!strcmp(argv[2], "f"))
>> +user = false;
>> +else
>> +return CMD_RET_USAGE;
>> +
>> +mtd = get_mtd_by_name(argv[1]);
>> +if (IS_ERR_OR_NULL(mtd))
>> +return CMD_RET_FAILURE;
>> +
>> +from = simple_strtoul(argv[3], NULL, 0);
>> +len = simple_strtoul(argv[4], NULL, 0);
>> +
>> +ret = CMD_RET_FAILURE;
>> +
>> +buf = malloc(len);
>> +if (!buf)
>> +goto put_mtd;
>> +
>> +printf("Reading %s OTP from 0x%lx, %lu bytes\n",
>> + user ? "user" : "factory", from, len);
>> +
>> +if (user)
>> +ret = mtd_read_user_prot_reg(mtd, from, len, , buf);
>> +else
>> +ret = mtd_read_fact_prot_reg(mtd, from, len, , buf);
>> +if (ret) {
>> +free(buf);
>> +pr_err("OTP read failed: %d\n", ret);
>> +ret = CMD_RET_FAILURE;
>> +goto put_mtd;
>> +}
>> +
>> +if (retlen != len)
>> +pr_err("OTP read returns %zu, but %zu expected\n",
>> + retlen, len);
>> +
>> +print_hex_dump("", 0, 16, 1, buf, retlen, true);
>> +
>> +free(buf);
>> +
>> +ret = CMD_RET_SUCCESS;
>> +
>> +put_mtd:
>> +put_mtd_device(mtd);
>> +
>> +return ret;
>> +}
>> +
>> +static int do_mtd_otp_lock(struct cmd_tbl *cmdtp, int flag, int argc,
>> + char *const argv[])
>> +{
>> +struct mtd_info *mtd;
>> +off_t from;
>> +size_t len;
>> +int ret;
>> +
>> +if (argc != 4)
>> +return CMD_RET_USAGE;
>> +
>> +mtd = get_mtd_by_name(argv[1]);
>> +if (IS_ERR_OR_NULL(mtd))
>> +return CMD_RET_FAILURE;
>> +
>> +from = simple_strtoul(argv[2], NULL, 0);
>> +len = simple_strtoul(argv[3], NULL, 0);
>> +
>> +ret = mtd_lock_user_prot_reg(mtd, from, len);
>> +if (ret) {
>> +pr_err("OTP lock failed: %d\n", ret);
>> +ret = CMD_RET_FAILURE;
>> +goto put_mtd;
>> +}
>> +
>> +ret = CMD_RET_SUCCESS;
>> +
>> +put_mtd:
>> +put_mtd_device(mtd);
>> +
>> +return ret;
>> +}
>> +
>> +static int do_mtd_otp_write(struct cmd_tbl *cmdtp, int flag, int argc,
>> +char *const argv[])
>> +{
>> +struct mtd_info *mtd;
>> +size_t retlen;
>> +size_t binlen;
>> +u8 *binbuf;
>> +off_t from;
>> +int ret;
>> +
>> +if (argc != 4)
>> +return CMD_RET_USAGE;
>> +
>> +mtd = get_mtd_by_name(argv[1]);
>> +if (IS_ERR_OR_NULL(mtd))
>> +return CMD_RET_FAILURE;
>> +
>> +from = simple_strtoul(argv[2], NULL, 0);
>> +binlen = strlen(argv[3]) / 2;
>> +
>> +ret = CMD_RET_FAILURE;
>> +binbuf = malloc(binlen);
>> +if (!binbuf)
>> +goto put_mtd;
>> +
>> +hex2bin(binbuf, argv[3], binlen);
>> +
>> +printf("Will write:\n");
>> +
>> +print_hex_dump("", 0, 16, 1, binbuf, binlen, true);
>> +
>> +printf("to 0x%zx\n", from);
>> +
>> +printf("Continue (y/n)?\n");
>> +
>> +if (confirm_yesno() != 1) {
>> +pr_err("OTP write canceled\n");
>> +ret = CMD_RET_SUCCESS;
>> +goto put_mtd;
>> +}
>> +
>> +ret = mtd_write_user_prot_reg(mtd, from, binlen, , binbuf);
>> +if (ret) {
>> +pr_err("OTP write failed: %d\n", ret);
>> +ret = CMD_RET_FAILURE;
>> +goto put_mtd;
>> +}
>> +
>> +if
Re: [PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
Sorry, pls ping Thanks, Arseniy On 08.01.2024 21:33, Arseniy Krasnov wrote: > Sorry, pls ping > > Thanks, Arseniy
Re: [PATCH v1] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions
[Fixing Ard's email address for something more current.] On Sat, 10 Feb 2024 12:07:09 +, Igor Opaniuk wrote: > > From: Igor Opaniuk > > Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto > Extensions. The CPU should support ARMv8.2 instruction set and implement > SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions. > > This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction > Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that > indicates support for SHA512* instructions in AArch64 state. As not all > ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by > default for now. But since you can actually probe it at runtime, what's the problem? > Tested in QEMU for ARMv8 with compiled-in SHA-2 support. > Even on emulated cpu the hashing speed increase was visible: Unfortunately, QEMU is not a good oracle for optimisations, and is more akin to rolling a dice. In your case, you *should* see an improvement, but this should be evaluated on bare metal. > > With CE usage: > => time hash sha512 0x4020 0x200 > Calculate hash > Calculate hash > sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... > > time: 0.215 seconds > > Without CE usage: > => time hash sha512 0x4020 0x200 > sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... > > time: 0.356 seconds > > Real HW tests should provide much more improvement and objective results > with 10x speed increase at least. > > The implementation is based on original implementation from Ard Biesheuvel in > Linux kernel [2] > > [1] > https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0 > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S > > CC: Ard Biesheuvel > CC: Loic Poulain > Signed-off-by: Igor Opaniuk > --- > > arch/arm/cpu/armv8/Kconfig | 5 + > arch/arm/cpu/armv8/Makefile | 1 + > arch/arm/cpu/armv8/sha512_ce_core.S | 210 > arch/arm/cpu/armv8/sha512_ce_glue.c | 20 +++ > lib/sha512.c| 6 +- > 5 files changed, 240 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/cpu/armv8/sha512_ce_core.S > create mode 100644 arch/arm/cpu/armv8/sha512_ce_glue.c > > diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig > index 9f0fb369f7..fd5c26421b 100644 > --- a/arch/arm/cpu/armv8/Kconfig > +++ b/arch/arm/cpu/armv8/Kconfig > @@ -204,6 +204,11 @@ config ARMV8_CE_SHA256 > bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)" > default y if SHA256 > > +config ARMV8_CE_SHA512 > + bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)" > + depends on SHA512 > + default n > + > endif > > endif > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile > index bba4f570db..3894f2bb2a 100644 > --- a/arch/arm/cpu/armv8/Makefile > +++ b/arch/arm/cpu/armv8/Makefile > @@ -45,3 +45,4 @@ obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/ > obj-$(CONFIG_XEN) += xen/ > obj-$(CONFIG_ARMV8_CE_SHA1) += sha1_ce_glue.o sha1_ce_core.o > obj-$(CONFIG_ARMV8_CE_SHA256) += sha256_ce_glue.o sha256_ce_core.o > +obj-$(CONFIG_ARMV8_CE_SHA512) += sha512_ce_glue.o sha512_ce_core.o > \ No newline at end of file > diff --git a/arch/arm/cpu/armv8/sha512_ce_core.S > b/arch/arm/cpu/armv8/sha512_ce_core.S > new file mode 100644 > index 00..906291f35b > --- /dev/null > +++ b/arch/arm/cpu/armv8/sha512_ce_core.S > @@ -0,0 +1,210 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * sha512-ce-core.S - core SHA-384/SHA-512 transform using v8 Crypto > + * Extensions > + * > + * Copyright (C) 2018 Linaro Ltd > + * Copyright (C) 2024 Igor Opaniuk > + */ > + > + #include > + #include > + #include > + #include > + > + .macro adr_l, dst, sym > + adrp\dst, \sym > + add \dst, \dst, :lo12:\sym > + .endm > + > + .irpb,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 > + .set.Lq\b, \b > + .set.Lv\b\().2d, \b > + .endr > + > + .macro sha512h, rd, rn, rm > + .inst 0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16) > + .endm > + > + .macro sha512h2, rd, rn, rm > + .inst 0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16) > + .endm > + > + .macro sha512su0, rd, rn > + .inst 0xcec08000 | .L\rd | (.L\rn << 5) > + .endm > + > + .macro sha512su1, rd, rn, rm > + .inst 0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16) > + .endm > + > + /* > + * The SHA-512 round constants > + */ > + .section".rodata", "a" > + .align 4 > +.Lsha512_rcon: > + .quad 0x428a2f98d728ae22, 0x7137449123ef65cd > + .quad 0xb5c0fbcfec4d3b2f, 0xe9b5dba58189dbbc > + .quad
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
On 2024-02-10 20:30, Jonas Karlman wrote:
On 2024-02-10 18:18, Dragan Simic wrote:
On 2024-02-08 22:54, Jonas Karlman wrote:
On 2024-02-08 04:53, Dragan Simic wrote:
On 2024-02-07 01:02, Jonas Karlman wrote:
Similar to RK35xx the BootRom in RK3328 can read all data and look
for
idbloader at 0x8000, same as on SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a
bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR
flash.
Signed-off-by: Jonas Karlman
Could you, please, clarify a bit why the "rkspi" format isn't used
instead of "rksd"?
Not really sure how I can clarify this.
As stated in commit message, the bootrom will read all bytes and use
same boot offset as the sd/emmc-format. The "legacy" spi-format only
read first 2kb of each 4kb of storage, see tools/rkspi.c.
A few bootrom versions:
- rk3288: 320A 20131116 V100
- rk3399: 330C 20160118 V100
- rk3328: 320C 20161117 V100
- rk3308: 330E 20180203 V100
I am not sure if the rkspi format must be used for all bootrom prior
to
and including rk3399 and all versions after that should use the rksd
format. I have only ever used boot from spi flash on rk3399, rk3328
and
rk35xx. And for those that has been true.
Ah, thank you very much for refreshing my memory. I somehow forgot
about the bug that the RK3399 BROM suffers from.
Please see also one small suggestion below.
---
arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
b/arch/arm/dts/rk3328-u-boot.dtsi
index b90d78878d77..2a5dca97dd4b 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -120,3 +120,14 @@
_otg {
hnp-srp-disable;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
Perhaps there's no need to use CONFIG_SYS_SOC there, because this is
an
U-Boot SoC dtsi specific to the RK3328. Furthermore, I find it much
more readable (and grep-able, which is also important) when the exact
name of the SoC is specified here.
This note also applies to the other U-Boot SoC dtsi files.
Consistency is my main concern so I would rather keep using SYS_SOC, it
is already being used at the two other override locations.
I agree that consistency is good. Just checking, are you referring
to the use of CONFIG_SYS_SOC in arch/arm/dts/rk356x-u-boot.dtsi and
arch/arm/dts/rk3588s-u-boot.dtsi? Frankly, I'd much rather see rk3568
and rk3588 there, which would be much more readable.
I mean, is CONFIG_SYS_SOC in each of the U-Boot SoC dtsi files ever
going to be substituted with something else than the already known
"rk" value? If so, IMHO there's no valid point in not using the
known value directly.
If we can get confirmation that it is brom in SoCs chronologically up
to
and including rk3399 that is affected by the read 2kb per 4kb of spi
issue we should be able to rework this into a more proper and future
proof way.
It would be nice to have some kind of an official confirmation for that.
+ offset = <0x8000>;
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index b591d38fe412..b82b209de9e2 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -36,6 +36,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@ff50",
};
[PATCH v3] mtd: rawnand: Meson NAND controller support
Basic support for Amlogic Meson NAND controller on AXG. This version works at only first EDO mode. Based on Linux version 6.7.0-rc4. Signed-off-by: Arseniy Krasnov --- Changelog: v1 -> v2: * Update commit message with 'Based on Linux ...'. * Add Linux driver author to .c file header. * Add comment for defines 'NFC_DEFAULT_BUS_CYCLE' and 'NFC_DEFAULT_BUS_TIMING'. * Use 'dev_read_addr_index_ptr()' instead of 'dev_read_addr()'. v2 -> v3: * Update commit message about EDO mode limitation. * Fix scrambling bit value in CMDRWGEN macro. * Add scrambling support for reading. drivers/mtd/nand/raw/Kconfig |9 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1248 + 3 files changed, 1258 insertions(+) create mode 100644 drivers/mtd/nand/raw/meson_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 46a1460746..e946305ccc 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -479,6 +479,15 @@ config NAND_ARASAN controller. This uses the hardware ECC for read and write operations. +config NAND_MESON + bool "Meson NAND support" + select SYS_NAND_SELF_INIT + depends on DM_MTD && ARCH_MESON + imply CMD_NAND + help + This enables Nand driver support for Meson raw NAND flash + controller. + config NAND_MXC bool "MXC NAND support" depends on CPU_ARM926EJS || CPU_ARM1136 || MX5 diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index add2b4cf65..5b4efd52c9 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o +obj-$(CONFIG_NAND_MESON) += meson_nand.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c new file mode 100644 index 00..5d411c4594 --- /dev/null +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -0,0 +1,1248 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Amlogic Meson Nand Flash Controller Driver + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Liang Yang + * + * Copyright (c) 2023 SaluteDevices, Inc. + * Author: Arseniy Krasnov + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define NFC_CMD_IDLE (0xc << 14) +#define NFC_CMD_CLE(0x5 << 14) +#define NFC_CMD_ALE(0x6 << 14) +#define NFC_CMD_DWR(0x4 << 14) +#define NFC_CMD_DRD(0x8 << 14) +#define NFC_CMD_ADL((0 << 16) | (3 << 20)) +#define NFC_CMD_ADH((1 << 16) | (3 << 20)) +#define NFC_CMD_AIL((2 << 16) | (3 << 20)) +#define NFC_CMD_AIH((3 << 16) | (3 << 20)) +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) +#define NFC_CMD_M2N((0 << 17) | (2 << 20)) +#define NFC_CMD_N2M((1 << 17) | (2 << 20)) +#define NFC_CMD_RB BIT(20) +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19) +#define NFC_CMD_SCRAMBLER_DISABLE 0 +#define NFC_CMD_SHORTMODE_DISABLE 0 +#define NFC_CMD_RB_INT BIT(14) +#define NFC_CMD_RB_INT_NO_PIN ((0xb << 10) | BIT(18) | BIT(16)) + +#define NFC_CMD_GET_SIZE(x)(((x) >> 22) & GENMASK(4, 0)) + +#define NFC_REG_CMD0x00 +#define NFC_REG_CFG0x04 +#define NFC_REG_DADR 0x08 +#define NFC_REG_IADR 0x0c +#define NFC_REG_BUF0x10 +#define NFC_REG_INFO 0x14 +#define NFC_REG_DC 0x18 +#define NFC_REG_ADR0x1c +#define NFC_REG_DL 0x20 +#define NFC_REG_DH 0x24 +#define NFC_REG_CADR 0x28 +#define NFC_REG_SADR 0x2c +#define NFC_REG_PINS 0x30 +#define NFC_REG_VER0x38 + +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages) \ + ( \ + (cmd_dir) | \ + (ran) | \ + ((bch) << 14) | \ + ((short_mode) << 13)| \ + (((page_size) & 0x7f) << 6) | \ + ((pages) & 0x3f)\ + ) + +#define GENCMDDADDRL(adl, addr)((adl) | ((addr) & 0x)) +#define
Re: [PATCH 14/15] rockchip: rk3328-rock64: Enable boot from SPI NOR flash
On 2024-02-10 20:38, Jonas Karlman wrote: On 2024-02-10 19:31, Dragan Simic wrote: On 2024-02-07 01:02, Jonas Karlman wrote: Add Kconfig options to enable support for booting from SPI NOR flash on Pine64 Rock64. The generated bootable u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash. The FIT image is loaded from 0x6, same as on RK35xx boards. => sf probe SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load mmc 1:1 1000 u-boot-rockchip-spi.bin 1359872 bytes read in 65 ms (20 MiB/s) => sf update $fileaddr 0 $filesize device 0 offset 0x0, size 0x14c000 1118208 bytes written, 241664 bytes skipped in 8.516s, speed 163516 B/s Signed-off-by: Jonas Karlman Looking good to me. I'm just not sure that we need to support multiple SPI chip brands, because I can't recall that the Rock64 has been shipped with different SPI chips, but perhaps better safe than sorry. Main reason was that rock64 v3 does not come with a spi flash, and the rock64 wiki link to datasheet for both gigadevice and winbond, and in order to keep consistent with the orangepi r1 plus board that use macronix in its schematics. Makes sense, so there's higher chance that an SPI chip selected by the board user is already supported. Maybe even CONFIG_SPI_FLASH_XTX could also be added. Reviewed-by: Dragan Simic --- configs/rock64-rk3328_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 0157a1efe374..01e447448513 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3328=y CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_ROCKCHIP_SPI_IMAGE=y CONFIG_TPL_LIBCOMMON_SUPPORT=y CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_STACK_R_ADDR=0x60 @@ -20,6 +21,8 @@ CONFIG_SPL_STACK=0x40 CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 CONFIG_DEBUG_UART_BASE=0xFF13 CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y # CONFIG_ANDROID_BOOT_IMAGE is not set @@ -42,6 +45,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_STACK_R=y CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_TPL_SYS_MALLOC_SIMPLE=y @@ -76,7 +81,10 @@ CONFIG_MISC=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHY_REALTEK=y CONFIG_DM_ETH_PHY=y CONFIG_ETH_DESIGNWARE=y
Re: [PATCH 14/15] rockchip: rk3328-rock64: Enable boot from SPI NOR flash
On 2024-02-10 19:31, Dragan Simic wrote: > On 2024-02-07 01:02, Jonas Karlman wrote: >> Add Kconfig options to enable support for booting from SPI NOR flash on >> Pine64 Rock64. >> >> The generated bootable u-boot-rockchip-spi.bin that can be written to >> 0x0 of SPI NOR flash. The FIT image is loaded from 0x6, same as on >> RK35xx boards. >> >> => sf probe >> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, >> total 16 MiB >> >> => load mmc 1:1 1000 u-boot-rockchip-spi.bin >> 1359872 bytes read in 65 ms (20 MiB/s) >> >> => sf update $fileaddr 0 $filesize >> device 0 offset 0x0, size 0x14c000 >> 1118208 bytes written, 241664 bytes skipped in 8.516s, speed 163516 >> B/s >> >> Signed-off-by: Jonas Karlman > > Looking good to me. I'm just not sure that we need to support multiple > SPI chip brands, because I can't recall that the Rock64 has been shipped > with different SPI chips, but perhaps better safe than sorry. Main reason was that rock64 v3 does not come with a spi flash, and the rock64 wiki link to datasheet for both gigadevice and winbond, and in order to keep consistent with the orangepi r1 plus board that use macronix in its schematics. Regards, Jonas > > Reviewed-by: Dragan Simic > >> --- >> configs/rock64-rk3328_defconfig | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/configs/rock64-rk3328_defconfig >> b/configs/rock64-rk3328_defconfig >> index 0157a1efe374..01e447448513 100644 >> --- a/configs/rock64-rk3328_defconfig >> +++ b/configs/rock64-rk3328_defconfig >> @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" >> CONFIG_DM_RESET=y >> CONFIG_ROCKCHIP_RK3328=y >> CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y >> +CONFIG_ROCKCHIP_SPI_IMAGE=y >> CONFIG_TPL_LIBCOMMON_SUPPORT=y >> CONFIG_TPL_LIBGENERIC_SUPPORT=y >> CONFIG_SPL_STACK_R_ADDR=0x60 >> @@ -20,6 +21,8 @@ CONFIG_SPL_STACK=0x40 >> CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 >> CONFIG_DEBUG_UART_BASE=0xFF13 >> CONFIG_DEBUG_UART_CLOCK=2400 >> +CONFIG_SPL_SPI_FLASH_SUPPORT=y >> +CONFIG_SPL_SPI=y >> CONFIG_SYS_LOAD_ADDR=0x800800 >> CONFIG_DEBUG_UART=y >> # CONFIG_ANDROID_BOOT_IMAGE is not set >> @@ -42,6 +45,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 >> CONFIG_SPL_STACK_R=y >> CONFIG_SPL_I2C=y >> CONFIG_SPL_POWER=y >> +CONFIG_SPL_SPI_LOAD=y >> +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 >> CONFIG_SPL_ATF=y >> CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y >> CONFIG_TPL_SYS_MALLOC_SIMPLE=y >> @@ -76,7 +81,10 @@ CONFIG_MISC=y >> CONFIG_ROCKCHIP_EFUSE=y >> CONFIG_MMC_DW=y >> CONFIG_MMC_DW_ROCKCHIP=y >> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y >> CONFIG_SPI_FLASH_GIGADEVICE=y >> +CONFIG_SPI_FLASH_MACRONIX=y >> +CONFIG_SPI_FLASH_WINBOND=y >> CONFIG_PHY_REALTEK=y >> CONFIG_DM_ETH_PHY=y >> CONFIG_ETH_DESIGNWARE=y
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
Hi Dragan,
On 2024-02-10 18:18, Dragan Simic wrote:
> Hello Jonas,
>
> On 2024-02-08 22:54, Jonas Karlman wrote:
>> On 2024-02-08 04:53, Dragan Simic wrote:
>>> On 2024-02-07 01:02, Jonas Karlman wrote:
Similar to RK35xx the BootRom in RK3328 can read all data and look
for
idbloader at 0x8000, same as on SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a
bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
Signed-off-by: Jonas Karlman
>>>
>>> Could you, please, clarify a bit why the "rkspi" format isn't used
>>> instead of "rksd"?
>>
>> Not really sure how I can clarify this.
>>
>> As stated in commit message, the bootrom will read all bytes and use
>> same boot offset as the sd/emmc-format. The "legacy" spi-format only
>> read first 2kb of each 4kb of storage, see tools/rkspi.c.
>>
>> A few bootrom versions:
>> - rk3288: 320A 20131116 V100
>> - rk3399: 330C 20160118 V100
>> - rk3328: 320C 20161117 V100
>> - rk3308: 330E 20180203 V100
>>
>> I am not sure if the rkspi format must be used for all bootrom prior to
>> and including rk3399 and all versions after that should use the rksd
>> format. I have only ever used boot from spi flash on rk3399, rk3328 and
>> rk35xx. And for those that has been true.
>
> Ah, thank you very much for refreshing my memory. I somehow forgot
> about
> the bug that the RK3399 BROM suffers from.
>
> Please see also one small suggestion below.
>
---
arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
b/arch/arm/dts/rk3328-u-boot.dtsi
index b90d78878d77..2a5dca97dd4b 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -120,3 +120,14 @@
_otg {
hnp-srp-disable;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>
> Perhaps there's no need to use CONFIG_SYS_SOC there, because this is an
> U-Boot SoC dtsi specific to the RK3328. Furthermore, I find it much
> more
> readable (and grep-able, which is also important) when the exact name of
> the SoC is specified here.
>
> This note also applies to the other U-Boot SoC dtsi files.
Consistency is my main concern so I would rather keep using SYS_SOC, it
is already being used at the two other override locations.
If we can get confirmation that it is brom in SoCs chronologically up to
and including rk3399 that is affected by the read 2kb per 4kb of spi
issue we should be able to rework this into a more proper and future
proof way.
Regards,
Jonas
>
+ offset = <0x8000>;
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index b591d38fe412..b82b209de9e2 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -36,6 +36,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@ff50",
};
Re: [PATCH 4/4] rockchip: rk3399: regenerate defconfigs
Hi Chen-Yu, On 2024-02-10 07:32, Chen-Yu Tsai wrote: > From: Chen-Yu Tsai > > Regenerate RK3399 defconfigs after adding imply statements. > > Signed-off-by: Chen-Yu Tsai > --- > configs/chromebook_bob_defconfig | 2 -- > configs/chromebook_kevin_defconfig| 2 -- > configs/firefly-rk3399_defconfig | 2 -- > configs/nanopi-r4s-rk3399_defconfig | 2 -- > configs/pinebook-pro-rk3399_defconfig | 2 -- > configs/pinephone-pro-rk3399_defconfig| 2 -- > configs/puma-rk3399_defconfig | 2 -- > configs/roc-pc-mezzanine-rk3399_defconfig | 2 -- > configs/roc-pc-rk3399_defconfig | 2 -- > configs/rock-4c-plus-rk3399_defconfig | 3 --- > configs/rock-4se-rk3399_defconfig | 3 --- > configs/rock-pi-4-rk3399_defconfig| 3 --- > configs/rock-pi-4c-rk3399_defconfig | 3 --- > configs/rock-pi-n10-rk3399pro_defconfig | 1 - > configs/rock960-rk3399_defconfig | 1 - > configs/rockpro64-rk3399_defconfig| 2 -- > 16 files changed, 34 deletions(-) > [snip] > diff --git a/configs/rock-4c-plus-rk3399_defconfig > b/configs/rock-4c-plus-rk3399_defconfig > index 18525c8bf504..12587b1eba10 100644 > --- a/configs/rock-4c-plus-rk3399_defconfig > +++ b/configs/rock-4c-plus-rk3399_defconfig > @@ -8,7 +8,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-4c-plus" > -CONFIG_OF_LIBFDT_OVERLAY=y This patch seems to also remove a few OF_LIBFDT_OVERLAY, guessing this was unintentional? If you are re-spinning this series, please also include change to: - add CONFIG_MISC=y to ficus-rk3399_defconfig, its required for efuse - drop CONFIG_ROCKCHIP_OTP=y from nanopi-r4s-rk3399_defconfig, soc have efuse or otp and on rk3399 it is efuse And possible also drop CONFIG_NET_RANDOM_ETHADDR=y from: - evb-rk3399_defconfig - ficus-rk3399_defconfig - khadas-edge-captain-rk3399_defconfig - khadas-edge-v-rk3399_defconfig now that these boards will have proper ethaddr. Regards, Jonas
Re: [PATCH 14/15] rockchip: rk3328-rock64: Enable boot from SPI NOR flash
On 2024-02-07 01:02, Jonas Karlman wrote: Add Kconfig options to enable support for booting from SPI NOR flash on Pine64 Rock64. The generated bootable u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash. The FIT image is loaded from 0x6, same as on RK35xx boards. => sf probe SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load mmc 1:1 1000 u-boot-rockchip-spi.bin 1359872 bytes read in 65 ms (20 MiB/s) => sf update $fileaddr 0 $filesize device 0 offset 0x0, size 0x14c000 1118208 bytes written, 241664 bytes skipped in 8.516s, speed 163516 B/s Signed-off-by: Jonas Karlman Looking good to me. I'm just not sure that we need to support multiple SPI chip brands, because I can't recall that the Rock64 has been shipped with different SPI chips, but perhaps better safe than sorry. Reviewed-by: Dragan Simic --- configs/rock64-rk3328_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 0157a1efe374..01e447448513 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3328=y CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_ROCKCHIP_SPI_IMAGE=y CONFIG_TPL_LIBCOMMON_SUPPORT=y CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_STACK_R_ADDR=0x60 @@ -20,6 +21,8 @@ CONFIG_SPL_STACK=0x40 CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 CONFIG_DEBUG_UART_BASE=0xFF13 CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y # CONFIG_ANDROID_BOOT_IMAGE is not set @@ -42,6 +45,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_STACK_R=y CONFIG_SPL_I2C=y CONFIG_SPL_POWER=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_TPL_SYS_MALLOC_SIMPLE=y @@ -76,7 +81,10 @@ CONFIG_MISC=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHY_REALTEK=y CONFIG_DM_ETH_PHY=y CONFIG_ETH_DESIGNWARE=y
[PATCH] doc: rockchip: Clarify the rkspi image format further
As discussed on the U-Boot mailing list, [1][2] only some Rockchip SoCs suffer from a bug in their BROMs that requires a specific format for their SPI images, which was the reason for the rkspi format to be introduced. Improve the description of the rkspi format a bit to mention this, for future reference and to make understanding it easier. [1] https://lore.kernel.org/u-boot/c32129ba-db25-4b9d-9a4a-032d88dfb...@kwiboo.se/ [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=lkkyob7fzo79afkuqky0e1hbb0zyjuoo...@mail.gmail.com/ Signed-off-by: Dragan Simic --- doc/README.rockchip | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index 84caff8a24d3..e0c5c395ec6a 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -649,7 +649,12 @@ sector is used. The header is the same as with rksd and the maximum size is also 32KB (before spreading). The image should be written to the start of SPI flash. -See above for instructions on how to write a SPI image. +Only the BROMs of some Rockchip SoCs, such as the RK3399, suffer from a bug +that mandates the above-described data spreading, thus requiring the rkspi +format to be used for their SPI images. Rockchip SoCs that don't suffer +from this bug use the rksd format for their SPI images. + +See the section above for instructions on how to write an SPI image. rkmux.py
Re: [PATCH 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B
On Thu, Feb 8, 2024 at 1:59 PM Frieder Schrempf wrote: > > From: Frieder Schrempf > > The datasheet can be found here: > https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf > > Signed-off-by: Frieder Schrempf Reviewed-by: Fabio Estevam
Re: [PATCH 2/3] board: Add support for Sielaff i.MX6 Solo board
Hi Frieder,
On Thu, Feb 8, 2024 at 1:59 PM Frieder Schrempf wrote:
> +/ {
> + binman: binman {
> + filename = "flash.bin";
> + pad-byte = <0x00>;
> +
> + spl: blob-ext@1 {
> + offset = <0x0>;
> + filename = "SPL";
> + };
> +
> + uboot: blob-ext@2 {
> + offset = <0x11000>;
> + filename = "u-boot.img";
> + };
> + };
As mentioned in patch 3/3, please remove the binman entry and use
u-boot-with-spl.imx instead.
> +config TARGET_MX6S_SIELAFF
> + bool "Sielaff i.MX6 Solo Board"
> + depends on MX6S
> + select BINMAN
Please drop it.
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +iomux_v3_cfg_t nfc_pads[] = {
Make it static.
> --- /dev/null
> +++ b/board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
> @@ -0,0 +1,115 @@
> +blkloadfdt=fatload ${device} ${devnum}:${partnum} ${fdt_addr}
> ${load_fdt_file}
> +blkloadimage=fatload ${device} ${devnum}:${partnum} ${loadaddr} ${load_image}
> +boot_devices=usb mmc ubi
> +bootargs_base=vt.global_cursor_default=0 consoleblank=0 cma=200M
> fbcon=rotate:1
> +bootdelay=3
> +bootdir=
> +console=ttymxc1,115200
> +ethact=FEC0
> +fdt_addr=0x1800
> +fdt_file_legacy=imx6dl_sielaff.dtb
> +fdt_file=imx6dl-sielaff.dtb
> +fdt_high=0x
> +hostname=mx6s-siline-hmi
Please remove it.
> +void reset_cpu(void)
> +{
> +}
Is this needed?
Does the 'reset' command work on this board?
> +++ b/configs/imx6dl_sielaff_defconfig
> @@ -0,0 +1,117 @@
> +CONFIG_ARM=y
> +CONFIG_SPL_SYS_ICACHE_OFF=y
> +CONFIG_SPL_SYS_DCACHE_OFF=y
These options should be dropped.
> +#include
> +#include
> +#include "mx6_common.h"
> +
> +#define CFG_MXC_UART_BASE UART2_BASE
As you use DM_SERIAL, this can be dropped.
Re: [PATCH v2] net: designware: Support high memory nodes
On Mon, 4 Dec 2023 01:09:30 +
Andre Przywara wrote:
Hi Joe, Ramon, Tom,
for some reason patchwork put this on my plate, but it looks like
genuine network code to me, and the problem definitely doesn't affect
sunxi.
As tagged below, I am happy with this change, so if there are no
objections, can one of you take this patch, please?
Cheers,
Andre
> On Sat, 2 Dec 2023 10:39:49 +0100
> Nils Le Roux wrote:
>
> Hi Nils,
>
> > Some platforms (such as the Lichee Pi 4A) have their dwmac device
> > addressable only in high memory space. Storing the node's base address
> > on 32 bits is not possible in such case.
> >
> > Use platform's physical address type to store the base address.
> >
> > Signed-off-by: Nils Le Roux
> > Cc: Andre Przywara
>
> many thanks for the changes, that looks good to me now. I have
> compile-tested that for arm64 and arm.
>
> Reviewed-by: Andre Przywara
>
> Cheers,
> Andre
>
> > ---
> >
> > Changes in v2:
> > - explicitly define and handle ioaddr as a virtual address
> > - use an intermediate variable to assign the PCI base address
> > - use appropriate placeholder to print physical addresses
> > ---
> > drivers/net/designware.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> > index a174344b3e..78bfce07f6 100644
> > --- a/drivers/net/designware.c
> > +++ b/drivers/net/designware.c
> > @@ -678,8 +678,8 @@ int designware_eth_probe(struct udevice *dev)
> > {
> > struct eth_pdata *pdata = dev_get_plat(dev);
> > struct dw_eth_dev *priv = dev_get_priv(dev);
> > - u32 iobase = pdata->iobase;
> > - ulong ioaddr;
> > + phys_addr_t iobase = pdata->iobase;
> > + void *ioaddr;
> > int ret, err;
> > struct reset_ctl_bulk reset_bulk;
> > #ifdef CONFIG_CLK
> > @@ -740,16 +740,18 @@ int designware_eth_probe(struct udevice *dev)
> > * or via a PCI bridge, fill in plat before we probe the hardware.
> > */
> > if (IS_ENABLED(CONFIG_PCI) && device_is_on_pci_bus(dev)) {
> > - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
> > - iobase &= PCI_BASE_ADDRESS_MEM_MASK;
> > - iobase = dm_pci_mem_to_phys(dev, iobase);
> > + u32 pcibase;
> >
> > + dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
> > + pcibase &= PCI_BASE_ADDRESS_MEM_MASK;
> > +
> > + iobase = dm_pci_mem_to_phys(dev, pcibase);
> > pdata->iobase = iobase;
> > pdata->phy_interface = PHY_INTERFACE_MODE_RMII;
> > }
> >
> > - debug("%s, iobase=%x, priv=%p\n", __func__, iobase, priv);
> > - ioaddr = iobase;
> > + debug("%s, iobase=%pa, priv=%p\n", __func__, , priv);
> > + ioaddr = phys_to_virt(iobase);
> > priv->mac_regs_p = (struct eth_mac_regs *)ioaddr;
> > priv->dma_regs_p = (struct eth_dma_regs *)(ioaddr + DW_DMA_BASE_OFFSET);
> > priv->interface = pdata->phy_interface;
>
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
Hello Da Xue,
On 2024-02-09 02:57, Da Xue wrote:
On Wed, Feb 7, 2024 at 10:53 PM Dragan Simic
wrote:
On 2024-02-07 01:02, Jonas Karlman wrote:
> Similar to RK35xx the BootRom in RK3328 can read all data and look for
> idbloader at 0x8000, same as on SD and eMMC.
>
> Use the rksd format and modify the mkimage offset to generate a
> bootable
> u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
>
> Signed-off-by: Jonas Karlman
Could you, please, clarify a bit why the "rkspi" format isn't used
instead of "rksd"?
"The SPI code has a bug that means that the 2 KiB blocks in which the
bootloader is loaded have a stride of 4KiB, leaving the 2KiB inbetween
as unused padding."
RK3399 has the 2K SPI bug and necessitated the rkspi format. RK3328
came after RK3399 and resolved this bug so the SPI and MMC formats are
now the same.
I verified on a ROC-RK3328-CC-V2.
Thank you very much too, for refreshing my memory. I somehow forgot
about
the bug that the RK3399 BROM suffers from.
> ---
> arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
> arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
> b/arch/arm/dts/rk3328-u-boot.dtsi
> index b90d78878d77..2a5dca97dd4b 100644
> --- a/arch/arm/dts/rk3328-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-u-boot.dtsi
> @@ -120,3 +120,14 @@
> _otg {
> hnp-srp-disable;
> };
> +
> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> + {
> + simple-bin-spi {
> + mkimage {
> + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> + offset = <0x8000>;
> + };
> + };
> +};
> +#endif
> diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
> b/arch/arm/mach-rockchip/rk3328/rk3328.c
> index b591d38fe412..b82b209de9e2 100644
> --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> @@ -36,6 +36,7 @@
>
> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
> + [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
> [BROM_BOOTSOURCE_SD] = "/mmc@ff50",
> };
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
Hello Jonas,
On 2024-02-08 22:54, Jonas Karlman wrote:
On 2024-02-08 04:53, Dragan Simic wrote:
On 2024-02-07 01:02, Jonas Karlman wrote:
Similar to RK35xx the BootRom in RK3328 can read all data and look
for
idbloader at 0x8000, same as on SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a
bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
Signed-off-by: Jonas Karlman
Could you, please, clarify a bit why the "rkspi" format isn't used
instead of "rksd"?
Not really sure how I can clarify this.
As stated in commit message, the bootrom will read all bytes and use
same boot offset as the sd/emmc-format. The "legacy" spi-format only
read first 2kb of each 4kb of storage, see tools/rkspi.c.
A few bootrom versions:
- rk3288: 320A 20131116 V100
- rk3399: 330C 20160118 V100
- rk3328: 320C 20161117 V100
- rk3308: 330E 20180203 V100
I am not sure if the rkspi format must be used for all bootrom prior to
and including rk3399 and all versions after that should use the rksd
format. I have only ever used boot from spi flash on rk3399, rk3328 and
rk35xx. And for those that has been true.
Ah, thank you very much for refreshing my memory. I somehow forgot
about
the bug that the RK3399 BROM suffers from.
Please see also one small suggestion below.
---
arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
b/arch/arm/dts/rk3328-u-boot.dtsi
index b90d78878d77..2a5dca97dd4b 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -120,3 +120,14 @@
_otg {
hnp-srp-disable;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
Perhaps there's no need to use CONFIG_SYS_SOC there, because this is an
U-Boot SoC dtsi specific to the RK3328. Furthermore, I find it much
more
readable (and grep-able, which is also important) when the exact name of
the SoC is specified here.
This note also applies to the other U-Boot SoC dtsi files.
+ offset = <0x8000>;
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index b591d38fe412..b82b209de9e2 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -36,6 +36,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@ff50",
};
Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399
On 2024-02-10 07:32, Chen-Yu Tsai wrote: From: Chen-Yu Tsai This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328 and RK3399 so that the cpuid is read from the efuse and used to generate a serial number and MAC addresses for all boards. This stacks on top of the recent defconfig update series [1] from Jonas. The entire series is looking good to me! Reviewed-by: Dragan Simic [1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/ Chen-Yu Tsai (4): rockchip: rk3328: Read cpuid and generate MAC address from efuse rockchip: rk3399: Read cpuid and generate MAC address from efuse rockchip: rk3328: regenerate defconfigs rockchip: rk3399: regenerate defconfigs arch/arm/mach-rockchip/Kconfig| 4 configs/chromebook_bob_defconfig | 2 -- configs/chromebook_kevin_defconfig| 2 -- configs/evb-rk3328_defconfig | 2 -- configs/firefly-rk3399_defconfig | 2 -- configs/nanopi-r2c-plus-rk3328_defconfig | 2 -- configs/nanopi-r2c-rk3328_defconfig | 2 -- configs/nanopi-r2s-rk3328_defconfig | 2 -- configs/nanopi-r4s-rk3399_defconfig | 2 -- configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 -- configs/orangepi-r1-plus-rk3328_defconfig | 2 -- configs/pinebook-pro-rk3399_defconfig | 2 -- configs/pinephone-pro-rk3399_defconfig| 2 -- configs/puma-rk3399_defconfig | 2 -- configs/roc-cc-rk3328_defconfig | 2 -- configs/roc-pc-mezzanine-rk3399_defconfig | 2 -- configs/roc-pc-rk3399_defconfig | 2 -- configs/rock-4c-plus-rk3399_defconfig | 3 --- configs/rock-4se-rk3399_defconfig | 3 --- configs/rock-pi-4-rk3399_defconfig| 3 --- configs/rock-pi-4c-rk3399_defconfig | 3 --- configs/rock-pi-e-rk3328_defconfig| 2 -- configs/rock-pi-n10-rk3399pro_defconfig | 1 - configs/rock64-rk3328_defconfig | 2 -- configs/rock960-rk3399_defconfig | 1 - configs/rockpro64-rk3399_defconfig| 2 -- 26 files changed, 4 insertions(+), 52 deletions(-)
[PATCH v2 6/6] efi_selftest: Add symbol character selftest
From: Janne Grunau
Draw symbols from code page 437 code points 0x01 - 01f used by UEFI
applications to draw user interfaces using
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
Add a simple test to displaying the Konami code using symbols used by
grub2. The output has to be checked manually on the screen for
correctness.
Signed-off-by: Janne Grunau
---
lib/efi_selftest/efi_selftest_textoutput.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_textoutput.c
b/lib/efi_selftest/efi_selftest_textoutput.c
index cc11a22eee..9e5d944fa0 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -46,6 +46,8 @@ u"left bottom \u2502 right bottom
\u2502\n\u2514\u2500\u2500\u2500"
u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534"
u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
u"\u2500\u2500\u2500\u2500\u2518\n";
+ const u16 konami[] =
+u"Konami code: \u25b2 \u25b2 \u25bc \u25bc \u25c4 \u25ba \u25c4 \u25ba B A\n";
/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -144,6 +146,11 @@ u"\u2500\u2500\u2500\u2500\u2518\n";
efi_st_error("OutputString failed for box drawing chars\n");
return EFI_ST_FAILURE;
}
+ ret = con_out->output_string(con_out, konami);
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("OutputString failed for symbol chars\n");
+ return EFI_ST_FAILURE;
+ }
con_out->output_string(con_out, u"waiting for admiration...\n");
EFI_CALL(systab.boottime->stall(300));
efi_st_printf("\n");
--
2.43.0
[PATCH v2 5/6] efi_selftest: Add box drawing character selftest
From: Andre Przywara
UEFI applications rely on Unicode output capability, and might use that
for drawing pseudo-graphical interfaces using Unicode defined box
drawing characters.
Add a simple test to display the most basic box characters, which would
need to be checked manually on the screen for correctness.
To facilitate this, add a three second delay after the output at this
point.
Signed-off-by: Andre Przywara
Suggested-by: Heinrich Schuchardt
Signed-off-by: Janne Grunau
---
lib/efi_selftest/efi_selftest_textoutput.c | 20
1 file changed, 20 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_textoutput.c
b/lib/efi_selftest/efi_selftest_textoutput.c
index 2aa81b0a80..cc11a22eee 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -33,6 +33,19 @@ static int execute(void)
const u16 text[] =
u"\u00d6sterreich Edelwei\u00df Sm\u00f8rrebr\u00f8d Sm\u00f6rg"
u"\u00e5s Ni\u00f1o Ren\u00e9 >\u1f19\u03bb\u03bb\u03ac\u03c2<\n";
+ const u16 boxes[] =
+u"This should render as four boxes with text\n"
+u"\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502"
+u" left top\u2502 right top \u2502\n\u251c\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 "
+u"left bottom \u2502 right bottom \u2502\n\u2514\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2518\n";
/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -126,6 +139,13 @@ u"\u00e5s Ni\u00f1o Ren\u00e9
>\u1f19\u03bb\u03bb\u03ac\u03c2<\n";
efi_st_error("OutputString failed for international chars\n");
return EFI_ST_FAILURE;
}
+ ret = con_out->output_string(con_out, boxes);
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("OutputString failed for box drawing chars\n");
+ return EFI_ST_FAILURE;
+ }
+ con_out->output_string(con_out, u"waiting for admiration...\n");
+ EFI_CALL(systab.boottime->stall(300));
efi_st_printf("\n");
return EFI_ST_SUCCESS;
--
2.43.0
[PATCH v2 1/6] lib: charset: Fix and extend utf8_to_utf32_stream() documentation
From: Janne Grunau Suggested-by: Heinrich Schuchardt Signed-off-by: Janne Grunau --- include/charset.h | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/include/charset.h b/include/charset.h index 44034c71d3..f1050c903d 100644 --- a/include/charset.h +++ b/include/charset.h @@ -324,11 +324,21 @@ int utf_to_cp(s32 *c, const u16 *codepage); int utf8_to_cp437_stream(u8 c, char *buffer); /** - * utf8_to_utf32_stream() - convert UTF-8 stream to UTF-32 + * utf8_to_utf32_stream() - convert UTF-8 byte stream to Unicode code points + * + * The function is called for each byte @c in a UTF-8 stream. The byte is + * appended to the temporary storage @buffer until the UTF-8 stream in + * @buffer describes a Unicode code point. + * + * When a new code point has been decoded it is returned and buffer[0] is + * set to '\0', otherwise the return value is 0. + * + * The buffer must be at least 5 characters long. Before the first function + * invocation buffer[0] must be set to '\0'." * * @c: next UTF-8 character to convert * @buffer:buffer, at least 5 characters - * Return: next codepage 437 character or 0 + * Return: Unicode code point or 0 */ int utf8_to_utf32_stream(u8 c, char *buffer); -- 2.43.0
[PATCH v2 4/6] efi_selftest: Add international characters test
From: Andre Przywara
UEFI relies entirely on unicode output, which actual fonts displayed on
the screen might not be ready for.
Add a test displaying some international characters, to reveal missing
glyphs, especially in our builtin fonts.
This would be needed to be manually checked on the screen for
correctness.
Signed-off-by: Andre Przywara
Suggested-by: Heinrich Schuchardt
Signed-off-by: Janne Grunau
---
lib/efi_selftest/efi_selftest_textoutput.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_textoutput.c
b/lib/efi_selftest/efi_selftest_textoutput.c
index cc44b38bc2..2aa81b0a80 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -30,6 +30,9 @@ static int execute(void)
0xD804, 0xDC05,
0xD804, 0xDC22,
0};
+ const u16 text[] =
+u"\u00d6sterreich Edelwei\u00df Sm\u00f8rrebr\u00f8d Sm\u00f6rg"
+u"\u00e5s Ni\u00f1o Ren\u00e9 >\u1f19\u03bb\u03bb\u03ac\u03c2<\n";
/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -118,6 +121,11 @@ static int execute(void)
efi_st_printf("Unicode not handled properly\n");
return EFI_ST_FAILURE;
}
+ ret = con_out->output_string(con_out, text);
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("OutputString failed for international chars\n");
+ return EFI_ST_FAILURE;
+ }
efi_st_printf("\n");
return EFI_ST_SUCCESS;
--
2.43.0
[PATCH v2 2/6] video: console: Parse UTF-8 character sequences
From: Janne Grunau
efi_console / UEFI applications (grub2, sd-boot, ...) pass UTF-8
character sequences to vidconsole which results in wrong glyphs for code
points outside of ASCII. The truetype console expects Unicode code
points and bitmap font based consoles expect code page 437 code points.
To support both convert UTF-8 to UTF-32 and pass Unicode code points in
vidconsole_ops.putc_xy(). These can be used directly in console_truetype
and after conversion to code page 437 in console_{normal,rotate}.
This fixes rendering of international, symbol and box drawing characters
used by UEFI applications.
Signed-off-by: Janne Grunau
---
drivers/video/console_normal.c | 6 --
drivers/video/console_rotate.c | 16 ++--
drivers/video/console_truetype.c| 8
drivers/video/vidconsole-uclass.c | 18 +-
drivers/video/vidconsole_internal.h | 15 +++
include/video_console.h | 10 ++
6 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
index a0231293f3..34ef5a5229 100644
--- a/drivers/video/console_normal.c
+++ b/drivers/video/console_normal.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -63,7 +64,7 @@ static int console_move_rows(struct udevice *dev, uint rowdst,
return 0;
}
-static int console_putc_xy(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy(struct udevice *dev, uint x_frac, uint y, int cp)
{
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -73,8 +74,9 @@ static int console_putc_xy(struct udevice *dev, uint x_frac,
uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int x, linenum, ret;
void *start, *line;
+ u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
- (u8)ch * fontdata->char_pixel_bytes;
+ ch * fontdata->char_pixel_bytes;
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index 65358a1c6e..e4303dfb36 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -67,7 +68,7 @@ static int console_move_rows_1(struct udevice *dev, uint
rowdst, uint rowsrc,
return 0;
}
-static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, int cp)
{
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -77,8 +78,9 @@ static int console_putc_xy_1(struct udevice *dev, uint
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int x, linenum, ret;
void *start, *line;
+ u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
- (u8)ch * fontdata->char_pixel_bytes;
+ ch * fontdata->char_pixel_bytes;
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
@@ -145,7 +147,7 @@ static int console_move_rows_2(struct udevice *dev, uint
rowdst, uint rowsrc,
return 0;
}
-static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, int cp)
{
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -155,8 +157,9 @@ static int console_putc_xy_2(struct udevice *dev, uint
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int linenum, x, ret;
void *start, *line;
+ u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
- (u8)ch * fontdata->char_pixel_bytes;
+ ch * fontdata->char_pixel_bytes;
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
@@ -227,7 +230,7 @@ static int console_move_rows_3(struct udevice *dev, uint
rowdst, uint rowsrc,
return 0;
}
-static int console_putc_xy_3(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_3(struct udevice *dev, uint x_frac, uint y, int cp)
{
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -237,8 +240,9 @@ static int console_putc_xy_3(struct udevice *dev, uint
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int linenum, x, ret;
void *start, *line;
+ u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
-
[PATCH v2 0/6] video: Add UTF-8 support for UEFI applications
Andre submitted 2 years ago DM_VIDEO improvements for UEFI applications using UEFI's EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL but did not follow with suggested changes. This series takes care of the UTF-8 support which required to draw symbol and box drawing characters used by UEFI applications like grub2 and sd-boot correctly. Compared to Andre's version this version has the following changes: - use and extend existing conversion functions from lib/charset.c - convert to Unicode code points for truetype console support - conversion is conditional on CONFIG_CHARSET - use escape sequences in tests as proposed by Heinrich Link: https://lore.kernel.org/u-boot/20220110005638.21599-1-andre.przyw...@arm.com/ Signed-off-by: Janne Grunau --- Changes in v2: - use "CONFIG_IS_ENABLED(CHARSET)" instead of EFI_LOADER - rewritten commit message for mapping CP437 cp 1-31 - extended utf8_to_utf32_stream() documentation as suggested by Heinrich - Link to RFC: https://lore.kernel.org/r/20240117-vidconsole-utf8-uefi-v1-0-539f7ce74...@jannau.net --- Andre Przywara (2): efi_selftest: Add international characters test efi_selftest: Add box drawing character selftest Janne Grunau (4): lib: charset: Fix and extend utf8_to_utf32_stream() documentation video: console: Parse UTF-8 character sequences lib/charset: Map Unicode code points to CP437 code points 0-31 efi_selftest: Add symbol character selftest drivers/video/console_normal.c | 6 +++-- drivers/video/console_rotate.c | 16 +- drivers/video/console_truetype.c | 8 +++ drivers/video/vidconsole-uclass.c | 18 ++- drivers/video/vidconsole_internal.h| 15 + include/charset.h | 16 +++--- include/cp1250.h | 12 -- include/cp437.h| 12 -- include/video_console.h| 10 + lib/charset.c | 9 +--- lib/efi_loader/efi_unicode_collation.c | 2 +- lib/efi_selftest/efi_selftest_textoutput.c | 35 ++ 12 files changed, 127 insertions(+), 32 deletions(-) --- base-commit: 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e change-id: 20240117-vidconsole-utf8-uefi-fa23b4ac65d6 Best regards, -- Janne Grunau
[PATCH v2 3/6] lib/charset: Map Unicode code points to CP437 code points 0-31
From: Janne Grunau
Code page 437 uses code points 1-31 for glyphs instead of control
characters. Map the appropriate Unicode code points to this code points.
Fixes rendering of grub2's menu as EFI application using the
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL on a console with bitmap fonts.
Signed-off-by: Janne Grunau
---
include/charset.h | 2 +-
include/cp1250.h | 12 ++--
include/cp437.h| 12 ++--
lib/charset.c | 9 ++---
lib/efi_loader/efi_unicode_collation.c | 2 +-
5 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/include/charset.h b/include/charset.h
index f1050c903d..348bad5883 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -16,7 +16,7 @@
/*
* codepage_437 - Unicode to codepage 437 translation table
*/
-extern const u16 codepage_437[128];
+extern const u16 codepage_437[160];
/**
* console_read_unicode() - read Unicode code point from console
diff --git a/include/cp1250.h b/include/cp1250.h
index adacf8a958..b762c78d9f 100644
--- a/include/cp1250.h
+++ b/include/cp1250.h
@@ -1,10 +1,18 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Constant CP1250 contains the Unicode code points for characters 0x80 - 0xff
- * of the code page 1250.
+ * Constant CP1250 contains the Unicode code points for characters 0x00 - 0x1f
+ * and 0x80 - 0xff of the code page 1250.
*/
#define CP1250 { \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
+ 0x, 0x, 0x, 0x, \
0x20ac, 0x, 0x201a, 0x, \
0x201e, 0x2026, 0x2020, 0x2021, \
0x, 0x2030, 0x0160, 0x2039, \
diff --git a/include/cp437.h b/include/cp437.h
index 0b2b97132e..5093130f5e 100644
--- a/include/cp437.h
+++ b/include/cp437.h
@@ -1,10 +1,18 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Constant CP437 contains the Unicode code points for characters 0x80 - 0xff
- * of the code page 437.
+ * Constant CP437 contains the Unicode code points for characters 0x00 - 0x1f
+ * and 0x80 - 0xff of the code page 437.
*/
#define CP437 { \
+ 0x, 0x263a, 0x263b, 0x2665, \
+ 0x2666, 0x2663, 0x2660, 0x2022, \
+ 0x25d8, 0x25cb, 0x25d9, 0x2642, \
+ 0x2640, 0x266a, 0x266b, 0x263c, \
+ 0x25ba, 0x25c4, 0x2195, 0x203c, \
+ 0x00b6, 0x00a7, 0x25ac, 0x21a8, \
+ 0x2191, 0x2193, 0x2192, 0x2190, \
+ 0x221f, 0x2194, 0x25b2, 0x25bc, \
0x00c7, 0x00fc, 0x00e9, 0x00e2, \
0x00e4, 0x00e0, 0x00e5, 0x00e7, \
0x00ea, 0x00eb, 0x00e8, 0x00ef, \
diff --git a/lib/charset.c b/lib/charset.c
index 5e4c4f948a..1f8480150a 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -16,7 +16,7 @@
/**
* codepage_437 - Unicode to codepage 437 translation table
*/
-const u16 codepage_437[128] = CP437;
+const u16 codepage_437[160] = CP437;
static struct capitalization_table capitalization_table[] =
#ifdef CONFIG_EFI_UNICODE_CAPITALIZATION
@@ -517,9 +517,12 @@ int utf_to_cp(s32 *c, const u16 *codepage)
int j;
/* Look up codepage translation */
- for (j = 0; j < 0x80; ++j) {
+ for (j = 0; j < 0xA0; ++j) {
if (*c == codepage[j]) {
- *c = j + 0x80;
+ if (j < 0x20)
+ *c = j;
+ else
+ *c = j + 0x60;
return 0;
}
}
diff --git a/lib/efi_loader/efi_unicode_collation.c
b/lib/efi_loader/efi_unicode_collation.c
index c4c7572063..4b2c52918a 100644
--- a/lib/efi_loader/efi_unicode_collation.c
+++ b/lib/efi_loader/efi_unicode_collation.c
@@ -257,7 +257,7 @@ static void EFIAPI efi_fat_to_str(struct
efi_unicode_collation_protocol *this,
for (i = 0; i < fat_size; ++i) {
c = (unsigned char)fat[i];
if (c > 0x80)
- c = codepage[c - 0x80];
+ c = codepage[c - 0x60];
string[i] = c;
if (!c)
break;
--
2.43.0
[PATCH v1] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions
From: Igor Opaniuk Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto Extensions. The CPU should support ARMv8.2 instruction set and implement SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions. This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that indicates support for SHA512* instructions in AArch64 state. As not all ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by default for now. Tested in QEMU for ARMv8 with compiled-in SHA-2 support. Even on emulated cpu the hashing speed increase was visible: With CE usage: => time hash sha512 0x4020 0x200 Calculate hash Calculate hash sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... time: 0.215 seconds Without CE usage: => time hash sha512 0x4020 0x200 sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37... time: 0.356 seconds Real HW tests should provide much more improvement and objective results with 10x speed increase at least. The implementation is based on original implementation from Ard Biesheuvel in Linux kernel [2] [1] https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S CC: Ard Biesheuvel CC: Loic Poulain Signed-off-by: Igor Opaniuk --- arch/arm/cpu/armv8/Kconfig | 5 + arch/arm/cpu/armv8/Makefile | 1 + arch/arm/cpu/armv8/sha512_ce_core.S | 210 arch/arm/cpu/armv8/sha512_ce_glue.c | 20 +++ lib/sha512.c| 6 +- 5 files changed, 240 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv8/sha512_ce_core.S create mode 100644 arch/arm/cpu/armv8/sha512_ce_glue.c diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 9f0fb369f7..fd5c26421b 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -204,6 +204,11 @@ config ARMV8_CE_SHA256 bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)" default y if SHA256 +config ARMV8_CE_SHA512 + bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)" + depends on SHA512 + default n + endif endif diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile index bba4f570db..3894f2bb2a 100644 --- a/arch/arm/cpu/armv8/Makefile +++ b/arch/arm/cpu/armv8/Makefile @@ -45,3 +45,4 @@ obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/ obj-$(CONFIG_XEN) += xen/ obj-$(CONFIG_ARMV8_CE_SHA1) += sha1_ce_glue.o sha1_ce_core.o obj-$(CONFIG_ARMV8_CE_SHA256) += sha256_ce_glue.o sha256_ce_core.o +obj-$(CONFIG_ARMV8_CE_SHA512) += sha512_ce_glue.o sha512_ce_core.o \ No newline at end of file diff --git a/arch/arm/cpu/armv8/sha512_ce_core.S b/arch/arm/cpu/armv8/sha512_ce_core.S new file mode 100644 index 00..906291f35b --- /dev/null +++ b/arch/arm/cpu/armv8/sha512_ce_core.S @@ -0,0 +1,210 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * sha512-ce-core.S - core SHA-384/SHA-512 transform using v8 Crypto + * Extensions + * + * Copyright (C) 2018 Linaro Ltd + * Copyright (C) 2024 Igor Opaniuk + */ + + #include + #include + #include + #include + + .macro adr_l, dst, sym + adrp\dst, \sym + add \dst, \dst, :lo12:\sym + .endm + + .irpb,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 + .set.Lq\b, \b + .set.Lv\b\().2d, \b + .endr + + .macro sha512h, rd, rn, rm + .inst 0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16) + .endm + + .macro sha512h2, rd, rn, rm + .inst 0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16) + .endm + + .macro sha512su0, rd, rn + .inst 0xcec08000 | .L\rd | (.L\rn << 5) + .endm + + .macro sha512su1, rd, rn, rm + .inst 0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16) + .endm + + /* +* The SHA-512 round constants +*/ + .section".rodata", "a" + .align 4 +.Lsha512_rcon: + .quad 0x428a2f98d728ae22, 0x7137449123ef65cd + .quad 0xb5c0fbcfec4d3b2f, 0xe9b5dba58189dbbc + .quad 0x3956c25bf348b538, 0x59f111f1b605d019 + .quad 0x923f82a4af194f9b, 0xab1c5ed5da6d8118 + .quad 0xd807aa98a3030242, 0x12835b0145706fbe + .quad 0x243185be4ee4b28c, 0x550c7dc3d5ffb4e2 + .quad 0x72be5d74f27b896f, 0x80deb1fe3b1696b1 + .quad 0x9bdc06a725c71235, 0xc19bf174cf692694 + .quad 0xe49b69c19ef14ad2, 0xefbe4786384f25e3 + .quad 0x0fc19dc68b8cd5b5, 0x240ca1cc77ac9c65 + .quad 0x2de92c6f592b0275, 0x4a7484aa6ea6e483 + .quad
Re: [PATCH RFC 4/6] efi_selftest: Add international characters test
Hej, On Thu, Jan 18, 2024, at 19:48, Heinrich Schuchardt wrote: > On 1/17/24 23:24, Janne Grunau via B4 Relay wrote: >> From: Andre Przywara >> >> UEFI relies entirely on unicode output, which actual fonts displayed on >> the screen might not be ready for. >> >> Add a test displaying some international characters, to reveal missing >> glyphs, especially in our builtin fonts. > > How would I detect missing Bengali and Gujarati glyphs with this test? Only by knowing what to expect or to check the test code. > What might help would be an output of the Unicode entries in the font in > parallel with the glyph. I'm not sure how useful it would be to extend the amount of text to register during the test. Even with the 3 second wait added in the the box drawing test time is short to check the results. Running the tests optionally with pagination might be an option. > U+0040, @ > U+0041, A > U+0A85. અ > U+0A86. આ > U+0A87. ઇ > U+0A88. ઈ > U+0A89. ઉ > > This would require some new command but not an EFI test. Wouldn't we need both? Console tests to check if the intended glyphs are shown would be useful but the EFI selftest should still tests that it can render UTF-8 correctly (partial support on cp437 bitmap font consoles). Best regards Janne
[PATCH v3 2/2] smbios: fill wake-up type
We should not use the reserved value 0x00 for the wake up type but
use 0x02 (Unknown).
Signed-off-by: Heinrich Schuchardt
---
v3:
use an enum for the constants
v2:
use wake-up type 'Unknown' as our default
add more SMBIOS wake-up type constants
---
include/smbios.h | 27 +++
lib/smbios.c | 1 +
2 files changed, 28 insertions(+)
diff --git a/include/smbios.h b/include/smbios.h
index 3df8827b60..a4fda9df7b 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -108,6 +108,33 @@ struct __packed smbios_type0 {
char eos[SMBIOS_STRUCT_EOS_BYTES];
};
+/**
+ * enum smbios_wakeup_type - wake-up type
+ *
+ * These constants are used for the Wake-Up Type field in the SMBIOS
+ * System Information (Type 1) structure.
+ */
+enum smbios_wakeup_type {
+ /** @SMBIOS_WAKEUP_TYPE_RESERVED: Reserved */
+ SMBIOS_WAKEUP_TYPE_RESERVED,
+ /** @SMBIOS_WAKEUP_TYPE_OTHER: Other */
+ SMBIOS_WAKEUP_TYPE_OTHER,
+ /** @SMBIOS_WAKEUP_TYPE_UNKNOWN: Unknown */
+ SMBIOS_WAKEUP_TYPE_UNKNOWN,
+ /** @SMBIOS_WAKEUP_TYPE_APM_TIMER: APM Timer */
+ SMBIOS_WAKEUP_TYPE_APM_TIMER,
+ /** @SMBIOS_WAKEUP_TYPE_MODEM_RING: Modem Ring */
+ SMBIOS_WAKEUP_TYPE_MODEM_RING,
+ /** @SMBIOS_WAKEUP_TYPE_LAN_REMOTE: LAN Remote */
+ SMBIOS_WAKEUP_TYPE_LAN_REMOTE,
+ /** @SMBIOS_WAKEUP_TYPE_POWER_SWITCH: Power Switch */
+ SMBIOS_WAKEUP_TYPE_POWER_SWITCH,
+ /** @SMBIOS_WAKEUP_TYPE_PCI_PME: PCI PME# */
+ SMBIOS_WAKEUP_TYPE_PCI_PME,
+ /** @SMBIOS_WAKEUP_TYPE_AC_POWER_RESTORED: AC Power Restored */
+ SMBIOS_WAKEUP_TYPE_AC_POWER_RESTORED,
+};
+
struct __packed smbios_type1 {
u8 type;
u8 length;
diff --git a/lib/smbios.c b/lib/smbios.c
index c83af730a9..b190b010f3 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -394,6 +394,7 @@ static int smbios_write_type1(ulong *current, int handle,
} else {
t->serial_number = smbios_add_prop(ctx, "serial", NULL);
}
+ t->wakeup_type = SMBIOS_WAKEUP_TYPE_UNKNOWN;
t->sku_number = smbios_add_prop(ctx, "sku", NULL);
t->family = smbios_add_prop(ctx, "family", NULL);
--
2.43.0
[PATCH v3 1/2] cmd: smbios: type 1 wake-up time, family
Correct type 1 output
* render wake up time as string
* print family string
* remove duplicate serial number output
Signed-off-by: Heinrich Schuchardt
---
v3:
no change
v2:
no change
---
cmd/smbios.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/cmd/smbios.c b/cmd/smbios.c
index 66f6b76137..d3bd8b12a6 100644
--- a/cmd/smbios.c
+++ b/cmd/smbios.c
@@ -14,6 +14,18 @@
DECLARE_GLOBAL_DATA_PTR;
+static const char * const wakeup_type_strings[] = {
+ "Reserved", /* 0x00 */
+ "Other",/* 0x01 */
+ "Unknown", /* 0x02 */
+ "APM Timer",/* 0x03 */
+ "Modem Ring", /* 0x04 */
+ "Lan Remote", /* 0x05 */
+ "Power Switch", /* 0x06 */
+ "PCI PME#", /* 0x07 */
+ "AC Power Restored",/* 0x08 */
+};
+
/**
* smbios_get_string() - get SMBIOS string from table
*
@@ -72,6 +84,14 @@ void smbios_print_str(const char *label, void *table, u8
index)
printf("\t%s: %s\n", label, smbios_get_string(table, index));
}
+const char *smbios_wakeup_type_str(u8 wakeup_type)
+{
+ if (wakeup_type >= ARRAY_SIZE(wakeup_type_strings))
+ /* Values over 0x08 are reserved. */
+ wakeup_type = 0;
+ return wakeup_type_strings[wakeup_type];
+}
+
static void smbios_print_type1(struct smbios_type1 *table)
{
printf("System Information\n");
@@ -81,11 +101,12 @@ static void smbios_print_type1(struct smbios_type1 *table)
smbios_print_str("Serial Number", table, table->serial_number);
if (table->length >= 0x19) {
printf("\tUUID: %pUl\n", table->uuid);
- smbios_print_str("Wake Up Type", table, table->serial_number);
+ printf("\tWake-up Type: %s\n",
+ smbios_wakeup_type_str(table->wakeup_type));
}
if (table->length >= 0x1b) {
- smbios_print_str("Serial Number", table, table->serial_number);
smbios_print_str("SKU Number", table, table->sku_number);
+ smbios_print_str("Family", table, table->family);
}
}
--
2.43.0
[PATCH v3 0/2] smbios: fill wake-up type
We should not use the reserved value 0x00 for the wake up type but use 0x06 (Power Switch). Correctly display wake-up type in smbios command. Display SMBIOS type 1 field family in smbios command. v3: provide an enum for the wake-up type constants v2: use wake-up type 0x02 as our default *** BLURB HERE *** Heinrich Schuchardt (2): cmd: smbios: type 1 wake-up time, family smbios: fill wake-up type cmd/smbios.c | 25 +++-- include/smbios.h | 27 +++ lib/smbios.c | 1 + 3 files changed, 51 insertions(+), 2 deletions(-) -- 2.43.0
Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399
Hi Chen-Yu, For the entire series: Reviewed-by: Christopher Obbard On 10 February 2024 06:32:46 GMT, Chen-Yu Tsai wrote: >From: Chen-Yu Tsai > >Hi folks, > >This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328 >and RK3399 so that the cpuid is read from the efuse and used to generate >a serial number and MAC addresses for all boards. > >This stacks on top of the recent defconfig update series [1] from Jonas. > >[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/ > > >Chen-Yu Tsai (4): > rockchip: rk3328: Read cpuid and generate MAC address from efuse > rockchip: rk3399: Read cpuid and generate MAC address from efuse > rockchip: rk3328: regenerate defconfigs > rockchip: rk3399: regenerate defconfigs > > arch/arm/mach-rockchip/Kconfig| 4 > configs/chromebook_bob_defconfig | 2 -- > configs/chromebook_kevin_defconfig| 2 -- > configs/evb-rk3328_defconfig | 2 -- > configs/firefly-rk3399_defconfig | 2 -- > configs/nanopi-r2c-plus-rk3328_defconfig | 2 -- > configs/nanopi-r2c-rk3328_defconfig | 2 -- > configs/nanopi-r2s-rk3328_defconfig | 2 -- > configs/nanopi-r4s-rk3399_defconfig | 2 -- > configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 -- > configs/orangepi-r1-plus-rk3328_defconfig | 2 -- > configs/pinebook-pro-rk3399_defconfig | 2 -- > configs/pinephone-pro-rk3399_defconfig| 2 -- > configs/puma-rk3399_defconfig | 2 -- > configs/roc-cc-rk3328_defconfig | 2 -- > configs/roc-pc-mezzanine-rk3399_defconfig | 2 -- > configs/roc-pc-rk3399_defconfig | 2 -- > configs/rock-4c-plus-rk3399_defconfig | 3 --- > configs/rock-4se-rk3399_defconfig | 3 --- > configs/rock-pi-4-rk3399_defconfig| 3 --- > configs/rock-pi-4c-rk3399_defconfig | 3 --- > configs/rock-pi-e-rk3328_defconfig| 2 -- > configs/rock-pi-n10-rk3399pro_defconfig | 1 - > configs/rock64-rk3328_defconfig | 2 -- > configs/rock960-rk3399_defconfig | 1 - > configs/rockpro64-rk3399_defconfig| 2 -- > 26 files changed, 4 insertions(+), 52 deletions(-) > >-- >2.39.2 >
