<macifom>
wens, thanks, it applies cleanly over 2018.09-rc2 so I'll try it there as soon as my build machine comes up for air
dddddd has quit [Ping timeout: 260 seconds]
lurchi__ is now known as lurchi_
jbrown has joined #linux-sunxi
dddddd has joined #linux-sunxi
<wens>
don't bother, I just tested it, it doesn't fix the data abort :(
<macifom>
wens, I see, what's your take on this? from your mailing list post it sounded like you thought this was a recent regression in u-boot
<macifom>
but I tried as far back as 2018.05 with GCC 8.2.0 and it fails
<macifom>
have you had any successes with 2018.07 on any GCC versions?
<wens>
later on I thought that it was the newer toolchain
<wens>
6.x works, 7.x and 8.x don't
<wens>
so I suggest getting the linaro toolchain for now :(
<macifom>
I roll my own toolchain, so that's not happening ;)
anarsoul has joined #linux-sunxi
<macifom>
I had success with 2018.05 on either 7.3.0 or 7.2.0
<wens>
btw, if you do have time to test other configs, try having u-boot boot secure
<wens>
you lose smp though
<macifom>
oof, that's a bit of a penalty
<macifom>
I'll add it to my list of things to try out
<macifom>
I'm about two months late on a major OS revision... not sure why I decided a toolchain upgrade would be a good idea
<wens>
I forgot, it's just an env setting, so I can try it without rebuilding
<wens>
and it works
<wens>
so the issue is somewhere in the sec/non-sec or psci code
<wens>
the hardest part to debug :(
<macifom>
working with the u-boot devs, we determined that A20 doesn't appear to be affected
<macifom>
or rather, the bananapi defconfig isn't affected
AneoX_ has joined #linux-sunxi
<macifom>
I had wondered if maybe some DE2 code could be involved, as there's been work there
AneoX has quit [Ping timeout: 264 seconds]
<wens>
it fails on the A33 as well, which is DE1
<macifom>
hmm
lmcloughlin has quit [Quit: Connection closed for inactivity]
dddddd has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
juri_ has joined #linux-sunxi
victhor has quit [Remote host closed the connection]
lurchi__ is now known as lurchi_
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
nuuuciano has quit [Ping timeout: 244 seconds]
jbrown has quit [Ping timeout: 272 seconds]
physpi24 has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
physpi24 has quit [Remote host closed the connection]
rexxster has quit [Remote host closed the connection]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
atsampson has quit [Ping timeout: 252 seconds]
mavkhimenia has joined #linux-sunxi
mavkhimenia has quit [Ping timeout: 252 seconds]
iamfrankenstein has joined #linux-sunxi
IgorPec has joined #linux-sunxi
gnufan1 has joined #linux-sunxi
gnufan1 has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
macifom has quit [Quit: Leaving]
reinforce has joined #linux-sunxi
Napsterbater has joined #linux-sunxi
lykt has joined #linux-sunxi
Napsterbater has quit [Ping timeout: 240 seconds]
AneoX_ has quit [Ping timeout: 244 seconds]
AneoX has joined #linux-sunxi
massi has joined #linux-sunxi
xerpi has joined #linux-sunxi
gnufan has quit [Read error: Connection reset by peer]
clemens3 has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson has quit [Remote host closed the connection]
djakov_ is now known as djakov
AneoX_ has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
AneoX has quit [Ping timeout: 264 seconds]
yann has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 272 seconds]
ElBarto has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
libv_ has joined #linux-sunxi
ElBarto has joined #linux-sunxi
libv has quit [Disconnected by services]
libv_ is now known as libv
afaerber has joined #linux-sunxi
msimpson has joined #linux-sunxi
f11f12 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
airwind has joined #linux-sunxi
tnovotny has joined #linux-sunxi
zgrepc has joined #linux-sunxi
yann has joined #linux-sunxi
mavkhimenia has joined #linux-sunxi
zgrepc has quit [Ping timeout: 244 seconds]
mavkhimenia has quit [Ping timeout: 264 seconds]
afaerber has quit [Quit: Leaving]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 252 seconds]
foxx_ has joined #linux-sunxi
mavkhimenia has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
<wens>
mali-450 es2gears performance at 4 fps on h5 lol
AneoX_ has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
afaerber has joined #linux-sunxi
<lvrp16>
lol
<MoeIcenowy>
wens: checked PMU IRQ issue?
<MoeIcenowy>
I think mripard/sunxi-mali has an issue mentioned it
<MoeIcenowy>
wens: btw does your graphics has corruption?
<MoeIcenowy>
(with mali-450
<wens>
MoeIcenowy: using meson driver now
<wens>
MoeIcenowy: no corruption. what kind are you seeing?
<wens>
my armsoc driver is heavily patched though
<wens>
ok, I think I see how to wire the PMU IRQ
<wens>
you still need blobs from rockchip or amlogic for mali-450 though. The allwinner ones don't seem to support it
<MoeIcenowy>
ah-oh
<MoeIcenowy>
wens: then if you run heavy programs will GL_OUT_OF_MEMORY happen?
<MoeIcenowy>
if it doesn't happen then you didn't meet my problem ;-0
<MoeIcenowy>
;-)
<MoeIcenowy>
I met it with RK r7p0
<MoeIcenowy>
after directly cheat the driver to be a PMUless design
<wens>
I don't see the driver ever requesting irq for PMU
<wens>
where did you see it waiting for the PMU?
Andy-D has joined #linux-sunxi
atsampson has joined #linux-sunxi
mhlavink has quit [Ping timeout: 244 seconds]
<MoeIcenowy>
wens: didn't see, but it really fixed the 5fps issue
<wens>
so how did you bypass it? remove the PMU address base?
<MoeIcenowy>
yes
brokenARM has joined #linux-sunxi
<wens>
looks like mali_pmu_wait_for_command_finish() doesn't actually "wait" on mali400
brokenARM has quit [Client Quit]
<wens>
and pmu time outs :(
<f11f12>
wens: do you know how the mali binaries know where the framebuffer memory is? I have mali running on V40 (gles test) but it doesn't render in the framebuffer, so the screen is blank
<wens>
I think it depends on what variant you are using
<f11f12>
I'm using r6p2 of the mali blobs
<wens>
yes, and what "variant"? x11? fbdev?
<f11f12>
fbdev
<wens>
I've only used the X11 variant myself
<f11f12>
stracing I can see it opens /dev/fb0 which otherwise works fine.
<wens>
with fbdev it probably just renders directly to fb0