00:07:27 | | Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) |
00:14:50 | | Join AciD` [0] (~AciD@longchamp44-1-82-67-133-87.fbx.proxad.net) |
00:14:50 | | Quit AciD` (Remote closed the connection) |
00:17:18 | | Join gromit` [0] (~gromit@ALagny-151-2-8-144.w82-121.abo.wanadoo.fr) |
00:19:51 | | Quit gromit` (Client Quit) |
00:22:33 | | Quit ripnetUK () |
00:30:18 | | Quit _aLF ("Leaving") |
00:53:37 | *** | Saving seen data "./dancer.seen" |
01:00 |
01:14:20 | | Quit Sebulba02 ("Bite me.") |
01:15:43 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
01:17:41 | | Join Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) |
01:31:42 | | Join iRiverMan [0] (~accbf484@labb.contactor.se) |
02:00 |
02:27:06 | | Quit iRiverMan ("CGI:IRC (EOF)") |
02:50:27 | | Quit midk (Read error: 238 (Connection timed out)) |
02:53:39 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:00:23 | amiconn | Woohoo! DMA transfer from MMC works! |
03:00:36 | amiconn | Bedtime |
03:00:51 | | Quit amiconn (" Zing") |
03:27:00 | | Quit mecraw (Read error: 104 (Connection reset by peer)) |
04:00 |
04:53:40 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:23:41 | | Quit MooMaunder (Read error: 110 (Connection timed out)) |
06:00 |
06:42:48 | | Join LinusN [0] (~linus@labb.contactor.se) |
06:53:42 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:38:57 | | Join ashridah [0] (ashridah@220-253-121-12.VIC.netspace.net.au) |
08:00 |
08:29:49 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8407.dip.t-dialin.net) |
08:30:47 | | Join amiconn [0] (~jens@pD9E7FC12.dip.t-dialin.net) |
08:32:00 | [IDC]Dragon | oh, Jens is up already |
08:32:10 | amiconn | Good morning |
08:32:10 | [IDC]Dragon | tell me about your DMA! |
08:33:13 | amiconn | DMA read is working (not yet with end interrupt, but polled), and swapping between sector transfers. Speed increase agains current cvs version ~40% |
08:33:38 | [IDC]Dragon | nice |
08:33:57 | amiconn | Last night I learned *a lot* about the SH1 SCI |
08:34:06 | [IDC]Dragon | again? |
08:34:30 | amiconn | There are many details that aren't mentioned in the datasheet |
08:34:38 | LinusN | tell, tell! |
08:35:13 | [IDC]Dragon | like a hidden MSB first flag? |
08:37:14 | amiconn | Unfortunately not :( |
08:41:45 | amiconn | E.g.: I now know why we have to enable both tx and rx for receiving: With sync mode and internal clock, the SCI generates 2 byte transfers. The 1st fills the data register, and the second gets received into the receive shift register. If at this moment the data register is not yet emptied, an overrun error occurs and the second byte is lost. |
08:42:06 | amiconn | (this is with rx only enabled) |
08:43:04 | amiconn | However, with both tx and rx enabled, the SCI stops clock after receiving the first byte, since then the transmission ends. This way no overrun and no lost byte occur |
08:43:33 | amiconn | There is more... later |
08:45:27 | [IDC]Dragon | ok (I'm unable to follow this right now) |
08:46:49 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
08:47:34 | | Join Zagor [242] (~bjst@labb.contactor.se) |
08:49:26 | LinusN | amiconn: wiki, wiki, wiki!!! |
08:53:44 | *** | No seen item changed, no save performed. |
09:00 |
09:24:30 | Zagor | amiconn: so how fast is mmc transfer now? |
09:35:34 | | Join plok [0] (s336156@student.uq.edu.au) |
09:37:58 | [IDC]Dragon | bbl |
09:38:02 | | Quit [IDC]Dragon () |
09:41:04 | * | plok is away - Automatically set away. - messages will be saved. |
09:55:46 | amiconn | Zagor: Reading is now ~270 kByte/s, writing ~330 kByte/s. However, this is not yet in cvs, and I plan to implement swapping in the background before doing so. This may push reading by another 10..20 % |
09:56:03 | Zagor | writing is faster? why? |
09:58:43 | | Join amiconn_ [0] (~jens@pD9E7FAB9.dip.t-dialin.net) |
10:00 |
10:01:05 | | Join wizzzard [0] (~merlin@dsl-082-082-234-136.arcor-ip.net) |
10:03:45 | | Quit amiconn (Nick collision from services.) |
10:03:45 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7FAB9.dip.t-dialin.net) |
10:06:36 | amiconn | Zagor: Writing is faster because bitswap is done in the background, while transferring byte-wise (still). Reading now uses dma (as reported), but bitswap is done between sector transfers, as I already mentioned |
10:06:41 | | Join pillo [0] (~trillian@navlab03.dei.unipd.it) |
10:06:52 | Zagor | ok |
10:18:39 | | Quit plok ("I'm outta here!") |
10:26:15 | Bagder | Zagor: did you spot why the ondios didn't build fine this morning? |
10:26:31 | Bagder | I noticed they were configed with 8mb ram, but that doesn't explain it |
10:30:32 | Zagor | i saw it, but haven't had time to look at it yet. i'll dig it up for you. |
10:31:43 | amiconn | Zagor: Any news concerning the play button issue with entering sub-browsers? |
10:31:46 | Zagor | #1 is bad group (not rockbox) on the ondio destination dirs |
10:32:28 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
10:32:36 | [IDC]Dragon | hi again |
10:32:36 | Zagor | amiconn: no fix yet. i've been a bit preoccupied lately |
10:33:05 | Bagder | Zagor: fixed group now |
10:33:28 | Zagor | Bagder: there's another issue too, might be related. i'm bouncing the cron output to you. |
10:33:39 | Bagder | ok |
10:35:55 | [IDC]Dragon | Bagder: I've been a good boy, did may homework assignment, updated http://www.rockbox.org/docs/devicechart.html |
10:36:05 | [IDC]Dragon | s/may/my |
10:36:23 | Zagor | nice |
10:36:32 | Bagder | good boy! ;-) |
10:39:21 | Bagder | Zagor: run that script manually and I bet we'll figure out if there's a quirk left |
10:40:18 | Zagor | ok |
10:41:01 | Bagder | and I'll add a iriver sim target to the cvs build table |
10:41:23 | LinusN | sed error fixed in tools/configure |
10:41:43 | LinusN | sed puked on the comma character in GCCOPTS |
10:41:51 | Bagder | ah |
10:42:16 | LinusN | but the log parser put a nice "OK" in the build log :-) |
10:42:26 | * | LinusN points at Bagder |
10:42:32 | Bagder | hehe |
10:42:38 | * | Bagder whistles |
10:45:15 | LinusN | dah, the SDRAM refresh counter is based on the bus clock |
10:45:41 | LinusN | and that depends on the CPU frequency, which we will change dynamically |
10:45:59 | LinusN | so we need to change the PLL *and* the refresh counter |
10:53:44 | LinusN | ah, my second binutils patch was just approved :-) |
10:53:48 | *** | Saving seen data "./dancer.seen" |
10:53:59 | Bagder | profit! |
10:54:07 | Bagder | ;-) |
10:54:11 | Bagder | at least happiness |
10:54:37 | amiconn | [IDC]Dragon: ReallyNicePicture™ of Ondio SP is on it's way |
10:54:44 | LinusN | yeah, it feels good to finally be able to contribute |
10:55:29 | Bagder | ok, the build log says "failed" for the h100 case |
10:55:37 | Bagder | but the table builder ignores it |
10:55:39 | * | LinusN wonders how fast we can clock the coldfire before the wiggler chokes |
10:55:48 | Bagder | and when I try to respect the 'failed' case |
10:56:05 | Bagder | ,,, I noticed that serveral other builds are falsely claimed Failed |
10:56:30 | Bagder | so, let's have that h100 cell green for a while ;-) |
10:56:53 | LinusN | i wonder why my last commit didn't trigger a build |
10:57:46 | Bagder | it will |
10:57:52 | Bagder | in... 3 minutes |
10:58:04 | LinusN | ah, i missed the 11:40 build by a minute |
10:58:08 | LinusN | 10:40 |
11:00 |
11:00:08 | Zagor | Bagder: I still get the "unary operator expected" error |
11:00:42 | Bagder | odd |
11:00:57 | Bagder | you understand from which script? |
11:01:20 | LinusN | sounds like it comes from the installer build |
11:01:42 | Zagor | yes |
11:01:45 | Bagder | yes, it sounds bash |
11:01:54 | Zagor | installer/src/build-installer |
11:04:33 | Bagder | I believe it is related to the RELEASE file warning and the RELEASE comparison in that script |
11:05:06 | [IDC]Dragon | amiconn: so you've scanned it now? |
11:06:03 | Bagder | iriver sim column appeared |
11:06:11 | LinusN | now what? the bleeding edge build still fails |
11:06:20 | LinusN | /bin/sh: -c: line 1: syntax error near unexpected token `;' |
11:06:42 | LinusN | (iriver) |
11:06:50 | Bagder | probably because there are no files at all in the list |
11:07:30 | Bagder | "for each in ;" |
11:07:41 | LinusN | works for me |
11:08:17 | amiconn | [IDC]Dragon: Yes, scanned now, currently polishing |
11:08:38 | Bagder | LinusN: probably because you have a different bash version that allows that thing |
11:10:02 | LinusN | ok |
11:10:13 | Bagder | I'm testing a fix right now |
11:16:23 | Bagder | wasn't that easy |
11:16:52 | [IDC]Dragon | we have an Ondio daily build, congratulations! |
11:17:22 | Bagder | mucho congratulations! |
11:18:01 | [IDC]Dragon | (thanks to all involved swedish script kiddies ;-) |
11:18:11 | * | Bagder grins |
11:18:35 | LinusN | Bagder: don't worry about the fix |
11:18:44 | Bagder | I have a fix now |
11:18:50 | LinusN | me too :-) |
11:19:04 | Bagder | how did you fix it? |
11:19:17 | LinusN | by adding main.c to SOURCES |
11:19:24 | Bagder | ok, then my fix is better |
11:19:29 | Bagder | since I address the problem in make.inc |
11:19:48 | LinusN | then let's add both fixes |
11:19:53 | Bagder | sounds fine |
11:20:34 | Bagder | committed |
11:21:00 | LinusN | nice |
11:22:23 | Bagder | now don't add a source file named "x" ;-) |
11:22:36 | Zagor | bah, I was just about to do that! |
11:24:13 | LinusN | Bagder: lame, but nice |
11:24:45 | Bagder | that's what shell scripting is all about |
11:26:18 | LinusN | lunch time |
11:26:19 | Zagor | lucnh |
11:26:29 | LinusN | lcuhn |
11:26:40 | LinusN | schnul |
11:28:50 | Bagder | schnul? wow |
11:29:56 | [IDC]Dragon | amiconn: have you seen the forum posting of Mark Bright? |
11:30:40 | [IDC]Dragon | he's got an interesting box, a new mask value, different firmware version |
11:30:42 | amiconn | [IDC]Dragon: Yes. Something I expected: An Ondio FMR with mask 0x0708 - tuner bit == 0 |
11:31:01 | [IDC]Dragon | I'd love to have a look inside |
11:31:35 | amiconn | Unfortunately it seems that this will not be possible |
11:31:43 | [IDC]Dragon | but that'll be asked for to much - it's his daughters's birthday present |
11:32:14 | [IDC]Dragon | maybe his daughter will join us in a month's time then |
11:39:31 | | Join MooMaunder [0] (~me@194.152.87.150) |
12:00 |
12:22:42 | | Join iRiverMan [0] (~acbeed3a@labb.contactor.se) |
12:22:50 | iRiverMan | hiyuaaaaaaaaaaaaaaa |
12:33:24 | iRiverMan | when iriver rockbox comes out, will it be possible to record from the radio? |
12:34:02 | | Part wizzzard ("Kopete 0.9.0 : http://kopete.kde.org") |
12:36:21 | | Part pillo |
12:42:21 | | Quit iRiverMan ("CGI:IRC (EOF)") |
12:53:51 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:07:33 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
13:07:45 | oxygen77 | hello |
13:07:59 | oxygen77 | I have some questions on rockbox plugin system |
13:09:04 | [IDC]Dragon | shoot |
13:09:26 | oxygen77 | I think I have done something similar for linav |
13:09:46 | oxygen77 | and I'm currently trying to do a simulator for my gui |
13:09:57 | oxygen77 | can you launch plugins from uiSimulator? |
13:10:06 | [IDC]Dragon | yes |
13:10:20 | | Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) |
13:10:31 | oxygen77 | k |
13:10:38 | oxygen77 | what do you use for this? |
13:10:53 | [IDC]Dragon | to debug them on a PC |
13:11:14 | [IDC]Dragon | for Win32, the plugins become DLLs |
13:11:25 | [IDC]Dragon | for Linux, I don't know |
13:11:35 | oxygen77 | k |
13:11:50 | oxygen77 | in fact I might have found, you are making calls to dlopn |
13:11:53 | oxygen77 | *dlopen |
13:12:00 | oxygen77 | will search on the net for that |
13:12:02 | oxygen77 | thx |
13:14:58 | ripnetUK | surely the plugins on windows will just be propritory binary data like on Archos? |
13:15:43 | [IDC]Dragon | no, they are DLLs on Windows, like I said |
13:16:45 | | Join wizzzard [0] (~merlin@dsl-082-082-234-136.arcor-ip.net) |
13:18:16 | [IDC]Dragon | amiconn: does your new MMC read code yield() already= |
13:18:24 | [IDC]Dragon | ? |
13:18:35 | | Part oxygen77 ("Cho") |
13:18:42 | Zagor | ripnetUK: archos has no simulator, nor plugins |
13:18:58 | Zagor | ignore me, i forgot my head at lunch... |
13:19:34 | | Join webguest75 [0] (~d96ee3e8@labb.contactor.se) |
13:28:01 | | Quit ripnetUK () |
13:28:44 | | Join methangas [0] (methangas@0x50a476ab.virnxx10.adsl-dhcp.tele.dk) |
13:37:57 | | Quit webguest75 ("CGI:IRC (EOF)") |
13:40:32 | amiconn | [IDC]Dragon: No, it doesn't, that's one reason why I did not yet commit it |
13:40:47 | amiconn | Btw: Look at the device chart now :) |
13:43:07 | LinusN | amiconn: "the picture shows an ondio FM"??? |
13:43:58 | LinusN | CPU frequency: 12MHz, interesting |
13:44:18 | amiconn | LinusN: I just fixed the footnote, but it seems that this takes a while to travel to the web server |
13:44:34 | LinusN | "Charge via USB: Power" |
13:44:37 | LinusN | what does that mean? |
13:44:44 | Zagor | yeah it only updates from cvs every 20 minutes |
13:45:21 | amiconn | That means the device is powered from USB, but of course this is no charging, as the Ondio uses no-rechargeable batteries |
13:46:02 | amiconn | Btw: I did not write the table (that was [IDC]Dragon), I merely added my Ondio SP pics |
13:46:40 | amiconn | LinusN:i The 12 MHz is because they use the same clock for CPU and USB bridge. |
13:47:50 | amiconn | Argh, I got the small pic size wrong. It should be 60x82, not 62x80 :( |
14:00 |
14:32:26 | [IDC]Dragon | I am wondering if we really should yield in the driver |
14:32:56 | [IDC]Dragon | or rather, do smaller transfers |
14:33:29 | [IDC]Dragon | depending on the transfer speed |
14:33:38 | [IDC]Dragon | LinusN, amiconn? |
14:33:44 | Zagor | why? |
14:34:01 | [IDC]Dragon | the ata driver also doesn't yield |
14:34:08 | Zagor | yes it does |
14:34:23 | [IDC]Dragon | oh, then ignore me |
14:36:07 | LinusN | we always do :-) |
14:37:12 | [IDC]Dragon | thanks |
14:38:20 | [IDC]Dragon | it yields in wait_for_ready/busy |
14:39:16 | amiconn | LinusN, Zagor: Whats the exact difference in using yield() versus sleep_thread() (that's what the i2c driver does)? |
14:39:24 | [IDC]Dragon | so that's done once per sector? |
14:39:53 | [IDC]Dragon | you should only sleep if an interrupt wakes it up |
14:40:24 | [IDC]Dragon | not useful for polling a non-interrupt activity |
14:41:01 | [IDC]Dragon | yield() surely returns control to you, once the other threads are done |
14:41:14 | [IDC]Dragon | did I explain that correct? |
14:42:01 | | Join webguest02 [0] (~53dea058@labb.contactor.se) |
14:44:57 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
14:45:04 | [IDC]Dragon | (they ignore me, as announced) |
14:45:35 | | Join R3nTiL [0] (~zorroz@220-250-30-217.kgts.ru) |
14:47:28 | LinusN | :-) |
14:47:51 | amiconn | [IDC]Dragon: The ata driver yields in wait for ready/busy. That's usually not for every sector, but for each max_multiple block of sectors |
14:48:04 | amiconn | Hope this is correct |
14:51:36 | Zagor | LinusN: please explain. I too don't get the difference of sleep_thread vs yield. why for example does mpeg_init_playback() use sleep_thread instead of yield? it's not getting any interrupts. |
14:51:38 | | Quit midk ("just STOP it arspy") |
14:52:30 | LinusN | i think calling sleep_thread() is wrong in both cases |
14:52:47 | LinusN | and yield() and sleep_thread() are not the same thing |
14:53:01 | [IDC]Dragon | at least the next tick will wake us up |
14:53:09 | LinusN | sleep_thread() might sleep, but yield() doesn't |
14:53:21 | [IDC]Dragon | thus painting over such oversights |
14:53:22 | LinusN | [IDC]Dragon: correct |
14:53:47 | LinusN | in fact, sleep_thread() isn't meant to be called directly by the application |
14:53:53 | *** | Saving seen data "./dancer.seen" |
14:54:22 | LinusN | it is (almost) equivalent of sleep(0) |
14:54:34 | [IDC]Dragon | yes, should be only for drivers which want to suspent until their interrupt |
14:55:05 | Zagor | does the tick always clear num_sleepers? |
14:55:11 | [IDC]Dragon | does a masked interrupt wake up the core? |
14:56:01 | Zagor | it does, found it |
14:56:25 | LinusN | the difference between sleep(0) and sleep_thread() is that sleep(0) only wakes up the thread on a tick interrupt, while sleep_thread() wakes up on any interrupt |
14:57:13 | LinusN | wrong |
14:57:43 | | Quit R3nTiL () |
14:59:47 | LinusN | sleep(0) doesn't wake you up until the next tick, while sleep_thread() might very well return immediately |
15:00 |
15:01:08 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:03:28 | LinusN | so sleep_thread() is a yield() with the extra "bonus" that it might sleep if all other threads are sleeping |
15:11:01 | amiconn | LinusN: I wonder about sleep_thread() vs. wake_up_thread(). sleep_thread() increases num_sleepers by 1, while wake_up_thread() directly sets it to 0? |
15:11:21 | LinusN | yes, that's correct |
15:15:03 | Zagor | the names confuse the reader |
15:15:52 | [IDC]Dragon | so it sould rather be wake_up_threads() ? |
15:15:52 | LinusN | num_sleepers? |
15:16:12 | LinusN | yes, as it wakes up all threads |
15:31:46 | amiconn | [IDC]Dragon: As I'm going to implement DMA both for reading and writing, I wonder if it's worth to implement background bitswap for writing. This would require 2 sector buffers, while swapping between sectors does only require 1 sector buffer. |
15:43:44 | [IDC]Dragon | how do you mean "between"? |
15:44:11 | [IDC]Dragon | and why do you need DMA on write? To gain time for yield()ing? |
15:44:47 | amiconn | Between = copy sector to buffer, swap, write it to mmc, copy sector to buffer... |
15:45:14 | amiconn | DMA on write could yield while the DMA is running |
15:46:13 | [IDC]Dragon | the copy swap would add to the transfer time, right? |
15:46:16 | dwihno | speaking of nothing ... move.l is a motorola 68k instruction? |
15:46:27 | amiconn | dwihno: yes |
15:46:28 | Bagder | yes |
15:46:37 | dwihno | ah |
15:46:45 | * | dwihno sucks when it comes to assembly |
15:46:47 | amiconn | [IDC]Dragon: yes |
15:46:48 | LinusN | coldfire, that is |
15:47:12 | amiconn | LinusN: of course, but it's also pure 68k |
15:47:18 | LinusN | yup |
15:47:20 | * | Bagder runs away |
15:49:48 | LinusN | amiconn: well, the coldfire has lots of restrictions compared to the 68k |
15:50:01 | LinusN | but you know that |
15:50:27 | amiconn | [IDC]Dragon: I'd expect that background-swap is ~30 % faster than in-between for writing, however, as I said, this would require 2 sector buffers, 515 bytes each |
15:50:47 | amiconn | The buffers should be preferably located in IRAM, for better swap & copy speed |
15:51:20 | amiconn | LinusN: yes. In turn there are some instructions not found in plain 68k CPUs (emac) |
15:51:28 | LinusN | yup |
15:51:37 | LinusN | i really miss the DBNE instruction :-) |
15:52:45 | amiconn | 68k is sloow compared to sh1 when comparing cycles per instruction. |
15:53:04 | amiconn | I dunno if this is also the case with coldfire |
15:56:40 | [IDC]Dragon | DBNE is very CISC, they reduced the complexity for RISC (dunno if it really qualifies, or should) |
15:58:38 | LinusN | gotta go |
15:58:40 | | Part LinusN |
15:59:31 | | Part Zagor |
15:59:47 | | Part wizzzard ("Kopete 0.9.0 : http://kopete.kde.org") |
16:00 |
16:01:03 | [IDC]Dragon | amiconn: or you copy and swap into an IRAM sector buffer, fire it off, yield, then copy swap the next sector into the *same* buffer, in a loops that makes sure it doesn't overtake the DMA read pointer |
16:01:30 | [IDC]Dragon | similar to yesterday's idea |
16:09:16 | [IDC]Dragon | single sectors probably need no DMA and no yield, not worth the startup delay |
16:11:07 | amiconn | I don't know if the write behind dma check would pay off. It may well be that this causes copy & swap in very small chunks |
16:12:17 | [IDC]Dragon | it's a busy loop, yes, so what? |
16:12:28 | amiconn | [IDC]Dragon: Another area: Could you do the same what you did with the CONFIG_HWCODEC for the batteries (CONFIG_BATTERIES)? I think we'd need this, with the values NIMH, LIION and ALKALINE |
16:12:47 | [IDC]Dragon | yes, I had that on the list already |
16:13:28 | amiconn | Ah ok. I'm asking because the blinking battery symbol annoys me, and the charging code should be ditched |
16:14:19 | amiconn | I did already look for the alkaline discharge curves. R03 alkalines have a capacity of ~1000 mAh |
16:15:04 | [IDC]Dragon | isn't charging out already? (at least tosome extent, by not defining HAVE_BATTERIES? |
16:15:51 | amiconn | Hmm, the it may be. Did not look closely |
16:15:54 | amiconn | yet |
16:17:21 | [IDC]Dragon | it removes only the charging screen, not the power thread |
16:19:02 | | Join Lurkski [0] (~Miranda@24.30.163.142) |
16:23:04 | midk | question.. can anyone here modify bmp2rb to read a 1bit bmp file but instead of outputting in rockbox format have it output an array of 1's and 0's according to which pixels are on? |
16:23:51 | amiconn | [IDC]Dragon: Of course. The power thread is still needed iirc |
16:25:30 | [IDC]Dragon | some remains of it, yes |
16:25:57 | [IDC]Dragon | but I won't give top priority to clean this out |
16:29:28 | amiconn | Again different topic: Imho we should introduce 2 new SYS_ events, for MMC inserted and MMC extracted |
16:31:59 | [IDC]Dragon | sigh, yes, I don't like them, but it's probably the only way |
16:32:50 | [IDC]Dragon | if this is interesting to muttiple threads |
16:33:23 | [IDC]Dragon | but better discuss that with LinusN and Zagor |
16:34:25 | [IDC]Dragon | yesterday the MMC handling annoyed me, because the config is gone when I insert a new MMC |
16:34:26 | amiconn | I don't see what is wrong with the SYS_ events... |
16:35:08 | [IDC]Dragon | ...because there might be so many places to check for this, at least if it's like USB |
16:35:21 | amiconn | [IDC]Dragon: This needs the unified file tree handling for internal & external |
16:35:37 | amiconn | (config etc) |
16:35:56 | [IDC]Dragon | or for a start, saving loading config data always from the internal |
16:38:16 | | Quit AciD (Remote closed the connection) |
16:38:32 | amiconn | I think we have to tackle the mmc handling soon, at least partial. Currently there are many situations where rockbox will panic if an mmc is inserted/extracted |
16:40:03 | [IDC]Dragon | amiconn: still interested in MMC field data? |
16:40:07 | [IDC]Dragon | I got 2 here |
16:40:35 | amiconn | Could be interesting. |
16:40:53 | [IDC]Dragon | anything particular? |
16:43:35 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
16:47:03 | amiconn | [IDC]Dragon: Particularly interesting things: Card whose max possible speed is < 20 MBit/s, Tsac and Nsac values, R2W factor |
16:48:02 | [IDC]Dragon | no, all the same on card #1 |
16:48:56 | amiconn | If you change the external card, you have to reboot rockbox to make it read the new values. |
16:49:13 | amiconn | Changing this behaviour requires the metioned SYS_ events |
16:49:26 | [IDC]Dragon | I left the 2nd card at home... |
16:49:27 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
16:50:26 | amiconn | [IDC]Dragon: What external card did you test? It has values identical to the internal? |
16:51:39 | [IDC]Dragon | for the timing and power, yes |
16:51:56 | [IDC]Dragon | it is a cheapish-looking 32 MB card |
16:53:46 | amiconn | Iat lest it looks like the CSD is properly programmed. The CSD content of my 256 MB Transcend card is incomplete, causing some parameters to have weird values. However, this doesn't break the driver |
16:53:55 | *** | Saving seen data "./dancer.seen" |
16:54:06 | amiconn | s/Iat lest/At least/ |
17:00 |
17:18:18 | [IDC]Dragon | c u later |
17:18:24 | | Quit [IDC]Dragon ("CGI:IRC") |
17:25:27 | | Quit webguest02 ("CGI:IRC (Ping timeout)") |
17:29:47 | | Quit MooMaunder (Read error: 104 (Connection reset by peer)) |
17:37:51 | | Quit ashridah ("sleep") |
17:38:48 | | Quit Lurkski (Read error: 110 (Connection timed out)) |
17:45:17 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
17:58:36 | | Join [1]marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
17:58:36 | | Quit marc77 (Read error: 104 (Connection reset by peer)) |
17:58:37 | | Nick [1]marc77 is now known as marc77 (~marc@pub212004076150.hfc.datazug.ch) |
18:00 |
18:01:19 | | Part marc77 |
18:01:21 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
18:01:22 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
18:01:48 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
18:01:51 | | Quit midk (Nick collision from services.) |
18:01:53 | | Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) |
18:09:22 | | Join [1]marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
18:09:23 | | Quit marc77 (Read error: 232 (Connection reset by peer)) |
18:09:25 | | Nick [1]marc77 is now known as marc77 (~marc@pub212004076150.hfc.datazug.ch) |
18:34:25 | | Join [1]marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
18:34:25 | | Quit marc77 (Read error: 104 (Connection reset by peer)) |
18:34:29 | | Nick [1]marc77 is now known as marc77 (~marc@pub212004076150.hfc.datazug.ch) |
18:36:51 | | Quit marc77 (Client Quit) |
18:53:59 | *** | Saving seen data "./dancer.seen" |
18:54:36 | | Quit midk (Remote closed the connection) |
18:57:52 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
19:00 |
19:17:26 | | Quit AciD (Read error: 232 (Connection reset by peer)) |
19:17:33 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
19:38:31 | | Join klaxon [0] (~klaxon@66.88.20.185) |
19:41:06 | klaxon | the hd on my jbr15 is dying. i reformatted it, and i copied a lot of data to it. |
19:41:24 | klaxon | but i cannot copy the rockbox firmware to it. |
19:41:40 | klaxon | i copied a bunch of small files - jpgs |
19:42:08 | klaxon | no matter what, i cannot copy that ajbrec.bin (or what that file is) to it. to any directory |
19:42:22 | klaxon | weird. |
19:42:44 | klaxon | i'm so lost using the stock firmware! :-) |
19:45:09 | klaxon | is there a linux tool to do something like a low level format and bad block remap? |
19:50:20 | amiconn | klaxon: All modern hard drives do bad block remapping internally, and low-level formatting is impossible by os tools. However, most hd manufacturers have tools to check and repair their own harddrive models. |
19:51:07 | klaxon | amiconn: yep i know. i was thinking of at the fs level. anyways the drive is dying and will need to be replaced |
19:52:02 | klaxon | but the weird thing is, i _cannot_ get that firmware file on it. |
19:52:06 | amiconn | It's strange that you can copy other files to it, but not ajbrec.ajz |
19:52:23 | amiconn | What happens if you try it? |
19:53:03 | klaxon | i've been using win2k. it copies okay but then some time later, it says error writing file. |
19:54:55 | amiconn | Hmm. I can't really imagine what may cause this |
19:55:28 | klaxon | yeah, wacky. i copied a lot of similar size jpgs. then i renamed abjrec.jpg - still didn't work! |
19:56:10 | klaxon | to be fair, some other files fail, but after formatting, i was able to put about 10gb of mp3s back on it. |
19:56:40 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8407.dip.t-dialin.net) |
19:56:51 | amiconn | hi again Jörg |
19:56:55 | [IDC]Dragon | amiconn: u there? |
19:57:37 | klaxon | i'll mess with it in linux - if i can copy a jpg to it, then i could cat abjrec.ajz >pic.jpeg && mv pic.jpg abjrec.ajz |
19:57:38 | [IDC]Dragon | I have prepared the battery type, feel free to fill in a discharge curve and the critical levels. |
19:58:40 | amiconn | [IDC]Dragon: In the meantime I added dma writing (copy & swap between sectors). My estimation was correct - the performance penalty against hidden swapping is ~30 % |
19:59:04 | [IDC]Dragon | and I checked the SP flash image on my FM, hangs as expected in both firmwares, but starts both |
19:59:16 | [IDC]Dragon | so flash the damn thing! |
19:59:17 | amiconn | yield() ing *once* while the dma is running produces *no* additional performance penalty |
19:59:29 | [IDC]Dragon | once per what? |
19:59:45 | amiconn | Once per sector |
19:59:55 | [IDC]Dragon | excellent! |
20:00 |
20:00:00 | [IDC]Dragon | Tagesschau time! |
20:00:03 | [IDC]Dragon | (away) |
20:00:24 | amiconn | One reason why I did not flash yet is because it eases development - flashed rockbox doesn't load ajbrec.ajz from disk |
20:01:20 | amiconn | klaxon: Try to get a new hd. I'd never trust fishy hds |
20:03:00 | klaxon | amiconn: yes, i agree. i'm thinking of the hd in my wife's laptop. now i'm convinced she needs to upgrade from that PII |
20:03:01 | amiconn | klaxon: There might be another reason for such a strange behaviour on Windows. It may be caused by a virus |
20:04:19 | amiconn | Finally, your recorder might have developed hw problem, so before ditching that hd, try to connect it to the pc by other means and check it again |
20:05:42 | klaxon | amiconn: good idea. i am pretty sure the hd i dying, it makes the sound of heads re-seeking. |
20:06:21 | amiconn | This might still be caused by a hw problem of the recorder, e.g. flakey power to the hd |
20:06:32 | klaxon | and i forgot it was in my saddle bag when i rode home. probably spun up while bouncing around under my saddle (bicycle) |
20:07:20 | klaxon | that is a good suggestion, before installing a new hd. i had not thought of that, thanks. |
20:07:32 | _aLF | perhaps out of topic : did you try to read SMART information ? |
20:08:06 | klaxon | _aLF: no, i suspose i need an ibm tool for that? |
20:08:52 | _aLF | www.hdtune.com |
20:08:53 | amiconn | _aLF: Afaik reading SMART info needs the special manufacturer tool, which is usually dos based, so this requires connecting the hd to the ide port |
20:09:22 | _aLF | hdtune work under windows, smartctl works under linux |
20:09:44 | amiconn | _aLF: Ok, thanks. I didn't know these tools |
20:10:10 | _aLF | when my harddisk started to crash, I seen a lot of errors with smartctl |
20:10:13 | klaxon | _aLF: great! thanks! |
20:10:34 | _aLF | (and I quickly made a backup ...) |
20:11:25 | _aLF | note: smartctl under linux says "pre-failed" on some variables. HDTune says that all is ok |
20:12:06 | _aLF | so if you can try a knoppix (or another linux installation) and smartctl |
20:13:46 | klaxon | i'll try both. |
20:14:52 | klaxon | about the poor power to the hd, it often powers off if it is playing and i plug it into a stereo. (archos hardware not the greatest) |
20:17:28 | klaxon | which is the dilema: i love the rockbox, but the archos hardware is weak. do i replace the harddrive, of find another? dilema. |
20:20:20 | | Quit AciD` (Read error: 110 (Connection timed out)) |
20:31:49 | | Join gromit` [0] (~gromit@ALagny-151-2-8-144.w82-121.abo.wanadoo.fr) |
20:40:42 | | Quit gromit` ("Client exiting") |
20:45:40 | | Join gromit` [0] (~gromit@ALagny-151-2-8-144.w82-121.abo.wanadoo.fr) |
20:47:34 | | Quit gromit` (Client Quit) |
20:49:17 | | Quit [IDC]Dragon (Read error: 238 (Connection timed out)) |
20:50:46 | | Join gromit` [0] (~gromit@ALagny-151-2-8-144.w82-121.abo.wanadoo.fr) |
20:54:02 | *** | Saving seen data "./dancer.seen" |
21:00 |
21:33:15 | amiconn | Bagder: Could you please replace the Ondio SP image on the daily build page with the correct one? I digged myself, but the dailymod.pl version in CVS doesn't seem to be current... |
22:00 |
22:03:06 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
22:15:18 | | Join wake [0] (~wake@jeremywakeman.ott.istop.com) |
22:16:23 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8236.dip.t-dialin.net) |
22:16:34 | amiconn | hi again... |
22:16:54 | amiconn | DMA read with background bitswap works! |
22:16:57 | [IDC]Dragon | mirc didn't tell me I got disconnected |
22:17:10 | [IDC]Dragon | whow, nice! |
22:17:25 | amiconn | I use HydraIRC, and have it set to auto-reconnect when I get disconnected |
22:17:28 | [IDC]Dragon | what's is the concept now? |
22:18:17 | amiconn | Start reading one sector with DMA, and while DMA is running, swap previous sector, yield, then poll for end of DMA |
22:19:02 | amiconn | Read speed is increased by ~70 % against CVS version, and the box stays responsive, thanks to the yield |
22:19:09 | [IDC]Dragon | :-) |
22:19:27 | amiconn | Reading 1 MB now takes almost exactly 3 seconds |
22:19:33 | [IDC]Dragon | you read into DRAM or IRAM? |
22:19:53 | amiconn | I read directly to DRAM, and swap in place with the existing bitswap |
22:20:23 | amiconn | Curently converting the writing, with 2 sector buffers |
22:21:16 | | Quit scott666_ (Read error: 238 (Connection timed out)) |
22:21:23 | [IDC]Dragon | yeah, with the relatively slow transfer, memory performance doesn't matter that much |
22:21:48 | [IDC]Dragon | sector buffers where? |
22:22:10 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
22:22:24 | amiconn | I'll try both IRAM and DRAM. I suspect IRAM won't increase the performance significantly |
22:22:51 | [IDC]Dragon | maybe not even the code location |
22:22:53 | amiconn | (but take 1032 bytes of IRAM) |
22:23:34 | amiconn | Of course writing single sectors won't use DMA, but the old swap-poll-write routine, due to it's lower latency |
22:23:50 | [IDC]Dragon | good |
22:24:11 | [IDC]Dragon | and it doesn't need to yield |
22:24:24 | amiconn | Nope, and it can't either |
22:24:43 | [IDC]Dragon | how about reading singles? |
22:25:38 | amiconn | This would be slower, since the swap-poll-reading is not back-to-back (and can't be, due to the SCI peculiarities) |
22:26:10 | [IDC]Dragon | fat+dir handling does a lot of these |
22:26:51 | [IDC]Dragon | you still don't like sector DMA+run swapping behind? |
22:27:09 | amiconn | Single sector reading now uses dma too. Of course this adds a bit of latency (first dma, then swap), but it's still faster |
22:27:35 | [IDC]Dragon | aha |
22:28:56 | amiconn | I doubt that the run-behind will gain much, but I can try anyway later |
22:30:18 | amiconn | For single sector transfers, a significant part of the total time needed is the access time of the card. |
22:31:47 | [IDC]Dragon | not nice |
22:32:50 | [IDC]Dragon | do you know how access time, transfer and swap are in relation? |
22:33:59 | amiconn | For almost all cards (those that run with >= 3 MBit/s), the full 3 MBit/s are usable for SCI. Then transfer time is a constant, ~1.3 ms |
22:34:53 | amiconn | swap takes ~20 % of that (for reading, for writing it is copy + swap and takes ~30% of that) |
22:36:16 | | Quit wake ("remounting new /home") |
22:37:30 | amiconn | Access times may vary a great deal across cards and conditions, reaching from almost zero to the possible maximum of 80 ms for reading, and 2.56 s (yes!) for writing, depending on the card |
22:37:33 | | Join wake [0] (~wake@jeremywakeman.ott.istop.com) |
22:38:05 | [IDC]Dragon | now _that_ is slow! |
22:38:43 | amiconn | The real-world access times are usually rather short compared to the sector transfer time, at least between the individual sectors of a multi-sector transfer |
22:39:29 | amiconn | The maximum access times are displayed in the debug menu, it's Tsac for reading, and Tsac * R2W for writing |
22:40:04 | [IDC]Dragon | (it's a mystery to me anyway how a solid state memory can be so slow) |
22:41:08 | amiconn | Again, these are worst-case times (but still, the MMC specs says that you should take these *10 for calculating timeout |
22:41:09 | amiconn | ) |
22:42:12 | amiconn | Perhaps the card finds a problem while flashing a sector, and relocates the data internally. Flashing is relatively slow afaik |
22:50:37 | [IDC]Dragon | have you seen the post from Mark? |
22:50:46 | amiconn | yes |
22:50:50 | [IDC]Dragon | his box has a Samsung tuner! |
22:51:18 | amiconn | Ah, there is another posting |
22:53:03 | | Join JoeBorn [0] (~41d6673c@labb.contactor.se) |
22:53:12 | amiconn | Samsung tuner! Somehow I expected this. What else should that tuner bit be good for? |
22:54:04 | *** | Saving seen data "./dancer.seen" |
22:54:16 | amiconn | That means if the button handling for the radio screen is reworked so that it copes with the limited Ondio buttons, he could already use the radio |
22:55:03 | amiconn | If you try to adapt the while-recording screen, recording should work out of the box imho |
22:55:35 | [IDC]Dragon | maybe, yes (to both of your points) |
22:56:45 | [IDC]Dragon | but I'll wait for you new r/w |
22:56:51 | amiconn | The recording hookup is identical to the recorders. I wonder why the mas parallel is connected at all in the Ondio SP. Archos could have saved the 8 bit buffer chip |
22:57:08 | [IDC]Dragon | is playback smooth now? |
22:57:36 | amiconn | Yes, as afr as I tried. Will have to try hight bitrates and/or mp2 |
22:57:47 | amiconn | s/afr/far/ |
23:00 |
23:09:32 | | Quit wake ("leaving") |
23:14:56 | [IDC]Dragon | the paint onmy Ondio's buttons already starts to peel off! |
23:15:10 | [IDC]Dragon | I had it in a pocket today |
23:16:24 | [IDC]Dragon | another topic: it operates down to 2.6V |
23:16:41 | [IDC]Dragon | so it can really suck the batteries flat |
23:17:19 | amiconn | Interesting. We should check the power good signal though, it may be that the MMC does unwanted things if the voltage is out of range |
23:17:53 | [IDC]Dragon | I did, it never comes |
23:18:35 | [IDC]Dragon | right now I have it closed, but should check what the supply voltage does |
23:19:19 | amiconn | Hmm. What is that signal be good for then? The archos hardware design is really a bit strange at some points |
23:19:57 | [IDC]Dragon | I guess they just had the pin left over |
23:31:40 | amiconn | Now there is a bug in my routines... |
23:32:19 | [IDC]Dragon | :-( |
23:33:44 | amiconn | It doesn't hang, or return non-success, but the data seems to be slighty wrong, because rockbox complains about strange things after doing test reading and writing |
23:38:11 | [IDC]Dragon | you have a test that verifies data, right? |
23:38:46 | amiconn | Yes, but that doesn't help much in this case. I'll do this test after I solved the mystery. |
23:44:49 | amiconn | The problem is within the reading... |
23:44:58 | [IDC]Dragon | I now fixed the battery display |
23:45:20 | amiconn | Nice |
23:53:25 | | Join gromit`` [0] (~gromit@ALagny-151-2-4-90.w82-121.abo.wanadoo.fr) |