[PATCH v3 3/3] board: toradex: add verdin am62 support

[Francesco Dolcini]

Hello Tom, hello Nishanth,

On Mon, Jul 24, 2023 at 07:23:03PM -0400, Tom Rini wrote:
> On Mon, Jul 24, 2023 at 08:34:04PM +0000, Marcel Ziswiler wrote:
> > On Fri, 2023-07-21 at 08:37 -0500, Nishanth Menon wrote:
> > > On 09:40-20230715, Marcel Ziswiler wrote:
> > > > From: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> > > > 
> > > > This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT
> > > > V1.0A module. They are strapped to boot from their on-module eMMC.
> > > > U-Boot supports booting from the on-module eMMC only, DFU support is
> > > > disabled for now due to missing AM62x USB support.
> > > > 
> > > > Boot sequence is:
> > > > SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE
> > > >   ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img)
> > > > 
> > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> > > > 
> > > > ---
> > > > 
> > > > Changes in v3:
> > > > - Integrate our recent find of CTRL_SLEEP_MOCI# needing to be driven
> > > >   from A53 SPL as it may be used to control some power-rails on the
> > > >   carrier board. E.g. on the Yavia carrier board it is needed to power
> > > >   the I2C EEPROM on the carrier board.
> > > > - Improve boot environment in R5 SPL vs. A53.
> > > > - Integrate launch configuration SKUs to Wi-Fi handling.
> > > > - Re-sync device trees from Linux kernel v6.5-rc1.
> > > > - Add warning if memory is less than expected.
> > > 
> > > Thank you. we are in the middle of a bunch of cleanup for AM62 at the
> > > moment - fixing up mdio, dts, ethernet etc and introducing binman at the
> > > moment.
> > 
> > I am, of course, fully aware of this and actually internally do have patches on top of all such work which
> > already got posted to the mailing list to make sure our stuff also works with this.
> > 
> > I am also more than happy to provide more feedback to help in moving this all forward.
> > 
> > > I think it might be better to introduce new platforms with those
> > > changes incorporated.
> > 
> > While I do understand what you are saying I am also a little bit disappointed that we are now blocked since
> > more than one and a half months without a clear path/timeline moving forward.
> 
> I too am not thrilled with the overall state here.  When roughly will
> the dts files be able to be re-synced and we can move forward? Perhaps
> when the merge window opens in about 4 weeks?

I would propose the following:
 - we rebase this patch on top of the recent binman changes
 - we merge the DTS as it is. The sync of the DTS should not be a reason
   for postponing this series, you should be able to do it anytime.

This would allow us to move forward, as soon as this is merged we have
CI and tests running on tip of master, and it uses to provide some
valuable feedback.

Does it works for you all?

Francesco