On Thu, Jul 16, 2026 at 2:03 PM Tom Rini <[email protected]> wrote: > > On Sun, Jun 28, 2026 at 03:27:48PM -0600, James Hilliard wrote: > > On Sun, Jun 28, 2026 at 10:16 AM Andre Przywara <[email protected]> > > wrote: > > > > > > On Fri, 26 Jun 2026 14:51:50 -0600 > > > James Hilliard <[email protected]> wrote: > > > > > > Hi James, > > > > > > > sunxi SPL normally uses the legacy MMC interface while U-Boot > > > > proper uses the DM driver. Boards which enable SPL_DM_MMC need > > > > > > I think I mentioned this before: enabling the device model in the SPL > > > (or not) is not a *device* decision, but a platform one. > > > > I'm a bit confused here, uboot's configuration system from what I can tell > > is designed to allow enabling device model for specific devices and even > > for specific drivers. > > Right. And to be clear, in your tree you're working to upstream out of, > only the h616 platforms end up enabling SPL_DM and not all of the > existing ARCH_SUNXI, yes?
Well my uboot config is managed out of tree by buildroot technically. I've only tested on h616 myself. AFAIU SPL_DM for sunxi is not disabled by kconfig on sunxi platform as-is, it's just a bit broken at runtime I think. > > > Why would this need to be a platform level decision? Given that boards > > that don't have enough SRAM for SPL DM support tend to be older, we > > will presumably want to migrate newer boards to SPL DM at some point > > in the future anyways. > > > > > And for > > > technical reasons, mostly to support older devices, which have no other > > > choice, but also to keep it simple and the SPL small, we do not use DM > > > in the SPL on Allwinner boards. > > > > I mean, this seems to me to be justification for continuing to support > > legacy drivers, not justification for not supporting DM as well since there > > are also many sunxi boards that don't have that limitation. > > This would be a separate set of potential cleanups to evaluate later on. > > > > I see the SPL as the continuation of the > > > BootROM, which is completely board agnostic. > > > > At a minimum SPL is still fairly SoC specific. Although in practice it seems > > to not be all that board agnostic, I think if anything DM support makes it > > more agnostic by allowing better factoring of the device specific stuff. > > > > > The SPL can mimic this > > > behaviour, to follow the decisions that the BootROM made, for instance > > > about the boot device. The only difference here is the DRAM > > > initialisation, which requires some board specific data, but so far we > > > got away with just hardcoding it. > > > > This is one of a few reasons I wanted to get SPL DM functional on sunxi. > > > > > If that is not good anymore, I think > > > we can find other solutions than pulling in the whole world of SPL_DM > > > support. > > > > > > So what is the purpose of this exercise, why do you want DM_SPL > > > supported? > > > > Some cryptoengine uboot drivers I was working on adding seemed to > > need DM_SPL, also I think handling DRAM profiles becomes easier with > > it somewhat. > > > > > Keep in mind that there are 178 Allwinner boards supported in > > > U-Boot, so there better would be good reasons to change something > > > fundamental like this for all of them. It changing it for a number of > > > them is not better, because this doubles the test matrix, so we have to > > > test now that it works on both legacy and DM_SPL boards - which frankly > > > nobody will do. > > > > Well it doesn't actually double the test matrix since presumably boards > > that are not SPL DM compatible will continue to use non-DM drivers only. > > And today nothing ARCH_SUNXI enables SPL, but they all could enable it > today and get an assortment of failures. With what James is doing, some > could now enable it and have it work, or more easily work. There are plenty of sunxi board configs in uboot with SPL enabled, I think it's just SPL DM that's always disabled: https://github.com/u-boot/u-boot/blob/v2026.07/configs/yuzukihd-chameleon_defconfig > > Wouldn't we typically just pick either DM or non-DM configs for upstream > > uboot testing/configs for any particular board to avoid maintaining more > > configurations than necessary in the test matrix? > > > > > And aside from that, please do NOT add any more #ifdef's to the U-Boot > > > code. > > > > This seemed to be how other subsystems handled both DM and non-DM > > driver support, is there a better way? > > So looking at this patch, it needs to be split up a whole lot more, to > make it easier to review and clearer what's being changed. Also, there's > a lot of places in code where it looks like you're handling > dependencies that Kconfig should handle instead. By which I mean, if we > have SPL_DM_MMC and we're in the driver, we don't need to handle > SPL_DM_CLK=n or SPL_OF_REAL=n. You can find examples of that, but > they're older code that also needs to be cleaned up. It might be the > case that the driver itself needs some re-organization first to make > what your end goal needs, easier to do. Ok, I'll try and clean this up a bit and send a v2.
