| 08:10.13 | *** join/#neo900 infobot (ibot@rikers.org) |
| 08:10.13 | *** topic/#neo900 is http://neo900.org | CCCAMP15 lightning talks at http://neo900.org/stuff/cccamp15/ - major: http://neo900.org/stuff/cccamp15/ccc2015talk/neo900-wpwrak_CCC2015.webm | conversations are logged to http://infobot.rikers.org/%23neo900/ and http://irclog.whitequark.org/neo900 |
| 08:10.13 | *** mode/#neo900 [+v infobot] by ChanServ |
| 08:21.39 | *** join/#neo900 Defiant (erik@x4e36bd49.dyn.telefonica.de) |
| 08:23.59 | *** join/#neo900 Xiaoman (~Xiaoman@unaffiliated/xiaoman) |
| 08:34.54 | *** join/#neo900 saper_ (saper@m.saper.info) |
| 08:36.10 | *** join/#neo900 bredebid (~bredebid@207.43.54.77.rev.vodafone.pt) |
| 08:36.52 | *** join/#neo900 kodomo (~gregor@92.63.174.119) |
| 08:37.14 | *** join/#neo900 Wizzup_ (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 08:38.31 | *** join/#neo900 JoHnY_ (~johny@imaginarium.2600.sk) |
| 08:42.24 | *** join/#neo900 varu- (~whee@67.213.82.179) |
| 08:42.54 | *** join/#neo900 hellekin (hellekin@gateway/shell/gnu/x-lswxetbndxtvofjf) |
| 08:42.54 | *** mode/#neo900 [+v hellekin] by ChanServ |
| 08:43.25 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 08:44.17 | *** join/#neo900 ceene (~ceene@collins.gmr.ssr.upm.es) |
| 09:00.46 | *** join/#neo900 lobito (~lobito@unaffiliated/lobito) |
| 09:03.36 | *** join/#neo900 freemangordon_ (~ivo@213.222.56.174) |
| 10:21.14 | *** join/#neo900 vakkov (~vakkov@s3n104.brunel.ac.uk) |
| 10:49.26 | *** join/#neo900 vakkov (~vakkov@134.83.225.3) |
| 10:57.40 | DocScrutinizer05 | ~closed |
| 10:57.41 | infobot | it has been said that closed is http://wiki.maemo.org/Why_the_closed_packages or https://wiki.maemo.org/Fremantle_closed_packages, or http://elinux.org/N900 |
| 12:04.03 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:799:dd00:ad7f:653b:c0e:6427) |
| 13:06.55 | *** join/#neo900 bredebid (~bredebid@207.43.54.77.rev.vodafone.pt) |
| 13:37.47 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:799:dd00:ad7f:653b:c0e:6427) |
| 13:50.31 | *** join/#neo900 enyc (~enyc@muddle.enyc.org.uk) |
| 14:12.45 | *** join/#neo900 pagurus (~user@ppp-46-244-226-178.dynamic.mnet-online.de) |
| 14:13.42 | *** join/#neo900 Xiaoman (~Xiaoman@unaffiliated/xiaoman) |
| 14:46.02 | *** join/#neo900 Guest68977 (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 14:46.22 | *** join/#neo900 Wizzup_ (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 15:03.17 | *** join/#neo900 mrcaaattt (~callisto@14.192.213.220) |
| 15:14.36 | *** join/#neo900 galiven (~Andrew@50-205-116-131-static.hfc.comcastbusiness.net) |
| 15:38.14 | *** join/#neo900 louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 15:50.54 | *** join/#neo900 xman (~xman@user-0cdft6f.cable.mindspring.com) |
| 16:20.04 | *** join/#neo900 louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 16:23.02 | *** join/#neo900 illwieckz (~illwieckz@AToulon-256-1-157-105.w83-113.abo.wanadoo.fr) |
| 16:23.02 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 16:30.35 | *** join/#neo900 SylvieLorxu (~TheLastPr@541B7AAC.cm-5-4b.dynamic.ziggo.nl) |
| 16:34.41 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 16:58.33 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 17:28.55 | *** join/#neo900 SylvieLorxu (~TheLastPr@541B7AAC.cm-5-4b.dynamic.ziggo.nl) |
| 17:30.43 | *** join/#neo900 Xiaoman (~Xiaoman@unaffiliated/xiaoman) |
| 17:35.14 | *** join/#neo900 SylvieLorxu (~TheLastPr@541B7AAC.cm-5-4b.dynamic.ziggo.nl) |
| 17:52.03 | *** join/#neo900 herpderphurr (~afwang@c-98-234-221-193.hsd1.ca.comcast.net) |
| 18:21.41 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 19:37.31 | *** join/#neo900 xman1 (~xman@user-0cdft6f.cable.mindspring.com) |
| 19:46.32 | *** join/#neo900 xman (~xman@user-0cdft6f.cable.mindspring.com) |
| 19:55.13 | *** join/#neo900 enyc (~enyc@muddle.enyc.org.uk) |
| 20:11.02 | wpwrak | Pali, freemangordon: i have a question about GPIOs we need to retain for compatibility with non-open N900 software: i discussed such pins with joerg, and i get the impression that nokia actually did some quite clean abstraction, with the part that actually knows there a certain signal is, being part of (open) kernel code |
| 20:12.58 | wpwrak | in other words: it seems to me that there are few if any signals that would actually have to be at the same pin for compatibility, given that the kernel needs some amount of adaptation anyway. |
| 20:13.37 | wpwrak | would you concur with this interpretation ? or are there some nasties i haven't thought of ? |
| 20:25.42 | *** join/#neo900 lobito (~lobito@unaffiliated/lobito) |
| 20:41.56 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:799:dd00:ad7f:653b:c0e:6427) |
| 20:43.21 | freemangordon | wpwrak: well, Nokia did the so-called gpio-switch driver which isn't upstream and won;t be |
| 20:44.00 | freemangordon | the "modern" way to do stuff is to use gpio-keys driver, which has board-dependent configuration |
| 20:44.36 | freemangordon | so, in that regard, gpio numbers does not really matter, just be careful to not use a pin assigned for other function |
| 20:54.57 | wpwrak | even gpio-switch looks pretty friendly. nice maps in arch/arm/mach-omap2/board-rx51-peripherals.c and arch/arm/mach-omap2/pdata-quirks.c :) |
| 20:57.33 | wpwrak | and yes, we have to avoid the function blocks. pinmux will help with that. https://neo900.org/git/?p=misc;a=blob;f=pinmux/neo900.assign |
| 20:58.37 | wpwrak | so, no unusual placement restrictions then. kewl. thanks a lot ! |
| 21:02.58 | freemangordon | wpwrak: just double-check with Pali :) |
| 21:03.06 | DocScrutinizer05 | I still fail to see why "the kernel needs some adaption anyway" |
| 21:03.48 | DocScrutinizer05 | anyway see |
| 21:03.52 | DocScrutinizer05 | ~fptf |
| 21:03.52 | infobot | fptf is, like, the Fremantle Porting Task Force, see http://talk.maemo.org/showthread.php?t=91308 |
| 21:05.54 | wpwrak | freemangordon: yup, it's the sort of question where it is better to not act already on the first response ;-) |
| 21:06.17 | DocScrutinizer05 | givern we talk about KP, I don't see which are the changes needed in kernel |
| 21:06.55 | DocScrutinizer05 | we *might* need a new bootloader and actually I'm pretty sure we want a new and free one, but kernel? |
| 21:07.22 | freemangordon | DocScrutinizer05: KP? |
| 21:07.23 | wpwrak | DocScrutinizer05: device tree at least. and i'm sure there's some glue stuff that won't fit, drivers that may need small improvements, etc. standard stuff, basically. also, won't we switch to a more modern kernel ? |
| 21:07.42 | DocScrutinizer05 | Pali's PowerKernel aka Kernel-Power |
| 21:07.56 | freemangordon | won't work on 3730 IMO |
| 21:08.15 | freemangordon | also, i don;t see why not use 4.7 and above |
| 21:08.16 | DocScrutinizer05 | freemangordon: why? |
| 21:08.28 | DocScrutinizer05 | sure we can use 4.7 |
| 21:08.30 | freemangordon | because n900 has almost everything upstreamed |
| 21:08.43 | DocScrutinizer05 | but I don't see why we *need* a new kernel |
| 21:08.56 | freemangordon | because of 3730 |
| 21:09.16 | DocScrutinizer05 | so? that's supposed to be compatible to 3530, no? |
| 21:09.19 | freemangordon | no |
| 21:09.32 | DocScrutinizer05 | what differs? |
| 21:09.35 | wpwrak | (new kernel) because we're not identical to n900 ? :) we need new drivers (and won't need some old ones) and so on |
| 21:09.35 | freemangordon | for example ISP is totally different |
| 21:10.03 | DocScrutinizer05 | ISP? |
| 21:10.09 | freemangordon | there are other major differences as well |
| 21:10.21 | freemangordon | image signal processor, aka cameras |
| 21:10.34 | DocScrutinizer05 | wow, you might be right |
| 21:11.00 | freemangordon | I am, I am struggling with cameras on n900 for the last 3 months or some |
| 21:11.10 | DocScrutinizer05 | I know :-) |
| 21:11.15 | freemangordon | which involves ISP driver code as well |
| 21:11.21 | DocScrutinizer05 | :nod: |
| 21:11.48 | wpwrak | ah, ISP sounds interesting. will this break the old cam blob ? or does that one sit on "portable" interfaces ? (v4l, etc.) |
| 21:12.28 | DocScrutinizer05 | i'm aware we have no HS device, but that shouldn't matter. I always was under the impression all other IP was backward compatible to 34xx in 36xx/37xx (where xx = xx) |
| 21:12.48 | freemangordon | well, it is tricky, there is omap3camd which uses some proprietary (but foss) interface to v4l (iirc), we will have to reomplement that |
| 21:13.21 | freemangordon | DocScrutinizer05: no, there is no 100% compatibility |
| 21:14.06 | DocScrutinizer05 | there's a TI porting from 34 to 36 guide IIRC |
| 21:14.38 | freemangordon | good, but I prefer to have support from the kernel devs than struggle with porting KP by myself |
| 21:14.50 | DocScrutinizer05 | sure |
| 21:15.04 | freemangordon | that is why upstream is the viable option |
| 21:15.17 | freemangordon | also, DT is not *that* bad |
| 21:15.49 | wpwrak | freemangordon: don't forget defconfig ! ;-) |
| 21:15.52 | DocScrutinizer05 | DT is broken by concept, in my book |
| 21:16.46 | wpwrak | and i bet we'll find some things where existing abstractions don't quite fit, or where the driver doesn't use the chip the way we want to. especially if it's drivers for some older "compatible" chip. |
| 21:16.48 | freemangordon | wpwrak: there'll be no problem to have one and the same kernel for n900 and Neo900, with different attached .dtb |
| 21:17.14 | wpwrak | freemangordon: oh, sure. i wasn't proposing we'd need a fork ;-)) |
| 21:17.27 | *** join/#neo900 silviof (~silviof@unaffiliated/silviof) |
| 21:18.25 | DocScrutinizer05 | I was assuming we *could* run even original kernel, and until we tested that I don't believe in too many incompatibilities, particularly none that couldn't get patched in original kernel |
| 21:18.34 | freemangordon | see, right now, in 4.7-rc we have everything but ISP/cameras and DSP working(if I am not missing something) . And that includes cpufreq, PM, etc |
| 21:19.05 | freemangordon | there are still problems with PM, but the framework is there |
| 21:19.54 | DocScrutinizer05 | I'm not saying we can't use 4.7+ |
| 21:20.05 | freemangordon | look at http://elinux.org/N900#Kernel_Status |
| 21:20.37 | freemangordon | aah, I missed bluetooth |
| 21:20.56 | DocScrutinizer05 | I just say I can't believe and didn't know so gar that Nokia did invompatible changes in register addresses or semantics from 3430 to 3730 |
| 21:21.16 | DocScrutinizer05 | so far* |
| 21:22.42 | wpwrak | original kernel wouldn't make sense. we have lots of differences already in peripherals. even if you could get it to boot somehow, it wouldn't be useful. not even for development, since you'd never quite know if problems would be caused by confused drivers and such. |
| 21:22.55 | freemangordon | :nod: |
| 21:22.59 | DocScrutinizer05 | no, we don't have that many diffs in peripherals |
| 21:23.28 | wpwrak | besides, then you'd have to preserve pretty much all gpio-pin associations, which would be a little nightmare of its own |
| 21:23.29 | DocScrutinizer05 | actually for those peripherals we had in N900 there should be zilch diff |
| 21:24.10 | DocScrutinizer05 | yes we have new peripherals, that's no reason why we need a new kernel |
| 21:24.23 | DocScrutinizer05 | please see |
| 21:24.26 | DocScrutinizer05 | ~fptf |
| 21:24.26 | infobot | methinks fptf is the Fremantle Porting Task Force, see http://talk.maemo.org/showthread.php?t=91308 |
| 21:24.35 | freemangordon | it is, because we don;t have the manpower to support the old one |
| 21:24.40 | DocScrutinizer05 | yes, that is the idea to preserve as many GPIO as possible |
| 21:25.42 | freemangordon | DocScrutinizer05: what will be the PM controller? twl4030? |
| 21:26.02 | Pali | why do you care about GPIO numbers and it compatibility? |
| 21:26.14 | Pali | IIRC cssu-devel userspace use it only for cellular modem |
| 21:26.29 | wpwrak | what good would a kernel do that doesn't even have keyboard, no connectivity at all (i.e., no USB), ... ? that just doesn't make sense |
| 21:26.29 | Pali | all other stuff in cssu-devel was converted to proper kernel layers |
| 21:26.30 | freemangordon | Pali: what about different switches? |
| 21:26.40 | Pali | which switches? |
| 21:26.46 | freemangordon | kbd, power, etc |
| 21:27.10 | freemangordon | Pali: BTW, wpwrak is asking :) |
| 21:27.18 | Pali | isnot mce using /dev/input layer (which comes from gpio-keys)? |
| 21:27.41 | DocScrutinizer05 | don't get me wrong, I'm not saying we don't need any patches to make maemo work on Neo900, but that's no reason to now abandon the concept of keeping maximal compatibility to N900 |
| 21:27.44 | wpwrak | Pali: i'm trying to correctly describe the compatibility needs for GPIOs. DocScrutinizer05 always said that there was a lot of non-open user space code that depended on 1:1 compatibility |
| 21:27.56 | Pali | only sscd daemon for cellular modem needs that GPIO switches in userspace |
| 21:27.59 | wpwrak | Pali: but now it seems that this isn't really an issue |
| 21:28.00 | freemangordon | Pali: yes, iirc, I ported that, but I guess wpwrak doesn;t have the time needed to dig into mce code |
| 21:28.10 | DocScrutinizer05 | wpwrak: the compatibility needs are described in ~fptf #1 #2 |
| 21:28.35 | DocScrutinizer05 | wpwrak: we won't introduce new GPIO pin number just because we can, now |
| 21:28.38 | freemangordon | DocScrutinizer05: well, afaik the concept is to keep neo900 compatible with Maemo |
| 21:28.43 | Pali | I think there will not be compatbility for bb5 cellular chip, right? |
| 21:29.26 | DocScrutinizer05 | again |
| 21:29.29 | DocScrutinizer05 | ~fptf |
| 21:29.29 | infobot | extra, extra, read all about it, fptf is the Fremantle Porting Task Force, see http://talk.maemo.org/showthread.php?t=91308 |
| 21:29.55 | DocScrutinizer05 | he mantra: |
| 21:29.57 | DocScrutinizer05 | first we try to fix the fremantle core system foss bits to match the new hw platform. |
| 21:29.58 | DocScrutinizer05 | if that can't be done we try to patch the kernel device drivers so the new device looks like the the N900 one to userland |
| 21:30.00 | DocScrutinizer05 | if that can't be done we try to RE userland blobs or binary-patch them or write bridging-adapters from one ABI to the other |
| 21:30.01 | DocScrutinizer05 | if that can't be done we need to adapt the hw platform to more closely resemble the N900. |
| 21:30.52 | wpwrak | it seems that "first" is easily covered. no need to try to design hardware around a problem that's trivial to fix in software ;-) |
| 21:31.12 | Pali | yes |
| 21:31.36 | DocScrutinizer05 | I won't take that for given until POC exists |
| 21:32.05 | DocScrutinizer05 | my problem is I work that list bottom up |
| 21:32.32 | wpwrak | any in any case, if you want a usable system you can't use the old kernel binaries. and in any case you really don't want to be stuck with a kernel based on some ancient mainline. |
| 21:32.42 | DocScrutinizer05 | that's why I asked SERVERAL TIMES to make a port of maemo to a BB-xN |
| 21:32.55 | DocScrutinizer05 | to see what actually can get patched easily |
| 21:33.24 | DocScrutinizer05 | wpwrak: proof needed |
| 21:34.06 | DocScrutinizer05 | the 2nd half of that sentence is irrelevant to me, since that's the devel's business |
| 21:34.21 | DocScrutinizer05 | the first half is unsupported by any proof |
| 21:35.40 | wpwrak | how do you expect to, say, use the keyboard if you don't have a driver for it ? also, does a wl1837 (wlan) driver even exist for that ancient kernel ? |
| 21:35.54 | DocScrutinizer05 | I'm still pretty sure we could boot into KP5x and modprobe a few new modules, and done as far as kernel is concerned |
| 21:37.10 | DocScrutinizer05 | a wl1837 driver can get built for stock nokia kernel like it can get built for 4.7 kernel |
| 21:37.41 | wpwrak | you could probably create an out-of-tree build to add some drivers. then backport others. etc. but why would you want to do that ? if you go to the pub, do you take a route that crosses antarctica ? ;-) |
| 21:38.08 | DocScrutinizer05 | because of compatibility, heck!!! |
| 21:38.48 | DocScrutinizer05 | and we WILL NOT go do weird reassigns of GPIO just because we can, and becuse you _assume_ it doesn't matter anyway |
| 21:39.50 | DocScrutinizer05 | we are NOT going to rebuilt the complete system for a new target hw platform, the platform still is supposed to be compatible |
| 21:40.27 | DocScrutinizer05 | to the point where in theory you could flash the original fiasco and then install a Neo900 compatibility metapackage from HAM |
| 21:43.02 | DocScrutinizer05 | you are the kernel devel guys, you tell me where the build differences are between OMAP35xx and OMAP37xx target, which #DEFINEs kick in and spoil stuff |
| 21:45.03 | DocScrutinizer05 | until you show me that a certain GPIO number is OMAP35xx specific and needs patches in 37xx anyway, I'll assume we stay compatible on a hw level and sw devels won't even need to think about it |
| 21:46.02 | *** join/#neo900 SylvieLorxu (~TheLastPr@541B7AAC.cm-5-4b.dynamic.ziggo.nl) |
| 21:46.38 | DocScrutinizer05 | heck, users pondered, even *tried*, to replace the SoC in **N900** by a DM3730, and all evaluations so far came to the result that it mostly should "just work" |
| 21:47.02 | wpwrak | seems that we "kernel devel guys" already have broad agreement that the best way forward is to stay close to today's mainline, and that gpios and such can be easily reassigned. and some changes to mainline will be needed anyway. or rather, it is strongly desirable to make these changes in mainline instead of having a bunch of local hacks that would have to be ported along. |
| 21:47.21 | DocScrutinizer05 | I will ignore that |
| 21:47.23 | DocScrutinizer05 | sorry |
| 21:47.36 | DocScrutinizer05 | that's not a part of Neo900 design rules |
| 21:48.31 | DocScrutinizer05 | you're drifting away on the "we can do it in software so we don't worry about it in hw" path |
| 21:48.56 | DocScrutinizer05 | this approach always been a big NOGO for Neo900 |
| 21:50.07 | DocScrutinizer05 | agauin: as long as we can stay compatible with N900 on a hw level, WE WILL DO SO. period |
| 21:51.07 | DocScrutinizer05 | I already elaborated on the few excemptions of that rule I consider tolerable, in private channel, this noon |
| 21:52.13 | DocScrutinizer05 | they are basically all those switches and (hall-)sensors that show up as GPIO-switch in sysfs |
| 21:52.30 | DocScrutinizer05 | except those who are closely entangled with blobs |
| 21:55.30 | DocScrutinizer05 | just because we _got_ IO-extenders now, doesn't mean we will use them for everything and reassign _all_ GPIO from SoC to extenders just because we can |
| 21:55.42 | *** join/#neo900 enyc (~enyc@muddle.enyc.org.uk) |
| 21:55.51 | DocScrutinizer05 | IO-Extenders are a last resort |
| 21:56.08 | DocScrutinizer05 | and a fine means for signals we didn't even have in N900 anyway |
| 21:56.27 | DocScrutinizer05 | the rest stays untouched! |
| 21:58.48 | DocScrutinizer05 | let me be very clear on that: we WILL NOT assign every possible IO signal on lower to a IO-Extender, and in the end of the day celebrate that we have 37 unisued pins on the 2 B2B conns between LOWEr and UPPER thanks to that |
| 21:59.12 | DocScrutinizer05 | unused* |
| 22:00.18 | DocScrutinizer05 | au contraire we will try to assign / route every IO signal in system to its legacy pin on SoC and only when we run into issues we can't solve we resort to IO-extenders |
| 22:00.51 | DocScrutinizer05 | this doesn't apply to all-new signals like the whole modem (monitoring) stuff |
| 22:03.41 | DocScrutinizer05 | this applies all the more when we hear freemangordon claim that we don't have manpower to maintain the old kernel. So we ned to design the hardware in a way so it is maximum useful with unmaintained kernel |
| 22:12.11 | *** join/#neo900 louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 22:32.21 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 22:41.08 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 23:00.02 | DocScrutinizer05 | to avoid ambiguities and misconceptions: I will ignore what kernel devel guys agree upon as best way forward (despite I wholeheartedly agree with you on it) simply because it's irrelevant for how we design the Neo900 hardware |
| 23:01.50 | DocScrutinizer05 | so as long as the way Neo900 is designed will not be a *roadblock* to that best approach you and me agree upon, there's no impact from that on the Neo900 design. I don't see any such possible roadblock in keeping maximum compatibility to N900 |
| 23:11.32 | *** join/#neo900 enyc (~enyc@muddle.enyc.org.uk) |