<freemangordon>
hmm, I think I know why kernel rebuilds every time
<freemangordon>
damn CROSS_COMPILE should be env var it seems, not make parameter
<freemangordon>
like 'export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-'
<bencoh>
you mean make CROSS_COMPILE=whatever- doesn't work?
<bencoh>
funny, I never actually tried I think
<Wizzup>
I always have them as env var
<bencoh>
same
<freemangordon>
it works, but make ARCH=arm omap2plus_defconfig seems to use HOST gcc version string
<Wizzup>
ha
<freemangordon>
and ofc I do not pass CROSS_COMPILE for make defconfig
<Wizzup>
ah, you should
<freemangordon>
yeah, looks like :)
<Wizzup>
I do this:
<Wizzup>
make -j16 ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- omap2plus_defconfig
<Wizzup>
ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- make -j16
<freemangordon>
but, with env var EVERYBODY is aware of the situation
<Wizzup>
INSTALL_MOD_PATH=`pwd`/output ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- make -j16 modules_install
<freemangordon>
yeah, yeah
<Wizzup>
:)
<Wizzup>
let me know if I can help facilitate the bisect somehow
<freemangordon>
I am not sure how to deal with that
<freemangordon>
git diff tmlind/droid4-pending-pvr-omapdrm-v5.9..tmlind/droid4-pending-pvr-omapdrm-v5.15 drivers/gpu/drm/pvrsgx/ results in differences that cannot result in a device hang (makefiles changes and more platforms supported)
<freemangordon>
git diff tmlind/droid4-pending-pvr-omapdrm-v5.9..tmlind/droid4-pending-pvr-omapdrm-v5.10 drivers/gpu/drm/omapdrm results in only one suspicious change I am going do test reverted now
<freemangordon>
if it is not that, I have no idea how to find what breaks it
<freemangordon>
there are lots of changes in drm though
<Wizzup>
maybe there is a slight chance that something is printed on serial when it hangs
<freemangordon>
ok, you can try it
<Wizzup>
I'll need to set up a sd card for it, I don't have any of that set up (yet)
<freemangordon>
hmm, why?
<freemangordon>
you just need one directory I will share
<freemangordon>
letux-pvrsrvkm-5.15-rc1 does not boot
<tmlind>
freemangordon: hmm so what did i break now? :)
<tmlind>
have not read the logs yet, but you trying to update pvr hopefully?
<freemangordon>
tmlind: I am not sure it is you
<Wizzup>
We're trying to debug why the n900 hangs for pvr since 5.10+
<freemangordon>
but I hope you can help me with that one, so:
<freemangordon>
tmlind: 33bc438d6d8883d77e37b369fe5144ee9b01fad8 makes it unbootable on n900
<freemangordon>
but, the initial issue is that starting with 5.10, kmscube renders one frame and device freezes
<freemangordon>
I did git diff tmlind/droid4-pending-pvr-omapdrm-v5.9..tmlind/droid4-pending-pvr-omapdrm-v5.10 drivers/gpu/drm/pvrsgx and git diff tmlind/droid4-pending-pvr-omapdrm-v5.9..tmlind/droid4-pending-pvr-omapdrm-v5.10 drivers/gpu/drm/omapdrm but I see nothing suspicios
<freemangordon>
so, the problem must be somewhere else, but I have no idea what to do
<freemangordon>
tmlind: ^^^
<tmlind>
freemangordon: i'd try with v5.15 pvr branch, then revert 33bc438d6d8883d77e37b369fe5144ee9b01fad8 or whatever that commit might be there
<freemangordon>
tmlind: already did - it boots, but as I said, device hangs after the first frame is rendered
<tmlind>
ok
<freemangordon>
the same was on 5.10 (the hang)
<freemangordon>
on 5.0 it was working
<freemangordon>
*5.9
<tmlind>
and pvr clock is configured in the dts for omap3?
<freemangordon>
I guess it needs some PM functions
<Wizzup>
yeah, maybe this is a moment to wait for tmlind :p
<freemangordon>
:nod:
<Wizzup>
I need to do some things in the house
<freemangordon>
me too
l_bratch has quit [Quit: Leaving]
<tmlind>
yeah that looks like some pm_runtime issue
<freemangordon>
tmlind: any hint how to fix it? is it possible to disable PM in runtime to test if it will still fail?
<tmlind>
freemangordon: yeah let me tell you what to comment out, a bit bad connection right now, few mins
<freemangordon>
ok
<tmlind>
freemangordon: you can disable runtime pm via sysfs by finding the target module in /sys and echo on > power/control, auto re-enables runtime pm
<freemangordon>
ok, lemme try
l_bratch has joined #maemo-leste
l_bratch has quit [Remote host closed the connection]
l_bratch has joined #maemo-leste
<tmlind>
echo on > /sys/devices/platform/68000000.ocp/50000014.target-module/power │[~] $
<freemangordon>
doing that resulted in freeze without cube
<tmlind>
sorry power/control i mean
<freemangordon>
root@devuan-n900:/sys/module/pvrsrvkm_omap3_sgx530_121/drivers/platform:pvrsrvkm/50000000.gpu/power# echo on > control
<freemangordon>
^^^ is not correct?
<tmlind>
both should work, the target module controls the resources, gpu module controls internal gates only
<freemangordon>
tmlind: shall I try /sys/devices/platform/68000000.ocp/50000014.target-module/power/control or what I already tried is ok?
<tmlind>
freemangordon: well sounds like it already removed the runtime pm issue?
<freemangordon>
ok, what I tried resulted in device hang, with no cube
<Wizzup>
trying as well to see if I get a panic
<Wizzup>
the write itself does nothing bad for me at least
<Wizzup>
yeah I think I see the same as fmg, similar panic, but no first frame is rendered
<tmlind>
yeah i see the runtime pm issue too on n900
<Wizzup>
maybe it is not related to powervr but gets triggered and it's similar to the random boot failure I se
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 245 seconds]
<tmlind>
do did it work earlier with the same dts config or just with older ddk?
<Wizzup>
I think freemangordon said it worked on 5.9 with the same ddk
<tmlind>
weird
<Wizzup>
but we're having trouble bringing 5.10 to live/boot at all, so the bisect is harder
<tmlind>
heh
<Wizzup>
freemangordon: maybe you can (re)confirm that the ddk on 5.9 does work
<bencoh>
do you have earlycon / a serial console?
<Wizzup>
yes, but there's many things to dig through
<Wizzup>
see earlier log today
<freemangordon>
yes, I confirm
<freemangordon>
5.9 was fine
<freemangordon>
I even posetd benchmarks
<freemangordon>
*posted
<freemangordon>
could it be that off mode that was enabled?
<tmlind>
seems like this should be really tracked down with git bisect.. does v5.10.y boot better with all the stable fixes?
<freemangordon>
I can try
<tmlind>
ok
<freemangordon>
but, how do you think I shall bisect?
<tmlind>
well you're have to carry the a patch with you through the bisect, there's some option for carrying a commit
<tmlind>
assuming v5.10.y has some fix that makes v5.10 usable for bisect that is
<freemangordon>
I don;t know which patch I need for 5.10 to boot
<freemangordon>
back then I was able to boot 5.10, but today I failed
<tmlind>
right but if v5.10.y boots, there's some patch there between v5.10..v5.10.y
<freemangordon>
oh, bisect to find the one I need first
<freemangordon>
right
<freemangordon>
this will take ages
<tmlind>
yeh, then carry it..
<freemangordon>
yeah
<freemangordon>
ok
<tmlind>
seems like two bisects are needed, one to boot, then another hopefully much easier one to track down the pvr issue
<freemangordon>
yeah
<freemangordon>
ok
<tmlind>
at some point we had to change the pvr build options for memory allocation, i think that was never properly resolved
<freemangordon>
mhm
<freemangordon>
if I can boot 5.10 at all
<tmlind>
need to transit now, bbl
<freemangordon>
bye
<freemangordon>
Wizzup: ok, what now
<freemangordon>
I mean - I am not sure I'll be able to boot 5.9 without serial
<Wizzup>
5.9 or 5.10
<freemangordon>
I think we need 5.9 and then bisect to 5.10
<freemangordon>
lemme try first to see if vanilla 5.9 boots on n900
<freemangordon>
5.9.y that is
<Wizzup>
it might also be good to see if 5.10 stable boots
<freemangordon>
mhm
<Wizzup>
then we can rebase pvr on top of stable and bisect that way
<freemangordon>
right
<freemangordon>
hmm, no
<freemangordon>
it is not a pvr change I think
<Wizzup>
we will figure that out soon enough then, at least it'll boot
<Wizzup>
but yeah, maybe
<Wizzup>
tmlind said they did change stuff for memory allocation, so it could be that
<freemangordon>
I know what he means, it is not that, it was a change in 3.8
<Wizzup>
5.8?
<freemangordon>
yeah
<freemangordon>
5.8
<Wizzup>
ok
<freemangordon>
maybe we can split the work
<freemangordon>
I can bisect 5.9 to see what commits are needed for it to boot
<freemangordon>
you can do the same for 5.10
<Wizzup>
sure, but I won't have a lot more time today
<Wizzup>
so you're asking me to figure out what patches from 5.10.y are required for plain 5.10 to boot?
<freemangordon>
yeah, but if you don't have time, I'll try to figure it out
<Wizzup>
I have a visitor for the rest of the day soon
<Wizzup>
I can continue tomorrow
<freemangordon>
ok
<freemangordon>
5.9.16 boots, at least
<Wizzup>
maybe we can confirm that that + ddk 1.17 works for the cube?
<freemangordon>
this is what I am doing
<freemangordon>
just merged tony's 5.9 droid branch
inky_ has quit [Ping timeout: 252 seconds]
_inky has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
<mighty17[m]>
do we have a workaround for GL_EXT_read_format_bgra on series5 (sgx5) gpus?
inky_ has quit [Ping timeout: 252 seconds]
nohit has quit [Ping timeout: 252 seconds]
nohit has joined #maemo-leste
_inky has joined #maemo-leste
<tmlind>
mighty17[m]: have not hit that one so far, what happens?
<tmlind>
freemangordon: plain v5.10 boots on n900 for me, maybe the mmc devices moving around again?
<freemangordon>
5.9.y boots for me, but not with droid4-pending-pvr-omapdrm-v5.9 merged
peetah has quit [Quit: -]
peetah has joined #maemo-leste
<freemangordon>
will revert "Flush what framebuffer wants flushed even if using page faults" and will retry
<tmlind>
ok
<mighty17[m]>
<tmlind> "mighty17: have not hit that..." <- comes in phosh for me (everything is fine just this comes up in log)
<mighty17[m]>
tmlind: do we have a fix for missing GL_OES_texture_border_clamp as well?
<tmlind>
mighty17[m]: the border clamp yeah, maybe the IMG_read_format workaround needs to be extended also for GL_EXT_read_format_bgra?
<mighty17[m]>
we can try that, but funny part is ` render/gles2: handle IMG_read_format like EXT_read_format_bgra ` we already do it?
<tmlind>
oh ok
<mighty17[m]>
send me the border clamp patch pls :D
<tmlind>
oh we only have the "render/gles2: Properly handle GL_EXT_unpack_subimage", no idea what else you might need there
<mighty17[m]>
so nothing for GL_OES_texture_border_clamp?
<tmlind>
don't think so, but see "render/wlr_texture: clamp texture coordinates to edge by default"
<mighty17[m]>
well GL_OES_texture_border_clamp happens in plamo for me
<mighty17[m]>
plamo doesnt use wlroots it uses kwin i think?
<tmlind>
no idea.. anyways the earlier patch from jonathan bakker had that included i think but that turned out to be a more generic problem
<mighty17[m]>
indeed
<mighty17[m]>
either i have to package 1.9 for xwayland or give up
<sicelo>
1.9 being?
<mighty17[m]>
ddk
<sicelo>
that's deprecated. newer kernels don't support it.
<mighty17[m]>
tmlind's newer kernel dropped it, but openpvrsgx should support it?
<mighty17[m]>
atleast 5.15-rc1
<tmlind>
i would not bother with that old crap, it never worked properly afaik
<tmlind>
i think xwayland is still broken for gles2 acceleration, ddk-1.9 won't help with that
inky_ has joined #maemo-leste
<freemangordon>
does not boot, but, in a different way :(
<freemangordon>
oh, but at least I have dmesg log
<freemangordon>
hmm:
<freemangordon>
udevd[455]: could not open moddep file '/lib/modules/5.9.16-00404-g43c25c2037ae/modules.dep.bin'
<mighty17[m]>
<tmlind> "i think xwayland is still broken..." <- oh well, is 1.19 the magical solution then? :P
<freemangordon>
I guess I should have waited for FS sync to complete
<tmlind>
heh
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
_inky has quit [Ping timeout: 250 seconds]
<freemangordon>
finally 17.217437] [drm] Initialized pvr 1.17.4948957 20110701 for 50000000.gpu on minor 0
<freemangordon>
tmlind: "PVR_K:(Error): PollForValueKM: Timeout. Expected 0x1 but found 0x0 (mask 0x1)." needs vmalloc patch, right?
<tmlind>
i guess yeah
<freemangordon>
I was able to boot letux-pvrsrvkm-5.9-rc2 with 5.9.y on top
<freemangordon>
droid4-pending-pvr-omapdrm-v5.9 with 5.9.y merged does not boot
<freemangordon>
but then I hit the above error when doing pvrsrvctl
<tmlind>
ok so does letux-pvrsrvkm-5.9-rc2 with 5.9.y work for kmscube?
_inky has joined #maemo-leste
<freemangordon>
and with eda22727a5575fe449a479539360282789bbc9fe cherry-picked kmscube works
<tmlind>
hmm sorry what's the eda22 commit, not seeing that one
<freemangordon>
Use PVR_LINUX_MEM_AREA_USE_VMAP to load driver properly
<tmlind>
ok
<freemangordon>
no idea why you don;t have that sha
<tmlind>
not sure sounds like i should
<freemangordon>
mhm, it is signed off by you :)
<tmlind>
yeah and i remember chasing that one down :)
<freemangordon>
mhm
<freemangordon>
anyway, we have something that works on n900
<freemangordon>
now what?
<freemangordon>
try to "downgrade" 5.9.y to 5.9?
<tmlind>
how about try to merge letux-pvrsrvkm-5.9-rc2 and that vmap patch on v5.10.y?
<freemangordon>
hmm, ok, lets try
pere has joined #maemo-leste
<freemangordon>
Automatic merge failed; fix conflicts and then commit the result. :(
<freemangordon>
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/vendor-prefixes.yaml
<tmlind>
sounds like you can resolve that one whichever way :)
<freemangordon>
yeah
<freemangordon>
tmlind: sorry, my bad, commit is f11c7d82d983b4bdcf6fbedd2e8748b3321e39f1
<freemangordon>
it seems cherry-pick changes sha
<tmlind>
yeah ok
<tmlind>
not seeing much anything changing between letux-pvrsrvkm-5.9-rc2..letux-pvrsrvkm-5.10-rc1 based on a quick diff, sucks if you have to test all the versions up to v5.15 :(
<tmlind>
anyways, ttyl
<freemangordon>
that's why I think the change is in linux, not in pvr
<freemangordon>
fingers crossed :)
Twig has quit [Ping timeout: 252 seconds]
<freemangordon>
doesn;t boot :(, lemme check if I broke something
sunshavi has quit [Ping timeout: 265 seconds]
Twig has joined #maemo-leste
Twig has quit [Remote host closed the connection]
DPA has quit [Ping timeout: 246 seconds]
<freemangordon>
tmlind: 5.10.72 with letux-pvrsrvkm-5.9-rc2 on top works
<Wizzup>
ah
<Wizzup>
freemangordon: nice going ;)
<Wizzup>
takes a weekend, but solid progress
<Wizzup>
ty
<freemangordon>
yeah
<freemangordon>
but, why it didn't work back then?
<freemangordon>
maybe some other patch breaks it
<freemangordon>
also, I see 'power off on boot' half of the times with 5.10
<freemangordon>
I guess this is the same issue you reported
sunshavi has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
DPA has joined #maemo-leste
<freemangordon>
anyway, enough for today
<freemangordon>
gn!
<Wizzup>
22:35 < freemangordon> also, I see 'power off on boot' half of the times with 5.10
<Wizzup>
22:35 < freemangordon> I guess this is the same issue you reported