uvos | Wizzup: its a regmap | 00:12 |
---|---|---|
uvos | so theres a file in debugfs for it | 00:12 |
uvos | not sure the exact path | 00:12 |
Wizzup | hi | 00:12 |
Wizzup | ok, let me see | 00:12 |
uvos | might be /sys/debug/regmap even | 00:12 |
Wizzup | meanwhile the android ones I uploaded | 00:12 |
Wizzup | there is /sys/kernel/debug/regmap/ | 00:15 |
Wizzup | # ls | 00:19 |
Wizzup | 0-0038 4806a000.serial:modem:audio-codec@2 dummy-scm_conf@4a002000 | 00:19 |
Wizzup | 1-0044 dummy-omap4_padconf_global@4a1005a0 spi0.0 | 00:19 |
uvos | spi0.0 is cpcap | 00:19 |
uvos | not sure why the name is so wierd | 00:20 |
uvos | i gues thats the host side of the bus? | 00:20 |
Wizzup | root@devuan-droid3:/sys/kernel/debug/regmap/spi0.0# cat name | 00:20 |
Wizzup | cpcap-core | 00:20 |
Wizzup | right | 00:20 |
Wizzup | ok, I can get the regs on serial, so shall I just them from mainline with screen on (and serial connected, but not usb)? | 00:21 |
uvos | as nutch of the same state as android as possible ofc | 00:21 |
uvos | since we are trying to make the diff as small as possible | 00:21 |
Wizzup | right | 00:21 |
Wizzup | the files I linked on my website have some pretty clear diffs | 00:21 |
Wizzup | between the diff frequencies | 00:22 |
uvos | sure, but ideally we would expect no diff between android and mainline, besides the rtc | 00:22 |
uvos | and the audio section is tricky | 00:22 |
Wizzup | what I mean is that maybe the android regs can tell us which mainlines regs to look at | 00:23 |
Wizzup | but then again I have no idea what I am doing :) | 00:23 |
uvos | what im looking for is mostly the possiblity of configureing a regulator wrong | 00:23 |
Wizzup | https://wizzup.org/dirlist/maemo-leste/droid3/mainline-cpcap-regs.txt | 00:24 |
Wizzup | do you also want the emif regs? | 00:45 |
Wizzup | uvos__: do you have the droid3 signal map as well, or is that https://uvos.xyz/maserati/stockinfo/signalmaps/xt860.txt | 10:55 |
Wizzup | I saw the dts for xt862 but presumably x860 and xt862 'the same' or similar enough | 10:56 |
Wizzup | although the xt860 might not have usb modem | 10:57 |
arno11 | freemangordon: you mean adding dh_installxsession in libcmtspeechdata rules (and xsession file) like pulseaudio in maemo-audio ? | 10:59 |
arno11 | btw i tried to add a xsession file for cmt_pulse by hand and got a blackscreen lol | 11:00 |
Wizzup | what did you add as contents | 11:01 |
arno11 | just /usr/bin/cmt_pulse | 11:02 |
Wizzup | did you look at any other xsession files? | 11:03 |
Wizzup | I'm pretty sure that whatever the script does, it should return to allow the next script to run | 11:04 |
Wizzup | so in the very /least/ you need /usr/bin/cmt_pulse & | 11:04 |
Wizzup | (and probably #!/bin/bash too) | 11:04 |
arno11 | (yes ofc i looked at other scripts) | 11:04 |
Wizzup | or ues dsme to start it with will also return | 11:04 |
arno11 | for #!/bin/bash: yes ofc, xsession scripts still use /bin/sh BTW | 11:08 |
Wizzup | sh is fine | 11:12 |
Wizzup | did you check if you backgrounded the task as I mentioned? | 11:13 |
arno11 | let me try again ;) | 11:13 |
arno11 | seems to work with background (need time to load h-d and check) | 11:18 |
arno11 | it works fine :) | 11:26 |
arno11 | so we have just to add dh_install stuff in libcmtspeechdata and we'll have calls OOTB | 11:27 |
arno11 | btw the alerting tone disappeared again | 11:27 |
freemangordon | arno11: as Wizzup said, look at other xsession files | 11:29 |
freemangordon | sec, will give you example | 11:29 |
arno11 | already done, why exactly ? | 11:29 |
arno11 | ok | 11:29 |
freemangordon | https://github.com/maemo-leste/connui-common/blob/master/debian/connui-conndlgs.xsession | 11:30 |
freemangordon | already done what? | 11:30 |
arno11 | already checked other xsession files | 11:30 |
freemangordon | ok, what dsme parameters you pass? | 11:31 |
freemangordon | also, do you install in .post? | 11:31 |
arno11 | ah ok, misunderstanding | 11:31 |
freemangordon | Wizzup: what do you think, where xsession file shall be installed? in .d or in .post? | 11:32 |
arno11 | it works with a basic xsession file with /usr/bin/cmt_pulse & | 11:32 |
arno11 | i didn't try with dsmetool | 11:32 |
freemangordon | arno11: cool, but this is a system critical daemon that shall be restarted on crash | 11:32 |
freemangordon | that's why dsmetool | 11:32 |
arno11 | ok makes sense | 11:33 |
freemangordon | or, we may decide to reboot the device is cmt_pusle crashes, etc | 11:33 |
freemangordon | also, how do you install the script? dh_installzsession? | 11:33 |
freemangordon | dh_installxsession? | 11:33 |
arno11 | no, i just created a file in xsession.d | 11:34 |
arno11 | to test | 11:34 |
freemangordon | ok, I was under the impression you are tryint to fix the package | 11:35 |
arno11 | no lol | 11:35 |
freemangordon | ok, but that shall be done by someone that can test it | 11:36 |
freemangordon | do you mind to do a PR for a proper xsession fix? after testing ofc | 11:37 |
freemangordon | otherwise we are more or less stuck, as I don;t have another SIM to put in n900 | 11:37 |
freemangordon | unless sicelo volunteers for the PR :) | 11:37 |
arno11 | yes sure, no probs, i modified and rebuild libcmtspeechdata hundreds of times lol | 11:38 |
freemangordon | coo | 11:38 |
freemangordon | l | 11:38 |
freemangordon | adding xsession support is very simple, no worries | 11:38 |
freemangordon | see https://github.com/maemo-leste/connui-common/blob/master/debian/rules as example | 11:38 |
freemangordon | you also need to add control dependency | 11:39 |
arno11 | yes ok | 11:39 |
freemangordon | maemo-system-services-dev, iirc | 11:39 |
freemangordon | and proper xsession file in /debian | 11:40 |
freemangordon | use connui-common as example | 11:40 |
arno11 | ok | 11:40 |
freemangordon | just change post to pre (iirc) here https://github.com/maemo-leste/connui-common/blob/master/debian/rules#L11 | 11:40 |
freemangordon | because we want daemon started before h-d, IIUC | 11:41 |
arno11 | if it starts after, that's ok too | 11:41 |
freemangordon | up to you | 11:42 |
arno11 | i think i must try both | 11:42 |
freemangordon | but then you won;t hear any sound if a call comes | 11:42 |
freemangordon | also, with dsmetool you can set nice value | 11:42 |
freemangordon | see /usr/sbin/dsmetool -h | 11:43 |
freemangordon | hmm... | 11:43 |
arno11 | ok | 11:43 |
arno11 | why no sound ? | 11:43 |
freemangordon | because daemon is still not running :) | 11:44 |
freemangordon | I wonder if we can teach dsme to alter scheduling priority as well | 11:44 |
arno11 | interesting indeed | 11:45 |
freemangordon | instead of doing whatever sudoers hacks we were planning | 11:45 |
freemangordon | but that will not fix the issue with PA process | 11:45 |
freemangordon | as it is not dsmetool started | 11:45 |
freemangordon | have to run, wish you luck :) | 11:45 |
arno11 | thanks :) i'll try a bit later and let you know (kids time for me) | 11:46 |
Wizzup | uvos__: so I will double check if I am setting the freq correct, by logging to system, and then also try the latest 6.6 kernel with dts forward ported | 11:51 |
Wizzup | freemangordon: I don't know @ .d or .post | 11:51 |
sicelo | no need to reboot device on cmt_pulse crash | 11:58 |
freemangordon | sicelo: that was just a theory :) | 12:00 |
freemangordon | but we shall restart it | 12:00 |
freemangordon | also, what will happen if ofono gets restarted? | 12:00 |
sicelo | it should be able to keep running. there's nothing it needs in ofono besides knowing when ofono's AudioSettings interface changes to Active status | 12:05 |
Wizzup | sicelo: not reboot, but restart | 12:06 |
Wizzup | 11:45 < freemangordon> I wonder if we can teach dsme to alter scheduling priority as well | 13:25 |
Wizzup | you could just ship a script start-cmt-pulse.sh that does all this | 13:25 |
Wizzup | and then dsme just runs this script | 13:25 |
Wizzup | I think | 13:25 |
Wizzup | tmlind: so uvos has been trying to help me figure out why the droid3 seems to reset (frequently) under load, I just wanted to check if you had some additional ideas | 13:26 |
Wizzup | currently I'm making sure that on the first kexec call the freq is set to max (1ghz), and I think this is already the case, but just in case I will verify | 13:27 |
Wizzup | then next I made cpcap register dump at each of the frequencies in android, and also one on leste, to see if there are any regs that are wrong | 13:27 |
Wizzup | but I am having a hard time interpreting *what* these cpcap regs are, there is a clear diff between the freqs on android | 13:28 |
Wizzup | I suppose I can make a few more dumps on android in the frequencies and see if there are regs that change in between say 300Mhz attempt 1 and 2, so that I can eliminate further certain regs that don't matter | 13:28 |
Wizzup | but other than this I am kind of stuck | 13:28 |
Wizzup | I suppose I could prevent say pvr from loading in case the gpu clock speed is also too high | 13:29 |
Wizzup | What seems to happen is that the device just hangs, watchdog realises this and then resets: | 13:33 |
Wizzup | root@devuan-droid3:~# | 13:33 |
Wizzup | -- OMAP 00004430 (version 00000b22) PPA release1.3.5 R2 | 13:33 |
Wizzup | Reset reason = 000379a2 | 13:33 |
Wizzup | Model ID is 0x00000003 | 13:33 |
Wizzup | PPA hash Block:0x9ff00000 Size:260096 Flag:3 | 13:33 |
Wizzup | uvos__: I confirmed that the frequency is 1000000 at the time of kexec | 13:46 |
Wizzup | /system/logs/maemo-freq.txt contains: | 13:46 |
Wizzup | 1000000 | 13:46 |
arno11 | freemangordon: sicelo: Wizzup: ok, we have calls on N900 OOTB :) | 14:11 |
arno11 | it works, adding xsession/dsme stuff in libcmtspeechdata | 14:11 |
sicelo | great. tyvm | 14:12 |
sicelo | do we have the sphone landscape thing in place ootb too? | 14:12 |
arno11 | nope, still need to modify sphone.ini by hand | 14:13 |
Wizzup | can't we set a gconf key? | 14:14 |
arno11 | don't no but probably | 14:15 |
arno11 | and BTW we don't need chrt stuff for cmt_pulse, we just need it for sphone and PA | 14:15 |
sicelo | maybe that should go in as well (landscape thing). would be unfortunate to find your screen dead | 14:15 |
arno11 | true | 14:16 |
Wizzup | if there is sphone.ini.d or a gconf key we can manage it with leste-config-n900 | 14:16 |
Wizzup | I updated hildon-meta, leste-config and mapphone-kexecboot-config with support for xt910 and xt912 and I split out the config and meta packages for them in case we need to diverge at some point | 14:17 |
Wizzup | there is /usr/share/sphone/sphone.ini.d | 14:18 |
Wizzup | arno11: what change to do you make to sphone.ini, can you share? | 14:18 |
Wizzup | then I will update leste-config-n900 now | 14:19 |
arno11 | i was looking for the same thing :) ok let me few sec | 14:20 |
arno11 | you just need to add LandscapeCall=1 | 14:21 |
arno11 | in Gui | 14:22 |
Wizzup | so | 14:22 |
Wizzup | [Gui] | 14:22 |
arno11 | yes | 14:22 |
Wizzup | LandscapeCall=1 | 14:22 |
arno11 | yes | 14:22 |
Wizzup | ok one sec | 14:22 |
arno11 | cool :) | 14:22 |
Wizzup | building new leste-config | 14:24 |
arno11 | :) | 14:24 |
Wizzup | in a few minutes, please apt update and apt upgrade, assuming you're on leste-devel, and then check /usr/share/sphone/sphone.ini.d/landscape-call.ini | 14:25 |
Wizzup | and then you can remove your change to /usr/share/sphone/sphone.ini and then see if it still works? | 14:25 |
arno11 | ok, yes ofc | 14:25 |
Wizzup | ready to update | 14:28 |
Wizzup | uvos__: static const struct dsic_panel_data razr_xt9xx_data's width_mm and height_mm doesn't match the xt910-xt912.dtsi width-mm and height-mm | 14:31 |
Wizzup | I doubt this makes a difference (will check, probably just for dpi) | 14:31 |
Wizzup | yeah looks like it | 14:31 |
sicelo | arno11: you made PR for libcmtspeechdata? so Wizzup can rebuild that while he's here :-) | 14:31 |
Wizzup | sicelo: I'm almost always here :D | 14:32 |
sicelo | 😃 I'll also love to test (in about 3 hours). would be nice to just apt get | 14:35 |
Wizzup | uvos__: dispc_timing_hsw from the xt912dts does seem to match the hsync-len <2> in mainline dts | 14:36 |
arno11 | sicelo: Wizzup: i can make a PR + sphone.ini test in 30-45 min (kids around so not so easy for me) | 14:39 |
sicelo | ah, no rush :-) | 14:40 |
Wizzup | tmlind: it looks like panel-dsi-cm had a commit from you to support x_offset (drm/panel: panel-dsi-cm: Add update window offset), but I don't see that actually being used anywhere in the subsequent commit that adds support for xt910 | 14:43 |
Wizzup | tmlind: nevermind I am wrong, it is used | 14:44 |
Wizzup | uvos__: so page 2085 of the omap4430 trm starts to list the dss regs, is this what you meant? | 15:20 |
Wizzup | uvos__: rwmem just always gives me bus error on mainline, even on addrs that apparently worked for folks here according to the irc log | 15:49 |
arno11 | Wizzup: i did a dist-upgrade with very last stuff and now N900 refuses to shutdown but reboot instead...in less than 25 sec !! | 15:50 |
Wizzup | okay, I give up for now, I'm going to use my time in a more effective way than this driver stuff | 15:50 |
Wizzup | arno11: I don't think I changed anything special | 15:50 |
arno11 | maybe last fmg stuff with weird shutdown | 15:52 |
arno11 | anyway we are not far to solve the slow shutdown imo | 15:55 |
arno11 | wow and sphone crashes with immediate reboot (ofc not related with previous reboot) | 15:57 |
arno11 | Wizzup: so ATM i'm not able to test sphone.ini stuff | 15:58 |
Wizzup | maybe it is not happy with the config file | 16:00 |
Wizzup | i'll try it on my n900 | 16:00 |
arno11 | i'll remove sphone.ini.d to see if sphone continue to crash | 16:00 |
arno11 | ok | 16:00 |
Wizzup | yes please do try that | 16:00 |
arno11 | yup | 16:00 |
arno11 | sphone.ini.d seems to be the problem, currently rebooting to test | 16:04 |
arno11 | yes sphone is not happy with the config file indeed | 16:12 |
arno11 | and the fast reboot was due to sphone.ini.d as well | 16:13 |
arno11 | i'll make the PR for cmt_pulse now (it works fine) | 16:13 |
sicelo | LandscapeCall=1 ... shouldn't that be LandscapeCalls maybe? (plural)? | 16:16 |
sicelo | otherwise, i don't see why it would crash sphone, or cause reboots | 16:16 |
Wizzup | I will check the src and debug if it crashes for me | 16:18 |
arno11 | sicelo: oh yes | 16:20 |
arno11 | you're right | 16:20 |
arno11 | LandscapeCalls=1 | 16:20 |
Wizzup | let's hope it doesn't crash because of this | 16:20 |
sicelo | i doubt the crash is due to it. in fact, it's not :-) | 16:21 |
Wizzup | how do you know? | 16:21 |
Wizzup | so sphone does not crash for me | 16:30 |
Wizzup | regardless of the key name | 16:31 |
Wizzup | sphone: sphone-conf: Could not open config overide dir /home/user/.config/sphone/ | 16:31 |
Wizzup | sphone: sphone-conf: found conf file 0: sphone.ini | 16:31 |
Wizzup | sphone: sphone-conf: found conf file 1: landscape-call.ini | 16:31 |
Wizzup | it does load it | 16:31 |
sicelo | https://github.com/maemo-leste/sphone/blob/e4f6af0d4d744f189ea0382846a6c1d9789c112e/src/modules/gui/gtk2/ui-calls-manager-gtk.c#L445 is where the decision is made, based on https://github.com/maemo-leste/sphone/blob/master/src/utils/sphone-conf.c#L80 ... this just feeds a simple ternary operator/condition. no way it causes crashing | 16:33 |
sicelo | there might have been something else at play for the observed crash | 16:33 |
Wizzup | yeah | 16:35 |
Wizzup | I changed it to calls (plural) and then rebooted, and it seems to boot fine | 16:39 |
arno11 | Wizzup: cool, and if you shutdown the device ? | 16:45 |
arno11 | the cmt_pulse PR: https://github.com/maemo-leste/libcmtspeechdata/pull/5 | 16:45 |
Wizzup | shutdown with ui or cmdline | 16:48 |
arno11 | with ui | 16:48 |
Wizzup | will try now | 16:48 |
arno11 | ok | 16:48 |
Wizzup | arno11: yes shutdown works fine for me | 16:50 |
Wizzup | arno11: so the "&" is not necessary when you use dsme | 16:51 |
Wizzup | I'll adjust the dsme flags a bit | 16:51 |
arno11 | ok | 16:53 |
arno11 | rebooting to test call | 16:56 |
arno11 | with sphone.ini.d | 16:57 |
arno11 | Wizzup: wow it works (call) then the phone crashes | 17:03 |
arno11 | working fine without sphone.ini.d, weird | 17:04 |
arno11 | Wizzup: i have to go, let me know when libcmtspeechdata is ready for upgrade | 17:06 |
arno11 | ttyl | 17:06 |
tsesani | I posted to the mailing list about building raspi4 images but no response. Also have been chatting in gemini://bbs.geminispace.org/s/maemo. I also released 2005 2006 2007 original code at https://github.com/tsesani/Maemo | 20:18 |
uvos | Wizzup: no idea whats wrong with rwram, but the kernel people where discussing adding more restricitons to /dev/mem | 20:20 |
Wizzup | tsesani: I did not see that email, I will respond when I get back | 20:20 |
uvos | so probubly that | 20:20 |
uvos | Wizzup: for the cpcap regs | 20:20 |
tsesani | Running in virtual machine on Devuan 5 OK with X core every once in awhile. Nice work to all. | 20:21 |
uvos | diff the state between the mainline kernel and the android kernel at the same oop | 20:21 |
uvos | theres a cpcap header with the register names, they are fairly inteligable | 20:21 |
uvos | use those to narrow different registers down | 20:21 |
uvos | really we are most interested in regulators being different | 20:22 |
uvos | bionic has some chaneges in what regs are used for what and we just assumed d3 is the same | 20:22 |
uvos | so thats a good first step | 20:22 |
uvos | maybe check sgx clock too, could be that we are running it to fast | 20:22 |
uvos | we clocked sgx up on the mapphones relative to spec because motorola also did that on d4/bionic | 20:23 |
uvos | but maybe they dident on d3 | 20:23 |
uvos | beyond that spme perifferals are different too between d3 and bionic | 20:24 |
uvos | so maybe some periferal driver is missbehavig | 20:24 |
uvos | might make sense to create a dts with everything non essental removed and see if its still unstable | 20:24 |
uvos | beyond that the d3 omap runns mutch older microcode that might have some additional errata fixed later, but this gets really outside of my capabilites | 20:26 |
uvos | havent had a time to look at the dumps but oh and you might have to redo them | 20:27 |
uvos | becasue we forgot to also fix the sgx opp | 20:27 |
uvos | android is mutch more argessive with power manageing the sgx so its probubly in a lower power state | 20:28 |
Wizzup | do you know how to fix the sgx opp? | 20:37 |
Wizzup | 20:28 < uvos> becasue we forgot to also fix the sgx opp | 21:13 |
Wizzup | do we also need to do this before kexec? | 21:13 |
Wizzup | ah now I see the email on the ML | 21:22 |
uvos | no | 21:54 |
Wizzup | uvos: regarding setting it high before kexec? I figured | 21:55 |
Wizzup | still not sure how to set the sgx opp in android for the comparison test though | 21:56 |
Wizzup | regarding rwmem, so I was trying to get the dss regs on mainline on the razr, and I just kept gettinb bus error | 21:56 |
Wizzup | /dev/mem did exist | 21:56 |
Wizzup | it also triggeed a kernel oops every time | 21:56 |
Wizzup | uvos: regarding razr, I also tried some futile things like setting hsync-active to 1, same for vsync-active, didn't help | 22:01 |
Wizzup | so: | 22:03 |
Wizzup | root@devuan-xt912:~# ./rwmem 0x58000000 | 22:03 |
Wizzup | Bus error | 22:03 |
Wizzup | https://bpa.st/2JVA | 22:04 |
Wizzup | it works OK on 6.1 | 22:04 |
Wizzup | not on 6.6.0 | 22:04 |
Wizzup | I guess I will go back to 6.1 on razr for now so I can read the dss regs | 22:06 |
Wizzup | uvos: heh no, so I also get the bus error on 6.1 on razr, but not on the d4 | 22:11 |
Wizzup | facinating | 22:12 |
Wizzup | hm.. | 22:14 |
Wizzup | no, ok | 22:15 |
Wizzup | so the bus error happens when screen is off | 22:15 |
Wizzup | I guess that makes sense | 22:15 |
uvos | not sure about sgx oop in android | 22:32 |
uvos | maybe just load it | 22:32 |
uvos | i think i ran glmark on d4 when doing this for it | 22:33 |
Wizzup | doing it for bionic? | 22:33 |
uvos | no d4 | 22:33 |
Wizzup | and then wher do you read the clock? | 22:33 |
uvos | i was figureing out why mainline sgx was underperforming | 22:33 |
uvos | anyhow on d3 this might be harder | 22:34 |
uvos | since d4 can run android 7, which is still essentally mostly compatable with modern android applications | 22:34 |
uvos | 2.3 is decidedly not | 22:34 |
uvos | so you would have to find something compiled agains the period correct sdk for it to run | 22:35 |
Wizzup | can we just clock it way lower in the dts and see if that is stable? | 22:39 |
Wizzup | I mean honestly I agree with your earlier statement that a more minimal dts with (maybe) a lot of things set to 'safe' would be a good way to test stability | 22:39 |
Wizzup | like maybe even a dts that just doesn't exceed 300Mhz and has some much lower sgx clock even | 22:39 |
uvos | we set the opp low already | 22:45 |
uvos | this dident help | 22:45 |
uvos | so i dont see why doing it in the dts would do anything | 22:46 |
Wizzup | I don't remember doing this, but seems like your memory is better | 22:46 |
uvos | well i did it myself | 22:46 |
uvos | that was like first thing | 22:46 |
Wizzup | on droid3? ok | 22:46 |
uvos | yes | 22:46 |
uvos | anyhow yes minimal dts would be good | 22:46 |
Wizzup | I'm wondering if there is just some things we've missed/forgot, like not setting freq to 1000Mhz before kexec | 22:46 |
uvos | theres not mutch to forget really | 22:47 |
uvos | since its just ctrl-c ctrl-v the bionic | 22:47 |
uvos | the bionic (in difference to d4) dosent seam to care about the opp at boot either it seams | 22:47 |
uvos | since it was apaeranlty always missing | 22:47 |
Wizzup | I mean clearly there is a problem since it is not ctrl-c ctrl-v :D | 22:51 |
Wizzup | I understand it is for the most part | 22:52 |
Wizzup | can't we read the allowed clocks from the kernel for the device, or the devtree for the device? | 22:52 |
Wizzup | for say sgx | 22:52 |
Wizzup | I just feel like maybe we took a shortcut too many or something | 22:53 |
Wizzup | okay, so to recap, I will get 6.6 on it just for the heck of it and because it is easier to then make changes | 22:56 |
Wizzup | does sgx clock show up in cpcap regs? | 22:56 |
Wizzup | or I guess in some regulator like you said | 22:56 |
Wizzup | hrm this xt912 lets me flash 4.1.2 fine but I am having trouble flashing older fw | 23:01 |
Wizzup | uvos: ok so I'm looking at razr dss regs atm because I'm a little frustrated with the d3 stuff (might try again tomorrow), and in leste I can now read the regs, but on android rwmem won't work: | 23:27 |
Wizzup | root@cdma_spyder:/data/maemo # ./rwmem | 23:27 |
Wizzup | FATAL: kernel too old | 23:27 |
Wizzup | Aborted | 23:27 |
Wizzup | I guess maybe busybox devmem can be used | 23:37 |
Wizzup | nope, that gives bus errors even with the screen on | 23:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!