On Mon, Sep 28, 2026 at 17:43:22 +0100, David Lechner wrote:
> On 9/23/26 4:17 PM, Carlo Caione wrote:
> > From: Julien Masson <[email protected]>
> >
> > Genio 510 and 700 need a way to provision blank eMMC and recover from
> > unusable boot firmware without relying on the installed bootloader.
> > Add a BootROM-loaded fastboot agent that also prepares the eMMC boot
> > settings so newly flashed firmware can boot.
> >
> > U-Boot proper is preferred when the complete agent fits BootROM's SRAM
> > download area before DRAM initialization. Provide the SPL alternative
> > for tighter payload budgets, avoiding the space required by BL31 and
> > U-Boot proper. An external DDR loader is still required.
>
> This is a bit short on details of why certain tecnical descisions are made
> in this patch.
I'll try to improve it when possible.
> > + /* Reset to x1 SDR, backward-compatible timing for each boot. */
> > + ret = mmc_set_boot_bus_width(mmc, 0, 0, 0);
> > + if (ret)
> > + printf("Cannot configure the eMMC boot bus: %d\n", ret);
> > +
> > + if (!mmc->ext_csd[EXT_CSD_RST_N_FUNCTION]) {
> > + ret = mmc_set_rst_n_function(mmc, 1);
>
> If I understand correctly, this makes a permanant change to the eMMC hardware.
> It is documented in patch 3, but I wonder if we should add a comment here too.
> And I wonder if anyone would not want that setting.
This was ported over from the downstream MTK code so I think that this
is actually needed. I'll add a comment here.
> > diff --git a/board/mediatek/MAINTAINERS b/board/mediatek/MAINTAINERS
> > index 20befdba0e2..61fefcf9a34 100644
> > --- a/board/mediatek/MAINTAINERS
> > +++ b/board/mediatek/MAINTAINERS
> > @@ -18,13 +18,18 @@ MT8188/MT8370/MT8390
> > M: Macpaul Lin <[email protected]>
> > M: Julien Stephan <[email protected]>
> > S: Maintained
> > +F: arch/arm/dts/mt8370-genio-da-u-boot.dtsi
> > F: arch/arm/dts/mt8370-genio-510-evk-u-boot.dtsi
> > F: arch/arm/dts/mt8390-genio-700-evk-u-boot.dtsi
> > F: arch/arm/dts/mt8390-genio-common-u-boot.dtsi
> > F: arch/arm/dts/mtk-genio-*-binman-u-boot.dtsi
> > F: arch/arm/dts/mtk-genio-binman-u-boot.dtsi
> > +F: configs/mt8370-genio-da-spl-fastboot.config
> > +F: configs/mt8370-genio-da.config
>
> These are not sorted in order.
:(
> > diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
> > index f296a72cf18..d8ef6e6afba 100644
> > --- a/drivers/usb/mtu3/mtu3_core.c
> > +++ b/drivers/usb/mtu3/mtu3_core.c
> > @@ -843,7 +843,10 @@ int ssusb_gadget_init(struct ssusb_mtk *ssusb)
> > mtu->mac_base = ssusb->mac_base;
> > mtu->ssusb = ssusb;
> > mtu->max_speed = usb_get_maximum_speed(dev_ofnode(ssusb->dev));
> > - mtu->force_vbus = dev_read_bool(ssusb->dev, "mediatek,force-vbus");
> > + /* Fixed peripheral mode must not depend on OTG session detection. */
>
> Why not? From what I am seeing in the Linux driver it doesn't do this.
> And I'm not sure why mt8183 has "mediatek,force-vbus" here in the U-boot
> devicetree. Maybe lack of proper pinmux for that target in U-boot?
>
> I feel like we should not be doing this for new boards. I would only expect
> to need to force vbus on a board where vbus wasn't wired up properly. That
> isn't the case here.
>
> Is fastboot broken without this change?
I tested it and it is not. So it looks like this change is actually not
really needed.
Thanks for the review,
--
Carlo Caione
