| 00:03:31 | | Quit ender` (Quit: A computer program will always do what you tell it to, and seldom what you want it to.) |
| 00:06:50 | kugel | grml, I can't use apache v2 code in rockbox (?) |
| 00:07:41 | | Quit LambdaCalculus37 (Quit: Fwump) |
| 00:08:20 | saratoga | google says its GPLv3, not v2, so you probably shouldn't |
| 00:10:25 | | Quit user890104 (Read error: Connection reset by peer) |
| 00:10:33 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 00:10:56 | | Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) |
| 00:10:57 | kugel | this is xml, I can't just re-implement it without ending up with the exact same (besides indentation maybe) |
| 00:11:16 | | Quit freddyb (Client Quit) |
| 00:13:53 | saratoga | assuming you re-implement it without copying from the old to the new you're ok |
| 00:14:25 | saratoga | so i guess make a note of the fields and then construct an XML file to store them using your knowledge of XML file structure |
| 00:18:26 | | Quit Buschel (Ping timeout: 255 seconds) |
| 00:25:44 | | Join Buschel [0] (~chatzilla@p54B67603.dip.t-dialin.net) |
| 00:27:24 | | Join user890104_ [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 00:27:57 | | Quit user890104 (Read error: Connection reset by peer) |
| 00:27:59 | | Quit user890104_ (Read error: Connection reset by peer) |
| 00:28:06 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 00:30:30 | | Quit bertrik (Quit: :tiuQ) |
| 00:33:18 | Buschel | imho it is a good assumption that FS #11627 is a duplicate of FS11608. any objections to close FS #11627? |
| 00:40:27 | | Quit user890104 (Ping timeout: 272 seconds) |
| 00:44:20 | | Quit sideral (Quit: Leaving.) |
| 00:49:10 | | Part toffe82_ |
| 00:51:27 | | Quit krazykit (Quit: brb locally) |
| 00:51:50 | | Join krazykit [0] (~kkit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 00:53:21 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:02:19 | | Quit Buschel (Ping timeout: 240 seconds) |
| 01:02:59 | | Quit {phoenix} (Remote host closed the connection) |
| 01:16:17 | | Quit BlakeJohnson86 (Quit: Leaving.) |
| 01:23:17 | | Quit ReimuHakurei_ (Quit: Leaving) |
| 01:24:15 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
| 01:25:57 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 01:26:23 | | Quit factor (Ping timeout: 255 seconds) |
| 01:29:35 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 01:31:05 | | Quit DerPapst (Quit: Leaving.) |
| 01:31:17 | | Quit Kupop (Ping timeout: 264 seconds) |
| 01:46:31 | | Quit kugel (Ping timeout: 252 seconds) |
| 01:46:51 | | Quit S00row (Read error: Connection reset by peer) |
| 01:49:24 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 01:55:09 | | Join Boldfilter [0] (~Boldfilte@99-120-142-250.lightspeed.jcvlfl.sbcglobal.net) |
| 02:00 |
| 02:00:59 | | Quit domonoky1 (Read error: Connection reset by peer) |
| 02:01:09 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 02:15:20 | | Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) |
| 02:20:08 | | Join Loto_ [0] (~Loto@S01060012171a84e3.no.shawcable.net) |
| 02:22:46 | | Quit Loto (Ping timeout: 240 seconds) |
| 02:33:48 | | Quit InsDel (Read error: Connection reset by peer) |
| 02:40:34 | | Quit xxcv () |
| 02:45:51 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 02:45:52 | | Quit S00row (Read error: Connection reset by peer) |
| 02:47:19 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 02:53:23 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:22:34 | | Quit BHSPitMonkey (Read error: Connection reset by peer) |
| 03:33:01 | | Quit liar (Quit: Leaving) |
| 03:38:24 | | Quit madalu (Remote host closed the connection) |
| 03:48:14 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 03:54:10 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 03:56:14 | | Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) |
| 03:57:56 | | Quit S00row (Read error: Connection reset by peer) |
| 04:00 |
| 04:00:31 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 04:03:02 | | Quit bluebrother (Disconnected by services) |
| 04:03:03 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 04:15:36 | | Join Barahir [0] (~jonathan@frnk-590f4199.pool.mediaWays.net) |
| 04:19:41 | | Quit Barahir_ (Ping timeout: 276 seconds) |
| 04:24:07 | | Quit anewuser (Ping timeout: 240 seconds) |
| 04:34:58 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 04:37:00 | | Quit ReimuHakurei (Quit: Leaving) |
| 04:37:12 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
| 04:46:20 | | Quit dys (Ping timeout: 276 seconds) |
| 04:46:28 | | Join dys [0] (~andreas@krlh-5f721792.pool.mediaWays.net) |
| 04:51:32 | | Quit TheSeven (Ping timeout: 276 seconds) |
| 04:53:27 | *** | Saving seen data "./dancer.seen" |
| 04:54:29 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.14) |
| 04:54:44 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:54:45 | saratoga | oh hell i just converted a filter to ASM that isn't actually used |
| 04:57:38 | | Quit amiconn (Disconnected by services) |
| 04:57:38 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:57:39 | | Quit pixelma (Disconnected by services) |
| 04:57:41 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:57:43 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:57:58 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:58:11 | | Quit LambdaCalculus37 (Quit: Zzzzzzz) |
| 05:00 |
| 05:01:31 | | Quit S_a_i_n_t (Ping timeout: 240 seconds) |
| 05:34:08 | | Quit ps-auxw (Ping timeout: 255 seconds) |
| 05:41:20 | | Quit clone4crw (Ping timeout: 245 seconds) |
| 05:43:32 | | Join clone4crw [0] (~Calvin@96-42-80-202.dhcp.roch.mn.charter.com) |
| 05:44:07 | | Quit anewuser (Ping timeout: 240 seconds) |
| 05:45:29 | | Join ps-auxw [0] (~arneb@p4FF7FF8A.dip.t-dialin.net) |
| 05:45:40 | | Quit clone4crw (Client Quit) |
| 05:48:28 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 05:52:45 | | Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
| 06:00 |
| 06:07:36 | | Quit InsDel (Read error: Connection reset by peer) |
| 06:25:07 | | Join ReimuHakurei_ [0] (~reimu@74.112.212.15) |
| 06:25:09 | | Quit ReimuHakurei_ (Client Quit) |
| 06:53:28 | *** | Saving seen data "./dancer.seen" |
| 06:57:26 | | Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
| 07:00 |
| 07:01:55 | | Quit froggyman (Read error: Connection reset by peer) |
| 07:04:04 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 07:10:52 | | Join Horschti [0] (~Horschti@xbmc/user/horscht) |
| 07:11:48 | | Join mordocai [0] (~mordocai@66.119.9.243) |
| 07:14:06 | | Quit Horscht (Ping timeout: 265 seconds) |
| 07:23:07 | mordocai | Just dobule checking, but it looks like rockbox does not support iRiver e200's? |
| 07:23:10 | mordocai | double* |
| 07:25:53 | saratoga | correct |
| 07:25:58 | saratoga | i've never even heard of that player |
| 07:27:56 | mordocai | http://www.iriver.com/product/view.asp?pCode=001&pNo=69 :P. It looks pretty nice to me. Luckily it already plays .ogg, so I wouldn't -have- to use rockbox to get ogg to work. (I assume rockbox makes ogg work?). [I'm looking into what portable music player to buy] |
| 07:29:53 | Sundiver | iriver was making pretty neat players |
| 07:30:30 | mordocai | Sundiver: Was? |
| 07:30:48 | Sundiver | Well, I meant flash players |
| 07:31:01 | saratoga | if you guys want to talk about iriver, go over to rockbox-community |
| 07:31:10 | Sundiver | sorry |
| 07:31:39 | Sundiver | I just finished theme for RB for my clip+ |
| 07:32:23 | | Part mordocai ("Leaving") |
| 07:32:27 | saratoga | does anyone understand pipeline scheduling on arm11 particularly well? |
| 07:32:32 | saratoga | i'm confused by their diagrams |
| 07:32:44 | Sundiver | I'm not |
| 07:33:14 | Sundiver | arm has awful datasheet |
| 07:34:57 | Sundiver | BTW, can I just delete unused plugins, themes from my player? |
| 07:36:28 | saratoga | sure |
| 07:36:59 | Sundiver | Thanks saratoga! |
| 07:46:22 | | Quit Boldfilter (Quit: Boldfilter) |
| 08:00 |
| 08:09:33 | | Quit xavieran (Remote host closed the connection) |
| 08:12:04 | | Join xavieran [0] (~xavieran@ppp118-209-137-192.lns20.mel6.internode.on.net) |
| 08:13:39 | | Join stoffel [0] (~quassel@p57B4C0EB.dip.t-dialin.net) |
| 08:14:18 | | Quit JesusFreak316 (Ping timeout: 245 seconds) |
| 08:39:08 | | Quit xxcv () |
| 08:53:31 | *** | Saving seen data "./dancer.seen" |
| 08:54:24 | | Join Buschel [0] (~chatzilla@p54B67BC7.dip.t-dialin.net) |
| 08:57:44 | | Quit stoffel (Remote host closed the connection) |
| 08:59:08 | | Quit Buschel (Ping timeout: 240 seconds) |
| 09:00 |
| 09:20:43 | | Quit amiconn (Remote host closed the connection) |
| 09:20:43 | | Quit pixelma (Remote host closed the connection) |
| 09:25:23 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 09:25:26 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 09:25:28 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 09:26:57 | | Join Rob2223 [0] (~Miranda@p4FFF2E04.dip.t-dialin.net) |
| 09:30:24 | | Quit Rob2222 (Ping timeout: 276 seconds) |
| 09:30:27 | | Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) |
| 09:33:29 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:33:29 | | Quit bertrik (Changing host) |
| 09:33:29 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 09:51:08 | | Quit Horschti (Read error: Connection reset by peer) |
| 09:51:30 | | Join Horscht [0] (~Horschti@p4FD4F242.dip.t-dialin.net) |
| 09:51:30 | | Quit Horscht (Changing host) |
| 09:51:30 | | Join Horscht [0] (~Horschti@xbmc/user/horscht) |
| 09:52:08 | | Quit S00row (Read error: Connection reset by peer) |
| 09:54:23 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 09:59:03 | | Quit sasquatch (Quit: WeeChat 0.3.2) |
| 09:59:29 | | Join sasquatch [0] (~username@p4FF2D67F.dip.t-dialin.net) |
| 10:00 |
| 10:08:32 | | Join Buschel [0] (~chatzilla@p54A3A669.dip.t-dialin.net) |
| 10:15:37 | | Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
| 10:21:27 | | Join kevku [0] (~kevku@2001:7d0:0:f000::135d) |
| 10:23:22 | Buschel | are there any thoughts, comments or ideas regarding FS #11753 (alignment definition/usage)? |
| 10:30:20 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 10:30:42 | | Quit Buschel (Ping timeout: 276 seconds) |
| 10:30:44 | | Join TheLemonMan [0] (~lemonboy@ppp-249-212.32-151.iol.it) |
| 10:37:09 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 10:39:19 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:47:36 | | Join bmbl [0] (~bmbl@unaffiliated/bmbl) |
| 10:53:34 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:03:54 | | Quit feisar- (Ping timeout: 250 seconds) |
| 11:05:16 | | Join {phoenix} [0] (~dirk@p57AA6C2C.dip.t-dialin.net) |
| 11:18:56 | | Join Gnea [0] (~gnea@unaffiliated/gnea) |
| 11:22:33 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 11:29:44 | | Join GeekShadow [0] (~Antoine@44.181.204-77.rev.gaoland.net) |
| 11:29:44 | | Quit GeekShadow (Changing host) |
| 11:29:44 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 11:39:02 | | Part dodddummy ("Leaving") |
| 11:54:19 | | Join Jaykay [0] (~chatzilla@p5DC57B57.dip.t-dialin.net) |
| 11:55:39 | n17ikh | what is the behavior of "idle poweroff" in rockbox-on-android? does it just stop the service? |
| 12:00 |
| 12:03:44 | | Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) |
| 12:29:47 | | Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) |
| 12:33:33 | | Quit dfkt (Ping timeout: 255 seconds) |
| 12:42:03 | | Quit Keripo (Ping timeout: 240 seconds) |
| 12:45:33 | | Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) |
| 12:53:35 | *** | Saving seen data "./dancer.seen" |
| 12:57:28 | | Quit Gnea (Ping timeout: 245 seconds) |
| 13:00 |
| 13:03:05 | | Join DerPapst [0] (~Alexander@p4FE8F803.dip.t-dialin.net) |
| 13:10:31 | | Join stoffel [0] (~quassel@p57B4C5E1.dip.t-dialin.net) |
| 13:14:06 | | Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) |
| 13:16:19 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 13:18:32 | | Quit mystica555_ (Ping timeout: 272 seconds) |
| 13:26:32 | | Quit stoffel (Remote host closed the connection) |
| 13:31:15 | | Join Gnea [0] (~gnea@unaffiliated/gnea) |
| 13:44:48 | | Quit xxcv (Ping timeout: 255 seconds) |
| 13:57:33 | | Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) |
| 13:58:39 | | Quit S00row (Read error: Connection reset by peer) |
| 13:59:31 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 14:00 |
| 14:05:20 | | Join piggz [0] (~piggz@78.151.53.160) |
| 14:06:54 | piggz | lo, i was wondering if there was a sleep mode in rockbox for my ipod video, as i noticed my daughters ipod video lasts a lot longer when not in use, and its faster than power cycling |
| 14:11:43 | JdGordon | n17ikh: idle poweroff doesnt do anything on android (yet) |
| 14:11:56 | JdGordon | piggz: rockbox doesnt sleep the ipod, it turns it off |
| 14:17:39 | piggz | JdGordon: shame, sleep would be cool |
| 14:18:11 | JdGordon | not really... it just uses up battery life doing nothing and rockbox boots to playing music in 3s or so anyway |
| 14:23:04 | | Quit Buschel (Ping timeout: 240 seconds) |
| 14:29:04 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 14:32:31 | | Join Topy [0] (~Topy44@f048110248.adsl.alicedsl.de) |
| 14:34:46 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 14:36:25 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:36:29 | | Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) |
| 14:36:30 | | Quit T44 (Ping timeout: 252 seconds) |
| 14:37:53 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 14:43:36 | | Quit Buschel (Ping timeout: 255 seconds) |
| 14:53:36 | *** | Saving seen data "./dancer.seen" |
| 14:57:15 | | Join hkmix [0] (~8e9dc124@giant.haxx.se) |
| 14:58:24 | | Quit hkmix (Client Quit) |
| 15:00 |
| 15:02:06 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 15:07:10 | | Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) |
| 15:17:34 | | Join feisar- [0] (jljhook@sienikerho.com) |
| 15:39:13 | | Quit guymann (Quit: BYE!) |
| 16:00 |
| 16:00:13 | | Quit teru (Quit: Quit) |
| 16:10:33 | | Join panni_ [0] (hannes@ip-178-203-101-205.unitymediagroup.de) |
| 16:10:56 | | Quit S00row (Read error: Connection reset by peer) |
| 16:13:14 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 16:15:52 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 4.0b8pre/20101119031701]) |
| 16:18:06 | | Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) |
| 16:28:16 | | Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) |
| 16:28:37 | | Quit freddyb (Client Quit) |
| 16:32:43 | soap | If your daughter's iPod video with the Apple Original Firmware has a longer shelf life than your iPod video with Rockbox something is seriously wrong. |
| 16:35:21 | soap | For, piggz, as JdGordo n said her Video is actually consuming power while sitting on the shelf, and yours is not. In general your iPod should achieve a longer battery life than hers, all things being equal, and if you turn on some of Rockbox's optional power-savings tricks you should be able to smoke her runtime. I am referring to the turning off of the Accessory Power Supply if/when you are not using dock connector accessories and setting the screen it |
| 16:35:21 | soap | self to turn off when the backlight is off. |
| 16:37:09 | piggz | soap: i understand that, its just nice that, with the stock firmware, although it is using power while alseep, it lasts for days anyway, and instantly comes on when needed |
| 16:38:41 | | Join Dreamxtreme [0] (~Dre@92.30.31.119) |
| 16:39:13 | soap | I understand the "responsiveness" point, as it is one of those subtle things which add up, but 3s boot in the grand scheme of things is not really problematic. But more importantly last I saw nobody actually knew how to put the iPod to sleep, much less expressed terrible interest in doing so. :( |
| 16:40:01 | piggz | i should probably configure my ipod to turn off when not used, as opposed to me always forgetting and it being constantly flat ;) |
| 16:41:00 | soap | Yes, I have mine set to turn off the screen when backlight is off, and power down after an hour at idle. That is a quite generous idle time and doesn't affect my music playback time significantly. |
| 16:42:00 | | Join mc2739_ [0] (~mc2739@rockbox/developer/mc2739) |
| 16:42:13 | | Quit mc2739_ (Client Quit) |
| 16:42:57 | n1s | figuring out how to "sleep" the ipod probably comes down to RE'ing the various device inits required to bring devices up again after shutting them down |
| 16:43:36 | n1s | power off everyting but the cpu and amybe ram and clock the cpu the lowest possible |
| 16:43:36 | Dreamxtreme | whats the highest bitrate and sample freq that rockbox supports |
| 16:44:14 | n1s | Dreamxtreme: rockbox resamples everything that isn't 44.1kHz to 44.1kHz and >16 bps is truncated or dithered to 16bps |
| 16:44:33 | soap | Dreamxtreme, do you mean the highest bitdepth of files, or of hardware playback? |
| 16:44:42 | n1s | (as long as we are talking about music playback) |
| 16:44:57 | Dreamxtreme | hardware playback really |
| 16:44:59 | Dreamxtreme | i think |
| 16:45:12 | n1s | then it differs from player to player |
| 16:45:18 | Dreamxtreme | i have a DVD of Foo Fighters that ive converted to FLAC 88200 24bit |
| 16:45:40 | soap | bit_rate_ would depend on how fast your storage is. And as n1s mentioned everything is taken brutally to 44.1/16, though some of the target hardware could support higher. |
| 16:45:47 | gevaerts | Th 88200 will work, not sure about the 24bit |
| 16:45:47 | Dreamxtreme | so the bit rate is around 3000kbps |
| 16:46:10 | gevaerts | But I suspect it should play fine on most players |
| 16:46:18 | soap | Not to get off topic, but 88.2 is an odd sample rate from a DVD. |
| 16:46:20 | n1s | yes, we support 24 bit flac |
| 16:46:35 | Dreamxtreme | o good |
| 16:46:36 | Dreamxtreme | :D |
| 16:46:39 | soap | and saratoga just mentioned fixing insane samplerates in the forums. |
| 16:46:40 | Dreamxtreme | yes i know |
| 16:46:53 | n1s | although there's a bug report about stupidly huge flac files not playing |
| 16:46:57 | gevaerts | If you care at all about battery life, I'd suggest reencoding to 44.1/16 |
| 16:47:34 | Dreamxtreme | with a Classic 3G (when its cracked) it shouldnt be a problem |
| 16:53:38 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:04:16 | * | kugel has track info in the notification area of android working |
| 17:25:18 | | Quit TheLemonMan (Quit: Help me, i got shot! *DIES*) |
| 17:28:21 | | Quit crwl (Ping timeout: 240 seconds) |
| 17:35:47 | | Join kreislauf [0] (~4e334c0a@giant.haxx.se) |
| 17:37:27 | kreislauf | hi guys. does anybody know, what vorbis decoder rockbox uses? |
| 17:37:41 | kreislauf | i read i review of libvorbis vs. ffvorbis |
| 17:37:48 | kreislauf | regarding battery life |
| 17:39:16 | | Quit froggyman (Quit: Bye) |
| 17:39:33 | gevaerts | I think it's based on libtremor |
| 17:39:57 | * | gevaerts doesn't know much about the codec side of rockbox though |
| 17:40:37 | kreislauf | didn't find any docs |
| 17:40:42 | kreislauf | but thanks |
| 17:41:25 | gevaerts | apps/codecs/libtremor in our sources |
| 17:44:08 | n1s | it is based on libtremor, yes |
| 17:44:29 | n1s | with quite a bit of our own optimizations by now |
| 17:46:19 | n1s | kreislauf: both libvorbis and the ffmpeg vorbis decoders are floating point and would need to be converted to fixed point to be usable in rockbox, also the ffmpeg one requires several MB of memory which makes it a bad fit on rockbox (mostly due to it always allocating worst-case sizes) |
| 17:46:38 | | Quit S00row (Read error: Connection reset by peer) |
| 17:49:43 | | Quit avacore (Ping timeout: 265 seconds) |
| 17:50:23 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 17:50:41 | | Quit InsDel (Read error: Connection reset by peer) |
| 17:51:10 | | Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) |
| 18:00 |
| 18:03:20 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 18:03:46 | Buschel | n1s: if you should have any free time left -> could you measure, if there is any difference in decoding speed with introduction of r28561 on your CF target? |
| 18:04:03 | n1s | sure |
| 18:04:46 | Buschel | cool :) |
| 18:04:56 | | Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) |
| 18:05:44 | | Join Daeken [0] (~Daeken@cpe-66-108-56-142.nyc.res.rr.com) |
| 18:06:38 | Daeken | hello all. does anyone happen to be working on ipod nano 6g support? i'm considering getting one to hack on, but i don't want to replicate work if possible. |
| 18:07:18 | Buschel | Daeken: ask TheSeven |
| 18:07:47 | n1s | Daeken: don't think anyone's working on it around here at least, AFAIK noone has found a working exploit for it yet |
| 18:08:24 | Daeken | ah, fun −− a challenge ;) |
| 18:08:43 | Daeken | hrm, think i'll walk over to the apple store in a bit and grab one. |
| 18:11:01 | bertrik | I think you're underestimating the challenge |
| 18:11:39 | Daeken | bertrik: i've spent the last 5 years reverse-engineering apple products :) |
| 18:12:55 | Daeken | usually very difficult, always a blast. well worth it |
| 18:14:09 | n1s | Buschel: seems to slow down 0.1MHz decoding the 128kbps test file |
| 18:15:29 | | Quit mc2739 (Quit: leaving) |
| 18:16:06 | Buschel | hmm, then it would be interesting to introduce target dependent defines... |
| 18:16:54 | | Quit bmbl (Read error: Connection reset by peer) |
| 18:17:03 | Buschel | which are set to CACHEALIGN_ATTR for ARM and maybe left empty for Coldfire... |
| 18:17:04 | gevaerts | Daeken: well, good luck with it :) |
| 18:17:09 | Buschel | (at least for mpc) |
| 18:17:35 | Daeken | gevaerts: thanks :) |
| 18:18:25 | Daeken | step one is getting access to a decrypted firmware... then, well, probably a file format vuln. quicktime's file format handling is insanely insecure −− can't be much (if any) better on the nano. |
| 18:18:30 | n1s | Buschel: well, the only thing that cares about alignment > the size of the members is movem in dram, the only place in mpc that uses movem is mpc_decoder_windowing_D and i thought that always worked on iram so this is probably just different code layout causing the icache to miss a little more |
| 18:18:32 | TheSeven | Daeken: what products have you previously been working on? |
| 18:18:41 | TheSeven | are you coming from the iphone scene? |
| 18:19:44 | Daeken | TheSeven: back in 2005, the itunes music store (dunno if you ever heard of pymusique, but it allowed you to purchase drm-free music from itms on linux); in recent-ish history, fairplay DRM a couple years back, and i worked on the dev team up through the initial unlock |
| 18:19:44 | | Quit kreislauf (Quit: CGI:IRC (EOF)) |
| 18:19:46 | Buschel | n1s: ok, only movem in dram would benefit on CF? |
| 18:20:29 | TheSeven | Daeken: the problem here is that you probably have to find an exploit blindly, because there is probably no way to get your hands on unencrypted main firmware code. |
| 18:20:31 | Daeken | TheSeven: i guess it's been a good 2 years since i've worked on anything apple-wise. been working on some odd things, like reversing a consumer EEG |
| 18:20:44 | Daeken | TheSeven: hmm, interesting. why is that? |
| 18:20:49 | n1s | yes, movem in dram does burst acces when alignment is 16bytes nothing else cares about large alignments |
| 18:20:56 | TheSeven | if you're incredibly lucky, there's an unencrypted (only signed) DFU image or bootloader on phobos, the main firmware is certainly encrypted |
| 18:21:37 | TheSeven | and if you have no way to run code on the device, you probably have no way to decrypt that |
| 18:22:08 | TheSeven | it might be worth to try one of those recently found bootrom exploits though |
| 18:22:25 | Daeken | TheSeven: do you have reason to believe that they're storing keys anywhere other than the flash? e.g. on the app cpu somewhere? |
| 18:22:42 | TheSeven | (i think there were at least two USB control message handling bugs in apple bootloader code recently, which may or may not have been fixed in that SoC) |
| 18:22:56 | TheSeven | from what we know, the nano6g uses an S5L8723 SoC |
| 18:23:19 | | Join Kitr88 [0] (~Kitarist@109.182.143.0) |
| 18:23:41 | TheSeven | on the previous devices, not even code on the CPU in privileged mode can access the keys, they can only be used by a hardware AES coprocessor |
| 18:24:00 | TheSeven | so you can only use the keys, but not read them out, and only if you can run code on it. |
| 18:24:11 | n1s | Buschel: also i don't think 0.1MHz is worth introducing more complexity ;) |
| 18:24:21 | Daeken | oh nice. they're starting to get this right :) |
| 18:24:24 | TheSeven | also they seem to be using asymmetric cryptography nowadays |
| 18:24:37 | Daeken | ok, so, are the keys actually /on/ the cpu, or are they stored somewhere in flash that's inaccessible? |
| 18:24:50 | TheSeven | Daeken: the hardware key thingy started with the ipod nano2g and the initial iphone i think |
| 18:25:18 | TheSeven | on the early iphones they were only using encrypted nonces to generate keys they use at runtime, while on the nano2g they used the hardware key directly |
| 18:25:51 | TheSeven | starting with the 3g, they introduced PKI for DFU images, starting with the 4g they seem to be using it for almost everything |
| 18:26:00 | Daeken | nah, the original iphone barely used the hardware aes accelerator −− at least i know that much on the baseband, not sure on the app cpu (i ran a good bit of baseband code in an emulator while reversing it, and the AES stuff was minimally used) |
| 18:26:12 | Daeken | hmm, interesting |
| 18:26:22 | | Quit Kitar|st (Ping timeout: 255 seconds) |
| 18:27:09 | Daeken | i haven't paid attention to apple's stuff in a few years now, so i have a lot to learn, history-wise. |
| 18:27:24 | | Quit Kitr88 (Ping timeout: 240 seconds) |
| 18:28:47 | Daeken | i just saw http://www.kickstarter.com/projects/1104350651/tiktok-lunatik-multi-touch-watch-kits earlier and decided that not only must i get one of those, but i have to be able to run my own code on it, so here i am ;) |
| 18:29:25 | | Join CaptainKewl [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 18:30:11 | gevaerts | Does one need a special patch to get at the ipod accessory protocol debug info? |
| 18:30:30 | bertrik | gevaerts, I think so, I haven't seen anything like that in SVN code |
| 18:30:58 | TheSeven | Daeken: to get back to your original question, I don't know of anyone working on it |
| 18:30:59 | bertrik | if it's not too intrusive, I'd say we add the debug info and enable it with a define |
| 18:31:19 | | Join toffe82 [0] (~chatzilla@adsl-71-154-234-239.dsl.frs2ca.sbcglobal.net) |
| 18:31:34 | TheSeven | and I myself am not planning to do anything with that one in the next couple of months unless maybe we accidentally discover a possible exploit |
| 18:31:53 | Daeken | TheSeven: alright, well, i appreciate your help. i'll idle here and if i discover anything fun, i'll let you guys know :) |
| 18:32:00 | TheSeven | feel free to try it, but this is going to be really hard |
| 18:32:12 | TheSeven | in case you find a working exploit, we would be glad to re-use it on the nano5g :) |
| 18:32:18 | gevaerts | bertrik: any idea about the task number? |
| 18:32:32 | Daeken | TheSeven: i sincerely hope so. i haven't had a good challenge in a long time. |
| 18:32:45 | Daeken | apple doesn't tend to let me down in that regard, so i'm looking forward to it ;) |
| 18:32:46 | TheSeven | Daeken: you might want to idle in #freemyipod :) |
| 18:33:02 | | Join Kitar|st [0] (Kitarist@BSN-142-102-198.dial-up.dsl.siol.net) |
| 18:33:04 | TheSeven | that's where we're currently poking at the ipod nano 3g/4g and classic |
| 18:33:14 | Daeken | great, thanks. |
| 18:33:21 | bertrik | gevaerts, http://www.rockbox.org/tracker/task/9951 |
| 18:33:28 | bertrik | not sure if it still applies |
| 18:34:09 | gevaerts | hm, do I need the logging patch, or both, or only the last one? |
| 18:34:42 | Daeken | TheSeven: do you know if it's possible to get the unencrypted bootloader/dfu image for the 6g? |
| 18:35:12 | TheSeven | check the files on phobos, i haven't looked at them yet |
| 18:35:18 | bertrik | I guess the aug 23th patch is the relevant one |
| 18:35:24 | TheSeven | http://www.trejan.com/projects/ipod/phobos.html |
| 18:35:34 | | Join Boldfilter [0] (~Boldfilte@99-120-142-250.lightspeed.jcvlfl.sbcglobal.net) |
| 18:35:44 | Daeken | ok, cool. thanks again :) |
| 18:35:52 | gevaerts | Yes, that one seems to apply at least |
| 18:35:52 | TheSeven | http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/x12320000_Recovery.ipsw |
| 18:35:56 | TheSeven | http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/x12480000_Recovery.ipsw |
| 18:36:12 | TheSeven | http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/iPod_1.0_36A00403.ipsw |
| 18:36:29 | TheSeven | there might be something unencrypted in one of them, but i rather doubt it |
| 18:36:50 | Daeken | same. |
| 18:37:39 | | Join domonoky1 [0] (~Domonoky@agsb-4d055ffd.pool.mediaWays.net) |
| 18:38:30 | Daeken | yea, the dfu image is encrypted, from 0x400 on |
| 18:38:30 | | Quit domonoky (Ping timeout: 245 seconds) |
| 18:39:13 | Daeken | hrm... they use CBC mode, right? |
| 18:40:23 | Buschel | n1s: it's not worth to introduce them for this 0.1 MHz, true. but if we should use alignment mactos for ARM we need to find a solution to cope with CF. see FS #11753. (might be interesting to make measurements on arm11) |
| 18:40:44 | Daeken | ah shit, need to get to the bank... back shortly. |
| 18:41:14 | Buschel | n1s: saratoga introduced 32 byte aligment in atrac3 to optimize for arm11 |
| 18:42:38 | n1s | Buschel: well, since large alignment doesn't really hurt anywhere i don't see why not just always align to 32 bytes (it would waste some space but that's usually very little9 |
| 18:43:59 | n1s | as an example in mpc, 5 arrays aligned to 32 bytes would waste a max of 31*5=155 bytes |
| 18:44:11 | Buschel | n1s: tha's the easiest way :) but I don't think such solution would be accepted in general |
| 18:45:46 | TheSeven | Daeken: they used CBC on the older platforms at least |
| 18:48:28 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 18:48:39 | n1s | Buschel: maybe we can use something global like FAST_ALIGN where we just align for the sake of speed and not something else which would then be 16 bytes on CF |
| 18:49:07 | n1s | i don't really like abusing CACHE_ALIGN for this on CF |
| 18:53:40 | *** | Saving seen data "./dancer.seen" |
| 18:54:14 | Buschel | yes, that's why I proposed to have something else. e.g. MEM_ALIGN_ATTR or FAST_ALIGN_ATTR. this can be same as CACHEALIGN_ATTR for ARM an something else for other CPUs. |
| 18:54:44 | Buschel | it could be simply defined in system.h as well |
| 18:54:58 | n1s | sounds good to me if you don't want to do unconditional 32byte alignment :) |
| 18:55:20 | Buschel | depends on what we want to use as default ;) |
| 18:56:47 | | Quit Rob2223 (Remote host closed the connection) |
| 18:57:23 | | Join Rob2222 [0] (~Miranda@p4FFF2E04.dip.t-dialin.net) |
| 18:57:24 | Buschel | e.g. it might be ok to use 32 byte alignment on unknown ARM CPUs. the newer ones have this alignment. so, the probability that it fits for a new port is high |
| 18:58:03 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 18:58:22 | n1s | i think the cores that use the cache from ARM have 32b cache lines but that the PP cores have custom caches |
| 18:58:45 | gevaerts | Anyone with IAP knowledge around who understands what http://pastie.org/1313231 means? |
| 18:58:46 | n1s | so, yes 32 bytes is very likely for newer ARM's |
| 19:00 |
| 19:00:58 | | Quit rvvs89 (Remote host closed the connection) |
| 19:01:02 | bertrik | gevaerts, 1st is length, 2nd is mode. Mode 0 is used for negotiation into other modes IIRC |
| 19:01:50 | kugel | I'm with n1s |
| 19:01:58 | gevaerts | Which presumably fails here since we have no idea how to deal with the thing |
| 19:02:10 | | Quit dfkt_ (Ping timeout: 252 seconds) |
| 19:05:37 | | Quit Gnea (Ping timeout: 272 seconds) |
| 19:05:45 | | Join guymann [0] (~charles@69.182.43.9) |
| 19:07:06 | | Quit piggz (Ping timeout: 250 seconds) |
| 19:11:25 | | Join T44 [0] (~Topy44@f054217089.adsl.alicedsl.de) |
| 19:14:21 | | Quit Topy (Ping timeout: 245 seconds) |
| 19:14:31 | kugel | FS #11766 |
| 19:19:41 | | Quit guymann (Quit: brb lol) |
| 19:25:13 | | Join guymann [0] (~charles@69.182.43.9) |
| 19:25:13 | | Quit S00row (Read error: Connection reset by peer) |
| 19:25:59 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 19:30:58 | | Quit n1s (Quit: Lämnar) |
| 19:35:22 | Daeken | TheSeven: any idea how they handle/have handled padding in the past? |
| 19:36:07 | TheSeven | they usually pad data to 16 byte blocks with 0xff |
| 19:36:13 | Daeken | ah, ok |
| 19:37:13 | Daeken | ... huh, the bootloader in the firmware update (the main one) isn't encrypted. |
| 19:40:40 | | Join Topy [0] (~Topy44@g228209202.adsl.alicedsl.de) |
| 19:43:31 | | Quit T44 (Ping timeout: 245 seconds) |
| 19:43:55 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 19:43:56 | | Quit Boldfilter (Quit: Boldfilter) |
| 19:44:38 | saratoga | Buschel: do you mind if I commit FS #11235? |
| 19:45:06 | | Quit dfkt (Read error: Connection reset by peer) |
| 19:45:06 | saratoga | i want to look at arm9 scheduling in more detail for libmad, so getting that patch in first would be nice |
| 19:45:07 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 19:45:45 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-109-252.tampfl.fios.verizon.net) |
| 19:46:07 | Buschel | can this still be applied to svn? |
| 19:46:57 | Buschel | if so, I do not mind if you would submit |
| 19:46:58 | | Quit dfkt_ (Read error: Connection reset by peer) |
| 19:47:00 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 19:48:19 | | Quit dfkt (Read error: Connection reset by peer) |
| 19:48:20 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 19:48:23 | saratoga | it doesn't apply, but it should be easy enough to fix |
| 19:48:53 | saratoga | also, i got the c version of libmad working with 32x16 muls and no "SSO" optimization |
| 19:48:57 | saratoga | i've started on the asm code |
| 19:50:14 | saratoga | scheduling this for arm11 is . . . interesting |
| 19:50:39 | saratoga | i didn't realize on arm11 doing two multiply accumulates into the same register on sequential cycles was a stall |
| 19:51:24 | saratoga | the optimal arm11 code should run with no speed hit on arm9e, but i'm thinking of splitting them up anyway just because the arm9e version is comprehensible while the arm11 version is going to be a mess |
| 19:51:24 | | Quit S00row (Read error: Connection reset by peer) |
| 19:53:34 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
| 19:53:46 | saratoga | Buschel: hmm i don't see why this patch is failing exactly, you wouldn't happen to have your synth.c for you last version of that patch handy? |
| 19:57:29 | saratoga | ah nevermind, got it |
| 20:00 |
| 20:01:59 | | Quit iq (Ping timeout: 240 seconds) |
| 20:03:18 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 20:05:58 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 20:06:13 | CIA-7 | New commit by saratoga (r28624): Commit first part of FS #11235 by Buschel and I. Improves scheduling on arm9 for two filter macros in libmad that are almost never called. A larger ... |
| 20:06:29 | saratoga | Buschel: I'm going to leave that task open for now, I want to play around with arm < 9E scheduling some more |
| 20:08:28 | CIA-7 | r28624 build result: All green |
| 20:11:36 | | Quit dfkt_ (Read error: Connection reset by peer) |
| 20:11:38 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 20:25:51 | | Join pamaury [0] (~quassel@dhcp-128-203.residence.ens-lyon.fr) |
| 20:25:51 | | Quit pamaury (Changing host) |
| 20:25:51 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 20:38:16 | kugel | gah |
| 20:38:32 | kugel | using the layout values for the inbuilt media player doesn't work for htc sense |
| 20:39:59 | | Quit user890104 (Ping timeout: 272 seconds) |
| 20:52:17 | | Quit Buschel (Ping timeout: 264 seconds) |
| 20:52:20 | | Quit liar (Ping timeout: 255 seconds) |
| 20:53:43 | *** | Saving seen data "./dancer.seen" |
| 20:53:52 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 21:00 |
| 21:00:18 | | Join u42p [0] (~u42p@d085196.adsl.hansenet.de) |
| 21:00:43 | u42p | (how) can i use http://www.rockbox.org/tracker/task/11664?show_task= in combinaton with RockboxUtility on linux? |
| 21:01:38 | u42p | i mean, my clip+ boots sansa firmware if i connect it to the pc and since it then hangs i'd like it to boot rockbox instead |
| 21:01:39 | soap | u42p, there is no need to use RockboxUtility in combination with that patch. |
| 21:01:58 | u42p | oh i dont know how to install anything without that tool :) |
| 21:02:38 | soap | What you want to do is build your own rockbox (starting with http://www.rockbox.org/wiki/CrossCompiler ) using those patches and test. |
| 21:03:11 | soap | u42p, one would simply copy the compiled .rockbox folder to their player overwriting the old one in the process. |
| 21:05:10 | u42p | oh, now that you say it, i think i looked at that page before and got scared. |
| 21:06:44 | soap | it is step by step. Lots of steps, but little left to the imagination. If soap can do it you can! |
| 21:08:40 | u42p | ok, gonna try it. :) |
| 21:10:44 | soap | if you're on Windows using the VMWare image is likely easier than cgywin |
| 21:11:08 | u42p | nope, archlinux |
| 21:11:16 | soap | then you're set. |
| 21:22:19 | u42p | ok, i have run rockboxdev.sh . how do i apply those patches? |
| 21:24:11 | TheSeven | Daeken: you mean the whatever.bootloader.rb3 file? |
| 21:24:28 | TheSeven | have fun disassembling that :) |
| 21:25:38 | Daeken | yea |
| 21:25:41 | u42p | "patch -p0 <file" in the root i guess |
| 21:26:04 | TheSeven | so they're still not encrypting that. nice. |
| 21:26:17 | u42p | no, cant find the file |
| 21:26:31 | TheSeven | Daeken: prepare yourself for a disassembling odyssey :) |
| 21:28:15 | TheSeven | seccore/peicore will be rather easy, but the rest will be rather evil. |
| 21:28:20 | Daeken | :) |
| 21:28:40 | TheSeven | in case you haven't noticed yet what's in there: |
| 21:28:57 | TheSeven | it's an EFI volume. yes, they're using EFI on those players. no idea why. |
| 21:29:10 | u42p | ok, did it manually |
| 21:29:15 | | Join mc2739 [0] (~mc2739@71.20.73.59) |
| 21:29:16 | TheSeven | it contains a shitload of compressed PE executables |
| 21:29:18 | | Quit mc2739 (Changing host) |
| 21:29:18 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 21:29:32 | u42p | if i want the complete makeover i need to build the Bbootloader and Normal, correct? |
| 21:29:35 | saratoga | looks like I can save 1-2MHz on arm9 (non-E) decoding mp3 |
| 21:29:38 | TheSeven | those are relocated at runtime, lots of dynamic memory allocation involved |
| 21:29:49 | saratoga | unless you're changing the bootloader you shouldn't touch it |
| 21:30:14 | Daeken | TheSeven: how much of the bootloader code depends on weird hardware features? e.g. does it use the aes accel? |
| 21:30:24 | TheSeven | and the worst is probably that they call each other through those runtime-registered guid to function table mappings |
| 21:30:36 | TheSeven | even some of the function tables are generated at runtime |
| 21:30:57 | TheSeven | it does, but the individual modules are nicely separated |
| 21:31:15 | TheSeven | the ugly thing are the cross-module calls/callbacks/events/triggers/whatever |
| 21:31:23 | Daeken | hmm... so running this in emulation might be a feasible approach. |
| 21:31:34 | TheSeven | possibly |
| 21:31:35 | Daeken | (that's how i did a lot of baseband reversing for the original iphone) |
| 21:32:34 | TheSeven | finding a vuln there will be hard, it's hardly doing any user interaction |
| 21:33:10 | Daeken | i'm mainly interested in it to understand the boot process better |
| 21:33:29 | TheSeven | the only possible route of exploitation that i can see is cracking the firmware update protocol, corrupting the firmware partition somehow, and exploiting the firmware file system reading code |
| 21:34:00 | u42p | aaargh, build failed: http://pastebin.com/iZAFkADu |
| 21:34:47 | TheSeven | or maybe some signature validation code |
| 21:35:18 | TheSeven | the boot logo will probably still be a bitmap, so it's not very likely that there will be a vuln in the decoder |
| 21:35:24 | saratoga | u42p: as I said before you dno't want to build a bootloader |
| 21:35:45 | u42p | sorry, i missed that line |
| 21:36:12 | saratoga | although since you haven't changed the bootloader, and its failing to build, you're probably still doing something else wrong |
| 21:36:25 | * | TheSeven asks for a general opinion: should we move this discussion to #freemyipod or stay here? |
| 21:36:27 | u42p | i don't know what exactly i am changing. but since it is related to the bootloader i suspect it might be it. it is this patch i want to try http://www.rockbox.org/tracker/task/11664?show_task= |
| 21:37:52 | gevaerts | TheSeven: I don't think it's wrong to have it here |
| 21:42:03 | saratoga | TheSeven: i hate having to read two sets of logs, so i say keep it here |
| 21:42:46 | Daeken | TheSeven: during the bootloader, what is active? is there a way to do anything usb-wise from the bootloader level, or does that come later? |
| 21:43:21 | Daeken | i imagine there's /something/ usb-wise there, to start the flashing process... |
| 21:44:02 | TheSeven | there are three points where USB is used: |
| 21:44:06 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 21:44:06 | TheSeven | - bootrom DFU (too early) |
| 21:44:13 | TheSeven | - USB mass storage device (too late) |
| 21:44:18 | TheSeven | - Disk mode (too late) |
| 21:45:16 | TheSeven | there's also a USB EFI module, but I'm not sure what this one is doing |
| 21:45:28 | TheSeven | might only be used to determine if there is voltage on the bus |
| 21:45:34 | Daeken | hmm... |
| 21:45:38 | TheSeven | or maybe in diagmode (which in integrated into this efi hell) |
| 21:48:18 | saratoga | stupid arm and its lack of registers, even storing the stack pointer so I can use it, I still have 1.5 cycles of stall per PCM sample produced in libmad on arm9 (non-E) |
| 21:50:19 | Daeken | you know, i wonder if it'd be possible to employ a timing attack against the signature check for the bootloader update process. |
| 21:50:36 | Daeken | i find it doubtful that they're doing it in constant time, unless someone's employed the same attack against them in the past... |
| 21:51:30 | Daeken | the timing would be precise enough to do it pretty damn quickly, especially if the update procedure works anything like bbupdate did. |
| 21:52:34 | TheSeven | you mean trying to figure out the hardware AES key by analyzing the time decryption takes? |
| 21:52:51 | saratoga | 16 hr, 20 min using freddyb's patch |
| 21:52:56 | saratoga | on fuzev1 |
| 21:53:33 | Daeken | no −− that'd pretty much require having code running on the device in the first place (might be feasible from there, though i think a power measurement attack would be more likely to succeed) ... i mean measuring the time it takes to check the signature during the update process. |
| 21:54:15 | Daeken | the bootloader code isn't encrypted, so modifying it would be easy (for some value of easy) ... if you can measure the time it takes to check the signature and they're not doing it in constant time, it'd be possible to find a matching signature... in theory. |
| 21:54:19 | Daeken | depends on how they're doing it, really |
| 21:54:26 | TheSeven | the only place where such an attack could be mounted is bootrom DFU IIUC |
| 21:55:15 | Daeken | that may well be the best way to get code running on it initially... as soon as one tiny bit of code runs on it, it's game over. |
| 21:55:16 | TheSeven | I still think that jitter introduced by USB will be way too big to do this |
| 21:55:48 | | Quit factor (Read error: Connection reset by peer) |
| 21:56:31 | Daeken | nah, noise is a nonissue in this regard. you can achieve nanosecond resolution over the internet with a timing attack... very practical on anything local. the only concern i have is that they're doing the check in constant time. |
| 21:56:38 | Daeken | but that's easy enough to figure out |
| 21:56:55 | TheSeven | well, try it :) |
| 21:57:26 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 21:57:36 | Daeken | yea, think i'm going to... probably gonna go pick up a nano this week. |
| 21:57:46 | Daeken | was going to do it today, but didn't feel like walking over there after i hit the bank :P |
| 21:57:58 | TheSeven | are the DFU images encrypted? |
| 21:58:03 | Daeken | yea |
| 21:58:11 | TheSeven | hm, that's not good |
| 21:58:16 | Daeken | why so? |
| 21:58:30 | TheSeven | because it means we would have to encrypt the code |
| 21:59:06 | Daeken | why? if you're patching the bootloader, it should take it no problem as long as the signature matches. |
| 21:59:35 | TheSeven | how would you get feedback on the time it takes for the bootloader signature to be verified? |
| 22:00 |
| 22:00:02 | TheSeven | (assuming they let you flash whatever you want, and will just fail on the next reboot) |
| 22:00:22 | Daeken | depends on how they're doing the updates. is it a situation where you simply ship the data off to the nano and it hands back an error or somesuch, or does it allow you some semblance of control? |
| 22:00:41 | Daeken | i imagine it won't flash the bootloader unless it validates the signature first, right? |
| 22:01:18 | TheSeven | i'm not sure about that |
| 22:01:47 | TheSeven | why should they check it? |
| 22:02:01 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 22:02:08 | Daeken | because if there's an error on the line, the user gets a brick. |
| 22:02:13 | TheSeven | nope |
| 22:02:17 | Daeken | how so? |
| 22:02:34 | TheSeven | if the bootloader isn't signed correctly, the bootrom will enter DFU, itunes will pick it up, upload WTF and disk mode, and flash it again |
| 22:02:43 | Daeken | ah, good point... |
| 22:02:49 | Daeken | hrm. |
| 22:03:32 | TheSeven | and "errors on the line" would have to pass USB CRCs |
| 22:04:11 | Daeken | the one big thing that makes me think this could work is that bytes 0x40-0x54 of the bootloader look to me like an sha1, most likely hmac. |
| 22:04:35 | Daeken | if they verify that in a non-constant-time way at flashtime, it'd be easy. |
| 22:04:36 | * | TheSeven bets it's plain sha1 of bytes 0-0x3f |
| 22:04:39 | Daeken | otherwise... not so much. |
| 22:05:01 | TheSeven | and bytes 0x10-0x14 will probably be plain sha1 of the payload |
| 22:05:22 | Daeken | you mean 0x10-0x24? |
| 22:05:29 | TheSeven | yes, of course |
| 22:05:40 | Daeken | nope, not in this case... this is the only thing that looks like an sha1. |
| 22:05:42 | Daeken | at all |
| 22:05:50 | TheSeven | hm, interesting |
| 22:05:58 | TheSeven | on the nano2g those were HMACs |
| 22:06:00 | Daeken | one sec, i'll pastebin the header. |
| 22:06:13 | TheSeven | on the nano3g/classic they switched to SHA1 run through the AES hardware key |
| 22:06:22 | TheSeven | and on the nano4g I've seen plain SHA1s somewhere |
| 22:07:26 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 22:11:38 | Daeken | http://pastie.org/1313553 <−− header plus first 16 bytes of payload. |
| 22:12:53 | Daeken | if they were to run sha1 through aes, either they'd truncate the hash first, meaning we'd have 4 bytes less data, or they'd pad it out, meaning we'd have 12 bytes more... i'd put money on that being an hmac |
| 22:15:21 | Daeken | well, there is one other possibility, but i find this insanely unlikely: SHA1 encrypted then truncated to 20 bytes... they couldn't decrypt it, but they could do the same thing on the hardware, allowing them to verify it. |
| 22:15:26 | Daeken | but i can't see why they would ever, ever do that :P |
| 22:16:03 | TheSeven | that's why i think it's a plain one |
| 22:16:15 | TheSeven | they seem to have accepted that encrypting those hashes buys them nothing |
| 22:16:15 | Daeken | how would they verify it? |
| 22:16:27 | Daeken | that is, how could they verify it wasn't tampered with |
| 22:16:28 | Daeken | ? |
| 22:17:20 | TheSeven | that's why they have a digital signature of the header (or even the payload?) at the end |
| 22:17:35 | | Quit alexbobP (Quit: leaving) |
| 22:18:02 | Daeken | there's none in the header... and i don't see one in the payload, but it could very well be there and simply not have anything to stand out. |
| 22:18:33 | kugel | saratoga: how much is 1.5c per sample improved over svn? and why 1.5c? |
| 22:18:35 | | Join alexbobP [0] (~alex@75.63.1.71) |
| 22:19:03 | saratoga | kugel: saves about 2 MHz on the Fuze v1 |
| 22:19:17 | Daeken | and in this case, hmacs would be identical to signatures for their purposes. except even more secure, in theory |
| 22:19:32 | Daeken | (personally disagree with that point, but i'm in the minority there) |
| 22:19:37 | saratoga | 1.5 cycles * 44100*2 = 132kHz |
| 22:19:59 | saratoga | so not too bad, but still annoying |
| 22:20:17 | kugel | 2MHz is nice |
| 22:20:27 | Daeken | brb, need a smoke. |
| 22:22:42 | saratoga | yeah i'm pretty happy with it |
| 22:22:56 | saratoga | i think we can get a much, much bigger improvement on arm9e and arm11 though |
| 22:23:40 | saratoga | probably on the order of 3-4 times that |
| 22:23:58 | saratoga | would make mp3 fast like vorbis |
| 22:24:27 | u42p | if i built a new rockbox.zip, should i remove the old .rockbox on my player before unpacking? |
| 22:24:32 | | Join stoffel [0] (~quassel@p57B4A17B.dip.t-dialin.net) |
| 22:25:28 | | Join ReimuHakurei_ [0] (~reimu@74.112.212.15) |
| 22:25:32 | | Quit ReimuHakurei (Read error: Connection reset by peer) |
| 22:26:47 | saratoga | no |
| 22:27:38 | u42p | ok |
| 22:28:05 | u42p | ok, done. still boots sansa if i plug it in |
| 22:29:01 | u42p | ah, i had to launch rockbox and then plug it in |
| 22:30:27 | u42p | hooray, works like a charm |
| 22:30:32 | u42p | thanks for your help guys! |
| 22:31:13 | u42p | pamaury: another satisfied customer here for http://www.rockbox.org/tracker/task/11664?show_task= . sansa clip+ |
| 22:31:16 | kugel | saratoga: your work already helps on armv5+, no? |
| 22:32:01 | saratoga | kugel: yes, same on arm9, but i'm going to replace this code with armv5 optimized versions soonish |
| 22:32:08 | saratoga | "same on all arm9" |
| 22:32:20 | pamaury | yes I saw, apparently the patch is working quite well with linux, but windows is still doing crap |
| 22:32:47 | kugel | saratoga: can you post the patch? I can test on my phone then |
| 22:33:13 | saratoga | kugel: sure, give me 5, tracking down a glitch in the audio sometimes |
| 22:36:22 | saratoga | ok there i think i got it working |
| 22:36:58 | | Join casainho [0] (~chatzilla@2.81.145.101) |
| 22:38:24 | saratoga | kugel: http://www.rockbox.org/tracker/task/11235 |
| 22:38:45 | kugel | awesome |
| 22:39:10 | kugel | I'll apply Buschel's alignment patch as well and make a new test codec batch |
| 22:39:12 | | Quit froggyman (Quit: Bye) |
| 22:39:20 | saratoga | according to test_codec, libmad has gotten 3.5MHz faster on the fuzev1 since the spring |
| 22:44:55 | kugel | saratoga: does your patch hurt PP? |
| 22:45:10 | saratoga | kugel: shouldn't |
| 22:45:32 | saratoga | doesn't really matter anyway thanks to the COP patch |
| 22:45:38 | saratoga | all this code runs on the COP |
| 22:46:18 | saratoga | TheSeven: my ipod says its blank and the OF wants me to restore it, whats the easiest way to fix this |
| 22:46:33 | saratoga | (haven't used it in a month or so FWIW) |
| 22:47:35 | TheSeven | saratoga: what kind of ipod? |
| 22:47:44 | saratoga | sorry, 2g |
| 22:47:46 | saratoga | naon |
| 22:47:48 | saratoga | nano |
| 22:47:53 | TheSeven | "use itunes to restore" |
| 22:48:07 | TheSeven | has it ever seen iloader? |
| 22:48:15 | saratoga | no, just whatever rbutil installed |
| 22:48:22 | TheSeven | that's weird |
| 22:48:33 | saratoga | i'll go find a machine with itunes |
| 22:48:58 | TheSeven | you could try handcrafting a firmwarefs with a rockbox bootloader inside :) |
| 22:49:12 | TheSeven | but itunes is certainly the easier way |
| 22:49:29 | saratoga | whats weird is the rockbox bootloader seems gone |
| 22:49:59 | TheSeven | "use itunes to restore" means that it failed to load the rockbox bootloader for whatever reason |
| 22:50:13 | TheSeven | this is displayed by the NOR bootloader |
| 22:51:36 | | Quit stoffel (Remote host closed the connection) |
| 22:52:16 | | Part u42p ("Leaving") |
| 22:53:45 | *** | Saving seen data "./dancer.seen" |
| 22:56:48 | | Quit benedikt93 (Quit: Bye ;)) |
| 23:00 |
| 23:00:01 | kugel | saratoga: good thing you fixed test codec to work with files larger than ram |
| 23:00:29 | saratoga | yes thats quite handy |
| 23:00:46 | saratoga | i'm thinking of next adding options to do boosted, unboosted, and "dynamic" boosted tests |
| 23:00:57 | saratoga | the last one attempting to boost and unboost as needed like during normal playback |
| 23:01:34 | kugel | i.e. testing how much boost happens in realtime decoding? |
| 23:01:47 | kugel | good idea generally but tests will take ages this way |
| 23:02:04 | saratoga | still faster then unboosted :) |
| 23:02:26 | saratoga | the thing is performance with boosting locked on is often a lot different then when it flips on and off on some players |
| 23:02:34 | kugel | not on android :) |
| 23:03:02 | saratoga | although i guess figuring out the right ratio of boosted to unboosted could be tough if we want to go a lot faster then real time |
| 23:03:59 | kugel | loading the file from disk basically takes longer than decoding for some codecs on android |
| 23:04:44 | kugel | (that's perhaps exaggerated) |
| 23:05:15 | saratoga | huh test codec is slightly slower then what the wiki says mp3 should be |
| 23:05:18 | saratoga | i wonder whats going on |
| 23:05:40 | kugel | the async clock mode change? |
| 23:06:23 | saratoga | sorry, i mean on the nano2g |
| 23:06:27 | saratoga | fuzev1 is faster |
| 23:11:39 | saratoga | hmm no its faster, however the nano2g has gotten slower since I tested it over the summer |
| 23:12:27 | kugel | the alignment patches already make some difference. most codecs are a good deal faster than in my last test |
| 23:13:29 | saratoga | hmm well this is TheSeven's problem |
| 23:13:36 | saratoga | i'll make the codecs faster, he has to figure out the hardware |
| 23:15:03 | TheSeven | saratoga: what exactly is slower now? |
| 23:15:05 | TheSeven | test_codec? |
| 23:15:14 | TheSeven | so decoding without the pcm driver running and always fully boosted? |
| 23:15:25 | saratoga | TheSeven: correct |
| 23:16:07 | TheSeven | is test_codec loading the complete file to RAM before decoding? |
| 23:16:21 | saratoga | you got 51.06MHz with r24786, I'm getting about 53MHz now |
| 23:16:35 | saratoga | it loads as much as fits into RAM, then pauses the timer to rebuffer if needed |
| 23:16:46 | saratoga | for 128k mp3 it shouldn't be rebuffering |
| 23:16:53 | TheSeven | OK |
| 23:17:01 | TheSeven | so it can't be coming from the FTL/NAND |
| 23:17:03 | saratoga | have you changed any clocks in the last 3000 revisions |
| 23:17:52 | TheSeven | i have changed the boosting/unboosting operation a bit, but this shouldn't have an effect |
| 23:18:08 | saratoga | pretty much the only thing that should matter is the bus and memory clocks |
| 23:18:32 | saratoga | is it possible my ipod is somehow faster then yours? |
| 23:18:41 | TheSeven | they should always have been the same (CPU: 192MHz, AHB: 96MHz, async mode) |
| 23:18:41 | | Quit xavieran (Ping timeout: 265 seconds) |
| 23:18:55 | TheSeven | i can have a check on mine if you like |
| 23:19:01 | | Join Gnea [0] (~gnea@unaffiliated/gnea) |
| 23:19:02 | saratoga | yeah probably a good idea |
| 23:19:24 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 23:19:28 | | Quit MethoS- (Read error: Connection reset by peer) |
| 23:19:34 | TheSeven | which file is that? lame128? |
| 23:20:12 | saratoga | yeah |
| 23:20:17 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 23:20:26 | | Quit MethoS- (Remote host closed the connection) |
| 23:20:39 | saratoga | the difference is even more pronounced when you consider that the fuzev1 seems to have gotten faster over that time due to better optimization in libmad |
| 23:20:57 | TheSeven | hm, no test_codec installed :/ |
| 23:22:13 | * | TheSeven needs to rebuild first |
| 23:23:14 | kugel | I get upto 20% speedups with the alignment patches |
| 23:23:23 | saratoga | wow |
| 23:23:26 | saratoga | on which target? |
| 23:23:32 | kugel | my phone |
| 23:24:47 | saratoga | arm11 or cortex? |
| 23:25:05 | saratoga | i guess alignment will matter a lot on either, since they have the 64 bit bus for aligned transfers |
| 23:25:17 | kugel | arm11 |
| 23:25:33 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 23:26:02 | kugel | I'll have new charts up in a few minutes |
| 23:28:14 | TheSeven | saratoga: 53.56MHz on r28602 with aafonts and hw keyclick patch applied, iLike theme |
| 23:28:41 | TheSeven | touched the clickwheel a few times during the process to keep the display awake |
| 23:29:10 | saratoga | ok same as i then |
| 23:29:10 | saratoga | weird |
| 23:29:19 | TheSeven | maybe one of Buschel's IRAM changes are related? |
| 23:29:33 | TheSeven | IRAM isn't really fast on this one, but I wouldn't expect it to be slower than DRAM |
| 23:29:39 | saratoga | that would make sense, ams doesn't use the iram defines |
| 23:30:00 | TheSeven | we'll probably have to bisect that |
| 23:30:37 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) |
| 23:31:02 | kugel | saratoga: http://pastie.org/1314086 |
| 23:31:13 | kugel | I'm redoing the svn test with backlight on this time |
| 23:32:25 | | Join alexxel [0] (flea2008@peer214-29-159-178.ll.magnitogorsk.multinex.ru) |
| 23:32:43 | kugel | the left is svn, the right is svn+asm enabled+alignment patches |
| 23:32:48 | | Quit MethoS- (Remote host closed the connection) |
| 23:32:55 | alexxel | Hey ? |
| 23:33:30 | saratoga | wow those are amazing |
| 23:33:35 | saratoga | is the alignment patch in SVN yet? |
| 23:33:39 | kugel | no |
| 23:33:43 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 23:34:10 | alexxel | rockbox for nano 3g ipod is it real ?? |
| 23:34:17 | saratoga | nope |
| 23:34:23 | kugel | I'll prepare a graph that has my last test codec benches in it |
| 23:34:30 | saratoga | you should get that patch in then |
| 23:34:33 | kugel | just need to find the right files |
| 23:34:36 | saratoga | whats the fs number? |
| 23:34:47 | kugel | FS #11753 |
| 23:35:42 | saratoga | does it help with any other CPUs? |
| 23:35:51 | saratoga | probably not much on arm9 i guess |
| 23:36:53 | saratoga | i should probably double check that everything in libmad is aligned |
| 23:37:36 | saratoga | huh it isn't |
| 23:38:36 | saratoga | what define should I be using to align things? |
| 23:41:05 | TheSeven | alexxel: not yet at least. it might be coming one day, i'm working on it :) |
| 23:43:23 | alexxel | :( |
| 23:43:31 | alexxel | funny guy |
| 23:44:41 | kugel | saratoga: pretty amazing: http://www.alice-dsl.net/simonemartitz/rockbox/test_codec_stats.pdf |
| 23:45:15 | kugel | saratoga: CACHEALIGN_ATTR, or whatever the outcome of fs#11753 is |
| 23:45:17 | saratoga | kugel: i wonder what those look like if libmad is actually aligned |
| 23:46:20 | kugel | wow, look at the mpc numbers |
| 23:46:30 | saratoga | alignment makes no real difference on arm9 that i can see |
| 23:46:47 | kugel | also, mp3 is faster now, and even faster with your patch and asm enabled (in svn C is faster) |
| 23:47:08 | TheSeven | alexxel: who is claiming that rockbox would run on it? |
| 23:48:53 | kugel | I'm surprised that cache align makes such a vast difference. or did something else change since a month ago? |
| 23:49:24 | saratoga | on arm11 aligned loads/stores are basically 2x as fast as unaligned ones |
| 23:49:58 | alexxel | Why not?? this is open sourse, it may run even on my tv if anybody cares... |
| 23:50:02 | saratoga | hmm i take back what i said about alignment on arm9, its more complicated to align libmad because of all those packed structs |
| 23:50:17 | saratoga | alexxel: no one cared until recently |
| 23:50:46 | saratoga | i'll have to dig into alignment more once buschel's patch is committed, theres probably a lot of room for improvement here |
| 23:51:17 | saratoga | kugel: also if possible having the raw MHz needed is nice too, since it makes it easier to see the actual magnitude of an improvement |
| 23:51:58 | alexxel | so very sad |
| 23:53:52 | kugel | saratoga: it should be possible, but you need to know the actual clock frequency of the device, luckily my parse_testcodec can do that |
| 23:54:20 | saratoga | cool |
| 23:54:28 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
| 23:57:18 | saratoga | someone should try doing test_codec on the nano2g without boosting |
| 23:57:44 | kugel | gah, ape is messing up the chart |
| 23:58:39 | | Quit advcomp2019 (Quit: There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.) |
icon identifies that the person is a core developer (has commit access).