<apritzel>
jernej: so I skipped all of read calibration, read training, write training, then I also turned off auto-detection and force the right param values: still the same hang, apparently when it uses DRAM
<apritzel>
jernej: the first read of PHY_BASE+0x184 in mctl_phy_read_calibration() returns 0, then 0x24, which eventually returns false
<apritzel>
when I skip all this, and test read-backs of some pattern (0x5a69c33c) for the whole DRAM in 1 MB steps, I get the following pattern:
tuxillo has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
asdf28 has joined #linux-sunxi
reinforce has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
willmore has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
willmore has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
asdf28 has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
cmeerw has joined #linux-sunxi
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
apritzel has quit [Ping timeout: 265 seconds]
ldevulder_ is now known as ldevulder
apritzel has joined #linux-sunxi
AneoX has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
<pgreco>
wens: looks like they are queued for lts too (5.4 and 4.19), they shouldn't break anything, right?
<wens>
considering the PHY driver "fix" was already backported, they should fix things up
<pgreco>
then I need to wati for my fixes to be backported too (or do that manually) before I rebuild
<pgreco>
I hadn't seen the "fix" in the lts branches
<apritzel>
wens: so does that mean that stable kernels now also break with old DTs?
<wens>
apritzel: they already did ...
<apritzel>
5.4 as well?
<wens>
I was wrong
<wens>
looks like the final "fix" was not backported
<wens>
apritzel: sorry for the confusion
<apritzel>
wens: I saw your patch (letting sun8i-emac just accept rgmii-* phy-modes) being backported, including Ubuntu's 5.3 kernel, for instance
<pgreco>
apritzel: 5.9 is broken at the moment, yes
<apritzel>
I didn't follow the discussion closely, but are there actually any boards that genuinely use "rgmii" now? Or do all need to go either to -id or -txid?
<apritzel>
pgreco: I know about that, I was more worried about LTS kernels like 5.4 or even 4.19
<pgreco>
no idea if any board needs "rgmii", but I haven't followed it that closely either, aside from the boards I use
yann has quit [Remote host closed the connection]
<pgreco>
yeah, that's why I checked, the dts patches are queued for lts 5.4 and 4.19, but I don't see the "fix" that generated the problem
<apritzel>
I don't care so much about DT backports (that's a weird concept to begin with)
\\Mr_C\\ has joined #linux-sunxi
<apritzel>
but more about nicely working machines (with a fixed DT provided by U-Boot) suddenly breaking after a stable kernel update
<pgreco>
if it doesn't break current lts kernels, I'd rather have updated device trees even in lts
<apritzel>
pgreco: that's if you take DTs from the same place where your kernel comes from, which is quite tricky with grub
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
<pgreco>
yeah, I mean, I don't see any good options
<apritzel>
so I was wondering if just "rgmii" is not a valid option anymore, the driver could recognise it as coming from a "legacy" DT, and fall back to the old behaviour (given that is still feasible)
Mangy_Dog has joined #linux-sunxi
<pgreco>
I think that's part of the problem, from what I understand rgmii is still a valid option
<pgreco>
so there's not real fallback
<apritzel>
pgreco: understood, I was afraid you were saying that ...
<pgreco>
apritzel: take my words with a grain of salt, I may be severely mistaken (though I don't think I am) ;)
<mripard>
that's my understanding as well
<apritzel>
mripard: thanks. But that's not only a sunxi problem, isn't it?
davidebeatrici has quit [Quit: Bridge terminating on SIGTERM]
z3ntu has quit [Quit: Bridge terminating on SIGTERM]
solderfumes[m] has quit [Quit: Bridge terminating on SIGTERM]
insep_ has quit [Quit: Bridge terminating on SIGTERM]
mahoux has quit [Quit: Bridge terminating on SIGTERM]
hpagseddy[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam has quit [Quit: Bridge terminating on SIGTERM]
Ke has quit [Quit: Bridge terminating on SIGTERM]
Irenes[m] has quit [Quit: Bridge terminating on SIGTERM]
fevv8[m] has quit [Quit: Bridge terminating on SIGTERM]
clementp[m] has quit [Quit: Bridge terminating on SIGTERM]
Jeremy_Rand_DT[m has quit [Quit: Bridge terminating on SIGTERM]
psydruid has quit [Quit: Bridge terminating on SIGTERM]
TiD91 has quit [Quit: Bridge terminating on SIGTERM]
thefloweringash has quit [Quit: Bridge terminating on SIGTERM]
<pgreco>
I don't see "net: phy: realtek: fix rtl8211e rx/tx delay config" backported to 5.4
<wens>
it was only backported to 5.8
<mripard>
ah my bad, there's a commit called "Add rtl8211e rx/tx delays config"
<wens>
that's the "doesn't really fix anything because the register defs are wrong" patch
<pgreco>
yeah, that was the first bad commit, but IIUC, and the bits are actually ignored, backporting the dts fixes shouldn't break anything
<pgreco>
and that leaves the dts ready for the actual fix
gaston1980 has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
kaspter has quit [Quit: kaspter]
\\Mr_C\\ has quit [K-Lined]
hlauer has joined #linux-sunxi
<hlauer>
the DTS gmac s/rgmii/rgmii-id/ for banana m2u made it's way into 5.10-cr5 - thanks! It's needed for Banana Pro too, right?
<pgreco>
hlauer: I think so, but I don't know who has a device to test it, I made the one for the bpi-m1 which is pretty similar iirc
matthias_bgg has quit [Ping timeout: 256 seconds]
Mangy_Dog has quit [Ping timeout: 240 seconds]
AneoX has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
rex has quit [Quit: Bye]
lurchi_ is now known as lurchi__
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
rex_victor has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 260 seconds]
gaston1980 has joined #linux-sunxi
<hlauer>
pgreco: 5.10-rc4 is running with this change on my banana pro. Ethernet 100M is working fine
matthias_bgg has joined #linux-sunxi
<pgreco>
hlauer: so it works with "rgmii-id" but fails with "rgmii"
<pgreco>
?
<hlauer>
last version I tried with rgmii seems to be 5.9.6. Had some trouble with connectivity, so I tried 5.9.8 with rgmii-id.
<hlauer>
Any kernel message to look for?
<pgreco>
hlauer: no, just that network works with rgmii-id and fails with rgmii (making the change to the dts needed)
<hlauer>
Ok, will test when rc5 compilation (running on m2u at the moment) is finished and report back
gaston1980 has quit [Ping timeout: 240 seconds]
gaston1980 has joined #linux-sunxi
<jernej>
apritzel: boot0 for OPi has dual rank bit set in configuration, although I don't see how would that make sense
<apritzel>
jernej: really? indeed ...
<apritzel>
I mean I can force it on and see ...
<jernej>
apritzel: bit 12 dram_para2 is rank (0 - single, 1 - dual) and bit 0 is bus with (0 - 32, 1 - 16)
<apritzel>
yeah, I believe you, just checking the schematic and DDR datasheet
<jernej>
as I said, I don't think this is correct
<jernej>
except if this is something for 512 MiB variant of the board
<jernej>
I didn't really experiment with different locations if DRAM didn't work - it was pretty obvious if SPL crashes or not
<jernej>
so I can't tell what those patterns mean
netlynx has joined #linux-sunxi
<apritzel>
so the schematic shows two chips, but with a #CS and a #CS1 input, wired to SCS0 and SCS1, respectively. So are those dual rank chips then?
<apritzel>
possibly only the 512MB version, because they couldn't get so small x16 chips?
rex_victor has quit [Ping timeout: 264 seconds]
vagrantc has joined #linux-sunxi
rex_victor has joined #linux-sunxi
rex_victor has quit [Killed (Sigyn (Spam is off topic on freenode.))]
lucascastro has quit [Ping timeout: 256 seconds]
<jernej>
hm... DRAM datasheet shows L1 as NC, but board schematic shows as CS1#
<jernej>
I wonder which DRAM chip is used on 512 MiB version
<apritzel>
jernej: the DRAM datasheet I am looking at mentions only one #CS signal
<jernej>
apritzel: mine too, but if you check board schematic, you'll see L1 pin is used as CS1#
<apritzel>
yeah, just understood what you mean ...
<jernej>
maybe this is just standard footprint and it's wired just in case
<apritzel>
the picture on the website seems to show the 1GB version, so no clue on the smaller version's chips
lucascastro has joined #linux-sunxi
<jernej>
did you compare SPL vs. boot0 values?
<jernej>
also for controller
<jernej>
but controller values depend on frequency
<apritzel>
does your TV box' boot0 use 696 MHz?
<apritzel>
and indeed comparing the timing parameters was my plan for tonight
<jernej>
yes, it's 696 MHz
<apritzel>
mine is 720 MHz
<apritzel>
the shop website shows the same pictures for both RAM versions :-(
lurchi__ is now known as lurchi_
<jernej>
I should get my OPi zero2 soon, but until then I can't do much
rex_victor has joined #linux-sunxi
<apritzel>
Has someone here ordered (or already received) the 512MB version of the Orange Pi Zero 2? Would love to know which RAM chips they use ...
<apritzel>
jernej: no worries, you are helping tremendously already! Will try to further debug tonight ...
rex_victor has quit [Client Quit]
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
luke-jr has quit [Excess Flood]
lucascastro has quit [Remote host closed the connection]
luke-jr has joined #linux-sunxi
lucascastro has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
luke-jr has quit [Read error: Connection reset by peer]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
luke-jr has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
rex_victor has joined #linux-sunxi
psydread has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
psydread has left #linux-sunxi [#linux-sunxi]
lucascastro has quit [Ping timeout: 240 seconds]
ldevulder_ has joined #linux-sunxi
<jernej>
apritzel: should be SPL size changed for H616? I don't think there is any real reason to hold back on 32k
<apritzel>
jernej: not so sure, we have this: U-Boot proper starts 32KB after SPL, for instance
ldevulder has quit [Ping timeout: 240 seconds]
<apritzel>
jernej: it smells like some refactoring to make this an easier per-SoC choice
<jernej>
there is already macro in sunxi-common.h for SPL size
<jernej>
and your mksunxiboot removal would also help
<apritzel>
jernej: if you turn the phy_init[] array into u8 and replace writel with writel_relaxed in most places, we should get down quite a bit
<apritzel>
the 360 bytes excess that you once mentioned were for an earlier version of the driver?
<jernej>
no, that oveflow happened when I enabled FIT handling
lucascastro has joined #linux-sunxi
<jernej>
apritzel: memory barriers at DRAM init stage don't make much sense, right? at least for in-order CPU
<apritzel>
yes, mostly not, at least not as long as you program a bunch of parameters, then enable them by setting a bit
<apritzel>
when using writel, each store is followed by a dmb instruction, plus the compiler barrier (the "memory" constraint in the inline assembly) prevents further optimisation