uvos | looks like all gtk3 applications also segfault | 00:02 |
---|---|---|
freemangordon | this is something to do with mesa | 00:04 |
freemangordon | because I am sure those were working | 00:04 |
freemangordon | at least firefox-esr | 00:04 |
uvos | have the devuan equivalent to the buster-debug repo above handy? | 00:05 |
uvos | ff-esr is a different version in devuan than buster | 00:05 |
HuGoDrOcHa | alguem do brasil ? | 00:05 |
HuGoDrOcHa | ? | 00:05 |
uvos | well nvm | 00:06 |
freemangordon | 0xaf250706 in dri2CreateScreen (screen=<optimized out>, priv=<optimized out>) | 00:06 |
uvos | yeah it segfaults in glx | 00:06 |
freemangordon | hmm, can we tell it to use gles, not glx? | 00:07 |
uvos | sure maybe | 00:07 |
uvos | but it should not segfault | 00:07 |
freemangordon | yeah | 00:07 |
uvos | it should use sw rendering instead | 00:07 |
uvos | in ddk1.9 it did use gles | 00:07 |
freemangordon | well, maybe it is pvr_dri at fault | 00:07 |
uvos | not sure what changed here | 00:07 |
uvos | maybe something reports glx being avialable that dident before | 00:08 |
Wizzup | right that's quite possible | 00:08 |
uvos | sec ill start the server with -glx | 00:08 |
freemangordon | yeah, that helps | 00:09 |
uvos | yeah | 00:12 |
uvos | fullscreen is wonky tho | 00:12 |
uvos | but you know allready | 00:12 |
uvos | ok | 00:13 |
uvos | Section "Module" | 00:13 |
uvos | Disable "glx" | 00:13 |
uvos | EndSection | 00:13 |
uvos | ^^^ we can add that to xorg.conf for now | 00:13 |
uvos | we want to keep it really (to stop stuff from using glx) | 00:13 |
uvos | but ofc sefault is still a bug | 00:13 |
uvos | scrolling in ff is great ;) | 00:14 |
Wizzup | now I need to try it as well | 00:15 |
Wizzup | uvos: so you have just that as conf? | 00:15 |
uvos | yeah | 00:15 |
freemangordon | what? | 00:15 |
uvos | freemangordon: hmm? | 00:16 |
freemangordon | what conf for FF TS scroll? | 00:16 |
uvos | freemangordon: there is an evvar | 00:16 |
Wizzup | I think the config is more like don't make firefox segfault | 00:16 |
uvos | sec | 00:16 |
Wizzup | oh | 00:16 |
Wizzup | right | 00:17 |
freemangordon | ah | 00:17 |
Wizzup | nvm me | 00:17 |
Wizzup | I'll shut up ;) | 00:17 |
uvos | export MOZ_USE_XINPUT2=1 | 00:17 |
freemangordon | ok, fullscreen if fixed too, going to push | 00:17 |
uvos | also apz.allow_zooming | 00:20 |
uvos | (to make zooming smartphone style) | 00:20 |
freemangordon | ok | 00:20 |
uvos | + something else for smartphone style selection | 00:21 |
uvos | but cant find it right now in my about:config | 00:21 |
uvos | Wizzup: yeah no kidding about maep | 00:24 |
uvos | thats insane improvement | 00:24 |
uvos | freemangordon: really incredible work :) | 00:24 |
freemangordon | :) | 00:26 |
freemangordon | and it will get better with DRI2 doing double-buffering | 00:26 |
freemangordon | for some reason omap driver assumes this to be tripple-buffering | 00:27 |
freemangordon | but anyway | 00:27 |
freemangordon | it needs to be fixed | 00:27 |
uvos | freemangordon: there is also something up with suspending composing | 00:27 |
freemangordon | uvos: compositing is not accelerated still | 00:27 |
uvos | freemangordon: right | 00:27 |
freemangordon | also XV | 00:27 |
uvos | freemangordon: but i mean suspending it | 00:27 |
uvos | dosent work | 00:27 |
uvos | in hildon | 00:27 |
freemangordon | uvos: sec to push fixed version | 00:28 |
freemangordon | and then we'll search for bugs | 00:28 |
uvos | the display just stops updateing if you ctrl-shift-n toggle it | 00:28 |
freemangordon | yes, I know | 00:28 |
uvos | ok | 00:28 |
freemangordon | that's the fix I am about to push :) | 00:28 |
uvos | ok ok | 00:28 |
uvos | :) | 00:28 |
uvos | sicelo: btw now that randr rotation working on n900 is really imminant | 00:30 |
uvos | sicelo: it would be great if you fixed the compatbile or what the probing problem was with the new st accell driver + the n900 accell | 00:31 |
uvos | i dimmly remember this as just being a missing compatible | 00:31 |
Wizzup | freemangordon: building the src with fix | 00:37 |
freemangordon | installing ATM for a final test before asking you to rebuild DDX :) | 00:38 |
freemangordon | ah, well | 00:38 |
Wizzup | hehe well it's -experimental | 00:39 |
freemangordon | yeah | 00:39 |
freemangordon | but still | 00:39 |
freemangordon | yeah, that change fixed it | 00:42 |
Wizzup | I still see some weird corruption in surf I think, but it's not a lot | 01:16 |
Wizzup | seems to be in the same place and it 'follows' the surf page around | 01:16 |
Wizzup | so it's in the 2d content I'd say rather than display flickering, so that's not the same issue | 01:32 |
Wizzup | this may be incidental but ofono seems better with 5.15 | 02:19 |
freemangordon | Wizzup: yeah, there seems to be some corruption from time to time, but it is not flickering | 07:37 |
freemangordon | asctually there *is* some flickering when 2d scrolling, but I hope that will disappear when we enable tripple-buffering | 07:41 |
freemangordon | ok, we *cannot* use dri3, because of the rotation, not until there is a way to request TILER BOs when using GBM | 07:50 |
parazyd | Wizzup: I imported libllvm8 to experimental, will try the upgrade now. | 10:17 |
parazyd | Wizzup: Let me know about pvrsrvinit, as now you put pvrsrvctl in /usr/bin, and the initscript does not use that. | 10:18 |
Wizzup | freemangordon: yeah, it seems to be in the pixmaps themselves | 10:46 |
Wizzup | of surf in this case | 10:46 |
Wizzup | parazyd: does it not? | 10:46 |
uvos | btw with /etc/init.d/powervr being in default atm | 10:46 |
Wizzup | parazyd: | 10:47 |
Wizzup | ebegin "Starting PowerVR" | 10:47 |
Wizzup | /usr/bin/pvrsrvinit | 10:47 |
uvos | (i had to compile my own pvrsrvinit) | 10:47 |
uvos | as parazyd mentions | 10:47 |
parazyd | Wizzup: Yeah there's no such binary | 10:47 |
Wizzup | idgi? | 10:47 |
parazyd | What does your `dpkg -S pvrsrvinit` say? | 10:47 |
uvos | parazyd: its this https://github.com/IMbackK/pvr-omap4/blob/master/pvrsrvinit.c | 10:47 |
Wizzup | pvrsrvinit is not a package | 10:47 |
Wizzup | it's in sgx-ddk-um-tools | 10:47 |
parazyd | Wizzup: It's not | 10:47 |
uvos | Wizzup: your pacakge contains pvrsrvctrl | 10:47 |
uvos | not jit | 10:47 |
uvos | init | 10:47 |
uvos | we dont need ctrl at all | 10:47 |
Wizzup | well I was going to check but mce turned off the device for battery guard even though it was at 40-50% and charging | 10:48 |
parazyd | uvos: Thanks | 10:48 |
Wizzup | so you'll have o wait a bit longer | 10:48 |
uvos | hehe shade | 10:49 |
uvos | wierd | 10:49 |
Wizzup | uvos: pvrsrvctrl --start --no-module is not what we need you say? | 10:49 |
uvos | no | 10:49 |
Wizzup | this literally worked for me yesterday | 10:49 |
parazyd | uvos: That should just work with gcc, no extra libs? | 10:49 |
uvos | that works | 10:49 |
uvos | Wizzup: but its a big binary blob we just dont need | 10:49 |
uvos | parazyd: -ldl | 10:49 |
parazyd | uvos: ok | 10:49 |
Wizzup | ok but hang on | 10:50 |
Wizzup | 1. it works now with the stuff I packaged | 10:50 |
Wizzup | 2. you want an alternative | 10:50 |
Wizzup | that's fine | 10:50 |
uvos | no the init script calls pvrsrvinit | 10:50 |
uvos | that binary isent in ddk1.17 | 10:50 |
Wizzup | but /usr/bin/pvrsrvctl exists and the init scripts call the right pkg afaik | 10:50 |
uvos | it was in 1.9 | 10:50 |
Wizzup | I purged everything 1.9 related and mine boots to accelerated h-d | 10:50 |
uvos | as it stands right now the package provides pvrsrvctrl but the init script tries to call pvrsrvinit | 10:51 |
uvos | i thats how it is on my d4 atm | 10:51 |
Wizzup | then why does it work for me | 10:51 |
Wizzup | weird | 10:51 |
Wizzup | maybe it's fmg's init code | 10:51 |
uvos | parazyd: also make sure its in sysinit | 10:51 |
Wizzup | uvos: yeah my droid says 53% charging, I really can't understand why it did reboot | 10:51 |
parazyd | uvos: mhm | 10:51 |
Wizzup | parazyd: should I not fix the package then? | 10:52 |
parazyd | I'm on it | 10:52 |
uvos | Wizzup: so there is the problem that the adc output is quite noisy | 10:52 |
Wizzup | all we needed to change was 3 chars it seems like :P | 10:52 |
uvos | Wizzup: upower might signal that the voltage is to low to early | 10:53 |
uvos | but i have never seen it | 10:53 |
Wizzup | parazyd: are you adding another binary? | 10:53 |
uvos | really hard to debug to if thats the reason :\ | 10:53 |
parazyd | Wizzup: We don't need pvrsrvctl | 10:53 |
parazyd | Instead we replace it with https://github.com/IMbackK/pvr-omap4/blob/master/pvrsrvinit.c | 10:53 |
Wizzup | uvos: wtf: Nov 23 10:47:48 localhost mce[3354]: Requesting shutdown from powerkey.c: generic_powerkey_handler(); action: 2 | 10:54 |
Wizzup | I'm really quite sure I didn't do that lol | 10:54 |
uvos | hmm | 10:54 |
Wizzup | parazyd: well this works, but if you want to try something else, ok | 10:54 |
Wizzup | it's already packaged and we'd just have to change the three chars | 10:54 |
Wizzup | but yeah ok, we'd have to compile it though | 10:54 |
Wizzup | I'm fine either way | 10:54 |
uvos | Wizzup: could be a hw glitch even (some moisture) | 10:55 |
Wizzup | parazyd: so the alternative is to reply 'init' with 'ctl' in the init script | 10:55 |
Wizzup | ss/reply/replace/ | 10:56 |
parazyd | The point is to replace a binary blob with 20 lines of C | 10:56 |
Wizzup | what about the other ~3-4MB of blob :P | 10:56 |
Wizzup | but ok, whatever | 10:56 |
parazyd | Nothing | 10:56 |
parazyd | We liberate what we can | 10:56 |
Wizzup | the same code is also in the DDX fwiw | 10:57 |
uvos | yeah but that dosent work | 10:57 |
uvos | its to late | 10:57 |
Wizzup | so why does my droid4 init | 11:05 |
Wizzup | lol | 11:05 |
Wizzup | I don't get it | 11:05 |
Wizzup | I don't have /usr/bin/pvrsrvinit | 11:05 |
Wizzup | maybe the X code does work for me? | 11:06 |
uvos | Wizzup: so the code in the ddx "works" but its not sufficant because 1. there is a race with h-d, h-d might sometimes end up on llvmpipe 2. it dosent do anything for other drm applications we might want before x starts, like a bootlogo or charge-mode | 11:07 |
Wizzup | ok, so I haven't seen the race yet | 11:07 |
Wizzup | oh yeah there was the chargemode thing | 11:07 |
uvos | particularly we need pvr to be init'ed before charging-sdl if we want charging-sdl to work on acellerated drm and not directfb | 11:07 |
Wizzup | it doesn't use acceleration atm though right? | 11:08 |
uvos | its on directfb so n | 11:08 |
uvos | but it works fine on ddk1.17 drm i tested it before there | 11:08 |
uvos | so its just a matter of flipping it over | 11:08 |
uvos | then its accellerated and can turn of the display | 11:08 |
uvos | so we def want that | 11:08 |
Wizzup | ok | 11:09 |
Wizzup | so the next thing is either n900 with uImage from 5.15 or u-boot mainline | 11:10 |
Wizzup | https://maedevu.maemo.org/images/n900/tools/ u-boot-2020.12-pali.bin this one is mainline u-boot afaik | 11:12 |
Wizzup | as in IIRC it should just work | 11:12 |
Wizzup | Pali: iirc all your n900 work is in v2021.10 - right? | 11:17 |
Wizzup | probably not in u-boot v2021.07 | 11:17 |
Pali | yes, they should work | 11:17 |
Wizzup | both? ok | 11:17 |
Pali | yes | 11:17 |
parazyd | Wizzup: We should package it like this: https://github.com/maemo-leste/pine64-uboot | 11:22 |
freemangordon | uvos: I don't see a way h-d to start without X :) | 11:40 |
Wizzup | parazyd: there are various places where it can be flashed, with attached kernel and stuff, so it's not easy | 11:40 |
Wizzup | parazyd: I'm just going to make mine work for now | 11:40 |
freemangordon | but I agree that it is racy on startup because could have no pvr modules loaded | 11:41 |
Wizzup | parazyd: I'm going to test 2021.10 now | 11:43 |
parazyd | Sure | 11:43 |
parazyd | I still don't have a clean upgrade path | 11:43 |
Wizzup | :) | 11:43 |
Wizzup | please keep at it :D | 11:43 |
Wizzup | also try to have cloudgps or other extras installed | 11:43 |
Wizzup | I had to force remove cloudgps since it depended on some libgles sgx thing | 11:44 |
parazyd | xserver-xorg-video-omap doesn't want to upgrade | 11:44 |
Wizzup | (maybe we just rebuild it) | 11:44 |
parazyd | There's still some of these somewhere: https://github.com/maemo-leste/pvr-omap4/blob/master/debian/control | 11:44 |
parazyd | But I can't find where | 11:45 |
Wizzup | ok 2021.10 boots for me and it boots leste as well | 11:46 |
uvos | i mean it might make some sense to stop recomending people attach kernels, surely we can just have people move whatever fremantle kernel they want to use somewhere else? | 11:49 |
uvos | the other option is to have the install script for uboot dd the partition to an image, extact the kernel if any and reattach it | 11:49 |
Wizzup | we might need attached dtb on n900? | 12:08 |
Wizzup | I guess I should check | 12:11 |
uvos | good question, yeah we do rn | 12:11 |
parazyd | user@devuan-droid4:~$ glxgears | 12:12 |
parazyd | LoadLib: Couldn't load libpvr_dri_support.so: libpvr_dri_support.so: cannot open shared object file: No such file or directory | 12:12 |
parazyd | Wizzup: ^ | 12:12 |
parazyd | Seen this? | 12:12 |
uvos | parazyd: GLXgears? | 12:13 |
Wizzup | parazyd: why are you trying glx? | 12:13 |
Wizzup | glx is not supported and also it's not gles | 12:13 |
Wizzup | es2gears_x11 is what you want I think | 12:13 |
parazyd | ah sry, I wanted to try es2gears indeed | 12:13 |
uvos | it should work on llvmpipe in theroy | 12:13 |
Wizzup | but, h-d is a much better test | 12:13 |
Wizzup | uvos: yes but we don't want that :) | 12:14 |
uvos | but its broken atm (we allready know) | 12:14 |
parazyd | but the same | 12:14 |
parazyd | user@devuan-droid4:~$ es2gears_x11 | 12:14 |
parazyd | LoadLib: Couldn't load libpvr_dri_support.so: libpvr_dri_support.so: cannot open shared object file: No such file or directory | 12:14 |
parazyd | libEGL warning: DRI2: failed to create dri screen | 12:14 |
Wizzup | so did you reboot to hildon-desktop and new ddx? | 12:14 |
parazyd | h-d is slow, so I'd say swrast | 12:14 |
Wizzup | what is the state of your system atm | 12:14 |
parazyd | Wizzup: Obviously | 12:14 |
parazyd | I have slow h-d running | 12:14 |
Wizzup | wasn't clear to me | 12:14 |
Wizzup | ok, first thing to check is /tmp/Xorg.0.log | 12:14 |
Wizzup | search for any errors | 12:14 |
uvos | also check you have the envvar | 12:14 |
Wizzup | it's in the package | 12:15 |
uvos | ok | 12:15 |
Wizzup | I added it last night, it should be there | 12:15 |
Wizzup | but we'll find out soon enough from Xorg.0.log | 12:15 |
parazyd | http://sprunge.us/oYJaL7 | 12:15 |
parazyd | I have the envvar | 12:15 |
uvos | looks fine | 12:15 |
parazyd | user@devuan-droid4:/tmp$ env | grep pvr | 12:15 |
parazyd | MESA_LOADER_DRIVER_OVERRIDE=pvr | 12:15 |
uvos | so libpvr_dri_support.so exists right? | 12:15 |
uvos | /usr/lib/arm-linux-gnueabihf/libpvr_dri_support.so.1.17.4948957 | 12:16 |
uvos | + link | 12:16 |
parazyd | so.1 and so.1.17.4948957 exist | 12:16 |
parazyd | But no .so itself | 12:16 |
Wizzup | install -dev maybe | 12:17 |
Wizzup | maybe that's it | 12:18 |
Wizzup | sgx-ddk-um-dev | 12:18 |
Wizzup | # dpkg -S /usr/lib/arm-linux-gnueabihf/libpvr_dri_support.so | 12:18 |
Wizzup | sgx-ddk-um-ti443x: /usr/lib/arm-linux-gnueabihf/libpvr_dri_support.so | 12:18 |
Wizzup | hmm | 12:18 |
Wizzup | did you change anything? let me apt upgrade | 12:18 |
parazyd | Nothing related to the libs | 12:19 |
parazyd | We just don't have those links | 12:19 |
Wizzup | yeah it's gone | 12:19 |
Wizzup | I just upgraded and it's gone | 12:19 |
Wizzup | so you did somethin that broke it | 12:20 |
Wizzup | # dpkg -S /usr/lib/arm-linux-gnueabihf/libpvr_dri_support.so | 12:20 |
Wizzup | dpkg-query: no path found matching pattern /usr/lib/arm-linux-gnueabihf/libpvr_dri_support.so | 12:20 |
parazyd | ok, that's probably an apt thing then | 12:20 |
Wizzup | huh? | 12:20 |
Wizzup | is "pvrsrvinit: Use version for symbol loading. | 12:21 |
Wizzup | " also related to this? | 12:21 |
parazyd | no | 12:21 |
parazyd | Well, yes | 12:21 |
parazyd | Because the .so weren't installed | 12:21 |
Wizzup | I am pretty sure they are on my device | 12:21 |
parazyd | Just give me a minute | 12:21 |
Wizzup | maybe you adding a Makefile broke it | 12:21 |
Wizzup | sure, just being helpful here :p | 12:22 |
Wizzup | as in they were there in ec28dc199f5666885c5756704dc67a6874c917ab | 12:22 |
uvos | Wizzup is in slightly beligerent mood :P | 12:23 |
Wizzup | nah it's fine to liberate more stuff I'm just pointing out it used to work | 12:24 |
Wizzup | I don't see what caused the problem either from the git history, so it's some weird debian build thing I'm sure | 12:25 |
Wizzup | probably dh install does something else now | 12:25 |
Wizzup | meanwhile I almost have a droid4 kernel pkg with n900 dtb and stuff in it | 12:25 |
Wizzup | will try that out in a bit, hope I can pass the dtb using u-boot this time | 12:26 |
Wizzup | Pali: do you boot with appended dtb still with zimage, or do you pass it separately for n900? | 12:28 |
Pali | I have tested only 2.6.28 kernel which do not use DTB | 12:28 |
Wizzup | hm, ok, ideally for leste we would use a separate dtb, not attached | 12:29 |
Pali | U-Boot should support both options without issues | 12:29 |
Wizzup | ok | 12:29 |
Wizzup | usually I think u-boot needs an addr to load those at, I'll try to figure it out | 12:30 |
Pali | on other ARM boards I'm using U-Boot with separate DTB and it is working fine | 12:30 |
Pali | yes, you need to specify address where is DTB loaded in memory when calling U-Boot bootz command | 12:30 |
Pali | also now U-Boot for n900 supports bootz command, so there is no need to generate uImage from zImage | 12:31 |
Pali | and booting 2.6.28 kernel (stock zImage) with bootz command in n900 qemu is part of u-boot automated tests | 12:32 |
Wizzup | great | 12:32 |
Pali | ... so this ensures that upstream u-boot does not break this booting | 12:32 |
Wizzup | do you know what addresses are sane? | 12:32 |
Pali | IIRC there is kernel documentation for it | 12:33 |
Pali | I will try to find it | 12:33 |
Wizzup | appreciate it, thanks | 12:33 |
Pali | https://www.kernel.org/doc/html/latest/arm/booting.html | 12:34 |
Pali | Setup the device tree --> A safe location is just above the 128MiB boundary from start of RAM. | 12:34 |
Pali | Calling the kernel image --> The zImage may also be placed in system RAM and called there. The kernel should be placed in the first 128MiB of RAM. | 12:35 |
Wizzup | ok | 12:36 |
Pali | Load initramfs --> A safe location is just above the device tree blob which itself will be loaded just above the 128MiB boundary from the start of RAM as recommended above. | 12:36 |
Pali | Anyway, there is standard U-Boot variable ${fdt_addr_r} which should specify address where DTB should be loaded | 12:37 |
Pali | I think that n900 does not set this variable in include/configs/nokia_rx51.h (during compile time) | 12:38 |
Pali | So it would be a nice to define this variable and send patch | 12:38 |
Pali | And ${fdtfile} variable should contain name of (default) DTB file | 12:39 |
Pali | Similarly ${kernel_addr_r} is address for zImage | 12:40 |
Wizzup | ok, I'll try to figure it out and see if I can send a patch | 12:40 |
Pali | n900 uses custom variables ($kernaddr, $initrdaddr, $scriptaddr), so aliases for standard variables could be useful | 12:41 |
Wizzup | oh, so the addrs are already there :) | 12:42 |
parazyd | Wizzup: Ok, when we convert it from native to quilt, it works. | 13:00 |
Wizzup | lmao what | 13:00 |
parazyd | https://github.com/maemo-leste/sgx-ddk-um/commit/dc4ff73d0e4f83a66af6f4716672be0f31fc8baa | 13:00 |
parazyd | gbp on a native package cleans "foo.so" files | 13:00 |
Wizzup | jfc | 13:00 |
parazyd | On a quilt package it doesn't. | 13:00 |
Wizzup | why does it not do that for the ones I did? | 13:00 |
parazyd | I don't even wanna understand it. | 13:00 |
uvos | freemangordon: so x hangs in ospoll_wait until OMAPDRI2SwapComplete | 13:00 |
Wizzup | because the ones I made worked | 13:00 |
uvos | freemangordon: not sure why yet | 13:00 |
parazyd | Wizzup: Probably because there was no Makefile. | 13:00 |
uvos | but that seams wrong | 13:01 |
parazyd | Wizzup: It also works only with `dpkg-buildpackage`. It's just gbp that's broken | 13:01 |
Wizzup | blergh | 13:01 |
Wizzup | parazyd: what packages do you install to try to uprade to the new stuff? | 13:01 |
uvos | lol debian packaging | 13:01 |
Wizzup | I want to try on my n900 | 13:01 |
parazyd | Wizzup: N900 is not ready yet. | 13:02 |
parazyd | But you could try on a bionic or something | 13:02 |
parazyd | Wizzup: This is the least steps I could do to perform the upgrade: http://sprunge.us/tASSBg | 13:02 |
freemangordon | uvos: hmm, this sounds ok to me | 13:04 |
Wizzup | parazyd: what do you mean 'n900 is not ready yet' ? | 13:05 |
Wizzup | do you mean dep wise? | 13:05 |
freemangordon | it should do nothing until page flip occurs | 13:05 |
parazyd | Wizzup: hildon-meta mostly | 13:05 |
freemangordon | the problem to me is that client does nothing as well int the meantime, instead of rendering | 13:05 |
Wizzup | well, I can ignore that for now as we need someone to test kernel and packages on n900 | 13:05 |
uvos | freemangordon: right because x i hanging i suspect | 13:05 |
Wizzup | and I don't have a bionic with me | 13:05 |
uvos | ie client waits on some x call | 13:06 |
freemangordon | ah | 13:06 |
freemangordon | yeah, right | 13:06 |
freemangordon | mikes sense | 13:06 |
freemangordon | *makes | 13:06 |
parazyd | Wizzup: So just try to install the t343x libs and upgrade the ddk | 13:06 |
uvos | im not _sure_ this is whats happening but it looks suspicous | 13:06 |
Wizzup | k | 13:06 |
parazyd | That's enough, along with upgrading mesa | 13:06 |
uvos | ill try on bionic sec | 13:09 |
parazyd | Hold on for 5 more minutes so the latest libs are in the repo | 13:11 |
parazyd | uvos: http://sprunge.us/8hERem | 13:13 |
parazyd | After adding experimental, this worked | 13:13 |
parazyd | uvos: Also I recommend having latest devel updated to avoid other package noise | 13:13 |
uvos | parazyd: ok will do | 13:13 |
uvos | but have to charge the thing first | 13:14 |
parazyd | :) | 13:14 |
Wizzup | can hildon-meta depend on libegl1? | 13:21 |
Wizzup | then maybe apt dist-upgrade could work? | 13:21 |
parazyd | Perhaps the ddk should? | 13:29 |
parazyd | https://github.com/maemo-leste/hildon-meta/blob/maemo/beowulf-experimental/debian/control#L139 | 13:30 |
Wizzup | I think mesa provides it | 13:30 |
Wizzup | the ddk does not provide this anymore afaik? | 13:30 |
uvos | yes | 13:31 |
uvos | its mesa | 13:31 |
uvos | nothing should depend on any of the ddk libs at all anymore | 13:32 |
Wizzup | then they will not get pulled in ;) | 13:32 |
uvos | except mesa itself and stuff that wants to use pvr2d | 13:32 |
Wizzup | but yeah | 13:32 |
uvos | the device meta pacakge should pull it | 13:32 |
Wizzup | it's more about making the upgrade smooth/working | 13:32 |
Wizzup | right | 13:32 |
uvos | nothing else should | 13:32 |
uvos | except video-omap (our only pvr2d user) | 13:32 |
parazyd | Yeah so I'm saying | 13:34 |
parazyd | Since hildon-meta-droid4 has xserver-xorg-video-omap | 13:34 |
parazyd | Should xserver-xorg-video-omap then have the sgx-ddk-um deps? | 13:34 |
uvos | i gues | 13:34 |
uvos | long term it would be better if we split hildon-device specific stuff and just device specific stuff | 13:35 |
parazyd | ok, I'm not sure where to put libegl1 then | 13:35 |
parazyd | Perhaps hildon-meta-$device indeed | 13:35 |
uvos | so hildon-desktop itself needs libegl | 13:36 |
uvos | so dose any other gles user | 13:36 |
uvos | they should pull mesas libegl | 13:36 |
freemangordon | wait, clutter chould already depend on that | 13:36 |
parazyd | It doesn't have a libegl1 dep | 13:36 |
uvos | then idealy mesa should pull sgx-ddk-um (but only on omap) | 13:36 |
parazyd | Only libgles2-mesa | 13:36 |
freemangordon | and that pulls the other stuff, no? | 13:37 |
uvos | thats wierd pacakging on debains part | 13:37 |
uvos | tho | 13:37 |
uvos | since you cant use libgles without egl | 13:37 |
parazyd | So maybe we should be more explicit with clutter deps? | 13:37 |
freemangordon | if it doesn't, then debian packaging is broken | 13:37 |
freemangordon | *mesa debian packaging | 13:37 |
uvos | parazyd: sure having clutter depend is a workaround | 13:38 |
uvos | but really this is upstreams fault if its as descibed above | 13:38 |
uvos | how dose it work on pp rn? | 13:39 |
parazyd | ah wait | 13:39 |
uvos | somhow egl must be installed there | 13:39 |
parazyd | I think if we rebuild clutter | 13:39 |
parazyd | We might be in luck | 13:39 |
parazyd | But we'd have to build it in experimental to test | 13:39 |
parazyd | I'll try that | 13:40 |
Wizzup | 13:34 < parazyd> Should xserver-xorg-video-omap then have the sgx-ddk-um deps? | 13:49 |
Wizzup | doesn't it have that already? | 13:49 |
Wizzup | it depends on -dev for build and it should depend on -libs at runtime | 13:49 |
Wizzup | if that's not the case it needs to be fixed | 13:49 |
Wizzup | uvos: why should ddx not pull sgx-ddk-um? it needs the libraries | 13:50 |
uvos | ? | 13:51 |
uvos | it should | 13:51 |
freemangordon | EXA needsw libs | 13:51 |
uvos | [13:32] <uvos> nothing should depend on any of the ddk libs at all anymore | 13:51 |
uvos | [13:32] <uvos> except video-omap (our only pvr2d user) | 13:51 |
freemangordon | :) | 13:51 |
Wizzup | agreed, ok | 13:51 |
parazyd | The issue is it can't pull them in directly | 13:51 |
parazyd | Since we have omap3 and omap4 | 13:51 |
parazyd | So we need to resolve that someplace else (hildon-meta) | 13:52 |
uvos | why | 13:52 |
uvos | the package is in n900 and in droid4 section | 13:52 |
uvos | it will pull what its on | 13:52 |
parazyd | Wizzup made it use a virtual | 13:53 |
uvos | ok | 13:53 |
parazyd | https://github.com/maemo-leste/sgx-ddk-um/blob/maemo/beowulf-experimental/debian/control#L14 | 13:53 |
Wizzup | right, yes, the pkg specific -meta should pick the exact version it wants | 13:53 |
Wizzup | where version = omap version | 13:53 |
parazyd | https://github.com/maemo-leste/xf86-video-omap/blob/maemo/beowulf-experimental/debian/control#L28 | 13:53 |
uvos | im not sure why you want to do it like tis | 13:53 |
uvos | instead of using the sections | 13:53 |
uvos | but if you do then sure | 13:53 |
uvos | meta then needs to pull it | 13:53 |
Wizzup | well we would have to introduce new sections | 13:53 |
Wizzup | and that is not an easy upgrade path | 13:54 |
uvos | Wizzup: why? | 13:54 |
Wizzup | unless you want to use n900 for omap3 and droid4 for omap4 | 13:54 |
Wizzup | uvos: because people would have to change sources.list | 13:54 |
uvos | no not that | 13:54 |
uvos | ok sure we might have some problem in the future if we add a non-mapphone non-n900 omap device | 13:55 |
uvos | really the current sections arnt so great anyways maybe we sould break at some point | 13:55 |
uvos | needs to be well thought out tho | 13:55 |
parazyd | I agree we could work on this a bit | 13:55 |
uvos | i mean bionic is droid4 bionic | 13:55 |
uvos | realy there sould be omap4 mapphone bionic or something like that | 13:56 |
Wizzup | uvos: like xt610 :) | 13:56 |
uvos | heh | 13:56 |
uvos | yeah | 13:56 |
Wizzup | so I went for the virtual like that because we had no easy other path, but yes we need to work on the components | 13:57 |
uvos | yeah sure makes sense | 13:57 |
uvos | just makes the packaging a bit ugly rn | 13:57 |
uvos | as you have discoverd :) | 13:57 |
Wizzup | I thought the -meta-$device could just pull the right libs | 13:57 |
Wizzup | does that not work? | 13:57 |
uvos | it dose | 13:58 |
uvos | but some package needing some other package but not directly depending on it is a bit ugly | 13:58 |
Wizzup | yeah | 13:58 |
uvos | you might want to install hildon without going for the full meta | 13:58 |
Wizzup | well that will break a lot more currently | 13:58 |
parazyd | We can have a big break, but then we need to clean up everything at once. | 13:59 |
parazyd | tbh it sounds better than patching solutions | 14:00 |
parazyd | (And really it's not a break, just changing sources.list and dist upgrade) | 14:00 |
uvos | yeah proubly fine if a short blogpost acompanies it to tell people what they need to do | 14:01 |
parazyd | Exactly | 14:01 |
Wizzup | why not do it with the buster+1 | 14:02 |
parazyd | That'd work | 14:04 |
parazyd | That's the time when we rebuild everything anyway :D | 14:04 |
Wizzup | I prefer that since it's obvious they should probably read the news update or flash a new image, which is better than folks not knowing what's up and upgrading and things breaking | 14:04 |
parazyd | For this, I'd like that we design some doc/spec on what the repo layouts should look like next | 14:05 |
parazyd | And do some prior investigation to know if it will work (and scale) | 14:05 |
Wizzup | yes we can make an issue for it | 14:05 |
Wizzup | with chimaere milestone | 14:05 |
Wizzup | (sp) | 14:05 |
Wizzup | lol | 14:05 |
Wizzup | ok, will try n900 momentarily | 14:05 |
Wizzup | freemangordon: you said portrait doesn't work yet right? | 14:06 |
sicelo | he said so, yes | 14:10 |
Wizzup | sicelo: thanks for refreshing my memory :p | 14:14 |
parazyd | Sorry I dunno how to get a clean upgrade | 14:29 |
Wizzup | what is the problem that you run into that doesn't work with dist-upgrade | 14:30 |
parazyd | Things don't want to upgrade unless I manually install libegl1 | 14:30 |
parazyd | And even that implies that hildon-meta is removed | 14:31 |
Wizzup | what is the verbose tree / error? | 14:31 |
parazyd | bbl I have to work on other things | 14:31 |
parazyd | Wizzup: I advise to try it with a new image | 14:31 |
parazyd | I outlined the steps to you and uvos earlier | 14:32 |
parazyd | (See the sprunge) | 14:32 |
Wizzup | yes, I wanted to offer help not pick up the task ;) | 14:32 |
parazyd | I don't know how to solve it | 14:32 |
parazyd | So somebody does have to pick it up | 14:32 |
crab | hi again, what is the current kernel version i should be running on n900 assuming im up to date? | 14:36 |
crab | is it > 5.1.21 ? | 14:37 |
Wizzup | no, it is 5.1.21 until we finish the 5.15 upgrade path | 14:38 |
Wizzup | I am going to try to do that today on my n900 | 14:38 |
crab | aah cool. | 14:38 |
crab | thanks | 14:38 |
crab | i was just wondering if the reason my gui doesnt work is maybe because im installed on an sd card | 14:39 |
crab | and kernel wasnt getting updated somehow, but it seems like it is in that case. :) | 14:39 |
Wizzup | your gui (still) doesn't work? | 14:40 |
Wizzup | apt-get -s -o Debug::pkgProblemResolver=yes upgrade | 14:44 |
Wizzup | this seems very helpful | 14:44 |
crab | aah thanks | 14:51 |
crab | also ill have to remember to sort out my uboot settings when that new kernel does get upgraded | 14:51 |
crab | Dependencies are not satisfied for hildon-connectivity-wlan:armhf < 1.4+2m7 -> 1.5+2m7 @ii umU Ib > | 14:53 |
crab | hmm. | 14:53 |
Wizzup | any context other than that line? | 14:57 |
crab | Keeping package hildon-connectivity-wlan:armhf | 14:58 |
crab | Calculating upgrade... Done | 14:58 |
crab | The following packages have been kept back: | 14:58 |
crab | hildon-connectivity-wlan | 14:58 |
Wizzup | does 'dist-upgrade' help? | 14:59 |
Wizzup | apt dist-upgrade | 14:59 |
crab | nah | 14:59 |
crab | that says shes all good :) | 15:00 |
crab | shall i try dist upgrade with apt-get and the debug ProblemResolver? | 15:00 |
Wizzup | huh, that's wierd, upgrade complains and dist-upgrade says there is nothing to do? | 15:01 |
crab | heh | 15:01 |
crab | same outcome | 15:01 |
crab | yeah looks like it | 15:01 |
crab | anyway dont let me distract you from more important work | 15:02 |
Wizzup | anyway, your UI is broken? | 15:02 |
crab | maybe it'll all come out in the wash when the next raft of updates are released, | 15:02 |
crab | and if not ill just do a fresh install | 15:02 |
crab | yeah | 15:02 |
crab | the text part of the boot process is fine | 15:02 |
crab | then it all goes black screen on me | 15:02 |
crab | but fortunately i can ssh in | 15:02 |
Wizzup | does /var/log/Xorg.0.log say anything useufl | 15:03 |
Wizzup | err | 15:03 |
Wizzup | not that | 15:03 |
Wizzup | /tmp/Xorg.0.log | 15:03 |
crab | there are a few errors about missing font paths | 15:04 |
crab | but it looks reasonably ok | 15:04 |
crab | i seem to remember something about "ofono" | 15:04 |
Wizzup | wait, you have -devel enabled? | 15:05 |
crab | some errors during the boot process about that | 15:05 |
crab | aah yeah i prob. do :) | 15:05 |
crab | how can i check? | 15:05 |
crab | is that a sources.list thing? | 15:06 |
crab | i cant see it there | 15:06 |
Wizzup | I wonder how ofono got installed | 15:06 |
crab | im not convinced it is | 15:07 |
crab | hmmm | 15:08 |
crab | some bits of it appear to be though | 15:08 |
crab | specifically libgofono and ofono-scripts | 15:09 |
Wizzup | we *really* need a good page on how to provide info about failures | 15:09 |
Wizzup | I don't know what to suggest atm | 15:09 |
crab | dont worry :) | 15:10 |
crab | thanks for help | 15:10 |
crab | and good luck with the real work. | 15:10 |
uvos | Wizzup: crab: i mean provide tail -n 2000 /var/log/daemon.log is a good start | 15:15 |
uvos | would be cool to have icd2 working in the emergency runlevel for this | 15:16 |
crab | ok ill pastebin that up if its really eating you, but i will give the rest of the channel a chance to stop me so we can save you from yourself | 15:16 |
crab | oh sorry, i didnt pay attention to who was typing... | 15:16 |
crab | :P | 15:16 |
uvos | contrary to popular belief this chat is not simply Wizzups different personalitys chating with eatch other | 15:17 |
crab | watch it! im in here under two irc clients as discussed! ;) | 15:17 |
crab | daemon.log is empty. :| | 15:17 |
uvos | really | 15:17 |
uvos | thats strange | 15:17 |
crab | possibly because i forwarded to my syslog server :P | 15:18 |
Wizzup | uvos: yes but I think we should split up daemon.log, I have syslog rules to do it per daemon | 15:18 |
Wizzup | but yeah only on my d4 atm | 15:18 |
crab | neither of you worry about it. | 15:19 |
uvos | Wizzup: sure thats fine | 15:19 |
crab | i got a weird feeling it'll sort itself a few apt's down the line | 15:19 |
crab | and if it doesnt its probably time to clean the machine up anyway | 15:19 |
crab | its got maemo, a strange gui-less debian install, | 15:19 |
crab | maemo leste | 15:19 |
crab | and possibly some other guff on here | 15:20 |
uvos | Wizzup: but thats not as conviniant if some user who knows little about linux just saies: black screen, dosent work or? | 15:20 |
crab | and none of them satisfy me like maemo-leste *even without the gui* ;) | 15:20 |
uvos | i mean leste with no gui is just devuan no :P | 15:20 |
uvos | but yeah | 15:20 |
crab | :) | 15:20 |
crab | it has a more up to date kernel than the debian thing on here | 15:21 |
crab | and more up to date userland | 15:21 |
crab | so its all good | 15:21 |
Wizzup | uvos: right, we also need a set of instructions | 15:21 |
crab | also currently ranked 42 on multirpg | 15:22 |
crab | :) | 15:22 |
Wizzup | uvos: parazyd: hm looks like the ddx somehow pulls in ti434x | 15:23 |
Wizzup | I have ti343x installed nad it wants to remove it | 15:23 |
Wizzup | that sucks... | 15:23 |
Wizzup | is that because it resolves it to ti434x at build time or something | 15:24 |
sicelo | sounds like some package has wrong dep(s) then :-) | 15:34 |
uvos | rr:7 https://pkgmaster.devuan.org/merged beowulf Release | 15:34 |
uvos | Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 152.228.204.144 443] | 15:34 |
uvos | whats wrong here | 15:34 |
uvos | the oldstable change? | 15:34 |
uvos | (upgrading a old bionic to latest devel) | 15:34 |
uvos | ah was my fault | 15:37 |
Wizzup | time? | 15:42 |
uvos | yes | 15:43 |
uvos | i saw 2021 in date and thoght that ment ntp worked | 15:43 |
uvos | but i forgot fake-hwclock exists | 15:43 |
freemangordon | Wizzup: hmm, I think I know what happens | 15:52 |
freemangordon | it was build against ti434x I guess | 15:52 |
freemangordon | so, I think ddx should have dependency to ti434x removed during build and a manual dependency to ddk-sgx-um virtual package | 15:54 |
freemangordon | or ddk-sgx-um-libs or whatever the package is called | 15:54 |
Wizzup | how would do we that in the ci | 16:00 |
Wizzup | freemangordon: btw, how do you boot your 5.15 n900 kernel image? | 16:00 |
Wizzup | any specific boot args? | 16:00 |
Wizzup | I have the serial here but no lab power supply, so I can't check serial for another two weeks :D | 16:01 |
bencoh | nah, who needs a lab psu anyway ... just rip open a usb cable and add a voltage divider with two resistors :* | 16:04 |
bencoh | (mostly kidding ... but it would probably work) | 16:04 |
Wizzup | maybe the kernel I built just doesn't work for the n900 | 16:07 |
uvos | parazyd style upgrade works fine on bionic | 16:11 |
uvos | and the new ddk setup works fine on bionic in general | 16:11 |
Wizzup | great | 16:14 |
Wizzup | weird that if hildon-meta-droid4 depends on libegl1 (with specific ersion) it still does not get installed | 16:15 |
freemangordon | Wizzup: I used uImage | 16:21 |
freemangordon | Wizzup: why CI? debian packaging should be fixed to exclude ti434x frompackage dependencies | 16:21 |
freemangordon | and in debian/control a manual dependency to virtual package shall be added | 16:22 |
freemangordon | or just shlibs:Depends can be removed, but that's too drastic IMO | 16:22 |
freemangordon | lemme see if I can fix the packaging | 16:23 |
Wizzup | freemangordon: isn't that what I did? | 16:23 |
Wizzup | freemangordon: ok thanks | 16:23 |
freemangordon | no idea, sorry, did you do something I missed? | 16:23 |
Wizzup | freemangordon: ok, I can't get the zImage to boot on the n900 | 16:23 |
Wizzup | freemangordon: no, please just take a look | 16:23 |
freemangordon | try uImage | 16:23 |
Wizzup | yeah the ci doesn't build a uimage | 16:23 |
Wizzup | but I'll make one | 16:23 |
freemangordon | yeah | 16:23 |
freemangordon | do you want me to provide mkimage command | 16:24 |
freemangordon | I mean - the paramters | 16:24 |
Wizzup | I think it is this mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -d zImage uImage | 16:24 |
Wizzup | but that's just what's in my history :) | 16:24 |
Wizzup | let me check n9xx-linux | 16:24 |
freemangordon | mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage -d zImage uImage | 16:24 |
freemangordon | -n can be different/missing ofc | 16:25 |
Wizzup | yeah | 16:25 |
freemangordon | Wizzup: what is the virtual package name? | 16:31 |
freemangordon | found it sgx-ddk-um-libs | 16:33 |
Wizzup | freemangordon: right | 16:33 |
Wizzup | and they both 'provide' it | 16:33 |
freemangordon | ah, it is already a dependency | 16:34 |
* freemangordon did some mogic, lets see if it is going to work | 16:34 | |
Wizzup | cool | 16:35 |
freemangordon | *magic* even :) | 16:35 |
Wizzup | brb, I'll try the uImage when I get back | 16:35 |
freemangordon | Depends: libc6 (>= 2.4), libdrm-omap1 (>= 2.4.33), libdrm2 (>= 2.4.36), xorg-video-abi-24, xserver-xorg-core (>= 2:1.18.99.901), sgx-ddk-um-libs | 16:47 |
freemangordon | :) | 16:47 |
freemangordon | Wizzup: https://github.com/maemo-leste/xf86-video-omap/commit/6a1eb3bf227ff69326895d11fdcf44ccb6dbca7c | 16:49 |
freemangordon | please rebuild when you have time | 16:49 |
Wizzup | running | 17:00 |
freemangordon | Wizzup: is it fixed now? | 17:13 |
Wizzup | let me see | 17:14 |
Wizzup | oh right | 17:14 |
Wizzup | I need to fix the uImage | 17:14 |
Wizzup | (since it's powered off atm) | 17:15 |
mighty17[m] | freemangordon:do you mind me packaging your mesa in pmOS? | 17:20 |
Wizzup | freemangordon: hm seems to just reset after a bit (kernel) | 17:20 |
freemangordon | mighty17[m]: not sure I understand the question | 17:21 |
freemangordon | why shall I mind? | 17:21 |
freemangordon | it is not 'mine' really | 17:21 |
mighty17[m] | asking for permissions is always better :D | 17:21 |
freemangordon | ok, you have my permission if you (and pmos guys) promise to fix the bug there if any :p | 17:22 |
mighty17[m] | well exporting =pvr is a not a bug, its a feature | 17:23 |
bencoh | :] | 17:23 |
freemangordon | mighty17[m]: also, 'my' mesa was a bit older, Wizzup rebased on some recent version | 17:23 |
mighty17[m] | we've been using 20.3.2 since ages :P | 17:23 |
freemangordon | 21.2.5+pvr1-1+2m7 | 17:24 |
freemangordon | most-probably has PP fixes/improvements | 17:24 |
freemangordon | but up to you ofc | 17:24 |
Wizzup | freemangordon: when you build n900 kernel, what config do you use? | 17:26 |
Wizzup | I wonder if perhaps some defconfig or built in command line change is the problem here | 17:26 |
freemangordon | the same as for d4 | 17:26 |
freemangordon | omap2plus-defconfig | 17:26 |
Wizzup | blergh | 17:26 |
Wizzup | ok | 17:26 |
Wizzup | and you also do appended dtb I assume | 17:27 |
freemangordon | yes | 17:27 |
Wizzup | well with 5.1 my n900 boots to a llvmpipe desktop at least | 17:28 |
Wizzup | so it's not completely fuba | 17:28 |
Wizzup | fubar* | 17:28 |
Wizzup | freemangordon: can you send me your uimage + mods (assuming the mods are different)? | 17:31 |
Wizzup | I took the droid4 img and did 'cat zImage omap3-n900.dtb > ../zImage' and then a mkimage, and it just doesn't boot | 17:31 |
mighty17[m] | <freemangordon> "most-probably has PP fixes/..." <- PP = pinephone? | 17:32 |
freemangordon | yes | 17:32 |
freemangordon | Wizzup: "mods"? | 17:33 |
freemangordon | modules? | 17:33 |
Wizzup | modules | 17:33 |
freemangordon | sec | 17:33 |
Wizzup | alt you can try the one we build in CI, but I suspect that's more work for you | 17:33 |
freemangordon | just lemme verify it still boots before sending to you | 17:34 |
Wizzup | ok | 17:35 |
freemangordon | hmm, maybe I shall provide you the .config files as well | 17:38 |
freemangordon | I am not 100% sure I didnt; change anything | 17:38 |
Wizzup | if it boots I won't need te config files, they are usually built in | 17:38 |
freemangordon | ok | 17:38 |
Wizzup | btw, yes, looks like the ddx fix worked | 17:40 |
Wizzup | (wrt deps) | 17:40 |
freemangordon | great | 17:40 |
Wizzup | freemangordon: do you use 'run sdboot' to boot the kernel? | 17:44 |
freemangordon | yes | 17:44 |
Wizzup | trying to find what I am doing wrong, not finding it :) | 17:45 |
freemangordon | btw, this kernel *does not* boot to h-d | 17:45 |
freemangordon | but boots to console | 17:45 |
Wizzup | for me it resets after like 10-15s | 17:45 |
freemangordon | ah, ok | 17:45 |
Wizzup | and I see nothing on the screen | 17:45 |
freemangordon | ok, boots here, sec to provide archive | 17:45 |
Wizzup | btw, if it does not boot to h-d, is it an older commit than the droid4-linux branch we have then? | 17:46 |
freemangordon | http://46.249.74.23/leste/n900/n900.tar.gz | 17:47 |
freemangordon | no, it is on leste/droid4-pending-pvr-omapdrm-v5.15 | 17:47 |
freemangordon | not saying it is kernel fault | 17:47 |
freemangordon | for sure it is missing nokia modules | 17:48 |
freemangordon | and maybe ofono hangs because of that | 17:48 |
freemangordon | wild guessing, didn;t investigate what happens | 17:48 |
Wizzup | so it's on this: https://github.com/maemo-leste/droid4-linux/commit/32fd293562d705670dfb3522e19e533e98729a9e | 17:48 |
freemangordon | yes | 17:48 |
Wizzup | ty I wil try this | 17:48 |
freemangordon | last commit is 32fd293562d705670dfb3522e19e533e98729a9e | 17:49 |
Wizzup | cool | 17:49 |
freemangordon | but maybe I have some config changes | 17:49 |
freemangordon | wifi related for sure | 17:49 |
freemangordon | I don;t think wl1251 is enabled by default | 17:50 |
Wizzup | still the one we have in the CI doesn't even get to a screen, probably not even to openrc | 17:51 |
Wizzup | let me try now.. | 17:51 |
freemangordon | hmm | 17:51 |
freemangordon | "Nov 23 18:44:20 localhost /etc/init.d/mce[2268]: ERROR: mce failed to start" | 17:51 |
freemangordon | that's why it doesn;t boot | 17:52 |
Wizzup | lol, your kernel also resets for me | 17:53 |
Wizzup | what u-boot do you have? | 17:53 |
freemangordon | hmm | 17:53 |
freemangordon | lemme check | 17:53 |
Wizzup | I built one today, 2021.10 | 17:53 |
freemangordon | some old one | 17:53 |
freemangordon | but not fremantle | 17:53 |
Wizzup | probably https://maedevu.maemo.org/images/n900/tools/u-boot-2013.04-2.bin | 17:53 |
freemangordon | like, from the times I played with uboot | 17:53 |
freemangordon | no, it is few months old | 17:54 |
freemangordon | have to reboot to verify | 17:54 |
freemangordon | sec | 17:54 |
uvos | mce --verbose --verbose? | 17:54 |
uvos | wrt it not starting | 17:54 |
Wizzup | with old u-boot it also resets with no info :( | 17:55 |
freemangordon | uvos: still, have to reboot | 17:55 |
freemangordon | also, this device hasn;t been updated for ages | 17:55 |
freemangordon | Wizzup: :( | 17:55 |
freemangordon | that's bad | 17:56 |
Wizzup | yeah, blind debugging is no fun | 17:56 |
Wizzup | I have the serial right here, but no the lab psu | 17:56 |
uvos | the n900's hard to acess serial port is a constant problem :\ | 17:56 |
freemangordon | I know (blind debugging) :) | 17:56 |
Wizzup | uvos: yes we had an idea about making some serials but you didn't like the design right :P | 17:56 |
uvos | well you dont need to me to rubber stamp your designs do you :P | 17:57 |
freemangordon | Wizzup: my uboot is built on 31 oct 2020 | 17:57 |
Wizzup | I think I'll take a break and see if I can think of a method to debug this later | 17:57 |
freemangordon | but I don;t think that's relevant | 17:58 |
Wizzup | right, same problem with our 'standard' 2013 uboot | 17:58 |
freemangordon | somehitn broken on uSD card? | 17:58 |
Wizzup | very much doubt it | 18:00 |
freemangordon | "/lib/rc/sh/openrc-run.sh: 1: export: directory:: bad variable name" | 18:00 |
freemangordon | yeah, SW on this device is old :) | 18:00 |
Wizzup | I'll be home on 7 december, then I can try it with psu | 18:00 |
Wizzup | exactly two weeks from now ;) | 18:01 |
freemangordon | nice | 18:01 |
Wizzup | maybe it's some watchdog kicking before the module is loaded ? | 18:01 |
freemangordon | new rule of thumb - never go abroad without lab psu :p | 18:01 |
Wizzup | I had one, I left it in sofia! | 18:01 |
Wizzup | lol | 18:01 |
freemangordon | ah, I see | 18:02 |
freemangordon | "1 upgraded, 0 newly installed, 0 to remove and 663 not upgraded." | 18:02 |
Wizzup | lol | 18:04 |
freemangordon | yeah, this will take time | 18:05 |
Wizzup | freemangordon: I wonder if it is the watchdog being '=m' | 18:31 |
Wizzup | CONFIG_OMAP_WATCHDOG=m | 18:31 |
Wizzup | CONFIG_TWL4030_WATCHDOG=m | 18:31 |
freemangordon | Wizzup: maybe | 18:44 |
freemangordon | if you boot from a slow uSD that could be a problem I guess | 18:44 |
Wizzup | n9xx-linux $ grep WATCH ./arch/arm/configs/n900_defconfig | 18:59 |
Wizzup | CONFIG_WATCHDOG=y | 18:59 |
Wizzup | CONFIG_OMAP_WATCHDOG=y | 18:59 |
Wizzup | CONFIG_TWL4030_WATCHDOG=y | 18:59 |
freemangordon | hmm | 19:01 |
freemangordon | well, try it | 19:01 |
sicelo | wl1251 should be enabled by default for n900. i committed that a while ago | 19:02 |
Wizzup | freemangordon: yeah will do in a bit | 19:12 |
freemangordon | Wizzup: who provides mesa.sh? | 19:23 |
freemangordon | found it | 19:24 |
freemangordon | Wizzup: we need nokia-modem enabled too | 19:26 |
Wizzup | that is for your problem, right? | 19:41 |
Wizzup | I'll enable it a bit later once I have it booting | 19:41 |
Wizzup | (your problem = not booting to h-d) | 19:41 |
uvos | tmlind: btw 5.15 pwrdm is unhappy on bionic | 19:47 |
uvos | pwrdm state mismatch(l4per_pwrdm) 3 != 1 repeats fairly often | 19:48 |
uvos | related to the cpcap regulator swap? | 19:48 |
freemangordon | Wizzup: not sure why h-d is not booting | 19:54 |
freemangordon | why xsession needs ofono? | 20:05 |
Wizzup | pinentry probably | 20:05 |
uvos | i think we added it for sphone | 20:05 |
Wizzup | freemangordon: wait are you seeing X starting, but hildon not? | 20:05 |
uvos | but sphone dosent need to be started after ofono anymore | 20:05 |
freemangordon | Wizzup: yes | 20:05 |
Wizzup | maybe see if some pin entry thing is running | 20:06 |
freemangordon | because I have no ofono installed ;) | 20:06 |
freemangordon | and because of that, xsession fails to start | 20:06 |
uvos | just remove it | 20:06 |
uvos | its not nessecary anymore | 20:06 |
freemangordon | but why it is there in the first place? I upgraded | 20:06 |
uvos | i think parazyd added it for sphone | 20:07 |
uvos | as i said | 20:07 |
freemangordon | ok, please remove it | 20:07 |
uvos | i dont have commit access | 20:07 |
uvos | so parazyd ^^^ | 20:07 |
Wizzup | so this could be all the ui update problems maybe as well | 20:08 |
uvos | yeah if its dependes | 20:08 |
uvos | instead of merly after ofono | 20:08 |
uvos | in the initscript | 20:09 |
uvos | then yeah | 20:09 |
uvos | thats a bug | 20:09 |
uvos | what pacakge is the init scipt in question in? | 20:10 |
uvos | Wizzup: its you accutally | 20:12 |
uvos | https://github.com/maemo-leste/maemo-system-services/commit/5b164f9a8dc0bf34abb4120348c1aa0c69a88c88 | 20:12 |
uvos | apearantly not for sphone either | 20:12 |
uvos | Scripts that get installed to xsession (like connui-conndlgs) require | 20:13 |
uvos | ofono to be running, or the entire xsession will block indefinitely | 20:13 |
uvos | (on startup-pin-query in this case). | 20:13 |
uvos | we need to do soemthing about that ^^^^ | 20:13 |
uvos | ofono cant be mandatory | 20:13 |
Wizzup | I think it was not on purpose that this went to table | 20:13 |
Wizzup | well later on it will have to be | 20:13 |
Wizzup | but not now | 20:13 |
uvos | ok | 20:13 |
uvos | no | 20:13 |
uvos | ofono cant be mandatory | 20:13 |
Wizzup | it should be depending on the installed packages, but let's not go into that now please | 20:14 |
uvos | ok | 20:14 |
uvos | anyhow please remove this commit | 20:14 |
uvos | Wizzup: a clean ish solution for now | 20:16 |
uvos | is for that init script to not need ofono but be after ofono | 20:16 |
Wizzup | won't that do the same? | 20:17 |
uvos | no | 20:17 |
uvos | and whatever xsession script blocks should check pidof ofono | 20:17 |
Wizzup | freemangordon: are you sure this is causing your problem btw? | 20:17 |
uvos | and then exit immitaly | 20:17 |
uvos | if ofono is not running | 20:17 |
Wizzup | i.e. can you remove ofono from the /etc/init.d/xsession | 20:17 |
freemangordon | yeah, already did | 20:17 |
freemangordon | now trying to boot | 20:17 |
Wizzup | and that's the problem? | 20:17 |
Wizzup | ok | 20:18 |
freemangordon | no idea, still trying to boot | 20:18 |
freemangordon | hmm, actually device got powered off a couple of times, exactly as you explained | 20:18 |
freemangordon | on the 3th try it booted fine | 20:18 |
freemangordon | yep, h-d is up | 20:19 |
uvos | sweet random reset timeing bug :P | 20:19 |
freemangordon | yeah, maybe the issue is with WDs being modules | 20:21 |
Wizzup | let me try wd now | 20:27 |
sicelo | i've never understood why retries make a difference with the booting :-/ | 20:37 |
Wizzup | if it's timing related | 20:37 |
uvos | also second boot is warm | 20:37 |
uvos | (ie registers are not in reset state nesscarly) | 20:37 |
Wizzup | freemangordon: how long before you see something on console btw? | 20:38 |
Wizzup | it's not resetting now at least with me compiling watchdog in | 20:38 |
sicelo | it's not a warm/cold boot issue. sometimes cold boots, then warm won't boot | 20:38 |
sicelo | anyway, i guess serial is the only way to really find out | 20:39 |
uvos | Wizzup: maybe the problem is that it fails to init the mmc card | 20:39 |
uvos | that would explain the reset | 20:39 |
uvos | cant find the modules | 20:39 |
uvos | and the no reset now | 20:39 |
Wizzup | it doesn't reset now with watchdog compiled in | 20:39 |
uvos | but still no boot | 20:39 |
Wizzup | yes maybe | 20:39 |
Wizzup | but why would that be the case for me and not for fmg? | 20:39 |
uvos | sdcards take different amounts of time to come up | 20:39 |
uvos | fmgs might come up faster | 20:39 |
uvos | or smth | 20:39 |
Wizzup | can't have nice things, ever :D | 20:40 |
Wizzup | wait it boots now I think | 20:41 |
uvos | maybe build in the dss modules | 20:41 |
uvos | /omapdrm | 20:41 |
uvos | then it might light the display | 20:41 |
uvos | having a fully static kernel around is very usefull for debuging this kind of issue gennerally | 20:42 |
Wizzup | yes it booted to 5.15 | 20:42 |
uvos | great | 20:42 |
Wizzup | looks like my X is trying to use fbdev | 20:43 |
uvos | still have -video-sgx installed? | 20:43 |
Wizzup | I think I removed it | 20:43 |
Wizzup | purging it... | 20:44 |
Wizzup | hm, same error | 20:45 |
uvos | xorg.log? | 20:45 |
* Wizzup removes xserver-xorg-video-fbdev | 20:46 | |
Wizzup | hm, maybe not | 20:46 |
Wizzup | uvos: same as before basically, no mention of omap | 20:46 |
Wizzup | hm: | 20:48 |
Wizzup | unrelated but: | 20:48 |
Wizzup | # /usr/bin/pvrsrvinit | 20:48 |
Wizzup | PVR:(Error): SrvInit: PVRSRVInitSrvConnect failed (129) [0, ] | 20:48 |
Wizzup | failed to initialize server | 20:48 |
Wizzup | (it might have already initialised) | 20:48 |
Wizzup | yeah it did I think: | 20:49 |
Wizzup | [ 481.334197] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ] | 20:49 |
Wizzup | freemangordon: do you have xorg conf on n900? | 20:49 |
Wizzup | It tried to load everything but omap it seems | 20:50 |
freemangordon | Wizzup: yes, I have | 20:53 |
freemangordon | it is there from when I played with omap driver | 20:54 |
freemangordon | I guess | 20:54 |
Wizzup | freemangordon: care to share the config? | 20:55 |
freemangordon | Wizzup: https://pastebin.com/0f2JWWEz | 20:56 |
freemangordon | but i guess if you copy it from d4 it will work | 20:57 |
Wizzup | we have none at d4 | 20:57 |
Wizzup | [ 1032.943] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/omap_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/omap_dri.so: cannot open shared object file: No such file or directory) | 20:57 |
Wizzup | mesa eh | 20:57 |
Wizzup | weird, even with the env var it doesn't work | 20:58 |
Wizzup | time to compare versions | 20:58 |
freemangordon | how's that (none on d4)? | 20:59 |
freemangordon | how does it know it shoul dload omap and not modesetting? | 20:59 |
Wizzup | I don't know, maybe I removed modesetting? | 21:00 |
freemangordon | I am almost sure d4 has omap.conf | 21:03 |
ruleh | there is /usr/share/X11/xorg.conf/99-omap.conf | 21:03 |
ruleh | xorg.conf.d | 21:04 |
Wizzup | ruleh: oh, yeah, I forget about these new paths... why do we have config in /usr/share again :-) | 21:04 |
ruleh | I think it is supposed to beĀ something like vendor supplied stuff goes to usr/share and admin configured stuff into etc or so | 21:05 |
Wizzup | freemangordon: so it doesn't segfault for you as soon as you touch the screen ? :P | 21:06 |
Wizzup | ruleh: right, yeah | 21:07 |
freemangordon | no | 21:08 |
Wizzup | I'll install debug symbols | 21:08 |
Wizzup | slowly getting there at least | 21:08 |
Wizzup | freemangordon: https://dpaste.com/2PVNJCCMC | 21:10 |
Wizzup | maybe I have old libdrm_omap | 21:10 |
tmlind | Wizzup: have you checked the kernel defconfig has been flipped over to 1.17? it defaults to 1.14 i think | 21:10 |
Wizzup | no, same version | 21:10 |
Wizzup | tmlind: it's the same kernel as the droid4-linux one, just with watchdog built in | 21:11 |
tmlind | ok | 21:11 |
Wizzup | freemangordon: hm I think maybe the init doesn't happen via init script | 21:11 |
Wizzup | freemangordon: ah: [ 390.615112] cma: cma_alloc: reserved: alloc failed, req-size: 375 pages, ret: -12 | 21:12 |
tmlind | uvos: that pwrdm mismatch is a bit of a mystery, probably some glitch between the cpuidle and prm driver, harmless afaik | 21:12 |
freemangordon | Wizzup: oh, now I remember, I increased CAM to 32 MiB :) | 21:13 |
freemangordon | *CMA | 21:13 |
Wizzup | hehe | 21:13 |
Wizzup | ok | 21:13 |
Wizzup | let me do that | 21:13 |
Wizzup | any reason to make it even higher? | 21:13 |
freemangordon | Wizzup: I don;t think we shall increase it that much | 21:15 |
Wizzup | ok | 21:15 |
Wizzup | rebuilding kernel | 21:15 |
freemangordon | I have a kernel fix in mind, unfortunately Tomi refused to accept the idea | 21:15 |
uvos | tmlind: ok, dont see it on d4 | 21:15 |
Wizzup | I think 32M is fine (for now) | 21:15 |
uvos | tmlind: seams to apear all the time on my bionic | 21:16 |
uvos | tmlind: dosent have any obvious negative effect yeah | 21:16 |
freemangordon | tmlind: is there any negative effect of increasing CMA on n900? | 21:17 |
Wizzup | uvos: ok questions are being asked internally about gitorious | 21:25 |
uvos | thank you :) | 21:25 |
tmlind | freemangordon: well how much does increasing help? n900 runs out of memory easily.. | 21:27 |
freemangordon | well, seems I didn't ask my question correctly :). Lemme rephrase - what should be the recommended value? given that we need at least 3 800x480x4 buffers for Xorg only | 21:28 |
tmlind | not sure, sounds like some experiments are needed to find the usable minimum size | 21:29 |
freemangordon | yeah. well, I'd rather write that fix | 21:30 |
tmlind | sounds like no help increasing it beyond the necessary minimum? | 21:30 |
Wizzup | uvos: they might hand me all the gitorious data and task me with putting it online, we'll see | 21:31 |
freemangordon | but, I think we need contiguous memory for VRFB, so maybe that patch is not that helpful | 21:31 |
Wizzup | fun... | 21:31 |
freemangordon | *will not be that helpful | 21:31 |
freemangordon | yeah: "...must be allocated as a contiguous memory segment." | 21:34 |
tmlind | maybe play with cma=size[MG] option a bit? | 21:34 |
freemangordon | tmlind: well, no hurry, I am just thinking a bit | 21:35 |
freemangordon | we need at lest 6MiB just for the framebuffers | 21:36 |
freemangordon | but for others, I still think it makes sense to not use CMA | 21:36 |
freemangordon | not sure what was needed by IVA | 21:36 |
uvos | This is a hack which is required until: http://lists.x.org/archives/xorg-devel/2013-February/035449.html is merged | 21:36 |
uvos | heh ok mesa | 21:36 |
freemangordon | uvos: hmm? | 21:38 |
Wizzup | also need to check my powervr.ini -- we don't have that in any of our new pkgs atm I think | 21:38 |
freemangordon | we don;t need it | 21:38 |
freemangordon | anyway, I am afk | 21:39 |
freemangordon | ttyl | 21:39 |
Wizzup | freemangordon: wait | 21:39 |
uvos | freemangordon: so | 21:39 |
Wizzup | freemangordon: it works :) | 21:39 |
uvos | glx segfaults | 21:39 |
Wizzup | just wanted to share that | 21:39 |
uvos | because dri2CreateScreen blindly assumes the extension __DRI2_CONFIG_QUERY exists | 21:39 |
* tmlind zzz | 21:40 | |
Wizzup | sicelo: around? | 21:41 |
freemangordon | uvos: ah | 21:44 |
freemangordon | uvos: ok, will implement that | 21:44 |
freemangordon | Wizzup: cool! | 21:45 |
Wizzup | freemangordon: great work | 21:45 |
Wizzup | uvos: I think what we should do is integrate gl4es to do glx for us perhaps | 21:45 |
sicelo | Wizzup: yes. | 21:45 |
Wizzup | sicelo: do you have n900 pm stuff around>? | 21:46 |
Wizzup | I'd like to try it on 5.15 | 21:46 |
Wizzup | like, to make it enter off mode, like a droid4-pm script | 21:46 |
uvos | yeah thats a good idea maybe xorg not ideling the display ever was all there was too it | 21:46 |
uvos | wrt it not idelin | 21:47 |
sicelo | no. i do have tmlind's patch though. had forward ported it to the last kernel i tried (5.12/5.13) | 21:47 |
uvos | g | 21:47 |
Wizzup | sicelo: right that's for reading the blockers | 21:47 |
Wizzup | but first we need to run the script and measure | 21:47 |
Wizzup | I had an adapted version at some point | 21:47 |
Wizzup | but I probably nuked it | 21:47 |
sicelo | there's the one in wiki. i was using that | 21:47 |
sicelo | n900 wiki, i.e. | 21:47 |
Wizzup | I don't think so | 21:48 |
sicelo | mmm, let me also check in my uSD card. i remember using a script similar to the d4 one, but can't find it now | 21:48 |
Wizzup | we also need to update idle_uarts (just change 4 to a 3 iirc) | 21:49 |
Wizzup | we also don't mount debugfs by default | 21:50 |
sicelo | hehe, and then my card won't work in laptop :-/ | 21:53 |
Wizzup | anyway this is fine, I can port the blocker patch and work on a pm script | 21:53 |
Wizzup | basically everything that blocks idle is loaded atm :P | 21:53 |
Wizzup | sicelo: rebuilding with deeper idle patch, will let you know how far I get | 22:01 |
sicelo | great. :-) | 22:05 |
sicelo | what patch is that? | 22:05 |
* calebtheythem[m] uploaded an image: (74KiB) < https://libera.ems.host/_matrix/media/r0/download/connolly.tech/xcEvGlcqFCwBKoZGQRJsZnfC/IMG_20211123_210549.jpg > | 22:06 | |
sicelo | seems my card is toast. now as soon as i put it on laptop, i get 'mmcblk0: mmc0:aaaa SB16G 14.8 GiB (ro)' - that (ro) at the end :-( | 22:06 |
calebtheythem[m] | well i gave it a go (hopefully image sends), maemo boots on the OnePlus 6 with a hacked up pinephone rootfs | 22:06 |
calebtheythem[m] | touch seems to work - i was getting haptics feedback when touching the screen initially but it doesnt seem to do anything | 22:07 |
sicelo | hehe, looks interesting! | 22:07 |
calebtheythem[m] | ah it is just rotated | 22:08 |
calebtheythem[m] | do you guys have rndis gadget support? OR how do you usually debug? | 22:09 |
Wizzup | sicelo: this https://github.com/maemo-leste/n9xx-linux/blob/maemo/beowulf-devel/debian/patches/0001_deeper_idle.patch | 22:10 |
Wizzup | calebtheythem[m]: yeah usbnet usually | 22:11 |
Wizzup | calebtheythem[m]: we have a daemon that also loads it automatically on plug, but it uses a whitelist... | 22:11 |
Wizzup | calebtheythem[m]: really cool btw! | 22:11 |
Wizzup | I like the glow that comes from it | 22:11 |
uvos | tklock looks really bad @hdpi | 22:12 |
Wizzup | yes | 22:12 |
Wizzup | :D | 22:12 |
calebtheythem[m] | it's only 1080p XD | 22:12 |
Wizzup | calebtheythem[m]: n900 is 800x480 | 22:12 |
sicelo | ah ok. that's the one i also had (patch) | 22:13 |
Wizzup | droid4 is a bit higher | 22:13 |
Wizzup | sicelo: right it just applied | 22:13 |
uvos | 960x540 | 22:13 |
calebtheythem[m] | Wizzup: what's the daemon? I can do some tweaking | 22:13 |
calebtheythem[m] | I use some custom busybox ramdisk which brings up rndis, it mostly works as long as maemo doesn't tear down the interface | 22:14 |
calebtheythem[m] | interfaces* | 22:14 |
Wizzup | calebtheythem[m]: let me try to remember :P | 22:15 |
calebtheythem[m] | cheers | 22:15 |
Wizzup | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L67 | 22:16 |
calebtheythem[m] | Wizzup: ah I see, so that brings up rndis? | 22:19 |
Wizzup | calebtheythem[m]: well, I believe that will launch a set of scripts, in particular a binary (let me find the name) that sets up usbnet | 22:20 |
Wizzup | I think it's this one: /usr/sbin/hildon-usb-gadget-network | 22:20 |
calebtheythem[m] | ah right | 22:20 |
calebtheythem[m] | I think I have some script somewhere which brings it up, I'll try dropping that in for now | 22:21 |
Wizzup | should work too | 22:21 |
Wizzup | there is a script that calls that binary and also sets up the IP I think | 22:21 |
freemangordon | calebtheythem[m]: what's with the date of that thing? | 22:22 |
freemangordon | omg: | 22:23 |
freemangordon | Octa-core (4x2.8 GHz Kryo 385 Gold & 4x1.7 GHz Kryo 385 Silver) | 22:23 |
calebtheythem[m] | freemangordon: the bloody RTC on this thing is readonly | 22:23 |
Wizzup | freemangordon: no keyboard though | 22:23 |
Wizzup | iiuc | 22:23 |
calebtheythem[m] | it reports the time since the battery was last removed (relative to epoch) | 22:24 |
Wizzup | lol | 22:24 |
freemangordon | and? you cannot set the date? | 22:24 |
calebtheythem[m] | i guess some the lockscreen clock got confused | 22:24 |
calebtheythem[m] | you can't write to the RTC | 22:24 |
sicelo | iirc this is the fastest/most powerful phone that's mainlined | 22:24 |
freemangordon | yeah, and is relatively new | 22:25 |
calebtheythem[m] | in postmarketOS we have a script which "solves" this by storing the now-rtc offset and updating the time | 22:25 |
freemangordon | 2018 | 22:25 |
Wizzup | freemangordon: anything in particular that should be in powervr.ini ? | 22:25 |
uvos | hildons gona fly on that | 22:25 |
freemangordon | I imagine leste is liek butter on this | 22:25 |
uvos | unfortionatly it dosent scale | 22:25 |
freemangordon | Wizzup: we don;t need powervr.ini :) | 22:26 |
uvos | so you need 7nm fingers to go with your 7nm process node | 22:26 |
freemangordon | uvos: I think we can easily scale it | 22:26 |
uvos | x can scale it | 22:26 |
Wizzup | calebtheythem[m]: btw mce will disable input devices if the device is considered in 'locked' mode, but since it vibrated it shouldn't be locked | 22:26 |
uvos | sure | 22:26 |
freemangordon | it is clutter behind the scenes after all | 22:26 |
uvos | but it looks bad | 22:26 |
uvos | x can just do this too | 22:26 |
freemangordon | anyway, I am again afk | 22:27 |
uvos | ie blinear scale | 22:27 |
freemangordon | ttyl | 22:27 |
uvos | *bilinear | 22:27 |
Wizzup | sicelo: I get this atm: https://pastebin.com/raw/ZUCUJ3uX | 22:29 |
Wizzup | sicelo: I don't remember if I got that list reversed or not | 22:29 |
Wizzup | I will have to recheck with some specific tests | 22:29 |
Wizzup | otherwise the blockers are mostly mmc | 22:30 |
Wizzup | sicelo: oh wait it doesn't actually read the live values.. | 22:33 |
Wizzup | ok, break time :) | 22:35 |
Wizzup | sicelo: yeah ok so that list needs a reversed(), just confirmed with otgusb | 22:47 |
Wizzup | https://dpaste.com/A7PRA4QLH | 22:49 |
Wizzup | oh mmc1 is the card, not wifi, nevermind me, anyway, you get the point | 22:49 |
Wizzup | these are the currnet blocking bits, maybe tmlind has some ideas tomorrow: | 22:51 |
Wizzup | ST_SDRC | 22:51 |
Wizzup | ST_OMAPCTRL | 22:51 |
Wizzup | ST_I2C1 | 22:51 |
Wizzup | ST_MCSPI4 | 22:51 |
Wizzup | I will also just boot to busybox a bit later to see what happens if we load almost nothing | 22:51 |
Wizzup | but not today | 22:51 |
* Wizzup afk | 22:51 | |
sicelo | nice stuff | 22:52 |
sicelo | i'll definitely need to get a new sd and get my hands dirty again :-) | 22:54 |
sicelo | nice to see wifi appears to already idle? | 22:55 |
Wizzup | yeah not too surprising | 22:57 |
sicelo | TRM says SDRC = SDRAM Controller. i suppose that won't really ever idle so much | 23:00 |
freemangordon | and now we can finally enable -depth 16 :D | 23:01 |
sicelo | mcspi4 ... isn't that spi? where our wifi is sitting. can't recall if we have anything else on spi bus | 23:02 |
freemangordon | hmm, where is display? | 23:03 |
sicelo | ah, yes | 23:04 |
Wizzup | a lot seems to be on spi if I read /sys correctly | 23:05 |
Wizzup | oh sorry, not spi | 23:05 |
Wizzup | touchscreen is on spi | 23:07 |
Wizzup | panel as well it seems | 23:08 |
uvos | sudo lsof /dev/input/* | 23:08 |
uvos | maybe something holds the input device open | 23:08 |
Wizzup | &mcspi4_pinsis wifi in dts | 23:08 |
Wizzup | &mcspi4_pins is wifi in dts* | 23:09 |
Wizzup | sicelo: and it doesn't always block | 23:09 |
Wizzup | so yes, wifi idles | 23:10 |
Wizzup | ST_SDRC | 23:10 |
Wizzup | ST_OMAPCTRL | 23:10 |
Wizzup | ST_I2C1 | 23:10 |
Wizzup | only have these now | 23:10 |
Wizzup | looks like st_i2c1 is twl | 23:11 |
uvos | check whats on i2c1 with ic2cdetect | 23:11 |
uvos | rmmod whatever is controling that device | 23:11 |
uvos | no idea about the others | 23:11 |
Wizzup | which could be a lot | 23:11 |
Wizzup | also mce and ke-recv hold input open | 23:11 |
uvos | they should | 23:12 |
uvos | non touchscreen ones | 23:12 |
Wizzup | yes, keypad, power button and and gpio_keys | 23:12 |
Wizzup | keypad is a bit weird IMHO | 23:12 |
Wizzup | mce 2854 root 12r CHR 13,64 0t0 412 /dev/input/event0 | 23:12 |
Wizzup | /dev/input/event0:TWL4030 Keypad | 23:12 |
uvos | Wizzup: trying to idle the keypad is a useless endeavor | 23:12 |
uvos | Wizzup: the kernel holds any device with any KEY _watever event open for itself regardless | 23:13 |
Wizzup | anyway I'm really going to take a break now | 23:13 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!