<smaeul>
it removes all of the #ifdefs for base addresses, register layouts, etc.
<smaeul>
it removes having a totally separate copy of the pinctrl setup
<smaeul>
and the clock gates
<apritzel>
I agree that the SPL clock setup is a total mess
sunshavi has quit [Ping timeout: 480 seconds]
<apritzel>
and I always hated to model MMIO register frames in structs
<smaeul>
as is the SPL pinctrl setup
<apritzel>
you mean those heavily ifdef'ed sunxi_gpio_set_cfgpin() calls?
<smaeul>
yes
<smaeul>
those all get replaced by the real pinctrl driver
<smaeul>
and things like the DT stdout path apply to SPL
<apritzel>
does your SPL_DM approach involve pulling the whole DT in, just a subset of it, or no DT at all?
<apritzel>
(I guess you mention H6 and newer because we are not limited to 32K there, right?)
<smaeul>
I'd like to put the whole DT in, to avoid annotating it, but right now annotating with u-boot,spl-dm is the only supported method
<smaeul>
(it's a trivial patch to remove the fdtgrep calls, but that would be a discussion with Simon)
<apritzel>
meh
<smaeul>
I tried OF_PLATDATA and it's a ton of work, and doesn't have any way to provide OF match data
<smaeul>
so I don't recommend it
<smaeul>
yes, H6 is when you have enough SRAM
hentai has joined #linux-sunxi
<smaeul>
oh, and we can do things like patch the DRAM size and the serial number into the DT :)
<smaeul>
instead of putting that in BL31
sunshavi has joined #linux-sunxi
<smaeul>
or using some custom ABI
<apritzel>
as you surely realised, I am not a big fan of DM_SPL.
<apritzel>
I actually think that the whole U-Boot framework in the SPL is more confusing than helpful, as actual code sharing between the SPL and U-Boot proper is quite limited, in reality
<apritzel>
I think the only really useful part is now the MMC framework
<apritzel>
and we would still need non-DM SPL support, for the older SoCs, right?
<smaeul>
we would be able to share clock/reset, pinctrl/gpio, i2c/rsb, pmic, regulator drivers
<smaeul>
yeah, it's definitely not everything, but not exactly trivial
<apritzel>
do you need to touch regulators in the SPL, for the D1? Like we do for the H616?
<smaeul>
no, D1 is a PMIC-less design. H616 would be the one that benefits there, or any future chip with the same requirement
<apritzel>
I think the H616 PMIC requirement for the DRAM is a mistake, as they used the wrong PMIC regulators for DRAM in their reference design
<apritzel>
or there was some issue with the PMIC, and they needed to switch rails
<smaeul>
the older SoCs all do their PMIC setup in SPL. I thought some of that was for DRAM?
<apritzel>
the A64/H3/H5/H6 don't, AFAIK, because the PMIC has a pin to set the reset voltage for the two DRAM rails to the right value, depending on the DRAM type you are using
sunshavi has quit [Read error: No route to host]
sunshavi has joined #linux-sunxi
<apritzel>
and the AXP305 has the same setup, but they wired the DRAM to different rails
<smaeul>
hmm, ok
<apritzel>
but I need to check the exact situation for the older SoCs
<apritzel>
smaeul: do you have some proof of concept DM_SPL code somewhere? Just to get an idea ...
<apritzel>
for this conceptually very questionable u-boot,dm-spl: can't we say we need MMC0 and UART0, and let some filter tool figure out the dependencies?
<smaeul>
that would make sense ;-)
<smaeul>
the tricky part is knowing which phandles to follow (e.g. clocks) and which to ignore (e.g. dmas)
<smaeul>
fdtgrep is definitely the most annoying part of DM_SPL
<smaeul>
(well technically SPL_OF_CONTROL)
<apritzel>
it wouldn't need to be the most versatile tool, to solve every kind of DT filter problem, so we could cut corners and just hardcode that? Or make this configurable (per platform)?
<apritzel>
or as a variation of that theme: extract the UART pins at *build time* from the DT, into a header file, for instance, then just have a very simple pinctrl setup code
<smaeul>
that's OF_PLATDATA :)
<smaeul>
well, sort of. I guess you mean generating straight-line code with magic numbers, but from the DT
<apritzel>
OF_PLATDATA> that was my impression, yes, but whenever I try to read up on that or try it, I get more confused
<apritzel>
generating magic numbers> yes, something like that
<apritzel>
I am trying to follow that idea that the SPL is some kind of the continuation of the BROM, just with some tiny bit of board specific knowledge
<smaeul>
it is enough to show how it generates structs for the DT nodes, which you can copy from instead of implementing of_to_plat
<smaeul>
and it generates the devices instances by matching driver -> DM_DRIVER_ALIAS -> compatible -> DTB
apritzel has quit [Ping timeout: 480 seconds]
rajkosto has quit [Ping timeout: 480 seconds]
<smaeul>
but it only sorta kinda rewrites the phandle references, and doesn't actually provide a way to use them, so things like clk_get_by_index() don't work
<smaeul>
and nodes without compatibles (i.e. pinctrl nodes) get ignored entirely
<smaeul>
hunbalazs: I don't see anything suspicious in either the dmesg or config. Maybe you're just missing the `rootwait` command line option? It looks like the kernel is still probing devices, so maybe it just hasn't gotten to mmc0 yet
<hunbalazs>
I already tried that
<hunbalazs>
same problem with patched 5.18.3 and 5.18.0-rc4
<hunbalazs>
uhh, if I enable CONFIG_RISCV_DMA_NONCOHERENT then I get the same crashes as before
<smaeul>
oh, that explains why mmc wasn't working. you definitely need that enabled
<hunbalazs>
I had that feeling
<hunbalazs>
I enabled CONFIG_RISCV_DMA_NONCOHERENT and disabled CONFIG_ERRATA_THEAD_CMO
<smaeul>
you need both of those
<hunbalazs>
now it doesn't crash, MMC does not init but I have an error: mmc0: unrecognised SCR structure version 10 \n mmc0: error -22 whilst initialising SD card
<smaeul>
that's the same issue that the kernel is reading garbage from the DMA buffer
<smaeul>
try, uh, adding "a0" to the clobber list of ALT_CMO_OP at the end of arch/riscv/include/asm/errata_list.h