<jernej>
apritzel: I'm not even sure if there is any discernible difference between T95 and X96
<apritzel>
jernej: I was wondering about that as well
<apritzel>
I managed to adapt your T95 Ethernet hack to my box (more to mainline U-Boot, really), and it worked
<jernej>
yeah, fast ethernet can be done in only one way
<apritzel>
and I needed the same DRAM switches as you used in your T95 defconfig
<jernej>
do you have DT somewhere so I can take a look?
<jernej>
and btw, what kind of U-Boot config do you use for X96? I know I have to select slightly different options for DRAM config in comparison to Zero2 in order to get full amount
<apritzel>
jernej: that's what I meant above: I used the very same DRAM settings that I found in some T95 github branch of yours
<jernej>
ah, ok
<jernej>
then I guess there really is not any difference at this point
<apritzel>
have you identified the DRAM chips on your box? Mine apparently uses DDR3L chips, so I put the DCDCD to 1.36V
<jernej>
it's a long time since I worked on this
<jernej>
let me check
<apritzel>
btw: I really believe AW somehow messed up the reference design in respect to the AXP: DCDCB smells for DRAM all over the place
<apritzel>
my box had a reset value of 1.35V, for instance
<apritzel>
and I believe the OPi Zero2 uses 1.5V
<jernej>
my box uses MT41K1G4RH-125:E
<jernej>
it seems to be DDR3L but datasheet metions DDR3 compatible mode
<apritzel>
jernej: yeah, I thought that every DDR3L DRAM can be used with 1.5V as well?
<apritzel>
so it doesn't really hurt, just wastes energy (and defeats the purpose of using DDR3L in the first place)
<jernej>
I'm not very familiar with electrical part
<jernej>
so, do you think it should work with 1.35V?
<apritzel>
I marked some rails as "disabled", the BSP enabled them, but they were not needed for the subset of features I tested
tnovotny has quit [Quit: Leaving]
<apritzel>
I guess some of them might be needed for HDMI and/or Ethernet
fl_0 has joined #linux-sunxi
<jernej>
no problem, they can be enabled later
<jernej>
anyway, for now, X96 seems compatible with T95
<apritzel>
so have a t95.dts which includes the x96 one, for now?
<apritzel>
then we can always differentiate later, either separating them completely, or using a common stub, like this sun5i-reference-design-tablet.dtsi
<notgood>
part of the HUD rendered over Kodi seek bar is fine
<notgood>
part of the HUD rendered over video isn't OK
<ndufresne>
But the seekbar is likely not using a fullscreen frame buffer
<anarsoul|2>
well, render target is still fullscreen
<ndufresne>
I guess that's left for later optimization ;-D
<jernej>
just to mention, it probably doesn't change anything, if you're using 4k screen, gui plane will still be only 1080p and then upscaled
<anarsoul|2>
ndufresne: I don't think it's possible
<ndufresne>
it depends on the HW capabilties, not sure about this one
<ndufresne>
most of the time, only some video layer can be subregions and moved around
<ndufresne>
there might be some optimization in the GL driver too, I'm not saying it's impossible to be a mesa issue, but the hud should likely not disable that
<jernej>
ndufresne: IIRC in Kodi, UI framebuffer always matches screen resolution unless it's > 1080p, then UI plane is kept at 1080p
<jernej>
note that this trick is used only on ARM boards
<jernej>
anyway, I still think that the only possible reason for that issue is wrong alpha channel values
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
<ndufresne>
could be, perhaps a premult vs straight kind of issues
<ndufresne>
ah wait, if the content is premult, but the display driver assumes straight ....
<ndufresne>
jernej: is the display driver sunxi specific or something generic used by many boards ?
<jernej>
what do you mean by display driver and sunxi specific?
<jernej>
Kodi doesn't have anything sunxi specific
<jernej>
and GUI plane is rendered as DRM_FORMAT_ARGB8888 in Kodi
<jernej>
I mean, UI framebuffer
<anarsoul|2>
notgood: does it work fine on any other board?
<notgood>
only got two ARM boards, H6 and H3, problem on both
<ndufresne>
jernej: ARGB8888 should be coded with premultiplied alpha by default
<ndufresne>
if the HW is setup to straight blending, then color values are much lower then what you actuallye expect and stuff may disapear, just a wild guess here
arnd has quit [Ping timeout: 250 seconds]
<jernej>
blending mode is currently hardcoded and set to same value as BSP, which is:
lvrp16 has quit [Ping timeout: 245 seconds]
<jernej>
source: 1 destination: 1 - source
<anarsoul|2>
notgood: that's likely something with sun4i-drm then since H3 uses lima for gles and H6 uses panfrost. I doubt there's the same bug in two completely different drivers
<jernej>
isn't HUD code common?
<anarsoul|2>
it is, I'd suggest testing on x86 machine or other SBC with different display driver
<jernej>
x86 would need to be intel
<anarsoul|2>
or AMD
lvrp16 has joined #linux-sunxi
<anarsoul|2>
or NVIDIA with nouveau
<jernej>
amd has only one plane afaik
arnd has joined #linux-sunxi
<anarsoul|2>
oh, OK
<jernej>
and nvidia is not supported in kodi direct to plane
<jernej>
ah, maybe with nouveau
<ndufresne>
test on RK3399 then ?
<ndufresne>
I have tested the blending mode recently on that one, and it's using premultiplied alpha (which means it will ignore the alpha channel when blending)
<ndufresne>
I would need a bit of setup and figure-out to do the same test on allwinner
<ndufresne>
planes don't work the same way
<ndufresne>
jernej: but from looking at this, I suspect the blend mode miss-match what the GL stack expect
<jernej>
premultiply mode can be set up
<jernej>
but probably not on 5.10
<jernej>
it's recent addition
<ndufresne>
ok, and did they change the default to premult ?
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
<ndufresne>
anyway, best is to setup and try, I'm too far on the setup to help further
<jernej>
let me first check if it's merged
<jernej>
and no, we don't change any defaults
<ndufresne>
haha, yeah, when you follow list, you never know what's merge and not merged
<jernej>
wait, nouveau doesn't support atomic mode?
<jernej>
that explains...
<notgood>
no idea :)
<jernej>
drmprime works only with atomic mode
<jernej>
most drivers already support it, but not nouveau, obviously
jstein_ has joined #linux-sunxi
<jernej>
later in the log you can see that only gui plane was found
<jernej>
so, this variant uses only single plane and all rendering is done through GPU
<notgood>
hmm, I could try to enable integrated Intel GPU on this box if that helps
<jernej>
I don't know
jstein_ has quit [Quit: quit]
notgood has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.1, revision: 5.0.1+git-7433-0df9f22f2, build type: debug, sources date: 20160102, built on: 2019-12-08 19:19:20 UTC 5.0.1+git-7433-0df9f22f2 http://www.kvirc.net/]
notgood has joined #linux-sunxi
<notgood>
jernej: atomic DRM supported on ancient integrated Intel GPU, but still no drmprime available in settings, and only gui plane used according to kodi.log
<notgood>
oh well
notgood has quit [Client Quit]
<k4be>
hi, do you know of any v40 sata instability? don't know if it's software or hardware
diego71 has quit [Ping timeout: 246 seconds]
diego71 has joined #linux-sunxi
<k4be>
one board falls back to 1.5G and then works perfectly, the other one keeps throwing errors in dmesg but still seems usable
netlynx has quit [Quit: Ex-Chat]
notgood has joined #linux-sunxi
notgood has quit [Quit: Leaving]
ldevulder has quit [Quit: Leaving]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
<apritzel>
k4be: on which kernel? mainline?
<apritzel>
k4be: and is the power situation OK? On the M2 Berry for instance the board is powered via an infamous micro-B, which is basically asking for trouble ...
<k4be>
the first one is mainline with sata patch (the version just prior to the one including the patch), the second one untouched mainline
<apritzel>
(if you power the disk from the board)
<k4be>
don't remember the version numbers
<k4be>
i've made the power supplies myself and trust them
<apritzel>
that's good!
<k4be>
these are 3.5 drives that require 12V too
<apritzel>
with "SATA patch" you mean the improvement for the write speed?
<k4be>
no, the support for sata in this soc
<apritzel>
that's somewhat old then?
<k4be>
yes
<k4be>
the second one is much newer
<apritzel>
why not try the latest mainline?
<k4be>
5.4.80-gentoo
<k4be>
i may try switching to the newest vanilla to see if it helps
diego71 has quit [Ping timeout: 246 seconds]
diego71 has joined #linux-sunxi
<apritzel>
k4be: thanks, please try that
<apritzel>
k4be: I just boot test something on my M2 Berry, but never used it in anger
<k4be>
the old one that works better is 4.18.0
<apritzel>
but also haven't heard of problems with SATA on the R40
<k4be>
these are both m2 berry, first one runs with wd green drive, second one with wd red
<apritzel>
only SSDs on my side ...
<k4be>
and it runs on 3.0G?
hlauer has quit [Ping timeout: 252 seconds]
jstein has quit [Quit: quit]
<apritzel>
don't remember, need to check
<apritzel>
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)