Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
On Thu, 13 Jun 2024 at 23:11, Heinrich Schuchardt wrote: > > > > Am 13. Juni 2024 21:05:58 MESZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Thu, 13 Jun 2024 at 11:32, Heinrich Schuchardt wrote: > >> > >> On 13.06.24 18:59, Simon Glass wrote: > >> > Hi Tom, > >> > > >> > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > >> >> > >> >> On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > >> >>> Hi Tom, > >> >>> > >> >>> On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > >> > >> On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > >> > Hi Tom, > >> > > >> > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > >> >> > >> >> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > >> >> > >> >> [snip] > >> >>> Also IMO there is only really one LMB list today. We create it at > >> >>> the > >> >>> start of bootm and then it is done when we boot. The file-loading > >> >>> stuff is what makes all this confusing...and with bootstd that is > >> >>> under control as well. > >> >>> > >> >>> At lot of this effort seems to be about dealing with random scripts > >> >>> which load things. We want to make sure we complain if something > >> >>> overlaps. But we should be making the bootstd case work nicely and > >> >>> doing things within that framework. Also EFI sort-of has its own > >> >>> thing, which it is very-much in control of. > >> >>> > >> >>> Overall I think this is a bit more subtle that just combining > >> >>> allocators. > >> >> > >> >> I think this gets to the main misunderstanding. The problem isn't > >> >> handling bootstd, or EFI boot, or even assorted scripts. Those are > >> >> all > >> >> cases where things are otherwise (sufficiently) well-defined. The > >> >> problem is "security" and that a "carefully crafted payload" could > >> >> do > >> >> something malicious. That's why we have to do all of this stuff > >> >> sooner > >> >> rather than later in our boot process. > >> > > >> > That's the first I have heard of this, actually, but a bit more > >> > detail > >> > would help. How does the payload get loaded? I'm just not sure about > >> > the overall goals. It seems that everyone else is already familiar - > >> > can someone please take the time to point me to the details? > >> > >> Well, the short version I believe of the first CVE we got (and so > >> started abusing LMB) was along the lines of "load an image near where > >> the U-Boot stack is, smash things for fun and exploits". > >> >>> > >> >>> OK. I am surprised that LMB does not catch that. It is supposed to add > >> >>> the stack and various other things right at the start before loading > >> >>> any file. So even if it clears the LMB each time, it should not be > >> >>> able to do that. Having said this, the code may be buggy as I don't > >> >>> think we have tests for U-Boot's overall functional behaviour in these > >> >>> situations. > >> >> > >> >> Right, LMB does catch the example I gave (because we made all of the > >> >> load from storage/network functions init an lmb and we always make sure > >> >> a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > >> >> "what if EFI does the loading?" and we've kludged around that, and in > >> >> turn had some of the thorny questions. Some of that is what I think > >> >> you're asking about in this part of the thread, to which the answer is > >> >> "EFI spec says you need to place X in memory", so we just need to > >> >> reserve it when it's asked for, so that something else can't come along > >> >> and smash it maliciously. > >> > > >> > OK I see. Of course it isn't just EFI that has this issue. I believe > >> > the answer (for small blocks) is to use malloc(), which I think we do > >> > with a few exceptions which Ilias pointed out. For things like the TPM > >> > log and ACPI tables we should probably use a bloblist, as we do on > >> > x86. For large things (like loading a kernel) we should use LMB. I've > >> > been thinking about how best to tie this to boot, as opposed to random > >> > allocations in U-Boot itself, which would lead to fragmentation and > >> > strange behaviour. I think bootstd is a great place to have a > >> > persistent LMB. It can be attached to bootstd_priv. > >> > > >> > My hope is that EFI is just another boot method, where > >> > already-allocating things are presented to the OS. Apart from the > >> > Ilias exceptions, I believe this is how it works today. > >> > > >> > Where I think this heads in the wrong direction is using > >> > EFI-allocation functions before we are booting an EFI image. EFI has > >> > no concept of what is 'in empty space' so it leads to the lmb > >> > conflict, the subject of this discussion. > >> > >> EFI binaries can return to the command line interface. > >> EFI binaries may be drivers that stay resident and run in the
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
On 6/13/24 4:13 PM, Claudius Heine wrote: Hi, I suspect the following patch to oe-core (or local.conf equivalent) might also entirely mitigate the issue by providing https fallback automatically, without the need to modify the legacy layer/recipe ? If so, maybe this could be added to OE LTS releases at least ? " diff --git a/meta/classes-global/mirrors.bbclass b/meta/classes-global/mirrors.bbclass index 862648eec5..50a14c5881 100644 --- a/meta/classes-global/mirrors.bbclass +++ b/meta/classes-global/mirrors.bbclass @@ -77,6 +77,7 @@ https?://downloads.yoctoproject.org/mirror/sources/ https://mirrors.kernel.org/y MIRRORS += "\ git://salsa.debian.org/.* git://salsa.debian.org/PATH;protocol=https \ +git://git.denx.de/.* git://git.denx.de/PATH;protocol=https \ Well the path will change a bit as well: git://git.denx.de/u-boot.git -> https://source.denx.de/u-boot/u-boot.git git://git.denx.de/u-boot-efi.git -> https://source.denx.de/u-boot/custodians/u-boot-efi.git Better avoid custodian trees in OE builds unless this is a test build. git://git.denx.de/xenomai.git -> https://source.denx.de/xenomai/xenomai.git git://git.denx.de/mxssb.git -> https://source.denx.de/denx/mxssb.git mxssb is I think long superseded by U-Boot mkimage integration, so this can also be dropped. The remaining two, u-boot and xenomai, yeah, those would likely need to be separate. If we want to make it perfect, it will be more difficult than that. git://git.gnome.org/.* git://gitlab.gnome.org/GNOME/PATH;protocol=https \ git://git.infradead.org/.* git://git.infraroot.at/PATH;protocol=https \ git://.*/.* git://HOST/PATH;protocol=https \ " Anyway, I fixed it yesterday, and it doesn't make much sense to stop it now. So I will leave it in place until it breaks again, then I just remove it. Do you know how long it was actually broken ? (i.e. how long nobody noticed and complained about it?) So since 3rd of June, so about 5-8 days or so until someone noticed. Hum, since it works now again, I think we can wrap this discussion up. However, maybe this can serve as a wake up call for people to switch to https cloning ?
[PATCH 11/11] usb: gadget: Mark dm_usb_gadget_handle_interrupts as non-weak for DM_USB_GADGET
The dm_usb_gadget_handle_interrupts() is not implemented by any USB
gadget controller drivers which do enable DM_USB_GADGET anymore. Set
the symbol as non-weak.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/gadget/udc/udc-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-uclass.c
b/drivers/usb/gadget/udc/udc-uclass.c
index 2320039fe3b..fbe62bbce47 100644
--- a/drivers/usb/gadget/udc/udc-uclass.c
+++ b/drivers/usb/gadget/udc/udc-uclass.c
@@ -18,7 +18,7 @@ usb_gadget_generic_dev_ops(struct udevice *dev)
return (const struct usb_gadget_generic_ops *)dev->driver->ops;
}
-__weak int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
{
const struct usb_gadget_generic_ops *ops;
--
2.43.0
[PATCH 10/11] usb: gadget: sandbox: Drop dm_usb_gadget_handle_interrupts()
Drop dm_usb_gadget_handle_interrupts() in favor of empty default
implementation of the same in drivers/usb/gadget/udc/udc-uclass.c .
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/host/usb-sandbox.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/usb/host/usb-sandbox.c b/drivers/usb/host/usb-sandbox.c
index e26f0b292ed..f687fe2c430 100644
--- a/drivers/usb/host/usb-sandbox.c
+++ b/drivers/usb/host/usb-sandbox.c
@@ -123,12 +123,7 @@ static int sandbox_submit_int(struct udevice *bus, struct
usb_device *udev,
return ret;
}
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- return 0;
-}
-#else
+#if !CONFIG_IS_ENABLED(DM_USB_GADGET)
int usb_gadget_register_driver(struct usb_gadget_driver *driver)
{
struct sandbox_udc *dev = this_controller;
--
2.43.0
[PATCH 09/11] usb: gadget: ux500: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/musb-new/ux500.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb-new/ux500.c b/drivers/usb/musb-new/ux500.c
index 6b4ef3c8578..89dd75b7d05 100644
--- a/drivers/usb/musb-new/ux500.c
+++ b/drivers/usb/musb-new/ux500.c
@@ -91,14 +91,6 @@ static const struct musb_platform_ops ux500_musb_ops = {
.disable= ux500_musb_disable,
};
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct ux500_glue *glue = dev_get_priv(dev);
-
- glue->mdata.host->isr(0, glue->mdata.host);
- return 0;
-}
-
static int ux500_musb_probe(struct udevice *dev)
{
#ifdef CONFIG_USB_MUSB_HOST
@@ -155,6 +147,19 @@ static int ux500_musb_remove(struct udevice *dev)
return 0;
}
+static int ux500_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct ux500_glue *glue = dev_get_priv(dev);
+
+ glue->mdata.host->isr(0, glue->mdata.host);
+
+ return 0;
+}
+
+static const struct usb_gadget_generic_ops ux500_gadget_ops = {
+ .handle_interrupts = ux500_gadget_handle_interrupts,
+};
+
static const struct udevice_id ux500_musb_ids[] = {
{ .compatible = "stericsson,db8500-musb" },
{ }
@@ -168,6 +173,7 @@ U_BOOT_DRIVER(ux500_musb) = {
.id = UCLASS_USB_GADGET_GENERIC,
#endif
.of_match = ux500_musb_ids,
+ .ops= _gadget_ops,
.probe = ux500_musb_probe,
.remove = ux500_musb_remove,
#ifdef CONFIG_USB_MUSB_HOST
--
2.43.0
[PATCH 08/11] usb: gadget: musb: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/musb-new/ti-musb.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
index 76e8b88369e..ec1baa9337d 100644
--- a/drivers/usb/musb-new/ti-musb.c
+++ b/drivers/usb/musb-new/ti-musb.c
@@ -233,15 +233,6 @@ static int ti_musb_peripheral_of_to_plat(struct udevice
*dev)
}
#endif
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct ti_musb_peripheral *priv = dev_get_priv(dev);
-
- priv->periph->isr(0, priv->periph);
-
- return 0;
-}
-
static int ti_musb_peripheral_probe(struct udevice *dev)
{
struct ti_musb_peripheral *priv = dev_get_priv(dev);
@@ -269,12 +260,26 @@ static int ti_musb_peripheral_remove(struct udevice *dev)
return 0;
}
+static int ti_musb_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct ti_musb_peripheral *priv = dev_get_priv(dev);
+
+ priv->periph->isr(0, priv->periph);
+
+ return 0;
+}
+
+static const struct usb_gadget_generic_ops ti_musb_gadget_ops = {
+ .handle_interrupts = ti_musb_gadget_handle_interrupts,
+};
+
U_BOOT_DRIVER(ti_musb_peripheral) = {
.name = "ti-musb-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
#if CONFIG_IS_ENABLED(OF_CONTROL)
.of_to_plat = ti_musb_peripheral_of_to_plat,
#endif
+ .ops= _musb_gadget_ops,
.probe = ti_musb_peripheral_probe,
.remove = ti_musb_peripheral_remove,
.ops= _usb_ops,
--
2.43.0
[PATCH 07/11] usb: gadget: omap2430: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/musb-new/omap2430.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb-new/omap2430.c b/drivers/usb/musb-new/omap2430.c
index c8dd73050b2..96771c28cef 100644
--- a/drivers/usb/musb-new/omap2430.c
+++ b/drivers/usb/musb-new/omap2430.c
@@ -46,16 +46,6 @@ static inline void omap2430_low_level_init(struct musb *musb)
musb_writel(musb->mregs, OTG_FORCESTDBY, l);
}
-#ifdef CONFIG_DM_USB_GADGET
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct musb_host_data *host = dev_get_priv(dev);
-
- host->host->isr(0, host->host);
- return 0;
-}
-#endif
-
static int omap2430_musb_init(struct musb *musb)
{
u32 l;
@@ -273,6 +263,21 @@ static int omap2430_musb_remove(struct udevice *dev)
return 0;
}
+#ifndef CONFIG_USB_MUSB_HOST
+static int omap2340_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct musb_host_data *host = dev_get_priv(dev);
+
+ host->host->isr(0, host->host);
+
+ return 0;
+}
+
+static const struct usb_gadget_generic_ops omap2340_gadget_ops = {
+ .handle_interrupts = omap2340_gadget_handle_interrupts,
+};
+#endif
+
static const struct udevice_id omap2430_musb_ids[] = {
{ .compatible = "ti,omap3-musb" },
{ .compatible = "ti,omap4-musb" },
@@ -285,6 +290,7 @@ U_BOOT_DRIVER(omap2430_musb) = {
.id = UCLASS_USB,
#else
.id = UCLASS_USB_GADGET_GENERIC,
+ .ops= _gadget_ops,
#endif
.of_match = omap2430_musb_ids,
.of_to_plat = omap2430_musb_of_to_plat,
--
2.43.0
[PATCH 06/11] usb: gadget: mtu3: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/mtu3/mtu3_plat.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index ca86b58dfcd..f8e14eabfb2 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -223,15 +223,6 @@ static const struct udevice_id ssusb_of_match[] = {
};
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct mtu3 *mtu = dev_get_priv(dev);
-
- mtu3_irq(0, mtu);
-
- return 0;
-}
-
static int mtu3_gadget_probe(struct udevice *dev)
{
struct ssusb_mtk *ssusb = dev_to_ssusb(dev->parent);
@@ -250,10 +241,24 @@ static int mtu3_gadget_remove(struct udevice *dev)
return 0;
}
+static int mtu3_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct mtu3 *mtu = dev_get_priv(dev);
+
+ mtu3_irq(0, mtu);
+
+ return 0;
+}
+
+static const struct usb_gadget_generic_ops mtu3_gadget_ops = {
+ .handle_interrupts = mtu3_gadget_handle_interrupts,
+};
+
U_BOOT_DRIVER(mtu3_peripheral) = {
.name = "mtu3-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
.of_match = ssusb_of_match,
+ .ops = _gadget_ops,
.probe = mtu3_gadget_probe,
.remove = mtu3_gadget_remove,
.priv_auto = sizeof(struct mtu3),
--
2.43.0
[PATCH 05/11] usb: gadget: max3420: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/gadget/max3420_udc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/max3420_udc.c b/drivers/usb/gadget/max3420_udc.c
index 5a227c0ffd9..557a1f0644e 100644
--- a/drivers/usb/gadget/max3420_udc.c
+++ b/drivers/usb/gadget/max3420_udc.c
@@ -808,13 +808,6 @@ static void max3420_setup_spi(struct max3420_udc *udc)
spi_wr8(udc, MAX3420_REG_PINCTL, bFDUPSPI);
}
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct max3420_udc *udc = dev_get_priv(dev);
-
- return max3420_irq(udc);
-}
-
static int max3420_udc_probe(struct udevice *dev)
{
struct max3420_udc *udc = dev_get_priv(dev);
@@ -859,6 +852,17 @@ static int max3420_udc_remove(struct udevice *dev)
return 0;
}
+static int max3420_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct max3420_udc *udc = dev_get_priv(dev);
+
+ return max3420_irq(udc);
+}
+
+static const struct usb_gadget_generic_ops max3420_gadget_ops = {
+ .handle_interrupts = max3420_gadget_handle_interrupts,
+};
+
static const struct udevice_id max3420_ids[] = {
{ .compatible = "maxim,max3421-udc" },
{ }
@@ -868,6 +872,7 @@ U_BOOT_DRIVER(max3420_generic_udc) = {
.name = "max3420-udc",
.id = UCLASS_USB_GADGET_GENERIC,
.of_match = max3420_ids,
+ .ops = _gadget_ops,
.probe = max3420_udc_probe,
.remove = max3420_udc_remove,
.priv_auto = sizeof(struct max3420_udc),
--
2.43.0
[PATCH 04/11] usb: gadget: dwc3: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/dwc3/dwc3-generic.c| 23 ++-
drivers/usb/dwc3/dwc3-layerscape.c | 21 +
2 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 8db678eb85d..731ede2fead 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -194,34 +194,39 @@ static int dwc3_generic_of_to_plat(struct udevice *dev)
}
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+static int dwc3_generic_peripheral_probe(struct udevice *dev)
{
struct dwc3_generic_priv *priv = dev_get_priv(dev);
- struct dwc3 *dwc3 = >dwc3;
- dwc3_gadget_uboot_handle_interrupt(dwc3);
-
- return 0;
+ return dwc3_generic_probe(dev, priv);
}
-static int dwc3_generic_peripheral_probe(struct udevice *dev)
+static int dwc3_generic_peripheral_remove(struct udevice *dev)
{
struct dwc3_generic_priv *priv = dev_get_priv(dev);
- return dwc3_generic_probe(dev, priv);
+ return dwc3_generic_remove(dev, priv);
}
-static int dwc3_generic_peripheral_remove(struct udevice *dev)
+static int dwc3_gadget_handle_interrupts(struct udevice *dev)
{
struct dwc3_generic_priv *priv = dev_get_priv(dev);
+ struct dwc3 *dwc3 = >dwc3;
- return dwc3_generic_remove(dev, priv);
+ dwc3_gadget_uboot_handle_interrupt(dwc3);
+
+ return 0;
}
+static const struct usb_gadget_generic_ops dwc3_gadget_ops = {
+ .handle_interrupts = dwc3_gadget_handle_interrupts,
+};
+
U_BOOT_DRIVER(dwc3_generic_peripheral) = {
.name = "dwc3-generic-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
.of_to_plat = dwc3_generic_of_to_plat,
+ .ops= _gadget_ops,
.probe = dwc3_generic_peripheral_probe,
.remove = dwc3_generic_peripheral_remove,
.priv_auto = sizeof(struct dwc3_generic_priv),
diff --git a/drivers/usb/dwc3/dwc3-layerscape.c
b/drivers/usb/dwc3/dwc3-layerscape.c
index ff83bf71e89..108b44c67eb 100644
--- a/drivers/usb/dwc3/dwc3-layerscape.c
+++ b/drivers/usb/dwc3/dwc3-layerscape.c
@@ -99,33 +99,38 @@ static int dwc3_layerscape_of_to_plat(struct udevice *dev)
}
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+static int dwc3_layerscape_peripheral_probe(struct udevice *dev)
{
struct dwc3_layerscape_priv *priv = dev_get_priv(dev);
- dwc3_gadget_uboot_handle_interrupt(>dwc3);
-
- return 0;
+ return dwc3_layerscape_probe(dev, priv);
}
-static int dwc3_layerscape_peripheral_probe(struct udevice *dev)
+static int dwc3_layerscape_peripheral_remove(struct udevice *dev)
{
struct dwc3_layerscape_priv *priv = dev_get_priv(dev);
- return dwc3_layerscape_probe(dev, priv);
+ return dwc3_layerscape_remove(dev, priv);
}
-static int dwc3_layerscape_peripheral_remove(struct udevice *dev)
+static int dwc3_layerscape_gadget_handle_interrupts(struct udevice *dev)
{
struct dwc3_layerscape_priv *priv = dev_get_priv(dev);
- return dwc3_layerscape_remove(dev, priv);
+ dwc3_gadget_uboot_handle_interrupt(>dwc3);
+
+ return 0;
}
+static const struct usb_gadget_generic_ops dwc3_layerscape_gadget_ops = {
+ .handle_interrupts = dwc3_layerscape_gadget_handle_interrupts,
+};
+
U_BOOT_DRIVER(dwc3_layerscape_peripheral) = {
.name = "dwc3-layerscape-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
.of_to_plat = dwc3_layerscape_of_to_plat,
+ .ops= _layerscape_gadget_ops,
.probe = dwc3_layerscape_peripheral_probe,
.remove = dwc3_layerscape_peripheral_remove,
.priv_auto = sizeof(struct dwc3_layerscape_priv),
--
2.43.0
[PATCH 03/11] usb: gadget: dwc2: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/gadget/dwc2_udc_otg.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index 6bd395a6235..7e9dd6f4268 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -941,11 +941,6 @@ int dwc2_udc_handle_interrupt(void)
return 0;
}
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- return dwc2_udc_handle_interrupt();
-}
-
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
struct dwc2_priv_data {
struct clk_bulk clks;
@@ -1173,6 +1168,15 @@ static int dwc2_udc_otg_remove(struct udevice *dev)
return dm_scan_fdt_dev(dev);
}
+static int dwc2_gadget_handle_interrupts(struct udevice *dev)
+{
+ return dwc2_udc_handle_interrupt();
+}
+
+static const struct usb_gadget_generic_ops dwc2_gadget_ops = {
+ .handle_interrupts = dwc2_gadget_handle_interrupts,
+};
+
static const struct udevice_id dwc2_udc_otg_ids[] = {
{ .compatible = "snps,dwc2" },
{ .compatible = "brcm,bcm2835-usb" },
@@ -1185,6 +1189,7 @@ U_BOOT_DRIVER(dwc2_udc_otg) = {
.name = "dwc2-udc-otg",
.id = UCLASS_USB_GADGET_GENERIC,
.of_match = dwc2_udc_otg_ids,
+ .ops= _gadget_ops,
.of_to_plat = dwc2_udc_otg_of_to_plat,
.probe = dwc2_udc_otg_probe,
.remove = dwc2_udc_otg_remove,
@@ -1200,4 +1205,9 @@ int dwc2_udc_B_session_valid(struct udevice *dev)
return readl(_reg->gotgctl) & B_SESSION_VALID;
}
+#else
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+ return dwc2_udc_handle_interrupt();
+}
#endif /* CONFIG_IS_ENABLED(DM_USB_GADGET) */
--
2.43.0
[PATCH 01/11] usb: gadget: Introduce handle_interrupts ops to USB_GADGET_GENERIC uclass
Introduce .ops for USB_GADGET_GENERIC uclass. The first new ops is
.handle_interrupts which must be implemented by DM capable USB gadget
controller drivers and must implement interrupt handling similar to
dm_usb_gadget_handle_interrupts(). This patch currently provides weak
dm_usb_gadget_handle_interrupts() implementation which is overriden by
the drivers, but this will be removed once conversion to handle_interrupts
callback is complete.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/gadget/udc/udc-uclass.c | 24
include/linux/usb/gadget.h | 8
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-uclass.c
b/drivers/usb/gadget/udc/udc-uclass.c
index 5dc23a55bb5..2320039fe3b 100644
--- a/drivers/usb/gadget/udc/udc-uclass.c
+++ b/drivers/usb/gadget/udc/udc-uclass.c
@@ -12,6 +12,25 @@
#include
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+static inline const struct usb_gadget_generic_ops *
+usb_gadget_generic_dev_ops(struct udevice *dev)
+{
+ return (const struct usb_gadget_generic_ops *)dev->driver->ops;
+}
+
+__weak int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+ const struct usb_gadget_generic_ops *ops;
+
+ ops = usb_gadget_generic_dev_ops(dev);
+ if (!ops)
+ return -EFAULT;
+ if (!ops->handle_interrupts)
+ return -ENOSYS;
+
+ return ops->handle_interrupts(dev);
+}
+
int udc_device_get_by_index(int index, struct udevice **udev)
{
struct udevice *dev = NULL;
@@ -54,6 +73,11 @@ int udc_device_put(struct udevice *udev)
{
return board_usb_cleanup(legacy_index, USB_INIT_DEVICE);
}
+
+__weak int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+ return 0;
+}
#endif
#if CONFIG_IS_ENABLED(DM)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 36572be89e6..cf2161603d6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -970,6 +970,14 @@ extern void usb_ep_autoconfig_reset(struct usb_gadget *);
extern int dm_usb_gadget_handle_interrupts(struct udevice *);
+/**
+ * struct usb_gadget_generic_ops - The functions that a gadget driver must
implement.
+ * @handle_interrupts: Handle UDC interrupts.
+ */
+struct usb_gadget_generic_ops {
+ int (*handle_interrupts)(struct udevice *udevice);
+};
+
/**
* udc_device_get_by_index() - Get UDC udevice by index
* @index: UDC device index
--
2.43.0
[PATCH 02/11] usb: gadget: cdns3: Convert interrupt handling to usb_gadget_generic_ops
Implement .handle_interrupts callback as a replacement for deprecated
dm_usb_gadget_handle_interrupts() function. The new callback allows
for each DM capable USB gadget controller driver to define its own
IRQ handling implementation without colliding with other controller
drivers.
Keep the dm_usb_gadget_handle_interrupts() in this driver for non-DM
case for now, until this driver gets fully converted to DM USB gadget.
Signed-off-by: Marek Vasut
---
Cc: Alexander Sverdlin
Cc: Felipe Balbi
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Nishanth Menon
Cc: Simon Glass
Cc: Thinh Nguyen
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
drivers/usb/cdns3/core.c | 24
drivers/usb/cdns3/gadget-export.h | 2 ++
drivers/usb/cdns3/gadget.c| 11 +--
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index b4e931646b8..cbe06a9e7b6 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -462,15 +463,38 @@ static int cdns3_gadget_remove(struct udevice *dev)
return cdns3_remove(cdns);
}
+static int cdns3_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct cdns3 *cdns = dev_get_priv(dev);
+
+ cdns3_gadget_uboot_handle_interrupt(cdns);
+
+ return 0;
+}
+
+static const struct usb_gadget_generic_ops cdns3_gadget_ops = {
+ .handle_interrupts = cdns3_gadget_handle_interrupts,
+};
+
U_BOOT_DRIVER(cdns_usb3_peripheral) = {
.name = "cdns-usb3-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
.of_match = cdns3_ids,
+ .ops= _gadget_ops,
.probe = cdns3_gadget_probe,
.remove = cdns3_gadget_remove,
.priv_auto = sizeof(struct cdns3_gadget_priv),
.flags = DM_FLAG_ALLOC_PRIV_DMA,
};
+#else
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+ struct cdns3 *cdns = dev_get_priv(dev);
+
+ cdns3_gadget_uboot_handle_interrupt(cdns);
+
+ return 0;
+}
#endif
#if defined(CONFIG_SPL_USB_HOST) || \
diff --git a/drivers/usb/cdns3/gadget-export.h
b/drivers/usb/cdns3/gadget-export.h
index 577469eee96..b3fd7c53039 100644
--- a/drivers/usb/cdns3/gadget-export.h
+++ b/drivers/usb/cdns3/gadget-export.h
@@ -25,4 +25,6 @@ static inline void cdns3_gadget_exit(struct cdns3 *cdns) { }
#endif
+void cdns3_gadget_uboot_handle_interrupt(struct cdns3 *cdns);
+
#endif /* __LINUX_CDNS3_GADGET_EXPORT */
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index d11175dc5b6..32b2c412068 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -2755,19 +2755,10 @@ int cdns3_gadget_init(struct cdns3 *cdns)
*
* Handles ep0 and gadget interrupt
*/
-static void cdns3_gadget_uboot_handle_interrupt(struct cdns3 *cdns)
+void cdns3_gadget_uboot_handle_interrupt(struct cdns3 *cdns)
{
int ret = cdns3_device_irq_handler(0, cdns);
if (ret == IRQ_WAKE_THREAD)
cdns3_device_thread_irq_handler(0, cdns);
}
-
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- struct cdns3 *cdns = dev_get_priv(dev);
-
- cdns3_gadget_uboot_handle_interrupt(cdns);
-
- return 0;
-}
--
2.43.0
[PATCH 00/11] usb: gadget: Introduce handle_interrupts ops to USB_GADGET_GENERIC uclass
Introduce .ops for USB_GADGET_GENERIC uclass. The first new ops is .handle_interrupts which must be implemented by DM capable USB gadget controller drivers and must implement interrupt handling similar to dm_usb_gadget_handle_interrupts(). For DM USB gadget drivers this is a replacement for dm_usb_gadget_handle_interrupts(). Convert the DM USB gadget drivers to this new ops instead. DEPENDS: https://patchwork.ozlabs.org/project/uboot/list/?series=410150 Marek Vasut (11): usb: gadget: Introduce handle_interrupts ops to USB_GADGET_GENERIC uclass usb: gadget: cdns3: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: dwc2: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: dwc3: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: max3420: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: mtu3: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: omap2430: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: musb: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: ux500: Convert interrupt handling to usb_gadget_generic_ops usb: gadget: sandbox: Drop dm_usb_gadget_handle_interrupts() usb: gadget: Mark dm_usb_gadget_handle_interrupts as non-weak for DM_USB_GADGET drivers/usb/cdns3/core.c| 24 drivers/usb/cdns3/gadget-export.h | 2 ++ drivers/usb/cdns3/gadget.c | 11 +-- drivers/usb/dwc3/dwc3-generic.c | 23 ++- drivers/usb/dwc3/dwc3-layerscape.c | 21 + drivers/usb/gadget/dwc2_udc_otg.c | 20 +++- drivers/usb/gadget/max3420_udc.c| 19 --- drivers/usb/gadget/udc/udc-uclass.c | 24 drivers/usb/host/usb-sandbox.c | 7 +-- drivers/usb/mtu3/mtu3_plat.c| 23 ++- drivers/usb/musb-new/omap2430.c | 26 -- drivers/usb/musb-new/ti-musb.c | 23 ++- drivers/usb/musb-new/ux500.c| 22 ++ include/linux/usb/gadget.h | 8 14 files changed, 172 insertions(+), 81 deletions(-) --- Cc: Alexander Sverdlin Cc: Felipe Balbi Cc: Lukasz Majewski Cc: Mattijs Korpershoek Cc: Nishanth Menon Cc: Simon Glass Cc: Thinh Nguyen Cc: Tom Rini Cc: u-boot@lists.denx.de -- 2.43.0
Re: [PATCH v5 0/3] automatically add /chosen/kaslr-seed and deduplicate code
On Thu, May 30, 2024 at 03:06:31PM -0700, Tim Harvey wrote: > This series will automatically add /chosen/kaslr-seed to the dt if DM_RNG is > enabled > during the boot process. > > 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. > > If we have DM_RNG enabled populate this value automatically when > fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT > is enabled as its implementation uses a different source of entropy > that is not yet implemented as DM_RNG. We also skip this if > MEASURED_BOOT is enabled as in that case any modifications to the > dt will cause measured boot to fail (although there are many other > places the dt is altered). > > As this fdt node is added elsewhere create a library function and > use it to deduplicate code. We will provide a parameter to overwrite > the node if present. > > For our automatic injection, we will use the first rng device and > not overwrite if already present with a non-zero value (which may > have been populated by an earlier boot stage). This way if a board > specific ft_board_setup() function wants to customize this behavior > it can call fdt_kaslrseed with a rng device index of its choosing and > set overwrite true. > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now > but left in place in case boot scripts exist that rely on this command > existing and returning success. An informational message is printed to > alert users of this command that it is likely no longer needed. > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for > randomization and completely ignores the kaslr-seed for its own > randomness needs (i.e the randomization of the physical placement of > the kernel). It gets weeded out from the DTB that gets handed over via > efi_install_fdt() as it would also mess up the measured boot DTB TPM > measurements as well. This needs to be reworked / update the test that now breaks: https://source.denx.de/u-boot/u-boot/-/jobs/849988#L264 -- Tom signature.asc Description: PGP signature
[PATCH v3 2/2] doc: api: bootcount: Convert to rST documentation
Move to the new documentation style with rST formatting. Signed-off-by: Vasileios Amoiridis --- doc/README.bootcount | 53 --- doc/api/bootcount.rst | 58 +++ 2 files changed, 58 insertions(+), 53 deletions(-) delete mode 100644 doc/README.bootcount create mode 100644 doc/api/bootcount.rst diff --git a/doc/README.bootcount b/doc/README.bootcount deleted file mode 100644 index 0f4ffb6828..00 --- a/doc/README.bootcount +++ /dev/null @@ -1,53 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -Boot Count Limit - - -This is enabled by CONFIG_BOOTCOUNT_LIMIT. - -This allows to detect multiple failed attempts to boot Linux. - -After a power-on reset, the "bootcount" variable will be initialized to 1, and -each reboot will increment the value by 1. - -If, after a reboot, the new value of "bootcount" exceeds the value of -"bootlimit", then instead of the standard boot action (executing the contents of -"bootcmd"), an alternate boot action will be performed, and the contents of -"altbootcmd" will be executed. - -If the variable "bootlimit" is not defined in the environment, the Boot Count -Limit feature is disabled. If it is enabled, but "altbootcmd" is not defined, -then U-Boot will drop into interactive mode and remain there. - -It is the responsibility of some application code (typically a Linux -application) to reset the variable "bootcount" to 0 when the system booted -successfully, thus allowing for more boot cycles. - -CONFIG_BOOTCOUNT_FS - - -This adds support for maintaining boot count in a file on a filesystem. -Supported filesystems are FAT and EXT. The file to use is defined by: - -CONFIG_SYS_BOOTCOUNT_FS_INTERFACE -CONFIG_SYS_BOOTCOUNT_FS_DEVPART -CONFIG_SYS_BOOTCOUNT_FS_NAME - -The format of the file is: - - = -type entry - = -u8 magic -u8 version -u8 bootcount -u8 upgrade_available - = - -To prevent unattended usage of "altbootcmd", the "upgrade_available" variable is -used. -If "upgrade_available" is 0, "bootcount" is not saved. -If "upgrade_available" is 1, "bootcount" is saved. -So a userspace application should take care of setting the "upgrade_available" -and "bootcount" variables to 0, if the system boots successfully. -This also avoids writing the "bootcount" information on all reboots. diff --git a/doc/api/bootcount.rst b/doc/api/bootcount.rst new file mode 100644 index 00..9435a7ef15 --- /dev/null +++ b/doc/api/bootcount.rst @@ -0,0 +1,58 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Boot Count Limit + + +This is enabled by CONFIG_BOOTCOUNT_LIMIT. + +This allows to detect multiple failed attempts to boot Linux. + +After a power-on reset, the ``bootcount`` variable will be initialized to 1, and +each reboot will increment the value by 1. + +If, after a reboot, the new value of ``bootcount`` exceeds the value of +``bootlimit``, then instead of the standard boot action (executing the contents +of ``bootcmd``), an alternate boot action will be performed, and the contents of +``altbootcmd`` will be executed. + +If the variable ``bootlimit`` is not defined in the environment, the Boot Count +Limit feature is disabled. If it is enabled, but ``altbootcmd`` is not defined, +then U-Boot will drop into interactive mode and remain there. + +It is the responsibility of some application code (typically a Linux +application) to reset the variable ``bootcount`` to 0 when the system booted +successfully, thus allowing for more boot cycles. + +CONFIG_BOOTCOUNT_FS + + +This adds support for maintaining boot count in a file on a filesystem. +Tested filesystems are FAT and EXT. The file to use is defined by: + +CONFIG_SYS_BOOTCOUNT_FS_INTERFACE +CONFIG_SYS_BOOTCOUNT_FS_DEVPART +CONFIG_SYS_BOOTCOUNT_FS_NAME + +The format of the file is: + +.. list-table:: + :header-rows: 1 + + * - type + - entry + * - u8 + - magic + * - u8 + - version + * - u8 + - bootcount + * - u8 + - upgrade_available + +To prevent unattended usage of ``altbootcmd``, the ``upgrade_available`` +variable is used. +If ``upgrade_available`` is 0, ``bootcount`` is not saved. +If ``upgrade_available`` is 1, ``bootcount`` is saved. +So a userspace application should take care of setting the ``upgrade_available`` +and ``bootcount`` variables to 0, if the system boots successfully. +This also avoids writing the ``bootcount`` information on all reboots. -- 2.25.1
[PATCH v3 1/2] drivers: bootcount: Add support for ANY filesystem
Add support to save boot count variable in ANY filesystem. Tested with
FAT and EXT.
Reviewed-by: Tom Rini
Reviewed-by: Heiko Schocher
Reviewed-by: Philip Oberfichtner
Signed-off-by: Vasileios Amoiridis
---
doc/README.bootcount | 12 +++
drivers/bootcount/Kconfig | 36 +--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 +++
4 files changed, 31 insertions(+), 31 deletions(-)
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
diff --git a/doc/README.bootcount b/doc/README.bootcount
index f6c5f82f98..0f4ffb6828 100644
--- a/doc/README.bootcount
+++ b/doc/README.bootcount
@@ -23,15 +23,15 @@ It is the responsibility of some application code
(typically a Linux
application) to reset the variable "bootcount" to 0 when the system booted
successfully, thus allowing for more boot cycles.
-CONFIG_BOOTCOUNT_EXT
+CONFIG_BOOTCOUNT_FS
-This adds support for maintaining boot count in a file on an EXT filesystem.
-The file to use is defined by:
+This adds support for maintaining boot count in a file on a filesystem.
+Supported filesystems are FAT and EXT. The file to use is defined by:
-CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
-CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
-CONFIG_SYS_BOOTCOUNT_EXT_NAME
+CONFIG_SYS_BOOTCOUNT_FS_INTERFACE
+CONFIG_SYS_BOOTCOUNT_FS_DEVPART
+CONFIG_SYS_BOOTCOUNT_FS_NAME
The format of the file is:
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 3c56253b1e..fbf3c56b41 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -25,13 +25,13 @@ config BOOTCOUNT_GENERIC
Set to the address where the bootcount and bootcount magic
will be stored.
-config BOOTCOUNT_EXT
- bool "Boot counter on EXT filesystem"
- depends on FS_EXT4
- select EXT4_WRITE
+config BOOTCOUNT_FS
+ bool "Boot counter on a filesystem"
help
- Add support for maintaining boot count in a file on an EXT
- filesystem.
+ Add support for maintaining boot count in a file on a filesystem.
+ This requires that you have enabled write support for the filesystem
+ that you will be used by the partition that you configure this feature
+ for.
config BOOTCOUNT_AM33XX
bool "Boot counter in AM33XX RTC IP block"
@@ -184,26 +184,26 @@ config SYS_BOOTCOUNT_SINGLEWORD
This option enables packing boot count magic value and boot count
into single word (32 bits).
-config SYS_BOOTCOUNT_EXT_INTERFACE
- string "Interface on which to find boot counter EXT filesystem"
+config SYS_BOOTCOUNT_FS_INTERFACE
+ string "Interface on which to find boot counter filesystem"
default "mmc"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the interface to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_DEVPART
- string "Partition of the boot counter EXT filesystem"
+config SYS_BOOTCOUNT_FS_DEVPART
+ string "Partition of the boot counter filesystem"
default "0:1"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the partition to use when locating the filesystem to use for the
boot counter.
-config SYS_BOOTCOUNT_EXT_NAME
- string "Path and filename of the EXT filesystem based boot counter"
+config SYS_BOOTCOUNT_FS_NAME
+ string "Path and filename of the FS filesystem based boot counter"
default "/boot/failures"
- depends on BOOTCOUNT_EXT
+ depends on BOOTCOUNT_FS
help
Set the filename and path of the file used to store the boot counter.
@@ -211,18 +211,18 @@ config SYS_BOOTCOUNT_ADDR
hex "RAM address used for reading and writing the boot counter"
default 0x44E3E000 if BOOTCOUNT_AM33XX || BOOTCOUNT_AM33XX_NVMEM
default 0xE0115FF8 if ARCH_LS1043A || ARCH_LS1021A
- depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX_NVMEM
help
Set the address used for reading and writing the boot counter.
config SYS_BOOTCOUNT_MAGIC
hex "Magic value for the boot counter"
- default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
BOOTCOUNT_RAM || BOOTCOUNT_AT91 || DM_BOOTCOUNT
default 0xB0 if BOOTCOUNT_AM33XX_NVMEM
- depends on BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
+ depends on BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
BOOTCOUNT_RAM || BOOTCOUNT_AT91 ||
[PATCH v3 0/2] drivers: bootcount: Add support for ANY filesystem
Changes in v3:
- Remove specific CONFIGs for filesystems
- Add message to prompt user to enable required write function
- Use tags from previous rounds
- Move documentation to rST
v2:
https://lore.kernel.org/u-boot/20240610185116.353604-1-vassilisa...@gmail.com
Changes in v2:
- Use generic code by utilizing FS_TYPE_ANY
- Change filename from bootcount_ext.c to bootcount_fs.c
v1:
https://lore.kernel.org/u-boot/20240605181041.68317-1-vassilisa...@gmail.com/
This patch adds support to save the bootcount variable in a file located in
FAT filesystem. Up to now, there was support only for EXT filesystem.
The reason I put this as RFC is because the file "bootcount_ext.c" will no
longer represent the implementation for the EXT filesystem, but also for the
FAT filesystem. Should it be renamed? If not, wouldn't it be inconsistent?
Cheers,
Vasilis
Vasileios Amoiridis (2):
drivers: bootcount: Add support for ANY filesystem
doc: api: bootcount: Convert to rST documentation
doc/README.bootcount | 53 -
doc/api/bootcount.rst | 58 +++
drivers/bootcount/Kconfig | 36 ++--
drivers/bootcount/Makefile| 2 +-
.../{bootcount_ext.c => bootcount_fs.c} | 12 ++--
5 files changed, 83 insertions(+), 78 deletions(-)
delete mode 100644 doc/README.bootcount
create mode 100644 doc/api/bootcount.rst
rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%)
--
2.25.1
Re: [PATCH] board: beagleplay: Fix the bootpart to pick from root partition
On Thu, Jun 13, 2024 at 4:47 PM Robert Nelson wrote: > > On Thu, Jun 13, 2024 at 3:06 AM Dhruva Gole wrote: > > > > The Kernel Image and DTB files are supposed to be picked from the rootfs > > of the SD Card, this fails in legacy boot flow because bootpart is set > > to 1:1. Fix it. > > and where is that rule defined? > > Production boards ship with Kernel Image and DTB's in the 1st fat partition.. Besides, u-boot should scan for extlinux.conf on "any" partition. Regards, -- Robert Nelson https://rcn-ee.com/
Re: [PATCH] board: beagleplay: Fix the bootpart to pick from root partition
On Thu, Jun 13, 2024 at 3:06 AM Dhruva Gole wrote: > > The Kernel Image and DTB files are supposed to be picked from the rootfs > of the SD Card, this fails in legacy boot flow because bootpart is set > to 1:1. Fix it. and where is that rule defined? Production boards ship with Kernel Image and DTB's in the 1st fat partition.. Regards, -- Robert Nelson https://rcn-ee.com/
Re: [PATCH v2 5/5] bootstd: Add test for bootmeth_android
Le 13/06/2024 à 12:13, Mattijs Korpershoek a écrit :
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_abootimg # build bootv4.img
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Reviewed-by: Simon Glass
Signed-off-by: Mattijs Korpershoek
---
arch/sandbox/dts/test.dts | 8 +
configs/sandbox_defconfig | 2 +-
test/boot/bootflow.c | 65 ++--
test/py/tests/test_ut.py | 76 +++
4 files changed, 147 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index a012f5c4c9ba..5fb5eac862ec 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -43,6 +43,7 @@
mmc4 = "/mmc4";
mmc5 = "/mmc5";
mmc6 = "/mmc6";
+ mmc7 = "/mmc7";
pci0 =
pci1 =
pci2 =
@@ -1129,6 +1130,13 @@
filename = "mmc6.img";
};
+ /* This is used for Android tests */
+ mmc7 {
+ status = "disabled";
+ compatible = "sandbox,mmc";
+ filename = "mmc7.img";
+ };
+
pch {
compatible = "sandbox,pch";
};
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 93b52f2de5cf..bc4398f101a7 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -15,6 +15,7 @@ CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTMETH_ANDROID=y
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_MEASURED_BOOT=y
CONFIG_BOOTSTAGE=y
@@ -40,7 +41,6 @@ CONFIG_LOG_MAX_LEVEL=9
CONFIG_LOG_DEFAULT_LEVEL=6
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_STACKPROTECTOR=y
-CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
CONFIG_CMD_LICENSE=y
CONFIG_CMD_SMBIOS=y
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 4511cfa7f9bf..934c4dcbad2b 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -27,6 +27,7 @@
DECLARE_GLOBAL_DATA_PTR;
+extern U_BOOT_DRIVER(bootmeth_android);
extern U_BOOT_DRIVER(bootmeth_cros);
extern U_BOOT_DRIVER(bootmeth_2script);
@@ -518,12 +519,12 @@ BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
* @uts: Unit test state
* @mmc_dev: MMC device to use, e.g. "mmc4". Note that this must remain valid
*in the caller until
- * @bind_cros: true to bind the ChromiumOS bootmeth
+ * @bind_cros: true to bind the ChromiumOS and Android bootmeths
* @old_orderp: Returns the original bootdev order, which must be restored
* Returns 0 on success, -ve on failure
*/
static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev,
- bool bind_cros, const char ***old_orderp)
+ bool bind_cros_android, const char ***old_orderp)
{
static const char *order[] = {"mmc2", "mmc1", NULL, NULL};
struct udevice *dev, *bootstd;
@@ -545,12 +546,19 @@ static int prep_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
"bootmeth_script", 0, ofnode_null(), ));
/* Enable the cros bootmeth if needed */
- if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros) {
+ if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros_android) {
ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_cros),
"cros", 0, ofnode_null(), ));
}
+ /* Enable the android bootmeths if needed */
+ if (IS_ENABLED(CONFIG_BOOTMETH_ANDROID) && bind_cros_android) {
+ ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
+ ut_assertok(device_bind(bootstd,
DM_DRIVER_REF(bootmeth_android),
+ "android", 0, ofnode_null(), ));
+ }
+
/* Change the order to include the device */
std = dev_get_priv(bootstd);
old_order = std->bootdev_order;
@@ -589,6 +597,37 @@ static int scan_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
return 0;
}
+/**
+ * scan_mmc_android_bootdev() - Set up an mmc bootdev so we can access other
+ * distros. Android bootflow might print "ANDROID:*" while scanning
+ *
+ * @uts: Unit test state
+ * @mmc_dev: MMC device to use, e.g. "mmc4"
+ * Returns 0 on success, -ve on failure
+ */
+static int scan_mmc_android_bootdev(struct unit_test_state *uts, const char
*mmc_dev)
+{
+
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
On Thu, 13 Jun 2024 at 22:57, Heinrich Schuchardt wrote: > > On 13.06.24 18:59, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > >> > >> On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > >>> Hi Tom, > >>> > >>> On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > >> > >> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > >> > >> [snip] > >>> Also IMO there is only really one LMB list today. We create it at the > >>> start of bootm and then it is done when we boot. The file-loading > >>> stuff is what makes all this confusing...and with bootstd that is > >>> under control as well. > >>> > >>> At lot of this effort seems to be about dealing with random scripts > >>> which load things. We want to make sure we complain if something > >>> overlaps. But we should be making the bootstd case work nicely and > >>> doing things within that framework. Also EFI sort-of has its own > >>> thing, which it is very-much in control of. > >>> > >>> Overall I think this is a bit more subtle that just combining > >>> allocators. > >> > >> I think this gets to the main misunderstanding. The problem isn't > >> handling bootstd, or EFI boot, or even assorted scripts. Those are all > >> cases where things are otherwise (sufficiently) well-defined. The > >> problem is "security" and that a "carefully crafted payload" could do > >> something malicious. That's why we have to do all of this stuff sooner > >> rather than later in our boot process. > > > > That's the first I have heard of this, actually, but a bit more detail > > would help. How does the payload get loaded? I'm just not sure about > > the overall goals. It seems that everyone else is already familiar - > > can someone please take the time to point me to the details? > > Well, the short version I believe of the first CVE we got (and so > started abusing LMB) was along the lines of "load an image near where > the U-Boot stack is, smash things for fun and exploits". > >>> > >>> OK. I am surprised that LMB does not catch that. It is supposed to add > >>> the stack and various other things right at the start before loading > >>> any file. So even if it clears the LMB each time, it should not be > >>> able to do that. Having said this, the code may be buggy as I don't > >>> think we have tests for U-Boot's overall functional behaviour in these > >>> situations. > >> > >> Right, LMB does catch the example I gave (because we made all of the > >> load from storage/network functions init an lmb and we always make sure > >> a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > >> "what if EFI does the loading?" and we've kludged around that, and in > >> turn had some of the thorny questions. Some of that is what I think > >> you're asking about in this part of the thread, to which the answer is > >> "EFI spec says you need to place X in memory", so we just need to > >> reserve it when it's asked for, so that something else can't come along > >> and smash it maliciously. > > > > OK I see. Of course it isn't just EFI that has this issue. I believe > > the answer (for small blocks) is to use malloc(), which I think we do > > with a few exceptions which Ilias pointed out. For things like the TPM > > log and ACPI tables we should probably use a bloblist, as we do on > > x86. For large things (like loading a kernel) we should use LMB. I've > > been thinking about how best to tie this to boot, as opposed to random > > allocations in U-Boot itself, which would lead to fragmentation and > > strange behaviour. I think bootstd is a great place to have a > > persistent LMB. It can be attached to bootstd_priv. > > > > My hope is that EFI is just another boot method, where > > already-allocating things are presented to the OS. Apart from the > > Ilias exceptions, I believe this is how it works today. > > > > Where I think this heads in the wrong direction is using > > EFI-allocation functions before we are booting an EFI image. EFI has > > no concept of what is 'in empty space' so it leads to the lmb > > conflict, the subject of this discussion. > > EFI binaries can return to the command line interface. > EFI binaries may be drivers that stay resident and run in the background > after returning to the command line interface. They might for instance > provide block devices. > > Device-paths must be created from EFI pool memory as they may be freed > via FreePool() according to the EFI specification. And these we create > whenever a block-device is probed. > > We should not make any assumptions that conflict with the UEFI > specification. > > In our initial discussion with Ilias one idea was to merge LMB and EFI > memory management.
Re: [PATCH v3 0/4] Enable OSPI boot for j721s2
On Tue, 04 Jun 2024 11:39:09 +0530, Manorit Chawdhry wrote: > The series enables ospi boot for j721s2. > > Test logs: > https://gist.github.com/manorit2001/6bb91885c608e3a8cb0267ab2c614781 > > Applied to u-boot/next, thanks! -- Tom
[PATCH v2 2/2] scripts/Makefile.lib: EFI: Use capsule CRT instead of ESL file
The EFI Capsule ESL file (EFI Signature List File) used for authentication
is a binary generated from the EFI Capsule public key certificate. Instead
of including it in the source repo, automatically generate it from the
certificate file during the build process.
Currently, sandbox is the only device using this, so removed its ESL file
and set the (new) CONFIG_EFI_CAPSULE_CRT_FILE config to point to its public
key certificate.
Signed-off-by: Jonathan Humphreys
---
board/sandbox/capsule_pub_esl_good.esl | Bin 831 -> 0 bytes
configs/sandbox_defconfig | 2 +-
configs/sandbox_flattree_defconfig | 2 +-
doc/develop/uefi/uefi.rst | 8
lib/efi_loader/Kconfig | 12 +++-
scripts/Makefile.lib | 22 ++
6 files changed, 27 insertions(+), 19 deletions(-)
delete mode 100644 board/sandbox/capsule_pub_esl_good.esl
diff --git a/board/sandbox/capsule_pub_esl_good.esl
b/board/sandbox/capsule_pub_esl_good.esl
deleted file mode 100644
index
f8cc272309b2f80113c29e22bc9fdd5c767b4667..
GIT binary patch
literal 0
HcmV?d1
literal 831
zcmZ1^?2Da*aux2_hA(f&|m&&@%1|1@gOCPI%=`vTjNcb9GchtTi3D3+YdNud
z!N;6d=3f<$i4vT_x7NA^t?#f
z>a)U0PLquF6_u8?^dHul+F@6qxB0YdssF`W?=n<3b^P4dmiKI#^@p}E)#B;%RW0;Z
z-#n?@Et9eDfUQTgV*{b|~VRC6NVv@WS%&0hbnAnbMH)s>mjlOWk4kw?f2&||$2#il@?9KqESXN5
zbz2wTe>RVi?d~3_cT1K9oDaUDRd@aM1GkLbi{)Ma(#i_ui5G`j(PuTIhpoN
z73DslYiZhJ`RkA&6EhzH
z-bULy5-~dZsg>zZPS-w(zNM;c<#N4ar|5@t2FY2AoF7{4IWYI(=HR-Vl;VtSQGM$z
zG|ez&@#LeqJ9NJDsL
xX})Fc$L0Fj-|CD!3Bu=aCF
$(depfile)
+capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
+capsule_crt_file=$(subst $(quote),,$(CONFIG_EFI_CAPSULE_CRT_FILE))
+capsule_esl_dtsi=.capsule_esl.dtsi
+
quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
-cmd_capsule_esl_gen = \
- $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):"
$(capsule_esl_input_file) > $@)
+cmd_capsule_esl_gen = cert-to-efi-sig-list $< $@
-$(obj)/.capsule_esl.dtsi: FORCE
-ifeq ($(CONFIG_EFI_CAPSULE_ESL_FILE),"")
- $(error "CONFIG_EFI_CAPSULE_ESL_FILE is empty, EFI capsule
authentication \
+$(obj)/capsule_esl_file: $(capsule_crt_file) FORCE
+ifeq ($(CONFIG_EFI_CAPSULE_CRT_FILE),"")
+ $(error "CONFIG_EFI_CAPSULE_CRT_FILE is empty, EFI capsule
authentication \
public key must be specified when CONFIG_EFI_CAPSULE_AUTHENTICATE is
enabled")
else
$(call cmd,capsule_esl_gen)
endif
-capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
-capsule_esl_dtsi = .capsule_esl.dtsi
-capsule_esl_path=$(abspath $(srctree)/$(subst
$(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
+quiet_cmd_capsule_dtsi_gen = CAPSULE_DTSI_GEN $@
+cmd_capsule_dtsi_gen = \
+ $(shell sed "s:ESL_BIN_FILE:$(abspath $<):" $(capsule_esl_input_file) >
$@)
+
+$(obj)/$(capsule_esl_dtsi): $(obj)/capsule_esl_file FORCE
+ $(call cmd,capsule_dtsi_gen)
dtsi_include_list_deps := $(addprefix $(u_boot_dtsi_loc),$(subst
$(quote),,$(dtsi_include_list)))
--
2.34.1
[PATCH v2 0/2] scripts/Makefile.lib: EFI: Use capsule CRT instead of ESL
Use the capsule's public key certificate rather than a prebuilt ESL generated from the certificate. The ESL is now generated as part of the build. Changes from v1: - Converted the single patch to a series to include a bug fix found during development. - Created an explicit rule for creating the ESL file for proper makefile dependency tracking. v1 had combined creating the ESL file and generating the .dtsi include in a single command. Jonathan Humphreys (2): scripts/Makefile.lib: fixes: Embed capsule public key in platform's dtb scripts/Makefile.lib: EFI: Use capsule CRT instead of ESL file board/sandbox/capsule_pub_esl_good.esl | Bin 831 -> 0 bytes configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- doc/develop/uefi/uefi.rst | 8 lib/efi_loader/Kconfig | 12 +++- scripts/Makefile.lib | 24 +++- 6 files changed, 28 insertions(+), 20 deletions(-) delete mode 100644 board/sandbox/capsule_pub_esl_good.esl -- 2.34.1
[PATCH v2 1/2] scripts/Makefile.lib: fixes: Embed capsule public key in platform's dtb
The call to cmd_capsule_esl_gen was made directly rather than using the
"cmd,xxx" syntax.
Fixes: c7d4dfcd ("scripts/Makefile.lib: Embed capsule public key in
platform's dtb")
Signed-off-by: Jonathan Humphreys
---
scripts/Makefile.lib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 62f87517c09..af97fcfe4bb 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -351,7 +351,7 @@ ifeq ($(CONFIG_EFI_CAPSULE_ESL_FILE),"")
$(error "CONFIG_EFI_CAPSULE_ESL_FILE is empty, EFI capsule
authentication \
public key must be specified when CONFIG_EFI_CAPSULE_AUTHENTICATE is
enabled")
else
- $(call cmd_capsule_esl_gen)
+ $(call cmd,capsule_esl_gen)
endif
capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
--
2.34.1
Re: [PATCH] efi: capsule: Improve capsule update porting to new boards
Ilias Apalodimas writes: > Hi Jon, > > On Sat, 8 Jun 2024 at 02:44, Jonathan Humphreys wrote: >> >> Add to the capsule update porting documentation that when capsule >> authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), a public key >> certificate corresponding to the capsule signing key must be specified. >> >> Also add a config (EFI_CAPSULE_BOARD_INSECURE) that is set by default and >> causes a warning (info level) alerting a developer to consult this porting >> section to ensure the capsule update capability is secure for the platform. >> Once this section has been reviewed and confidence is established in the >> security of the capsule update implementation for this board, deselecting >> the EFI_CAPSULE_BOARD_INSECURE config will remove the warning. >> >> This config is to balance the desire to provide a reference implementation >> in upstream for capsule authentication but also provide some safeguards >> to prevent developers from overlooking the need to properly secure their >> implementation. >> >> Signed-off-by: Jonathan Humphreys >> --- >> doc/develop/uefi/uefi.rst| 30 +++--- >> lib/efi_loader/Kconfig | 13 + >> lib/efi_loader/efi_capsule.c | 5 + >> 3 files changed, 41 insertions(+), 7 deletions(-) >> >> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst >> index 985956ab85c..1c98c6e4ab4 100644 >> --- a/doc/develop/uefi/uefi.rst >> +++ b/doc/develop/uefi/uefi.rst >> @@ -526,6 +526,7 @@ following command can be issued >>--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \ >>optee.bin optee.capsule >> >> +.. _Enabling Capsule Authentication: >> >> Enabling Capsule Authentication >> *** >> @@ -631,17 +632,32 @@ where version.dtso looks like:: >> The properties of image-type-id and image-index must match the value >> defined in the efi_fw_image array as image_type_id and image_index. >> >> -Porting Capsule Updates to new boards >> -* >> +Porting Capsule Update to new boards >> + >> >> It is important, when using a reference board as a starting point for a >> custom >> board, that certain steps are taken to properly support Capsule Updates. >> >> -Capsule GUIDs need to be unique for each firmware and board. That is, if two >> -firmwares are built from the same source but result in different binaries >> -because they are built for different boards, they should have different >> GUIDs. >> -Therefore it is important when creating support for a new board, new GUIDs >> are >> -defined in the board's header file. *DO NOT* reuse capsule GUIDs. >> +Capsule GUIDs need to be unique for each firmware and board. That is, even >> +if two firmwares are built from the same source but result in different >> +binaries because they are built for different boards, they should have >> +different GUIDs. Therefore it is important when creating support for a new >> +board, new GUIDs are defined in the board's header file. *DO NOT* reuse >> +capsule GUIDs. >> + >> +When capsule authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), it >> +is also very important to set the public key certificate corresponding to >> +the capsule signing key. See :ref:`Enabling Capsule Authentication` for >> +more information on signing capsules. *DO NOT* reuse the certificate file >> +from the reference board, which usually would be based on the development >> +board keys. >> + >> +By default, the EFI_CAPSULE_BOARD_INSECURE config is set to true and causes >> +a warning (info level) alerting a developer to consult this section to >> +ensure the capsule update capability is secure for the platform. Once this >> +section has been reviewed and confidence is established in the security of >> +the capsule update implementation for this board, deselecting >> +EFI_CAPSULE_BOARD_INSECURE config will remove the warning. >> >> Executing the boot manager >> ~~ >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >> index 23079a5709d..f4b1a20ee40 100644 >> --- a/lib/efi_loader/Kconfig >> +++ b/lib/efi_loader/Kconfig >> @@ -236,6 +236,19 @@ config EFI_CAPSULE_ON_DISK_EARLY >> executed as part of U-Boot initialisation so that they will >> surely take place whatever is set to distro_bootcmd. >> >> +config EFI_CAPSULE_BOARD_INSECURE >> + bool "Permit insecure capsule-on-disk support" >> + depends on EFI_HAVE_CAPSULE_SUPPORT >> + default y >> + help >> + Permit insecure capsule update support and emit a warning (info >> level) >> + when applying capsule updates, indicating that the configuration is >> + insecure and including a link to the capsule update porting guide >> in >> + U-Boot docs. Disabling this option removes the warning. A developer >> + configuration doesn't need to be secure, but before making a >> product >> + from
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
Am 13. Juni 2024 21:05:58 MESZ schrieb Simon Glass : >Hi Heinrich, > >On Thu, 13 Jun 2024 at 11:32, Heinrich Schuchardt wrote: >> >> On 13.06.24 18:59, Simon Glass wrote: >> > Hi Tom, >> > >> > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: >> >> >> >> On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: >> >>> Hi Tom, >> >>> >> >>> On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: >> >> On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: >> > Hi Tom, >> > >> > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: >> >> >> >> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: >> >> >> >> [snip] >> >>> Also IMO there is only really one LMB list today. We create it at the >> >>> start of bootm and then it is done when we boot. The file-loading >> >>> stuff is what makes all this confusing...and with bootstd that is >> >>> under control as well. >> >>> >> >>> At lot of this effort seems to be about dealing with random scripts >> >>> which load things. We want to make sure we complain if something >> >>> overlaps. But we should be making the bootstd case work nicely and >> >>> doing things within that framework. Also EFI sort-of has its own >> >>> thing, which it is very-much in control of. >> >>> >> >>> Overall I think this is a bit more subtle that just combining >> >>> allocators. >> >> >> >> I think this gets to the main misunderstanding. The problem isn't >> >> handling bootstd, or EFI boot, or even assorted scripts. Those are all >> >> cases where things are otherwise (sufficiently) well-defined. The >> >> problem is "security" and that a "carefully crafted payload" could do >> >> something malicious. That's why we have to do all of this stuff sooner >> >> rather than later in our boot process. >> > >> > That's the first I have heard of this, actually, but a bit more detail >> > would help. How does the payload get loaded? I'm just not sure about >> > the overall goals. It seems that everyone else is already familiar - >> > can someone please take the time to point me to the details? >> >> Well, the short version I believe of the first CVE we got (and so >> started abusing LMB) was along the lines of "load an image near where >> the U-Boot stack is, smash things for fun and exploits". >> >>> >> >>> OK. I am surprised that LMB does not catch that. It is supposed to add >> >>> the stack and various other things right at the start before loading >> >>> any file. So even if it clears the LMB each time, it should not be >> >>> able to do that. Having said this, the code may be buggy as I don't >> >>> think we have tests for U-Boot's overall functional behaviour in these >> >>> situations. >> >> >> >> Right, LMB does catch the example I gave (because we made all of the >> >> load from storage/network functions init an lmb and we always make sure >> >> a new lmb gets U-Boot stack/etc). The next thing we didn't catch was >> >> "what if EFI does the loading?" and we've kludged around that, and in >> >> turn had some of the thorny questions. Some of that is what I think >> >> you're asking about in this part of the thread, to which the answer is >> >> "EFI spec says you need to place X in memory", so we just need to >> >> reserve it when it's asked for, so that something else can't come along >> >> and smash it maliciously. >> > >> > OK I see. Of course it isn't just EFI that has this issue. I believe >> > the answer (for small blocks) is to use malloc(), which I think we do >> > with a few exceptions which Ilias pointed out. For things like the TPM >> > log and ACPI tables we should probably use a bloblist, as we do on >> > x86. For large things (like loading a kernel) we should use LMB. I've >> > been thinking about how best to tie this to boot, as opposed to random >> > allocations in U-Boot itself, which would lead to fragmentation and >> > strange behaviour. I think bootstd is a great place to have a >> > persistent LMB. It can be attached to bootstd_priv. >> > >> > My hope is that EFI is just another boot method, where >> > already-allocating things are presented to the OS. Apart from the >> > Ilias exceptions, I believe this is how it works today. >> > >> > Where I think this heads in the wrong direction is using >> > EFI-allocation functions before we are booting an EFI image. EFI has >> > no concept of what is 'in empty space' so it leads to the lmb >> > conflict, the subject of this discussion. >> >> EFI binaries can return to the command line interface. >> EFI binaries may be drivers that stay resident and run in the background >> after returning to the command line interface. They might for instance >> provide block devices. > >Hmm you mentioned that before but I'm still not quite understanding. >Do you mean that the EFI app returns back to U-Boot, leaving the There are 3 types of of EFI binaries: * apps * boot time
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
On Thu, Jun 13, 2024 at 10:59:48AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > > > > On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > > > > > > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > > > > > > > > > > > > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > > > > > > > > > > > > [snip] > > > > > > > Also IMO there is only really one LMB list today. We create it at > > > > > > > the > > > > > > > start of bootm and then it is done when we boot. The file-loading > > > > > > > stuff is what makes all this confusing...and with bootstd that is > > > > > > > under control as well. > > > > > > > > > > > > > > At lot of this effort seems to be about dealing with random > > > > > > > scripts > > > > > > > which load things. We want to make sure we complain if something > > > > > > > overlaps. But we should be making the bootstd case work nicely and > > > > > > > doing things within that framework. Also EFI sort-of has its own > > > > > > > thing, which it is very-much in control of. > > > > > > > > > > > > > > Overall I think this is a bit more subtle that just combining > > > > > > > allocators. > > > > > > > > > > > > I think this gets to the main misunderstanding. The problem isn't > > > > > > handling bootstd, or EFI boot, or even assorted scripts. Those are > > > > > > all > > > > > > cases where things are otherwise (sufficiently) well-defined. The > > > > > > problem is "security" and that a "carefully crafted payload" could > > > > > > do > > > > > > something malicious. That's why we have to do all of this stuff > > > > > > sooner > > > > > > rather than later in our boot process. > > > > > > > > > > That's the first I have heard of this, actually, but a bit more detail > > > > > would help. How does the payload get loaded? I'm just not sure about > > > > > the overall goals. It seems that everyone else is already familiar - > > > > > can someone please take the time to point me to the details? > > > > > > > > Well, the short version I believe of the first CVE we got (and so > > > > started abusing LMB) was along the lines of "load an image near where > > > > the U-Boot stack is, smash things for fun and exploits". > > > > > > OK. I am surprised that LMB does not catch that. It is supposed to add > > > the stack and various other things right at the start before loading > > > any file. So even if it clears the LMB each time, it should not be > > > able to do that. Having said this, the code may be buggy as I don't > > > think we have tests for U-Boot's overall functional behaviour in these > > > situations. > > > > Right, LMB does catch the example I gave (because we made all of the > > load from storage/network functions init an lmb and we always make sure > > a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > > "what if EFI does the loading?" and we've kludged around that, and in > > turn had some of the thorny questions. Some of that is what I think > > you're asking about in this part of the thread, to which the answer is > > "EFI spec says you need to place X in memory", so we just need to > > reserve it when it's asked for, so that something else can't come along > > and smash it maliciously. > > OK I see. Of course it isn't just EFI that has this issue. I believe > the answer (for small blocks) is to use malloc(), which I think we do > with a few exceptions which Ilias pointed out. For things like the TPM > log and ACPI tables we should probably use a bloblist, as we do on > x86. For large things (like loading a kernel) we should use LMB. I've > been thinking about how best to tie this to boot, as opposed to random > allocations in U-Boot itself, which would lead to fragmentation and > strange behaviour. I think bootstd is a great place to have a > persistent LMB. It can be attached to bootstd_priv. > > My hope is that EFI is just another boot method, where > already-allocating things are presented to the OS. Apart from the > Ilias exceptions, I believe this is how it works today. > > Where I think this heads in the wrong direction is using > EFI-allocation functions before we are booting an EFI image. EFI has > no concept of what is 'in empty space' so it leads to the lmb > conflict, the subject of this discussion. > > This is all quite subtle and probably worthy of a VC discussion. But it's not tied to "boot". Again, the problems are with potential malicious actions. So if we're in some function that says "I need to claim $THIS range", it needs check in with the reservation system so that it can be told "Sorry, already reserved" if needed. It's not a good idea for $subsystem to say it needs $THIS range, but then we don't make the reservation until later because someone could have acted in there in the interim. I
Re: [PATCH v2 1/5] boot: android: Provide vendor_bootimg_addr in boot_get_fdt()
Hi,
Le 13/06/2024 à 12:13, Mattijs Korpershoek a écrit :
When calling android_image_get_dtb_by_index() using boot image v3+,
we should also pass the vendor_boot ramdisk address.
Use get_avendor_bootimg_addr() to do so.
Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
returns -1.
for legacy implementations that don't have CMD_ABOOTIMG, add a weak
implementation to avoid linking errors.
Signed-off-by: Mattijs Korpershoek
---
boot/image-android.c | 5 +
boot/image-fdt.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/boot/image-android.c b/boot/image-android.c
index ee626972c114..09c7a44e058a 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -56,6 +56,11 @@ static ulong add_trailer(ulong bootconfig_start_addr, ulong
bootconfig_size)
return BOOTCONFIG_TRAILER_SIZE;
}
+__weak ulong get_avendor_bootimg_addr(void)
+{
+ return -1;
+}
+
static void android_boot_image_v3_v4_parse_hdr(const struct
andr_boot_img_hdr_v3 *hdr,
struct andr_image_data *data)
{
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 56dd7687f51c..8332792b8e80 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -502,7 +502,7 @@ int boot_get_fdt(void *buf, const char *select, uint arch,
* Firstly check if this android boot image has dtb field.
*/
dtb_idx = (u32)env_get_ulong("adtb_idx", 10, 0);
- if (android_image_get_dtb_by_index((ulong)hdr, 0,
+ if (android_image_get_dtb_by_index((ulong)hdr,
get_avendor_bootimg_addr(),
dtb_idx, _addr,
_size)) {
fdt_blob = (char *)map_sysmem(fdt_addr, 0);
if (fdt_check_header(fdt_blob))
Reviewed-by: Guillaume La Roque
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
Hi Sughosh, On Thu, 13 Jun 2024 at 12:17, Sughosh Ganu wrote: > > On Thu, 13 Jun 2024 at 22:57, Heinrich Schuchardt wrote: > > > > On 13.06.24 18:59, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > > >> > > >> On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > > >>> Hi Tom, > > >>> > > >>> On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > > >> > > >> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > > >> > > >> [snip] > > >>> Also IMO there is only really one LMB list today. We create it at > > >>> the > > >>> start of bootm and then it is done when we boot. The file-loading > > >>> stuff is what makes all this confusing...and with bootstd that is > > >>> under control as well. > > >>> > > >>> At lot of this effort seems to be about dealing with random scripts > > >>> which load things. We want to make sure we complain if something > > >>> overlaps. But we should be making the bootstd case work nicely and > > >>> doing things within that framework. Also EFI sort-of has its own > > >>> thing, which it is very-much in control of. > > >>> > > >>> Overall I think this is a bit more subtle that just combining > > >>> allocators. > > >> > > >> I think this gets to the main misunderstanding. The problem isn't > > >> handling bootstd, or EFI boot, or even assorted scripts. Those are > > >> all > > >> cases where things are otherwise (sufficiently) well-defined. The > > >> problem is "security" and that a "carefully crafted payload" could do > > >> something malicious. That's why we have to do all of this stuff > > >> sooner > > >> rather than later in our boot process. > > > > > > That's the first I have heard of this, actually, but a bit more detail > > > would help. How does the payload get loaded? I'm just not sure about > > > the overall goals. It seems that everyone else is already familiar - > > > can someone please take the time to point me to the details? > > > > Well, the short version I believe of the first CVE we got (and so > > started abusing LMB) was along the lines of "load an image near where > > the U-Boot stack is, smash things for fun and exploits". > > >>> > > >>> OK. I am surprised that LMB does not catch that. It is supposed to add > > >>> the stack and various other things right at the start before loading > > >>> any file. So even if it clears the LMB each time, it should not be > > >>> able to do that. Having said this, the code may be buggy as I don't > > >>> think we have tests for U-Boot's overall functional behaviour in these > > >>> situations. > > >> > > >> Right, LMB does catch the example I gave (because we made all of the > > >> load from storage/network functions init an lmb and we always make sure > > >> a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > > >> "what if EFI does the loading?" and we've kludged around that, and in > > >> turn had some of the thorny questions. Some of that is what I think > > >> you're asking about in this part of the thread, to which the answer is > > >> "EFI spec says you need to place X in memory", so we just need to > > >> reserve it when it's asked for, so that something else can't come along > > >> and smash it maliciously. > > > > > > OK I see. Of course it isn't just EFI that has this issue. I believe > > > the answer (for small blocks) is to use malloc(), which I think we do > > > with a few exceptions which Ilias pointed out. For things like the TPM > > > log and ACPI tables we should probably use a bloblist, as we do on > > > x86. For large things (like loading a kernel) we should use LMB. I've > > > been thinking about how best to tie this to boot, as opposed to random > > > allocations in U-Boot itself, which would lead to fragmentation and > > > strange behaviour. I think bootstd is a great place to have a > > > persistent LMB. It can be attached to bootstd_priv. > > > > > > My hope is that EFI is just another boot method, where > > > already-allocating things are presented to the OS. Apart from the > > > Ilias exceptions, I believe this is how it works today. > > > > > > Where I think this heads in the wrong direction is using > > > EFI-allocation functions before we are booting an EFI image. EFI has > > > no concept of what is 'in empty space' so it leads to the lmb > > > conflict, the subject of this discussion. > > > > EFI binaries can return to the command line interface. > > EFI binaries may be drivers that stay resident and run in the background > > after returning to the command line interface. They might for instance > > provide block devices. > > > > Device-paths must be created from EFI pool memory as they may be freed > >
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
Hi Heinrich, On Thu, 13 Jun 2024 at 11:32, Heinrich Schuchardt wrote: > > On 13.06.24 18:59, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > >> > >> On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > >>> Hi Tom, > >>> > >>> On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > >> > >> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > >> > >> [snip] > >>> Also IMO there is only really one LMB list today. We create it at the > >>> start of bootm and then it is done when we boot. The file-loading > >>> stuff is what makes all this confusing...and with bootstd that is > >>> under control as well. > >>> > >>> At lot of this effort seems to be about dealing with random scripts > >>> which load things. We want to make sure we complain if something > >>> overlaps. But we should be making the bootstd case work nicely and > >>> doing things within that framework. Also EFI sort-of has its own > >>> thing, which it is very-much in control of. > >>> > >>> Overall I think this is a bit more subtle that just combining > >>> allocators. > >> > >> I think this gets to the main misunderstanding. The problem isn't > >> handling bootstd, or EFI boot, or even assorted scripts. Those are all > >> cases where things are otherwise (sufficiently) well-defined. The > >> problem is "security" and that a "carefully crafted payload" could do > >> something malicious. That's why we have to do all of this stuff sooner > >> rather than later in our boot process. > > > > That's the first I have heard of this, actually, but a bit more detail > > would help. How does the payload get loaded? I'm just not sure about > > the overall goals. It seems that everyone else is already familiar - > > can someone please take the time to point me to the details? > > Well, the short version I believe of the first CVE we got (and so > started abusing LMB) was along the lines of "load an image near where > the U-Boot stack is, smash things for fun and exploits". > >>> > >>> OK. I am surprised that LMB does not catch that. It is supposed to add > >>> the stack and various other things right at the start before loading > >>> any file. So even if it clears the LMB each time, it should not be > >>> able to do that. Having said this, the code may be buggy as I don't > >>> think we have tests for U-Boot's overall functional behaviour in these > >>> situations. > >> > >> Right, LMB does catch the example I gave (because we made all of the > >> load from storage/network functions init an lmb and we always make sure > >> a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > >> "what if EFI does the loading?" and we've kludged around that, and in > >> turn had some of the thorny questions. Some of that is what I think > >> you're asking about in this part of the thread, to which the answer is > >> "EFI spec says you need to place X in memory", so we just need to > >> reserve it when it's asked for, so that something else can't come along > >> and smash it maliciously. > > > > OK I see. Of course it isn't just EFI that has this issue. I believe > > the answer (for small blocks) is to use malloc(), which I think we do > > with a few exceptions which Ilias pointed out. For things like the TPM > > log and ACPI tables we should probably use a bloblist, as we do on > > x86. For large things (like loading a kernel) we should use LMB. I've > > been thinking about how best to tie this to boot, as opposed to random > > allocations in U-Boot itself, which would lead to fragmentation and > > strange behaviour. I think bootstd is a great place to have a > > persistent LMB. It can be attached to bootstd_priv. > > > > My hope is that EFI is just another boot method, where > > already-allocating things are presented to the OS. Apart from the > > Ilias exceptions, I believe this is how it works today. > > > > Where I think this heads in the wrong direction is using > > EFI-allocation functions before we are booting an EFI image. EFI has > > no concept of what is 'in empty space' so it leads to the lmb > > conflict, the subject of this discussion. > > EFI binaries can return to the command line interface. > EFI binaries may be drivers that stay resident and run in the background > after returning to the command line interface. They might for instance > provide block devices. Hmm you mentioned that before but I'm still not quite understanding. Do you mean that the EFI app returns back to U-Boot, leaving the driver active? If so, how does U-Boot use the driver? I'm just not familiar with how such a construct could work in a single-threaded U-Boot. > > Device-paths must be created from EFI pool memory as they may be
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
On 13.06.24 18:59, Simon Glass wrote: Hi Tom, On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: Hi Tom, On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: Hi Tom, On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: [snip] Also IMO there is only really one LMB list today. We create it at the start of bootm and then it is done when we boot. The file-loading stuff is what makes all this confusing...and with bootstd that is under control as well. At lot of this effort seems to be about dealing with random scripts which load things. We want to make sure we complain if something overlaps. But we should be making the bootstd case work nicely and doing things within that framework. Also EFI sort-of has its own thing, which it is very-much in control of. Overall I think this is a bit more subtle that just combining allocators. I think this gets to the main misunderstanding. The problem isn't handling bootstd, or EFI boot, or even assorted scripts. Those are all cases where things are otherwise (sufficiently) well-defined. The problem is "security" and that a "carefully crafted payload" could do something malicious. That's why we have to do all of this stuff sooner rather than later in our boot process. That's the first I have heard of this, actually, but a bit more detail would help. How does the payload get loaded? I'm just not sure about the overall goals. It seems that everyone else is already familiar - can someone please take the time to point me to the details? Well, the short version I believe of the first CVE we got (and so started abusing LMB) was along the lines of "load an image near where the U-Boot stack is, smash things for fun and exploits". OK. I am surprised that LMB does not catch that. It is supposed to add the stack and various other things right at the start before loading any file. So even if it clears the LMB each time, it should not be able to do that. Having said this, the code may be buggy as I don't think we have tests for U-Boot's overall functional behaviour in these situations. Right, LMB does catch the example I gave (because we made all of the load from storage/network functions init an lmb and we always make sure a new lmb gets U-Boot stack/etc). The next thing we didn't catch was "what if EFI does the loading?" and we've kludged around that, and in turn had some of the thorny questions. Some of that is what I think you're asking about in this part of the thread, to which the answer is "EFI spec says you need to place X in memory", so we just need to reserve it when it's asked for, so that something else can't come along and smash it maliciously. OK I see. Of course it isn't just EFI that has this issue. I believe the answer (for small blocks) is to use malloc(), which I think we do with a few exceptions which Ilias pointed out. For things like the TPM log and ACPI tables we should probably use a bloblist, as we do on x86. For large things (like loading a kernel) we should use LMB. I've been thinking about how best to tie this to boot, as opposed to random allocations in U-Boot itself, which would lead to fragmentation and strange behaviour. I think bootstd is a great place to have a persistent LMB. It can be attached to bootstd_priv. My hope is that EFI is just another boot method, where already-allocating things are presented to the OS. Apart from the Ilias exceptions, I believe this is how it works today. Where I think this heads in the wrong direction is using EFI-allocation functions before we are booting an EFI image. EFI has no concept of what is 'in empty space' so it leads to the lmb conflict, the subject of this discussion. EFI binaries can return to the command line interface. EFI binaries may be drivers that stay resident and run in the background after returning to the command line interface. They might for instance provide block devices. Device-paths must be created from EFI pool memory as they may be freed via FreePool() according to the EFI specification. And these we create whenever a block-device is probed. We should not make any assumptions that conflict with the UEFI specification. In our initial discussion with Ilias one idea was to merge LMB and EFI memory management. This merged system would have to consider the requirements of the UEFI specifications like a finer grained memory type system and page boundaries. Best regards Heinrich This is all quite subtle and probably worthy of a VC discussion. But that also raised the more general problem, and why we need a persistent reservation list, of allowing boards/SoCs to say they want to reserve a block of memory for whatever, and have that obeyed, for real. For example, the mach-apple logic of "just pick some memory locations to use for kernel/dtb/initrd" isn't really as safe as it should be since those
Re: [PATCH v2 3/5] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
Le 13/06/2024 à 12:13, Mattijs Korpershoek a écrit :
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk
Signed-off-by: Mattijs Korpershoek
---
cmd/abootimg.c | 10 ++
include/image.h | 14 ++
2 files changed, 24 insertions(+)
diff --git a/cmd/abootimg.c b/cmd/abootimg.c
index 327712a536c0..ae7a1a7c83b0 100644
--- a/cmd/abootimg.c
+++ b/cmd/abootimg.c
@@ -22,6 +22,11 @@ ulong get_abootimg_addr(void)
return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
}
+void set_abootimg_addr(ulong addr)
+{
+ _abootimg_addr = addr;
+}
+
ulong get_ainit_bootimg_addr(void)
{
return _ainit_bootimg_addr;
@@ -32,6 +37,11 @@ ulong get_avendor_bootimg_addr(void)
return _avendor_bootimg_addr;
}
+void set_avendor_bootimg_addr(ulong addr)
+{
+ _avendor_bootimg_addr = addr;
+}
+
static int abootimg_get_ver(int argc, char *const argv[])
{
const struct andr_boot_img_hdr_v0 *hdr;
diff --git a/include/image.h b/include/image.h
index c5b288f62b44..df2decbf5c2a 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1970,6 +1970,13 @@ bool is_android_vendor_boot_image_header(const void
*vendor_boot_img);
*/
ulong get_abootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android boot image address
+ *
+ * Return: no returned results
+ */
+void set_abootimg_addr(ulong addr);
+
/**
* get_ainit_bootimg_addr() - Get Android init boot image address
*
@@ -1984,6 +1991,13 @@ ulong get_ainit_bootimg_addr(void);
*/
ulong get_avendor_bootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android vendor boot image address
+ *
+ * Return: no returned results
+ */
+void set_avendor_bootimg_addr(ulong addr);
+
/**
* board_fit_config_name_match() - Check for a matching board name
*
Reviewed-by: Guillaume La Roque
Re: [PATCH v2 2/5] bootstd: Add bootflow_iter_check_mmc() helper
Le 13/06/2024 à 12:13, Mattijs Korpershoek a écrit :
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk
Signed-off-by: Mattijs Korpershoek
---
boot/bootflow.c| 12
include/bootflow.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 9aa3179c3881..59d77d2385f4 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -575,6 +575,18 @@ int bootflow_iter_check_blk(const struct bootflow_iter
*iter)
return -ENOTSUPP;
}
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter)
+{
+ const struct udevice *media = dev_get_parent(iter->dev);
+ enum uclass_id id = device_get_uclass_id(media);
+
+ log_debug("uclass %d: %s\n", id, uclass_get_name(id));
+ if (id == UCLASS_MMC)
+ return 0;
+
+ return -ENOTSUPP;
+}
+
int bootflow_iter_check_sf(const struct bootflow_iter *iter)
{
const struct udevice *media = dev_get_parent(iter->dev);
diff --git a/include/bootflow.h b/include/bootflow.h
index 080ee8501225..6058ddd89b16 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -407,6 +407,15 @@ void bootflow_remove(struct bootflow *bflow);
*/
int bootflow_iter_check_blk(const struct bootflow_iter *iter);
+/**
+ * bootflow_iter_check_mmc() - Check that a bootflow uses a MMC device
+ *
+ * This checks the bootdev in the bootflow to make sure it uses a mmc device
+ *
+ * Return: 0 if OK, -ENOTSUPP if some other device is used (e.g. ethernet)
+ */
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter);
+
/**
* bootflow_iter_check_sf() - Check that a bootflow uses SPI FLASH
*
Reviewed-by: Guillaume La Roque
Re: [PATCH] Fix typo in NVME show command
On Fri, May 31, 2024 at 06:48:34AM +, Thomas Perl wrote: > Foramt -> Format > > Signed-off-by: Thomas Perl Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: silent u-boot not working
Hi Jonas, On 6/13/24 09:16, Jonas Kvinge wrote: > Hi, > > I'm running openSUSE Tumbleweed on an RPI CM4, I'm trying to silence u- > boot boot messages, with the default configuration there is an u-boot > logo on the top right corner and boot text, I'd like to get rid of the > logo and all text if possible. > The keyboard is not working before the Linux kernel is loaded, so I can > not interrupt u-boot and enter any commands, so where should I put "set > env silent 1"? > > I've followed the guide on > > I have built u-boot from source using `make rpi_4_defconfig` > configuration modified the configuration with make menuconfig, and > verified this in .config before builing. > CONFIG_SILENT_CONSOLE=y > CONFIG_SILENT_U_BOOT_ONLY=y > CONFIG_SILENT_CONSOLE_UPDATE_ON_SET=y > CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC=y > CONFIG_SILENT_CONSOLE_UNTIL_ENV=y > > Copied the binary to /boot/efi/u-boot.bin and /boot/vc/u-boot.bin > > I've also tried to define CONFIG_EXTRA_ENV_SETTINGS in > include/configs/rpi.h according to: > and rebuilt and copied to binary again, still not working. > > The text and logo is still present during boot, what am I doing wrong > here? I implemented a silent console recently. Here are the steps I took: - Define CONFIG_DISABLE_CONSOLE - set silent=y in the default environment (CONFIG_EXTRA_ENV_SETTINGS) You can still enable the console by pressing any key at the (invisible) prompt. Let me know if that works for you. --Sean
Re: [PATCH v2 1/5] boot: android: Provide vendor_bootimg_addr in boot_get_fdt()
On Thu, Jun 13, 2024 at 12:13 PM Mattijs Korpershoek
wrote:
>
> When calling android_image_get_dtb_by_index() using boot image v3+,
> we should also pass the vendor_boot ramdisk address.
>
> Use get_avendor_bootimg_addr() to do so.
>
> Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
>returns -1.
>for legacy implementations that don't have CMD_ABOOTIMG, add a weak
>implementation to avoid linking errors.
>
> Signed-off-by: Mattijs Korpershoek
> ---
> boot/image-android.c | 5 +
> boot/image-fdt.c | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index ee626972c114..09c7a44e058a 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -56,6 +56,11 @@ static ulong add_trailer(ulong bootconfig_start_addr,
> ulong bootconfig_size)
> return BOOTCONFIG_TRAILER_SIZE;
> }
>
> +__weak ulong get_avendor_bootimg_addr(void)
> +{
> + return -1;
> +}
> +
> static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3 *hdr,
>struct andr_image_data *data)
> {
> diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> index 56dd7687f51c..8332792b8e80 100644
> --- a/boot/image-fdt.c
> +++ b/boot/image-fdt.c
> @@ -502,7 +502,7 @@ int boot_get_fdt(void *buf, const char *select, uint arch,
> * Firstly check if this android boot image has dtb field.
> */
> dtb_idx = (u32)env_get_ulong("adtb_idx", 10, 0);
> - if (android_image_get_dtb_by_index((ulong)hdr, 0,
> + if (android_image_get_dtb_by_index((ulong)hdr,
> get_avendor_bootimg_addr(),
>dtb_idx, _addr,
> _size)) {
> fdt_blob = (char *)map_sysmem(fdt_addr, 0);
> if (fdt_check_header(fdt_blob))
>
> --
> 2.45.2
>
Reviewed-by: Igor Opaniuk
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
Re: [PATCH v2 1/5] boot: android: Provide vendor_bootimg_addr in boot_get_fdt()
On Thu 13 Jun 2024 at 17:42, Mattijs Korpershoek
wrote:
> When calling android_image_get_dtb_by_index() using boot image v3+,
> we should also pass the vendor_boot ramdisk address.
>
> Use get_avendor_bootimg_addr() to do so.
>
> Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
>returns -1.
>for legacy implementations that don't have CMD_ABOOTIMG, add a weak
>implementation to avoid linking errors.
>
> Signed-off-by: Mattijs Korpershoek
> ---
> boot/image-android.c | 5 +
> boot/image-fdt.c | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index ee626972c114..09c7a44e058a 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -56,6 +56,11 @@ static ulong add_trailer(ulong bootconfig_start_addr,
> ulong bootconfig_size)
> return BOOTCONFIG_TRAILER_SIZE;
> }
>
> +__weak ulong get_avendor_bootimg_addr(void)
> +{
> + return -1;
> +}
> +
> static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3 *hdr,
> struct andr_image_data *data)
> {
> diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> index 56dd7687f51c..8332792b8e80 100644
> --- a/boot/image-fdt.c
> +++ b/boot/image-fdt.c
> @@ -502,7 +502,7 @@ int boot_get_fdt(void *buf, const char *select, uint arch,
>* Firstly check if this android boot image has dtb field.
>*/
> dtb_idx = (u32)env_get_ulong("adtb_idx", 10, 0);
> - if (android_image_get_dtb_by_index((ulong)hdr, 0,
> + if (android_image_get_dtb_by_index((ulong)hdr,
> get_avendor_bootimg_addr(),
> dtb_idx, _addr,
> _size)) {
> fdt_blob = (char *)map_sysmem(fdt_addr, 0);
> if (fdt_check_header(fdt_blob))
>
> --
> 2.45.2
>
Reviewed-by: Julien Masson
--
Julien Masson
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
Hi Tom, On Thu, 13 Jun 2024 at 09:42, Tom Rini wrote: > > On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > > > > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > > > > > > > > > > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > > > > > > > > > > [snip] > > > > > > Also IMO there is only really one LMB list today. We create it at > > > > > > the > > > > > > start of bootm and then it is done when we boot. The file-loading > > > > > > stuff is what makes all this confusing...and with bootstd that is > > > > > > under control as well. > > > > > > > > > > > > At lot of this effort seems to be about dealing with random scripts > > > > > > which load things. We want to make sure we complain if something > > > > > > overlaps. But we should be making the bootstd case work nicely and > > > > > > doing things within that framework. Also EFI sort-of has its own > > > > > > thing, which it is very-much in control of. > > > > > > > > > > > > Overall I think this is a bit more subtle that just combining > > > > > > allocators. > > > > > > > > > > I think this gets to the main misunderstanding. The problem isn't > > > > > handling bootstd, or EFI boot, or even assorted scripts. Those are all > > > > > cases where things are otherwise (sufficiently) well-defined. The > > > > > problem is "security" and that a "carefully crafted payload" could do > > > > > something malicious. That's why we have to do all of this stuff sooner > > > > > rather than later in our boot process. > > > > > > > > That's the first I have heard of this, actually, but a bit more detail > > > > would help. How does the payload get loaded? I'm just not sure about > > > > the overall goals. It seems that everyone else is already familiar - > > > > can someone please take the time to point me to the details? > > > > > > Well, the short version I believe of the first CVE we got (and so > > > started abusing LMB) was along the lines of "load an image near where > > > the U-Boot stack is, smash things for fun and exploits". > > > > OK. I am surprised that LMB does not catch that. It is supposed to add > > the stack and various other things right at the start before loading > > any file. So even if it clears the LMB each time, it should not be > > able to do that. Having said this, the code may be buggy as I don't > > think we have tests for U-Boot's overall functional behaviour in these > > situations. > > Right, LMB does catch the example I gave (because we made all of the > load from storage/network functions init an lmb and we always make sure > a new lmb gets U-Boot stack/etc). The next thing we didn't catch was > "what if EFI does the loading?" and we've kludged around that, and in > turn had some of the thorny questions. Some of that is what I think > you're asking about in this part of the thread, to which the answer is > "EFI spec says you need to place X in memory", so we just need to > reserve it when it's asked for, so that something else can't come along > and smash it maliciously. OK I see. Of course it isn't just EFI that has this issue. I believe the answer (for small blocks) is to use malloc(), which I think we do with a few exceptions which Ilias pointed out. For things like the TPM log and ACPI tables we should probably use a bloblist, as we do on x86. For large things (like loading a kernel) we should use LMB. I've been thinking about how best to tie this to boot, as opposed to random allocations in U-Boot itself, which would lead to fragmentation and strange behaviour. I think bootstd is a great place to have a persistent LMB. It can be attached to bootstd_priv. My hope is that EFI is just another boot method, where already-allocating things are presented to the OS. Apart from the Ilias exceptions, I believe this is how it works today. Where I think this heads in the wrong direction is using EFI-allocation functions before we are booting an EFI image. EFI has no concept of what is 'in empty space' so it leads to the lmb conflict, the subject of this discussion. This is all quite subtle and probably worthy of a VC discussion. > > But that also raised the more general problem, and why we need a > persistent reservation list, of allowing boards/SoCs to say they want to > reserve a block of memory for whatever, and have that obeyed, for real. > For example, the mach-apple logic of "just pick some memory locations to > use for kernel/dtb/initrd" isn't really as safe as it should be since > those reservations aren't really seen anywhere once the function > returns, it's just setting some environment variables. Yes, that part of it I understand. Somehow I either didn't see or forgot that board_late_init() code. With the script-based boot it makes some sort of sense, but with bootstd we should have allocation of addresses dealt with there. I
Re: [PATCH 14/20] CI: GitLab: Split build_world tasks
On Wed, Jun 12, 2024 at 02:24:24PM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 12 Jun 2024 at 11:07, Tom Rini wrote: > > > > On Wed, Jun 12, 2024 at 05:14:46PM +0100, Jiaxun Yang wrote: > > > > > > > > > 在2024年6月12日六月 下午5:01，Tom Rini写道： > > > > On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote: > > > > > > > >> Current build_world task runs for too long on public gitlab > > > >> runner. > > > >> > > > >> Split the job as what we've done to azure pipeline. > > > >> > > > >> Signed-off-by: Jiaxun Yang > > > >> --- > > > >> .gitlab-ci.yml | 103 > > > >> + > > > >> 1 file changed, 59 insertions(+), 44 deletions(-) > > > > > > > > I don't like this. The list in Azure is because of the time limits there > > > > and in turn we: > > > > a) Have to tweak it periodically to keep things from running too long > > > > b) Have to tweak it to ensure that we don't miss some new SoC/etc > > > > > > Then it will render running CI test on gitlab.com impossible again :-( > > > > Yeah, it's not something I'm the happiest with. Looking around a bit, I > > see a blog post that talks about dealing with dynamic variables, in > > Azure. So we could, I think, figure out some logic to have each build > > stage say what platforms it covers. And then have a final step that > > compares all of the platforms built vs the global list (just > > tools/buildman/buildman --dry-run -v) to make sure nothing was missed. > > With something like that, and assuming GitLab can do it too (it probably > > can), I'm OK with having the world build be broken down to 10 groups > > (maximum number of parallel jobs in Azure CI for free) since we'll know > > if we miss something too. > > > > So lets set this patch (and the doc update) aside for now, unless you > > want to look at the above. I'll look at the above soon. > > Could we hook up one of our machines as a public runner somehow? It's a pool of free runners, ala Azure. I don't think we can, no, and I don't want to make all of our runners available on public CI either, they're a bit over-whelmed as it is I think once custodians start working. -- Tom signature.asc Description: PGP signature
Re: [PATCH] efi: capsule: Improve capsule update porting to new boards
Hi Jon, On Sat, 8 Jun 2024 at 02:44, Jonathan Humphreys wrote: > > Add to the capsule update porting documentation that when capsule > authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), a public key > certificate corresponding to the capsule signing key must be specified. > > Also add a config (EFI_CAPSULE_BOARD_INSECURE) that is set by default and > causes a warning (info level) alerting a developer to consult this porting > section to ensure the capsule update capability is secure for the platform. > Once this section has been reviewed and confidence is established in the > security of the capsule update implementation for this board, deselecting > the EFI_CAPSULE_BOARD_INSECURE config will remove the warning. > > This config is to balance the desire to provide a reference implementation > in upstream for capsule authentication but also provide some safeguards > to prevent developers from overlooking the need to properly secure their > implementation. > > Signed-off-by: Jonathan Humphreys > --- > doc/develop/uefi/uefi.rst| 30 +++--- > lib/efi_loader/Kconfig | 13 + > lib/efi_loader/efi_capsule.c | 5 + > 3 files changed, 41 insertions(+), 7 deletions(-) > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > index 985956ab85c..1c98c6e4ab4 100644 > --- a/doc/develop/uefi/uefi.rst > +++ b/doc/develop/uefi/uefi.rst > @@ -526,6 +526,7 @@ following command can be issued >--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \ >optee.bin optee.capsule > > +.. _Enabling Capsule Authentication: > > Enabling Capsule Authentication > *** > @@ -631,17 +632,32 @@ where version.dtso looks like:: > The properties of image-type-id and image-index must match the value > defined in the efi_fw_image array as image_type_id and image_index. > > -Porting Capsule Updates to new boards > -* > +Porting Capsule Update to new boards > + > > It is important, when using a reference board as a starting point for a > custom > board, that certain steps are taken to properly support Capsule Updates. > > -Capsule GUIDs need to be unique for each firmware and board. That is, if two > -firmwares are built from the same source but result in different binaries > -because they are built for different boards, they should have different > GUIDs. > -Therefore it is important when creating support for a new board, new GUIDs > are > -defined in the board's header file. *DO NOT* reuse capsule GUIDs. > +Capsule GUIDs need to be unique for each firmware and board. That is, even > +if two firmwares are built from the same source but result in different > +binaries because they are built for different boards, they should have > +different GUIDs. Therefore it is important when creating support for a new > +board, new GUIDs are defined in the board's header file. *DO NOT* reuse > +capsule GUIDs. > + > +When capsule authentication is enabled (via EFI_CAPSULE_AUTHENTICATE), it > +is also very important to set the public key certificate corresponding to > +the capsule signing key. See :ref:`Enabling Capsule Authentication` for > +more information on signing capsules. *DO NOT* reuse the certificate file > +from the reference board, which usually would be based on the development > +board keys. > + > +By default, the EFI_CAPSULE_BOARD_INSECURE config is set to true and causes > +a warning (info level) alerting a developer to consult this section to > +ensure the capsule update capability is secure for the platform. Once this > +section has been reviewed and confidence is established in the security of > +the capsule update implementation for this board, deselecting > +EFI_CAPSULE_BOARD_INSECURE config will remove the warning. > > Executing the boot manager > ~~ > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index 23079a5709d..f4b1a20ee40 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -236,6 +236,19 @@ config EFI_CAPSULE_ON_DISK_EARLY > executed as part of U-Boot initialisation so that they will > surely take place whatever is set to distro_bootcmd. > > +config EFI_CAPSULE_BOARD_INSECURE > + bool "Permit insecure capsule-on-disk support" > + depends on EFI_HAVE_CAPSULE_SUPPORT > + default y > + help > + Permit insecure capsule update support and emit a warning (info > level) > + when applying capsule updates, indicating that the configuration is > + insecure and including a link to the capsule update porting guide in > + U-Boot docs. Disabling this option removes the warning. A developer > + configuration doesn't need to be secure, but before making a product > + from the configuration, the intent is to developers alert of steps > that > + must be taken. > + > config EFI_CAPSULE_FIRMWARE >
Re: [PATCH] cmd: sound: fix help text
On Mon, 10 Jun 2024 18:11:44 +0200, Quentin Schulz wrote: > There's never been a -q or -s argument handled in the command, so let's > remove it. This was highlighted during review[1] but somehow still got > through. > > While at it, slightly "reword" in the help text how the len + freq > arguments are defined. Indeed, len and freq work in pair, it is possible > to define none of either, n of both, or n - 1 of freq if there are n > len, in which case the freq that goes with the last len would be the n - > 1 (and not the default of 400Hz if neither len nor freq is passed). I > assume this isn't what's expected but leaving it for another patch if > need be to fix what happens in that very odd scenario. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present
On Mon, Jun 10, 2024 at 02:43:17PM -0500, Sam Protsenko wrote: > On Tue, May 14, 2024 at 3:26 PM Sam Protsenko > wrote: > > > > On Wed, May 1, 2024 at 4:12 PM Sam Protsenko > > wrote: > > > > > > On Wed, Apr 10, 2024 at 9:53 PM Sean Anderson wrote: > > > > > > > > On 3/7/24 19:04, Sam Protsenko wrote: > > > > > Sometimes clocks provided to a consumer might not have .set_rate > > > > > operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag > > > > > set. In that case it's usually possible to find a parent up the tree > > > > > which is capable of setting the rate (div, pll, etc). Implement a > > > > > simple > > > > > lookup procedure for such cases, to traverse the clock tree until > > > > > .set_rate capable parent is found, and use that parent to actually > > > > > change the rate. The search will stop once the first .set_rate capable > > > > > clock is found, which is usually enough to handle most cases. > > > > > > > > > > Signed-off-by: Sam Protsenko > > > > > --- > > > > > > [snip] > > > > > > > > > > > Can you give an example of where this is needed? > > > > > > > > > > Sure. In my case it's needed for eMMC enablement on E850-96 board. > > > eMMC node in the device tree [1] is a gate clock > > > (CLK_GOUT_MMC_EMBD_SDCLKIN), so the MMC driver won't be able to change > > > its rate. But that clock actually has CLK_SET_RATE_PARENT flag set in > > > the clock driver [2]. So the right thing to do in this case (and > > > that's basically how it's done in Linux kernel too) is to traverse the > > > clock tree upwards, and try to find the parent capable to do .set_rate > > > (which is usually a divider clock), and use it to change the clock > > > rate. I'm working on exynos_dw_mmc driver [3] right now, making it use > > > CCF clocks, but I can't do that before this patch is applied. > > > > > > Grepping the U-Boot tree I can see the CLK_SET_RATE_PARENT flag is > > > also used in various IMX clock drivers and STM32MP13 clock driver. I > > > guess without this change those flags will be basically ignored. > > > > > > Thanks! > > > > > > > Hi Sean, > > > > Just wanted to check if you think my explanation above is ok and the > > patch can be applied? I'm finishing my new patch series for enabling > > MMC on E850-96, but this patch has to be applied first. > > > > Thanks! > > > > Hi Tom, > > Would it be reasonable to ask you to take care of this patch? It's > been ignored for 3 months now, but it's needed for eMMC enablement on > E850-96 board. Any comments at this point Sean? -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
On Thu, Jun 13, 2024 at 09:22:15AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > > > > > > > > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > > > > > > > > [snip] > > > > > Also IMO there is only really one LMB list today. We create it at the > > > > > start of bootm and then it is done when we boot. The file-loading > > > > > stuff is what makes all this confusing...and with bootstd that is > > > > > under control as well. > > > > > > > > > > At lot of this effort seems to be about dealing with random scripts > > > > > which load things. We want to make sure we complain if something > > > > > overlaps. But we should be making the bootstd case work nicely and > > > > > doing things within that framework. Also EFI sort-of has its own > > > > > thing, which it is very-much in control of. > > > > > > > > > > Overall I think this is a bit more subtle that just combining > > > > > allocators. > > > > > > > > I think this gets to the main misunderstanding. The problem isn't > > > > handling bootstd, or EFI boot, or even assorted scripts. Those are all > > > > cases where things are otherwise (sufficiently) well-defined. The > > > > problem is "security" and that a "carefully crafted payload" could do > > > > something malicious. That's why we have to do all of this stuff sooner > > > > rather than later in our boot process. > > > > > > That's the first I have heard of this, actually, but a bit more detail > > > would help. How does the payload get loaded? I'm just not sure about > > > the overall goals. It seems that everyone else is already familiar - > > > can someone please take the time to point me to the details? > > > > Well, the short version I believe of the first CVE we got (and so > > started abusing LMB) was along the lines of "load an image near where > > the U-Boot stack is, smash things for fun and exploits". > > OK. I am surprised that LMB does not catch that. It is supposed to add > the stack and various other things right at the start before loading > any file. So even if it clears the LMB each time, it should not be > able to do that. Having said this, the code may be buggy as I don't > think we have tests for U-Boot's overall functional behaviour in these > situations. Right, LMB does catch the example I gave (because we made all of the load from storage/network functions init an lmb and we always make sure a new lmb gets U-Boot stack/etc). The next thing we didn't catch was "what if EFI does the loading?" and we've kludged around that, and in turn had some of the thorny questions. Some of that is what I think you're asking about in this part of the thread, to which the answer is "EFI spec says you need to place X in memory", so we just need to reserve it when it's asked for, so that something else can't come along and smash it maliciously. But that also raised the more general problem, and why we need a persistent reservation list, of allowing boards/SoCs to say they want to reserve a block of memory for whatever, and have that obeyed, for real. For example, the mach-apple logic of "just pick some memory locations to use for kernel/dtb/initrd" isn't really as safe as it should be since those reservations aren't really seen anywhere once the function returns, it's just setting some environment variables. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] dm: typo prbing
On Sat, 08 Jun 2024 06:12:44 +0200, Heinrich Schuchardt wrote: > %s/prbing/probing/ > > Applied to u-boot/master, thanks! -- Tom
Re: [u-boot-test-hooks PATCH v2 1/2] Create a common file for test scripts
On Wed, Jun 12, 2024 at 07:15:11PM -0600, Simon Glass wrote: > The top part of each of the u-boot-test-* files is common. Put it in > a common script file to avoid duplication and to allow it to be > replaced for the Labgrid integration. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: Pull request efi-2024-07-rc5 for branch master
On Thu, Jun 13, 2024 at 01:37:31PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 1ebd659cf020843fd8e8ef90d85a66941cbab6ec: > > Merge tag 'u-boot-dfu-20240606' of > https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-06-06 08:24:15 > -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2024-07-rc5 > > for you to fetch changes up to f3b6228ef4ee6918a9e1ec1db399ede057308a13: > > doc/sphinx, test/py: Update requests module to 2.32.2 (2024-06-10 > 15:05:30 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21060 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/5] boot: android: Provide vendor_bootimg_addr in boot_get_fdt()
On Thu, 13 Jun 2024 at 04:13, Mattijs Korpershoek wrote: > > When calling android_image_get_dtb_by_index() using boot image v3+, > we should also pass the vendor_boot ramdisk address. > > Use get_avendor_bootimg_addr() to do so. > > Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr() >returns -1. >for legacy implementations that don't have CMD_ABOOTIMG, add a weak >implementation to avoid linking errors. > > Signed-off-by: Mattijs Korpershoek > --- > boot/image-android.c | 5 + > boot/image-fdt.c | 2 +- > 2 files changed, 6 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable
Hi Tom, On Wed, 12 Jun 2024 at 15:40, Tom Rini wrote: > > On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 12 Jun 2024 at 11:22, Tom Rini wrote: > > > > > > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote: > > > > > > [snip] > > > > Also IMO there is only really one LMB list today. We create it at the > > > > start of bootm and then it is done when we boot. The file-loading > > > > stuff is what makes all this confusing...and with bootstd that is > > > > under control as well. > > > > > > > > At lot of this effort seems to be about dealing with random scripts > > > > which load things. We want to make sure we complain if something > > > > overlaps. But we should be making the bootstd case work nicely and > > > > doing things within that framework. Also EFI sort-of has its own > > > > thing, which it is very-much in control of. > > > > > > > > Overall I think this is a bit more subtle that just combining > > > > allocators. > > > > > > I think this gets to the main misunderstanding. The problem isn't > > > handling bootstd, or EFI boot, or even assorted scripts. Those are all > > > cases where things are otherwise (sufficiently) well-defined. The > > > problem is "security" and that a "carefully crafted payload" could do > > > something malicious. That's why we have to do all of this stuff sooner > > > rather than later in our boot process. > > > > That's the first I have heard of this, actually, but a bit more detail > > would help. How does the payload get loaded? I'm just not sure about > > the overall goals. It seems that everyone else is already familiar - > > can someone please take the time to point me to the details? > > Well, the short version I believe of the first CVE we got (and so > started abusing LMB) was along the lines of "load an image near where > the U-Boot stack is, smash things for fun and exploits". OK. I am surprised that LMB does not catch that. It is supposed to add the stack and various other things right at the start before loading any file. So even if it clears the LMB each time, it should not be able to do that. Having said this, the code may be buggy as I don't think we have tests for U-Boot's overall functional behaviour in these situations. Regards, Simon
Re: [PATCH v2 3/5] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
On Thu, 13 Jun 2024 at 04:13, Mattijs Korpershoek wrote: > > The only way to configure the load addresses for both bootimg and > vendor_bootimg is by using the "abootimg" command. > If we want to use the C API, there is no equivalent. > > Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can > specify the load address from C. > > This can be useful for implementing an Android bootmethod. > > Reviewed-by: Igor Opaniuk > Signed-off-by: Mattijs Korpershoek > --- > cmd/abootimg.c | 10 ++ > include/image.h | 14 ++ > 2 files changed, 24 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 3/5] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
On Thu 13 Jun 2024 at 16:16, Mattijs Korpershoek
wrote:
> The only way to configure the load addresses for both bootimg and
> vendor_bootimg is by using the "abootimg" command.
> If we want to use the C API, there is no equivalent.
>
> Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
> specify the load address from C.
>
> This can be useful for implementing an Android bootmethod.
>
> Reviewed-by: Igor Opaniuk
> Signed-off-by: Mattijs Korpershoek
> ---
> cmd/abootimg.c | 10 ++
> include/image.h | 14 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/cmd/abootimg.c b/cmd/abootimg.c
> index 327712a536c0..ae7a1a7c83b0 100644
> --- a/cmd/abootimg.c
> +++ b/cmd/abootimg.c
> @@ -22,6 +22,11 @@ ulong get_abootimg_addr(void)
> return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
> }
>
> +void set_abootimg_addr(ulong addr)
> +{
> + _abootimg_addr = addr;
> +}
> +
> ulong get_ainit_bootimg_addr(void)
> {
> return _ainit_bootimg_addr;
> @@ -32,6 +37,11 @@ ulong get_avendor_bootimg_addr(void)
> return _avendor_bootimg_addr;
> }
>
> +void set_avendor_bootimg_addr(ulong addr)
> +{
> + _avendor_bootimg_addr = addr;
> +}
> +
> static int abootimg_get_ver(int argc, char *const argv[])
> {
> const struct andr_boot_img_hdr_v0 *hdr;
> diff --git a/include/image.h b/include/image.h
> index c5b288f62b44..df2decbf5c2a 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1970,6 +1970,13 @@ bool is_android_vendor_boot_image_header(const void
> *vendor_boot_img);
> */
> ulong get_abootimg_addr(void);
>
> +/**
> + * set_abootimg_addr() - Set Android boot image address
> + *
> + * Return: no returned results
> + */
> +void set_abootimg_addr(ulong addr);
> +
> /**
> * get_ainit_bootimg_addr() - Get Android init boot image address
> *
> @@ -1984,6 +1991,13 @@ ulong get_ainit_bootimg_addr(void);
> */
> ulong get_avendor_bootimg_addr(void);
>
> +/**
> + * set_abootimg_addr() - Set Android vendor boot image address
> + *
> + * Return: no returned results
> + */
> +void set_avendor_bootimg_addr(ulong addr);
> +
> /**
> * board_fit_config_name_match() - Check for a matching board name
> *
>
> --
> 2.45.2
>
Reviewed-by: Julien Masson
--
Julien Masson
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
Hi Marek, On 2024-06-13 3:12 pm, Marek Vasut wrote: On 6/13/24 9:49 AM, Claudius Heine wrote: Hi, [...] Also, while I checked OE-Core, other third party/community maintained layer could be impacted. I assume this is the case of meta-amarula-engicam[1] and meta-allwinner-hx[2] for example. I would suggest sending a mail to the different build systems mailing lists, I assume https://lists.openembedded.org/g/openembedded-devel and https://lists.yoctoproject.org/g/yocto for the OE-Core/YP side? Either to ask for their opinion or notify them (and specifically third party layers) it's going away or both. Not sure if I want to go through them all. Looking into all these 3rd party, downstream repos and informing everyone seems to be even more effort than maintaining the git protocol. And if someone uses their repo, they will notice it quickly and can easily fix it. I very much agree, that ^ is probably the best way to go. If some legacy repository breaks, fix the repository, hopefully there aren't too many of those to fix. Github deprecated git protocol a few years back and users managed too, except the fallout here is much smaller as it affects only one recipe (or a few). I suspect the following patch to oe-core (or local.conf equivalent) might also entirely mitigate the issue by providing https fallback automatically, without the need to modify the legacy layer/recipe ? If so, maybe this could be added to OE LTS releases at least ? " diff --git a/meta/classes-global/mirrors.bbclass b/meta/classes-global/mirrors.bbclass index 862648eec5..50a14c5881 100644 --- a/meta/classes-global/mirrors.bbclass +++ b/meta/classes-global/mirrors.bbclass @@ -77,6 +77,7 @@ https?://downloads.yoctoproject.org/mirror/sources/ https://mirrors.kernel.org/y MIRRORS += "\ git://salsa.debian.org/.* git://salsa.debian.org/PATH;protocol=https \ +git://git.denx.de/.* git://git.denx.de/PATH;protocol=https \ Well the path will change a bit as well: git://git.denx.de/u-boot.git -> https://source.denx.de/u-boot/u-boot.git git://git.denx.de/u-boot-efi.git -> https://source.denx.de/u-boot/custodians/u-boot-efi.git git://git.denx.de/xenomai.git -> https://source.denx.de/xenomai/xenomai.git git://git.denx.de/mxssb.git -> https://source.denx.de/denx/mxssb.git If we want to make it perfect, it will be more difficult than that. git://git.gnome.org/.* git://gitlab.gnome.org/GNOME/PATH;protocol=https \ git://git.infradead.org/.* git://git.infraroot.at/PATH;protocol=https \ git://.*/.* git://HOST/PATH;protocol=https \ " Anyway, I fixed it yesterday, and it doesn't make much sense to stop it now. So I will leave it in place until it breaks again, then I just remove it. Do you know how long it was actually broken ? (i.e. how long nobody noticed and complained about it?) So since 3rd of June, so about 5-8 days or so until someone noticed. I mean I could make it fail 10% of the time, and issue a deprecation notice, and then raise that percentage each month a bit higher... Maybe some kind of scaling, the fewer people use it in a certain time, the oftener it fails... :D regards, Claudius -- DENX Software Engineering GmbHt,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
Re: [PATCH v2 2/7] drivers: misc: k3_avs: Use soc_match_device instead of compatible.
On Tue, May 28, 2024 at 01:43:01PM +0530, Manorit Chawdhry wrote:
> vd_data remains the same for most of the SoCs but there are some
> differences in power domains and clocks that don't need a change to
> compatible and can be handled at SoC level.
>
> Change the data population logic from compatible to soc_match_device to
> add support for newer devices.
>
> Signed-off-by: Manorit Chawdhry
On am65x_evm_r5_usbdfu am65x_evm_r5_usbmsc:
arm: + am65x_evm_r5_usbmsc
+(am65x_evm_r5_usbmsc) In function 'k3_avs_configure',
+(am65x_evm_r5_usbmsc) inlined from 'k3_avs_probe' at
drivers/misc/k3_avs.c:459:8:
+(am65x_evm_r5_usbmsc) drivers/misc/k3_avs.c:333:12: error: 'conf' is used
uninitialized [-Werror=uninitialized]
+(am65x_evm_r5_usbmsc) 333 | if (!conf) {
+(am65x_evm_r5_usbmsc) |^
+(am65x_evm_r5_usbmsc) drivers/misc/k3_avs.c: In function 'k3_avs_probe':
+(am65x_evm_r5_usbmsc) drivers/misc/k3_avs.c:323:27: note: 'conf' was declared
here
+(am65x_evm_r5_usbmsc) 323 | struct vd_config *conf;
+(am65x_evm_r5_usbmsc) | ^~~~
+(am65x_evm_r5_usbmsc) cc1: all warnings being treated as errors
+(am65x_evm_r5_usbmsc) make[3]: *** [scripts/Makefile.build:256:
drivers/misc/k3_avs.o] Error 1
+(am65x_evm_r5_usbmsc) make[2]: *** [scripts/Makefile.build:397: drivers/misc]
Error 2
+(am65x_evm_r5_usbmsc) make[1]: *** [Makefile:1892: drivers] Error 2
+(am65x_evm_r5_usbmsc) make: *** [Makefile:177: sub-make] Error 2
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 5/5] bootstd: Add test for bootmeth_android
On Thu 13 Jun 2024 at 16:19, Mattijs Korpershoek
wrote:
> Add a unit test for testing the Android bootmethod.
>
> This requires another mmc image (mmc7) to contain the following partitions:
> - misc: contains the Bootloader Control Block (BCB)
> - boot_a: contains a fake generic kernel image
> - vendor_boot_a: contains a fake vendor_boot image
>
> Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
> this with:
>
> $ ./test/py/test.py --bd sandbox --build -k test_abootimg # build bootv4.img
> $ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
> $ ./test/py/test.py --bd sandbox --build -k bootflow_android
>
> Reviewed-by: Simon Glass
> Signed-off-by: Mattijs Korpershoek
> ---
> arch/sandbox/dts/test.dts | 8 +
> configs/sandbox_defconfig | 2 +-
> test/boot/bootflow.c | 65 ++--
> test/py/tests/test_ut.py | 76
> +++
> 4 files changed, 147 insertions(+), 4 deletions(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index a012f5c4c9ba..5fb5eac862ec 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -43,6 +43,7 @@
> mmc4 = "/mmc4";
> mmc5 = "/mmc5";
> mmc6 = "/mmc6";
> + mmc7 = "/mmc7";
> pci0 =
> pci1 =
> pci2 =
> @@ -1129,6 +1130,13 @@
> filename = "mmc6.img";
> };
>
> + /* This is used for Android tests */
> + mmc7 {
> + status = "disabled";
> + compatible = "sandbox,mmc";
> + filename = "mmc7.img";
> + };
> +
> pch {
> compatible = "sandbox,pch";
> };
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 93b52f2de5cf..bc4398f101a7 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -15,6 +15,7 @@ CONFIG_FIT=y
> CONFIG_FIT_RSASSA_PSS=y
> CONFIG_FIT_CIPHER=y
> CONFIG_FIT_VERBOSE=y
> +CONFIG_BOOTMETH_ANDROID=y
> CONFIG_LEGACY_IMAGE_FORMAT=y
> CONFIG_MEASURED_BOOT=y
> CONFIG_BOOTSTAGE=y
> @@ -40,7 +41,6 @@ CONFIG_LOG_MAX_LEVEL=9
> CONFIG_LOG_DEFAULT_LEVEL=6
> CONFIG_DISPLAY_BOARDINFO_LATE=y
> CONFIG_STACKPROTECTOR=y
> -CONFIG_ANDROID_AB=y
> CONFIG_CMD_CPU=y
> CONFIG_CMD_LICENSE=y
> CONFIG_CMD_SMBIOS=y
> diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
> index 4511cfa7f9bf..934c4dcbad2b 100644
> --- a/test/boot/bootflow.c
> +++ b/test/boot/bootflow.c
> @@ -27,6 +27,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +extern U_BOOT_DRIVER(bootmeth_android);
> extern U_BOOT_DRIVER(bootmeth_cros);
> extern U_BOOT_DRIVER(bootmeth_2script);
>
> @@ -518,12 +519,12 @@ BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM |
> UT_TESTF_SCAN_FDT);
> * @uts: Unit test state
> * @mmc_dev: MMC device to use, e.g. "mmc4". Note that this must remain valid
> * in the caller until
> - * @bind_cros: true to bind the ChromiumOS bootmeth
> + * @bind_cros: true to bind the ChromiumOS and Android bootmeths
> * @old_orderp: Returns the original bootdev order, which must be restored
> * Returns 0 on success, -ve on failure
> */
> static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev,
> - bool bind_cros, const char ***old_orderp)
> + bool bind_cros_android, const char ***old_orderp)
> {
> static const char *order[] = {"mmc2", "mmc1", NULL, NULL};
> struct udevice *dev, *bootstd;
> @@ -545,12 +546,19 @@ static int prep_mmc_bootdev(struct unit_test_state
> *uts, const char *mmc_dev,
> "bootmeth_script", 0, ofnode_null(), ));
>
> /* Enable the cros bootmeth if needed */
> - if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros) {
> + if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros_android) {
> ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
> ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_cros),
> "cros", 0, ofnode_null(), ));
> }
>
> + /* Enable the android bootmeths if needed */
> + if (IS_ENABLED(CONFIG_BOOTMETH_ANDROID) && bind_cros_android) {
> + ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
> + ut_assertok(device_bind(bootstd,
> DM_DRIVER_REF(bootmeth_android),
> + "android", 0, ofnode_null(), ));
> + }
> +
> /* Change the order to include the device */
> std = dev_get_priv(bootstd);
> old_order = std->bootdev_order;
> @@ -589,6 +597,37 @@ static int scan_mmc_bootdev(struct unit_test_state *uts,
> const char *mmc_dev,
> return 0;
> }
>
> +/**
> + * scan_mmc_android_bootdev() - Set up an mmc bootdev so we can access other
> + * distros. Android bootflow might print "ANDROID:*" while scanning
> + *
> + * @uts: Unit test state
> + * @mmc_dev: MMC
Re: [PATCH v2 4/5] bootstd: Add a bootmeth for Android
On Thu 13 Jun 2024 at 16:18, 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:
> 3.a. Get slot (A/B) from BCB
> 3.b. Run AVB (Android Verified Boot) on boot partitions
> 3.c. Load boot and vendor_boot partitions
> 3.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.
>
> [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/
>
> Reviewed-by: Simon Glass
> Signed-off-by: Mattijs Korpershoek
> ---
> MAINTAINERS | 7 +
> boot/Kconfig| 16 ++
> boot/Makefile | 2 +
> boot/bootmeth_android.c | 553
>
> boot/bootmeth_android.h | 29 +++
> doc/develop/bootstd.rst | 6 +
> 6 files changed, 613 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 66783d636e3d..6d2b87720565 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -939,6 +939,13 @@ F: include/bootstd.h
> F: net/eth_bootdevice.c
> F: test/boot/
>
> +BOOTMETH_ANDROID
> +M: Mattijs Korpershoek
> +S: Maintained
> +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git
> +F: boot/bootmeth_android.c
> +F: boot/bootmeth_android.h
> +
> BTRFS
> M: Marek Beh.n
> R: Qu Wenruo
> diff --git a/boot/Kconfig b/boot/Kconfig
> index 6f3096c15a6f..88266c8d2ed3 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -494,6 +494,22 @@ config BOOTMETH_GLOBAL
> EFI bootmgr, since they take full control over which bootdevs are
> selected to boot.
>
> +config BOOTMETH_ANDROID
> + bool "Bootdev support for Android"
> + depends on X86 || ARM || SANDBOX
> + select ANDROID_AB
> + select ANDROID_BOOT_IMAGE
> + select CMD_BCB
> + select CMD_FASTBOOT
> + select PARTITION_TYPE_GUID
> + select PARTITION_UUIDS
> + help
> + Enables support for booting Android using bootstd. Android requires
> + multiple partitions (misc, boot, vbmeta, ...) in storage for booting.
> +
> + Note that only MMC bootdevs are supported at present. This is caused
> + by AVB being limited to MMC devices only.
> +
> config BOOTMETH_CROS
> bool "Bootdev support for Chromium OS"
> depends on X86 || ARM || SANDBOX
> diff --git a/boot/Makefile b/boot/Makefile
> index 84ccfeaecec4..75d1cd46fabf 100644
> --- a/boot/Makefile
> +++ b/boot/Makefile
> @@ -66,3 +66,5 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_REQUEST) +=
> vbe_request.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
> obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_OS) += vbe_simple_os.o
> +
> +obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_ANDROID) += bootmeth_android.o
> diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
> new file mode 100644
> index ..6e8d3e615db0
> --- /dev/null
> +++ b/boot/bootmeth_android.c
> @@ -0,0 +1,553 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bootmeth for Android
> + *
> + * Copyright (C) 2024 BayLibre, SAS
> + * Written by Mattijs Korpershoek
> + */
> +#define LOG_CATEGORY UCLASS_BOOTSTD
> +
> +#include
> +#include
> +#if CONFIG_IS_ENABLED(AVB_VERIFY)
> +#include
> +#endif
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "bootmeth_android.h"
> +
> +#define BCB_FIELD_COMMAND_SZ 32
> +#define BCB_PART_NAME "misc"
> +#define BOOT_PART_NAME "boot"
> +#define VENDOR_BOOT_PART_NAME "vendor_boot"
> +
> +/**
> + * struct android_priv - Private data
> + *
> + * This is read from the disk and recorded for use when the full Android
> + * kernel must be loaded and booted
> + *
> + * @boot_mode: Requested boot mode (normal, recovery, bootloader)
> + * @slot: Nul-terminated partition slot suffix read from BCB ("a\0" or "b\0")
> + * @header_version: Android boot image header version
> + */
> +struct android_priv {
> + enum android_boot_mode boot_mode;
> + char slot[2];
> + u32
Re: [PATCH v2 2/5] bootstd: Add bootflow_iter_check_mmc() helper
On Thu 13 Jun 2024 at 16:15, Mattijs Korpershoek
wrote:
> Some bootflows might be able to only boot from MMC devices.
>
> Add a helper function these bootflows can use.
>
> Reviewed-by: Igor Opaniuk
> Signed-off-by: Mattijs Korpershoek
> ---
> boot/bootflow.c| 12
> include/bootflow.h | 9 +
> 2 files changed, 21 insertions(+)
>
> diff --git a/boot/bootflow.c b/boot/bootflow.c
> index 9aa3179c3881..59d77d2385f4 100644
> --- a/boot/bootflow.c
> +++ b/boot/bootflow.c
> @@ -575,6 +575,18 @@ int bootflow_iter_check_blk(const struct bootflow_iter
> *iter)
> return -ENOTSUPP;
> }
>
> +int bootflow_iter_check_mmc(const struct bootflow_iter *iter)
> +{
> + const struct udevice *media = dev_get_parent(iter->dev);
> + enum uclass_id id = device_get_uclass_id(media);
> +
> + log_debug("uclass %d: %s\n", id, uclass_get_name(id));
> + if (id == UCLASS_MMC)
> + return 0;
> +
> + return -ENOTSUPP;
> +}
> +
> int bootflow_iter_check_sf(const struct bootflow_iter *iter)
> {
> const struct udevice *media = dev_get_parent(iter->dev);
> diff --git a/include/bootflow.h b/include/bootflow.h
> index 080ee8501225..6058ddd89b16 100644
> --- a/include/bootflow.h
> +++ b/include/bootflow.h
> @@ -407,6 +407,15 @@ void bootflow_remove(struct bootflow *bflow);
> */
> int bootflow_iter_check_blk(const struct bootflow_iter *iter);
>
> +/**
> + * bootflow_iter_check_mmc() - Check that a bootflow uses a MMC device
> + *
> + * This checks the bootdev in the bootflow to make sure it uses a mmc device
> + *
> + * Return: 0 if OK, -ENOTSUPP if some other device is used (e.g. ethernet)
> + */
> +int bootflow_iter_check_mmc(const struct bootflow_iter *iter);
> +
> /**
> * bootflow_iter_check_sf() - Check that a bootflow uses SPI FLASH
> *
>
> --
> 2.45.2
>
Reviewed-by: Julien Masson
--
Julien Masson
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
On 6/13/24 9:49 AM, Claudius Heine wrote: Hi, [...] Also, while I checked OE-Core, other third party/community maintained layer could be impacted. I assume this is the case of meta-amarula-engicam[1] and meta-allwinner-hx[2] for example. I would suggest sending a mail to the different build systems mailing lists, I assume https://lists.openembedded.org/g/openembedded-devel and https://lists.yoctoproject.org/g/yocto for the OE-Core/YP side? Either to ask for their opinion or notify them (and specifically third party layers) it's going away or both. Not sure if I want to go through them all. Looking into all these 3rd party, downstream repos and informing everyone seems to be even more effort than maintaining the git protocol. And if someone uses their repo, they will notice it quickly and can easily fix it. I very much agree, that ^ is probably the best way to go. If some legacy repository breaks, fix the repository, hopefully there aren't too many of those to fix. Github deprecated git protocol a few years back and users managed too, except the fallout here is much smaller as it affects only one recipe (or a few). I suspect the following patch to oe-core (or local.conf equivalent) might also entirely mitigate the issue by providing https fallback automatically, without the need to modify the legacy layer/recipe ? If so, maybe this could be added to OE LTS releases at least ? " diff --git a/meta/classes-global/mirrors.bbclass b/meta/classes-global/mirrors.bbclass index 862648eec5..50a14c5881 100644 --- a/meta/classes-global/mirrors.bbclass +++ b/meta/classes-global/mirrors.bbclass @@ -77,6 +77,7 @@ https?://downloads.yoctoproject.org/mirror/sources/ https://mirrors.kernel.org/y MIRRORS += "\ git://salsa.debian.org/.* git://salsa.debian.org/PATH;protocol=https \ +git://git.denx.de/.* git://git.denx.de/PATH;protocol=https \ git://git.gnome.org/.* git://gitlab.gnome.org/GNOME/PATH;protocol=https \ git://git.infradead.org/.*git://git.infraroot.at/PATH;protocol=https \ git://.*/.* git://HOST/PATH;protocol=https \ " Anyway, I fixed it yesterday, and it doesn't make much sense to stop it now. So I will leave it in place until it breaks again, then I just remove it. Do you know how long it was actually broken ? (i.e. how long nobody noticed and complained about it?)
silent u-boot not working
Hi, I'm running openSUSE Tumbleweed on an RPI CM4, I'm trying to silence u- boot boot messages, with the default configuration there is an u-boot logo on the top right corner and boot text, I'd like to get rid of the logo and all text if possible. The keyboard is not working before the Linux kernel is loaded, so I can not interrupt u-boot and enter any commands, so where should I put "set env silent 1"? I've followed the guide on https://github.com/ARM-software/u-boot/blob/master/doc/README.silent I have built u-boot from source using `make rpi_4_defconfig` configuration modified the configuration with make menuconfig, and verified this in .config before builing. CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y CONFIG_SILENT_CONSOLE_UPDATE_ON_SET=y CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC=y CONFIG_SILENT_CONSOLE_UNTIL_ENV=y Copied the binary to /boot/efi/u-boot.bin and /boot/vc/u-boot.bin I've also tried to define CONFIG_EXTRA_ENV_SETTINGS in include/configs/rpi.h according to: https://stackoverflow.com/questions/34356844/how-to-disable-serial-consolenon-kernel-in-u-boot/64583919#64583919?newreg=0df51e20b39a448094cbb70fe356e4ec and rebuilt and copied to binary again, still not working. The text and logo is still present during boot, what am I doing wrong here? Jonas
Re: [PATCH] board: beagleplay: Fix the bootpart to pick from root partition
Hi Dhruva,
On 13/06/24 13:36, Dhruva Gole wrote:
The Kernel Image and DTB files are supposed to be picked from the rootfs
of the SD Card, this fails in legacy boot flow because bootpart is set
to 1:1. Fix it.
Fixes: a200f428b5b21 ("board: ti: am62x: Add am62x_beagleplay_* defconfigs and env
file")
Signed-off-by: Dhruva Gole
Acked-by: Chirag Shilwant
---
board/beagle/beagleplay/beagleplay.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/beagle/beagleplay/beagleplay.env
b/board/beagle/beagleplay/beagleplay.env
index bbf6b925d02c..190181c8ad0c 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -11,7 +11,7 @@ set_led_state_start_load=led led-0 on; led led-1 off;
led led-2 on; led led-3 off; led led-4 on
boot=mmc
mmcdev=1
-bootpart=1:1
+bootpart=1:2
bootdir=/boot
boot_targets=mmc1 mmc0
bootmeths=script extlinux efi pxe
[PATCH v2 14/14] clk: mediatek: mt7986: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7986-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7986.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7986.c
b/drivers/clk/mediatek/clk-mt7986.c
index b3fa63fc0ab..efc3d4120b7 100644
--- a/drivers/clk/mediatek/clk-mt7986.c
+++ b/drivers/clk/mediatek/clk-mt7986.c
@@ -533,6 +533,7 @@ static const struct mtk_clk_tree mt7986_infracfg_clk_tree =
{
static const struct udevice_id mt7986_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7986-fixed-plls" },
+ { .compatible = "mediatek,mt7986-apmixedsys" },
{}
};
--
2.43.0
[PATCH v2 13/14] clk: mediatek: mt7988: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7988-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7988.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7988.c
b/drivers/clk/mediatek/clk-mt7988.c
index 34e7b2d734c..32b04511781 100644
--- a/drivers/clk/mediatek/clk-mt7988.c
+++ b/drivers/clk/mediatek/clk-mt7988.c
@@ -833,6 +833,7 @@ static const struct mtk_clk_tree mt7988_infracfg_clk_tree =
{
static const struct udevice_id mt7988_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7988-fixed-plls" },
+ { .compatible = "mediatek,mt7988-apmixedsys" },
{}
};
--
2.43.0
[PATCH v2 12/14] pci: mediatek: make pcie-phy optional for gen3
Set pcie-phy optional for PCIe gen3. MT7988 doesn't require it and
making it mandatory prevent the driver to correctly probe.
Signed-off-by: Christian Marangi
---
drivers/pci/pcie_mediatek_gen3.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pcie_mediatek_gen3.c b/drivers/pci/pcie_mediatek_gen3.c
index 673813b8b75..0149edae0bf 100644
--- a/drivers/pci/pcie_mediatek_gen3.c
+++ b/drivers/pci/pcie_mediatek_gen3.c
@@ -284,9 +284,8 @@ static int mtk_pcie_power_on(struct udevice *dev)
pcie->priv = dev;
- err = generic_phy_get_by_name(dev, "pcie-phy", >phy);
- if (err)
- return err;
+ /* pcie-phy is optional (mt7988 doesn't need it) */
+ generic_phy_get_by_name(dev, "pcie-phy", >phy);
/*
* Upstream linux kernel devine these clock without clock-names
@@ -308,13 +307,15 @@ static int mtk_pcie_power_on(struct udevice *dev)
if (err)
return err;
- err = generic_phy_init(>phy);
- if (err)
- return err;
+ if (pcie->phy.dev) {
+ err = generic_phy_init(>phy);
+ if (err)
+ return err;
- err = generic_phy_power_on(>phy);
- if (err)
- goto err_phy_on;
+ err = generic_phy_power_on(>phy);
+ if (err)
+ goto err_phy_on;
+ }
err = clk_enable(>pl_250m_ck);
if (err)
@@ -348,7 +349,8 @@ err_clk_tl_26m:
err_clk_pl_250m:
clk_disable(>pl_250m_ck);
err_phy_on:
- generic_phy_exit(>phy);
+ if (pcie->phy.dev)
+ generic_phy_exit(>phy);
return err;
}
--
2.43.0
[PATCH v2 11/14] pinctrl: mediatek: mt7981: init device before relocation
Upstream kernel linux define pinctrl for uart0, hence this pin group
and pinctrl driver is needed before relocation. Add DM_FLAG_PRE_RELOC
flag to init and mute mtk_serial error on early serial init.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
index 3fa198ed79c..4bc4abe6518 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
@@ -1050,4 +1050,5 @@ U_BOOT_DRIVER(mt7981_pinctrl) = {
.ops = _pinctrl_ops,
.probe = mtk_pinctrl_mt7981_probe,
.priv_auto = sizeof(struct mtk_pinctrl_priv),
+ .flags = DM_FLAG_PRE_RELOC,
};
--
2.43.0
[PATCH v2 10/14] pinctrl: mediatek: add support for gpio-controller property in root node
Add support for gpio-controller property in root pinctrl node.
This is to follow upstream linux DTSI that doesn't define the
gpio-controller and cells in dedicated nodes.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 0baef57c1c2..7465e236bc8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -762,6 +762,15 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (!drv)
return -ENOENT;
+ /*
+* Support upstream linux DTSI that define gpio-controller
+* in the root node (instead of a dedicated subnode)
+*/
+ if (dev_read_bool(dev, "gpio-controller")) {
+ node = dev_ofnode(parent);
+ goto bind;
+ }
+
ret = -ENOENT;
dev_for_each_subnode(node, parent)
if (ofnode_read_bool(node, "gpio-controller")) {
@@ -772,6 +781,7 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (ret)
return ret;
+bind:
ret = device_bind_with_driver_data(parent, _gpio_driver,
"mediatek_gpio", 0, node,
);
--
2.43.0
[PATCH v2 09/14] clk: mediatek: mt7981: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7981-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7981.c
b/drivers/clk/mediatek/clk-mt7981.c
index 7fcb81419cd..13dc3df0e9e 100644
--- a/drivers/clk/mediatek/clk-mt7981.c
+++ b/drivers/clk/mediatek/clk-mt7981.c
@@ -543,6 +543,7 @@ static const struct mtk_clk_tree mt7981_infracfg_clk_tree =
{
static const struct udevice_id mt7981_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7981-fixed-plls" },
+ { .compatible = "mediatek,mt7981-apmixedsys" },
{}
};
--
2.43.0
[PATCH v2 08/14] mmc: mediatek: add support for upstream linux clock and property
Add support for upstream linux clock and map U-Boot property to the one
use in upstream linux where supported.
Also add handling for the use_internal_cd that on upstream is hardcoded
enabled on mt7620.
Signed-off-by: Christian Marangi
---
drivers/mmc/mtk-sd.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index 296aaee7331..65b6b02e759 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -336,6 +336,7 @@ struct msdc_compatible {
bool enhance_rx;
bool builtin_pad_ctrl;
bool default_pad_dly;
+ bool use_internal_cd;
};
struct msdc_delay_phase {
@@ -366,6 +367,10 @@ struct msdc_host {
struct clk src_clk_cg; /* optional, MSDC source clock control gate */
struct clk h_clk; /* MSDC core clock */
+ /* upstream linux clock */
+ struct clk axi_cg_clk; /* optional, AXI clock */
+ struct clk ahb_cg_clk; /* optional, AHB clock */
+
u32 src_clk_freq; /* source clock */
u32 mclk; /* mmc framework required bus clock */
u32 sclk; /* actual calculated bus clock */
@@ -1638,6 +1643,11 @@ static void msdc_ungate_clock(struct msdc_host *host)
clk_enable(>h_clk);
if (host->src_clk_cg.dev)
clk_enable(>src_clk_cg);
+
+ if (host->axi_cg_clk.dev)
+ clk_enable(>axi_cg_clk);
+ if (host->ahb_cg_clk.dev)
+ clk_enable(>ahb_cg_clk);
}
static int msdc_drv_probe(struct udevice *dev)
@@ -1651,6 +1661,9 @@ static int msdc_drv_probe(struct udevice *dev)
host->dev_comp = (struct msdc_compatible *)dev_get_driver_data(dev);
+ if (host->dev_comp->use_internal_cd)
+ host->builtin_cd = 1;
+
host->src_clk_freq = clk_get_rate(>src_clk);
if (host->dev_comp->clk_div_bits == 8)
@@ -1716,18 +1729,31 @@ static int msdc_of_to_plat(struct udevice *dev)
clk_get_by_name(dev, "source_cg", >src_clk_cg); /* optional */
+ /* upstream linux clock */
+ clk_get_by_name(dev, "axi_cg", >axi_cg_clk); /* optional */
+ clk_get_by_name(dev, "ahb_cg", >ahb_cg_clk); /* optional */
+
#if CONFIG_IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "wp-gpios", 0, >gpio_wp, GPIOD_IS_IN);
gpio_request_by_name(dev, "cd-gpios", 0, >gpio_cd, GPIOD_IS_IN);
#endif
host->hs400_ds_delay = dev_read_u32_default(dev, "hs400-ds-delay", 0);
- host->hs200_cmd_int_delay =
- dev_read_u32_default(dev, "cmd_int_delay", 0);
+ if (dev_read_u32(dev, "mediatek,hs200-cmd-int-delay",
+>hs200_cmd_int_delay))
+ host->hs200_cmd_int_delay =
+ dev_read_u32_default(dev, "cmd_int_delay", 0);
+
host->hs200_write_int_delay =
dev_read_u32_default(dev, "write_int_delay", 0);
- host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
+ if (dev_read_u32(dev, "mediatek,latch-ck", >latch_ck))
+ host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
host->r_smpl = dev_read_u32_default(dev, "r_smpl", 0);
+ if (dev_read_bool(dev, "mediatek,hs400-cmd-resp-sel-rising"))
+ host->r_smpl = 1;
+
host->builtin_cd = dev_read_u32_default(dev, "builtin-cd", 0);
host->cd_active_high = dev_read_bool(dev, "cd-active-high");
@@ -1776,6 +1802,7 @@ static const struct msdc_compatible mt7620_compat = {
.enhance_rx = false,
.builtin_pad_ctrl = true,
.default_pad_dly = true,
+ .use_internal_cd = true,
};
static const struct msdc_compatible mt7621_compat = {
@@ -1806,7 +1833,7 @@ static const struct msdc_compatible mt7623_compat = {
.data_tune = true,
.busy_check = false,
.stop_clk_fix = false,
- .enhance_rx = false
+ .enhance_rx = false,
};
static const struct msdc_compatible mt7986_compat = {
--
2.43.0
[PATCH v2 07/14] serial: mediatek: add special handling for highspeed and linux compat
Upstream linux serial driver use a different logic to setup serial regs.
They have 2 interval:
- < 115200 we use lowspeed regs and 16 * baud
- >= 115200 we use highspeed
We currently use force_highspeed property to force usage of highspeed
regs even with low baud rate.
Add special handling if the upstream compatible is used where we just
apply the same interval with anything >= 115200 in highspeed simulating
force_highspeed.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index d34a31c9cf0..14be095653a 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -89,8 +89,8 @@ struct mtk_serial_priv {
bool force_highspeed;
};
-static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud,
- uint clk_rate)
+static void _mtk_serial_setbrg(struct udevice *dev, struct mtk_serial_priv
*priv,
+ int baud, uint clk_rate)
{
u32 quot, realbaud, samplecount = 1;
@@ -113,7 +113,12 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
*priv, int baud,
goto set_baud;
}
- if (priv->force_highspeed)
+ /*
+* Upstream linux use highspeed for anything >= 115200 and lowspeed
+* for < 115200. Simulate this if we are using the upstream compatible.
+*/
+ if (priv->force_highspeed ||
+ (device_is_compatible(dev, "mediatek,mt6577-uart") && baud >=
115200))
goto use_hs3;
if (baud <= 115200) {
@@ -186,7 +191,7 @@ static int mtk_serial_setbrg(struct udevice *dev, int
baudrate)
if (IS_ERR_VALUE(clk_rate) || clk_rate == 0)
clk_rate = priv->fixed_clk_rate;
- _mtk_serial_setbrg(priv, baudrate, clk_rate);
+ _mtk_serial_setbrg(dev, priv, baudrate, clk_rate);
return 0;
}
@@ -302,13 +307,13 @@ DECLARE_GLOBAL_DATA_PTR;
writel(0, _hsuart##port.regs->ier); \
writel(UART_MCRVAL, _hsuart##port.regs->mcr); \
writel(UART_FCRVAL, _hsuart##port.regs->fcr); \
- _mtk_serial_setbrg(_hsuart##port, gd->baudrate, \
+ _mtk_serial_setbrg(NULL, _hsuart##port, gd->baudrate, \
mtk_hsuart##port.fixed_clk_rate); \
return 0 ; \
} \
static void mtk_serial##port##_setbrg(void) \
{ \
- _mtk_serial_setbrg(_hsuart##port, gd->baudrate, \
+ _mtk_serial_setbrg(NULL, _hsuart##port, gd->baudrate, \
mtk_hsuart##port.fixed_clk_rate); \
} \
static int mtk_serial##port##_getc(void) \
@@ -456,7 +461,7 @@ static inline void _debug_uart_init(void)
writel(UART_MCRVAL, >mcr);
writel(UART_FCRVAL, >fcr);
- _mtk_serial_setbrg(, CONFIG_BAUDRATE, priv.fixed_clk_rate);
+ _mtk_serial_setbrg(NULL, , CONFIG_BAUDRATE, priv.fixed_clk_rate);
}
static inline void _debug_uart_putc(int ch)
--
2.43.0
[PATCH v2 06/14] serial: mediatek: add support for bus clock and enable it
Upstream linux also provide the additional optional bus clock.
Add support for it and also enable the baud and bus clock on probe.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index f146f2b006e..d34a31c9cf0 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -76,6 +76,7 @@ struct mtk_serial_regs {
* driver
* @regs: Register base of the serial port
* @clk: The baud clock device
+ * @clk_bus: The bus clock device
* @fixed_clk_rate:Fallback fixed baud clock rate if baud clock
* device is not specified
* @force_highspeed: Force using high-speed mode
@@ -83,6 +84,7 @@ struct mtk_serial_regs {
struct mtk_serial_priv {
struct mtk_serial_regs __iomem *regs;
struct clk clk;
+ struct clk clk_bus;
u32 fixed_clk_rate;
bool force_highspeed;
};
@@ -220,6 +222,10 @@ static int mtk_serial_probe(struct udevice *dev)
writel(UART_MCRVAL, >regs->mcr);
writel(UART_FCRVAL, >regs->fcr);
+ clk_enable(>clk);
+ if (priv->clk_bus.dev)
+ clk_enable(>clk_bus);
+
return 0;
}
@@ -250,6 +256,8 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
}
}
+ clk_get_by_name(dev, "bus", >clk_bus);
+
priv->force_highspeed = dev_read_bool(dev, "mediatek,force-highspeed");
return 0;
--
2.43.0
[PATCH v2 05/14] i2c: mediatek: add support for optional arb and pmic clock
Add support for optional arb and pmic clock for i2c provided in upstream
linux DTSI.
Signed-off-by: Christian Marangi
---
drivers/i2c/mtk_i2c.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c
index 5592fe91817..3450177741a 100644
--- a/drivers/i2c/mtk_i2c.c
+++ b/drivers/i2c/mtk_i2c.c
@@ -221,6 +221,8 @@ struct mtk_i2c_priv {
void __iomem *pdmabase; /* dma base address*/
struct clk clk_main;/* main clock for i2c bus */
struct clk clk_dma; /* DMA clock for i2c via DMA */
+ struct clk clk_arb; /* DMA clock for i2c ARB */
+ struct clk clk_pmic;/* DMA clock for i2c PMIC */
const struct mtk_i2c_soc_data *soc_data; /* Compatible data for
different IC */
int op; /* operation mode */
bool zero_len; /* Only transfer slave address, no data
*/
@@ -255,6 +257,18 @@ static int mtk_i2c_clk_enable(struct mtk_i2c_priv *priv)
if (ret)
return log_msg_ret("enable clk_dma", ret);
+ if (priv->clk_arb.dev) {
+ ret = clk_enable(>clk_arb);
+ if (ret)
+ return log_msg_ret("enable clk_arb", ret);
+ }
+
+ if (priv->clk_pmic.dev) {
+ ret = clk_enable(>clk_pmic);
+ if (ret)
+ return log_msg_ret("enable clk_pmic", ret);
+ }
+
return 0;
}
@@ -262,6 +276,18 @@ static int mtk_i2c_clk_disable(struct mtk_i2c_priv *priv)
{
int ret;
+ if (priv->clk_pmic.dev) {
+ ret = clk_disable(>clk_pmic);
+ if (ret)
+ return log_msg_ret("disable clk_pmic", ret);
+ }
+
+ if (priv->clk_arb.dev) {
+ ret = clk_disable(>clk_arb);
+ if (ret)
+ return log_msg_ret("disable clk_arb", ret);
+ }
+
ret = clk_disable(>clk_dma);
if (ret)
return log_msg_ret("disable clk_dma", ret);
@@ -748,6 +774,10 @@ static int mtk_i2c_of_to_plat(struct udevice *dev)
ret = clk_get_by_index(dev, 1, >clk_dma);
+ /* optional i2c clock */
+ clk_get_by_name(dev, "arb", >clk_arb);
+ clk_get_by_name(dev, "pmic", >clk_pmic);
+
return ret;
}
--
2.43.0
[PATCH v2 04/14] net: mediatek: handle alternative name for pn_swap property
Handle alternative name for pn_swap property as upstream linux use
mediatek,pnswap.
Signed-off-by: Christian Marangi
---
drivers/net/mtk_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 75e7bcf83b7..87e2e1d9cda 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -1965,7 +1965,9 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
return -ENODEV;
}
- priv->pn_swap = ofnode_read_bool(args.node, "pn_swap");
+ /* Upstream linux use mediatek,pnswap instead of pn_swap */
+ priv->pn_swap = ofnode_read_bool(args.node, "pn_swap") ||
+ ofnode_read_bool(args.node, "mediatek,pnswap");
} else if (priv->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
/* get corresponding usxgmii phandle */
ret = dev_read_phandle_with_args(dev, "mediatek,usxgmiisys",
--
2.43.0
[PATCH v2 03/14] spi: mtk_spim: add support for upstream mediatek, spi-ipm compatible
Upstream kernel linux use a different compatible mediatek,spi-ipm.
Add support for this compatible and add handling for the additional
clock similar to how it's done by the upstream driver and handling for
all the property enabled by default.
Signed-off-by: Christian Marangi
---
drivers/spi/mtk_spim.c | 45 --
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/mtk_spim.c b/drivers/spi/mtk_spim.c
index 90f4c3cecb9..b360eca2b91 100644
--- a/drivers/spi/mtk_spim.c
+++ b/drivers/spi/mtk_spim.c
@@ -137,6 +137,8 @@ struct mtk_spim_capability {
* @state: Controller state
* @sel_clk: Pad clock
* @spi_clk: Core clock
+ * @parent_clk:Parent clock (needed for mediatek,spi-ipm,
upstream DTSI)
+ * @hclk: HCLK clock (needed for mediatek,spi-ipm, upstream DTSI)
* @pll_clk_rate: Controller's PLL source clock rate, which is different
* from SPI bus clock rate
* @xfer_len: Current length of data for transfer
@@ -151,6 +153,7 @@ struct mtk_spim_priv {
void __iomem *base;
u32 state;
struct clk sel_clk, spi_clk;
+ struct clk parent_clk, hclk;
u32 pll_clk_rate;
u32 xfer_len;
struct mtk_spim_capability hw_cap;
@@ -650,7 +653,21 @@ static int mtk_spim_probe(struct udevice *dev)
if (!priv->base)
return -EINVAL;
- mtk_spim_get_attr(priv, dev);
+ /*
+* Upstream linux driver for ipm design enable all the modes
+* and setup the calibrarion values directly in the driver with
+* standard values.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ priv->hw_cap.enhance_timing = true;
+ priv->hw_cap.dma_ext = true;
+ priv->hw_cap.ipm_design = true;
+ priv->hw_cap.support_quad = true;
+ priv->sample_sel = 0;
+ priv->tick_dly = 2;
+ } else {
+ mtk_spim_get_attr(priv, dev);
+ }
ret = clk_get_by_name(dev, "sel-clk", >sel_clk);
if (ret < 0) {
@@ -664,8 +681,31 @@ static int mtk_spim_probe(struct udevice *dev)
return ret;
}
- clk_enable(>sel_clk);
+ /*
+* Upstream DTSI use a different compatible that provide additional
+* clock instead of the assigned-clock implementation.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ ret = clk_get_by_name(dev, "parent-clk", >parent_clk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get parent-clk\n");
+ return ret;
+ }
+
+ ret = clk_get_by_name(dev, "hclk", >hclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get hclk\n");
+ return ret;
+ }
+
+ clk_enable(>parent_clk);
+ clk_set_parent(>sel_clk, >parent_clk);
+
+ clk_enable(>hclk);
+ }
+
clk_enable(>spi_clk);
+ clk_enable(>sel_clk);
priv->pll_clk_rate = clk_get_rate(>spi_clk);
if (priv->pll_clk_rate == 0)
@@ -698,6 +738,7 @@ static const struct dm_spi_ops mtk_spim_ops = {
static const struct udevice_id mtk_spim_ids[] = {
{ .compatible = "mediatek,ipm-spi" },
+ { .compatible = "mediatek,spi-ipm", },
{}
};
--
2.43.0
[PATCH v2 02/14] pci: mediatek: add PCIe controller support for filogic silicon
From: John Crispin
Add MediaTek GEN3 PCIe controller support for filogic silicon.
This is adapted from the Linux version of the driver.
Signed-off-by: John Crispin
[ fix minor problems, fix checkpatch errors ]
Signed-off-by: Christian Marangi
---
drivers/pci/Kconfig | 7 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_mediatek_gen3.c | 382 +++
3 files changed, 390 insertions(+)
create mode 100644 drivers/pci/pcie_mediatek_gen3.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 8d02ab82ad9..22a56f4ca38 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -350,6 +350,13 @@ config PCIE_MEDIATEK
Say Y here if you want to enable Gen2 PCIe controller,
which could be found on MT7623 SoC family.
+config PCIE_MEDIATEK_GEN3
+ bool "MediaTek PCIe Gen3 controller"
+ depends on ARCH_MEDIATEK
+ help
+ Say Y here if you want to enable Gen3 PCIe controller,
+ which could be found on the Mediatek Filogic SoC family.
+
config PCIE_DW_MESON
bool "Amlogic Meson DesignWare based PCIe controller"
depends on ARCH_MESON
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 2927c519129..5b2d2969802 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
obj-$(CONFIG_PCIE_DW_COMMON) += pcie_dw_common.o
obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
+obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie_mediatek_gen3.o
obj-$(CONFIG_PCIE_ROCKCHIP) += pcie_rockchip.o
obj-$(CONFIG_PCIE_DW_ROCKCHIP) += pcie_dw_rockchip.o
obj-$(CONFIG_PCIE_DW_MESON) += pcie_dw_meson.o
diff --git a/drivers/pci/pcie_mediatek_gen3.c b/drivers/pci/pcie_mediatek_gen3.c
new file mode 100644
index 000..673813b8b75
--- /dev/null
+++ b/drivers/pci/pcie_mediatek_gen3.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek PCIe host controller driver.
+ *
+ * Copyright (c) 2023 John Crispin
+ * Driver is based on u-boot gen1/2 and upstream linux gen3 code
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pci_internal.h"
+
+/* PCIe shared registers */
+#define PCIE_CFG_ADDR 0x20
+#define PCIE_CFG_DATA 0x24
+
+#define PCIE_SETTING_REG 0x80
+
+#define PCIE_PCI_IDS_1 0x9c
+#define PCIE_RC_MODE BIT(0)
+#define PCI_CLASS(class) ((class) << 8)
+
+#define PCIE_CFGNUM_REG0x140
+#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0))
+#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8))
+#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19,
16))
+#define PCIE_CFG_FORCE_BYTE_EN BIT(20)
+#define PCIE_CFG_OFFSET_ADDR 0x1000
+#define PCIE_CFG_HEADER(bus, devfn)(PCIE_CFG_BUS(bus) |
PCIE_CFG_DEVFN(devfn))
+
+#define PCIE_RST_CTRL_REG 0x148
+#define PCIE_MAC_RSTB BIT(0)
+#define PCIE_PHY_RSTB BIT(1)
+#define PCIE_BRG_RSTB BIT(2)
+#define PCIE_PE_RSTB BIT(3)
+
+#define PCIE_LINK_STATUS_REG 0x154
+#define PCIE_PORT_LINKUP BIT(8)
+
+#define PCIE_INT_ENABLE_REG0x180
+
+#define PCIE_MISC_CTRL_REG 0x348
+#define PCIE_DISABLE_DVFSRC_VLT_REQBIT(1)
+
+#define PCIE_TRANS_TABLE_BASE_REG 0x800
+#define PCIE_ATR_SRC_ADDR_MSB_OFFSET0x4
+#define PCIE_ATR_TRSL_ADDR_LSB_OFFSET 0x8
+#define PCIE_ATR_TRSL_ADDR_MSB_OFFSET 0xc
+#define PCIE_ATR_TRSL_PARAM_OFFSET 0x10
+#define PCIE_ATR_TLB_SET_OFFSET 0x20
+
+#define PCIE_MAX_TRANS_TABLES 8
+#define PCIE_ATR_EN BIT(0)
+#define PCIE_ATR_SIZE(size) \
+ (size) - 1) << 1) & GENMASK(6, 1)) | PCIE_ATR_EN)
+#define PCIE_ATR_ID(id) ((id) & GENMASK(3, 0))
+#define PCIE_ATR_TYPE_MEM PCIE_ATR_ID(0)
+#define PCIE_ATR_TYPE_IOPCIE_ATR_ID(1)
+#define PCIE_ATR_TLP_TYPE(type) (((type) << 16) & GENMASK(18, 16))
+#define PCIE_ATR_TLP_TYPE_MEM PCIE_ATR_TLP_TYPE(0)
+#define PCIE_ATR_TLP_TYPE_IOPCIE_ATR_TLP_TYPE(2)
+
+struct mtk_pcie {
+ void __iomem *base;
+ void *priv;
+ struct clk pl_250m_ck;
+ struct clk tl_26m_ck;
+ struct clk peri_26m_ck;
+ struct clk top_133m_ck;
+ struct reset_ctl reset_phy;
+ struct reset_ctl reset_mac;
+ struct phy phy;
+};
+
+static void mtk_pcie_config_tlp_header(const struct udevice *bus,
+ pci_dev_t devfn,
+ int where, int size)
+{
+ struct mtk_pcie *pcie = dev_get_priv(bus);
+ int bytes;
+ u32 val;
+
+ size = 1 << size;
+
[PATCH v2 01/14] phy: phy-mtk-tphy: add support for phy type switch
Add support for PHY type switch via the mediatek topmisc syscon.
This is needed on mt7981 to make the PCIe correctly work and display
LinkUp.
Follow the same implementation done on Linux kernel with the usage of
the mediatek,syscon-type property.
Example:
u3port0: usb-phy@11e10700 {
reg = <0x11e10700 0x900>;
clocks = < CK_TOP_USB3_PHY_SEL>;
clock-names = "ref";
#phy-cells = <1>;
mediatek,syscon-type = < 0x218 0>;
status = "okay";
};
Signed-off-by: Christian Marangi
---
drivers/phy/phy-mtk-tphy.c | 80 ++
1 file changed, 80 insertions(+)
diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index ea9edf212c6..24938c8d2e3 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -216,6 +218,14 @@
#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+/* PHY switch between pcie/usb3/sgmii/sata */
+#define USB_PHY_SWITCH_CTRL0x0
+#define RG_PHY_SW_TYPE GENMASK(3, 0)
+#define RG_PHY_SW_PCIE 0x0
+#define RG_PHY_SW_USB3 0x1
+#define RG_PHY_SW_SGMII0x2
+#define RG_PHY_SW_SATA 0x3
+
enum mtk_phy_version {
MTK_TPHY_V1 = 1,
MTK_TPHY_V2,
@@ -258,6 +268,10 @@ struct mtk_phy_instance {
u32 index;
u32 type;
+ struct regmap *type_sw;
+ u32 type_sw_reg;
+ u32 type_sw_index;
+
u32 eye_vrt;
u32 eye_term;
u32 discth;
@@ -617,6 +631,67 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
FIELD_PREP(PA6_RG_U2_PRE_EMP,
instance->pre_emphasis));
}
+/* type switch for usb3/pcie/sgmii/sata */
+static int phy_type_syscon_get(struct udevice *dev, struct mtk_phy_instance
*instance,
+ ofnode dn)
+{
+ struct ofnode_phandle_args args;
+ int err;
+
+ if (!ofnode_read_bool(dn, "mediatek,syscon-type"))
+ return 0;
+
+ err = ofnode_parse_phandle_with_args(dn, "mediatek,syscon-type",
+NULL, 2, 0, );
+ if (err)
+ return err;
+
+ instance->type_sw_reg = args.args[0];
+ instance->type_sw_index = args.args[1] & 0x3; /* <=3 */
+ instance->type_sw = syscon_node_to_regmap(args.node);
+ if (IS_ERR(instance->type_sw))
+ return PTR_ERR(instance->type_sw);
+
+ debug("phy-%s.%d: type_sw - reg %#x, index %d\n",
+ dev->name, instance->index, instance->type_sw_reg,
+ instance->type_sw_index);
+
+ return 0;
+}
+
+static int phy_type_set(struct mtk_phy_instance *instance)
+{
+ int type;
+ u32 offset;
+
+ if (!instance->type_sw)
+ return 0;
+
+ switch (instance->type) {
+ case PHY_TYPE_USB3:
+ type = RG_PHY_SW_USB3;
+ break;
+ case PHY_TYPE_PCIE:
+ type = RG_PHY_SW_PCIE;
+ break;
+ case PHY_TYPE_SGMII:
+ type = RG_PHY_SW_SGMII;
+ break;
+ case PHY_TYPE_SATA:
+ type = RG_PHY_SW_SATA;
+ break;
+ case PHY_TYPE_USB2:
+ default:
+ return 0;
+ }
+
+ offset = instance->type_sw_index * BITS_PER_BYTE;
+ regmap_update_bits(instance->type_sw, instance->type_sw_reg,
+ RG_PHY_SW_TYPE << offset, type << offset);
+
+ return 0;
+}
+
static int mtk_phy_init(struct phy *phy)
{
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
@@ -747,6 +822,7 @@ static int mtk_phy_xlate(struct phy *phy,
}
phy_parse_property(tphy, instance);
+ phy_type_set(instance);
return 0;
}
@@ -808,6 +884,10 @@ static int mtk_tphy_probe(struct udevice *dev)
>da_ref_clk);
if (err)
return err;
+
+ err = phy_type_syscon_get(dev, instance, subnode);
+ if (err)
+ return err;
}
return 0;
--
2.43.0
[PATCH v2 00/14] mediatek: cumulative trivial fix for OF_UPSTREAM support
This is an initial series that have all the initial trivial fixes required for usage of OF_UPSTREAM for the mediatek SoC This also contains the pcie-gen3 driver and the required tphy support driver to make it work. Subsequent series will follow with conversion of the mtk-clk to permit usage of OF_UPSTREAM and upstream clk ID. MT7981, MT7986 and MT7988 migration to upstream clock ID is complete and working on MT7623. Changes v2: - Add mt7986 and mt7988 apmixed trivial PATCH - Make phy for pcie optional (it is for mt7988) - Fix broken mmc patch Christian Marangi (13): phy: phy-mtk-tphy: add support for phy type switch spi: mtk_spim: add support for upstream mediatek,spi-ipm compatible net: mediatek: handle alternative name for pn_swap property i2c: mediatek: add support for optional arb and pmic clock serial: mediatek: add support for bus clock and enable it serial: mediatek: add special handling for highspeed and linux compat mmc: mediatek: add support for upstream linux clock and property clk: mediatek: mt7981: support alternative compatible for fixed-plls pinctrl: mediatek: add support for gpio-controller property in root node pinctrl: mediatek: mt7981: init device before relocation pci: mediatek: make pcie-phy optional for gen3 clk: mediatek: mt7988: support alternative compatible for fixed-plls clk: mediatek: mt7986: support alternative compatible for fixed-plls John Crispin (1): pci: mediatek: add PCIe controller support for filogic silicon drivers/clk/mediatek/clk-mt7981.c | 1 + drivers/clk/mediatek/clk-mt7986.c | 1 + drivers/clk/mediatek/clk-mt7988.c | 1 + drivers/i2c/mtk_i2c.c | 30 ++ drivers/mmc/mtk-sd.c | 35 +- drivers/net/mtk_eth.c | 4 +- drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pcie_mediatek_gen3.c | 384 ++ drivers/phy/phy-mtk-tphy.c| 80 drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 + drivers/serial/serial_mtk.c | 27 +- drivers/spi/mtk_spim.c| 45 +- 14 files changed, 613 insertions(+), 14 deletions(-) create mode 100644 drivers/pci/pcie_mediatek_gen3.c -- 2.43.0
[PATCH v2 2/5] bootstd: Add bootflow_iter_check_mmc() helper
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk
Signed-off-by: Mattijs Korpershoek
---
boot/bootflow.c| 12
include/bootflow.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 9aa3179c3881..59d77d2385f4 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -575,6 +575,18 @@ int bootflow_iter_check_blk(const struct bootflow_iter
*iter)
return -ENOTSUPP;
}
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter)
+{
+ const struct udevice *media = dev_get_parent(iter->dev);
+ enum uclass_id id = device_get_uclass_id(media);
+
+ log_debug("uclass %d: %s\n", id, uclass_get_name(id));
+ if (id == UCLASS_MMC)
+ return 0;
+
+ return -ENOTSUPP;
+}
+
int bootflow_iter_check_sf(const struct bootflow_iter *iter)
{
const struct udevice *media = dev_get_parent(iter->dev);
diff --git a/include/bootflow.h b/include/bootflow.h
index 080ee8501225..6058ddd89b16 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -407,6 +407,15 @@ void bootflow_remove(struct bootflow *bflow);
*/
int bootflow_iter_check_blk(const struct bootflow_iter *iter);
+/**
+ * bootflow_iter_check_mmc() - Check that a bootflow uses a MMC device
+ *
+ * This checks the bootdev in the bootflow to make sure it uses a mmc device
+ *
+ * Return: 0 if OK, -ENOTSUPP if some other device is used (e.g. ethernet)
+ */
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter);
+
/**
* bootflow_iter_check_sf() - Check that a bootflow uses SPI FLASH
*
--
2.45.2
[PATCH v2 1/5] boot: android: Provide vendor_bootimg_addr in boot_get_fdt()
When calling android_image_get_dtb_by_index() using boot image v3+,
we should also pass the vendor_boot ramdisk address.
Use get_avendor_bootimg_addr() to do so.
Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
returns -1.
for legacy implementations that don't have CMD_ABOOTIMG, add a weak
implementation to avoid linking errors.
Signed-off-by: Mattijs Korpershoek
---
boot/image-android.c | 5 +
boot/image-fdt.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/boot/image-android.c b/boot/image-android.c
index ee626972c114..09c7a44e058a 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -56,6 +56,11 @@ static ulong add_trailer(ulong bootconfig_start_addr, ulong
bootconfig_size)
return BOOTCONFIG_TRAILER_SIZE;
}
+__weak ulong get_avendor_bootimg_addr(void)
+{
+ return -1;
+}
+
static void android_boot_image_v3_v4_parse_hdr(const struct
andr_boot_img_hdr_v3 *hdr,
struct andr_image_data *data)
{
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 56dd7687f51c..8332792b8e80 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -502,7 +502,7 @@ int boot_get_fdt(void *buf, const char *select, uint arch,
* Firstly check if this android boot image has dtb field.
*/
dtb_idx = (u32)env_get_ulong("adtb_idx", 10, 0);
- if (android_image_get_dtb_by_index((ulong)hdr, 0,
+ if (android_image_get_dtb_by_index((ulong)hdr,
get_avendor_bootimg_addr(),
dtb_idx, _addr,
_size)) {
fdt_blob = (char *)map_sysmem(fdt_addr, 0);
if (fdt_check_header(fdt_blob))
--
2.45.2
[PATCH v2 0/5] bootstd: Add Android support
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 Signed-off-by: Mattijs Korpershoek --- Changes in v2: - Dropped patch 2/6 boot: android: Add image_android_get_version() (Igor) - Fixed multi-line comment style (Igor, Simon) - Added dependency on CMD_FASTBOOT for BOOTMETH_ANDROID (Igor) - Fixed various resource leaks (Igor) - Fixed bootmeth_priv dangling pointer on error cases (Igor) - Updated test instructions in commit message for patch 6/6 - Added __weak impl of get_avendor_bootimg_addr() in patch 1 (dropped Igor's review because of this change) - Added extra info in Kconfig to detail MMC limitation (Simon) - Fixed typo Bootmethod->Bootmeth (Simon) - Documented android_priv structure (Simon) - Demoted various messages from printf() to log_debug (Simon) - Fixed some lines too long (Simon) - Added function documentation to read_slotted_partition() (Simon) - Added some doc about avb extra_args being modified (Simon) - Link to v1: https://lore.kernel.org/r/20240606-bootmeth-android-v1-0-0c69d4457...@baylibre.com --- Mattijs Korpershoek (5): boot: android: Provide vendor_bootimg_addr in boot_get_fdt() bootstd: Add bootflow_iter_check_mmc() helper android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr() bootstd: Add a bootmeth for Android bootstd: Add test for bootmeth_android MAINTAINERS | 7 + arch/sandbox/dts/test.dts | 8 + boot/Kconfig | 16 ++ boot/Makefile | 2 + boot/bootflow.c | 12 + boot/bootmeth_android.c | 553 ++ boot/bootmeth_android.h | 29 +++ boot/image-android.c | 5 + boot/image-fdt.c | 2 +- cmd/abootimg.c| 10 + configs/sandbox_defconfig | 2 +- doc/develop/bootstd.rst | 6 + include/bootflow.h| 9 + include/image.h | 14 ++ test/boot/bootflow.c | 65 +- test/py/tests/test_ut.py | 76 +++ 16 files changed, 811 insertions(+), 5 deletions(-) --- base-commit: f9886bc60f42d5bcfcfa4e474af7dc230400b6be change-id: 20240605-bootmeth-android-bfc8596e9367 Best regards, -- Mattijs Korpershoek
[PATCH v2 3/5] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk
Signed-off-by: Mattijs Korpershoek
---
cmd/abootimg.c | 10 ++
include/image.h | 14 ++
2 files changed, 24 insertions(+)
diff --git a/cmd/abootimg.c b/cmd/abootimg.c
index 327712a536c0..ae7a1a7c83b0 100644
--- a/cmd/abootimg.c
+++ b/cmd/abootimg.c
@@ -22,6 +22,11 @@ ulong get_abootimg_addr(void)
return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
}
+void set_abootimg_addr(ulong addr)
+{
+ _abootimg_addr = addr;
+}
+
ulong get_ainit_bootimg_addr(void)
{
return _ainit_bootimg_addr;
@@ -32,6 +37,11 @@ ulong get_avendor_bootimg_addr(void)
return _avendor_bootimg_addr;
}
+void set_avendor_bootimg_addr(ulong addr)
+{
+ _avendor_bootimg_addr = addr;
+}
+
static int abootimg_get_ver(int argc, char *const argv[])
{
const struct andr_boot_img_hdr_v0 *hdr;
diff --git a/include/image.h b/include/image.h
index c5b288f62b44..df2decbf5c2a 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1970,6 +1970,13 @@ bool is_android_vendor_boot_image_header(const void
*vendor_boot_img);
*/
ulong get_abootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android boot image address
+ *
+ * Return: no returned results
+ */
+void set_abootimg_addr(ulong addr);
+
/**
* get_ainit_bootimg_addr() - Get Android init boot image address
*
@@ -1984,6 +1991,13 @@ ulong get_ainit_bootimg_addr(void);
*/
ulong get_avendor_bootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android vendor boot image address
+ *
+ * Return: no returned results
+ */
+void set_avendor_bootimg_addr(ulong addr);
+
/**
* board_fit_config_name_match() - Check for a matching board name
*
--
2.45.2
Pull request efi-2024-07-rc5 for branch master
Dear Tom, The following changes since commit 1ebd659cf020843fd8e8ef90d85a66941cbab6ec: Merge tag 'u-boot-dfu-20240606' of https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-06-06 08:24:15 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2024-07-rc5 for you to fetch changes up to f3b6228ef4ee6918a9e1ec1db399ede057308a13: doc/sphinx, test/py: Update requests module to 2.32.2 (2024-06-10 15:05:30 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21060 Pull request efi-2024-07-rc5 Documentation: * update build dependency Python request module to version 2.32.2 * fix typos UEFI: * Correct signature check when appending to EFI variables. Mattijs Korpershoek (1): doc: cmd: bootmeth: Fix extlinunx -> extlinux typo Michal Simek (1): efi_loader: Fix capsule_esl.dtsi.in comment style Tom Rini (1): doc/sphinx, test/py: Update requests module to 2.32.2 Weizhao Ouyang (1): efi_loader: Fix EFI_VARIABLE_APPEND_WRITE hash check doc/sphinx/requirements.txt| 2 +- doc/usage/cmd/bootmeth.rst | 2 +- lib/efi_loader/capsule_esl.dtsi.in | 4 ++-- lib/efi_loader/efi_variable.c | 6 +++--- test/py/requirements.txt | 2 +- test/py/tests/test_efi_secboot/conftest.py | 10 ++ test/py/tests/test_efi_secboot/test_authvar.py | 4 ++-- test/py/tests/test_efi_secboot/test_signed.py | 10 +- 8 files changed, 25 insertions(+), 15 deletions(-)
[PATCH RFC] gpio: Fix probing of gpio-hogs
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; } } }
[PATCH] arm: fsl: imx6ulz_bsh_smm_m2: Migrate to OF_UPSTREAM
Migrate imx6ulz_bsh_smm_m2 board to OF_UPSTREAM.
Signed-off-by: Patrick Barsanti
---
This breaks compilation because upstream and local DTs are different.
The Makefile gives priority to the local DT headers, which are missing
a define, specifically in `imx6ul-clock.h`. As of now, upstreamed boards
are being compiled potentially using some legacy files.
Because of this, this patch requires patch [1] to be applied first.
Links:
- [1]
https://lore.kernel.org/u-boot/20240603150749.507797-1-patrick.barsa...@amarulasolutions.com/
arch/arm/dts/Makefile | 1 -
arch/arm/dts/imx6ulz-bsh-smm-m2.dts | 146
arch/arm/mach-imx/mx6/Kconfig | 1 +
configs/imx6ulz_smm_m2_defconfig| 2 +-
4 files changed, 2 insertions(+), 148 deletions(-)
delete mode 100644 arch/arm/dts/imx6ulz-bsh-smm-m2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1196ab040a..2c43bdbc19 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -871,7 +871,6 @@ dtb-$(CONFIG_MX6ULL) += \
imx6ull-phytec-segin-ff-rdk-emmc.dtb \
imx6ull-dart-6ul.dtb \
imx6ull-somlabs-visionsom.dtb \
- imx6ulz-bsh-smm-m2.dtb \
imx6ulz-14x14-evk.dtb
dtb-$(CONFIG_ARCH_MX6) += \
diff --git a/arch/arm/dts/imx6ulz-bsh-smm-m2.dts
b/arch/arm/dts/imx6ulz-bsh-smm-m2.dts
deleted file mode 100644
index 59bcfc9a6b..00
--- a/arch/arm/dts/imx6ulz-bsh-smm-m2.dts
+++ /dev/null
@@ -1,146 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Copyright (C) 2021 BSH Hausgeraete GmbH
- */
-
-/dts-v1/;
-
-#include
-#include "imx6ulz.dtsi"
-
-/ {
- model = "BSH SMM M2";
- compatible = "bsh,imx6ulz-bsh-smm-m2", "fsl,imx6ull", "fsl,imx6ulz";
-
- chosen {
- stdout-path =
- };
-
- usdhc2_pwrseq: usdhc2-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = < 21 GPIO_ACTIVE_LOW>;
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_gpmi_nand>;
- nand-on-flash-bbt;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_uart3>;
- uart-has-rtscts;
- status = "okay";
-
- bluetooth {
- compatible = "brcm,bcm4330-bt";
- max-speed = <300>;
- shutdown-gpios = < 1 GPIO_ACTIVE_HIGH>;
- device-wakeup-gpios = < 17 GPIO_ACTIVE_HIGH>;
- host-wakeup-gpios = < 13 GPIO_ACTIVE_HIGH>;
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_uart4>;
- status = "okay";
-};
-
- {
- dr_mode = "peripheral";
- srp-disable;
- hnp-disable;
- adp-disable;
- status = "okay";
-};
-
- {
- fsl,tx-d-cal = <106>;
-};
-
- {
- #address-cells = <1>;
- #size-cells = <0>;
- pinctrl-names = "default";
- pinctrl-0 = <_wlan>;
- bus-width = <4>;
- no-1-8-v;
- non-removable;
- cap-power-off-card;
- keep-power-in-suspend;
- cap-sdio-irq;
- mmc-pwrseq = <_pwrseq>;
- status = "okay";
-
- brcmf: wifi@1 {
- reg = <1>;
- compatible = "brcm,bcm4329-fmac";
- interrupt-parent = <>;
- interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "host-wake";
- };
-};
-
- {
- status = "okay";
-};
-
- {
- pinctrl_gpmi_nand: gpmi-nand {
- fsl,pins = <
- MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0xb0b1
- MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0xb0b1
- MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0xb0b1
- MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb000
- MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0xb0b1
- MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0xb0b1
- MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0xb0b1
- MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0xb0b1
- MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0xb0b1
- MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0xb0b1
- MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0xb0b1
- MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0xb0b1
- MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0xb0b1
- MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0xb0b1
- MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0xb0b1
- >;
- };
-
- pinctrl_uart3: uart3grp {
- fsl,pins = <
- MX6UL_PAD_UART3_TX_DATA__UART3_DCE_TX 0x1b0b1
- MX6UL_PAD_UART3_RX_DATA__UART3_DCE_RX 0x1b099
- MX6UL_PAD_UART3_RTS_B__UART3_DCE_RTS0x1b0b1
- MX6UL_PAD_UART3_CTS_B__UART3_DCE_CTS0x1b099
- MX6UL_PAD_GPIO1_IO01__GPIO1_IO01
[PATCH v2 5/5] bootstd: Add test for bootmeth_android
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_abootimg # build bootv4.img
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Reviewed-by: Simon Glass
Signed-off-by: Mattijs Korpershoek
---
arch/sandbox/dts/test.dts | 8 +
configs/sandbox_defconfig | 2 +-
test/boot/bootflow.c | 65 ++--
test/py/tests/test_ut.py | 76 +++
4 files changed, 147 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index a012f5c4c9ba..5fb5eac862ec 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -43,6 +43,7 @@
mmc4 = "/mmc4";
mmc5 = "/mmc5";
mmc6 = "/mmc6";
+ mmc7 = "/mmc7";
pci0 =
pci1 =
pci2 =
@@ -1129,6 +1130,13 @@
filename = "mmc6.img";
};
+ /* This is used for Android tests */
+ mmc7 {
+ status = "disabled";
+ compatible = "sandbox,mmc";
+ filename = "mmc7.img";
+ };
+
pch {
compatible = "sandbox,pch";
};
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 93b52f2de5cf..bc4398f101a7 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -15,6 +15,7 @@ CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTMETH_ANDROID=y
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_MEASURED_BOOT=y
CONFIG_BOOTSTAGE=y
@@ -40,7 +41,6 @@ CONFIG_LOG_MAX_LEVEL=9
CONFIG_LOG_DEFAULT_LEVEL=6
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_STACKPROTECTOR=y
-CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
CONFIG_CMD_LICENSE=y
CONFIG_CMD_SMBIOS=y
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 4511cfa7f9bf..934c4dcbad2b 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -27,6 +27,7 @@
DECLARE_GLOBAL_DATA_PTR;
+extern U_BOOT_DRIVER(bootmeth_android);
extern U_BOOT_DRIVER(bootmeth_cros);
extern U_BOOT_DRIVER(bootmeth_2script);
@@ -518,12 +519,12 @@ BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM |
UT_TESTF_SCAN_FDT);
* @uts: Unit test state
* @mmc_dev: MMC device to use, e.g. "mmc4". Note that this must remain valid
* in the caller until
- * @bind_cros: true to bind the ChromiumOS bootmeth
+ * @bind_cros: true to bind the ChromiumOS and Android bootmeths
* @old_orderp: Returns the original bootdev order, which must be restored
* Returns 0 on success, -ve on failure
*/
static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev,
- bool bind_cros, const char ***old_orderp)
+ bool bind_cros_android, const char ***old_orderp)
{
static const char *order[] = {"mmc2", "mmc1", NULL, NULL};
struct udevice *dev, *bootstd;
@@ -545,12 +546,19 @@ static int prep_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
"bootmeth_script", 0, ofnode_null(), ));
/* Enable the cros bootmeth if needed */
- if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros) {
+ if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros_android) {
ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_cros),
"cros", 0, ofnode_null(), ));
}
+ /* Enable the android bootmeths if needed */
+ if (IS_ENABLED(CONFIG_BOOTMETH_ANDROID) && bind_cros_android) {
+ ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
+ ut_assertok(device_bind(bootstd,
DM_DRIVER_REF(bootmeth_android),
+ "android", 0, ofnode_null(), ));
+ }
+
/* Change the order to include the device */
std = dev_get_priv(bootstd);
old_order = std->bootdev_order;
@@ -589,6 +597,37 @@ static int scan_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
return 0;
}
+/**
+ * scan_mmc_android_bootdev() - Set up an mmc bootdev so we can access other
+ * distros. Android bootflow might print "ANDROID:*" while scanning
+ *
+ * @uts: Unit test state
+ * @mmc_dev: MMC device to use, e.g. "mmc4"
+ * Returns 0 on success, -ve on failure
+ */
+static int scan_mmc_android_bootdev(struct unit_test_state *uts, const char
*mmc_dev)
+{
+ struct bootstd_priv *std;
+ struct udevice *bootstd;
+ const
[PATCH v2 4/5] bootstd: Add a bootmeth for Android
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:
3.a. Get slot (A/B) from BCB
3.b. Run AVB (Android Verified Boot) on boot partitions
3.c. Load boot and vendor_boot partitions
3.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.
[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/
Reviewed-by: Simon Glass
Signed-off-by: Mattijs Korpershoek
---
MAINTAINERS | 7 +
boot/Kconfig| 16 ++
boot/Makefile | 2 +
boot/bootmeth_android.c | 553
boot/bootmeth_android.h | 29 +++
doc/develop/bootstd.rst | 6 +
6 files changed, 613 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66783d636e3d..6d2b87720565 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -939,6 +939,13 @@ F: include/bootstd.h
F: net/eth_bootdevice.c
F: test/boot/
+BOOTMETH_ANDROID
+M: Mattijs Korpershoek
+S: Maintained
+T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git
+F: boot/bootmeth_android.c
+F: boot/bootmeth_android.h
+
BTRFS
M: Marek Behún
R: Qu Wenruo
diff --git a/boot/Kconfig b/boot/Kconfig
index 6f3096c15a6f..88266c8d2ed3 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -494,6 +494,22 @@ config BOOTMETH_GLOBAL
EFI bootmgr, since they take full control over which bootdevs are
selected to boot.
+config BOOTMETH_ANDROID
+ bool "Bootdev support for Android"
+ depends on X86 || ARM || SANDBOX
+ select ANDROID_AB
+ select ANDROID_BOOT_IMAGE
+ select CMD_BCB
+ select CMD_FASTBOOT
+ select PARTITION_TYPE_GUID
+ select PARTITION_UUIDS
+ help
+ Enables support for booting Android using bootstd. Android requires
+ multiple partitions (misc, boot, vbmeta, ...) in storage for booting.
+
+ Note that only MMC bootdevs are supported at present. This is caused
+ by AVB being limited to MMC devices only.
+
config BOOTMETH_CROS
bool "Bootdev support for Chromium OS"
depends on X86 || ARM || SANDBOX
diff --git a/boot/Makefile b/boot/Makefile
index 84ccfeaecec4..75d1cd46fabf 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -66,3 +66,5 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_REQUEST) += vbe_request.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_OS) += vbe_simple_os.o
+
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_ANDROID) += bootmeth_android.o
diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
new file mode 100644
index ..6e8d3e615db0
--- /dev/null
+++ b/boot/bootmeth_android.c
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmeth for Android
+ *
+ * Copyright (C) 2024 BayLibre, SAS
+ * Written by Mattijs Korpershoek
+ */
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#if CONFIG_IS_ENABLED(AVB_VERIFY)
+#include
+#endif
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bootmeth_android.h"
+
+#define BCB_FIELD_COMMAND_SZ 32
+#define BCB_PART_NAME "misc"
+#define BOOT_PART_NAME "boot"
+#define VENDOR_BOOT_PART_NAME "vendor_boot"
+
+/**
+ * struct android_priv - Private data
+ *
+ * This is read from the disk and recorded for use when the full Android
+ * kernel must be loaded and booted
+ *
+ * @boot_mode: Requested boot mode (normal, recovery, bootloader)
+ * @slot: Nul-terminated partition slot suffix read from BCB ("a\0" or "b\0")
+ * @header_version: Android boot image header version
+ */
+struct android_priv {
+ enum android_boot_mode boot_mode;
+ char slot[2];
+ u32 header_version;
+};
+
+static int android_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+ /* This only works on mmc devices */
+ if (bootflow_iter_check_mmc(iter))
+ return log_msg_ret("mmc", -ENOTSUPP);
+
+ /*
+* This only works on whole devices, as
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
On 13/06/2024 09.32, Claudius Heine wrote: >> I'm just wondering if it's possible to have the server send some message >> to the client when the git protocol is used, for some deprecation period >> (6 months?), so a developer doing "git remote update" will get notified. >> He would then also have a chance to propagate that to whatever local CI >> he's responsible for, instead of only noticing when things do start >> breaking. > > We are using `git-daemon` and there is a `--accept-hook` which can print > a single line to the requestor, but only if the request is denied. > So there doesn't seem to be a way to implement a deprecation period. That's a pity. But perhaps, when it breaks again, you could still make use of this to keep a stub up and running for a while: point --accept-hook at a two-liner script that just prints a notice that the git protocol has been disabled, what to use instead, and exit 1. That will still be nicer than just "connection refused". You could also point the user at some mailing list thread (this, or a new post when you do pull the plug) with a bit more info than what can reasonably fit in that --accept-hook message. Rasmus
[PATCH] board: beagleplay: Fix the bootpart to pick from root partition
The Kernel Image and DTB files are supposed to be picked from the rootfs
of the SD Card, this fails in legacy boot flow because bootpart is set
to 1:1. Fix it.
Fixes: a200f428b5b21 ("board: ti: am62x: Add am62x_beagleplay_* defconfigs and
env file")
Signed-off-by: Dhruva Gole
---
board/beagle/beagleplay/beagleplay.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/beagle/beagleplay/beagleplay.env
b/board/beagle/beagleplay/beagleplay.env
index bbf6b925d02c..190181c8ad0c 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -11,7 +11,7 @@ set_led_state_start_load=led led-0 on; led led-1 off;
led led-2 on; led led-3 off; led led-4 on
boot=mmc
mmcdev=1
-bootpart=1:1
+bootpart=1:2
bootdir=/boot
boot_targets=mmc1 mmc0
bootmeths=script extlinux efi pxe
--
2.34.1
Re: [PATCH 1/3] doc: board: phytec: phycore-am62x: Fix Link to Documentation
Am 12.06.24 um 18:16 schrieb Daniel Schultz: We moved our documentation to another hoster and therefore the URL changed. Point to the latest documentation instead of release versions to not link out-dated documentation. Signed-off-by: Daniel Schultz For all three patches, Reviewed-by: Wadim Egorov --- doc/board/phytec/phycore-am62x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst index bc6d5246694..681ac536125 100644 --- a/doc/board/phytec/phycore-am62x.rst +++ b/doc/board/phytec/phycore-am62x.rst @@ -155,4 +155,4 @@ Further Information --- Please see :doc:`../ti/am62x_sk` chapter for further AM62 SoC related documentation -and https://docs.phytec.com/phycore-am62x for vendor documentation. +and https://docs.phytec.com/projects/yocto-phycore-am62x/en/latest/ for vendor documentation.
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
Hi Quentin, On 2024-06-12 12:37 pm, Quentin Schulz wrote: Hi Claudius, On 6/12/24 12:20 PM, Claudius Heine wrote: Hi everyone, in the past we used cgit, which provided cloning the u-boot repo via http, https, ssh and the git protocol. When we migrated to gitlab, which doesn't support the git protocol, we implemented some additional service files to continue to support it for some of our git repositories. We just noticed that cloning via the git protocol is currently broken, likely some changes in gitlab happened and we would need to recreate the symlinks on the server to point to the right repositories again. Since that is another thing to maintain and keep up, we would like to just shut the git protocol down. AFAIK most projects moved to use https for cloning anyway, since there were not many reports of broken cloning. What are your thoughts? Is it worth the effort to keep the git protocol up? On the side of OpenEmbedded-Core, HTTPS is being used since Langdale (4.1) and the first dot release of Kirkstone (4.0.1) so only outdated layers would be impacted (provided they aren't already, but since there's a download cache system in Yocto, it's possible they're hitting their own local cache instead of fetching it from your server(s)). It's never nice to see things going/breaking compatibility because it may break old builds which is always a nice trick up one's sleeve to figure out when things started to go wrong in one's image. Well, this happens all the time, but maintaining backwards compatibility here should be done in a best-effort way. With old build, they likely need old compilers and systems, which will probably break anyway if they use https or ssh, because obsolete crypto. If people want to build old stuff, they probably have to fiddle around everywhere anyway, or have a download cache. The internet, or any network, isn't nice to old systems... Also, while I checked OE-Core, other third party/community maintained layer could be impacted. I assume this is the case of meta-amarula-engicam[1] and meta-allwinner-hx[2] for example. I would suggest sending a mail to the different build systems mailing lists, I assume https://lists.openembedded.org/g/openembedded-devel and https://lists.yoctoproject.org/g/yocto for the OE-Core/YP side? Either to ask for their opinion or notify them (and specifically third party layers) it's going away or both. Not sure if I want to go through them all. Looking into all these 3rd party, downstream repos and informing everyone seems to be even more effort than maintaining the git protocol. And if someone uses their repo, they will notice it quickly and can easily fix it. Anyway, I fixed it yesterday, and it doesn't make much sense to stop it now. So I will leave it in place until it breaks again, then I just remove it. thanks everyone for their input, Claudius [1] https://github.com/amarula/meta-amarula-engicam/blob/master/recipes-bsp/u-boot/u-boot-common_2018.05.inc [2] https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-bsp/u-boot/u-boot-common.inc Cheers, Quentin -- DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)
Hi Rasmus, On 2024-06-12 1:18 pm, Rasmus Villemoes wrote: On 12/06/2024 12.20, Claudius Heine wrote: Hi everyone, in the past we used cgit, which provided cloning the u-boot repo via http, https, ssh and the git protocol. When we migrated to gitlab, which doesn't support the git protocol, we implemented some additional service files to continue to support it for some of our git repositories. We just noticed that cloning via the git protocol is currently broken, likely some changes in gitlab happened and we would need to recreate the symlinks on the server to point to the right repositories again. Since that is another thing to maintain and keep up, we would like to just shut the git protocol down. AFAIK most projects moved to use https for cloning anyway, since there were not many reports of broken cloning. What are your thoughts? Is it worth the effort to keep the git protocol up? So I don't think you should necessarily keep the git:// working if it means extra maintenance. I just checked a couple of my local copies of u-boot.git (don't ask, it's many different customer projects) and it seems to be more or less random if I added upstream with git:// or https:// . I can certainly change those, and thanks for the heads up. I'm just wondering if it's possible to have the server send some message to the client when the git protocol is used, for some deprecation period (6 months?), so a developer doing "git remote update" will get notified. He would then also have a chance to propagate that to whatever local CI he's responsible for, instead of only noticing when things do start breaking. We are using `git-daemon` and there is a `--accept-hook` which can print a single line to the requestor, but only if the request is denied. So there doesn't seem to be a way to implement a deprecation period. regards, Claudius -- DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM
Hi Sumit On Thu, Jun 13, 2024 at 9:02 AM Sumit Garg wrote: > > On Mon, 3 Jun 2024 at 20:38, Patrick Barsanti > wrote: > > > > Always prioritizing u-boot includes causes problems when trying to migrate > > boards to OF_UPSTREAM that have different local devicetree files with > > respect to the upstream ones, if local DT headers are not dropped. > > At the same time if local and upstream files are the same, migrations > > can be, and have been, introduced without dropping local DT headers. > > This also causes problems whenever upstream DTS and DT headers are patched. > > > > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM > > breaks it, as there are some missing defines in a local DT header file > > (`imx6ul-clock.h`); the solution would be to drop it, which has not always > > been done in previous OF_UPSTREAM migration patches for other boards > > because most of the time the two are the same. This solution is also > > vulnerable to ABI breakage, although this has not yet happened since the > > introduction of OF_UPSTREAM support and is unlikely. > > > > Maintainers assure backwards compatibility for DT headers when syncing the > > upstream folder with the kernel. > > The problem is that, at the current state, all boards that have not dropped > > their local headers when migrating to OF_UPSTREAM will break once the > > upstream devicetrees are patched, for example, to use any newly added > > define which is not present in the local DT header file, even if those > > changes are backwards compatible. > > > > This patch fixes these problems by prioritizing upstream includes when > > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is > > not. > > > > Also in case of ABI breakage in the kernel, keeping redundant header files > > (only until strictly necessary, e.g. until all boards including them have > > been migrated to OF_UPSTREAM) together with this selective prioritization > > of the include folder is a solution for keeping not-yet-migrated boards > > from breaking. > > Let's just not try to make assumptions about DT ABI breakage due to > using upstream headers for not-yet-migrated boards but rather talk > about some real world examples. Have you come across any DT ABI > breakage with usage of upstream headers? The breakage you have > reported is due to usage of an old local copy of DT header. > The include priority is broken, and this a Makefile problem anyway. This patch fix anyway includes priorities. The imx6 board migration for us does not work > However, if this patch is only needed to address fear of DT ABI > breakage (which hasn't happened in the past) then I can live with it > such that it can help convince more people for OF_UPSTREAM migration. > We can drop local DT headers as and when people feel comfortable with > upstream. It's not abi breakage only but path inclusion order. Michael > > -Sumit > > > > > Link: > > https://lore.kernel.org/u-boot/20240528084224.113385-1-patrick.barsa...@amarulasolutions.com/ > > Signed-off-by: Patrick Barsanti > > Tested-by: Michael Trimarchi > > --- > > > > Changes in v2: > > - Reword and correct the commit message following the discussion > > with Sumit, per Michael's suggestion. > > > > Makefile | 14 ++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index 79b28c2d81..899ae664ca 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g) > > > > # Use UBOOTINCLUDE when you must reference the include/ directory. > > # Needed to be compatible with the O= option > > +ifeq ($(CONFIG_OF_UPSTREAM),y) > > +UBOOTINCLUDE:= \ > > + -I$(srctree)/dts/upstream/include \ > > + -Iinclude \ > > + $(if $(KBUILD_SRC), -I$(srctree)/include) \ > > + $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \ > > + $(if $(CONFIG_HAS_THUMB2), \ > > + $(if $(CONFIG_CPU_V7M), \ > > + -I$(srctree)/arch/arm/thumb1/include), \ > > + -I$(srctree)/arch/arm/thumb1/include)) \ > > + -I$(srctree)/arch/$(ARCH)/include \ > > + -include $(srctree)/include/linux/kconfig.h > > +else > > UBOOTINCLUDE:= \ > > -Iinclude \ > > $(if $(KBUILD_SRC), -I$(srctree)/include) \ > > @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \ > > -I$(srctree)/arch/$(ARCH)/include \ > > -include $(srctree)/include/linux/kconfig.h \ > > -I$(srctree)/dts/upstream/include > > +endif > > > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > > -print-file-name=include) > > > > -- > > 2.45.1 > > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM
On Mon, 3 Jun 2024 at 20:38, Patrick Barsanti wrote: > > Always prioritizing u-boot includes causes problems when trying to migrate > boards to OF_UPSTREAM that have different local devicetree files with > respect to the upstream ones, if local DT headers are not dropped. > At the same time if local and upstream files are the same, migrations > can be, and have been, introduced without dropping local DT headers. > This also causes problems whenever upstream DTS and DT headers are patched. > > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM > breaks it, as there are some missing defines in a local DT header file > (`imx6ul-clock.h`); the solution would be to drop it, which has not always > been done in previous OF_UPSTREAM migration patches for other boards > because most of the time the two are the same. This solution is also > vulnerable to ABI breakage, although this has not yet happened since the > introduction of OF_UPSTREAM support and is unlikely. > > Maintainers assure backwards compatibility for DT headers when syncing the > upstream folder with the kernel. > The problem is that, at the current state, all boards that have not dropped > their local headers when migrating to OF_UPSTREAM will break once the > upstream devicetrees are patched, for example, to use any newly added > define which is not present in the local DT header file, even if those > changes are backwards compatible. > > This patch fixes these problems by prioritizing upstream includes when > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is > not. > > Also in case of ABI breakage in the kernel, keeping redundant header files > (only until strictly necessary, e.g. until all boards including them have > been migrated to OF_UPSTREAM) together with this selective prioritization > of the include folder is a solution for keeping not-yet-migrated boards > from breaking. Let's just not try to make assumptions about DT ABI breakage due to using upstream headers for not-yet-migrated boards but rather talk about some real world examples. Have you come across any DT ABI breakage with usage of upstream headers? The breakage you have reported is due to usage of an old local copy of DT header. However, if this patch is only needed to address fear of DT ABI breakage (which hasn't happened in the past) then I can live with it such that it can help convince more people for OF_UPSTREAM migration. We can drop local DT headers as and when people feel comfortable with upstream. -Sumit > > Link: > https://lore.kernel.org/u-boot/20240528084224.113385-1-patrick.barsa...@amarulasolutions.com/ > Signed-off-by: Patrick Barsanti > Tested-by: Michael Trimarchi > --- > > Changes in v2: > - Reword and correct the commit message following the discussion > with Sumit, per Michael's suggestion. > > Makefile | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Makefile b/Makefile > index 79b28c2d81..899ae664ca 100644 > --- a/Makefile > +++ b/Makefile > @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g) > > # Use UBOOTINCLUDE when you must reference the include/ directory. > # Needed to be compatible with the O= option > +ifeq ($(CONFIG_OF_UPSTREAM),y) > +UBOOTINCLUDE:= \ > + -I$(srctree)/dts/upstream/include \ > + -Iinclude \ > + $(if $(KBUILD_SRC), -I$(srctree)/include) \ > + $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \ > + $(if $(CONFIG_HAS_THUMB2), \ > + $(if $(CONFIG_CPU_V7M), \ > + -I$(srctree)/arch/arm/thumb1/include), \ > + -I$(srctree)/arch/arm/thumb1/include)) \ > + -I$(srctree)/arch/$(ARCH)/include \ > + -include $(srctree)/include/linux/kconfig.h > +else > UBOOTINCLUDE:= \ > -Iinclude \ > $(if $(KBUILD_SRC), -I$(srctree)/include) \ > @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \ > -I$(srctree)/arch/$(ARCH)/include \ > -include $(srctree)/include/linux/kconfig.h \ > -I$(srctree)/dts/upstream/include > +endif > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) > > -- > 2.45.1 >
