| 01:06.29 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 02:00.01 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@113.117.211.218) |
| 02:04.11 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 02:55.01 | jonwil | http://wiki.maemo.org/Porting/Cellular_Modem |
| 03:06.44 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@113.117.211.218) |
| 03:06.49 | LaoLang_cool | hello |
| 03:06.56 | LaoLang_cool | anyone use fetchmail on maemo? |
| 03:07.21 | LaoLang_cool | I'm looking for maemo's version of fetchmail |
| 03:11.43 | jonwil | I dont think fetchmail has been ported to maemo |
| 03:12.52 | LaoLang_cool | jonwil: oh... |
| 03:13.09 | LaoLang_cool | thanks, I think maybe someone has compiled it for maemo |
| 05:34.56 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 06:44.15 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 06:44.20 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 06:45.24 | *** join/#maemo-ssu arcean (~arcean@aacz106.neoplus.adsl.tpnet.pl) |
| 07:48.08 | *** join/#maemo-ssu arcean (~arcean@aacz106.neoplus.adsl.tpnet.pl) |
| 07:48.49 | *** join/#maemo-ssu nedko (nedko@unaffiliated/nedko) |
| 07:54.03 | *** join/#maemo-ssu arcean (~arcean@aacz106.neoplus.adsl.tpnet.pl) |
| 07:56.55 | sixwheeledbeast | Put a quick stub on the wiki at wmo/porting to navigate between the porting pages easier. Also added some categories. |
| 07:58.30 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:27.36 | *** join/#maemo-ssu NIN101 (~NIN@p5DD29C63.dip0.t-ipconnect.de) |
| 08:33.33 | *** join/#maemo-ssu amizraa4 (~amizraa@gateway/tor-sasl/amizraa) |
| 08:58.49 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 09:00.08 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 09:09.20 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@112.96.172.87) |
| 09:17.03 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 09:17.56 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 09:24.08 | jonwil | hi |
| 09:26.44 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 09:27.23 | sixwheeledbeast | lo |
| 09:28.21 | sixwheeledbeast | jonwil: <<(08:56:55) sixwheeledbeast: Put a quick stub on the wiki at wmo/porting to navigate between the porting pages easier. Also added some categories.>> |
| 09:28.34 | jonwil | ok, great :) |
| 09:30.23 | jonwil | I think the # of packages that will need stuff done to them for the Neo900 is not as big as I thought it would be |
| 09:31.20 | jonwil | The hardest part will be the cellular modem stuff |
| 09:43.27 | freemangordon | jonwil: great job :) |
| 09:54.14 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 10:00.53 | *** join/#maemo-ssu arcean_ (~arcean@aacz106.neoplus.adsl.tpnet.pl) |
| 10:06.23 | sixwheeledbeast | Any objections to new http://wiki.maemo.org/Porting/Cellular_Modem layout can rollback if so? |
| 10:10.49 | jonwil | looks good to me |
| 10:11.49 | sixwheeledbeast | :) it a bit easier to read IMO |
| 10:11.55 | sixwheeledbeast | s/it/it's |
| 10:12.06 | jonwil | yewah |
| 10:12.09 | jonwil | yeh |
| 10:12.12 | jonwil | yeah |
| 10:12.14 | jonwil | :) |
| 10:15.40 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 10:24.29 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 10:27.08 | Pali | freemangordon: look at my patches for ke-recv: https://gitorious.org/community-ssu/pali-ke-recv/commits/master |
| 10:27.39 | Pali | I reverted more commits and implemented multipartition support again and reused your code |
| 10:40.26 | *** part/#maemo-ssu janemba (~101@unaffiliated/janemba) |
| 10:55.27 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@2a01:e35:8788:b500:6017:a141:794f:8b3b) |
| 11:05.57 | *** join/#maemo-ssu piscodig (~discopig@unaffiliated/discopig) |
| 11:07.31 | *** join/#maemo-ssu thedead1440_ (~thedead14@unaffiliated/thedead1440) |
| 11:11.02 | sixwheeledbeast | Pali: I have been told KP fixes the issue where stock maemo bootup causes uSD card to locate at mmc0. Is this correct? |
| 11:11.57 | Pali | order of mmc devices in maemo and also in upstream kernel is random |
| 11:12.18 | Pali | real name is later configured by udev |
| 11:12.43 | Pali | kernel-power has patch which allocate mmc0 only for internal eMMC |
| 11:13.06 | Pali | so when SD card is initializing it will always get num 1 |
| 11:13.59 | sixwheeledbeast | So what would be the "correct" or "best" way to depend on this? |
| 11:14.16 | Pali | but just to note, this is not issue in kernel... kernel assign first available number for first device which ask for it |
| 11:14.50 | Pali | any other policy operations is up to userspace --> udev |
| 11:15.15 | Pali | sixwheeledbeast: so which problem do you have? |
| 11:15.38 | Pali | udev which setting correct mmc number is starting before maemo gui |
| 11:17.31 | sixwheeledbeast | flopswap uses fixed locations for swap spaces 1p2 and 1p3 due to the way it flip-flops in the script. an issue obviously appears without kp installed. |
| 11:18.02 | Pali | and when is flopswap started? before udev? |
| 11:18.09 | Pali | then it should care about numbers! |
| 11:18.11 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 11:19.00 | Pali | and what is flopswap doing? |
| 11:19.31 | sixwheeledbeast | started? it not that clever. |
| 11:21.06 | sixwheeledbeast | scripts that swapon/swapoff partitions. the only thing that started is an option to add upstart script to put swap on 1p2 at start. |
| 11:21.42 | kerio | just use LABEL=foo |
| 11:21.59 | kerio | it's a solved problem |
| 11:22.08 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 11:22.10 | Pali | use blkd for locating swap partitions |
| 11:22.21 | kerio | or, you know, use the LABEL directive |
| 11:22.36 | Pali | cssu-devel generating swaps in /etc/fstab from blkid output |
| 11:22.51 | Pali | and it can be configured to add also swaps from SD card paritions |
| 11:23.27 | Pali | hardcoding any paths is BAD |
| 11:24.08 | Pali | even maemo ke-recv can use MyDocs if eMMC is mmc1 |
| 11:24.30 | sixwheeledbeast | ok i see I will have to look at doing that then. I understand hardcoding it not ideal but I 'm still learning |
| 11:25.33 | Pali | sixwheeledbeast: you should use only swap partitions specified in /etc/fstab |
| 11:25.46 | Pali | swapon/swapoff use them |
| 11:26.30 | FatPhil | DocScrutinizer05: my irc window closed, but I found the meeting proceedings on the website. |
| 11:27.14 | sixwheeledbeast | so i need to modify scripts to get locations from /etc/fstab |
| 11:29.08 | FatPhil | if you want someone local to finland, or a natve english speaker, I can be that person (even though I go back to Estonia soon, it's not a long trip) |
| 11:37.07 | DocScrutinizer05 | ((<jonwil> ... # of packages that will need stuff done...not as big. The hardest part will be the cellular modem stuff)) I'm really happy to see you are 100% in line with my own estimation regarding this :-) \o/ |
| 11:38.12 | DocScrutinizer05 | FatPhil: thanks! much appreciated. |
| 11:49.24 | DocScrutinizer05 | FatPhil: I think we hardly could find anybody better qualified to draft or review such a letter to Nokia, knowing their "mentality", with perfect English, and even a background that helps with some internals that mere mortals are for sure not aware of. If you're willing to help council (+HiFo) to write such a letter/mail to Nokia asking/offering about managing sourcecode of maemo for them, we might actually have a small chance that |
| 11:49.25 | DocScrutinizer05 | this will fly |
| 11:51.05 | DocScrutinizer05 | If otoh you say it's futile effort, we for sure should reconsider that idea |
| 11:54.00 | jonwil | DocScrutinuizer05: The GPS will be the other hard part :) |
| 11:54.15 | jonwil | And a few smaller parts like MCE |
| 11:54.24 | DocScrutinizer05 | yep, exactly |
| 11:55.00 | DocScrutinizer05 | GPS is low prio, MCE is a MUST HAVE |
| 11:56.52 | DocScrutinizer05 | IOW GPS we can make all FOSS apps work, even when switching to completely different API |
| 11:57.21 | DocScrutinizer05 | (though that's not really the idea behind FP) |
| 11:59.25 | jonwil | btw it is my view that we should set the goal of doing things such that we dont need to touch telepathy-ring, rtcom-call-ui or rtcom-messaging-ui at all. |
| 11:59.41 | DocScrutinizer05 | but we can jerry-build sth that kinda works, even with a thin compatibility layer above gypsy |
| 12:00.10 | DocScrutinizer05 | yes, absolutely |
| 12:01.51 | FatPhil | having stuff written down on paper is the best way of knowing what the territory really is. If they reply with contradictions, that leaves room for further approaches. |
| 12:02.12 | DocScrutinizer05 | for modem we could start development on N900 with UMTS-USB-modem attached via H-E-N |
| 12:03.26 | jonwil | for GPS the way to go now that I look at it is to figure out what com.nokia.location.* does and implement that on top of the the new GPS hardware |
| 12:03.45 | DocScrutinizer05 | ...which will not give us proper audio most likely, but we can test everything else - like call setup, answer, hold, end. Data/GPRS |
| 12:03.47 | DocScrutinizer05 | etc |
| 12:04.43 | DocScrutinizer05 | jonwil: please consider using FSO wherever possible |
| 12:05.23 | jonwil | if FSO has a GPS stack, adding support to it to spit out com.nokia.location.* seems like the way to go |
| 12:05.25 | DocScrutinizer05 | jonwil: we have some great support/knowhow regarding FSO in openmoko community ;-) |
| 12:05.48 | DocScrutinizer05 | FSO is using gypsy for GPS |
| 12:05.57 | DocScrutinizer05 | freedesktop.org |
| 12:06.21 | dos1 | but gypsy API is only implemented in python implementation (frameworkd) |
| 12:06.36 | DocScrutinizer05 | ooh? |
| 12:06.40 | DocScrutinizer05 | why that? |
| 12:06.44 | jonwil | btw if by some miracle we CAN get more source code out of Nokia but cant get everything for some reason, I have a wishlist of about 10 packages where having source would be of use and another 10-15 where having docs/info would be of use :) |
| 12:06.51 | DocScrutinizer05 | (not that it matters too much) |
| 12:06.53 | *** join/#maemo-ssu arcean_ (~arcean@aacz106.neoplus.adsl.tpnet.pl) |
| 12:07.00 | dos1 | in cornucopia, there's no dedicated GPS API implemented by FSO |
| 12:07.23 | dos1 | and there's some gpsd integration in fsotdld |
| 12:07.58 | dos1 | DocScrutinizer05: well, I'm not sure. I remember that mickeyl had some reason behind it, but I don't remember what it was |
| 12:08.23 | DocScrutinizer05 | have you "seen" him during the last weeks? |
| 12:09.00 | dos1 | nope |
| 12:09.05 | DocScrutinizer05 | his help would be an *invaluable* benefit to FPTF |
| 12:09.11 | dos1 | I guess direct e-mail would be the only way to contact him right now |
| 12:09.29 | DocScrutinizer05 | will you do or shall I...? |
| 12:09.33 | dos1 | basing on latest post on his blog |
| 12:09.40 | DocScrutinizer05 | *nod* |
| 12:10.24 | DocScrutinizer05 | we at very least should let him know about Neo900, FPTF, and our plans to base that on FSO where possible |
| 12:11.00 | dos1 | DocScrutinizer05: maybe you, I already wasted too much time not learning to exams soon :x |
| 12:11.00 | DocScrutinizer05 | any help from his side highly appreciated |
| 12:11.20 | DocScrutinizer05 | k, another point on my ToDo list |
| 12:11.36 | DocScrutinizer05 | ~seen mickeyl |
| 12:11.41 | infobot | mickeyl <~mickey@openmoko/coreteam/mickey> was last seen on IRC in channel #openmoko-cdevel, 373d 21h 27m 33s ago, saying: 'hi, btw.'. |
| 12:11.53 | DocScrutinizer05 | *cough* |
| 12:12.18 | DocScrutinizer05 | [2013-09-14 14:12:04] [Notice] -NickServ- Last addr : ~mickey@digitaleclipse.org |
| 12:12.20 | DocScrutinizer05 | [2013-09-14 14:12:04] [Notice] -NickServ- Last seen : Jun 26 20:35:58 2013 (11 weeks, 2 days, 15:36:06 ago) |
| 12:12.52 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 12:52.24 | *** part/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
| 12:59.42 | freemangordon | Pali: so, now the partition exported through mass storage in case there is swap is /dev/mmcblk1k1, always? |
| 13:00.02 | Pali | now yes |
| 13:00.04 | freemangordon | mmcblk1p1 |
| 13:00.28 | freemangordon | what if this is the swap partition? |
| 13:00.52 | Pali | any non deterministic behaviour should be removed now |
| 13:01.00 | Pali | then exporting fail |
| 13:01.11 | Pali | this needs to be fixed... |
| 13:02.16 | freemangordon | Pali: I still think we should export first vfat. And that this is not hard to be implemented in a deterministic way |
| 13:02.45 | freemangordon | also we should mount the first vfat under /media/mmc1 |
| 13:02.58 | Pali | you do not know if HAL reported all partitions when you enabled mass storage mode |
| 13:03.19 | freemangordon | so? we have them in /dev/ |
| 13:03.34 | Pali | but you can expect that user will enable mass storage mode when HAL report all partitions |
| 13:03.50 | Pali | yes, we have them in /dev/ but not in internal ke-recv structures |
| 13:04.01 | freemangordon | we can enumerate /dev/mmcblk1pN, get the partition fs and make the decision |
| 13:04.57 | freemangordon | we don;t need HAL, after all we unmount at that moment |
| 13:05.09 | freemangordon | or better said "going to unmount" |
| 13:05.25 | Pali | and what happens when you reformat some ext partition to fat which was before first fat? |
| 13:05.47 | freemangordon | Pali: it will become /media/mmc1 |
| 13:05.49 | Pali | same problem as before, tracker will se new path and database will be broken |
| 13:06.36 | Pali | and if there is bug in ke-recv/HAL which enumerate partitions and inserting them into ke-recv structures, users will have this problem... |
| 13:06.50 | Pali | see report on TMO where user reported this problem |
| 13:07.23 | freemangordon | Pali: I think this is a better solution. Imagine what will happen if you have p1 and p2 as swap. I know it is pretty unusual, but still |
| 13:07.30 | Pali | ke-recv has (or had) bug in code which adding/removing partitions in structures which cause that his partition swap between mmc1 and mmc1p1 |
| 13:07.47 | freemangordon | lets fix it then (the bug) |
| 13:08.03 | freemangordon | what you're going to export is p1 and p2 are swap? |
| 13:08.10 | freemangordon | s/is/if/ |
| 13:08.18 | Pali | fixing this bug means: 1. removing ke-recv or 2. rewirting it |
| 13:09.06 | Pali | or 3. make sure that any future bugs which depends on non determinisic behaviour will not be triggered |
| 13:09.26 | freemangordon | I think this is what I propose :) |
| 13:10.03 | Pali | means that ke-recv must be deterministic in way how to choose partition for /media/mmc1 and partition for exporting via USB |
| 13:10.32 | Pali | and this means that this partition should be hardcoded |
| 13:10.39 | Pali | we can add new option to some config file and user can change first partition to any |
| 13:10.44 | jonwil | so bored :( |
| 13:11.30 | freemangordon | Pali: if you want once a vfat partition is mounted as /media/mmc1 the same to always be mounted there, I think we can just store either volume id or some unique id and use it next time |
| 13:12.01 | Pali | this will be broken after user format partition |
| 13:12.13 | Pali | both windows and mkfs genereting new volume uuid |
| 13:12.28 | freemangordon | but we don;t care if that happens, as it is not the *same* partition anymore |
| 13:12.47 | Pali | rather use partition number and not uuid |
| 13:12.58 | Pali | and we can use partition number from some gconf key |
| 13:13.00 | freemangordon | should work too |
| 13:13.04 | freemangordon | exactly |
| 13:13.15 | freemangordon | gconf is what I had on my mind |
| 13:13.23 | Pali | by default it could be first partition |
| 13:13.29 | freemangordon | so: |
| 13:13.41 | freemangordon | 1. a new uSD is inserted |
| 13:14.02 | freemangordon | 2. enumerate /dev/mmcblk1pN to find the first vfat |
| 13:14.30 | freemangordon | 3. store uSD id and N in some gconf key |
| 13:14.56 | freemangordon | 4. use that from now on to mount under /media/mmc1 and to export (if there is a swap) |
| 13:15.17 | freemangordon | there should be a change in p.1. if uSD had changed |
| 13:15.31 | freemangordon | s/change/verification/ |
| 13:16.10 | Pali | uSD id is problematic and enumerating partitions in ke-recv is not easy, because ke-recv working in async mode - this is reason why using hal/dbus |
| 13:16.12 | freemangordon | also a check in p4 if partition type has change, if yes goto 1 |
| 13:16.31 | freemangordon | Pali: we can use libblkid or directly go to shell |
| 13:17.03 | Pali | I do not want to patch ke-recv to mix sync/async calls more --> we will have other problems... |
| 13:17.27 | freemangordon | Pali: all this can be done in a shell script |
| 13:17.31 | Pali | now it is problematic with mount commands, and we can be happy that ke-revc working... |
| 13:18.00 | freemangordon | (deterministic first vfat detection) |
| 13:18.37 | Pali | partitions are mounted by ke-recv immetiately when they appear |
| 13:18.51 | Pali | and partitions are reported in random order by HAL |
| 13:19.08 | Pali | this is problem |
| 13:19.13 | Pali | HAL working in async mode |
| 13:19.27 | Pali | and for all above to work we need sync function for enumeration |
| 13:19.58 | freemangordon | so? we can call get_first_vfat() everytime ke-recv tries to mount a partition and if get_first_vfat() == current+partition, mount it under /media/mmc1 |
| 13:20.01 | Pali | and there could be problems, that we miss some HAL info about partitions... |
| 13:20.15 | freemangordon | current_partition |
| 13:21.30 | Pali | and if you have some non vfat partitions before vfat and you format non vfat to vfat, then first vfat will change |
| 13:21.53 | Pali | and this cause tracker problems |
| 13:22.05 | freemangordon | I know, but that will happen *after* we did a first time mount, so we'll have it stored in gconf key |
| 13:22.48 | Pali | and I do not trust any uSD ids... |
| 13:23.15 | Pali | really one simple gconf key which will be by default 1 |
| 13:23.42 | freemangordon | Pali: we should take care of uSD changed |
| 13:24.16 | Pali | and are you sure that some ids reported by hal/kernel will work? |
| 13:24.26 | freemangordon | they should work |
| 13:24.27 | Pali | I bet that there will be problems... |
| 13:24.54 | *** join/#maemo-ssu arcean__ (~arcean@aacu151.neoplus.adsl.tpnet.pl) |
| 13:25.22 | freemangordon | mmc.cid = '1b534d30303030301079af83c700cb63' (string) |
| 13:25.22 | freemangordon | mmc.csd = '400e00325b590001d47a7f800a404079' (string) |
| 13:25.32 | freemangordon | whatever is that :) |
| 13:25.46 | freemangordon | oh, mmc.serial = 2041545671 (0x79af83c7) (int) |
| 13:26.18 | freemangordon | Pali: https://www.kernel.org/doc/Documentation/mmc/mmc-dev-attrs.txt |
| 13:27.09 | freemangordon | Pali: iiuc mmc.cid is what we want to use |
| 13:28.35 | freemangordon | Pali: or some part of it, maybe manfid, date and serial |
| 13:30.00 | freemangordon | we can just keep card specific info in gconf tree, I bet noone will put 100 uSD cards in his n900 |
| 13:30.22 | freemangordon | his/her |
| 13:30.49 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 13:32.54 | freemangordon | so: 1. a card is put |
| 13:34.40 | freemangordon | 2. ke-recv receives "new partition added" and calls get_first_vfaf(), gfv() checks if the card is already in gconf, if it is, it verifies if the "first_vfat" from gconf is still vfat. if it is, it returns it. if not, it enumerates /dev/mmcblk1pN to find the first vfat |
| 13:35.02 | freemangordon | if the card is not in gconf, gfv() enumerates |
| 13:35.52 | freemangordon | 3. ke-recv checks if the current_partition is the one returned from gfv(), if ye, it updates gconf and mounts it under /media/mmc1 |
| 13:36.04 | freemangordon | Pali: I think ^^^ will work just fine |
| 13:36.55 | Pali | I will implement something to my new ke-recv git tree |
| 13:37.10 | freemangordon | Pali: like the above? |
| 13:37.32 | Pali | will see if there are some problems... |
| 13:37.40 | Pali | but I will try something as above |
| 13:38.24 | freemangordon | Pali: ooh, and if there is *no* vfat, I don;t think anything should be mounted under /media/mmc1 |
| 13:38.31 | freemangordon | Pali: ok, nice :) |
| 13:38.55 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 13:40.21 | freemangordon | Pali: just to make it clear - I insist on that "vfat" because there are lots of windows users. most of them are clueless enough to don;t know what to do if we hardcode /media/mmc1->/dev/mmcblk1p1 and they already have uSD partitioned in some incompatible way |
| 13:41.21 | Pali | if they have partition in other way, they probably know what to do... |
| 13:41.48 | freemangordon | even if they know, thay'll have to reformat the card |
| 13:42.01 | freemangordon | imagine a 6gGB card full with data ;) |
| 13:42.07 | freemangordon | 64GB that is |
| 13:43.30 | freemangordon | one have to copy that date to their desktop, format the card with a partition layout that makes us happy and copy the data back |
| 13:43.37 | freemangordon | I don;t think this is fare :) |
| 13:44.03 | freemangordon | data even, not date |
| 13:45.20 | freemangordon | Pali: btw is that kernel camera drivers guy helpful? |
| 13:46.01 | Pali | freemangordon: last week I got email from him, and some months ago he sent me that board data for front webcam |
| 13:46.07 | freemangordon | ok |
| 13:46.24 | freemangordon | lets hope he'll answer me :) |
| 13:48.36 | freemangordon | Pali: one more thing and I'll stop pestering you - which is the next thing in kernel you think I should try to fix, while wating for sakari to answer? |
| 13:48.53 | freemangordon | modem drivers? |
| 13:49.08 | freemangordon | (I remember those working in 3.5) |
| 13:49.19 | Pali | yes, look at modem drivers why not working with maemo5 |
| 13:49.23 | freemangordon | ok |
| 13:49.26 | Pali | and why rtcom-call-ui crashing |
| 13:49.59 | freemangordon | oh, bwt hulda tries to use some /sys/kernel/low/high_watermark, WTF is this? |
| 13:50.13 | freemangordon | hmm, goping to as google |
| 13:50.13 | Pali | special nokia sysfs |
| 13:50.30 | Pali | patch hulda to not fail if that sysfs file not exists |
| 13:50.58 | freemangordon | I don;t think it fails, it just spits some warning in syslog. but I'll look in the code anyway |
| 13:51.18 | ShadowJK | it's lowmem stuff |
| 13:51.39 | ShadowJK | to get advance warning of running out of memory, before things slow down |
| 13:51.44 | Pali | I already patches rcS-late to not fail if that file does not exists |
| 13:51.55 | Pali | and this was reason why maemo not booted on 3.x kernels |
| 13:52.57 | ShadowJK | iirc google also used this stuff in android at some point |
| 13:53.45 | freemangordon | maybe we should forward port it |
| 13:54.03 | freemangordon | I don;t think it is that complicated |
| 13:54.22 | freemangordon | will look at it when everything else works :D |
| 14:11.05 | *** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 14:23.14 | *** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 14:25.46 | jonwil | wishes there was something he could usefully do :( |
| 14:45.46 | DocScrutinizer05 | jonwil: why don't you help on reviewing and sanitizing ke-recv specifications? |
| 14:46.04 | jonwil | I dont know the first thing about ke-recv |
| 14:46.09 | *** join/#maemo-ssu oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 14:46.28 | DocScrutinizer05 | when you read backscroll you'll notice it has a whole lot of very intriguing implications |
| 14:46.54 | DocScrutinizer05 | even with tracker *COUGH* |
| 14:51.55 | jonwil | besides, pouring over source code to ke-recv sounds like the sort of thing that would make me MORE bored |
| 14:59.59 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 15:12.38 | *** join/#maemo-ssu sunny_s (~sunny_s@178.124.152.19) |
| 15:12.48 | jonwil | btw doc, I suspect the FPTF is gonna need someone who knows PulseAudio and probably someone who knows telepathy |
| 15:19.10 | *** join/#maemo-ssu oldtopman (~oldtopman@75-166-150-132.hlrn.qwest.net) |
| 15:19.13 | *** join/#maemo-ssu oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 15:26.04 | nedko | i'm trying to setup a cross-compilation environment for n900. is still scratchbox the proper/best way? |
| 15:27.29 | Sicelo | yes sir :P |
| 15:28.01 | nedko | thanks |
| 15:32.31 | nedko | how good is to use the maemo sdk virtual image? |
| 15:32.56 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 15:34.00 | nedko | i guess i could install a virtual debian system and then install scratchbox |
| 15:35.38 | freemangordon | nedko: VMWare image is what i use |
| 15:36.57 | nedko | freemangordon: i'm a bit worried that the version is from 2009 but the latest sdk is from 2010... |
| 15:37.50 | freemangordon | it is ok, just fix your DEB_BUILD_OPTIONS |
| 15:38.32 | nedko | freemangordon: is there an online resource on how to do this? |
| 15:38.46 | freemangordon | do what? |
| 15:39.01 | nedko | fix your DEB_BUILD_OPTIONS |
| 15:39.34 | freemangordon | export DEB_BUILD_OPTIONS=$OPTIONS, the default on contains thumb |
| 15:39.43 | freemangordon | *one |
| 15:41.51 | nedko | freemangordon: do you use image from tablets-dev.nokia.com or from maemovmware.garage.maemo.org ? |
| 15:42.29 | freemangordon | I downloaded it 2-3 ears ago, so I don;t know what I use :) |
| 15:42.31 | nedko | hmm, maybe they are the same |
| 15:42.36 | freemangordon | *years |
| 15:42.41 | freemangordon | most probably |
| 15:44.59 | nedko | my main problem is that i use gentoo and virtualbox :] |
| 15:45.49 | jonwil | if you use Gentoo, why not just install Scratchbox for N900 development? |
| 15:45.55 | jonwil | I have a Gentoo box and I did exactly that |
| 15:47.58 | nedko | jonwil: how to install scratchbox for n900 development on gentoo? |
| 15:48.18 | nedko | i see there is dev-embedded/scratchbox |
| 15:48.26 | nedko | it has no use flags |
| 15:48.39 | nedko | and i see no packages matching "n900" search pattern |
| 15:49.42 | nedko | or maybe i should use scratchbox2? |
| 15:51.41 | jonwil | I downloaded the SDK from this page http://developer.nokia.com/info/sw.nokia.com/id/c05693a1-265c-4c7f-a389-fc227db4c465/Maemo_5_SDK.html and installed it that way (including Scratchbox) |
| 15:51.59 | jonwil | i.e. I installed the Scratchbox Nokia suggested and ignored anything from the Gentoo repos |
| 15:55.11 | nedko | jonwil: you used the two scripts and they worked ok on gentoo? |
| 15:55.34 | jonwil | Not sure which script I used |
| 15:55.42 | jonwil | but yes I used the Nokia installer and it worked on Gentoo |
| 15:56.05 | jonwil | my Gentoo box is not 100% functional right now otherwise I would check more |
| 15:56.15 | nedko | ok, thanks |
| 16:05.50 | Sicelo | is going to join the scratchbox banddwagon soon.. |
| 16:05.58 | Sicelo | how big is the vmware image btw? |
| 16:08.02 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 16:12.45 | nedko | the one i'm downloading is 1457450621 bytes |
| 16:13.06 | nedko | they provide no digital signatures for the files :( |
| 16:13.33 | nedko | the only way to check are md5 checksums |
| 16:15.23 | *** join/#maemo-ssu arcean__ (~arcean@aacu151.neoplus.adsl.tpnet.pl) |
| 16:27.32 | *** join/#maemo-ssu tg (~x@unaffiliated/tg) |
| 16:28.47 | DocScrutinizer05 | nedko: huh? |
| 16:29.04 | DocScrutinizer05 | what's wrong with md5? |
| 16:31.15 | nedko | DocScrutinizer05: it doesnt protect you from compromised servers |
| 16:31.24 | nedko | man in the middle attacks too |
| 16:31.41 | DocScrutinizer05 | ohmy |
| 16:32.08 | DocScrutinizer05 | when our server gets compromised, they as well can steal our private signing key |
| 16:32.47 | DocScrutinizer05 | MITM attacks you hardly can counteract at all |
| 16:33.28 | nedko | DocScrutinizer05: you put your private keys on a server? |
| 16:34.13 | nedko | the one for SSL certificate (for https) is ok, obviously |
| 16:34.28 | nedko | i actually downloaded the file from a host in buglaria |
| 16:34.38 | nedko | i bet it is a local mirror of nokia |
| 16:36.16 | nedko | or probably a CDN is a better term here |
| 16:36.39 | DocScrutinizer05 | nedko: when those are private maemo.org keys, what do you think where we should store them? |
| 16:37.22 | nedko | depends on what you use them for, no? |
| 16:37.55 | DocScrutinizer05 | in MrFlop's bedside locker? |
| 16:38.30 | nedko | the two scripts for installing the SDK require root |
| 16:38.54 | DocScrutinizer05 | so what? I can't help that |
| 16:38.54 | nedko | don't you think it is a good idea to have them at least somewhat verified before executing code as root |
| 16:39.43 | nedko | or it is expected that people should use a dedicated machine for maemo development |
| 16:39.55 | DocScrutinizer05 | don't you think, since they are scripts anyway, that it should be *YOU* to verify them, on sourcecode level? |
| 16:40.14 | DocScrutinizer05 | or would you trust *me* to do that for you? |
| 16:40.23 | nedko | DocScrutinizer05: yup, this is the good side. they are scripts |
| 16:40.50 | DocScrutinizer05 | I can signe those files with my private key, no problem |
| 16:41.00 | DocScrutinizer05 | but that doesn't mean a thing |
| 16:41.05 | nedko | if i trust you... |
| 16:41.34 | nedko | and my trust on you may be different that trust on someone controlling the internet access in my country |
| 16:41.57 | freemangordon | DocScrutinizer05: what is GAZOO and what is RAPUYAMA? |
| 16:42.00 | DocScrutinizer05 | honestly, I don't see how techstaff can help |
| 16:42.40 | DocScrutinizer05 | freemangordon: RAPU = BB5 baseband, GAZOO = companion chip with power, maybe RF amp |
| 16:42.55 | freemangordon | thanks |
| 16:42.58 | DocScrutinizer05 | yw |
| 16:43.14 | nedko | DocScrutinizer05: you are from nokia techstaff? |
| 16:43.20 | DocScrutinizer05 | no |
| 16:43.42 | nedko | :) |
| 16:44.00 | DocScrutinizer05 | nedko: if you maybe haven't noticed yet: maemo.org is a community driven project since start of this year |
| 16:44.16 | DocScrutinizer05 | no NOKIA techstaff around at all |
| 16:45.08 | nedko | DocScrutinizer05: yes, i noticed |
| 16:45.16 | DocScrutinizer05 | so yes, i'm from techstaff, and NO I'm NOt NOKIA |
| 16:45.44 | nedko | i just complained that i have almost no mean to verify nokia maemo sdk vmware image |
| 16:46.22 | DocScrutinizer05 | verify against what? what is your damn reference to verify it against? |
| 16:46.59 | nedko | DocScrutinizer05: in a corporate world, i'd expect the MD5SUM file to be available via https |
| 16:47.00 | DocScrutinizer05 | for all I could tell it may contain malware since 5 years |
| 16:47.06 | nedko | with proper certificate |
| 16:47.26 | nedko | ssl certificate |
| 16:47.32 | DocScrutinizer05 | *shrug* |
| 16:48.05 | nedko | if it was open source, i'd expect someone from upstream to sign the releases with a private key stored on his own machine, not a server |
| 16:48.13 | DocScrutinizer05 | we CANNOT get a proper SSL cert since maemo.org domain (DNS) still owned by NOKIA |
| 16:48.13 | nedko | this is what i do when i act as a upstream |
| 16:48.39 | DocScrutinizer05 | and i'm not your dang upstream |
| 16:48.44 | nedko | DocScrutinizer05: i'm not telling that it is your fault |
| 16:48.52 | DocScrutinizer05 | YOU are upsteam! |
| 16:49.00 | DocScrutinizer05 | +r |
| 16:50.01 | nedko | shuts up, there is no point |
| 16:50.30 | DocScrutinizer05 | indeed |
| 16:50.41 | DocScrutinizer05 | there's zilch I could do for you |
| 16:51.47 | DocScrutinizer05 | I can quote the md5sum out of band in this IRC channel, if that helps |
| 16:52.06 | DocScrutinizer05 | directly off the commandline on server |
| 16:52.06 | nedko | btw, it is nokia.com i'm talking about |
| 16:52.21 | DocScrutinizer05 | prolly not really |
| 16:52.58 | nedko | the MD5SUM file is available from tablets-dev.nokia.com |
| 16:53.24 | DocScrutinizer05 | which is a CDS to maemo.org/tabletsdev |
| 16:53.36 | freemangordon | FatPhil: ping |
| 16:53.54 | DocScrutinizer05 | ~tabletsdev |
| 16:53.54 | infobot | http://tablets-dev.nokia.com/ http://wiki.maemo.org/Tabletsdev , http://skeiron.org/tablets-dev/ or http://tabletsdev.maemo.org |
| 16:55.36 | DocScrutinizer05 | you're free to compare all 4 information sources to verify that you indeed got that opaque blob that Nokia donated to community. Nobody will give any warranty for its content though, except that it been unchanged since years |
| 16:56.44 | nedko | now this is useful, thank you |
| 16:56.55 | DocScrutinizer05 | yw |
| 16:57.20 | nedko | http://tabletsdev.maemo.org/ sdk link points to nokia site... |
| 16:57.45 | DocScrutinizer05 | then edit the URL |
| 16:57.59 | DocScrutinizer05 | it's stage for http://tablets-dev.nokia.com/ |
| 16:58.15 | DocScrutinizer05 | of course the links point to http://tablets-dev.nokia.com/ |
| 16:58.33 | DocScrutinizer05 | CDS, remember? |
| 16:58.48 | nedko | i admit i dont really know what CDS is |
| 16:59.01 | DocScrutinizer05 | Content Distribution System |
| 16:59.10 | DocScrutinizer05 | a server farm of proxies basically |
| 16:59.42 | DocScrutinizer05 | http://tablets-dev.nokia.com/ are slaves, http://tabletsdev.maemo.org is master aka stage |
| 16:59.48 | nedko | so how i could at least check that the MD5SUM i downloaded from the bulgarian server is same as the one you use? |
| 16:59.59 | nedko | s/use/will get if you try to download it/ |
| 17:00.29 | DocScrutinizer05 | get it from http://tabletsdev.maemo.org |
| 17:00.51 | DocScrutinizer05 | the URL on http://tabletsdev.maemo.org is identical to that on http://tablets-dev.nokia.com/ |
| 17:01.03 | DocScrutinizer05 | just edit it, to access the master |
| 17:01.31 | nedko | edit what? |
| 17:01.35 | nedko | the url? |
| 17:01.40 | freemangordon | url in your browser |
| 17:01.47 | freemangordon | or wget or whatever you use |
| 17:02.04 | freemangordon | thean download the sdk |
| 17:02.27 | freemangordon | BTW I am nor sure #maemo-ssu is the channel to discuss SDK stuff on |
| 17:02.28 | nedko | i got redirect to tablets-dev.nokia.com |
| 17:02.43 | nedko | freemangordon: what is a better channel for this? |
| 17:02.45 | freemangordon | then replace that with tabletsdev.maemo.org |
| 17:02.56 | freemangordon | try on #maemo |
| 17:02.59 | DocScrutinizer05 | s|http://tablets-dev.nokia.com/|http://tabletsdev.maemo.org| |
| 17:03.09 | nedko | http://tabletsdev.maemo.org/maemo-dev-env-downloads.php |
| 17:03.18 | nedko | click accept and you get to http://tablets-dev.nokia.com |
| 17:03.32 | nedko | freemangordon: thank you |
| 17:03.34 | nedko | shuts up |
| 17:03.46 | DocScrutinizer05 | ~skeiron |
| 17:03.47 | infobot | from memory, skeiron is the semi-official backup and emergency standin for all internet borne maemo resources: http://skeiron.org/tablets-dev/ http://talk.maemo.org/showthread.php?p=1315143#post1315143, or see: ~tabletsdev |
| 17:16.44 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:26.32 | freemangordon | DocScrutinizer05: hmm, need a little help with that cmt shit. by looking at the schematics, gpio 72 seems to be input to omap (APE_RST_RQ). But I have gpio 72 as .cmt_rst_ind_gpio = 72 in board data. this makes no sense |
| 17:27.18 | DocScrutinizer05 | both are RST at least :-) |
| 17:27.26 | freemangordon | :) |
| 17:27.27 | freemangordon | yeah |
| 17:27.35 | DocScrutinizer05 | dunno if cmt resets APE or APE resets cmt ;-D |
| 17:27.50 | freemangordon | wtf is APE? |
| 17:27.51 | DocScrutinizer05 | or both? :-o |
| 17:28.02 | DocScrutinizer05 | App Proc Env |
| 17:28.20 | DocScrutinizer05 | == linux |
| 17:28.29 | DocScrutinizer05 | == SoC OMAP3430 |
| 17:28.29 | freemangordon | hmm, but this is input to omap (gpio 72) |
| 17:28.36 | freemangordon | yeah, got it |
| 17:28.49 | freemangordon | so, modem resets omap? |
| 17:28.54 | freemangordon | weird |
| 17:29.00 | DocScrutinizer05 | possibly. One of the WD |
| 17:29.18 | DocScrutinizer05 | makes a lot of sense to me |
| 17:29.54 | freemangordon | hmm, yeah |
| 17:30.13 | DocScrutinizer05 | either it's one of our 2 or 3 generic WD, or a special one that only kicks in during 2orphaned" phonecalls |
| 17:30.48 | DocScrutinizer05 | you wouldn't want the modem to continue a call ad infinitum while APE locked up, eh? |
| 17:31.14 | freemangordon | hmm, but this is just a gpio |
| 17:31.55 | DocScrutinizer05 | check OMAP34xx TRM aka spruf98 for exact meaning/semantics/function of APE_RST_RQ |
| 17:32.22 | DocScrutinizer05 | *each* GPIO has at least a 2nd function, often a 3rd and 4th |
| 17:32.25 | freemangordon | ok |
| 17:32.44 | DocScrutinizer05 | you define that via IO-mux or whatever it's called |
| 17:33.00 | freemangordon | ok, this is fine then |
| 17:33.45 | DocScrutinizer05 | actually it's rather the other way round: each function pin can also get used as GPIO when you don't need the function |
| 17:34.21 | DocScrutinizer05 | except a very few ones like VDD, GND ;-) and maybe CLK etc |
| 17:35.17 | DocScrutinizer05 | and most of GPIO can also create an IRQ |
| 17:35.29 | DocScrutinizer05 | well, several |
| 17:35.38 | DocScrutinizer05 | dunno if "most of" |
| 17:35.51 | DocScrutinizer05 | SPRUF98 |
| 17:36.05 | DocScrutinizer05 | page 164258 |
| 17:36.18 | DocScrutinizer05 | ;-) |
| 17:36.48 | freemangordon | hmm, iirc every gpio can act as irq too |
| 17:36.53 | DocScrutinizer05 | maybe reading service manual L3_4 helps! |
| 17:37.21 | DocScrutinizer05 | they have _some_ nice high level function descriptions in there |
| 17:37.45 | freemangordon | yeah |
| 17:37.56 | DocScrutinizer05 | strongly recommended read |
| 17:42.42 | DocScrutinizer05 | N900_RX-51_SM_L3_4.pdf page 165 |
| 17:43.54 | DocScrutinizer05 | p180 "Cellular RF Block Diagram" |
| 17:44.01 | freemangordon | yeah |
| 17:44.32 | DocScrutinizer05 | actually not that enlightening |
| 17:45.55 | freemangordon | a black box |
| 17:45.57 | freemangordon | :) |
| 17:48.21 | freemangordon | hmm, cawake gpio control seems fine |
| 17:50.25 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 17:51.42 | DocScrutinizer05 | freemangordon: ok, forget about L3_4, it has nothing interesting. Just ask me instead ;-) |
| 17:52.18 | freemangordon | ok :) |
| 17:53.59 | DocScrutinizer05 | watch the funny stuff around BSI they done to RAPU |
| 17:54.03 | DocScrutinizer05 | (p 11) |
| 17:55.39 | DocScrutinizer05 | you evidently can signal special modes (TEST[!!] Battery) directly to BB5 RAPU, via BSI |
| 17:56.00 | DocScrutinizer05 | shutting down BME won't change any of that |
| 17:56.31 | Pali | DocScrutinizer05: it is possible to (re)charge RTC battery in n900? |
| 17:56.51 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:56.58 | freemangordon | hmm. maybe replacing the battery with a diagnostic tool is the way used to test bb5 |
| 17:59.10 | DocScrutinizer05 | Pali: it recharges automatically |
| 17:59.23 | DocScrutinizer05 | freemangordon: exactly |
| 17:59.49 | Pali | DocScrutinizer05: without BME? |
| 17:59.59 | freemangordon | Pali: yes |
| 18:00.00 | DocScrutinizer05 | yes |
| 18:00.10 | freemangordon | nolo sets the charging |
| 18:00.20 | DocScrutinizer05 | built-in function of TWL4030 |
| 18:00.33 | Pali | ok, so then my rtc battery is emtpy or dead... |
| 18:00.38 | DocScrutinizer05 | needs one or two bits set in one of the twl4030 registers |
| 18:00.47 | freemangordon | as is mine and all the others :D |
| 18:00.52 | DocScrutinizer05 | :-P |
| 18:01.01 | DocScrutinizer05 | ~bupbat |
| 18:01.02 | infobot | somebody said bupbat was use the capacitive type, LiIon are breaking during 12 months, or http://www.digikey.de/product-detail/de/PAS414HR-VG1/587-2157-1-ND/1959153, or https://hbe-shop.de/KONDENSATOR006F-33V-STAKED-COIN, or http://talk.maemo.org/showthread.php?t=90864 |
| 18:01.10 | freemangordon | DocScrutinizer05: yeap, charge current and enable |
| 18:05.08 | DocScrutinizer05 | Pali: http://talk.maemo.org/showthread.php?t=90864 |
| 18:05.20 | Pali | already reading |
| 18:06.52 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 18:10.52 | DocScrutinizer05 | ooh, it was already in infobot's factoid |
| 18:11.16 | DocScrutinizer05 | feels silly for searching 10min for an URL that's been in front of his nose |
| 18:12.42 | DocScrutinizer05 | Pali: you noticed ~zapman ? :-) |
| 18:12.54 | DocScrutinizer05 | zapman zaps fapman |
| 18:14.45 | DocScrutinizer05 | ~zapman usb |
| 18:14.45 | infobot | http://www.google.de/search?q=site%3Amaemo.org%2Fdownloads%2Fproduct%2Fmaemo5+usb |
| 18:15.58 | DocScrutinizer05 | OOOOH! Mobile HotSpot V0.3.4 is from Eero/Rambo! |
| 18:16.27 | freemangordon | DocScrutinizer05: hmm, can;t find gpio 157 on the schematic :( |
| 18:16.43 | DocScrutinizer05 | mompls |
| 18:16.47 | freemangordon | that one is defined as CMT_BSI |
| 18:16.53 | freemangordon | in board data |
| 18:17.25 | DocScrutinizer05 | yeah |
| 18:17.29 | DocScrutinizer05 | better ddat |
| 18:17.34 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 18:17.41 | DocScrutinizer05 | err nope |
| 18:17.58 | DocScrutinizer05 | where from you got GPIO_157? |
| 18:18.10 | freemangordon | #define RX51_GPIO_CMT_BSI157 |
| 18:18.15 | freemangordon | #define RX51_GPIO_CMT_BSI 157 |
| 18:18.16 | DocScrutinizer05 | SIGH |
| 18:18.31 | DocScrutinizer05 | fools |
| 18:18.43 | freemangordon | DocScrutinizer05: I am verifying gpio defs in board data for validity |
| 18:18.49 | DocScrutinizer05 | it's probably some AD_IN4 or whatever |
| 18:19.01 | freemangordon | omg |
| 18:19.20 | freemangordon | .name= "cmt_bsi", |
| 18:19.22 | freemangordon | .gpio= RX51_GPIO_CMT_BSI, |
| 18:19.24 | freemangordon | .flags= OMAP_GPIO_SWITCH_FLAG_OUTPUT, |
| 18:19.26 | freemangordon | .type= OMAP_GPIO_SWITCH_TYPE_ACTIVITY, |
| 18:19.28 | freemangordon | .debounce_rising= RX51_GPIO_DEBOUNCE_TIMEOUT, |
| 18:19.30 | freemangordon | .debounce_falling= RX51_GPIO_DEBOUNCE_TIMEOUT, |
| 18:19.46 | DocScrutinizer05 | you need to: get spruf98, find GPIO157, check for 2nd function, search for $SECONDFUNCTION in schematics |
| 18:19.55 | freemangordon | ok |
| 18:20.08 | DocScrutinizer05 | or get the pin coords (H21 or sth) and search for those |
| 18:21.39 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 18:22.37 | DocScrutinizer05 | try ADCIN4 |
| 18:22.41 | freemangordon | cam_global_reset?!? |
| 18:22.57 | DocScrutinizer05 | ooh wait |
| 18:24.54 | DocScrutinizer05 | hmm, no clue. would actually like to hear which pin number you find for GPIO_157 |
| 18:25.24 | freemangordon | I find nothing but that define in board data |
| 18:25.50 | DocScrutinizer05 | you need to check SPRUF98 |
| 18:25.59 | DocScrutinizer05 | search GPIO 157 |
| 18:26.06 | freemangordon | sec |
| 18:26.13 | DocScrutinizer05 | read the pin ID (AF21) |
| 18:26.41 | DocScrutinizer05 | s/ID/number/ |
| 18:27.15 | freemangordon | hmm, lost it, need to find it again |
| 18:27.37 | DocScrutinizer05 | since it seems the pin number is the only label that *every* SoC pin got, in schematics |
| 18:28.07 | freemangordon | see on page 779 |
| 18:28.11 | freemangordon | in trm |
| 18:28.19 | DocScrutinizer05 | I don't have spruf98 opened |
| 18:28.36 | freemangordon | Table 7-4. Core Control Module Pad Configuration Register Fields (continued) |
| 18:28.45 | DocScrutinizer05 | yep |
| 18:28.47 | DocScrutinizer05 | that one |
| 18:28.49 | freemangordon | CONTROL_PADCONF_MCBSP1_CLKR[31:16] 0x4800 218C mcbsp1_fsr adpllv2d_dither cam_global_ gpio_157 safe_mode |
| 18:29.13 | freemangordon | in node4 this is gpio 157 |
| 18:29.17 | freemangordon | *mode4 |
| 18:29.25 | DocScrutinizer05 | yeahyeah |
| 18:30.08 | DocScrutinizer05 | and other modes seem mcbsp1_fsr adpllv2d_dither |
| 18:30.21 | freemangordon | yep |
| 18:30.57 | freemangordon | adpllv2d_dithering_en1 |
| 18:31.08 | DocScrutinizer05 | i'd rather like to learn the pin number ;-) |
| 18:31.13 | freemangordon | me too :) |
| 18:31.39 | DocScrutinizer05 | MCBSP1_CLKR ? |
| 18:31.54 | DocScrutinizer05 | Y21? |
| 18:32.26 | DocScrutinizer05 | makes no sense |
| 18:32.26 | freemangordon | no, this is gpio 156 |
| 18:32.42 | freemangordon | mcbsp1_fsr is gpio 157 |
| 18:32.47 | freemangordon | you mean the define? |
| 18:33.06 | DocScrutinizer05 | yep |
| 18:33.13 | freemangordon | I know, that is why I asked :) |
| 18:33.30 | freemangordon | hmm, going to check in meego kernel |
| 18:34.04 | DocScrutinizer05 | there's mcbsp1_fsx |
| 18:34.09 | DocScrutinizer05 | but no mcbsp1_fsr |
| 18:34.41 | DocScrutinizer05 | and there's MCBSP1_CLKR[ |
| 18:34.45 | DocScrutinizer05 | -[ |
| 18:35.07 | DocScrutinizer05 | which is pin Y21 |
| 18:35.34 | DocScrutinizer05 | search SPRUF98 for Y21 |
| 18:35.57 | freemangordon | ok |
| 18:36.25 | DocScrutinizer05 | you should find a GPIO definition next to it |
| 18:36.32 | freemangordon | btw what I have is not spruf98, but omap3430 public trm |
| 18:36.41 | DocScrutinizer05 | search in same table for GPIO_157 |
| 18:37.02 | DocScrutinizer05 | what is written at bottom of that TRM? |
| 18:37.09 | DocScrutinizer05 | each page? |
| 18:37.25 | freemangordon | SWPU223M–July 2007–Revised February 2011 |
| 18:37.45 | DocScrutinizer05 | SWPU223? DUH! |
| 18:37.56 | freemangordon | SWPU223M |
| 18:39.39 | DocScrutinizer05 | right, prolly SPRUF has no pin numbers at all |
| 18:40.00 | DocScrutinizer05 | yup |
| 18:41.06 | DocScrutinizer05 | dang |
| 18:41.16 | DocScrutinizer05 | no SWPU here |
| 18:42.17 | freemangordon | DocScrutinizer05: see https://lkml.org/lkml/2013/6/13/558 |
| 18:42.26 | freemangordon | gpio157 is put in safe mode |
| 18:45.01 | DocScrutinizer05 | can't say this means much to me |
| 18:45.35 | freemangordon | I guess safe mode means "floating" |
| 18:45.39 | DocScrutinizer05 | at *some* time *some* GPIO_157 is set to a certain mode, maybe |
| 18:45.48 | freemangordon | oh, well |
| 18:46.39 | DocScrutinizer05 | probably float/high-Z, yes |
| 18:47.08 | DocScrutinizer05 | somewhere they define what "safe_mode" actually means |
| 18:47.30 | DocScrutinizer05 | I didn't bother so far to check |
| 18:47.53 | freemangordon | me neither |
| 18:48.57 | *** join/#maemo-ssu lansiir (~oldtopman@unaffiliated/oldtopman) |
| 18:50.53 | DocScrutinizer05 | anyway possible functions of this pin are: mcbsp1_fsr adpllv2d_dithering_en1 cam_global_reset and gpio157 |
| 18:51.09 | DocScrutinizer05 | neither of those shows up in N900 schematics |
| 18:51.24 | freemangordon | yep |
| 18:52.00 | DocScrutinizer05 | so your only last chance is to find out about the pin number for the package used in N900, and search for that. You likely won't find that either, which means the pin is unused |
| 18:52.13 | freemangordon | :nod: |
| 18:52.46 | DocScrutinizer05 | is GPIO_157 used *anywhere* in maemo kernel? |
| 18:52.57 | DocScrutinizer05 | I mean: *used* |
| 18:53.27 | DocScrutinizer05 | like in: read it, write to it |
| 18:53.40 | DocScrutinizer05 | define a IRQ handler for it |
| 18:53.52 | freemangordon | will check if maemo sscd uses that gpio |
| 18:53.57 | freemangordon | (cmt_bsi) |
| 18:54.36 | DocScrutinizer05 | cmt_bsi sounds pretty odd |
| 18:55.01 | freemangordon | hmm, "ssc_run.c:304 ssc_hw_write(".../cmt_bsi/state", "inactive")" |
| 18:55.19 | freemangordon | lemme check where is that wired on 2.6.28 |
| 18:55.32 | DocScrutinizer05 | I ponted you to what cmt does with respect to BSI. I don't see much of any cmt_bsi signal from or to APE |
| 18:55.55 | freemangordon | me neither, but sscd seems to use that |
| 18:56.11 | DocScrutinizer05 | really? |
| 18:56.30 | freemangordon | see ^^^ |
| 18:56.49 | DocScrutinizer05 | the line you quoted above sounds more like "not used at all" |
| 18:56.52 | freemangordon | this is syslog when "/usr/sbin/sscd -w -d 3" |
| 18:57.15 | DocScrutinizer05 | what the heck is sscd? |
| 18:57.32 | freemangordon | the one that talks to the modem |
| 18:57.36 | DocScrutinizer05 | mhm |
| 18:58.24 | freemangordon | see /sys/devices/platform/gpio-switch/cmt_bsi |
| 18:59.46 | DocScrutinizer05 | IroN900:~# cat /sys/devices/platform/gpio-switch/cmt_bsi/state |
| 18:59.48 | DocScrutinizer05 | inactive |
| 18:59.55 | DocScrutinizer05 | meh, you beaten me to it |
| 19:01.08 | DocScrutinizer05 | ssc_run.c:304 ssc_hw_write(".../cmt_bsi/state", "inactive") looks like it does just that: create a sysnode and fill it with "inactive" |
| 19:01.22 | freemangordon | see /sys/kernel/debug/omap_gpio |
| 19:01.46 | DocScrutinizer05 | uhuh |
| 19:01.55 | DocScrutinizer05 | to see what? |
| 19:02.06 | freemangordon | gpios :) |
| 19:02.19 | freemangordon | this is not userspace creatde |
| 19:02.24 | freemangordon | created* |
| 19:02.36 | DocScrutinizer05 | GPIO 157 (cmt_bsi ): out lo |
| 19:02.38 | freemangordon | and our schematic is missing that |
| 19:03.18 | DocScrutinizer05 | I wonder if our schamitcs are missing that or it's just cruft in kernel |
| 19:03.28 | DocScrutinizer05 | schematics even |
| 19:04.02 | freemangordon | oh, I think I have some clue while the modem does not work |
| 19:04.04 | freemangordon | just a sec |
| 19:05.54 | freemangordon | http://pastebin.com/avrjPPX7 |
| 19:06.03 | freemangordon | DocScrutinizer05: Pali: ^^^ |
| 19:06.46 | Sicelo | why modem does"mt work? you mean in 3.x? |
| 19:06.48 | freemangordon | pio-72 (cmt_rst_ind ) in lo |
| 19:06.55 | freemangordon | gpio-72 (ape_rst_rq ) in hi irq-232 edge-falling wakeup |
| 19:08.35 | DocScrutinizer05 | freemangordon: yep, seems no IRQ registered on 72 and 151 in 3.10 |
| 19:08.45 | freemangordon | mhm |
| 19:08.59 | freemangordon | also, in lo/in hi |
| 19:09.03 | DocScrutinizer05 | so modem tries to "talk2 but APE is deaf |
| 19:09.13 | freemangordon | yep |
| 19:09.45 | DocScrutinizer05 | of course you need IRQ handlers registered for those IO |
| 19:10.03 | DocScrutinizer05 | init fsckdup |
| 19:10.08 | freemangordon | Pali: any idea what that hi/lo means? is that the current state, or acteve state? |
| 19:10.12 | freemangordon | *active |
| 19:10.27 | DocScrutinizer05 | hmm I think current state |
| 19:12.01 | Pali | freemangordon: I have no idea |
| 19:12.32 | DocScrutinizer05 | clearly current state |
| 19:12.43 | DocScrutinizer05 | watch --differences=cumulative cat /sys/kernel/debug/omap_gpio |
| 19:12.53 | freemangordon | ok |
| 19:12.53 | DocScrutinizer05 | then engage lockswitch |
| 19:13.02 | freemangordon | ok, got it |
| 19:13.18 | freemangordon | ok, lets see why cmt does not register interuupts |
| 19:13.25 | freemangordon | or rather ssi driver |
| 19:13.39 | DocScrutinizer05 | ssi driver BS? |
| 19:13.50 | DocScrutinizer05 | board file BS? |
| 19:14.12 | freemangordon | no idea, have to find it :D |
| 19:17.50 | freemangordon | hmm, most probably irqs are just not reported :( |
| 19:17.53 | DocScrutinizer05 | anyway, have to start my RL weekend. finally |
| 19:24.07 | DocScrutinizer05 | wtf acmelite reset |
| 19:25.00 | DocScrutinizer05 | watch -n 0,5 --differences=cumulative cat /sys/kernel/debug/omap_gpio ;<--awesome |
| 19:29.39 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 19:32.28 | DocScrutinizer05 | freemangordon: anyway cmt_bsi aka 157 constantly out_low here |
| 19:36.14 | DocScrutinizer05 | stingray reset??? |
| 19:36.28 | freemangordon | back camera |
| 19:36.49 | freemangordon | hmm, no, modem uses that, whatever it is |
| 19:46.31 | *** join/#maemo-ssu arcean (~arcean@aacu151.neoplus.adsl.tpnet.pl) |
| 20:32.24 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 21:20.23 | unclouded | didn't know about "--differences=cumulative". nice |
| 21:33.44 | *** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com) |
| 21:43.34 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 21:49.59 | *** join/#maemo-ssu oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 22:09.44 | *** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com) |
| 23:09.49 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 23:15.36 | *** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com) |