ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<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 ...
<smaeul> yes, for D1, though it's really not cleaned up at the moment: https://github.com/smaeul/u-boot/commits/d1-spl
rajkosto has joined #linux-sunxi
<apritzel> I see, thanks, I will have a look
<smaeul> the existing board code effectively turns in to this: https://github.com/smaeul/u-boot/blob/d1-spl/board/sunxi/board-riscv.c#L91-L108
<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
<apritzel> smaeul: sorry, getting late here ...
<smaeul> no worries
<smaeul> I just pushed an OF_PLATDATA example if you're ever curious: https://github.com/smaeul/u-boot/commits/wip/spl-of-platdata
<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
hentai has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
rajkosto has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
anarsoul has quit [Quit: ZNC 1.8.2 - https://znc.in]
anarsoul has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 is now known as Daanct12
Daanct12 has quit [Ping timeout: 480 seconds]
buZz has quit [Ping timeout: 480 seconds]
buZz has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
Daaanct12 has quit [Quit: Leaving]
hlauer has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
JoaoSchim has quit [Remote host closed the connection]
JoaoSchim has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
machinehum1 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
cnxsoft1 has quit []
cnxsoft has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
hentai has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
rajkosto has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
rajkosto has quit [Ping timeout: 480 seconds]
hunbalazs has joined #linux-sunxi
<hunbalazs> hello, I'm trying to build a "stable" linux kernel (5.18.3 + smaeul's patches) for lichee RV dock but I always get a kernel error at boot
<hunbalazs> this is the .config I'm currently using: https://pastebin.com/SeZZnrhr
<hunbalazs> and this is the error I'm getting: https://pastebin.com/mdiSxuw5
<hunbalazs> I tried smaeul's riscv/d1-wip branch too but the only diffrence is that I get a different error: https://pastebin.com/q3RXecaR
<hunbalazs> did anyone experience something like this?
paulk-bis has joined #linux-sunxi
rajkosto has joined #linux-sunxi
<montjoie> I will retry on mine tonight
<hunbalazs> thanks
<hunbalazs> I'm currently checking the differences between mine and this: https://github.com/tmolteno/d1_build/blob/main/kernel/licheerv_linux_defconfig
<hunbalazs> debian images build with scripts from that repo works (mostly)
jakllsch has quit [Remote host closed the connection]
jakllsch has joined #linux-sunxi
<montjoie> hunbalazs: I got https://pastebin.com/4SKuBUgk
cnxsoft has quit []
<hunbalazs> montjoie: with my config?
Hypfer has quit [Ping timeout: 480 seconds]
Hypfer has joined #linux-sunxi
rajkosto has quit [Ping timeout: 480 seconds]
<montjoie> with the defconfig
<hunbalazs> I started stripping down the debian version but now it can't find the SD card
ftg has joined #linux-sunxi
<montjoie> it seems my sdcard die on it, i need to replace it
<smaeul> fwiw I have also seen random kernel splats like that before, but never consistent enough to debug them
<smaeul> possibly it's some issue with the cache or MMU code that gets patched in all over the kernel
<hunbalazs> I'm currently past that, now the MMC interface doesn't want to initialize
<hunbalazs> config: https://pastebin.com/FC9QBbD6
<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
<hunbalazs> it does not have a clobber list now?
<smaeul> yea, which is wrong
<hunbalazs> ok, added it
<hunbalazs> doesn't t3 need to be added to ALT_THEAD_PMA?
<hunbalazs> so yes :D
<hunbalazs> sadly it didn't fix it
<smaeul> yeah, I tried reverting that patch and couldn't reproduce it either. I am running out of ideas
jakllsch has quit [Ping timeout: 480 seconds]
<hunbalazs> 5.18.0-rc4: https://pastebin.com/t9L1SmnN
JohnDoe_71Rus has quit []
jakllsch has joined #linux-sunxi
jakllsch has quit [Quit: brb]
jakllsch has joined #linux-sunxi
apritzel has joined #linux-sunxi
vagrantc has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]