| 00:00:19 | | Quit Dege (Read error: 110 (Connection timed out)) |
| 00:00:37 | mc2739 | kugel: pong |
| 00:00:42 | | Quit Horscht ("Verlassend") |
| 00:01:46 | kugel | mc273: can you give http://www.rockbox.org/tracker/task/10667 a test, to see if it fixes the scrollwheel problems? |
| 00:02:19 | mc2739 | sure |
| 00:02:40 | TheSeven | i assume "B" in the stack view means that the thread is blocked? |
| 00:02:48 | TheSeven | what does a "+" in front of it mean? |
| 00:07:48 | amiconn | + means the thread in question requested a cpu boost |
| 00:08:34 | amiconn | See debug_menu.c line 120..226 |
| 00:12:15 | | Quit Tristan (Nick collision from services.) |
| 00:12:34 | TheSeven | ok, so the codec and audio threadys are blocked, and audio is requesting a boost |
| 00:13:27 | | Join _Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) |
| 00:15:42 | | Join FlynDice [0] (n=FlynDice@65.74.4.35) |
| 00:16:15 | * | TheSeven can't think any more and will go to bed now |
| 00:26:58 | | Part froggyman |
| 00:39:32 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 00:41:26 | | Quit JackWinter (Read error: 104 (Connection reset by peer)) |
| 00:41:52 | *** | Saving seen data "./dancer.seen" |
| 00:46:03 | | Quit mt (Read error: 113 (No route to host)) |
| 00:47:20 | mc2739 | kugel: scrollwheel patch works quite good |
| 00:47:40 | kugel | cool |
| 00:47:57 | kugel | mc2739: how's it compared to http://www.rockbox.org/tracker/task/10603 ? |
| 00:48:27 | mc2739 | no more jumping, good slow response, good acceleration |
| 00:49:11 | mc2739 | I'd say it is probably as good as FS #10603 |
| 00:50:36 | kugel | I'll post a patch to it which works very well for the fuze (including hold button. finally) |
| 00:50:40 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 00:51:12 | mc2739 | good work! |
| 00:51:58 | bertrik | kugel, oh you figured out the hold button? what was the problem? |
| 00:52:45 | bertrik | my guess wass that the hold button just takes longer than the other buttons to reach its final value after the "precharge" |
| 00:53:13 | kugel | yea, i did |
| 00:53:37 | kugel | bertrik: exactly, I need a delay. But, I also need to set bit 19 (tri-state) of dbop_ctrl |
| 00:55:12 | | Join Hillshum [0] (n=hillshum@75-165-237-63.slkc.qwest.net) |
| 00:56:06 | kugel | bertrik: btw, why are you incrementing/decrementing dbop_locked? that requires reading it |
| 00:56:56 | * | kugel wonders what impact reading dbop_din has on the lcd framerates |
| 00:57:19 | | Join GeekShado_ [0] (n=Antoine@63.172.97-84.rev.gaoland.net) |
| 00:58:35 | bertrik | kugel, it was meant as a protection against nested locks, so that it only really unlocks when reaching 0 again |
| 00:59:09 | | Quit JackWinter (Read error: 60 (Operation timed out)) |
| 00:59:19 | bertrik | I expect the impact of reading to be very small, it's basically just a few cycles (write cycle + read cycle + extra delay for hold button) |
| 01:00 |
| 01:00:11 | bertrik | it can be probably be done in just over 1 microsecond |
| 01:01:54 | | Quit antil33t () |
| 01:02:28 | kugel | I don't think nested locks are possible |
| 01:02:43 | kugel | since drawing is only done/allowed in the main thread |
| 01:05:24 | bertrik | the case I was thinking of was that lcd_update might lock and then call a lcd sub-function that also calls dbop_lock (and dbop_unlock), causing the lock to be released too early |
| 01:05:47 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 01:07:10 | kugel | the sub-functions don't do locking (at least not in SVN) |
| 01:07:58 | bertrik | this was just defensive programming, just in case someone might modify the lcd code and not realise this potential problem |
| 01:08:56 | | Quit DerPapst ("Leaving.") |
| 01:09:18 | bertrik | I'm with making it a simple boolean-like variable, if you insist :) |
| 01:09:29 | kugel | just saying, reading the value makes the overhead a tiny bit higher |
| 01:09:42 | kugel | I don't think it matters too much |
| 01:09:42 | bertrik | I meant, I'm OK ... |
| 01:11:43 | bertrik | How are you doing the delay? I think an elegant method would be to simply read the dbop twice (and discarding the first read), so the read delay is based on PCLK timing and relatively independent of CPU frequency / boost |
| 01:11:47 | | Quit robin0800 (Remote closed the connection) |
| 01:12:37 | kugel | simple busy wait |
| 01:12:43 | bertrik | (I'm still hoping for the possibility of a "universal" DBOP read method) |
| 01:12:48 | kugel | I don't find reading it twice elegant at all |
| 01:13:24 | bertrik | a simple busy wait suffers from variable delay due to variable CPU frequency |
| 01:14:00 | kugel | yes, but I'd rather find a way to do udelay() instead reading it twice |
| 01:14:17 | | Quit JackWinter (Remote closed the connection) |
| 01:14:40 | | Quit GeekShadow (Connection timed out) |
| 01:14:56 | kugel | but we are at a point now where we cannot be much faster (max cpu freq, caches working, max lcd framerate), so the delay shouldn't be needed to increased |
| 01:16:41 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 01:17:06 | bertrik | if the busy wait delay is just long enough to work correctly at Fcpu=248 MHz, it will waste unneeded time at Fcpu=62 MHz |
| 01:17:29 | kugel | that's true for all delays |
| 01:18:20 | bertrik | a DBOP read cycle is timed with PCLK, which is a constant |
| 01:18:39 | kugel | maybe we can have a udelay, using the tick interrupt (handling wrap, but capping it to 5ms to keep it simple) |
| 01:20:54 | bertrik | how much delay do we need really? I think the tick interrupt is way too slow for this |
| 01:26:36 | | Quit FlynDice (Read error: 60 (Operation timed out)) |
| 01:27:40 | CIA-43 | New commit by kugel (r23059): Fuze/e200v2: Fix inaccuracy when moving the wheel slowly (fixes FS #10667). |
| 01:28:36 | kugel | bertrik: why is it too slow? |
| 01:29:13 | kugel | I'm not thinking of waiting for the tick interrupt to fire of, but busy waiting his actual value |
| 01:29:17 | bertrik | most buttons (except hold) require on the order of a microsecond to read, the tick interrupt runs at 5 or 10 ms |
| 01:29:45 | bertrik | ah ok, you want to read some counter value |
| 01:30:15 | kugel | you just need to handle at most 1 wrap if you cap it |
| 01:32:20 | | Quit MethoS- (Remote closed the connection) |
| 01:33:10 | kugel | or watchdog |
| 01:35:27 | kugel | watchdog seems doable actually |
| 01:36:28 | amiconn | kugel: Nothing *guarantees* that the main thread is the only one ever drawing to the lcd. That said, no other thread should draw to the lcd during normal operation (by convention). Technically all thread could draw without confusing the lcd controller (this would probably produce gibberish in the framebuffer though) |
| 01:37:06 | kugel | I knew that |
| 01:37:39 | amiconn | But the main thread is allowed to hand over lcd control to another thread. Iirc mpegplayer is drawing from another thread. And the greylib even does something you should never do during normal operation: it draws from an isr |
| 01:38:18 | amiconn | The latter would instantly confuse the lcd controller when mixed with normal drawing from a thread |
| 01:41:20 | kugel | hrm, no, watchdog isn't clocked high enough |
| 01:43:02 | amiconn | bertrik, kugel: Can't you make the delay depend on cpu frequency? |
| 01:43:50 | bertrik | amiconn, I'd rather make it depend on the peripheral clock frequency, which is constant regardless of boost |
| 01:44:35 | bertrik | like implementing the delay by doing a dummy DBOP read (which is clocked by the peripheral clock PCLK) :) |
| 01:44:41 | | Quit GeekShado_ ("The cake is a lie !") |
| 01:45:10 | kugel | bertrik: the dbop clock may change too in the future |
| 01:45:49 | bertrik | we'll fix that problem in the future then :) |
| 01:46:30 | amiconn | On coldfire some drivers are adjusting delays based on cpu clock |
| 01:46:34 | kugel | we can do that with a plain delay also |
| 01:47:34 | kugel | amiconn: can one have a almost-accurate udelay() using nops and bein dependant on the frequency? |
| 01:47:51 | amiconn | The bit-banging i2c driver for the pcf50606 adjusts the number of iterations of delay loops, and the bit.banging remote lcd drivers even switch transfer routines at a certain frequency |
| 01:48:21 | | Quit ender` (" Engineers think that equations approximate the real world. Scientists think that the real world approximates equations. Mat") |
| 01:49:08 | amiconn | kugel: No, since there is no guarantee the loop won't be interrupted. But it's still better than consistently waiting for too long at lower clock frequencies |
| 01:50:15 | kugel | doesn't the problem with being interrupt apply to other udelay()s as well (even those using a separate timer)? |
| 01:50:17 | | Quit togetic ("WeeChat 0.3.0") |
| 01:50:28 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 01:51:08 | kugel | well, those using a separate timer wouldn't be wrong if the delay was bigger than the isr needs time |
| 01:52:09 | amiconn | exactly |
| 01:52:45 | amiconn | If you need guaranteed delays you need to disable interrupts, but that has to be done very carefully |
| 01:52:54 | amiconn | Interrupts should never be disabled for too long |
| 01:53:04 | bertrik | I think we basically just need a *minimal* time delay for DBOP |
| 01:53:07 | kugel | I think being accurate most of the time is sufficient enough |
| 01:53:23 | bertrik | so a little extra latency from an interrupt should not be a problem |
| 01:53:24 | kugel | as long as it's not shorter that requested |
| 01:53:44 | | Join FlynDice [0] (n=FlynDice@65.74.4.35) |
| 01:55:12 | | Quit bertrik ("sleep") |
| 01:55:50 | amiconn | If you only need a certain minimum delay, an ordinary loop is sufficient. Changing the loop count according to cpu clock then is a matter of efficiency if the routine containing the delay is called very often |
| 01:56:05 | amiconn | ...and the cpu frequency is variable, of course |
| 01:57:11 | amiconn | The pcf i2c on H300 and X5/M5 used called every tick so efficiency was important |
| 01:58:18 | amiconn | (as long as no remote is connected it's not that critical nowadays, because it's then only called every tick if at least one button is pressed) |
| 02:00 |
| 02:03:32 | | Quit togetic ("WeeChat 0.3.0") |
| 02:03:33 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 02:08:49 | kugel | actually, I think I've managed to make a udelay |
| 02:10:48 | | Quit Thundercloud (Remote closed the connection) |
| 02:12:58 | kugel | amiconn: does that look sane? http://pastie.org/649105 |
| 02:13:23 | | Quit StealthyXIIGer (Client Quit) |
| 02:14:46 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 02:22:34 | | Quit pixelma (Nick collision from services.) |
| 02:22:35 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 02:22:47 | | Quit amiconn (Nick collision from services.) |
| 02:22:51 | | Join amiconn___ [0] (i=quassel@p57A0EEC2.dip.t-dialin.net) |
| 02:22:54 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 02:22:58 | | Nick amiconn___ is now known as amiconn (i=quassel@p57A0EEC2.dip.t-dialin.net) |
| 02:25:51 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 02:37:22 | | Quit Horscht ("Verlassend") |
| 02:41:56 | *** | Saving seen data "./dancer.seen" |
| 02:44:11 | | Quit efyx_ (Remote closed the connection) |
| 02:52:47 | | Join Hillshum_ [0] (n=hillshum@75-165-235-2.slkc.qwest.net) |
| 02:53:03 | | Quit chandoo ("Leaving") |
| 02:53:49 | | Quit kkurbjun (Read error: 110 (Connection timed out)) |
| 02:54:54 | | Quit Hillshum (Read error: 113 (No route to host)) |
| 02:58:04 | | Quit gevaerts (Nick collision from services.) |
| 02:58:16 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 02:59:17 | | Quit Zoxc () |
| 03:00 |
| 03:01:21 | | Quit JackWinter (Read error: 131 (Connection reset by peer)) |
| 03:03:58 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 03:04:35 | | Nick Hillshum_ is now known as Hillshum (n=hillshum@75-165-235-2.slkc.qwest.net) |
| 03:05:13 | | Join midgey [0] (n=tjross@rockbox/developer/midgey) |
| 03:05:50 | | Join kkurbjun [0] (n=kkurbjun@c-98-245-170-51.hsd1.co.comcast.net) |
| 03:28:47 | | Join efyx [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 03:34:09 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 03:53:18 | | Join IceGuest_75_ [0] (n=IceChat7@nmd.sbx05656.mesaxaz.wayport.net) |
| 03:53:24 | IceGuest_75_ | hi |
| 03:53:55 | IceGuest_75_ | with jailbreak for the ipod touch will rockbox be ported to ipod touch |
| 03:54:03 | Hillshum | Not likely |
| 03:54:17 | IceGuest_75_ | no love for the ipod touch |
| 03:54:22 | Hillshum | IceGuest_75_: If you do it then yes |
| 03:54:43 | IceGuest_75_ | ha |
| 03:54:47 | IceGuest_75_ | not a programmer |
| 03:55:08 | IceGuest_75_ | but i hear you |
| 03:55:37 | Hillshum | Platforms like the iPod Touch are much more suited for Rockbox running as an app rather than as a firmware replacement, and getting that to work takes a good deal of work |
| 03:55:54 | IceGuest_75_ | good point |
| 03:58:05 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 03:59:30 | IceGuest_75_ | have you seen jailbroken ipod? |
| 03:59:48 | IceGuest_75_ | does it make ipod touch much better? |
| 04:00 |
| 04:01:07 | Hillshum | IceGuest_75_: It means we don't have to deal with getting into the App Store, but that's about it |
| 04:01:34 | IceGuest_75_ | sounds like no big deal |
| 04:02:55 | Hillshum | What do you mean by that? |
| 04:03:24 | IceGuest_75_ | sounds like jailbroken ipod touch is not that cool |
| 04:03:53 | | Join Revolution [0] (n=revoluti@pool-151-204-78-89.delv.east.verizon.net) |
| 04:04:44 | Hillshum | Oh. If I had one I'd jailbreak it quick, but this is getting off-topic anyway |
| 04:05:10 | Revolution | wat was the question? |
| 04:05:49 | Hillshum | Revolution: regarding iTouches |
| 04:06:15 | Revolution | oh i hav 1 |
| 04:06:22 | Revolution | they r cool |
| 04:06:30 | Revolution | mines jailbroken |
| 04:06:57 | | Quit TheSeven (Nick collision from services.) |
| 04:07:15 | | Join The_Seven [0] (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 04:07:21 | Revolution | and i think my nano 2g is almost as cool as itouch as soon as i put rockbox on it |
| 04:07:21 | IceGuest_75_ | COOL |
| 04:07:27 | | Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 04:07:37 | IceGuest_75_ | i have a nano |
| 04:07:43 | IceGuest_75_ | it's the new one though |
| 04:07:54 | IceGuest_75_ | can't put rockbox on it right? |
| 04:08:03 | Hillshum | No |
| 04:08:17 | Hillshum | Only the first-generation |
| 04:08:21 | IceGuest_75_ | sux |
| 04:08:31 | IceGuest_75_ | i miss rockbox |
| 04:08:54 | Revolution | second 2 |
| 04:09:01 | Revolution | nano 2g works now |
| 04:09:12 | Revolution | look it up in the build |
| 04:09:36 | Hillshum | Sorta |
| 04:09:40 | Revolution | http://l4n.clustur.com/ |
| 04:10:12 | Revolution | well i hav a self built debug build on my nano 2g |
| 04:10:39 | | Quit Revolution (Read error: 104 (Connection reset by peer)) |
| 04:10:39 | | Join Revolution_ [0] (n=revoluti@pool-151-204-78-89.delv.east.verizon.net) |
| 04:10:45 | IceGuest_75_ | with the advent of 2g is 3g and 4g in the works? |
| 04:10:49 | | Nick Revolution_ is now known as Revolution (n=revoluti@pool-151-204-78-89.delv.east.verizon.net) |
| 04:11:01 | Revolution | so it works 4 me |
| 04:11:17 | IceGuest_75_ | with the advent of 2g is 3g and 4g in the works? |
| 04:11:42 | Revolution | yep 3g and 4g is in the works |
| 04:11:46 | Hillshum | IceGuest_75_: Not really. 3g is I think somewhat similar to the 2g, not sure about the 4g |
| 04:11:59 | Revolution | they hav execution on 4g |
| 04:12:06 | Revolution | not on 3g though |
| 04:12:17 | IceGuest_75_ | really, is there a timeline on 4g? |
| 04:12:24 | Revolution | not really |
| 04:12:32 | | Quit kugel ("Ex-Chat") |
| 04:12:34 | IceGuest_75_ | cool |
| 04:12:37 | Revolution | i think they wanna finish 2g first |
| 04:13:10 | | Quit Revolution (Read error: 104 (Connection reset by peer)) |
| 04:13:10 | | Join Revolution_ [0] (n=revoluti@pool-151-204-78-89.delv.east.verizon.net) |
| 04:13:23 | IceGuest_75_ | thx guys |
| 04:13:25 | | Nick Revolution_ is now known as Revolution (n=revoluti@pool-151-204-78-89.delv.east.verizon.net) |
| 04:13:27 | | Part IceGuest_75_ |
| 04:13:35 | Revolution | ok |
| 04:15:09 | | Quit Strife89 ("Bed.") |
| 04:18:39 | | Quit Revolution (Remote closed the connection) |
| 04:27:49 | | Quit intrados3 (Connection timed out) |
| 04:38:34 | | Quit Rondom (Nick collision from services.) |
| 04:38:45 | | Join Rondom [0] (n=Rondom@dslb-084-057-140-153.pools.arcor-ip.net) |
| 04:41:58 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:08:37 | | Join JackWinter2 [0] (n=jack@vodsl-10804.vo.lu) |
| 05:12:00 | | Join Strife89 [0] (n=michael@adsl-220-123-13.mcn.bellsouth.net) |
| 05:21:00 | | Quit JackWinter (Read error: 110 (Connection timed out)) |
| 05:23:16 | LambdaCalculus37 | I would not recommend using Rockbox on the 2nd gen nano just yet. |
| 05:23:36 | LambdaCalculus37 | It's still very buggy in terms of audio playback, and some functions have not been implemented yet. |
| 06:00 |
| 06:11:40 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 06:24:36 | | Quit midgey () |
| 06:24:45 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 06:26:32 | | Quit efyx (Remote closed the connection) |
| 06:28:06 | | Join panni__ [0] (i=hannes@95.222.21.143) |
| 06:29:04 | | Quit JackWinter2 (robinson.freenode.net irc.freenode.net) |
| 06:29:04 | NSplit | robinson.freenode.net irc.freenode.net |
| 06:29:04 | | Quit _Tristan (robinson.freenode.net irc.freenode.net) |
| 06:29:04 | | Quit panni_ (robinson.freenode.net irc.freenode.net) |
| 06:29:04 | | Quit pcc1 (robinson.freenode.net irc.freenode.net) |
| 06:29:04 | | Quit r00s (robinson.freenode.net irc.freenode.net) |
| 06:30:02 | NHeal | robinson.freenode.net irc.freenode.net |
| 06:30:02 | NJoin | JackWinter2 [0] (n=jack@vodsl-10804.vo.lu) |
| 06:33:25 | | Join Tristan [0] (i=tristan@66.252.24.153) |
| 06:42:00 | *** | Saving seen data "./dancer.seen" |
| 06:47:36 | | Quit Kohlrabi (Remote closed the connection) |
| 06:47:40 | | Join Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) |
| 06:56:45 | froggyman | /join #rockbox-community |
| 06:57:41 | | Part froggyman |
| 06:57:49 | | Quit LambdaCalculus37 ("Fwump") |
| 07:00 |
| 07:24:48 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 07:28:01 | | Quit panni__ (Read error: 131 (Connection reset by peer)) |
| 07:33:23 | | Quit Lss (Read error: 110 (Connection timed out)) |
| 07:43:38 | | Quit Hillshum ("Ex-Chat") |
| 07:56:13 | | Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) |
| 07:58:44 | | Quit FlynDice (Read error: 60 (Operation timed out)) |
| 08:00 |
| 08:01:04 | | Join stoffel [0] (n=quassel@p57B4DFCB.dip.t-dialin.net) |
| 08:22:33 | DEBUG | EOF from server (Connection timed out) (snapshot: netstuff.c line 545) |
| 08:22:33 | *** | Cleanup |
| 08:22:33 | *** | Cleanup |
| 08:22:33 | *** | Saving seen data "./dancer.seen" |
| 08:22:33 | *** | Exit |
| 08:22:36 | *** | Started Dancer V4.16 |
| 08:22:36 | *** | Connected to irc.freenode.net on port 6667 |
| 08:22:36 | *** | Logfile for #rockbox started |
| 08:22:38 | *** | Server message 501: 'logbot :Unknown MODE flag' |
| 08:22:38 | Mode | "logbot :+i" by logbot |
| 08:22:38 | | Join logbot [0] (n=rockbox@giant.haxx.se) |
| 08:22:38 | | Join yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
| 08:22:38 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 08:22:38 | | Join robin0800_ [0] (n=robin080@general-ld-216.t-mobile.co.uk) |
| 08:22:38 | | Join tmzt [0] (n=tmzt@adsl-99-52-65-233.dsl.akrnoh.sbcglobal.net) |
| 08:22:38 | | Join fxb__ [0] (n=felixbru@85.214.97.64) |
| 08:22:38 | | Join polobricolo [0] (n=paul@86.193.13.12) |
| 08:22:38 | | Join batman52 [0] (n=chatzill@dfv4p34j.polito.it) |
| 08:22:38 | | Join Llorean1 [0] (n=DarkkOne@adsl-99-4-146-40.dsl.hstntx.sbcglobal.net) |
| 08:22:38 | | Join Bob_C [0] (n=chatzill@host86-141-199-226.range86-141.btcentralplus.com) |
| 08:22:38 | | Join hd [0] (n=jd@Wikipedia/HellDragon) |
| 08:22:38 | | Join stoffel [0] (n=quassel@p57B4DFCB.dip.t-dialin.net) |
| 08:22:38 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 08:22:38 | | Join Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) |
| 08:22:38 | | Join Tristan [0] (i=tristan@66.252.24.153) |
| 08:22:38 | | Join JackWinter2 [0] (n=jack@vodsl-10804.vo.lu) |
| 08:22:38 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 08:22:38 | | Join Strife89 [0] (n=michael@adsl-220-123-13.mcn.bellsouth.net) |
| 08:22:38 | | Join Rondom [0] (n=Rondom@dslb-084-057-140-153.pools.arcor-ip.net) |
| 08:22:38 | | Join TheSeven [0] (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 08:22:38 | | Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) |
| 08:22:38 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 08:22:38 | | Join amiconn [0] (i=quassel@p57A0EEC2.dip.t-dialin.net) |
| 08:22:38 | | Join pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 08:22:38 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 08:22:38 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 08:22:38 | | Join Galois [0] (i=djao@efnet.math.uwaterloo.ca) |
| 08:22:38 | | Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) |
| 08:22:38 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 08:22:38 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 08:22:38 | | Join lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) |
| 08:22:38 | | Join elcan [0] (i=user36@pr0.us) |
| 08:22:38 | | Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 08:22:38 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 08:22:38 | | Join Topy [0] (n=Topy44@f054174066.adsl.alicedsl.de) |
| 08:22:38 | | Join GodEater_ [0] (n=bibble@rockbox/staff/GodEater) |
| 08:22:38 | | Join pjm0616 [0] (n=user@61.250.113.98) |
| 08:22:38 | | Join tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) |
| 08:22:38 | | Join ch4os [0] (n=ch4os@gentoo/user/ch4os) |
| 08:22:38 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 08:22:38 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 08:22:38 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 08:22:38 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 08:22:38 | | Join saratoga [0] (i=98039f25@gateway/web/freenode/x-lqpprvomqheekqip) |
| 08:22:38 | | Join Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) |
| 08:22:38 | | Join liar|netbook [0] (n=liar@83.175.83.185) |
| 08:22:38 | | Join linuxguy3 [0] (n=timj@adsl-75-58-40-183.dsl.emhril.sbcglobal.net) |
| 08:22:38 | | Join niekie [0] (i=quasselc@dreamworld.bergnetworks.com) |
| 08:22:38 | | Join gtkspert_ [0] (n=gtkspert@203-206-40-4.dyn.iinet.net.au) |
| 08:22:38 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 08:22:38 | | Join Rob2223 [0] (n=Miranda@p4FDCD232.dip.t-dialin.net) |
| 08:22:38 | | Join Res1 [0] (n=Res@user-0c6s6ir.cable.mindspring.com) |
| 08:22:38 | | Join evilnick [0] (n=evilnick@rockbox/staff/evilnick) |
| 08:22:38 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
| 08:22:38 | | Join freqmod_qu [0] (i=quasselg@dhcp208-240.ed.ntnu.no) |
| 08:22:38 | | Join thegeek [0] (n=nnscript@s168c.studby.ntnu.no) |
| 08:22:38 | | Join preglow [0] (n=thomj@tvilling2.pvv.ntnu.no) |
| 08:22:38 | | Join Hadaka [0] (n=naked@naked.iki.fi) |
| 08:22:38 | | Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
| 08:22:38 | | Join parafin [0] (i=parafin@paraf.in) |
| 08:22:38 | | Join bubsy [0] (n=bubsy@94.139.72.137) |
| 08:22:38 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 08:22:38 | | Join mc2739 [0] (n=mc2739@rockbox/developer/mc2739) |
| 08:22:38 | | Join tarbo [0] (n=me@unaffiliated/tarbo) |
| 08:22:38 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 08:22:38 | | Join killan_ [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 08:22:38 | | Join xavieran [0] (n=xavieran@ppp121-44-220-190.lns10.mel4.internode.on.net) |
| 08:22:38 | | Join HBK- [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 08:22:38 | | Join shadearg [0] (i=arg@ipv4.panoptix.net) |
| 08:22:38 | | Join feisar-_ [0] (i=jljhook@irkki.fi) |
| 08:22:38 | | Join Zambezi [0] (i=Zulu@80.67.9.2) |
| 08:22:38 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 08:22:38 | | Join jvd [0] (n=syscrash@poipu/developer/syscrash) |
| 08:22:38 | | Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk) |
| 08:22:38 | | Join blithe [0] (n=blithe@blakesmith.me) |
| 08:22:38 | | Join ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) |
| 08:22:38 | | Join dionoea [0] (n=dionoea@videolan/developer/dionoea) |
| 08:22:38 | | Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) |
| 08:22:38 | | Join jds2001 [0] (n=jds2001@fedora/jds2001) |
| 08:22:38 | | Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
| 08:22:38 | | Join aidy [0] (n=aidy@mail.rty.ca) |
| 08:22:38 | | Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
| 08:22:38 | | Join YPSY [0] (n=ypsy@87.106.45.183) |
| 08:22:38 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
| 08:22:38 | | Join jordan`` [0] (i=gromit@78.235.252.137) |
| 08:22:38 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 08:22:38 | | Join Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) |
| 08:22:38 | | Join jfc [0] (n=john@dpc6682208002.direcpc.com) |
| 08:22:38 | | Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 08:22:38 | | Join Shaid [0] (i=adam@lurking.shaid.net) |
| 08:22:38 | | Join janne_oksanen [0] (n=janne@130.234.191.99) |
| 08:22:38 | | Join volkmar [0] (n=volkmar@gentoo/developer/volkmar) |
| 08:22:38 | | Join crashd [0] (i=foobar@lostnode.org) |
| 08:22:38 | | Join scorche [50] (n=scorche@rockbox/administrator/scorche) |
| 08:22:38 | | Join rasher [50] (n=rasher@rockbox/developer/rasher) |
| 08:22:38 | | Join maraz_ [0] (i=maraz@xob.kapsi.fi) |
| 08:22:38 | | Join Bagder [241] (n=daniel@rockbox/developer/bagder) |
| 08:22:38 | | Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
| 08:22:38 | | Join Beta2K [0] (n=beta@d24-36-68-97.home1.cgocable.net) |
| 08:22:38 | | Join goffa [0] (n=goffa@70.33.8.114) |
| 08:22:38 | | Join rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) |
| 08:22:38 | | Join zu [0] (n=zu@bucketheaded.eu) |
| 08:22:38 | | Join CIA-43 [0] (n=CIA@208.69.182.149) |
| 08:22:38 | | Join lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) |
| 08:22:38 | | Join DaCapn [0] (i=dacapn@using.your.wireless-inter.net) |
| 08:22:38 | | Join AB3JU [0] (n=dz@alt.dissonance.nl) |
| 08:22:38 | | Join meermanr [0] (n=meermanr@robmeerman.co.uk) |
| 08:22:38 | | Join alexbobp [0] (n=alex@66.112.249.119) |
| 08:22:38 | | Join scorche|sh [50] (n=scorche@rockbox/administrator/scorche) |
| 08:22:38 | | Join fish_ [0] (n=fish@freigeist.org) |
| 08:22:38 | | Join redfox [0] (n=redfox2@ns351996.ovh.net) |
| 08:22:38 | | Join Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) |
| 08:22:38 | | Join bzed [0] (n=bzed@devel.recluse.de) |
| 08:22:38 | | Join jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 08:22:38 | | Join UserFriendly [0] (n=qball@unaffiliated/qball) |
| 08:22:38 | | Join @ChanServ [0] (ChanServ@services.) |
| 08:22:38 | | Join w1ll14m| [0] (n=nobody@84-104-81-17.cable.quicknet.nl) |
| 08:22:38 | | Join TDJACR [0] (n=TDJACR@Wikipedia/Thedjatclubrock) |
| 08:22:38 | | Join courtc [0] (n=court@unaffiliated/courtc) |
| 08:22:38 | | Join crwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi) |
| 08:24:54 | Ctcp | Version from freenode-connect!freenode@freenode/bot/connect |
| 08:24:55 | *** | Server message 477: 'logbot #rockbox :[freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp' |
| 08:25:11 | shai | Is it common to replace iPod's firmware with Rockbox? |
| 08:25:17 | | Quit Strife89 ("If you hold a Linux shell to your ear, you can hear the C.") |
| 08:25:52 | robin0800_ | shai: no but you can |
| 08:26:09 | shai | robin0800_, After using the Rockbox Utility, I still have the ability to boot into iPod's original firmware and I have leftovers in the filesystem too... |
| 08:27:57 | robin0800_ | shai: like what? |
| 08:31:13 | shai | Directories called "iPod Computer Transfer" and "iPod_Control" |
| 08:32:06 | shai | I don't know if Calendars, Contacts etc. are also from original or came from Rockbox |
| 08:32:25 | shai | I also have Photos and Notes |
| 08:33:17 | robin0800_ | shai: I think most of your questions are answered here http://www.rockbox.org/wiki/IpodFAQ and all those folders are ipod ones |
| 08:34:00 | | Join Rob2222 [0] (n=Miranda@p4FDCD8BE.dip.t-dialin.net) |
| 08:34:46 | shai | robin0800_, I will go read :) |
| 08:36:23 | | Quit Topy (Read error: 104 (Connection reset by peer)) |
| 08:36:38 | | Join Topy44 [0] (n=Topy44@f054174066.adsl.alicedsl.de) |
| 08:44:55 | | Join lifeless_ [0] (n=lifeless@188.18.80.194) |
| 08:51:40 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 08:52:25 | | Join snookums [0] (n=N_Sherza@cpe-69-133-10-20.cinci.res.rr.com) |
| 09:00 |
| 09:12:33 | | Quit snookums () |
| 09:12:36 | | Quit GodEater_ ("leaving") |
| 09:12:44 | | Join snookums [0] (n=N_Sherza@cpe-69-133-10-20.cinci.res.rr.com) |
| 09:12:48 | | Join GodEater [0] (n=bibble@bb-87-80-121-64.ukonline.co.uk) |
| 09:17:29 | CIA-43 | New commit by nls (r23060): Clean up a bogus array and avoid some copying of static strings |
| 09:21:07 | | Part jon-kha ("[IRSSI] the cure for the common client") |
| 09:22:13 | | Join jon-kha [0] (i=jon-kha@83.150.91.127) |
| 09:27:15 | | Quit snookums () |
| 09:29:50 | polobricolo | does the rockbox still has some freezes on the nano2g |
| 09:37:10 | amiconn | n1s: Why did you remove the second 'const'? |
| 09:38:04 | n1s | amiconn: eh, oops; i'll put it back |
| 09:38:45 | amiconn | static const char * const freq_strings[] |
| 09:39:09 | amiconn | The pointers are also constant - 6*4 bytes which end up in flash instead of ram when running from rom |
| 09:39:30 | n1s | right |
| 09:39:33 | amiconn | Nice spot though (12 -> 6) |
| 09:41:52 | CIA-43 | New commit by nls (r23061): Add second 'const' qualifyer accidentally removed in r23060 |
| 09:43:30 | amiconn | This could be made even more efficient by using a 2-dimensional char array instead of an array of char pointer, but that may be too ugly to be worth it |
| 09:44:58 | n1s | that const pointer thing can probably be done in a few more places |
| 09:46:55 | CIA-43 | New commit by nls (r23062): Deinline fuction and some whitespace tweaks |
| 09:47:47 | n1s | amiconn: are there any targets that can still run from rom? |
| 09:48:37 | pixelma | sure |
| 09:49:32 | pixelma | n1s: the Player, OndioSP and the H120s |
| 09:49:32 | amiconn | 3 targets can, although I still didn't do it on the 3rd: Archos Player, Ondio SP, and iriver H1x0 |
| 09:49:54 | n1s | ah |
| 09:50:25 | amiconn | The other archoses can as well, if they're modded with a 512KB flash rom |
| 09:50:37 | n1s | btw i think we should make that h100 flash support more official, i.e supported by an official bootloader and described in the manual |
| 09:50:40 | linuxstb | polobricolo: You tell us! TheSeven made a commit last night which should help a little, but I think there are still problems. |
| 09:50:50 | amiconn | Afaik [IDC]Dragon was the only one who ever did this mod though |
| 09:51:31 | amiconn | n1s: The official bootloader is still awaiting testing by LinusN :( |
| 09:51:36 | polobricolo | linuxstb: ok i'll update my rockbox.ipod file and i tell you |
| 09:51:46 | pixelma | I guess the OndioSP is the closest to lose rombox of those 3 |
| 09:52:46 | n1s | amiconn: i thought it was pretty ell tested by others by now or is that a different one than the version Slasheri released? |
| 09:54:47 | amiconn | Afaik Slasheri's version doesn't contain the CF related fixes, and probably other storage related ones. Imo we should release a bootloader which is based on current driver code - but testing such a bootloader may need a bdm for recovery |
| 09:55:39 | amiconn | I'm not sure, there might have been some more things to check as well. Quite some time has passed :\ |
| 09:57:03 | n1s | yes, the h300 bootloader is in a similar state, the released one is buggy and no new one in sight |
| 09:58:12 | pixelma | I thought a newer one had trouble on some devices (e.g. petur's) |
| 09:58:23 | pixelma | H300 bootloader that is |
| 10:00 |
| 10:00:32 | n1s | yeah i think so |
| 10:01:52 | | Join snookums [0] (n=N_Sherza@cpe-69-133-10-20.cinci.res.rr.com) |
| 10:02:45 | | Quit snookums (Client Quit) |
| 10:05:45 | amiconn | One problem I know about the H300 bootloader is that the current official one produces a nasty click when entering bootloader usb, but not during normal boot - on my H300 |
| 10:06:18 | amiconn | LinusN's fix for that made it click on normal boot instead on mine |
| 10:11:39 | n1s | it also starts the OF when ac is inserted which was intentional but is very annoying and it turns off immediately if powered on with the non lcd remote |
| 10:11:51 | n1s | and i think it has problems with CF too |
| 10:12:08 | | Quit Grahack ("Leaving.") |
| 10:14:00 | amiconn | Very likely. It's as old as the H1x0 bootloader |
| 10:20:36 | | Join intrados3 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 10:21:06 | | Join snookums [0] (n=N_Sherza@cpe-69-133-10-20.cinci.res.rr.com) |
| 10:22:40 | *** | Saving seen data "./dancer.seen" |
| 10:29:15 | CIA-43 | New commit by nls (r23063): Make function arg const pointer |
| 10:37:13 | | Quit AB3JU (verne.freenode.net irc.freenode.net) |
| 10:37:13 | NSplit | verne.freenode.net irc.freenode.net |
| 10:37:43 | NHeal | verne.freenode.net irc.freenode.net |
| 10:37:43 | NJoin | AB3JU [0] (n=dz@alt.dissonance.nl) |
| 10:51:09 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 11:00 |
| 11:08:33 | | Join DerPapst [0] (n=DerPapst@p4FE8EE55.dip.t-dialin.net) |
| 11:16:20 | | Join funman [0] (n=fun@2001:0:53aa:64c:207f:2ca3:a9b7:5870) |
| 11:16:48 | | Nick funman is now known as Guest98412 (n=fun@2001:0:53aa:64c:207f:2ca3:a9b7:5870) |
| 11:17:19 | | Nick Guest98412 is now known as funman (n=fun@2001:0:53aa:64c:207f:2ca3:a9b7:5870) |
| 11:22:36 | funman | Zagor: can you fix http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot-1.1 permissions ? (i see mkamsboot-1.1RC is back ?) |
| 11:24:18 | TheSeven | can anybody tell me where i can find the code that is run if i click on a music file in the file browser? |
| 11:27:20 | funman | TheSeven: ft_enter() in filetree.c is a good start i think |
| 11:27:47 | funman | then filetype_get_plugin() and plugin_load() |
| 11:31:22 | TheSeven | thanks |
| 11:32:34 | | Quit polobricolo (Read error: 131 (Connection reset by peer)) |
| 11:40:01 | | Join Horscht [0] (n=Horscht2@79.212.196.186) |
| 11:42:25 | amiconn | funman, TheSeven: Starting a music file doesn't call plugin_load() for sure. |
| 11:42:31 | amiconn | Playback is core functionality |
| 11:44:09 | funman | TheSeven: did you see http://www.rockbox.org/tracker/task/10656 ? |
| 11:44:37 | TheSeven | yes, i did |
| 11:45:30 | TheSeven | but i'll go for more serious things first before fixing cosmetic issues like that one |
| 11:46:16 | funman | amiconn: i can't see where extension comparison is made elsewhere |
| 11:46:49 | TheSeven | funman: it's done with switch ( file->attr & FILE_ATTR_MASK ), whatever this does |
| 11:48:10 | amiconn | Correct, and the case that's executed for an audio file is case FILE_ATTR_AUDIO |
| 11:55:19 | | Join Thundercloud [0] (i=thunderc@81.187.69.84) |
| 11:55:32 | CIA-43 | New commit by nls (r23064): Don't cast away constness |
| 11:56:49 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 11:57:05 | CIA-43 | New commit by nls (r23065): Slight const police and avoid copying a lang string |
| 11:57:31 | funman | who has access to the download server except zagor and Bagder ? |
| 11:58:56 | bertrik | n1s, I saw your commit de-inlining a function and that makes me wonder when to use inline and when not? |
| 11:59:34 | n1s | bertrik: explicit inline is for speed critical things IMO |
| 11:59:49 | bertrik | (I prefer to not use inline, unless for a specific reason) |
| 12:00 |
| 12:01:54 | n1s | using inline on functions that aren't critical for speed usually wastes space (unless the function is static and called few times in which case the compiler might decide not to emit the function body) |
| 12:02:14 | n1s | s/few/times/from few places/ |
| 12:03:02 | bertrik | a quick look at the rockbox code suggests to me that there's a lot of places where it's not really needed |
| 12:03:21 | n1s | h |
| 12:03:42 | n1s | fixing that might save some code then |
| 12:04:56 | n1s | asm stuff is of course special |
| 12:05:13 | bertrik | yes |
| 12:06:20 | | Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) |
| 12:06:35 | amiconn | If a static function is only used once, gcc auto-inlines it anyway |
| 12:06:45 | n1s | yeah |
| 12:07:12 | amiconn | Explicit inline should only be used for speed reasons, as it makes the code larger |
| 12:07:26 | n1s | that's what i was thinking |
| 12:07:51 | amiconn | *Sometimes* that may even make things slower (larger code may cause more cache misses), so it always needs testing |
| 12:10:38 | | Quit funman ("free(random());") |
| 12:13:01 | TheSeven | ok, I narrowed down that freeze to fd = open(trackname, O_RDONLY); |
| 12:13:58 | TheSeven | btw, something's garbling part of the logf buffer |
| 12:17:03 | | Quit barrywardell (Read error: 104 (Connection reset by peer)) |
| 12:17:52 | | Join barrywardell [0] (n=barrywar@p5B25A7AB.dip0.t-ipconnect.de) |
| 12:21:50 | amiconn | TheSeven: File system - as I kinda expected |
| 12:22:00 | * | amiconn guesses it's related to SECTOR_SIZE |
| 12:22:09 | TheSeven | yeah, half of it was icache, half of it FS |
| 12:22:16 | TheSeven | no, it's getting stuck somewhere in the FTL |
| 12:22:42 | *** | Saving seen data "./dancer.seen" |
| 12:22:52 | TheSeven | (and thus holding the mutex, which will make the rest of rockbox lock up soon) |
| 12:23:10 | amiconn | The worm that came from the can, remember? ;) |
| 12:23:28 | TheSeven | no, i don't even think that it's one of those worms |
| 12:23:33 | | Quit faemir ("Leaving") |
| 12:23:52 | TheSeven | that bug rather looks like it is coming from the FTL itself |
| 12:24:12 | TheSeven | ooooh yeah |
| 12:24:20 | TheSeven | double-locking a mutex :-/ |
| 12:24:57 | * | TheSeven needs to look at the kernel, how this is handled |
| 12:26:22 | TheSeven | so far that can seems to only have contained a single worm |
| 12:26:31 | bertrik | in theory, a thread can claim a mutex it has already locked without blocking |
| 12:26:58 | TheSeven | yes, but double-unlocking that afterwards may make things go crazy |
| 12:27:30 | bertrik | it should only really unlock when the number of unlocks is the same as the number of locks, otherwise there might be a bug in the kernel |
| 12:31:37 | TheSeven | ok, had a look at the kernel, this seems to be true |
| 12:36:00 | TheSeven | ok, the lockup is happening in the lowlevel NAND driver |
| 12:36:06 | | Join JackWinter3 [0] (n=jack@vodsl-10804.vo.lu) |
| 12:37:16 | TheSeven | so this is evidence of either failing timeouts or forgetting to unlock a mutex somewhere earlier |
| 12:37:19 | TheSeven | let's see |
| 12:38:27 | * | TheSeven spotted a place where the latter may happen |
| 12:40:51 | TheSeven | that didn't fix it, but it's definitely a NAND mutex issue |
| 12:44:02 | bertrik | are you sure that the mutex is initialised at all? this isn't currently checked in the kernel |
| 12:44:24 | TheSeven | bertrik: I already hit (and caught) that earlier |
| 12:44:43 | TheSeven | and now i also caught this one |
| 12:44:55 | TheSeven | writing a nand page didn't release the mutex if it succeeded |
| 12:45:31 | * | TheSeven wonders why that much could ever work then |
| 12:46:15 | TheSeven | well, yes, at long as it was all being done from the same thread, this worked |
| 12:50:00 | | Quit JackWinter2 (Read error: 110 (Connection timed out)) |
| 12:51:08 | CIA-43 | New commit by theseven (r23066): Fixed some mutex issues in the iPod Nano 2G NAND driver and FTL. |
| 12:59:11 | linuxstb | TheSeven: What's the state of Rockbox now? Are you still getting freezes? |
| 13:00 |
| 13:00:28 | TheSeven | not when opening tracks |
| 13:00:43 | TheSeven | still need to see if i manage to reproduce these wmcodec i2c freezes |
| 13:01:53 | TheSeven | they are still there |
| 13:03:11 | TheSeven | so there are 2 major issues left: these i2c problems (and fixing that interrupt loss properly) and the clickwheel problems after releasing the hold switch |
| 13:03:18 | linuxstb | Do you think it's worth adding a list of known bugs on the iPodNano2G wiki page? |
| 13:04:29 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 13:05:06 | TheSeven | probably yes |
| 13:05:08 | bertrik | I don't understand the while (...) wakeup_wait() construct in the i2c driver |
| 13:05:59 | TheSeven | bertrik: that's to poll it occasionally to keep it from blocking if an int gets lost (which happens regularly on nano2g right now for a still unknown reason) |
| 13:07:16 | bertrik | ok, I still don't understand it and it looks suspicious |
| 13:08:05 | TheSeven | i just added a timeout of 10msec to the wakeup wait, and then check if it's done. if not, it'll wait again |
| 13:09:41 | TheSeven | i want to get rid of that in the long term, but if i remove it right now, it just locks up as soon as the first I2C request is issued after starting audio playback |
| 13:12:32 | | Join petur [0] (n=peter@94-225-47-142.access.telenet.be) |
| 13:12:37 | bertrik | I wrote the initial i2c driver, but to be honest I don't remember anymore why the INT_IIC just disables the interrupt instead of clearing it directly ... |
| 13:13:09 | tmzt | bertrik: this is i2c host periph, not bitbang gpios? |
| 13:13:10 | bertrik | TheSeven, you could try to go back to the first revision of the s5l8700 driver, that one was simply polled instead of using interrupts |
| 13:13:19 | bertrik | tmzt, yes |
| 13:13:22 | TheSeven | yes, that one works |
| 13:13:36 | TheSeven | and that's why i did that polling-interrupt-hybrid now |
| 13:14:39 | | Join einhirn [0] (n=Miranda@p5DCC1367.dip0.t-ipconnect.de) |
| 13:14:45 | TheSeven | crap. i just removed it, and it still works |
| 13:15:00 | bertrik | removed what ? |
| 13:15:07 | TheSeven | that while ... wait code |
| 13:15:20 | TheSeven | so this was probably once again some side-effect of a bug we fixed in the meantime |
| 13:15:37 | bertrik | I hope so ... :) |
| 13:16:14 | bertrik | I would really like some more debugging/checks in the kernel sometimes |
| 13:17:13 | bertrik | We could make a 'debug' target with lots of checks (but possibly slower) and a 'release' target without them (basically what we have now) |
| 13:17:26 | TheSeven | bertrik: it already is like that |
| 13:17:58 | bertrik | Maybe during the pre-release freeze we could make debug version binaries available for testing |
| 13:18:14 | TheSeven | KERNEL_ASSERT will only do something if KERNEL_OBJECT_CHECKS is defined, which is usually the case with DEBUG defined and in the sim |
| 13:18:44 | TheSeven | so we should just scatter those all over the place |
| 13:18:45 | * | bertrik should have looked better ... |
| 13:18:48 | | Quit Thundercloud (Remote closed the connection) |
| 13:19:48 | TheSeven | having them check for uninitialized mutex/semaphore/wakeup/queue/whatever structs would be a good idea, i think... |
| 13:20:47 | bertrik | I agree. Maybe "someone" (could be me) should make a patch as a proposal for this. |
| 13:20:56 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 13:20:56 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 13:21:17 | CIA-43 | New commit by funman (r23067): mkamsboot: support Fuze OF v 1.02.28 |
| 13:23:00 | TheSeven | bertrik: bad news. the i2c trouble keeps coming back |
| 13:26:54 | TheSeven | bertrik: clearing the int properly indeed makes rockbox behave very weird |
| 13:27:14 | TheSeven | it seems to just read garbage some of the time |
| 13:30:15 | bertrik | the driver might need a rewrite then... |
| 13:32:34 | | Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) |
| 13:34:04 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 13:39:03 | pixelma | barrywardell: did you read logs a bit this week? |
| 13:39:32 | barrywardell | pixelma: i had a quick look at them earlier today |
| 13:39:50 | barrywardell | pixelma: so you got usb prober working? |
| 13:39:58 | | Quit yosafbridge ("Coyote finally caught me") |
| 13:40:08 | | Join yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
| 13:42:24 | pixelma | yeah. I posted the log too - it only shows tiny difference in the hex numbers under "Raw Descriptor", the fun part was that with USB prober running, the HID functions worked properly but still no drive appearing. Someone pointed towards a known MacOS 10.4 bug with composite devices |
| 13:42:35 | pixelma | log is here: http://rockbox.pastebin.ca/1602298 |
| 13:45:18 | barrywardell | pixelma: did you also try using the logger? |
| 13:45:36 | | Join T44 [0] (n=Topy44@g227163138.adsl.alicedsl.de) |
| 13:45:55 | barrywardell | it would report any errors |
| 13:46:33 | CIA-43 | New commit by dave (r23068): Add crypt_firmware plugin for Nano2G - this uses the hardware crypto unit to encrypt (or decrypt) a firmware image for writing to a Nano 2G's firmware ... |
| 13:47:41 | pixelma | barrywardell: no, didn't know about it and was happy to get the USB prober running at all. My knowledge about MacOS is very very limited |
| 13:47:45 | bertrik | nice |
| 13:48:01 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 13:48:20 | linuxstb | bertrik: Was that for r23068? |
| 13:49:07 | barrywardell | pixelma: the logger is the last tab in usb prober |
| 13:49:40 | barrywardell | it might report some error that would indicate what the problem might be |
| 13:49:46 | pixelma | ok, will try next time |
| 13:50:23 | * | linuxstb now has two tasks left before we have a nice user-friendly install for the Nano2G - finish ipodpatcher support for the Nano2G and write a Rockbox bootloader... |
| 13:52:00 | barrywardell | pixelma: on the plus side, your log on pastebin seems to suggest that the device is enumerating properly, although I don't know the significance of those two bytes being swapped |
| 13:52:02 | | Quit Topy44 (Read error: 60 (Operation timed out)) |
| 13:52:41 | bertrik | linuxstb, yes |
| 13:54:14 | linuxstb | bertrik: Again, mostly TheSeven's work, but yes, it's nice ;) |
| 14:00 |
| 14:02:14 | TheSeven | bertrik: I had a look at i2c again, and not clearing the int in the handler seems to be just the right thing |
| 14:11:00 | | Join Dege [0] (n=bla@151.61.192.140) |
| 14:12:07 | | Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) |
| 14:22:46 | *** | Saving seen data "./dancer.seen" |
| 14:23:40 | | Quit TheSeven (Read error: 104 (Connection reset by peer)) |
| 14:23:58 | | Join The_Seven [0] (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 14:24:10 | | Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 14:27:19 | | Quit TheSeven (Nick collision from services.) |
| 14:27:35 | | Join The_Seven [0] (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 14:27:47 | | Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-159-242.pools.arcor-ip.net) |
| 14:33:48 | | Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) |
| 14:48:30 | | Quit barrywardell () |
| 14:49:18 | | Quit TDJACR (Connection reset by peer) |
| 14:49:18 | | Quit intrados3 (Read error: 110 (Connection timed out)) |
| 14:53:54 | | Join Lynx_ [0] (n=Lynx@xdsl-87-79-161-69.netcologne.de) |
| 14:56:34 | | Join JackWinter4 [0] (n=jack@vodsl-10804.vo.lu) |
| 14:58:05 | | Join ender` [0] (i=krneki@84.255.206.8) |
| 15:00 |
| 15:00:50 | | Join gb_master [0] (i=82c03212@gateway/web/freenode/x-vkclvpbpfqfaznwh) |
| 15:08:40 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 15:11:01 | | Quit JackWinter3 (Read error: 110 (Connection timed out)) |
| 15:19:24 | * | linuxstb looks at apps/debug_menu.c and is horrified! |
| 15:23:09 | CIA-43 | New commit by dave (r23069): Implement __dbg_ports for S5L870X targets (Nano2G and Meizus) |
| 15:24:21 | | Join Strife89 [0] (n=michael@adsl-220-123-13.mcn.bellsouth.net) |
| 15:27:28 | | Quit gb_master ("Page closed") |
| 15:34:35 | | Join efyx [0] (n=efyx@82.225.185.146) |
| 15:59:47 | | Quit Strife89 ("Ah, got a job to do ....") |
| 16:00 |
| 16:01:15 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 16:04:28 | kugel | bertrik: I think I have a working udelay()I |
| 16:15:15 | | Join darkham [0] (n=darkham@host211-179-dynamic.6-87-r.retail.telecomitalia.it) |
| 16:16:18 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:17:17 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 16:20:54 | | Part froggyman |
| 16:21:03 | | Quit stoffel (Read error: 113 (No route to host)) |
| 16:22:50 | *** | Saving seen data "./dancer.seen" |
| 16:27:37 | bubsy | hey mcuelenaere |
| 16:27:49 | bubsy | I opened my Zen Vision:M some days ago, sure has got some powerful chips in there :) |
| 16:31:30 | mcuelenaere | yeah it does |
| 16:32:33 | bubsy | where can I grab the lastest rockbox source again? The "general" one, so I can grab the ZVM source and compile it |
| 16:32:41 | bubsy | can't see any links in the ZVM wiki on rockbox.org |
| 16:32:42 | mcuelenaere | svn.rockbox.org |
| 16:35:28 | | Quit bubsy ("Party time, EXCELLENT! *wring wring wring!!* Party on, Wayne! Party on, Garth!") |
| 16:38:33 | | Join bubsy [0] (n=bubsy@94.139.72.137) |
| 16:39:21 | | Quit darkham ("Sto andando via") |
| 16:43:43 | bubsy | hmm |
| 16:43:45 | linuxstb | bubsy: http://www.rockbox.org/wiki/UsingSVN |
| 16:43:53 | bubsy | yes, I'm there now |
| 16:43:59 | bubsy | svn://svn.rockbox.org/rockbox/trunk rockbox |
| 16:44:03 | bubsy | Tortioise SVN says: |
| 16:44:13 | bubsy | Error URL 'svn://svn.rockbox.org/rockbox/trunk%20rockbox' doesn't exist |
| 16:44:33 | bubsy | nevermind :) |
| 16:44:39 | linuxstb | People very often have problems using Tortoise - I would suggest using the command-line SVN |
| 16:45:35 | | Join Gun_Smoke [0] (n=G@fsf/member/GunSmoke) |
| 16:46:58 | Gun_Smoke | Going shopping today.... Any personal favorites? around 4G, FM, cheaper end? |
| 16:48:48 | | Join sunflash2 [0] (i=sunflash@adsl-157-95-195.clt.bellsouth.net) |
| 16:49:32 | | Join Lynx [0] (n=Lynx@xdsl-87-79-56-85.netcologne.de) |
| 16:50:04 | | Nick Lynx is now known as Guest61553 (n=Lynx@xdsl-87-79-56-85.netcologne.de) |
| 16:50:25 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 16:50:53 | linuxstb | Gun_Smoke: I don't think there are any devices you can buy in a local shop which run Rockbox. |
| 16:51:09 | linuxstb | (see www.rockbox.org for the list of targets) |
| 16:51:15 | sunflash2 | hey guys i just got an mp4 player out of China via ebay one of the nano ripoffs and was wondering if rockbox will work on it im iffy on trying it only cause i dont know how to restore the original firmware |
| 16:51:17 | Gun_Smoke | Yeah I'm looking at that. |
| 16:51:43 | linuxstb | sunflash2: No. All devices are different. This is what is needed to run Rockbox on a new device - http://www.rockbox.org/wiki/NewPort |
| 16:52:00 | Gun_Smoke | Well I'm not opposed to ordering something. While back there was a nice drop on the mailing list of a newegg deal. |
| 16:53:03 | sunflash2 | @linuxstb thanks ill look into getting a spare to play with |
| 16:53:19 | TheSeven | linuxstb: lowering the i2c bus freq seems to help |
| 16:53:48 | TheSeven | (even though I would think that 12kHz is ridiculously low) |
| 16:54:11 | bubsy | mcuelenaere, |
| 16:54:12 | | Quit Lynx_ (Read error: 60 (Operation timed out)) |
| 16:54:13 | | Nick Guest61553 is now known as Lynx_ (n=Lynx@xdsl-87-79-56-85.netcologne.de) |
| 16:54:24 | mcuelenaere | bubsy: ? |
| 16:54:24 | bubsy | I can only find Creative ZEN Vision:M 60 GB Firmware 1.21.02e (For Europe only) |
| 16:54:28 | bubsy | from creative.com |
| 16:54:31 | | Part sunflash2 ("Leaving") |
| 16:54:31 | bubsy | but I have the 30GB one :/ |
| 16:54:51 | mcuelenaere | look for 'Older players' |
| 16:55:11 | bubsy | h |
| 16:55:12 | bubsy | ah |
| 16:55:13 | bubsy | found it :) |
| 16:56:16 | * | mcuelenaere spots new Creative DAPs |
| 16:58:09 | TheSeven | bertrik, linuxstb: 12kHz I2C is rock solid, 24kHz already starts getting flakey. and even 96kHz seems to work for everything except changing volume while music is playing |
| 16:59:13 | * | TheSeven has the suspicion that calling wakeup_wait is taking longer than the actual I2C transfer |
| 16:59:19 | * | bubsy really wants mcuelenaere to continue hack on the ZVM port |
| 16:59:20 | DBUG | Enqueued KICK bubsy |
| 16:59:20 | bubsy | :D |
| 16:59:38 | linuxstb | TheSeven: Any idea what speed the Nano2G OF uses? |
| 16:59:51 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 16:59:51 | * | TheSeven will have a look |
| 17:00 |
| 17:00:20 | * | linuxstb gets frustrated in the maze of USB #defines, trying to add support for "reboot to disk mode" on the Nano2G |
| 17:00:42 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 17:00:50 | | Quit Grahack ("Leaving.") |
| 17:04:12 | TheSeven | linuxstb: reboot to disk mode if usb is connected, or just do it at all? |
| 17:04:54 | linuxstb | Yes, reboot to disk mode if usb is connected. |
| 17:05:13 | TheSeven | well, do you know how to detect if usb is connected? |
| 17:05:45 | linuxstb | Probably not, but there's a GPIO pin that toggles when USB is inserted (but that's probably just charging/power) |
| 17:05:56 | TheSeven | which one is that? |
| 17:06:02 | linuxstb | PCON14 & 0x8 |
| 17:06:16 | linuxstb | (see the new "View I/O ports" debug screen) |
| 17:06:20 | TheSeven | nice to know - i want to have a look at proper charging soon |
| 17:06:45 | TheSeven | rebooting to disk mode is the easier part... write "hotstuffdiskmode\1\0\0\0" to 0x2202BF00 and reset :-) |
| 17:07:55 | linuxstb | Yes, that part is working. For some reason my detect code doesn't seem to be though... |
| 17:18:25 | | Part linuxstb ("Leaving") |
| 17:18:35 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 17:18:57 | linuxstb | TheSeven: Also, headphone detection is PCON14 & 0x20 |
| 17:19:13 | | Quit teru ("Quit") |
| 17:19:53 | TheSeven | looking at the apple firmware tells me that there are 2 i2c controllers, we're writing to the wrong one and it works nevertheless, and there are undocumented bits in the regs |
| 17:20:50 | | Quit Gun_Smoke (Read error: 110 (Connection timed out)) |
| 17:21:30 | * | linuxstb thinks he should use PDAT14, not PCON14... ;) |
| 17:23:35 | | Join intrados3 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 17:26:40 | CIA-43 | New commit by dave (r23070): Nano2G - reboot into disk mode when USB is inserted. |
| 17:27:42 | bertrik | kugel, nice ... |
| 17:27:43 | kugel | amiconn: ping |
| 17:28:30 | linuxstb | bertrik: Is anything holding up the Meizu ports, or is it just a lack of time/motivation ? |
| 17:28:31 | bertrik | TheSeven, must be some kind of timing problem then between the interrupt and the main thread, I can't imagine that the i2c hardware is unable to run at 96 kHz |
| 17:28:33 | kugel | bertrik: it's not very accurate for us < 10 though (timer frequency too low |
| 17:28:35 | kugel | ) |
| 17:29:11 | | Join ChristW [0] (n=chatzill@h247103.upc-h.chello.nl) |
| 17:29:13 | bertrik | linuxstb, I lack the time/motivation to really look into the Meizu/Samsung FTL |
| 17:29:57 | bertrik | kugel, I'm about to change my mind again on how to do the DBOP button read |
| 17:30:13 | bertrik | the fuze is just so cumbersomely designed to use the DBOP port |
| 17:30:34 | ChristW | I'm looking into obtaining the source code, but the Wiki is a bit unhelpful. It doesn't tell me the svn url! |
| 17:30:58 | linuxstb | bertrik: Ah yes, I forgot the FTL... |
| 17:31:12 | bertrik | the fuze needs a high scrollwheel polling rate AND apparently a lot of time to read HOLD button |
| 17:31:20 | CIA-43 | New commit by bluebrother (r23071): Don't put the complete HTML source in the trace when checking for a new version. The recognized filenames is enough. |
| 17:31:32 | bubsy | but bertrik, I know you want to look more into the Creative Zen Vision:M! |
| 17:31:34 | bubsy | we're come far |
| 17:31:41 | bubsy | some things left, is sound and PIC |
| 17:31:48 | bubsy | and something with the filesystem/hdd thingies :/ |
| 17:32:06 | linuxstb | bluebrother: Can I just check, if the Nano2G bootloader is bootloader-ipodnano2g.ipodx, is that going to be problem for rbutil? |
| 17:32:13 | kugel | bertrik: the wheel works perfectly, and no lcd glitches, with the patch I uploaded (the one that has the two tweaks applied). I'm not sure why you're still nagging |
| 17:32:19 | linuxstb | bluebrother: (an extra "x" at the end) |
| 17:33:10 | kugel | udelay(2); works for the hold button, 1 would probably also work but my udelay doesn't do 1us in that case |
| 17:33:35 | kugel | the huge delay is in SVN too, btw |
| 17:34:02 | bertrik | kugel, so you mean it's still an improvement over SVN :) |
| 17:34:07 | kugel | definitely |
| 17:34:10 | bluebrother | linuxstb: won't be a problem at all, the bootloader classes are done to handle this :) |
| 17:37:07 | CIA-43 | New commit by dave (r23072): Nano2G - implement "Pause on headphone unplug" feature |
| 17:39:12 | | Quit Horscht ("Verlassend") |
| 17:39:41 | kugel | TheSeven: I believe a fix for the scrollwheel-after-hold problem for the older ipods was committed a few weeks agop |
| 17:48:03 | linuxstb | kugel: Thanks, but we know that. Problem is we don't know how to re-init the clickwheel (which was the fix on the older ipods). |
| 17:51:27 | | Join midgey [0] (n=tjross@rockbox/developer/midgey) |
| 17:54:18 | * | TheSeven is back |
| 18:00 |
| 18:01:29 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 18:02:29 | TheSeven | 780kHz I2C works, 1.5MHz fails sometimes |
| 18:04:07 | | Join intrados4 [0] (n=intrados@67.149.219.101) |
| 18:04:07 | TheSeven | 1MHz seems to be stable |
| 18:04:57 | | Quit intrados4 (SendQ exceeded) |
| 18:06:03 | TheSeven | linuxstb, bertrik: my suspicion is that wakeup_wait gets interrupted by the I2C int before everything is in place |
| 18:06:21 | | Join intrados4 [0] (n=intrados@d149-67-101-219.col.wideopenwest.com) |
| 18:06:25 | TheSeven | (which points towards polling probably being faster than interrupt-driven I2C |
| 18:06:45 | TheSeven | an I2C request takes less than 1000 CPU clock cycles |
| 18:11:02 | | Quit intrados3 (Read error: 110 (Connection timed out)) |
| 18:11:08 | TheSeven | even though the kernel code looks like it should be able to handle the wakeup coming in before even waiting for it |
| 18:12:14 | bertrik | I have no problem with changing it into a busy-wait, IIRC the Meizu OF does that too, I just tried to improve on it |
| 18:12:40 | TheSeven | the apple OF is doing it really weird. they are polling for the interrupt handler to be called |
| 18:13:07 | bertrik | oh, I think we can certainly do better than *that* :) |
| 18:13:48 | TheSeven | even though i would really like to find out what's causing the trouble we're seeing right now |
| 18:14:12 | TheSeven | btw, your I2C is running at 48kHz, is the OF doing that, too, or are they faster? |
| 18:14:33 | bertrik | TheSeven, regarding max frequency, I think nearly all i2c device can handle 100 kHz and most can handle 400 kHz but I wouldn't go any higher |
| 18:14:49 | TheSeven | i haven't figured out what apple is using, but 1MHz seems to work flawlessly |
| 18:16:23 | bertrik | 48 kHz wasn't my intention, I think I copied what the meizu OF did |
| 18:17:03 | TheSeven | well, I assumed PCLK = 100MHz for that calculation, but I doubt it will be higher than that ;-) |
| 18:18:08 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 18:18:16 | CIA-43 | New commit by dave (r23073): Squash a warning when FTL_READONLY is defined |
| 18:20:16 | kugel | TheSeven: : " they are polling for the interrupt handler to be called" <−− that's not much different from wakeup_wait, isn't it? I think wakeup_wait yields, but that's all |
| 18:20:33 | TheSeven | no, that's real thread blocking |
| 18:20:52 | | Join toffe82 [0] (n=chatzill@adsl-75-12-168-246.dsl.frs2ca.sbcglobal.net) |
| 18:20:55 | TheSeven | and apple doesn't even yield, so it's completely pointless to poll for an int, rather for a HW reg |
| 18:21:44 | TheSeven | kugel: but yes, the kernel of course polls for the thread to get woken up or the timeout to expire when doing task switches ;-) |
| 18:22:53 | *** | Saving seen data "./dancer.seen" |
| 18:25:07 | TheSeven | bertrik: is it ok with you if i commit a polling I2C driver running at 390kHz? |
| 18:25:22 | bertrik | yes |
| 18:25:26 | TheSeven | or should I ifdef the clock speed? |
| 18:26:54 | | Quit froggyman (Read error: 104 (Connection reset by peer)) |
| 18:26:59 | linuxstb | TheSeven: Does this finally make audio playback stable? |
| 18:27:24 | bertrik | I'm not fully sure that all i2c devices do indeed handle 400 kHz (meaning I haven't checked, but I'm fairly confident) |
| 18:28:00 | TheSeven | seems so. i haven't noticed any freezes when talking to the wmcodec at 500kHz, so 390kHz should be safe. |
| 18:28:12 | bertrik | I can add an #ifdef later if it turns out that 400 kHz is too fast for some other device (on the meizu or samsung yp-s3) |
| 18:28:24 | TheSeven | linuxstb: that volume changing bug resolved by this seems to have been the last one |
| 18:28:30 | bertrik | \o/ |
| 18:31:19 | linuxstb | TheSeven: Cool! If I can get a bootloader (I'm working on it now) and ipodpatcher finished, I can't think of anything else to stop us releasing... |
| 18:31:46 | linuxstb | I _think_ the Nano1G manual can be used "as-is"... |
| 18:32:41 | TheSeven | the FTL also seems to be a lot more stable now that I caught that mutex bug |
| 18:32:58 | linuxstb | Well, first step of "releasing" is moving it up to "unstable". |
| 18:33:34 | * | linuxstb wonders if "Usable" is a better definition than "Unstable" |
| 18:34:46 | * | bertrik agrees |
| 18:34:52 | linuxstb | (and moving some of the "stable" ports down a category, such as the earlier ipods (no charging)) |
| 18:35:15 | * | linuxstb would like a "top-tier" category for the very best ports of Rockbox |
| 18:35:18 | TheSeven | ah, yes, charging. another thing i want to have a look at today. |
| 18:36:56 | CIA-43 | New commit by theseven (r23074): Revert the S5L870X I2C driver to busy waiting because of some issues with interrupts, and increase the bus speed from 24kHz to 390kHz. |
| 18:37:13 | * | linuxstb hopes the bootloader works first-time, as the compile, copy to ipod, encrypt using Rockbox, write to device with ipodpatcher, test cycle is a bit slow... |
| 18:37:40 | TheSeven | linuxstb: test it using ibugger |
| 18:38:06 | TheSeven | (and boot that one through iloader) |
| 18:38:18 | linuxstb | But I can't use IRAM then? |
| 18:38:33 | TheSeven | you can, you'll just need to reboot ibugger afterwards to make it work again |
| 18:38:39 | TheSeven | but that's like 10 seconds |
| 18:39:32 | TheSeven | the rockbox crt0.S should kill iBugger on the interrupt side quite early, long before writing to IRAM |
| 18:39:54 | TheSeven | you won't be able to use it for debugging, but it's still nice for uploading |
| 18:41:26 | linuxstb | Yes, that's probably better... |
| 18:44:47 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 18:52:53 | CIA-43 | New commit by bluebrother (r23075): Rework configuration dialog for TTS / Encoder values. ... |
| 18:54:31 | | Part ChristW |
| 18:55:14 | linuxstb | TheSeven: I guess we should commit that stack increase. My crypt_firmware plugin also needs it, as well as Rockboy and pictureflow |
| 18:55:33 | TheSeven | OK, I'll go for it |
| 18:55:51 | TheSeven | I'll do that for S5L870X as the other ones have even more IRAM |
| 18:56:11 | linuxstb | I'm not sure about that - perhaps use SECTOR_SIZE |
| 18:56:28 | TheSeven | the issue doesn't seem to depend only on the sector size |
| 18:57:03 | TheSeven | the pictureflow stack was way too full to work with 8KB stack even at 512 |
| 18:57:58 | linuxstb | It works fine on other targets with a 8KB stack though. |
| 18:58:27 | linuxstb | Maybe its simply the NAND/FTL code is using a lot of stack in general? |
| 18:58:36 | linuxstb | (or something else target-specific) |
| 18:58:39 | CIA-43 | New commit by theseven (r23076): Fix panic caused by r23074 |
| 19:00 |
| 19:01:05 | TheSeven | anyways, I expect that to happen on the other S5L870Xs, too, and we have more than enough IRAM. We may try to lower that later, though. |
| 19:01:20 | TheSeven | Any idea how to find out what's actually causing it? |
| 19:06:14 | TheSeven | linuxstb: I would estimate your plugin at ~5KB of stack usage |
| 19:06:28 | TheSeven | (supposed the FAT driver takes about half of that) |
| 19:06:42 | TheSeven | oh, wait, there is another sector buffer |
| 19:07:03 | TheSeven | but things should still have worked with 12KB, which they didn't |
| 19:07:20 | | Quit robin0800_ (Remote closed the connection) |
| 19:10:41 | | Quit linuxstb (Read error: 104 (Connection reset by peer)) |
| 19:13:01 | | Quit hd (Read error: 110 (Connection timed out)) |
| 19:13:38 | | Quit bertrik (Read error: 113 (No route to host)) |
| 19:13:56 | | Quit efyx (Read error: 131 (Connection reset by peer)) |
| 19:15:52 | * | TheSeven will add a timeout for I2C requests |
| 19:16:09 | TheSeven | I suppose 20ms is OK? |
| 19:16:14 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 19:18:54 | | Part froggyman |
| 19:19:55 | | Quit linuxstb (Read error: 131 (Connection reset by peer)) |
| 19:21:09 | | Join lifeless__ [0] (n=lifeless@188.18.65.190) |
| 19:21:41 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 19:22:08 | CIA-43 | New commit by theseven (r23077): Add a timeout for I2C transfers (S5L870x) |
| 19:22:29 | TheSeven | linuxstb: is there a way to disable that reboot to disk mode on usb connect feature? |
| 19:22:32 | | Join Hillshum [0] (n=hillshum@75-165-235-2.slkc.qwest.net) |
| 19:22:50 | TheSeven | i somehow don't like it at all |
| 19:23:19 | gevaerts | TheSeven: disable in what way? |
| 19:23:42 | TheSeven | not have it reboot to disk mode when I plug it (e.g. to charge it) |
| 19:24:11 | gevaerts | there should be a button mapped to do that |
| 19:26:14 | linuxstb | Yes, you hold MENU to charge. |
| 19:26:23 | linuxstb | (I haven't tested, but that's how it works on other ipods) |
| 19:26:59 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 19:27:10 | TheSeven | doesn't work |
| 19:29:25 | linuxstb | Hmm, you're right, it doesn't... |
| 19:29:49 | TheSeven | I'm reverting that locally for now, as it blocks me from playing around with charging |
| 19:29:56 | | Quit Hillshum (Read error: 104 (Connection reset by peer)) |
| 19:30:48 | | Quit Dege ("Peace and Protection 4.22.2") |
| 19:31:01 | gevaerts | weird |
| 19:33:23 | linuxstb | TheSeven: You could just change it to return "false" in the USB detect function in usb-s5l8700.c |
| 19:33:31 | gevaerts | linuxstb, TheSeven: I think you need HAVE_USB_POWER |
| 19:34:08 | linuxstb | gevaerts: Ah yes... |
| 19:34:50 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 19:35:05 | CIA-43 | New commit by rob (r23078): Initial support for runtime detection of the PMU used in newer D2+ models (PCF50635). The backlight and battery monitoring should work, but the RTC ... |
| 19:35:14 | | Join adambrower [0] (n=adambrow@173-161-40-166-Illinois.hfc.comcastbusiness.net) |
| 19:35:57 | adambrower | hello |
| 19:36:06 | | Quit lifeless_ (Read error: 110 (Connection timed out)) |
| 19:36:15 | adambrower | anyone one here |
| 19:37:11 | gevaerts | lots of people |
| 19:38:43 | | Quit adambrower (Client Quit) |
| 19:39:32 | | Join Strife89 [0] (n=michael@adsl-220-123-13.mcn.bellsouth.net) |
| 19:39:45 | | Nick Kohlrabi is now known as kohl^fi (n=Kohlrabi@frustrum.nosebud.de) |
| 19:42:38 | CIA-43 | New commit by rob (r23079): D2: Don't read touchscreen co-ordinates when hold is enabled. |
| 19:42:44 | | Join r00s [0] (n=ru@zentrale.profitables.biz) |
| 19:48:10 | | Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) |
| 19:48:20 | | Join Hillshum [0] (n=hillshum@75-165-235-2.slkc.qwest.net) |
| 20:00 |
| 20:13:13 | TheSeven | linuxstb: how did you find that GPIO? |
| 20:13:27 | TheSeven | just look at the values while plugging? |
| 20:14:21 | | Nick Llorean1 is now known as Llorean (n=DarkkOne@adsl-99-4-146-40.dsl.hstntx.sbcglobal.net) |
| 20:14:24 | linuxstb | TheSeven: Yes. |
| 20:15:28 | linuxstb | TheSeven: If it's like earlier ipods, then that pin will probably actually indicate "charging" or "charger attached". To distinguish between USB power only and a USB data connection you need to talk to the USB controller. |
| 20:16:53 | saratoga | is anything known about the USB controller? |
| 20:17:11 | TheSeven | yes, of course, but I'm actually dealing with the charger right now, and I'm wondering if there are some interesting pins beneath |
| 20:17:31 | TheSeven | saratoga: it's the same one as used on the S5L8900 iphone soc |
| 20:18:34 | linuxstb | saratoga: TheSeven's "ibugger" tool communicates over USB. So he already has working code for it... |
| 20:19:23 | saratoga | I'm really amazed at the speed of the nano2g port |
| 20:20:03 | TheSeven | saratoga: once we got that bootrom dump, the hardest part was done |
| 20:20:25 | linuxstb | And fortunately the encryption wasn't secure... |
| 20:20:33 | saratoga | funny that "porting rockbox" wasn't the hard part |
| 20:20:38 | saratoga | usually it is |
| 20:20:50 | TheSeven | the hardest part definitely was breaking into it the first time |
| 20:20:59 | linuxstb | Well, that took about 3 years! |
| 20:21:23 | saratoga | what about the Ipod 6G/Classic? |
| 20:21:27 | TheSeven | using a buffer overflow exploit on an almost unknown system... and if we hadn't found that (crippled) JTAG, we would still be trying around |
| 20:21:54 | TheSeven | saratoga: we can execute code on that one, but nobody has bothered actually writing code for it yet |
| 20:22:09 | saratoga | is the same true of the nano3g? |
| 20:22:12 | linuxstb | TheSeven: Only the 1st gen Classic though (there are 3 generations now). |
| 20:22:20 | * | linuxstb has the 2nd gen Classic (120GB) |
| 20:22:26 | TheSeven | the nano3g is still resisting... |
| 20:22:56 | *** | Saving seen data "./dancer.seen" |
| 20:23:06 | * | TheSeven suspects they may have used the same GID key on 1st/2nd gen classic |
| 20:23:13 | TheSeven | and even if not, it should be bruteforcable |
| 20:23:27 | * | TheSeven has no idea what's going wrong with our 3g attack |
| 20:25:17 | liar|netbook | TheSeven: how many nano3g nanotrons are currently bruteforcing? |
| 20:26:18 | linuxstb | saratoga: A lot of code came for free from other ports though. The Meizu work helped get it started, including most of the work for the audio driver. apps/ code didn't need adapting as it's the same button layout and LCD size/depth as the 1st gen Nano. The button driver is merged with the PP ipod clickwheel driver, so the wheel acceleration etc came for free. |
| 20:26:45 | linuxstb | It's the same audio codec as the 1st gen nano as well. |
| 20:30:15 | TheSeven | liar|netbook: one, but it's not finding anything, even though we almost completely scanned it for 2 firmware revisions |
| 20:30:56 | liar|netbook | TheSeven: so its maybe just not working proplery |
| 20:31:29 | TheSeven | the results seem sane though |
| 20:36:04 | liar|netbook | hm |
| 20:37:33 | liar|netbook | maybe i can borrow a nanotron from a classmate, just to see if it gives different results |
| 20:37:41 | liar|netbook | a nano3g* |
| 20:37:50 | liar|netbook | and build a nanotron i meant |
| 20:38:31 | * | TheSeven will do GPIO bruteforcing now |
| 20:43:31 | TheSeven | no reaction from the charger :-( |
| 20:46:25 | | Quit intrados4 (Read error: 60 (Operation timed out)) |
| 20:47:14 | | Join intrados4 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 20:51:57 | | Quit evilnick (Read error: 113 (No route to host)) |
| 20:56:53 | | Quit Rob2222 (Read error: 54 (Connection reset by peer)) |
| 20:57:37 | | Join Rob2222 [0] (n=Miranda@p4FDCD8BE.dip.t-dialin.net) |
| 21:00 |
| 21:00:53 | * | pixelma wonders about the timestamp on the red line of the build table |
| 21:03:10 | | Join Dege [0] (i=Dege@151.61.192.140) |
| 21:03:23 | linuxstb | TheSeven: I don't know if this will give you any clues, but it's the task related to charging on older ipods - http://www.rockbox.org/tracker/task/8802 |
| 21:06:25 | | Quit Strife89 ("If you hold a Linux shell to your ear, you can hear the C.") |
| 21:07:43 | TheSeven | linuxstb: yep, I'm searching for the corresponding GPIO |
| 21:11:07 | | Quit intrados4 (Read error: 110 (Connection timed out)) |
| 21:16:30 | | Quit bluebrother (Nick collision from services.) |
| 21:16:33 | | Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) |
| 21:19:08 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 21:24:30 | * | TheSeven found that gpio ports 3 and B have an influence on battery current |
| 21:24:50 | TheSeven | zeroing port 3 increases drain a lot, zeroing port B decreases it a little |
| 21:26:25 | liar|netbook | linuxstb: "Pause on headphone unplug" does not work for me |
| 21:26:39 | linuxstb | liar|netbook: Have you enabled it? It's a setting (and off by default). |
| 21:27:03 | liar|netbook | linuxstb: oh did not knew that |
| 21:27:14 | * | linuxstb hands liar|netbook a copy of the Rockbox manual ;) |
| 21:30:34 | liar|netbook | ok it works, but its a bit out of sync |
| 21:30:43 | * | liar|netbook is going to read the rockbox manual |
| 21:31:40 | linuxstb | What do you mean "out of sync" ? Out of sync with what? |
| 21:32:52 | liar|netbook | its takes 1 second to pause |
| 21:34:00 | | Join AquaFox [0] (n=474afcd1@giant.haxx.se) |
| 21:34:52 | linuxstb | I guess that's just how it works - I've never used it before. I don't know if that's by design or not though. |
| 21:35:00 | | Quit shai ("Leaving") |
| 21:35:21 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 21:35:34 | | Join Strife89 [0] (n=michael@adsl-220-123-13.mcn.bellsouth.net) |
| 21:36:26 | liar|netbook | and in audio playback the counters work strange too(the right one counts down ~0.5secs after the left one counts up) |
| 21:36:45 | AquaFox | is there any idea if rockbox could work on a Creative Nomad Jukebox? (i have one) this is the player that runs on 4AA batteries and looks like a personal CD player and has a standard notebook harddrive in it |
| 21:37:25 | liar|netbook | but thats just a "cosmeticbug" |
| 21:42:38 | | Join nosa- [0] (n=k@adsl-235-42-106.clt.bellsouth.net) |
| 21:43:26 | | Nick nosa- is now known as nosa-j (n=k@adsl-235-42-106.clt.bellsouth.net) |
| 21:43:59 | linuxstb | AquaFox: It _could_ work on most things. No-one has done any of the work needed for that device though. See here - http://www.rockbox.org/wiki/NewPort |
| 21:46:16 | | Part Grahack |
| 21:47:08 | | Part froggyman |
| 21:47:16 | | Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) |
| 21:47:24 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 21:48:54 | | Join zu_ [0] (n=zu@bucketheaded.eu) |
| 21:49:18 | | Join avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
| 21:52:15 | | Join CIA-85 [0] (n=CIA@208.69.182.149) |
| 21:58:19 | | Quit nosa-j (Read error: 104 (Connection reset by peer)) |
| 21:58:32 | | Join nosa-j [0] (n=k@adsl-235-42-106.clt.bellsouth.net) |
| 21:59:32 | | Quit zu (Connection timed out) |
| 21:59:54 | | Quit JackWinter4 (Connection timed out) |
| 21:59:56 | | Quit avacore (Read error: 110 (Connection timed out)) |
| 22:00 |
| 22:01:10 | | Join moonscapex [0] (n=moonscap@d173-183-151-230.abhsia.telus.net) |
| 22:01:22 | | Quit CIA-43 (Read error: 110 (Connection timed out)) |
| 22:02:23 | moonscapex | has the problem with album art overlapping images been fixed yet? |
| 22:03:44 | | Quit moonscapex (Client Quit) |
| 22:12:49 | linuxstb | TheSeven: Can I now remove the "I2C driver is unreliable, causing freezes" known bug from the IPodNano2GPort wiki page? |
| 22:13:59 | TheSeven | yes, even though I'm not happy with the solution |
| 22:14:11 | TheSeven | I2C just sometimes fails, but this is handled more gracefully now |
| 22:14:49 | TheSeven | btw, PCON3 |= 0x80000000 causes a heavily increased current draw |
| 22:19:43 | TheSeven | YEAH |
| 22:20:03 | TheSeven | PCONB |= 0x01000000 |
| 22:20:23 | TheSeven | ...and battery current fires up like a rocket :-P |
| 22:22:18 | linuxstb | \o/ |
| 22:23:00 | *** | Saving seen data "./dancer.seen" |
| 22:23:20 | TheSeven | (just wrote some small python tool that connects to ibugger, tinkers with GPIOs, and monitors the battery voltage and current) |
| 22:33:54 | | Quit merbanan (Read error: 110 (Connection timed out)) |
| 22:37:00 | TheSeven | ok, what next? the clickwheel? |
| 22:37:39 | linuxstb | I guess so. Or figure out why the stack usage is so high... |
| 22:37:51 | * | linuxstb can't see why his bootloader isn't working... |
| 22:38:25 | TheSeven | how does it fail? |
| 22:41:01 | linuxstb | Just freezes on the Apple logo. I've now re-installed the Apple firmware and am using iBuggerLoader... |
| 22:41:19 | TheSeven | i would suggest the iloader-ibugger way, it's faster |
| 22:41:29 | TheSeven | did the bootloader run in ibugger? |
| 22:42:02 | TheSeven | control.py upload 08000000 bootloader.bin && control.py execute 08000000 0a000000 |
| 22:42:05 | linuxstb | I'm just using ibuggerloader to upload the code to 0x08000000 and then executing it. That seems as fast as it could be. |
| 22:42:15 | linuxstb | Yes, that's exactly what I'm running. |
| 22:42:32 | TheSeven | i mean booting ibugger loader through the apple firmware is really slow |
| 22:42:50 | TheSeven | and you'll need to start up ibugger core before uploading |
| 22:43:05 | TheSeven | else some usb buffers will trash uploaded data |
| 22:43:34 | linuxstb | Ah yes, I remember now... So how can I use ibugger with iloader? |
| 22:43:34 | | Join nosa- [0] (n=k@74.235.42.106) |
| 22:44:07 | TheSeven | if you want to do it the quick way, just dd one of my iloader images to the ipod, this already contains ibugger loader |
| 22:44:23 | TheSeven | then just boot it using the menu button and run the following |
| 22:44:28 | TheSeven | control.py startup; control.py upload 08000000 bootloader.bin && control.py execute 08000000 0a000000 |
| 22:47:04 | linuxstb | Is there an alternative? e.g. loading ibugger from /iloader/ ? |
| 22:47:38 | TheSeven | yes, you can install iloader in whatever way and feed ibugger as /iloader/ibugger.bin or a "ibgr" firmware partition image |
| 22:47:52 | TheSeven | (the latter is how it's done in my image) |
| 22:48:50 | linuxstb | Where/what is ibugger.bin ? I can't see it in your archive. Is it just core.bin ? |
| 22:49:15 | TheSeven | no, it's loader.bin |
| 22:51:34 | linuxstb | Thanks, I'll try that. Just to check, my bootloader gets loaded to 0x08000000 and then remaps IRAM to 0x0 and relocates itself there. Should that work fine? |
| 22:52:03 | TheSeven | yes, at least if interrupts are disabled during that, which they should be |
| 22:52:29 | linuxstb | I'm guessing they are when the NOR bootloader loads my bootloader. But with ibugger? |
| 22:53:04 | TheSeven | with ibugger, only the USB int will be active, but you'll need to shut that one down, too (but I think crt0.S is doing this early enough) |
| 22:54:07 | TheSeven | with ibugger, only the USB int will be active, but you'll need to shut that one down, too (but I think crt0.S is doing this early enough) |
| 22:54:14 | TheSeven | oops |
| 22:54:33 | linuxstb | OK, this is weird. When I run those three commands, I see the iBugger loader, then I'm taken back to iloader... |
| 22:54:41 | linuxstb | s/iBugger loader/iBugger logo/ |
| 22:55:15 | TheSeven | that's really weird. |
| 22:55:30 | TheSeven | without an apple logo in between? |
| 22:55:58 | TheSeven | then you somehow didn't upload your bootloader, and ibugger didn't corrupt iloader enough to stop it from booting :-P |
| 22:56:56 | linuxstb | Yes, it seems running the commands in one command-line is too fast for it. Running them manually, and my bootloader just crashes (i.e. it stays on the iBugger logo) |
| 22:57:19 | linuxstb | (it displayed a "No iBugger found" error which I missed...) |
| 22:57:48 | TheSeven | funny, this should work |
| 22:58:27 | TheSeven | i suggest changing libibugger.py line 268 and using the run command |
| 22:59:43 | linuxstb | Yes, that's better. |
| 23:00 |
| 23:00:02 | TheSeven | and does things even faster, but without all those reconnects in between |
| 23:00:46 | linuxstb | Sorry, no it's not better... |
| 23:01:29 | TheSeven | run has always worked for me |
| 23:01:51 | linuxstb | Doing it immediately after startup isn't working. If I wait a short time, it's fine. |
| 23:01:56 | TheSeven | does it still just boot to iloader or spit out some error message? |
| 23:02:13 | TheSeven | startup is supposed to wait 2 seconds for the ipod to reconnect |
| 23:02:19 | | Quit nosa-j (Connection timed out) |
| 23:02:30 | TheSeven | you may possibly need to increase that, but it always worked for me (on windows) |
| 23:02:31 | linuxstb | control.py gives an error - no iBugger device found |
| 23:03:03 | linuxstb | Yes, I'm on Linux. I'll increase that wait. |
| 23:03:05 | TheSeven | then increase line 260 |
| 23:03:36 | linuxstb | Ah, you meant "run" without using startup? |
| 23:03:46 | | Join evilnick [0] (n=evilnick@ool-4571af51.dyn.optonline.net) |
| 23:04:05 | TheSeven | yes |
| 23:04:15 | TheSeven | run will do it all magically |
| 23:04:26 | linuxstb | Then yes, that's fine. |
| 23:07:42 | amiconn | Really strange build line... |
| 23:10:06 | | Join ifonefox [0] (n=458e6209@giant.haxx.se) |
| 23:11:25 | linuxstb | amiconn: Hmm, the non-existent builds? |
| 23:11:53 | TheSeven | heh, that was my commit! :-P |
| 23:12:01 | | Quit ifonefox (Client Quit) |
| 23:12:40 | amiconn | Yes, including the timestamp |
| 23:14:08 | | Quit DaCapn (Read error: 113 (No route to host)) |
| 23:14:15 | | Join DaCapn [0] (i=dacapn@using.your.wireless-inter.net) |
| 23:21:33 | TheSeven | what about finally adding nano2g to the build system? |
| 23:21:34 | TheSeven | are these builds only done for checking, or can one download them somewhere? |
| 23:21:38 | | Join ShapeShifter499 [0] (n=chatzill@adsl-69-105-84-31.dsl.scrm01.pacbell.net) |
| 23:21:56 | linuxstb | TheSeven: Yes, they're all downloadable. |
| 23:22:07 | TheSeven | then that could be the solution to that problem |
| 23:22:23 | linuxstb | I'm not really sure what the criteria are for adding builds there. Apart from compiling without any warnings (which it doesn't at the moment) |
| 23:22:37 | TheSeven | btw, i just spotted a shutdown freeze (caught by the 20sec timeout) :-/ |
| 23:22:49 | TheSeven | fixing those yellows shouldn't be too hard |
| 23:22:57 | linuxstb | But the Gigabeat S is there, and that's in the same category as the Nano2G - "Unusable" ;) |
| 23:23:26 | TheSeven | I'll have a look at that core_sleep one |
| 23:23:36 | linuxstb | So yes, I would say that once we fix the warnings, it could be added. |
| 23:23:59 | linuxstb | Anyone know the mechanics of adding new builds? gevaerts ? |
| 23:24:11 | gevaerts | add them to the builds file :) |
| 23:24:32 | linuxstb | Does that then need to be installed somewhere by someone? |
| 23:24:45 | linuxstb | s/someone/some Swede/ |
| 23:24:47 | gevaerts | no |
| 23:25:38 | * | linuxstb stares blankly at the builds file... |
| 23:25:55 | * | gevaerts can do that bit |
| 23:26:30 | | Quit Lss (Read error: 110 (Connection timed out)) |
| 23:26:58 | * | bluebroth3r wonders who on earth "The Rockbox Crew" on cnet is |
| 23:27:05 | linuxstb | gevaerts: OK ;) What's the "−−type" parameter? |
| 23:28:43 | gevaerts | linuxstb: that's the build type, i.e. n for normal, b for bootloader, s for sim, c for checkwps |
| 23:28:54 | linuxstb | I guessed that, but the number? |
| 23:29:23 | gevaerts | that's another column :). It's the score |
| 23:29:55 | linuxstb | How difficult the build is? |
| 23:30:13 | gevaerts | yes |
| 23:30:33 | linuxstb | OK. It's a bit clever that build system... |
| 23:31:04 | ShapeShifter499 | which audio format takes up less space that can be read by rockbox? |
| 23:31:38 | TheSeven | ShapeShifter499: mainly depends on what your quality assumptions are :-) |
| 23:32:15 | gevaerts | for the nano2g normal build, score is 22606 |
| 23:32:46 | ShapeShifter499 | quality would be so-so, as long there are no horrid clicking or static in the music |
| 23:33:01 | linuxstb | ShapeShifter499: If you want a low bitrate codec, HE-AAC could be worth testing - the Nano2G's CPU might handle it. |
| 23:33:29 | ShapeShifter499 | no I want more music in less space |
| 23:33:48 | linuxstb | Don't you mean more music in the same space? |
| 23:33:54 | ShapeShifter499 | yea |
| 23:35:06 | gevaerts | TheSeven, linuxstb: the nano2g bootloader doesn't seem to compile |
| 23:35:13 | linuxstb | gevaerts: No, it doesn't exist yet... |
| 23:35:23 | gevaerts | ah, ok |
| 23:35:26 | linuxstb | (we're using "iloader" - TheSeven's own bootloader) |
| 23:35:33 | * | gevaerts thinks that those people are doing things backwards :) |
| 23:35:35 | * | linuxstb is working on a Rockbox bootloader ATM |
| 23:36:17 | TheSeven | is there any place in rockbox where you may need current measurements? |
| 23:36:24 | ShapeShifter499 | linuxstb: an how is the rockbox loader coming? |
| 23:36:28 | TheSeven | i haven't found such a thing in the powermgmt apis |
| 23:36:29 | | Join ifonefox [0] (n=ifonefox@c-69-142-98-9.hsd1.nj.comcast.net) |
| 23:36:58 | linuxstb | ShapeShifter499: Doesn't work... I'm currently trying to debug it. |
| 23:37:07 | linuxstb | (but it doesn't get as far as being debuggable...) |
| 23:37:14 | ShapeShifter499 | linuxstb: oh |
| 23:37:28 | | Quit JackWinter (Read error: 60 (Operation timed out)) |
| 23:37:54 | TheSeven | linuxstb: what did you do to it? it has worked before, hasn't it? (at least as far as entering main) |
| 23:39:01 | | Join JackWinter [0] (n=jack@vodsl-10804.vo.lu) |
| 23:39:03 | linuxstb | I guess the relocation to IRAM and remapping IRAM to 0x0 is new. |
| 23:39:20 | linuxstb | But I haven't tried running it for a long time. |
| 23:39:27 | | Quit ifonefox (Client Quit) |
| 23:39:59 | | Join ifonefox [0] (n=ifonefox@c-69-142-98-9.hsd1.nj.comcast.net) |
| 23:40:16 | | Quit ifonefox (Client Quit) |
| 23:40:56 | * | ShapeShifter499 is away playing with his hacked wii |
| 23:41:12 | | Join efyx [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 23:41:23 | TheSeven | linuxstb: wow the beast battery debug screen is nice :-) |
| 23:41:41 | linuxstb | I don't think I've seen it. Torne has my beast... |
| 23:41:58 | TheSeven | i just saw the source - awesome! |
| 23:42:14 | TheSeven | monitoring things like regulator heat dissipation, different temperatures, etc. :-) |
| 23:42:54 | linuxstb | Yes, jhMikeS (who did most of the Beast port) is thorough... Sadly he hasn't been around recently. |
| 23:43:48 | | Join intrados4 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 23:44:08 | | Join HellDragon [0] (n=jd@vpn.exhort.ca) |
| 23:51:28 | ShapeShifter499 | what is the beast port? |
| 23:51:37 | TheSeven | gigabeat s |
| 23:52:00 | midgey | pixelma: around? |
| 23:52:54 | gevaerts | TheSeven, linuxstb: when do you plan to fix the warnings? Before or after adding it to the build system? |
| 23:53:09 | | Join stoffel [0] (n=quassel@p57B4DFCB.dip.t-dialin.net) |
| 23:53:33 | linuxstb | gevaerts: I think we should fix before. |
| 23:54:10 | * | TheSeven wonders why nano2g battery runtime is higher when playing music than when idle |
| 23:54:34 | TheSeven | it should be around ~15 hours right now |
| 23:55:14 | linuxstb | How are you measuring runtime? |
| 23:55:28 | TheSeven | i'm just believing what the PMU tells me |
| 23:55:41 | TheSeven | we're at 27mA when playing music (backlight off) |
| 23:56:19 | AquaFox | idle time should be similar to a cell phone, which most models can run for a week or two in idle |
| 23:57:19 | TheSeven | core_sleep only makes 3mA difference |
| 23:57:27 | TheSeven | i suspect most of the current draw is outside the SOC |
| 23:57:46 | Hillshum | But DAPs get turned off when idle |
| 23:57:55 | linuxstb | Useful that it can be measured though. IIUC, other targets require linking up a meter to the device. |
| 23:58:02 | AquaFox | moms phone plays mp3s and stuff and it lasts about 12 days between charges with the occasional call lasting about a minute |
icon identifies that the person is a core developer (has commit access).