Re: [PATCH v3 03/18] mkeficapsule: Add a --version argument
On Fri, 21 Jun 2024 at 02:06, Simon Glass wrote:
>
> Tools should have an option to obtain the version, so add this to the
> mkeficapsule tool.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> doc/mkeficapsule.1 | 4
> tools/mkeficapsule.c | 8 +++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
> index c4c2057d5c7..c3d0f21488a 100644
> --- a/doc/mkeficapsule.1
> +++ b/doc/mkeficapsule.1
> @@ -87,6 +87,10 @@ Generate a firmware revert empty capsule
> .BI "-o\fR,\fB --capoemflag "
> Capsule OEM flag, value between 0x to 0x
>
> +.TP
> +.BR -V ", " --version
> +Print version information and exit.
> +
> .TP
> .BR -h ", " --help
> Print a help message
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 6a261ff549d..c112ae2de8d 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -21,6 +21,8 @@
> #include
> #include
>
> +#include
> +
> #include "eficapsule.h"
>
> static const char *tool_name = "mkeficapsule";
> @@ -28,7 +30,7 @@ static const char *tool_name = "mkeficapsule";
> efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
>
> -static const char *opts_short = "g:i:I:v:p:c:m:o:dhARD";
> +static const char *opts_short = "g:i:I:v:p:c:m:o:dhARDV";
>
> enum {
> CAPSULE_NORMAL_BLOB = 0,
> @@ -70,6 +72,7 @@ static void print_usage(void)
> "\t-R, --fw-revert firmware revert capsule, takes no GUID,
> no image blob\n"
> "\t-o, --capoemflag Capsule OEM Flag, an integer between
> 0x and 0x\n"
> "\t-D, --dump-capsule dump the contents of the
> capsule headers\n"
> + "\t-V, --version show version number\n"
> "\t-h, --help print a help message\n",
> tool_name);
> }
> @@ -969,6 +972,9 @@ int main(int argc, char **argv)
> case 'D':
> capsule_dump = true;
> break;
> + case 'V':
> + printf("mkeficapsule version %s\n", PLAIN_VERSION);
> + exit(EXIT_SUCCESS);
> default:
> print_usage();
> exit(EXIT_SUCCESS);
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v3 10/18] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
On Fri, 21 Jun 2024 at 08:32, Ilias Apalodimas wrote: > > Hi Simon, > > On Fri, 21 Jun 2024 at 02:06, Simon Glass wrote: > > > > It does not make sense to enable all SHA algorithms unless they are > > needed. It bloats the code and in this case, causes chromebook_link to > > fail to build. That board does use the TPM, but not with measured boot, > > nor EFI. > > > > Since EFI_TCG2_PROTOCOL already selects these options, we just need to > > add them to MEASURED_BOOT as well. > > > > Note that the original commit combines refactoring and new features, > > which makes it hard to see what is going on. > > > > Fixes: 97707f12fda tpm: Support boot measurements > > Reviewed-by: Heinrich Schuchardt > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v2) > > There was a discussion in the previous version, bout enabling these on > CMD_TPM as they are required. Or switch this to an imply instead so you can disable it ? Regards /Ilias > > Thanks > /Ilias > > >
Re: [PATCH v2] arm: dts: k3-am625-beagleplay: Package TIFS Stub
Nishanth,
On Jun 19, 2024 at 13:47:36 -0500, Nishanth Menon wrote:
> On 10:26-20240618, Dhruva Gole wrote:
> > Add support for packaging the TIFS Stub as it's required for basic Low
> > Power Modes like Deep Sleep.
>
> What the heck is tifs stub?
> https://docs.u-boot.org/en/latest/search.html?q=tifs_keywords=yes=default
> I see no mention of the same?
I agree, documentation is lacking, will be sure to add that.
> >
> > Acked-by: Neha Malcom Francis
> > Signed-off-by: Dhruva Gole
> > ---
> >
> > No changes from v1, just picked Neha's ack and rebased on master again.
> > Link to v1:
> > https://lore.kernel.org/u-boot/20240612062351.3690091-1-d-g...@ti.com/
> >
> > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++-
> > 1 file changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > index fb2032068d1c..5e2248a4a668 100644
> > --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > @@ -69,6 +69,23 @@
> > };
> > };
> >
> > + tifsstub-gp {
> > + filename = "tifsstub.bin_gp";
> > + ti-secure-rom {
> > + content = <_gp>;
> > + core = "secure";
> > + load = <0x6>;
> > + sw-rev = ;
> > + keyfile = "ti-degenerate-key.pem";
> > + tifsstub;
> > + };
> > + tifsstub_gp: tifsstub-gp.bin {
> > + filename = "ti-sysfw/ti-fs-stub-firmware-am62x-gp.bin";
> > + type = "blob-ext";
> > + optional;
> > + };
> > + };
> > +
> > ti-spl_unsigned {
> > filename = "tispl.bin_unsigned";
> > pad-byte = <0xff>;
> > @@ -105,6 +122,19 @@
> > };
> > };
> >
> > + tifsstub-gp {
> > + description = "tifsstub";
> > + type = "firmware";
> > + arch = "arm32";
> > + compression = "none";
> > + os = "tifsstub-gp";
> > + load = <0x9dc0>;
> > + entry = <0x9dc0>;
>
> two issues with this:
> a) if the tifsstub-gp is not automatically consumed by tifs by the time
> u-boot is up or kernel is up, this is going to get clobbered by OS
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts#n78
> Should be updated before this is done.
This won't be much of a concern, the TIFS Stub is loaded into the R5 ATCM as
soon as the DM R5 core comes up [0] : See the Deep Sleep Exit part, it
talks about this stub.
[0]
https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/09_01_00/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Power_Management/pm_sw_arch.html
> b) Documentation update - please always make sure you update
> documentation when doing this kind of change
> https://docs.u-boot.org/en/latest/board/beagle/am62x_beagleplay.html#image-formats
Will do.
--
Best regards,
Dhruva Gole
Re: [PATCH v3 10/18] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
Hi Simon, On Fri, 21 Jun 2024 at 02:06, Simon Glass wrote: > > It does not make sense to enable all SHA algorithms unless they are > needed. It bloats the code and in this case, causes chromebook_link to > fail to build. That board does use the TPM, but not with measured boot, > nor EFI. > > Since EFI_TCG2_PROTOCOL already selects these options, we just need to > add them to MEASURED_BOOT as well. > > Note that the original commit combines refactoring and new features, > which makes it hard to see what is going on. > > Fixes: 97707f12fda tpm: Support boot measurements > Reviewed-by: Heinrich Schuchardt > Signed-off-by: Simon Glass > --- > > (no changes since v2) There was a discussion in the previous version, bout enabling these on CMD_TPM as they are required. Thanks /Ilias > > Changes in v2: > - Put the conditions under EFI_TCG2_PROTOCOL > - Consider MEASURED_BOOT too > > boot/Kconfig | 4 > lib/Kconfig | 4 > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/boot/Kconfig b/boot/Kconfig > index 6f3096c15a6..b061891e109 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -734,6 +734,10 @@ config LEGACY_IMAGE_FORMAT > config MEASURED_BOOT > bool "Measure boot images and configuration when booting without EFI" > depends on HASH && TPM_V2 > + select SHA1 > + select SHA256 > + select SHA384 > + select SHA512 > help > This option enables measurement of the boot process when booting > without UEFI . Measurement involves creating cryptographic hashes > diff --git a/lib/Kconfig b/lib/Kconfig > index 189e6eb31aa..568892fce44 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -438,10 +438,6 @@ config TPM > bool "Trusted Platform Module (TPM) Support" > depends on DM > imply DM_RNG > - select SHA1 > - select SHA256 > - select SHA384 > - select SHA512 > help > This enables support for TPMs which can be used to provide security > features for your board. The TPM can be connected via LPC or I2C > -- > 2.34.1 >
Re: [PATCH v2] arm: dts: k3-am625-beagleplay: Package TIFS Stub
Bryan,
On Jun 19, 2024 at 16:44:48 -0500, Bryan Brattlof wrote:
> On June 18, 2024 thus sayeth Dhruva Gole:
> > Add support for packaging the TIFS Stub as it's required for basic Low
> > Power Modes like Deep Sleep.
> >
> > Acked-by: Neha Malcom Francis
> > Signed-off-by: Dhruva Gole
> > ---
> >
> > No changes from v1, just picked Neha's ack and rebased on master again.
> > Link to v1:
> > https://lore.kernel.org/u-boot/20240612062351.3690091-1-d-g...@ti.com/
> >
> > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++-
> > 1 file changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > index fb2032068d1c..5e2248a4a668 100644
> > --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> > @@ -69,6 +69,23 @@
> > };
> > };
> >
> > + tifsstub-gp {
> > + filename = "tifsstub.bin_gp";
> > + ti-secure-rom {
> > + content = <_gp>;
> > + core = "secure";
> > + load = <0x6>;
> > + sw-rev = ;
> > + keyfile = "ti-degenerate-key.pem";
> > + tifsstub;
> > + };
> > + tifsstub_gp: tifsstub-gp.bin {
> > + filename = "ti-sysfw/ti-fs-stub-firmware-am62x-gp.bin";
> > + type = "blob-ext";
> > + optional;
> > + };
> > + };
> > +
> > ti-spl_unsigned {
> > filename = "tispl.bin_unsigned";
> > pad-byte = <0xff>;
> > @@ -105,6 +122,19 @@
> > };
> > };
> >
> > + tifsstub-gp {
> > + description = "tifsstub";
> > + type = "firmware";
> > + arch = "arm32";
> > + compression = "none";
> > + os = "tifsstub-gp";
> > + load = <0x9dc0>;
> > + entry = <0x9dc0>;
>
> Is this stub position independent? Or is this address compiled in at
> build time? We have some variants of 62x that don't have these addresses
> backed by DRAM.
The stub is not position independent and is indeed fixed at build time.
Can you talk more about these am62x variants that don't have the address
backed by DRAM? What would be the suggested address range in those
cases?
For BeaglePlay atleast I don't see an issue. So I don't think we'd have
issues with this patch in particular?
--
Best regards,
Dhruva Gole
Re: [PATCH] include/fastboot.h: add missing types.h include
On Thu, Jun 20, 2024 at 8:51 PM Caleb Connolly wrote: > > Fixes a compile error when building with only the TCP fastboot implementation. > > Signed-off-by: Caleb Connolly > --- Reviewed-by: Sam Protsenko > include/fastboot.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/fastboot.h b/include/fastboot.h > index 2ca1b907a54d..b106d6177493 100644 > --- a/include/fastboot.h > +++ b/include/fastboot.h > @@ -11,8 +11,10 @@ > */ > #ifndef _FASTBOOT_H_ > #define _FASTBOOT_H_ > > +#include > + > #define FASTBOOT_VERSION "0.4" > > /* > * Signals u-boot fastboot code to send multiple responses by > -- > 2.45.0 >
[PATCH] usb: dwc3: respect role-switch-default-mode
* Factor out the common pattern of checking the dr_mode property on
the usb node and it's parent
* Respect the usb-role-switch property, rather than requiring dr_mode be
set
* Override OTG mode with the value in role-switch-default-mode
The devicetree bindings don't dictate that dr_mode is a required
property, but the dwc3 driver would refuse to probe if it was unset
(this breaks the Qualcomm RB2 board which doesn't set it).
Here, we update the driver to respect the other properties that can be
used to describe the controller, and more gracefully handle some of the
edge cases.
Signed-off-by: Caleb Connolly
---
Cc: Ilias Apalodimas
Cc: Neil Armstrong
---
drivers/usb/dwc3/dwc3-generic.c | 56 +
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index cbb5d61dfb0b..1cf8b90e8bbf 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -49,8 +49,46 @@ struct dwc3_generic_host_priv {
struct dwc3_generic_priv gen_priv;
struct udevice *vbus_supply;
};
+/**
+ * dwc3_get_preferred_dr_mode() - Get the preferred DR mode for the USB node
+ *
+ * Since we don't support dynamic role switching yet in dwc3, this is a
slightly
+ * opinionated wrapper around usb_get_dr_mode() which will respect the
+ * role-switch-default-mode property if it is present and the dr_mode is OTG.
+ *
+ * @child: Node to get the DR mode for
+ */
+static enum usb_dr_mode dwc3_get_preferred_dr_mode(ofnode node)
+{
+ enum usb_dr_mode mode;
+ bool is_role_switch = ofnode_has_property(node, "usb-role-switch");
+
+ mode = usb_get_dr_mode(node);
+ /* Attempt to search the parent node too */
+ if (mode == USB_DR_MODE_UNKNOWN) {
+ node = ofnode_get_parent(node);
+ mode = usb_get_dr_mode(node);
+ is_role_switch |= ofnode_has_property(node, "usb-role-switch");
+ }
+
+ /* If the usb-role-switch property is present, but dr_mode isn't, then
the
+* default is OTG.
+*/
+ if (is_role_switch && mode == USB_DR_MODE_UNKNOWN)
+ mode = USB_DR_MODE_OTG;
+
+ /* Respect the role-switch-default-mode property */
+ if (mode == USB_DR_MODE_OTG && is_role_switch) {
+ mode = usb_get_role_switch_default_mode(node);
+ if (mode == USB_DR_MODE_UNKNOWN)
+ mode = USB_DR_MODE_OTG;
+ }
+
+ return mode;
+}
+
static int dwc3_generic_probe(struct udevice *dev,
struct dwc3_generic_priv *priv)
{
int rc;
@@ -178,17 +216,12 @@ static int dwc3_generic_of_to_plat(struct udevice *dev)
pr_info("No USB maximum speed specified. Using super speed\n");
plat->maximum_speed = USB_SPEED_SUPER;
}
- plat->dr_mode = usb_get_dr_mode(node);
+ plat->dr_mode = dwc3_get_preferred_dr_mode(node);
if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
- /* might be a leaf so check the parent for mode */
- node = dev_ofnode(dev->parent);
- plat->dr_mode = usb_get_dr_mode(node);
- if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
- pr_err("Invalid usb mode setup\n");
- return -ENODEV;
- }
+ pr_err("Invalid usb mode setup\n");
+ return -ENODEV;
}
return 0;
}
@@ -541,12 +574,9 @@ static int dwc3_glue_bind_common(struct udevice *parent,
ofnode node)
int ret;
debug("%s: subnode name: %s\n", __func__, name);
- /* if the parent node doesn't have a mode check the leaf */
- dr_mode = usb_get_dr_mode(dev_ofnode(parent));
- if (!dr_mode)
- dr_mode = usb_get_dr_mode(node);
+ dr_mode = dwc3_get_preferred_dr_mode(node);
if (CONFIG_IS_ENABLED(DM_USB_GADGET) &&
(dr_mode == USB_DR_MODE_PERIPHERAL || dr_mode == USB_DR_MODE_OTG)) {
debug("%s: dr_mode: OTG or Peripheral\n", __func__);
@@ -698,9 +728,9 @@ int dwc3_glue_probe(struct udevice *dev)
while (child) {
enum usb_dr_mode dr_mode;
- dr_mode = usb_get_dr_mode(dev_ofnode(child));
+ dr_mode = dwc3_get_preferred_dr_mode(dev_ofnode(child));
device_find_next_child();
if (ops && ops->glue_configure)
ops->glue_configure(dev, index, dr_mode);
index++;
--
2.45.0
[PATCH] mmc: msm_sdhci: program core_vendor_spec
After resetting the host controller, program in the POR val for this
register just like the Linux driver does.
This seems to help with initialization when running U-Boot as the primary
bootloader on some boards.
Signed-off-by: Caleb Connolly
---
drivers/mmc/msm_sdhci.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 4ce0de6c47d8..8b3188fa20d4 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -31,8 +31,10 @@
#define SDCC_MCI_STATUS2 0x6C
#define SDCC_MCI_STATUS2_MCI_ACT 0x1
#define SDCC_MCI_HC_MODE 0x78
+#define CORE_VENDOR_SPEC_POR_VAL 0xa9c
+
struct msm_sdhc_plat {
struct mmc_config cfg;
struct mmc mmc;
};
@@ -45,21 +47,25 @@ struct msm_sdhc {
struct msm_sdhc_variant_info {
bool mci_removed;
+ u32 core_vendor_spec;
u32 core_vendor_spec_capabilities0;
};
DECLARE_GLOBAL_DATA_PTR;
static int msm_sdc_clk_init(struct udevice *dev)
{
struct msm_sdhc *prv = dev_get_priv(dev);
+ const struct msm_sdhc_variant_info *var_info;
ofnode node = dev_ofnode(dev);
ulong clk_rate;
int ret, i = 0, n_clks;
const char *clk_name;
+ var_info = (void *)dev_get_driver_data(dev);
+
ret = ofnode_read_u32(node, "clock-frequency", (uint *)(_rate));
if (ret)
clk_rate = 20150;
@@ -104,8 +110,11 @@ static int msm_sdc_clk_init(struct udevice *dev)
log_warning("Couldn't set MMC core clock rate: %dE\n", clk_rate
? (int)PTR_ERR((void *)clk_rate) : 0);
return -EINVAL;
}
+ writel_relaxed(CORE_VENDOR_SPEC_POR_VAL,
+ prv->host.ioaddr + var_info->core_vendor_spec);
+
return 0;
}
static int msm_sdc_mci_init(struct msm_sdhc *prv)
@@ -254,14 +263,16 @@ static int msm_sdc_bind(struct udevice *dev)
static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
.mci_removed = false,
+ .core_vendor_spec = 0x10c,
.core_vendor_spec_capabilities0 = 0x11c,
};
static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
.mci_removed = true,
+ .core_vendor_spec = 0x20c,
.core_vendor_spec_capabilities0 = 0x21c,
};
static const struct udevice_id msm_mmc_ids[] = {
--
2.45.0
[PATCH] include/fastboot.h: add missing types.h include
Fixes a compile error when building with only the TCP fastboot implementation. Signed-off-by: Caleb Connolly --- include/fastboot.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/fastboot.h b/include/fastboot.h index 2ca1b907a54d..b106d6177493 100644 --- a/include/fastboot.h +++ b/include/fastboot.h @@ -11,8 +11,10 @@ */ #ifndef _FASTBOOT_H_ #define _FASTBOOT_H_ +#include + #define FASTBOOT_VERSION "0.4" /* * Signals u-boot fastboot code to send multiple responses by -- 2.45.0
Re: [PATCH 3/5] buildman: Support building within a Python venv
On Thu, Jun 20, 2024 at 05:05:30PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 20 Jun 2024 at 08:32, Tom Rini wrote:
> >
> > On Thu, Jun 20, 2024 at 07:19:35AM -0600, Simon Glass wrote:
> >
> > > The Python virtualenv tool sets up a few things in the envronment,
> > > putting its path first in the PATH environment variable and setting up
> > > a sys.prefix different from the sys.base_prefix value.
> > >
> > > At present buildman puts the toolchain path first in PATH so that it can
> > > be found easily during the build. For sandbox this causes problems since
> > > /usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
> > > PATH variable. As a result, the venv is partially disabled.
> > >
> > > The result is that sandbox builds within a venv ignore the venv, e.g.
> > > when looking for packages.
> > >
> > > Correct this by detecting the venv and adding the toolchain path after
> > > the venv path.
> > >
> > > Signed-off-by: Simon Glass
> >
> > Why are we using PATH at all in this case? Shouldn't we just be setting
> > CROSS_COMPILE=/full/path/to/the/prefix ?
>
> This is the -p option to buildman. The original commit was:
>
> commit bb1501f2c22c979961b735db775605cccedd98f6
> Author: Simon Glass
> Date: Mon Dec 1 17:34:00 2014 -0700
>
> buildman: Add an option to use the full tool chain path
>
> In some cases there may be multiple toolchains with the same name in the
> path. Provide an option to use the full path in the CROSS_COMPILE
> environment variable.
>
> Note: Wolfgang mentioned that this is dangerous since in some cases there
> may be other tools on the path that are needed. So this is set up as an
> option, not the default. I will need test confirmation (i.e. that this
> commit fixes a real problem) before merging it.
>
> As to why we don't always do this, well that is back in the mists of
> time, 10 years ago.
>
> BTW, this is raising a point ("let's change the behaviour") separate
> from the goal of this commit, which is to fix a problem with venv,
> albeit that if we made -p the only option, then we could potentially
> drop all PATH changes. Perhaps toolchains are built differently now,
> such that they always invoke their tools using the same prefix and
> dir?
Wait, I'm confused. buildman internally updates its own PATH to avoid
calling CROSS_COMPILE with the full path due to a concern about
toolchain bugs?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
On Thu, Jun 20, 2024 at 05:05:29PM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 19 Jun 2024 at 09:32, Tom Rini wrote: > > > > On Tue, Jun 18, 2024 at 09:03:37PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 18 Jun 2024 at 08:15, Tom Rini wrote: > > > > > > > > On Tue, Jun 18, 2024 at 06:43:51AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 17 Jun 2024 at 11:16, Tom Rini wrote: > > > > > > > > > > > > On Mon, Jun 17, 2024 at 07:53:22AM -0600, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Sat, 15 Jun 2024 at 01:03, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Heinrich > > > > > > > > > > > > > > > > resending the reply, I accidentally sent half of the message... > > > > > > > > > > > > > > > > On Fri, 14 Jun 2024 at 12:04, Heinrich Schuchardt > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 14.06.24 09:01, Ilias Apalodimas wrote: > > > > > > > > > > On Fri, 14 Jun 2024 at 09:59, Heinrich Schuchardt > > > > > > > > > > wrote: > > > > > > > > > >> > > > > > > > > > >> On 6/14/24 08:03, Ilias Apalodimas wrote: > > > > > > > > > >>> Hi Simon, > > > > > > > > > >>> > > > > > > > > > >>> On Mon, 10 Jun 2024 at 17:59, Simon Glass > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > > > It does not make sense to enable all SHA algorithms > > > > > > > > > unless they are > > > > > > > > > needed. It bloats the code and in this case, causes > > > > > > > > > chromebook_link to > > > > > > > > > fail to build. That board does use the TPM, but not with > > > > > > > > > measured boot, > > > > > > > > > nor EFI. > > > > > > > > > > > > > > > > > > Since EFI_TCG2_PROTOCOL already selects these options, > > > > > > > > > we just need to > > > > > > > > > add them to MEASURED_BOOT as well. > > > > > > > > > > > > > > > > > > Note that the original commit combines refactoring and > > > > > > > > > new features, > > > > > > > > > which makes it hard to see what is going on. > > > > > > > > > > > > > > > > > > Fixes: 97707f12fda tpm: Support boot measurements > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > - Put the conditions under EFI_TCG2_PROTOCOL > > > > > > > > > - Consider MEASURED_BOOT too > > > > > > > > > > > > > > > > > > boot/Kconfig | 4 > > > > > > > > > lib/Kconfig | 4 > > > > > > > > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > > > > index 6f3096c15a6..b061891e109 100644 > > > > > > > > > --- a/boot/Kconfig > > > > > > > > > +++ b/boot/Kconfig > > > > > > > > > @@ -734,6 +734,10 @@ config LEGACY_IMAGE_FORMAT > > > > > > > > > config MEASURED_BOOT > > > > > > > > > bool "Measure boot images and configuration > > > > > > > > > when booting without EFI" > > > > > > > > > depends on HASH && TPM_V2 > > > > > > > > > + select SHA1 > > > > > > > > > + select SHA256 > > > > > > > > > + select SHA384 > > > > > > > > > + select SHA512 > > > > > > > > > help > > > > > > > > > This option enables measurement of the boot > > > > > > > > > process when booting > > > > > > > > > without UEFI . Measurement involves creating > > > > > > > > > cryptographic hashes > > > > > > > > > diff --git a/lib/Kconfig b/lib/Kconfig > > > > > > > > > index 189e6eb31aa..568892fce44 100644 > > > > > > > > > --- a/lib/Kconfig > > > > > > > > > +++ b/lib/Kconfig > > > > > > > > > @@ -438,10 +438,6 @@ config TPM > > > > > > > > > bool "Trusted Platform Module (TPM) Support" > > > > > > > > > depends on DM > > > > > > > > > imply DM_RNG > > > > > > > > > - select SHA1 > > > > > > > > > - select SHA256 > > > > > > > > > - select SHA384 > > > > > > > > > - select SHA512 > > > > > > > > > >>> > > > > > > > > > >>> I am not sure this is the right way to deal with your > > > > > > > > > >>> problem. > > > > > > > > > >>> The TPM main functionality is to measure and extend PCRs, > > > > > > > > > >>> so sha > > > > > > > > > >>> is really required. To make things even worse, you don't > > > > > > > > > >>> know the PCR > > > > > > > > > >>> banks that are enabled beforehand. This is a runtime > > > > > > > > > >>> config of the > > > > > > > > > >>> TPM. > > > > > > > > > >> > > > > > > > > > >> If neither MEASURED_BOOT nor EFI_TCG2_PROTOCOL is > > > > > > > > > >> selected, U-Boot > > > > > > > > > >> cannot extend PCRs. So it seems fine to let these two > > > > > > > > > >> select the > >
Re: [PATCH] RFC: Add a tag for the world builds
On Thu, Jun 20, 2024 at 05:05:26PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jun 2024 at 08:39, Tom Rini wrote: > > > > On Thu, Jun 20, 2024 at 07:33:46AM -0600, Simon Glass wrote: > > > > > Currently the world builds run on all runners, including faster and > > > slower ones. > > > > > > The difference can be quite dramatic, with some builders 4x as fast as > > > others, resulting in just one world build taking between 20 minutes and > > > an hour and 20 minutes. > > > > > > Add a tag so that we can select which builders run these CPU-intensive > > > jobs. > > > > > > With this tag we can also increase CPU utilisation by running multiple > > > QEMU tests in parallel. Currently these tests leave most machines fairly > > > idle, since we cannot run more than one world build on a machine. > > > > > > Signed-off-by: Simon Glass > > > > This conflicts I think with Jiaxun's desire to make our GitLab job > > runnable on the public runners too, and where we'll end up with 10 world > > build jobs ala Azure. > > It probably doesn't actually conflict, although I am not sure if one > can add a tag to jobs that run on public runners. I mean conceptually at least as it will likely be slower to build the world as 10 jobs than as 4 jobs. -- Tom signature.asc Description: PGP signature
[PATCH v3 00/18] Bug-fixes for a few boards
This series includes fixes to get some rockchip and nvidia boards working again. It also drops the broken Beaglebone Black config and provides a devicetree fix for coral (x86). Changes in v3: - Use BLOBLIST instead of OF_BLOBLIST - Cut the patch down to bare bones - Split out the refactoring into a separate patch - Drop the non-dcache optimisation, since the cache should normally be on Changes in v2: - Put the conditions under EFI_TCG2_PROTOCOL - Consider MEASURED_BOOT too - Remove the superfluous if() and drop the debug() as well - Use 'phase' instead of 'stage' - Add new patch to correct memory size in SPL - Drop patch "regulator: rk8xx: Fix incorrect parameter" - Rewrite boneblack patch to onstead drop the target and update docs Simon Glass (18): binman: Support an assumed size for missing binaries binman: Make Intel ME default to position 0x1000 mkeficapsule: Add a --version argument binman: Collect the version number for mkeficapsule binman: Deal with mkeficapsule being missing binman: Return failure when a usage() message is generated binman: Keep the efi_capsule input file x86: Set up some assumed sizes for binary blobs nvidia: nyan-big: Disable debug UART tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL rockchip: veyron: Add logging for power init power: regulator: Handle autoset in regulators_enable_boot_on() fdt: Correct condition for bloblist existing spl: Allow ATF to work when dcache is disabled rockchip: Ensure memory size is available in RK3399 SPL rockchip: Avoid #ifdefs in RK3399 SPL rockchip: bob: kevin: Disable dcache in SPL Drop the special am335x_boneblack_vboot target arch/x86/dts/u-boot.dtsi | 5 ++ board/google/veyron/veyron.c | 30 +++ board/ti/am335x/MAINTAINERS| 1 - boot/Kconfig | 4 + common/spl/spl_atf.c | 3 +- configs/am335x_boneblack_vboot_defconfig | 94 -- configs/am335x_evm_defconfig | 3 +- configs/chromebook_bob_defconfig | 1 + configs/chromebook_kevin_defconfig | 1 + configs/nyan-big_defconfig | 1 - doc/mkeficapsule.1 | 4 + doc/usage/fit/beaglebone_vboot.rst | 21 +++-- drivers/power/regulator/regulator-uclass.c | 2 +- drivers/ram/rockchip/sdram_rk3399.c| 49 ++- lib/Kconfig| 4 - lib/fdtdec.c | 12 ++- tools/binman/binman.rst| 7 ++ tools/binman/btool/mkeficapsule.py | 3 +- tools/binman/entry.py | 1 + tools/binman/etype/blob.py | 7 +- tools/binman/etype/efi_capsule.py | 5 +- tools/binman/etype/intel_descriptor.py | 2 +- tools/binman/ftest.py | 28 +++ tools/binman/test/326_assume_size.dts | 16 tools/binman/test/327_assume_size_ok.dts | 16 tools/mkeficapsule.c | 10 ++- 26 files changed, 168 insertions(+), 162 deletions(-) delete mode 100644 configs/am335x_boneblack_vboot_defconfig create mode 100644 tools/binman/test/326_assume_size.dts create mode 100644 tools/binman/test/327_assume_size_ok.dts -- 2.34.1
Re: [PATCH v2 2/2] board: rockchip: Add FriendlyElec NanoPi R6S
Sebastian Kropatsch writes: > The R6S is very similar to the R6C, the major difference being that > instead of the M.2 NVMe socket on the R6C, the R6S has a second RTL8125BG > Ethernet chip, which uses the same PCIe lanes that the R6C uses for its > M.2 socket. Other minor differences include: > - 12-pin GPIO FPC instead of 30-pin header > - IR receiver (pwm-based) > - 5V fan connector > Other than that, they are the same, which is why the difference in > U-Boot is only the missing NVME config option in the R6S defconfig. > > Please note that I was not able to test this device. I only chose to > add it due to it being a very similar implementation to the R6C, like the > NanoPi R5C and R5S are similar. It should however boot just fine and even > both RTL8125 Ethernet ports should work in U-Boot since RTL8125 is the > same chip used in the R6C, using the rtl8169 driver. Hi Sebastian, it looks like you forgot to include the hunk that includes the board config board/friendlyelec/nanopi-r6s-rk3588s/Kconfig into rk3588/Kconfig. > diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig > b/arch/arm/mach-rockchip/rk3588/Kconfig > index a9e400861a3..051d50e26f6 100644 > --- a/arch/arm/mach-rockchip/rk3588/Kconfig > +++ b/arch/arm/mach-rockchip/rk3588/Kconfig > @@ -257,6 +257,7 @@ config TEXT_BASE > source "board/edgeble/neural-compute-module-6/Kconfig" > source "board/friendlyelec/nanopc-t6-rk3588/Kconfig" > source "board/friendlyelec/nanopi-r6c-rk3588s/Kconfig" > +source "board/friendlyelec/nanopi-r6s-rk3588s/Kconfig" > source "board/indiedroid/nova/Kconfig" > source "board/pine64/quartzpro64-rk3588/Kconfig" > source "board/turing/turing-rk1-rk3588/Kconfig" Other than that, this appears to work great on my Nanopi R6S (with the device tree from linux-6.9), including all three network interfaces, but no working status leds for the rtl8169 ports. I have also noticed the minor inconvenience that only the first two interfaces are initialized with nonzero MAC addresses (because rockchip_setup_macaddr is hardcoded for two interfaces?): > => pci enum > => net list > eth0 : ethernet@fe1c 7a:d9:6d:ad:cb:26 active > eth1 : eth_rtl8169 7a:d9:6d:ad:cb:27 > eth2 : eth_rtl8169 00:00:00:00:00:00 I don't think this is a huge deal as it works fine when manually setting a MAC address and other boards with three or more interfaces (like the NanoPi R5S) also behave that way. What do you think? Best regards Ulli
[PATCH v3 18/18] Drop the special am335x_boneblack_vboot target
Now that am335x_evm boots OK on the Beaglebone black, drop the latter and update the docs to cover the change. Also add a few updates about 'make fit' and drop the note about the security review, as U-Boot's verified boot has had quite extensive review now. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- (no changes since v2) Changes in v2: - Drop patch "regulator: rk8xx: Fix incorrect parameter" - Rewrite boneblack patch to onstead drop the target and update docs board/ti/am335x/MAINTAINERS | 1 - configs/am335x_boneblack_vboot_defconfig | 94 configs/am335x_evm_defconfig | 3 +- doc/usage/fit/beaglebone_vboot.rst | 21 +++--- 4 files changed, 12 insertions(+), 107 deletions(-) delete mode 100644 configs/am335x_boneblack_vboot_defconfig diff --git a/board/ti/am335x/MAINTAINERS b/board/ti/am335x/MAINTAINERS index 219c8715bf1..ed8800a2663 100644 --- a/board/ti/am335x/MAINTAINERS +++ b/board/ti/am335x/MAINTAINERS @@ -3,6 +3,5 @@ M: Tom Rini S: Maintained F: board/ti/am335x/ F: include/configs/am335x_evm.h -F: configs/am335x_boneblack_vboot_defconfig F: configs/am335x_evm_defconfig F: configs/am335x_evm_spiboot_defconfig diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig deleted file mode 100644 index d473a1a793b..000 --- a/configs/am335x_boneblack_vboot_defconfig +++ /dev/null @@ -1,94 +0,0 @@ -CONFIG_ARM=y -CONFIG_ARCH_CPU_INIT=y -# CONFIG_SPL_USE_ARCH_MEMCPY is not set -# CONFIG_SPL_USE_ARCH_MEMSET is not set -CONFIG_ARCH_OMAP2PLUS=y -CONFIG_TI_COMMON_CMD_OPTIONS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00 -CONFIG_SF_DEFAULT_SPEED=2400 -CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack" -CONFIG_AM33XX=y -CONFIG_CLOCK_SYNTHESIZER=y -CONFIG_SPL=y -CONFIG_ENV_OFFSET_REDUND=0x28 -CONFIG_TIMESTAMP=y -CONFIG_FIT_SIGNATURE=y -CONFIG_FIT_VERBOSE=y -CONFIG_SYS_BOOTM_LEN=0x100 -CONFIG_DISTRO_DEFAULTS=y -CONFIG_AUTOBOOT_KEYED=y -CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" -CONFIG_AUTOBOOT_DELAY_STR="d" -CONFIG_AUTOBOOT_STOP_STR=" " -CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd" -CONFIG_SYS_CONSOLE_INFO_QUIET=y -CONFIG_ARCH_MISC_INIT=y -CONFIG_SPL_SYS_MALLOC=y -CONFIG_SPL_SYS_MALLOC_SIZE=0x80 -CONFIG_SPL_MUSB_NEW=y -# CONFIG_SPL_NAND_SUPPORT is not set -CONFIG_SPL_NET=y -CONFIG_SPL_NET_VCI_STRING="AM33xx U-Boot SPL" -CONFIG_SPL_OS_BOOT=y -CONFIG_SPL_FALCON_BOOT_MMCSD=y -CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR=0x1700 -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR=0x1500 -CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS=0x200 -CONFIG_CMD_SPL=y -CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 -# CONFIG_CMD_SETEXPR is not set -CONFIG_BOOTP_DNS2=y -CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y -CONFIG_ENV_OVERWRITE=y -CONFIG_ENV_IS_IN_MMC=y -CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_SYS_RELOC_GD_ENV_ADDR=y -CONFIG_SYS_MMC_ENV_DEV=1 -CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_VERSION_VARIABLE=y -CONFIG_NET_RETRY_COUNT=10 -CONFIG_BOOTP_SEND_HOSTNAME=y -# CONFIG_SPL_BLK is not set -CONFIG_BOOTCOUNT_LIMIT=y -CONFIG_SYS_BOOTCOUNT_BE=y -CONFIG_DFU_MMC=y -CONFIG_DFU_RAM=y -CONFIG_USB_FUNCTION_FASTBOOT=y -CONFIG_DM_I2C=y -CONFIG_MISC=y -CONFIG_SYS_I2C_EEPROM_ADDR=0x50 -# CONFIG_SPL_DM_MMC is not set -CONFIG_MMC_OMAP_HS=y -CONFIG_MTD=y -CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_WINBOND=y -CONFIG_PHY_ATHEROS=y -CONFIG_PHY_SMSC=y -CONFIG_PHY_GIGE=y -CONFIG_MII=y -CONFIG_DRIVER_TI_CPSW=y -CONFIG_DM_PMIC=y -# CONFIG_SPL_DM_PMIC is not set -CONFIG_PMIC_TPS65217=y -CONFIG_SPL_POWER_TPS65910=y -CONFIG_SPI=y -CONFIG_DM_SPI=y -CONFIG_OMAP3_SPI=y -CONFIG_TIMER=y -CONFIG_OMAP_TIMER=y -CONFIG_USB=y -CONFIG_DM_USB_GADGET=y -CONFIG_SPL_DM_USB_GADGET=y -CONFIG_USB_MUSB_HOST=y -CONFIG_USB_MUSB_GADGET=y -CONFIG_USB_MUSB_TI=y -CONFIG_USB_GADGET=y -CONFIG_SPL_USB_GADGET=y -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" -CONFIG_USB_GADGET_VENDOR_NUM=0x0451 -CONFIG_USB_GADGET_PRODUCT_NUM=0xd022 -CONFIG_USB_ETHER=y -CONFIG_SPL_USB_ETHER=y -CONFIG_LZO=y diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index d243cb16e72..cabc181460a 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -13,6 +13,8 @@ CONFIG_AM335X_USB0_PERIPHERAL=y CONFIG_AM335X_USB1=y CONFIG_SPL=y CONFIG_TIMESTAMP=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y CONFIG_SPL_LOAD_FIT=y CONFIG_SYS_BOOTM_LEN=0x100 CONFIG_DISTRO_DEFAULTS=y @@ -119,5 +121,4 @@ CONFIG_SPL_USB_ETHER=y CONFIG_WDT=y # CONFIG_SPL_WDT is not set CONFIG_DYNAMIC_CRC_TABLE=y -CONFIG_RSA=y CONFIG_LZO=y diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index cd6bb141910..1360c71803c 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -67,18 +67,20 @@ a. Set up the environment variable to point to your toolchain. You will need
[PATCH v3 17/18] rockchip: bob: kevin: Disable dcache in SPL
This causes a hang, so disable it. Unfortunately the RAM-size fix does
not resolve the problem and I am unsure what is wrong. As soon as the
cache is enabled the board appears to hang.
Fixes: 6d8cdfd1536 ("rockchip: spl: Enable caches to speed up checksum
validation")
Signed-off-by: Simon Glass
---
(no changes since v1)
configs/chromebook_bob_defconfig | 1 +
configs/chromebook_kevin_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index acfe3934104..b2ecfa6050c 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SPL_SYS_DCACHE_OFF=y
CONFIG_COUNTER_FREQUENCY=2400
CONFIG_ARCH_ROCKCHIP=y
CONFIG_TEXT_BASE=0x0020
diff --git a/configs/chromebook_kevin_defconfig
b/configs/chromebook_kevin_defconfig
index 95fdb418d82..da748e4f022 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
CONFIG_SKIP_LOWLEVEL_INIT=y
CONFIG_COUNTER_FREQUENCY=2400
CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SPL_SYS_DCACHE_OFF=y
CONFIG_TEXT_BASE=0x0020
CONFIG_SPL_GPIO=y
CONFIG_NR_DRAM_BANKS=1
--
2.34.1
[PATCH v3 16/18] rockchip: Avoid #ifdefs in RK3399 SPL
The code here is confusing due to large blocks which are #ifdefed out.
Add a function phase_sdram_init() which returns whether SDRAM init
should happen in the current phase, using that as needed to control the
code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass
---
Changes in v3:
- Split out the refactoring into a separate patch
- Drop the non-dcache optimisation, since the cache should normally be on
drivers/ram/rockchip/sdram_rk3399.c | 47 -
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 3c4e20f4e80..2f37dd712e7 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -63,8 +64,6 @@ struct chan_info {
};
struct dram_info {
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
u32 pwrup_srefresh_exit[2];
struct chan_info chan[2];
struct clk ddr_clk;
@@ -75,7 +74,6 @@ struct dram_info {
struct rk3399_pmusgrf_regs *pmusgrf;
struct rk3399_ddr_cic_regs *cic;
const struct sdram_rk3399_ops *ops;
-#endif
struct ram_info info;
struct rk3399_pmugrf_regs *pmugrf;
};
@@ -92,9 +90,6 @@ struct sdram_rk3399_ops {
struct rk3399_sdram_params *params);
};
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
-
struct rockchip_dmc_plat {
#if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_rockchip_rk3399_dmc dtplat;
@@ -191,6 +186,17 @@ struct io_setting {
},
};
+/**
+ * phase_sdram_init() - Check if this is the phase where SDRAM init happens
+ *
+ * Returns: true to do SDRAM init in this phase, false to not
+ */
+static bool phase_sdram_init(void)
+{
+ return spl_phase() == PHASE_TPL ||
+ (!IS_ENABLED(CONFIG_TPL) && !spl_in_proper());
+}
+
static struct io_setting *
lpddr4_get_io_settings(const struct rk3399_sdram_params *params, u32 mr5)
{
@@ -3024,7 +3030,7 @@ static int rk3399_dmc_of_to_plat(struct udevice *dev)
struct rockchip_dmc_plat *plat = dev_get_plat(dev);
int ret;
- if (!CONFIG_IS_ENABLED(OF_REAL))
+ if (!CONFIG_IS_ENABLED(OF_REAL) || !phase_sdram_init())
return 0;
ret = dev_read_u32_array(dev, "rockchip,sdram-params",
@@ -3138,22 +3144,24 @@ static int rk3399_dmc_init(struct udevice *dev)
return 0;
}
-#endif
static int rk3399_dmc_probe(struct udevice *dev)
{
struct dram_info *priv = dev_get_priv(dev);
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
- if (rk3399_dmc_init(dev))
- return 0;
-#endif
- priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
- debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
- priv->info.base = CFG_SYS_SDRAM_BASE;
- priv->info.size =
- rockchip_sdram_size((phys_addr_t)>pmugrf->os_reg2);
+ if (phase_sdram_init()) {
+ if (rk3399_dmc_init(dev))
+ return 0;
+ } else {
+ priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+ debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
+ }
+
+ if (!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
+ priv->info.base = CFG_SYS_SDRAM_BASE;
+ priv->info.size =
+ rockchip_sdram_size((ulong)>pmugrf->os_reg2);
+ }
return 0;
}
@@ -3181,10 +3189,7 @@ U_BOOT_DRIVER(dmc_rk3399) = {
.id = UCLASS_RAM,
.of_match = rk3399_dmc_ids,
.ops = _dmc_ops,
-#if defined(CONFIG_TPL_BUILD) || \
- (!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
.of_to_plat = rk3399_dmc_of_to_plat,
-#endif
.probe = rk3399_dmc_probe,
.priv_auto = sizeof(struct dram_info),
#if defined(CONFIG_TPL_BUILD) || \
--
2.34.1
[PATCH v3 15/18] rockchip: Ensure memory size is available in RK3399 SPL
At present gd->ram_size is 0 in SPL, meaning that it is not possible to
enable the cache. Correct this by always populating the RAM size
correctly.
This increases code size by about 500 bytes in SPL, since it must call
the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass
---
Changes in v3:
- Cut the patch down to bare bones
Changes in v2:
- Add new patch to correct memory size in SPL
drivers/ram/rockchip/sdram_rk3399.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 02cc4a38cf0..3c4e20f4e80 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -3142,19 +3142,19 @@ static int rk3399_dmc_init(struct udevice *dev)
static int rk3399_dmc_probe(struct udevice *dev)
{
+ struct dram_info *priv = dev_get_priv(dev);
+
#if defined(CONFIG_TPL_BUILD) || \
(!defined(CONFIG_TPL) && defined(CONFIG_SPL_BUILD))
if (rk3399_dmc_init(dev))
return 0;
-#else
- struct dram_info *priv = dev_get_priv(dev);
-
+#endif
priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
debug("%s: pmugrf = %p\n", __func__, priv->pmugrf);
priv->info.base = CFG_SYS_SDRAM_BASE;
priv->info.size =
rockchip_sdram_size((phys_addr_t)>pmugrf->os_reg2);
-#endif
+
return 0;
}
--
2.34.1
[PATCH v3 14/18] spl: Allow ATF to work when dcache is disabled
The dcache may not be enabled in SPL. Add a check to avoid trying to use an undefined function. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- (no changes since v1) common/spl/spl_atf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c index 3bdd013a35f..9afe6456bc4 100644 --- a/common/spl/spl_atf.c +++ b/common/spl/spl_atf.c @@ -204,7 +204,8 @@ static void __noreturn bl31_entry(uintptr_t bl31_entry, uintptr_t bl32_entry, fdt_addr); raw_write_daif(SPSR_EXCEPTION_MASK); - dcache_disable(); + if (!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) + dcache_disable(); atf_entry(bl31_params, (void *)fdt_addr); } -- 2.34.1
[PATCH v3 13/18] fdt: Correct condition for bloblist existing
On some boards, the bloblist is created in SPL once SDRAM is ready. It
cannot be accessed until that point, so is not available early in SPL.
Add a condition to avoid a hang in this case.
This fixes a hang in chromebook_coral
Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Simon Glass
---
Changes in v3:
- Use BLOBLIST instead of OF_BLOBLIST
Changes in v2:
- Use 'phase' instead of 'stage'
lib/fdtdec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index b2c59ab3818..e16d1819449 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1669,8 +1669,16 @@ int fdtdec_setup(void)
{
int ret = -ENOENT;
- /* If allowing a bloblist, check that first */
- if (CONFIG_IS_ENABLED(BLOBLIST)) {
+ /*
+* If allowing a bloblist, check that first. This would be better
+* handled with an OF_BLOBLIST Kconfig, but that caused far too much
+* argument, so add a hack here, used e.g. by chromebook_coral
+* The necessary test is whether the previous phase passed a bloblist,
+* not whether this phase creates one.
+*/
+ if (CONFIG_IS_ENABLED(BLOBLIST) &&
+ (spl_prev_phase() != PHASE_TPL ||
+!IS_ENABLED(CONFIG_TPL_BLOBLIST))) {
ret = bloblist_maybe_init();
if (!ret) {
gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
--
2.34.1
[PATCH v3 12/18] power: regulator: Handle autoset in regulators_enable_boot_on()
With a recent change, regulators_enable_boot_on() returns an error if a
regulator is already set. Check for and handle this situation.
Fixes: d99fb64a98a power: regulator: Only run autoset once for each regulator
Reviewed-by: Jonas Karlman
Reviewed-by: Quentin Schulz
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/power/regulator/regulator-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 77d101f262e..d9e1fb68295 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -518,7 +518,7 @@ int regulators_enable_boot_on(bool verbose)
dev;
uclass_next_device()) {
ret = regulator_autoset(dev);
- if (ret == -EMEDIUMTYPE) {
+ if (ret == -EMEDIUMTYPE || ret == -EALREADY) {
ret = 0;
continue;
}
--
2.34.1
[PATCH v3 11/18] rockchip: veyron: Add logging for power init
Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can
be enabled.
Signed-off-by: Simon Glass
Reviewed-by: Quentin Schulz
---
(no changes since v2)
Changes in v2:
- Remove the superfluous if() and drop the debug() as well
board/google/veyron/veyron.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/board/google/veyron/veyron.c b/board/google/veyron/veyron.c
index 32dbcdc4d10..6d4c9debdee 100644
--- a/board/google/veyron/veyron.c
+++ b/board/google/veyron/veyron.c
@@ -29,44 +29,38 @@ static int veyron_init(void)
int ret;
ret = regulator_get_by_platname("vdd_arm", );
- if (ret) {
- debug("Cannot set regulator name\n");
- return ret;
- }
+ if (ret)
+ return log_msg_ret("vdd", ret);
/* Slowly raise to max CPU voltage to prevent overshoot */
ret = regulator_set_value(dev, 120);
if (ret)
- return ret;
+ return log_msg_ret("s12", ret);
udelay(175); /* Must wait for voltage to stabilize, 2mV/us */
ret = regulator_set_value(dev, 140);
if (ret)
- return ret;
+ return log_msg_ret("s14", ret);
udelay(100); /* Must wait for voltage to stabilize, 2mV/us */
ret = rockchip_get_clk();
if (ret)
- return ret;
+ return log_msg_ret("clk", ret);
clk.id = PLL_APLL;
ret = clk_set_rate(, 18);
if (IS_ERR_VALUE(ret))
- return ret;
+ return log_msg_ret("s18", ret);
ret = regulator_get_by_platname("vcc33_sd", );
- if (ret) {
- debug("Cannot get regulator name\n");
- return ret;
- }
+ if (ret)
+ return log_msg_ret("vcc", ret);
ret = regulator_set_value(dev, 330);
if (ret)
- return ret;
+ return log_msg_ret("s33", ret);
ret = regulators_enable_boot_on(false);
- if (ret) {
- debug("%s: Cannot enable boot on regulators\n", __func__);
- return ret;
- }
+ if (ret)
+ return log_msg_ret("boo", ret);
return 0;
}
@@ -81,7 +75,7 @@ int board_early_init_r(void)
if (!fdt_node_check_compatible(gd->fdt_blob, 0, "google,veyron")) {
ret = veyron_init();
if (ret)
- return ret;
+ return log_msg_ret("vey", ret);
}
#endif
/*
--
2.34.1
[PATCH v3 10/18] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
It does not make sense to enable all SHA algorithms unless they are needed. It bloats the code and in this case, causes chromebook_link to fail to build. That board does use the TPM, but not with measured boot, nor EFI. Since EFI_TCG2_PROTOCOL already selects these options, we just need to add them to MEASURED_BOOT as well. Note that the original commit combines refactoring and new features, which makes it hard to see what is going on. Fixes: 97707f12fda tpm: Support boot measurements Reviewed-by: Heinrich Schuchardt Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Put the conditions under EFI_TCG2_PROTOCOL - Consider MEASURED_BOOT too boot/Kconfig | 4 lib/Kconfig | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 6f3096c15a6..b061891e109 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -734,6 +734,10 @@ config LEGACY_IMAGE_FORMAT config MEASURED_BOOT bool "Measure boot images and configuration when booting without EFI" depends on HASH && TPM_V2 + select SHA1 + select SHA256 + select SHA384 + select SHA512 help This option enables measurement of the boot process when booting without UEFI . Measurement involves creating cryptographic hashes diff --git a/lib/Kconfig b/lib/Kconfig index 189e6eb31aa..568892fce44 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -438,10 +438,6 @@ config TPM bool "Trusted Platform Module (TPM) Support" depends on DM imply DM_RNG - select SHA1 - select SHA256 - select SHA384 - select SHA512 help This enables support for TPMs which can be used to provide security features for your board. The TPM can be connected via LPC or I2C -- 2.34.1
[PATCH v3 09/18] nvidia: nyan-big: Disable debug UART
This cannot be enabled early in boot since some other init is needed. At this point it is unclear exactly what init is needed, so disable the debug UART to avoid a hang. Signed-off-by: Simon Glass --- (no changes since v1) configs/nyan-big_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/nyan-big_defconfig b/configs/nyan-big_defconfig index 1483d17d975..4dec710cf8d 100644 --- a/configs/nyan-big_defconfig +++ b/configs/nyan-big_defconfig @@ -17,7 +17,6 @@ CONFIG_TEGRA124=y CONFIG_TARGET_NYAN_BIG=y CONFIG_TEGRA_GPU=y CONFIG_SYS_LOAD_ADDR=0x82408000 -CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_FIT_BEST_MATCH=y CONFIG_BOOTSTAGE=y -- 2.34.1
[PATCH v3 08/18] x86: Set up some assumed sizes for binary blobs
Add assumed sizes so that Binman can check that the U-Boot binaries do
not grow too large.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/dts/u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index e0de3318091..fdd28979e0b 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -24,9 +24,11 @@
#ifdef CONFIG_HAVE_INTEL_ME
intel-descriptor {
filename = CONFIG_FLASH_DESCRIPTOR_FILE;
+ assume-size = <0x1000>;
};
intel-me {
filename = CONFIG_INTEL_ME_FILE;
+ assume-size = <0x1ff000>;
};
#endif
#ifdef CONFIG_TPL
@@ -87,6 +89,7 @@
#ifdef CONFIG_HAVE_MRC
intel-mrc {
offset = ;
+ assume-size = <0x2fc94>;
};
#endif
#ifdef CONFIG_FSP_VERSION1
@@ -98,6 +101,7 @@
#ifdef CONFIG_FSP_VERSION2
intel-descriptor {
filename = CONFIG_FLASH_DESCRIPTOR_FILE;
+ assume-size = <4096>;
};
intel-ifwi {
filename = CONFIG_IFWI_INPUT_FILE;
@@ -139,6 +143,7 @@
intel-vga {
filename = CONFIG_VGA_BIOS_FILE;
offset = ;
+ assume-size = <0x1>;
};
#endif
#ifdef CONFIG_HAVE_VBT
--
2.34.1
[PATCH v3 07/18] binman: Keep the efi_capsule input file
There is no need to remove input files. It makes it harder to diagnose
failures. Keep the payload file.
There is no test for this condition, but one could be added.
Signed-off-by: Simon Glass
Fixes: b617611b27a ("binman: capsule: Add support for generating...")
---
(no changes since v1)
tools/binman/etype/efi_capsule.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/binman/etype/efi_capsule.py
b/tools/binman/etype/efi_capsule.py
index 47da5da324b..03e55cbc4d9 100644
--- a/tools/binman/etype/efi_capsule.py
+++ b/tools/binman/etype/efi_capsule.py
@@ -148,7 +148,6 @@ class Entry_efi_capsule(Entry_section):
self.fw_version,
self.oem_flags)
if ret is not None:
-os.remove(payload)
return tools.read_file(capsule_fname)
else:
# Bintool is missing; just use the input data as the output
--
2.34.1
[PATCH v3 06/18] binman: Return failure when a usage() message is generated
The tool must return an error code when invalid arguments are provided,
otherwise binman has no way of knowing that anything went wrong.
Correct this.
Signed-off-by: Simon Glass
Fixes: fab430be2f4 ("tools: add mkeficapsule command for UEFI...")
---
(no changes since v1)
tools/mkeficapsule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index c112ae2de8d..f28008a0829 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -977,7 +977,7 @@ int main(int argc, char **argv)
exit(EXIT_SUCCESS);
default:
print_usage();
- exit(EXIT_SUCCESS);
+ exit(EXIT_FAILURE);
}
}
--
2.34.1
[PATCH v3 05/18] binman: Deal with mkeficapsule being missing
Tools cannot be assumed to be present. Add a check for this with the
mkeficpasule tool.
Signed-off-by: Simon Glass
Fixes: b617611b27a ("binman: capsule: Add support for generating...")
---
(no changes since v1)
tools/binman/etype/efi_capsule.py | 4
1 file changed, 4 insertions(+)
diff --git a/tools/binman/etype/efi_capsule.py
b/tools/binman/etype/efi_capsule.py
index e3203717822..47da5da324b 100644
--- a/tools/binman/etype/efi_capsule.py
+++ b/tools/binman/etype/efi_capsule.py
@@ -150,6 +150,10 @@ class Entry_efi_capsule(Entry_section):
if ret is not None:
os.remove(payload)
return tools.read_file(capsule_fname)
+else:
+# Bintool is missing; just use the input data as the output
+self.record_missing_bintool(self.mkeficapsule)
+return data
def AddBintools(self, btools):
self.mkeficapsule = self.AddBintool(btools, 'mkeficapsule')
--
2.34.1
[PATCH v3 04/18] binman: Collect the version number for mkeficapsule
Now that this tool has a version number, collect it. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/mkeficapsule.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/binman/btool/mkeficapsule.py b/tools/binman/btool/mkeficapsule.py index ef1da638df1..f7e5a886849 100644 --- a/tools/binman/btool/mkeficapsule.py +++ b/tools/binman/btool/mkeficapsule.py @@ -33,7 +33,8 @@ class Bintoolmkeficapsule(bintool.Bintool): commandline, or through a config file. """ def __init__(self, name): -super().__init__(name, 'mkeficapsule tool for generating capsules') +super().__init__(name, 'mkeficapsule tool for generating capsules', + r'mkeficapsule version (.*)') def generate_capsule(self, image_index, image_guid, hardware_instance, payload, output_fname, priv_key, pub_key, -- 2.34.1
[PATCH v3 03/18] mkeficapsule: Add a --version argument
Tools should have an option to obtain the version, so add this to the
mkeficapsule tool.
Signed-off-by: Simon Glass
---
(no changes since v1)
doc/mkeficapsule.1 | 4
tools/mkeficapsule.c | 8 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
index c4c2057d5c7..c3d0f21488a 100644
--- a/doc/mkeficapsule.1
+++ b/doc/mkeficapsule.1
@@ -87,6 +87,10 @@ Generate a firmware revert empty capsule
.BI "-o\fR,\fB --capoemflag "
Capsule OEM flag, value between 0x to 0x
+.TP
+.BR -V ", " --version
+Print version information and exit.
+
.TP
.BR -h ", " --help
Print a help message
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 6a261ff549d..c112ae2de8d 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -21,6 +21,8 @@
#include
#include
+#include
+
#include "eficapsule.h"
static const char *tool_name = "mkeficapsule";
@@ -28,7 +30,7 @@ static const char *tool_name = "mkeficapsule";
efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
-static const char *opts_short = "g:i:I:v:p:c:m:o:dhARD";
+static const char *opts_short = "g:i:I:v:p:c:m:o:dhARDV";
enum {
CAPSULE_NORMAL_BLOB = 0,
@@ -70,6 +72,7 @@ static void print_usage(void)
"\t-R, --fw-revert firmware revert capsule, takes no GUID, no
image blob\n"
"\t-o, --capoemflag Capsule OEM Flag, an integer between 0x
and 0x\n"
"\t-D, --dump-capsule dump the contents of the capsule
headers\n"
+ "\t-V, --version show version number\n"
"\t-h, --help print a help message\n",
tool_name);
}
@@ -969,6 +972,9 @@ int main(int argc, char **argv)
case 'D':
capsule_dump = true;
break;
+ case 'V':
+ printf("mkeficapsule version %s\n", PLAIN_VERSION);
+ exit(EXIT_SUCCESS);
default:
print_usage();
exit(EXIT_SUCCESS);
--
2.34.1
[PATCH v3 02/18] binman: Make Intel ME default to position 0x1000
This cannot ever go at offset 0 since the descriptor is there. Use a
better offset for the ME, as used by link and coral, for example.
This matters when we start using assumed sizes for missing blobs.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/binman/etype/intel_descriptor.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/etype/intel_descriptor.py
b/tools/binman/etype/intel_descriptor.py
index 7fe88a9ec1a..3ce967fe81a 100644
--- a/tools/binman/etype/intel_descriptor.py
+++ b/tools/binman/etype/intel_descriptor.py
@@ -59,7 +59,7 @@ class Entry_intel_descriptor(Entry_blob_ext):
if self.missing:
# Return zero offsets so that these entries get placed somewhere
if self.HasSibling('intel-me'):
-info['intel-me'] = [0, None]
+info['intel-me'] = [0x1000, None]
return info
offset = self.data.find(FD_SIGNATURE)
if offset == -1:
--
2.34.1
[PATCH v3 01/18] binman: Support an assumed size for missing binaries
Binman has a the useful feature of handling missing external blobs
gracefully, including allowing them to be missing, deciding whether the
resulting image is functional or not and faking blobs when this is
necessary for particular tools (e.g. mkimage).
This feature is widely used in CI. One drawback is that if U-Boot grows
too large to fit along with the required blobs, then this is not
discovered until someone does a 'real' build which includes the blobs.
Add a 'assume-size' property to entries to allow Binman to reserve a
given size for missing external blobs.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/binman/binman.rst | 7 ++
tools/binman/entry.py| 1 +
tools/binman/etype/blob.py | 7 +-
tools/binman/ftest.py| 28
tools/binman/test/326_assume_size.dts| 16 ++
tools/binman/test/327_assume_size_ok.dts | 16 ++
6 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 tools/binman/test/326_assume_size.dts
create mode 100644 tools/binman/test/327_assume_size_ok.dts
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index 230e055667f..872e9746c8c 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -711,6 +711,13 @@ missing-msg:
information about what needs to be fixed. See missing-blob-help for the
message for each tag.
+assume-size:
+Sets the assumed size of a blob entry if it is missing. This allows for a
+check that the rest of the image fits into the available space, even when
+the contents are not available. If the entry is missing, Binman will use
+this assumed size for the entry size, including creating a fake file of
that
+size if requested.
+
no-expanded:
By default binman substitutes entries with expanded versions if available,
so that a `u-boot` entry type turns into `u-boot-expanded`, for example.
The
diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index 42e0b7b9145..c1904f8ae69 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -315,6 +315,7 @@ class Entry(object):
self.overlap = fdt_util.GetBool(self._node, 'overlap')
if self.overlap:
self.required_props += ['offset', 'size']
+self.assume_size = fdt_util.GetInt(self._node, 'assume-size', 0)
# This is only supported by blobs and sections at present
self.compress = fdt_util.GetString(self._node, 'compress', 'none')
diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
index 064fae50365..041e1122953 100644
--- a/tools/binman/etype/blob.py
+++ b/tools/binman/etype/blob.py
@@ -48,11 +48,16 @@ class Entry_blob(Entry):
self.external and (self.optional or
self.section.GetAllowMissing()))
# Allow the file to be missing
if not self._pathname:
+if not fake_size and self.assume_size:
+fake_size = self.assume_size
self._pathname, faked = self.check_fake_fname(self._filename,
fake_size)
self.missing = True
if not faked:
-self.SetContents(b'')
+content_size = 0
+if self.assume_size: # Ensure we get test coverage on next line
+content_size = self.assume_size
+self.SetContents(tools.get_bytes(0, content_size))
return True
self.ReadBlobContents()
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8a44bc051b3..bd0a10ff885 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7460,5 +7460,33 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
with self.assertRaises(ValueError) as e:
self._DoReadFile('323_capsule_accept_revert_missing.dts')
+def test_assume_size(self):
+"""Test handling of the assume-size property for external blob"""
+with self.assertRaises(ValueError) as e:
+self._DoTestFile('326_assume_size.dts', allow_missing=True,
+ allow_fake_blobs=True)
+self.assertIn("contents size 0xa (10) exceeds section size 0x9 (9)",
+ str(e.exception))
+
+def test_assume_size_ok(self):
+"""Test handling of the assume-size where it fits OK"""
+with test_util.capture_sys_output() as (stdout, stderr):
+self._DoTestFile('327_assume_size_ok.dts', allow_missing=True,
+ allow_fake_blobs=True)
+err = stderr.getvalue()
+self.assertRegex(
+err,
+"Image '.*' has faked external blobs and is non-functional: .*")
+
+def test_assume_size_no_fake(self):
+"""Test handling of the assume-size where it fits OK"""
+with test_util.capture_sys_output() as (stdout, stderr):
+
Re: [PATCH 3/5] buildman: Support building within a Python venv
Hi Heinrich,
On Thu, 20 Jun 2024 at 07:38, Heinrich Schuchardt wrote:
>
> On 20.06.24 15:19, Simon Glass wrote:
> > The Python virtualenv tool sets up a few things in the envronment,
>
> Nits
>
> %s/envronment/environment/
>
> > putting its path first in the PATH environment variable and setting up
> > a sys.prefix different from the sys.base_prefix value.
> >
> > At present buildman puts the toolchain path first in PATH so that it can
> > be found easily during the build. For sandbox this causes problems since
> > /usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
> > PATH variable. As a result, the venv is partially disabled.
>
> If you want to remember a PATH, why don't you use a differnet variable
> like U_BOOT_TOOLPATH to convey this information instead of manipulating
> the PATH variable?
Remembering a path?
The goal here is to give buildman what it needs, i.e. the combination
of PATH changes (if needed) and CROSS_COMPILE that makes things work.
I am not proposing to change the mechanics of buildman, just deal with
this venv situation which I had not previously noticed.
>
> >
> > The result is that sandbox builds within a venv ignore the venv, e.g.
> > when looking for packages.
> >
> > Correct this by detecting the venv and adding the toolchain path after
> > the venv path.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/buildman/bsettings.py | 3 ++
> > tools/buildman/test.py | 83 +
> > tools/buildman/toolchain.py | 31 --
> > 3 files changed, 113 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
> > index e225ac2ca0f..1be1d45e0fa 100644
> > --- a/tools/buildman/bsettings.py
> > +++ b/tools/buildman/bsettings.py
> > @@ -31,6 +31,9 @@ def setup(fname=''):
> > def add_file(data):
> > settings.readfp(io.StringIO(data))
> >
> > +def add_section(name):
> > +settings.add_section(name)
> > +
> > def get_items(section):
> > """Get the items from a section of the config.
> >
> > diff --git a/tools/buildman/test.py b/tools/buildman/test.py
> > index f92add7a7c5..83219182fe0 100644
> > --- a/tools/buildman/test.py
> > +++ b/tools/buildman/test.py
> > @@ -146,6 +146,7 @@ class TestBuild(unittest.TestCase):
> > self.toolchains.Add('arm-linux-gcc', test=False)
> > self.toolchains.Add('sparc-linux-gcc', test=False)
> > self.toolchains.Add('powerpc-linux-gcc', test=False)
> > +self.toolchains.Add('/path/to/aarch64-linux-gcc', test=False)
> > self.toolchains.Add('gcc', test=False)
> >
> > # Avoid sending any output
> > @@ -747,6 +748,88 @@ class TestBuild(unittest.TestCase):
> > self.assertEqual([
> > ['MARY="mary"', 'Missing expected line:
> > CONFIG_MARY="mary"']], result)
> >
> > +def call_make_environment(self, tchn, full_path, in_env=None):
> > +"""Call Toolchain.MakeEnvironment() and process the result
> > +
> > +Args:
> > +tchn (Toolchain): Toolchain to use
> > +full_path (bool): True to return the full path in CROSS_COMPILE
> > +rather than adding it to the PATH variable
> > +in_env (dict): Input environment to use, None to use current
> > env
> > +
> > +Returns:
> > +tuple:
> > +dict: Changes that MakeEnvironment has made to the
> > environment
> > +key: Environment variable that was changed
> > +value: New value (for PATH this only includes
> > components
> > +which were added)
> > +str: Full value of the new PATH variable
> > +"""
> > +env = tchn.MakeEnvironment(full_path, env=in_env)
> > +
> > +# Get the original environment
> > +orig_env = dict(os.environb if in_env is None else in_env)
> > +orig_path = orig_env[b'PATH'].split(b':')
> > +
> > +# Find new variables
> > +diff = dict((k, env[k]) for k in env if orig_env.get(k) != env[k])
> > +
> > +# Find new / different path components
> > +diff_path = None
> > +new_path = None
> > +if b'PATH' in diff:
> > +new_path = diff[b'PATH'].split(b':')
> > +diff_paths = [p for p in new_path if p not in orig_path]
> > +diff_path = b':'.join(p for p in new_path if p not in
> > orig_path)
> > +if diff_path:
> > +diff[b'PATH'] = diff_path
> > +else:
> > +del diff[b'PATH']
> > +return diff, new_path
> > +
> > +def test_toolchain_env(self):
> > +"""Test PATH and other environment settings for toolchains"""
> > +# Use a toolchain which has a path, so that full_path makes a
> > difference
> > +tchn = self.toolchains.Select('aarch64')
> > +
> > +# Normal cases
> > +diff =
Re: [PATCH 3/5] buildman: Support building within a Python venv
Hi Tom,
On Thu, 20 Jun 2024 at 08:32, Tom Rini wrote:
>
> On Thu, Jun 20, 2024 at 07:19:35AM -0600, Simon Glass wrote:
>
> > The Python virtualenv tool sets up a few things in the envronment,
> > putting its path first in the PATH environment variable and setting up
> > a sys.prefix different from the sys.base_prefix value.
> >
> > At present buildman puts the toolchain path first in PATH so that it can
> > be found easily during the build. For sandbox this causes problems since
> > /usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
> > PATH variable. As a result, the venv is partially disabled.
> >
> > The result is that sandbox builds within a venv ignore the venv, e.g.
> > when looking for packages.
> >
> > Correct this by detecting the venv and adding the toolchain path after
> > the venv path.
> >
> > Signed-off-by: Simon Glass
>
> Why are we using PATH at all in this case? Shouldn't we just be setting
> CROSS_COMPILE=/full/path/to/the/prefix ?
This is the -p option to buildman. The original commit was:
commit bb1501f2c22c979961b735db775605cccedd98f6
Author: Simon Glass
Date: Mon Dec 1 17:34:00 2014 -0700
buildman: Add an option to use the full tool chain path
In some cases there may be multiple toolchains with the same name in the
path. Provide an option to use the full path in the CROSS_COMPILE
environment variable.
Note: Wolfgang mentioned that this is dangerous since in some cases there
may be other tools on the path that are needed. So this is set up as an
option, not the default. I will need test confirmation (i.e. that this
commit fixes a real problem) before merging it.
As to why we don't always do this, well that is back in the mists of
time, 10 years ago.
BTW, this is raising a point ("let's change the behaviour") separate
from the goal of this commit, which is to fix a problem with venv,
albeit that if we made -p the only option, then we could potentially
drop all PATH changes. Perhaps toolchains are built differently now,
such that they always invoke their tools using the same prefix and
dir?
Regards,
Simon
Re: [PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
Hi Tom, On Wed, 19 Jun 2024 at 09:32, Tom Rini wrote: > > On Tue, Jun 18, 2024 at 09:03:37PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 18 Jun 2024 at 08:15, Tom Rini wrote: > > > > > > On Tue, Jun 18, 2024 at 06:43:51AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 17 Jun 2024 at 11:16, Tom Rini wrote: > > > > > > > > > > On Mon, Jun 17, 2024 at 07:53:22AM -0600, Simon Glass wrote: > > > > > > Hi, > > > > > > > > > > > > On Sat, 15 Jun 2024 at 01:03, Ilias Apalodimas > > > > > > wrote: > > > > > > > > > > > > > > Hi Heinrich > > > > > > > > > > > > > > resending the reply, I accidentally sent half of the message... > > > > > > > > > > > > > > On Fri, 14 Jun 2024 at 12:04, Heinrich Schuchardt > > > > > > > wrote: > > > > > > > > > > > > > > > > On 14.06.24 09:01, Ilias Apalodimas wrote: > > > > > > > > > On Fri, 14 Jun 2024 at 09:59, Heinrich Schuchardt > > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >> On 6/14/24 08:03, Ilias Apalodimas wrote: > > > > > > > > >>> Hi Simon, > > > > > > > > >>> > > > > > > > > >>> On Mon, 10 Jun 2024 at 17:59, Simon Glass > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > It does not make sense to enable all SHA algorithms unless > > > > > > > > they are > > > > > > > > needed. It bloats the code and in this case, causes > > > > > > > > chromebook_link to > > > > > > > > fail to build. That board does use the TPM, but not with > > > > > > > > measured boot, > > > > > > > > nor EFI. > > > > > > > > > > > > > > > > Since EFI_TCG2_PROTOCOL already selects these options, we > > > > > > > > just need to > > > > > > > > add them to MEASURED_BOOT as well. > > > > > > > > > > > > > > > > Note that the original commit combines refactoring and new > > > > > > > > features, > > > > > > > > which makes it hard to see what is going on. > > > > > > > > > > > > > > > > Fixes: 97707f12fda tpm: Support boot measurements > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > - Put the conditions under EFI_TCG2_PROTOCOL > > > > > > > > - Consider MEASURED_BOOT too > > > > > > > > > > > > > > > > boot/Kconfig | 4 > > > > > > > > lib/Kconfig | 4 > > > > > > > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > > > index 6f3096c15a6..b061891e109 100644 > > > > > > > > --- a/boot/Kconfig > > > > > > > > +++ b/boot/Kconfig > > > > > > > > @@ -734,6 +734,10 @@ config LEGACY_IMAGE_FORMAT > > > > > > > > config MEASURED_BOOT > > > > > > > > bool "Measure boot images and configuration when > > > > > > > > booting without EFI" > > > > > > > > depends on HASH && TPM_V2 > > > > > > > > + select SHA1 > > > > > > > > + select SHA256 > > > > > > > > + select SHA384 > > > > > > > > + select SHA512 > > > > > > > > help > > > > > > > > This option enables measurement of the boot > > > > > > > > process when booting > > > > > > > > without UEFI . Measurement involves creating > > > > > > > > cryptographic hashes > > > > > > > > diff --git a/lib/Kconfig b/lib/Kconfig > > > > > > > > index 189e6eb31aa..568892fce44 100644 > > > > > > > > --- a/lib/Kconfig > > > > > > > > +++ b/lib/Kconfig > > > > > > > > @@ -438,10 +438,6 @@ config TPM > > > > > > > > bool "Trusted Platform Module (TPM) Support" > > > > > > > > depends on DM > > > > > > > > imply DM_RNG > > > > > > > > - select SHA1 > > > > > > > > - select SHA256 > > > > > > > > - select SHA384 > > > > > > > > - select SHA512 > > > > > > > > >>> > > > > > > > > >>> I am not sure this is the right way to deal with your > > > > > > > > >>> problem. > > > > > > > > >>> The TPM main functionality is to measure and extend PCRs, > > > > > > > > >>> so sha > > > > > > > > >>> is really required. To make things even worse, you don't > > > > > > > > >>> know the PCR > > > > > > > > >>> banks that are enabled beforehand. This is a runtime config > > > > > > > > >>> of the > > > > > > > > >>> TPM. > > > > > > > > >> > > > > > > > > >> If neither MEASURED_BOOT nor EFI_TCG2_PROTOCOL is selected, > > > > > > > > >> U-Boot > > > > > > > > >> cannot extend PCRs. So it seems fine to let these two select > > > > > > > > >> the > > > > > > > > >> complete set of hashing algorithms. As Simon pointed out for > > > > > > > > >> EFI_TCG2_PROTOCOL this is already done in > > > > > > > > >> lib/efi_loader/Kconfig. > > > > > > > > > > > > > > > > > > It can. The cmd we have can extend those pcrs -- e.g tpm2 > > >
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
Hi Nishanth, On Thu, 20 Jun 2024 at 15:35, Nishanth Menon wrote: > > Hi Team, > > We have briefly discussed this topic on IRC[1]. I would like to > propose a new boot-firmware repository similar to the Linux-firmware > repository under the aegis of u-boot hosting. > > In addition to TI, it looks like some NXP[2] and Rockchip[3] > platforms seem to require additional closed-source/open-source > binaries to have a complete bootable image. Distribution rights and > locations of these binaries are challenging, and there needs to be a > standard for how and where they are hosted for end users. > > Further, looking ahead to future architectures: > * IP firmware: More and more IP vendors are embedding their own > "specialized controllers" and require firmware for the operation > (similar to Rockchip's DDR controller, I guess), > * boot stage firmware: Additional stages of the boot process involve > vendor intermediate firmware, such as power configuration. > * Security enclave binaries: While I see a few folks trying to have an > open-source s/w architecture, many PKA and PQC systems still require > prop binaries for IP reasons. > > NOTE: I am not judging any company(including TI) for reasons why some > firmware is proprietary, but I hate to have the end users and other > system (distro) maintainers have to deal with hell trying to make the > life of end users easy to live with. > > In the case of TI's K3 architecture devices, we have two binary blobs > that are critical for the boot process. > > 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave > firmware. It is often encrypted, and sources are not public (due to > various business/regulatory reasons). > 2. DM Firmware[5] - There is a source in public in some cases and > binary only in others - essentially limited function binary to be > put up in the device management uC. In cases where the source is > available, the build procedure is, in my personal opinion, pretty > arcane, and even though in theory it is practical, in practice, not > friendly - efforts are going to simplify it, even probably integrate > it with a more opensource ecosystem, but that is talking "look at the > tea leaves" stuff. > 3. Low Power Management (LPM) binaries: tifs stub: another encrypted > binary that gives the tifs system context restore logic before > retrieving tifs firmware and a corresponding DM restoration binary. > > All told, this is not unlike the situation that necessitated the > creation of a Linux firmware repository. > > Options that I see: > > 1. Let the status quo be - SoC vendors maintain random locations and > random rules to maintain boot firmware. > 2. Ask Linux-firmware to host the binaries in a single canonical > location > 3. Host a boot-firmware repository - u-boot repo may be the more > logical location. > > * (1) isn't the correct answer. > > * (2) Though I haven't seen any policy from the Linux-firmware > community mandating anything of the form, the binaries we are talking > of may not belong to Linux-firmware as they aren't strictly speaking > something Linux kernel will load (since the bootloader has that > responsibility), and in some cases may not even directly talk to > (security enclave or DDR firmware stuff). I am adding Josh to this > mail to see if he has any opinions on the topic (but keeping > from cross posting on linux-firmware list, unless folks feel it is > OK). > > On (3): > Proposal: > > * Create a boot firmware repository in Denx and/or GitHub (if > financials are a hurdle, I hope we can solve it as a community). > * Limit binaries only to those consumed part of the u-boot scope. > > * Limit binaries only to those that do not have an opensource project > (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor > source or are binary only in nature (subject to licensing terms below) > * Limit binaries to some pre-established size to prevent repository > explosion - say, 512Kib? > * Follow the same rules of integration and licensing guidelines as > Linux-firmware[6]. > * Similar rules as Linux-firmware guidelines of ABI backward and > forward compatibility. > * Set a workflow update flow and a compatibility requirements document > > If we agree to have boot firmware under the stewardship of u-boot, we > should also set other rules, which is excellent to discuss. > > Thoughts? I suggest: 4) Add a 'binman blob' subcommand which can fetch blobs, similarly to how 'binman tool -f xxx' features a tool, using the image description to know what is needed and some configuration for where to find it / how to build it. That way we can actually build working images and test them, without user intervention / guesswork. IMO the actual repo is not the ultimate goal here. Building and testing should be the ultimate goal. > > [1] https://libera.irclog.whitequark.org/u-boot/2024-06-13#36498796; > [2]
Re: mkimage alignment of initrd with -T multi
Hi Chris, On Wed, 19 Jun 2024 at 23:16, Chris Packham wrote: > > Hi U-Boot, > > I've been given a MIPS reference board with a fairly old vendor U-Boot > on it. It does seem to support the Mutli-File Image format but I'm > running into an issue where the kernel expects the initrd on a page > boundary. > > I'm using a command like the following to produce and image > cat board.dtb >> vmlinux.bin > gzip vmlinux.bin >vmlinux.gz > mkimage -C gzip -A mips -O linux -T multi -a 0x8010 -e > 0x8010 -d vmlinux.gz:initrd.sqsh myboard.img > > I can mess about with padding vmlinux.gz after the gzip step but the > process is a bit fragile and involves me guessing at some magic > numbers that I think might be sizes of certain headers. > > Is there any way to convince mkimage to make sure the initrd is on an > appropriately aligned boundary so I don't have to guess. There is a -B flag which might help, if you can convert it to use FIT. I am sure that it does, though. Regards, Simon
Re: [PATCH] RFC: Add a tag for the world builds
Hi Tom, On Thu, 20 Jun 2024 at 08:39, Tom Rini wrote: > > On Thu, Jun 20, 2024 at 07:33:46AM -0600, Simon Glass wrote: > > > Currently the world builds run on all runners, including faster and > > slower ones. > > > > The difference can be quite dramatic, with some builders 4x as fast as > > others, resulting in just one world build taking between 20 minutes and > > an hour and 20 minutes. > > > > Add a tag so that we can select which builders run these CPU-intensive > > jobs. > > > > With this tag we can also increase CPU utilisation by running multiple > > QEMU tests in parallel. Currently these tests leave most machines fairly > > idle, since we cannot run more than one world build on a machine. > > > > Signed-off-by: Simon Glass > > This conflicts I think with Jiaxun's desire to make our GitLab job > runnable on the public runners too, and where we'll end up with 10 world > build jobs ala Azure. It probably doesn't actually conflict, although I am not sure if one can add a tag to jobs that run on public runners. Regards, Simon
Re: [PATCH] scripts/Makefile.lib: remove bootph-some-ram property from VPL/TPL/SPL
On Wed, 19 Jun 2024 at 05:33, Quentin Schulz wrote: > > From: Quentin Schulz > > The property isn't useful in VPL/SPL/TPL as it is only for U-Boot proper > pre-reloc, which has its own DTB. > > Signed-off-by: Quentin Schulz > --- > scripts/Makefile.lib | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
> Date: Fri, 21 Jun 2024 00:22:43 +0200 > From: Quentin Schulz Hi Quentin, > FYI, the DDR bin is printing stuff on the console, so we had to modify > it (with a tool from Rockchip) to remove the gibberish breaking the > terminal by setting the appropriate controller, mux and baudrate (for > our products, there's no one size fits all :) ). The question is how to > handle this since we cannot realistically store every possible > permutation of that binary for each UART controller, mux of UART > controller and baudrate (the only parameters **we** modify, but there > are tons of others). To build the RK356x and RK3588 of the u-boot packages on OpenBSD I've written a small program that changes the baudrate from 150 to 115200: https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk356x/files/rkbinpatch.c https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk3588/files/rkbinpatch.c This just does the bare minimum and it might break with future changes to the layout of the binaries. But I don't think it would be difficult to add a few more parameters. Cheers, Mark
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
On Thu, 20 Jun 2024 at 23:22, Quentin Schulz wrote: > > Hi Nishanth Menon, > > +Cc Kever from Rockchip as maintainer of the arch in U-Boot > +Cc Heiko as maintainer of many things Rockchip in many projects > > On 6/20/24 11:35 PM, Nishanth Menon wrote: > > Hi Team, > > > > We have briefly discussed this topic on IRC[1]. I would like to > > propose a new boot-firmware repository similar to the Linux-firmware > > repository under the aegis of u-boot hosting. > > > > In addition to TI, it looks like some NXP[2] and Rockchip[3] > > platforms seem to require additional closed-source/open-source > > binaries to have a complete bootable image. Distribution rights and > > locations of these binaries are challenging, and there needs to be a > > standard for how and where they are hosted for end users. > > > > Further, looking ahead to future architectures: > > * IP firmware: More and more IP vendors are embedding their own > >"specialized controllers" and require firmware for the operation > >(similar to Rockchip's DDR controller, I guess), > > * boot stage firmware: Additional stages of the boot process involve > >vendor intermediate firmware, such as power configuration. > > * Security enclave binaries: While I see a few folks trying to have an > >open-source s/w architecture, many PKA and PQC systems still require > >prop binaries for IP reasons. > > > > NOTE: I am not judging any company(including TI) for reasons why some > > firmware is proprietary, but I hate to have the end users and other > > system (distro) maintainers have to deal with hell trying to make the > > life of end users easy to live with. > > > > In the case of TI's K3 architecture devices, we have two binary blobs > > that are critical for the boot process. > > > > 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave > >firmware. It is often encrypted, and sources are not public (due to > >various business/regulatory reasons). > > 2. DM Firmware[5] - There is a source in public in some cases and > >binary only in others - essentially limited function binary to be > >put up in the device management uC. In cases where the source is > >available, the build procedure is, in my personal opinion, pretty > >arcane, and even though in theory it is practical, in practice, not > >friendly - efforts are going to simplify it, even probably integrate > >it with a more opensource ecosystem, but that is talking "look at the > >tea leaves" stuff. > > 3. Low Power Management (LPM) binaries: tifs stub: another encrypted > >binary that gives the tifs system context restore logic before > >retrieving tifs firmware and a corresponding DM restoration binary. > > > > All told, this is not unlike the situation that necessitated the > > creation of a Linux firmware repository. > > > > Options that I see: > > > > 1. Let the status quo be - SoC vendors maintain random locations and > >random rules to maintain boot firmware. > > 2. Ask Linux-firmware to host the binaries in a single canonical > >location > > 3. Host a boot-firmware repository - u-boot repo may be the more > >logical location. > > > > * (1) isn't the correct answer. > > > > * (2) Though I haven't seen any policy from the Linux-firmware > >community mandating anything of the form, the binaries we are talking > >of may not belong to Linux-firmware as they aren't strictly speaking > >something Linux kernel will load (since the bootloader has that > >responsibility), and in some cases may not even directly talk to > >(security enclave or DDR firmware stuff). I am adding Josh to this > >mail to see if he has any opinions on the topic (but keeping > >from cross posting on linux-firmware list, unless folks feel it is > >OK). > > > > On (3): > > Proposal: > > > > * Create a boot firmware repository in Denx and/or GitHub (if > >financials are a hurdle, I hope we can solve it as a community). > > * Limit binaries only to those consumed part of the u-boot scope. > > > > * Limit binaries only to those that do not have an opensource project > >(Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor > >source or are binary only in nature (subject to licensing terms below) > > FYI, on Rockchip, there are currently three blobs **we** use on Aarch64 > (i have only worked with RK3399, PX30 and RK3588, so they may be more :) ): > - DDR bin/TPL no clue what this actually is under the hood. I think > most SoCs do not get an open-source DDR init in U-Boot sadly, therefore > mandatory until it isn't, > - BL31, mandatory on Aarch64, a blob that is an old TF-A (v2.2/2.3 I > don't remember anymore). I don't know the state for all SoCs, but I can > say the RK3399, PX30 and RK3568 have an open one, RK3588 is one the way > (but considering the RK3568 and RK3588 were released years ago, BL31 > blob is mandatory for a while), rk3568 is now upstream, there was a PR upstream for this for
[PATCH] board: gateworks: venice: Simplify Ethernet initialization
With DM enabled, there is no need for board code to initialize
the Ethernet interfaces.
Specifically board_interface_eth_init will handle the configuration of
GPR1.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/venice.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index 3080ff20cb02..d4c22121497b 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -45,22 +45,6 @@ int board_fit_config_name_match(const char *path)
return -1;
}
-static int __maybe_unused setup_fec(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
-#ifndef CONFIG_IMX8MP
- /* Use 125M anatop REF_CLK1 for ENET1, not from external */
- clrsetbits_le32(>gpr[1], 0x2000, 0);
-#else
- /* Enable RGMII TX clk output */
- setbits_le32(>gpr[1], BIT(22));
-#endif
-
- return 0;
-}
-
#if (IS_ENABLED(CONFIG_NET))
int board_phy_config(struct phy_device *phydev)
{
@@ -91,9 +75,6 @@ int board_init(void)
{
venice_eeprom_init(1);
- if (IS_ENABLED(CONFIG_FEC_MXC))
- setup_fec();
-
return 0;
}
--
2.25.1
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
Hi Nishanth Menon, +Cc Kever from Rockchip as maintainer of the arch in U-Boot +Cc Heiko as maintainer of many things Rockchip in many projects On 6/20/24 11:35 PM, Nishanth Menon wrote: Hi Team, We have briefly discussed this topic on IRC[1]. I would like to propose a new boot-firmware repository similar to the Linux-firmware repository under the aegis of u-boot hosting. In addition to TI, it looks like some NXP[2] and Rockchip[3] platforms seem to require additional closed-source/open-source binaries to have a complete bootable image. Distribution rights and locations of these binaries are challenging, and there needs to be a standard for how and where they are hosted for end users. Further, looking ahead to future architectures: * IP firmware: More and more IP vendors are embedding their own "specialized controllers" and require firmware for the operation (similar to Rockchip's DDR controller, I guess), * boot stage firmware: Additional stages of the boot process involve vendor intermediate firmware, such as power configuration. * Security enclave binaries: While I see a few folks trying to have an open-source s/w architecture, many PKA and PQC systems still require prop binaries for IP reasons. NOTE: I am not judging any company(including TI) for reasons why some firmware is proprietary, but I hate to have the end users and other system (distro) maintainers have to deal with hell trying to make the life of end users easy to live with. In the case of TI's K3 architecture devices, we have two binary blobs that are critical for the boot process. 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave firmware. It is often encrypted, and sources are not public (due to various business/regulatory reasons). 2. DM Firmware[5] - There is a source in public in some cases and binary only in others - essentially limited function binary to be put up in the device management uC. In cases where the source is available, the build procedure is, in my personal opinion, pretty arcane, and even though in theory it is practical, in practice, not friendly - efforts are going to simplify it, even probably integrate it with a more opensource ecosystem, but that is talking "look at the tea leaves" stuff. 3. Low Power Management (LPM) binaries: tifs stub: another encrypted binary that gives the tifs system context restore logic before retrieving tifs firmware and a corresponding DM restoration binary. All told, this is not unlike the situation that necessitated the creation of a Linux firmware repository. Options that I see: 1. Let the status quo be - SoC vendors maintain random locations and random rules to maintain boot firmware. 2. Ask Linux-firmware to host the binaries in a single canonical location 3. Host a boot-firmware repository - u-boot repo may be the more logical location. * (1) isn't the correct answer. * (2) Though I haven't seen any policy from the Linux-firmware community mandating anything of the form, the binaries we are talking of may not belong to Linux-firmware as they aren't strictly speaking something Linux kernel will load (since the bootloader has that responsibility), and in some cases may not even directly talk to (security enclave or DDR firmware stuff). I am adding Josh to this mail to see if he has any opinions on the topic (but keeping from cross posting on linux-firmware list, unless folks feel it is OK). On (3): Proposal: * Create a boot firmware repository in Denx and/or GitHub (if financials are a hurdle, I hope we can solve it as a community). * Limit binaries only to those consumed part of the u-boot scope. * Limit binaries only to those that do not have an opensource project (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor source or are binary only in nature (subject to licensing terms below) FYI, on Rockchip, there are currently three blobs **we** use on Aarch64 (i have only worked with RK3399, PX30 and RK3588, so they may be more :) ): - DDR bin/TPL no clue what this actually is under the hood. I think most SoCs do not get an open-source DDR init in U-Boot sadly, therefore mandatory until it isn't, - BL31, mandatory on Aarch64, a blob that is an old TF-A (v2.2/2.3 I don't remember anymore). I don't know the state for all SoCs, but I can say the RK3399, PX30 and RK3568 have an open one, RK3588 is one the way (but considering the RK3568 and RK3588 were released years ago, BL31 blob is mandatory for a while), - BL32, OP-TEE. I don't think we support it upstream for Aarch64 (I think there was some issue around the binary format being different than the upstream OP-TEE?). Don't know the state for Aarch32 SoCs though. - I vaguely remember something about a miniloader but have no clue what is its use as I've never had to use it, mentioning it anyway. So, BL31 and BL32 are blobs but based on open-source projects with "weak" licensing
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
Hi Nishanth, Thanks for starting this conversation. > We have briefly discussed this topic on IRC[1]. I would like to > propose a new boot-firmware repository similar to the Linux-firmware > repository under the aegis of u-boot hosting. > > In addition to TI, it looks like some NXP[2] and Rockchip[3] > platforms seem to require additional closed-source/open-source > binaries to have a complete bootable image. Distribution rights and > locations of these binaries are challenging, and there needs to be a > standard for how and where they are hosted for end users. Yes, it's been painful for some time, and often the distribution is unclear because often the binaries are copies around between SBC makers often without the other bits such as licenses etc so it's a case of "who knows ¯\_(ツ)_/¯" even if it's the same for all devices of a particular SoC. Having a process around licensing and redistribution requirements is useful. > Further, looking ahead to future architectures: > * IP firmware: More and more IP vendors are embedding their own > "specialized controllers" and require firmware for the operation > (similar to Rockchip's DDR controller, I guess), > * boot stage firmware: Additional stages of the boot process involve > vendor intermediate firmware, such as power configuration. > * Security enclave binaries: While I see a few folks trying to have an > open-source s/w architecture, many PKA and PQC systems still require > prop binaries for IP reasons. > > NOTE: I am not judging any company(including TI) for reasons why some > firmware is proprietary, but I hate to have the end users and other > system (distro) maintainers have to deal with hell trying to make the > life of end users easy to live with. > > In the case of TI's K3 architecture devices, we have two binary blobs > that are critical for the boot process. > > 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave > firmware. It is often encrypted, and sources are not public (due to > various business/regulatory reasons). > 2. DM Firmware[5] - There is a source in public in some cases and > binary only in others - essentially limited function binary to be > put up in the device management uC. In cases where the source is > available, the build procedure is, in my personal opinion, pretty > arcane, and even though in theory it is practical, in practice, not > friendly - efforts are going to simplify it, even probably integrate > it with a more opensource ecosystem, but that is talking "look at the > tea leaves" stuff. > 3. Low Power Management (LPM) binaries: tifs stub: another encrypted > binary that gives the tifs system context restore logic before > retrieving tifs firmware and a corresponding DM restoration binary. > > All told, this is not unlike the situation that necessitated the > creation of a Linux firmware repository. > > Options that I see: > > 1. Let the status quo be - SoC vendors maintain random locations and > random rules to maintain boot firmware. > 2. Ask Linux-firmware to host the binaries in a single canonical > location I don't believe this makes sense. linux-firmware is designed for firmware that is loaded by linunx drivers, these are not, they're generally used a part of early boot firmware prior to the linux kernel even booting, and could in fact be any other OS. As it is linux-firmware is 2Gb+ in size, as a maintainer of that package in Fedora having to determine which of 1000s of firmware is used by linux or something else or if we need to ship it is hard enough already without throwing a whole raft of other FW into the mix. I think a separate repo is the right way to go here please. > 3. Host a boot-firmware repository - u-boot repo may be the more > logical location. > > * (1) isn't the correct answer. > > * (2) Though I haven't seen any policy from the Linux-firmware > community mandating anything of the form, the binaries we are talking my understanding is the policy is that it's firmware required by linux drivers. > of may not belong to Linux-firmware as they aren't strictly speaking > something Linux kernel will load (since the bootloader has that > responsibility), and in some cases may not even directly talk to > (security enclave or DDR firmware stuff). I am adding Josh to this > mail to see if he has any opinions on the topic (but keeping > from cross posting on linux-firmware list, unless folks feel it is > OK). > > On (3): > Proposal: > > * Create a boot firmware repository in Denx and/or GitHub (if > financials are a hurdle, I hope we can solve it as a community). > * Limit binaries only to those consumed part of the u-boot scope. > * Limit binaries only to those that do not have an opensource project > (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor > source or are binary only in nature (subject to licensing terms below) > * Limit binaries to some pre-established size to prevent repository > explosion - say,
Re: [PATCH] board: beagle: beagleplay: enable OF_SYSTEM_SETUP
On Thu, Jun 20, 2024 at 4:15 PM Nishanth Menon wrote: > > On 11:55-20240620, Chirag Shilwant wrote: > > > > On 20/06/24 11:21, Dhruva Gole wrote: > > > On Jun 19, 2024 at 15:44:41 -0500, Andrew Davis wrote: > > > > On 6/19/24 2:12 PM, Bryan Brattlof wrote: > > > > > Unfortunately when enabling FDT fixups for the AM62x family of SoCs > > > > > and > > > > > moving TF-A to the bottom of RAM we missed the BeaglePlay. This is > > > > > causing Linux's memory allocator to clobber TF-A and break its boot. > > > > > > > > > > Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the > > > > > actual location of the firmware > > > > > > > > > > CC: Andrew Davis > > > > > CC: Nishanth Menon > > > > > CC: Robert Nelson > > > > > Reported-by: Dhruva Gole > > > > > Signed-off-by: Bryan Brattlof > > > > > --- > > > > Acked-by: Andrew Davis > > > > > > Acked-by: Chirag Shilwant > > > > > > > > > > > Hello everyone, > > > > > > > > > > Fair warning, this may turn into a philosophical discussion about the > > > > > role of device-tree with SystemReady and U-Boot's role in enabling > > > > > true > > > > > distribution to be completely agnostic of the board it's running on. > > > > > > > > > > However substantively this is simply fixing a boot regression Dhruva > > > > > found while testing out the beagleplay. > > > > > > > > > > Happy reviewing > > > > > ~Bryan > > > > > --- > > > > >board/beagle/beagleplay/Kconfig | 1 + > > > > >1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/board/beagle/beagleplay/Kconfig > > > > > b/board/beagle/beagleplay/Kconfig > > > > > index 7dbd833acb4cc..896a1c1be3010 100644 > > > > > --- a/board/beagle/beagleplay/Kconfig > > > > > +++ b/board/beagle/beagleplay/Kconfig > > > > > @@ -12,6 +12,7 @@ config TARGET_AM625_A53_BEAGLEPLAY > > > > > bool "BeagleBoard.org AM625 BeaglePlay running on A53" > > > > > select ARM64 > > > > > select BINMAN > > > > > + select OF_SYSTEM_SETUP > > > Thanks for the quick fix, > > > Tested-by: Dhruva Gole > > > > > > Boot logs upto kernel prompt: > > > https://gist.github.com/DhruvaG2000/4dc1c1e42207dd98a144f27cc9dff177 > > > > > > Thanks. > > Reviewed-by: Nishanth Menon > > > Tom: this is a regression in master and in next - will appreciate if you > could merge this.. Boot tested on v2024.07-rc4 with my BeaglePlay's.. Tested-by: Robert Nelson -- Robert Nelson https://rcn-ee.com/
Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
Hi Team, We have briefly discussed this topic on IRC[1]. I would like to propose a new boot-firmware repository similar to the Linux-firmware repository under the aegis of u-boot hosting. In addition to TI, it looks like some NXP[2] and Rockchip[3] platforms seem to require additional closed-source/open-source binaries to have a complete bootable image. Distribution rights and locations of these binaries are challenging, and there needs to be a standard for how and where they are hosted for end users. Further, looking ahead to future architectures: * IP firmware: More and more IP vendors are embedding their own "specialized controllers" and require firmware for the operation (similar to Rockchip's DDR controller, I guess), * boot stage firmware: Additional stages of the boot process involve vendor intermediate firmware, such as power configuration. * Security enclave binaries: While I see a few folks trying to have an open-source s/w architecture, many PKA and PQC systems still require prop binaries for IP reasons. NOTE: I am not judging any company(including TI) for reasons why some firmware is proprietary, but I hate to have the end users and other system (distro) maintainers have to deal with hell trying to make the life of end users easy to live with. In the case of TI's K3 architecture devices, we have two binary blobs that are critical for the boot process. 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave firmware. It is often encrypted, and sources are not public (due to various business/regulatory reasons). 2. DM Firmware[5] - There is a source in public in some cases and binary only in others - essentially limited function binary to be put up in the device management uC. In cases where the source is available, the build procedure is, in my personal opinion, pretty arcane, and even though in theory it is practical, in practice, not friendly - efforts are going to simplify it, even probably integrate it with a more opensource ecosystem, but that is talking "look at the tea leaves" stuff. 3. Low Power Management (LPM) binaries: tifs stub: another encrypted binary that gives the tifs system context restore logic before retrieving tifs firmware and a corresponding DM restoration binary. All told, this is not unlike the situation that necessitated the creation of a Linux firmware repository. Options that I see: 1. Let the status quo be - SoC vendors maintain random locations and random rules to maintain boot firmware. 2. Ask Linux-firmware to host the binaries in a single canonical location 3. Host a boot-firmware repository - u-boot repo may be the more logical location. * (1) isn't the correct answer. * (2) Though I haven't seen any policy from the Linux-firmware community mandating anything of the form, the binaries we are talking of may not belong to Linux-firmware as they aren't strictly speaking something Linux kernel will load (since the bootloader has that responsibility), and in some cases may not even directly talk to (security enclave or DDR firmware stuff). I am adding Josh to this mail to see if he has any opinions on the topic (but keeping from cross posting on linux-firmware list, unless folks feel it is OK). On (3): Proposal: * Create a boot firmware repository in Denx and/or GitHub (if financials are a hurdle, I hope we can solve it as a community). * Limit binaries only to those consumed part of the u-boot scope. * Limit binaries only to those that do not have an opensource project (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor source or are binary only in nature (subject to licensing terms below) * Limit binaries to some pre-established size to prevent repository explosion - say, 512Kib? * Follow the same rules of integration and licensing guidelines as Linux-firmware[6]. * Similar rules as Linux-firmware guidelines of ABI backward and forward compatibility. * Set a workflow update flow and a compatibility requirements document If we agree to have boot firmware under the stewardship of u-boot, we should also set other rules, which is excellent to discuss. Thoughts? [1] https://libera.irclog.whitequark.org/u-boot/2024-06-13#36498796; [2] https://docs.nxp.com/bundle/AN14093/page/topics/build_the_u-boot.html [3] https://bbs.t-firefly.com/forum.php?mod=viewthread=2236 [4] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-sysfw?h=ti-linux-firmware [5] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=ti-linux-firmware [6] https://docs.kernel.org/next/driver-api/firmware/firmware-usage-guidelines.html -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] board: beagle: beagleplay: enable OF_SYSTEM_SETUP
On 11:55-20240620, Chirag Shilwant wrote: > > On 20/06/24 11:21, Dhruva Gole wrote: > > On Jun 19, 2024 at 15:44:41 -0500, Andrew Davis wrote: > > > On 6/19/24 2:12 PM, Bryan Brattlof wrote: > > > > Unfortunately when enabling FDT fixups for the AM62x family of SoCs and > > > > moving TF-A to the bottom of RAM we missed the BeaglePlay. This is > > > > causing Linux's memory allocator to clobber TF-A and break its boot. > > > > > > > > Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the > > > > actual location of the firmware > > > > > > > > CC: Andrew Davis > > > > CC: Nishanth Menon > > > > CC: Robert Nelson > > > > Reported-by: Dhruva Gole > > > > Signed-off-by: Bryan Brattlof > > > > --- > > > Acked-by: Andrew Davis > > > Acked-by: Chirag Shilwant > > > > > > > Hello everyone, > > > > > > > > Fair warning, this may turn into a philosophical discussion about the > > > > role of device-tree with SystemReady and U-Boot's role in enabling true > > > > distribution to be completely agnostic of the board it's running on. > > > > > > > > However substantively this is simply fixing a boot regression Dhruva > > > > found while testing out the beagleplay. > > > > > > > > Happy reviewing > > > > ~Bryan > > > > --- > > > >board/beagle/beagleplay/Kconfig | 1 + > > > >1 file changed, 1 insertion(+) > > > > > > > > diff --git a/board/beagle/beagleplay/Kconfig > > > > b/board/beagle/beagleplay/Kconfig > > > > index 7dbd833acb4cc..896a1c1be3010 100644 > > > > --- a/board/beagle/beagleplay/Kconfig > > > > +++ b/board/beagle/beagleplay/Kconfig > > > > @@ -12,6 +12,7 @@ config TARGET_AM625_A53_BEAGLEPLAY > > > > bool "BeagleBoard.org AM625 BeaglePlay running on A53" > > > > select ARM64 > > > > select BINMAN > > > > + select OF_SYSTEM_SETUP > > Thanks for the quick fix, > > Tested-by: Dhruva Gole > > > > Boot logs upto kernel prompt: > > https://gist.github.com/DhruvaG2000/4dc1c1e42207dd98a144f27cc9dff177 > > Thanks. Reviewed-by: Nishanth Menon Tom: this is a regression in master and in next - will appreciate if you could merge this.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: obscure microsd detection issue between U-Boot and kernel
On 6/20/24 17:48, Tim Harvey wrote: > On Tue, Jun 4, 2024 at 1:14 AM Michael Walle wrote: >> >> On Tue Jun 4, 2024 at 9:47 AM CEST, Christian Loehle wrote: >>> On 6/3/24 22:28, Tim Harvey wrote: On Mon, Jun 3, 2024 at 1:18 AM Christian Loehle wrote: > > On 5/31/24 21:47, Tim Harvey wrote: >> Greetings, >> >> I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where >> for a specific set of microsd cards if I have accessed the microsd in >> U-Boot with UHS/1.8V the kernel will not recognize that microsd when >> scanning. >> >> The issue does not occur with all microsd cards but seems to appear >> with a large sample size of a specific card/model (Kingston SDC32 32GB >> SDR104 card). I do not see a signal integrity issue on the scope. >> >> Instrumenting the kernel the issue is that the host reports a CRC >> error as soon as the first mmc_send_if_cond call which occurs in >> mmc_rescan_try_freq. >> >> I can avoid the issue by either not accessing the microsd in U-Boot or >> by disabling UHS/1.8V mode in U-Boot therefore what I think is >> happening is that U-Boot leaves the card in UHS/1.8V signalling mode >> and when the kernel scans it sets the voltage back to 3.3V >> standard/default and default timings then issues its clock cycles to >> 'reset' the card and the card does not recognize the reset. I'm >> wondering if this is because the reset is done via clock cycles after >> the kernel has set the I/O voltage back to 3.3V when perhaps the card >> is still in 1.8V mode (although I don't see how that would cause an >> issue)? > > It will cause an issue for many cards and might break some cards. > >> >> Is there some sort of MMC 'reset' I can/should do in U-Boot before >> booting the kernel? Has anyone encountered anything like this before? > > There is no 'switching back' to 3.3V signalling from UHS 1.8V. > The only way this can be done is therefore a full power-off. > Is that done correctly for your system? > AFAIR spec dictates 500ms of <0.5V on VCC. Note that driving CLK/signal > lines can also sustain the card somewhat, as leakage is only limited > within operating voltage. Hi Christian, Are you saying the only way to properly reset from 1.8V is to have a VDD supply on the microSD card that can be turned off before booting to Linux? We have never had that before and never encountered something like this. >>> >>> Yes, the only safe way to use UHS-I really anyway. >> >> I can second that. And also keep in mind that the actual supply >> voltage must be below that threshold. Thus, the power-off time also >> depends on the capacitance on that supply line after the power load >> switch. There are switches with dedicated output discharge circuits >> built-in. >> >> That being said, from my experience there are cards which will work >> when switching back from 1V8 to 3V3 signalling and some don't. I >> haven't digged deeper into that topic, though. >> >> -michael >> >>> You could disable UHS for u-boot but that still leaves (potentially) >>> problematic warm-reboots of the board. >>> Having a (software-controlled) switchable regulator on SD VCC is pretty >>> common for this reason and you should be able to find it in most dts >>> for host controllers with sd-uhs-* property. >>> I'm afraid that the relevant spec section isn't available in the >>> simplified version. >>> >>> Kind Regards, >>> Christian >> > > Thanks for both of your responses here! > > I have a situation where I can re-create a problem switching from 1.8V > back to 3.3V with a specific card on a board that has ESD protection > between the IMX8MM host and the microSD connector (Semtech > ECLAMP2410P.TCT [1]) but works just fine on a previous revision of > that same PCB that does not have the ESD protection added. Boards with > proper ESD protection are the first time I've seen this issue occur. > Does this make sense at all? I have some hypothesis but that isn't even worth sharing, see below. > > I believe that the MMC device is 'reset' via a series of CLK cycles > with CMD/DAT non-asserted so I'm having a difficult time understanding > how this wouldn't work if the host has been reset to 3.3V. My answer is simple but not very satisfying: It is out of spec. After the CMD11 UHS voltage switch anything on CMD, DAT and CLK you drive from the host at 3.3V without a proper powercycle is out of spec, the card's behavior isn't covered by the SD spec and the card isn't to blame. If you want a really detailed answer try asking your SD card vendor, my guess would be their answer is "the host is out of spec". Kind Regards, Christian
Re: [PATCH RFC] gpio: Fix probing of gpio-hogs
On Thu, Jun 13, 2024 at 11:59:05AM +0100, Chris Webb wrote:
> 48b3ecbe replumbed the gpio-hog probing to use DM_FLAG_PROBE_AFTER_BIND.
>
> Unfortunately gpio_post_bind is called after the non-preloc recursive
> dm_probe_devices completes, so setting this flag does not have the intended
> effect and the gpio-hogs never get probed. With instrumentation:
>
> [...]
> CPU: MediaTek MT7981
> Model: GL.iNet GL-X3000
> DRAM: 512 MiB
>
>
>
> [...]
>
> Core: 34 devices, 14 uclasses, devicetree: separate
> MMC:
> mmc@1123: 0
> [...]
>
> Probe them directly in gpio_post_bind instead.
>
> Signed-off-by: Chris Webb
> ---
> drivers/gpio/gpio-uclass.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index 4234cd91..1c6e1715 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -1539,7 +1539,9 @@ static int gpio_post_bind(struct udevice *dev)
>* since hogs can be essential to the hardware
>* system.
>*/
> - dev_or_flags(child, DM_FLAG_PROBE_AFTER_BIND);
> + ret = device_probe(child);
> + if (ret)
> + return ret;
> }
> }
> }
Adding Marek, as the author of commit 48b3ecbedf82 ("gpio: Get rid of
gpio_hog_probe_all()").
--
Tom
signature.asc
Description: PGP signature
[PATCH] efi_loader: adjust config options for capsule updates
EFI_IGNORE_OSINDICATIONS is used to ignore OsIndications if setvariable at runtime is not supported and allow the platform to perform capsule updates on disk. With the recent changes boards can conditionally enable setvariable at runtime using EFI_RT_VOLATILE_STORE. Let's make that visible in our Kconfigs and enable EFI_IGNORE_OSINDICATIONS when set variable at runtime is disabled. Since EFI_RT_VOLATILE_STORE needs help from the OS to persist the variables, allow users to ignore OsIndications even if setvariable at runtime is enabled. Signed-off-by: Ilias Apalodimas --- lib/efi_loader/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index ee71f417147a..6006e845cb1f 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -220,6 +220,7 @@ config EFI_CAPSULE_ON_DISK config EFI_IGNORE_OSINDICATIONS bool "Ignore OsIndications for CapsuleUpdate on-disk" depends on EFI_CAPSULE_ON_DISK + default y if !EFI_RT_VOLATILE_STORE help There are boards where U-Boot does not support SetVariable at runtime. Select this option if you want to use the capsule-on-disk feature -- 2.43.0
Re: [PATCH 0/4] boot: fix crash in bootflow menu with EFI BOOTMGR support + typos
On Wed, 12 Jun 2024 16:58:45 +0200, Quentin Schulz wrote: > bootflow menu currently crashes U-Boot with a NULL pointer dereference > because bootflow->dev is NULL for global bootmeths (such as EFI BOOTMGR). > Therefore, let's check if the bootflow is associated with a global > bootmeth before trying to make it part of the menu. > > While this makes U-Boot not crash anymore, bootflow menu doesn't work > for me (I have never had a happy path with it, but I haven't actually > tried it before today :) ) and this was basically just implemented > following Simon's suggestion sent over IRC. No clue if this is enough or > just a quick band-aid patch. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH 0/3] lib: smbios: Extend driver with using sysinfo driver
On Fri, 26 Apr 2024 15:38:10 +0200, Michal Simek wrote: > currently only DT way is supported and it is added directly to lib/smbios.c > but I think DT and env is only one way how information can be found that's > why this series is improving handling with using sysinfo driver which can > be platform specific. > At the end of day DT should be taken from smbios.c and put to sysinfo DT > driver instead of implementing it directly in this generic file. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] efi_loader: adjust config options for capsule updates
Hi Heinrich, On Thu, 20 Jun 2024 at 18:23, Heinrich Schuchardt wrote: > > On 18.06.24 17:49, Ilias Apalodimas wrote: > > EFI_IGNORE_OSINDICATIONS is used to ignore OsIndications if setvariable > > at runtime is not supported and allow the platform to perform capsule > > updates on disk. With the recent changes boards can conditionally enable > > setvariable at runtime using EFI_RT_VOLATILE_STORE. > > > > So let's make the options depend on each other and clarify their > > functionality. When EFI_RT_VOLATILE_STORE, setvariable at runtime is > > supported and EFI_IGNORE_OSINDICATIONS, which also breaks the EFI spec, is > > not needed anymore. > > > > Signed-off-by: Ilias Apalodimas > > --- > > lib/efi_loader/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index 430bb7f0f7dc..c84064de1366 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -220,6 +220,8 @@ config EFI_CAPSULE_ON_DISK > > config EFI_IGNORE_OSINDICATIONS > > bool "Ignore OsIndications for CapsuleUpdate on-disk" > > depends on EFI_CAPSULE_ON_DISK > > + depends on !EFI_RT_VOLATILE_STORE > > EFI_RT_VOLATILE_STORE does not imply that the OS that you are running > supports writing variables to ubootefi.var or eMMC. > > How about > > default y if !EFI_RT_VOLATILE_STORE Sure, that works for me. I'll send a v2 Cheers > > Best regards > > Heinrich > > > + default y > > help > > There are boards where U-Boot does not support SetVariable at > > runtime. > > Select this option if you want to use the capsule-on-disk feature >
Re: [PATCH 1/2] tpm: Fix return code, if the eventlog buffer is full
On Thu, 20 Jun 2024 at 22:16, Ilias Apalodimas
wrote:
>
> We currently return 'No space left on device' if the eventlong buffer
> we allocated is not enough. On a similar check later on that function
> during the call to tcg2_log_init() we return 'No buffer space
> available'. So switch both error codes to -ENOBUFS since we are always
> checking a buffer and not a device.
>
> Fixes: 97707f12fdab ("tpm: Support boot measurements")
and now I wonder why checkpatch didn't warn on this. There's a
'commit' missing after the Fixes tag. Sorry!
> Signed-off-by: Ilias Apalodimas
> ---
> lib/tpm-v2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index a67daed2f3c1..91526af33acb 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@ -554,7 +554,7 @@ int tcg2_log_prepare_buffer(struct udevice *dev, struct
> tcg2_event_log *elog,
> if (elog->log_size) {
> if (log.found) {
> if (elog->log_size < log.log_position)
> - return -ENOSPC;
> + return -ENOBUFS;
>
> /*
> * Copy the discovered log into the user
> buffer
> --
> 2.45.2
>
[PATCH 2/2] efi_loader: fix return values on efi_tcg
A while back we moved the core functions of the EFI TCG protocol to the
TPM APIs in order for them to be used with bootm, booti etc.
Some prototypes changed from returning efi_status_t to int, which is more
appropriate for the non-EFI APIs. However, some of the EFI callsites never
changed and we ended up assigning the int value to efi_status_t.
This is unlikely to cause any problems, apart from returning invalid
values on failures and violating the EFI spec. Let's fix them
by looking at the new return code and map it to the proper EFI return
code on failures.
Fixes: commit 97707f12fdab ("tpm: Support boot measurements")
Fixes: commit d6b55a420cfc ("efi_loader: startup the tpm device when installing
the protocol")
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_tcg2.c | 121 --
1 file changed, 64 insertions(+), 57 deletions(-)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 51264c1b998c..37783942d716 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -254,8 +254,8 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol *this,
capability->protocol_version.major = 1;
capability->protocol_version.minor = 1;
- efi_ret = tcg2_platform_get_tpm2();
- if (efi_ret != EFI_SUCCESS) {
+ ret = tcg2_platform_get_tpm2();
+ if (ret) {
capability->supported_event_logs = 0;
capability->hash_algorithm_bitmap = 0;
capability->tpm_present_flag = false;
@@ -350,8 +350,7 @@ efi_tcg2_get_eventlog(struct efi_tcg2_protocol *this,
goto out;
}
- ret = tcg2_platform_get_tpm2();
- if (ret != EFI_SUCCESS) {
+ if (tcg2_platform_get_tpm2()) {
event_log_location = NULL;
event_log_last_entry = NULL;
*event_log_truncated = false;
@@ -386,7 +385,7 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64
efi_size,
void *new_efi = NULL;
u8 hash[TPM2_SHA512_DIGEST_SIZE];
struct udevice *dev;
- efi_status_t ret;
+ efi_status_t ret = EFI_SUCCESS;
u32 active;
int i;
@@ -401,12 +400,13 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64
efi_size,
goto out;
}
- ret = tcg2_platform_get_tpm2();
- if (ret != EFI_SUCCESS)
+ if (tcg2_platform_get_tpm2()) {
+ ret = EFI_DEVICE_ERROR;
goto out;
+ }
- ret = tcg2_get_active_pcr_banks(dev, );
- if (ret != EFI_SUCCESS) {
+ if (tcg2_get_active_pcr_banks(dev, )) {
+ ret = EFI_DEVICE_ERROR;
goto out;
}
@@ -470,12 +470,12 @@ efi_status_t tcg2_measure_pe_image(void *efi, u64
efi_size,
IMAGE_DOS_HEADER *dos;
IMAGE_NT_HEADERS32 *nt;
struct efi_handler *handler;
+ int rc;
if (!is_tcg2_protocol_installed())
return EFI_SUCCESS;
- ret = tcg2_platform_get_tpm2();
- if (ret != EFI_SUCCESS)
+ if (tcg2_platform_get_tpm2())
return EFI_SECURITY_VIOLATION;
switch (handle->image_type) {
@@ -499,9 +499,9 @@ efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
if (ret != EFI_SUCCESS)
return ret;
- ret = tcg2_pcr_extend(dev, pcr_index, _list);
- if (ret != EFI_SUCCESS)
- return ret;
+ rc = tcg2_pcr_extend(dev, pcr_index, _list);
+ if (rc)
+ return EFI_DEVICE_ERROR;
ret = efi_search_protocol(>header,
_guid_loaded_image_device_path, );
@@ -571,9 +571,10 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol
*this, u64 flags,
struct efi_tcg2_event *efi_tcg_event)
{
struct udevice *dev;
- efi_status_t ret;
+ efi_status_t ret = EFI_SUCCESS;
u32 event_type, pcr_index, event_size;
struct tpml_digest_values digest_list;
+ int rc = 0;
EFI_ENTRY("%p, %llu, %llu, %llu, %p", this, flags, data_to_hash,
data_to_hash_len, efi_tcg_event);
@@ -583,9 +584,10 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol
*this, u64 flags,
goto out;
}
- ret = tcg2_platform_get_tpm2();
- if (ret != EFI_SUCCESS)
+ if (tcg2_platform_get_tpm2()) {
+ ret = EFI_DEVICE_ERROR;
goto out;
+ }
if (efi_tcg_event->size < efi_tcg_event->header.header_size +
sizeof(u32)) {
@@ -618,8 +620,10 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol
*this, u64 flags,
ret = tcg2_hash_pe_image((void *)(uintptr_t)data_to_hash,
data_to_hash_len, _list);
} else {
- ret = tcg2_create_digest(dev, (u8 *)(uintptr_t)data_to_hash,
-data_to_hash_len, _list);
+
[PATCH 1/2] tpm: Fix return code, if the eventlog buffer is full
We currently return 'No space left on device' if the eventlong buffer
we allocated is not enough. On a similar check later on that function
during the call to tcg2_log_init() we return 'No buffer space
available'. So switch both error codes to -ENOBUFS since we are always
checking a buffer and not a device.
Fixes: 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Ilias Apalodimas
---
lib/tpm-v2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index a67daed2f3c1..91526af33acb 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -554,7 +554,7 @@ int tcg2_log_prepare_buffer(struct udevice *dev, struct
tcg2_event_log *elog,
if (elog->log_size) {
if (log.found) {
if (elog->log_size < log.log_position)
- return -ENOSPC;
+ return -ENOBUFS;
/*
* Copy the discovered log into the user buffer
--
2.45.2
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
On Thu, 20 Jun 2024 at 18:41, Alex Bee wrote: > > > Am 20.06.24 um 19:08 schrieb Tom Rini: > > On Thu, Jun 20, 2024 at 07:03:26PM +0200, Alex Bee wrote: > >> Am 20.06.24 um 12:24 schrieb Quentin Schulz: > >>> From: Quentin Schulz > >>> > >>> No meaningful changes were made to this SoM since February 2021. Nobody > >>> from Theobroma has booted anything recent on that product since July > >>> 2021 at the latest. The product isn't available to buy anymore and > >>> disappeared from our website. > >>> > >>> This product is therefore unmaintained and it would be disingenuous to > >>> say the opposite, so drop support for RK3368 Lion. > >>> > >>> If you're a user of Lion, feel free to revert this patch or contact our > >>> sales/support department. > >> That's a pretty interesting support-strategy. While I really don't care for > >> this board, please don't go ahead and remove the whole TPL-/SPL-part for > >> RK3368 in yet another pointless "cleanup" only because lion was one the of > >> last/only user. Even if EOL RK3368 is getting finally interesting in > >> regards of display pipeline as we are finally getting a OSS gpu driver [0]. > >> I'm planning to add a board which uses TPL/SPL soonish (when my rare spare > >> time allows). > > Please update the MAINTAINERS file for the relevant to your future > > platform, or even better possibly get a skeleton of this platform > > posted. Thanks. > > > I don't think the whole platform would get removed as it has several users > (and is maintained) - I just was a bit worried that TPL/SPL support could > get removed, but now noticed there is one more user: evb-px5. So: sorry for > noise. > So I will go the usual way via upstream DT (linux tree) addition and so > forth. It's easy enough to bring back the pieces from git, I have a geekbox somewhere I've always meant to take a closer look at.
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
Am 20.06.24 um 19:08 schrieb Tom Rini: On Thu, Jun 20, 2024 at 07:03:26PM +0200, Alex Bee wrote: Am 20.06.24 um 12:24 schrieb Quentin Schulz: From: Quentin Schulz No meaningful changes were made to this SoM since February 2021. Nobody from Theobroma has booted anything recent on that product since July 2021 at the latest. The product isn't available to buy anymore and disappeared from our website. This product is therefore unmaintained and it would be disingenuous to say the opposite, so drop support for RK3368 Lion. If you're a user of Lion, feel free to revert this patch or contact our sales/support department. That's a pretty interesting support-strategy. While I really don't care for this board, please don't go ahead and remove the whole TPL-/SPL-part for RK3368 in yet another pointless "cleanup" only because lion was one the of last/only user. Even if EOL RK3368 is getting finally interesting in regards of display pipeline as we are finally getting a OSS gpu driver [0]. I'm planning to add a board which uses TPL/SPL soonish (when my rare spare time allows). Please update the MAINTAINERS file for the relevant to your future platform, or even better possibly get a skeleton of this platform posted. Thanks. I don't think the whole platform would get removed as it has several users (and is maintained) - I just was a bit worried that TPL/SPL support could get removed, but now noticed there is one more user: evb-px5. So: sorry for noise. So I will go the usual way via upstream DT (linux tree) addition and so forth.
Re: [PATCH v3 0/9] misc: introduce STATUS LED activity function
On Wed, 12 Jun 2024 at 03:33, Christian Marangi wrote: > > This series expand the STATUS LED framework with a new color > and a big new feature. One thing that many device need is a way > to communicate to the user that the device is actually doing > something. > > This is especially useful for recovery steps where an > user (for example) insert an USB drive, keep a button pressed > and the device autorecover. > > There is currently no way to signal the user externally that > the bootloader is processing/recoverying aside from setting > a LED on. > > A solid LED on is not enough and won't actually signal any > kind of progress. > Solution is the good old blinking LED but uboot doesn't > suggest (and support) interrupts and almost all the LED > are usually GPIO LED that doesn't support HW blink. > > To fix this and handle the problem of device not supporting > HW blink, expand the STATUS LED framework with new API. > > We introduce a new config LED_STATUS_ACTIVITY, that similar > to the RED, GREEN and others, takes the LED ID set in > the LED_STATUS config and is used as the global LED for activity > operations. > > We add status_led_activity_start/stop() used to turn the > activity LED on and register a cyclic to make it blink. > LED will continue to blink until _stop() is called. > > Function that will start some kind of action will first call > _start() and then at the end will call stop(). > If (on the broken implementation) a _start() is called before > calling a _stop(), the Cyclic is first unregister and is > registered again. > > Support for this is initially added to the tftp, mtd and ubi > command. > > This also contains a big fixup for the gpio_led driver that > currently deviates from the Documentation and make the > coloured status led feature unusable. > > Changes v3: > - Add log on Status LED error conditions > Changes v2: > - Add Documentation conversion > - Rework to Cyclic and simplify implementation > > Christian Marangi (9): > misc: gpio_led: fix broken coloured LED status functions > led: status_led: add support for white LED colour > led: status_led: add function to toggle a status LED > led: status_led: add warning when an invalid Status LED ID is used > led: status_led: add new activity LED config and functions > tftp: implement support for LED status activity > mtd: implement support for LED status activity > ubi: implement support for LED status activity > doc: convert README.LED to .rst documentation > > cmd/legacy_led.c | 6 + > cmd/mtd.c | 19 > cmd/ubi.c | 15 ++- > common/board_f.c | 2 + > doc/README.LED| 77 - > doc/api/index.rst | 1 + > doc/api/status_led.rst| 35 ++ > drivers/led/Kconfig | 30 + > drivers/misc/gpio_led.c | 41 +-- Does it make sense to move misc/gpio_led.c to drivers/led as that's where the Kconfig is? > drivers/misc/status_led.c | 75 - > include/status_led.h | 231 +- > net/tftp.c| 7 ++ > 12 files changed, 440 insertions(+), 99 deletions(-) > delete mode 100644 doc/README.LED > create mode 100644 doc/api/status_led.rst > > -- > 2.43.0 >
Re: [PATCH v4 4/9] led: status_led: add warning when an invalid Status LED ID is used
On Thu, 20 Jun 2024 at 02:51, Christian Marangi wrote:
>
> Add a warning when an invalid Status LED ID is used to make the user
> aware of bad configurations.
>
> Signed-off-by: Christian Marangi
> ---
> drivers/misc/status_led.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
> index 2b904bfa9c2..7912b4a9448 100644
> --- a/drivers/misc/status_led.c
> +++ b/drivers/misc/status_led.c
> @@ -105,8 +105,10 @@ void status_led_tick(ulong timestamp)
>
> static led_dev_t *status_get_led_dev(int led)
> {
> - if (led < 0 || led >= MAX_LED_DEV)
> + if (led < 0 || led >= MAX_LED_DEV) {
> + printf("Invalid Status LED ID %d.", led);
I think this needs a \n to ensure what ever the next message is it
will be on a new line.
> return NULL;
> + }
>
> if (!status_led_init_done)
> status_led_init();
> --
> 2.43.0
>
Re: [PATCH v4 9/9] doc: convert README.LED to .rst documentation
On 6/20/24 06:37, Christian Marangi wrote: On Thu, Jun 20, 2024 at 08:13:34AM +0200, Heinrich Schuchardt wrote: On 6/20/24 01:03, Christian Marangi wrote: Convert README.LED to .rst documentation and include all the relevant documentation in the status_led.h. Signed-off-by: Christian Marangi --- doc/README.LED | 77 -- doc/api/index.rst | 1 + doc/api/status_led.rst | 35 +++ include/status_led.h | 224 - 4 files changed, 256 insertions(+), 81 deletions(-) delete mode 100644 doc/README.LED create mode 100644 doc/api/status_led.rst diff --git a/doc/README.LED b/doc/README.LED deleted file mode 100644 index c21c9d53ec3..000 --- a/doc/README.LED +++ /dev/null @@ -1,77 +0,0 @@ -Status LED - - -This README describes the status LED API. - -The API is defined by the include file include/status_led.h - -The first step is to enable CONFIG_LED_STATUS in menuconfig: -> Device Drivers > LED Support. - -If the LED support is only for specific board, enable -CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. - -Status LEDS 0 to 5 are enabled by the following configurations at menuconfig: -CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 - -The following should be configured for each of the enabled LEDs: -CONFIG_STATUS_LED_BIT -CONFIG_STATUS_LED_STATE -CONFIG_STATUS_LED_FREQ -Where is an integer 1 through 5 (empty for 0). - -CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED -is being acted on. As such, the value choose must be unique with with respect to -the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the -reponsiblity of the __led_* function. - -CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one -of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. - -CONFIG_STATUS_LED_FREQ determines the LED blink frequency. -Values range from 2 to 10. - -Some other LED macros -- - -CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. -This must be a valid LED number (0-5). - -CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be -a valid LED number (0-5). Other similar color LED's macros are -CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE. - -General LED functions -- -The following functions should be defined: - -__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. -One time start up code should be placed here. - -__led_set is called to change the state of the LED. - -__led_toggle is called to toggle the current state of the LED. - -Colour LED - - -Colour LED's are at present only used by ARM. - -The functions names explain their purpose. - -coloured_LED_init -red_LED_on -red_LED_off -green_LED_on -green_LED_off -yellow_LED_on -yellow_LED_off -blue_LED_on -blue_LED_off - -These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define -these functions in the board specific source. - -TBD : Describe older board dependent macros similar to what is done for - -TBD : Describe general support via asm/status_led.h diff --git a/doc/api/index.rst b/doc/api/index.rst index 51b2013af36..d40e90801d1 100644 --- a/doc/api/index.rst +++ b/doc/api/index.rst @@ -22,6 +22,7 @@ U-Boot API documentation rng sandbox serial + status_led sysreset timer unicode diff --git a/doc/api/status_led.rst b/doc/api/status_led.rst new file mode 100644 index 000..44bbea47157 --- /dev/null +++ b/doc/api/status_led.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Status LED +== + +.. kernel-doc:: include/status_led.h + :doc: Overview + +CONFIG_STATUS_LED Description +- + +.. kernel-doc:: include/status_led.h + :doc: CONFIG Description + +Special Status LED Configs +-- +.. kernel-doc:: include/status_led.h + :doc: LED Status Config + +Colour Status LED Configs +- +.. kernel-doc:: include/status_led.h + :doc: LED Colour Config + +Required API + + +.. kernel-doc:: include/status_led.h + :doc: Required API + +Status LED API +-- + +.. kernel-doc:: include/status_led.h + :internal: diff --git a/include/status_led.h b/include/status_led.h index 7de40551621..6893d1d68e0 100644 --- a/include/status_led.h +++ b/include/status_led.h @@ -4,18 +4,102 @@ * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ -/* - * The purpose of this code is to signal the operational status of a +/** + * DOC: Overview + * + * Status LED is a Low-Level way to handle LEDs to signal state of the Status LEDs can be used to signal the operational status of a + * bootloader, for example boot progress, file transfer fail, activity + * of some sort like tftp
Re: [PATCH v4 00/14] Introduce the lwIP network stack
On Mon, Jun 17, 2024 at 8:33 AM Jerome Forissier wrote: > > This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip > library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP > stack [2] [3] as an alternative to the current implementation in net/, > selectable with Kconfig, and ultimately keep only lwIP if possible. Some > reasons for doing so are: > - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) > has some additional lwIP and Mbed TLS patches to do so. With that it > becomes possible to fetch and launch a distro installer such as Debian > etc. using a secure, authenticated connection directly from the U-Boot > shell. Several use cases: > * Authentication: prevent MITM attack (third party replacing the > binary with a different one) > * Confidentiality: prevent third parties from grabbing a copy of the > image as it is being downloaded > * Allow connection to servers that do not support plain HTTP anymore > (this is becoming more and more common on the Internet these days) > - Possibly benefit from additional features implemented in lwIP > - Less code to maintain in U-Boot > > Prior to applying this series, the lwIP stack needs to be added as a > Git subtree with the following command: > > $ git subtree add --squash --prefix lib/lwip/lwip > https://git.savannah.gnu.org/git/lwip.git STABLE-2_2_0_RELEASE > > The first patch renames some enums in order to avoid a conflict when a > later patch enables the lwIP library. > > The second patch introduces a new Kconfig symbol: NET_LWIP, which selects > the lwIP implementation instead of the current one (NET). Contrary to the > approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled > simultaneously. The rationale is we want to start from a clean state and > not pull potentially duplicated functionality from both stacks. Note > however that a few files are still built in net/, they are the ones > related to ethernet device management and the ethernet bootflow. > > The third patch splits the net.h header into net-legacy.h, net-common.h, > net-lwip.h, leaving net.h as a simple wrapper. > > The fourth patch introduces the Makefile to build lwIP when NET_LWIP is > enabled. > > The subsequent patches implement various network-oriented commands and > features: dhcp, dns, ping, tftpboot, wget. > > A number of features are currently incompatible with NET_LWIP: SANDBOX, > DFU_TFTP, FASTBOOT, SPL_NET. All make assumptions on how the network > stack is implemented and/or pull sybols that are not trivially exported > from lwIP. Some interface rework may be needed. > > Due to the above and in order to provide some level of testing, a new QEMU > configuration is introduced (qemu_arm64_lwip_defconfig) which is the same > as qemu_arm64_defconfig but with NET_LWIP and CMD_*_LWIP enabled. > Tests are added to test/py/tests/test_net.py for that configuration. > Hi Jermone, I've given this a spin on an imx8mm-venice-gw73xx-0x via imx8mm_venice_defconfig and I can't get DHCP to work (didn't work in v3 either): $ diff defconfig configs/imx8mm_venice_defconfig 68,69c68,71 < CONFIG_CMD_DNS_LWIP=y < CONFIG_CMD_WGET_LWIP=y --- > CONFIG_CMD_DHCP6=y > CONFIG_CMD_TFTPPUT=y > CONFIG_SYS_DISABLE_AUTOLOAD=y > CONFIG_CMD_WGET=y 88,90c90,94 < CONFIG_NET_LWIP=y < CONFIG_LWIP_DEBUG=y < CONFIG_LWIP_ASSERT=y --- > CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_IP_DEFRAG=y > CONFIG_TFTP_BLOCKSIZE=4096 > CONFIG_PROT_TCP_SACK=y > CONFIG_IPV6=y Target: u-boot=> net list eth0 : ethernet@30be 00:d0:12:b5:f8:41 active u-boot=> dhcp || echo fail eth0: ethernet@30be 00:d0:12:b5:f8:41 active netif_set_ipaddr: netif address being changed netif: added interface 0 addr 192.168.1.1 netmask 0.0.0.0 gw 0.0.0.0 etharp_request: sending ARP request. etharp_raw: sending raw ARP packet. ethernet_output: sending packet 7df00bf0 dhcp_start(netif=7df2af40) 0dhcp_start(): mallocing new DHCP client dhcp_start(): allocated dhcp dhcp_start(): starting DHCP configuration dhcp_discover() transaction id xid(42021) dhcp_discover: making request dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, LWIP_IANA_PORT_DHCP_SERVER) ip4_output_if: 0IP header: +---+ | 4 | 5 | 0x00 | 336 | (v, hl, tos, len) +---+ |0 |000| 0 | (id, flags, offset) +---+ | 255 | 17 |0xba9d | (ttl, proto, chksum) +---+ |0 |0 |0 |0 | (src) +---+ | 255 | 255 | 255 | 255 | (dest) +---+ ip4_output_if: call netif->output() ethernet_output: sending packet 7df2c010 dhcp_discover: deleting() dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:28:28:5d:bb:16:9f, type:8899 ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:00:27:0e:0d:74:ba, type:806 etharp_update_arp_entry:
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
On Thu, Jun 20, 2024 at 07:03:26PM +0200, Alex Bee wrote: > Am 20.06.24 um 12:24 schrieb Quentin Schulz: > > From: Quentin Schulz > > > > No meaningful changes were made to this SoM since February 2021. Nobody > > from Theobroma has booted anything recent on that product since July > > 2021 at the latest. The product isn't available to buy anymore and > > disappeared from our website. > > > > This product is therefore unmaintained and it would be disingenuous to > > say the opposite, so drop support for RK3368 Lion. > > > > If you're a user of Lion, feel free to revert this patch or contact our > > sales/support department. > That's a pretty interesting support-strategy. While I really don't care for > this board, please don't go ahead and remove the whole TPL-/SPL-part for > RK3368 in yet another pointless "cleanup" only because lion was one the of > last/only user. Even if EOL RK3368 is getting finally interesting in > regards of display pipeline as we are finally getting a OSS gpu driver [0]. > I'm planning to add a board which uses TPL/SPL soonish (when my rare spare > time allows). Please update the MAINTAINERS file for the relevant to your future platform, or even better possibly get a skeleton of this platform posted. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
Am 20.06.24 um 12:24 schrieb Quentin Schulz: From: Quentin Schulz No meaningful changes were made to this SoM since February 2021. Nobody from Theobroma has booted anything recent on that product since July 2021 at the latest. The product isn't available to buy anymore and disappeared from our website. This product is therefore unmaintained and it would be disingenuous to say the opposite, so drop support for RK3368 Lion. If you're a user of Lion, feel free to revert this patch or contact our sales/support department. That's a pretty interesting support-strategy. While I really don't care for this board, please don't go ahead and remove the whole TPL-/SPL-part for RK3368 in yet another pointless "cleanup" only because lion was one the of last/only user. Even if EOL RK3368 is getting finally interesting in regards of display pipeline as we are finally getting a OSS gpu driver [0]. I'm planning to add a board which uses TPL/SPL soonish (when my rare spare time allows). Alex [0] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/issues/1
Re: [PATCH v4 0/9] misc: introduce STATUS LED activity function
On Thu, Jun 20, 2024 at 06:29:23AM +0200, Christian Marangi wrote: > On Thu, Jun 20, 2024 at 08:34:03AM +0200, Heinrich Schuchardt wrote: > > On 6/20/24 01:03, Christian Marangi wrote: > > > This series expand the STATUS LED framework with a new color > > > and a big new feature. One thing that many device need is a way > > > to communicate to the user that the device is actually doing > > > something. > > > > > > This is especially useful for recovery steps where an > > > user (for example) insert an USB drive, keep a button pressed > > > and the device autorecover. > > > > > > There is currently no way to signal the user externally that > > > the bootloader is processing/recoverying aside from setting > > > a LED on. > > > > > > A solid LED on is not enough and won't actually signal any > > > kind of progress. > > > Solution is the good old blinking LED but uboot doesn't > > > suggest (and support) interrupts and almost all the LED > > > are usually GPIO LED that doesn't support HW blink. > > > > > > To fix this and handle the problem of device not supporting > > > HW blink, expand the STATUS LED framework with new API. > > > > > > We introduce a new config LED_STATUS_ACTIVITY, that similar > > > to the RED, GREEN and others, takes the LED ID set in > > > the LED_STATUS config and is used as the global LED for activity > > > operations. > > > > > > We add status_led_activity_start/stop() used to turn the > > > activity LED on and register a cyclic to make it blink. > > > LED will continue to blink until _stop() is called. > > > > > > Function that will start some kind of action will first call > > > _start() and then at the end will call stop(). > > > If (on the broken implementation) a _start() is called before > > > calling a _stop(), the Cyclic is first unregister and is > > > registered again. > > > > > > Support for this is initially added to the tftp, mtd and ubi > > > command. > > > > > > This also contains a big fixup for the gpio_led driver that > > > currently deviates from the Documentation and make the > > > coloured status led feature unusable. > > > > > > (world tested with the azure pipeline) > > > > Hello Christian, > > > > What is the relationship between CONFIG_LED and CONFIG_LED_STATUS? > > Can they be used at the same time or should they be exclusive? > > Should CONFIG_LED_STATUS depend on CONFIG_LED? > > Well this is something that should have been fixed long time ago. > Given the 2 cmd and some function clash with each other they are totally > incompatible with each other and one should exclude the other. Yes, sorry, I missed this earlier on, my fault. The CONFIG_LED_STATUS code is legacy and indeed shouldn't be enabled on anything new (and ideally, someone would care enough to transition the few platforms using the old framework over). So this functionality should be added to the drivers/led/ framework and then yes, your platforms defining the LED via device tree, with the same compatibles the Linux needs anyhow to be able to control it too. -- Tom signature.asc Description: PGP signature
Re: obscure microsd detection issue between U-Boot and kernel
On Tue, Jun 4, 2024 at 1:14 AM Michael Walle wrote: > > On Tue Jun 4, 2024 at 9:47 AM CEST, Christian Loehle wrote: > > On 6/3/24 22:28, Tim Harvey wrote: > > > On Mon, Jun 3, 2024 at 1:18 AM Christian Loehle > > > wrote: > > >> > > >> On 5/31/24 21:47, Tim Harvey wrote: > > >>> Greetings, > > >>> > > >>> I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where > > >>> for a specific set of microsd cards if I have accessed the microsd in > > >>> U-Boot with UHS/1.8V the kernel will not recognize that microsd when > > >>> scanning. > > >>> > > >>> The issue does not occur with all microsd cards but seems to appear > > >>> with a large sample size of a specific card/model (Kingston SDC32 32GB > > >>> SDR104 card). I do not see a signal integrity issue on the scope. > > >>> > > >>> Instrumenting the kernel the issue is that the host reports a CRC > > >>> error as soon as the first mmc_send_if_cond call which occurs in > > >>> mmc_rescan_try_freq. > > >>> > > >>> I can avoid the issue by either not accessing the microsd in U-Boot or > > >>> by disabling UHS/1.8V mode in U-Boot therefore what I think is > > >>> happening is that U-Boot leaves the card in UHS/1.8V signalling mode > > >>> and when the kernel scans it sets the voltage back to 3.3V > > >>> standard/default and default timings then issues its clock cycles to > > >>> 'reset' the card and the card does not recognize the reset. I'm > > >>> wondering if this is because the reset is done via clock cycles after > > >>> the kernel has set the I/O voltage back to 3.3V when perhaps the card > > >>> is still in 1.8V mode (although I don't see how that would cause an > > >>> issue)? > > >> > > >> It will cause an issue for many cards and might break some cards. > > >> > > >>> > > >>> Is there some sort of MMC 'reset' I can/should do in U-Boot before > > >>> booting the kernel? Has anyone encountered anything like this before? > > >> > > >> There is no 'switching back' to 3.3V signalling from UHS 1.8V. > > >> The only way this can be done is therefore a full power-off. > > >> Is that done correctly for your system? > > >> AFAIR spec dictates 500ms of <0.5V on VCC. Note that driving CLK/signal > > >> lines can also sustain the card somewhat, as leakage is only limited > > >> within operating voltage. > > > > > > Hi Christian, > > > > > > Are you saying the only way to properly reset from 1.8V is to have a > > > VDD supply on the microSD card that can be turned off before booting > > > to Linux? We have never had that before and never encountered > > > something like this. > > > > Yes, the only safe way to use UHS-I really anyway. > > I can second that. And also keep in mind that the actual supply > voltage must be below that threshold. Thus, the power-off time also > depends on the capacitance on that supply line after the power load > switch. There are switches with dedicated output discharge circuits > built-in. > > That being said, from my experience there are cards which will work > when switching back from 1V8 to 3V3 signalling and some don't. I > haven't digged deeper into that topic, though. > > -michael > > > You could disable UHS for u-boot but that still leaves (potentially) > > problematic warm-reboots of the board. > > Having a (software-controlled) switchable regulator on SD VCC is pretty > > common for this reason and you should be able to find it in most dts > > for host controllers with sd-uhs-* property. > > I'm afraid that the relevant spec section isn't available in the > > simplified version. > > > > Kind Regards, > > Christian > Thanks for both of your responses here! I have a situation where I can re-create a problem switching from 1.8V back to 3.3V with a specific card on a board that has ESD protection between the IMX8MM host and the microSD connector (Semtech ECLAMP2410P.TCT [1]) but works just fine on a previous revision of that same PCB that does not have the ESD protection added. Boards with proper ESD protection are the first time I've seen this issue occur. Does this make sense at all? I believe that the MMC device is 'reset' via a series of CLK cycles with CMD/DAT non-asserted so I'm having a difficult time understanding how this wouldn't work if the host has been reset to 3.3V. Best Regards, Tim [1] https://www.semtech.com/products/circuit-protection/esd-emi-filter-devices/eclamp2410p
Re: [PATCH v5 1/2] arm: mediatek: add mt8195 SOC support
Hello,
What happened to this series? Has it been abandoned? Also, is it
possible to get memory size installed to the board dynamically?
Best regards,
Shengyu
在 2023/8/4 19:04, Macpaul Lin 写道:
From: Fabien Parent
The MediaTek MT8195 is a ARM64-based SoC with a quad-core Cortex-A73 and
a quad-core Cortex-A53. It is including UART, SPI, USB3.0 device and hosts,
SD and MMC cards, UFS, PWM, I2C, I2S, S/PDIF, and several LPDDR3
and LPDDR4 options.
Signed-off-by: Fabien Parent
Signed-off-by: Macpaul Lin
Reviewed-by: Simon Glass
---
MAINTAINERS| 2 +
arch/arm/dts/mt8195.dtsi | 370 +
arch/arm/mach-mediatek/Kconfig | 13 +-
arch/arm/mach-mediatek/Makefile| 1 +
arch/arm/mach-mediatek/mt8195/Kconfig | 13 +
arch/arm/mach-mediatek/mt8195/Makefile | 3 +
arch/arm/mach-mediatek/mt8195/init.c | 97 +++
7 files changed, 498 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/mt8195.dtsi
create mode 100644 arch/arm/mach-mediatek/mt8195/Kconfig
create mode 100644 arch/arm/mach-mediatek/mt8195/Makefile
create mode 100644 arch/arm/mach-mediatek/mt8195/init.c
Changes for v2:
- Correct node name to t-phy for u3phy0.
- Add platform compatible string "mediatek,mt8195-tphy" to all usb phy nodes.
- remove clock nodes that software cannot controlled in phy nodes.
- Test and add back "mac" for HOST only xhci nodes.
Changes for v3:
- Revise device node name from "xhciX: xhciX@" to "xhciX: xhci@".
Changes for v4:
- No change.
Changes for v5:
- Fix Copyright year to 2023.
- Fix memory map in dram_init() to support 8GB onboard memory.
- Add '#if !IS_ENABLED(CONFIG_SYSRESET)' with reset_cpu().
- Correct reset_cpu() function prototype.
- rebase patchset to v2023-10.rc1
- Add missing arch/arm/mach-mediatek/mt8195/Kconfig.
diff --git a/MAINTAINERS b/MAINTAINERS
index 47581cf6fb..4d0f017e7e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -369,8 +369,10 @@ ARM MEDIATEK
M:Ryder Lee
M:Weijie Gao
M:Chunfeng Yun
+M: Macpaul Lin
R:GSS_MTK_Uboot_upstream
S:Maintained
+F: arch/arm/dts/mt8195.dtsi
F:arch/arm/mach-mediatek/
F:arch/arm/include/asm/arch-mediatek/
F:board/mediatek/
diff --git a/arch/arm/dts/mt8195.dtsi b/arch/arm/dts/mt8195.dtsi
new file mode 100644
index 00..14cb28d008
--- /dev/null
+++ b/arch/arm/dts/mt8195.dtsi
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2023 MediaTek Inc.
+ * Copyright (C) 2023 BayLibre, SAS
+ * Author: Ben Ho
+ * Erin Lo
+ * Fabien Parent
+ * Macpaul Lin
+ */
+
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8195";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ core2 {
+ cpu = <>;
+ };
+ core3 {
+ cpu = <>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ core2 {
+ cpu = <>;
+ };
+ core3 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+
Re: [PATCH] efi_loader: adjust config options for capsule updates
On 18.06.24 17:49, Ilias Apalodimas wrote: EFI_IGNORE_OSINDICATIONS is used to ignore OsIndications if setvariable at runtime is not supported and allow the platform to perform capsule updates on disk. With the recent changes boards can conditionally enable setvariable at runtime using EFI_RT_VOLATILE_STORE. So let's make the options depend on each other and clarify their functionality. When EFI_RT_VOLATILE_STORE, setvariable at runtime is supported and EFI_IGNORE_OSINDICATIONS, which also breaks the EFI spec, is not needed anymore. Signed-off-by: Ilias Apalodimas --- lib/efi_loader/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 430bb7f0f7dc..c84064de1366 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -220,6 +220,8 @@ config EFI_CAPSULE_ON_DISK config EFI_IGNORE_OSINDICATIONS bool "Ignore OsIndications for CapsuleUpdate on-disk" depends on EFI_CAPSULE_ON_DISK + depends on !EFI_RT_VOLATILE_STORE EFI_RT_VOLATILE_STORE does not imply that the OS that you are running supports writing variables to ubootefi.var or eMMC. How about default y if !EFI_RT_VOLATILE_STORE Best regards Heinrich + default y help There are boards where U-Boot does not support SetVariable at runtime. Select this option if you want to use the capsule-on-disk feature
Re: [PATCH v3 6/7] tools: add genguid tool
On Fri, May 31, 2024 at 03:50:40PM +0200, Caleb Connolly wrote:
> Add a tool that can generate GUIDs that match those generated internally
> by U-Boot for capsule update fw_images.
Hi Caleb,
Thanks for working on this.
I think there is a leftover "dtb" option; see below.
Best regards,
Vincent.
>
> Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it
> with the board model, compatible, and fw_image name.
>
> This tool accepts the same inputs and will produce the same GUID as
> U-Boot would at runtime.
>
> Signed-off-by: Caleb Connolly
> ---
> doc/genguid.1 | 52 +++
> tools/Kconfig | 7 +++
> tools/Makefile | 3 ++
> tools/genguid.c | 154
>
> 4 files changed, 216 insertions(+)
(...)
> diff --git a/tools/genguid.c b/tools/genguid.c
> new file mode 100644
> index ..e71bc1d48f95
> --- /dev/null
> +++ b/tools/genguid.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2024 Linaro Ltd.
> + * Author: Caleb Connolly
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static struct option options[] = {
> + {"dtb", required_argument, NULL, 'd'},
I think this is unused.
> + {"compat", required_argument, NULL, 'c'},
> + {"help", no_argument, NULL, 'h'},
> + {"verbose", no_argument, NULL, 'v'},
> + {"json", no_argument, NULL, 'j'},
> + {NULL, 0, NULL, 0},
> +};
> +
> +static void usage(const char *progname)
> +{
> + fprintf(stderr, "Usage: %s GUID [-v] -c COMPAT NAME...\n", progname);
> + fprintf(stderr,
> + "Generate a v5 GUID for one of more U-Boot fw_images the same
> way U-Boot does at runtime.\n");
> + fprintf(stderr,
> + "\nOptions:\n"
> + " GUID namespace/salt GUID in 8-4-4-4-12
> format\n"
> + " -h, --help display this help and exit\n"
> + " -c, --compat=COMPAT first compatible property in the
> board devicetree\n"
> + " -v, --verboseprint debug messages\n"
> + " -j, --json output in JSON format\n"
> + " NAME... one or more names of fw_images to
> generate GUIDs for\n"
> + );
> + fprintf(stderr, "\nExample:\n");
> + fprintf(stderr, " %s 2a5aa852-b856-4d97-baa9-5c5f4421551f \\\n"
> + "\t-c \"qcom,qrb4210-rb2\" \\\n"
> + "\tQUALCOMM-UBOOT\n", progname);
> +}
> +
> +static size_t u16_strsize(const uint16_t *in)
> +{
> + size_t i = 0, count = UINT16_MAX;
> +
> + while (count-- && in[i])
> + i++;
> +
> + return (i + 1) * sizeof(uint16_t);
> +}
> +
> +int main(int argc, char **argv)
> +{
> + struct uuid namespace;
> + char *namespace_str;
> + char uuid_str[37];
> + char **image_uuids;
> + char *compatible = NULL;
> + uint16_t **images_u16;
> + char **images;
> + int c, n_images;
> + bool debug = false, json = false;
> +
> + if (argc < 2) {
> + usage(argv[0]);
> + return 1;
> + }
> +
> + namespace_str = argv[1];
> +
> + /* The first arg is the GUID so skip it */
> + while ((c = getopt_long(argc, argv, "c:hvj", options, NULL)) != -1) {
> + switch (c) {
> + case 'c':
> + compatible = strdup(optarg);
> + break;
> + case 'h':
> + usage(argv[0]);
> + return 0;
> + case 'v':
> + debug = true;
> + break;
> + case 'j':
> + json = true;
> + break;
> + default:
> + usage(argv[0]);
> + return 1;
> + }
> + }
> +
> + if (!compatible) {
> + fprintf(stderr, "ERROR: Please specify the compatible
> property.\n\n");
> + usage(argv[0]);
> + return 1;
> + }
> +
> + if (uuid_str_to_bin(namespace_str, (unsigned char *),
> UUID_STR_FORMAT_GUID)) {
> + fprintf(stderr, "ERROR: Check that your UUID is formatted
> correctly.\n");
> + exit(EXIT_FAILURE);
> + }
> +
> + /* This is probably not the best way to convert a string to a "u16"
> string */
> + n_images = argc - optind - 1;
> + images = argv + optind + 1;
> + images_u16 = calloc(n_images, sizeof(char *));
> + for (int i = 0; i < n_images; i++) {
> + images_u16[i] = calloc(1, strlen(images[i]) * 2 + 2);
> + for (int j = 0; j < strlen(images[i]); j++)
> + images_u16[i][j] = (uint16_t)images[i][j];
> + }
> +
> + if (debug) {
> + fprintf(stderr, "GUID: ");
> + uuid_bin_to_str((uint8_t *), uuid_str,
> UUID_STR_FORMAT_GUID);
>
Re: [PATCH] RFC: Add a tag for the world builds
On Thu, Jun 20, 2024 at 07:33:46AM -0600, Simon Glass wrote: > Currently the world builds run on all runners, including faster and > slower ones. > > The difference can be quite dramatic, with some builders 4x as fast as > others, resulting in just one world build taking between 20 minutes and > an hour and 20 minutes. > > Add a tag so that we can select which builders run these CPU-intensive > jobs. > > With this tag we can also increase CPU utilisation by running multiple > QEMU tests in parallel. Currently these tests leave most machines fairly > idle, since we cannot run more than one world build on a machine. > > Signed-off-by: Simon Glass This conflicts I think with Jiaxun's desire to make our GitLab job runnable on the public runners too, and where we'll end up with 10 world build jobs ala Azure. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: corstone1000: enable secondary cores for FVP
On Wed, 12 Jun 2024 11:04:21 +0100, harsimransingh.tun...@arm.com wrote: > Add the secondary cores nodes in the dts file > > Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v2 0/2] Enable ICSSG Driver for AM64x
On Wed, 12 Jun 2024 16:37:47 +0530, MD Danish Anwar wrote: > This series adds config changes and env changes to enable ICSSG Ethernet > Driver on AM64x. > > Changes since v1: > *) Dropped the patch [0] as this needs to be fixed in driver as suggested >by Andrew Davis > *) Rebased on latest u-boot/next. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH 5/5] CI: Run code-coverage test for Binman
On Thu, Jun 20, 2024 at 07:19:37AM -0600, Simon Glass wrote: > Binman includes a good set of tests covering all of its functionality. > This includes a code-coverage test. > > However to date the code-coverage test has not been checked > automatically by CI, relying on people to run 'binman test -T' > themselves. > > Plug the gap to avoid bugs creeping in future. > > Signed-off-by: Simon Glass > --- > > .gitlab-ci.yml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) This misses Azure, please update as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] buildman: Support building within a Python venv
On Thu, Jun 20, 2024 at 07:19:35AM -0600, Simon Glass wrote: > The Python virtualenv tool sets up a few things in the envronment, > putting its path first in the PATH environment variable and setting up > a sys.prefix different from the sys.base_prefix value. > > At present buildman puts the toolchain path first in PATH so that it can > be found easily during the build. For sandbox this causes problems since > /usr/bin/gcc (for example) results in '/usr/bin' being prepended to the > PATH variable. As a result, the venv is partially disabled. > > The result is that sandbox builds within a venv ignore the venv, e.g. > when looking for packages. > > Correct this by detecting the venv and adding the toolchain path after > the venv path. > > Signed-off-by: Simon Glass Why are we using PATH at all in this case? Shouldn't we just be setting CROSS_COMPILE=/full/path/to/the/prefix ? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] Dockerfile: Add python3-coverage
On Thu, Jun 20, 2024 at 07:19:33AM -0600, Simon Glass wrote: > Add this package so we can run code-coverage tests for Binman. > > Signed-off-by: Simon Glass This (and same for patch 2) should be in tools/buildman/requirements.txt -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/5] bootstd: Add Android support
On Thu, Jun 13, 2024 at 12:13:07PM +0200, Mattijs Korpershoek wrote: > Android boot flow is a bit different than a regular Linux distro. > Android relies on multiple partitions in order to boot. > > A typical boot flow would be: > 1. Parse the Bootloader Control Block (BCB, misc partition) > 2. If BCB requested bootonce-bootloader, start fastboot and wait. > 3. If BCB requested recovery or normal android, run the following: >a. Get slot (A/B) from BCB >b. Run AVB (Android Verified Boot) on boot partitions >c. Load boot and vendor_boot partitions >d. Load device-tree, ramdisk and boot > > The AOSP documentation has more details at [1], [2], [3] > > This has been implemented via complex boot scripts such as [4]. > However, these boot script are neither very maintainable nor generic. > Moreover, DISTRO_DEFAULTS is being deprecated [5]. > > Add a generic Android bootflow implementation for bootstd. > > For this initial version, only boot image v4 is supported. > > This has been tested on sandbox using: > $ ./test/py/test.py --bd sandbox --build -k test_ut > > This has also been tested on the AM62X SK EVM using TI's Android SDK[6] > To test on TI board, the following (WIP) patch is needed as well: > https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04 > > [1] https://source.android.com/docs/core/architecture/bootloader > [2] https://source.android.com/docs/core/architecture/partitions > [3] https://source.android.com/docs/core/architecture/partitions/generic-boot > [4] > https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h > [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-...@chromium.org/ > [6] > https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html This leads to failures in CI such as: === FAILURES === ___ test_ut_dm_init_bootstd test/py/tests/test_ut.py:555: in test_ut_dm_init_bootstd setup_android_image(u_boot_console) test/py/tests/test_ut.py:488: in setup_android_image with open(boot_img, 'rb') as inf: E FileNotFoundError: [Errno 2] No such file or directory: '/tmp/malta64el/bootv4.img' - Captured stdout call - -- Tom signature.asc Description: PGP signature
[PATCH] mkimage: Allow 'auto-conf' signing of scripts
U-Boot configured for verified boot with the "required" option set to
"conf" also checks scripts put in FIT images for a valid signature, and
refuses to source and run such a script if the signature for the
configuration is bad or missing. Such a script could not be packaged
before, because mkimage failed like this:
% tools/mkimage -T script -C none -d tmp/my.scr -f auto-conf -k tmp -g dev
-o sha256,rsa4096 my.uimg
Failed to find any images for configuration 'conf-1/signature'
tools/mkimage Can't add hashes to FIT blob: -1
Error: Bad parameters for FIT image type
This is especially unfortunate if LEGACY_IMAGE_FORMAT is disabled as
recommended.
Listing the script configuration in a "sign-images" subnode instead,
would have added even more complexity to the already complex auto fit
generation code.
Signed-off-by: Alexander Dahl
---
tools/image-host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/image-host.c b/tools/image-host.c
index 7bfc0cb6b18..49ce7436bb9 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -730,7 +730,7 @@ static const char *fit_config_get_image_list(const void
*fit, int noffset,
int *lenp, int *allow_missingp)
{
static const char default_list[] = FIT_KERNEL_PROP "\0"
- FIT_FDT_PROP;
+ FIT_FDT_PROP "\0" FIT_SCRIPT_PROP;
const char *prop;
/* If there is an "sign-image" property, use that */
base-commit: fe2ce09a0753634543c32cafe85eb87a625f76ca
--
2.39.2
Re: [PATCH v4 9/9] doc: convert README.LED to .rst documentation
On Thu, Jun 20, 2024 at 08:13:34AM +0200, Heinrich Schuchardt wrote: > On 6/20/24 01:03, Christian Marangi wrote: > > Convert README.LED to .rst documentation and include all the relevant > > documentation in the status_led.h. > > > > Signed-off-by: Christian Marangi > > --- > > doc/README.LED | 77 -- > > doc/api/index.rst | 1 + > > doc/api/status_led.rst | 35 +++ > > include/status_led.h | 224 - > > 4 files changed, 256 insertions(+), 81 deletions(-) > > delete mode 100644 doc/README.LED > > create mode 100644 doc/api/status_led.rst > > > > diff --git a/doc/README.LED b/doc/README.LED > > deleted file mode 100644 > > index c21c9d53ec3..000 > > --- a/doc/README.LED > > +++ /dev/null > > @@ -1,77 +0,0 @@ > > -Status LED > > - > > - > > -This README describes the status LED API. > > - > > -The API is defined by the include file include/status_led.h > > - > > -The first step is to enable CONFIG_LED_STATUS in menuconfig: > > -> Device Drivers > LED Support. > > - > > -If the LED support is only for specific board, enable > > -CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. > > - > > -Status LEDS 0 to 5 are enabled by the following configurations at > > menuconfig: > > -CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 > > - > > -The following should be configured for each of the enabled LEDs: > > -CONFIG_STATUS_LED_BIT > > -CONFIG_STATUS_LED_STATE > > -CONFIG_STATUS_LED_FREQ > > -Where is an integer 1 through 5 (empty for 0). > > - > > -CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify > > which LED > > -is being acted on. As such, the value choose must be unique with with > > respect to > > -the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is > > the > > -reponsiblity of the __led_* function. > > - > > -CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set > > to one > > -of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. > > - > > -CONFIG_STATUS_LED_FREQ determines the LED blink frequency. > > -Values range from 2 to 10. > > - > > -Some other LED macros > > -- > > - > > -CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. > > -This must be a valid LED number (0-5). > > - > > -CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This > > must be > > -a valid LED number (0-5). Other similar color LED's macros are > > -CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and > > CONFIG_STATUS_LED_BLUE. > > - > > -General LED functions > > -- > > -The following functions should be defined: > > - > > -__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. > > -One time start up code should be placed here. > > - > > -__led_set is called to change the state of the LED. > > - > > -__led_toggle is called to toggle the current state of the LED. > > - > > -Colour LED > > - > > - > > -Colour LED's are at present only used by ARM. > > - > > -The functions names explain their purpose. > > - > > -coloured_LED_init > > -red_LED_on > > -red_LED_off > > -green_LED_on > > -green_LED_off > > -yellow_LED_on > > -yellow_LED_off > > -blue_LED_on > > -blue_LED_off > > - > > -These are weakly defined in arch/arm/lib/board.c to noops. Where > > applicable, define > > -these functions in the board specific source. > > - > > -TBD : Describe older board dependent macros similar to what is done for > > - > > -TBD : Describe general support via asm/status_led.h > > diff --git a/doc/api/index.rst b/doc/api/index.rst > > index 51b2013af36..d40e90801d1 100644 > > --- a/doc/api/index.rst > > +++ b/doc/api/index.rst > > @@ -22,6 +22,7 @@ U-Boot API documentation > > rng > > sandbox > > serial > > + status_led > > sysreset > > timer > > unicode > > diff --git a/doc/api/status_led.rst b/doc/api/status_led.rst > > new file mode 100644 > > index 000..44bbea47157 > > --- /dev/null > > +++ b/doc/api/status_led.rst > > @@ -0,0 +1,35 @@ > > +.. SPDX-License-Identifier: GPL-2.0+ > > + > > +Status LED > > +== > > + > > +.. kernel-doc:: include/status_led.h > > + :doc: Overview > > + > > +CONFIG_STATUS_LED Description > > +- > > + > > +.. kernel-doc:: include/status_led.h > > + :doc: CONFIG Description > > + > > +Special Status LED Configs > > +-- > > +.. kernel-doc:: include/status_led.h > > + :doc: LED Status Config > > + > > +Colour Status LED Configs > > +- > > +.. kernel-doc:: include/status_led.h > > + :doc: LED Colour Config > > + > > +Required API > > + > > + > > +.. kernel-doc:: include/status_led.h > > + :doc: Required API > > + > > +Status LED API > > +-- > > + > > +.. kernel-doc:: include/status_led.h > > + :internal: >
Re: [PATCH v4 0/9] misc: introduce STATUS LED activity function
On Thu, Jun 20, 2024 at 08:34:03AM +0200, Heinrich Schuchardt wrote: > On 6/20/24 01:03, Christian Marangi wrote: > > This series expand the STATUS LED framework with a new color > > and a big new feature. One thing that many device need is a way > > to communicate to the user that the device is actually doing > > something. > > > > This is especially useful for recovery steps where an > > user (for example) insert an USB drive, keep a button pressed > > and the device autorecover. > > > > There is currently no way to signal the user externally that > > the bootloader is processing/recoverying aside from setting > > a LED on. > > > > A solid LED on is not enough and won't actually signal any > > kind of progress. > > Solution is the good old blinking LED but uboot doesn't > > suggest (and support) interrupts and almost all the LED > > are usually GPIO LED that doesn't support HW blink. > > > > To fix this and handle the problem of device not supporting > > HW blink, expand the STATUS LED framework with new API. > > > > We introduce a new config LED_STATUS_ACTIVITY, that similar > > to the RED, GREEN and others, takes the LED ID set in > > the LED_STATUS config and is used as the global LED for activity > > operations. > > > > We add status_led_activity_start/stop() used to turn the > > activity LED on and register a cyclic to make it blink. > > LED will continue to blink until _stop() is called. > > > > Function that will start some kind of action will first call > > _start() and then at the end will call stop(). > > If (on the broken implementation) a _start() is called before > > calling a _stop(), the Cyclic is first unregister and is > > registered again. > > > > Support for this is initially added to the tftp, mtd and ubi > > command. > > > > This also contains a big fixup for the gpio_led driver that > > currently deviates from the Documentation and make the > > coloured status led feature unusable. > > > > (world tested with the azure pipeline) > > Hello Christian, > > What is the relationship between CONFIG_LED and CONFIG_LED_STATUS? > Can they be used at the same time or should they be exclusive? > Should CONFIG_LED_STATUS depend on CONFIG_LED? Well this is something that should have been fixed long time ago. Given the 2 cmd and some function clash with each other they are totally incompatible with each other and one should exclude the other. > > This should be clarified both in Kconfig and in the documentation. > > At least cmd/led.c and cmd/legacy_led.c are conflicting as both provide > a command 'led'. > > Can we unify the too? Unify them is complicated (I tried) as the Status LED goes very deep and can be supported by the board with specific implementation. LED driver is all based on DT and most of the time it's just GPIO. (aka require OF support) > > Best regards > > Heinrich > > > > > Changes v4: > > - Rebase on top of next > > - Rework for cyclic changes on next > > - Fix compilation error > > - Fix compilation warning due to missing header > > Changes v3: > > - Add log on Status LED error conditions > > Changes v2: > > - Add Documentation conversion > > - Rework to Cyclic and simplify implementation > > > > Christian Marangi (9): > >misc: gpio_led: fix broken coloured LED status functions > >led: status_led: add support for white LED colour > >led: status_led: add function to toggle a status LED > >led: status_led: add warning when an invalid Status LED ID is used > >led: status_led: add new activity LED config and functions > >tftp: implement support for LED status activity > >mtd: implement support for LED status activity > >ubi: implement support for LED status activity > >doc: convert README.LED to .rst documentation > > > > cmd/legacy_led.c | 6 + > > cmd/mtd.c | 19 > > cmd/ubi.c | 15 ++- > > common/board_f.c | 2 + > > doc/README.LED| 77 - > > doc/api/index.rst | 1 + > > doc/api/status_led.rst| 35 ++ > > drivers/led/Kconfig | 30 + > > drivers/misc/gpio_led.c | 41 +-- > > drivers/misc/status_led.c | 75 - > > include/status_led.h | 231 +- > > net/tftp.c| 7 ++ > > 12 files changed, 440 insertions(+), 99 deletions(-) > > delete mode 100644 doc/README.LED > > create mode 100644 doc/api/status_led.rst > > > -- Ansuel
Re: [PATCH v7 1/4] Add fdt_kaslrseed function to add kaslr-seed to chosen node
Hi Tim,
On 18/06/2024 23:06, Tim Harvey wrote:
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.
Signed-off-by: Tim Harvey
Reviewed-by: Simon Glass
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v6:
- collected tags
v5:
- move function to boot/fdt_support.c
- remove ability to select rng index and note in the commit log
something like this as a future enhancement.
- fixed typo in commit message s/it's/its/
- use cmd_process_error per Michal's suggestion
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
boot/fdt_support.c| 44 +++
include/fdt_support.h | 10 ++
2 files changed, 54 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 2bd80a9dfb18..b1b2679dea0c 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,12 +7,15 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -274,6 +277,47 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end)
return 0;
}
+int fdt_kaslrseed(void *fdt, bool overwrite)
+{
+ int len, err, nodeoffset;
+ struct udevice *dev;
+ const u64 *orig;
+ u64 data = 0;
+
+ err = fdt_check_header(fdt);
+ if (err < 0)
+ return err;
All the paths that call fdt_kaslrseed() call fdt_check_header()
beforehand, I think it's safe to drop this.
+
+ /* find or create "/chosen" node. */
+ nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
+ if (nodeoffset < 0)
+ return nodeoffset;
Arguably, this shouldn't be the responsibility of this function, maybe
it would be better to error our here?
+
+ /* return without error if we are not overwriting and existing non-zero
node */
+ orig = fdt_getprop(fdt, nodeoffset, "kaslr-seed", );
+ if (orig && len == sizeof(*orig))
+ data = fdt64_to_cpu(*orig);
+ if (data && !overwrite) {
+ debug("not overwriting existing kaslr-seed\n");
+ return 0;
+ }
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (err) {
+ printf("No RNG device\n");
+ return err;
+ }
+ err = dm_rng_read(dev, , sizeof(data));
+ if (err) {
+ dev_err(dev, "dm_rng_read failed: %d\n", err);
+ return err;
+ }
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", , sizeof(data));
+ if (err < 0)
+ printf("WARNING: could not set kaslr-seed %s.\n",
fdt_strerror(err));
+
+ return err;
+}
+
/**
* board_fdt_chosen_bootargs - boards may override this function to use
* alternative kernel command line arguments
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 4b71b8948d99..741e2360c224 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -463,4 +463,14 @@ void fdt_fixup_board_enet(void *blob);
#ifdef CONFIG_CMD_PSTORE
void fdt_fixup_pstore(void *blob);
#endif
+
+/**
+ * fdt_kaslrseed() - create a 'kaslr-seed' node in chosen
+ *
+ * @blob: fdt blob
+ * @overwrite: do not overwrite existing non-zero node unless true
+ * Return: 0 if OK, -ve on error
+ */
+int fdt_kaslrseed(void *blob, bool overwrite);
+
#endif /* ifndef __FDT_SUPPORT_H */
--
// Caleb (they/them)
Re: [PATCH 3/5] buildman: Support building within a Python venv
On 20.06.24 15:19, Simon Glass wrote:
The Python virtualenv tool sets up a few things in the envronment,
Nits
%s/envronment/environment/
putting its path first in the PATH environment variable and setting up
a sys.prefix different from the sys.base_prefix value.
At present buildman puts the toolchain path first in PATH so that it can
be found easily during the build. For sandbox this causes problems since
/usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
PATH variable. As a result, the venv is partially disabled.
If you want to remember a PATH, why don't you use a differnet variable
like U_BOOT_TOOLPATH to convey this information instead of manipulating
the PATH variable?
The result is that sandbox builds within a venv ignore the venv, e.g.
when looking for packages.
Correct this by detecting the venv and adding the toolchain path after
the venv path.
Signed-off-by: Simon Glass
---
tools/buildman/bsettings.py | 3 ++
tools/buildman/test.py | 83 +
tools/buildman/toolchain.py | 31 --
3 files changed, 113 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
index e225ac2ca0f..1be1d45e0fa 100644
--- a/tools/buildman/bsettings.py
+++ b/tools/buildman/bsettings.py
@@ -31,6 +31,9 @@ def setup(fname=''):
def add_file(data):
settings.readfp(io.StringIO(data))
+def add_section(name):
+settings.add_section(name)
+
def get_items(section):
"""Get the items from a section of the config.
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index f92add7a7c5..83219182fe0 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -146,6 +146,7 @@ class TestBuild(unittest.TestCase):
self.toolchains.Add('arm-linux-gcc', test=False)
self.toolchains.Add('sparc-linux-gcc', test=False)
self.toolchains.Add('powerpc-linux-gcc', test=False)
+self.toolchains.Add('/path/to/aarch64-linux-gcc', test=False)
self.toolchains.Add('gcc', test=False)
# Avoid sending any output
@@ -747,6 +748,88 @@ class TestBuild(unittest.TestCase):
self.assertEqual([
['MARY="mary"', 'Missing expected line: CONFIG_MARY="mary"']],
result)
+def call_make_environment(self, tchn, full_path, in_env=None):
+"""Call Toolchain.MakeEnvironment() and process the result
+
+Args:
+tchn (Toolchain): Toolchain to use
+full_path (bool): True to return the full path in CROSS_COMPILE
+rather than adding it to the PATH variable
+in_env (dict): Input environment to use, None to use current env
+
+Returns:
+tuple:
+dict: Changes that MakeEnvironment has made to the environment
+key: Environment variable that was changed
+value: New value (for PATH this only includes components
+which were added)
+str: Full value of the new PATH variable
+"""
+env = tchn.MakeEnvironment(full_path, env=in_env)
+
+# Get the original environment
+orig_env = dict(os.environb if in_env is None else in_env)
+orig_path = orig_env[b'PATH'].split(b':')
+
+# Find new variables
+diff = dict((k, env[k]) for k in env if orig_env.get(k) != env[k])
+
+# Find new / different path components
+diff_path = None
+new_path = None
+if b'PATH' in diff:
+new_path = diff[b'PATH'].split(b':')
+diff_paths = [p for p in new_path if p not in orig_path]
+diff_path = b':'.join(p for p in new_path if p not in orig_path)
+if diff_path:
+diff[b'PATH'] = diff_path
+else:
+del diff[b'PATH']
+return diff, new_path
+
+def test_toolchain_env(self):
+"""Test PATH and other environment settings for toolchains"""
+# Use a toolchain which has a path, so that full_path makes a
difference
+tchn = self.toolchains.Select('aarch64')
+
+# Normal cases
+diff = self.call_make_environment(tchn, full_path=False)[0]
+self.assertEqual(
+{b'CROSS_COMPILE': b'aarch64-linux-', b'LC_ALL': b'C',
+ b'PATH': b'/path/to'}, diff)
+
+diff = self.call_make_environment(tchn, full_path=True)[0]
+self.assertEqual(
+{b'CROSS_COMPILE': b'/path/to/aarch64-linux-', b'LC_ALL': b'C'},
+diff)
+
+# When overriding the toolchain, only LC_ALL should be set
+tchn.override_toolchain = True
+diff = self.call_make_environment(tchn, full_path=True)[0]
+self.assertEqual({b'LC_ALL': b'C'}, diff)
+
+# Test that virtualenv is handled correctly
+tchn.override_toolchain = False
+sys.prefix = '/some/venv'
+env = dict(os.environb)
+env[b'PATH'] =
[PATCH] RFC: Add a tag for the world builds
Currently the world builds run on all runners, including faster and
slower ones.
The difference can be quite dramatic, with some builders 4x as fast as
others, resulting in just one world build taking between 20 minutes and
an hour and 20 minutes.
Add a tag so that we can select which builders run these CPU-intensive
jobs.
With this tag we can also increase CPU utilisation by running multiple
QEMU tests in parallel. Currently these tests leave most machines fairly
idle, since we cannot run more than one world build on a machine.
Signed-off-by: Simon Glass
---
.gitlab-ci.yml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 165f765a833..750c4ff5f4d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,6 +2,7 @@
variables:
DEFAULT_TAG: ""
+ BUILD_TAG: "build"
MIRROR_DOCKER: docker.io
default:
@@ -92,6 +93,8 @@ stages:
.world_build:
stage: world build
+ tags:
+- ${BUILD_TAG}
rules:
- when: always
--
2.34.1
[PATCH 5/5] CI: Run code-coverage test for Binman
Binman includes a good set of tests covering all of its functionality.
This includes a code-coverage test.
However to date the code-coverage test has not been checked
automatically by CI, relying on people to run 'binman test -T'
themselves.
Plug the gap to avoid bugs creeping in future.
Signed-off-by: Simon Glass
---
.gitlab-ci.yml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 165f765a833..eb01fa4868d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -201,7 +201,9 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
./tools/buildman/buildman -T0 -o ${UBOOT_TRAVIS_BUILD_DIR} -w
--board tools-only;
set -e;
- ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test;
+ export TOOLPATH="--toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools --toolpath
/opt/coreboot";
+ ./tools/binman/binman ${TOOLPATH} test;
+ ./tools/binman/binman ${TOOLPATH} test -T;
./tools/buildman/buildman -t;
./tools/dtoc/dtoc -t;
./tools/patman/patman test;
--
2.34.1
[PATCH 4/5] u_boot_pylib: Use correct coverage tool within venv
When running within a Python venv we must use the 'coverage' tool (which
is within the venv) so that the venv packages are used in preference to
system packages. Otherwise the coverage tests run in a different
environment from the normal tests and may fail due to missing packages.
Handle this by detecting the venv and changing the tool name.
Signed-off-by: Simon Glass
---
tools/u_boot_pylib/test_util.py | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/u_boot_pylib/test_util.py b/tools/u_boot_pylib/test_util.py
index f18d385d995..857ce58c98c 100644
--- a/tools/u_boot_pylib/test_util.py
+++ b/tools/u_boot_pylib/test_util.py
@@ -60,12 +60,17 @@ def run_test_coverage(prog, filter_fname, exclude_list,
build_dir, required=None
prefix = ''
if build_dir:
prefix = 'PYTHONPATH=$PYTHONPATH:%s/sandbox_spl/tools ' % build_dir
-cmd = ('%spython3-coverage run '
- '--omit "%s" %s %s %s %s' % (prefix, ','.join(glob_list),
+
+# Detect a Python virtualenv and use 'coverage' instead
+covtool = ('python3-coverage' if sys.prefix == sys.base_prefix else
+ 'coverage')
+
+cmd = ('%s%s run '
+ '--omit "%s" %s %s %s %s' % (prefix, covtool, ','.join(glob_list),
prog, extra_args or '', test_cmd,
single_thread or '-P1'))
os.system(cmd)
-stdout = command.output('python3-coverage', 'report')
+stdout = command.output(covtool, 'report')
lines = stdout.splitlines()
if required:
# Convert '/path/to/name.py' just the module name 'name'
--
2.34.1
[PATCH 3/5] buildman: Support building within a Python venv
The Python virtualenv tool sets up a few things in the envronment,
putting its path first in the PATH environment variable and setting up
a sys.prefix different from the sys.base_prefix value.
At present buildman puts the toolchain path first in PATH so that it can
be found easily during the build. For sandbox this causes problems since
/usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
PATH variable. As a result, the venv is partially disabled.
The result is that sandbox builds within a venv ignore the venv, e.g.
when looking for packages.
Correct this by detecting the venv and adding the toolchain path after
the venv path.
Signed-off-by: Simon Glass
---
tools/buildman/bsettings.py | 3 ++
tools/buildman/test.py | 83 +
tools/buildman/toolchain.py | 31 --
3 files changed, 113 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
index e225ac2ca0f..1be1d45e0fa 100644
--- a/tools/buildman/bsettings.py
+++ b/tools/buildman/bsettings.py
@@ -31,6 +31,9 @@ def setup(fname=''):
def add_file(data):
settings.readfp(io.StringIO(data))
+def add_section(name):
+settings.add_section(name)
+
def get_items(section):
"""Get the items from a section of the config.
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index f92add7a7c5..83219182fe0 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -146,6 +146,7 @@ class TestBuild(unittest.TestCase):
self.toolchains.Add('arm-linux-gcc', test=False)
self.toolchains.Add('sparc-linux-gcc', test=False)
self.toolchains.Add('powerpc-linux-gcc', test=False)
+self.toolchains.Add('/path/to/aarch64-linux-gcc', test=False)
self.toolchains.Add('gcc', test=False)
# Avoid sending any output
@@ -747,6 +748,88 @@ class TestBuild(unittest.TestCase):
self.assertEqual([
['MARY="mary"', 'Missing expected line: CONFIG_MARY="mary"']],
result)
+def call_make_environment(self, tchn, full_path, in_env=None):
+"""Call Toolchain.MakeEnvironment() and process the result
+
+Args:
+tchn (Toolchain): Toolchain to use
+full_path (bool): True to return the full path in CROSS_COMPILE
+rather than adding it to the PATH variable
+in_env (dict): Input environment to use, None to use current env
+
+Returns:
+tuple:
+dict: Changes that MakeEnvironment has made to the environment
+key: Environment variable that was changed
+value: New value (for PATH this only includes components
+which were added)
+str: Full value of the new PATH variable
+"""
+env = tchn.MakeEnvironment(full_path, env=in_env)
+
+# Get the original environment
+orig_env = dict(os.environb if in_env is None else in_env)
+orig_path = orig_env[b'PATH'].split(b':')
+
+# Find new variables
+diff = dict((k, env[k]) for k in env if orig_env.get(k) != env[k])
+
+# Find new / different path components
+diff_path = None
+new_path = None
+if b'PATH' in diff:
+new_path = diff[b'PATH'].split(b':')
+diff_paths = [p for p in new_path if p not in orig_path]
+diff_path = b':'.join(p for p in new_path if p not in orig_path)
+if diff_path:
+diff[b'PATH'] = diff_path
+else:
+del diff[b'PATH']
+return diff, new_path
+
+def test_toolchain_env(self):
+"""Test PATH and other environment settings for toolchains"""
+# Use a toolchain which has a path, so that full_path makes a
difference
+tchn = self.toolchains.Select('aarch64')
+
+# Normal cases
+diff = self.call_make_environment(tchn, full_path=False)[0]
+self.assertEqual(
+{b'CROSS_COMPILE': b'aarch64-linux-', b'LC_ALL': b'C',
+ b'PATH': b'/path/to'}, diff)
+
+diff = self.call_make_environment(tchn, full_path=True)[0]
+self.assertEqual(
+{b'CROSS_COMPILE': b'/path/to/aarch64-linux-', b'LC_ALL': b'C'},
+diff)
+
+# When overriding the toolchain, only LC_ALL should be set
+tchn.override_toolchain = True
+diff = self.call_make_environment(tchn, full_path=True)[0]
+self.assertEqual({b'LC_ALL': b'C'}, diff)
+
+# Test that virtualenv is handled correctly
+tchn.override_toolchain = False
+sys.prefix = '/some/venv'
+env = dict(os.environb)
+env[b'PATH'] = b'/some/venv/bin:other/things'
+tchn.path = '/my/path'
+diff, diff_path = self.call_make_environment(tchn, False, env)
+
+self.assertIn(b'PATH', diff)
+self.assertEqual([b'/some/venv/bin', b'/my/path', b'other/things'],
+
[PATCH 2/5] Dockerfile: Add python3-pycryptodome
This is used by some Binman entry types, so add it to allow more tests to pass. Signed-off-by: Simon Glass --- tools/docker/Dockerfile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 0941b0f6952..a23504179c2 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -98,6 +98,7 @@ RUN apt-get update && apt-get install -y \ python2.7 \ python3 \ python3-coverage \ + python3-pycryptodome \ python3-dev \ python3-pip \ python3-pyelftools \ -- 2.34.1
[PATCH 1/5] Dockerfile: Add python3-coverage
Add this package so we can run code-coverage tests for Binman. Signed-off-by: Simon Glass --- tools/docker/Dockerfile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index cda87354566..0941b0f6952 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -97,6 +97,7 @@ RUN apt-get update && apt-get install -y \ python-is-python3 \ python2.7 \ python3 \ + python3-coverage \ python3-dev \ python3-pip \ python3-pyelftools \ -- 2.34.1
[PATCH 0/5] Add Binman code-coverage test to CI
Binman has 100% code coverage to ensure that future changes and refactors do not break existing entry types. This is a critical feature, given that it is relied on to produce images for all sorts of different SoCs and vendors. With the NXP additions the 'binman test -T' step was missed, so the Binman coverage test is currently failing. This series provides a means to close the testing gap. It cannot be applied until the tests are added, which should happen before -next is applied to -master Simon Glass (5): Dockerfile: Add python3-coverage Dockerfile: Add python3-pycryptodome buildman: Support building within a Python venv u_boot_pylib: Use correct coverage tool within venv CI: Run code-coverage test for Binman .gitlab-ci.yml | 4 +- tools/buildman/bsettings.py | 3 ++ tools/buildman/test.py | 83 + tools/buildman/toolchain.py | 31 ++-- tools/docker/Dockerfile | 2 + tools/u_boot_pylib/test_util.py | 11 +++-- 6 files changed, 126 insertions(+), 8 deletions(-) -- 2.34.1
[PATCH] doc: board: phytec: phycore-am6: Describe UART based boot
Describe how to boot via UART.
Signed-off-by: Wadim Egorov
---
For next
---
doc/board/phytec/phycore-am62x.rst | 17 +
doc/board/phytec/phycore-am64x.rst | 19 +++
2 files changed, 36 insertions(+)
diff --git a/doc/board/phytec/phycore-am62x.rst
b/doc/board/phytec/phycore-am62x.rst
index a615d01474e..5f02a9db5f8 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -118,6 +118,23 @@ tiboot3.bin, tispl.bin and u-boot.img are stored on the
uSD card.
fatload mmc 1 ${loadaddr} u-boot.img
mtd write ospi.u-boot ${loadaddr} 0 ${filesize}
+UART based boot
+---
+
+To boot the board via UART, set the switches to UART mode and connect to the
+micro USB port labeled as "Debug UART". After power-on the build artifacts
+needs to be uploaded one by one with a tool like sz.
+
+Example bash script sequence for running on a Linux host PC feeding all boot
+artifacts needed to the device. Assuming the host uses /dev/ttyUSB0 as
+the main domain serial port:
+
+.. prompt:: bash $
+
+ stty -F /dev/ttyUSB0 115200
+ sb --xmodem tiboot3.bin > /dev/ttyUSB0 < /dev/ttyUSB0
+ sb --ymodem tispl.bin > /dev/ttyUSB0 < /dev/ttyUSB0
+ sb --ymodem u-boot.img > /dev/ttyUSB0 < /dev/ttyUSB0
Boot Modes
--
diff --git a/doc/board/phytec/phycore-am64x.rst
b/doc/board/phytec/phycore-am64x.rst
index 189da179534..e7f8656e1bf 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -119,6 +119,25 @@ tiboot3.bin, tispl.bin and u-boot.img are stored on the
uSD card.
fatload mmc 1 ${loadaddr} u-boot.img
mtd write ospi.u-boot ${loadaddr} 0 ${filesize}
+UART based boot
+---
+
+To boot the board via UART, set the switches to UART mode and connect to the
+micro USB port labeled as "Debug UART". After power-on the build artifacts
+needs to be uploaded one by one with a tool like sz.
+
+Example bash script sequence for running on a Linux host PC feeding all boot
+artifacts needed to the device. Assuming the host uses /dev/ttyUSB0 as
+the main domain serial port:
+
+.. prompt:: bash $
+
+ stty -F /dev/ttyUSB0 115200
+ sb --xmodem tiboot3.bin > /dev/ttyUSB0 < /dev/ttyUSB0
+ # Resend tiboot3.bin a 2nd time due to ErrataID:i2331
+ sb --xmodem tiboot3.bin > /dev/ttyUSB0 < /dev/ttyUSB0
+ sb --ymodem tispl.bin > /dev/ttyUSB0 < /dev/ttyUSB0
+ sb --ymodem u-boot.img > /dev/ttyUSB0 < /dev/ttyUSB0
Boot Modes
--
--
2.34.1
Re: [PATCH v2 5/5] usb: dwc3: meson-g12a: drop usb.h and make dwc3_meson_g12a_force_mode static
On 6/20/24 9:42 AM, Neil Armstrong wrote: Drop this useless usb.h and now make dwc3_meson_g12a_force_mode static since only used in the dwc3-meson-g12a.c file. Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut
Re: [PATCH v2 4/5] usb: dwc3: meson-gxl: drop usb-gx.h and make dwc3_meson_gxl_force_mode static
On 6/20/24 9:42 AM, Neil Armstrong wrote: Drop this useless usb-gx.h and now make dwc3_meson_gxl_force_mode static since only used in the dwc3-meson-gxl.c file. Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut
Re: [PATCH v2 3/5] phy: meson-gxl-usb2: remove phy_meson_gxl_usb2_set_mode
On 6/20/24 9:42 AM, Neil Armstrong wrote:
Remove the public phy_meson_gxl_usb2_set_mode and move
the implementation in the the set_mode callback.
Signed-off-by: Neil Armstrong
Reviewed-by: Marek Vasut
-static int _phy_meson_gxl_usb2_set_mode(struct phy *phy, enum phy_mode mode,
int submode)
-{
- if (submode)
- return -EOPNOTSUPP;
-
- switch (mode) {
- case PHY_MODE_USB_DEVICE:
- phy_meson_gxl_usb2_set_mode(phy, USB_DR_MODE_PERIPHERAL);
- break;
case PHY_MODE_USB_HOST:
case PHY_MODE_USB_OTG:
- phy_meson_gxl_usb2_set_mode(phy, USB_DR_MODE_HOST);
+ val |= U2P_R0_DM_PULLDOWN;
+ val |= U2P_R0_DP_PULLDOWN;
btw this could be a one-liner val |= macro1 | macro2 ;
Re: [PATCH v2 2/5] usb: dwc3: meson-gxl: switch to generic_phy_set_mode
On 6/20/24 9:42 AM, Neil Armstrong wrote: Use the PHY set_mode call instead of calling directly in the PHY shared function. Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut
Re: [PATCH v2 1/5] phy: meson-gxl-usb2: add set_mode callback
On 6/20/24 9:42 AM, Neil Armstrong wrote: Implement set_mode callback by calling the current public function, use a temporary function name that will be removed when the public phy_meson_gxl_usb2_set_mode is finally removed in a following change. Signed-off-by: Neil Armstrong Reviewed-by: Marek Vasut
Re: [PATCH 3/5] phy: meson-gxl-usb2: remove phy_meson_gxl_usb2_set_mode
On 6/20/24 9:39 AM, Neil Armstrong wrote:
On 18/06/2024 16:56, Marek Vasut wrote:
On 6/18/24 9:55 AM, Neil Armstrong wrote:
[...]
@@ -205,7 +188,7 @@ static int phy_meson_gxl_usb2_power_off(struct
phy *phy)
struct phy_ops meson_gxl_usb2_phy_ops = {
.power_on = phy_meson_gxl_usb2_power_on,
.power_off = phy_meson_gxl_usb2_power_off,
- .set_mode = _phy_meson_gxl_usb2_set_mode,
+ .set_mode = phy_meson_gxl_usb2_set_mode,
Oh, I see you did rename it here, so please ignore my comment on 1/5 .
Maybe just mention in the 1/5 commit message that the rename is
happening in follow up patch , if you are doing V2 at all .
Sure, let me update the commit message,
Thank you
Re: [PATCH v1 0/7] Add Starfive JH7110 Cadence USB driver
Minda, can you test USB Host function on VisionFive2? I guess that it is connected to the USB-C port. For the boards with JH7110 and not any VL805 USB controller this Cadence USB is the only way to have host USB. It is very much wanted to have host USB. Thanks! -E On Sun, May 19, 2024 at 11:20 PM Minda Chen wrote: > > > > > -邮件原件- > > 发件人: E Shattow > > 发送时间: 2024年5月20日 13:06 > > 收件人: Minda Chen > > 抄送: Marek Vasut ; Tom Rini ; Roger > > Quadros ; Neil Armstrong ; > > Alexey Romanov ; Sumit Garg > > ; Mark Kettenis ; Nishanth > > Menon ; Rick Chen ; Leo Yu-Chi Liang > > ; u-boot@lists.denx.de; Heinrich Schuchardt > > ; Simon Glass > > 主题: Re: [PATCH v1 0/7] Add Starfive JH7110 Cadence USB driver > > > > Hi, there is a compile warning. I don't know why. > > > > On Sat, May 4, 2024 at 8:04 AM Minda Chen > > wrote: > > > > > > Add Starfive JH7110 Cadence USB driver and related PHY driver. > > > So the codes can be used in visionfive2 and milkv 7110 board. > > > > > > The driver is almost the same with kernel driver. > > > > > > patch1: Add set phy mode function in cdns3 core driver > > > which is used by Starfive. > > > > > > patch2-3: USB and PCIe 2.0 (usb 3.0) PHY drivier > > > patch4: Cadence USB wrapper driver. > > > patch5-7 dts, config and maintainers update. > > > > > > Minda Chen (7): > > > usb: cdns3: Set USB PHY mode in cdns3_probe() > > > phy: starfive: Add Starfive JH7110 USB 2.0 PHY driver > > > phy: starfive: Add Starfive JH7110 PCIe 2.0 PHY driver > > > usb: cdns: starfive: Add cdns USB driver > > > configs: starfive: Add visionfive2 cadence USB configuration > > > dts: starfive: Add JH7110 Cadence USB dts node > > > MAINTAINERS: Update Starfive visionfive2 maintain files. > > > > > > .../dts/jh7110-starfive-visionfive-2.dtsi | 5 + > > > arch/riscv/dts/jh7110.dtsi| 52 + > > > board/starfive/visionfive2/MAINTAINERS| 2 + > > > configs/starfive_visionfive2_defconfig| 9 + > > > drivers/phy/Kconfig | 1 + > > > drivers/phy/Makefile | 1 + > > > drivers/phy/starfive/Kconfig | 19 ++ > > > drivers/phy/starfive/Makefile | 7 + > > > drivers/phy/starfive/phy-jh7110-pcie.c| 211 > > ++ > > > drivers/phy/starfive/phy-jh7110-usb2.c| 135 +++ > > > drivers/usb/cdns3/Kconfig | 7 + > > > drivers/usb/cdns3/Makefile| 2 + > > > drivers/usb/cdns3/cdns3-starfive.c| 184 +++ > > > drivers/usb/cdns3/core.c | 17 ++ > > > 14 files changed, 652 insertions(+) > > > create mode 100644 drivers/phy/starfive/Kconfig create mode 100644 > > > drivers/phy/starfive/Makefile create mode 100644 > > > drivers/phy/starfive/phy-jh7110-pcie.c > > > create mode 100644 drivers/phy/starfive/phy-jh7110-usb2.c > > > create mode 100644 drivers/usb/cdns3/cdns3-starfive.c > > > > > > > > > base-commit: 174ac987655c888017c82df1883c0c2ea0dc2495 > > > -- > > > 2.17.1 > > > > > > > The compile warning as follows: > > > > In file included from > > /home/user/source/u-boot.git/drivers/usb/cdns3/gadget.c:70: > > /home/user/source/u-boot.git/include/linux/bitmap.h: In function > > ‘bitmap_find_next_zero_area’: > > /home/user/source/u-boot.git/include/linux/bitmap.h:170:17: warning: > > implicit declaration of function ‘find_next_zero_bit’; did you mean > > ‘find_next_bit’? [-Wimplicit-function-declaration] > > 170 | index = find_next_zero_bit(map, size, start); > > | ^~ > > | find_next_bit > > CC drivers/usb/cdns3/ep0.o > > In file included from > > /home/user/source/u-boot.git/include/linux/usb/composite.h:26, > > from > > /home/user/source/u-boot.git/drivers/usb/cdns3/ep0.c:19: > > /home/user/source/u-boot.git/include/linux/bitmap.h: In function > > ‘bitmap_find_next_zero_area’: > > /home/user/source/u-boot.git/include/linux/bitmap.h:170:17: warning: > > implicit declaration of function ‘find_next_zero_bit’; did you mean > > ‘find_next_bit’? [-Wimplicit-function-declaration] > > 170 | index = find_next_zero_bit(map, size, start); > > | ^~ > > | find_next_bit > > > > > > Is this something missing in the patch series? > > > > -E > > I have not noticed this. I just check this it is risc-v code do not contain > "find_next_zero_bit" macro define.
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
Am Donnerstag, 20. Juni 2024, 12:24:51 CEST schrieb Quentin Schulz: > From: Quentin Schulz > > No meaningful changes were made to this SoM since February 2021. Nobody > from Theobroma has booted anything recent on that product since July > 2021 at the latest. The product isn't available to buy anymore and > disappeared from our website. > > This product is therefore unmaintained and it would be disingenuous to > say the opposite, so drop support for RK3368 Lion. > > If you're a user of Lion, feel free to revert this patch or contact our > sales/support department. > > Signed-off-by: Quentin Schulz I think any meaningful work on rk3368 in general has pretty much stalled at this point. Acked-by: Heiko Stuebner
[PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
From: Quentin Schulz
No meaningful changes were made to this SoM since February 2021. Nobody
from Theobroma has booted anything recent on that product since July
2021 at the latest. The product isn't available to buy anymore and
disappeared from our website.
This product is therefore unmaintained and it would be disingenuous to
say the opposite, so drop support for RK3368 Lion.
If you're a user of Lion, feel free to revert this patch or contact our
sales/support department.
Signed-off-by: Quentin Schulz
---
arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 119 -
arch/arm/dts/rk3368-lion-haikou.dts | 144 ---
arch/arm/dts/rk3368-lion.dtsi | 318
arch/arm/mach-rockchip/rk3368/Kconfig | 22 --
board/theobroma-systems/lion_rk3368/Kconfig | 18 --
board/theobroma-systems/lion_rk3368/MAINTAINERS | 10 -
board/theobroma-systems/lion_rk3368/README | 78 --
configs/lion-rk3368_defconfig | 110
doc/board/rockchip/rockchip.rst | 1 -
include/configs/lion_rk3368.h | 16 --
10 files changed, 836 deletions(-)
diff --git a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
deleted file mode 100644
index a3c2b707e9a..000
--- a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
+++ /dev/null
@@ -1,119 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-/*
- * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
- */
-
-#include "rk3368-u-boot.dtsi"
-
-/ {
- config {
- u-boot,spl-payload-offset = <0x4>; /* @ 256KB */
- u-boot,mmc-env-offset = <0x4000>; /* @ 16KB */
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- u-boot,spl-boot-order = ,
- };
-
- smbios {
- compatible = "u-boot,sysinfo-smbios";
-
- smbios {
- system {
- manufacturer = "rockchip";
- product = "sheep_rk3368";
- };
-
- baseboard {
- manufacturer = "rockchip";
- product = "sheep_rk3368";
- };
-
- chassis {
- manufacturer = "rockchip";
- product = "sheep_rk3368";
- };
- };
- };
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
-_msch {
- bootph-all;
-};
-
- {
- bootph-all;
-
- /*
-* Validation of throughput using SPEC2000 shows the following
-* relative performance for the different memory schedules:
-* - CBDR: 30.1
-* - CBRD: 29.8
-* - CRBD: 29.9
-* Note that the best performance for any given application workload
-* may vary from the default configured here (e.g. 164.gzip is fastest
-* with CBRD, whereas 252.eon and 186.crafty are fastest with CRBD).
-*
-* See doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt for
-* details on the 'rockchip,memory-schedule' property and how it
-* affects the physical-address to device-address mapping.
-*/
- rockchip,memory-schedule = ;
- rockchip,ddr-frequency = <8>;
- rockchip,ddr-speed-bin = ;
-
- status = "okay";
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-pre-ram;
-};
-
- {
- bootph-pre-ram;
-};
-
- {
- bootph-pre-ram;
-
- spiflash: w25q32dw@0 {
- bootph-pre-ram;
- };
-};
-
- {
- bootph-all;
- clock-frequency = <2400>;
- status = "okay";
-};
-
-
diff --git a/arch/arm/dts/rk3368-lion-haikou.dts
b/arch/arm/dts/rk3368-lion-haikou.dts
deleted file mode 100644
index cae01d35b93..000
--- a/arch/arm/dts/rk3368-lion-haikou.dts
+++ /dev/null
@@ -1,144 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2018 Theobroma Systems Design und Consulting GmbH
- */
-
-/dts-v1/;
-#include "rk3368-lion.dtsi"
-
-/ {
- model = "Theobroma Systems RK3368-uQ7 Baseboard";
- compatible = "tsd,rk3368-lion-haikou", "rockchip,rk3368";
-
- aliases {
- mmc1 =
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- i2cmux2 {
- i2c@0 {
- eeprom: eeprom@50 {
- compatible = "atmel,24c01";
- pagesize = <8>;
- reg = <0x50>;
- };
- };
- };
-
- leds {
- pinctrl-0 = <_led_pins>, <_card_led_pin>;
-
- sd_card_led:
[PATCH next 1/2] rockchip: theobroma-systems: migrate git URLs to HTTPS
From: Quentin Schulz It turns out only Puma had a working git:// URL. Though that is now fixed, having HTTPS URLs make it easier to directly reach our cgit webserver to check what's up without having to change the URL manually. Depending on your terminal settings, this also makes it possible to open the link from it. Signed-off-by: Quentin Schulz --- board/theobroma-systems/jaguar_rk3588/MAINTAINERS | 2 +- board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +- board/theobroma-systems/ringneck_px30/MAINTAINERS | 2 +- board/theobroma-systems/tiger_rk3588/MAINTAINERS | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/theobroma-systems/jaguar_rk3588/MAINTAINERS b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS index ab7051b427f..370d0a1272a 100644 --- a/board/theobroma-systems/jaguar_rk3588/MAINTAINERS +++ b/board/theobroma-systems/jaguar_rk3588/MAINTAINERS @@ -10,4 +10,4 @@ F:include/configs/jaguar_rk3588.h F: arch/arm/dts/rk3588-jaguar* F: configs/jaguar-rk3588_defconfig W: https://embedded.cherry.de/product/jaguar-sbc-rk3588/ -T: git git://git.embedded.cherry.de/jaguar-u-boot.git +T: git https://git.embedded.cherry.de/jaguar-u-boot.git diff --git a/board/theobroma-systems/puma_rk3399/MAINTAINERS b/board/theobroma-systems/puma_rk3399/MAINTAINERS index 2536e348887..1a5b78bf535 100644 --- a/board/theobroma-systems/puma_rk3399/MAINTAINERS +++ b/board/theobroma-systems/puma_rk3399/MAINTAINERS @@ -9,4 +9,4 @@ F: include/configs/puma_rk3399.h F: arch/arm/dts/rk3399-puma* F: configs/puma-rk3399_defconfig W: https://embedded.cherry.de/product/puma-som-rk3399-q7/ -T: git git://git.embedded.cherry.de/puma-u-boot.git +T: git https://git.embedded.cherry.de/puma-u-boot.git diff --git a/board/theobroma-systems/ringneck_px30/MAINTAINERS b/board/theobroma-systems/ringneck_px30/MAINTAINERS index 2aff91f4207..4d4544a2a3e 100644 --- a/board/theobroma-systems/ringneck_px30/MAINTAINERS +++ b/board/theobroma-systems/ringneck_px30/MAINTAINERS @@ -9,4 +9,4 @@ F: include/configs/ringneck_px30.h F: arch/arm/dts/px30-ringneck* F: configs/ringneck-px30_defconfig W: https://embedded.cherry.de/product/ringneck-som-px30-uq7/ -T: git git://git.embedded.cherry.de/ringneck-u-boot.git +T: git https://git.embedded.cherry.de/ringneck-u-boot.git diff --git a/board/theobroma-systems/tiger_rk3588/MAINTAINERS b/board/theobroma-systems/tiger_rk3588/MAINTAINERS index e5aab4b29f3..a95135616ad 100644 --- a/board/theobroma-systems/tiger_rk3588/MAINTAINERS +++ b/board/theobroma-systems/tiger_rk3588/MAINTAINERS @@ -10,4 +10,4 @@ F:include/configs/tiger_rk3588.h F: arch/arm/dts/rk3588-tiger* F: configs/tiger-rk3588_defconfig W: https://embedded.cherry.de/product/tiger-som-rk3588-q7/ -T: git git://git.embedded.cherry.de/tiger-u-boot.git +T: git https://git.embedded.cherry.de/tiger-u-boot.git -- 2.45.2
[PATCH next 0/2] rockchip: theobroma: use HTTPS for git URLs and drop RK3368 Lion support
Nobody at Theobroma has booted Lion since at least July 2021 and the last meaningful changes were made in February 2021. The product isn't listed on our website anymore. Therefore let's remove its support. Additionally, migrate git URLs in MAINTAINERS to use https:// instead of git:// as it's more user-friendly (and also that git:// was only supported for Puma repo until yesterday). Signed-off-by: Quentin Schulz --- Quentin Schulz (2): rockchip: theobroma-systems: migrate git URLs to HTTPS rockchip: remove support for Theobroma Systems RK3368 Lion arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 119 arch/arm/dts/rk3368-lion-haikou.dts | 144 -- arch/arm/dts/rk3368-lion.dtsi | 318 -- arch/arm/mach-rockchip/rk3368/Kconfig | 22 -- board/theobroma-systems/jaguar_rk3588/MAINTAINERS | 2 +- board/theobroma-systems/lion_rk3368/Kconfig | 18 -- board/theobroma-systems/lion_rk3368/MAINTAINERS | 10 - board/theobroma-systems/lion_rk3368/README| 78 -- board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +- board/theobroma-systems/ringneck_px30/MAINTAINERS | 2 +- board/theobroma-systems/tiger_rk3588/MAINTAINERS | 2 +- configs/lion-rk3368_defconfig | 110 doc/board/rockchip/rockchip.rst | 1 - include/configs/lion_rk3368.h | 16 -- 14 files changed, 4 insertions(+), 840 deletions(-) --- base-commit: e124e630ad694327e33d6513e43951793e827d3a change-id: 20240620-tsd-http-git-clone-53c0ea69adbe Best regards, -- Quentin Schulz
