<apritzel>
qcom seems to be as awful as can be, from what I have seen and heard, I think AW is easier
<alikates>
yay xDD
<apritzel>
the mux' and gates in the new SoCs seem to be pretty stable, so chances are the existing code just work
<apritzel>
the PLLs are a different story though
timsu has quit [Ping timeout: 480 seconds]
<alikates>
Hey! Somehow I got the first line from SPL through uart!
<alikates>
It hangs in a "DRAM:" line, so I guess the DRAM initialization is not working..
<apritzel>
alikates: oh wow, congrats!
<apritzel>
that means you are running 64-bit code
timsu has joined #linux-sunxi
timsu has quit []
<apritzel>
and yes, you now discovered the big hurdle: the DRAM code ...
<alikates>
Ty! Yeah the DRAM
<alikates>
Could it be using the same memory controller as the D1/T113?
<apritzel>
no one knows, and I think in the past there were always at least subtle differences between the controller, more often actually bigger ones
<apritzel>
so that's unfortunately a show stopper. Your best chance at this point is probably to hack an existing boot0 to let it init the DRAM, then return to FEL
<apritzel>
then you can upload U-Boot proper and a kernel, and can continue making progress
<apritzel>
can you extract a boot0 from somewhere? Either an update image, or from the eMMC
<alikates>
yes, I have a dump of the emmc
<apritzel>
alikates: can you try to extract boot0 (sunxi-fw might help you: extract -n boot0 -o boot0.bin), and then try to upload this with sunxi-fel as the SPL
<alikates>
it does work
<alikates>
like
<alikates>
it outputs stuff but then there's a "Loading boot-pkg fail..."
<alikates>
and stays there
<apritzel>
and FEL is gone, I guess?
<apritzel>
in the past I hacked the binary to return to FEL after initialising the DRAM
<apritzel>
that's a bit tricky, admittedly, since you probably have to save SP and LR in the beginning first, then later restore them
<apritzel>
or it might work to branch to 0x20 (the typical FEL entry point)
<alikates>
yes, FEL is gone
<apritzel>
one way to find the boot0 offset is to find the address of some string after DRAM init, then find an instruction referencing this address, in the disassembly
<apritzel>
if you put the boot0 somewhere, I can give it a try ... tomorrow
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
<alikates>
i already had ghidra open xDD, yeah was doing exactly that. The issue is that it looks like its calculating the string index in the fly, so ghidra can't figure out the load offsets
smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
machinehum has joined #linux-sunxi
<Jookia>
does uboot support video output on the t113
apritzel has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
machinehum has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
<Jookia>
i'm looking at the code and the answer to that is no, so my follow-up question is: how hard will it be to add it? it doesn't look TOO hard
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Jookia: well, that last display engine we support is the H3/A64/H5 one, so there might be some delta to cover
<Jookia>
I'll dive in to it more next week but I *think* it shouldn't be too hard. This is comparing Linux drivers and quirks though
<apritzel>
yeah, but I don't know how different the D1 DE is from DE2
<apritzel>
but yeah, it sounds doable, though you would need to understand the U-Boot DM for that, and maybe renovate some parts on the way
<apritzel>
existing old code is considered okay with being sloppy or cutting corners, but for new patches there is more scrutiny
<apritzel>
and be aware that LCD is more complicated, as you need to model properly, too
<apritzel>
but yeah, if you'd be willing to invest some time, many people (including me) would be quite grateful
<Jookia>
This would be based on drivers/video/sunxi/sunxi_display.c I think
<Jookia>
So just adding code to that
<Jookia>
i think the D1 uses DE1?
<apritzel>
I doubt that, and no, sorry, that's the old video driver, you cannot use that
<apritzel>
it's sunxi_de2.c that you would need to look at
<Jookia>
hmm
<apritzel>
the other one is at least old, and would need much more work to be DM compliant
<Jookia>
i'm not too worried about DM righ tnow
<apritzel>
I'd look at Linux commits 2deb9739bc133 and parent, that introduced video support for the D1, and then try to replicate that on the U-Boot code base
<apritzel>
and parents*
<Jookia>
yeah
<Jookia>
the kernel doesn't do display engine 2 i don't think
<Jookia>
i don't know, it's confusing
<Jookia>
i don't think i can do this
<apritzel>
the H3/A64/H5 has what we call DE2, I think
<Jookia>
i don't have any documentation for the DE2
<Jookia>
or DE1
<apritzel>
I think DE1 is legacy, used in the A20 and such
<Jookia>
i don't understand u-boot driver model enough to write code for it
<apritzel>
and there is some documentation in the various manuals
<apritzel>
I think the most challenging part is to understand the overarching architecture, with mixers, TCON, and so on
<apritzel>
then you can indeed look at what the D1 does differently from the A64, in the Linux code, and try to transplant that to U-Boot
<apritzel>
I don't think the U-Boot DM is too difficult, at least not if you are used to modern Linux anyway
<Jookia>
is the A64 supported in the u-boot?
<apritzel>
yes
<Jookia>
i think modern linux binds based on device trees while u-boot just seems to bind based on the driver being added
<Jookia>
i mean A64 supported for the DE2 LCD code
<apritzel>
yeah, the LCD code in U-Boot is a bit worrying, and there might be old code still around, which is not fully DM compliant
<Jookia>
well, i might as well have a go
<apritzel>
but conceptually the U-Boot DM is not that far from the Linux DM, it's DT based as well
<apritzel>
just not *everything* is fully converted over yet, especially in those fringes like LCD
<apritzel>
I think HDMI is a bit better off, but IIRC the D1/T113 does not have HDMI?
<Jookia>
i don't think it does
<Jookia>
i mean, linux runs the LCD
<Jookia>
and it can't be THAT big a deal to update u-boot to deal with whatever quirks
<apritzel>
ah, the D1 supports HDMI, but the T113-s3 does not
<apritzel>
anyway, I'd lean on more graphics savvy people in here, especially jernej and smaeul should know about this
<alikates>
apritzel: I'm trying to guess the DRAM controller base address from checking where boot0 is reading the DRAM param header...
<alikates>
At least I think I've identified some parts of the code that read the DRAM clock speed (header offset 14)
<jernej>
Jookia: can you point me to D1 BSP somewhere on github? I can quickly extract some pointers
<jernej>
while simple, it's needed for more or less all newer than H3/H5 SoCs
<jernej>
and yes, it's DE2, which means you can reuse some code in U-Boot
<Jookia>
there's no manual for the T113 DE variant from what i can see so all the knowledge must be from the BSPs
ftg has joined #linux-sunxi
<jernej>
correct, but you can heavily lean on Linux implementation
<Jookia>
yeah i plan to
<jernej>
once tcon-top driver is in, H6 display support would be easy too
<jernej>
although that needs DE3 support, basics needed for U-Boot are almost the same as for DE2
<apritzel>
alikates: boot0 stores DRAM parameters in the boot0 header, this is what sunxi-fw decodes
<alikates>
Yeah, im correlating the known parameter structure with what the boot0 code is doing
<apritzel>
those parameters are the per-board specific values, to compensate for board dependent timings, like the length of traces and such
<alikates>
Looks like the controller address is the same as on h6
<alikates>
Okay
<apritzel>
jernej: how far is the R40 from DE2 and DE3? There are old U-Boot patches from MoeIcenowy for the R40 display, although there need some rework
Guest4156 is now known as ynezz
<jernej>
R40 uses DE2, just with tcon-top
<jernej>
and IIRC, it uses same HDMI driver as H3
<jernej>
so this would be a good choice for next display driver in U-Boot
<apritzel>
so there must be some TCON-TOP code in MoeIcenowy's patches then?
<jernej>
yes
<apritzel>
I think the problem with that patch set is that it's old, so before your DM conversion
<jernej>
do you have a link?
<apritzel>
just a sec
<jernej>
in any case, don't be afraid to write driver for it. it's not a rocket science, just 2-3 registers to set
<jernej>
this code has hardcoded routing, but to be honest, also Linux dynamic one isn't ideal
<Jookia>
it definitely won't spiral in to a month of pain
<apritzel>
Jookia: any help is welcome, I am happy to provide some U-Boot DM adaptations, if you do the heavy functionality lifting
<Jookia>
sure
<apritzel>
Jookia: and btw. I don't think you need any simplefb code
<apritzel>
that was originally to get some Linux graphics output, but since we have a native driver, this is much less useful these days
<Jookia>
i'm interested in having the panel handed over
<jernej>
Jookia: you'll probably need pwm driver too? for backlight
<Jookia>
hmm not sure yet
<apritzel>
Jookia: why would you need graphics support in U-Boot anyway? Many people seem to get away without it (one of the reasons we don't support newer SoCs)
<Jookia>
for a splash image while it waits to boot, however this was planned when booting took 30 seconds, not 6
<Jookia>
displaying error codes is the secondary reason
<Jookia>
or firmware updating
<Jookia>
i would like to embed a little linux failsafe system to handle that somehow though :)
<apritzel>
alikates: please keep in mind that the DRAM controller typically consists of like three IP blocks, sometimes AW mixes and matches some of them
<jernej>
apritzel, alikates: which soc are you working on?
<alikates>
H713/TV303
<apritzel>
jernej: it's sun50i-w12p1, an NCAT2, so probably closer to the A523 than to the H616/H700
<jernej>
yeah, I'm just looking into that
<jernej>
do you know sram addresses?
<jernej>
I'm trying to load boot0, but 0x20000 doesn't seem to be correct one
Asara has quit [Quit: leaving]
<apritzel>
jernej: it's 0x100000 for SRAM A2, with the ARISC exception vectors up from, so effectively 0x104000
<apritzel>
up front*
<apritzel>
it seems similar to the R329 in that it doesn't have SRAM A1
<apritzel>
alikates found that SRAM ends at 0x124000, I think
Asara has joined #linux-sunxi
<apritzel>
jernej: do you have a device? Or are you looking at boot0 in Ghidra?
<jernej>
ghidra
<jernej>
I'm interested in DRAM
<jernej>
and at least from the strings, it seems that it supports only DDR2 and DDR3
<apritzel>
jernej: yeah, have you seen the boot log?
<alikates>
> NOTICE: BL3-1: Next image address = 0x4a000000
<alikates>
Idk where BL31 is loaded though
<apritzel>
don't know for sure, but there are some hints that it's indeed 0x104000
<jernej>
alikates: boot address for boot0.bin is somewhere in SRAM region
<jernej>
ok, let me try that
<alikates>
Ah, boot0 expects to be loaded to 0x104000
<jernej>
that works
<alikates>
the ghidra decomp also confirms it
<jernej>
it may be worth to check if DRAM driver is similar to one from dram_sunxi_dw.c
<alikates>
There seem to be 2 register spaces, one at 0x4810000 and other at 0x4820000
warpme has quit []
<apritzel>
jernej: yeah, I was thinking about that already, since boot0 just reports ZQ and ODT
<jernej>
and DDR2/DDR3 only support reminds me of V3
<jernej>
SoC I mean
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
macromorgan, tokyovigilante, acmeplus: can you check whether the new cpufreq series works for you, and allows the H700 to go up to 1.5GHz?
machinehum has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest4326
ungeskriptet has joined #linux-sunxi
Guest4326 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.0, revision: 5.2.0+git-7558-9b8fa92ef, build type: debug, sources date: 20160102, built on: 2024-02-17 21:13:17 UTC 5.2.0+git-7558-]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
<tokyovigilante>
apritzel: thanks, will test out the new u-boot sector offset and cpufreq next week, am away for easter this week.
apritzel has joined #linux-sunxi
daschaos has quit [Remote host closed the connection]
daschaos has joined #linux-sunxi
<alikates>
apritzel: is there any way of jumping from boot0 to FEL? That way I could at least dump the values written to the DRAM controller
<alikates>
Not sure if there's even possible to read those registers with sunxi-fel though
<alikates>
i only get zeros, maybe because the clock is gated?
pmp-p has quit [Ping timeout: 480 seconds]
<apritzel>
initially, before any code is run, you mean?
<alikates>
Yes
<apritzel>
yes, there is a clock gate and a reset bit
<apritzel>
so regarding returning to FEL:
<apritzel>
you can try to just branch to 0x20, which is the FEL entry point in the BROM
<apritzel>
mov r0, #0x20; br r0
<apritzel>
but I think this doesn't work too well with the spl command, since it expects the code to *return*
<apritzel>
so the best way is to save SP and LR at the very beginning
<apritzel>
there is some redundancy in the very first boot0 instructions executed
<apritzel>
so you can merge some insn, to get three or so for free, to load some pointer, and store LR and SP there
<apritzel>
then, after the DRAM init, you restore them from there, and do a "ret"
<alikates>
theres some padding between the header and the code after the first jump
<apritzel>
let me see if I can quickly sketch up the first part, which is the more constrained one
<apritzel>
well, this is part of the boot0 header, so really to mess with that
<alikates>
Okay
<apritzel>
be really* careful
<alikates>
Have you considered doing something similar as what the asahi-linux team does, having a small hypervisor on top of the firmware to be able to trace the setup code
<alikates>
?
<apritzel>
for instance the insn: "orr r0, r0, #19" and "orr r0, r0, #192" can be merged into "orr r0, r0, #0xd3"
<apritzel>
yes, I have started playing with that, using self hosted debug in EL3, to run the *BROM* code in secure EL1, and trap stuff as needed
<alikates>
cool!
<apritzel>
but it's in an early stage, and typically we don't need that, as you can much easier deduce the code with Ghidra
<apritzel>
with "you can" mostly meaning "jernej can" ;-)
<alikates>
Well 1/3 of the boot0 are strings from what I see
<apritzel>
and if he says it looks similar to the V3 DRAM, then it might be much easier to compare that
<apritzel>
we would just need to dump the registers *after* boot0 has inited the DRAM
<alikates>
I've been looking into it, the issue is that the init code is tightly coupled with the H3 clock controller too
<alikates>
in u-boot i mean
<alikates>
So it might not have the third PHY block, right?
<apritzel>
I have no idea, really
<apritzel>
but the clock controller shouldn't be that problematic
<apritzel>
since it's just a one time setup function
<apritzel>
so we just provide an alternative version, for the H713, and be done
<apritzel>
is the later part of boot0 Thumb2 code?
<apritzel>
so in my old notes I find: " a: 2320 movs r3, #0x20" and " c: 4718 bx r3"
<apritzel>
I think that should be sufficient, to put that at any point behind the DRAM init code
<apritzel>
you need to recalculate the checksum then, sunxi-fw can help with that
<alikates>
okay
<alikates>
anyways, i don't know exactly where the dram init is, so..
<apritzel>
but maybe you can find some code behind it?
<apritzel>
doesn't need to be exact
<apritzel>
just after the DRAM init, and before it bails out
<alikates>
okay
<alikates>
Thank you
<alikates>
I will try some of the suggestions, and see where i can get
<alikates>
Love the difference with qcom. with qcom everything was locked and signed with secureboot, with AW its an exploit party xD