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
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
linkmauve has left #linux-sunxi [#linux-sunxi]
linkmauve has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
bauen1 has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
<MasterR3C0RD> Finally some free time; going to take a fine toothed comb through the A527 DRAM code and see if I can catch anything...
aggi has quit [Quit: connection closed.]
aggi has joined #linux-sunxi
<MasterR3C0RD> jernej: If I were a betting man, I'd say the issues we're running into on the Cubie are related to the DRAM special case
<MasterR3C0RD> s/DRAM/address mapping/
<MasterR3C0RD> I mentioned it before here on the A133, but essentially it shifts around some of the column/row bits in the mapping. It was necessary to get working DRAM init on the 4GB board that was being used by someone else
<MasterR3C0RD> Hmm wait... I might be wrong
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<MasterR3C0RD> Okay no, the special case on A527 is just for 3GiB models it seems. Strange; on the A133 there was definitely something strange with address mapping
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
<MasterR3C0RD> Okay; I've patched together a few things and I can confirm it is 100% memory corruption. I took the DRAM test I used on the A133 (which was copied from some other repo) and threw it into the A523 DRAM code. Doesn't seem to be aliasing
<jernej> MasterR3C0RD: have you compared register values between BSP and your code?
<jernej> besides some delay fine tunning, it should match perfectly
<jernej> I have recieved cubie board, so I can also start experimenting soon
<MasterR3C0RD> I haven't yet, no; I was running into issues even getting U-Boot from the vendor image working initially, though I finally got it working (dumb PhoenixCard tool made bad SD image, as did OpenixCard initially; still can't boot into Linux)
<jernej> well, for entering U-Boot, you don't need PhoenixCard. Last time it worked that I just concatenated GPT, boot0 and U-Boot parts together and flashed that.
<MasterR3C0RD> Ahhh... wait... it appears that the issues I was running into were entirely my fault
<MasterR3C0RD> I had reset the changes I made for MR14 so I could test my Avaota, and forgot to switch it back
<MasterR3C0RD> No more memory test errors
<jernej> great! what's the next issue? :)
Schimsalabim has quit [Read error: Connection reset by peer]
<MasterR3C0RD> Not getting past "trying to boot from MMC1"; investigating...
<jernej> are you booting from SD or FEL?
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD> SD card, FEL doesn't work at all
<jernej> well, it works if you use 32-bit SPL and then for jumping to TF-A you use reset64 command
aggi_ has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
<MasterR3C0RD> I'm running into some issues compiling ATF now actually... not entirely sure why
<MasterR3C0RD> Figured it out; environment variables
<MasterR3C0RD> It's been a long week LOL
apritzel has joined #linux-sunxi
chewitt has joined #linux-sunxi
dsimic is now known as Guest6942
dsimic has joined #linux-sunxi
Guest6942 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
<jernej> which version of cubie a5e board did you receive? I have v1.1
apritzel has joined #linux-sunxi
apritzel has quit []
apritzel has joined #linux-sunxi
<apritzel> jernej: I have v1.1 as well. I "diff'ed" both versions of the schematics in gimp, there are not many differences:
<apritzel> 1) PJ25 is EEPROM write detect (though I am not sure there is an EEPROM even)?
<apritzel> 2) the SD card detect is different - maybe it's the push/push vs. push/pull difference? Might create a different polarity for the CD pin then: active low vs. active high
<apritzel> 3) R75 on page 14, on the VBUS_5V to 5V_USB regulator, is 6.8K vs 3.6K
colinsane has quit [Ping timeout: 480 seconds]
<apritzel> (EEPROM write *protect above, of course)
<apritzel> those are the only differences, so not much to worry about, I think. If the SD CD pin is indeed different polarity, it might become a slightly annoying DT problem, though
<jernej> apritzel: ah, thanks, I was just about to start diff'ing
<jernej> well, it wouldn't be the first time to have multiple DTs for different revisions
<jernej> EEPROM can be very unassuming, so it's entirely possible that's there
<apritzel> yeah, but they would differ in just one bit, literally, that's sounds annoying. Maybe we can somehow detect it, and patch the DT at runtime
<apritzel> jernej: are you in the U-Boot shell on the Cubie?
<jernej> no, I haven't had time to start playing with it
<apritzel> no worries, I just think MasterR3C0RD reported something like this, and it would help to check those things (SD CD polarity, EEPROM)
<apritzel> I am making slow, but steady progress with cleaning up the A523 U-Boot patches. Rewrote most of the H6 PLL clock code yesterday, to accommodate all of H6, H616, T113/D1, A523, aligning with the manual
<apritzel> jernej: your PLL code in your "avaota WIP" patch was very helpful, though I ended up changing it quite a bit, to include H6/H616
<jernej> oh, that's nice
<jernej> apritzel: do you know what frequency should DSU have in comparison to little or big cores?
<apritzel> and I got rid of "struct sunxi_ccm_reg" entirely, which has always bugged me. At least for H6 and friends
<apritzel> not from the top of my head, but I can find that out, I guess there might be hints in the A55 TRM
<apritzel> jernej: did you look at what the BSP does there?
<jernej> not yet, no
<jernej> I mean, DSU clock init code is similar to boot0
<jernej> but I haven't checked kernel code yet
<jernej> apritzel: SD card difference really looks like inverter
<jernej> apritzel: now that I'm looking to schematic, it looks like there is no pull up on sd-det pin, so it has to be enabled internally
<jernej> no, pull up
<apritzel> details... ;-) but yeah, that's something I wanted to check
<jernej> it's worth checking BSP DT ;)
<jernej> it has: cd-gpios = <&pio PF 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel> well, I have seen so much crap in BSP DTs, I stopped trusting them. Sometimes even contradictory information
apritzel has quit [Ping timeout: 480 seconds]
<loki666> apritzel: using sunxi-fw on a a133p images, wich column should I use for the params ? H616 ?
<loki666> h616, seems to match with Teclast P80 values
apritzel has joined #linux-sunxi
<apritzel> loki666: use MasterR3C0RD's branch, that has explicit A133 support: https://github.com/apritzel/sunxi-fw/pull/6
<loki666> arf, ok, the param of my image perfectly match teclast p80 from MasterR3C0RD u-boot
<loki666> so I guess should be good
<loki666> I'll make a build and see how it goes later
aggi_ has quit []
aggi has joined #linux-sunxi
<apritzel> loki666: if you want to compare notes: this is what I have for my Liontron board: https://gist.github.com/apritzel/8f6bb2f900a38a406e1aa2b312806c23
<loki666> Thanks, should I also creates a axp717.dtsi or embed it in board DTS like it was done for h700 ? Or this completely irrelevant now
Schimsalabim has quit [Ping timeout: 480 seconds]
wingrime-ww has quit [Quit: WeeChat 4.5.1]
bauen1 has quit [Ping timeout: 480 seconds]
wingrime-ww has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<apritzel> no AXP .dtsi, do it like H700 does it
<hlauer> <apritzel> "or use &reg_dldo1, which is..." <- Tried and failed ;-)
<hlauer> But noticed mmc1 (used by the wifi interface) uses dldo1 too, and disabled that and (e)mmc2
<hlauer> And with all other interfaces disabled, mmc0 seems to be stable so far - at least just survived a testing update. Thanks!
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel> hlauer: that sounds very odd! Does it help to just disable MMC1?
<apritzel> and what is the actual voltage of DLDO1? The DT is very unhelpful (wrong?) here by saying "between 1.8V and 3.3V", which probably means it stays at the reset default
<apritzel> (check /sys/kernel/debug/regulator/regulator_summary)
ftg has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<loki666> I'm really not sure about the regs
<loki666> nor the cpu-supply
<MasterR3C0RD> loki666: You won't be able to set up cpu-supply atm since that's using a regulator that isn't supported by mainline yet
<loki666> well this is axp717 like h700
<MasterR3C0RD> Yeah but it has an additional regulator, the TCS one, that just handles powering the CPU cores
<loki666> ah yes saw that
<loki666> so I should drop it ?
<MasterR3C0RD> Don't bother with the CPU supply, but keep the AXP717 (that voltage is for the DRAM)
<MasterR3C0RD> The bootlog you posted also states it should be set to 1200mV, not 1100mV
<loki666> for which reg ?
<loki666> ah in uboot conf
<MasterR3C0RD> That would be DCDC3 I'm pretty sure; the DCDC5 is for a different PMIC
<MasterR3C0RD> So should replace that in the config with CONFIG_AXP_DCDC3_VOLT=1200
<loki666> done, should I also update dts with dcdc3
<MasterR3C0RD> Yeah, it should accurately represent the hardware. Make sure to set it as "regulator-always-on" though
<loki666> ok
<loki666> for TCS4838, I should look in bsp code ?
<MasterR3C0RD> It'll need to be ported to work with U-Boot and SPL, but you'll certainly need to use the BSP as a reference since there's no reference manual available for the TCS
<MasterR3C0RD> It does, though any small slipup could mean your CPU gets extra crispy :))
<loki666> MasterR3C0RD: am I missing something, I'm getting an error
<loki666> dts/upstream/src/arm64/allwinner/.sun50i-a133p-magicx-minizero28.dtb.pre.tmp:16.10-18.4: ERROR (path_references): /aliases: Reference to non-existent node or label "mmc0"
<loki666> I don't have mmc0 in my aliases
<MasterR3C0RD> Hmm, I'm not sure; U-Boot does add some extra stuff to the DTS, including some to set up the MMC
<MasterR3C0RD> Oh wait...
<loki666> yes but mmc0 is not defined in a100.dtsi
<MasterR3C0RD> You need to copy the DTSIs from the kernel
<loki666> a100 ?
<MasterR3C0RD> Yeah, the upstreams in my branch are old and don't have the MMC and a few other peripherals
<loki666> ok it compiles
<apritzel> loki666: ah, yeah, I had updated the DTs in U-Boot with the recent kernel versions, to get MMC and USB, sorry for not mentioning that
<apritzel> that should happen in the next weeks automatically
<loki666> ok I don't know how to config my mmc0 anyway
<apritzel> the SD card is pretty easy: just give it some 3.3V reg as vmmc-supply, and probably PF6 as cd-gpios, there is typically not much variation
<apritzel> so you can copy that from the Liontron DT
<apritzel> having some kind of mass storage typically makes any device suddenly a lot more useful ;-)
<loki666> yes I suppose
<loki666> ok let's boot that
<loki666> why is it trying mmc2 ?
<loki666> do I need CONFIG_MMC_SUNXI_SLOT_EXTRA=2 ?
<MasterR3C0RD> No, you should replace it with `CONFIG_MMC_SUNXI_SLOT_EXTRA=-1`
<loki666> ok
<loki666> at lest dram detection works
<loki666> MasterR3C0RD: same, still trying MMC2
<loki666> well not exactly the same , as now it seems to crash just after 'Trying to boot from MMC2'
<loki666> maybe they swapped the mmc ?
<loki666> and I'm booting from mmc2 ?
<apritzel> loki666: does that thing have two SD card slots?
<loki666> yes
<apritzel> so have you tried booting from the other?
<loki666> no, but I inserted in the same slot bsp booted from
<apritzel> that SD card slot is apparently MMC2, so you would indeed need CONFIG_MMC_SUNXI_SLOT_EXTRA=2
<loki666> yes
<apritzel> and you can describe &mmc2 the same as &mmc0 in the DT
<loki666> ok, just got a dram detection failure
<apritzel> what DRAM parameters did you use? the ones shown in the BSP bootlog, or the ones extracted from the image, via sunxi-fw
<loki666> sunxi-fw
<loki666> it seems to happens since I declared mmc2
<loki666> but even when it detect the ram, ok it still doesn't boot from mmc2
<apritzel> in U-Boot's drivers/mmc/sunxi_mmc.c, change the line "cfg->host_caps = MMC_MODE_8BIT;" to use MMC_MODE_4BIT instead
<apritzel> the SPL assumes that MMC2 is eMMC, and always uses 8-bit
<apritzel> which won't work on an SD card
<apritzel> loki666: did you manage to extract a DT from the BSP image? Do you have a link to some image file?
<MasterR3C0RD> loki666: That's a RAM misdetection; it happens sometimes for some reason. I'll try and port jernej's patches for RAM detection at some point to see if that improves things
<loki666> didn't extract the DT yet
<loki666> I think MasterR3C0RD found it in the 10Gb sdk
<MasterR3C0RD> ^
<loki666> went a bit further https://pastebin.com/UTBb2gft
<loki666> but only one, can't reproduce it
<loki666> ^once
<loki666> got this MMC: block number 0x660 exceeds max(0x80)
<apritzel> loki666: try this binary for TF-A: https://paste.c-net.org/ScryingAdmiring