**** BEGIN LOGGING AT Sun Jan 01 02:59:57 2012 Jan 01 06:42:34 happy new yea Jan 01 06:42:35 r Jan 01 11:51:54 GNUtoo: happy new year. any idea why my 04 does not start to charge? Jan 01 11:51:59 (plugged in via usb) Jan 01 11:52:07 no idea sorry, happy GNU year Jan 01 11:52:14 and yes I have the same problem Jan 01 11:52:46 maybe the 3.2 kernel doesn't support charging yet? Jan 01 11:53:29 hmm, possible Jan 01 11:53:35 mrmoku: ? Jan 01 11:54:05 yes indeed mrmoku did a big error switching to 3.2 too early, even neil brown said it was too early Jan 01 11:54:20 but now what to do? Jan 01 11:54:28 I mean reverting is also bad Jan 01 12:03:21 btw I got precom working with bootie last night Jan 01 12:03:54 but in another hand I really wonder if it's worth supporting the palm pre in shr Jan 01 12:03:59 I mean for now Jan 01 12:04:08 we could drop it too and focus on other stuff Jan 01 12:04:17 because the kernel has problem like NEON stuff Jan 01 12:04:24 (the official kernel) Jan 01 12:05:27 ya Jan 01 12:06:04 I mean the other day I tried mplayer in a chroot Jan 01 12:06:08 so I do mplayer Jan 01 12:06:16 like for seeing its help Jan 01 12:08:15 and it froze....under the official kernel Jan 01 12:09:08 hmm, bad Jan 01 12:09:30 better concentrate on 04 for now Jan 01 12:12:26 indeed Jan 01 12:12:38 * DocScrutinizer yawns a bit Jan 01 12:12:42 but I didn't want to risk the gta04 working on it the night beeing very tired Jan 01 12:15:00 btw, kernel supports USB charging, a rather funny idea Jan 01 12:18:33 but I'm sure some hardcore 'kacker' will even implement that. Hell we got wakelocks, and probably next will be mono integration into kernel ;-P Jan 01 12:18:59 funny typo, s/kacker/hacker/ Jan 01 12:29:02 :D Jan 01 12:36:53 well, I've seen more complex stacks and functions getting implemented in kernel even when they possibly better lived in userland. But none of those was so terribly board-specific Jan 01 12:39:08 where from will your kernel charger pull info about max charge current allowed *with* *currently* *inserted* *battery*? At currently given ambient/cell temperature? Jan 01 12:40:18 where from pull info which of the half a dozen alternative USB fastcharger detection schemes to use? Jan 01 12:41:25 or are we getting kernel_3.0.12_for_chatging_with_D+-short_fastchargers now? Jan 01 12:42:20 or new kernel cmdline parameters? Jan 01 12:43:13 (not kidding, not [really] sarcastic, really wanna know) Jan 01 12:47:03 the whole charger issue is a nice example why *some* kernel patches better NOT got upstream, though we don't want to miss them either. IOW there's a reason for board specific kernels Jan 01 12:47:35 freesmartphone.org: 03morphis 07framework * rda80d0a93af0 10/etc/freesmartphone/oevents/herring/rules.yaml: Jan 01 12:47:35 freesmartphone.org: Drop oevents configuration for not existing herring machine Jan 01 12:47:35 freesmartphone.org: Signed-off-by: Simon Busch Jan 01 12:47:35 freesmartphone.org: 03morphis 07framework * r0e7dea864c4b 10/etc/freesmartphone/oevents/crespo/rules.yaml: Jan 01 12:47:36 freesmartphone.org: Update oevents configuration of crespo (Nexus S) machine Jan 01 12:47:36 freesmartphone.org: Signed-off-by: Simon Busch Jan 01 12:48:03 one of the reasons why meego kernel sucks, with the strict "upstream stuff only" policy Jan 01 12:48:56 SHR: 03morphis 07meta-smartphone * r6142d70301f4 10/meta-fso/recipes-freesmartphone/freesmartphone/frameworkd_git.bb: meta-fso: frameworkd: bump SRCREV for configuration updates for crespo machine Jan 01 13:02:51 though - as you might have guessed - I prefer the approach of only doing plain hw/silicon defined driver things in kernel, I.E. for example expose all the registers of bq24150 charger chip on sysnodes, maybe slightly augment it by plausibility checks for parameters, unit conversations, IRQ handling and servicing, etc. Do the REST in userland, so the kernel stays clean of board specifics that are by manufacturer's schematics design Jan 01 13:02:53 and thus beyond what chip specifics introduce. Deal with your particular board idiosyncrasies in userland, while getting the clean chip drivers from upstream Jan 01 13:04:06 s/conversations/converting/. Jan 01 13:05:12 well, whatever way works, works for us. our problem is we don't have enough people to also take care about low level things. we're working on a phonestack, not on kernels :/ Jan 01 13:05:16 or at least we should... Jan 01 13:05:34 i know Jan 01 13:05:55 just had my philosophical 5 minutes Jan 01 13:06:00 FWIW Jan 01 13:06:03 sure Jan 01 13:08:39 so, back to the originating problem... what could be the reason why the device does not enter charging mdoe Jan 01 13:16:59 mickeyl: doesn't that largely depend on how "charging mode" is defined and thus implemented? Jan 01 13:17:37 yo, my theory is it doesn't move into 500mA mode Jan 01 13:18:09 beyond that i have no idea Jan 01 13:18:28 quite likely as that for sure needs support from CPU, can't be generally done by twl4030 chip autonomously Jan 01 13:20:15 depending on schematics the board *might* be able to detect some variant of fastcharger signalling, e.g. D+-short, and then switch to "unlimited" USB current charging, without any support from CPU. Jan 01 13:25:39 to find out about that you need to either refer to the board hw description (probably missing or incomplete regarding that topic), or you study the twl4030 technical reference manual and schematics. For all software supported charging you as well have to learn all the basics from aforementioned sources, then see what and how it's already implemented in either kernel and/or userland daemons Jan 01 13:25:51 right Jan 01 13:26:02 and that exceeds way beyond what i'm willing to do to fix that problem :D Jan 01 13:26:14 i'm afraid i will just write a mail instead Jan 01 13:26:21 and hope it gets fixed by someone else... Jan 01 13:26:36 :-D Jan 01 13:33:09 btw iirc exactly that D+- short detection for automatic fastcharging had a silicon bug in some variants of twl4030, that being the reason why Nokia switched to 1707 USB PHY "last minute" and thus introduced mindboggling problems with hostmode, as that 1707 doesn't support sw controlled fake ID pin GND (indication of A-plug in USB receptagle, to make musb_core switch to hostmode) Jan 01 13:34:35 seems USB charging by twl4030 is a mega PITA Jan 01 13:36:11 so Nokia not only binned the USB PHY of twl4030, but completely "outsourced" charging to bq24150 chip which kinda works, with 1707, to provide proper autonomous fastcharging (called emergency charging) Jan 01 13:36:22 ~flatbatrecover Jan 01 13:36:22 Remove battery for 1 minute. Insert battery. Plug powered Nokia wallcharger to device. Watch steady amber. Let sit and charge. Do NOT try to boot. After 30 min, you got either a) a booted up N900, b) flashing amber which means you can boot, c) steady amber going off - in this case start over again with ~flatbatrecover Jan 01 13:38:04 steady amber N900 indicator light driven by bq24150 on a direct hw level - a chip pin plus 2 transistors Jan 01 13:38:04 fun Jan 01 13:46:13 I have no idea where from Nikolaus 'copied' the GTA04 schematics, whether it's TI application notes or pandora/beagle/panda/whatever, and what's the technical board function description regarding charging for any of those 'sources'. Basically that's exactly *my* job as I always specified it: provide those technical functions specs for SW devels from inside the EE R&D Jan 01 13:48:32 EE tends to "throw over the wall" the finalized hw design and SW devels have to find their way around, gathering info of how hw is supposed to work from any available source they can find, and resorting to mere guesswork on what EE thought when they designed detail XY in that particular way Jan 01 13:52:07 alas NO management seems to ever realize this common problem, and if you rise it to them they dismiss it and say EE is already supposed to provide those docs - ignoring the fact that quite usually their EE don't Jan 01 13:59:35 all this gets extremely nasty for FOSS when some hw needs "tricks" to put it to proper operation, and those "tricks" were disclosed to the R&D EE under NDA by the chip manuf Jan 01 14:00:24 so you get a hw that EE attributes "works" but "sorry we must not tell you HOW we made it work" Jan 01 14:01:09 worst case you have to RE a blob dumped on you by EE Jan 01 14:01:59 this can happen for *any* hw component of a certain minimum complexity and beyond, not limited to gfx drivers Jan 01 14:09:42 on GTA02 pmu we had that note about silicon wear-out that reduces charging current. If we would've found a way to avoid the operation modes that cause the wear, or a way to compensate it, it's highly questionable if we would have been allowed to disclose that to community and explain why it's needed Jan 01 14:11:28 original chip docs being publicly available doesn't mean same applies for all the silicon errata the manuf might throw at you eventually Jan 01 14:13:47 lol for morons at TV: "Benidorm verbraucht jedes Jahr 22Mio *Kubik*Hektoliter" Jan 01 14:14:32 * DocScrutinizer tries to envision liter^3 Jan 01 14:14:59 aka litre Jan 01 14:21:04 should I be building SHR with meta-smartphone on the origin/shr branch? Jan 01 14:21:35 because the Makefile doesn't check out origin/shr, it checks out origin/master Jan 01 14:23:47 rah, then update your Makefile Jan 01 14:24:34 GNUtoo: I'm not using the Makefile Jan 01 14:24:39 GNUtoo: hence my question Jan 01 14:24:45 ok Jan 01 14:24:51 checkout origin/shr Jan 01 14:25:01 I'm not using the Makefile either Jan 01 14:25:24 GNUtoo: so I should be using the shr branch of meta-smartphone? Jan 01 14:26:10 last time I checked the response was yes Jan 01 14:26:21 ok, thanks Jan 01 14:26:24 that is not so long ago Jan 01 14:26:38 maybe it changed again since, ask JaMa if you see him then Jan 01 14:27:54 it hasn't rid me of my error Jan 01 14:27:56 ERROR: Unable to parse conf/bitbake.conf: Could not include required file conf/distro/include/shr-autorev.inc Jan 01 14:28:11 pastebin bblayers.conf Jan 01 14:28:25 and also the output of pwd and ls Jan 01 14:28:40 you should stay in the dir that has conf/bblayers.conf i Jan 01 14:30:23 http://codepad.org/0lAprVfp Jan 01 14:30:30 that's the output of bblayers.conf and ls Jan 01 14:30:47 err.. that is bblayers.conf and the output of ls Jan 01 14:32:15 then define TOPDIR Jan 01 14:33:56 TOPDIR is defined Jan 01 14:35:41 OE om-gta01@shr ~/phones/gta01/shr/shr-core $ cat conf/topdir.conf Jan 01 14:35:41 TOPDIR='/home/rah/phones/gta01/shr/shr-core' Jan 01 14:35:41 OE om-gta01@shr ~/phones/gta01/shr/shr-core $ grep topdir.conf setup-env Jan 01 14:35:41 . ./conf/topdir.conf Jan 01 14:37:02 http://git.shr-project.org/git/?p=shr-makefile.git;a=blobdiff;f=conf/shr-core/local.conf;h=9de5c8417bba5f2405c642c51ec17066d822b424;hp=ce5c0967d34def7dcd326a3163d48efebdd79443;hb=50ed2e82f415ca5b53faca8be7a7f37a38d42977;hpb=60f4f6de183689386ba80862969e50fc1d3690f5 Jan 01 14:37:17 shr-autorev.inc is no longer present apparently Jan 01 14:37:21 yes but you would need bbextra-white Jan 01 14:37:23 ah ok Jan 01 14:37:25 let me look Jan 01 14:38:01 try to add topdir in the bblayers.conf Jan 01 14:38:14 and then also look if conf/distro/include/shr-autorev.inc is still present in meta-smartphone/meta-shr Jan 01 14:38:46 erm Jan 01 14:38:59 I mean shr-autorev.inc is no longer present in the repo Jan 01 14:39:17 the URL I pasted is to the commit that removes the reference to it Jan 01 14:52:04 then do the same Jan 01 15:47:59 mickeyl, due to you charging problem: which kernel do you use? Jan 01 15:48:36 mickeyl, if you use a current shr kernel you need to supply the charging options via cmdline Jan 01 15:49:15 mickeyl, have a look here: http://trac.shr-project.org/trac/wiki/Devices/GTA04/InstallGuide (and in the advanced section, where you can see the cmdline of boot.scr) Jan 01 16:09:26 mickeyl, GNUtoo: charging works fine with 3.2... it just needs a kernel cmdline parameter to be enabled Jan 01 16:10:52 (as Slyon already noted :P) Jan 01 17:01:26 mickeyl: btw. twl4030_charger.allow_usb=1 twl4030_charger.charge_backup=1 Jan 01 17:01:29 are the ones you need Jan 01 17:07:39 mrmoku: kernel cmdline parameter - LOL. See backscroll, what I said [2012-01-01 13:35:08] Jan 01 17:07:59 mrmoku: and a happy new year to you! :-D Jan 01 17:08:18 and to whole #openmoko-cdevel Jan 01 17:41:32 Happy new year DocScrutinizer :) Jan 01 17:41:49 and to all readers :) Jan 01 17:44:02 DocScrutinizer: to you too :) Jan 01 17:46:42 hi mrmoku Jan 01 17:47:09 hi GNUtoo-netbook Jan 01 17:47:59 mrmoku, what should we do for gta04 now? Jan 01 17:48:22 GNUtoo-netbook: honestly I think switching to the 3.2 kernel was a good thing Jan 01 17:48:27 should I work on an mmap version of the sound forwarder Jan 01 17:48:36 it was too early Jan 01 17:48:53 we could have waited for sound support at least Jan 01 17:49:07 we also must look into battery charging Jan 01 17:49:34 what would have changed? you could have started with userspace sound parts a week earlier maybe... that's it Jan 01 17:49:42 and charging works fine Jan 01 17:49:50 if you pass it those two kernel params Jan 01 17:49:52 mickeyl, and me have charging issues Jan 01 17:49:57 what kernel params? Jan 01 17:50:01 17:54 < mrmoku> mickeyl: btw. twl4030_charger.allow_usb=1 twl4030_charger.charge_backup=1 Jan 01 17:50:06 is that in shr? Jan 01 17:50:17 it is in the default kernel config Jan 01 17:50:27 probably get's overwritten by u-boot Jan 01 17:50:34 because for me it *seems* that sometimes charging work Jan 01 17:50:41 and sometime it doesn\t Jan 01 17:51:03 hmm... for me it works reliably with those params for quite some time Jan 01 17:51:22 how do you charge it? Jan 01 17:51:27 usb or charger? Jan 01 17:52:11 usb Jan 01 17:52:23 * mrmoku still has to locate his wall charger :/ Jan 01 17:52:27 will try that right now Jan 01 17:52:32 good Jan 01 17:52:46 arrrg armv4: asio uses too much ram Jan 01 17:57:13 like more than 7G Jan 01 17:57:20 and I've only 4G Jan 01 17:57:27 and a huge swap Jan 01 18:01:26 I hope JaMa knows about asio Jan 01 18:05:06 dos11: how's you stipendium going? Jan 01 18:05:11 +r Jan 01 18:05:32 mrmoku: still few weeks left Jan 01 18:05:39 ok :) Jan 01 18:07:03 mrmoku: three weeks, to be specific ;) Jan 01 18:07:51 mrmoku, for the call forwarder, I integrate in fsoaudiod? Jan 01 18:08:04 GNUtoo-netbook: yeah Jan 01 18:09:07 ok because of fsodeviced/fsoaudiod scenarios clash and what was decided about it for next release I didn't know what to do anymroe Jan 01 18:11:22 GNUtoo-netbook: hmm... that depends on what the release means for gta04 Jan 01 18:12:04 IIRC we decided to *not* pull fsoaudiod into *all* images Jan 01 18:12:19 but we could (and probably should) do that for n900 and gta04 Jan 01 18:12:56 ok Jan 01 18:13:27 can we pull only the fsoaudiod activator part? not the scenario handling.... Jan 01 18:14:40 we can simply disable the module Jan 01 18:17:16 ok Jan 01 18:17:20 hi DocScrutinizer Jan 01 18:20:53 hi GNUtoo-netbook Jan 01 18:23:27 DocScrutinizer, do you have any advises for writing a low latency forwarder for the gta04, for instance should I use mmap instead of writei? Jan 01 18:23:40 I remember the n900 code Jan 01 18:24:09 I'm looking for specific tips for programming part of it, not the scheduling by the operating system Jan 01 18:26:05 GNUtoo-netbook: I haven't looked into gta04 audio sw side at all, wouldn't even know how modem audio gets routed to the earpiece and from mic Jan 01 18:26:19 ok Jan 01 18:26:59 ooh I see. APE centric design, like N900 Jan 01 18:27:10 so probably all the same concept applies Jan 01 18:27:20 The main question is how much should I re-use from the n900 Jan 01 18:27:34 for instance if it becomes mmap some stuff changes Jan 01 18:27:37 like ~all? Jan 01 18:27:45 but I'm not sure mmap gives lower latencies Jan 01 18:28:09 don't bother about that kind of latency, it's irrelevant Jan 01 18:28:27 ok I was mislead by the gta04 mailing list then Jan 01 18:28:39 I"ll try to get the best sound quality possible then Jan 01 18:28:45 ~330m/s / 1m Jan 01 18:29:07 and then to schedule the task real-time Jan 01 18:29:07 maybe it's doable in alsa Jan 01 18:29:07 maybe it's the classic audio real time stuff from professional audio Jan 01 18:29:07 is what 'natural' latency is, when you use speakerphone Jan 01 18:29:47 maybe I should start by fixing the n900 audio> Jan 01 18:29:56 s/>/?/ Jan 01 18:29:58 GNUtoo-netbook meant: maybe I should start by fixing the n900 audio? Jan 01 18:30:09 actually 1m/330ms^-1 Jan 01 18:30:19 because if I re-use the code... Jan 01 18:31:09 yeah, prior to porting N900 cmtspeech on another platform, it for sure better works on N900 ;-) Jan 01 18:31:29 because it doesn't work well at all on n900 Jan 01 18:31:43 the sound quality in receiving the audio is not good but beareable Jan 01 18:31:58 but the countrary is quite unbereable (sending the aidio) Jan 01 18:32:04 *audio Jan 01 18:33:03 hmm, so our handling of timing adj msgs from ISI obviously lacks something Jan 01 18:37:09 good point Jan 01 18:41:41 but are we sure that it's isi? Jan 01 18:41:58 for instance porting to gta04 without fixing could tell.... Jan 01 18:46:22 should be quite easy to try Jan 01 18:46:29 yo JaMa Jan 01 18:47:02 hi JaMa Jan 01 18:47:25 btw do you know why asio boost takes too much ram at compilation? Jan 01 18:49:22 mrmoku: GNUtoo-netbook: hmmm, how's PCM/SPI audio defined for gta04 modem? Jan 01 18:54:50 yo Jan 01 18:55:15 GNUtoo-netbook: probaly same problem as webkit-*, incredibly big .so files before stripping debug info Jan 01 18:55:26 mrmoku: how was .it? Jan 01 18:56:15 ok Jan 01 19:10:04 fsoaudiod: symbol lookup error: /usr/lib/cornucopia/modules/fsoaudio/gsmvoice_alsa_cmtspeechdata.so: undefined symbol: cmt_speech_init Jan 01 19:10:10 JaMa: quiet and short :) Jan 01 19:10:46 fortunatelly too short to feel the symptoms of the 'I have no internet' syndrom :P Jan 01 19:11:15 <[Rui]> hi all Jan 01 19:12:25 >> WWAN data. Telephony voice is transmitted digitally through a PCM interface (module generates 2.048 MHz clock and 8kZh frame sync) connected to McBSP4. A GPL Driver is avaliable by Option and is part of the mainstream Linux kernel since 2.6.31. << Jan 01 19:13:16 it's cmtspeech_init Jan 01 19:13:53 so I've to build and fix Jan 01 19:14:05 so I've to wait for the toolchain Jan 01 19:14:07 bbl Jan 01 20:15:10 hi, happy new year to everybody :) Jan 01 20:16:26 hi, happy GNU year Jan 01 20:22:28 hi mickeyl Jan 01 20:22:30 mrmoku: ah, command line args, i see. ok, i'll try to change those Jan 01 20:22:32 yo GNUtoo Jan 01 20:22:43 mickeyl, can you fix that: Jan 01 20:22:50 fsoaudiod: symbol lookup error: /usr/lib/cornucopia/modules/fsoaudio/gsmvoice_alsa_cmtspeechdata.so: undefined symbol: cmt_speech_init Jan 01 20:23:01 the correct symbol is cmtspeech_init Jan 01 20:23:19 hmm Jan 01 20:23:25 75: 000044d4 4 FUNC GLOBAL DEFAULT 10 cmtspeech_init Jan 01 20:23:53 didn't that work for a while? Jan 01 20:24:21 no idea Jan 01 20:24:29 I didn't made a phone call for a while on n900 Jan 01 20:24:40 since it's known to have bad audio quality.... Jan 01 20:25:50 also we must factorize n900 code to permit gta04 to use some of its code Jan 01 20:27:41 freesmartphone.org: 03mickey 07cornucopia * r575d71de801c 10/fsoaudiod/vapi/libcmtspeechdata.vapi: fsoaudiod: vapi: add CCode directive for CmtSpeech namespace Jan 01 20:27:46 can you try whether this fixes it? Jan 01 20:27:49 ok Jan 01 20:28:02 thanks a lot I'll try as soon as compiler has finished Jan 01 20:28:27 ha it has Jan 01 20:28:33 restarting a build Jan 01 20:28:43 ERROR: '/home/gnutoo/embedded/oe/oe-core/repos/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_4.6.bb' failed Jan 01 20:28:44 arrrg Jan 01 20:29:25 cleaning toolchain once again Jan 01 20:32:07 I always thought oe was a poor decision to base on Jan 01 20:32:55 do you know something that could replace it? Jan 01 20:33:00 I don't think that exists Jan 01 20:33:32 I mean how long would it take to compile debian within qemu.... Jan 01 20:33:40 that wouldn't have autorev Jan 01 20:33:45 etc... Jan 01 20:33:51 that would create many more problems Jan 01 20:34:02 if you're going to build a device that in the end shall be as close to a normal desktop PC as possible, then where do you start? on a distro for stiching machines, or on a distro for normal desktop PC? Jan 01 20:34:38 that's where some of us disagree Jan 01 20:35:05 indeed Jan 01 20:35:15 for instance we do not have desktop-like resolutions Jan 01 20:35:22 n900 has Jan 01 20:35:28 but the other phones don't Jan 01 20:35:58 oooh, 640*480 is quite a normal desktop resolution, and btw resolution is really the least problem Jan 01 20:36:58 (battle for wesnoth doesn't work at 640x480 without --tiny-gui) Jan 01 20:37:19 but that's a lousy argument Jan 01 20:37:38 mhm, valid point to use a distro as starting point where battle of wresnoth isn't supposed to ever run at all Jan 01 20:37:57 in shr-unstable it ran fine Jan 01 20:38:36 we need some games still Jan 01 20:38:50 I think the most downloaded apps in the android market are games Jan 01 20:38:52 yeah, even that browser was patchable so it didn't show the "DO NOT RUN ME AS ROOT!" warning anymore Jan 01 20:39:10 indeed oe is about customizations Jan 01 20:39:20 altough maybe debian has something similar Jan 01 20:39:23 for instance pre-seed Jan 01 20:39:27 or some name like that Jan 01 20:39:35 it's used by freedombox Jan 01 20:41:36 mickeyl: I know who are those who disagree. Those who think a phone is a phone is a phone, and if you tell them about landscape orientation, or even about virtual ascii kbd they shudder Jan 01 20:41:52 for a featurephone for sure oe was the starting point of choice Jan 01 20:42:07 like the palm-pre? Jan 01 20:42:24 as a featurephone clearly complies with all the points of "embedded" definition Jan 01 20:42:59 is the palm-pre a feature phone? Jan 01 20:43:31 also what about the hard work of upstreaming in debian? Jan 01 20:43:38 why run the dialer, or contacts, or calendar under normal user? they all don't offer any method to mess with system, no matter if they have rot or user permissions Jan 01 20:43:49 for instance you code a feature and have to wait years to see it? Jan 01 20:44:01 root* Jan 01 20:44:04 or it doesn't apply because of external feeds Jan 01 20:44:44 GNUtoo, do you know if elm_softkey is fixed? Jan 01 20:44:47 GNUtoo: those are all rather moot points Jan 01 20:45:00 pespin, it should be, in my last gta04 images it is Jan 01 20:45:17 ok, time to try a staging image then I guess :P Jan 01 20:47:28 also.... Jan 01 20:47:50 hmmm never mind Jan 01 20:48:10 I think the gta02 under debian has a recent enough kenrel Jan 01 20:48:19 but what for instance if you have a palm pre Jan 01 20:48:25 with a 2.6.24 kernel Jan 01 20:48:32 you will need to adapt a lot of debian Jan 01 20:48:36 for instance udev Jan 01 20:49:27 hi nschle85 Jan 01 20:49:50 GNUtoo: hi, happy new year Jan 01 20:49:54 thanks Jan 01 20:49:59 happy GNU year to you too Jan 01 20:50:01 hmmm there are no images for gta02 in shr buildhost? :S Jan 01 20:50:11 GNUtoo: the kernel is not in official debian though but 2.6.34 is in pkg-fso repository and works. I also have used 2.6.39 for some time now Jan 01 20:50:15 http://build.shr-project.org/shr-core-staging/latest/images/ Jan 01 20:50:21 pespin, there are but maybe not for all the numbers Jan 01 20:50:40 lindi-, how will you handle newer udevs? Jan 01 20:50:46 most recent is 014 Jan 01 20:50:54 GNUtoo: how new? Jan 01 20:51:07 which doesn't have the elm_softkey fix >.< Jan 01 20:51:20 GNUtoo: the 2.6.34 in pkg-fso has backported one patch I think to support udev Jan 01 20:51:21 when debian will switch to a newer udev version which require a very recent kernel....how will you handle that? Jan 01 20:51:26 ok Jan 01 20:51:31 the sys_accept one? Jan 01 20:51:31 GNUtoo: you need to specify "newer udev" Jan 01 20:51:46 GNUtoo: but that backport was done ages ago Jan 01 20:51:51 ok Jan 01 20:52:02 GNUtoo: it's udev 175-3 now Jan 01 20:52:08 ok Jan 01 20:52:23 lindi-, did you try my 3.1 kernel btw? Jan 01 20:52:26 GNUtoo: nope Jan 01 20:52:30 ok Jan 01 20:52:56 I think at some point I'll need to write some bbclass to filter out non-free licenses in oe Jan 01 20:54:48 lindi-, all the shr patches were ported on 3.1 Jan 01 20:55:03 or were already in if not ported Jan 01 20:55:26 GNUtoo: I thought 3.1 was not yet usable Jan 01 20:55:59 under SHR it's not because it's not well tested and the userland is not adapted yet Jan 01 20:56:14 for instance the modem didn't came up, I didn't investigate tough Jan 01 20:56:24 ok so not really usable yet :/ Jan 01 20:56:43 like xorg.conf must be changed etc... Jan 01 20:57:01 GNUtoo: I don't see your point - the "newer" the kernel you use, the closer it gets to main. You had to build a device specific kernel for oe as well, and it's not been any easier than to build it for debian. Of course you need to place your device specific patches on top of linus kernel, but that's true no matter if the kernel is built for oe or for debian or for meego or whatever Jan 01 20:57:02 but theorically it should work Jan 01 21:02:23 but thanks to oe we still got no normal user accounts on SHR, and I think this was just one of the pieces that got binned in OE as OE was for stiching machines which don't have users, while on a internet tablet + general purpose pocket-able palmtop computer you of course need proper user management Jan 01 21:04:36 heh, not quite. it hasn't been binned, it just was never there and obviously didn't annoy anyone enough to motivate someone to fix it Jan 01 21:05:07 now that intel has adopted it, we may see all that Jan 01 21:11:47 there were commits for that in oe Jan 01 21:11:52 but the problem is not only in oe Jan 01 21:11:56 it's also the shr apps Jan 01 21:12:01 like iliwi Jan 01 21:12:27 it annoyed people a lot Jan 01 21:12:39 <[Rui]> intel adopted oe? Jan 01 21:12:43 but no one had the time and the will to work on it Jan 01 21:13:07 [Rui], yes intel contribute a lot to yocto Jan 01 21:13:11 they bought openhand Jan 01 21:13:17 which made poky Jan 01 21:14:05 http://www.shr-project.org/trac/wiki/run%20SHR%20as%20user Jan 01 21:14:43 the main issue isn't oe Jan 01 21:14:46 it's the apps Jan 01 21:15:17 hmmm Jan 01 21:15:39 <[Rui]> aren't a lot of things already used vya dbus? Jan 01 21:15:45 <[Rui]> s/vya/via Jan 01 21:16:56 scanning for iliwi is not done by dbus Jan 01 21:17:16 and iliwi is a key app Jan 01 21:17:19 ya, the general architecture supports user privilege boundaries, like GNUtoo says though it hasn't been carried out in the actual apps and there are quite a bunch of 'legacy' apps directly accessing the hardware Jan 01 21:17:23 but I guess it may be the only problem Jan 01 21:17:23 GNUtoo: guess WHY all the apps have issues with assuming always-being-root Jan 01 21:17:28 ;-D Jan 01 21:17:28 "directly" Jan 01 21:17:58 of course there are other apps Jan 01 21:18:04 but theses apps are not in the image Jan 01 21:18:06 <[Rui]> omnewrotate Jan 01 21:18:11 yes such apps Jan 01 21:18:14 in 3rdparty Jan 01 21:18:24 <[Rui]> but tecnically, if the device is readable, omnnewrotate can work without root Jan 01 21:18:28 the gesture app too Jan 01 21:19:14 Ipromise you'll *never* fix this foundation flaw Jan 01 21:19:18 <[Rui]> acellerometer apps aren't much of a problem, then can be pointed to an input device, and that iseasy controllable wioth permissions Jan 01 21:20:18 who will volounter to fix iliwi? Jan 01 21:22:27 [Rui]: technically, omnewrotate mustn't directly access accelerometer, as I explained just 2 days ago. "Orientation" is an abstract thing that shall get managed by a central instance (preferably in FSO) and all apps only talk to that GUI-less instance to learn what orientation user wants right now Jan 01 21:22:54 I think there is some plugin for that Jan 01 21:22:57 IOW orientation is NOT directly related to accelerometer at all Jan 01 21:24:03 and I see why mokomaze or spirit-level may want to access accelerometer data, but no app shall abuse accelerometer to decide about orientation Jan 01 21:29:53 mickeyl, I don't understand, maybe I did an error in the setup....but it seems that it didn't work Jan 01 21:30:16 ha wait Jan 01 21:30:24 I forgett to pull there Jan 01 21:30:33 ahh no Jan 01 21:30:37 it cd into oe dir Jan 01 21:30:39 sorry Jan 01 21:30:50 . .../run_do_compile.... Jan 01 21:32:28 <[Rui]> DocScrutinizer, yeah, but I wasn't here 2 days ago :) Jan 01 21:32:35 | include/linux/math64.h: In function 'div_u64_rem': Jan 01 21:32:35 | include/linux/math64.h:51:15: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Jan 01 21:32:53 ERROR: Task 7 (/home/rah/phones/gta01/shr/shr-core/meta-smartphone/meta-openmoko/recipes-kernel/linux/linux-openmoko_2.6.39.bb, do_compile) failed with exit code '1' Jan 01 21:33:09 <[Rui]> DocScrutinizer, I'm reviving omnewrotate a bit because of my tablet Jan 01 21:33:16 why would __LINUX_ARM_ARCH__ not be declared? Jan 01 21:33:33 rah, you have a freerunner too? Jan 01 21:33:46 <[Rui]> it has recently gained accelerometer support via a Linux upgrade, but the screen driver still get's borked calibration on non 0 xrandr positions Jan 01 21:33:52 GNUtoo: no, I don't have a freerunner Jan 01 21:33:54 <[Rui]> brb baby Jan 01 21:34:00 GNUtoo: I do have a 1973 though Jan 01 21:34:12 ah ok and you're compiling for it Jan 01 21:34:17 I am indeed Jan 01 21:34:27 or trying to.. Jan 01 21:34:36 rah, please share your steps with us Jan 01 21:34:42 because none of the shr devs have one Jan 01 21:35:08 let me look in a moment Jan 01 21:35:11 GNUtoo: "bitbake -k shr-lite-image" :-) Jan 01 21:35:18 ok Jan 01 21:35:22 under shr-core? Jan 01 21:35:29 aye Jan 01 21:35:31 MACHINE="om-gta01" Jan 01 21:35:36 that's all I've set Jan 01 21:35:38 ok Jan 01 21:37:46 it's the arm version Jan 01 21:38:11 -D__LINUX_ARM_ARCH__=4 Jan 01 21:38:32 that's what the Makefiles should pass to the compiler Jan 01 21:38:57 it's in arch/arm/Makefile Jan 01 21:39:14 arch-$(CONFIG_CPU_32v4T) :=-D__LINUX_ARM_ARCH__=4 -march=armv4t Jan 01 21:39:15 arch-$(CONFIG_CPU_32v4) :=-D__LINUX_ARM_ARCH__=4 -march=armv4 Jan 01 21:39:38 aye Jan 01 21:39:46 saw that myself Jan 01 21:39:52 ok Jan 01 21:40:02 so look at the CONFIG_ in the defconfig Jan 01 21:40:09 there's no CONFIG_CPU_WHATEVER set in defconfig Jan 01 21:40:14 and if you succeed to fix it send a patch to the shr ml Jan 01 21:40:24 ok but don't look in the real defconfig Jan 01 21:40:27 but in .config Jan 01 21:40:32 ok Jan 01 21:40:53 nothing Jan 01 21:41:05 nothing for me either Jan 01 21:41:36 ah sorry Jan 01 21:41:38 bad grep Jan 01 21:41:39 CONFIG_CPU_32v4T=y Jan 01 21:41:47 that's in .config Jan 01 21:41:53 so do a better defconfig Jan 01 21:41:57 or fix the Kconfigs Jan 01 21:42:03 let me find where they are defined Jan 01 21:43:25 arch/arm/mm/Kconfig: Jan 01 21:43:43 config CPU_ARM920T Jan 01 21:43:45 ... Jan 01 21:43:50 select CPU_32v4T Jan 01 21:44:10 so do you have CONFIG_CPU_ARM920T ? Jan 01 21:50:05 OE om-gta01@shr ~/phones/gta01/shr/shr-core $ egrep ^CONFIG_CPU_ tmp-eglibc/work/om_gta01-oe-linux-gnueabi/linux-openmoko-2.6.39-r6-oe16/linux-2.6.39/.config Jan 01 21:50:05 CONFIG_CPU_IDLE=y Jan 01 21:50:05 CONFIG_CPU_IDLE_GOV_LADDER=y Jan 01 21:50:05 OE om-gta01@shr ~/phones/gta01/shr/shr-core $ Jan 01 21:50:25 there is nothing to select any CPU Jan 01 21:50:27 pastebin your whole .config Jan 01 21:51:13 the openmoko.patch contains a Kconfig entry for the GTA02 but it contains nothing for the GTA01 Jan 01 21:51:22 I don't think this kernel supports the 1973 Jan 01 21:51:39 let me look Jan 01 21:51:50 http://codepad.org/PRa7IdlZ Jan 01 21:51:52 that's the config Jan 01 21:52:45 there is a config for gta01 Jan 01 21:52:54 in meta-openmoko which is in meta-smartphone Jan 01 21:53:27 but no GTA01 in that kenrel Jan 01 21:53:31 yes, there's a config for it but it seems irrelevant as the kernel doesn't support it :-) Jan 01 21:53:35 idneed Jan 01 21:53:40 add it then Jan 01 21:53:41 *indeed Jan 01 21:54:23 there are SHR images for the GTA01 so a kernel must exist somewhere Jan 01 21:54:33 yes I'm looking right now Jan 01 21:54:54 not for 39 Jan 01 21:55:06 but it's just a machine config to port forward Jan 01 21:55:34 beware about the alsa driver Jan 01 21:55:44 you need to revert a commit which removed gta01 Jan 01 21:57:57 rah, the problem is that git.openmoko.org is down Jan 01 21:58:16 should I push the 37 for gta01 for you on gitorious Jan 01 21:58:16 ? Jan 01 22:01:01 GNUtoo: ok Jan 01 22:01:15 is git.openmoko.org down temporarily or (semi-)permanently? Jan 01 22:03:02 no idea Jan 01 22:06:05 hey JaMa did a 3.2 for freerunner (seem similar to the 3.1 I did) Jan 01 22:14:43 rah, also maybe you should add a gta01 machine mainline Jan 01 22:14:59 because well, it's easier than gta02 to have it fully supported Jan 01 22:15:06 no wifi, no glamo.... Jan 01 22:15:19 GNUtoo: what do you mean by "add a gta01 machine mainline"? Jan 01 22:16:08 I mean after you'll have ported the machine config from 2.6.37 you should maybe rebase it on linux-next and submit it for mainline Jan 01 22:16:19 altough you need a machine ID Jan 01 22:17:11 none of the actual devs have a gta01 Jan 01 22:17:15 so we couln't do it Jan 01 22:17:47 https://gitorious.org/~gnutoo/shr/gnutoos-linux-shr-temp/commits/gta01-machine-2.6.37 Jan 01 22:20:02 I see Jan 01 22:20:23 so cherry-pick the commits Jan 01 22:20:28 resolve the possible conflicts Jan 01 22:20:29 compile Jan 01 22:20:38 and fix the compilations issues if any Jan 01 22:20:40 and run it Jan 01 22:20:51 do you have a debug board? Jan 01 22:20:57 I do have a debug board Jan 01 22:21:02 wow nice Jan 01 22:22:26 so you have everything to succeed Jan 01 22:22:48 because the debug board may be needed Jan 01 22:22:55 for instance to debug boot issues Jan 01 22:27:08 mickeyl, it fails to compile now Jan 01 22:27:22 cmthandler.c:1514:2: error: unknown type name 'EventData' Jan 01 22:27:25 maybe it's me tough Jan 01 22:27:37 in the sense of my setup Jan 01 22:30:36 at the moment, my concern is to get SHR on it, rather than sending patches to the mainline kernel Jan 01 22:30:52 yes that's why I said that the patches should be sent later Jan 01 22:30:59 when everything works Jan 01 22:30:59 the simplest way to achieve that is to use that 2.6.37 tree Jan 01 22:31:07 not sure Jan 01 22:31:26 maybe it's to port the 2.6.37 stuff to 2.6.39 Jan 01 22:31:32 just cherry-pick the commit Jan 01 22:34:42 why would I port things from the 2.6.37 kernel to some other kernel, rather than just using the 2.6.37 kernel itself? Jan 01 22:36:11 because it doesn't contain all the drivers Jan 01 22:36:53 *may not Jan 01 22:37:17 where did this tree come from? Jan 01 22:37:18 like for the touchscreen for instance Jan 01 22:37:21 openmoko Jan 01 22:37:25 openmoko git Jan 01 22:40:29 surely you would expect the kernel tree from openmoko to have all the relevant drivers? Jan 01 22:42:35 do you want older branches? Jan 01 22:43:24 I want one that works :-) Jan 01 22:43:34 but I don't know which one works Jan 01 22:43:44 let me rephrase: Jan 01 22:43:56 do you want me to push an other branch like an older branch? Jan 01 22:44:08 I don't know which one works either Jan 01 22:44:10 http://www.pastie.org/private/83yvshqzaphxzzfpdydkw Jan 01 22:44:15 shr-unstable has a kernel though Jan 01 22:44:26 2.6.34? Jan 01 22:44:39 look which one it is Jan 01 22:44:41 is there a web interface to the shr-unstable git tree? Jan 01 22:44:42 I can't find one Jan 01 22:44:46 tes Jan 01 22:44:50 *yes Jan 01 22:44:56 there is that gitorious repo: Jan 01 22:45:11 https://gitorious.org/shr/linux Jan 01 22:45:48 I mean shr-unstable itself, rather than the kernel Jan 01 22:46:34 sh-runtable will have a recipe for building shr-lite-image for om-gta01, which will include a kernel Jan 01 22:46:37 or should Jan 01 22:46:38 https://gitorious.org/shr/linux/commits/shr-2.6.34 Jan 01 22:46:44 has gta01 in it Jan 01 22:46:46 and should work Jan 01 22:47:48 what makes you think it should work? Jan 01 22:47:59 because I guess that was the kernel in shr-unstable Jan 01 22:48:05 and it contains all the drivers Jan 01 22:48:10 and gta01 machine stuff Jan 01 22:48:47 why are you guessing that was the kernel in shr-unstable? Jan 01 22:49:38 ah I was guessing wrong Jan 01 22:49:42 http://build.shr-project.org/#!/shr-unstable/images/om-gta01/ Jan 01 22:50:11 there is a 37 for gta01 Jan 01 22:50:19 but maybe it doesn't even boot Jan 01 22:50:22 you should try it Jan 01 22:50:32 and look at opkg info on the kenrel Jan 01 22:50:35 to find the sources Jan 01 22:52:23 it contains shr.patch Jan 01 22:52:37 and openmoko.patch Jan 01 22:52:41 ask JaMa Jan 01 23:24:03 JaMa: om-gta01 support has disappeared from the linux-2.6.39 kernel in shr-core Jan 01 23:24:12 JaMa: is this something you know about? **** ENDING LOGGING AT Mon Jan 02 02:59:56 2012