ftg has quit [Read error: Connection reset by peer]
adjtm has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
<MasterR3C0RD>
Ah, I might have actually found the culprit in address mapping this time. Seems like there's yet another special case, specifically when there are 10 columns and 16 rows
<MasterR3C0RD>
The conditions just read really weird because it mixes in the TPR13 checks for 12Gb/24Gb configurations
<MasterR3C0RD>
And then an extra condition, when there's 10 columns, 16 rows, and a single rank
<MasterR3C0RD>
s/a single/dual/
<MasterR3C0RD>
In other words, the exact configuration used by parthiban's custom board
<MasterR3C0RD>
Pushed up a fix; really hoping this is the winner
hipboi has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
<parthiban>
MasterR3C0RD: Morning!
<parthiban>
"Can you try updating TPR3 = 0x84040404, TPR6 = 0x48000000, TPR11 = 0x1d18131b, TPR12 = 0x15151413, TPR13 = 0x752" Should I keep this values or go back to the previous one?
<MasterR3C0RD>
You can try with your current values firsty
<parthiban>
I think I need to use the correct devicetree to get into the u-boot fully may be
<MasterR3C0RD>
Hooray!
<MasterR3C0RD>
Now we wait for a 12Gb/24Gb to pop up and ruin all of my plans
<parthiban>
:-)
<parthiban>
Changed the dts. Still stuck at the print.
<parthiban>
DRAM in u-boot says 4GiB and waits. Am I missing something?
<MasterR3C0RD>
Try turning on logging in U-Boot, and increase log level to 9
<MasterR3C0RD>
Should give a bit more info
<MasterR3C0RD>
If you still get nothing, switch to a different set of DRAM parameters; I did run into issues when my parameters were incorrectr
<MasterR3C0RD>
Similar to that, where it would lock up after DRAM
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
veremootz has quit [Ping timeout: 480 seconds]
veremitz has joined #linux-sunxi
<MasterR3C0RD>
parthiban: You can also try using the H616 LPDDR4 timings (or the A133's if you're using the H616 timings already)
<parthiban>
Am using the A133 timing value
<parthiban>
Am still stuck at the same point. Logging didn't help much
JohnDoe_71Rus has joined #linux-sunxi
<MasterR3C0RD>
Is your PMIC setting the correct DRAM voltage?
<parthiban>
AXP_DCDC3_VOLT this one, am checking that already
hentai has quit [Quit: SIGTERM]
<parthiban>
AXP717, PMIC varies as well.
<parthiban>
sunxi_board_init is returned good in SPL. this means the DRAM voltage should be ok IMO.
<parthiban>
I mean in this file board/sunxi/board.c
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
<parthiban>
board_init_f is returned. But still nothing in the console. Strange.
<parthiban>
What am I missing.
<MasterR3C0RD>
Do you have JTAG on your board?
<parthiban>
Nope
<MasterR3C0RD>
Not really sure what it could be then at this point; maybe try reducing the DRAM clock?
<MasterR3C0RD>
720 might be fairly safe
<parthiban>
Seems the relocation is failing.
<parthiban>
720 freq didn't help
<MasterR3C0RD>
I'm afraid there's probably not much more I can think of aside from checking parameters; if it's passing the DRAM test it's fairly likely there's no more address mapping shenanigans, and the DRAM organization is likely being scanned correctly
<MasterR3C0RD>
You can try bumping up the amount of memory tested; change the value on line 1207 of arch/arm/mach-sunxi/dram_sun50i_a133.c from 16384 to something much higher, like 16777216
<MasterR3C0RD>
See if it catches anything
<MasterR3C0RD>
It might take a while to run though as you increase that number
<parthiban>
Everything looks fine. Except u-boot is not really starting from the relocated address.
apritzel has joined #linux-sunxi
<MasterR3C0RD>
parthiban: How much success do you get if you modify line 995 to `i = 0` instead of `i = 1`? It should detect half the RAM, but maybe you'll have a shot
<parthiban>
2 GB works.
Schimsalabim has quit [Read error: Connection reset by peer]
<parthiban>
another bank is not detected or not init?
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD>
The second rank is definitely being detected, otherwise it would fall back to 0 rank bits, 32-bit
<parthiban>
but we are not able to access it?
<parthiban>
U-boot is relocated to the top of the RAM.
<MasterR3C0RD>
Yeah, if it's working when ranks aren't in use then it points to the second rank not working correctly
<MasterR3C0RD>
The address mapping code is actually one of the simplest bits, it's just very convoluted because Allwinner maps things in some really odd ways
<parthiban>
"libdram_dramc_simple_wr_test" changing to 16777216 timesout.
<MasterR3C0RD>
One last thing you can give a go: comment out lines 322-325
<MasterR3C0RD>
Should just leave the last writel
<MasterR3C0RD>
If that doesn't work, change the -2 to -1 and see if that fares better
<parthiban>
changing to -1 works
<parthiban>
I meant, the whole 4GB
<MasterR3C0RD>
Woohoo! I'll re-analyze the code later on and see if I messed something up
<parthiban>
Many thanks.
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
parthi has joined #linux-sunxi
parthiban has quit [Ping timeout: 480 seconds]
Lightsword has quit [Ping timeout: 480 seconds]
parthi is now known as parthiban
Lightsword has joined #linux-sunxi
Lightsword_ has joined #linux-sunxi
Lightsword has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
warpme has quit []
Turl_ has joined #linux-sunxi
warpme has joined #linux-sunxi
Turl has quit [Remote host closed the connection]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
<parthiban>
apritzel: MasterR3C0RD: From A133 vendor code I see there are 2 x DE, 2 x TCON TOP. Is this common case? Only other reference which I can compare is A733. How is this usually layered?
warpme has joined #linux-sunxi
<apritzel>
parthiban: sorry, no clue, I guess MoeIcenowy, jernej or mripard might have some pointers ^^^^
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
warpme has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<machinehum>
I'll ask here once more just in case, I'm trying to get a dsi screen working on an a33 and every single driver I think is required is probing without issue. ast thing you can give a go: │ gamiee
<machinehum>
│ │ comment out lines 322-325 │ gamiee_
<gamiee>
it's on top of "sunxi" defconfig in linux
<machinehum>
I'm assuming for hdmi none of the DSI stuff needs to be on
<machinehum>
Sorry, assuming for DSI none of the hdmi stuff needs to be on*
<gamiee>
Most likely no, but frame buffer and other common stuff yes.
<gamiee>
Since it seems you have DSI stuff enabled as it should
<gamiee>
Take look on some PinePhone defconfigs, that might be useful
<machinehum>
Good idea
<machinehum>
gamiee: I think I might be dumb
<machinehum>
I forgot status = "okay";
apritzel has joined #linux-sunxi
ftg has joined #linux-sunxi
<MasterR3C0RD>
apritzel: You mentioned you had made some changes to ATF locally for A133; have you pushed those anywhere I could take a look at? Might start taking a look at bringing up SMP
<apritzel>
no not yet pushed, I was actually thinking about asking someone else to make the patches
<apritzel>
reason is a huge review problem in TF-A, and I can't review my own patches
<apritzel>
you need three gerrit votes: CI, Code-owner, maintainer. I can give the latter two, and trigger CI and help fix things, but not on my own patches
<apritzel>
so if someone has some spare cycles (MasterR3C0RD: NOT looking at you!), I would be more than happy to help get patches merged
<apritzel>
parthiban: was it your custom board that has an AXP717, or this helperboard?
<MasterR3C0RD>
apritzel: I mean, I definitely have a few cycles at the moment; with DRAM init working on parthiban's board and him working on bringing up DE/TCON support (having succeeded with the GPU thus far), as well as my patches to bring up Ethernet being functional (though I may still need to investigate why I can't get a 1Gbit uplink), that doesn't leave
<MasterR3C0RD>
many more peripherals I can work on until my second A133 device and H616/A527 boards arrive
<MasterR3C0RD>
Also, I believe the AXP717 was on his custom board that was having trouble with the dual rank address mapping
<apritzel>
I guess low hanging fruits are IR, SPI, crypto
<MasterR3C0RD>
Ah I missed SPI; device has an SPI port so I can look at that. Not really sure how I'd test IR as I don't believe my advice has an IR blaster or photodiode, but SRAM, RTC, EMAC are working, so I can take on SPI/crypto/efuses then
<apritzel>
yeah, great, that's what we get from committing code untested by third parties: the A100 MMC compatible description is basically broken
<apritzel>
found the A133 SD card bug
<apritzel>
both the descriptors for eMMC and SD only support 13 bits, and not 16 bits for SD
<apritzel>
which explains why eMMC worked
<apritzel>
while this is a trivial fix, the H616 falls back to the A100 compatible, which is not true anymore, so we have to break this up
<apritzel>
I think it should keep working, though, in the worst case we lose a bit of efficiency with SD card transfers on the H616, but let me check that
<MasterR3C0RD>
Bleh, Allwinner code strikes again. The MMC patches seem like they were particularly lazy from them, considering the NO_REPARENTs
<apritzel>
exactly, and they must have not been tested well
<apritzel>
I should have thought of this before: when the request is 8K or smaller (like mount, read a small FAT), it works, but larger requests wouldn't