| 00:00.00 | *** join/#maemo shentey (~shentey@p4FF0EF3A.dip0.t-ipconnect.de) |
| 02:19.42 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 02:45.48 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 02:49.15 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 02:49.45 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 02:50.13 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 03:07.51 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 03:37.32 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 05:25.55 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 06:35.52 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 06:37.03 | *** join/#maemo arcean (~arcean@131.228.32.166) |
| 07:10.37 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 07:14.02 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 07:18.20 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 07:19.55 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 07:21.45 | *** join/#maemo spinal84 (~spinal@nat4-minsk-pool-46-53-176-225.telecom.by) |
| 07:24.48 | *** part/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 07:25.56 | *** join/#maemo L29Ah (~L29Ah@cl-154.led-01.ru.sixxs.net) |
| 08:02.50 | Vajb | hmm aaa123 is not anymore, but maybe his problem was kernel power reporting that "unexpected reboot detected. Custom kernel settings not loaded" |
| 08:03.00 | Vajb | is not here* |
| 08:06.20 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 08:29.34 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 08:41.22 | *** join/#maemo KotCzarny (ariel@31.135.195.151) |
| 09:04.21 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 09:35.43 | *** join/#maemo krnlyng (~liar@178.114.55.21.wireless.dyn.drei.com) |
| 10:13.52 | *** join/#maemo kerio (kerio@bad.memes.vs.dank.ninja) |
| 12:06.01 | *** join/#maemo geaaru (~geaaru@host214-223-dynamic.250-95-r.retail.telecomitalia.it) |
| 12:13.52 | *** join/#maemo cpt_nemo (cpt_nemo@rfc1459.de) |
| 12:17.00 | *** join/#maemo jon_y (~enforcer@2001:e68:4075:ccc3:f64d:30ff:fe63:5a5a) |
| 12:26.26 | *** join/#maemo shentey (~shentey@p4FF0F939.dip0.t-ipconnect.de) |
| 13:06.20 | Pali | DocScrutinizer05: nokia n900 has 4 GPIOs for eci |
| 13:06.35 | Pali | at least they are named "eci" in stock nokia 2.6.28 kernel |
| 13:06.42 | DocScrutinizer05 | I know |
| 13:07.05 | Pali | and there is configuration /* ECI INT#2 detect connected to mic/bias line */ which is never used |
| 13:07.27 | Pali | when eci_sw1 and eci_sw2 are both set to zero |
| 13:17.25 | Pali | current mainline kernel does not support that one button n900 headset... |
| 13:17.51 | Pali | I will try to extend mainline rx51.c snd driver to support it |
| 13:18.05 | *** join/#maemo BCMM (~BCMM@unaffiliated/bcmm) |
| 13:27.43 | DocScrutinizer05 | ShadowJK: Pali: http://paste.opensuse.org/29295440 is a bq27200.sh (partial) log of a calibrate-bq27k.sh run. It's quite strange how the chip doesn't even adjust NAC anymore when it reaches 6% RSOC |
| 13:33.15 | ShadowJK | DocScrutinizer05, it hasn't reached the voltage threshold yet, which is at 3248mV, iirc. |
| 13:33.25 | DocScrutinizer05 | yep |
| 13:34.08 | DocScrutinizer05 | but that it doesn't count down even NAC is pretty strange, never realized that it works that way |
| 13:34.42 | ShadowJK | Yeah it holds it at 6% |
| 13:35.00 | ShadowJK | Eventually it does start counting down from 6% too, but I'm not sure what the conditions for that are |
| 13:35.48 | DocScrutinizer05 | EDV1 ? |
| 13:36.48 | ShadowJK | Might be if the "hidden" counter goes below 0% |
| 13:37.00 | DocScrutinizer05 | hmm |
| 13:37.27 | ShadowJK | although then it's probably also over the learning limit |
| 13:39.02 | DocScrutinizer05 | I *guess* when it really starts counting again then it does that on EDV1=1 and it counts down until 0% |
| 13:39.28 | DocScrutinizer05 | at EDVF it prolly will stall totaly |
| 13:42.22 | DocScrutinizer05 | internal counter (if such thing exists) must be way below 0% now: http://paste.opensuse.org/31660145 |
| 13:42.42 | DocScrutinizer05 | s/internal/hidden/ |
| 13:45.25 | DocScrutinizer05 | I'm surprised about apparent health of that battery, I bought it "used" yesterday and it was flatbat, I suspect it sat in that carton box like that for years |
| 13:48.14 | DocScrutinizer05 | weird is how temperature of device is rising now that bat voltage drops a bit |
| 13:48.44 | *** join/#maemo shentey (~shentey@p4FF0F939.dip0.t-ipconnect.de) |
| 13:50.52 | DocScrutinizer05 | also current drawn from battery increased from avg 220mA to avg 300mA only by plugging in USB charger while charging *disabled* and 0.0mA drawn from charger |
| 13:51.13 | Pali | yes, you need to wait for EDV1=1 |
| 13:51.34 | DocScrutinizer05 | I bet that's the damn MUSB core, plus ULPI, PHY etc |
| 13:51.54 | freemangordon | Pali: I think we would need yet another input driver |
| 13:52.06 | freemangordon | (re ECI) |
| 13:52.07 | Pali | for snd? |
| 13:52.12 | freemangordon | for eci |
| 13:52.48 | freemangordon | isn;t it supposed to act like kbd? |
| 13:52.51 | Pali | ECI would be hard to implement in state ready for upstream |
| 13:53.06 | Pali | DocScrutinizer05 already did some investigation about ECI protocol |
| 13:53.37 | Pali | but for that one button n900 headset either new input driver is needed, or integration into sound/soc/rx51.c |
| 13:54.00 | freemangordon | I guess upstream will only accept input driver |
| 13:54.01 | Pali | I will try to play with integration into rx51.c |
| 13:54.35 | freemangordon | hmm, maybe I am missing something - why it should be integrated with snd? |
| 13:54.37 | Pali | it needs functions from rx51.c, so either it will be in rx51.c or or rx51 exports funcions |
| 13:54.43 | freemangordon | ah, I see |
| 13:55.00 | Pali | also needed gpios are defined for rx51.c |
| 13:55.23 | freemangordon | maybe rx51.c should create that input driver. I have no idea if upstream will accept that |
| 13:55.41 | Pali | first I need some working code :-) and then I can modify it for upstream |
| 13:55.47 | freemangordon | yeah :) |
| 13:56.02 | freemangordon | Pali: do you have booting maemo with 4.9? |
| 13:56.12 | Pali | no |
| 13:56.15 | Pali | 4.9 is broken |
| 13:56.21 | freemangordon | oh |
| 13:56.27 | Pali | CONFIG_CMDLINE is ignored |
| 13:56.37 | Pali | and also cmdline from bootloader is ignored |
| 13:56.38 | Pali | :D |
| 13:56.40 | freemangordon | but there is a patch already? |
| 13:56.47 | Pali | so no way to specify cmdline |
| 13:56.50 | freemangordon | I saw on the ML |
| 13:57.02 | Pali | there are more patches, but people discuss how to fix it properly |
| 13:57.07 | freemangordon | ah |
| 13:57.37 | Pali | basically CONFIG_CMDLINE was broken for arm since begining |
| 13:57.47 | Pali | also cmdline from bootloader was broken for DT boot from begining |
| 13:57.58 | Pali | and in some specific situation it worked :D |
| 13:58.16 | Pali | some bugs where fixed and cmdline stopped working... |
| 13:58.17 | freemangordon | yep, I read the discussion. But I was under the impression it was decided on how the fix should like |
| 13:58.30 | freemangordon | *look like |
| 13:58.40 | freemangordon | addin the missing node |
| 13:58.53 | Pali | haha, looks like it is not simple |
| 13:59.00 | Pali | and not enough for CONFIG_CMDLINE |
| 13:59.15 | freemangordon | Pali: on the other hand - did you see the video with latest gtk3 h-d? |
| 13:59.24 | Pali | not yet |
| 13:59.37 | freemangordon | it is almost like the real one :D |
| 13:59.55 | freemangordon | wanna link? |
| 14:00.00 | Pali | y! |
| 14:00.12 | freemangordon | just a minute |
| 14:08.17 | DocScrutinizer05 | ((<Pali> ECI would be hard to implement in state ready for upstream)) then something is wrong with upstream |
| 14:12.15 | Pali | DocScrutinizer05: I mean that we need to cleanup nokia's eci code from harmattan kernel |
| 14:12.22 | Pali | cleanup will not be easy |
| 14:12.25 | DocScrutinizer05 | aah, yes |
| 14:12.51 | DocScrutinizer05 | *Nokia's code* may be hard to get upstream |
| 14:14.18 | DocScrutinizer05 | I wondered what might be wrong with upstream to not like ECI concept |
| 14:14.22 | DocScrutinizer05 | ;-) |
| 14:18.17 | DocScrutinizer05 | ShadowJK: http://paste.opensuse.org/17749468 http://paste.opensuse.org/73629256 |
| 14:18.32 | freemangordon | Pali: http://46.249.74.23/allwinner/ |
| 14:18.48 | freemangordon | the video from today, download it, do not try to play it in the browser |
| 14:19.07 | freemangordon | for some reason FF doesn;t like videos recorded by n900 :) |
| 14:19.20 | freemangordon | MoeIcenowy: ^^^ |
| 14:19.46 | DocScrutinizer05 | ShadowJK: LMD 1079 mAh -> Last Measured Discharge: 1264 mAh |
| 14:21.07 | freemangordon | arcean: see the video ^^^ |
| 14:21.28 | MoeIcenowy | freemangodron: chromium also do not like it ;-) |
| 14:22.04 | freemangordon | BTW Facebook doesn;t like n900 videos as well, there are some tags in the container |
| 14:22.20 | freemangordon | something related to geolocation iirc |
| 14:26.19 | DocScrutinizer05 | ((for some reason FF doesn;t like videos recorded by n900 :))) VLC also acts silly |
| 14:29.38 | freemangordon | hmm, seems my ISP is actually a good one - 2.5MB/s international upload, nice :) |
| 14:30.06 | freemangordon | that's for ~5 euro per month |
| 14:30.47 | MoeIcenowy | so perfect ;-) |
| 14:31.02 | xes | freemangordon: please excuse my telepathic comment about your conenction |
| 14:31.19 | freemangordon | hmm? :) |
| 14:31.35 | MoeIcenowy | my network connection for ~5 euro per month have even no public IP ;-) |
| 14:31.35 | DocScrutinizer05 | my dl bandwidth on that URL is ~700kB/s and thus only 3/4 of what's needed for streaming |
| 14:32.00 | MoeIcenowy | (although it comes with ipv6 |
| 14:33.03 | freemangordon | DocScrutinizer05: well, there are more monkeys on the branch, so you don;t get the full bandwidth I guess |
| 14:33.13 | KotCzarny | fmg: not a bad price, external static ip too? |
| 14:33.28 | KotCzarny | ahm, no static |
| 14:33.36 | freemangordon | not really static |
| 14:33.52 | freemangordon | but it hasn't changed for the last couple of years |
| 14:33.57 | KotCzarny | :) |
| 14:34.20 | DocScrutinizer05 | well, avg speed now 912KiB/s, still too low for that video to live stream it |
| 14:34.26 | MoeIcenowy | P.S. I don't think current firefox is capable of being run on a 512MB RAM tablet for daily use |
| 14:34.36 | freemangordon | it is not |
| 14:34.38 | MoeIcenowy | 256MB RAM N900 will be even worse |
| 14:34.47 | DocScrutinizer05 | the video is like 3:03, download took >220s |
| 14:35.30 | DocScrutinizer05 | so VLC stopped playback and filled buffer every 10s |
| 14:36.12 | freemangordon | maybe I should record in lower res next time |
| 14:36.32 | MoeIcenowy | yes... |
| 14:36.39 | MoeIcenowy | but when can we get the status menu? ;-) |
| 14:37.21 | freemangordon | MoeIcenowy: I ordered 1GB tablet, got 512MB :). I opened it a couple of days ago - there are 2 empty places on the board - one for DRAM and one for FLASH chip :) |
| 14:37.34 | KotCzarny | MoeIcenowy: i dont think 1gb would be comfortable enough either ;) |
| 14:37.45 | MoeIcenowy | Yes |
| 14:37.56 | MoeIcenowy | we may need a special browser for 256MB RAM |
| 14:38.01 | freemangordon | MoeIcenowy: accordin to android808, status menu should be working a bit, though I didn;t test it |
| 14:38.01 | KotCzarny | few days ago i was playing with self built droid on oppc |
| 14:38.03 | KotCzarny | opipc |
| 14:38.20 | KotCzarny | and caching things in mem would effect in oom kills |
| 14:38.30 | freemangordon | the same goes for hildon-home |
| 14:38.56 | xes | freemangordon: nice progress! |
| 14:38.57 | KotCzarny | unfortunatelly web is memory hungry (big media) nowadays |
| 14:39.08 | freemangordon | MoeIcenowy: besides n900, is there another device with 256? |
| 14:39.28 | freemangordon | xes: ;) |
| 14:39.34 | MoeIcenowy | with ARMv7? I don't know any other with 256MB RAM |
| 14:39.51 | MoeIcenowy | although I have a WIP light-weight development board with 64MB ;-) |
| 14:40.07 | freemangordon | BTW, dillo might have chance |
| 14:40.14 | xes | freemangordon: any plan to use a kernel patched with BFQ and MuQSS? |
| 14:40.21 | MoeIcenowy | we need dillo-touch ;-) |
| 14:40.28 | freemangordon | but it still far from being ready |
| 14:41.14 | freemangordon | xes: no. I don;t even know what MuQSS is :) |
| 14:41.46 | xes | anyway palemoon has some chance to be usable |
| 14:41.58 | freemangordon | MoeIcenowy: that shouldn;t be that hard |
| 14:42.08 | MoeIcenowy | (offtopic) I wonder whether there's any binarys meaningful to run on a Wine on ARM |
| 14:42.11 | freemangordon | once the engine itself is ready |
| 14:42.19 | xes | freemangordon: http://ck-hack.blogspot.com |
| 14:42.22 | DocScrutinizer05 | freemangordon: please don't mix physically implemented RAM with free memory |
| 14:42.47 | freemangordon | DocScrutinizer05: hmm? in what regard? |
| 14:42.56 | MoeIcenowy | DocScrutinizer05: on modern Flash storages, even SD cards, are easily to be worn with swap |
| 14:43.02 | DocScrutinizer05 | IroN900:~# free |
| 14:43.04 | DocScrutinizer05 | <PROTECTED> |
| 14:43.05 | DocScrutinizer05 | Mem: 245540 240152 5388 0 20120 55696 |
| 14:43.25 | freemangordon | DocScrutinizer05: so? |
| 14:43.54 | DocScrutinizer05 | so a browser doesn't have a 256MB of memory available on a 256MB RAM device |
| 14:43.59 | freemangordon | sure |
| 14:44.05 | MoeIcenowy | sure |
| 14:44.10 | MoeIcenowy | we all known that ;-) |
| 14:44.25 | DocScrutinizer05 | it seemed like you're ignoring it though :-) |
| 14:44.40 | MoeIcenowy | I think it's a common sense ;-) |
| 14:45.09 | DocScrutinizer05 | going 256->512MB RAM on maemo means like a 10 times the amount of free memory available for browser |
| 14:45.22 | freemangordon | DocScrutinizer05: yes, if it is microb |
| 14:45.46 | freemangordon | if it is FF... makes no difference, it will still lack memory :) |
| 14:45.46 | MoeIcenowy | is it still possible to build a old browser on a new system? ;-) |
| 14:45.58 | freemangordon | sure it is, but what's the point |
| 14:46.28 | freemangordon | even on quad core old JS engine on microb will struggle |
| 14:47.52 | freemangordon | anyone here with jolla phone? |
| 14:48.04 | freemangordon | how's browser memory usage there? |
| 14:48.06 | DocScrutinizer05 | why? |
| 14:48.10 | freemangordon | ^^^ |
| 14:48.17 | DocScrutinizer05 | nfc |
| 14:48.25 | freemangordon | afaik it is qtmozembed |
| 14:48.53 | freemangordon | that would give us a clue on how much can be stripped from gecko in terms of memory usage |
| 14:49.10 | DocScrutinizer05 | it seems I never managed to install a sshd on that device, so sorry I have no access to gather such info |
| 14:49.11 | freemangordon | I mean - modern gecko |
| 14:50.08 | DocScrutinizer05 | tbh I didn't really touch jollaphone for years |
| 14:50.31 | freemangordon | I'll ask on #jollamobile |
| 14:50.32 | DocScrutinizer05 | it's simply no nice experience to touch it |
| 14:50.38 | freemangordon | :) |
| 14:51.49 | DocScrutinizer05 | and fuzzing around with a device I **need to send in for reflash** when I do a little oopsie?!??! really, no way |
| 14:52.50 | freemangordon | what? you can;t flash it? |
| 14:52.53 | DocScrutinizer05 | no |
| 14:53.03 | freemangordon | cuuute |
| 14:53.19 | freemangordon | but,but... why? |
| 14:53.48 | DocScrutinizer05 | Jolla must not provide the sekrit sauce closed blob shit stored for snapdragon modem in the "private" partitions |
| 14:54.08 | freemangordon | MoeIcenowy: do we have any chance for support on that gpu driver stuttering bug? |
| 14:54.25 | freemangordon | ah |
| 14:54.45 | freemangordon | wonders why they didn;t go for omap |
| 14:55.00 | DocScrutinizer05 | that's what you get from modem integration into SoC, where basicaly modem is DOM0 and linux is only a SOM-U |
| 14:55.06 | DocScrutinizer05 | DOM-U |
| 14:55.28 | freemangordon | mhm |
| 14:55.40 | DocScrutinizer05 | FUUUUUBAAAAR |
| 14:56.18 | DocScrutinizer05 | only good for consumer products for sheep |
| 14:56.46 | DocScrutinizer05 | which alas was Nokia's and now is Jolla's approach to FOSS |
| 14:57.33 | DocScrutinizer05 | to then FOSS means you may use gcc to compile your apps, but sou have to keep your finger out of "THEIR" OS |
| 14:57.41 | DocScrutinizer05 | to them* |
| 14:58.14 | DocScrutinizer05 | started with Aegis, that stinking pile of shit |
| 14:59.09 | DocScrutinizer05 | and it's only a lucky coincidence that we didn't have Aegis on fremantle already |
| 14:59.23 | freemangordon | looks like |
| 14:59.32 | DocScrutinizer05 | they always planned to go that path |
| 14:59.36 | Pali | and that nolo can boot anything :-) |
| 14:59.44 | DocScrutinizer05 | just failed to implement it for fremantle |
| 15:00.21 | DocScrutinizer05 | Pali: that's an immanent part of such TC concept like Aegis |
| 15:00.49 | DocScrutinizer05 | bootloader only boots signed OS, and OS only grants certain permissions to any process |
| 15:00.52 | freemangordon | well, on harmattan there is some thing called "open mode" afaik |
| 15:00.56 | freemangordon | at least |
| 15:01.07 | Pali | which locks your phone |
| 15:01.12 | DocScrutinizer05 | yep |
| 15:01.23 | freemangordon | locks as in? |
| 15:01.35 | Pali | nand is locked to read-only mode |
| 15:01.36 | DocScrutinizer05 | open mode actially means "secure element locked" mode |
| 15:01.44 | Pali | bootloader and CAL |
| 15:02.07 | Pali | and IIRC omap crypto HW too |
| 15:02.09 | DocScrutinizer05 | so you can't even change device lockcode |
| 15:02.19 | freemangordon | I see |
| 15:02.25 | DocScrutinizer05 | Pali: yes, afaik that's correct |
| 15:02.51 | Pali | but n900 has locked AES hw crypto too :-( |
| 15:03.07 | freemangordon | Pali: not really, it is just not unlocked |
| 15:03.12 | DocScrutinizer05 | hmm, not sure about that |
| 15:03.26 | DocScrutinizer05 | or what freemangordon said |
| 15:03.27 | Pali | locked == not unlocked |
| 15:03.42 | freemangordon | this is rather a bug in nolo, than intentional |
| 15:03.49 | DocScrutinizer05 | :nod: |
| 15:03.55 | Pali | and it can be done only in signed x-loader image |
| 15:04.12 | freemangordon | Pali: maybe it is time to crack the keys ;) |
| 15:04.21 | Pali | unless we got signing keys for x-loader aes remains locked |
| 15:04.34 | Pali | cracking aes128? |
| 15:04.39 | DocScrutinizer05 | no, when it's not locked, it can get unlocked aby time until you lock the secure monitor or whatever the name |
| 15:04.47 | Pali | bruteforce is slow |
| 15:05.02 | freemangordon | afaik it is sha1, which is well, considered weak |
| 15:05.06 | Pali | and I do not know any vulnerability in omap3 implementation |
| 15:05.09 | freemangordon | why aes? |
| 15:05.10 | DocScrutinizer05 | as I understand it |
| 15:05.21 | freemangordon | it is not encrypted, just signed |
| 15:05.33 | Pali | I think I read somewhere there parts are encoded by aes128 |
| 15:05.46 | freemangordon | hmm, no, afaik |
| 15:05.57 | Pali | I do not remember details |
| 15:06.07 | freemangordon | all the code is plain, you just hav a signature in the header, iirc |
| 15:06.15 | Pali | but still, generating new valid sha1 signature is not fun! |
| 15:06.19 | DocScrutinizer05 | ~listvalues omappedia |
| 15:06.28 | DocScrutinizer05 | ~listvalues omapedia |
| 15:06.33 | DocScrutinizer05 | dang |
| 15:06.45 | Pali | it was never documented on omapedia |
| 15:07.30 | DocScrutinizer05 | http://www.droid-developers.org/wiki/Booting_chain |
| 15:07.58 | Pali | something is there: http://wiki.maemo.org/Firmware_hacking |
| 15:08.12 | DocScrutinizer05 | http://www.and-developers.com/custom_recovery:mbmloader_replacement_attack no idea if any of that is useful |
| 15:09.06 | Pali | "Buy this domain." |
| 15:09.58 | Pali | http://www.droid-developers.org/wiki/Cryptography |
| 15:10.57 | freemangordon | Pali: yes, droid bootloader is crtypted, n900 is not |
| 15:11.20 | freemangordon | just look in n900 flash images |
| 15:11.24 | DocScrutinizer05 | http://www.omappedia.org/wiki/Bootloader_Project |
| 15:11.30 | freemangordon | nothing crypted there |
| 15:13.27 | DocScrutinizer05 | Note: If you are using an HS (High Security) OMAP device, an extra step is required. First, build x-load.bin using the steps above. Then, download the MShield signing tool and use the commands below. Contact your TI representative to get access to this tool. |
| 15:13.28 | DocScrutinizer05 | # cd mshield-dk-root-folder |
| 15:15.00 | freemangordon | and this signs the image, most probably rsa signature with 1024bit key |
| 15:15.26 | DocScrutinizer05 | :nod: |
| 15:15.56 | DocScrutinizer05 | however it seems non-HS SoC don't need a common signature, they don't need *any* signature? |
| 15:16.21 | DocScrutinizer05 | so I assume they have a different core boot |
| 15:16.42 | freemangordon | so, what we have (most probably) is sha1 hash signed wuth 1024bit key |
| 15:16.54 | freemangordon | which should be close to be breakable |
| 15:17.02 | DocScrutinizer05 | *is* N900 a HS device? |
| 15:17.16 | freemangordon | yes |
| 15:17.26 | DocScrutinizer05 | sorry, I am supposed to be the one to know, but... got headache |
| 15:17.51 | *** join/#maemo spinal84 (~spinal@nat4-minsk-pool-46-53-176-225.telecom.by) |
| 15:18.40 | Pali | just to note, nobody has found any colision in sha1 yet! |
| 15:19.34 | DocScrutinizer05 | freemangordon: isn't there a sort of "sealing" action executed during boot in xloader, which forbids further config changes to M-Shield? and is our xloader actually doing that sealing? |
| 15:20.23 | Pali | DocScrutinizer05: x-loader is switching cpu to secure mode and then boot nolo |
| 15:20.52 | Pali | once you switch to secure mode, it is not possible to switch back (only reboot or smc instruction) |
| 15:21.01 | freemangordon | :nod: |
| 15:21.03 | DocScrutinizer05 | that's what I meant, yes |
| 15:21.18 | Pali | and aes needs to be enabled in that x-loader code before switching... |
| 15:21.28 | DocScrutinizer05 | :nod: |
| 15:21.54 | DocScrutinizer05 | secure mode assigns AES hw accel to secure domain, while open mode it's available to userland |
| 15:21.59 | DocScrutinizer05 | afaik |
| 15:22.42 | DocScrutinizer05 | so AES accel is "only available on *non*-HS devices" |
| 15:23.29 | DocScrutinizer05 | while on HS devices (in HS mode) there's still crypto accel but only to monitor |
| 15:23.52 | DocScrutinizer05 | monitor aka smc |
| 15:24.11 | DocScrutinizer05 | the hw is always the same, I am pretty sure about that |
| 15:25.28 | DocScrutinizer05 | basically OMAP implements TZ/M-Shield as an additional addr line which only goes 1 when CPU in smc mode (from a sw exception) |
| 15:25.47 | Pali | I read that TRM and via l3 or l4 firewall you can configure which address space you can access |
| 15:26.07 | Pali | and it is configured to disallow access to aes address space |
| 15:26.18 | Pali | and also disallow access to l3 or l4 firewall |
| 15:26.23 | DocScrutinizer05 | and you can config each hw IP block incl crypto to either have a "public" hw address or a secure domain (secure addr line = 1) hw addr |
| 15:26.40 | DocScrutinizer05 | yes, exactly |
| 15:27.03 | Pali | and firewall is for n900 configured in way that you even cannot read current settings |
| 15:27.39 | DocScrutinizer05 | that TZ stuff is pretty versatile and seemingly implemented in a glitch free way |
| 15:27.44 | Pali | I scanned address space and we have only unlocked sha1 and md5 crypto access |
| 15:28.19 | freemangordon | Pali: what do you need that aes for? |
| 15:28.37 | Pali | currently... nothing :-) |
| 15:28.38 | DocScrutinizer05 | iirc you can config firtually every page in RAM and NAND to be either secure domain or open domain |
| 15:29.09 | Pali | I think l3 or l4 firewall will allows you to do that |
| 15:29.14 | KotCzarny | https://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ |
| 15:29.14 | KotCzarny | :) |
| 15:29.22 | Pali | but only if you have unlocked firewall :D which is not on n900 |
| 15:29.25 | DocScrutinizer05 | really every shitty little timer can get configured if it's TZ secure or public |
| 15:30.41 | DocScrutinizer05 | there's a IP block called "mailbox", it's a multiple FIFO to exchange bytes (or words) between CPU cores. You can configure each single FIFO of mailbox to be secure or public |
| 15:31.46 | DocScrutinizer05 | ARM did a proper job with TZ |
| 15:33.45 | DocScrutinizer05 | but (like Aegis) the more versatile the stuff gets, the more complex it gets to correctly configure and set it up. And there *might* be bugs in sw doing the config |
| 15:34.27 | DocScrutinizer05 | first HARM Aegis policy versions allowed modprobe to load unsigned modules, or somesuch |
| 15:34.29 | DocScrutinizer05 | ;-P |
| 15:35.14 | DocScrutinizer05 | similar loopholes might exist in TZ/M-Shiled particular sw implementations |
| 15:35.53 | freemangordon | I've tried to find ppa function that might allow us to tweak the FW, but failed |
| 15:36.06 | DocScrutinizer05 | I recall some hacker exploited a buffer overflow of sorts in a SMC function call |
| 15:36.09 | Pali | yes, but there are two problems: 1) we do not have source code to look for bugs, 2) we even do not have binaries for all and we do not know all algorithms in use |
| 15:36.28 | freemangordon | we have the binaries |
| 15:36.38 | freemangordon | BTW, there is some sort of developer key afaik |
| 15:36.47 | DocScrutinizer05 | o.O |
| 15:37.06 | Pali | and signing program for windows |
| 15:37.11 | freemangordon | if we can only find it :) |
| 15:37.20 | Pali | iirs that key is part of that signing program |
| 15:37.37 | freemangordon | Pali: being windows is not a problem , you have wine nad WV after all |
| 15:37.46 | freemangordon | *VM |
| 15:37.57 | Pali | I doubt that dev key will work on n900 |
| 15:38.12 | freemangordon | Pali: I remember something in CAl referenced it |
| 15:38.16 | freemangordon | *CAL |
| 15:38.28 | Pali | in CAL are some certificates and keys |
| 15:38.38 | Pali | but I have no idea who uses them |
| 15:38.42 | Pali | and how |
| 15:39.03 | freemangordon | and, iirc, one of those is some developer key |
| 15:39.23 | freemangordon | we can use to sign our own ppa, that is executed in secure mode |
| 15:40.05 | Pali | CSST_SDP3430_v2_5_Binary_Release.zip |
| 15:40.25 | Pali | it is that signing program |
| 15:40.27 | freemangordon | yep, have it somewhere |
| 15:40.40 | Pali | http://forum.gsmhosting.com/vbb/f83/nokia-rsa-private-key-195f111a9543a8644e77e1677296ab23-free-1490743/ |
| 15:40.43 | freemangordon | you just need to load the correct keys |
| 15:42.09 | DocScrutinizer05 | hmm, might be a key for BB5 aiui |
| 15:42.28 | DocScrutinizer05 | well, BB5 also has an OMAP iirc |
| 15:42.35 | DocScrutinizer05 | not sure which, though |
| 15:43.06 | xes | ..an interesting document: https://www.uni-oldenburg.de/fileadmin/user_upload/informatik/ag/svs/download/thesis/Reichel_Sebastian.pdf |
| 15:43.41 | freemangordon | easy to be checked, just calculate a signature with that key and compare it with modem firmware signature or nolo signature |
| 15:43.43 | Pali | yes, I read sre's thesis |
| 15:44.14 | *** join/#maemo chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 15:53.03 | DocScrutinizer05 | it's a tad obsolete |
| 15:53.34 | DocScrutinizer05 | (thesis) |
| 15:54.44 | xes | DocScrutinizer05: we too :) |
| 15:54.51 | DocScrutinizer05 | hehe yes |
| 15:54.54 | DocScrutinizer05 | LOL |
| 15:56.46 | DocScrutinizer05 | maemo: kernel: custom - ummm |
| 15:57.05 | DocScrutinizer05 | (Table1.1 |
| 15:57.07 | DocScrutinizer05 | ) |
| 15:57.41 | DocScrutinizer05 | openmoko: kernel: custom - hell no |
| 15:58.28 | DocScrutinizer05 | maemo: userland software: GNU based - if only!! |
| 16:00.01 | DocScrutinizer05 | that's what basically *everybody* seems to get wrong (or *I* always got wrong after an intitial phase where I seem to got it right): maemo KERNEL is FOSS, maemo USERLAND is partially custom, see ~closed |
| 16:02.29 | DocScrutinizer05 | maybe by "custom" he means "not mainlined" (aka upstream?) |
| 16:03.11 | DocScrutinizer05 | but then, _who_ IS upstream? |
| 16:03.24 | DocScrutinizer05 | Linus? |
| 16:04.06 | DocScrutinizer05 | sounds pretty much like a moving phantom target |
| 16:06.12 | DocScrutinizer05 | it seems to me that large parts of IT experts have to more thoroughly adopt the concept/idea of 'middleware', and that a system consists of kernel - middleware/libs - apps |
| 16:07.46 | DocScrutinizer05 | what hurts most in fremantle are the closed middleware blobs, plus the lack of any proper interface/API and functional definitions/descriptions of that middleware |
| 16:08.34 | DocScrutinizer05 | there are a few closed blob apps too, but those would be easy to re-inplement in FOSS if only the middleware APIs would be available |
| 16:09.21 | DocScrutinizer05 | just like the middleware itself would be almost a nobrainer to re-implement if only those APIs... |
| 16:15.56 | DocScrutinizer05 | SpeedEvil had put it in a most precise way years ago, regarding the mess in maemo with that middleware. Alas I can't find the exact wording anymore, but it was like "it's _designed_ in a way to be everything entangled with everything, so you can't take out a single bit without making the whole thing collapse. And no docs at all just to the supposed purpose to ensure it stays like this" |
| 16:16.50 | KotCzarny | sounds like systemd description |
| 16:17.17 | DocScrutinizer05 | yes, it's very similar |
| 16:17.52 | DocScrutinizer05 | just fremantle isn't that monolithic |
| 16:18.20 | DocScrutinizer05 | well, actually systemd also isn't, but it *looks* even more like it was |
| 16:18.52 | Pali | systemd is in one repository and they do not have defined stable api between components |
| 16:19.09 | Pali | maemo has (or had) some stable api between components... |
| 16:19.14 | DocScrutinizer05 | neither did Nokia |
| 16:19.24 | DocScrutinizer05 | well, *some* |
| 16:19.54 | DocScrutinizer05 | many d-bus signals/msgs are not defined at all |
| 16:20.02 | DocScrutinizer05 | many libs are not defined either |
| 16:20.57 | DocScrutinizer05 | see the whole libisi and csd and whatnpt mess |
| 16:21.07 | DocScrutinizer05 | whatnot* |
| 16:21.24 | DocScrutinizer05 | ~closed |
| 16:21.24 | infobot | extra, extra, read all about it, closed is http://wiki.maemo.org/Why_the_closed_packages or https://wiki.maemo.org/Fremantle_closed_packages, or http://elinux.org/N900 |
| 16:22.00 | DocScrutinizer05 | if there were decent APIs, all those closed blobs would be easy to FOSSify |
| 16:22.23 | Pali | yes, some header files are missing... |
| 16:23.30 | DocScrutinizer05 | and a header file is no comprehensive API spec per se yet. A var int x34tz may be specified in .h yet you have no fucking clue how to use it |
| 16:33.40 | Pali | who designed that maemo 5 architecture? |
| 16:34.07 | DocScrutinizer05 | when you have a int status, you need a enum 0: OK, 1: PIN error, 2: No signal etc |
| 16:34.20 | DocScrutinizer05 | Nokia and Colabora plus a few others |
| 16:38.42 | DocScrutinizer05 | and that is the root cause of a lot of problems with FOSSifying stuff it seems, since Colab must not publish source code they made for Nokia as subcontractor, and Nokia doesn't really have the copyright on the source either |
| 16:41.15 | DocScrutinizer05 | https://www.collabora.com/ |
| 16:44.03 | DocScrutinizer05 | https://www.collabora.com/industries/oem.html >> Hardware enablement --- Whether your products are intended to run on ARM or x86, there are always components that require particular attention. The Linux kernel has come a very long way however there is still (and will always be) a need for device drivers and general platform optimizations for your product to shine.<< |
| 16:44.42 | DocScrutinizer05 | and right they are |
| 16:45.35 | DocScrutinizer05 | thus I don't buy the "only mainline" approach, it won't yield optimum results |
| 16:46.09 | DocScrutinizer05 | and actually a generic mainline kernel is bloatware |
| 16:47.04 | KotCzarny | i think mainlining trick ensures that your driver/code wont stop working unexpectedly |
| 16:47.43 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 17:56.24 | DocScrutinizer51 | <PROTECTED> |
| 17:56.46 | DocScrutinizer51 | 18:54 4120 99 99 -19 1246 1246 1246 65535 3748 26 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 |
| 17:57.51 | DocScrutinizer51 | 3748 minutes time to empty not bad for roaming device with IRC online, eh? |
| 17:59.05 | DocScrutinizer51 | 'roaming' = not on home WLAN |
| 18:17.42 | *** join/#maemo M4rtinK (~M4rtinK@77.48.149.46) |
| 18:22.43 | Vajb | just a quick hint. Telegram windows desktop ap seems to work fast. Messages appear on maemo pidgin and desktop about the same time. |
| 18:24.20 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 18:53.18 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 19:04.05 | *** join/#maemo robink_ (~quassel@unaffilated/robink) |
| 19:28.04 | sicelo- | Vajb: that's Telegram's selling point .. they say speed :) |
| 19:28.27 | kerio | >telegram |
| 19:28.34 | kerio | please no |
| 20:03.26 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 20:15.27 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 20:28.07 | Vajb | sicelo-: it sure is fast. And works quite well so far. If only it would integrate as well as yappari. |
| 20:51.24 | *** join/#maemo Natch (~Natch@h-155-122.a444.priv.bahnhof.se) |
| 20:55.52 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 21:05.40 | *** join/#maemo phlixi (~phlixi@ppp-88-217-54-66.dynamic.mnet-online.de) |
| 21:22.10 | ceene | i should place a kickstarter to pay me for coding bits for maemo |
| 21:22.48 | ceene | i had a plan for reusing yappari gui as frontend for a qt based telegram librar i found |
| 21:22.58 | ceene | but tbh, i lost interest |
| 21:23.17 | ceene | i even ended up buying an android phone :/ |
| 21:23.44 | ceene | if i got paid to code for maemo i would leave this soul sucking job i have right now |
| 21:24.23 | kerio | ceene: i'd settle for whatsapp web |
| 21:24.43 | kerio | ༼ 㤠â_â ༽㤠give whatsapp web client |
| 21:25.01 | ceene | kerio: problem is the webapp communicates with the phone app, which is the one doing the communication with whatsapp servers |
| 21:25.07 | kerio | yes |
| 21:25.14 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 21:25.17 | kerio | i already have whatsapp running |
| 21:25.22 | ceene | so web client means writing a client |
| 21:25.27 | kerio | in android x86_64 |
| 21:25.30 | kerio | on my server |
| 21:25.57 | ceene | you could run web whatsapp on chromium |
| 21:26.14 | kerio | or i could actually keep some ram for the rest of the phone |
| 21:26.21 | ceene | but chrome/chromium on maemo is basically unusable due to low ram |
| 21:28.55 | kerio | whatsapp is a strange IM server |
| 21:29.04 | kerio | where you login by having the server scan a qr code with a webcam |
| 21:31.21 | ceene | you can always vnc to your x86 android |
| 21:31.32 | ceene | that's probably the less error prone way |
| 21:34.41 | ceene | i thought about a software that processes sqlite databases of whatsapp |
| 21:35.13 | ceene | that would allow the writing of a proxy |
| 21:40.26 | kerio | how do you send messages tho |
| 21:41.27 | ceene | good question |
| 21:41.45 | ceene | faking user input |
| 21:41.54 | ceene | sounds troublesomo |
| 21:42.01 | kerio | whatsapp web :3 |
| 21:42.23 | ceene | running android on lxc on maemo |
| 21:42.48 | ceene | i think there's some project to do just that on sailfish |
| 21:42.50 | kerio | no but honestly i want whatsapp web/client way more than whatsapp standalone |
| 21:43.04 | kerio | this whatsapp on the cloud thing is working incredibly well with my lappy |
| 21:43.27 | ceene | chrome it is, then |
| 21:43.45 | kerio | now if only i could run whatsapp in a freebsd jail rather than having to run a full vm :^) |
| 21:44.40 | ceene | until and unless android code is upstreamed to linux kernel... |
| 21:44.47 | ceene | not even under lxc |
| 21:59.13 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |