[PATCH 1/1] doc/README.distro: kernel_comp_addr_r
Add missing articles and preposition. Signed-off-by: Heinrich Schuchardt --- doc/README.distro | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/README.distro b/doc/README.distro index cc1c41ecb3..c4f041ca71 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -259,10 +259,10 @@ kernel_addr_r: kernel_comp_addr_r: Optional. This is only required if user wants to boot Linux from a compressed - Image(.gz, .bz2, .lzma, .lzo) using booti command. It represents the location - in RAM where the compressed Image will be decompressed temporarily. Once the - decompression is complete, decompressed data will be moved kernel_addr_r for - booting. + Image(.gz, .bz2, .lzma, .lzo) using the booti command. It represents the + location in RAM where the compressed Image will be decompressed temporarily. + Once the decompression is complete, the decompressed data will be moved to + kernel_addr_r for booting. kernel_comp_size: Optional. This is only required if user wants to boot Linux from a compressed -- 2.30.0
Re: About doc/usage directory
Am 17. Februar 2021 07:06:02 MEZ schrieb Jaehoon Chung : >Hi all, > >I have a question about usage page. >I have found files under doc/usage/. It's description how to use each >command. >But there is not mmc.rst and file relevant to power command.(regulator, >pmic, etc) >If someone didn't have any plan, I want to update file relevant to mmc >and pmic command. > >Is there any rule to update it? My goal is to apply next release. Thank you for taking care of these man-pages. As it is documentation, reaching the next release should not pose a problem. I not aware of any current work. You could use load.rst as a template for structuring your pages. Best regards Heinrich > >If someone are already doing this, let me know, plz. > >Best Regards, >Jaehoon Chung
About doc/usage directory
Hi all, I have a question about usage page. I have found files under doc/usage/. It's description how to use each command. But there is not mmc.rst and file relevant to power command.(regulator, pmic, etc) If someone didn't have any plan, I want to update file relevant to mmc and pmic command. Is there any rule to update it? My goal is to apply next release. If someone are already doing this, let me know, plz. Best Regards, Jaehoon Chung
Re: [PATCH 2/2] efi: ESRT cration unit test
On Mon, Feb 08, 2021 at 12:52:46PM +, Jose Marinho wrote:
> This commit exercises the ESRT creation -- introduced in the previous
> commit.
>
> A fake FMP, controlling TEST_ESRT_NUM_ENTRIES, is installed in the system
> leading to the corresponding ESRT entries being populated.
> The ESRT entries are checked against the FMP initialization input
> datastructure.
I hope that you will also provide a pytest to make sure that
an entry in ESRT is correctly updated after capsule update.
There are already some tests for capsule update.
-Takahiro Akashi
> Signed-off-by: Jose Marinho
>
> CC: Heinrich Schuchardt
> CC: Sughosh Ganu
> CC: AKASHI Takahiro
> CC: Ilias Apalodimas
> CC: Andre Przywara
> CC: Alexander Graf
> CC: n...@arm.com
>
> ---
> test/lib/Makefile | 1 +
> test/lib/efi_esrt.c | 188
> 2 files changed, 189 insertions(+)
> create mode 100644 test/lib/efi_esrt.c
>
> diff --git a/test/lib/Makefile b/test/lib/Makefile
> index 97c11e35a8..687e791db0 100644
> --- a/test/lib/Makefile
> +++ b/test/lib/Makefile
> @@ -15,3 +15,4 @@ obj-$(CONFIG_UT_LIB_ASN1) += asn1.o
> obj-$(CONFIG_UT_LIB_RSA) += rsa.o
> obj-$(CONFIG_AES) += test_aes.o
> obj-$(CONFIG_GETOPT) += getopt.o
> +obj-y += efi_esrt.o
> diff --git a/test/lib/efi_esrt.c b/test/lib/efi_esrt.c
> new file mode 100644
> index 00..3c9d1de731
> --- /dev/null
> +++ b/test/lib/efi_esrt.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Test ESRT tables support
> + *
> + * Copyright (C) 2021 Arm Ltd.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define TEST_ESRT_NUM_ENTRIES 255
> +
> +#if 0x100 < TEST_ESRT_NUM_ENTRIES
> +#error TEST_ESRT_NUM_ENTRIES must be lower or equal to 255.
> +#endif
> +
> +static
> +struct efi_firmware_image_descriptor static_img_info[TEST_ESRT_NUM_ENTRIES];
> +static const efi_guid_t esrt_guid = EFI_SYSTEM_RESOURCE_TABLE_GUID;
> +
> +static void efi_test_esrt_init_info(void)
> +{
> + for (int idx = 0; idx < TEST_ESRT_NUM_ENTRIES; idx++) {
> + static_img_info[idx].image_index = 1;
> +
> + // Note: the 16 byte value present in
> + // static_img_info[idx].image_type_id is not strictly a GUID.
> + // The value is used for the sake of code testing.
> + static_img_info[idx].image_type_id.b[0] = idx;
> +
> + static_img_info[idx].image_id = 0;
> + static_img_info[idx].image_id_name = NULL;
> + static_img_info[idx].version = 0;
> + static_img_info[idx].version_name = NULL;
> + static_img_info[idx].size = 0;
> + static_img_info[idx].lowest_supported_image_version = 1;
> + static_img_info[idx].last_attempt_version = 2;
> + static_img_info[idx].last_attempt_status = 3;
> + static_img_info[idx].hardware_instance = 1;
> + }
> +}
> +
> +static efi_status_t
> +EFIAPI efi_test_fmp_get_image_info(struct efi_firmware_management_protocol
> *this,
> +efi_uintn_t *image_info_size,
> +struct efi_firmware_image_descriptor
> *image_info,
> +u32 *descriptor_version,
> +u8 *descriptor_count,
> +efi_uintn_t *descriptor_size,
> +u32 *package_version,
> +u16 **package_version_name)
> +{
> + efi_status_t ret = EFI_SUCCESS;
> +
> + EFI_ENTRY("%p %p %p %p %p %p %p %p\n", this,
> + image_info_size, image_info,
> + descriptor_version, descriptor_count, descriptor_size,
> + package_version, package_version_name);
> +
> + if (!image_info_size)
> + return EFI_EXIT(EFI_INVALID_PARAMETER);
> +
> + if (descriptor_version)
> + *descriptor_version = EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION;
> + if (descriptor_count)
> + *descriptor_count = TEST_ESRT_NUM_ENTRIES;
> + if (descriptor_size)
> + *descriptor_size = sizeof(*image_info);
> + if (package_version)
> + *package_version = 0x;
> + if (package_version_name)
> + *package_version_name = NULL;
> +
> + if (*image_info_size < sizeof(*image_info)) {
> + *image_info_size = *descriptor_size * *descriptor_count;
> + return EFI_EXIT(EFI_BUFFER_TOO_SMALL);
> + }
> +
> + for (int idx = 0; idx < TEST_ESRT_NUM_ENTRIES; idx++)
> + image_info[idx] = static_img_info[idx];
> +
> + return EFI_EXIT(ret);
> +}
> +
> +struct efi_firmware_management_protocol efi_test_fmp = {
> + .get_image_info = efi_test_fmp_get_image_info,
> + .get_image = NULL,
> + .set_image = NULL,
> + .check_image = NULL,
> + .get_package_info = NULL,
> + .set_package_info = NULL,
> +};
> +
> +static v
Re: [PATCH 1/2] efi: Add ESRT to the EFI system table
On Tue, Feb 16, 2021 at 10:06:43AM +0100, Heinrich Schuchardt wrote:
> On 08.02.21 13:52, Jose Marinho wrote:
> > The ESRT is initialised during efi_init_objlist after
> > efi_initialize_system_table().
> >
> > The ESRT is initially created with size for 50 FW image entries.
> > The ESRT is resized when it runs out of space. Every resize adds 50
> > additional entries.
> > The ESRT is populated from information provided by FMP instances only.
> >
> > Signed-off-by: Jose Marinho
> >
> > CC: Heinrich Schuchardt
> > CC: Sughosh Ganu
> > CC: AKASHI Takahiro
> > CC: Ilias Apalodimas
> > CC: Andre Przywara
> > CC: Alexander Graf
> > CC: n...@arm.com
> >
> > ---
> > cmd/efidebug.c| 4 +
> > include/efi_api.h | 21 ++
> > include/efi_loader.h | 19 ++
> > lib/efi_loader/Kconfig| 7 +
> > lib/efi_loader/Makefile | 1 +
> > lib/efi_loader/efi_boottime.c | 2 -
> > lib/efi_loader/efi_capsule.c | 7 +
> > lib/efi_loader/efi_esrt.c | 439 ++
> > lib/efi_loader/efi_setup.c| 6 +
> > 9 files changed, 504 insertions(+), 2 deletions(-)
> > create mode 100644 lib/efi_loader/efi_esrt.c
> >
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> > index 83bc2196a5..4160dde1cf 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -458,6 +458,10 @@ static const struct {
> > "Block IO",
> > EFI_BLOCK_IO_PROTOCOL_GUID,
> > },
> > + {
> > + "EFI System Resource Table",
> > + EFI_SYSTEM_RESOURCE_TABLE_GUID,
> > + },
> > {
> > "Simple File System",
> > EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index 48e48a6263..7eb15bd44c 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -1722,6 +1722,23 @@ struct efi_load_file_protocol {
> > void *buffer);
> > };
> >
> > +struct efi_system_resource_entry {
> > + efi_guid_t fw_class;
> > + uint32_t fw_type;
> > + uint32_t fw_version;
> > + uint32_t lowest_supported_fw_version;
> > + uint32_t capsule_flags;
> > + uint32_t last_attempt_version;
> > + uint32_t last_attempt_status;
> > +} __packed;
> > +
> > +struct efi_system_resource_table {
> > + uint32_t fw_resource_count;
> > + uint32_t fw_resource_count_max;
> > + uint64_t fw_resource_version;
> > + struct efi_system_resource_entry entries[];
> > +} __packed;
> > +
> > /* Boot manager load options */
> > #define LOAD_OPTION_ACTIVE 0x0001
> > #define LOAD_OPTION_FORCE_RECONNECT0x0002
> > @@ -1740,6 +1757,10 @@ struct efi_load_file_protocol {
> > #define ESRT_FW_TYPE_DEVICEFIRMWARE0x0002
> > #define ESRT_FW_TYPE_UEFIDRIVER0x0003
> >
> > +#define EFI_SYSTEM_RESOURCE_TABLE_GUID\
> > + EFI_GUID(0xb122a263, 0x3661, 0x4f68,\
> > + 0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80 )
>
> Please, run scripts/checkpatch.pl on your patches before submitting.
>
> ERROR: space prohibited before that close parenthesis ')'
>
> > +
> > /* Last Attempt Status Values */
> > #define LAST_ATTEMPT_STATUS_SUCCESS0x
> > #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL 0x0001
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index f470bbd636..c85c540041 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -884,4 +884,23 @@ static inline efi_status_t efi_launch_capsules(void)
> >
> > #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >
> > +/*
> > + * Install the ESRT system table.
> > + *
> > + * @return status code
> > + */
> > +efi_status_t efi_esrt_register(void);
> > +
> > +/**
> > + * efi_esrt_add_from_fmp() - Populates a sequence of ESRT entries from the
> > FW
> > + * images in the FMP.
> > + *
> > + * @fmp:the fmp from which fw images are added to the ESRT
> > + *
> > + * Return:
> > + * - EFI_SUCCESS if all the FW images in the FMP are added to the ESRT
> > + * - Error status otherwise
> > + */
> > +efi_status_t efi_esrt_add_from_fmp(struct efi_firmware_management_protocol
> > *fmp);
> > +
> > #endif /* _EFI_LOADER_H */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index e729f727df..12b29180a0 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -347,4 +347,11 @@ config EFI_SECURE_BOOT
> > it is signed with a trusted key. To do that, you need to install,
> > at least, PK, KEK and db.
> >
> > +config EFI_ESRT
> > + bool "Enable the UEFI ESRT generation"
> > + depends on EFI_LOADER
>
> This line is after "if EFI_LOADER".
>
> I assume EFI_ESRT should depend on CONFIG_EFI_HAVE_CAPSULE_SUPPORT.
Strictly speaking, this can be doubtful: According to "23.4.2
ESRT and Firmware Management Protocol,"
Although the ESRT does not require firmware to use Firmware Management
Protocol for updates it is designed to wo
Re: [PATCH 2/3] fit: Use hash.c to call SHA code
Simon,
# This is not a direct comment on this patch.
On Wed, Feb 17, 2021 at 01:50:41PM +1030, Joel Stanley wrote:
> Currently the FIT hashing will call directly into the SHA algorithms to
> get a hash.
>
> This moves the fit code to use hash_lookup_algo, giving a common
> entrypoint into the hashing code and removing the duplicated algorithm
> look up. It also allows the use of hardware acceleration if configured.
>
> Signed-off-by: Joel Stanley
> ---
> common/image-fit.c | 34 --
> 1 file changed, 8 insertions(+), 26 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index 28b3d2b19111..3451cdecc95b 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1210,37 +1210,19 @@ int fit_set_timestamp(void *fit, int noffset, time_t
> timestamp)
> * 0, on success
> *-1, when algo is unsupported
> */
> -int calculate_hash(const void *data, int data_len, const char *algo,
> +int calculate_hash(const void *data, int data_len, const char *algo_name,
> uint8_t *value, int *value_len)
> {
> - if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
> - *((uint32_t *)value) = crc32_wd(0, data, data_len,
> - CHUNKSZ_CRC32);
> - *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
> - *value_len = 4;
> - } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
> - sha1_csum_wd((unsigned char *)data, data_len,
> - (unsigned char *)value, CHUNKSZ_SHA1);
> - *value_len = 20;
> - } else if (IMAGE_ENABLE_SHA256 && strcmp(algo, "sha256") == 0) {
> - sha256_csum_wd((unsigned char *)data, data_len,
> -(unsigned char *)value, CHUNKSZ_SHA256);
> - *value_len = SHA256_SUM_LEN;
> - } else if (IMAGE_ENABLE_SHA384 && strcmp(algo, "sha384") == 0) {
> - sha384_csum_wd((unsigned char *)data, data_len,
> -(unsigned char *)value, CHUNKSZ_SHA384);
> - *value_len = SHA384_SUM_LEN;
> - } else if (IMAGE_ENABLE_SHA512 && strcmp(algo, "sha512") == 0) {
> - sha512_csum_wd((unsigned char *)data, data_len,
> -(unsigned char *)value, CHUNKSZ_SHA512);
> - *value_len = SHA512_SUM_LEN;
> - } else if (IMAGE_ENABLE_MD5 && strcmp(algo, "md5") == 0) {
> - md5_wd((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
> - *value_len = 16;
> - } else {
> + struct hash_algo *algo;
> +
> + if (hash_lookup_algo(algo_name, &algo)) {
> debug("Unsupported hash alogrithm\n");
> return -1;
> }
> +
> + algo->hash_func_ws(data, data_len, value, algo->chunk_size);
> + *value_len = algo->digest_size;
With this patch applied, there co-exists a very similar, hence
confusing function, hash_calculate(), in rsa-checksum.c (now checksum.c?).
If there is no particular reason for those two functions,
we'd better unify them?
-Takahiro Akashi
> return 0;
> }
>
> --
> 2.30.0
>
[PATCH 3/3] hash: Allow for SHA512 hardware implementations
Similar to support for SHA1 and SHA256, allow the use of hardware hashing
engine by enabling the algorithm and setting CONFIG_SHA_HW_ACCEL /
CONFIG_SHA_PROG_HW_ACCEL.
Signed-off-by: Joel Stanley
---
common/hash.c| 24 ++--
include/hw_sha.h | 26 ++
lib/Kconfig | 15 +++
3 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index fc64002f736a..10dff7ddb0e7 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -97,7 +97,7 @@ static int hash_finish_sha256(struct hash_algo *algo, void
*ctx, void
}
#endif
-#if defined(CONFIG_SHA384)
+#if defined(CONFIG_SHA384) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
static int hash_init_sha384(struct hash_algo *algo, void **ctxp)
{
sha512_context *ctx = malloc(sizeof(sha512_context));
@@ -125,7 +125,7 @@ static int hash_finish_sha384(struct hash_algo *algo, void
*ctx, void
}
#endif
-#if defined(CONFIG_SHA512)
+#if defined(CONFIG_SHA512) && !defined(CONFIG_SHA_PROG_HW_ACCEL)
static int hash_init_sha512(struct hash_algo *algo, void **ctxp)
{
sha512_context *ctx = malloc(sizeof(sha512_context));
@@ -260,10 +260,20 @@ static struct hash_algo hash_algo[] = {
.name = "sha384",
.digest_size= SHA384_SUM_LEN,
.chunk_size = CHUNKSZ_SHA384,
+#ifdef CONFIG_SHA_HW_ACCEL
+ .hash_func_ws = hw_sha384,
+#else
.hash_func_ws = sha384_csum_wd,
+#endif
+#ifdef CONFIG_SHA_PROG_HW_ACCEL
+ .hash_init = hw_sha_init,
+ .hash_update= hw_sha_update,
+ .hash_finish= hw_sha_finish,
+#else
.hash_init = hash_init_sha384,
.hash_update= hash_update_sha384,
.hash_finish= hash_finish_sha384,
+#endif
},
#endif
#ifdef CONFIG_SHA512
@@ -271,10 +281,20 @@ static struct hash_algo hash_algo[] = {
.name = "sha512",
.digest_size= SHA512_SUM_LEN,
.chunk_size = CHUNKSZ_SHA512,
+#ifdef CONFIG_SHA_HW_ACCEL
+ .hash_func_ws = hw_sha512,
+#else
.hash_func_ws = sha512_csum_wd,
+#endif
+#ifdef CONFIG_SHA_PROG_HW_ACCEL
+ .hash_init = hw_sha_init,
+ .hash_update= hw_sha_update,
+ .hash_finish= hw_sha_finish,
+#else
.hash_init = hash_init_sha512,
.hash_update= hash_update_sha512,
.hash_finish= hash_finish_sha512,
+#endif
},
#endif
{
diff --git a/include/hw_sha.h b/include/hw_sha.h
index 15b1a1c79836..d4f3471c4308 100644
--- a/include/hw_sha.h
+++ b/include/hw_sha.h
@@ -8,6 +8,32 @@
#define __HW_SHA_H
#include
+/**
+ * Computes hash value of input pbuf using h/w acceleration
+ *
+ * @param in_addr A pointer to the input buffer
+ * @param bufleni Byte length of input buffer
+ * @param out_addr A pointer to the output buffer. When complete
+ * 64 bytes are copied to pout[0]...pout[63]. Thus, a user
+ * should allocate at least 64 bytes at pOut in advance.
+ * @param chunk_size chunk size for sha512
+ */
+void hw_sha512(const uchar *in_addr, uint buflen, uchar *out_addr,
+ uint chunk_size);
+
+/**
+ * Computes hash value of input pbuf using h/w acceleration
+ *
+ * @param in_addr A pointer to the input buffer
+ * @param bufleni Byte length of input buffer
+ * @param out_addr A pointer to the output buffer. When complete
+ * 48 bytes are copied to pout[0]...pout[47]. Thus, a user
+ * should allocate at least 48 bytes at pOut in advance.
+ * @param chunk_size chunk size for sha384
+ */
+void hw_sha384(const uchar *in_addr, uint buflen, uchar *out_addr,
+ uint chunk_size);
+
/**
* Computes hash value of input pbuf using h/w acceleration
*
diff --git a/lib/Kconfig b/lib/Kconfig
index b35a71ac368b..0d753eedeced 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -389,19 +389,18 @@ config SHA384
config SHA_HW_ACCEL
bool "Enable hashing using hardware"
help
- This option enables hardware acceleration
- for SHA1/SHA256 hashing.
- This affects the 'hash' command and also the
- hash_lookup_algo() function.
+ This option enables hardware acceleration for SHA hashing.
+ This affects the 'hash' command and also the hash_lookup_algo()
+ function.
config SHA_PROG_HW_ACCEL
bool "Enable Progressive hashing support using hardware"
depends on SHA_HW_ACCEL
help
- This option enables hardware-acceleration for
- SHA1/SHA256 progressive hashing.
- Data can be streamed in a block at a time and the hashing
- is performed in hardware.
+ This option enables hardware-acceleration for SHA progressive
+
[PATCH 2/3] fit: Use hash.c to call SHA code
Currently the FIT hashing will call directly into the SHA algorithms to
get a hash.
This moves the fit code to use hash_lookup_algo, giving a common
entrypoint into the hashing code and removing the duplicated algorithm
look up. It also allows the use of hardware acceleration if configured.
Signed-off-by: Joel Stanley
---
common/image-fit.c | 34 --
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index 28b3d2b19111..3451cdecc95b 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1210,37 +1210,19 @@ int fit_set_timestamp(void *fit, int noffset, time_t
timestamp)
* 0, on success
*-1, when algo is unsupported
*/
-int calculate_hash(const void *data, int data_len, const char *algo,
+int calculate_hash(const void *data, int data_len, const char *algo_name,
uint8_t *value, int *value_len)
{
- if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
- *((uint32_t *)value) = crc32_wd(0, data, data_len,
- CHUNKSZ_CRC32);
- *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
- *value_len = 4;
- } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
- sha1_csum_wd((unsigned char *)data, data_len,
-(unsigned char *)value, CHUNKSZ_SHA1);
- *value_len = 20;
- } else if (IMAGE_ENABLE_SHA256 && strcmp(algo, "sha256") == 0) {
- sha256_csum_wd((unsigned char *)data, data_len,
- (unsigned char *)value, CHUNKSZ_SHA256);
- *value_len = SHA256_SUM_LEN;
- } else if (IMAGE_ENABLE_SHA384 && strcmp(algo, "sha384") == 0) {
- sha384_csum_wd((unsigned char *)data, data_len,
- (unsigned char *)value, CHUNKSZ_SHA384);
- *value_len = SHA384_SUM_LEN;
- } else if (IMAGE_ENABLE_SHA512 && strcmp(algo, "sha512") == 0) {
- sha512_csum_wd((unsigned char *)data, data_len,
- (unsigned char *)value, CHUNKSZ_SHA512);
- *value_len = SHA512_SUM_LEN;
- } else if (IMAGE_ENABLE_MD5 && strcmp(algo, "md5") == 0) {
- md5_wd((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
- *value_len = 16;
- } else {
+ struct hash_algo *algo;
+
+ if (hash_lookup_algo(algo_name, &algo)) {
debug("Unsupported hash alogrithm\n");
return -1;
}
+
+ algo->hash_func_ws(data, data_len, value, algo->chunk_size);
+ *value_len = algo->digest_size;
+
return 0;
}
--
2.30.0
[PATCH 1/3] hw_sha: Fix coding style errors
Checkpatch complains about: ERROR: "foo * bar" should be "foo *bar" and CHECK: Alignment should match open parenthesis Signed-off-by: Joel Stanley --- include/hw_sha.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/hw_sha.h b/include/hw_sha.h index 991e496a3cb2..15b1a1c79836 100644 --- a/include/hw_sha.h +++ b/include/hw_sha.h @@ -18,8 +18,8 @@ * should allocate at least 32 bytes at pOut in advance. * @param chunk_size chunk size for sha256 */ -void hw_sha256(const uchar * in_addr, uint buflen, - uchar * out_addr, uint chunk_size); +void hw_sha256(const uchar *in_addr, uint buflen, uchar *out_addr, + uint chunk_size); /** * Computes hash value of input pbuf using h/w acceleration @@ -31,8 +31,8 @@ void hw_sha256(const uchar * in_addr, uint buflen, * should allocate at least 32 bytes at pOut in advance. * @param chunk_size chunk_size for sha1 */ -void hw_sha1(const uchar * in_addr, uint buflen, - uchar * out_addr, uint chunk_size); +void hw_sha1(const uchar *in_addr, uint buflen, uchar *out_addr, +uint chunk_size); /* * Create the context for sha progressive hashing using h/w acceleration @@ -56,7 +56,7 @@ int hw_sha_init(struct hash_algo *algo, void **ctxp); * @return 0 if ok, -ve on error */ int hw_sha_update(struct hash_algo *algo, void *ctx, const void *buf, -unsigned int size, int is_last); + unsigned int size, int is_last); /* * Copy sha hash result at destination location @@ -70,6 +70,6 @@ int hw_sha_update(struct hash_algo *algo, void *ctx, const void *buf, * @return 0 if ok, -ve on error */ int hw_sha_finish(struct hash_algo *algo, void *ctx, void *dest_buf, -int size); + int size); #endif -- 2.30.0
[PATCH 0/3] Improvements to FIT hashing
Here are some small changes to the FIT hashing code in order to use more code from common/, which in turns allows hw implementations of SHA. This was motivated by a need to reduce the SPL size for the Aspeed platforms by using the hardware engine. I have a driver for the Aspeed SoC that I will submit. Joel Stanley (3): hw_sha: Fix coding style errors fit: Use hash.c to call SHA code hash: Allow for SHA512 hardware implementations common/hash.c | 24 ++-- common/image-fit.c | 34 -- include/hw_sha.h | 38 -- lib/Kconfig| 15 +++ 4 files changed, 69 insertions(+), 42 deletions(-) -- 2.30.0
Re: [PATCH 1/1] doc: Add reference to U-Boot project in conf.py
On Wed, Feb 17, 2021 at 1:41 AM Heinrich Schuchardt wrote:
>
> With the last update of conf.py the references to U-Boot where replaced by
> references to Linux.
>
> Fix the project references in the generated documentation.
>
> Reported by: Simon Glass
Wrong tag. Should be: "Reported-by"
Reported-by: Bin Meng
See https://lists.denx.de/pipermail/u-boot/2021-February/439615.html
> Fixes: 98f01cf7a22e ("doc: update Kernel documentation build system")
> Signed-off-by: Heinrich Schuchardt
> ---
> doc/conf.py | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
Otherwise:
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Re: [PATCH 1/1] doc: Add reference to U-Boot project in conf.py
On Tue, 16 Feb 2021 at 10:41, Heinrich Schuchardt wrote:
>
> With the last update of conf.py the references to U-Boot where replaced by
> references to Linux.
>
> Fix the project references in the generated documentation.
>
> Reported by: Simon Glass
> Fixes: 98f01cf7a22e ("doc: update Kernel documentation build system")
> Signed-off-by: Heinrich Schuchardt
> ---
> doc/conf.py | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH] lib: rsa: Add debug message on algo mismatch
Hi Sean,
On Tue, 16 Feb 2021 at 10:05, Sean Anderson wrote:
>
>
>
> On 2/16/21 12:01 PM, Wolfgang Denk wrote:
> > Dear Sean Anderson,
> >
> > In message <20210216164016.635125-1-sean.ander...@seco.com> you wrote:
> >> Currently we fail silently if there is an algorithm mismatch. To help
> >> distinguish this failure condition.
> >>
> >> Signed-off-by: Sean Anderson
> >> ---
> >>
> >> lib/rsa/rsa-verify.c | 5 -
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> >> index e34d3293d1..aee76f42d5 100644
> >> --- a/lib/rsa/rsa-verify.c
> >> +++ b/lib/rsa/rsa-verify.c
> >> @@ -447,8 +447,11 @@ static int rsa_verify_with_keynode(struct
> image_sign_info *info,
> >> }
> >>
> >> algo = fdt_getprop(blob, node, "algo", NULL);
> >> - if (strcmp(info->name, algo))
> >> + if (strcmp(info->name, algo)) {
> >> + debug("%s: Wrong algo: have %s, expected %s", __func__,
> >> + info->name, algo);
> >> return -EFAULT;
> >> + }
> >
> > If this is considered an error, should that not be a printf() then
> > instead of a debug() which users will never see?
>
> I also thought that, but the much of the rest of this file also uses
> debug() to report errors. Perhaps there are security implications? Or
> perhaps it was done to reduce binary size? Simon, can you comment on
> this?
In general should not print messages in the bowels of the code, since
then there is no way to control what is printed. So long as the error
is produced it can be reported and propagated up, and you can document
what the different error codes mean. It also bloats the code to
include strings everywhere.
I suggest adding logging around the return value as it makes it easy
to trace things:
CONFIG_LOG_ERROR_RETURN=y
and return the error with:
return log_msg_ret("algo", -EFAULT)
Regards,
Simon
Re: [PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
On Wed, Feb 17, 2021 at 02:42:21AM +0100, Heiko Stuebner wrote: > Hi Tom, > > Am Dienstag, 16. Februar 2021, 15:26:52 CET schrieb Tom Rini: > > On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote: > > > Hi Roger, > > > > > > Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne: > > > > From: Roger Pau Monné > > > > > > > > Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the > > > > resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. > > > > Removing the setting from the defconfig allows U-Boot to load > > > > successfully. > > > > > > Hmm, I'd disagree slightly. > > > > > > In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as > > > > > > /* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */ > > > #define CONFIG_SPL_PAD_TO 8355840 > > > > > > so it's a static value but based on the MMCSD_RAW_MODE... config option. > > > > > > So instead of mandating one specific MMCSD_RAW_MODE... value > > > that CONFIG_SPL_PAD_TO should be defined based on the the > > > actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > > and not some static number that then gets enforced for all boards. > > > > So, what does CONFIG_SPL_PAD_TO actually mean, in this case? And > > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR ? What I'm getting at is that we > > generally have some required to be fixed (by the SoC/ROM/etc) locations > > some parts of our SPL/TPL/U-Boot need to be at and then the rest of the > > values are (supposed to be) well and carefully chosen offsets and not > > changed around. So with the above comment in the code to explain where > > 8355840 came from, it also shouldn't and nor should > > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR be changed without a compelling > > reason. > > Normally Rockchip platforms have two loader binaries: > > - idbLoader.img (tpl + spl, or only spl), loving at offset 64 of a sd-card > This is mandated by the bootrom > - u-boot.itb (u-boot, atf, etc) living at SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > As SPL will load from the location specified in the config, this location > can be set depending on emmc/sd-card/whatever needs. > > It looks like recently a new binary creating method was added that creates > a u-boot-rockchip.bin combining these somewhat automatically: > > idbLoader.img > + SPL_PAD_TO > + u-boot.itb > > So that only that binary needs to be flashed to the boot medium > instead of two. > > So the SPL_PAD_TO essentially would mandate one specific > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR for every board. > > > For the odroid-go2 itself it doesn't really matter I guess, but there are > other boards with different requirements, so mandating one specific place > for the main uboot for all boards that will ever exist seems a bit counter- > intuitive to me. I would say that yes, it's quite intentional that all boards for a given SoC (or SoC family) would use the same value for SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and NOT leave it up to be per-board. It should be a matter of kilobytes being potentially wasted which is (often or most likely) worth sacrificing in the name of consistency and ease of future use / development. In other cases this ends up being something around "ROM will only load something of $X size, round that up a little bit, place U-Boot there, as it's the next thing to load". -- Tom signature.asc Description: PGP signature
Re: [PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
Hi Tom, Am Dienstag, 16. Februar 2021, 15:26:52 CET schrieb Tom Rini: > On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote: > > Hi Roger, > > > > Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne: > > > From: Roger Pau Monné > > > > > > Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the > > > resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. > > > Removing the setting from the defconfig allows U-Boot to load > > > successfully. > > > > Hmm, I'd disagree slightly. > > > > In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as > > > > /* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */ > > #define CONFIG_SPL_PAD_TO 8355840 > > > > so it's a static value but based on the MMCSD_RAW_MODE... config option. > > > > So instead of mandating one specific MMCSD_RAW_MODE... value > > that CONFIG_SPL_PAD_TO should be defined based on the the > > actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > and not some static number that then gets enforced for all boards. > > So, what does CONFIG_SPL_PAD_TO actually mean, in this case? And > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR ? What I'm getting at is that we > generally have some required to be fixed (by the SoC/ROM/etc) locations > some parts of our SPL/TPL/U-Boot need to be at and then the rest of the > values are (supposed to be) well and carefully chosen offsets and not > changed around. So with the above comment in the code to explain where > 8355840 came from, it also shouldn't and nor should > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR be changed without a compelling > reason. Normally Rockchip platforms have two loader binaries: - idbLoader.img (tpl + spl, or only spl), loving at offset 64 of a sd-card This is mandated by the bootrom - u-boot.itb (u-boot, atf, etc) living at SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR As SPL will load from the location specified in the config, this location can be set depending on emmc/sd-card/whatever needs. It looks like recently a new binary creating method was added that creates a u-boot-rockchip.bin combining these somewhat automatically: idbLoader.img + SPL_PAD_TO + u-boot.itb So that only that binary needs to be flashed to the boot medium instead of two. So the SPL_PAD_TO essentially would mandate one specific SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR for every board. For the odroid-go2 itself it doesn't really matter I guess, but there are other boards with different requirements, so mandating one specific place for the main uboot for all boards that will ever exist seems a bit counter- intuitive to me. Heiko
Re: [PATCH] board: sl28: add DSA support for variant 2
Am 2021-02-17 00:55, schrieb Vladimir Oltean:
On Wed, Feb 17, 2021 at 12:29:33AM +0100, Michael Walle wrote:
Am 2021-02-16 23:53, schrieb Vladimir Oltean:
> On Tue, Feb 16, 2021 at 11:25:25PM +0100, Michael Walle wrote:
> > Now that u-boot gained DSA support, and it is already enabled for the
> > kontron_sl28 board, add the last missing piece and enable the
> > corresponding devices it in the device tree.
> >
> > Signed-off-by: Michael Walle
> > ---
> > .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46
> > +++
> > 1 file changed, 46 insertions(+)
> >
> > diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > index 1ea1265bcf..39280cd1c7 100644
> > --- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > +++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > @@ -15,6 +15,12 @@
> > / {
> > model = "Kontron SMARC-sAL28 (TSN-on-module)";
> > compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
> > +
> > + aliases {
> > + eth0 = &mscc_felix_port0;
> > + eth1 = &mscc_felix_port1;
> > + eth2 = &enetc2;
>
> The way DSA is intended to be used is that the alias for the DSA master
> (host port) comes first, then the alias for switch ports.
>
> The reasoning is that U-Boot has MAC address inheritance rules. If
> ethNaddr (where N is the sequence id of the Ethernet udevice
> corresponding to a switch port) is not defined in the env, then the MAC
> address is inherited from the master interface.
>
> But the address cannot be inherited unless the master has already been
> probed. So it must be probed first, so it needs to have a lower numbered
> alias.
Hm. I reordered the aliases because ethaddr should be the MAC
address for the first port and eth1addr the one for the second
port.
Every board has a pool of MAC addresses and the vendor version of
u-boot will populate the environment accoring to the pool. I.e.
there will be ethaddr, eth1addr, .. ethNaddr. This is still missing
in the vanilla bootloader (no EEPROM decode and no access to the
SPI OTP area yet). So for now, the user will have to supply the
ethNaddr variables.
The DSA master is an Ethernet port too which needs a MAC address of its
own, and a board vendor should think about what MAC address it wants to
assign to it.
In the case of NXP LS1028A, the MAC address assigned to eno2 doesn't
really matter, since the tagging protocol used by the Felix switch
shifts the MAC addresses to the right, replacing them with the DSA
header plus some prefix/padding. That prefix maps over the Ethernet
header in such a way that ENETC believes it's seeing broadcast frames
(ff:ff:ff:ff:ff:ff), so it accepts them regardless of the MAC address
that was assigned to eno2 and therefore used for RX filtering.
But not all switches are like that. The vast majority either have a DSA
header before the EtherType, or as a tail tag. So the source &
destination
MAC addresses are not shifted, and whatever the MAC address the front
panel port claims, the DSA master will perceive the same MAC address
too. This implies that the sanest approach for these switches is to let
DSA inherit the MAC address from the master. If they have a unique
MAC address, someone would have to put the DSA master in promiscuous
mode, something which we do not do currently.
So it should be OK in principle. But if - for some reason - there
is only one ethaddr, it won't work, right?
The code should be more expressive than my words:
/*
* Inherit port's hwaddr from the DSA master, unless the port already
* has a unique MAC address specified in the environment.
*/
eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
if (!is_zero_ethaddr(env_enetaddr))
return 0;
master = dsa_get_master(dev);
if (!master)
return 0;
master_pdata = dev_get_plat(master);
eth_pdata = dev_get_plat(pdev);
memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
master_pdata->enetaddr);
If the environment is populated with only one ethaddr, that will work.
DSA calls eth_env_set_enetaddr_by_index automatically as you can see.
So next time you run saveenv, eth1addr and eth2addr will automagically
have the value of ethaddr too. They can be overridden too, and that
works as well as long as what I said above holds true (the master does
not need to go into promiscuous mode in order to receive packets with a
different MAC address from the encapsulated packet's perspective).
Unfortunately, I don't see a way to make both work:
(1) the first port should have ethaddr and the second ethaddr
(2) it should work with just one ethaddr
I don't understand "the first port should have ethaddr and the second
ethaddr".
This should read "the second eth1addr".
You mea
Re: [PATCH] board: sl28: add DSA support for variant 2
On Wed, Feb 17, 2021 at 12:29:33AM +0100, Michael Walle wrote:
> Am 2021-02-16 23:53, schrieb Vladimir Oltean:
> > On Tue, Feb 16, 2021 at 11:25:25PM +0100, Michael Walle wrote:
> > > Now that u-boot gained DSA support, and it is already enabled for the
> > > kontron_sl28 board, add the last missing piece and enable the
> > > corresponding devices it in the device tree.
> > >
> > > Signed-off-by: Michael Walle
> > > ---
> > > .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46
> > > +++
> > > 1 file changed, 46 insertions(+)
> > >
> > > diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > > b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > > index 1ea1265bcf..39280cd1c7 100644
> > > --- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > > +++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> > > @@ -15,6 +15,12 @@
> > > / {
> > > model = "Kontron SMARC-sAL28 (TSN-on-module)";
> > > compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
> > > +
> > > + aliases {
> > > + eth0 = &mscc_felix_port0;
> > > + eth1 = &mscc_felix_port1;
> > > + eth2 = &enetc2;
> >
> > The way DSA is intended to be used is that the alias for the DSA master
> > (host port) comes first, then the alias for switch ports.
> >
> > The reasoning is that U-Boot has MAC address inheritance rules. If
> > ethNaddr (where N is the sequence id of the Ethernet udevice
> > corresponding to a switch port) is not defined in the env, then the MAC
> > address is inherited from the master interface.
> >
> > But the address cannot be inherited unless the master has already been
> > probed. So it must be probed first, so it needs to have a lower numbered
> > alias.
>
> Hm. I reordered the aliases because ethaddr should be the MAC
> address for the first port and eth1addr the one for the second
> port.
>
> Every board has a pool of MAC addresses and the vendor version of
> u-boot will populate the environment accoring to the pool. I.e.
> there will be ethaddr, eth1addr, .. ethNaddr. This is still missing
> in the vanilla bootloader (no EEPROM decode and no access to the
> SPI OTP area yet). So for now, the user will have to supply the
> ethNaddr variables.
The DSA master is an Ethernet port too which needs a MAC address of its
own, and a board vendor should think about what MAC address it wants to
assign to it.
In the case of NXP LS1028A, the MAC address assigned to eno2 doesn't
really matter, since the tagging protocol used by the Felix switch
shifts the MAC addresses to the right, replacing them with the DSA
header plus some prefix/padding. That prefix maps over the Ethernet
header in such a way that ENETC believes it's seeing broadcast frames
(ff:ff:ff:ff:ff:ff), so it accepts them regardless of the MAC address
that was assigned to eno2 and therefore used for RX filtering.
But not all switches are like that. The vast majority either have a DSA
header before the EtherType, or as a tail tag. So the source & destination
MAC addresses are not shifted, and whatever the MAC address the front
panel port claims, the DSA master will perceive the same MAC address
too. This implies that the sanest approach for these switches is to let
DSA inherit the MAC address from the master. If they have a unique
MAC address, someone would have to put the DSA master in promiscuous
mode, something which we do not do currently.
> So it should be OK in principle. But if - for some reason - there
> is only one ethaddr, it won't work, right?
The code should be more expressive than my words:
/*
* Inherit port's hwaddr from the DSA master, unless the port already
* has a unique MAC address specified in the environment.
*/
eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
if (!is_zero_ethaddr(env_enetaddr))
return 0;
master = dsa_get_master(dev);
if (!master)
return 0;
master_pdata = dev_get_plat(master);
eth_pdata = dev_get_plat(pdev);
memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
master_pdata->enetaddr);
If the environment is populated with only one ethaddr, that will work.
DSA calls eth_env_set_enetaddr_by_index automatically as you can see.
So next time you run saveenv, eth1addr and eth2addr will automagically
have the value of ethaddr too. They can be overridden too, and that
works as well as long as what I said above holds true (the master does
not need to go into promiscuous mode in order to receive packets with a
different MAC address from the encapsulated packet's perspective).
> Unfortunately, I don't see a way to make both work:
> (1) the first port should have ethaddr and the second ethaddr
> (2) it should work with just one ethaddr
I don't understand "the first port should have ethaddr and the second
ethaddr". You mean "the first and t
Re: [PATCH] board: sl28: add DSA support for variant 2
Am 2021-02-16 23:53, schrieb Vladimir Oltean:
On Tue, Feb 16, 2021 at 11:25:25PM +0100, Michael Walle wrote:
Now that u-boot gained DSA support, and it is already enabled for the
kontron_sl28 board, add the last missing piece and enable the
corresponding devices it in the device tree.
Signed-off-by: Michael Walle
---
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46
+++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 1ea1265bcf..39280cd1c7 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -15,6 +15,12 @@
/ {
model = "Kontron SMARC-sAL28 (TSN-on-module)";
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
+
+ aliases {
+ eth0 = &mscc_felix_port0;
+ eth1 = &mscc_felix_port1;
+ eth2 = &enetc2;
The way DSA is intended to be used is that the alias for the DSA master
(host port) comes first, then the alias for switch ports.
The reasoning is that U-Boot has MAC address inheritance rules. If
ethNaddr (where N is the sequence id of the Ethernet udevice
corresponding to a switch port) is not defined in the env, then the MAC
address is inherited from the master interface.
But the address cannot be inherited unless the master has already been
probed. So it must be probed first, so it needs to have a lower
numbered
alias.
Hm. I reordered the aliases because ethaddr should be the MAC
address for the first port and eth1addr the one for the second
port.
Every board has a pool of MAC addresses and the vendor version of
u-boot will populate the environment accoring to the pool. I.e.
there will be ethaddr, eth1addr, .. ethNaddr. This is still missing
in the vanilla bootloader (no EEPROM decode and no access to the
SPI OTP area yet). So for now, the user will have to supply the
ethNaddr variables.
So it should be OK in principle. But if - for some reason - there
is only one ethaddr, it won't work, right?
Unfortunately, I don't see a way to make both work:
(1) the first port should have ethaddr and the second ethaddr
(2) it should work with just one ethaddr
-michael
Re: [PATCH] board: sl28: add DSA support for variant 2
On Tue, Feb 16, 2021 at 11:25:25PM +0100, Michael Walle wrote:
> Now that u-boot gained DSA support, and it is already enabled for the
> kontron_sl28 board, add the last missing piece and enable the
> corresponding devices it in the device tree.
>
> Signed-off-by: Michael Walle
> ---
> .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 +++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> index 1ea1265bcf..39280cd1c7 100644
> --- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> +++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
> @@ -15,6 +15,12 @@
> / {
> model = "Kontron SMARC-sAL28 (TSN-on-module)";
> compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
> +
> + aliases {
> + eth0 = &mscc_felix_port0;
> + eth1 = &mscc_felix_port1;
> + eth2 = &enetc2;
The way DSA is intended to be used is that the alias for the DSA master
(host port) comes first, then the alias for switch ports.
The reasoning is that U-Boot has MAC address inheritance rules. If
ethNaddr (where N is the sequence id of the Ethernet udevice
corresponding to a switch port) is not defined in the env, then the MAC
address is inherited from the master interface.
But the address cannot be inherited unless the master has already been
probed. So it must be probed first, so it needs to have a lower numbered
alias.
[PATCH 4/4] sandbox: add a DSA sandbox driver and unit test
From: Claudiu Manoil
The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a very
simple tag to identify the ports.
The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox
driver. The 'dsa-test-eth' is not intended for testing the eth class
code however, but it is used to emulate traffic through the 'lan0' and
'lan1' front pannel switch ports. To achieve this the dsa sandbox driver
registers a tx handler for the 'dsa-test-eth' device. The switch ports,
labeled as 'lan0' and 'lan1', are also registered as eth devices by the
dsa class code this time. So pinging through these switch ports is as
easy as:
=> setenv ethact lan0
=> ping 1.2.3.5
Unit tests for the dsa class code were also added. The 'dsa_probe'
test exercises most API functions from dsa.h. The 'dsa' unit test
simply exercises ARP/ICMP traffic through the two switch ports,
including tag injection and extraction, with the help of the dsa
sandbox driver.
I took care to minimize the impact on the existing eth unit tests,
though some adjustments needed to be made with the addition of
extra eth interfaces used by the dsa unit tests. The additional eth
interfaces also require MAC addresses, these have been added to the
sandbox default environment.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Reviewed-by: Simon Glass
Signed-off-by: Vladimir Oltean
---
arch/Kconfig | 2 +
arch/sandbox/dts/test.dts | 48 ++
drivers/net/Kconfig | 9 ++
drivers/net/Makefile | 1 +
drivers/net/dsa_sandbox.c | 179 ++
include/configs/sandbox.h | 2 +
test/dm/Makefile | 1 +
test/dm/dsa.c | 82 +
test/dm/eth.c | 10 +--
9 files changed, 329 insertions(+), 5 deletions(-)
create mode 100644 drivers/net/dsa_sandbox.c
create mode 100644 test/dm/dsa.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 6c8167826cf8..f114a025fa5b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -161,6 +161,8 @@ config SANDBOX
imply CMD_CLONE
imply SILENT_CONSOLE
imply BOOTARGS_SUBST
+ imply PHY_FIXED
+ imply DM_DSA
config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e95f4631bf2f..d4ee6ddbbe4c 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -14,7 +14,9 @@
aliases {
console = &uart0;
eth0 = "/eth@10002000";
+ eth2 = &swp_0;
eth3 = ð_3;
+ eth4 = &dsa_eth0;
eth5 = ð_5;
gpio1 = &gpio_a;
gpio2 = &gpio_b;
@@ -432,6 +434,52 @@
fake-host-hwaddr = [00 00 66 44 22 22];
};
+ dsa_eth0: dsa-test-eth {
+ compatible = "sandbox,eth";
+ reg = <0x10006000 0x1000>;
+ fake-host-hwaddr = [00 00 66 44 22 66];
+ };
+
+ dsa-test {
+ compatible = "sandbox,dsa";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ swp_0: port@0 {
+ reg = <0>;
+ label = "lan0";
+ phy-mode = "rgmii-rxid";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ swp_1: port@1 {
+ reg = <1>;
+ label = "lan1";
+ phy-mode = "rgmii-txid";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ ethernet = <&dsa_eth0>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
firmware {
sandbox_firmware: sandbox-firmware {
compatible = "sandbox,firmware";
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0e84c22b5075..f96ee642494a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -78,6 +78,15 @@ config DM_ETH_PHY
help
Enable driver model for Ethernet Generic PHY .
+config DSA_SANDBOX
+ depends on DM_DSA && SANDBOX
+ default y
+ bool "Sandbox: Mocked DSA driver"
+ help
+
[PATCH 3/4] net: mdio: teach dm_eth_phy_connect to connect to fixed PHY
From: Vladimir Oltean
It would be desirable for top-level callers of PHYLIB to deal with as
little complexity as possible, and when they call dm_eth_phy_connect,
they get a struct phy_device that "just works".
There is a phy_connect_fixed interception put in phy_connect, however
dm_eth_phy_connect will not reach there: if will search for a phy-handle
all by itself, and error out if there isn't one. So we can make callers
of dm_eth_phy_connect suffer by having them call:
err = dm_eth_phy_connect();
if (err)
err = dm_eth_phy_connect_fixed();
or we can just add the logic in dm_eth_phy_connect() that searches for a
fixed-link before searching for a phy-handle.
In fact we already have an in-tree driver that can make use of this
refactoring: the Freescale TSEC driver.
Signed-off-by: Vladimir Oltean
---
drivers/net/tsec.c | 6 +-
net/mdio-uclass.c | 12 ++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index ec4868937257..f801d020fb65 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -707,11 +707,7 @@ static int init_phy(struct tsec_private *priv)
tsec_configure_serdes(priv);
#if defined(CONFIG_DM_ETH) && defined(CONFIG_DM_MDIO)
- if (ofnode_valid(ofnode_find_subnode(dev_ofnode(priv->dev),
-"fixed-link")))
- phydev = phy_connect(NULL, 0, priv->dev, priv->interface);
- else
- phydev = dm_eth_phy_connect(priv->dev);
+ phydev = dm_eth_phy_connect(priv->dev);
#else
phydev = phy_connect(priv->bus, priv->phyaddr, priv->dev,
priv->interface);
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 697e5f838d94..766d4711cc23 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -177,9 +177,10 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
/* Connect to a PHY linked in eth DT node */
struct phy_device *dm_eth_phy_connect(struct udevice *ethdev)
{
- const char *if_str;
+ ofnode node = dev_ofnode(ethdev), subnode;
phy_interface_t interface;
struct phy_device *phy;
+ const char *if_str;
int i;
if (!dev_has_ofnode(ethdev)) {
@@ -200,7 +201,14 @@ struct phy_device *dm_eth_phy_connect(struct udevice
*ethdev)
if (interface == PHY_INTERFACE_MODE_NONE)
dev_dbg(ethdev, "can't find interface mode, default to NONE\n");
- phy = dm_eth_connect_phy_handle(ethdev, interface);
+ subnode = ofnode_find_subnode(node, "fixed-link");
+ if (ofnode_valid(subnode)) {
+ phy = phy_connect(NULL, 0, ethdev, interface);
+ if (phy)
+ phy->node = subnode;
+ } else {
+ phy = dm_eth_connect_phy_handle(ethdev, interface);
+ }
if (!phy)
return NULL;
--
2.25.1
[PATCH 2/4] net: phy: drop #ifdef CONFIG_DM_ETH around phy_connect_fixed
From: Vladimir Oltean
In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
CONFIG_DM_ETH, so the function prototype definition when CONFIG_DM_ETH=n
does nothing, so it can be dropped. It is also never reachable, since
the whole function is already under #ifdef CONFIG_PHY_FIXED (which
again, as I said, depends on CONFIG_DM_ETH=y).
Signed-off-by: Vladimir Oltean
---
drivers/net/phy/phy.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 2feb559bba97..eae40cc0d6b7 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1012,15 +1012,9 @@ struct phy_device *fixed_phy_create(ofnode node)
return phydev;
}
-#ifdef CONFIG_DM_ETH
static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
struct udevice *dev,
phy_interface_t interface)
-#else
-static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
- struct eth_device *dev,
- phy_interface_t interface)
-#endif
{
ofnode node = dev_ofnode(dev), subnode;
struct phy_device *phydev;
--
2.25.1
[PATCH 1/4] net: phy: fixed: be compatible with live OF tree
From: Vladimir Oltean
On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined as
const struct device_node *np, while on the flat DT systems it is defined
as a long of_offset into gd->fdt_blob.
It is desirable that the fixed PHY driver uses the higher-level ofnode
abstraction instead of parsing gd->fdt_blob directly, because that
enables it to work on live OF systems.
The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c10 ("drivers/net/phy: add fixed-phy / fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already mismatched
leading to a potential truncation (flat OF offset was supposed to be a
long and not an int), we really cannot extend this hack any longer,
because there's no way an int will hold the other representation of
ofnode, the struct device_node *np.
So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in commit eef0b8a930d1 ("net:
phy: add ofnode node to struct phy_device"). This will populate
phydev->node for the fixed PHY.
Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.
I do believe I've converted all the possible call paths for creating a
PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.
Signed-off-by: Vladimir Oltean
---
drivers/net/phy/fixed.c | 30 ++
drivers/net/phy/phy.c | 30 +++---
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 1a38c29469a4..d67c22a7b8c7 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -15,15 +15,17 @@
DECLARE_GLOBAL_DATA_PTR;
-int fixedphy_probe(struct phy_device *phydev)
+static int fixedphy_of_init(struct phy_device *phydev)
{
+ ofnode node = phy_get_ofnode(phydev);
struct fixed_link *priv;
- int ofnode = phydev->addr;
u32 val;
+ if (!ofnode_valid(node))
+ return -EINVAL;
+
/* check for mandatory properties within fixed-link node */
- val = fdt_getprop_u32_default_node(gd->fdt_blob,
- ofnode, 0, "speed", 0);
+ val = ofnode_read_u32_default(node, "speed", 0);
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 &&
val != SPEED_2500 && val != SPEED_1) {
printf("ERROR: no/invalid speed given in fixed-link node!");
@@ -33,14 +35,26 @@ int fixedphy_probe(struct phy_device *phydev)
priv = malloc(sizeof(*priv));
if (!priv)
return -ENOMEM;
+
memset(priv, 0, sizeof(*priv));
phydev->priv = priv;
priv->link_speed = val;
- priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, "full-duplex");
- priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "pause");
- priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "asym-pause");
+ priv->duplex = ofnode_read_bool(node, "full-duplex");
+ priv->pause = ofnode_read_bool(node, "pause");
+ priv->asym_pause = ofnode_read_bool(node, "asym-pause");
+
+ return 0;
+}
+
+static int fixedphy_config(struct phy_device *phydev)
+{
+ int err;
+
+ err = fixedphy_of_init(phydev);
+ if (err)
+ return err;
/* fixed-link phy must not be reset by core phy code */
phydev->flags |= PHY_FLAG_BROKEN_RESET;
@@ -71,7 +85,7 @@ static struct phy_driver fixedphy_driver = {
.mask = 0x,
.name = "Fixed PHY",
.features = PHY_GBIT_FEATURES | SUPPORTED_MII,
- .probe = fixedphy_probe,
+ .config = fixedphy_config,
.startup= fixedphy_startup,
.shutdown = fixedphy_shutdown,
};
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 89e3076bfd25..2feb559bba97 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -988,6 +988,7 @@ static struct phy_device *phy_connect_gmii2rgmii(struct
mii_dev *bus,
struct phy_device *fixed_phy_create(ofnode node)
{
phy_interface_t interface = PHY_INTERFACE_MODE_NONE;
+ struct phy_device *phydev;
const char *if_str;
ofnode subnode;
@@ -1004,8 +1005,11 @@ struct phy_device *fixed_phy_create(ofnode node)
return NULL;
}
- return phy_device_cr
[PATCH 0/4] Sandbox driver for DSA uclass
From: Vladimir Oltean This is a spin-off of the larger patch series for DSA in U-Boot: https://patchwork.ozlabs.org/project/uboot/cover/20210125122357.414742-1-olte...@gmail.com/ There is currently an issue which prevents DSA from working properly with the sandbox: the sandbox uses CONFIG_OF_LIVE, and DSA has a dependency in CONFIG_FIXED_PHY which is broken with CONFIG_OF_LIVE. At Tom Rini's request, the DSA patches were merged without support for sandbox, and here we are now, submitting them separately. Claudiu Manoil (1): sandbox: add a DSA sandbox driver and unit test Vladimir Oltean (3): net: phy: fixed: be compatible with live OF tree net: phy: drop #ifdef CONFIG_DM_ETH around phy_connect_fixed net: mdio: teach dm_eth_phy_connect to connect to fixed PHY arch/Kconfig | 2 + arch/sandbox/dts/test.dts | 48 ++ drivers/net/Kconfig | 9 ++ drivers/net/Makefile | 1 + drivers/net/dsa_sandbox.c | 179 ++ drivers/net/phy/fixed.c | 30 +-- drivers/net/phy/phy.c | 36 drivers/net/tsec.c| 6 +- include/configs/sandbox.h | 2 + net/mdio-uclass.c | 12 ++- test/dm/Makefile | 1 + test/dm/dsa.c | 82 + test/dm/eth.c | 10 +-- 13 files changed, 377 insertions(+), 41 deletions(-) create mode 100644 drivers/net/dsa_sandbox.c create mode 100644 test/dm/dsa.c -- 2.25.1
Re: [PATCH 1/4] mmc: fsl_esdhc_imx: Add a compatible for i.MX51
On 2/15/21 8:58 PM, Fabio Estevam wrote:
> Add a compatible for i.MX51 so that i.MX51 can use this driver
> via driver model.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/fsl_esdhc_imx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index 8ac859797f04..827a6f113f3b 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -1705,6 +1705,7 @@ static struct esdhc_soc_data usdhc_imx8qm_data = {
> };
>
> static const struct udevice_id fsl_esdhc_ids[] = {
> + { .compatible = "fsl,imx51-esdhc", },
> { .compatible = "fsl,imx53-esdhc", },
> { .compatible = "fsl,imx6ul-usdhc", },
> { .compatible = "fsl,imx6sx-usdhc", },
>
[PATCH] board: sl28: add DSA support for variant 2
Now that u-boot gained DSA support, and it is already enabled for the
kontron_sl28 board, add the last missing piece and enable the
corresponding devices it in the device tree.
Signed-off-by: Michael Walle
---
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 1ea1265bcf..39280cd1c7 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -15,6 +15,12 @@
/ {
model = "Kontron SMARC-sAL28 (TSN-on-module)";
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
+
+ aliases {
+ eth0 = &mscc_felix_port0;
+ eth1 = &mscc_felix_port1;
+ eth2 = &enetc2;
+ };
};
&enetc0 {
@@ -22,4 +28,44 @@
/delete-property/ phy-handle;
};
+&enetc2 {
+ status = "okay";
+};
+
+&mscc_felix {
+ status = "okay";
+};
+
+&mscc_felix_port0 {
+ label = "gbe0";
+ phy-handle = <&phy0>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+&mscc_felix_port1 {
+ label = "gbe1";
+ phy-handle = <&phy1>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
+
/delete-node/ &phy0;
+&mdio0 {
+ phy0: ethernet-phy@5 {
+ reg = <0x5>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+
+ phy1: ethernet-phy@4 {
+ reg = <0x4>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+};
--
2.20.1
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 11:15:06PM +0100, Michael Walle wrote: > Am 2021-02-16 22:58, schrieb Michael Walle: > > I just tried it again on my board and there seems still to be something > > broken :( I just don't have time right now. Would it be OK, to delay > > this until tomorrow? > > Please disregard this nonsense. Its all working. Don't worry. I've done and said so many stupid things in the past week I couldn't even keep track, and if I didn't feel bad for them, neither should you :D I have the follow-up patches for the sandbox prepared, is it okay if I send them tonight? They can marinate for as long as necessary.
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
Am 2021-02-16 22:58, schrieb Michael Walle: I just tried it again on my board and there seems still to be something broken :( I just don't have time right now. Would it be OK, to delay this until tomorrow? Please disregard this nonsense. Its all working. -michael
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
Am 2021-02-16 22:38, schrieb Tom Rini: On Tue, Feb 16, 2021 at 10:33:37PM +0100, Michael Walle wrote: Am 2021-02-16 22:21, schrieb Vladimir Oltean: > On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: > > On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > > > Hi Tom, > > > > > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > > > This test does not pass for me. This can be seen at: > > > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > > > > > Note that I'm still reviewing the rest of the series right now. > > > > > > You're right, thanks for letting me know. > > > I've fixed this in my tree [ by adding two more patches :-/ ], let me > > > know if you have any other feedback, otherwise I'm going to resend soon. > > > > I'm about to push the rest of the series, so you can rebase on master > > shortly, thanks! Or should I hold off as this exposed problems in the > > rest of your series? > > Sorry, I missed your reply earlier. I just sent out a new version which > should be sandbox-clean and which also makes the fixed PHY driver > compatible with live OF, since that's what the problem was, essentially. If this series is merged, I'd just send a follow up for the kontron sl28 board device tree, which also uses DSA. Originally, this it wasn't possible to include the patch in this series, because there was still the base device tree for this board variant pending in u-boot. So if possible, I'd welcome it if it can be merged after this series. OK, so I guess there's a small amount of follow-up to finish enabling it as I see, today with v4: kontron_sl28 : all +9467 bss +2560 data +568 rodata +675 spl/u-boot-spl:all +18 spl/u-boot-spl:rodata +18 text +5664 The support was already enabled, but the device tree for this partitcular variant was still missing when this patchset was posted. Therefore, it couldn't be enabled. commit b463010be067ba4b8ef9b7b80919f592a0f83bfb Author: Michael Walle Date: Fri Jan 8 00:08:58 2021 +0100 board: sl28: add network variant 2 support Although this variant has two external network ports, they are not (yet) supported by the bootloader because they are connected via an internal network switch. Otherwise its the same as the other variants. Signed-off-by: Michael Walle Reviewed-by: Priyanka Jain So the only thing which is missing is device tree fragment. when building and it's on just a few layerscape platforms so I assumed it was enabling everything. And, I'm inclined to go with reposting just a follow-up that fixes / enables sandbox and livetree as I would like to both: - Not delay the whole thing further - Not merge other changes immediately after they're posted[*] I just tried it again on my board and there seems still to be something broken :( I just don't have time right now. Would it be OK, to delay this until tomorrow? -michael
Re: [PATCH v1 11/11] usb: kbd: destroy device after console is stopped
On Thu, Feb 11, 2021 at 05:09:44PM +0200, Andy Shevchenko wrote:
> In case of IOMUX enabled it assumes that console devices in the list
> are available to get them stopped properly via ->stop() callback.
> However, the USB keyboard driver violates this assumption and tries
> to play tricks so the device get destroyed while being listed as
> an active console.
>
> Swap the order of device deregistration and IOMUX update along with
> converting to use iomux_replace_device() jelper to avoid the use-after-free.
>
> Fixes: 3cbcb2892809 ("usb: Fix usb_kbd_deregister when console-muxing is
> used")
> Fixes: 8a8348703081 ("dm: usb: Add a remove() method for USB keyboards")
> Reported-by: Nicolas Saenz Julienne
> Signed-off-by: Andy Shevchenko
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1 10/11] IOMUX: Introduce iomux_replace_device()
On Thu, Feb 11, 2021 at 05:09:43PM +0200, Andy Shevchenko wrote: > Some console devices may appear or disappear at run time. In order to > support such a hotplug mechanism introduce a new iomux_replace_device() > helper to update the list of devices without altering environment. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 08/11] IOMUX: Split out iomux_match_device() helper
On Thu, Feb 11, 2021 at 05:09:41PM +0200, Andy Shevchenko wrote: > Deduplicate the code used in a few places by splitting out a common helper. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 05/11] console: Set console device counter in console_devices_set()
On Thu, Feb 11, 2021 at 05:09:38PM +0200, Andy Shevchenko wrote:
> console_devices_set() missed the console device counter to be set correctly.
>
> Fixes: 45375adc9799 ("console: add function console_devices_set")
> Cc: Patrick Delaunay
> Signed-off-by: Andy Shevchenko
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1 09/11] IOMUX: Split out for_each_console_dev() helper macro
On Thu, Feb 11, 2021 at 05:09:42PM +0200, Andy Shevchenko wrote: > It is not only less lines of code, but also better readability > when new macro is being in use. Introduce for_each_console_dev() > helper macro and convert current users to it. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 07/11] IOMUX: Switch to use stdio_file_to_flags()
On Thu, Feb 11, 2021 at 05:09:40PM +0200, Andy Shevchenko wrote: > Deduplicate code by replacing with stdio_file_to_flags() helper. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 06/11] console: Set file and devices at one go
On Thu, Feb 11, 2021 at 05:09:39PM +0200, Andy Shevchenko wrote: > Logical continuation of the change that brought console_devices_set() is > to unify console_setfile() with it and replace in the callers. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 04/11] console: Switch to use stdio_file_to_flags()
On Thu, Feb 11, 2021 at 05:09:37PM +0200, Andy Shevchenko wrote: > Deduplicate code by replacing with stdio_file_to_flags() helper. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 02/11] stdio: Split out nulldev_register() and move it under #if
On Thu, Feb 11, 2021 at 05:09:35PM +0200, Andy Shevchenko wrote: > It's possible that NULLDEV can be disabled while it makes leftovers, > move entire device under #if. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 03/11] stdio: Introduce a new helper stdio_file_to_flags()
On Thu, Feb 11, 2021 at 05:09:36PM +0200, Andy Shevchenko wrote: > Let's deduplicate existing copies by splitting off to a new helper. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 01/11] stdio: Get rid of dead code, i.e. stdio_deregister()
On Thu, Feb 11, 2021 at 05:09:34PM +0200, Andy Shevchenko wrote: > Nobody is using stdio_deregister(), remove for good. > > Note, even its parameters are not consistent with stdio_register(). > So, if anyone want to introduce this again, better with some consistency. > > Signed-off-by: Andy Shevchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 4/4] test: dm: tee: extend with RPC test
On Mon, Jan 25, 2021 at 02:28:43PM +0200, Igor Opaniuk wrote: > From: Igor Opaniuk > > Extend existing DM tee tests adding test coverage for reverse RPC calls. > Currently this commit only adds tests for I2C requests from TEE driver > to TEE supplicant, for instance reading/writing data to emulated i2c > eeprom defines in standard sandbox test device tree > (arch/sandbox/dts/test.dtb): > > => i2c bus > Bus 0:i2c@0 (active 0) >2c: eeprom@2c, offset len 1, flags 0 >... > > Running TEE tests: > => ut dm tee > Test: dm_test_tee: tee.c > Test: dm_test_tee: tee.c (flat tree) > Failures: 0 > > Signed-off-by: Igor Opaniuk > Reviewed-by: Simon Glass > Acked-by: Etienne Carriere Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 3/4] drivers: tee: sandbox: add rpc test ta emulation
On Mon, Jan 25, 2021 at 02:28:42PM +0200, Igor Opaniuk wrote: > From: Igor Opaniuk > > This adds support for RPC test trusted application emulation, which > permits to test reverse RPC calls to TEE supplicant. Currently it covers > requests to the I2C bus from TEE. > > Signed-off-by: Igor Opaniuk > Reviewed-by: Simon Glass > Reviewed-by: Jens Wiklander > Acked-by: Etienne Carriere Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 2/4] test: py: add pygit2 and pyelftools to requirements.txt
On Mon, Jan 25, 2021 at 02:28:41PM +0200, Igor Opaniuk wrote: > From: Igor Opaniuk > > Add pygit2 and pyelftools to the list of packages for virtualenv > needed to run all sets of pytests.This fixes warnings like: > > binman.elf_test.TestElf.testDecodeElf (subunit.RemotedTestCase): > Python elftools not available > > Signed-off-by: Igor Opaniuk > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 1/4] drivers: tee: i2c trampoline driver
On Mon, Jan 25, 2021 at 02:28:40PM +0200, Igor Opaniuk wrote:
> From: Jorge Ramirez-Ortiz
>
> This commit gives the secure world access to the I2C bus so it can
> communicate with I2C slaves (typically those would be secure elements
> like the NXP SE050).
>
> A similar service implementation has been merged in linux:
> c05210ab ("drivers: optee: allow op-tee to access devices on the i2c
> bus")
>
> Signed-off-by: Jorge Ramirez-Ortiz
> Reviewed-by: Simon Glass
> Reviewed-by: Etienne Carriere
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 7/7] configs: ls1028a: Enable the Ethernet switch driver in defconfig
On Mon, Jan 25, 2021 at 02:23:57PM +0200, Vladimir Oltean wrote: > From: Alex Marginean > > The switch driver for LS1028A Ethernet switch is now compiled in for > the NXP LS1028A reference design boards and for the Kontron SMARC-sAL28. > > Signed-off-by: Alex Marginean > Signed-off-by: Claudiu Manoil > Signed-off-by: Vladimir Oltean > Acked-by: Michael Walle Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 6/7] arm: dts: ls1028a: Add Ethernet switch node and dependencies
On Mon, Jan 25, 2021 at 02:23:56PM +0200, Vladimir Oltean wrote: > From: Alex Marginean > > The definition follows the DSA binding in kernel and describes the switch, > its ports and PHYs. The switch node has the same structure as in Linux > and this patch enables it (and relevant ports) for the LS1028A RDB board. > > ENETC PF6 is the 2nd Eth controller linked to the switch on LS1028A, it is > not used in U-Boot and was disabled. Ethernet port aliases were also > added to better manage the multitude of ports available now. > > Signed-off-by: Alex Marginean > Signed-off-by: Claudiu Manoil > Signed-off-by: Vladimir Oltean > Reviewed-by: Michael Walle Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 5/7] drivers: net: Add Felix DSA switch driver
On Mon, Jan 25, 2021 at 02:23:55PM +0200, Vladimir Oltean wrote: > From: Alex Marginean > > This driver is used for the Ethernet switch integrated into LS1028A NXP. > Felix on LS1028A has 4 front panel ports and two internal ports, I/O > to/from the switch is done through an ENETC Ethernet interface. > The 4 front panel ports are available as Ethernet interfaces and can be > used with the typical network commands like tftp. > > Signed-off-by: Alex Marginean > Signed-off-by: Claudiu Manoil > Signed-off-by: Vladimir Oltean Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/7] net: phy: introduce fixed_phy_create for DSA CPU ports
On Mon, Jan 25, 2021 at 02:23:52PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The DSA (Distributed Switch Architecture) implementation has made a
> design decision when it got introduced to the Linux kernel in 2008.
> That was to hide away from the user the CPU-facing Ethernet MAC, since
> it does not make sense to register it as a struct net_device (UCLASS_ETH
> udevice for U-Boot), because that would never be beneficial for a user:
> they would not be able to use it for traffic, since conceptually, a
> packet delivered to the CPU port should loop back into the system.
>
> Nonetheless, DSA has had numerous growing pains due to the lack of a
> struct net_device for the CPU port, but so far it has overcome them.
> It is unlikely at this stage of maturity that this aspect of it will
> change.
>
> We would like U-Boot to present the same information as Linux, to be at
> parity in terms of number of interfaces, so that ethNaddr environment
> variables could directly be associated between U-Boot and Linux.
> Therefore, we would implicitly like U-Boot to hide the CPU port from the
> user as well.
>
> But the paradox is that DSA still needs a struct phy_device to inform
> the driver of the parameters of the link that it should configure the
> CPU port to. The problem is that the phy_device is typically returned
> via a call to phy_connect, which needs an udevice to attach the PHY to,
> and to search its ofnode for the 'fixed-link' property. But we don't
> have an udevice to present for the CPU port.
>
> Since 99% of DSA setups are MAC-to-MAC connections between the switch
> and the host Ethernet controller, the struct phy_device is going to be a
> fixed PHY. This simplifies things quite a bit. In U-Boot, a fixed PHY
> does not need an MDIO bus, and does not need an attached dev either.
> Basically, the phy_connect call doesn't do any connection, it just
> creates the fixed PHY.
>
> The proposal of this patch is to introduce a new fixed_phy_create
> function which will take a single argument: the ofnode that holds this:
>
> port@4 {
> reg = <4>;
> phy-mode = "internal";
>
> fixed-link {
> speed = <2500>;
> full-duplex;
> };
> };
>
> and probe a fixed PHY driver using the information from this ofnode.
> DSA will probably be the only user of this function.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Claudiu Manoil
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 3/7] net: Introduce DSA class for Ethernet switches
On Mon, Jan 25, 2021 at 02:23:53PM +0200, Vladimir Oltean wrote: > From: Claudiu Manoil > > DSA stands for Distributed Switch Architecture and it covers switches that > are connected to the CPU through an Ethernet link and generally use frame > tags to pass information about the source/destination ports to/from CPU. > Front panel ports are presented as regular ethernet devices in U-Boot and > they are expected to support the typical networking commands. > DSA switches may be cascaded, DSA class code does not currently support > this. > > Signed-off-by: Alex Marginean > Signed-off-by: Claudiu Manoil > Reviewed-by: Simon Glass > Signed-off-by: Vladimir Oltean Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/7] net: phy: fixed: support speeds of 2500 and 10000
On Mon, Jan 25, 2021 at 02:23:51PM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean > > Unlike the Linux fixed PHY driver, the one in U-Boot does not attempt to > emulate the clause 22 register set of a gigabit copper PHY driver > through the swphy framework. Therefore, the limitation of being unable > to support speeds higher than gigabit in fixed-link does not apply to > the U-Boot fixed PHY driver. This makes the fixed-link U-Boot > implementation more similar to the one from phylink, which can work with > any valid link speed. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Claudiu Manoil Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 11:53:46PM +0200, Vladimir Oltean wrote: > On Tue, Feb 16, 2021 at 04:38:06PM -0500, Tom Rini wrote: > > On Tue, Feb 16, 2021 at 10:33:37PM +0100, Michael Walle wrote: > > > Am 2021-02-16 22:21, schrieb Vladimir Oltean: > > > > On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: > > > > > On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > > > > > > This test does not pass for me. This can be seen at: > > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > > > > > > > > > > > Note that I'm still reviewing the rest of the series right now. > > > > > > > > > > > > You're right, thanks for letting me know. > > > > > > I've fixed this in my tree [ by adding two more patches :-/ ], let > > > > > > me > > > > > > know if you have any other feedback, otherwise I'm going to resend > > > > > > soon. > > > > > > > > > > I'm about to push the rest of the series, so you can rebase on master > > > > > shortly, thanks! Or should I hold off as this exposed problems in the > > > > > rest of your series? > > > > > > > > Sorry, I missed your reply earlier. I just sent out a new version which > > > > should be sandbox-clean and which also makes the fixed PHY driver > > > > compatible with live OF, since that's what the problem was, essentially. > > > > > > If this series is merged, I'd just send a follow up for the kontron sl28 > > > board device tree, which also uses DSA. Originally, this it wasn't > > > possible to include the patch in this series, because there was still > > > the base device tree for this board variant pending in u-boot. > > > > > > So if possible, I'd welcome it if it can be merged after this series. > > > > OK, so I guess there's a small amount of follow-up to finish enabling it > > as I see, today with v4: > > kontron_sl28 : all +9467 bss +2560 data +568 rodata +675 > > spl/u-boot-spl:all +18 spl/u-boot-spl:rodata +18 text +5664 > > > > when building and it's on just a few layerscape platforms so I assumed > > it was enabling everything. > > > > And, I'm inclined to go with reposting just a follow-up that fixes / > > enables sandbox and livetree as I would like to both: > > - Not delay the whole thing further > > - Not merge other changes immediately after they're posted[*] > > > > -- > > Tom > > > > [*]: Yes, I did this literally yesterday, but for a security series I > > had seen prior, so a special case I don't like either, but... anyhow. > > Tom, if you want to merge v4 sans the sandbox support instead of v5, I'm > okay with that. I can easily send out the v5 changes in a follow-up series. Thanks! Pushing stuff now.. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 04:38:06PM -0500, Tom Rini wrote: > On Tue, Feb 16, 2021 at 10:33:37PM +0100, Michael Walle wrote: > > Am 2021-02-16 22:21, schrieb Vladimir Oltean: > > > On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: > > > > On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > > > > > Hi Tom, > > > > > > > > > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > > > > > This test does not pass for me. This can be seen at: > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > > > > > > > > > Note that I'm still reviewing the rest of the series right now. > > > > > > > > > > You're right, thanks for letting me know. > > > > > I've fixed this in my tree [ by adding two more patches :-/ ], let me > > > > > know if you have any other feedback, otherwise I'm going to resend > > > > > soon. > > > > > > > > I'm about to push the rest of the series, so you can rebase on master > > > > shortly, thanks! Or should I hold off as this exposed problems in the > > > > rest of your series? > > > > > > Sorry, I missed your reply earlier. I just sent out a new version which > > > should be sandbox-clean and which also makes the fixed PHY driver > > > compatible with live OF, since that's what the problem was, essentially. > > > > If this series is merged, I'd just send a follow up for the kontron sl28 > > board device tree, which also uses DSA. Originally, this it wasn't > > possible to include the patch in this series, because there was still > > the base device tree for this board variant pending in u-boot. > > > > So if possible, I'd welcome it if it can be merged after this series. > > OK, so I guess there's a small amount of follow-up to finish enabling it > as I see, today with v4: > kontron_sl28 : all +9467 bss +2560 data +568 rodata +675 spl/u-boot-spl:all > +18 spl/u-boot-spl:rodata +18 text +5664 > > when building and it's on just a few layerscape platforms so I assumed > it was enabling everything. > > And, I'm inclined to go with reposting just a follow-up that fixes / > enables sandbox and livetree as I would like to both: > - Not delay the whole thing further > - Not merge other changes immediately after they're posted[*] > > -- > Tom > > [*]: Yes, I did this literally yesterday, but for a security series I > had seen prior, so a special case I don't like either, but... anyhow. Tom, if you want to merge v4 sans the sandbox support instead of v5, I'm okay with that. I can easily send out the v5 changes in a follow-up series.
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 10:33:37PM +0100, Michael Walle wrote: > Am 2021-02-16 22:21, schrieb Vladimir Oltean: > > On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: > > > On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > > > > Hi Tom, > > > > > > > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > > > > This test does not pass for me. This can be seen at: > > > > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > > > > > > > Note that I'm still reviewing the rest of the series right now. > > > > > > > > You're right, thanks for letting me know. > > > > I've fixed this in my tree [ by adding two more patches :-/ ], let me > > > > know if you have any other feedback, otherwise I'm going to resend soon. > > > > > > I'm about to push the rest of the series, so you can rebase on master > > > shortly, thanks! Or should I hold off as this exposed problems in the > > > rest of your series? > > > > Sorry, I missed your reply earlier. I just sent out a new version which > > should be sandbox-clean and which also makes the fixed PHY driver > > compatible with live OF, since that's what the problem was, essentially. > > If this series is merged, I'd just send a follow up for the kontron sl28 > board device tree, which also uses DSA. Originally, this it wasn't > possible to include the patch in this series, because there was still > the base device tree for this board variant pending in u-boot. > > So if possible, I'd welcome it if it can be merged after this series. OK, so I guess there's a small amount of follow-up to finish enabling it as I see, today with v4: kontron_sl28 : all +9467 bss +2560 data +568 rodata +675 spl/u-boot-spl:all +18 spl/u-boot-spl:rodata +18 text +5664 when building and it's on just a few layerscape platforms so I assumed it was enabling everything. And, I'm inclined to go with reposting just a follow-up that fixes / enables sandbox and livetree as I would like to both: - Not delay the whole thing further - Not merge other changes immediately after they're posted[*] -- Tom [*]: Yes, I did this literally yesterday, but for a security series I had seen prior, so a special case I don't like either, but... anyhow. signature.asc Description: PGP signature
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
Am 2021-02-16 22:21, schrieb Vladimir Oltean: On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > Hi Tom, > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > This test does not pass for me. This can be seen at: > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > Note that I'm still reviewing the rest of the series right now. > > You're right, thanks for letting me know. > I've fixed this in my tree [ by adding two more patches :-/ ], let me > know if you have any other feedback, otherwise I'm going to resend soon. I'm about to push the rest of the series, so you can rebase on master shortly, thanks! Or should I hold off as this exposed problems in the rest of your series? Sorry, I missed your reply earlier. I just sent out a new version which should be sandbox-clean and which also makes the fixed PHY driver compatible with live OF, since that's what the problem was, essentially. If this series is merged, I'd just send a follow up for the kontron sl28 board device tree, which also uses DSA. Originally, this it wasn't possible to include the patch in this series, because there was still the base device tree for this board variant pending in u-boot. So if possible, I'd welcome it if it can be merged after this series. -michael
Re: [PATCH v5 4/9] net: mdio: teach dm_eth_connect_phy_handle to connect to fixed PHY
On Tue, Feb 16, 2021 at 11:19:31PM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean > > dm_eth_connect_phy_handle has all the info it needs in order to hide > away from the UCLASS_ETH caller the fact that it is attached to a > fixed-link PHY. So only attempt to search for a phy-handle if we've > exhausted the fixed-link option first. > > Signed-off-by: Vladimir Oltean > --- Ouch, the function name in the commit message is wrong, I meant dm_eth_phy_connect but I pasted the wrong one. The patch is correct though. Should have not hurried.
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 04:13:41PM -0500, Tom Rini wrote: > On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > > Hi Tom, > > > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > > This test does not pass for me. This can be seen at: > > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > > > Note that I'm still reviewing the rest of the series right now. > > > > You're right, thanks for letting me know. > > I've fixed this in my tree [ by adding two more patches :-/ ], let me > > know if you have any other feedback, otherwise I'm going to resend soon. > > I'm about to push the rest of the series, so you can rebase on master > shortly, thanks! Or should I hold off as this exposed problems in the > rest of your series? Sorry, I missed your reply earlier. I just sent out a new version which should be sandbox-clean and which also makes the fixed PHY driver compatible with live OF, since that's what the problem was, essentially.
[PATCH v5 9/9] configs: ls1028a: enable the Ethernet switch driver
From: Alex Marginean The switch driver for LS1028A Ethernet switch is now compiled in for the NXP LS1028A reference design boards and for the Kontron SMARC-sAL28. Signed-off-by: Alex Marginean Signed-off-by: Claudiu Manoil Signed-off-by: Vladimir Oltean Acked-by: Michael Walle --- v5: none v4: enabled CONFIG_PHY_FIXED which is a new dependency of CONFIG_DM_DSA v3: enable the config options for the Kontron board too. v2: none configs/kontron_sl28_defconfig | 3 +++ configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 3 +++ configs/ls1028aqds_tfa_defconfig | 3 +++ configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 3 +++ configs/ls1028ardb_tfa_defconfig | 3 +++ 5 files changed, 15 insertions(+) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 1759d5e1b92e..d56709689b38 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -84,6 +84,9 @@ CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FSL_ENETC=y +CONFIG_PHY_FIXED=y +CONFIG_DM_DSA=y +CONFIG_MSCC_FELIX_SWITCH=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index eaf903f65427..93b13b472942 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -62,6 +62,9 @@ CONFIG_DM_MDIO_MUX=y CONFIG_E1000=y CONFIG_FSL_ENETC=y CONFIG_MDIO_MUX_I2CREG=y +CONFIG_PHY_FIXED=y +CONFIG_DM_DSA=y +CONFIG_MSCC_FELIX_SWITCH=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 248c64048296..c915069f283a 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -68,6 +68,9 @@ CONFIG_DM_MDIO_MUX=y CONFIG_E1000=y CONFIG_FSL_ENETC=y CONFIG_MDIO_MUX_I2CREG=y +CONFIG_PHY_FIXED=y +CONFIG_DM_DSA=y +CONFIG_MSCC_FELIX_SWITCH=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index 240e4204ae57..45d9f40043d9 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -59,6 +59,9 @@ CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FSL_ENETC=y +CONFIG_PHY_FIXED=y +CONFIG_DM_DSA=y +CONFIG_MSCC_FELIX_SWITCH=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 493fe7c377a1..cff68a3cc823 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -65,6 +65,9 @@ CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FSL_ENETC=y +CONFIG_PHY_FIXED=y +CONFIG_DM_DSA=y +CONFIG_MSCC_FELIX_SWITCH=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_DM_PCI=y -- 2.25.1
[PATCH v5 6/9] sandbox: add a DSA sandbox driver and unit test
From: Claudiu Manoil
The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a very
simple tag to identify the ports.
The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox
driver. The 'dsa-test-eth' is not intended for testing the eth class
code however, but it is used to emulate traffic through the 'lan0' and
'lan1' front pannel switch ports. To achieve this the dsa sandbox driver
registers a tx handler for the 'dsa-test-eth' device. The switch ports,
labeled as 'lan0' and 'lan1', are also registered as eth devices by the
dsa class code this time. So pinging through these switch ports is as
easy as:
=> setenv ethact lan0
=> ping 1.2.3.5
Unit tests for the dsa class code were also added. The 'dsa_probe'
test exercises most API functions from dsa.h. The 'dsa' unit test
simply exercises ARP/ICMP traffic through the two switch ports,
including tag injection and extraction, with the help of the dsa
sandbox driver.
I took care to minimize the impact on the existing eth unit tests,
though some adjustments needed to be made with the addition of
extra eth interfaces used by the dsa unit tests. The additional eth
interfaces also require MAC addresses, these have been added to the
sandbox default environment.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Reviewed-by: Simon Glass
Signed-off-by: Vladimir Oltean
---
v5: make SANDBOX imply PHY_FIXED, a DSA dependency.
v4: none.
v3:
- deleted the unit tests associated with the infrastructure for
dsa_foreach_port, since that function no longer exists.
- added fixed-link and phy-mode to lan0 from the sandbox device tree.
We don't support ports that don't have a PHY and are not fixed-link
either.
v2: none
arch/Kconfig | 2 +
arch/sandbox/dts/test.dts | 48 ++
drivers/net/Kconfig | 9 ++
drivers/net/Makefile | 1 +
drivers/net/dsa_sandbox.c | 179 ++
include/configs/sandbox.h | 2 +
test/dm/Makefile | 1 +
test/dm/dsa.c | 82 +
test/dm/eth.c | 10 +--
9 files changed, 329 insertions(+), 5 deletions(-)
create mode 100644 drivers/net/dsa_sandbox.c
create mode 100644 test/dm/dsa.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 6c8167826cf8..f114a025fa5b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -161,6 +161,8 @@ config SANDBOX
imply CMD_CLONE
imply SILENT_CONSOLE
imply BOOTARGS_SUBST
+ imply PHY_FIXED
+ imply DM_DSA
config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e95f4631bf2f..d4ee6ddbbe4c 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -14,7 +14,9 @@
aliases {
console = &uart0;
eth0 = "/eth@10002000";
+ eth2 = &swp_0;
eth3 = ð_3;
+ eth4 = &dsa_eth0;
eth5 = ð_5;
gpio1 = &gpio_a;
gpio2 = &gpio_b;
@@ -432,6 +434,52 @@
fake-host-hwaddr = [00 00 66 44 22 22];
};
+ dsa_eth0: dsa-test-eth {
+ compatible = "sandbox,eth";
+ reg = <0x10006000 0x1000>;
+ fake-host-hwaddr = [00 00 66 44 22 66];
+ };
+
+ dsa-test {
+ compatible = "sandbox,dsa";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ swp_0: port@0 {
+ reg = <0>;
+ label = "lan0";
+ phy-mode = "rgmii-rxid";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ swp_1: port@1 {
+ reg = <1>;
+ label = "lan1";
+ phy-mode = "rgmii-txid";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ ethernet = <&dsa_eth0>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
firmware {
sandbox_firmware: sandbox-firmware {
compatible = "sandbox,firmware";
diff --git a/drivers/net/Kconfig b/dr
[PATCH v5 7/9] drivers: net: add Felix DSA switch driver
From: Alex Marginean
This driver is used for the Ethernet switch integrated into NXP LS1028A.
Felix on LS1028A has 4 front panel ports and two internal ports, I/O
to/from the switch is done through an ENETC Ethernet interface.
The 4 front panel ports are available as Ethernet interfaces and can be
used with the typical network commands like tftp.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Signed-off-by: Vladimir Oltean
---
v5: none
v4: none
v3: dsa_foreach_port() does not work when called from the probe function
of the DSA udevice, because the eth port udevices are _not_ yet probed
at that point. To fix this, we are now initializing all ports from
the .port_enable() callback of each eth udevice.
v2: none
drivers/net/fsl_enetc.h | 5 +
drivers/net/mscc_eswitch/Kconfig| 8 +
drivers/net/mscc_eswitch/Makefile | 1 +
drivers/net/mscc_eswitch/felix_switch.c | 414
4 files changed, 428 insertions(+)
create mode 100644 drivers/net/mscc_eswitch/felix_switch.c
diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
index 37e7e858435b..110c1d78fbc6 100644
--- a/drivers/net/fsl_enetc.h
+++ b/drivers/net/fsl_enetc.h
@@ -201,6 +201,11 @@ struct enetc_priv {
/* PCS replicator block for USXGMII */
#define ENETC_PCS_DEVAD_REPL 0x1f
+#define ENETC_PCS_REPL_LINK_TIMER_10x12
+#define ENETC_PCS_REPL_LINK_TIMER_1_DEF 0x0003
+#define ENETC_PCS_REPL_LINK_TIMER_20x13
+#define ENETC_PCS_REPL_LINK_TIMER_2_DEF 0x06a0
+
/* ENETC external MDIO registers */
#define ENETC_MDIO_BASE0x1c00
#define ENETC_MDIO_CFG 0x00
diff --git a/drivers/net/mscc_eswitch/Kconfig b/drivers/net/mscc_eswitch/Kconfig
index 80dd22f98b7f..ccf7822dbe7a 100644
--- a/drivers/net/mscc_eswitch/Kconfig
+++ b/drivers/net/mscc_eswitch/Kconfig
@@ -36,3 +36,11 @@ config MSCC_SERVAL_SWITCH
select PHYLIB
help
This driver supports the Serval network switch device.
+
+config MSCC_FELIX_SWITCH
+ bool "Felix switch driver"
+ depends on DM_DSA && DM_PCI
+ select FSL_ENETC
+ help
+ This driver supports the Ethernet switch integrated in the
+ NXP LS1028A SoC.
diff --git a/drivers/net/mscc_eswitch/Makefile
b/drivers/net/mscc_eswitch/Makefile
index d583fe9fc4bb..22342ed11417 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
mscc_mac_table.o m
obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o mscc_miim.o
obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o mscc_miim.o
obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
mscc_mac_table.o mscc_miim.o
+obj-$(CONFIG_MSCC_FELIX_SWITCH) += felix_switch.o
diff --git a/drivers/net/mscc_eswitch/felix_switch.c
b/drivers/net/mscc_eswitch/felix_switch.c
new file mode 100644
index ..f20e84e0f10c
--- /dev/null
+++ b/drivers/net/mscc_eswitch/felix_switch.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Felix (VSC9959) Ethernet switch driver
+ * Copyright 2018-2021 NXP Semiconductors
+ */
+
+/*
+ * This driver is used for the Ethernet switch integrated into NXP LS1028A.
+ * Felix switch is derived from Microsemi Ocelot but there are several NXP
+ * adaptations that makes the two U-Boot drivers largely incompatible.
+ *
+ * Felix on LS1028A has 4 front panel ports and two internal ports, connected
+ * to ENETC interfaces. We're using one of the ENETC interfaces to push
traffic
+ * into the switch. Injection/extraction headers are used to identify
+ * egress/ingress ports in the switch for Tx/Rx.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* defines especially around PCS are reused from enetc */
+#include "../fsl_enetc.h"
+
+#define PCI_DEVICE_ID_FELIX_ETHSW 0xEEF0
+
+/* Felix has in fact 6 ports, but we don't use the last internal one */
+#define FELIX_PORT_COUNT 5
+/* Front panel port mask */
+#define FELIX_FP_PORT_MASK 0xf
+
+/* Register map for BAR4 */
+#define FELIX_SYS 0x01
+#define FELIX_ES0 0x04
+#define FELIX_IS1 0x05
+#define FELIX_IS2 0x06
+#define FELIX_GMII(port) (0x10 + (port) * 0x1)
+#define FELIX_QSYS 0x20
+
+#define FELIX_SYS_SYSTEM (FELIX_SYS + 0x0E00)
+#define FELIX_SYS_SYSTEM_EN BIT(0)
+#define FELIX_SYS_RAM_CTRL (FELIX_SYS + 0x0F24)
+#define FELIX_SYS_RAM_CTRL_INIT BIT(1)
+#define FELIX_SYS_SYSTEM_PORT_MODE(a) (FELIX_SYS_SYSTEM + 0xC + (a) * 4)
+#define FELIX_SYS_SYSTEM_PORT_MODE_CPU0x001e
+
+#define FELIX_ES0_TCAM_CTRL(FELIX_ES0 + 0x03C0)
+#define FELIX_ES0_TCAM_CTRL_ENBIT(0)
+#define FELIX_IS
[PATCH v5 8/9] arm: dts: ls1028a: add Ethernet switch node and dependencies
From: Alex Marginean
The definition follows the DSA binding in kernel and describes the switch,
its ports and PHYs. The switch node has the same structure as in Linux
and this patch enables it (and relevant ports) for the LS1028A RDB board.
ENETC PF6 is the 2nd Eth controller linked to the switch on LS1028A, it is
not used in U-Boot and was disabled. Ethernet port aliases were also
added to better manage the multitude of ports available now.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Signed-off-by: Vladimir Oltean
Reviewed-by: Michael Walle
---
v5: none.
v4: none.
v3: Added a comment denoting the PHY model present on the RDB.
v2: Switch node structure defined in dtsi now consistent with the Linux
switch node definition. Moved aliases from dtsi to the RDB DTS to
minimize impact on other boards (and for improved flexibility).
arch/arm/dts/fsl-ls1028a-rdb.dts | 64
arch/arm/dts/fsl-ls1028a.dtsi| 55 ++-
2 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 85b4815b2ed7..3432fca35269 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -15,6 +15,12 @@
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
aliases {
spi0 = &fspi;
+ eth0 = &enetc0;
+ eth1 = &enetc2;
+ eth2 = &mscc_felix_port0;
+ eth3 = &mscc_felix_port1;
+ eth4 = &mscc_felix_port2;
+ eth5 = &mscc_felix_port3;
};
};
@@ -131,9 +137,67 @@
phy-handle = <&rdb_phy0>;
};
+&enetc2 {
+ status = "okay";
+};
+
+&mscc_felix {
+ status = "okay";
+};
+
+&mscc_felix_port0 {
+ label = "swp0";
+ phy-handle = <&sw_phy0>;
+ phy-mode = "qsgmii";
+ status = "okay";
+};
+
+&mscc_felix_port1 {
+ label = "swp1";
+ phy-handle = <&sw_phy1>;
+ phy-mode = "qsgmii";
+ status = "okay";
+};
+
+&mscc_felix_port2 {
+ label = "swp2";
+ phy-handle = <&sw_phy2>;
+ phy-mode = "qsgmii";
+ status = "okay";
+};
+
+&mscc_felix_port3 {
+ label = "swp3";
+ phy-handle = <&sw_phy3>;
+ phy-mode = "qsgmii";
+ status = "okay";
+};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
+
&mdio0 {
status = "okay";
rdb_phy0: phy@2 {
reg = <2>;
};
+
+ /* VSC8514 QSGMII PHY */
+ sw_phy0: phy@10 {
+ reg = <0x10>;
+ };
+
+ sw_phy1: phy@11 {
+ reg = <0x11>;
+ };
+
+ sw_phy2: phy@12 {
+ reg = <0x12>;
+ };
+
+ sw_phy3: phy@13 {
+ reg = <0x13>;
+ };
};
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 5171bf28c79e..22d107d959de 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -151,9 +151,62 @@
reg = <0x000300 0 0 0 0>;
status = "disabled";
};
+
+ mscc_felix: pci@0,5 {
+ reg = <0x000500 0 0 0 0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mscc_felix_port0: port@0 {
+ reg = <0>;
+ status = "disabled";
+ };
+
+ mscc_felix_port1: port@1 {
+ reg = <1>;
+ status = "disabled";
+ };
+
+ mscc_felix_port2: port@2 {
+ reg = <2>;
+ status = "disabled";
+ };
+
+ mscc_felix_port3: port@3 {
+ reg = <3>;
+ status = "disabled";
+ };
+
+ mscc_felix_port4: port@4 {
+ reg = <4>;
+ phy-mode = "internal";
+ status = "disabled";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ };
+ };
+
+ mscc_felix_port5: port@5 {
+ reg = <5>;
+ phy-mode = "internal";
+ status = "disabled";
+
+
[PATCH v5 5/9] net: introduce DSA class for Ethernet switches
From: Claudiu Manoil
DSA stands for Distributed Switch Architecture (a presentation here:
https://netdevconf.info/2.1/papers/distributed-switch-architecture.pdf)
and it covers switches that are connected to the host CPU through an
Ethernet (typically MAC-to-MAC) link. Generally, DSA switches use frame
tags to pass information about the source/destination ports to/from CPU.
This way, the CPU has full individual awareness of the front-facing
switch ports.
Front panel ports are presented as regular ethernet devices in U-Boot
and they are expected to support the typical networking commands.
The use case for U-Boot is to use DSA switches as port multipliers, for
things such as TFTP over a specific switch port. The switching ability
is deemed to be too dangerous to be enabled from the bootloader without
network protection features such as Spanning Tree Protocol, and is
therefore not supported at all, in lack of a good reason.
Some DSA switches may be cascaded in a multi-chip setup; the DSA class
code does not currently support this.
Signed-off-by: Alex Marginean
Signed-off-by: Claudiu Manoil
Reviewed-by: Simon Glass
Signed-off-by: Vladimir Oltean
---
v5: Adjusted commit message.
v4: Implemented the TODO for having a phy_device on the CPU port.
v3:
- Removed all infrastructure associated with dsa_foreach_port, which
is no longer needed.
- Only inherit the DSA master's MAC address if the environment does not
already have a specific MAC address that should be used for the DSA
port.
- Be compatible with the new "ethernet-ports" container name which has
been introduced in the Linux kernel as commit 85e05d263ed2 ("net: dsa:
of: Allow ethernet-ports as encapsulating node") in v5.9.
v2: none
drivers/net/Kconfig| 15 ++
include/dm/uclass-id.h | 1 +
include/net.h | 6 +
include/net/dsa.h | 165 ++
net/Makefile | 1 +
net/dsa-uclass.c | 478 +
6 files changed, 666 insertions(+)
create mode 100644 include/net/dsa.h
create mode 100644 net/dsa-uclass.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 971a57224821..0e84c22b5075 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -37,6 +37,21 @@ config DM_MDIO_MUX
This is currently implemented in net/mdio-mux-uclass.c
Look in include/miiphy.h for details.
+config DM_DSA
+ bool "Enable Driver Model for DSA switches"
+ depends on DM_ETH && DM_MDIO
+ depends on PHY_FIXED
+ help
+ Enable driver model for DSA switches
+
+ Adds UCLASS_DSA class supporting switches that follow the Distributed
+ Switch Architecture (DSA). These switches rely on the presence of a
+ management switch port connected to an Ethernet controller capable of
+ receiving frames from the switch. This host Ethernet controller is
+ called the "master" Ethernet interface in DSA terminology.
+ This is currently implemented in net/dsa-uclass.c, refer to
+ include/net/dsa.h for API details.
+
config MDIO_SANDBOX
depends on DM_MDIO && SANDBOX
default y
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index ae4425d7a57a..d75de368c5a8 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -46,6 +46,7 @@ enum uclass_id {
UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
UCLASS_DSI_HOST,/* Display Serial Interface host */
UCLASS_DMA, /* Direct Memory Access */
+ UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture */
UCLASS_EFI, /* EFI managed devices */
UCLASS_ETH, /* Ethernet device */
UCLASS_ETH_PHY, /* Ethernet PHY device */
diff --git a/include/net.h b/include/net.h
index 13da69b7c145..b95d6a6f60eb 100644
--- a/include/net.h
+++ b/include/net.h
@@ -499,7 +499,13 @@ struct icmp_hdr {
* maximum packet size and multiple of 32 bytes = 1536
*/
#define PKTSIZE1522
+#ifndef CONFIG_DM_DSA
#define PKTSIZE_ALIGN 1536
+#else
+/* Maximum DSA tagging overhead (headroom and/or tailroom) */
+#define DSA_MAX_OVR256
+#define PKTSIZE_ALIGN (1536 + DSA_MAX_OVR)
+#endif
/*
* Maximum receive ring size; that is, the number of packets
diff --git a/include/net/dsa.h b/include/net/dsa.h
new file mode 100644
index ..0f31a908c9d1
--- /dev/null
+++ b/include/net/dsa.h
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019-2021 NXP Semiconductors
+ */
+
+#ifndef __DSA_H__
+#define __DSA_H__
+
+#include
+#include
+
+/**
+ * DSA stands for Distributed Switch Architecture and it is infrastructure
+ * intended to support drivers for Switches that rely on an intermediary
+ * Ethernet device for I/O. These switches may support cascading allowing
+ * them to be arranged as a tree.
+ * DSA is documented in detail in the Lin
[PATCH v5 3/9] net: phy: introduce fixed_phy_create for DSA CPU ports
From: Vladimir Oltean
The DSA (Distributed Switch Architecture) implementation has made a
design decision when it got introduced to the Linux kernel in 2008.
That was to hide away from the user the CPU-facing Ethernet MAC, since
it does not make sense to register it as a struct net_device (UCLASS_ETH
udevice for U-Boot), because that would never be beneficial for a user:
they would not be able to use it for traffic, since conceptually, a
packet delivered to the CPU port should loop back into the system.
Nonetheless, DSA has had numerous growing pains due to the lack of a
struct net_device for the CPU port, but so far it has overcome them.
It is unlikely at this stage of maturity that this aspect of it will
change.
We would like U-Boot to present the same information as Linux, to be at
parity in terms of number of interfaces, so that ethNaddr environment
variables could directly be associated between U-Boot and Linux.
Therefore, we would implicitly like U-Boot to hide the CPU port from the
user as well.
But the paradox is that DSA still needs a struct phy_device to inform
the driver of the parameters of the link that it should configure the
CPU port to. The problem is that the phy_device is typically returned
via a call to phy_connect, which needs an udevice to attach the PHY to,
and to search its ofnode for the 'fixed-link' property. But we don't
have an udevice to present for the CPU port.
Since 99% of DSA setups are MAC-to-MAC connections between the switch
and the host Ethernet controller, the struct phy_device is going to be a
fixed PHY. This simplifies things quite a bit. In U-Boot, a fixed PHY
does not need an MDIO bus, and does not need an attached dev either.
Basically, the phy_connect call doesn't do any connection, it just
creates the fixed PHY.
The proposal of this patch is to introduce a new fixed_phy_create
function which will take a single argument: the ofnode that holds this:
port@4 {
reg = <4>;
phy-mode = "internal";
fixed-link {
speed = <2500>;
full-duplex;
};
};
and probe a fixed PHY driver using the information from this ofnode.
DSA will probably be the only user of this function.
Signed-off-by: Vladimir Oltean
Reviewed-by: Claudiu Manoil
---
Changes in v5:
Use the new API for creating a fixed PHY (introduced in patch 1), which
is to put the ofnode in phydev->node instead of phydev->addr.
Changes in v4:
Patch is new.
drivers/net/phy/phy.c | 35 +++
include/phy.h | 21 +
2 files changed, 56 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index e88c93c4180d..a3b294054d18 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -977,6 +977,41 @@ static struct phy_device *phy_connect_gmii2rgmii(struct
mii_dev *bus,
#endif
#ifdef CONFIG_PHY_FIXED
+/**
+ * fixed_phy_create() - create an unconnected fixed-link pseudo-PHY device
+ * @node: OF node for the container of the fixed-link node
+ *
+ * Description: Creates a struct phy_device based on a fixed-link of_node
+ * description. Can be used without phy_connect by drivers which do not expose
+ * a UCLASS_ETH udevice.
+ */
+struct phy_device *fixed_phy_create(ofnode node)
+{
+ phy_interface_t interface = PHY_INTERFACE_MODE_NONE;
+ struct phy_device *phydev;
+ const char *if_str;
+ ofnode subnode;
+
+ if_str = ofnode_read_string(node, "phy-mode");
+ if (!if_str) {
+ if_str = ofnode_read_string(node, "phy-interface-type");
+ }
+ if (if_str) {
+ interface = phy_get_interface_by_name(if_str);
+ }
+
+ subnode = ofnode_find_subnode(node, "fixed-link");
+ if (!ofnode_valid(subnode)) {
+ return NULL;
+ }
+
+ phydev = phy_device_create(NULL, 0, PHY_FIXED_ID, false, interface);
+ if (phydev)
+ phydev->node = subnode;
+
+ return phydev;
+}
+
#ifdef CONFIG_DM_ETH
static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
struct udevice *dev,
diff --git a/include/phy.h b/include/phy.h
index 7750efd8bb5c..2754421ed4fb 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -402,6 +402,27 @@ int phy_reset(struct phy_device *phydev);
struct phy_device *phy_find_by_mask(struct mii_dev *bus, unsigned phy_mask,
phy_interface_t interface);
+#ifdef CONFIG_PHY_FIXED
+
+/**
+ * fixed_phy_create() - create an unconnected fixed-link pseudo-PHY device
+ * @node: OF node for the container of the fixed-link node
+ *
+ * Description: Creates a struct phy_device based on a fixed-link of_node
+ * description. Can be used without phy_connect by drivers which do not expose
+ * a UCLASS_ETH udevice.
+ */
+struct phy_device *fixed_phy_create(ofnode node);
+
+#else
+
+static inline struct phy_device *fixed_phy_create(ofnode node)
+{
[PATCH v5 4/9] net: mdio: teach dm_eth_connect_phy_handle to connect to fixed PHY
From: Vladimir Oltean
dm_eth_connect_phy_handle has all the info it needs in order to hide
away from the UCLASS_ETH caller the fact that it is attached to a
fixed-link PHY. So only attempt to search for a phy-handle if we've
exhausted the fixed-link option first.
Signed-off-by: Vladimir Oltean
---
Changes in v5:
None.
net/mdio-uclass.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 697e5f838d94..766d4711cc23 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -177,9 +177,10 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
/* Connect to a PHY linked in eth DT node */
struct phy_device *dm_eth_phy_connect(struct udevice *ethdev)
{
- const char *if_str;
+ ofnode node = dev_ofnode(ethdev), subnode;
phy_interface_t interface;
struct phy_device *phy;
+ const char *if_str;
int i;
if (!dev_has_ofnode(ethdev)) {
@@ -200,7 +201,14 @@ struct phy_device *dm_eth_phy_connect(struct udevice
*ethdev)
if (interface == PHY_INTERFACE_MODE_NONE)
dev_dbg(ethdev, "can't find interface mode, default to NONE\n");
- phy = dm_eth_connect_phy_handle(ethdev, interface);
+ subnode = ofnode_find_subnode(node, "fixed-link");
+ if (ofnode_valid(subnode)) {
+ phy = phy_connect(NULL, 0, ethdev, interface);
+ if (phy)
+ phy->node = subnode;
+ } else {
+ phy = dm_eth_connect_phy_handle(ethdev, interface);
+ }
if (!phy)
return NULL;
--
2.25.1
[PATCH v5 2/9] net: phy: fixed: support speeds of 2500 and 10000
From: Vladimir Oltean
Unlike the Linux fixed PHY driver, the one in U-Boot does not attempt to
emulate the clause 22 register set of a gigabit copper PHY driver
through the swphy framework. Therefore, the limitation of being unable
to support speeds higher than gigabit in fixed-link does not apply to
the U-Boot fixed PHY driver. This makes the fixed-link U-Boot
implementation more similar to the one from phylink, which can work with
any valid link speed.
Signed-off-by: Vladimir Oltean
Reviewed-by: Claudiu Manoil
---
Changes in v5:
None.
Changes in v4:
Patch is new.
drivers/net/phy/fixed.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index d117a50719a2..ae6b44bec81c 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -25,7 +25,8 @@ static int fixedphy_of_init(struct phy_device *phydev)
return -EINVAL;
val = ofnode_read_u32_default(node, "speed", 0);
- if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000) {
+ if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000 &&
+ val != SPEED_2500 && val != SPEED_1) {
printf("ERROR: no/invalid speed given in fixed-link node!");
return -EINVAL;
}
--
2.25.1
[PATCH v5 1/9] net: phy: fixed: be compatible with live OF tree
From: Vladimir Oltean
On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined as
const struct device_node *np, while on the flat DT systems it is defined
as a long of_offset into gd->fdt_blob.
It is desirable that the fixed PHY driver uses the higher-level ofnode
abstraction instead of parsing gd->fdt_blob directly, because that
enables it to work on live OF systems.
The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c10 ("drivers/net/phy: add fixed-phy / fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already mismatched
leading to a potential truncation (flat OF offset was supposed to be a
long and not an int), we really cannot extend this hack any longer,
because there's no way an int will hold the other representation of
ofnode, the struct device_node *np.
So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in commit eef0b8a930d1 ("net:
phy: add ofnode node to struct phy_device"). This will populate
phydev->node for the fixed PHY.
Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver.
Signed-off-by: Vladimir Oltean
---
Changes in v5:
Patch is new.
drivers/net/phy/fixed.c | 31 ++-
drivers/net/phy/phy.c | 24 ++--
2 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 3228672fc4ae..d117a50719a2 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -15,15 +15,16 @@
DECLARE_GLOBAL_DATA_PTR;
-int fixedphy_probe(struct phy_device *phydev)
+static int fixedphy_of_init(struct phy_device *phydev)
{
+ ofnode node = phy_get_ofnode(phydev);
struct fixed_link *priv;
- int ofnode = phydev->addr;
u32 val;
- /* check for mandatory properties within fixed-link node */
- val = fdt_getprop_u32_default_node(gd->fdt_blob,
- ofnode, 0, "speed", 0);
+ if (!ofnode_valid(node))
+ return -EINVAL;
+
+ val = ofnode_read_u32_default(node, "speed", 0);
if (val != SPEED_10 && val != SPEED_100 && val != SPEED_1000) {
printf("ERROR: no/invalid speed given in fixed-link node!");
return -EINVAL;
@@ -32,14 +33,26 @@ int fixedphy_probe(struct phy_device *phydev)
priv = malloc(sizeof(*priv));
if (!priv)
return -ENOMEM;
+
memset(priv, 0, sizeof(*priv));
phydev->priv = priv;
priv->link_speed = val;
- priv->duplex = fdtdec_get_bool(gd->fdt_blob, ofnode, "full-duplex");
- priv->pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "pause");
- priv->asym_pause = fdtdec_get_bool(gd->fdt_blob, ofnode, "asym-pause");
+ priv->duplex = ofnode_read_bool(node, "full-duplex");
+ priv->pause = ofnode_read_bool(node, "pause");
+ priv->asym_pause = ofnode_read_bool(node, "asym-pause");
+
+ return 0;
+}
+
+static int fixedphy_config(struct phy_device *phydev)
+{
+ int err;
+
+ err = fixedphy_of_init(phydev);
+ if (err)
+ return err;
/* fixed-link phy must not be reset by core phy code */
phydev->flags |= PHY_FLAG_BROKEN_RESET;
@@ -70,7 +83,7 @@ static struct phy_driver fixedphy_driver = {
.mask = 0x,
.name = "Fixed PHY",
.features = PHY_GBIT_FEATURES | SUPPORTED_MII,
- .probe = fixedphy_probe,
+ .config = fixedphy_config,
.startup= fixedphy_startup,
.shutdown = fixedphy_shutdown,
};
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a2be3987364c..e88c93c4180d 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -987,19 +987,23 @@ static struct phy_device *phy_connect_fixed(struct
mii_dev *bus,
phy_interface_t interface)
#endif
{
+ ofnode node = dev_ofnode(dev), subnode;
struct phy_device *phydev = NULL;
- int sn;
const char *name;
- sn = fdt_first_subnode(gd->fdt_blob, dev_of_offset(dev));
- while (sn > 0) {
- name = fdt_get_name(gd->fdt_blob, sn, NULL);
- if (name && strcmp(name, "fixed-link") == 0) {
- phydev = phy_device_create(bus, sn, PHY_FIXED_ID, false,
- interface);
- break;
- }
- sn = fdt_next_subno
[PATCH v5 0/9] Introduce DSA Ethernet switch class and Felix driver
From: Vladimir Oltean
DSA stands for Distributed Switch Architecture and it is a subsystem
introduced in the Linux kernel to support switches that:
- have an Ethernet link up to the CPU
- use some form of tagging to identify the source/destination port for
Rx/Tx
- may be cascaded in tree-like structures.
DSA is described in depth here:
https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
This patch set introduces a DSA class in U-Boot to support drivers of DSA
switches. DSA drivers have to implement the following ops:
- enable/disable of switch ports,
- insert a tag in frames being transmitted, used by the switch to select
the egress port,
- parse a tag in frames being received, used for Rx traffic.
DSA class code deals with presentation of switch ports as Ethernet
interfaces, deals with the master Ethernet device for I/O and helps with
parsing of the DT assuming the structure follows the DSA kernel binding.
Support for switch cascading is not included yet.
In the sandbox environment, the DSA sandbox driver, the switch ports and
master eth interface look like this:
=> dm tree
Class Index Probed DriverName
---
[...]
eth 4 [ + ] eth_sandbox |-- dsa-test-eth
dsa 0 [ + ] dsa_sandbox |-- dsa-test
eth 5 [ + ] dsa-port | |-- lan0
eth 6 [ + ] dsa-port | `-- lan1
=> setenv ethact lan1
=> ping 1.2.3.5
Using lan1 device
host 1.2.3.5 is alive
=>
This patch set also introduces a driver for the Ethernet switch integrated
into NXP LS1028A, called Felix. The switch has 4 front panel ports, I/O
to/from it is done though an ENETC Ethernet interface and meta-data is
carried between the switch and the driver though an additional header
pre-pended to the original frame.
Network commands like tftp can be used on these front panel ports. The
ports are disabled unless used so they do not cause issues on network
topologies that include loops.
Felix as seen on LS1028A RDB:
=> dm tree
Class Index Probed DriverName
---
[...]
dsa 0 [ + ] felix-switch | |-- felix-switch
eth 4 [ + ] dsa-port | | |-- swp0
eth 5 [ + ] dsa-port | | |-- swp1
eth 6 [ + ] dsa-port | | |-- swp2
eth 7 [ + ] dsa-port | | `-- swp3
=> mdio list
[...]
10 - Vitesse VSC8514 <--> swp0
11 - Vitesse VSC8514 <--> swp1
12 - Vitesse VSC8514 <--> swp2
13 - Vitesse VSC8514 <--> swp3
NOTE:
This patchset is a major rework of the dsa-class code since the last
submission from May 5th:
https://patchwork.ozlabs.org/project/uboot/cover/1588700588-8587-1-git-send-email-claudiu.man...@nxp.com/
The basic concepts and data path operation (tagging) in the DSA class
code remain the same as in the initial patchset from Alex, however the
external API has been changed significantly (simplified), the driver
model integration has been improved to the point that the DSA class
code no longer needs to allocate extra memory internally (via malloc),
reduced memory footprint, internal state data moved from the external
API and internalized, cleaner external API, internal code reworked,
completely reworked DSA sandbox driver and unit tests for better coverage
and to integrate better with the eth sandbox driver and tests, etc.
v5:
Fix the DSA driver not probing in the sandbox, and the net_retry test
failing due to that:
- Made PHY_FIXED work with live OF.
- Made DSA user ports [ not just CPU ports as before ], and any other
callers of dm_eth_phy_connect, work with fixed-link.
v4:
- Implemented the TODO for having a phy_device on the CPU port.
- Enabled CONFIG_PHY_FIXED which is a new dependency of CONFIG_DM_DSA.
v3:
- Removed all infrastructure associated with dsa_foreach_port, which
is no longer needed.
- Only inherit the DSA master's MAC address if the environment does not
already have a specific MAC address that should be used for the DSA
port.
- Be compatible with the new "ethernet-ports" container name which has
been introduced in the Linux kernel as commit 85e05d263ed2 ("net: dsa:
of: Allow ethernet-ports as encapsulating node") in v5.9.
- Fixed the felix driver not getting its ports initialized, due to
dsa_foreach_port() being actually unusable when called from the probe
function of the DSA udevice - the eth port udevices are _not_ yet
probed at that point. We are now initializing all ports from the
.port_enable() callback of each eth udevice.
- Deleted the unit tests associated with the infrastructure for
dsa_foreach_port, since that function no longer exists.
- Enabled the config options for the Kontron LS1028A board too.
v2: Switch node structure defined in dtsi now consistent with the Linux
switch node definition. Moved aliases f
Re: [PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()
On 2/16/21 6:32 PM, Patrice CHOTARD wrote:
Hi Marek
Hi,
On 2/11/21 12:26 PM, Marek Vasut wrote:
On 2/11/21 10:58 AM, Patrice CHOTARD wrote:
Hi Marek
On 2/10/21 3:26 PM, Marek Vasut wrote:
On 2/10/21 3:17 PM, Patrice Chotard wrote:
Since commit 8745b9ebccae ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.
Remove the speed test in dwc2_gadget_start() to fix it.
Tested on stm32mp157c-ev1 board.
Isn't the speed check correct though ?
I am not sure this speed test is needed.
What is really going on when this fails ?
Since 8745b9ebccae ("usb: gadget: add super speed support"),
driver->speed is now set to USB_SPEED_SUPER in drivers/usb/gadget/composite.c
and this forbids dwc2_udc_otg.c to be registered.
That sounds like a bug in the USB gadget/otg core , no ?
After analysis, if i correctly understood, the speed test done in both
usb_gadget_register_driver()
and in dwc2_gadget_start() in dwc2_udc_otg.c is too restrictive and accepts
only gadget driver with
max speed equal to USB_SPEED_FULL or USB_SPEED_HIGH.
That should be fine for the DWC2 IP, which is LS/FS/HS.
So all gadget driver with max speed set to higher speed than USB_SPEED_HIGH
(USB_SPEED_SUPER in case of
composite gadget driver) are not allowed, which is wrong.
This test should check that the gadget driver max speed is higher or equal to
the min speed supported by
dwc2_udc_otg driver, ie USB_SPEED_FULL.
So the test should be :
@@ -247,12 +247,11 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
unsigned long flags = 0;
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
if (!driver
- || (driver->speed != USB_SPEED_FULL
- && driver->speed != USB_SPEED_HIGH)
+ || driver->speed < USB_SPEED_FULL
|| !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
return -ENODEV;
if (dev->driver)
@@ -319,12 +318,11 @@ static int dwc2_gadget_start(struct usb_gadget *g,
struct dwc2_udc *dev = the_controller;
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
if (!driver ||
- (driver->speed != USB_SPEED_FULL &&
-driver->speed != USB_SPEED_HIGH) ||
+ driver->speed < USB_SPEED_FULL ||
The DWC2 can't operate in LS gadget mode , i.e. emulate some old
keyboard ? Maybe what you want is driver->speed > USB_SPEED_HIGH instead ?
!driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
I you are agree, i will send a v2 with this.
Yes please. But you really want to get AB/RB from Lukasz, since he does
the gadget stuff.
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Tue, Feb 16, 2021 at 11:02:25PM +0200, Vladimir Oltean wrote: > Hi Tom, > > On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > > This test does not pass for me. This can be seen at: > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > > > Note that I'm still reviewing the rest of the series right now. > > You're right, thanks for letting me know. > I've fixed this in my tree [ by adding two more patches :-/ ], let me > know if you have any other feedback, otherwise I'm going to resend soon. I'm about to push the rest of the series, so you can rebase on master shortly, thanks! Or should I hold off as this exposed problems in the rest of your series? -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
Hi Tom, On Tue, Feb 16, 2021 at 01:14:57PM -0500, Tom Rini wrote: > This test does not pass for me. This can be seen at: > https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 > > Note that I'm still reviewing the rest of the series right now. You're right, thanks for letting me know. I've fixed this in my tree [ by adding two more patches :-/ ], let me know if you have any other feedback, otherwise I'm going to resend soon.
[PATCH 2/2] configs: RPi2: Disable EFI Grub workaround
From: Matthias Brugger The EFI Grub workaround isn't needed with Grub version 2.04 or higher. This version was published over a year ago, so disable the workaround to reduce boot time. Signed-off-by: Matthias Brugger --- configs/rpi_2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 33f27cf09f..a0f36e1a93 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -42,3 +42,4 @@ CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y +# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set -- 2.30.0
[PATCH 1/2] configs: BPI-R2: Disable EFI Grub workaround
From: Matthias Brugger The EFI Grub workaround on BananaPi R2 slows down the boot process to the point, that the watchdog will trigger a reboot before the kernel can reset it. Fix this by disabeling the workaround. Signed-off-by: Matthias Brugger --- configs/mt7623n_bpir2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig index d36ff560cf..fb20cb1832 100644 --- a/configs/mt7623n_bpir2_defconfig +++ b/configs/mt7623n_bpir2_defconfig @@ -53,3 +53,4 @@ CONFIG_TIMER=y CONFIG_MTK_TIMER=y CONFIG_WDT_MTK=y CONFIG_LZMA=y +# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set -- 2.30.0
[PATCH v5] timer: imx-gpt: Add timer support for i.MX SoCs family
From: Jesse Taube
This timer driver is using GPT Timer (General Purpose Timer)
available on most i.MX SoCs.
Since this driver is only meant to provide u-boot's timer and counter,
and most of the i.MX* SoCs use a 24Mhz crystal,
let's focus on that specific source.
Signed-off-by: Giulio Benetti
Signed-off-by: Jesse Taube
---
V1->V2:
* Fixed indentation
* Fixed capitals
* Made timer work on only 24MHz clock
V2->V3:
* Fixed indentation
* Made implementation imatate the Linux kernel
* Fix wrong definition
V3->V4:
* Fixed indentation
* Made bit manipluation into its own function.
V4->V5:
* Fixed indentation
* Made commit message 75 char
* Moved prescaler code into sub funcions
drivers/timer/Kconfig | 7 ++
drivers/timer/Makefile| 1 +
drivers/timer/imx-gpt-timer.c | 160 ++
3 files changed, 168 insertions(+)
create mode 100644 drivers/timer/imx-gpt-timer.c
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 80743a2551..ee81dfa776 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
Select this to enable support for Microchip 64-bit periodic
interval timer.
+config IMX_GPT_TIMER
+ bool "NXP i.MX GPT timer support"
+ depends on TIMER
+ help
+ Select this to enable support for the timer found on
+ NXP i.MX devices.
+
endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
obj-$(CONFIG_MCHP_PIT64B_TIMER)+= mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..1607a2fbcb
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define GPT_CR_SWR 0x8000
+#define GPT_CR_EN_24M 0x0400
+#define GPT_CR_EN 0x0001
+#define GPT_PR_PRESCALER 0x0FFF
+
+#define GPT_CLKSRC_IPG_CLK (1 << 6)
+#define GPT_CLKSRC_IPG_CLK_24M (5 << 6)
+
+struct imx_gpt_timer_regs {
+ u32 cr;
+ u32 pr;
+ u32 sr;
+ u32 ir;
+ u32 ocr1;
+ u32 ocr2;
+ u32 ocr3;
+ u32 icr1;
+ u32 icr2;
+ u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+ struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+ struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+ struct imx_gpt_timer_regs *regs = priv->base;
+
+ return readl(®s->cnt);
+}
+
+static int imx_gpt_setup_24M(struct imx_gpt_timer_regs *regs)
+{
+ u32 prescaler;
+
+ /* Set timer frequency to 1MHz */
+ prescaler = (2400UL / CONFIG_SYS_HZ_CLOCK) - 1;
+ if (prescaler > GPT_PR_PRESCALER)
+ return -EINVAL;
+ /* We set timer prescaler to obtain a 1MHz timer counter frequency */
+ writel(prescaler, ®s->pr);
+
+ writel(GPT_CLKSRC_IPG_CLK_24M | GPT_CR_EN_24M, ®s->cr);
+ return 0;
+}
+
+static int imx_gpt_setup_per(u32 rate, struct imx_gpt_timer_regs *regs)
+{
+ u32 prescaler;
+
+ /* Set timer frequency to 1MHz */
+ prescaler = (rate / CONFIG_SYS_HZ_CLOCK) - 1;
+ if (prescaler > GPT_PR_PRESCALER)
+ return -EINVAL;
+ /* We set timer prescaler to obtain a 1MHz timer counter frequency */
+ writel(prescaler, ®s->pr);
+
+ writel(GPT_CLKSRC_IPG_CLK, ®s->cr);
+ return 0;
+}
+
+static int imx_gpt_setup(u32 rate, struct imx_gpt_timer_regs *regs)
+{
+ int ret;
+
+ /* Reset the timer */
+ setbits_le32(®s->cr, GPT_CR_SWR);
+
+ /* Wait for timer to finish reset */
+ while (readl(®s->cr) & GPT_CR_SWR)
+ ;
+
+ if (rate != 2400UL)
+ ret = imx_gpt_setup_per(rate, regs);
+ else
+ ret = imx_gpt_setup_24M(regs);
+
+ /* Start timer */
+ setbits_le32(®s->cr, GPT_CR_EN);
+
+ return ret;
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+ struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+ struct imx_gpt_timer_regs *regs;
+ struct clk clk;
+ fdt_addr_t addr;
+ u32 rate;
+ int ret;
+
+ addr = dev_read_addr(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ priv->base = (struct imx_gpt_timer_regs *)addr;
+ regs = priv->base;
+
+ uc_priv->clock_rate = CONFIG_SYS_HZ_CLOCK;
+
+ ret = cl
Re: [PATCH v4 4/7] sandbox: Add a DSA sandbox driver and unit test
On Mon, Jan 25, 2021 at 02:23:54PM +0200, Vladimir Oltean wrote: > From: Claudiu Manoil > > The DSA sandbox driver is used for unit testing the DSA class code. > It implements a simple 2 port switch plus 1 CPU port, and uses a very > simple tag to identify the ports. > The DSA sandbox device is connected via CPU port to a regular Ethernet > sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox > driver. The 'dsa-test-eth' is not intended for testing the eth class > code however, but it is used to emulate traffic through the 'lan0' and > 'lan1' front pannel switch ports. To achieve this the dsa sandbox driver > registers a tx handler for the 'dsa-test-eth' device. The switch ports, > labeled as 'lan0' and 'lan1', are also registered as eth devices by the > dsa class code this time. So pinging through these switch ports is as > easy as: > => setenv ethact lan0 > => ping 1.2.3.5 > > Unit tests for the dsa class code were also added. The 'dsa_probe' > test exercises most API functions from dsa.h. The 'dsa' unit test > simply exercises ARP/ICMP traffic through the two switch ports, > including tag injection and extraction, with the help of the dsa > sandbox driver. > I took care to minimize the impact on the existing eth unit tests, > though some adjustments needed to be made with the addition of > extra eth interfaces used by the dsa unit tests. The additional eth > interfaces also require MAC addresses, these have been added to the > sandbox default environment. > > Signed-off-by: Alex Marginean > Signed-off-by: Claudiu Manoil > Reviewed-by: Simon Glass > Signed-off-by: Vladimir Oltean This test does not pass for me. This can be seen at: https://gitlab.denx.de/u-boot/u-boot/-/jobs/223660 Note that I'm still reviewing the rest of the series right now. -- Tom signature.asc Description: PGP signature
Re: Chromium OS verified boot 2018 with U-Boot
On 16.02.21 18:12, Simon Glass wrote: > Hi, > > Just a note that the U-Boot / vboot integration has been updated with > the 2018 version of vboot and it makes full use of driver model. > > If it available at [1] > > Documentation for running it on coral (2018 Intel Apollo Lake > Chromebook) is available [2] as well as running it on sandbox [3]. > > The earlier release for 2015's samus (Chromebook Pixel 2) and 2012's > link is still available at [4]. > > Regards, > Simon > > [1] https://github.com/sjg20/u-boot/tree/cros-2021.01 > [2] https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_coral.rst > [3] > https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_sandbox.rst > [4] https://github.com/sjg20/u-boot/tree/cros-2019.01 Those *.rst should be in /doc/board/ ? It this something you are planning to merge into upstream U-Boot? Best regards Heinrich
[PATCH 1/1] doc: Add reference to U-Boot project in conf.py
With the last update of conf.py the references to U-Boot where replaced by
references to Linux.
Fix the project references in the generated documentation.
Reported by: Simon Glass
Fixes: 98f01cf7a22e ("doc: update Kernel documentation build system")
Signed-off-by: Heinrich Schuchardt
---
doc/conf.py | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/doc/conf.py b/doc/conf.py
index 3f456a18f5..eb74b86aef 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -147,9 +147,9 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
-project = 'The Linux Kernel'
-copyright = 'The kernel development community'
-author = 'The kernel development community'
+project = 'Das U-Boot'
+copyright = 'The U-Boot development community'
+author = 'The U-Boot development community'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
@@ -260,7 +260,7 @@ except ImportError:
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
-#html_logo = None
+html_logo = '../tools/logos/u-boot_logo.svg'
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
@@ -340,7 +340,7 @@ html_use_smartypants = False
#html_search_scorer = 'scorer.js'
# Output file base name for HTML help builder.
-htmlhelp_basename = 'TheLinuxKerneldoc'
+htmlhelp_basename = 'TheUBootdoc'
# -- Options for LaTeX output -
@@ -470,6 +470,8 @@ if major == 1 and minor < 6:
# author, documentclass [howto, manual, or own class]).
# Sorted in alphabetical order
latex_documents = [
+('index', 'u-boot-hacker-manual.tex', 'U-Boot Hacker Manual',
+ 'The U-Boot development community', 'manual'),
]
# Add all other index files from Documentation/ subdirectories
@@ -483,8 +485,8 @@ for fn in os.listdir('.'):
break
if not has:
latex_documents.append((doc, fn + '.tex',
-'Linux %s Documentation' % fn.capitalize(),
-'The kernel development community',
+'U-Boot %s Documentation' %
fn.capitalize(),
+'The U-Boot development community',
'manual'))
# The name of an image file (relative to this directory) to place at the top of
@@ -513,7 +515,7 @@ for fn in os.listdir('.'):
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
-(master_doc, 'thelinuxkernel', 'The Linux Kernel Documentation',
+(master_doc, 'dasuboot', 'The U-Boot Documentation',
[author], 1)
]
@@ -527,8 +529,8 @@ man_pages = [
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
-(master_doc, 'TheLinuxKernel', 'The Linux Kernel Documentation',
- author, 'TheLinuxKernel', 'One line description of project.',
+(master_doc, 'DasUBoot', 'The U-Boot Documentation',
+ author, 'DasUBoot', 'One line description of project.',
'Miscellaneous'),
]
@@ -626,7 +628,7 @@ epub_exclude_files = ['search.html']
# multiple PDF files here actually tries to get the cross-referencing right
# *between* PDF files.
pdf_documents = [
-('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
+('uboot-documentation', u'U-Boot', u'U-Boot', u'J. Random Bozo'),
]
# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
--
2.30.0
Re: [PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()
Hi Marek
On 2/11/21 12:26 PM, Marek Vasut wrote:
> On 2/11/21 10:58 AM, Patrice CHOTARD wrote:
>> Hi Marek
>>
>> On 2/10/21 3:26 PM, Marek Vasut wrote:
>>> On 2/10/21 3:17 PM, Patrice Chotard wrote:
Since commit 8745b9ebccae ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.
Remove the speed test in dwc2_gadget_start() to fix it.
Tested on stm32mp157c-ev1 board.
>>>
>>> Isn't the speed check correct though ?
>>
>> I am not sure this speed test is needed.
>>
>>>
>>> What is really going on when this fails ?
>>
>>
>> Since 8745b9ebccae ("usb: gadget: add super speed support"),
>> driver->speed is now set to USB_SPEED_SUPER in drivers/usb/gadget/composite.c
>>
>> and this forbids dwc2_udc_otg.c to be registered.
>
> That sounds like a bug in the USB gadget/otg core , no ?
After analysis, if i correctly understood, the speed test done in both
usb_gadget_register_driver()
and in dwc2_gadget_start() in dwc2_udc_otg.c is too restrictive and accepts
only gadget driver with
max speed equal to USB_SPEED_FULL or USB_SPEED_HIGH.
So all gadget driver with max speed set to higher speed than USB_SPEED_HIGH
(USB_SPEED_SUPER in case of
composite gadget driver) are not allowed, which is wrong.
This test should check that the gadget driver max speed is higher or equal to
the min speed supported by
dwc2_udc_otg driver, ie USB_SPEED_FULL.
So the test should be :
@@ -247,12 +247,11 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
unsigned long flags = 0;
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
if (!driver
- || (driver->speed != USB_SPEED_FULL
- && driver->speed != USB_SPEED_HIGH)
+ || driver->speed < USB_SPEED_FULL
|| !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
return -ENODEV;
if (dev->driver)
@@ -319,12 +318,11 @@ static int dwc2_gadget_start(struct usb_gadget *g,
struct dwc2_udc *dev = the_controller;
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
if (!driver ||
- (driver->speed != USB_SPEED_FULL &&
-driver->speed != USB_SPEED_HIGH) ||
+ driver->speed < USB_SPEED_FULL ||
!driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
I you are agree, i will send a v2 with this.
Patrice
Chromium OS verified boot 2018 with U-Boot
Hi, Just a note that the U-Boot / vboot integration has been updated with the 2018 version of vboot and it makes full use of driver model. If it available at [1] Documentation for running it on coral (2018 Intel Apollo Lake Chromebook) is available [2] as well as running it on sandbox [3]. The earlier release for 2015's samus (Chromebook Pixel 2) and 2012's link is still available at [4]. Regards, Simon [1] https://github.com/sjg20/u-boot/tree/cros-2021.01 [2] https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_coral.rst [3] https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_sandbox.rst [4] https://github.com/sjg20/u-boot/tree/cros-2019.01
Re: [PATCH] lib: rsa: Add debug message on algo mismatch
On 2/16/21 12:01 PM, Wolfgang Denk wrote:
> Dear Sean Anderson,
>
> In message <20210216164016.635125-1-sean.ander...@seco.com> you wrote:
>> Currently we fail silently if there is an algorithm mismatch. To help
>> distinguish this failure condition.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> lib/rsa/rsa-verify.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
>> index e34d3293d1..aee76f42d5 100644
>> --- a/lib/rsa/rsa-verify.c
>> +++ b/lib/rsa/rsa-verify.c
>> @@ -447,8 +447,11 @@ static int rsa_verify_with_keynode(struct
image_sign_info *info,
>>}
>>
>>algo = fdt_getprop(blob, node, "algo", NULL);
>> - if (strcmp(info->name, algo))
>> + if (strcmp(info->name, algo)) {
>> + debug("%s: Wrong algo: have %s, expected %s", __func__,
>> +info->name, algo);
>>return -EFAULT;
>> + }
>
> If this is considered an error, should that not be a printf() then
> instead of a debug() which users will never see?
I also thought that, but the much of the rest of this file also uses
debug() to report errors. Perhaps there are security implications? Or
perhaps it was done to reduce binary size? Simon, can you comment on
this?
--Sean
>
> Best regards,
>
> Wolfgang Denk
>
Re: [PATCH] lib: rsa: Add debug message on algo mismatch
Dear Sean Anderson,
In message <20210216164016.635125-1-sean.ander...@seco.com> you wrote:
> Currently we fail silently if there is an algorithm mismatch. To help
> distinguish this failure condition.
>
> Signed-off-by: Sean Anderson
> ---
>
> lib/rsa/rsa-verify.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> index e34d3293d1..aee76f42d5 100644
> --- a/lib/rsa/rsa-verify.c
> +++ b/lib/rsa/rsa-verify.c
> @@ -447,8 +447,11 @@ static int rsa_verify_with_keynode(struct
> image_sign_info *info,
> }
>
> algo = fdt_getprop(blob, node, "algo", NULL);
> - if (strcmp(info->name, algo))
> + if (strcmp(info->name, algo)) {
> + debug("%s: Wrong algo: have %s, expected %s", __func__,
> + info->name, algo);
> return -EFAULT;
> + }
If this is considered an error, should that not be a printf() then
instead of a debug() which users will never see?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is impractical for the standard to attempt to constrain the
behavior of code that does not obey the constraints of the standard.
- Doug Gwyn
[PATCH] lib: rsa: Add debug message on algo mismatch
Currently we fail silently if there is an algorithm mismatch. To help
distinguish this failure condition.
Signed-off-by: Sean Anderson
---
lib/rsa/rsa-verify.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index e34d3293d1..aee76f42d5 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -447,8 +447,11 @@ static int rsa_verify_with_keynode(struct image_sign_info
*info,
}
algo = fdt_getprop(blob, node, "algo", NULL);
- if (strcmp(info->name, algo))
+ if (strcmp(info->name, algo)) {
+ debug("%s: Wrong algo: have %s, expected %s", __func__,
+ info->name, algo);
return -EFAULT;
+ }
prop.num_bits = fdtdec_get_int(blob, node, "rsa,num-bits", 0);
--
2.25.1
Re: [PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote: > Hi Roger, > > Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne: > > From: Roger Pau Monné > > > > Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the > > resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. > > Removing the setting from the defconfig allows U-Boot to load > > successfully. > > Hmm, I'd disagree slightly. > > In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as > > /* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */ > #define CONFIG_SPL_PAD_TO 8355840 > > so it's a static value but based on the MMCSD_RAW_MODE... config option. > > So instead of mandating one specific MMCSD_RAW_MODE... value > that CONFIG_SPL_PAD_TO should be defined based on the the > actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > and not some static number that then gets enforced for all boards. So, what does CONFIG_SPL_PAD_TO actually mean, in this case? And SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR ? What I'm getting at is that we generally have some required to be fixed (by the SoC/ROM/etc) locations some parts of our SPL/TPL/U-Boot need to be at and then the rest of the values are (supposed to be) well and carefully chosen offsets and not changed around. So with the above comment in the code to explain where 8355840 came from, it also shouldn't and nor should CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR be changed without a compelling reason. -- Tom signature.asc Description: PGP signature
[PATCH] imx: Add 2GB lpddr support for i.MX8MN Beacon EmbeddedWorks devkit.
There is a second lpddr configuration with 2GB of RAM, but this requires
different RAM timings, so in addition to adding the timing file, a
separate defconfig is necessary.
Signed-off-by: Adam Ford
diff --git a/board/beacon/imx8mn/Kconfig b/board/beacon/imx8mn/Kconfig
index 6ed17c00d8..2bcfb25cf8 100644
--- a/board/beacon/imx8mn/Kconfig
+++ b/board/beacon/imx8mn/Kconfig
@@ -13,6 +13,10 @@ config IMX8MN_FORCE_NOM_SOC
bool "Force to use nominal mode for SOC and ARM"
default n
+config IMX8MN_BEACON_2GB_LPDDR
+ bool "Enable 2GB LPDDR"
+ default n
+
source "board/freescale/common/Kconfig"
endif
diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS
index 4e3fc713a0..4805cb255c 100644
--- a/board/beacon/imx8mn/MAINTAINERS
+++ b/board/beacon/imx8mn/MAINTAINERS
@@ -4,3 +4,4 @@ S: Maintained
F: board/beacon/imx8mn/
F: include/configs/imx8mn_beacon.h
F: configs/imx8mn_beacon_defconfig
+F: configs/imx8mn_beacon_2g_defconfig
diff --git a/board/beacon/imx8mn/Makefile b/board/beacon/imx8mn/Makefile
index 9e842de42f..d620ccb772 100644
--- a/board/beacon/imx8mn/Makefile
+++ b/board/beacon/imx8mn/Makefile
@@ -8,6 +8,9 @@ obj-y += imx8mn_beacon.o
obj-y += ../../freescale/common/
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
-obj-$(CONFIG_IMX8M_LPDDR4) += lpddr4_timing.o
-obj-$(CONFIG_IMX8M_DDR4) += ddr4_timing.o
+ifdef CONFIG_IMX8MN_BEACON_2GB_LPDDR
+obj-y += lpddr4_2g_timing.o
+else
+obj-y += lpddr4_timing.o
+endif
endif
diff --git a/board/beacon/imx8mn/lpddr4_2g_timing.c
b/board/beacon/imx8mn/lpddr4_2g_timing.c
new file mode 100644
index 00..3c32d804a1
--- /dev/null
+++ b/board/beacon/imx8mn/lpddr4_2g_timing.c
@@ -0,0 +1,1440 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *
+ * Generated code from MX8M_DDR_tool
+ * Align with uboot-imx_v2018.03_4.14.78_1.0.0_ga
+ */
+
+#include
+#include
+
+struct dram_cfg_param ddr_ddrc_cfg[] = {
+ /** Initialize DDRC registers **/
+ { 0x3d400304, 0x1 },
+ { 0x3d400030, 0x1 },
+ { 0x3d40, 0xa3080020 },
+ { 0x3d400020, 0x202 },
+ { 0x3d400024, 0x3e800 },
+ { 0x3d400064, 0x3000e0 },
+ { 0x3d4000d0, 0xc003061c },
+ { 0x3d4000d4, 0x9e },
+ { 0x3d4000dc, 0xd4002d },
+ { 0x3d4000e0, 0x31 },
+ { 0x3d4000e8, 0x66004d },
+ { 0x3d4000ec, 0x16004d },
+ { 0x3d400100, 0x1a200d22 },
+ { 0x3d400104, 0x60633 },
+ { 0x3d40010c, 0xc0c000 },
+ { 0x3d400110, 0xf04080f },
+ { 0x3d400114, 0x2040c0c },
+ { 0x3d400118, 0x1010007 },
+ { 0x3d40011c, 0x401 },
+ { 0x3d400130, 0x20600 },
+ { 0x3d400134, 0xc12 },
+ { 0x3d400138, 0xe6 },
+ { 0x3d400144, 0xa00050 },
+ { 0x3d400180, 0x3200018 },
+ { 0x3d400184, 0x28061a8 },
+ { 0x3d400188, 0x0 },
+ { 0x3d400190, 0x497820a },
+ { 0x3d400194, 0x80303 },
+ { 0x3d4001b4, 0x170a },
+ { 0x3d4001a0, 0xe0400018 },
+ { 0x3d4001a4, 0xdf00e4 },
+ { 0x3d4001a8, 0x8000 },
+ { 0x3d4001b0, 0x11 },
+ { 0x3d4001c0, 0x1 },
+ { 0x3d4001c4, 0x1 },
+ { 0x3d4000f4, 0xc99 },
+ { 0x3d400108, 0x70e1617 },
+ { 0x3d400200, 0x17 },
+ { 0x3d40020c, 0x0 },
+ { 0x3d400210, 0x1f1f },
+ { 0x3d400204, 0x80808 },
+ { 0x3d400214, 0x7070707 },
+ { 0x3d400218, 0x7070707 },
+ { 0x3d400250, 0x29001701 },
+ { 0x3d400254, 0x2c },
+ { 0x3d40025c, 0x430 },
+ { 0x3d400264, 0x900093e7 },
+ { 0x3d40026c, 0x2005574 },
+ { 0x3d400400, 0x111 },
+ { 0x3d400408, 0x72ff },
+ { 0x3d400494, 0x2100e07 },
+ { 0x3d400498, 0x620096 },
+ { 0x3d40049c, 0x1100e07 },
+ { 0x3d4004a0, 0xc8012c },
+ { 0x3d402020, 0x0 },
+ { 0x3d402024, 0x7d00 },
+ { 0x3d402050, 0x20d040 },
+ { 0x3d402064, 0x6001c },
+ { 0x3d4020dc, 0x84 },
+ { 0x3d4020e0, 0x31 },
+ { 0x3d4020e8, 0x66004d },
+ { 0x3d4020ec, 0x16004d },
+ { 0x3d402100, 0xa040105 },
+ { 0x3d402104, 0x30407 },
+ { 0x3d402108, 0x203060b },
+ { 0x3d40210c, 0x505000 },
+ { 0x3d402110, 0x2040202 },
+ { 0x3d402114, 0x2030202 },
+ { 0x3d402118, 0x1010004 },
+ { 0x3d40211c, 0x301 },
+ { 0x3d402130, 0x20300 },
+ { 0x3d402134, 0xa12 },
+ { 0x3d402138, 0x1d },
+ { 0x3d402144, 0x14000a },
+ { 0x3d402180, 0x640004 },
+ { 0x3d402190, 0x3818200 },
+ { 0x3d402194, 0x80303 },
+ { 0x3d4021b4, 0x100 },
+ { 0x3d4020f4, 0xc99 },
+ { 0x3d403020, 0x0 },
+ { 0x3d403024, 0x1f40 },
+ { 0x3d403050, 0x20d040 },
+ { 0x3d403064, 0x30007 },
+ { 0x3d4030dc, 0x84 },
+ { 0x3d4030e0, 0x31 },
+ { 0x3d4030e8, 0x66004d },
+ { 0x3d4030ec, 0x16004d },
+ { 0x3d403100, 0xa010102 },
+ { 0x3d403104, 0x30404 },
+ { 0x3d403108, 0x203060b },
[PATCH] sunxi: Use kconfig instead define CONFIG_I2C_EDID
Signed-off-by: Igor Iurasov --- arch/arm/mach-sunxi/Kconfig| 1 + include/configs/sunxi-common.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 0135575ca1..1ffdc3de1d 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -818,6 +818,7 @@ config VIDEO_SUNXI depends on !SUN50I_GEN_H6 select VIDEO imply VIDEO_DT_SIMPLEFB + imply I2C_EDID default y ---help--- Say Y here to add support for using a cfb console on the HDMI, LCD diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 000f386470..068aef2f5a 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -265,7 +265,6 @@ extern int soft_i2c_gpio_scl; #define CONFIG_VIDEO_LOGO #define CONFIG_VIDEO_STD_TIMINGS -#define CONFIG_I2C_EDID #define VIDEO_LINE_LEN (pGD->plnSizeX) /* allow both serial and cfb console. */ -- 2.26.2
Re: [PATCH v3] mmc: mmc_spi: Print verbose debug output when crc16 check fails
On Sun, Feb 7, 2021 at 7:50 PM Peng Fan wrote: > > > Subject: Re: [PATCH v3] mmc: mmc_spi: Print verbose debug output when > > crc16 check fails > > > > On Tue, Feb 2, 2021 at 10:32 AM Bin Meng wrote: > > > > > > Add some verbose debug output when crc16 check fails. > > > > > > Signed-off-by: Bin Meng > > > Reviewed-by: Jaehoon Chung > > > > > > --- > > > > > > Changes in v3: > > > - use expected/got instead of expect/get > > > > > > Changes in v2: > > > - do the crc_ok assignment at the the same line where it's defined > > > > > > drivers/mmc/mmc_spi.c | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > Peng, ping? > > Sorry for delay, I'll take it and PR in next week. Ping?
Re: [PATCH v10 02/11] efi_loader: capsule: add capsule_on_disk support
On Tue, Feb 16, 2021 at 11:24:47AM +0100, Heinrich Schuchardt wrote:
> On 30.11.20 10:12, AKASHI Takahiro wrote:
> > Capsule data can be loaded into the system either via UpdateCapsule
> > runtime service or files on a file system (of boot device).
> > The latter case is called "capsules on disk", and actual updates will
> > take place at the next boot time.
> >
> > In this commit, we will support capsule on disk mechanism.
> >
> > Please note that U-Boot itself has no notion of "boot device" and
> > all the capsule files to be executed will be detected only if they
> > are located in a specific directory, \EFI\UpdateCapsule, on a device
> > that is identified as a boot device by "Boot" variables.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > common/main.c| 4 +
> > include/efi_loader.h | 9 +
> > lib/efi_loader/Kconfig | 22 ++
> > lib/efi_loader/efi_capsule.c | 498 +++
> > lib/efi_loader/efi_setup.c | 8 +
> > 5 files changed, 541 insertions(+)
> >
> > diff --git a/common/main.c b/common/main.c
> > index 4b3cd302c3e2..ae5bcdb32f8b 100644
> > --- a/common/main.c
> > +++ b/common/main.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static void run_preboot_environment_command(void)
> > {
> > @@ -53,6 +54,9 @@ void main_loop(void)
> > if (IS_ENABLED(CONFIG_UPDATE_TFTP))
> > update_tftp(0UL, NULL, NULL);
> >
> > + if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY))
> > + efi_launch_capsules();
>
> If my preboot command is
>
> load mmc 0:1 $kernel_addr_r EFI/boot/grubaa64.efi &&
> bootefi $kernel_addr_r
Why do you want to run "bootefi" in "preboot" environment?
> efi_lauch_capsule() will never be called.
>
> Why do you call efi_launch_capsule after
> run_preboot_environment_command() and update_tftp()?
Capsule update logically provides a similar function to update_tftp().
So I believed that the place near update_tftp() is the best.
-Takahiro Akashi
> efi_init_obj_list() is executed as last routine in board_init_r() just
> before invoking run_main_loop().
>
> Can't we simplify the coding by relying on calling efi_launch_capsule()
> in efi_init_obj_list()?
>
> Best regards
>
> Heinrich
>
> > +
> > s = bootdelay_process();
> > if (cli_process_fdt(&s))
> > cli_secure_boot_cmd(s);
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index d22f7a43ad09..eb57e7455eb1 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -820,6 +820,11 @@ efi_status_t EFIAPI efi_query_capsule_caps(
> > u64 *maximum_capsule_size,
> > u32 *reset_type);
> >
> > +#define EFI_CAPSULE_DIR L"\\EFI\\UpdateCapsule\\"
> > +
> > +/* Hook at initialization */
> > +efi_status_t efi_launch_capsules(void);
> > +
> > #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >
> > /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out
> > */
> > @@ -836,6 +841,10 @@ static inline void efi_set_bootdev(const char *dev,
> > const char *devnr,
> >const char *path) { }
> > static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
> > static inline void efi_print_image_infos(void *pc) { }
> > +static inline efi_status_t efi_launch_capsules(void)
> > +{
> > + return EFI_SUCCESS;
> > +}
> >
> > #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 3ca396df3646..e1ac5ac055de 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -104,6 +104,28 @@ config EFI_RUNTIME_UPDATE_CAPSULE
> > Select this option if you want to use UpdateCapsule and
> > QueryCapsuleCapabilities API's.
> >
> > +config EFI_CAPSULE_ON_DISK
> > + bool "Enable capsule-on-disk support"
> > + select EFI_HAVE_CAPSULE_SUPPORT
> > + default n
> > + help
> > + Select this option if you want to use capsule-on-disk feature,
> > + that is, capsules can be fetched and executed from files
> > + under a specific directory on UEFI system partition instead of
> > + via UpdateCapsule API.
> > +
> > +config EFI_CAPSULE_ON_DISK_EARLY
> > + bool "Initiate capsule-on-disk at U-Boot boottime"
> > + depends on EFI_CAPSULE_ON_DISK
> > + default n
> > + select EFI_SETUP_EARLY
> > + help
> > + Normally, without this option enabled, capsules will be
> > + executed only at the first time of invoking one of efi command.
> > + If this option is enabled, capsules will be enforced to be
> > + executed as part of U-Boot initialisation so that they will
> > + surely take place whatever is set to distro_bootcmd.
> > +
> > config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 575fa75b0a2f..b3c7d1b735b6 100644
> > --- a/lib/efi_loader/efi_capsule.c
>
Re: [PATCH 1/2] efi: Add ESRT to the EFI system table
On 16.02.21 10:06, Heinrich Schuchardt wrote:
> On 08.02.21 13:52, Jose Marinho wrote:
>> The ESRT is initialised during efi_init_objlist after
>> efi_initialize_system_table().
>>
>> The ESRT is initially created with size for 50 FW image entries.
>> The ESRT is resized when it runs out of space. Every resize adds 50
>> additional entries.
>> The ESRT is populated from information provided by FMP instances only.
>>
>> Signed-off-by: Jose Marinho
>>
>> CC: Heinrich Schuchardt
>> CC: Sughosh Ganu
>> CC: AKASHI Takahiro
>> CC: Ilias Apalodimas
>> CC: Andre Przywara
>> CC: Alexander Graf
>> CC: n...@arm.com
>>
>> ---
>> cmd/efidebug.c| 4 +
>> include/efi_api.h | 21 ++
>> include/efi_loader.h | 19 ++
>> lib/efi_loader/Kconfig| 7 +
>> lib/efi_loader/Makefile | 1 +
>> lib/efi_loader/efi_boottime.c | 2 -
>> lib/efi_loader/efi_capsule.c | 7 +
>> lib/efi_loader/efi_esrt.c | 439 ++
>> lib/efi_loader/efi_setup.c| 6 +
>> 9 files changed, 504 insertions(+), 2 deletions(-)
>> create mode 100644 lib/efi_loader/efi_esrt.c
>>
>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>> index 83bc2196a5..4160dde1cf 100644
>> --- a/cmd/efidebug.c
>> +++ b/cmd/efidebug.c
>> @@ -458,6 +458,10 @@ static const struct {
>> "Block IO",
>> EFI_BLOCK_IO_PROTOCOL_GUID,
>> },
>> +{
>> +"EFI System Resource Table",
>> +EFI_SYSTEM_RESOURCE_TABLE_GUID,
>> +},
>> {
>> "Simple File System",
>> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 48e48a6263..7eb15bd44c 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -1722,6 +1722,23 @@ struct efi_load_file_protocol {
>> void *buffer);
>> };
>>
>> +struct efi_system_resource_entry {
>> +efi_guid_t fw_class;
>> +uint32_t fw_type;
>> +uint32_t fw_version;
>> +uint32_t lowest_supported_fw_version;
>> +uint32_t capsule_flags;
>> +uint32_t last_attempt_version;
>> +uint32_t last_attempt_status;
>> +} __packed;
>> +
>> +struct efi_system_resource_table {
>> +uint32_t fw_resource_count;
>> +uint32_t fw_resource_count_max;
>> +uint64_t fw_resource_version;
>> +struct efi_system_resource_entry entries[];
>> +} __packed;
>> +
>> /* Boot manager load options */
>> #define LOAD_OPTION_ACTIVE 0x0001
>> #define LOAD_OPTION_FORCE_RECONNECT 0x0002
>> @@ -1740,6 +1757,10 @@ struct efi_load_file_protocol {
>> #define ESRT_FW_TYPE_DEVICEFIRMWARE 0x0002
>> #define ESRT_FW_TYPE_UEFIDRIVER 0x0003
>>
>> +#define EFI_SYSTEM_RESOURCE_TABLE_GUID\
>> +EFI_GUID(0xb122a263, 0x3661, 0x4f68,\
>> +0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80 )
>
> Please, run scripts/checkpatch.pl on your patches before submitting.
>
> ERROR: space prohibited before that close parenthesis ')'
>
>> +
>> /* Last Attempt Status Values */
>> #define LAST_ATTEMPT_STATUS_SUCCESS 0x
>> #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL 0x0001
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index f470bbd636..c85c540041 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -884,4 +884,23 @@ static inline efi_status_t efi_launch_capsules(void)
>>
>> #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
>>
>> +/*
>> + * Install the ESRT system table.
>> + *
>> + * @return status code
>> + */
>> +efi_status_t efi_esrt_register(void);
>> +
>> +/**
>> + * efi_esrt_add_from_fmp() - Populates a sequence of ESRT entries from the
>> FW
>> + * images in the FMP.
>> + *
>> + * @fmp:the fmp from which fw images are added to the ESRT
>> + *
>> + * Return:
>> + * - EFI_SUCCESS if all the FW images in the FMP are added to the ESRT
>> + * - Error status otherwise
>> + */
>> +efi_status_t efi_esrt_add_from_fmp(struct efi_firmware_management_protocol
>> *fmp);
>> +
>> #endif /* _EFI_LOADER_H */
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index e729f727df..12b29180a0 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -347,4 +347,11 @@ config EFI_SECURE_BOOT
>>it is signed with a trusted key. To do that, you need to install,
>>at least, PK, KEK and db.
>>
>> +config EFI_ESRT
>> +bool "Enable the UEFI ESRT generation"
>> +depends on EFI_LOADER
>
> This line is after "if EFI_LOADER".
>
> I assume EFI_ESRT should depend on CONFIG_EFI_HAVE_CAPSULE_SUPPORT.
>
>> +default y
>> +help
>> + Enabling this option creates the ESRT UEFI system table.
>> +
>> endif
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index 10b42e8847..dec791b310 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -52,6 +52,7 @@ obj-y += efi_variable.o
>> obj-$(CONFIG_EFI_VARIABLES
Re: [PATCH v10 02/11] efi_loader: capsule: add capsule_on_disk support
On 30.11.20 10:12, AKASHI Takahiro wrote:
> Capsule data can be loaded into the system either via UpdateCapsule
> runtime service or files on a file system (of boot device).
> The latter case is called "capsules on disk", and actual updates will
> take place at the next boot time.
>
> In this commit, we will support capsule on disk mechanism.
>
> Please note that U-Boot itself has no notion of "boot device" and
> all the capsule files to be executed will be detected only if they
> are located in a specific directory, \EFI\UpdateCapsule, on a device
> that is identified as a boot device by "Boot" variables.
>
> Signed-off-by: AKASHI Takahiro
> ---
> common/main.c| 4 +
> include/efi_loader.h | 9 +
> lib/efi_loader/Kconfig | 22 ++
> lib/efi_loader/efi_capsule.c | 498 +++
> lib/efi_loader/efi_setup.c | 8 +
> 5 files changed, 541 insertions(+)
>
> diff --git a/common/main.c b/common/main.c
> index 4b3cd302c3e2..ae5bcdb32f8b 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> static void run_preboot_environment_command(void)
> {
> @@ -53,6 +54,9 @@ void main_loop(void)
> if (IS_ENABLED(CONFIG_UPDATE_TFTP))
> update_tftp(0UL, NULL, NULL);
>
> + if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY))
> + efi_launch_capsules();
If my preboot command is
load mmc 0:1 $kernel_addr_r EFI/boot/grubaa64.efi &&
bootefi $kernel_addr_r
efi_lauch_capsule() will never be called.
Why do you call efi_launch_capsule after
run_preboot_environment_command() and update_tftp()?
efi_init_obj_list() is executed as last routine in board_init_r() just
before invoking run_main_loop().
Can't we simplify the coding by relying on calling efi_launch_capsule()
in efi_init_obj_list()?
Best regards
Heinrich
> +
> s = bootdelay_process();
> if (cli_process_fdt(&s))
> cli_secure_boot_cmd(s);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index d22f7a43ad09..eb57e7455eb1 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -820,6 +820,11 @@ efi_status_t EFIAPI efi_query_capsule_caps(
> u64 *maximum_capsule_size,
> u32 *reset_type);
>
> +#define EFI_CAPSULE_DIR L"\\EFI\\UpdateCapsule\\"
> +
> +/* Hook at initialization */
> +efi_status_t efi_launch_capsules(void);
> +
> #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
>
> /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
> @@ -836,6 +841,10 @@ static inline void efi_set_bootdev(const char *dev,
> const char *devnr,
> const char *path) { }
> static inline void efi_net_set_dhcp_ack(void *pkt, int len) { }
> static inline void efi_print_image_infos(void *pc) { }
> +static inline efi_status_t efi_launch_capsules(void)
> +{
> + return EFI_SUCCESS;
> +}
>
> #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 3ca396df3646..e1ac5ac055de 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -104,6 +104,28 @@ config EFI_RUNTIME_UPDATE_CAPSULE
> Select this option if you want to use UpdateCapsule and
> QueryCapsuleCapabilities API's.
>
> +config EFI_CAPSULE_ON_DISK
> + bool "Enable capsule-on-disk support"
> + select EFI_HAVE_CAPSULE_SUPPORT
> + default n
> + help
> + Select this option if you want to use capsule-on-disk feature,
> + that is, capsules can be fetched and executed from files
> + under a specific directory on UEFI system partition instead of
> + via UpdateCapsule API.
> +
> +config EFI_CAPSULE_ON_DISK_EARLY
> + bool "Initiate capsule-on-disk at U-Boot boottime"
> + depends on EFI_CAPSULE_ON_DISK
> + default n
> + select EFI_SETUP_EARLY
> + help
> + Normally, without this option enabled, capsules will be
> + executed only at the first time of invoking one of efi command.
> + If this option is enabled, capsules will be enforced to be
> + executed as part of U-Boot initialisation so that they will
> + surely take place whatever is set to distro_bootcmd.
> +
> config EFI_DEVICE_PATH_TO_TEXT
> bool "Device path to text protocol"
> default y
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 575fa75b0a2f..b3c7d1b735b6 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -11,10 +11,16 @@
> #include
> #include
> #include
> +#include
> #include
>
> const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
>
> +#ifdef CONFIG_EFI_CAPSULE_ON_DISK
> +/* for file system access */
> +static struct efi_file_handle *bootdev_root;
> +#endif
> +
> /**
> * get_last_capsule - get the last capsule index
> *
> @@ -163,3 +169,495 @@ efi_status_t EFIAPI efi_query_capsule_caps(
> out:
>
Re: [PATCH 1/2] efi: Add ESRT to the EFI system table
On 08.02.21 13:52, Jose Marinho wrote:
> The ESRT is initialised during efi_init_objlist after
> efi_initialize_system_table().
>
> The ESRT is initially created with size for 50 FW image entries.
> The ESRT is resized when it runs out of space. Every resize adds 50
> additional entries.
> The ESRT is populated from information provided by FMP instances only.
>
> Signed-off-by: Jose Marinho
>
> CC: Heinrich Schuchardt
> CC: Sughosh Ganu
> CC: AKASHI Takahiro
> CC: Ilias Apalodimas
> CC: Andre Przywara
> CC: Alexander Graf
> CC: n...@arm.com
>
> ---
> cmd/efidebug.c| 4 +
> include/efi_api.h | 21 ++
> include/efi_loader.h | 19 ++
> lib/efi_loader/Kconfig| 7 +
> lib/efi_loader/Makefile | 1 +
> lib/efi_loader/efi_boottime.c | 2 -
> lib/efi_loader/efi_capsule.c | 7 +
> lib/efi_loader/efi_esrt.c | 439 ++
> lib/efi_loader/efi_setup.c| 6 +
> 9 files changed, 504 insertions(+), 2 deletions(-)
> create mode 100644 lib/efi_loader/efi_esrt.c
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 83bc2196a5..4160dde1cf 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -458,6 +458,10 @@ static const struct {
> "Block IO",
> EFI_BLOCK_IO_PROTOCOL_GUID,
> },
> + {
> + "EFI System Resource Table",
> + EFI_SYSTEM_RESOURCE_TABLE_GUID,
> + },
> {
> "Simple File System",
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 48e48a6263..7eb15bd44c 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -1722,6 +1722,23 @@ struct efi_load_file_protocol {
>void *buffer);
> };
>
> +struct efi_system_resource_entry {
> + efi_guid_t fw_class;
> + uint32_t fw_type;
> + uint32_t fw_version;
> + uint32_t lowest_supported_fw_version;
> + uint32_t capsule_flags;
> + uint32_t last_attempt_version;
> + uint32_t last_attempt_status;
> +} __packed;
> +
> +struct efi_system_resource_table {
> + uint32_t fw_resource_count;
> + uint32_t fw_resource_count_max;
> + uint64_t fw_resource_version;
> + struct efi_system_resource_entry entries[];
> +} __packed;
> +
> /* Boot manager load options */
> #define LOAD_OPTION_ACTIVE 0x0001
> #define LOAD_OPTION_FORCE_RECONNECT 0x0002
> @@ -1740,6 +1757,10 @@ struct efi_load_file_protocol {
> #define ESRT_FW_TYPE_DEVICEFIRMWARE 0x0002
> #define ESRT_FW_TYPE_UEFIDRIVER 0x0003
>
> +#define EFI_SYSTEM_RESOURCE_TABLE_GUID\
> + EFI_GUID(0xb122a263, 0x3661, 0x4f68,\
> + 0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80 )
Please, run scripts/checkpatch.pl on your patches before submitting.
ERROR: space prohibited before that close parenthesis ')'
> +
> /* Last Attempt Status Values */
> #define LAST_ATTEMPT_STATUS_SUCCESS 0x
> #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL 0x0001
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f470bbd636..c85c540041 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -884,4 +884,23 @@ static inline efi_status_t efi_launch_capsules(void)
>
> #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
>
> +/*
> + * Install the ESRT system table.
> + *
> + * @return status code
> + */
> +efi_status_t efi_esrt_register(void);
> +
> +/**
> + * efi_esrt_add_from_fmp() - Populates a sequence of ESRT entries from the FW
> + * images in the FMP.
> + *
> + * @fmp:the fmp from which fw images are added to the ESRT
> + *
> + * Return:
> + * - EFI_SUCCESS if all the FW images in the FMP are added to the ESRT
> + * - Error status otherwise
> + */
> +efi_status_t efi_esrt_add_from_fmp(struct efi_firmware_management_protocol
> *fmp);
> +
> #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index e729f727df..12b29180a0 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -347,4 +347,11 @@ config EFI_SECURE_BOOT
> it is signed with a trusted key. To do that, you need to install,
> at least, PK, KEK and db.
>
> +config EFI_ESRT
> + bool "Enable the UEFI ESRT generation"
> + depends on EFI_LOADER
This line is after "if EFI_LOADER".
I assume EFI_ESRT should depend on CONFIG_EFI_HAVE_CAPSULE_SUPPORT.
> + default y
> + help
> + Enabling this option creates the ESRT UEFI system table.
> +
> endif
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 10b42e8847..dec791b310 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -52,6 +52,7 @@ obj-y += efi_variable.o
> obj-$(CONFIG_EFI_VARIABLES_PRESEED) += efi_var_seed.o
> endif
> obj-y += efi_watchdog.o
> +obj-y += efi_esrt.o
> obj-$(CONFIG_LCD) += efi_gop.o
> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>
Re: [PATCH] cmd: mmc: add mmc partboot
On 2/16/21 5:18 PM, gr embeter wrote:
> Hi Jaehoon,
> thanks for your comments.
>
> On Tue, 16 Feb 2021 at 00:30 Jaehoon Chung wrote:
>
>> Hi Grygorii,
>>
>> On 2/15/21 10:04 PM, gr embeter wrote:
>>> Hello Jaehoon,
>>>
>>> On Sun, 14 Feb 2021 at 23:08 Jaehoon Chung
>> wrote:
>>>
Dear Grygorii,
On 2/12/21 7:32 PM, grygorii tertychnyi wrote:
> This patch allows to determine active boot partition in boot script:
>
> if mmc partboot ${mmcdev} 2; then
> echo "booted from eMMC boot1 partition"
> fi
I don't know what purpose this patch has.
>>>
>>>
>>> With an eMMC as a boot source I have two boot partitions, i.e. “boot1”
>> and
>>> “boot2”, with two different versions of U-Boot on each partition.
>>>
>>> I also have two different kernels located on eMMC “user” partition, let’s
>>> say “image1” and “image2”.
>>>
>>> So, I want to boot “image1” kernel if it is U-boot from “boot1” partition
>>> is booted now,
>>> and to boot “image2” kernel if it is U-boot from “boot2” partition is
>>> booted.
>>>
>>> It is easy to do it manually. I just added possibility to do it with
>> U-boot
>>> script now,
>>> because “mmc partconf ...” does not let you check the current boot
>>> partition with hush.
>>>
>>> Hope, I explained the purpose.
>>
>> I remembered. Because i feel to see similar patch to use bootpart.
>> At that time, i also asked same question. Sorry for not remembered yours.
>>
>>
>> https://protect2.fireeye.com/v1/url?k=dac52f49-855e1643-dac4a406-0cc47a31384a-4f6e07c1e040623a&q=1&e=3829977a-6bc3-49e3-868a-0dcba5fab9e4&u=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20201212074633.891704-1-grembeter%40outlook.com%2F
>>
>
> Indeed. I should’ve mentioned this link. Sorry. I’ll extend commit message.
>
>
>>>
>>>
>>>
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Grygorii Tertychnyi <
grygorii.tertych...@leica-geosystems.com>
> ---
> cmd/mmc.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 1529a3e05ddd..010d6ab9aa19 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl
*cmdtp, int flag,
> return CMD_RET_SUCCESS;
> }
>
> +static int do_mmc_partboot(struct cmd_tbl *cmdtp, int flag,
> +int argc, char *const argv[])
> +{
> + int dev;
> + struct mmc *mmc;
> + u8 part_args, part_emmc;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + dev = simple_strtoul(argv[1], NULL, 10);
> +
> + mmc = init_mmc_device(dev, false);
> + if (!mmc)
> + return CMD_RET_FAILURE;
> +
> + if (IS_SD(mmc)) {
> + puts("PARTITION_CONFIG only exists on eMMC\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> + printf("No part_config info for ver. 0x%x\n",
mmc->version);
> + return CMD_RET_FAILURE;
> + }
> +
> + part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> + part_args = simple_strtoul(argv[2], NULL, 10);
> +
> + if (part_emmc == part_args)
> + return CMD_RET_SUCCESS;
> + else
> + return CMD_RET_FAILURE;
> +}
> +
> static int mmc_partconf_print(struct mmc *mmc)
> {
> u8 ack, access, part;
> @@ -953,6 +988,7 @@ static struct cmd_tbl cmd_mmc[] = {
> #ifdef CONFIG_SUPPORT_EMMC_BOOT
> U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "",
""),
> + U_BOOT_CMD_MKENT(partboot, 3, 0, do_mmc_partboot, "", ""),
>>
>> partboot can be confused. how about changing more clear name, like
>> mmc_bootpart_check?
>
>
> Agree. We have “bootpart-resize”, and “bootpart-check” looks very natural.
>
> I’ll prepare V2 for
> mmc bootpart-check
>
>
>>
> U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
> #endif
> @@ -1021,6 +1057,9 @@ U_BOOT_CMD(
> " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> "mmc bootpart-resize >>> MB>\n"
> " - Change sizes of boot and RPMB partitions of specified
>> device\n"
> + "mmc partboot dev boot_partition\n"
>>
>> why it needs to pass "boot_partition"?
>
>
> We need to return true or false to be able to use “if” in boot script
> (hush).
> Comparing the real value with the given one is the only way to return true
> or false. So, this argument is mandatory.
How about setting environment variable in checking command? With optional
arguments.
e,g) mmc partconf-check [varname] ?
-
Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it
Hi Pali, > On Monday 08 February 2021 23:34:06 Pali Rohár wrote: > > On Monday 08 February 2021 23:21:38 Pali Rohár wrote: > > > On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote: > > > > Hi Pali, > > > > > > > > > Resended v2 patch series with fixed commit messages > > > > > > > > > > This patch series fix usbtty code (serial console via USB > > > > > peripheral mode), fix underlying musb peripheral code, fix > > > > > compilation of CONFIG_USB_DEVICE (used by usbtty), remove > > > > > unused Nokia RX-51 code to decrease size of U-Boot binary and > > > > > finally enable usbtty serial console for Nokia RX-51. > > > > > > > > > > With this patch series debugging of Nokia RX-51 can be done > > > > > also via USB serial console. > > > > > > > > > > It fixes also stability of musb code and allows usage of file > > > > > transfers via Kermit protocol on Nokia RX-51. Kermit file > > > > > transfer via U-Boot loadb command is stable on Nokia N900 and > > > > > gives about 52kB/s transfer rate. > > > > > > > > > > On computer this serial console is accessible via > > > > > /dev/ttyACM0 device. > > > > > > > > I've integrated your patchset and now it turns out that the > > > > u-boot size is too big: > > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24&view=results > > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24&view=logs&j=9a06d2a9-1498-5de0-2a01-be581d48ba67&t=f9a6b761-daa3-500f-4840-65a939c5040d > > > > > > > > > > Ah :-( > > > In November when I sent these patches, U-Boot binary was smaller. > > > > > > > The branch is > > > > https://github.com/lmajewski/u-boot-dfu/tree/testing > > > > > > > > Have you experienced similar issues? > > > > > > Yes, memory for U-Boot is limited. It is needed to decrease size > > > of U-Boot binary and then it will work. > > > > > > I will try to look at it later and find some dead code which can > > > be commented or removed to decrease binary size... > > > > Just a quick test, could you try to add > > > > CONFIG_OPTIMIZE_INLINING=y > > > > into configs/nokia_rx51_defconfig file, if it helps? > > Lukasz, is CONFIG_OPTIMIZE_INLINING=y option fixing build for you? Could you setup the CI environment and test your patchset with it? It is documented in .azure-pipelines.yml. Azure build takes not more than 3h for the whole test setup. > > > > If you have an idea what increased U-Boot side it could help. > > > > > > > > Pali Rohár (16): > > > > > serial: usbtty: Fix puts function > > > > > serial: usbtty: Send urb data in correct order > > > > > usb: musb: Fix compilation of gadget code > > > > > usb: musb: Always clear the data toggle bit when > > > > > configuring ep usb: musb: Fix configuring FIFO for endpoints > > > > > usb: musb: Read value of PERI_RXCSR to 16bit variable > > > > > usb: musb: Fix transmission of bigger buffers > > > > > usb: musb: Fix receiving of bigger buffers > > > > > usb: musb: Fix handling interrupts for EP0 and SET ADDRESS > > > > > commmand usb: musb: Ensure that we set musb dynamic FIFO > > > > > buffer for every endpoint > > > > > usb: gadget: Use dbg_ep0() macro instead of serial_printf() > > > > > arm: omap3: Compile lowlevel_init() function only when it > > > > > is used arm: omap3: Compile s_init() function only when it is > > > > > used Nokia RX-51: Remove function set_muxconf_regs() > > > > > Nokia RX-51: Move content of rx51.h to rx51.c > > > > > Nokia RX-51: Enable usbtty serial console by default > > > > > > > > > > Makefile | 1 + > > > > > arch/arm/mach-omap2/omap3/board.c | 3 + > > > > > arch/arm/mach-omap2/omap3/lowlevel_init.S | 6 +- > > > > > board/nokia/rx51/rx51.c | 28 +- > > > > > board/nokia/rx51/rx51.h | 377 > > > > > -- configs/nokia_rx51_defconfig > > > > >| 7 +- doc/README.nokia_rx51 | 15 +- > > > > > drivers/serial/usbtty.c | 16 +- > > > > > drivers/usb/gadget/ep0.c | 16 +- > > > > > drivers/usb/musb/musb_core.c | 12 +- > > > > > drivers/usb/musb/musb_udc.c | 61 ++-- > > > > > include/configs/nokia_rx51.h | 21 +- > > > > > 12 files changed, 82 insertions(+), 481 deletions(-) > > > > > delete mode 100644 board/nokia/rx51/rx51.h > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Lukasz Majewski > > > > > > > > -- > > > > > > > > DENX Software Engineering GmbH, Managing Director: > > > > Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 > > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: > > > > (+49)-8142-66989-80 Email: lu...@denx.de > > > > > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phon
Re: [PATCH] cmd: mmc: add mmc partboot
Hi Jaehoon,
thanks for your comments.
On Tue, 16 Feb 2021 at 00:30 Jaehoon Chung wrote:
> Hi Grygorii,
>
> On 2/15/21 10:04 PM, gr embeter wrote:
> > Hello Jaehoon,
> >
> > On Sun, 14 Feb 2021 at 23:08 Jaehoon Chung
> wrote:
> >
> >> Dear Grygorii,
> >>
> >> On 2/12/21 7:32 PM, grygorii tertychnyi wrote:
> >>> This patch allows to determine active boot partition in boot script:
> >>>
> >>> if mmc partboot ${mmcdev} 2; then
> >>> echo "booted from eMMC boot1 partition"
> >>> fi
> >>
> >> I don't know what purpose this patch has.
> >
> >
> > With an eMMC as a boot source I have two boot partitions, i.e. “boot1”
> and
> > “boot2”, with two different versions of U-Boot on each partition.
> >
> > I also have two different kernels located on eMMC “user” partition, let’s
> > say “image1” and “image2”.
> >
> > So, I want to boot “image1” kernel if it is U-boot from “boot1” partition
> > is booted now,
> > and to boot “image2” kernel if it is U-boot from “boot2” partition is
> > booted.
> >
> > It is easy to do it manually. I just added possibility to do it with
> U-boot
> > script now,
> > because “mmc partconf ...” does not let you check the current boot
> > partition with hush.
> >
> > Hope, I explained the purpose.
>
> I remembered. Because i feel to see similar patch to use bootpart.
> At that time, i also asked same question. Sorry for not remembered yours.
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20201212074633.891704-1-grembe...@outlook.com/
>
Indeed. I should’ve mentioned this link. Sorry. I’ll extend commit message.
> >
> >
> >
> >>
> >> Best Regards,
> >> Jaehoon Chung
> >>
> >>>
> >>> Signed-off-by: Grygorii Tertychnyi <
> >> grygorii.tertych...@leica-geosystems.com>
> >>> ---
> >>> cmd/mmc.c | 39 +++
> >>> 1 file changed, 39 insertions(+)
> >>>
> >>> diff --git a/cmd/mmc.c b/cmd/mmc.c
> >>> index 1529a3e05ddd..010d6ab9aa19 100644
> >>> --- a/cmd/mmc.c
> >>> +++ b/cmd/mmc.c
> >>> @@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl
> >> *cmdtp, int flag,
> >>> return CMD_RET_SUCCESS;
> >>> }
> >>>
> >>> +static int do_mmc_partboot(struct cmd_tbl *cmdtp, int flag,
> >>> +int argc, char *const argv[])
> >>> +{
> >>> + int dev;
> >>> + struct mmc *mmc;
> >>> + u8 part_args, part_emmc;
> >>> +
> >>> + if (argc != 3)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + dev = simple_strtoul(argv[1], NULL, 10);
> >>> +
> >>> + mmc = init_mmc_device(dev, false);
> >>> + if (!mmc)
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + if (IS_SD(mmc)) {
> >>> + puts("PARTITION_CONFIG only exists on eMMC\n");
> >>> + return CMD_RET_FAILURE;
> >>> + }
> >>> +
> >>> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> >>> + printf("No part_config info for ver. 0x%x\n",
> >> mmc->version);
> >>> + return CMD_RET_FAILURE;
> >>> + }
> >>> +
> >>> + part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> >>> + part_args = simple_strtoul(argv[2], NULL, 10);
> >>> +
> >>> + if (part_emmc == part_args)
> >>> + return CMD_RET_SUCCESS;
> >>> + else
> >>> + return CMD_RET_FAILURE;
> >>> +}
> >>> +
> >>> static int mmc_partconf_print(struct mmc *mmc)
> >>> {
> >>> u8 ack, access, part;
> >>> @@ -953,6 +988,7 @@ static struct cmd_tbl cmd_mmc[] = {
> >>> #ifdef CONFIG_SUPPORT_EMMC_BOOT
> >>> U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> >>> U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "",
> >> ""),
> >>> + U_BOOT_CMD_MKENT(partboot, 3, 0, do_mmc_partboot, "", ""),
>
> partboot can be confused. how about changing more clear name, like
> mmc_bootpart_check?
Agree. We have “bootpart-resize”, and “bootpart-check” looks very natural.
I’ll prepare V2 for
mmc bootpart-check
>
> >>> U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> >>> U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
> >>> #endif
> >>> @@ -1021,6 +1057,9 @@ U_BOOT_CMD(
> >>> " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> >>> "mmc bootpart-resize>> MB>\n"
> >>> " - Change sizes of boot and RPMB partitions of specified
> device\n"
> >>> + "mmc partboot dev boot_partition\n"
>
> why it needs to pass "boot_partition"?
We need to return true or false to be able to use “if” in boot script
(hush).
Comparing the real value with the given one is the only way to return true
or false. So, this argument is mandatory.
> And use more clear usage..with optional or mandatory.
> <> - mandatory
> [] - optional
OK.
>
> mmc partboot
>
> >>> + " - Return success if the given boot_partition value matches
> >> BOOT_PARTITION_ENABLE\n"
> >>> + " bit field of the specified device\n"
> >>> "mmc partconf dev [boot_ack boot_partition partition_access]\n"
> >>> " - Show or change the
