<apritzel>
(though this is only step one, I guess, the manual says to re-lock the PLL as well)
<apritzel>
parthiban: is your A523 CPU PLL driver in a decent shape? Mine is only half-baked, I guess, so happy to use your patch instead
<MasterR3C0RD>
parthiban: Did you see that I updated my U-Boot branch? Should support LPDDR4 memory now
apritzel has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Would be great if you could test it on your board whenever you get a chance
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hipboi has joined #linux-sunxi
<MasterR3C0RD>
Curiously, the original patchset uses a H3 fallback compatible for the A100's MUSB peripheral, even though the user manual and Allwinner kernel claim 5 EPs
<Parthiban>
apritzel: Well, I have pulled most things from vendor for A523 without much cleanup on 6.12. As I don't have the board yet (probably will get it today), I haven't checked on it. Likely I will cleanup those for next week.
<MasterR3C0RD>
parthiban: I also posted above the current iteration of the rebased A100 patch series (plural); it fixes some problems I neglected when I was originally rebasing
<MasterR3C0RD>
For the kernel
<Parthiban>
Do you have this perf1 board? I couldn't find any details related to a100 at all.
<MasterR3C0RD>
parthiban: No; I think it was a QA board made by Allwinner. As for the A100, I did some research myself; rumor is the A133 was originally intended to be the higher binning of the A100, but then everything met the A133 standards, so they got rid of it
<MasterR3C0RD>
As for the config options: you'll want to set them in menuconfig, but yes, you'll use the settings from the A133 column
<MasterR3C0RD>
They're under ARM Architecture, there's a number of DRAM settings there
<Parthiban>
yeah doing it. But few doesn't have the Kconfig entry in this case. But there are values in the colomn
<Parthiban>
Should be left as 0?
<MasterR3C0RD>
If there are places to put values in Kconfig but nothing in the columns, keep them 0. If there's a value in the table but nothing in the config, it's one of the settings I determined was useless and you don't need to worry about it
<Parthiban>
If there is no physical SoC in use, what't the idea to retain the dts and bindings in favour of a100?
<MasterR3C0RD>
These patches were originally targeted for the A100, and since they appear to be the same thing, no reason to rock the boat
<MasterR3C0RD>
You can think of the A100 as a "series" of SoCs if you'd like, since there's the A133 and the A133 "Plus"
<Parthiban>
DRAM:read calibration failed 0 MiB
<MasterR3C0RD>
You made sure to set the DRAM type correct?
JohnDoe_71Rus has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
<Parthiban>
CONFIG_DRAM_SUN50I_ODT_EN should be this 0x1?
<Parthiban>
I don't have this value
<MasterR3C0RD>
That doesn't affect anything
<MasterR3C0RD>
There should be a menu for "DRAM timings" in ARM Architecture
<MasterR3C0RD>
Make sure you have LPDDR4 selected
<Parthiban>
CONFIG_SUNXI_DRAM_A133_LPDDR4
<MasterR3C0RD>
You had that set already?
<Parthiban>
missed it, changed it now and trying now
<MasterR3C0RD>
Fingers crossed, this would be the second device to boot off this tree
<MasterR3C0RD>
Alright, can you run `sunxi-fel sid`?
<Parthiban>
54401400:2c004814:00c59054:5c911b5b
<Parthiban>
I dont know what this data means, but
<MasterR3C0RD>
I just needed the 0x1400 bit, I'll double check to make sure that doesn't require any quirks
<MasterR3C0RD>
In the meantime, you can try the H616 LPDDR4 timings instead and see if your results differ
<Parthiban>
sure
<MasterR3C0RD>
Doesn't look like 0x1400 is special. Hmm...
<MasterR3C0RD>
If your boot0 is printing out para1/para2 values, you can also give those a try instead
<Parthiban>
"[262]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, tpr13 = 7525" I have this yes.
<MasterR3C0RD>
Yeah, try those instead of the original parameters
<MasterR3C0RD>
*parameters from the boot0 dump
<MasterR3C0RD>
+0x20 on the para1. I think I had similar results on my boot0. I might need to dig a bit more...
<Parthiban>
10001000 for para2 doesn't seem right?
<Parthiban>
It needs to be 0x1000 ?
<MasterR3C0RD>
I don't see why it needs to be 0x1000, unless you tested and it doesn't work
<Parthiban>
tried both
<MasterR3C0RD>
And still no dice?
<Parthiban>
Unfortunately no
<MasterR3C0RD>
Might be the MRs then, I had similar behavior when I messed those up before
<MasterR3C0RD>
As in my code setting up the MRs
hipboi has joined #linux-sunxi
hipboi has quit []
<Parthiban>
same result with H616 values as well.
<MasterR3C0RD>
Oh... *facepalm*
<MasterR3C0RD>
I'm not actually using all the parameters from the config
<MasterR3C0RD>
Pull down the code now and give it a shot
<MasterR3C0RD>
Btw, the parameters you got from sunxi-fw will probably leave you with the wrong amount of RAM; I don't know why para1 is off by 0x20 but that's what actually stores the DRAM organization
<MasterR3C0RD>
It must be adding that back somewhere, I just don't know exactly where
smaeul_ has joined #linux-sunxi
<Parthiban>
pulled and tried. same result still
smaeul has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Shoot. I guess I'll need to get an LPDDR4 board then
<MasterR3C0RD>
I'll dig into the code one more time tomorrow to see if there's any other smoking guns
hipboi has joined #linux-sunxi
<MasterR3C0RD>
If you get a chance to test out my kernel, lemme know
<Parthiban>
Yeah, I will be swapped into another projects. Will do test the kernel parts later today.
<Parthiban>
MMC parts are same as mine, USB is what I need to give a try.
<Parthiban>
My knowledge with DDR/LPDDR is limited. I need to understand your changes in u-boot related to it still, so that I can technically help. But thanks for your efforts.
<Parthiban>
To add, I have the GPU power domain driver and GPU nodes added in my tree kernel parts. I still need to get the DE, TCON display pipeline working before pushing those IMO.
smaeul_ has quit []
smaeul has joined #linux-sunxi
<MasterR3C0RD>
Basically all of the DRAM code is from reverse engineering; to be honest I had to teach myself what the init code is doing as I went along, based on function naming in the DRAM and the few registers we do know for sure (like the DRAM controller itself)
<MasterR3C0RD>
s/in the DRAM/in boot0/
<Parthiban>
Btw, "fastboot flash:raw boot ./bin/boot.img" am able to flash the boot partition by entering into fastboot from vendor u-boot and boot it. but "fastboot boot ./bin/boot.img --base 0x40000000 --kernel-offset 0x80000 --ramdisk-offset 19922944 --dtb-offset 18874368 --header-version 2" this doesn't work, meaning loading into RAM is ok, but unable boot yet. Any hints or have you done that before?
<Parthiban>
Do we have same or similar DRAM controller with reference manual which I can refer to? Any recommendations?
<MasterR3C0RD>
I haven't played with fastboot I'm afraid
<MasterR3C0RD>
The DDR PHY on the other hand is a mystery; I tried hunting around myself for what it could be but I came up empty. I'm thinking it's probably a Designware IP core of some sort due to one of the functions having a suspiciously DWC name, but whatever it is isn't well known. What we do know is that it supports DDR3, DDR3L, DDR4, LPDDR3, and LPDDR4,
<MasterR3C0RD>
based on the user manual
<MasterR3C0RD>
The H616 PHY is very similar to what's used on the A133; the COM registers seem to be laid out slightly differently, and there's different phy_init code, but the rest of the code has a lot of similarities to the H616. For LPDDR4, comparing with that is probably your best bet. I wasn't able to do that for DDR4, as there isn't support for that on the
<MasterR3C0RD>
H616 at the moment
<Parthiban>
Isn't that the one used on i.mx8mm family? I may be wrong.
<MasterR3C0RD>
It could be; the documentation is rather lacking though. The closest match I found based on specs alone was the DWC LPDDR4 multiPHY
<MasterR3C0RD>
Actually just checked the datasheet for the i.MX 8M mini, and it's definitely not it
apritzel has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
<loki666>
apritzel: stress-ng seems to do the job fine to trigger it
Schimsalabim has joined #linux-sunxi
hipboi has joined #linux-sunxi
warpme has joined #linux-sunxi
ungeskriptet is now known as Guest7303
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
Guest7303 has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
MasterR3C0RD: the Linux patches look good on first glance, I will do a proper review on the list. Do you have a working git send-email setup? Then feel free to send them out.
<apritzel>
I'd recommend to send a series first to yourself only, to uncover any issues. Also helps to skim over the emails, sometimes you spot typos or leftovers quicker in a different environment (like an email client)
<apritzel>
also please add a cover letter if you don't already have one, and mention the A133 in there
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
warpme has quit []
<MasterR3C0RD>
apritzel: Thanks for the quick lookthrough! I did get send-email working last night and sent the patches to myself; going to make a few changes to my cover letter and then send them off
JohnDoe_71Rus has joined #linux-sunxi
dsimic is now known as Guest7332
dsimic has joined #linux-sunxi
Guest7332 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
gnarface has quit [Quit: Leaving]
ity has quit []
gnarface has joined #linux-sunxi
<apritzel>
MasterR3C0RD: very nice cover letter: explaining the situation and giving a quick overview
<MasterR3C0RD>
apritzel: Thank you! I think I might've spent more time on that than the actual rebase HAHA
<Parthiban>
MasterR3C0RD: got my helperboards for A133 and A523 today. Will give a try to your patch series sometime tomorrow.
Parthiban has quit [Quit: Leaving]
<MasterR3C0RD>
parthiban: Awesome, thanks! If it works on that board, would you be willing to add a "Tested-by" on my patches?
sh1 has quit [Quit: Lost terminal]
sh1 has joined #linux-sunxi
<apritzel>
parthiban: ... and if you do so, please reply to the individual patches (preferably the ones that add the driver code), not the cover letter, as it makes it easier to attribute the tag
<MasterR3C0RD>
apritzel: Saw your comment regarding the PHY, and double checked the original patches to be extra certain that I mapped the old handling based on "phy_type" to the new quirks. Looks like you're right, the A100 cfg can just be dropped
<apritzel>
tokyovigilante: congrats: broonie took the codec patches (minus the DT parts)
vagrantc has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
<apritzel>
loki666: did you get anywhere with your H700 cpufreq testing?
<apritzel>
I tested some H618 TV box here, and never saw any issue
<apritzel>
with various tests, including some stuttered computation, to trigger OPP changes, and some manual flooding of scaling_setspeed, to force PLL changes
<apritzel>
I also hacked the driver to report my 0x2000 as H700, to get the exact same OPPs
<MasterR3C0RD>
Now that's interesting. Turns out half of the values that I was getting running sunxi-fw on my A100 recovery image for this device were just flat out wrong
<apritzel>
from the initial table, at the beginning of boot0?
<MasterR3C0RD>
apritzel: All tables, even the one that's actually for DDR4
<MasterR3C0RD>
Not just the one value I did notice (para1 having incorrect DRAM organization values), but also some of the mode registers
<MasterR3C0RD>
That could be a factor as to why parthiban's board wouldn't come up on my branch
<apritzel>
how did you figure that? By looking at boot0's debug output? Or by comparing register dumps between mainline and boot0?
<MasterR3C0RD>
I haven't flashed the recovery image to my device, but the current boot0 installed on my Sonic Pad has debugging output that dumps the entire parameter table (in linear order)
<MasterR3C0RD>
I only checked it because I was running into issues shortly after boot where the board wasn't coming up, and double checked those values vs the ones from my boot0 log
<MasterR3C0RD>
para1 is 0x60fa in the firmware parameters, vs 0x610a being used by boot0
<apritzel>
I think traditionally we were using register dumps between boot0 and mainline, then sometimes recalculate the values back to get the input parameters
<MasterR3C0RD>
Do we have a tool to set the debug_mode for boot0?
<apritzel>
can you do this on the binary anyway?
<MasterR3C0RD>
Yeah, there's a field in the boot0 "private header" that sets debug level
<apritzel>
you can use sunxi-fw to calculate the checksum, after you hacked that with a hex editor
vagrantc has quit [Quit: leaving]
<apritzel>
and then put that new checksum in
<apritzel>
though the checksum is very simple, so you can just subtract the difference between the old and the new value, if you just change a single byte (or word)
<MasterR3C0RD>
I might walk parthiban through that tomorrow then so he can use those parameters instead
<MasterR3C0RD>
Since my code works mostly off the para0 parameters