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
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 has quit [Quit: Leaving]
parthiban has joined #linux-sunxi
<parthiban> Looks same between two
<MasterR3C0RD> Address is aliased with itself...
<MasterR3C0RD> That has to be a memory test bug
<MasterR3C0RD> Ah wait actually
<MasterR3C0RD> That means it's aliased at the step
Schimsalabim has quit [Ping timeout: 480 seconds]
<MasterR3C0RD> Found it
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD> parthiban: Pushed a fix
<parthiban> Finally.
<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]
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
warpme has quit []
colinsane has quit []
colinsane has joined #linux-sunxi
warpme has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
colinsane has quit []
wingrime-ww has quit [Quit: WeeChat 4.4.2]
wingrime-ww has joined #linux-sunxi
colinsane has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
dsimic is now known as Guest8629
dsimic has joined #linux-sunxi
warpme has quit [Remote host closed the connection]
Guest8629 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<MasterR3C0RD> parthiban: I'm pretty sure the second node for each don't actually exist, but I could be wrong
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
mripard has quit [Quit: WeeChat 4.4.2]
mripard has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
vagrantc has joined #linux-sunxi
hentai has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
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_
<machinehum> Whoope
<machinehum> Ignore the last paste vomit lol
<machinehum> Does anyone know if there any other drivers/config that I might be missing?
<gamiee> machinehum: can you send defconfig pls?
<machinehum> yup
<machinehum> Ty for taking a look btw
<gamiee_> I see what you miss
<gamiee_> CONFIG_FB=y
<gamiee_> CONFIG_FB_SIMPLE=y
<machinehum> ;o
<machinehum> well then
<machinehum> I'm going to change all these modules back to builtin, because once I got a /dev/fb0 but it didn't work
<machinehum> Maybe I'll try to get back to there
<gamiee> so you got the fb finally?
<machinehum> nope
<gamiee> this is what i use for allwinner h3 (hdmi ofc): https://paste.debian.net/1334744/
<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> MasterR3C0RD: well, there is quite a lot of grey boxes in the A133 column here: https://linux-sunxi.org/Linux_mainlining_effort
<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