<smaeul>
apritzel: T113 should be able to use the D1 clock driver as-is. I don't think anyone's written a D1s/T113 pinctrl driver yet.
<smaeul>
xfel is a competitor to sunxi-tools. it's not a replacement for SPL on nonvolatile storage
<smaeul>
and since T113 == D1, the DRAM driver should work as-is too. IIRC Moe_Icenowy said it's similar to R329, but I haven't tried the R329 DRAM driver from her U-Boot series on D1 yet
<smaeul>
I somewhat tried the "creative" merging of clock drivers when writing A80 R_CCU support, but it was somewhat ugly, so I split it out. I can re-merge those so we have an example
adjtm is now known as Guest1130
Guest1130 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
adjtm is now known as Guest1132
Guest1132 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
<apritzel>
smaeul: I figured that the "new" H6 style clocks are unique across the SoCs (there seems to be some magic superset), so there are no conflicting register addresses
<apritzel>
(as in: if there is a PLL_GPU, it's always at 0x030, and other SoCs don't have anything at this address, if they lack this particular PLL)
<apritzel>
same of the mod clocks and gates
<apritzel>
which sounds like we could have a consistent numbering scheme, possibly reusing the same driver across multiple SoCs
<apritzel>
but of course there might be those annoying peculiarities, like different parent lists, which spoil this
<apritzel>
smaeul: I spent the whole afternoon on the V5 clock driver, and was wondering if we can avoid having to repeat this exercise for every little SoC variant that AW feels to send upon us
Guest1133 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
<apritzel>
smaeul: is sun55i this reportedly cancelled Cortex-A55 SoC? The T723, for instance?
adjtm has quit [Read error: Connection reset by peer]
<apritzel>
and there is a GICv3 driver in arch/arm/mach-sunxi (for whatever reason ...), and it's selected by MACH_SUN55IW3
<apritzel>
cpu_autogen.h mentions USB3.1 and PCIe, but again with the outbound window cooped into at most 6MB ...
<smaeul>
I don't know what (former) product it maps to. I haven't seen anything about it on AW's site, other than leftover sun55i* code files
evgeny_boger has joined #linux-sunxi
<apritzel>
yeah, CNX software once reported about the T723, with 8 Cortex-A55s, plus SATA, PCIe, USB3.1 (smells like RK3366/3368), but I guess we won't see this anytime soon (if at all)
<apritzel>
TLLim reporting about this "licensing from Arm China only" didn't sound good ...
apritzel has quit [Ping timeout: 480 seconds]
ftg has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
toorl has joined #linux-sunxi
toorl has quit []
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
tomf_ has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 480 seconds]
<jernej>
apritzel: how is your AC200 EPHY effort coming along?
macromorgan has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
Moe_Icenowy has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
vpeter has quit [Remote host closed the connection]
vpeter has joined #linux-sunxi
<LordKalma>
do you have any good way of using the linux headers in ghidra?
<LordKalma>
when I try to parse any one of them (i need couple complicated structs) it just errors out
apritzel has joined #linux-sunxi
<jernej>
LordKalma: it's tricky because there is a lot of dependencies
<jernej>
other way around is that you build a file yourself. start with struct you're interested in and add all dependencies by hand...
<LordKalma>
yeah, I think it'll have to be...
<jernej>
LordKalma: reverse engineering is often excersise in patience :)
<LordKalma>
hehe indeed
rajkosto has quit [Ping timeout: 480 seconds]
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger1 has quit [Remote host closed the connection]
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #linux-sunxi
cp- has quit []
cp- has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
aggi has quit [Quit: connection closed.]
ftg has joined #linux-sunxi
aggi has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.5]
megi has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
indy has joined #linux-sunxi
apritzel has joined #linux-sunxi
<LordKalma>
sooo, I was looking at the `struct spi_driver`
<LordKalma>
seems that it's common for the device drivers to only set some elements?
<LordKalma>
especially of it's `struct device_driver` member
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
aggi has quit [Quit: connection closed.]
<jernej>
some fields are optional and some mandatory
<jernej>
well, you should at least set probe and remove callbacks
<apritzel>
jernej: ac200: I am in the middle of implementing what I came up with this week. Was nice weather this afternoon, though, but shall rain all day tomorrow ;-)
<LordKalma>
but iirc it's a struct so it may have some other things in there
vagrantc has joined #linux-sunxi
<jernej>
it's ok, in first 0x20 locations is name and next 0x20 is type. compatible is after that and it nicely matches
<LordKalma>
In fact just noticed something
<LordKalma>
c0854cdc says "sitronix,st7701s" and after a bunch more zeros, c0854da0 "jinglitai,jlt4013a"
<LordKalma>
and "jinglitai,jlt4013a" is what the community found in the DTB from the original kernel
<LordKalma>
so two match strings? (although so far apart?)
<jernej>
how much apart? 0x100?
<jernej>
eh, 0xc0
<LordKalma>
0xc4?
<LordKalma>
c0854da0 – c0854cdc = C4
<jernej>
ah, yes, forgot one pointer
<jernej>
one driver can be compatible with multiple devices
<jernej>
that's usually done when they are similar
<LordKalma>
ah yes
<LordKalma>
and an array of compatibilities would have members 0xc4 apart
<LordKalma>
nbecause that's the size of struct of_device_id
<jernej>
correct
<LordKalma>
just checked it is
<LordKalma>
thanks again
<LordKalma>
this looks more viable by the day :)
<jernej>
last item in array must have all zeros. that signals it's last element
<LordKalma>
those zeros ebtween the strings are the .data element
<jernej>
no, data is just pointer and thus 4 bytes wide
<LordKalma>
ah yes, sorry
<jernej>
zeros comes mostly from name and type (32 bytes each) and remaining, unused space for compatible (128 bytes total)
<LordKalma>
anyhow, this looks more viable by the day :)
<jernej>
yeah, nothing hard, you just have spend some time on it
<LordKalma>
I'm not sure what to do now tho. If I branch the linux kernel (btw, why are there only git tags for 5.15 but not for like 5.15.#?) and add it there and then give it to buildroot as a patch file with the diff
<LordKalma>
or if I try to implement it out of tree with buildroot
<LordKalma>
neither of which will give me a nice compile_commands.json to give clangd :p hahah (i know there is a script in /scripts/ but you have to build it once first)
<jernej>
I'm not familiar with buildroot, so I can't help you there