Re: [RESEND RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
Hi Etienne,
[...]
> > > > +
> > > > + /* And now the replica */
> > > > + ret = gpt_write_metadata_partition(desc, metadata,
> > > secondary_mpart);
> > > > + if (ret < 0) {
> > > > + log_err("Updating secondary metadata partition failed\n");
> > > > + return ret;
> > > > + }
> > >
> > > So shouldn't we do something about this case? The first partition was
> > > correctly written and the second failed. Now if the primary GPT somehow
> > > gets corrupted the device is now unusable.
>
> The replica is not there to overcome bitflips of the storage media.
> It's here to allow updates while reliable info a still available in
> the counter part.
Sure but with this piece of code this assumption is broken. At the
point the secondary partition fails to write, you loose that
reliability. When the next update happens you are left with one valid
and one invalid partition of metadata.
> The scheme could be to rely on only 1 instance of the fwu-metadata
> (sorry Simon) image is valid.
> A first load: load 1st instance, crap the second.
> At update: find the crapped one: write it with new data. Upon success
> crapped the alternate one.
> This is a suggestion. There are many ways to handle that.
We could change to something like that, however this is not what's
currently happening. gpt_check_metadata_validity() is trying to check
and make sure both of the partitions are sane. If they aren't it
tries to recover those looking at a sane partition. So the question
for really is, should we do something *here* or rely on the fact that
the next update will try to fix the broken metadata.
Cheers
/Ilias
Re: [PATCH v1 1/1] support rsa3072
The 12/08/2021 14:48, Tom Rini wrote:
> On Wed, Dec 08, 2021 at 06:36:21PM +0800, Jamin Lin wrote:
>
> > This patch set support rsa3072.
> >
> > Signed-off-by: Jamin Lin
> > ---
> > common/image-sig.c | 7 +++
> > include/u-boot/rsa.h | 1 +
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/common/image-sig.c b/common/image-sig.c
> > index e4bbac55c1..c94854ef8b 100644
> > --- a/common/image-sig.c
> > +++ b/common/image-sig.c
> > @@ -85,6 +85,13 @@ struct crypto_algo crypto_algos[] = {
> > .add_verify_data = rsa_add_verify_data,
> > .verify = rsa_verify,
> > },
> > + {
> > + .name = "rsa3072",
> > + .key_len = RSA3072_BYTES,
> > + .sign = rsa_sign,
> > + .add_verify_data = rsa_add_verify_data,
> > + .verify = rsa_verify,
> > + },
> > {
> > .name = "rsa4096",
> > .key_len = RSA4096_BYTES,
> > diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
> > index 2d3024d8b7..d561e5f8ca 100644
> > --- a/include/u-boot/rsa.h
> > +++ b/include/u-boot/rsa.h
> > @@ -135,6 +135,7 @@ static inline int padding_pss_verify(struct
> > image_sign_info *info,
> > #define RSA_DEFAULT_PADDING_NAME "pkcs-1.5"
> >
> > #define RSA2048_BYTES (2048 / 8)
> > +#define RSA3072_BYTES (3072 / 8)
> > #define RSA4096_BYTES (4096 / 8)
> >
> > /* This is the minimum/maximum key size we support, in bits */
>
> For both of these patches, please expand the commit message and header
> so it's clear where you're adding the support to. Perhaps they should
> be squashed in to a single patch as the tooling needs to support it when
> the binary also supports it?
>
> --
> Tom
Hi Tom
Thanks for your review.
I sent v2 patch and waiting for your review.
Thanks
[PATCH v2] rsa: adds rsa3072 algorithm
Add to support rsa 30272 bits algorithm in tools
for image sign at host side and adds rsa 3027 bits
verification in the image binary.
Signed-off-by: Jamin Lin
wq
---
include/u-boot/rsa.h | 1 +
lib/rsa/rsa-verify.c | 6 ++
tools/image-sig-host.c | 7 +++
3 files changed, 14 insertions(+)
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index 7556aa5b4b..bb56c2243c 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -110,6 +110,7 @@ int padding_pss_verify(struct image_sign_info *info,
#define RSA_DEFAULT_PADDING_NAME "pkcs-1.5"
#define RSA2048_BYTES (2048 / 8)
+#define RSA3072_BYTES (3072 / 8)
#define RSA4096_BYTES (4096 / 8)
/* This is the minimum/maximum key size we support, in bits */
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 83f7564101..4fe487d7e5 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -588,6 +588,12 @@ U_BOOT_CRYPTO_ALGO(rsa2048) = {
.verify = rsa_verify,
};
+U_BOOT_CRYPTO_ALGO(rsa3072) = {
+ .name = "rsa3072",
+ .key_len = RSA3072_BYTES,
+ .verify = rsa_verify,
+};
+
U_BOOT_CRYPTO_ALGO(rsa4096) = {
.name = "rsa4096",
.key_len = RSA4096_BYTES,
diff --git a/tools/image-sig-host.c b/tools/image-sig-host.c
index 8ed6998dab..d0133aec4c 100644
--- a/tools/image-sig-host.c
+++ b/tools/image-sig-host.c
@@ -55,6 +55,13 @@ struct crypto_algo crypto_algos[] = {
.add_verify_data = rsa_add_verify_data,
.verify = rsa_verify,
},
+ {
+ .name = "rsa3072",
+ .key_len = RSA3072_BYTES,
+ .sign = rsa_sign,
+ .add_verify_data = rsa_add_verify_data,
+ .verify = rsa_verify,
+ },
{
.name = "rsa4096",
.key_len = RSA4096_BYTES,
--
2.17.1
[PATCH v2 0/1] rsa: adds rsa3072 algorithm
Add to support rsa 30272 bits algorithm in tools for make-image signing at host side and add rsa 3027 bits verification in the image binary. v2: - update to send a single patch *** BLURB HERE *** Jamin Lin (1): rsa: adds rsa3072 algorithm include/u-boot/rsa.h | 1 + lib/rsa/rsa-verify.c | 6 ++ tools/image-sig-host.c | 7 +++ 3 files changed, 14 insertions(+) -- 2.17.1
Re: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
On Wed, Dec 8, 2021 at 9:13 PM Andre Przywara wrote:
>
> On Wed, 8 Dec 2021 20:48:54 +0330
> Javad Rahimi wrote:
>
> > On Wed, Dec 8, 2021 at 8:33 PM Andre Przywara
> > wrote:
> > >
> > > On Wed, 8 Dec 2021 19:14:22 +0330
> > > Javad Rahimi wrote:
> > >
> > > > On Wed, Dec 8, 2021 at 6:05 PM Andre Przywara
> > > > wrote:
> > > > >
> > > > > On Wed, 8 Dec 2021 15:25:54 +0100
> > > > > Frank Wunderlich wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > you should add maintainer email for your patch
> > > > > >
> > > > > > $ scripts/get_maintainer.pl board/sunxi/board.c
> > > > > > Jagan Teki (maintainer:ARM SUNXI)
> > > > > > Andre Przywara (maintainer:ARM SUNXI)
> > > > > > u-boot@lists.denx.de (open list)
> > > > >
> > > > > Thanks Frank!
> > > > >
> > > > > > > Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> > > > > > > Von: "Javad Rahimi"
> > > > > > > An: u-boot@lists.denx.de
> > > > > > > Cc: "Javad Rahimi"
> > > > > > > Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
> > > > > > >
> > > > > > > This feature makes it possible to assign one of
> > > > > > > LED1(PH20) and LED2(PH21) to BOOT process LED.
> > > > > > > User should activates the "Enable status LED API" in
> > > > > > > "Device Drivers -> LED Support"
> > > > >
> > > > > Please have a look at the current pinephone_defconfig, because that
> > > > > uses
> > > > > the boot LED already in a much easier fashion:
> > > > > https://source.denx.de/u-boot/u-boot/-/commit/0534153fd1
> > > > >
> > > > > Cheers,
> > > > > Andre
> > > > >
> > > > Hi Andre,
> > > > Thanks for your comments. I studied the pinephone_defconfig.
> > > > By default, when activating the same options on Cubieboard2_defconfig
> > > > it shows linker error for `__led_init` and `__led_set`.
> > > > In other words, they are not defined. So, in this patch, I added the
> > > > implementation for these functions for this board.
> > >
> > > Did you add the:
> > > CONFIG_SPL_DRIVERS_MISC=y
> > > line as well? And re-ran make Cubieboard2_defconfig?
> > > Because that seemed to work for me.
> > >
> > > Cheers,
> > > Andre
> > >
> > >
> > When I add CONFIG_SPL_DRIVERS_MISC=y
> > By flashing SD card and turning on the board, It freezes in this step:
> > ```
> > U-Boot SPL 2022.01-rc3-00025-gf570594bc9-dirty (Dec 08 2021 - 20:36:51
> > +0330)
> > ```
> > -
> > The customized defconfig file for Cubieboard:
> > ```
> > CONFIG_ARM=y
> > CONFIG_ARCH_SUNXI=y
> > CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-cubieboard2"
> > CONFIG_SPL_DRIVERS_MISC=y
> > CONFIG_SPL=y
> > CONFIG_MACH_SUN7I=y
> > CONFIG_DRAM_CLK=480
> > CONFIG_MMC0_CD_PIN="PH1"
> > CONFIG_SATAPWR="PB8"
> > CONFIG_AHCI=y
> > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > CONFIG_SPL_I2C=y
> > CONFIG_SCSI_AHCI=y
> > CONFIG_SYS_I2C_MVTWSI=y
> > CONFIG_SYS_I2C_SLAVE=0x7f
> > CONFIG_SYS_I2C_SPEED=40
> > CONFIG_PHY_REALTEK=y
> > CONFIG_ETH_DESIGNWARE=y
> > CONFIG_MII=y
> > CONFIG_SUN7I_GMAC=y
> > CONFIG_SCSI=y
> > CONFIG_USB_EHCI_HCD=y
> > CONFIG_USB_OHCI_HCD=y
> > CONFIG_LED_STATUS=y
> > CONFIG_LED_STATUS_GPIO=y
> > CONFIG_LED_STATUS0=y
> > CONFIG_LED_STATUS_BIT=114
>
> This is the GPIO number, you need to adjust this to point to the pin your
> LED is connected to. PH20 would be 244, for instance:
> ('H' - 'A') * 32 + 20
>
> Cheers,
> Andre
>
Thanks,
Now the LED is ON, but the loader still freezes in (SPL, I think)
```
U-Boot SPL 2022.01-rc3-00025-gf570594bc9-dirty (Dec 09 2021 - 06:19:40 +0330)
```
Best Regards,
Javad
> > CONFIG_LED_STATUS_STATE=2
> > ```
> > Best Regards,
> > Javad
> > > > > > >
> > > > > > > Signed-off-by: Javad Rahimi
> > > > > > > ---
> > > > > > > This is my first contributation in open source world.
> > > > > > > I'm sorry if I have mistakes in my commits and versioning.
> > > > > > > I do my best to learn fast.
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Missed braces added
> > > > > > > - Unnecessary debug removed
> > > > > > > - Some typo fixed
> > > > > > >
> > > > > > > board/sunxi/board.c | 49
> > > > > > > +
> > > > > > > 1 file changed, 49 insertions(+)
> > > > > > >
> > > > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > > > > > index 4f5747c34a..5e2f6ae902 100644
> > > > > > > --- a/board/sunxi/board.c
> > > > > > > +++ b/board/sunxi/board.c
> > > > > > > @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char
> > > > > > > *name)
> > > > > > > return ret;
> > > > > > > }
> > > > > > > #endif
> > > > > > > +
> > > > > > > +#if defined(CONFIG_LED_STATUS) &&
> > > > > > > defined(CONFIG_LED_STATUS_BOOT) &&
> > > > > > > defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> > > > > > > +
> > > > > > > +#define CUBIE2_LED_BOOT_GPIO "PH20"
> > > > > > > +static int gpio_boot_led;
> > > > > > > +
> > > > > > > +void __led_init(led_id_t mask, int state)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + if (mask != CONFIG_LE
[PATCH] dm: fix an 'undefined' error in some macros
Due to a non-existing parameter name in macro's, use of those macro's will
cause a compiler error of "undefined reference".
Unfortunately, dm test doesn't fail because a wrong name ("&dev", hence it
is accidentally a valid name in the context of a caller site) is passed on.
Signed-off-by: AKASHI Takahiro
Fixes: f262d4ca4b2b ("dm: core: Add a way to read platdata for all
child devices")
Fixes: 903e83ee8464 ("dm: core: Add a way to iterate through children,
probing each")
---
include/dm/device.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/dm/device.h b/include/dm/device.h
index 3028d002ab0d..f7900417066d 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -959,8 +959,8 @@ static inline bool device_is_on_pci_bus(const struct
udevice *dev)
* @parent: parent device to scan
*/
#define device_foreach_child_of_to_plat(pos, parent) \
- for (int _ret = device_first_child_ofdata_err(parent, &dev); !_ret; \
-_ret = device_next_child_ofdata_err(&dev))
+ for (int _ret = device_first_child_ofdata_err(parent, &pos); !_ret; \
+_ret = device_next_child_ofdata_err(&pos))
/**
* device_foreach_child_probe() - iterate through children, probing them
@@ -976,8 +976,8 @@ static inline bool device_is_on_pci_bus(const struct
udevice *dev)
* @parent: parent device to scan
*/
#define device_foreach_child_probe(pos, parent)\
- for (int _ret = device_first_child_err(parent, &dev); !_ret; \
-_ret = device_next_child_err(&dev))
+ for (int _ret = device_first_child_err(parent, &pos); !_ret; \
+_ret = device_next_child_err(&pos))
/**
* dm_scan_fdt_dev() - Bind child device in the device tree
--
2.33.0
Re: [RESEND RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
Hi Etienne,
On Wed, 8 Dec 2021 at 07:18, Etienne Carriere
wrote:
>
> Hi Sughosh, Ilias (and all),
>
> On Thu, 2 Dec 2021 at 08:43, Sughosh Ganu wrote:
> >
> > hi Ilias,
> >
> > On Wed, 1 Dec 2021 at 17:56, Ilias Apalodimas
> > wrote:
> >
> > > Hi Sughosh,
> > >
> > > On Thu, Nov 25, 2021 at 12:42:56PM +0530, Sughosh Ganu wrote:
> > > > In the FWU Multi Bank Update feature, the information about the
> > > > updatable images is stored as part of the metadata, on a separate
> > > > partition. Add functions for reading from and writing to the metadata
> > > > when the updatable images and the metadata are stored on a block
> > > > device which is formated with GPT based partition scheme.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > lib/fwu_updates/fwu_metadata_gpt_blk.c | 716 +
> > > > 1 file changed, 716 insertions(+)
> > > > create mode 100644 lib/fwu_updates/fwu_metadata_gpt_blk.c
> > > >
> > > > +#define SECONDARY_VALID 0x2
> > >
> > >
> > > Change those to BIT(0), BIT(1) etc please
> > >
> >
> > Will change.
> >
> >
> > >
> > > > +
> > > > +#define MDATA_READ (u8)0x1
> > > > +#define MDATA_WRITE (u8)0x2
> > > > +
> > > > +#define IMAGE_ACCEPT_SET (u8)0x1
> > > > +#define IMAGE_ACCEPT_CLEAR (u8)0x2
> > > > +
> > > > +static int gpt_verify_metadata(struct fwu_metadata *metadata, bool
> > > pri_part)
> > > > +{
> > > > + u32 calc_crc32;
> > > > + void *buf;
> > > > +
> > > > + buf = &metadata->version;
> > > > + calc_crc32 = crc32(0, buf, sizeof(*metadata) - sizeof(u32));
> > > > +
> > > > + if (calc_crc32 != metadata->crc32) {
> > > > + log_err("crc32 check failed for %s metadata partition\n",
> > > > + pri_part ? "primary" : "secondary");
> > >
> > > I think we can rid of the 'bool pri_part'. It's only used for printing
> > > and
> > > you can have more that 2 partitions anyway right?
> > >
> >
> > We will have only two partitions for the metadata. But i think looking at
> > it now, it is a bit fuzzy on which is the primary metadata partition and
> > which is the secondary one. Can we instead print the UniquePartitionGUID of
> > the metadata partition instead. That will help in identifying for which
> > metadata copy the verification failed. Let me know your thoughts on this.
> >
> >
> > > > + return -1;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int gpt_get_metadata_partitions(struct blk_desc *desc,
> > >
> > >
> > > Please add a function descriptions (on following functions as well)
> > >
> >
> > I have added the function descriptions in the fwu_metadata.c, where the
> > api's are being defined. Do we need to add the descriptions for the
> > functions in this file as well?
> >
> >
> > >
> > > > +u32 *primary_mpart,
> > > > +u32 *secondary_mpart)
> > >
> > > u16 maybe? This is the number of gpt partitions with metadata right?
> >
> >
> > Okay.
> >
> >
> > >
> > >
> > > > +{
> > > > + int i, ret;
> > > > + u32 nparts, mparts;
>
> I think the 2 variables labels are too similar, it's a source of confusion.
> One is a number of entries, the second is a counter. It would be nice
> it's a bit more explicit.
>
> > > > + gpt_entry *gpt_pte = NULL;
> > > > + const efi_guid_t fwu_metadata_guid = FWU_METADATA_GUID;
> > > > +
> > > > + ALLOC_CACHE_ALIGN_BUFFER_PAD(gpt_header, gpt_head, 1,
> > > > + desc->blksz);
> > > > +
> > > > + ret = get_gpt_hdr_parts(desc, gpt_head, &gpt_pte);
> > > > + if (ret < 0) {
> > > > + log_err("Error getting GPT header and partitions\n");
> > > > + ret = -EIO;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + nparts = gpt_head->num_partition_entries;
> > > > + for (i = 0, mparts = 0; i < nparts; i++) {
> > > > + if (!guidcmp(&fwu_metadata_guid,
> > > > + &gpt_pte[i].partition_type_guid)) {
> > > > + ++mparts;
> > > > + if (!*primary_mpart)
> > > > + *primary_mpart = i + 1;
> > > > + else
> > > > + *secondary_mpart = i + 1;
> > > > + }
> > > > + }
> > > > +
> > > > + if (mparts != 2) {
> > > > + log_err("Expect two copies of the metadata instead of
> > > %d\n",
> > > > + mparts);
> > > > + ret = -EINVAL;
> > > > + } else {
> > > > + ret = 0;
> > > > + }
> > > > +out:
> > > > + free(gpt_pte);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int gpt_get_metadata_disk_part(struct blk_desc *desc,
> > > > + struct disk_partition *info,
> > > > + u32 part_num)
> > > > +{
> > > > + int ret
Re: [RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
Hi Sughosh, On Thu, 25 Nov 2021 at 00:03, Sughosh Ganu wrote: > > In the FWU Multi Bank Update feature, the information about the > updatable images is stored as part of the metadata, on a separate > partition. Add functions for reading from and writing to the metadata > when the updatable images and the metadata are stored on a block > device which is formated with GPT based partition scheme. > > Signed-off-by: Sughosh Ganu > --- > lib/fwu_updates/fwu_metadata_gpt_blk.c | 716 + > 1 file changed, 716 insertions(+) > create mode 100644 lib/fwu_updates/fwu_metadata_gpt_blk.c Given that you use mdata in some places, could you use it everywhere (identifiers and filenames)? I think mdata is a much better name than the generic word 'metadata'. Regards, Simon
Re: [PATCH 1/4] rockchip: gru: Set up SoC IO domain registers
Hi Alper, On Tue, 7 Dec 2021 at 13:31, Alper Nebi Yasak wrote: > > On 03/12/2021 06:31, Simon Glass wrote: > > On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak > > wrote: > >> The RK3399 SoC needs to know the voltage value provided by some > >> regulators, which is done by setting relevant register bits. Configure > >> these the way other RK3399 boards do, but with values set in coreboot. > > > > What do you mean by values set in coreboot? We don't need that to run > > here, do we? > > I meant that I wasn't blindly copying from other boards which have the > same block (e.g. Pinebook Pro), but was using known-good values for Gru > boards that coreboot also uses [1]. > > I tested again and it looks like my Kevin works just as good without > this patch, so I'll drop it. Well I have no objection to the patch. I'd suggest saying 'but with the same values as asre set in the equivalent code in coreboot'. Regards, Simon > [1] > https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/google/gru/bootblock.c#19 > > >> Signed-off-by: Alper Nebi Yasak > >> --- > >> There is a driver for this on Rockchip's repo, I managed to forward-port > >> it and get it working. If that's more desirable than doing it per-board > >> like this I can send that upstream (but I'd prefer to do it after this). > >> > >> board/google/gru/gru.c | 54 ++ > >> 1 file changed, 54 insertions(+)
[next 5/5] clk: ast2600: Revise MII interface delay
The clock delay of the RMII/RGMII interface is controlled by SCU340~35C. These values are obtained by measurement and experiments so we simply use macro to define them. Signed-off-by: Dylan Hung --- drivers/clk/aspeed/clk_ast2600.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c index 3a92739f5cf5..6441fcbbbd4c 100644 --- a/drivers/clk/aspeed/clk_ast2600.c +++ b/drivers/clk/aspeed/clk_ast2600.c @@ -19,11 +19,11 @@ DECLARE_GLOBAL_DATA_PTR; #define CLKIN_25M 2500UL /* MAC Clock Delay settings */ -#define MAC12_DEF_DELAY_1G 0x0041b75d -#define MAC12_DEF_DELAY_100M 0x00417410 -#define MAC12_DEF_DELAY_10M0x00417410 -#define MAC34_DEF_DELAY_1G 0x0010438a -#define MAC34_DEF_DELAY_100M 0x00104208 +#define MAC12_DEF_DELAY_1G 0x0028a410 +#define MAC12_DEF_DELAY_100M 0x00410410 +#define MAC12_DEF_DELAY_10M0x00410410 +#define MAC34_DEF_DELAY_1G 0x00104208 +#define MAC34_DEF_DELAY_100M 0x00104208 #define MAC34_DEF_DELAY_10M0x00104208 /* -- 2.25.1
[next 3/5] ARM: dts: ast2600: Add MDIO devices
There are 4 MDIO bus controllers in AST2600 SOC. Each of them can
connect to one or more PHY chips and is flexible to work with the 4 MAC
devices in AST2600. On AST2600 EVB, MDIO 0,1,2,3 connect to the PHY
chips used by MAC 0,1,2,3 respectively.
Signed-off-by: Dylan Hung
---
arch/arm/dts/ast2600-evb.dts | 68
arch/arm/dts/ast2600.dtsi| 46 +---
2 files changed, 109 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
index 2abd31341c11..4e256d1e2b4e 100644
--- a/arch/arm/dts/ast2600-evb.dts
+++ b/arch/arm/dts/ast2600-evb.dts
@@ -163,6 +163,74 @@
pinctrl-0 = <&pinctrl_i2c9_default>;
};
+&mdio0 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&mdio1 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy1: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&mdio2 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy2: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&mdio3 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy3: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&mac0 {
+ status = "okay";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <ðphy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1_default>;
+};
+
+&mac1 {
+ status = "okay";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <ðphy1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii2_default>;
+};
+
+&mac2 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <ðphy2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii3_default>;
+};
+
+&mac3 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <ðphy3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii4_default>;
+};
+
&scu {
mac0-clk-delay = <0x1d 0x1c
0x10 0x17
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index f121f547e6d4..bdcca69e060d 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -193,11 +193,47 @@
interrupts = ;
};
- mdio: ethernet@1e65 {
- compatible = "aspeed,aspeed-mdio";
- reg = <0x1e65 0x40>;
- resets = <&rst ASPEED_RESET_MII>;
- status = "disabled";
+ mdio: bus@1e65 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1e65 0x100>;
+
+ mdio0: mdio@0 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0 0x8>;
+ resets = <&rst ASPEED_RESET_MII>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mdio1_default>;
+ status = "disabled";
+ };
+
+ mdio1: mdio@8 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x8 0x8>;
+ resets = <&rst ASPEED_RESET_MII>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mdio2_default>;
+ status = "disabled";
+ };
+
+ mdio2: mdio@10 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x10 0x8>;
+ resets = <&rst ASPEED_RESET_MII>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mdio3_default>;
+ status = "disabled";
+ };
+
+ mdio3: mdio@18 {
+ compatible = "aspeed,ast2600-mdio";
+ reg = <0x18 0x8>;
+ resets = <&rst ASPEED_RESET_MII>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mdio4_default>;
+ status = "disabled";
+ };
};
mac0: ftgmac@1e66 {
--
2.25.1
[next 4/5] configs: ast2600: enable DM_MDIO and MDIO driver
Enable DM_MDIO and Aspeed MDIO driver for AST2600 EVB. Signed-off-by: Dylan Hung --- configs/evb-ast2600_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig index 5f00d6a944a6..21af905a047a 100644 --- a/configs/evb-ast2600_defconfig +++ b/configs/evb-ast2600_defconfig @@ -54,7 +54,9 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ASPEED=y CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_FTGMAC100=y +CONFIG_ASPEED_MDIO=y CONFIG_PHY=y CONFIG_PINCTRL=y CONFIG_RAM=y -- 2.25.1
[next 2/5] net: ftgmac100: Add Aspeed AST2600 support
Add support of the MAC controller of Aspeed AST2600 SOC. The MAC
controller is the same with AST2500, except it has stand-alone MDIO
hardware block.
Signed-off-by: Dylan Hung
---
drivers/net/ftgmac100.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index b6e9526c3b9f..aa719d295f3d 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -644,6 +644,7 @@ static const struct eth_ops ftgmac100_ops = {
static const struct udevice_id ftgmac100_ids[] = {
{ .compatible = "faraday,ftgmac100", .data = FTGMAC100_MODEL_FARADAY },
{ .compatible = "aspeed,ast2500-mac", .data = FTGMAC100_MODEL_ASPEED },
+ { .compatible = "aspeed,ast2600-mac", .data = FTGMAC100_MODEL_ASPEED },
{ }
};
--
2.25.1
[next 1/5] net: ftgmac100: Add DM_MDIO support
Add support for DM_MDIO to connect to PHY. For the systems that have a
stand-alone MDIO hardware block, enable CONFIG_DM_MDIO to use driver
model for MDIO devices.
Signed-off-by: Dylan Hung
---
drivers/net/ftgmac100.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 0687230b4bb4..b6e9526c3b9f 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -220,7 +220,11 @@ static int ftgmac100_phy_init(struct udevice *dev)
struct phy_device *phydev;
int ret;
- phydev = phy_connect(priv->bus, priv->phy_addr, dev, priv->phy_mode);
+ if (IS_ENABLED(CONFIG_DM_MDIO))
+ phydev = dm_eth_phy_connect(dev);
+ else
+ phydev = phy_connect(priv->bus, priv->phy_addr, dev,
priv->phy_mode);
+
if (!phydev)
return -ENODEV;
@@ -589,10 +593,16 @@ static int ftgmac100_probe(struct udevice *dev)
if (ret)
goto out;
- ret = ftgmac100_mdio_init(dev);
- if (ret) {
- dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
- goto out;
+ /*
+* If DM MDIO is enabled, the MDIO bus will be initialized later in
+* dm_eth_phy_connect
+*/
+ if (!IS_ENABLED(CONFIG_DM_MDIO)) {
+ ret = ftgmac100_mdio_init(dev);
+ if (ret) {
+ dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
+ goto out;
+ }
}
ret = ftgmac100_phy_init(dev);
--
2.25.1
[next 0/5] Add support of Ethernet for Aspeed AST2600 SoC
This patch series adds support of Ethernet for Aspeed AST2600 SoC. There are 4 MAC controllers (ftgmac100) in AST2600 that can support 10/100/1000T Ethernet. 4 MDIO controllers are used to connect to PHY chips. The MDIO controller has stand-alone hardware block so we introduce DM_MDIO so that we can use external MDIO driver (aspeed_mdio) instead of integrated MDIO drier in ftgmac100.c. The patch series also revises the MII interface delay for better RMII/RGMII timing margin. Dylan Hung (5): net: ftgmac100: Add DM_MDIO support net: ftgmac100: Add Aspeed AST2600 support ARM: dts: ast2600: Add MDIO devices configs: ast2600: enable DM_MDIO and MDIO driver clk: ast2600: Revise MII interface delay arch/arm/dts/ast2600-evb.dts | 68 arch/arm/dts/ast2600.dtsi| 46 ++--- configs/evb-ast2600_defconfig| 2 + drivers/clk/aspeed/clk_ast2600.c | 10 ++--- drivers/net/ftgmac100.c | 21 +++--- 5 files changed, 132 insertions(+), 15 deletions(-) -- 2.25.1
Re: [RFC PATCH 01/10] GPT: Add function to get gpt header and partition entries
On Wed, Dec 08, 2021 at 01:10:51PM +0530, Sughosh Ganu wrote:
> hi Patrick,
>
> On Tue, 7 Dec 2021 at 21:05, Patrick DELAUNAY
> wrote:
>
> > Hi Sugosh
> >
> > On 11/25/21 8:01 AM, Sughosh Ganu wrote:
> >
> > Add function to get the gpt header and partition entries filled. These
> >
> > would be used subsequently for multi bank firmware update support on
> >
> > devices where the images reside on GPT partitions.
> >
> >
> >
> > Signed-off-by: Sughosh Ganu
> >
> >
> > ---
> >
> > disk/part_efi.c | 10 ++
> >
> > include/part.h | 14 ++
> >
> > 2 files changed, 24 insertions(+)
> >
> >
> >
> > diff --git a/disk/part_efi.c b/disk/part_efi.c
> >
> > index 0ca7effc32..792b9218a9 100644
> >
> > --- a/disk/part_efi.c
> >
> > +++ b/disk/part_efi.c
> >
> > @@ -216,6 +216,16 @@ int get_disk_guid(struct blk_desc * dev_desc, char
> > *guid)
> >
> > return 0;
> >
> > }
> >
> > +int get_gpt_hdr_parts(struct blk_desc *desc, gpt_header *gpt_head,
> >
> > + gpt_entry **gpt_pte)
> >
> > +{
> >
> > + /* This function validates and fills in the GPT header and PTE's */
> >
> > + if (find_valid_gpt(desc, gpt_head, gpt_pte) != 1)
> >
> > +return -EINVAL;
> >
> > +
> >
> > + return 0;
> >
> > +}
> >
> > +
> >
> > void part_print_efi(struct blk_desc *dev_desc)
> >
> > {
> >
> > ALLOC_CACHE_ALIGN_BUFFER_PAD(gpt_header, gpt_head, 1, dev_desc->blksz);
> >
> > diff --git a/include/part.h b/include/part.h
> >
> > index b66b07a1f0..8e86485b97 100644
> >
> > --- a/include/part.h
> >
> > +++ b/include/part.h
> >
> > @@ -345,6 +345,20 @@ struct part_driver {
> >
> > #if CONFIG_IS_ENABLED(EFI_PARTITION)
> >
> > /* disk/part_efi.c */
> >
> > +
> >
> > +/**
> >
> > + * get_gpt_hdr_parts() - Get information on the GPT Header and
> >
> > + * Partition Table Entries
> >
> > + *
> >
> > + * @param desc - block device descriptor
> >
> > + * @param gpt_h - pointer to GPT header representation
> >
> >
> >
> > gpt_h need to be allocated / DMA alligned by caller
> >
> >
> Will add this comment to the description.
>
>
> >
> >
> > + * @param gpt_e - pointer to GPT partition table entries
> >
> >
> >
> > gpt_e is allocated in this fucntion need to freed by caller
> >
> >
> Will add this comment to the description.
>
> >
> >
> > + *
> >
> > + * @return - zero on success, otherwise error
> >
> > + */
> >
> > +int get_gpt_hdr_parts(struct blk_desc *desc, gpt_header *gpt_head,
> >
> > + gpt_entry **gpt_pte);
> >
> > +
> >
> > /**
> >
> > * write_gpt_table() - Write the GUID Partition Table to disk
> >
> > *
> >
> > no need to export the low level function "find_valid_gpt"
> >
> >
> find_valid_gpt is not being exported. It is defined statically in
> part_efi.c. Do i misunderstand your comment?
>
>
> >
> >
> > the same services are already provided by part_get_info() ?
> >
> > ST Restricted
> >
> > 2 information are used in the serie
> >
> >
> >
> > => gpt_head->num_partition_entries
> >
> > => &gpt_pte[i].partition_type_guid
> >
> >
> >
> >
> >
> > type_guid is available in disk_partition,
> >
> > and num_partition_entries is not needed (replaced by MAX_SEARCH_PARTITIONS)
> >
> >
> >
> > something like:
> >
> >
> >
> > struct disk_partition info;
> >
> >
> >
> > for (p = 1; p < MAX_SEARCH_PARTITIONS; p++) {
> >
> >if (part_get_info(desc, p, &info))
> >
> >continue;
> >
> >=> info.type_guid
> >
> > }
> >
> >
> I had actually explored using part_get_info. But the type_guid field is
> actually a char string. While I need the guid value to compare it using
> guidcmp. Which is the reason I introduced get_gpt_hdr_parts.
Think of using uuid_str_to_bin() if this is the only reason.
-Takahiro Akashi
> -sughosh
>
>
> >
> > Regards
> >
> >
> >
> > Patrick
> >
> >
Re: [PATCH 1/5] net: ravb: Support multiple clocks
On Mon, Dec 6, 2021 at 6:29 PM Adam Ford wrote:
>
> The RZ/G2 series uses an external clock as a reference to the AVB.
> If this clock is controlled by an external programmable clock,
> it must be requested by the consumer or it will not turn on.
> In order to do this, update the driver to use bulk enable and
> disable functions to enable clocks for boards with multiple clocks.
>
> Signed-off-by: Adam Ford
> ---
> drivers/net/ravb.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ravb.c b/drivers/net/ravb.c
> index 6953b7286a..d756dddb02 100644
> --- a/drivers/net/ravb.c
> +++ b/drivers/net/ravb.c
> @@ -129,7 +129,7 @@ struct ravb_priv {
> struct phy_device *phydev;
> struct mii_dev *bus;
> void __iomem*iobase;
> - struct clk clk;
> + struct clk_bulk clks;
> struct gpio_descreset_gpio;
> };
>
> @@ -485,7 +485,7 @@ static int ravb_probe(struct udevice *dev)
> iobase = map_physmem(pdata->iobase, 0x1000, MAP_NOCACHE);
> eth->iobase = iobase;
>
> - ret = clk_get_by_index(dev, 0, ð->clk);
> + ret = clk_get_bulk(dev, ð->clks);
> if (ret < 0)
> goto err_mdio_alloc;
>
> @@ -518,7 +518,7 @@ static int ravb_probe(struct udevice *dev)
> eth->bus = miiphy_get_dev_by_name(dev->name);
>
> /* Bring up PHY */
> - ret = clk_enable(ð->clk);
> + ret = clk_enable_bulk(ð->clks);
> if (ret)
> goto err_mdio_register;
>
> @@ -533,7 +533,7 @@ static int ravb_probe(struct udevice *dev)
> return 0;
>
> err_mdio_reset:
> - clk_disable(ð->clk);
> + clk_release_bulk(ð->clks);
> err_mdio_register:
> mdio_free(mdiodev);
> err_mdio_alloc:
> @@ -545,7 +545,7 @@ static int ravb_remove(struct udevice *dev)
> {
> struct ravb_priv *eth = dev_get_priv(dev);
>
> - clk_disable(ð->clk);
> + clk_release_bulk(ð->clks);
>
> free(eth->phydev);
> mdio_unregister(eth->bus);
> --
> 2.32.0
>
Reviewed-by: Ramon Fried
Re: [PATCH v2] net: zynq: Add support for GEM reset
On Mon, Dec 6, 2021 at 5:25 PM Michal Simek wrote:
>
> Perform reset before core initialization.
> Standard flow which close to 99% users are using getting all IPs out of
> reset that there is no need to reset IP again. This is because of all low
> level initialization is done in previous bootloader stage.
> In SOM case these IPs are not touched by previous bootloader stage that's
> why reset needs to be called before IP is accessed to make sure that it is
> in correct state.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Update commit message
>
> drivers/net/zynq_gem.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 91957757727d..5cbe8d28304b 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -217,6 +218,7 @@ struct zynq_gem_priv {
> bool int_pcs;
> bool dma_64bit;
> u32 clk_en_info;
> + struct reset_ctl_bulk resets;
> };
>
> static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
> @@ -688,12 +690,36 @@ static int zynq_gem_miiphy_write(struct mii_dev *bus,
> int addr, int devad,
> return phywrite(priv, addr, reg, value);
> }
>
> +static int zynq_gem_reset_init(struct udevice *dev)
> +{
> + struct zynq_gem_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = reset_get_bulk(dev, &priv->resets);
> + if (ret == -ENOTSUPP || ret == -ENOENT)
> + return 0;
> + else if (ret)
> + return ret;
> +
> + ret = reset_deassert_bulk(&priv->resets);
> + if (ret) {
> + reset_release_bulk(&priv->resets);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int zynq_gem_probe(struct udevice *dev)
> {
> void *bd_space;
> struct zynq_gem_priv *priv = dev_get_priv(dev);
> int ret;
>
> + ret = zynq_gem_reset_init(dev);
> + if (ret)
> + return ret;
> +
> /* Align rxbuffers to ARCH_DMA_MINALIGN */
> priv->rxbuffers = memalign(ARCH_DMA_MINALIGN, RX_BUF * PKTSIZE_ALIGN);
> if (!priv->rxbuffers)
> --
> 2.33.1
>
Reviewed-by: Ramon Fried
Pull request: u-boot-sunxi/master fixes for 2022.01
Hi Tom, please pull those two fixes from the sunxi tree. This fixes two regressions: eMMC operation on boards with WiFi (so using three MMC devices), and a repeated wrong error message in USB gadget mode (fastboot, ums). Thanks, Andre === The following changes since commit 558002a0f2230bedf6b38716f3ed86a92fc9010b: Merge https://source.denx.de/u-boot/custodians/u-boot-riscv (2021-12-03 09:02:49 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to fbd9207e7fe3712b372ca9889a2a82402161fd27: sunxi: Remove misleading USB-OTG charger message (2021-12-08 23:07:15 +) Andre Przywara (2): sunxi: dts: Fix typoed eMMC check sunxi: Remove misleading USB-OTG charger message arch/arm/dts/sunxi-u-boot.dtsi | 2 +- board/sunxi/board.c| 8 +--- 2 files changed, 2 insertions(+), 8 deletions(-)
Re: [PATCH] sunxi: dts: Fix typoed eMMC check
在 2021-12-06星期一的 01:54 +，Andre Przywara写道：
> Commit 03510bf62149 ("sunxi: only include alias for eMMC when mmc2
> used") protected the eMMC alias in U-Boot's DT stub the with the
> associated Kconfig symbol, but was actually using the wrong name.
>
> Fix the name of the symbol to match what's defined in Kconfig and
> what
> the defconfig files actually use.
>
> Fixes: 03510bf62149 ("sunxi: only include alias for eMMC when mmc2
> used")
> Signed-off-by: Andre Przywara
> Reported-by: 5...@5kft.org
LGTM. I am just too careless.
Reviewed-by: Icenowy Zheng
> ---
> arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-
> boot.dtsi
> index b7244c1112a..f2d7361b84f 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -13,7 +13,7 @@
> / {
> aliases {
> mmc0 = &mmc0;
> -#if CONFIG_MMC_SUNXI_EXTRA_SLOT == 2
> +#if CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
> mmc1 = &mmc2;
> #endif
> };
Re: [RFC PATCH v3 8/8] tools: gen_pre_load_header.sh: initial import
Hi Rasmus,
First, thanks for the feedback.
Le 06/12/2021 à 09:23, Rasmus Villemoes a écrit :
On 17/11/2021 18.52, Philippe Reynes wrote:
This commit adds a script gen_pre_load_header.sh
that generate the header used by the image pre-load
stage.
Signed-off-by: Philippe Reynes
---
tools/gen_pre_load_header.sh | 174 +++
1 file changed, 174 insertions(+)
create mode 100755 tools/gen_pre_load_header.sh
diff --git a/tools/gen_pre_load_header.sh b/tools/gen_pre_load_header.sh
new file mode 100755
index 00..8256fa80ee
--- /dev/null
+++ b/tools/gen_pre_load_header.sh
@@ -0,0 +1,174 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+
+#
+# default value
+#
+size='4096'
+algo='sha256,rsa2048'
+padding='pkcs-1.5'
+key=''
+verbose='false'
+input=''
+output=''
+
+usage() {
+printf "Usage: $0 -a -k [-p ] [-s ] [-v] -i -o
\n"
+}
+
+#
+# parse arguments
+#
+while getopts 'a:hi:k:o:p:s:v' flag; do
+case "${flag}" in
+a) algo="${OPTARG}" ;;
+h) usage
+ exit 0 ;;
+i) input="${OPTARG}" ;;
+k) key="${OPTARG}" ;;
+o) output="${OPTARG}" ;;
+p) padding="${OPTARG}" ;;
+s) size="${OPTARG}" ;;
+v) verbose='true' ;;
+*) usage
+ exit 1 ;;
+esac
+done
+
+#
+# check that mandatory arguments are provided
+#
+if [ -z "$key" -o -z "$input" -o -z "$output" ]
+then
+usage
+exit 0
+fi
+
+hash=$(echo $algo | cut -d',' -f1)
+sign=$(echo $algo | cut -d',' -f2)
+
+echo "status:"
+echo "size= $size"
+echo "algo= $algo"
+echo "hash= $hash"
+echo "sign= $sign"
+echo "padding = $padding"
+echo "key = $key"
+echo "verbose = $verbose"
+
+#
+# check if input file exist
+#
+if [ ! -f "$input" ]
+then
+echo "Error: file '$input' doesn't exist"
+exit 1
+fi
+
+#
+# check if output is not empty
+#
+if [ -z "$output" ]
+then
+echo "Error: output is empty"
+exit 1
+fi
+
+#
+# check that size is bigger than 0
+#
+if [ $size -le 0 ]
+then
+echo "Error: $size lower than 0"
+exit 1
+fi
+
+#
+# check if the key file exist
+#
+if [ ! -f "$key" ]
+then
+echo "Error: file $key doesn't exist\n"
+exit 1
+fi
+
+#
+# check if the hash is valid and supported
+#
+print_supported_hash() {
+echo "Supported hash:"
+echo "- sha1"
+echo "- sha256"
+echo "- sha384"
+echo "- sha512"
+}
+
+case "$hash" in
+"sha1") hashOption="-sha1" ;;
+"sha256") hashOption="-sha256" ;;
+"sha384") hashOption="-sha384" ;;
+"sha512") hashOption="-sha512" ;;
+*) echo "Error: $hash is an invalid hash"
+ print_supported_hash
+ exit 1;;
+esac
+
+#
+# check if the sign is valid and supported
+#
+print_supported_sign() {
+echo "Supported sign:"
+echo "- rsa1024"
+echo "- rsa2048"
+echo "- rsa4096"
+}
+
+case "$sign" in
+"rsa1024") ;;
+"rsa2048") ;;
+"rsa4096") ;;
+*) echo "Error: $sign is an invalid signature type"
+ print_supported_sign
+ exit 1;;
+esac
+
+#
+# check if the padding is valid and supported
+#
+print_supported_padding() {
+echo "Supported padding:"
+echo "- pkcs-1.5"
+echo "- pss"
+}
+
+case "$padding" in
+"pkcs-1.5") optionPadding='' ;;
+"pss") optionPadding='-sigopt rsa_padding_mode:pss -sigopt
rsa_pss_saltlen:-2' ;;
+*) echo "Error: $padding is an invalid padding"
+ print_supported_padding
+ exit 1;;
+esac
+
+
+#
+# generate the sigature
+#
+sig=$(openssl dgst $optionHash -sign $key $optionPadding $input | xxd -p)
+
+#
+# generate the header
+#
+# 0 = magic
+# 4 = image size
+# 8 = signature
+#
+h=$(printf "%08x" 0x55425348)
+i=$(stat --printf="%s" $input)
+i=$(printf "%08x" $i)
+
+echo "$h$i$sig" | xxd -r -p > $output
So this sounds like a completely generic way of prepending a signature
to an arbitrary blob, whether that is a FIT image, a U-Boot script
wrapped in a FIT, some firmware blob or whatnot. So it sounds like it
could be generally useful, and a lot simpler than the complexity
inherent when trying to add signature data within the signed data
structure itself.
We plan to use it with FIT, but it is very generic and may be used
with any firmware.
So, can we perhaps not tie it to bootm as such? It's not a problem if
bootm learns to recognize 0x55425348 as another image format and then
automatically knows how to locate the "real" image, and/or automatically
verifies it. But I'd really like to be able to
fatload $loadaddr blabla && \
verify $loadaddr && \
source $loadaddr
where fatload can be any random command that gets a bunch of bytes into
memory at a specific location (tftpboot, mmc read, ubi...). Currently,
we simply don't have any sane way to verify a boot script, or random
blobs, AFAICT.
Based on this header, it is quite easy to develop a command verify.
It wasn't planned but it is a very good idea. I will add it, in the next
version or in another series a bit after.
Re: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
On Wed, 8 Dec 2021 20:48:54 +0330
Javad Rahimi wrote:
> On Wed, Dec 8, 2021 at 8:33 PM Andre Przywara wrote:
> >
> > On Wed, 8 Dec 2021 19:14:22 +0330
> > Javad Rahimi wrote:
> >
> > > On Wed, Dec 8, 2021 at 6:05 PM Andre Przywara
> > > wrote:
> > > >
> > > > On Wed, 8 Dec 2021 15:25:54 +0100
> > > > Frank Wunderlich wrote:
> > > >
> > > > Hi,
> > > >
> > > > > you should add maintainer email for your patch
> > > > >
> > > > > $ scripts/get_maintainer.pl board/sunxi/board.c
> > > > > Jagan Teki (maintainer:ARM SUNXI)
> > > > > Andre Przywara (maintainer:ARM SUNXI)
> > > > > u-boot@lists.denx.de (open list)
> > > >
> > > > Thanks Frank!
> > > >
> > > > > > Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> > > > > > Von: "Javad Rahimi"
> > > > > > An: u-boot@lists.denx.de
> > > > > > Cc: "Javad Rahimi"
> > > > > > Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
> > > > > >
> > > > > > This feature makes it possible to assign one of
> > > > > > LED1(PH20) and LED2(PH21) to BOOT process LED.
> > > > > > User should activates the "Enable status LED API" in
> > > > > > "Device Drivers -> LED Support"
> > > >
> > > > Please have a look at the current pinephone_defconfig, because that uses
> > > > the boot LED already in a much easier fashion:
> > > > https://source.denx.de/u-boot/u-boot/-/commit/0534153fd1
> > > >
> > > > Cheers,
> > > > Andre
> > > >
> > > Hi Andre,
> > > Thanks for your comments. I studied the pinephone_defconfig.
> > > By default, when activating the same options on Cubieboard2_defconfig
> > > it shows linker error for `__led_init` and `__led_set`.
> > > In other words, they are not defined. So, in this patch, I added the
> > > implementation for these functions for this board.
> >
> > Did you add the:
> > CONFIG_SPL_DRIVERS_MISC=y
> > line as well? And re-ran make Cubieboard2_defconfig?
> > Because that seemed to work for me.
> >
> > Cheers,
> > Andre
> >
> >
> When I add CONFIG_SPL_DRIVERS_MISC=y
> By flashing SD card and turning on the board, It freezes in this step:
> ```
> U-Boot SPL 2022.01-rc3-00025-gf570594bc9-dirty (Dec 08 2021 - 20:36:51 +0330)
> ```
> -
> The customized defconfig file for Cubieboard:
> ```
> CONFIG_ARM=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-cubieboard2"
> CONFIG_SPL_DRIVERS_MISC=y
> CONFIG_SPL=y
> CONFIG_MACH_SUN7I=y
> CONFIG_DRAM_CLK=480
> CONFIG_MMC0_CD_PIN="PH1"
> CONFIG_SATAPWR="PB8"
> CONFIG_AHCI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SPL_I2C=y
> CONFIG_SCSI_AHCI=y
> CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_SYS_I2C_SLAVE=0x7f
> CONFIG_SYS_I2C_SPEED=40
> CONFIG_PHY_REALTEK=y
> CONFIG_ETH_DESIGNWARE=y
> CONFIG_MII=y
> CONFIG_SUN7I_GMAC=y
> CONFIG_SCSI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> CONFIG_LED_STATUS=y
> CONFIG_LED_STATUS_GPIO=y
> CONFIG_LED_STATUS0=y
> CONFIG_LED_STATUS_BIT=114
This is the GPIO number, you need to adjust this to point to the pin your
LED is connected to. PH20 would be 244, for instance:
('H' - 'A') * 32 + 20
Cheers,
Andre
> CONFIG_LED_STATUS_STATE=2
> ```
> Best Regards,
> Javad
> > > > > >
> > > > > > Signed-off-by: Javad Rahimi
> > > > > > ---
> > > > > > This is my first contributation in open source world.
> > > > > > I'm sorry if I have mistakes in my commits and versioning.
> > > > > > I do my best to learn fast.
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Missed braces added
> > > > > > - Unnecessary debug removed
> > > > > > - Some typo fixed
> > > > > >
> > > > > > board/sunxi/board.c | 49
> > > > > > +
> > > > > > 1 file changed, 49 insertions(+)
> > > > > >
> > > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > > > > index 4f5747c34a..5e2f6ae902 100644
> > > > > > --- a/board/sunxi/board.c
> > > > > > +++ b/board/sunxi/board.c
> > > > > > @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char
> > > > > > *name)
> > > > > > return ret;
> > > > > > }
> > > > > > #endif
> > > > > > +
> > > > > > +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT)
> > > > > > && defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> > > > > > +
> > > > > > +#define CUBIE2_LED_BOOT_GPIO "PH20"
> > > > > > +static int gpio_boot_led;
> > > > > > +
> > > > > > +void __led_init(led_id_t mask, int state)
> > > > > > +{
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > > > > + return;
> > > > > > +
> > > > > > + ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
> > > > > > &gpio_boot_led);
> > > > > > +
> > > > > > + if (ret)
> > > > > > + return;
> > > > > > +
> > > > > > + ret = gpio_request(gpio_boot_led, "boot_led");
> > > > > > + if (ret == -1) {
> > > > > > + debug("[gpio_request] Error:%d\n", ret);
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + ret = gpio_direction_output(gpio_boot_led, 1);
Re: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
On Wed, Dec 8, 2021 at 8:33 PM Andre Przywara wrote:
>
> On Wed, 8 Dec 2021 19:14:22 +0330
> Javad Rahimi wrote:
>
> > On Wed, Dec 8, 2021 at 6:05 PM Andre Przywara
> > wrote:
> > >
> > > On Wed, 8 Dec 2021 15:25:54 +0100
> > > Frank Wunderlich wrote:
> > >
> > > Hi,
> > >
> > > > you should add maintainer email for your patch
> > > >
> > > > $ scripts/get_maintainer.pl board/sunxi/board.c
> > > > Jagan Teki (maintainer:ARM SUNXI)
> > > > Andre Przywara (maintainer:ARM SUNXI)
> > > > u-boot@lists.denx.de (open list)
> > >
> > > Thanks Frank!
> > >
> > > > > Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> > > > > Von: "Javad Rahimi"
> > > > > An: u-boot@lists.denx.de
> > > > > Cc: "Javad Rahimi"
> > > > > Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
> > > > >
> > > > > This feature makes it possible to assign one of
> > > > > LED1(PH20) and LED2(PH21) to BOOT process LED.
> > > > > User should activates the "Enable status LED API" in
> > > > > "Device Drivers -> LED Support"
> > >
> > > Please have a look at the current pinephone_defconfig, because that uses
> > > the boot LED already in a much easier fashion:
> > > https://source.denx.de/u-boot/u-boot/-/commit/0534153fd1
> > >
> > > Cheers,
> > > Andre
> > >
> > Hi Andre,
> > Thanks for your comments. I studied the pinephone_defconfig.
> > By default, when activating the same options on Cubieboard2_defconfig
> > it shows linker error for `__led_init` and `__led_set`.
> > In other words, they are not defined. So, in this patch, I added the
> > implementation for these functions for this board.
>
> Did you add the:
> CONFIG_SPL_DRIVERS_MISC=y
> line as well? And re-ran make Cubieboard2_defconfig?
> Because that seemed to work for me.
>
> Cheers,
> Andre
>
>
When I add CONFIG_SPL_DRIVERS_MISC=y
By flashing SD card and turning on the board, It freezes in this step:
```
U-Boot SPL 2022.01-rc3-00025-gf570594bc9-dirty (Dec 08 2021 - 20:36:51 +0330)
```
-
The customized defconfig file for Cubieboard:
```
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-cubieboard2"
CONFIG_SPL_DRIVERS_MISC=y
CONFIG_SPL=y
CONFIG_MACH_SUN7I=y
CONFIG_DRAM_CLK=480
CONFIG_MMC0_CD_PIN="PH1"
CONFIG_SATAPWR="PB8"
CONFIG_AHCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_I2C=y
CONFIG_SCSI_AHCI=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_SYS_I2C_SLAVE=0x7f
CONFIG_SYS_I2C_SPEED=40
CONFIG_PHY_REALTEK=y
CONFIG_ETH_DESIGNWARE=y
CONFIG_MII=y
CONFIG_SUN7I_GMAC=y
CONFIG_SCSI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_LED_STATUS=y
CONFIG_LED_STATUS_GPIO=y
CONFIG_LED_STATUS0=y
CONFIG_LED_STATUS_BIT=114
CONFIG_LED_STATUS_STATE=2
```
Best Regards,
Javad
> > > > >
> > > > > Signed-off-by: Javad Rahimi
> > > > > ---
> > > > > This is my first contributation in open source world.
> > > > > I'm sorry if I have mistakes in my commits and versioning.
> > > > > I do my best to learn fast.
> > > > >
> > > > > Changes in v2:
> > > > > - Missed braces added
> > > > > - Unnecessary debug removed
> > > > > - Some typo fixed
> > > > >
> > > > > board/sunxi/board.c | 49
> > > > > +
> > > > > 1 file changed, 49 insertions(+)
> > > > >
> > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > > > index 4f5747c34a..5e2f6ae902 100644
> > > > > --- a/board/sunxi/board.c
> > > > > +++ b/board/sunxi/board.c
> > > > > @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char
> > > > > *name)
> > > > > return ret;
> > > > > }
> > > > > #endif
> > > > > +
> > > > > +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
> > > > > defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> > > > > +
> > > > > +#define CUBIE2_LED_BOOT_GPIO "PH20"
> > > > > +static int gpio_boot_led;
> > > > > +
> > > > > +void __led_init(led_id_t mask, int state)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > > > + return;
> > > > > +
> > > > > + ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
> > > > > &gpio_boot_led);
> > > > > +
> > > > > + if (ret)
> > > > > + return;
> > > > > +
> > > > > + ret = gpio_request(gpio_boot_led, "boot_led");
> > > > > + if (ret == -1) {
> > > > > + debug("[gpio_request] Error:%d\n", ret);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + ret = gpio_direction_output(gpio_boot_led, 1);
> > > > > + if (ret == -1) {
> > > > > + debug("[gpio_direction_output] Error:%d\n", ret);
> > > > > + return;
> > > > > + }
> > > > > + __led_set(mask, state);
> > > > > +}
> > > > > +
> > > > > +void __led_set(led_id_t mask, int state)
> > > > > +{
> > > > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > > > + return;
> > > > > +
> > > > > + gpio_set_value(gpio_boot_led, state);
> > > > > +}
> > > > > +
> > > > > +void __led_toggle(led_id_t mask)
> > > > > +{
> > > > > + if (mask != CONFI
Re: [PATCH v7 08/31] arm: vexpress: Add a devicetree files for juno
On Wed, Dec 08, 2021 at 04:59:14PM +, Andre Przywara wrote: > On Mon, 6 Dec 2021 17:11:46 -0700 > Simon Glass wrote: > > Hi, > > > Sync these file, obtained from Linux v5.15. > > So just for the records: > Here you have the same problem as with the other platforms: There are > three different revisions of the board, all out in the wild and heavily > used. The platform firmware (some STM32 controller on the board) sorts > out which board you have, and places the right DTB in the NOR flash. So by > reading that from there, you get the correct information. > > So as it stands right now, having the Juno DTBs in the tree does not help > in any way, as they are not packaged. Actually just u-boot.bin is becoming > part of the TF-A FIP image, and then this fip.bin is copied to the board's > SD card, along with all three DTBs. > I can write up some instructions on how to deploy the firmware on the > board, if that helps. To me, a common theme is that the board documentation isn't clear enough on how things work so yes, this would be greatly appreciated. -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 08/31] arm: vexpress: Add a devicetree files for juno
On Mon, 6 Dec 2021 17:11:46 -0700
Simon Glass wrote:
Hi,
> Sync these file, obtained from Linux v5.15.
So just for the records:
Here you have the same problem as with the other platforms: There are
three different revisions of the board, all out in the wild and heavily
used. The platform firmware (some STM32 controller on the board) sorts
out which board you have, and places the right DTB in the NOR flash. So by
reading that from there, you get the correct information.
So as it stands right now, having the Juno DTBs in the tree does not help
in any way, as they are not packaged. Actually just u-boot.bin is becoming
part of the TF-A FIP image, and then this fip.bin is copied to the board's
SD card, along with all three DTBs.
I can write up some instructions on how to deploy the firmware on the
board, if that helps.
If you want to tweak the DTB, for experimentation or testing, just copy
something to the SD card, from where it gets automatically copied to the
NOR flash on board bootup.
So I would rather just avoid the duplicated .dts copies in the U-Boot
tree, given that they won't be used in any way.
Cheers,
Andre
> Add a note for the maintainer, and SPDX lines where they are missing.
> The added lines are:
>
>SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>
> Note, this matches the text in those files, but is not the same as the
> GPL-2.0 of some files.
>
> [1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v7:
> - Bring in files from Linux instead
> - Rewrite the commit message
>
> arch/arm/dts/Makefile | 3 +
> arch/arm/dts/juno-base.dtsi| 831 +
> arch/arm/dts/juno-clocks.dtsi | 46 ++
> arch/arm/dts/juno-cs-r1r2.dtsi | 85 +++
> arch/arm/dts/juno-motherboard.dtsi | 303 +
> arch/arm/dts/juno-r2.dts | 322 ++
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> 7 files changed, 1591 insertions(+)
> create mode 100644 arch/arm/dts/juno-base.dtsi
> create mode 100644 arch/arm/dts/juno-clocks.dtsi
> create mode 100644 arch/arm/dts/juno-cs-r1r2.dtsi
> create mode 100644 arch/arm/dts/juno-motherboard.dtsi
> create mode 100644 arch/arm/dts/juno-r2.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9cddab37207..d53bae2c350 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1149,7 +1149,10 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb
> dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
>
> +# TODO(Linus Walleij ): Should us a single vexpress
> +# Kconfig option to build all of these. See examples above.
> dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
> +dtb-$(CONFIG_TARGET_VEXPRESS64_JUNO) += juno-r2.dtb
>
> dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
>
> diff --git a/arch/arm/dts/juno-base.dtsi b/arch/arm/dts/juno-base.dtsi
> new file mode 100644
> index 000..6288e104a08
> --- /dev/null
> +++ b/arch/arm/dts/juno-base.dtsi
> @@ -0,0 +1,831 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "juno-clocks.dtsi"
> +#include "juno-motherboard.dtsi"
> +
> +/ {
> + /*
> + * Devices shared by all Juno boards
> + */
> +
> + memtimer: timer@2a81 {
> + compatible = "arm,armv7-timer-mem";
> + reg = <0x0 0x2a81 0x0 0x1>;
> + clock-frequency = <5000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x2a82 0x2>;
> + status = "disabled";
> + frame@2a83 {
> + frame-number = <1>;
> + interrupts = ;
> + reg = <0x1 0x1>;
> + };
> + };
> +
> + mailbox: mhu@2b1f {
> + compatible = "arm,mhu", "arm,primecell";
> + reg = <0x0 0x2b1f 0x0 0x1000>;
> + interrupts = ,
> + ;
> + #mbox-cells = <1>;
> + clocks = <&soc_refclk100mhz>;
> + clock-names = "apb_pclk";
> + };
> +
> + smmu_gpu: iommu@2b40 {
> + compatible = "arm,mmu-400", "arm,smmu-v1";
> + reg = <0x0 0x2b40 0x0 0x1>;
> + interrupts = ,
> + ;
> + #iommu-cells = <1>;
> + #global-interrupts = <1>;
> + power-domains = <&scpi_devpd 1>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + smmu_pcie: iommu@2b50 {
> + compatible = "arm,mmu-401", "arm,smmu-v1";
> + reg = <0x0 0x2b50 0x0 0x1>;
> + interrupts = ,
> + ;
> + #iommu-cells = <1>;
> + #global-interrupts = <1>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> +
[PATCH 2/2] fdtgrep: Handle an empty output tree
In strange cases it is possible for fdtgrep to find nothing to output.
Typically this means that the resulting SPL device tree is not going to
allow anything to boot, but at present the tree is actually invalid,
since it only has an END tag in the struct region.
The FDT spec requires at least a root node. So add a special case to
include at least this, if the FDT_REG_SUPERNODES flag is set.
This ensures that grepping an empty tree still produces a valid tree.
Also add comments to the enum since it is not completely obvious from
the names now.
The typical symptom of this problem is a message from binman:
pylibfdt error -11: FDT_ERR_BADSTRUCTURE
Signed-off-by: Simon Glass
---
boot/fdt_region.c| 43 +--
include/fdt_region.h | 1 +
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/boot/fdt_region.c b/boot/fdt_region.c
index e4ef0ca7703..bac55593294 100644
--- a/boot/fdt_region.c
+++ b/boot/fdt_region.c
@@ -185,6 +185,8 @@ static int fdt_add_region(struct fdt_region_state *info,
int offset, int size)
reg++;
reg->offset = offset;
reg->size = size;
+ if (!(offset - fdt_off_dt_struct(info->fdt)))
+ info->have_node = true;
}
} else {
return -1;
@@ -342,13 +344,19 @@ static int fdt_include_supernodes(struct fdt_region_state
*info, int depth)
return 0;
}
+/*
+ * Tracks the progress through the device tree. Everything fdt_next_region() is
+ * called it picks up at the same state as last time, looks at info->start and
+ * decides what region to add next
+ */
enum {
- FDT_DONE_NOTHING,
- FDT_DONE_MEM_RSVMAP,
- FDT_DONE_STRUCT,
- FDT_DONE_END,
- FDT_DONE_STRINGS,
- FDT_DONE_ALL,
+ FDT_DONE_NOTHING, /* Starting */
+ FDT_DONE_MEM_RSVMAP,/* Completed mem_rsvmap region */
+ FDT_DONE_STRUCT,/* Completed struct region */
+ FDT_DONE_EMPTY, /* Completed checking for empty struct region */
+ FDT_DONE_END, /* Completed the FDT_END tag */
+ FDT_DONE_STRINGS, /* Completed the strings */
+ FDT_DONE_ALL, /* All done */
};
int fdt_first_region(const void *fdt,
@@ -365,6 +373,7 @@ int fdt_first_region(const void *fdt,
info->can_merge = 1;
info->max_regions = 1;
info->start = -1;
+ info->have_node = false;
p->want = WANT_NOTHING;
p->end = path;
*p->end = '\0';
@@ -633,6 +642,8 @@ int fdt_next_region(const void *fdt,
* region.
*/
if (!include && info->start != -1) {
+ if (!info->start)
+ info->have_node = true;
if (fdt_add_region(info, base + info->start,
stop_at - info->start))
return 0;
@@ -644,11 +655,31 @@ int fdt_next_region(const void *fdt,
info->ptrs = p;
}
+ if (info->ptrs.done < FDT_DONE_EMPTY) {
+ /*
+* Handle a special case where no nodes have been written. Write
+* the first { so we have at least something, since
+* FDT_REG_SUPERNODES means that a valid tree is required. A
+* tree with no nodes is not valid
+*/
+ if ((flags & FDT_REG_SUPERNODES) && !info->have_node &&
+ info->start) {
+ /* Output the FDT_BEGIN_NODE and the empty name */
+ if (fdt_add_region(info, base, 8))
+ return 0;
+ }
+ info->ptrs.done++;
+ }
+
/* Add a region for the END tag and a separate one for string table */
if (info->ptrs.done < FDT_DONE_END) {
if (info->ptrs.nextoffset != fdt_size_dt_struct(fdt))
return -FDT_ERR_BADSTRUCTURE;
+ /* Output the } before the end tag to finish it off */
+ if (info->start == fdt_size_dt_struct(fdt) - 4)
+ info->start -= 4;
+
if (fdt_add_region(info, base + info->start,
info->ptrs.nextoffset - info->start))
return 0;
diff --git a/include/fdt_region.h b/include/fdt_region.h
index ff7a1ccb9af..d0c68760f78 100644
--- a/include/fdt_region.h
+++ b/include/fdt_region.h
@@ -77,6 +77,7 @@ struct fdt_region_state {
int max_regions;/* Maximum regions to find */
int can_merge; /* 1 if we can merge with previous region */
int start; /* Start position of current region */
+ bool have_node; /* True if any node is included */
struct fdt_region_ptrs ptrs;/* Pointers for
[PATCH 1/2] fdtgrep: Correct alignment of struct section
When outputting a devicetree we should not align the struct section to a 16-byte boundary. The normal position is fine, which is 8-byte aligned. This avoids leaving adding 8 extra zero bytes in the output tree in the case where the reserved section is empty (i.e has 16 zero bytes). Signed-off-by: Simon Glass --- tools/fdtgrep.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c index db512465db1..641d6a2e3e0 100644 --- a/tools/fdtgrep.c +++ b/tools/fdtgrep.c @@ -438,8 +438,7 @@ static int dump_fdt_regions(struct display_info *disp, const void *blob, fdt = (struct fdt_header *)out; memset(fdt, '\0', sizeof(*fdt)); fdt_set_magic(fdt, FDT_MAGIC); - struct_start = FDT_ALIGN(sizeof(struct fdt_header), - sizeof(struct fdt_reserve_entry)); + struct_start = sizeof(struct fdt_header); fdt_set_off_mem_rsvmap(fdt, struct_start); fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION); fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION); -- 2.34.1.400.ga245620fadb-goog
Re: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
On Wed, Dec 8, 2021 at 6:05 PM Andre Przywara wrote:
>
> On Wed, 8 Dec 2021 15:25:54 +0100
> Frank Wunderlich wrote:
>
> Hi,
>
> > you should add maintainer email for your patch
> >
> > $ scripts/get_maintainer.pl board/sunxi/board.c
> > Jagan Teki (maintainer:ARM SUNXI)
> > Andre Przywara (maintainer:ARM SUNXI)
> > u-boot@lists.denx.de (open list)
>
> Thanks Frank!
>
Hi Andre,
Thanks for your comments. I studied the pinephone_defconfig.
By default, when activating the same options on Cubieboard2_defconfig
it shows linker error for `__led_init` and `__led_set`.
In other words, they are not defined. So, in this patch, I added the
implementation for these functions for this board.
Regards,
Javad
> > > Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> > > Von: "Javad Rahimi"
> > > An: u-boot@lists.denx.de
> > > Cc: "Javad Rahimi"
> > > Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
> > >
> > > This feature makes it possible to assign one of
> > > LED1(PH20) and LED2(PH21) to BOOT process LED.
> > > User should activates the "Enable status LED API" in
> > > "Device Drivers -> LED Support"
>
> Please have a look at the current pinephone_defconfig, because that uses
> the boot LED already in a much easier fashion:
> https://source.denx.de/u-boot/u-boot/-/commit/0534153fd1
>
> Cheers,
> Andre
>
> > >
> > > Signed-off-by: Javad Rahimi
> > > ---
> > > This is my first contributation in open source world.
> > > I'm sorry if I have mistakes in my commits and versioning.
> > > I do my best to learn fast.
> > >
> > > Changes in v2:
> > > - Missed braces added
> > > - Unnecessary debug removed
> > > - Some typo fixed
> > >
> > > board/sunxi/board.c | 49 +
> > > 1 file changed, 49 insertions(+)
> > >
> > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > > index 4f5747c34a..5e2f6ae902 100644
> > > --- a/board/sunxi/board.c
> > > +++ b/board/sunxi/board.c
> > > @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char *name)
> > > return ret;
> > > }
> > > #endif
> > > +
> > > +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
> > > defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> > > +
> > > +#define CUBIE2_LED_BOOT_GPIO "PH20"
> > > +static int gpio_boot_led;
> > > +
> > > +void __led_init(led_id_t mask, int state)
> > > +{
> > > + int ret;
> > > +
> > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > + return;
> > > +
> > > + ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
> > > &gpio_boot_led);
> > > +
> > > + if (ret)
> > > + return;
> > > +
> > > + ret = gpio_request(gpio_boot_led, "boot_led");
> > > + if (ret == -1) {
> > > + debug("[gpio_request] Error:%d\n", ret);
> > > + return;
> > > + }
> > > +
> > > + ret = gpio_direction_output(gpio_boot_led, 1);
> > > + if (ret == -1) {
> > > + debug("[gpio_direction_output] Error:%d\n", ret);
> > > + return;
> > > + }
> > > + __led_set(mask, state);
> > > +}
> > > +
> > > +void __led_set(led_id_t mask, int state)
> > > +{
> > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > + return;
> > > +
> > > + gpio_set_value(gpio_boot_led, state);
> > > +}
> > > +
> > > +void __led_toggle(led_id_t mask)
> > > +{
> > > + if (mask != CONFIG_LED_STATUS_BOOT)
> > > + return;
> > > +
> > > + gpio_set_value(gpio_boot_led, !gpio_get_value(gpio_boot_led));
> > > +}
> > > +
> > > +#endif
> > > --
> > > 2.25.1
> > >
> > >
>
Re: [PATCH v1 1/1] support rsa3072
On Wed, Dec 08, 2021 at 06:36:21PM +0800, Jamin Lin wrote:
> This patch set support rsa3072.
>
> Signed-off-by: Jamin Lin
> ---
> common/image-sig.c | 7 +++
> include/u-boot/rsa.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/common/image-sig.c b/common/image-sig.c
> index e4bbac55c1..c94854ef8b 100644
> --- a/common/image-sig.c
> +++ b/common/image-sig.c
> @@ -85,6 +85,13 @@ struct crypto_algo crypto_algos[] = {
> .add_verify_data = rsa_add_verify_data,
> .verify = rsa_verify,
> },
> + {
> + .name = "rsa3072",
> + .key_len = RSA3072_BYTES,
> + .sign = rsa_sign,
> + .add_verify_data = rsa_add_verify_data,
> + .verify = rsa_verify,
> + },
> {
> .name = "rsa4096",
> .key_len = RSA4096_BYTES,
> diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
> index 2d3024d8b7..d561e5f8ca 100644
> --- a/include/u-boot/rsa.h
> +++ b/include/u-boot/rsa.h
> @@ -135,6 +135,7 @@ static inline int padding_pss_verify(struct
> image_sign_info *info,
> #define RSA_DEFAULT_PADDING_NAME "pkcs-1.5"
>
> #define RSA2048_BYTES(2048 / 8)
> +#define RSA3072_BYTES(3072 / 8)
> #define RSA4096_BYTES(4096 / 8)
>
> /* This is the minimum/maximum key size we support, in bits */
For both of these patches, please expand the commit message and header
so it's clear where you're adding the support to. Perhaps they should
be squashed in to a single patch as the tooling needs to support it when
the binary also supports it?
--
Tom
signature.asc
Description: PGP signature
[PATCH v3] Cubieboard2:SUN7I:Add LED BOOT support
This feature makes it possible to assign one of
LED1(PH20) and LED2(PH21) to BOOT process LED.
User should activates the "Enable status LED API" in
"Device Drivers -> LED Support"
Signed-off-by: Javad Rahimi
---
This is my first contributation in open source world.
I'm sorry if I have mistakes in my commits and versioning.
I do my best to learn fast.
Changes in v3:
- Maintainers email added
Changes in v2:
- Missed braces added
- Unnecessary debug removed
- Some typo fixed
board/sunxi/board.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4f5747c34a..5e2f6ae902 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char *name)
return ret;
}
#endif
+
+#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
+
+#define CUBIE2_LED_BOOT_GPIO "PH20"
+static int gpio_boot_led;
+
+void __led_init(led_id_t mask, int state)
+{
+ int ret;
+
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
&gpio_boot_led);
+
+ if (ret)
+ return;
+
+ ret = gpio_request(gpio_boot_led, "boot_led");
+ if (ret == -1) {
+ debug("[gpio_request] Error:%d\n", ret);
+ return;
+ }
+
+ ret = gpio_direction_output(gpio_boot_led, 1);
+ if (ret == -1) {
+ debug("[gpio_direction_output] Error:%d\n", ret);
+ return;
+ }
+ __led_set(mask, state);
+}
+
+void __led_set(led_id_t mask, int state)
+{
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ gpio_set_value(gpio_boot_led, state);
+}
+
+void __led_toggle(led_id_t mask)
+{
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ gpio_set_value(gpio_boot_led, !gpio_get_value(gpio_boot_led));
+}
+
+#endif
--
2.25.1
Re: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
On Wed, 8 Dec 2021 15:25:54 +0100
Frank Wunderlich wrote:
Hi,
> you should add maintainer email for your patch
>
> $ scripts/get_maintainer.pl board/sunxi/board.c
> Jagan Teki (maintainer:ARM SUNXI)
> Andre Przywara (maintainer:ARM SUNXI)
> u-boot@lists.denx.de (open list)
Thanks Frank!
> > Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> > Von: "Javad Rahimi"
> > An: u-boot@lists.denx.de
> > Cc: "Javad Rahimi"
> > Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
> >
> > This feature makes it possible to assign one of
> > LED1(PH20) and LED2(PH21) to BOOT process LED.
> > User should activates the "Enable status LED API" in
> > "Device Drivers -> LED Support"
Please have a look at the current pinephone_defconfig, because that uses
the boot LED already in a much easier fashion:
https://source.denx.de/u-boot/u-boot/-/commit/0534153fd1
Cheers,
Andre
> >
> > Signed-off-by: Javad Rahimi
> > ---
> > This is my first contributation in open source world.
> > I'm sorry if I have mistakes in my commits and versioning.
> > I do my best to learn fast.
> >
> > Changes in v2:
> > - Missed braces added
> > - Unnecessary debug removed
> > - Some typo fixed
> >
> > board/sunxi/board.c | 49 +
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 4f5747c34a..5e2f6ae902 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char *name)
> > return ret;
> > }
> > #endif
> > +
> > +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
> > defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> > +
> > +#define CUBIE2_LED_BOOT_GPIO "PH20"
> > +static int gpio_boot_led;
> > +
> > +void __led_init(led_id_t mask, int state)
> > +{
> > + int ret;
> > +
> > + if (mask != CONFIG_LED_STATUS_BOOT)
> > + return;
> > +
> > + ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
> > &gpio_boot_led);
> > +
> > + if (ret)
> > + return;
> > +
> > + ret = gpio_request(gpio_boot_led, "boot_led");
> > + if (ret == -1) {
> > + debug("[gpio_request] Error:%d\n", ret);
> > + return;
> > + }
> > +
> > + ret = gpio_direction_output(gpio_boot_led, 1);
> > + if (ret == -1) {
> > + debug("[gpio_direction_output] Error:%d\n", ret);
> > + return;
> > + }
> > + __led_set(mask, state);
> > +}
> > +
> > +void __led_set(led_id_t mask, int state)
> > +{
> > + if (mask != CONFIG_LED_STATUS_BOOT)
> > + return;
> > +
> > + gpio_set_value(gpio_boot_led, state);
> > +}
> > +
> > +void __led_toggle(led_id_t mask)
> > +{
> > + if (mask != CONFIG_LED_STATUS_BOOT)
> > + return;
> > +
> > + gpio_set_value(gpio_boot_led, !gpio_get_value(gpio_boot_led));
> > +}
> > +
> > +#endif
> > --
> > 2.25.1
> >
> >
[PATCH] fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED use
Commit "fw_setenv: lock the flash only if it was locked before"
checks for Locked status with uninitialized erase data.
Address by moving the test for MEMISLOCKED.
Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was locked before")
Signed-off-by: Joakim Tjernlund
---
tools/env/fw_env.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index e39c39e23a..3da75be783 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1083,12 +1083,6 @@ static int flash_write_buf(int dev, int fd, void *buf,
size_t count)
}
erase.length = erasesize;
- if (DEVTYPE(dev) != MTD_ABSENT) {
- was_locked = ioctl(fd, MEMISLOCKED, &erase);
- /* treat any errors as unlocked flash */
- if (was_locked < 0)
- was_locked = 0;
- }
/* This only runs once on NOR flash and SPI-dataflash */
while (processed < write_total) {
@@ -1108,6 +1102,10 @@ static int flash_write_buf(int dev, int fd, void *buf,
size_t count)
if (DEVTYPE(dev) != MTD_ABSENT) {
erase.start = blockstart;
+ was_locked = ioctl(fd, MEMISLOCKED, &erase);
+ /* treat any errors as unlocked flash */
+ if (was_locked < 0)
+ was_locked = 0;
if (was_locked)
ioctl(fd, MEMUNLOCK, &erase);
/* These do not need an explicit erase cycle */
@@ -1163,7 +1161,6 @@ static int flash_flag_obsolete(int dev, int fd, off_t
offset)
char tmp = ENV_REDUND_OBSOLETE;
int was_locked; /* flash lock flag */
- was_locked = ioctl(fd, MEMISLOCKED, &erase);
erase.start = DEVOFFSET(dev);
erase.length = DEVESIZE(dev);
/* This relies on the fact, that ENV_REDUND_OBSOLETE == 0 */
@@ -1173,6 +1170,10 @@ static int flash_flag_obsolete(int dev, int fd, off_t
offset)
DEVNAME(dev));
return rc;
}
+ was_locked = ioctl(fd, MEMISLOCKED, &erase);
+ /* treat any errors as unlocked flash */
+ if (was_locked < 0)
+ was_locked = 0;
if (was_locked)
ioctl(fd, MEMUNLOCK, &erase);
rc = write(fd, &tmp, sizeof(tmp));
--
2.32.0
Aw: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
Hi,
you should add maintainer email for your patch
$ scripts/get_maintainer.pl board/sunxi/board.c
Jagan Teki (maintainer:ARM SUNXI)
Andre Przywara (maintainer:ARM SUNXI)
u-boot@lists.denx.de (open list)
regards Frank
> Gesendet: Mittwoch, 08. Dezember 2021 um 15:22 Uhr
> Von: "Javad Rahimi"
> An: u-boot@lists.denx.de
> Cc: "Javad Rahimi"
> Betreff: [PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
>
> This feature makes it possible to assign one of
> LED1(PH20) and LED2(PH21) to BOOT process LED.
> User should activates the "Enable status LED API" in
> "Device Drivers -> LED Support"
>
> Signed-off-by: Javad Rahimi
> ---
> This is my first contributation in open source world.
> I'm sorry if I have mistakes in my commits and versioning.
> I do my best to learn fast.
>
> Changes in v2:
> - Missed braces added
> - Unnecessary debug removed
> - Some typo fixed
>
> board/sunxi/board.c | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 4f5747c34a..5e2f6ae902 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char *name)
> return ret;
> }
> #endif
> +
> +#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
> defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
> +
> +#define CUBIE2_LED_BOOT_GPIO "PH20"
> +static int gpio_boot_led;
> +
> +void __led_init(led_id_t mask, int state)
> +{
> + int ret;
> +
> + if (mask != CONFIG_LED_STATUS_BOOT)
> + return;
> +
> + ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
> &gpio_boot_led);
> +
> + if (ret)
> + return;
> +
> + ret = gpio_request(gpio_boot_led, "boot_led");
> + if (ret == -1) {
> + debug("[gpio_request] Error:%d\n", ret);
> + return;
> + }
> +
> + ret = gpio_direction_output(gpio_boot_led, 1);
> + if (ret == -1) {
> + debug("[gpio_direction_output] Error:%d\n", ret);
> + return;
> + }
> + __led_set(mask, state);
> +}
> +
> +void __led_set(led_id_t mask, int state)
> +{
> + if (mask != CONFIG_LED_STATUS_BOOT)
> + return;
> +
> + gpio_set_value(gpio_boot_led, state);
> +}
> +
> +void __led_toggle(led_id_t mask)
> +{
> + if (mask != CONFIG_LED_STATUS_BOOT)
> + return;
> +
> + gpio_set_value(gpio_boot_led, !gpio_get_value(gpio_boot_led));
> +}
> +
> +#endif
> --
> 2.25.1
>
>
[PATCH v2] Cubieboard2:SUN7I:Add LED BOOT support
This feature makes it possible to assign one of
LED1(PH20) and LED2(PH21) to BOOT process LED.
User should activates the "Enable status LED API" in
"Device Drivers -> LED Support"
Signed-off-by: Javad Rahimi
---
This is my first contributation in open source world.
I'm sorry if I have mistakes in my commits and versioning.
I do my best to learn fast.
Changes in v2:
- Missed braces added
- Unnecessary debug removed
- Some typo fixed
board/sunxi/board.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4f5747c34a..5e2f6ae902 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -1002,3 +1002,52 @@ int board_fit_config_name_match(const char *name)
return ret;
}
#endif
+
+#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT) &&
defined(CONFIG_LED_STATUS_BOARD_SPECIFIC)
+
+#define CUBIE2_LED_BOOT_GPIO "PH20"
+static int gpio_boot_led;
+
+void __led_init(led_id_t mask, int state)
+{
+ int ret;
+
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ ret = gpio_lookup_name(CUBIE2_LED_BOOT_GPIO, NULL, NULL,
&gpio_boot_led);
+
+ if (ret)
+ return;
+
+ ret = gpio_request(gpio_boot_led, "boot_led");
+ if (ret == -1) {
+ debug("[gpio_request] Error:%d\n", ret);
+ return;
+ }
+
+ ret = gpio_direction_output(gpio_boot_led, 1);
+ if (ret == -1) {
+ debug("[gpio_direction_output] Error:%d\n", ret);
+ return;
+ }
+ __led_set(mask, state);
+}
+
+void __led_set(led_id_t mask, int state)
+{
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ gpio_set_value(gpio_boot_led, state);
+}
+
+void __led_toggle(led_id_t mask)
+{
+ if (mask != CONFIG_LED_STATUS_BOOT)
+ return;
+
+ gpio_set_value(gpio_boot_led, !gpio_get_value(gpio_boot_led));
+}
+
+#endif
--
2.25.1
Re: [RESEND RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
Hi Sughosh, Ilias (and all),
On Thu, 2 Dec 2021 at 08:43, Sughosh Ganu wrote:
>
> hi Ilias,
>
> On Wed, 1 Dec 2021 at 17:56, Ilias Apalodimas
> wrote:
>
> > Hi Sughosh,
> >
> > On Thu, Nov 25, 2021 at 12:42:56PM +0530, Sughosh Ganu wrote:
> > > In the FWU Multi Bank Update feature, the information about the
> > > updatable images is stored as part of the metadata, on a separate
> > > partition. Add functions for reading from and writing to the metadata
> > > when the updatable images and the metadata are stored on a block
> > > device which is formated with GPT based partition scheme.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > lib/fwu_updates/fwu_metadata_gpt_blk.c | 716 +
> > > 1 file changed, 716 insertions(+)
> > > create mode 100644 lib/fwu_updates/fwu_metadata_gpt_blk.c
> > >
> > > +#define SECONDARY_VALID 0x2
> >
> >
> > Change those to BIT(0), BIT(1) etc please
> >
>
> Will change.
>
>
> >
> > > +
> > > +#define MDATA_READ (u8)0x1
> > > +#define MDATA_WRITE (u8)0x2
> > > +
> > > +#define IMAGE_ACCEPT_SET (u8)0x1
> > > +#define IMAGE_ACCEPT_CLEAR (u8)0x2
> > > +
> > > +static int gpt_verify_metadata(struct fwu_metadata *metadata, bool
> > pri_part)
> > > +{
> > > + u32 calc_crc32;
> > > + void *buf;
> > > +
> > > + buf = &metadata->version;
> > > + calc_crc32 = crc32(0, buf, sizeof(*metadata) - sizeof(u32));
> > > +
> > > + if (calc_crc32 != metadata->crc32) {
> > > + log_err("crc32 check failed for %s metadata partition\n",
> > > + pri_part ? "primary" : "secondary");
> >
> > I think we can rid of the 'bool pri_part'. It's only used for printing and
> > you can have more that 2 partitions anyway right?
> >
>
> We will have only two partitions for the metadata. But i think looking at
> it now, it is a bit fuzzy on which is the primary metadata partition and
> which is the secondary one. Can we instead print the UniquePartitionGUID of
> the metadata partition instead. That will help in identifying for which
> metadata copy the verification failed. Let me know your thoughts on this.
>
>
> > > + return -1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int gpt_get_metadata_partitions(struct blk_desc *desc,
> >
> >
> > Please add a function descriptions (on following functions as well)
> >
>
> I have added the function descriptions in the fwu_metadata.c, where the
> api's are being defined. Do we need to add the descriptions for the
> functions in this file as well?
>
>
> >
> > > +u32 *primary_mpart,
> > > +u32 *secondary_mpart)
> >
> > u16 maybe? This is the number of gpt partitions with metadata right?
>
>
> Okay.
>
>
> >
> >
> > > +{
> > > + int i, ret;
> > > + u32 nparts, mparts;
I think the 2 variables labels are too similar, it's a source of confusion.
One is a number of entries, the second is a counter. It would be nice
it's a bit more explicit.
> > > + gpt_entry *gpt_pte = NULL;
> > > + const efi_guid_t fwu_metadata_guid = FWU_METADATA_GUID;
> > > +
> > > + ALLOC_CACHE_ALIGN_BUFFER_PAD(gpt_header, gpt_head, 1,
> > > + desc->blksz);
> > > +
> > > + ret = get_gpt_hdr_parts(desc, gpt_head, &gpt_pte);
> > > + if (ret < 0) {
> > > + log_err("Error getting GPT header and partitions\n");
> > > + ret = -EIO;
> > > + goto out;
> > > + }
> > > +
> > > + nparts = gpt_head->num_partition_entries;
> > > + for (i = 0, mparts = 0; i < nparts; i++) {
> > > + if (!guidcmp(&fwu_metadata_guid,
> > > + &gpt_pte[i].partition_type_guid)) {
> > > + ++mparts;
> > > + if (!*primary_mpart)
> > > + *primary_mpart = i + 1;
> > > + else
> > > + *secondary_mpart = i + 1;
> > > + }
> > > + }
> > > +
> > > + if (mparts != 2) {
> > > + log_err("Expect two copies of the metadata instead of
> > %d\n",
> > > + mparts);
> > > + ret = -EINVAL;
> > > + } else {
> > > + ret = 0;
> > > + }
> > > +out:
> > > + free(gpt_pte);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int gpt_get_metadata_disk_part(struct blk_desc *desc,
> > > + struct disk_partition *info,
> > > + u32 part_num)
> > > +{
> > > + int ret;
> > > + char *metadata_guid_str = "8a7a84a0-8387-40f6-ab41-a8b9a5a60d23";
> > > +
> > > + ret = part_get_info(desc, part_num, info);
> > > + if (ret < 0) {
> > > + log_err("Unable to get the partition info for the metadata
> > part %d",
> > > + part_num);
> > > + return -1;
> > > + }
> > > +
> > > +
Re: [RFC PATCH 03/10] FWU: Add metadata structure and functions for accessing metadata
Hi Sughosh,
On Thu, 25 Nov 2021 at 08:03, Sughosh Ganu wrote:
>
> In the FWU Multi Bank Update feature, the information about the
> updatable images is stored as part of the metadata, which is stored on
> a dedicated partition. Add the metadata structure, and functions to
> access the metadata. These are generic API's, and implementations can
> be added based on parameters like how the metadata partition is
> accessed and what type of storage device houses the metadata.
>
> Signed-off-by: Sughosh Ganu
> ---
> include/fwu_metadata.h | 125 +++
> lib/fwu_updates/fwu_metadata.c | 275 +
> 2 files changed, 400 insertions(+)
> create mode 100644 include/fwu_metadata.h
> create mode 100644 lib/fwu_updates/fwu_metadata.c
>
> diff --git a/include/fwu_metadata.h b/include/fwu_metadata.h
> new file mode 100644
> index 00..e692ef7506
> --- /dev/null
> +++ b/include/fwu_metadata.h
> @@ -0,0 +1,125 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#if !defined _FWU_METADATA_H_
nitpicking: prefer #ifndef ?
> +#define _FWU_METADATA_H_
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/**
> + * struct fwu_image_bank_info - firmware image information
> + * @image_uuid: Guid value of the image in this bank
> + * @accepted: Acceptance status of the image
> + * @reserved: Reserved
> + *
> + * The structure contains image specific fields which are
> + * used to identify the image and to specify the image's
> + * acceptance status
> + */
> +struct fwu_image_bank_info {
> + efi_guid_t image_uuid;
> + u32 accepted;
> + u32 reserved;
> +};
> +
> +/**
> + * struct fwu_image_entry - information for a particular type of image
> + * @image_type_uuid: Guid value for identifying the image type
> + * @location_uuid: Guid of the storage volume where the image is located
> + * @img_bank_info: Array containing properties of images
> + *
> + * This structure contains information on various types of updatable
> + * firmware images. Each image type then contains an array of image
> + * information per bank.
> + */
> +struct fwu_image_entry {
> + efi_guid_t image_type_uuid;
> + efi_guid_t location_uuid;
> + struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> +};
> +
> +/**
> + * struct fwu_metadata - Metadata structure for multi-bank updates
> + * @crc32: crc32 value for the metadata
> + * @version: Metadata version
> + * @active_index: Index of the bank currently used for booting images
> + * @previous_active_inde: Index of the bank used before the current bank
> + *being used for booting
> + * @img_entry: Array of information on various firmware images that can
> + * be updated
> + *
> + * This structure is used to store all the needed information for performing
> + * multi bank updates on the platform. This contains info on the bank being
> + * used to boot along with the information needed for identification of
> + * individual images
> + */
> +struct fwu_metadata {
> + u32 crc32;
> + u32 version;
> + u32 active_index;
> + u32 previous_active_index;
> +
> + struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
> +};
> +
> +/**
> + * @get_active_index: get the current active_index value
> + * @update_active_index: update the active_index value
> + * @fill_partition_guid_array: fill the array with guid values of the
> + * partitions found on the storage media
> + * @get_image_alt_num: get the alt number to be used for the image
> + * @metadata_check: check the validity of the metadata partitions
> + * @revert_boot_index: set the active_index to previous_active_index
> + * @set_accept_image: set the accepted bit for the image
> + * @clear_accept_image: clear the accepted bit for the image
> + * @get_metadata() - Get a metadata copy
> + */
> +struct fwu_metadata_ops {
> + int (*get_active_index)(u32 *active_idx);
> +
> + int (*update_active_index)(u32 active_idx);
> +
> + int (*fill_partition_guid_array)(efi_guid_t **part_guid_arr,
> +u32 *nparts);
> +
> + int (*get_image_alt_num)(efi_guid_t image_type_id, u32 update_bank,
> +int *alt_num);
> +
> + int (*metadata_check)(void);
> +
> + int (*revert_boot_index)(u32 *active_idx);
revert_active_index seems a better name (imho)
Is active_idx really needed as an output argument?
One requiring this value could fetch it calling get_active_index ops afterward.
> +
> + int (*set_accept_image)(efi_guid_t *img_type_id);
> +
> + int (*clear_accept_image)(efi_guid_t *img_type_id, u32 bank);
> +
> + int (*get_metadata)(struct fwu_metadata **metadata);
> +};
> +
> +#define FWU_METADATA_GUID \
> + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> +0xa8, 0xb9, 0xa5,
Re: [RFC PATCH 02/10] stm32mp: dfu: Move the ram partitions to the end of the dfu_alt_info variable
On Thu, 25 Nov 2021 at 08:03, Sughosh Ganu wrote:
>
> With the FWU multi bank update feature enabled, the dfu alt no that is
> used to identify the partition to be updated is derived at runtime and
> should match the partition number on the storage media. Achieve this
> by moving the ram partitions to the end of the dfu_alt_info variable.
>
> Signed-off-by: Sughosh Ganu
> ---
> board/st/common/stm32mp_dfu.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
> index 00d1fb8f59..394a2704ee 100644
> --- a/board/st/common/stm32mp_dfu.c
> +++ b/board/st/common/stm32mp_dfu.c
> @@ -102,6 +102,7 @@ static void board_get_alt_info_mtd(struct mtd_info *mtd,
> char *buf)
>
> void set_dfu_alt_info(char *interface, char *devstr)
> {
> + int len;
> struct udevice *dev;
> struct mtd_info *mtd;
>
> @@ -112,9 +113,6 @@ void set_dfu_alt_info(char *interface, char *devstr)
>
> memset(buf, 0, sizeof(buf));
>
> - snprintf(buf, DFU_ALT_BUF_LEN,
> -"ram 0=%s", CONFIG_DFU_ALT_RAM0);
> -
> if (CONFIG_IS_ENABLED(MMC)) {
> if (!uclass_get_device(UCLASS_MMC, 0, &dev))
> board_get_alt_info_mmc(dev, buf);
> @@ -151,6 +149,13 @@ void set_dfu_alt_info(char *interface, char *devstr)
> strncat(buf, "&virt 1=PMIC", DFU_ALT_BUF_LEN);
> }
>
> + len = strlen(buf);
> + if (buf[0] != '\0')
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
> +
> + snprintf(buf + len, DFU_ALT_BUF_LEN,
> +"ram 0=%s", CONFIG_DFU_ALT_RAM0);
s/DFU_ALT_BUF_LEN/DFU_ALT_BUF_LEN - len/
Should check snprintf() return value.
> +
> env_set("dfu_alt_info", buf);
> puts("DFU alt info setting: done\n");
> }
> --
> 2.17.1
>
[PATCH v1 1/1] support rsa3072
This patch support rsa3072.
Signed-off-by: Jamin Lin
---
include/u-boot/rsa.h | 1 +
lib/rsa/rsa-verify.c | 6 ++
tools/image-sig-host.c | 7 +++
3 files changed, 14 insertions(+)
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index 7556aa5b4b..bb56c2243c 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -110,6 +110,7 @@ int padding_pss_verify(struct image_sign_info *info,
#define RSA_DEFAULT_PADDING_NAME "pkcs-1.5"
#define RSA2048_BYTES (2048 / 8)
+#define RSA3072_BYTES (3072 / 8)
#define RSA4096_BYTES (4096 / 8)
/* This is the minimum/maximum key size we support, in bits */
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 83f7564101..4fe487d7e5 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -588,6 +588,12 @@ U_BOOT_CRYPTO_ALGO(rsa2048) = {
.verify = rsa_verify,
};
+U_BOOT_CRYPTO_ALGO(rsa3072) = {
+ .name = "rsa3072",
+ .key_len = RSA3072_BYTES,
+ .verify = rsa_verify,
+};
+
U_BOOT_CRYPTO_ALGO(rsa4096) = {
.name = "rsa4096",
.key_len = RSA4096_BYTES,
diff --git a/tools/image-sig-host.c b/tools/image-sig-host.c
index 8ed6998dab..d0133aec4c 100644
--- a/tools/image-sig-host.c
+++ b/tools/image-sig-host.c
@@ -55,6 +55,13 @@ struct crypto_algo crypto_algos[] = {
.add_verify_data = rsa_add_verify_data,
.verify = rsa_verify,
},
+ {
+ .name = "rsa3072",
+ .key_len = RSA3072_BYTES,
+ .sign = rsa_sign,
+ .add_verify_data = rsa_add_verify_data,
+ .verify = rsa_verify,
+ },
{
.name = "rsa4096",
.key_len = RSA4096_BYTES,
--
2.17.1
[PATCH v1 0/1] support rsa3072
This patch set supports rsa3072. Jamin Lin (1): support rsa3072 include/u-boot/rsa.h | 1 + lib/rsa/rsa-verify.c | 6 ++ tools/image-sig-host.c | 7 +++ 3 files changed, 14 insertions(+) -- 2.17.1
[PATCH v1 1/1] support rsa3072
This patch set support rsa3072.
Signed-off-by: Jamin Lin
---
common/image-sig.c | 7 +++
include/u-boot/rsa.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/common/image-sig.c b/common/image-sig.c
index e4bbac55c1..c94854ef8b 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -85,6 +85,13 @@ struct crypto_algo crypto_algos[] = {
.add_verify_data = rsa_add_verify_data,
.verify = rsa_verify,
},
+ {
+ .name = "rsa3072",
+ .key_len = RSA3072_BYTES,
+ .sign = rsa_sign,
+ .add_verify_data = rsa_add_verify_data,
+ .verify = rsa_verify,
+ },
{
.name = "rsa4096",
.key_len = RSA4096_BYTES,
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index 2d3024d8b7..d561e5f8ca 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -135,6 +135,7 @@ static inline int padding_pss_verify(struct image_sign_info
*info,
#define RSA_DEFAULT_PADDING_NAME "pkcs-1.5"
#define RSA2048_BYTES (2048 / 8)
+#define RSA3072_BYTES (3072 / 8)
#define RSA4096_BYTES (4096 / 8)
/* This is the minimum/maximum key size we support, in bits */
--
2.17.1
[PATCH v1 0/1] support rsa3072
support rsa3072 Jamin Lin (1): support rsa3072 common/image-sig.c | 7 +++ include/u-boot/rsa.h | 1 + 2 files changed, 8 insertions(+) -- 2.17.1
Aw: Re: debugging crash for arm64
Hi,
thanks for answer, but it seems it is there
arch/arm/mach-rockchip/rk3568/rk3568.c:50: .attrs =
PTE_BLOCK_MEMTYPE(MT_NORMAL) |
arch/arm/mach-rockchip/rk3568/rk3568.c:56: .attrs =
PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
arch/arm/mach-rockchip/rk3568/rk3568.c:63: .attrs =
PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
or is there a mem-region not defined? if yes which?
static struct mm_region rk3568_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
.size = 0xf000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
.virt = 0xf000UL,
.phys = 0xf000UL,
.size = 0x1000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
.virt = 0x3,
.phys = 0x3,
.size = 0x0c0c0,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* List terminator */
0,
}
};
struct mm_region *mem_map = rk3568_mem_map;
regards Frank
> Gesendet: Mittwoch, 08. Dezember 2021 um 12:49 Uhr
> Von: "Joakim Tjernlund"
> An: "Frank Wunderlich" , "u-boot@lists.denx.de"
>
> Betreff: Re: debugging crash for arm64
>
> Just had the same and you are probably missing to map that mem area to the
> MMU. grep for PTE_BLOCK_MEMTYPE in board
> and you will see how to.
> That said, I think the error msg in u-boot can be a bit better, some SEGV msg
> perhaps.
>
> Jocke
>
>
> From: U-Boot on behalf of Frank Wunderlich
>
> Sent: 08 December 2021 12:12
> To: u-boot@lists.denx.de
> Subject: debugging crash for arm64
>
> Hi,
>
> i got a crash on uboot while running reset-command in rk3568 board
> (bananapi-r2 pro, currently not in upstream).
>
> maybe a callback is missing (e.g. reset_cpu())??
>
> i tried to analyse it using the documentation:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu-boot.readthedocs.io%2Fen%2Flatest%2Fdevelop%2Fcrash_dumps.html&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C59463e6ea58d41f0ca9008d9ba3b9a99%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637745587442544318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2PrM0CxcISTGINRz2DvLtMXB0UWow0x%2Bl0y58JkpkK0%3D&reserved=0
>
> Resetting CPU ...
>
> resetting ...
> "Synchronous Abort" handler, esr 0x9645
> elr: 00a25f78 lr : 00a25f48 (reloc)
> elr: 7ff94f78 lr : 7ff94f48
> x0 : fdd2 x1 : 1401
> x2 : fdb9 x3 : 7df5cd48
> x4 : 7df4fe88 x5 : 7df5c710
> x6 : 001a x7 : 7df459f0
> x8 : 0001 x9 : 000c
> x10: 000186a0 x11: ffd0
> x12: 0010 x13: 0001869f
> x14: 7ff70158 x15: 0021
> x16: 7ff94f2c x17:
> x18: 7df4fdd0 x19:
> x20: 0001 x21:
> x22: 7df5ddd0 x23: 0001
> x24: 7ffe8800 x25:
> x26: x27:
> x28: 7df5e980 x29: 7df45990
>
> Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)
>
> $ echo 'Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)' |
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 scripts/decodecode
> Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)
> All code
>
>0: d65f03c0ret
>4: d5033fbfdmb sy
>8: b9400661ldr w1, [x19, #4]
>c: 529d9502mov w2, #0xeca8 // #60584
> 10:* b8206822str w2, [x1, x0]<-- trapping
> instruction
>
> Code starting with the faulting instruction
> ===
>0: b8206822str w2, [x1, x0]
>
>
> now i'm here
>
> "Now lets use the locations provided by the elr and lr registers after
> subtracting the relocation offset to find out where in the code the crash
> occurred and from where it was invoked."
>
> does that means that i have to subtract values of first 2 lines of trace?
>
> 0x7ff94f78 - 0x00a25f78 = 0x7F56F000
>
> "File u-boot.map contains the memory layout of the U-Boot binary. Here we
> find these lines:"
>
> this is not clear enough for me too...i did not found 0x7F56F000 in the file.
>
> i expect to do anything with the address in the disassembled code
> (0xb8206822), but i do not know what :p
>
> i've uploaded the matching u-boot.map and u-boot.dbg (output of objdump) here:
>
> https://nam11.safelinks.protecti
Re: debugging crash for arm64
Just had the same and you are probably missing to map that mem area to the MMU. grep for PTE_BLOCK_MEMTYPE in board and you will see how to. That said, I think the error msg in u-boot can be a bit better, some SEGV msg perhaps. Jocke From: U-Boot on behalf of Frank Wunderlich Sent: 08 December 2021 12:12 To: u-boot@lists.denx.de Subject: debugging crash for arm64 Hi, i got a crash on uboot while running reset-command in rk3568 board (bananapi-r2 pro, currently not in upstream). maybe a callback is missing (e.g. reset_cpu())?? i tried to analyse it using the documentation: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu-boot.readthedocs.io%2Fen%2Flatest%2Fdevelop%2Fcrash_dumps.html&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C59463e6ea58d41f0ca9008d9ba3b9a99%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637745587442544318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2PrM0CxcISTGINRz2DvLtMXB0UWow0x%2Bl0y58JkpkK0%3D&reserved=0 Resetting CPU ... resetting ... "Synchronous Abort" handler, esr 0x9645 elr: 00a25f78 lr : 00a25f48 (reloc) elr: 7ff94f78 lr : 7ff94f48 x0 : fdd2 x1 : 1401 x2 : fdb9 x3 : 7df5cd48 x4 : 7df4fe88 x5 : 7df5c710 x6 : 001a x7 : 7df459f0 x8 : 0001 x9 : 000c x10: 000186a0 x11: ffd0 x12: 0010 x13: 0001869f x14: 7ff70158 x15: 0021 x16: 7ff94f2c x17: x18: 7df4fdd0 x19: x20: 0001 x21: x22: 7df5ddd0 x23: 0001 x24: 7ffe8800 x25: x26: x27: x28: 7df5e980 x29: 7df45990 Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822) $ echo 'Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)' | CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 scripts/decodecode Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822) All code 0: d65f03c0ret 4: d5033fbfdmb sy 8: b9400661ldr w1, [x19, #4] c: 529d9502mov w2, #0xeca8 // #60584 10:* b8206822str w2, [x1, x0]<-- trapping instruction Code starting with the faulting instruction === 0: b8206822str w2, [x1, x0] now i'm here "Now lets use the locations provided by the elr and lr registers after subtracting the relocation offset to find out where in the code the crash occurred and from where it was invoked." does that means that i have to subtract values of first 2 lines of trace? 0x7ff94f78 - 0x00a25f78 = 0x7F56F000 "File u-boot.map contains the memory layout of the U-Boot binary. Here we find these lines:" this is not clear enough for me too...i did not found 0x7F56F000 in the file. i expect to do anything with the address in the disassembled code (0xb8206822), but i do not know what :p i've uploaded the matching u-boot.map and u-boot.dbg (output of objdump) here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%2F10rJbjWNdkYTA_pjnfXEADIZO-7yo4ZhC%3Fusp%3Dsharing&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7C59463e6ea58d41f0ca9008d9ba3b9a99%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637745587442544318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZTv1TcijNfXF7Ft2TG0hcw0MGTyFQvF9X2XeWlO2gxk%3D&reserved=0 regards Frank
debugging crash for arm64
Hi, i got a crash on uboot while running reset-command in rk3568 board (bananapi-r2 pro, currently not in upstream). maybe a callback is missing (e.g. reset_cpu())?? i tried to analyse it using the documentation: https://u-boot.readthedocs.io/en/latest/develop/crash_dumps.html Resetting CPU ... resetting ... "Synchronous Abort" handler, esr 0x9645 elr: 00a25f78 lr : 00a25f48 (reloc) elr: 7ff94f78 lr : 7ff94f48 x0 : fdd2 x1 : 1401 x2 : fdb9 x3 : 7df5cd48 x4 : 7df4fe88 x5 : 7df5c710 x6 : 001a x7 : 7df459f0 x8 : 0001 x9 : 000c x10: 000186a0 x11: ffd0 x12: 0010 x13: 0001869f x14: 7ff70158 x15: 0021 x16: 7ff94f2c x17: x18: 7df4fdd0 x19: x20: 0001 x21: x22: 7df5ddd0 x23: 0001 x24: 7ffe8800 x25: x26: x27: x28: 7df5e980 x29: 7df45990 Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822) $ echo 'Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822)' | CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 scripts/decodecode Code: d65f03c0 d5033fbf b9400661 529d9502 (b8206822) All code 0: d65f03c0ret 4: d5033fbfdmb sy 8: b9400661ldr w1, [x19, #4] c: 529d9502mov w2, #0xeca8 // #60584 10:* b8206822str w2, [x1, x0]<-- trapping instruction Code starting with the faulting instruction === 0: b8206822str w2, [x1, x0] now i'm here "Now lets use the locations provided by the elr and lr registers after subtracting the relocation offset to find out where in the code the crash occurred and from where it was invoked." does that means that i have to subtract values of first 2 lines of trace? 0x7ff94f78 - 0x00a25f78 = 0x7F56F000 "File u-boot.map contains the memory layout of the U-Boot binary. Here we find these lines:" this is not clear enough for me too...i did not found 0x7F56F000 in the file. i expect to do anything with the address in the disassembled code (0xb8206822), but i do not know what :p i've uploaded the matching u-boot.map and u-boot.dbg (output of objdump) here: https://drive.google.com/drive/folders/10rJbjWNdkYTA_pjnfXEADIZO-7yo4ZhC?usp=sharing regards Frank
Re: [RFC PATCH 05/10] FWU: stm32mp1: Add helper functions for accessing metadata
hi Patrick,
On Tue, 7 Dec 2021 at 20:03, Patrick DELAUNAY
wrote:
> Hi Sanghosh
>
> On 11/25/21 8:01 AM, Sughosh Ganu wrote:
> > Add helper functions needed for accessing the metadata which contains
> > information on the updatable images. These functions have been added
> > for the STM32MP157C-DK2 board which has the updatable images on the
> > uSD card, formatted as GPT partitions.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > board/st/stm32mp1/stm32mp1.c | 63
> > include/fwu_metadata.h | 3 ++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> > index 84592677e4..a6884d2772 100644
> > --- a/board/st/stm32mp1/stm32mp1.c
> > +++ b/board/st/stm32mp1/stm32mp1.c
> > @@ -7,6 +7,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -14,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -23,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -938,3 +941,63 @@ static void board_copro_image_process(ulong
> fw_image, size_t fw_size)
> > }
> >
> > U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_COPRO, board_copro_image_process);
> > +
> > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > +
> > +int fwu_plat_get_update_index(u32 *update_idx)
> > +{
> > + int ret;
> > + u32 active_idx;
> > +
> > + ret = fwu_get_active_index(&active_idx);
> > +
> > + if (ret < 0)
> > + return -1;
> > +
> > + *update_idx = active_idx ^= 0x1;
> > +
> > + return ret;
> > +}
> > +
> > +int fwu_plat_get_blk_desc(struct blk_desc **desc)
> > +{
> > + int ret;
> > + struct mmc *mmc;
> > + struct udevice *dev;
> > +
> > + /*
> > + * Initial support is being added for the DK2
> > + * platform
> > + */
> > + if (CONFIG_IS_ENABLED(TARGET_ST_STM32MP15x) &&
> > + (of_machine_is_compatible("st,stm32mp157c-dk2"))) {
> > + ret = uclass_get_device(UCLASS_MMC, 0, &dev);
> > + if (ret)
> > + return -1;
> > +
> > + mmc = mmc_get_mmc_dev(dev);
> > + if (!mmc)
> > + return -1;
> > +
> > + if (mmc_init(mmc))
> > + return -1;
> > +
> > + *desc = mmc_get_blk_desc(mmc);
> > + if (!*desc)
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +struct fwu_metadata_ops *get_plat_fwu_metadata_ops(void)
> > +{
> > + if (CONFIG_IS_ENABLED(TARGET_ST_STM32MP15x) &&
> > + (of_machine_is_compatible("st,stm32mp157c-dk2"))) {
> > + return &fwu_gpt_blk_ops;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +#endif /* CONFIG_FWU_MULTI_BANK_UPDATE */
> > diff --git a/include/fwu_metadata.h b/include/fwu_metadata.h
> > index e692ef7506..6a5e814ab6 100644
> > --- a/include/fwu_metadata.h
> > +++ b/include/fwu_metadata.h
> > @@ -122,4 +122,7 @@ int fwu_accept_image(efi_guid_t *img_type_id);
> > int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > int fwu_get_metadata(struct fwu_metadata **metadata);
> >
> > +int fwu_plat_get_update_index(u32 *update_idx);
> > +int fwu_plat_get_blk_desc(struct blk_desc **desc);
> > +
> > #endif /* _FWU_METADATA_H_ */
>
>
> One general question:
>
>
> How we can handle the EV1 board with 2 MMC devices => eMMC (mmc1) /
> SDCard (mmc0)
>
The current metadata structure has a location_uuid, which can be used to
identify the device which will contain the banks of firmware images. The
current code for DK2 board does not have this implemented, but adding this
logic should not be difficult. Based on the location_uuid, we can identify
the device and return the blk_desc of that device.
>
> and how to managed HW partition of eMMC boot1 / boot2
>
> => for eMMC boot, the TF-A BL2 is located in these eMMC hw partition.
>
>
> in the serie, I see only support for partition > 0 => partition in GPT
> but not the update of eMMC boot partition.
>
I will get back to you on this. The current specification is dealing with
GPT formatted devices. Need to check how the boot partitions will be
supported for multiple banks of images.
-sughosh
>
> Regards
>
> Patrick
>
>
RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hello Sahil, > -Original Message- > From: Sahil Malhotra (OSS) > Sent: Wednesday, December 8, 2021 7:12 AM > To: Michael Walle ; Sahil Malhotra (OSS) > > Cc: Clément Faure ; Gaurav Jain ; > Pankaj Gupta ; Priyanka Jain ; u- > b...@lists.denx.de; Varun Sethi ; Ye Li ; > ZHIZHIKIN Andrey > Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature > > > Hi Michael, > > -Original Message- > From: Michael Walle > Sent: Monday, November 29, 2021 11:17 PM > To: Sahil Malhotra (OSS) > Cc: Clément Faure ; Gaurav Jain ; > Pankaj Gupta ; Priyanka Jain ; u- > b...@lists.denx.de; Varun Sethi ; Ye Li ; > ZHIZHIKIN Andrey > Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature > > Hi Sahil, > > Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS): > > Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS): > >>> Could you please add some description what this is doing and for > >>> what this is intended? To have a "DTB overlay feature", it is enough > >>> to just enable CONFIG_OF_LIBFDT_OVERLAY. > >> I will add some description, and yes for DTB overlay feature, it is > >> enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step > >> before booting the kernel that's why also have to enable > >> CONFIG_OF_SYSTEM_SETUP. > > > >> Ok. What will the overlay do? Could you give an example? > > This overlay will be disabling the crypto nodes which will be used by > > optee in secure world, so that linux should not use it. > > > > > >>> Apparently you're adding an overlay passed by optee. Doesn't this > >>> have to be applied to u-boot's control dtb too? > >> Yes, we will be applying the overlay passed by optee, yes it will be > >> applied to dtb which will be passed to uboot for kernel booting. > > > >> If I read this patch correctly, you're modifying the DT before you > >> jump to linux. But I was asking whether you also have to modify the > >> DT which is used by u-boot. Eg. if you disable some kind of crypto > >> nodes (because optee will use them in secure world), this also have > >> to communicated to u-boot, not only linux, no? > > Yes, I got your point now, and is very valid, but as of now for u-boot > > we are just using the first available node for communicating with CAAM > > leaving other job rings as it is. > > So we need not to apply overlay to DTB used by uboot. > > > But we should do the correct thing, so that u-boot and linux doesn't see a > different version of the device tree. > > > Also what do you mean with "the first available node"? > > There is already a new CAAM driver for u-boot pending, see > > https://lore.kernel.org/u-boot/2025070014.17586-1-gaurav.j...@nxp.com/ > > Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this > job > ring. Same job ring can be used by Linux once it boots up. Just for clarification: by saying "Very first CAAM Job Ring" do you actually mean JR0? If the BootROM logic with respect to JR reservation for LS family does not differ from i.MX8M family (which I assume does not), then why can't the logic be implemented in the same way proposed by Gaurav [1] here as well? DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World. OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over. This is however valid only if OP-TEE implementation for LS matches to one from i.MX8M family. If it OP-TEE does differ, then I suggest this should be rather addressed there before U-Boot, since OP-TEE have all facilities in place to reserve JR nodes as they are needed. > > Regards, > Sahil Malhotra -- andrey Link: [1]: https://lore.kernel.org/u-boot/20211207074129.10955-9-gaurav.j...@nxp.com
When is the console connected during spl run?
Hello experts,
I was following u-boot-spl program on our board hoping somewhere serial port
will be initialized and also the console using the serial port.
In our FPGA board, there is a small 8 BM on-chip memory in place of DDR and
I can use two 51kB sram on-chip.
The spl program is loaded on the first sram and bss and gd was allocated on
sdram (actually it's on-chip sram as I said).
I followed u-boot-spl program using some debug prints on memory until it
goes into board_init_r function (in common/spl/spl.c).
Just inside the function I see this line
void board_init_r(gd_t *dummy1, ulong dummy2)
{
u32 spl_boot_list[] = {
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
};
struct spl_image_info spl_image;
int ret;
debug(">>" SPL_TPL_PROMPT "board_init_r()\n");
spl_set_bd();
The "debug" macro is the one defined in include/log.h and because I added
"#define DEBUG" to the make argument, it uses this definition.
#else /* _DEBUG */
/*
* Output a debug text when condition "cond" is met. The "cond" should be
* computed by a preprocessor in the best case, allowing for the best
* optimization.
*/
#define debug_cond(cond, fmt, args...) \
({ \
if (cond) \
printf(pr_fmt(fmt), ##args);\
})
#endif /* _DEBUG */
So, am I supposed to see the message in my console? From the reset to this
point, I couldn't see any serial port initialization (this is arm64 and
board_init_f just returned doing nothing. No need to initialize sdram.).
How should I connect uart to console? Should I add my own board_init_f
function and do serial_init and console_init_f there?
Any comment or help will be really appreciated.
Thank you!
Chan Kim
Re: [PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
On Fri, Dec 3, 2021 at 8:13 PM Simon Glass wrote: > > Hi Peter, > > On Fri, 3 Dec 2021 at 05:20, Peter Robinson wrote: > > > > On Fri, Dec 3, 2021 at 3:32 AM Simon Glass wrote: > > > > > > Hi Peter, > > > > > > On Wed, 1 Dec 2021 at 07:23, Peter Robinson wrote: > > > > > > > > On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak > > > > wrote: > > > > > > > > > > I have recently started testing booting U-Boot from SPI on my > > > > > gru-kevin > > > > > (as opposed to chainloading it from vendor coreboot + depthcharge) and > > > > > brought it to a better working state based on an initial support patch > > > > > from Marty [1][2] and some follow-up work by Simon [3]. > > > > > > > > > > I tried to keep them as the git author when I took things from their > > > > > work, but squashing other changes into those and rewriting commit > > > > > messages makes things a bit weird in my opinion, especially for > > > > > keeping > > > > > their signoff. Do tell me if there is a better way to that. > > > > > > > > > > As the Kevin and Bob boards are very similar. I assumed the config and > > > > > devicetree changes will be appropriate for Bob as well, and applied > > > > > them > > > > > to it first. I do not have a Bob, so could not test on one myself, but > > > > > Simon did test an earlier version of this and it appears to work [4]. > > > > > > > > > > Other useful things for these boards: > > > > > - Patch to fix a hang when usb controllers exit [5] > > > > > - Series to support HS400ES mode as HS400 training fails [6] > > > > > - Hack to skip eMMC reinitialization so it keeps working [7] > > > > > > > > Is there docs updates to be done in doc/chromium/ for this so people > > > > know how to use it ? > > > > > > This is for bare-metal use though, so it isn't anything to do with > > > Chromium at present. > > > > So are there docs for how do this? I didn't manage to find any, > > although the docs I find can be a little over the place in U-Boot so > > they may be there and I missed them, so either way docs would be fab. > > There are SPI instructions at doc/board/rockchip but they are pretty > 'one way'. So you would need a way to get your old SPI-flash contents > back when it doesn't work, because I don't think these platforms > support SD boot. I use a 'servo' board and a Dediprog em100 SPI > emulator. I know that kevin does not support CCD (Close-Case > Debugging) so you cannot program the SPI flash that way... I thought there was a different process for the chtomebooks than the usual rockchip route. Do the rockchip chomebooks support writing to a space in SPI and chainloading like some of the other arm chtomebooks did (I think tegra/samsung but my memory fades there)? I think it would be useful to document the rockchip chromebook options somewhere so that people that are interested in using the U-Boot option have some resources, we've had a few queries over the time around that. Peter
