RE: [PATCH 4/4] fit: Use DM hash driver if supported
Hi Alex,
> From: Alex G.
> Sent: Friday, September 17, 2021 12:00 AM
>
> On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
> > Calculate hash using DM driver if supported.
> > For backward compatibility, the call to legacy hash functions is
> > reserved.
> >
> > Signed-off-by: Chia-Wei Wang
> > ---
> > common/image-fit.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/common/image-fit.c b/common/image-fit.c index
> > d6b2c3c7ec..ec2e526356 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -25,6 +25,10 @@
> > #include
> > #include
> > #include
> > +#ifdef CONFIG_DM_HASH
> > +#include
> > +#include
> > +#endif
> > DECLARE_GLOBAL_DATA_PTR;
> > #endif /* !USE_HOSTCC*/
> >
> > @@ -1214,6 +1218,31 @@ int fit_set_timestamp(void *fit, int noffset,
> time_t timestamp)
> > int calculate_hash(const void *data, int data_len, const char *algo,
> > uint8_t *value, int *value_len)
> > {
> > +#if !defined(USE_HOSTCC) && defined(CONFIG_DM_HASH)
>
> This file is shared in its entirety with host tools. There isn't a huge
> opportunity
> for using a DM-type approach here without #ifndef USE_HOSTCC.
>
There are still clean up missions to make U-boot bootloader to move on to the
DM-based approach.
For instance, when a FIT image is verified by a hash digest, the hash is
calculated by calculate_hash() in image-fit.c.
However, when a FIT image is verified by a signature, the hash comes from
hash_calculate() in hash-checksum.c.
In my personal opinion, a consistent way to calculate hash for U-Boot
bootloader would be better for maintenance.
To make this transition more smoothly, currently the USE_HOSTCC and
CONFIG_DM_HASH are added in an ad-hoc way.
Chiawei
> > + int rc;
> > + enum HASH_ALGO hash_algo;
> > + struct udevice *dev;
> > +
> > + rc = uclass_get_device(UCLASS_HASH, 0, &dev);
> > + if (rc) {
> > + debug("failed to get hash device, rc=%d\n", rc);
> > + return -1;
> > + }
> > +
> > + hash_algo = hash_algo_lookup_by_name(algo);
> > + if (hash_algo == HASH_ALGO_INVALID) {
> > + debug("Unsupported hash algorithm\n");
> > + return -1;
> > + };
> > +
> > + rc = hash_digest_wd(dev, hash_algo, data, data_len, value, CHUNKSZ);
> > + if (rc) {
> > + debug("failed to get hash value, rc=%d\n", rc);
> > + return -1;
> > + }
> > +
> > + *value_len = hash_algo_digest_size(hash_algo); #else
> > if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
> > *((uint32_t *)value) = crc32_wd(0, data, data_len,
> > CHUNKSZ_CRC32);
> > @@ -1242,6 +1271,7 @@ int calculate_hash(const void *data, int data_len,
> const char *algo,
> > debug("Unsupported hash alogrithm\n");
> > return -1;
> > }
> > +#endif
> > return 0;
> > }
> >
> >
RE: [PATCH 3/4] crypto: hash: Add software hash DM driver
Hi Alex,
> From: Alex G.
> Sent: Thursday, September 16, 2021 11:49 PM
>
> On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
> > Add purely software-implmented drivers to support multiple hash
> > operations including CRC, MD5, and SHA family.
> >
> > This driver is based on the new hash uclass.
> >
> > Signed-off-by: Chia-Wei Wang
> > ---
> > drivers/crypto/hash/Kconfig | 11 ++
> > drivers/crypto/hash/Makefile | 1 +
> > drivers/crypto/hash/hash_sw.c | 301
> ++
> > 3 files changed, 313 insertions(+)
> > create mode 100644 drivers/crypto/hash/hash_sw.c
> >
> > diff --git a/drivers/crypto/hash/Kconfig b/drivers/crypto/hash/Kconfig
> > index e226144b9b..cd29a5c6a4 100644
> > --- a/drivers/crypto/hash/Kconfig
> > +++ b/drivers/crypto/hash/Kconfig
> > @@ -3,3 +3,14 @@ config DM_HASH
> > depends on DM
> > help
> > If you want to use driver model for Hash, say Y.
> > +
> > +config HASH_SOFTWARE
> > + bool "Enable driver for Hash in software"
> > + depends on DM_HASH
> > + depends on MD5
> > + depends on SHA1
> > + depends on SHA256
> > + depends on SHA512_ALGO
>
> I would have expected a U_BOOT_DRIVER() for each hash algo, rather than a
> U_BOOT_DRIVER() wich encompassess all possible algos. If I'm trying to use
> SHA256 in SPL, I might not have the room too add SHA1 and MD5, so I'd have
> issues using HASH_SOFTWARE, as designed.
I agree with the SPL size issue.
A future patches to move those CONFIG_SHAxxx/CONFIG_MD5 options into the
DM-based hash_sw.c could be an option.
Thus the balance between the hash algos support and the code size can be
managed.
>
> > diff --git a/drivers/crypto/hash/hash_sw.c
> > b/drivers/crypto/hash/hash_sw.c new file mode 100644 index
> > 00..fea9d12609
> > --- /dev/null
> > +++ b/drivers/crypto/hash/hash_sw.c
> > @@ -0,0 +1,301 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2021 ASPEED Technology Inc.
> > + * Author: ChiaWei Wang */ #include
> > + #include #include #include
> > +#include #include #include
> > +#include #include #include
> > + #include #include
> > +
> > +/* CRC16-CCITT */
> > +static void hash_init_crc16_ccitt(void *ctx) {
> > + *((uint16_t *)ctx) = 0;
>
> Undefined behavior: Pointer aliased type-punning. I would suggest using
> memset(). Might not be necessarrym as expleined in the next comment.
>
> > +static void hash_update_crc16_ccitt(void *ctx, const void *ibuf,
> > +uint32_t ilen) static void hash_finish_crc16_ccitt(void *ctx, void
> > +*obuf)
> > +/* CRC32 */
> > +static void hash_init_crc32(void *ctx) static void
> > +hash_update_crc32(void *ctx, const void *ibuf, uint32_t ilen) static
> > +void hash_finish_crc32(void *ctx, void *obuf)
> > +/* SHA1 */
> > +static void hash_init_sha1(void *ctx)
> > +/* SHA256 */
> > +/* SHA384 */
> > +/* SHA512 */
>
> This logic already exists in common/hash.c for hash_Lookup_algo() and
> hash_progressive_algo().
Yes.
To prevent modifying the 'static' keyword in common/hash.c while reusing the
hash lib, the same logic appears in the DM-based hash_sw.c.
Chiawei
RE: [PATCH 2/4] dm: hash: Add new UCLASS_HASH support
Hi Alex,
> From: Alex G.
> Sent: Thursday, September 16, 2021 11:43 PM
>
> Hi,
>
> On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
> > Add UCLASS_HASH for hash driver development. Thus the hash drivers (SW
> > or HW-accelerated) can be developed in the DM-based fashion.
>
> Software hashing implementations are shared tightly with host tools.
> With DM, there's no opportunity for code sharing with host tools. The design
> question that I have is "do we want to DM hashes, or do we want to DM
> hardware accelerators for hashes?"
>
> I did some parallel work expose remaining hash algos via
> hash_lookup_algo() and hash_progressive_lookup_algo().
DM-based approach is mainly for the U-Boot bootloader part.
A consistent, abstract interface is therefore available for vendor drivers
regardless of the hashing are conducted in the SW or HW-assisted fashion.
And the CONFIG_SHAxxx_HW_ACCEL/CONFIG_SHA_PROG_HW_ACCEL options can be dropped.
Most of the current DM-based, SW hash driver implementation reuses the code of
hash lib.
The code sharing benefit is still greatly leveraged.
>
> > Signed-off-by: Chia-Wei Wang
> > ---
> > drivers/crypto/Kconfig| 2 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/hash/Kconfig | 5 ++
> > drivers/crypto/hash/Makefile | 5 ++
> > drivers/crypto/hash/hash-uclass.c | 121
> ++
> > include/dm/uclass-id.h| 1 +
> > include/u-boot/hash.h | 61 +++
> > 7 files changed, 196 insertions(+)
> > create mode 100644 drivers/crypto/hash/Kconfig
> > create mode 100644 drivers/crypto/hash/Makefile
> > create mode 100644 drivers/crypto/hash/hash-uclass.c
> > create mode 100644 include/u-boot/hash.h
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index
> > 1ea116be75..0082177c21 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -1,5 +1,7 @@
> > menu "Hardware crypto devices"
> >
> > +source drivers/crypto/hash/Kconfig
> > +
> Hashes are useful outside of cryptographic functions, so it seems odd to merge
> them in crypto. For example, CRC32 is not a hash useful in crypto, but
> otherwise widely used in u-boot.
Certain systems have the hash functionality included in their crypto engine.
(e.g. ARM, FSL, ASPEED, etc.)
Based on this observation, the DM hash driver is placed under crypto/.
However, it is OK for me to move the hash/ out of crypto/ if a more specific
place is created and preferred.
>
> [snip]
> > diff --git a/drivers/crypto/hash/hash-uclass.c
> > b/drivers/crypto/hash/hash-uclass.c
> > new file mode 100644
> > index 00..446eb9e56a
> > --- /dev/null
> > +++ b/drivers/crypto/hash/hash-uclass.c
> > @@ -0,0 +1,121 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2021 ASPEED Technology Inc.
> > + * Author: ChiaWei Wang */
> > +
> > +#define LOG_CATEGORY UCLASS_HASH
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct hash_info {
> > + char *name;
> > + uint32_t digest_size;
> > +};
> > +
> > +static const struct hash_info hash_info[HASH_ALGO_NUM] = {
> > + [HASH_ALGO_CRC16_CCITT] = { "crc16-ccitt", 2 },
> > + [HASH_ALGO_CRC32] = { "crc32", 4 },
> > + [HASH_ALGO_MD5] = { "md5", 16 },
> > + [HASH_ALGO_SHA1] = { "sha1", 20 },
> > + [HASH_ALGO_SHA256] = { "sha256", 32 },
> > + [HASH_ALGO_SHA384] = { "sha384", 48 },
> > + [HASH_ALGO_SHA512] = { "sha512", 64}, };
>
> It seems a step backwards to have to enum {} our hash algos, since we already
> identify them by their strings (e.g. "sha256"). and then associated ops
> structure.
> The
>
> > +
> > +enum HASH_ALGO hash_algo_lookup_by_name(const char *name)
>
> string -> hash_lookup_algo() -> ops struct
>
> Is the current way to do things. hash_algo_lookup_by_name() does the
> roundabout through an enum. That doesn't make sense to me.
>
The common hash-uclass.c also provides the string_to_enum conversion.
Both the DM-based hash driver works on both the string-based and enum-based
scenario.
Chiawei
Re: Question about extension board used in U-boot
Hi Heinrich, I think I met some chicken and egg problem. Or I misunderstand something you mentioned. So I tried board_fdt_blob_setup() and board_fix_fdt(). Both are too early. I need i2c to be drived first. And then I can use dm_i2c_probe() on different address to detect which extension board it is. However, in board_fdt_blob_setup() or board_fix_fdt(). i2c seems not working there. I can do the detection in board_late_init() but it is just too late for U-boot itself. Good for Linux kernel though. Sorry for my bad English. Measured boot is already working on my branch. But the way I implemented this is directly modify the dts of U-boot and assume the TPM extension board is always there. Thus this is not upstreamable. I think let me upstream some code by extension manager first (for linux kernel first). And then we can see how the detection is implemented and how to modify it for U-boot. Thanks, Paul Heinrich Schuchardt 於 2021/9/18 下午3:14 寫道: > > > On 9/18/21 8:54 AM, François Ozog wrote: >> Le sam. 18 sept. 2021 à 08:49, François Ozog >> a >> écrit : >> >>> Hi Paul >>> >>> Too posting because I think we also need to address this at a higher >>> level. >>> >>> i think we discussed this topic quite a while back. I may be wrong >>> but it >>> may be Bill Mills who proposed to have an eeprom on the extensions >>> that the >>> carrier board can use to detect and fetch proper overlay. Another >>> way would >>> be that the contract between the extension board and the carrier board >>> includes an i2c accessible storage to fetch an overlay that would >>> identify >>> the board and give all details. >>> >> i just forgot to state that the mode is well known: SPD for DIMMs. >> >>> Bottom line, a software only solution seems not entirely satisfying. >>> In that suboptimal case, U-Boot shall be able to assemble a DT for >>> itself >>> and another for OS (may be same in some cases) through scripting. >>> And in >>> this case, come your questions below >>> >>> . >>> >>> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) >>> >>> a écrit : >>> Hi all, I have some questions about how to implement extension board usage. My case is on imx8mm-cl-iot-gate. It can add three different types of extension boards. One of the extension boards is SPI extension which have 3 empty slots. And you can add some small boards onto it. One of them is a "TPM2" module. > > You could implement the weak function board_fdt_blob_setup() to detect > your addon boards and extend the devicetree. > > My first question is if I want to use tpm2 in U-boot for measured boot. How to implement this right? Currently I just modify the dts used by U-boot to let it drive > > Measured boot is provided in U-Boot v2021.10-rc4 based on TPMv2. Just > enable CONFIG_EFI_TCG2_PROTOCOL. > the extension board. And let it drive the TPM. But it is not good for upstreaming because when other types of extension boards installed then it is not working. Where to implement this? What is the best practice of this? >>> >>> The second question is about extension manager. I have read the extension.rst. I think I'll implement this anyway because then I can have a command to query what type of extension boards I have. And if the extension board is the 3 slots one. I can then detect which slot is the TPM. I'll implement this anyway because the "extension" command is convenient for users. But it seems to me that it only solves the problem for Linux kernel. It can apply a DTB Overlay to Linux DTB to let Linux knows we have that extension board. But it is too late for U-boot itself, right? The third question is I'm also dong SystemReady IR certificate. That means the dtb for Linux is directly provided by U-boot. We use U-boot dtb directly to Linux kernel. In this case, how to modify that dts dynamically to feed to the Linux kernel by the extension manager? > > U-Boot has a fdt command which you could use to apply overlays. Or > implement function board_fdt_blob_setup(). > > Best regards > > Heinrich > What is the best practice if I want to use U-boot dts for Linux in implementation? Thanks a lot. Yours, Paul -- >>> François-Frédéric Ozog | *Director Business Development* >>> T: +33.67221.6485 >>> francois.o...@linaro.org | Skype: ffozog >>> >>> -- >> François-Frédéric Ozog | *Director Business Development* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> ___ >> boot-architecture mailing list >> boot-architect...@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/boot-architecture >> OpenPGP_signature Description: OpenPGP digital signature
Status of the various RISC-V specification and policy
Hi All, Please find the below email from Stephano about the freeze announcement for various RISC-V specifications that will be part of privilege specification v1.12. All the review discussions are happening in the isa-dev mailing list. The review period will be open for 45 days ending Sunday October 31, 2021. I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions are frozen now. *This will help us merge some patches that have been present in the mailing list for a while. Here are the ratification policy and extension life cycle documents present in the public. If you have any questions regarding this, please check with Mark/Stephano (cc'd). Ratification policy: https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit Extension life cycle: https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 -- Regards, Atish Mail from Stephano: -- Subject: Privileged Specification 1.12 Freeze Milestone: Public Review All, The Privileged Specification version 1.12 has gone to public review. You can view the specification documents by following the links provided here: https://docs.google.com/document/d/1soGI__HytotOkoJtgTYD0nzf82Zhp5nWw1Mcgqvbn8o/edit?usp=sharing Review discussion can be followed on the ISA-DEV mailing list here: https://groups.google.com/a/groups.riscv.org/g/isa-dev The review period will be open for 45 days ending Sunday October 31, 2021. We encourage all conversation to happen on this mailing list. Simply reply to the posts linked above with any questions or comments. If you feel that you have a topic that is best discussed internally with RISC-V members only, please contact me directly. Kind Regards, Stephano -- Stephano Cetola Director of Technical Programs RISC-V International
Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification
> Since it doesn't seem possible to have each boot component using the same log > format, we added a log_format and log_phys_addr fields to give flexibility in > how logs are stored. An example of a different log format that can be used is > the cbmem_console log format used by coreboot: I am not exactly sure how you expect this interoperability you seem to be suggesting here to work. Are you saying that your bf_log_header can sometimes point to the bf_log_buffer structure you define, and sometimes to a coreboot CBMEM console buffer? But that's a completely different format that requires a different reader implementation, how is that supposed to work? If this proposal is just "we define a wrapper structure that points to everyone's custom firmware log implementation", then I don't really see the point (the only benefit still left then might be discovery of the log buffer, but that's the part you leave open in your design while all those other implementations already have working discovery mechanisms of their own anyway). For the other structures you have defined, the same feedback that I think was already mentioned on the last iteration of this thread still applies: it seems incredibly bloated for a simple firmware logging mechanism. You have a whooping 24+n bytes of overhead *per line* which probably comes out to somewhere between 30-50% of total space wasted on overhead for the average log buffer. I guess there are just fundamentally different opinions on how featureful a firmware log mechanism needs to be so we're probably not gonna find a format that makes everyone happy here, but at least for the coreboot project I see little reason for us to implement something like this when we already have a well-working existing solution with tooling and wideranged support.
Re: [PATCH] Taking over responsibility for GE boards from Sebastian
Hi, On Tue, Sep 21, 2021 at 05:35:06PM +0100, Martyn Welch wrote: > I am taking over responsibility for the GE board from Sebastian Reichel. > Updating the MAINTAINERS files to reflect this. > > Signed-off-by: Martyn Welch Acked-by: Sebastian Reichel -- Sebastian > --- > board/ge/b1x5v2/MAINTAINERS | 2 +- > board/ge/bx50v3/MAINTAINERS | 2 +- > board/ge/mx53ppd/MAINTAINERS | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/board/ge/b1x5v2/MAINTAINERS b/board/ge/b1x5v2/MAINTAINERS > index f22d492835..3196ddbb51 100644 > --- a/board/ge/b1x5v2/MAINTAINERS > +++ b/board/ge/b1x5v2/MAINTAINERS > @@ -1,7 +1,7 @@ > GE B1X5V2 BOARD > M: Huan 'Kitty' Wang > M: Ian Ray > -M: Sebastian Reichel > +M: Martyn Welch > S: Maintained > F: arch/arm/dts/imx6dl-b1x5v2.dts > F: board/ge/b1x5v2/ > diff --git a/board/ge/bx50v3/MAINTAINERS b/board/ge/bx50v3/MAINTAINERS > index fafbd78c2a..c165048336 100644 > --- a/board/ge/bx50v3/MAINTAINERS > +++ b/board/ge/bx50v3/MAINTAINERS > @@ -1,6 +1,6 @@ > GE BX50V3 BOARD > M: Ian Ray > -M: Sebastian Reichel > +M: Martyn Welch > S: Maintained > F: arch/arm/dts/imx6q-b450v3.dts > F: arch/arm/dts/imx6q-b650v3.dts > diff --git a/board/ge/mx53ppd/MAINTAINERS b/board/ge/mx53ppd/MAINTAINERS > index 2c06c8ee86..146a460e7e 100644 > --- a/board/ge/mx53ppd/MAINTAINERS > +++ b/board/ge/mx53ppd/MAINTAINERS > @@ -1,7 +1,7 @@ > GE PPD BOARD > M: Antti Mäentausta > M: Ian Ray > -M: Sebastian Reichel > +M: Martyn Welch > S: Maintained > F: arch/arm/dts/imx53-ppd* > F: board/ge/mx53ppd/ > -- > 2.33.0 > signature.asc Description: PGP signature
Re: [PATCH] configs: Migrate CONFIG_ST_SMI to Kconfig
On Tue, Sep 21, 2021 at 06:36:03PM +0200, Patrick Delaunay wrote:
> Use moveconfig.py script to convert the define CONFIG_ST_SMI to Kconfig
> and move this entries to defconfigs.
>
> Before migration, the st_smi.c driver was empty when CONFIG_MTD_NOR_FLASH
> wasn't activated; it is now managed in Kconfig by the "depends on" and
> this driver is not compiled.
>
> After this patch, the driver st_smic.c is no more used in U-Boot;
> it was only used in SPEAr products before commit 570c3dcfc153 ("arm:
> Remove spear600 boards and the rest of SPEAr support").
>
> Signed-off-by: Patrick Delaunay
> ---
> In the first migration process (without depends on) the config
> CONFIG_ST_SMI was added in bcm7445_defconfig and bcm7260_defconfig.
>
> But after adding the "depends on MTD_NOR_FLASH" and a Rsync all defconfig
> files using moveconfig.py the CONFIG_ST_SMI is also deactivated in these
> 2 last users:
> - bcm7260_defconfig
> - bcm7445_defconfig
>
> The U-Boot size don't change for these 2 defconfig (tested with buildman).
Thanks for doing a migration. But, since you've found this is dead
code now, it would make more sense to just delete the driver.
--
Tom
signature.asc
Description: PGP signature
[PATCH] Taking over responsibility for GE boards from Sebastian
I am taking over responsibility for the GE board from Sebastian Reichel. Updating the MAINTAINERS files to reflect this. Signed-off-by: Martyn Welch --- board/ge/b1x5v2/MAINTAINERS | 2 +- board/ge/bx50v3/MAINTAINERS | 2 +- board/ge/mx53ppd/MAINTAINERS | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/board/ge/b1x5v2/MAINTAINERS b/board/ge/b1x5v2/MAINTAINERS index f22d492835..3196ddbb51 100644 --- a/board/ge/b1x5v2/MAINTAINERS +++ b/board/ge/b1x5v2/MAINTAINERS @@ -1,7 +1,7 @@ GE B1X5V2 BOARD M: Huan 'Kitty' Wang M: Ian Ray -M: Sebastian Reichel +M: Martyn Welch S: Maintained F: arch/arm/dts/imx6dl-b1x5v2.dts F: board/ge/b1x5v2/ diff --git a/board/ge/bx50v3/MAINTAINERS b/board/ge/bx50v3/MAINTAINERS index fafbd78c2a..c165048336 100644 --- a/board/ge/bx50v3/MAINTAINERS +++ b/board/ge/bx50v3/MAINTAINERS @@ -1,6 +1,6 @@ GE BX50V3 BOARD M: Ian Ray -M: Sebastian Reichel +M: Martyn Welch S: Maintained F: arch/arm/dts/imx6q-b450v3.dts F: arch/arm/dts/imx6q-b650v3.dts diff --git a/board/ge/mx53ppd/MAINTAINERS b/board/ge/mx53ppd/MAINTAINERS index 2c06c8ee86..146a460e7e 100644 --- a/board/ge/mx53ppd/MAINTAINERS +++ b/board/ge/mx53ppd/MAINTAINERS @@ -1,7 +1,7 @@ GE PPD BOARD M: Antti Mäentausta M: Ian Ray -M: Sebastian Reichel +M: Martyn Welch S: Maintained F: arch/arm/dts/imx53-ppd* F: board/ge/mx53ppd/ -- 2.33.0
[PATCH] configs: Migrate CONFIG_ST_SMI to Kconfig
Use moveconfig.py script to convert the define CONFIG_ST_SMI to Kconfig
and move this entries to defconfigs.
Before migration, the st_smi.c driver was empty when CONFIG_MTD_NOR_FLASH
wasn't activated; it is now managed in Kconfig by the "depends on" and
this driver is not compiled.
After this patch, the driver st_smic.c is no more used in U-Boot;
it was only used in SPEAr products before commit 570c3dcfc153 ("arm:
Remove spear600 boards and the rest of SPEAr support").
Signed-off-by: Patrick Delaunay
---
In the first migration process (without depends on) the config
CONFIG_ST_SMI was added in bcm7445_defconfig and bcm7260_defconfig.
But after adding the "depends on MTD_NOR_FLASH" and a Rsync all defconfig
files using moveconfig.py the CONFIG_ST_SMI is also deactivated in these
2 last users:
- bcm7260_defconfig
- bcm7445_defconfig
The U-Boot size don't change for these 2 defconfig (tested with buildman).
drivers/mtd/Kconfig | 7 +++
drivers/mtd/st_smi.c | 3 ---
include/configs/bcmstb.h | 1 -
scripts/config_whitelist.txt | 1 -
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index b303fabe0f..9ba163bdab 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -109,6 +109,13 @@ config HBMC_AM654
This is the driver for HyperBus controller on TI's AM65x and
other SoCs
+config ST_SMI
+ bool "SMI driver"
+ depends on MTD_NOR_FLASH
+ help
+ This enables access to the serial memory interface controller (SMI)
+ used in STMicroelectronics SPEAr products.
+
source "drivers/mtd/nand/Kconfig"
source "drivers/mtd/spi/Kconfig"
diff --git a/drivers/mtd/st_smi.c b/drivers/mtd/st_smi.c
index 7c652e6c53..9b9393fbb1 100644
--- a/drivers/mtd/st_smi.c
+++ b/drivers/mtd/st_smi.c
@@ -13,8 +13,6 @@
#include
#include
-#if defined(CONFIG_MTD_NOR_FLASH)
-
static struct smi_regs *const smicntl =
(struct smi_regs * const)CONFIG_SYS_SMI_BASE;
static ulong bank_base[CONFIG_SYS_MAX_FLASH_BANKS] =
@@ -562,4 +560,3 @@ int flash_erase(flash_info_t *info, int s_first, int s_last)
puts(" done\n");
return rcode;
}
-#endif
diff --git a/include/configs/bcmstb.h b/include/configs/bcmstb.h
index 7f1c298cdc..54e5655af6 100644
--- a/include/configs/bcmstb.h
+++ b/include/configs/bcmstb.h
@@ -127,7 +127,6 @@ extern phys_addr_t prior_stage_fdt_address;
/*
* Flash configuration.
*/
-#define CONFIG_ST_SMI
#define CONFIG_SPI_FLASH_STMICRO
#define CONFIG_SPI_FLASH_MACRONIX
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 36b8cc1db0..6c8277cba9 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1308,7 +1308,6 @@ CONFIG_STM32_FLASH
CONFIG_STV0991
CONFIG_STV0991_HZ
CONFIG_STV0991_HZ_CLOCK
-CONFIG_ST_SMI
CONFIG_SXNI855T
CONFIG_SYSFS
CONFIG_SYSMGR_ISWGRP_HANDOFF
--
2.25.1
[PATCH] MAINTAINERS: remove SPEAR entry
As the lastest spear directories are removed, delete the associated entry
in the MAINTAINERS file:
- arch/arm/cpu/arm926ejs/spear/
- arch/arm/include/asm/arch-spear/
Fixes: 570c3dcfc153 ("arm: Remove spear600 boards and the rest of SPEAr
support")
Signed-off-by: Patrick Delaunay
---
MAINTAINERS | 7 ---
1 file changed, 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5e8693f877..70931e25a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -412,13 +412,6 @@ F: include/dt-bindings/clock/stih407-clks.h
F: include/dt-bindings/clock/stih410-clks.h
F: include/dt-bindings/reset/stih407-resets.h
-ARM STM SPEAR
-#M:Vipin Kumar
-S: Orphaned (Since 2016-02)
-T: git https://source.denx.de/u-boot/custodians/u-boot-stm.git
-F: arch/arm/cpu/arm926ejs/spear/
-F: arch/arm/include/asm/arch-spear/
-
ARM STM STM32MP
M: Patrick Delaunay
M: Patrice Chotard
--
2.25.1
Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC
> From: Bin Meng > Date: Tue, 21 Sep 2021 23:53:10 +0800 > > On Tue, Sep 21, 2021 at 8:42 PM Tom Rini wrote: > > > > On Sun, Sep 19, 2021 at 10:33:25PM +0200, Mark Kettenis wrote: > > > > From: Bin Meng > > > > Date: Sun, 19 Sep 2021 09:17:07 +0800 > > > > > > > > Hi Mark, > > > > > > > > On Sun, Sep 19, 2021 at 9:04 AM Bin Meng wrote: > > > > > > > > > > Hi Mark, > > > > > > > > > > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis > > > > > wrote: > > > > > > > > > > > > Add support for Apple's M1 SoC that is used in "Apple Silicon" > > > > > > Macs. This builds a basic U-Boot that can be used as a payload > > > > > > for the m1n1 boot loader being developed by the Asahi Linux > > > > > > project. > > > > > > > > > > > > Signed-off-by: Mark Kettenis > > > > > > --- > > > > > > arch/arm/Kconfig| 22 > > > > > > arch/arm/Makefile | 1 + > > > > > > arch/arm/mach-apple/Kconfig | 18 > > > > > > arch/arm/mach-apple/Makefile| 4 + > > > > > > arch/arm/mach-apple/board.c | 158 > > > > > > > > > > > > arch/arm/mach-apple/lowlevel_init.S | 16 +++ > > > > > > configs/apple_m1_defconfig | 14 +++ > > > > > > include/configs/apple.h | 38 +++ > > > > > > 8 files changed, 271 insertions(+) > > > > > > create mode 100644 arch/arm/mach-apple/Kconfig > > > > > > create mode 100644 arch/arm/mach-apple/Makefile > > > > > > create mode 100644 arch/arm/mach-apple/board.c > > > > > > create mode 100644 arch/arm/mach-apple/lowlevel_init.S > > > > > > create mode 100644 configs/apple_m1_defconfig > > > > > > create mode 100644 include/configs/apple.h > > > > > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > > > > index b5bd3284cd..7cdea1f615 100644 > > > > > > --- a/arch/arm/Kconfig > > > > > > +++ b/arch/arm/Kconfig > > > > > > @@ -895,6 +895,26 @@ config ARCH_NEXELL > > > > > > select DM > > > > > > select GPIO_EXTRA_HEADER > > > > > > > > > > > > +config ARCH_APPLE > > > > > > + bool "Apple SoCs" > > > > > > + select ARM64 > > > > > > + select LINUX_KERNEL_IMAGE_HEADER > > > > > > + select POSITION_INDEPENDENT > > > > > > + select BLK > > > > > > + select DM > > > > > > + select DM_KEYBOARD > > > > > > + select DM_SERIAL > > > > > > + select DM_USB > > > > > > + select DM_VIDEO > > > > > > + select CMD_USB > > > > > > + select MISC > > > > > > + select OF_CONTROL > > > > > > + select OF_BOARD > > > > > > + select USB > > > > > > + imply CMD_DM > > > > > > + imply CMD_GPT > > > > > > + imply DISTRO_DEFAULTS > > > > > > + > > > > > > config ARCH_OWL > > > > > > bool "Actions Semi OWL SoCs" > > > > > > select DM > > > > > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR > > > > > > image headers. > > > > > > endif > > > > > > > > > > > > +source "arch/arm/mach-apple/Kconfig" > > > > > > + > > > > > > source "arch/arm/mach-aspeed/Kconfig" > > > > > > > > > > > > source "arch/arm/mach-at91/Kconfig" > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > > index c68e598a67..44178c204b 100644 > > > > > > --- a/arch/arm/Makefile > > > > > > +++ b/arch/arm/Makefile > > > > > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y) > > > > > > > > > > > > # Machine directory name. This list is sorted alphanumerically > > > > > > # by CONFIG_* macro name. > > > > > > +machine-$(CONFIG_ARCH_APPLE) += apple > > > > > > machine-$(CONFIG_ARCH_ASPEED) += aspeed > > > > > > machine-$(CONFIG_ARCH_AT91)+= at91 > > > > > > machine-$(CONFIG_ARCH_BCM283X) += bcm283x > > > > > > diff --git a/arch/arm/mach-apple/Kconfig > > > > > > b/arch/arm/mach-apple/Kconfig > > > > > > new file mode 100644 > > > > > > index 00..66cab91b2a > > > > > > --- /dev/null > > > > > > +++ b/arch/arm/mach-apple/Kconfig > > > > > > @@ -0,0 +1,18 @@ > > > > > > +if ARCH_APPLE > > > > > > + > > > > > > +config SYS_TEXT_BASE > > > > > > + default 0x > > > > > > + > > > > > > +config SYS_CONFIG_NAME > > > > > > + default "apple" > > > > > > + > > > > > > +config SYS_SOC > > > > > > + default "m1" > > > > > > + > > > > > > +config SYS_MALLOC_LEN > > > > > > + default 0x400 > > > > > > + > > > > > > +config SYS_MALLOC_F_LEN > > > > > > + default 0x4000 > > > > > > + > > > > > > +endif > > > > > > diff --git a/arch/arm/mach-apple/Makefile > > > > > > b/arch/arm/mach-apple/Makefile > > > > > > new file mode 100644 > > > > > > index 00..e74a8c9df1 > > > > > > --- /dev/null > > > > > > +++ b/arch/arm/mach-apple/Makefile > > > > > > @@ -0,0 +1,4 @@ > > > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > > > + > > > > > > +obj-y += board.o > > > > > > +obj-y += lowlevel_init.o > > > > > > diff --git a/arch/arm/mach-apple/board.c > > > > > >
Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC
On Tue, Sep 21, 2021 at 11:53:10PM +0800, Bin Meng wrote: > On Tue, Sep 21, 2021 at 8:42 PM Tom Rini wrote: > > > > On Sun, Sep 19, 2021 at 10:33:25PM +0200, Mark Kettenis wrote: > > > > From: Bin Meng > > > > Date: Sun, 19 Sep 2021 09:17:07 +0800 > > > > > > > > Hi Mark, > > > > > > > > On Sun, Sep 19, 2021 at 9:04 AM Bin Meng wrote: > > > > > > > > > > Hi Mark, > > > > > > > > > > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis > > > > > wrote: > > > > > > > > > > > > Add support for Apple's M1 SoC that is used in "Apple Silicon" > > > > > > Macs. This builds a basic U-Boot that can be used as a payload > > > > > > for the m1n1 boot loader being developed by the Asahi Linux > > > > > > project. > > > > > > > > > > > > Signed-off-by: Mark Kettenis > > > > > > --- > > > > > > arch/arm/Kconfig| 22 > > > > > > arch/arm/Makefile | 1 + > > > > > > arch/arm/mach-apple/Kconfig | 18 > > > > > > arch/arm/mach-apple/Makefile| 4 + > > > > > > arch/arm/mach-apple/board.c | 158 > > > > > > > > > > > > arch/arm/mach-apple/lowlevel_init.S | 16 +++ > > > > > > configs/apple_m1_defconfig | 14 +++ > > > > > > include/configs/apple.h | 38 +++ > > > > > > 8 files changed, 271 insertions(+) > > > > > > create mode 100644 arch/arm/mach-apple/Kconfig > > > > > > create mode 100644 arch/arm/mach-apple/Makefile > > > > > > create mode 100644 arch/arm/mach-apple/board.c > > > > > > create mode 100644 arch/arm/mach-apple/lowlevel_init.S > > > > > > create mode 100644 configs/apple_m1_defconfig > > > > > > create mode 100644 include/configs/apple.h > > > > > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > > > > index b5bd3284cd..7cdea1f615 100644 > > > > > > --- a/arch/arm/Kconfig > > > > > > +++ b/arch/arm/Kconfig > > > > > > @@ -895,6 +895,26 @@ config ARCH_NEXELL > > > > > > select DM > > > > > > select GPIO_EXTRA_HEADER > > > > > > > > > > > > +config ARCH_APPLE > > > > > > + bool "Apple SoCs" > > > > > > + select ARM64 > > > > > > + select LINUX_KERNEL_IMAGE_HEADER > > > > > > + select POSITION_INDEPENDENT > > > > > > + select BLK > > > > > > + select DM > > > > > > + select DM_KEYBOARD > > > > > > + select DM_SERIAL > > > > > > + select DM_USB > > > > > > + select DM_VIDEO > > > > > > + select CMD_USB > > > > > > + select MISC > > > > > > + select OF_CONTROL > > > > > > + select OF_BOARD > > > > > > + select USB > > > > > > + imply CMD_DM > > > > > > + imply CMD_GPT > > > > > > + imply DISTRO_DEFAULTS > > > > > > + > > > > > > config ARCH_OWL > > > > > > bool "Actions Semi OWL SoCs" > > > > > > select DM > > > > > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR > > > > > > image headers. > > > > > > endif > > > > > > > > > > > > +source "arch/arm/mach-apple/Kconfig" > > > > > > + > > > > > > source "arch/arm/mach-aspeed/Kconfig" > > > > > > > > > > > > source "arch/arm/mach-at91/Kconfig" > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > > index c68e598a67..44178c204b 100644 > > > > > > --- a/arch/arm/Makefile > > > > > > +++ b/arch/arm/Makefile > > > > > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y) > > > > > > > > > > > > # Machine directory name. This list is sorted alphanumerically > > > > > > # by CONFIG_* macro name. > > > > > > +machine-$(CONFIG_ARCH_APPLE) += apple > > > > > > machine-$(CONFIG_ARCH_ASPEED) += aspeed > > > > > > machine-$(CONFIG_ARCH_AT91)+= at91 > > > > > > machine-$(CONFIG_ARCH_BCM283X) += bcm283x > > > > > > diff --git a/arch/arm/mach-apple/Kconfig > > > > > > b/arch/arm/mach-apple/Kconfig > > > > > > new file mode 100644 > > > > > > index 00..66cab91b2a > > > > > > --- /dev/null > > > > > > +++ b/arch/arm/mach-apple/Kconfig > > > > > > @@ -0,0 +1,18 @@ > > > > > > +if ARCH_APPLE > > > > > > + > > > > > > +config SYS_TEXT_BASE > > > > > > + default 0x > > > > > > + > > > > > > +config SYS_CONFIG_NAME > > > > > > + default "apple" > > > > > > + > > > > > > +config SYS_SOC > > > > > > + default "m1" > > > > > > + > > > > > > +config SYS_MALLOC_LEN > > > > > > + default 0x400 > > > > > > + > > > > > > +config SYS_MALLOC_F_LEN > > > > > > + default 0x4000 > > > > > > + > > > > > > +endif > > > > > > diff --git a/arch/arm/mach-apple/Makefile > > > > > > b/arch/arm/mach-apple/Makefile > > > > > > new file mode 100644 > > > > > > index 00..e74a8c9df1 > > > > > > --- /dev/null > > > > > > +++ b/arch/arm/mach-apple/Makefile > > > > > > @@ -0,0 +1,4 @@ > > > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > > > + > > > > > > +obj-y += board.o > > > > > > +obj-y += lowlevel_init.o > > > > > > diff --git a/arch/arm/mach-apple/board.c > > > > > > b/
Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC
On Tue, Sep 21, 2021 at 8:42 PM Tom Rini wrote: > > On Sun, Sep 19, 2021 at 10:33:25PM +0200, Mark Kettenis wrote: > > > From: Bin Meng > > > Date: Sun, 19 Sep 2021 09:17:07 +0800 > > > > > > Hi Mark, > > > > > > On Sun, Sep 19, 2021 at 9:04 AM Bin Meng wrote: > > > > > > > > Hi Mark, > > > > > > > > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis > > > > wrote: > > > > > > > > > > Add support for Apple's M1 SoC that is used in "Apple Silicon" > > > > > Macs. This builds a basic U-Boot that can be used as a payload > > > > > for the m1n1 boot loader being developed by the Asahi Linux > > > > > project. > > > > > > > > > > Signed-off-by: Mark Kettenis > > > > > --- > > > > > arch/arm/Kconfig| 22 > > > > > arch/arm/Makefile | 1 + > > > > > arch/arm/mach-apple/Kconfig | 18 > > > > > arch/arm/mach-apple/Makefile| 4 + > > > > > arch/arm/mach-apple/board.c | 158 > > > > > > > > > > arch/arm/mach-apple/lowlevel_init.S | 16 +++ > > > > > configs/apple_m1_defconfig | 14 +++ > > > > > include/configs/apple.h | 38 +++ > > > > > 8 files changed, 271 insertions(+) > > > > > create mode 100644 arch/arm/mach-apple/Kconfig > > > > > create mode 100644 arch/arm/mach-apple/Makefile > > > > > create mode 100644 arch/arm/mach-apple/board.c > > > > > create mode 100644 arch/arm/mach-apple/lowlevel_init.S > > > > > create mode 100644 configs/apple_m1_defconfig > > > > > create mode 100644 include/configs/apple.h > > > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > > > index b5bd3284cd..7cdea1f615 100644 > > > > > --- a/arch/arm/Kconfig > > > > > +++ b/arch/arm/Kconfig > > > > > @@ -895,6 +895,26 @@ config ARCH_NEXELL > > > > > select DM > > > > > select GPIO_EXTRA_HEADER > > > > > > > > > > +config ARCH_APPLE > > > > > + bool "Apple SoCs" > > > > > + select ARM64 > > > > > + select LINUX_KERNEL_IMAGE_HEADER > > > > > + select POSITION_INDEPENDENT > > > > > + select BLK > > > > > + select DM > > > > > + select DM_KEYBOARD > > > > > + select DM_SERIAL > > > > > + select DM_USB > > > > > + select DM_VIDEO > > > > > + select CMD_USB > > > > > + select MISC > > > > > + select OF_CONTROL > > > > > + select OF_BOARD > > > > > + select USB > > > > > + imply CMD_DM > > > > > + imply CMD_GPT > > > > > + imply DISTRO_DEFAULTS > > > > > + > > > > > config ARCH_OWL > > > > > bool "Actions Semi OWL SoCs" > > > > > select DM > > > > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR > > > > > image headers. > > > > > endif > > > > > > > > > > +source "arch/arm/mach-apple/Kconfig" > > > > > + > > > > > source "arch/arm/mach-aspeed/Kconfig" > > > > > > > > > > source "arch/arm/mach-at91/Kconfig" > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > index c68e598a67..44178c204b 100644 > > > > > --- a/arch/arm/Makefile > > > > > +++ b/arch/arm/Makefile > > > > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y) > > > > > > > > > > # Machine directory name. This list is sorted alphanumerically > > > > > # by CONFIG_* macro name. > > > > > +machine-$(CONFIG_ARCH_APPLE) += apple > > > > > machine-$(CONFIG_ARCH_ASPEED) += aspeed > > > > > machine-$(CONFIG_ARCH_AT91)+= at91 > > > > > machine-$(CONFIG_ARCH_BCM283X) += bcm283x > > > > > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig > > > > > new file mode 100644 > > > > > index 00..66cab91b2a > > > > > --- /dev/null > > > > > +++ b/arch/arm/mach-apple/Kconfig > > > > > @@ -0,0 +1,18 @@ > > > > > +if ARCH_APPLE > > > > > + > > > > > +config SYS_TEXT_BASE > > > > > + default 0x > > > > > + > > > > > +config SYS_CONFIG_NAME > > > > > + default "apple" > > > > > + > > > > > +config SYS_SOC > > > > > + default "m1" > > > > > + > > > > > +config SYS_MALLOC_LEN > > > > > + default 0x400 > > > > > + > > > > > +config SYS_MALLOC_F_LEN > > > > > + default 0x4000 > > > > > + > > > > > +endif > > > > > diff --git a/arch/arm/mach-apple/Makefile > > > > > b/arch/arm/mach-apple/Makefile > > > > > new file mode 100644 > > > > > index 00..e74a8c9df1 > > > > > --- /dev/null > > > > > +++ b/arch/arm/mach-apple/Makefile > > > > > @@ -0,0 +1,4 @@ > > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > > + > > > > > +obj-y += board.o > > > > > +obj-y += lowlevel_init.o > > > > > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c > > > > > new file mode 100644 > > > > > index 00..0c8b35292e > > > > > --- /dev/null > > > > > +++ b/arch/arm/mach-apple/board.c > > > > > @@ -0,0 +1,158 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > > +/* > > > > > + * (C) Copyright 2021 Mark Kettenis > > > > > + */ > > > > > + > > > >
Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification
Alec Brown wrote: > Below is how the layout of these logs would store their data. > > bf_log_header: >+---+ > u32| version | > u32| size | > u8[64] | producer | > u8[64] | log_format| > u64| flags | > u64| next_bflh_addr| > u64| log_addr | > u32| log_size | >+---+ I suggest to include a .magic at least in bf_log_header and an .xor_checksum or .crc32 only in bf_log_header. .magic doubles as endianess indicator when the structures are stored on movable media. (Pick an asymmetric magic bit pattern!) I suggest renaming .next_bflh_addr to .next_log_header and .log_addr to .log_buffer_addr. I suggest to remove .size and .log_size: The rationale for .size is "to allow for backward compatibility" but that seems redundant thanks to .version. .log_size can be calculated from the subordinate data and is thus mostly an unneccessary source of potential inconsistency. > bf_log_buffer: >+---+ > u32| version | > u32| size | > u8[64] | producer | > u32| next_msg_off | > bf_log_msg[l] | msgs | >+---+ I suggest replacing .size and .next_msg_off with .messages containing l: .size can then be calculated from .messages; again, reliably avoiding inconsistency between .size and .next_msg_off. Allocated size doesn't seem useful if writers must anyway maintain state containing the starting address. If writers must be allowed to be completely stateless then maybe at least rename .size to .allocated_size and see below for discovery. Having .messages also eliminates the need for an end-of-messages marker when the allocated space is not yet filled. > bf_log_msg: >+---+ > u32| size | > u64| ts_nsec | > u32| level | > u32| facility | > u32| msg_off | > u8[n] | type | > u8[m] | msg | >+---+ It seems inconsistent that log_header.size and log_msg.size cover only the respective struct itself while log_buffer.size also covers all subordinate messages. Skipping all .size in this version fixes that. And log_msg.size is not very useful since both .type and .msg have variable length; it's not possible to access .msg without scanning .type. Please at a minimum add .type_size but better yet replace .size with .type_size and .msg_size. > There is still the outstanding issue of how the logs will be sent to the OS. > If > UEFI is used, we can use config tables. If ACPI or Device Tree is used, we can > use bf_log_header.next_bflh_addr to present the logs. If none of these > platforms > are used, it becomes a lot trickier to solve this issue. > > Any suggestions are much appreciated and will be taken into consideration. Having bf_log_header.magic and some bf_log_header.$checksum, a strict rule for bf_log_header start address granularity and a strict maximum offset for the first header from top and/or bottom of memory allows to quickly discover a log in memory without explicit handover. > LPC System Boot and Security Micro-conference on the 22nd of September > at 7:50 AM PDT (14:50 UTC). Have fun! :) Heinrich Schuchardt wrote: > We already the EFI_TCG2_PROTOCOL and RFC 5424 (The syslog protocol). > Why do we need to start from scratch? That's a good question. I guess noone wants to settle for a standard from somewhere else. ;) I wouldn't mind if log_msg was a syslog transport, but I can understand if that's rejected because syslog messages require a lot of parsing for presentation while Alec's proposal seems focused on efficiency and simplicity. It's also nice to be able to strictly mandate UTF-8 for all fields. (RFC 5424 allows MSG to be anything.) Kind regards //Peter
Re: [PATCH] Makefile: Add a warning about ad-hoc CONFIG options
On Mon, Sep 20, 2021 at 07:11:26PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 20 Sept 2021 at 09:20, Tom Rini wrote: > > > > On Sat, Sep 18, 2021 at 12:21:21PM -0600, Simon Glass wrote: > > > > > The Kconfig feature was added in 2014. Some 7 years later there are still > > > quite a few CONFIG options that have not been migrated. It is time to > > > close this out. > > > > > > Add a deadline and a warning for boards to migrate to Kconfig. > > > > > > Signed-off-by: Simon Glass > > > > I agree with the sentiment. But we aren't at the point where even aside > > from environment and a few outstanding migrations I've posted but not > > yet pulled, that any platform is 100% clean. There's still even > > migrated-but-in-config.h symbols seemingly everywhere. > > Indeed! > > So perhaps the trigger for this would be to have one board that > doesn't have a config.h ? I'm not sure. There's, largely, the ability to confirm that a conversion is identical here, unlike with DM migrations. Setting aside environment (which thanks for picking up again), there's a few tricky conversions that might be best served by code updates (like CONFIG_SYS_NAND_ECCPOS I think can be removed IF drivers are converted to use mtd_ooblayout_get_eccbytes() instead, which is how both the Linux Kernel, and a few more modern in-tree drivers do this today) or really just moving information to some other header. But we shouldn't be stuck with groups of boards that are unconverted. I feel like NAND is probably going to be the worst subsystem to finish converting and that's just going to highlight further "this should be updated for DM an DT.." of which only a few users have been. -- Tom signature.asc Description: PGP signature
Re: [PATCH] board/freescale/vid : move platform specific definitions
On Tue, Sep 21, 2021 at 04:24:57PM +0200, Wasim Khan wrote: > From: Wasim Khan > > VID is a common driver. Move platform specific definitions > to platform specific header files > > Signed-off-by: Wasim Khan > --- > board/freescale/common/vid.h | 10 -- > include/configs/lx2160a_common.h | 7 +++ > 2 files changed, 7 insertions(+), 10 deletions(-) NAK. Things need to move out of include/configs/ and not in to them, please find another common header file to use. -- Tom signature.asc Description: PGP signature
[PATCH] board/freescale/vid : move platform specific definitions
From: Wasim Khan VID is a common driver. Move platform specific definitions to platform specific header files Signed-off-by: Wasim Khan --- board/freescale/common/vid.h | 10 -- include/configs/lx2160a_common.h | 7 +++ 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/board/freescale/common/vid.h b/board/freescale/common/vid.h index b34c080b4b..32e68fceb2 100644 --- a/board/freescale/common/vid.h +++ b/board/freescale/common/vid.h @@ -59,16 +59,6 @@ #define PMBUS_CMD_VOUT_COMMAND 0x21 #define PMBUS_CMD_PAGE_PLUS_WRITE 0x05 -#if defined(CONFIG_TARGET_LX2160AQDS) || defined(CONFIG_TARGET_LX2162AQDS) || \ -defined(CONFIG_TARGET_LX2160ARDB) -/* Voltage monitor on channel 2*/ -#define I2C_VOL_MONITOR_BUS_V_OFFSET 0x2 -#define I2C_VOL_MONITOR_BUS_V_OVF 0x1 -#define I2C_VOL_MONITOR_BUS_V_SHIFT3 -#define I2C_VOL_MONITOR_ADDR0x63 -#define I2C_MUX_CH_VOL_MONITOR 0xA -#endif - int adjust_vdd(ulong vdd_override); u16 soc_get_fuse_vid(int vid_index); diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h index 1ae7d37dd9..c2c4a8c7a1 100644 --- a/include/configs/lx2160a_common.h +++ b/include/configs/lx2160a_common.h @@ -86,6 +86,13 @@ #define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET 0x00F2 #define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 5000 +/* Voltage monitor on channel 2*/ +#define I2C_VOL_MONITOR_BUS_V_OFFSET 0x2 +#define I2C_VOL_MONITOR_BUS_V_OVF 0x1 +#define I2C_VOL_MONITOR_BUS_V_SHIFT3 +#define I2C_VOL_MONITOR_ADDR 0x63 +#define I2C_MUX_CH_VOL_MONITOR 0xA + /* Define phy_reset function to boot the MC based on mcinitcmd. * This happens late enough to properly fixup u-boot env MAC addresses. */ -- 2.25.1
Re: [PATCH] ARM: dts: imx6-apalis: enable watchdog
Hi Oleksandr,
On Tue, Sep 21, 2021 at 2:48 PM Oleksandr Suvorov
wrote:
>
> From: Ricardo Salveti
>
> Add u-boot.dtsi specific to imx6-apalis with a watchdog enabled.
>
> If OP-TEE is loaded by SPL, it may use a watchdog to handle fails of
> u-boot running. Enable the watchdog in SPL to use it by OP-TEE.
>
> Signed-off-by: Ricardo Salveti
> Signed-off-by: Oleksandr Suvorov
> ---
>
> arch/arm/dts/imx6-apalis-u-boot.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
> create mode 100644 arch/arm/dts/imx6-apalis-u-boot.dtsi
>
> diff --git a/arch/arm/dts/imx6-apalis-u-boot.dtsi
> b/arch/arm/dts/imx6-apalis-u-boot.dtsi
> new file mode 100644
> index 00..95e7e022b9
> --- /dev/null
> +++ b/arch/arm/dts/imx6-apalis-u-boot.dtsi
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2020 Foundries.IO
> + */
> +
> +#include "imx6qdl-u-boot.dtsi"
> +
> +&wdog1 {
> + status = "okay";
> + u-boot,dm-spl;
> +};
> --
> 2.31.1
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Embedded Software Engineer
T: +380 938364067
E: igor.opan...@foundries.io
W: www.foundries.io
Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC
On Sun, Sep 19, 2021 at 10:33:25PM +0200, Mark Kettenis wrote:
> > From: Bin Meng
> > Date: Sun, 19 Sep 2021 09:17:07 +0800
> >
> > Hi Mark,
> >
> > On Sun, Sep 19, 2021 at 9:04 AM Bin Meng wrote:
> > >
> > > Hi Mark,
> > >
> > > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis
> > > wrote:
> > > >
> > > > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > > > Macs. This builds a basic U-Boot that can be used as a payload
> > > > for the m1n1 boot loader being developed by the Asahi Linux
> > > > project.
> > > >
> > > > Signed-off-by: Mark Kettenis
> > > > ---
> > > > arch/arm/Kconfig| 22
> > > > arch/arm/Makefile | 1 +
> > > > arch/arm/mach-apple/Kconfig | 18
> > > > arch/arm/mach-apple/Makefile| 4 +
> > > > arch/arm/mach-apple/board.c | 158
> > > > arch/arm/mach-apple/lowlevel_init.S | 16 +++
> > > > configs/apple_m1_defconfig | 14 +++
> > > > include/configs/apple.h | 38 +++
> > > > 8 files changed, 271 insertions(+)
> > > > create mode 100644 arch/arm/mach-apple/Kconfig
> > > > create mode 100644 arch/arm/mach-apple/Makefile
> > > > create mode 100644 arch/arm/mach-apple/board.c
> > > > create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > > > create mode 100644 configs/apple_m1_defconfig
> > > > create mode 100644 include/configs/apple.h
> > > >
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > index b5bd3284cd..7cdea1f615 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > > > select DM
> > > > select GPIO_EXTRA_HEADER
> > > >
> > > > +config ARCH_APPLE
> > > > + bool "Apple SoCs"
> > > > + select ARM64
> > > > + select LINUX_KERNEL_IMAGE_HEADER
> > > > + select POSITION_INDEPENDENT
> > > > + select BLK
> > > > + select DM
> > > > + select DM_KEYBOARD
> > > > + select DM_SERIAL
> > > > + select DM_USB
> > > > + select DM_VIDEO
> > > > + select CMD_USB
> > > > + select MISC
> > > > + select OF_CONTROL
> > > > + select OF_BOARD
> > > > + select USB
> > > > + imply CMD_DM
> > > > + imply CMD_GPT
> > > > + imply DISTRO_DEFAULTS
> > > > +
> > > > config ARCH_OWL
> > > > bool "Actions Semi OWL SoCs"
> > > > select DM
> > > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> > > > image headers.
> > > > endif
> > > >
> > > > +source "arch/arm/mach-apple/Kconfig"
> > > > +
> > > > source "arch/arm/mach-aspeed/Kconfig"
> > > >
> > > > source "arch/arm/mach-at91/Kconfig"
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index c68e598a67..44178c204b 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> > > >
> > > > # Machine directory name. This list is sorted alphanumerically
> > > > # by CONFIG_* macro name.
> > > > +machine-$(CONFIG_ARCH_APPLE) += apple
> > > > machine-$(CONFIG_ARCH_ASPEED) += aspeed
> > > > machine-$(CONFIG_ARCH_AT91)+= at91
> > > > machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > > > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> > > > new file mode 100644
> > > > index 00..66cab91b2a
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-apple/Kconfig
> > > > @@ -0,0 +1,18 @@
> > > > +if ARCH_APPLE
> > > > +
> > > > +config SYS_TEXT_BASE
> > > > + default 0x
> > > > +
> > > > +config SYS_CONFIG_NAME
> > > > + default "apple"
> > > > +
> > > > +config SYS_SOC
> > > > + default "m1"
> > > > +
> > > > +config SYS_MALLOC_LEN
> > > > + default 0x400
> > > > +
> > > > +config SYS_MALLOC_F_LEN
> > > > + default 0x4000
> > > > +
> > > > +endif
> > > > diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> > > > new file mode 100644
> > > > index 00..e74a8c9df1
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-apple/Makefile
> > > > @@ -0,0 +1,4 @@
> > > > +# SPDX-License-Identifier: GPL-2.0+
> > > > +
> > > > +obj-y += board.o
> > > > +obj-y += lowlevel_init.o
> > > > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > > > new file mode 100644
> > > > index 00..0c8b35292e
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-apple/board.c
> > > > @@ -0,0 +1,158 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * (C) Copyright 2021 Mark Kettenis
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +static struct mm_region apple_mem_map[] = {
> > > > + {
> > > > + /* I/O */
> > > > + .virt = 0x2,
> > > > +
Re: [PATCH v3 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported
Hi, On 9/17/21 3:36 PM, Marek Vasut wrote: On 9/17/21 12:55 PM, Patrick DELAUNAY wrote: Hi Marek, > Marek VasutSept. 16, 2021, 5:24 p.m. UTC | #1 > On 9/16/21 4:01 PM, Patrick Delaunay wrote: >> When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, >> CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks, >> but this variable is defined in drivers/mtd/cfi_flash.c, which is >> compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot >> or in SPL when CONFIG_SPL_MTD_SUPPORT is activated. >> >> This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT >> when flash cfi driver is not activated to avoid compilation issue in >> the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in spi_nor_scan(). > Maybe just migrate this config option to Kconfig and let Kconfig handle > the macro magic ? Sorry for the format of my answer (it is just copy paste from archive) because I don't received the U-Boot mails on my @foss.st.com mailbo since yesterday. I think about migration but is difficult to don't break the existing behaviour in kconfig CONFIG_SYS_MAX_FLASH_BANKS and CONFIG_SYS_MAX_FLASH_BANKS_DETECT are define as 'int' but can be absent => 2 new config CONFIG_USE need to be added CONFIG_USE_SYS_MAX_FLASH_BANKS CONFIG_USE_SYS_MAX_FLASH_BANKS_DETECT and I don't fully understood the mix between the 2 options and CFI_MAX_FLASH_BANKS in some part of code I think CONFIG_SYS_MAX_FLASH_BANKS should be replaced by CFI_MAX_FLASH_BANKS to avoid to define CONFIG_SYS_MAX_FLASH_BANKS = cfi_flash_num_flash_banks (as it is not possible in Kconfig) => too huge task just to solve compilation issues. and I also think to use CONFIG_IS_ENABLED(MTD_SUPPORT) but it not possible because today - CONFIG_SPL_MTD_SUPPORT exist - CONFIG_MTD_SUPPORT don't exit ( test on $(mtd-y) in Makefile) => the creation of this config is a huge task just to solve compilation issue. All right, well, ew. Can you send a subsequent patchset _after_ this one to fix this flash banks mess ? I can try, I will add it in my TODO list. Patrick
[PATCH] ARM: dts: imx6-apalis: enable watchdog
From: Ricardo Salveti
Add u-boot.dtsi specific to imx6-apalis with a watchdog enabled.
If OP-TEE is loaded by SPL, it may use a watchdog to handle fails of
u-boot running. Enable the watchdog in SPL to use it by OP-TEE.
Signed-off-by: Ricardo Salveti
Signed-off-by: Oleksandr Suvorov
---
arch/arm/dts/imx6-apalis-u-boot.dtsi | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/dts/imx6-apalis-u-boot.dtsi
diff --git a/arch/arm/dts/imx6-apalis-u-boot.dtsi
b/arch/arm/dts/imx6-apalis-u-boot.dtsi
new file mode 100644
index 00..95e7e022b9
--- /dev/null
+++ b/arch/arm/dts/imx6-apalis-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2020 Foundries.IO
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+&wdog1 {
+ status = "okay";
+ u-boot,dm-spl;
+};
--
2.31.1
[PULL] Pull request for u-boot master / v2021.10 = u-boot-stm32-20210921
Hi Tom, Please pull the STM32 related fixes for u-boot/master, v2021.10: u-boot-stm32-20210921 - stm32mp15: fix the used partition name for U-Boot environement with SPL CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9197 Thanks, Patrick git request-pull origin/master https://source.denx.de/u-boot/custodians/u-boot-stm.git/ u-boot-stm32-20210921 The following changes since commit e3f5edf65916a881b71eea54f475c7a4bae8565c: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-09-20 08:45:26 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git/ tags/u-boot-stm32-20210921 for you to fetch changes up to cf39d0c29dcf332d7055d0545fc95e3379d91a62: arm: dts: stm32mp1: use ssbl partition name for U-Boot (2021-09-21 09:22:01 +0200) - stm32mp15: fix the used partition name for U-Boot environement with SPL Patrick Delaunay (1): arm: dts: stm32mp1: use ssbl partition name for U-Boot arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 +++- arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)
Re: [PATCH 0/4] ARM: amlogic: add Radxa Zero
On 15/09/2021 03:46, Christian Hewitt wrote: > This series alpha sorts the Amlogic Makefile, then adds > support for the Radxa Zero SBC using the device-tree > queued in the Amlogic maintainer tree for Linux 5.16.y > > Patches are based on custodians/u-boot-amlogic-next > > Christian Hewitt (4): > ARM: dts: sort Amlogic Makefile section > ARM: dts: add support for Radxa Zero > boards: amlogic: add Radxa Zero defconfig > doc: boards: amlogic: update for Radxa Zero > > arch/arm/dts/Makefile | 12 +- > .../arm/dts/meson-g12a-radxa-zero-u-boot.dtsi | 7 + > arch/arm/dts/meson-g12a-radxa-zero.dts| 405 ++ > configs/radxa-zero_defconfig | 70 +++ > doc/board/amlogic/index.rst | 3 +- > doc/board/amlogic/radxa-zero.rst | 74 > 6 files changed, 565 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/dts/meson-g12a-radxa-zero-u-boot.dtsi > create mode 100644 arch/arm/dts/meson-g12a-radxa-zero.dts > create mode 100644 configs/radxa-zero_defconfig > create mode 100644 doc/board/amlogic/radxa-zero.rst > Applied to u-boot-amlogic-next Neil
Re: [PATCH] arm: dts: stm32mp1: use ssbl partition name for U-Boot
Hi,
On 9/14/21 2:14 PM, Patrick Delaunay wrote:
Continue to use the "ssbl" name for GPT partition of secondary boot
stage = U-Boot for basic boot with SPL to avoid to disturb existing user.
The "fip" partition name is only used for TFA_BOOT with FIP, it is a TF-A
BL2 requirement; it the default configuration for STMicroelectronics
boards.
Fixes: b73e8bf453f8 ("arm: stm32mp: add defconfig for trusted boot with FIP")
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 +++-
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
Applied to u-boot-stm/master, thanks!
Regards
Patrick
Re: [PATCH v3 0/3] ARM: meson: add support for JetHub D1/H1
On 20/09/2021 10:40, Vyacheslav Bocharov wrote: > Add support for new home automation devices manufactured by JetHome. > Patches prepared for use with the "ARM: meson: Sync Amlogic DT from Linux > 5.14" patch series by Neil Armstrong > > JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation > controller with the following features: > - DIN Rail Mounting case > - Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz > - no video out > - 512Mb/1GB DDR3 > - 8/16GB eMMC flash > - 1 x USB 2.0 > - 1 x 10/100Mbps ethernet > - WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, > Bluetooth 4.2. > - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and > Zigbee 3.0 support. > - 2 x gpio LEDS > - GPIO user Button > - 1 x 1-Wire > - 2 x RS-485 > - 4 x dry contact digital GPIO inputs > - 3 x relay GPIO outputs > - DC source with a voltage of 9 to 56 V / Passive POE > > JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation > controller with the following features: > - Square plastic case > - Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz > - no video out > - 1GB DDR3 > - 8/16GB eMMC flash > - 2 x USB 2.0 > - 1 x 10/100Mbps ethernet > - WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0. > - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and > Zigbee 3.0 support. > - MicroSD 2.x/3.x/4.x DS/HS cards. > - 1 x gpio LED > - ADC user Button > - DC source 5V microUSB with serial console > > Changes from v2: > - fix "Alignment should match open parenthesis" in > board/amlogic/jethub-j80/jethub-j80.c > - add missing files to board/amlogic/jethub-j80/MAINTAINERS > - fix unexpected unindent in doc files > > Changes from v1: > - fix BOOT_TARGET_DEVICES in jethub.h (patch 1/3) > - add lore URLs to description (patch 2/3) > > Signed-off-by: Vyacheslav Bocharov > > Vyacheslav Bocharov (3): > ARM: amlogic: add JetHub common config header > ARM: amlogic: add JetHub D1/H1 device support > ARM: amlogic: add JetHub D1/H1 docs > > arch/arm/dts/Makefile | 2 + > .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++ > .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 > board/amlogic/jethub-j80/MAINTAINERS | 9 + > board/amlogic/jethub-j80/Makefile | 6 + > board/amlogic/jethub-j80/jethub-j80.c | 68 > configs/jethub_j100_defconfig | 55 +++ > configs/jethub_j80_defconfig | 63 +++ > doc/board/amlogic/index.rst | 128 --- > doc/board/amlogic/jethub-j100.rst | 108 ++ > doc/board/amlogic/jethub-j80.rst | 97 + > include/configs/jethub.h | 40 ++ > 12 files changed, 1115 insertions(+), 63 deletions(-) > create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts > create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts > create mode 100644 board/amlogic/jethub-j80/MAINTAINERS > create mode 100644 board/amlogic/jethub-j80/Makefile > create mode 100644 board/amlogic/jethub-j80/jethub-j80.c > create mode 100644 configs/jethub_j100_defconfig > create mode 100644 configs/jethub_j80_defconfig > create mode 100644 doc/board/amlogic/jethub-j100.rst > create mode 100644 doc/board/amlogic/jethub-j80.rst > create mode 100644 include/configs/jethub.h > Applied to u-boot-amlogic-next Neil
Re: [PATCH v3 01/10] ARM: meson: Sync Amlogic DT from Linux 5.14
On 17/09/2021 09:37, Neil Armstrong wrote:
> Import Amlogic DT changes from Linux commit 7d2a07b76933 ("Linux 5.14"),
> dt-bindings clock changes and new meson-g12b-gsking-x.dts,
> meson-sm1-bananapi-m5 & odroid-hc4 boards.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm/dts/Makefile | 3 +
> arch/arm/dts/meson-axg-s400.dts | 16 +
> arch/arm/dts/meson-axg.dtsi | 181 +
> arch/arm/dts/meson-g12-common.dtsi| 31 +-
> arch/arm/dts/meson-g12a-sei510.dts| 2 +-
> arch/arm/dts/meson-g12b-gsking-x.dts | 133
> arch/arm/dts/meson-g12b-gtking-pro.dts| 23 +-
> arch/arm/dts/meson-g12b-gtking.dts| 22 +-
> arch/arm/dts/meson-g12b-odroid-n2-plus.dts| 2 +-
> arch/arm/dts/meson-g12b-odroid-n2.dtsi| 74 +-
> arch/arm/dts/meson-g12b-w400.dtsi | 2 +-
> arch/arm/dts/meson-g12b.dtsi | 4 +
> arch/arm/dts/meson-gx-libretech-pc.dtsi | 2 +-
> arch/arm/dts/meson-gx-p23x-q20x.dtsi | 2 +-
> arch/arm/dts/meson-gx.dtsi| 7 +
> arch/arm/dts/meson-gxbb-nanopi-k2.dts | 42 +-
> arch/arm/dts/meson-gxbb-odroidc2.dts | 44 +-
> arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 2 +-
> arch/arm/dts/meson-gxl-s905x-khadas-vim.dts | 50 +-
> .../dts/meson-gxl-s905x-libretech-cc-v2.dts | 6 +-
> arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 2 +-
> arch/arm/dts/meson-gxm-khadas-vim2.dts| 55 +-
> arch/arm/dts/meson-gxm-wetek-core2.dts| 2 +-
> arch/arm/dts/meson-gxm.dtsi | 20 +
> arch/arm/dts/meson-khadas-vim3.dtsi | 73 +-
> arch/arm/dts/meson-sm1-bananapi-m5.dts| 646 ++
> arch/arm/dts/meson-sm1-khadas-vim3l.dts | 20 +-
> arch/arm/dts/meson-sm1-odroid-c4.dts | 448 +---
> arch/arm/dts/meson-sm1-odroid-hc4.dts | 140
> arch/arm/dts/meson-sm1-odroid.dtsi| 449
> arch/arm/dts/meson-sm1-sei610.dts | 10 +-
> arch/arm/dts/meson-sm1.dtsi | 12 +-
> include/dt-bindings/clock/axg-clkc.h | 26 +-
> include/dt-bindings/clock/g12a-clkc.h | 2 +
> 34 files changed, 2030 insertions(+), 523 deletions(-)
> create mode 100644 arch/arm/dts/meson-g12b-gsking-x.dts
> create mode 100644 arch/arm/dts/meson-sm1-bananapi-m5.dts
> create mode 100644 arch/arm/dts/meson-sm1-odroid-hc4.dts
> create mode 100644 arch/arm/dts/meson-sm1-odroid.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fc16a57e60..f0160d2dc0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -177,11 +177,14 @@ dtb-$(CONFIG_ARCH_MESON) += \
> meson-g12a-sei510.dtb \
> meson-g12b-gtking.dtb \
> meson-g12b-gtking-pro.dtb \
> + meson-g12b-gsking-x.dtb \
> meson-g12b-odroid-n2.dtb \
> meson-g12b-odroid-n2-plus.dtb \
> meson-g12b-a311d-khadas-vim3.dtb \
> + meson-sm1-bananapi-m5.dtb \
> meson-sm1-khadas-vim3l.dtb \
> meson-sm1-odroid-c4.dtb \
> + meson-sm1-odroid-hc4.dtb \
> meson-sm1-sei610.dtb
> dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
> tegra20-medcom-wide.dtb \
> diff --git a/arch/arm/dts/meson-axg-s400.dts b/arch/arm/dts/meson-axg-s400.dts
> index cb1360ae12..359589d1df 100644
> --- a/arch/arm/dts/meson-axg-s400.dts
> +++ b/arch/arm/dts/meson-axg-s400.dts
> @@ -441,6 +441,16 @@
> status = "okay";
> };
>
> +&pcieA {
> + reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&pcieB {
> + reset-gpios = <&gpio GPIOZ_10 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +};
> +
> &pwm_ab {
> status = "okay";
> pinctrl-0 = <&pwm_a_x20_pins>;
> @@ -584,3 +594,9 @@
> pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> };
> +
> +&usb {
> + status = "okay";
> + dr_mode = "otg";
> + vbus-supply = <&usb_pwr>;
> +};
> diff --git a/arch/arm/dts/meson-axg.dtsi b/arch/arm/dts/meson-axg.dtsi
> index b9efc84692..3f5254eeb4 100644
> --- a/arch/arm/dts/meson-axg.dtsi
> +++ b/arch/arm/dts/meson-axg.dtsi
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -171,6 +172,98 @@
> #size-cells = <2>;
> ranges;
>
> + pcieA: pcie@f980 {
> + compatible = "amlogic,axg-pcie", "snps,dw-pcie";
> + reg = <0x0 0xf980 0x0 0x40>,
> + <0x0 0xff646000 0x0 0x2000>,
> + <0x0 0xf9f0 0x0 0x10>;
> + reg-names = "elbi", "cfg", "config";
> + interrupts = ;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0
Re: [PATCH] pci: pcie_dw_meson: fix usb fail when pci link fails to go up
On 08/09/2021 14:32, Neil Armstrong wrote: > On Amlogic A311D, when the PCIe link fails disabling the related clocks > makes USB fail. For an unknown reason, this doesn happen on the S905D3 SoC. > > Mimic the Linux behavior by not considering a link failure a probe failure, > and continue even if the PCIe link is down. > > Reported-by: Art Nikpal > Signed-off-by: Neil Armstrong > --- > drivers/pci/pcie_dw_meson.c | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/pci/pcie_dw_meson.c b/drivers/pci/pcie_dw_meson.c > index 0525ecbea6..07da9fa533 100644 > --- a/drivers/pci/pcie_dw_meson.c > +++ b/drivers/pci/pcie_dw_meson.c > @@ -319,15 +319,9 @@ static int meson_pcie_init_port(struct udevice *dev) > > pcie_dw_setup_host(&priv->dw); > > - ret = meson_pcie_link_up(priv, LINK_SPEED_GEN_2); > - if (ret < 0) > - goto err_link_up; > + meson_pcie_link_up(priv, LINK_SPEED_GEN_2); > > return 0; > -err_link_up: > - clk_disable(&priv->clk_port); > - clk_disable(&priv->clk_general); > - clk_disable(&priv->clk_pclk); > err_deassert_bulk: > reset_assert_bulk(&priv->rsts); > err_power_off_phy: > Applied to u-boot-amlogic-next Neil
Re: [PATCH] drivers: pmic: Add sysreset driver to da9063 pmic device
On 9/20/21 5:48 PM, Alexandre Ghiti wrote:
This pmic device is present on the SiFive Unmatched board and this
new driver adds the possibility to reset it.
Signed-off-by: Alexandre Ghiti
---
configs/sifive_unmatched_defconfig | 2 ++
drivers/power/pmic/da9063.c| 49 ++
2 files changed, 51 insertions(+)
diff --git a/configs/sifive_unmatched_defconfig
b/configs/sifive_unmatched_defconfig
index 978818b688..9ab058be39 100644
--- a/configs/sifive_unmatched_defconfig
+++ b/configs/sifive_unmatched_defconfig
@@ -43,3 +43,5 @@ CONFIG_DM_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_DA9063=y
diff --git a/drivers/power/pmic/da9063.c b/drivers/power/pmic/da9063.c
index 25101d18f7..b04879d9c5 100644
--- a/drivers/power/pmic/da9063.c
+++ b/drivers/power/pmic/da9063.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -87,6 +88,7 @@ static int da9063_bind(struct udevice *dev)
{
ofnode regulators_node;
int children;
+ int ret;
regulators_node = dev_read_subnode(dev, "regulators");
if (!ofnode_valid(regulators_node)) {
@@ -101,6 +103,14 @@ static int da9063_bind(struct udevice *dev)
if (!children)
debug("%s: %s - no child found\n", __func__, dev->name);
+ if (CONFIG_IS_ENABLED(SYSRESET)) {
Thank you for addressing the missing reset driver for the SiFive
Unmatched board.
I imagine some existing or future boards using the DA9063 will have a
GPIO for system reset. Should all boards having a DA9063 PMIC implement
system reset via the power management IC?
We could instead use the devicetree to identify if a board shall use the
DA9063 for system reset.
+ ret = device_bind_driver(dev, "da9063-sysreset",
+"da9063-sysreset", NULL);
+ if (ret)
+ debug("%s: %s - failed to bind sysreset driver\n",
+ __func__, dev->name);
+ }
+
/* Always return success for this device */
return 0;
}
@@ -129,3 +139,42 @@ U_BOOT_DRIVER(pmic_da9063) = {
.probe = da9063_probe,
.ops = &da9063_ops,
};
+
+#ifdef CONFIG_SYSRESET
The linker will remove functions that are not used automatically. We
have tended to not enclose functions in #ifdef but instead allow the
compiler to check the code.
+#include
Please, keep includes at the top of the code.
+
Even though this is a static function I would add a Sphinx style comment
here. Cf.
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation
Best regards
Heinrich
+static int da9063_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+ struct udevice *pmic_dev = dev->parent;
+ uint ret;
+
+ if (type != SYSRESET_WARM && type != SYSRESET_COLD)
+ return -EPROTONOSUPPORT;
+
+ ret = pmic_reg_write(pmic_dev, DA9063_REG_PAGE_CON, 0x00);
+ if (ret < 0)
+ return ret;
+
+ /* Sets the WAKE_UP bit */
+ ret = pmic_reg_write(pmic_dev, DA9063_REG_CONTROL_F, 0x04);
+ if (ret < 0)
+ return ret;
+
+ /* Powerdown! */
+ ret = pmic_reg_write(pmic_dev, DA9063_REG_CONTROL_A, 0x68);
+ if (ret < 0)
+ return ret;
+
+ return -EINPROGRESS;
+}
+
+static struct sysreset_ops da9063_sysreset_ops = {
+ .request = da9063_sysreset_request,
+};
+
+U_BOOT_DRIVER(da9063_sysreset) = {
+ .name = "da9063-sysreset",
+ .id = UCLASS_SYSRESET,
+ .ops = &da9063_sysreset_ops,
+};
+#endif
[PATCH v2 3/3] efi_loader: add DeployedMode and AuditMode variable measurement
This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client PFP Spec.
Signed-off-by: Masahisa Kojima
---
(no changes since v1)
lib/efi_loader/efi_tcg2.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index ea2c1ead03..68542c7cd3 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1828,6 +1829,50 @@ out:
return ret;
}
+/**
+ * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
+ *
+ * @dev: TPM device
+ *
+ * Return: status code
+ */
+static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
+{
+ u8 deployed_mode;
+ u8 audit_mode;
+ efi_uintn_t size;
+ efi_status_t ret;
+ u32 pcr_index;
+
+ size = sizeof(deployed_mode);
+ ret = efi_get_variable_int(L"DeployedMode", &efi_global_variable_guid,
+ NULL, &size, &deployed_mode, NULL);
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ pcr_index = (deployed_mode ? 1 : 7);
+
+ ret = tcg2_measure_variable(dev, pcr_index,
+ EV_EFI_VARIABLE_DRIVER_CONFIG,
+ L"DeployedMode",
+ &efi_global_variable_guid,
+ size, &deployed_mode);
+
+ size = sizeof(audit_mode);
+ ret = efi_get_variable_int(L"AuditMode", &efi_global_variable_guid,
+ NULL, &size, &audit_mode, NULL);
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ ret = tcg2_measure_variable(dev, pcr_index,
+ EV_EFI_VARIABLE_DRIVER_CONFIG,
+ L"AuditMode",
+ &efi_global_variable_guid,
+ size, &audit_mode);
+
+ return ret;
+}
+
/**
* tcg2_measure_secure_boot_variable() - measure secure boot variables
*
@@ -1891,6 +1936,8 @@ static efi_status_t
tcg2_measure_secure_boot_variable(struct udevice *dev)
free(data);
}
+ ret = tcg2_measure_deployed_audit_mode(dev);
+
error:
return ret;
}
--
2.17.1
[PATCH v2 2/3] efi_loader: add UEFI GPT measurement
This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client PFP Spec.
Signed-off-by: Masahisa Kojima
---
(no changes since v1)
include/blk.h | 3 +
include/efi_loader.h | 2 +-
include/efi_tcg2.h| 12 +++
lib/efi_loader/efi_boottime.c | 2 +-
lib/efi_loader/efi_tcg2.c | 175 +-
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/include/blk.h b/include/blk.h
index 19bab081c2..f0cc7ca1a2 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -45,6 +45,9 @@ enum if_type {
#define BLK_PRD_SIZE 20
#define BLK_REV_SIZE 8
+#define PART_FORMAT_PCAT 0x1
+#define PART_FORMAT_GPT0x2
+
/*
* Identifies the partition table type (ie. MBR vs GPT GUID) signature
*/
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 13f0c24058..dbcc296e01 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
void efi_variables_boot_exit_notify(void);
efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
/* Measure efi application invocation */
-efi_status_t efi_tcg2_measure_efi_app_invocation(void);
+efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj
*handle);
/* Measure efi application exit */
efi_status_t efi_tcg2_measure_efi_app_exit(void);
/* Called by bootefi to initialize root node */
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 85a032dbbd..0ecc7f99d7 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -230,6 +230,18 @@ struct smbios_handoff_table_pointers2 {
struct efi_configuration_table table_entry[];
} __packed;
+/**
+ * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
+ * @uefi_partition_header: gpt partition header
+ * @number_of_partitions: the number of partition
+ * @partitions:partition entries
+ */
+struct efi_gpt_data {
+ gpt_header uefi_partition_header;
+ u64 number_of_partitions;
+ gpt_entry partitions[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 701e2212c8..bf5661e1ee 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3003,7 +3003,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) {
- ret = efi_tcg2_measure_efi_app_invocation();
+ ret = efi_tcg2_measure_efi_app_invocation(image_obj);
if (ret != EFI_SUCCESS) {
log_warning("tcg2 measurement fails(0x%lx)\n",
ret);
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 4f68f6dfd5..ea2c1ead03 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1525,12 +1525,181 @@ static void *find_smbios_table(void)
return NULL;
}
+/**
+ * search_gpt_dp_node() - search gpt device path node
+ *
+ * @device_path: device path
+ *
+ * Return: pointer to the gpt device path node
+ */
+static struct
+efi_device_path *search_gpt_dp_node(struct efi_device_path *device_path)
+{
+ struct efi_device_path *dp = device_path;
+
+ while (dp) {
+ if (dp->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+ dp->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+ struct efi_device_path_hard_drive_path *hd_dp =
+ (struct efi_device_path_hard_drive_path *)dp;
+
+ if (hd_dp->partmap_type == PART_FORMAT_GPT &&
+ hd_dp->signature_type == SIG_TYPE_GUID)
+ return dp;
+ }
+ dp = efi_dp_next(dp);
+ }
+
+ return NULL;
+}
+
+/**
+ * tcg2_measure_gpt_table() - measure gpt table
+ *
+ * @dev: TPM device
+ * @loaded_image: handle to the loaded image
+ *
+ * Return: status code
+ */
+static efi_status_t
+tcg2_measure_gpt_data(struct udevice *dev,
+ struct efi_loaded_image_obj *loaded_image)
+{
+ efi_status_t ret;
+ efi_handle_t handle;
+ struct efi_handler *dp_handler;
+ struct efi_device_path *orig_device_path;
+ struct efi_device_path *device_path;
+ struct efi_device_path *dp;
+ struct efi_block_io *block_io;
+ struct efi_gpt_data *event = NULL;
+ efi_guid_t null_guid = NULL_GUID;
+ gpt_header *orig_gpt_h = NULL;
+ gpt_entry *orig_gpt_e = NULL;
+ gpt_header *gpt_h = NUL
[PATCH v2 1/3] efi_loader: add SMBIOS table measurement
TCG PC Client spec requires to measure the SMBIOS
table that contain static configuration information
(e.g. Platform Manufacturer Enterprise Number assigned by IANA,
platform model number, Vendor and Device IDs for each SMBIOS table).
The device and environment dependent information such as
serial number is cleared to zero or space character for
the measurement.
Existing smbios_string() function returns pointer to the string
with const qualifier, but exisintg use case is updating version
string and const qualifier must be removed.
This commit removes const qualifier from smbios_string()
return value and reuses to clear the strings for the measurement.
This commit also fixes the following compiler warning:
lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
const struct smbios_header *header = (struct smbios_header
*)entry->struct_table_address;
Signed-off-by: Masahisa Kojima
---
Changes in v2:
- use flexible array for table_entry field
- modify funtion name to find_smbios_table()
- remove unnecessary const qualifier from smbios_string()
- create non-const version of next_header()
include/efi_loader.h | 2 +
include/efi_tcg2.h| 15
include/smbios.h | 17 +++-
lib/efi_loader/Kconfig| 1 +
lib/efi_loader/efi_boottime.c | 2 +
lib/efi_loader/efi_smbios.c | 2 -
lib/efi_loader/efi_tcg2.c | 84 +++
lib/smbios-parser.c | 152 +++---
8 files changed, 261 insertions(+), 14 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c440962fe5..13f0c24058 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -308,6 +308,8 @@ extern const efi_guid_t efi_guid_capsule_report;
extern const efi_guid_t efi_guid_firmware_management_protocol;
/* GUID for the ESRT */
extern const efi_guid_t efi_esrt_guid;
+/* GUID of the SMBIOS table */
+extern const efi_guid_t smbios_guid;
extern char __efi_runtime_start[], __efi_runtime_stop[];
extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 5a1a36212e..85a032dbbd 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -215,6 +215,21 @@ struct efi_tcg2_uefi_variable_data {
u8 variable_data[1];
};
+/**
+ * struct tdUEFI_HANDOFF_TABLE_POINTERS2 - event log structure of SMBOIS tables
+ * @table_description_size:size of table description
+ * @table_description: table description
+ * @number_of_tables: number of uefi configuration table
+ * @table_entry: uefi configuration table entry
+ */
+#define SMBIOS_HANDOFF_TABLE_DESC "SmbiosTable"
+struct smbios_handoff_table_pointers2 {
+ u8 table_description_size;
+ u8 table_description[sizeof(SMBIOS_HANDOFF_TABLE_DESC)];
+ u64 number_of_tables;
+ struct efi_configuration_table table_entry[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/include/smbios.h b/include/smbios.h
index aa6b6f3849..acfcbfe2ca 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -260,9 +260,9 @@ const struct smbios_header *smbios_header(const struct
smbios_entry *entry, int
*
* @header:pointer to struct smbios_header
* @index: string index
- * @return:NULL or a valid const char pointer
+ * @return:NULL or a valid char pointer
*/
-const char *smbios_string(const struct smbios_header *header, int index);
+char *smbios_string(const struct smbios_header *header, int index);
/**
* smbios_update_version() - Update the version string
@@ -292,4 +292,17 @@ int smbios_update_version(const char *version);
*/
int smbios_update_version_full(void *smbios_tab, const char *version);
+/**
+ * smbios_prepare_measurement() - Update smbios table for the measurement
+ *
+ * TCG specification requires to measure static configuration information.
+ * This function clear the device dependent parameters such as
+ * serial number for the measurement.
+ *
+ * @entry: pointer to a struct smbios_entry
+ * @header: pointer to a struct smbios_header
+ */
+void smbios_prepare_measurement(const struct smbios_entry *entry,
+ struct smbios_header *header);
+
#endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index f4e9129a39..da68a219a3 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -328,6 +328,7 @@ config EFI_TCG2_PROTOCOL
select SHA384
select SHA512
select HASH
+ select SMBIOS_PARSER
help
Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
of the platform.
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f0283b539e..701e2212c8 100644
--
[PATCH v2 0/3] Enhance Measured Boot
This patch series add the following measurement mandated in the TCG PC Client PFP Specification. - SMBIOS tables - GPT disk partition topology - AuditMode and Deployed mode Masahisa Kojima (3): efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: add DeployedMode and AuditMode variable measurement include/blk.h | 3 + include/efi_loader.h | 4 +- include/efi_tcg2.h| 27 +++ include/smbios.h | 17 +- lib/efi_loader/Kconfig| 1 + lib/efi_loader/efi_boottime.c | 4 +- lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c | 306 +- lib/smbios-parser.c | 152 +++-- 9 files changed, 499 insertions(+), 17 deletions(-) -- 2.17.1
