<calebtheythem[m]>
the JTAG header pinout from the moto X was close enough, found the TX pin and it spits out bootloader logs
<calebtheythem[m]>
omg, the cheeky bootloader finds any `console=` args on the kernel cmdline and replaces it with `console=null`
xmn has joined #maemo-leste
<calebtheythem[m]>
aha and we have 5.15 booting!
<zmatt>
freemangordon: oh if it's of interest, I also found this bit of documentation/code I wrote to explain how exactly TILER swizzles addresses: https://pastebin.com/raw/pWWtEiXc
cockroach has joined #maemo-leste
joerg is now known as DocScrutinizer
DocScrutinizer is now known as joerg
xmn has quit [Quit: ZZZzzz…]
<dreamer>
hmm, want to try some gl4es on droid4 soon. have it working on pandora 1ghz now with pure data and Gem :]
cockroach has quit [Quit: leaving]
<joerg>
*crickets*
<tmlind>
calebtheythem[m]: nice to hear your got it working, got some link for the jtag header pinout for reference?
<calebtheythem[m]>
tmlind: its the qcom pm8921 pmic, similar ti the pm8941 i think, it has quite good support in mainline
<tmlind>
ok nice
<calebtheythem[m]>
the emmc works already with no configuration from what i can tell, USB and display will be trickier
<tmlind>
ok what's the usb controller then?
* tmlind
at least not musb hopefully
<tmlind>
dwc2 maybe?
<calebtheythem[m]>
probably dwc2
<calebtheythem[m]>
theres no dt for it yet, and downstream is uhhh pretty useless. im not very familiar with board files so it will be a learning experience
<calebtheythem[m]>
currently it seems the watchdog driver fails to probe with some clock error, so i have that to resolve first otherwise it reboots after ~30 seconds or so
<tmlind>
ok yeah the old downstream kernels can be mostly used as some kind of register documentation :)
<tmlind>
zmatt: hi, so there are now open sourced mesa patches from chromeos so the situation is a little bit better than last time around
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
vectis_ has joined #maemo-leste
<sicelo>
Nice work calebtheythem[m]
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #maemo-leste
<Danct12>
calebtheythem[m], GIVE ME YOUR PHOTON Q
<Danct12>
*angry face*
zhxt has quit [Ping timeout: 250 seconds]
zhxt has joined #maemo-leste
xes has quit [Ping timeout: 260 seconds]
mrkrisprolls has quit [Ping timeout: 264 seconds]
xes has joined #maemo-leste
<freemangordon>
zmatt: going to send SG patch for upstreaming, what name/email to use for Suggested-by: tag?
<zmatt>
see pm. how much fudging was required in the end to make it work? :)
<zmatt>
I'll admit I don't know much about how mesa works... like, where does this fit in in the big picture?
<freemangordon>
we have a couple of blobs replaced with FOSS stuff
<freemangordon>
zmatt: RE fudging - not that much
<zmatt>
which? this still links to the closed source libs right?
<freemangordon>
basically your patch re fine, IIUC, and I have to teach SGX driver to not assume it receives scatterlist that describes a single block of contiguous memory
<freemangordon>
zmatt: pvr_dri.so, for example
<freemangordon>
yes, it still links to the closed blobs
nohit has quit [Ping timeout: 264 seconds]
nohit has joined #maemo-leste
<zmatt>
what exactly does this do/provide? like, I noticed the structural changes between the 1.14 and 1.17 drivers, and the introduction of mesa stuff such as its libgbm instead of the custom one used in 1.14, but I don't know what exactly the significance/impact is of these changes
mrkrisprolls has joined #maemo-leste
<freemangordon>
I was able to get xorg working in 1,17 ;)
<zmatt>
ah
<zmatt>
because x11 depends (for 3d accel) on mesa, and the sgx libs now function as a plugin into that?
<freemangordon>
well, my work is based on top of chromeos driver, which allowed us to have xorg support
<freemangordon>
but, I REed pvr_dri that comes with 1.17 blobs, so we now have 100% match
<freemangordon>
chromeos mesa was crashing SGX with glmark-es2-drm. Also, IIRC it has issues with wayland
<freemangordon>
x11 3d support depends on dri2/dri3 support in mesa
<freemangordon>
or rather EGL_PLATFORM_X11 and the was compiled out in MESA coming with the blobs
sixwheeledbeast has left #maemo-leste [#maemo-leste]
<Wizzup>
should we start looking at packaging this?
<freemangordon>
not yet
<freemangordon>
well, "start looking", yes
<freemangordon>
:)
sixwheeledbeast has joined #maemo-leste
<Wizzup>
ok
<freemangordon>
oh, send a bad patch
<freemangordon>
:*
<freemangordon>
:(
<Wizzup>
happens
<freemangordon>
yeah
<Wizzup>
so apart from kernel, mesa, and new userspace, we need the omap ddx?
<freemangordon>
yes
<freemangordon>
so far I have SolidFill accelerated
<Wizzup>
do we care which mesa we use in particular? i.e. do we go the extra mile and somehow get new meson working in our CI to build recent mesa release?
<Wizzup>
or do we stick to some older release with your work on top
<freemangordon>
I think this makes sense
<freemangordon>
(get lates)
<freemangordon>
*latest
<freemangordon>
sec, to re-send the patch
inky has joined #maemo-leste
_inky has quit [Ping timeout: 260 seconds]
inky_ has quit [Ping timeout: 245 seconds]
<Wizzup>
makes sense - older release or latest mesa?
<zmatt>
freemangordon: I have no idea about this anymore though, I don't remember the issue at all and would need to dig into how scatterlists work again, which I don't think I am going to since I have other stuff that needs my attention
<freemangordon>
yeah, sure
<freemangordon>
I am not going to send that nents/orig_nents patch anyway
<freemangordon>
tmlind: do you plan to upstream your prm fixes?
<freemangordon>
also, it seems we have 5.15 released, are you goingt o rebase?
_inky has joined #maemo-leste
<freemangordon>
ok, all patches were send :)
<zmatt>
freemangordon: looks like this would be a case for using for_each_sgtable_dma_sg() ?
<freemangordon>
yeah, I know it is ugly, but basically I copied what was already there
<freemangordon>
but yeah, I may look into that
<freemangordon>
ah, it is one-line change
<freemangordon>
well...
<freemangordon>
will fix if nikolaus asks me to do so
<freemangordon>
VRFB suppot in omapdrm is of higher prio
<freemangordon>
*support
<zmatt>
so what happens here if any scatterlist element is not actually page-aligned?
<freemangordon>
no idea
<freemangordon>
also, don;t know how test that
<freemangordon>
I can only hope PVR driver is smart enough to deal with that
<zmatt>
that seems highly unlikely
<freemangordon>
why not?
<zmatt>
because there's no way to handle that other than by failing or doing something bad
<freemangordon>
zmatt: I understand, lets see how Tomi will comment on the patch and I will propse TILER buffers to be PAGE aligned
<freemangordon>
or, maybe he will come up with another solution to that
Pali has joined #maemo-leste
<zmatt>
and it shouldn't be hard to test, if you allocate two buffers whose width (rounded up to a multiple of 32) is not a multiple of 1024 pixels you'll probably get a misaligned buffer
<freemangordon>
yes, but I would really want some comments from upstream first
<dreamer>
zmatt: remember you also noted some recent builds for sgx, except some missing SoCs right?
<dreamer>
noticed*
pere has quit [Ping timeout: 264 seconds]
pere has joined #maemo-leste
_inky has quit [Ping timeout: 260 seconds]
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 264 seconds]
<tmlind>
freemangordon: ah right, i should send that omap3 prm patch out, will do after -rc1
<tmlind>
will also merge or rebase the pending patches after -rc1
<tmlind>
zmatt: yeah so less binary blobs, and nothing really stopping adding functions using standard drm functions that relate to kernel implementation like the 2d acceleration support done for gma500 pvr driver in kernel for example
<tmlind>
freemangordon: so if we fixed up the kernel module mmu support, and added something similar to gma500 2d functions, then xorg/mesa could just use those without any need to pipe the functions to the binary blobs?
<freemangordon>
no idea
<freemangordon>
I don't know what gma500 2d functions do
<tmlind>
accelerate 2d?
<freemangordon>
yes, but how?
<freemangordon>
by sending opcodes to 2d/3d engine?
<tmlind>
no it seems the 2d part is separate, there is some very limited blit function
<freemangordon>
blobs seem support all the solid ALU x11 ops
<freemangordon>
and also all composite ops
<freemangordon>
no idea how do the do it, but seems to be in HW
<freemangordon>
not to say that ultimately I want something that works so I will be able to get back to osso-abook
<tmlind>
heh, can't any longer find the accelerated 2d blit function in the gma500 driver
<tmlind>
looks like it got removed with commit 846939118270 ("drm/gma500: Remove 2D accel code")
<tmlind>
psb_accel_2d_copy()
<freemangordon>
hmm, looks similar to what blobs do
<tmlind>
oh
<tmlind>
just fyi, not saying there's any need to do anything about it, but seems kind of pointless piping everything to the blobs if the kernel sort of already knows about how to do it..
<freemangordon>
maybe we shall clone that in leste, dunno
<Wizzup>
yeah we'd probably want to package a part of that I recon
<Wizzup>
maybe we can make a github issue for packaging this?
<Wizzup>
would make it easier to pick it up without back and forths
<parazyd>
Wizzup: pong
<Wizzup>
fmg asked for help packaging all the new 3d stuff which will bring n900 and droid4 to 5.15 and dk 1.17
<Wizzup>
ddk 1.17
<Wizzup>
I can help some, but maybe you can help some too
<Wizzup>
we'll probably want to use -experimental for a bit
<parazyd>
I can help tomorrow, sure.
<parazyd>
If you have a list of pkgs, it'd be helpful
<Wizzup>
I think that's a part we have to figure out
<Wizzup>
there's mesa with patches
<Wizzup>
and the ddk binary stuff, also a -dev header pkg for it
<Wizzup>
and omap ddx at least
<Wizzup>
not sure if there is more
r3boot has joined #maemo-leste
<parazyd>
aha, ok
<Wizzup>
freemangordon: where is the kernel tree?
<parazyd>
Did you already play some with mesa packaging?
<Wizzup>
parazyd: no, but 4-5 folks built mesa on their d4, and I was thinking of toying with bencoh's cross compile thing to build it on my laptop first
<Wizzup>
it just seems to need meson from deb stable
<parazyd>
Alright
<parazyd>
From the mesa we currently build, we had to downgrade the meson dep to 0.49
<parazyd>
And pull the rest from backports
<parazyd>
However backports is just build-dependency, not necessary for runtime.
<Wizzup>
right
<Wizzup>
what do you mean downgrade?
<parazyd>
And there's also glvnd and libdrm which we might want to try to update.
<parazyd>
By downgrade, I mean replacing the 0.52 with 0.49 in debian/control.
<freemangordon>
this is the hack I came up with on d4
<freemangordon>
I call it every time scanout has been changed
<tmlind>
ok let me post some kind of version of what i did in omapdrm
<freemangordon>
for me this assures the latest change is always visible
<freemangordon>
tmlind: I think th issue is that omapdrm have no idea if sgx has rendered something so it never flushes framebuffer to the display unless forced
<freemangordon>
ttyl
<tmlind>
here you go, maybe give this a try and see if it might make sense: muru.com/linux/d4/omapdrm-flush-on-pin-unpin.patch
<tmlind>
later
<freemangordon>
tmlind: maybe do that for manually updated displays only
<freemangordon>
also, when this pin/unpin happens?
<tmlind>
not quite sure, but yeah only needed for manually updated displays
<bencoh>
Wizzup: do you want me to upload an uptodate version of that howto?
<tmlind>
freemangordon: omap_crtc_flush() already returns early if not manually_updated display. no idea if pin/unpin is the right place for the flush though
<tmlind>
it might be flushing way too often, i guess glmark would tell
<freemangordon>
TDB, I don;t think kernel has information about when a flush is needed
<freemangordon>
*TBH
<tmlind>
yeah might be
<freemangordon>
also pn/unpin is mmap/munmap, no?
<tmlind>
yup..
<freemangordon>
I don't think this is the right place
<tmlind>
me neither
<tmlind>
testing with hdmi also shows the black squares flickering between the frames if you underclock sgx
<tmlind>
which means this has nothing to do with the refresh of the lcd
<freemangordon>
this is weston?
<tmlind>
yeah
<tmlind>
i also suspect you would see the same with xorg on hdmi when underclocked
<freemangordon>
did you try to change FlushBehaviour in powervr.ini?
<freemangordon>
tmlind: I doubt, pvr exa waits for blits to complete and then flushes the framebuffer
<Wizzup>
bencoh: maybe qemu binfmt was not set up
<Wizzup>
retrying
<tmlind>
freemangordon: should i try with 2 or what did you suggest earlier?
<freemangordon>
yes
<freemangordon>
2 is the value
<freemangordon>
but, you also need glFinish() at the appropriate place(s)
<tmlind>
ok will try tomorrow, what's the difference between 1 and 2? one number is greater than the other?
<Wizzup>
bencoh: hm same problem
<freemangordon>
2 makes glFlush() behave as expected
<tmlind>
ok
<freemangordon>
1 just sends to SGX to start rendering, without actually witing for render to complete
<freemangordon>
IIUC
<tmlind>
ah ok that sounds like it would explain the black squares
<tmlind>
i guess no need to reload the kernel module hopefully?
<freemangordon>
no, this is userspace thing
<tmlind>
you never know with these blobs
<freemangordon>
tmlind: you need to add that in [default] section, IIUC
<tmlind>
ok
<freemangordon>
ttyl
<tmlind>
later
<Wizzup>
heh lxc-create deletes the subvolume right away so I can't see the log
<tmlind>
freemangordon: changing it to 2 did not make any difference alone, will try again just in case
<tmlind>
ttyl
<Wizzup>
bencoh: ah my qemu isn't static
<bencoh>
Wizzup: right you need a static qemu
<bencoh>
my bad
<Wizzup>
I think it is static, so there is something else going on
<bencoh>
any erro?
<bencoh>
(still the same?)
<bencoh>
assuming your host is debian/devuan based, installing qemu-static should be enough as it will also pull binfmt and set it properly in the postinst script
<bencoh>
(iirc)
* sicelo
whispers systemd-nspawn :p
joerg has quit [Read error: Connection reset by peer]
<Wizzup>
bencoh: sorry, phone call
<Wizzup>
sicelo: how is this relevant?
<dsc_>
Wizzup: hello, is this the droid4 helpdesk? My droid4 seems "dead-ish" - wont turn on, no blinking green light
<dsc_>
10sec power button + volume down does nothing
<dsc_>
do I need an USB charger?
<dsc_>
(I connect it straigh to my pc with the usb cable :P)
joerg has joined #maemo-leste
<Wizzup>
dsc_: might the battery be dead?
<Wizzup>
or very low
<dsc_>
Wizzup: it has been connected directly to my PC for some time now
<dsc_>
getting the impressino it might not be charging ...
<dsc_>
do you use a dedicated USB charger?
<Wizzup>
in cases of low batteries, try wall/dedicated charger
<Wizzup>
bencoh: gentoo, but I'll go and figure it out
vectis_ has quit [Read error: Connection reset by peer]
vectis_ has joined #maemo-leste
vectis_ has quit [Ping timeout: 265 seconds]
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
<Wizzup>
bencoh: ok I need thiscp -v /usr/bin/qemu-arm /var/cache/lxc/devuan/partial-beowulf-armhf/usr/bin/
<bencoh>
Wizzup: tbh I'm still amazed it works here without qemu in the lxc rootfs
<bencoh>
back in the days (when I did it manually with chroots) I had to copy it there
<bencoh>
sorry I didn't mention it
<bencoh>
(it really works without it here on debian though)