Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2004-10-08

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:23amiconnWoohoo! DMA transfer from MMC works!
03:00:36amiconnBedtime
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]Dragonoh, Jens is up already
08:32:10amiconnGood morning
08:32:10[IDC]Dragontell me about your DMA!
08:33:13amiconnDMA 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]Dragonnice
08:33:57amiconnLast night I learned *a lot* about the SH1 SCI
08:34:06[IDC]Dragonagain?
08:34:30amiconnThere are many details that aren't mentioned in the datasheet
08:34:38LinusNtell, tell!
08:35:13[IDC]Dragonlike a hidden MSB first flag?
08:37:14amiconnUnfortunately not :(
08:41:45amiconnE.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:06amiconn(this is with rx only enabled)
08:43:04amiconnHowever, 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:33amiconnThere is more... later
08:45:27[IDC]Dragonok (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:26LinusNamiconn: wiki, wiki, wiki!!!
08:53:44***No seen item changed, no save performed.
09:00
09:24:30Zagoramiconn: so how fast is mmc transfer now?
09:35:34 Join plok [0] (s336156@student.uq.edu.au)
09:37:58[IDC]Dragonbbl
09:38:02 Quit [IDC]Dragon ()
09:41:04*plok is away - Automatically set away. - messages will be saved.
09:55:46amiconnZagor: 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:03Zagorwriting 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:36amiconnZagor: 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:52Zagorok
10:18:39 Quit plok ("I'm outta here!")
10:26:15BagderZagor: did you spot why the ondios didn't build fine this morning?
10:26:31BagderI noticed they were configed with 8mb ram, but that doesn't explain it
10:30:32Zagori saw it, but haven't had time to look at it yet. i'll dig it up for you.
10:31:43amiconnZagor: Any news concerning the play button issue with entering sub-browsers?
10:31:46Zagor#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]Dragonhi again
10:32:36Zagoramiconn: no fix yet. i've been a bit preoccupied lately
10:33:05BagderZagor: fixed group now
10:33:28ZagorBagder: there's another issue too, might be related. i'm bouncing the cron output to you.
10:33:39Bagderok
10:35:55[IDC]DragonBagder: I've been a good boy, did may homework assignment, updated http://www.rockbox.org/docs/devicechart.html
10:36:05[IDC]Dragons/may/my
10:36:23Zagornice
10:36:32Bagdergood boy! ;-)
10:39:21BagderZagor: run that script manually and I bet we'll figure out if there's a quirk left
10:40:18Zagorok
10:41:01Bagderand I'll add a iriver sim target to the cvs build table
10:41:23LinusNsed error fixed in tools/configure
10:41:43LinusNsed puked on the comma character in GCCOPTS
10:41:51Bagderah
10:42:16LinusNbut the log parser put a nice "OK" in the build log :-)
10:42:26*LinusN points at Bagder
10:42:32Bagderhehe
10:42:38*Bagder whistles
10:45:15LinusNdah, the SDRAM refresh counter is based on the bus clock
10:45:41LinusNand that depends on the CPU frequency, which we will change dynamically
10:45:59LinusNso we need to change the PLL *and* the refresh counter
10:53:44LinusNah, my second binutils patch was just approved :-)
10:53:48***Saving seen data "./dancer.seen"
10:53:59Bagderprofit!
10:54:07Bagder;-)
10:54:11Bagderat least happiness
10:54:37amiconn[IDC]Dragon: ReallyNicePicture™ of Ondio SP is on it's way
10:54:44LinusNyeah, it feels good to finally be able to contribute
10:55:29Bagderok, the build log says "failed" for the h100 case
10:55:37Bagderbut the table builder ignores it
10:55:39*LinusN wonders how fast we can clock the coldfire before the wiggler chokes
10:55:48Bagderand when I try to respect the 'failed' case
10:56:05Bagder,,, I noticed that serveral other builds are falsely claimed Failed
10:56:30Bagderso, let's have that h100 cell green for a while ;-)
10:56:53LinusNi wonder why my last commit didn't trigger a build
10:57:46Bagderit will
10:57:52Bagderin... 3 minutes
10:58:04LinusNah, i missed the 11:40 build by a minute
10:58:08LinusN10:40
11:00
11:00:08ZagorBagder: I still get the "unary operator expected" error
11:00:42Bagderodd
11:00:57Bagderyou understand from which script?
11:01:20LinusNsounds like it comes from the installer build
11:01:42Zagoryes
11:01:45Bagderyes, it sounds bash
11:01:54Zagorinstaller/src/build-installer
11:04:33BagderI believe it is related to the RELEASE file warning and the RELEASE comparison in that script
11:05:06[IDC]Dragonamiconn: so you've scanned it now?
11:06:03Bagdeririver sim column appeared
11:06:11LinusNnow what? the bleeding edge build still fails
11:06:20LinusN /bin/sh: -c: line 1: syntax error near unexpected token `;'
11:06:42LinusN(iriver)
11:06:50Bagderprobably because there are no files at all in the list
11:07:30Bagder"for each in ;"
11:07:41LinusNworks for me
11:08:17amiconn[IDC]Dragon: Yes, scanned now, currently polishing
11:08:38BagderLinusN: probably because you have a different bash version that allows that thing
11:10:02LinusNok
11:10:13BagderI'm testing a fix right now
11:16:23Bagderwasn't that easy
11:16:52[IDC]Dragonwe have an Ondio daily build, congratulations!
11:17:22Bagdermucho congratulations!
11:18:01[IDC]Dragon(thanks to all involved swedish script kiddies ;-)
11:18:11*Bagder grins
11:18:35LinusNBagder: don't worry about the fix
11:18:44BagderI have a fix now
11:18:50LinusNme too :-)
11:19:04Bagderhow did you fix it?
11:19:17LinusNby adding main.c to SOURCES
11:19:24Bagderok, then my fix is better
11:19:29Bagdersince I address the problem in make.inc
11:19:48LinusNthen let's add both fixes
11:19:53Bagdersounds fine
11:20:34Bagdercommitted
11:21:00LinusNnice
11:22:23Bagdernow don't add a source file named "x" ;-)
11:22:36Zagorbah, I was just about to do that!
11:24:13LinusNBagder: lame, but nice
11:24:45Bagderthat's what shell scripting is all about
11:26:18LinusNlunch time
11:26:19Zagorlucnh
11:26:29LinusNlcuhn
11:26:40LinusNschnul
11:28:50Bagderschnul? wow
11:29:56[IDC]Dragonamiconn: have you seen the forum posting of Mark Bright?
11:30:40[IDC]Dragonhe's got an interesting box, a new mask value, different firmware version
11:30:42amiconn[IDC]Dragon: Yes. Something I expected: An Ondio FMR with mask 0x0708 - tuner bit == 0
11:31:01[IDC]DragonI'd love to have a look inside
11:31:35amiconnUnfortunately it seems that this will not be possible
11:31:43[IDC]Dragonbut that'll be asked for to much - it's his daughters's birthday present
11:32:14[IDC]Dragonmaybe 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:50iRiverManhiyuaaaaaaaaaaaaaaa
12:33:24iRiverManwhen 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:45oxygen77hello
13:07:59oxygen77I have some questions on rockbox plugin system
13:09:04[IDC]Dragonshoot
13:09:26oxygen77I think I have done something similar for linav
13:09:46oxygen77and I'm currently trying to do a simulator for my gui
13:09:57oxygen77can you launch plugins from uiSimulator?
13:10:06[IDC]Dragonyes
13:10:20 Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
13:10:31oxygen77k
13:10:38oxygen77what do you use for this?
13:10:53[IDC]Dragonto debug them on a PC
13:11:14[IDC]Dragonfor Win32, the plugins become DLLs
13:11:25[IDC]Dragonfor Linux, I don't know
13:11:35oxygen77k
13:11:50oxygen77in fact I might have found, you are making calls to dlopn
13:11:53oxygen77*dlopen
13:12:00oxygen77will search on the net for that
13:12:02oxygen77thx
13:14:58ripnetUKsurely the plugins on windows will just be propritory binary data like on Archos?
13:15:43[IDC]Dragonno, 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]Dragonamiconn: does your new MMC read code yield() already=
13:18:24[IDC]Dragon?
13:18:35 Part oxygen77 ("Cho")
13:18:42ZagorripnetUK: archos has no simulator, nor plugins
13:18:58Zagorignore 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:32amiconn[IDC]Dragon: No, it doesn't, that's one reason why I did not yet commit it
13:40:47amiconnBtw: Look at the device chart now :)
13:43:07LinusNamiconn: "the picture shows an ondio FM"???
13:43:58LinusNCPU frequency: 12MHz, interesting
13:44:18amiconnLinusN: I just fixed the footnote, but it seems that this takes a while to travel to the web server
13:44:34LinusN"Charge via USB: Power"
13:44:37LinusNwhat does that mean?
13:44:44Zagoryeah it only updates from cvs every 20 minutes
13:45:21amiconnThat means the device is powered from USB, but of course this is no charging, as the Ondio uses no-rechargeable batteries
13:46:02amiconnBtw: I did not write the table (that was [IDC]Dragon), I merely added my Ondio SP pics
13:46:40amiconnLinusN:i The 12 MHz is because they use the same clock for CPU and USB bridge.
13:47:50amiconnArgh, I got the small pic size wrong. It should be 60x82, not 62x80 :(
14:00
14:32:26[IDC]DragonI am wondering if we really should yield in the driver
14:32:56[IDC]Dragonor rather, do smaller transfers
14:33:29[IDC]Dragondepending on the transfer speed
14:33:38[IDC]DragonLinusN, amiconn?
14:33:44Zagorwhy?
14:34:01[IDC]Dragonthe ata driver also doesn't yield
14:34:08Zagoryes it does
14:34:23[IDC]Dragonoh, then ignore me
14:36:07LinusNwe always do :-)
14:37:12[IDC]Dragonthanks
14:38:20[IDC]Dragonit yields in wait_for_ready/busy
14:39:16amiconnLinusN, Zagor: Whats the exact difference in using yield() versus sleep_thread() (that's what the i2c driver does)?
14:39:24[IDC]Dragonso that's done once per sector?
14:39:53[IDC]Dragonyou should only sleep if an interrupt wakes it up
14:40:24[IDC]Dragonnot useful for polling a non-interrupt activity
14:41:01[IDC]Dragonyield() surely returns control to you, once the other threads are done
14:41:14[IDC]Dragondid 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:28LinusN:-)
14:47:51amiconn[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:04amiconnHope this is correct
14:51:36ZagorLinusN: 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:30LinusNi think calling sleep_thread() is wrong in both cases
14:52:47LinusNand yield() and sleep_thread() are not the same thing
14:53:01[IDC]Dragonat least the next tick will wake us up
14:53:09LinusNsleep_thread() might sleep, but yield() doesn't
14:53:21[IDC]Dragonthus painting over such oversights
14:53:22LinusN[IDC]Dragon: correct
14:53:47LinusNin fact, sleep_thread() isn't meant to be called directly by the application
14:53:53***Saving seen data "./dancer.seen"
14:54:22LinusNit is (almost) equivalent of sleep(0)
14:54:34[IDC]Dragonyes, should be only for drivers which want to suspent until their interrupt
14:55:05Zagordoes the tick always clear num_sleepers?
14:55:11[IDC]Dragondoes a masked interrupt wake up the core?
14:56:01Zagorit does, found it
14:56:25LinusNthe 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:13LinusNwrong
14:57:43 Quit R3nTiL ()
14:59:47LinusNsleep(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:28LinusNso sleep_thread() is a yield() with the extra "bonus" that it might sleep if all other threads are sleeping
15:11:01amiconnLinusN: 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:21LinusNyes, that's correct
15:15:03Zagorthe names confuse the reader
15:15:52[IDC]Dragonso it sould rather be wake_up_threads() ?
15:15:52LinusNnum_sleepers?
15:16:12LinusNyes, as it wakes up all threads
15:31:46amiconn[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]Dragonhow do you mean "between"?
15:44:11[IDC]Dragonand why do you need DMA on write? To gain time for yield()ing?
15:44:47amiconnBetween = copy sector to buffer, swap, write it to mmc, copy sector to buffer...
15:45:14amiconnDMA on write could yield while the DMA is running
15:46:13[IDC]Dragonthe copy swap would add to the transfer time, right?
15:46:16dwihnospeaking of nothing ... move.l is a motorola 68k instruction?
15:46:27amiconndwihno: yes
15:46:28Bagderyes
15:46:37dwihnoah
15:46:45*dwihno sucks when it comes to assembly
15:46:47amiconn[IDC]Dragon: yes
15:46:48LinusNcoldfire, that is
15:47:12amiconnLinusN: of course, but it's also pure 68k
15:47:18LinusNyup
15:47:20*Bagder runs away
15:49:48LinusNamiconn: well, the coldfire has lots of restrictions compared to the 68k
15:50:01LinusNbut you know that
15:50:27amiconn[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:47amiconnThe buffers should be preferably located in IRAM, for better swap & copy speed
15:51:20amiconnLinusN: yes. In turn there are some instructions not found in plain 68k CPUs (emac)
15:51:28LinusNyup
15:51:37LinusNi really miss the DBNE instruction :-)
15:52:45amiconn68k is sloow compared to sh1 when comparing cycles per instruction.
15:53:04amiconnI dunno if this is also the case with coldfire
15:56:40[IDC]DragonDBNE is very CISC, they reduced the complexity for RISC (dunno if it really qualifies, or should)
15:58:38LinusNgotta 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]Dragonamiconn: 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]Dragonsimilar to yesterday's idea
16:09:16[IDC]Dragonsingle sectors probably need no DMA and no yield, not worth the startup delay
16:11:07amiconnI 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]Dragonit's a busy loop, yes, so what?
16:12:28amiconn[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]Dragonyes, I had that on the list already
16:13:28amiconnAh ok. I'm asking because the blinking battery symbol annoys me, and the charging code should be ditched
16:14:19amiconnI did already look for the alkaline discharge curves. R03 alkalines have a capacity of ~1000 mAh
16:15:04[IDC]Dragonisn't charging out already? (at least tosome extent, by not defining HAVE_BATTERIES?
16:15:51amiconnHmm, the it may be. Did not look closely
16:15:54amiconnyet
16:17:21[IDC]Dragonit removes only the charging screen, not the power thread
16:19:02 Join Lurkski [0] (~Miranda@24.30.163.142)
16:23:04midkquestion.. 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:51amiconn[IDC]Dragon: Of course. The power thread is still needed iirc
16:25:30[IDC]Dragonsome remains of it, yes
16:25:57[IDC]Dragonbut I won't give top priority to clean this out
16:29:28amiconnAgain different topic: Imho we should introduce 2 new SYS_ events, for MMC inserted and MMC extracted
16:31:59[IDC]Dragonsigh, yes, I don't like them, but it's probably the only way
16:32:50[IDC]Dragonif this is interesting to muttiple threads
16:33:23[IDC]Dragonbut better discuss that with LinusN and Zagor
16:34:25[IDC]Dragonyesterday the MMC handling annoyed me, because the config is gone when I insert a new MMC
16:34:26amiconnI 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:21amiconn[IDC]Dragon: This needs the unified file tree handling for internal & external
16:35:37amiconn(config etc)
16:35:56[IDC]Dragonor for a start, saving loading config data always from the internal
16:38:16 Quit AciD (Remote closed the connection)
16:38:32amiconnI 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]Dragonamiconn: still interested in MMC field data?
16:40:07[IDC]DragonI got 2 here
16:40:35amiconnCould be interesting.
16:40:53[IDC]Dragonanything particular?
16:43:35 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
16:47:03amiconn[IDC]Dragon: Particularly interesting things: Card whose max possible speed is < 20 MBit/s, Tsac and Nsac values, R2W factor
16:48:02[IDC]Dragonno, all the same on card #1
16:48:56amiconnIf you change the external card, you have to reboot rockbox to make it read the new values.
16:49:13amiconnChanging this behaviour requires the metioned SYS_ events
16:49:26[IDC]DragonI left the 2nd card at home...
16:49:27 Join mecraw [0] (~lmarlow@69.2.235.2)
16:50:26amiconn[IDC]Dragon: What external card did you test? It has values identical to the internal?
16:51:39[IDC]Dragonfor the timing and power, yes
16:51:56[IDC]Dragonit is a cheapish-looking 32 MB card
16:53:46amiconnIat 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:06amiconns/Iat lest/At least/
17:00
17:18:18[IDC]Dragonc 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:06klaxonthe hd on my jbr15 is dying. i reformatted it, and i copied a lot of data to it.
19:41:24klaxonbut i cannot copy the rockbox firmware to it.
19:41:40klaxoni copied a bunch of small files - jpgs
19:42:08klaxonno matter what, i cannot copy that ajbrec.bin (or what that file is) to it. to any directory
19:42:22klaxonweird.
19:42:44klaxoni'm so lost using the stock firmware! :-)
19:45:09klaxonis there a linux tool to do something like a low level format and bad block remap?
19:50:20amiconnklaxon: 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:07klaxonamiconn: yep i know. i was thinking of at the fs level. anyways the drive is dying and will need to be replaced
19:52:02klaxonbut the weird thing is, i _cannot_ get that firmware file on it.
19:52:06amiconnIt's strange that you can copy other files to it, but not ajbrec.ajz
19:52:23amiconnWhat happens if you try it?
19:53:03klaxoni've been using win2k. it copies okay but then some time later, it says error writing file.
19:54:55amiconnHmm. I can't really imagine what may cause this
19:55:28klaxonyeah, wacky. i copied a lot of similar size jpgs. then i renamed abjrec.jpg - still didn't work!
19:56:10klaxonto 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:51amiconnhi again Jörg
19:56:55[IDC]Dragonamiconn: u there?
19:57:37klaxoni'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]DragonI have prepared the battery type, feel free to fill in a discharge curve and the critical levels.
19:58:40amiconn[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]Dragonand I checked the SP flash image on my FM, hangs as expected in both firmwares, but starts both
19:59:16[IDC]Dragonso flash the damn thing!
19:59:17amiconnyield() ing *once* while the dma is running produces *no* additional performance penalty
19:59:29[IDC]Dragononce per what?
19:59:45amiconnOnce per sector
19:59:55[IDC]Dragonexcellent!
20:00
20:00:00[IDC]DragonTagesschau time!
20:00:03[IDC]Dragon(away)
20:00:24amiconnOne reason why I did not flash yet is because it eases development - flashed rockbox doesn't load ajbrec.ajz from disk
20:01:20amiconnklaxon: Try to get a new hd. I'd never trust fishy hds
20:03:00klaxonamiconn: 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:01amiconnklaxon: There might be another reason for such a strange behaviour on Windows. It may be caused by a virus
20:04:19amiconnFinally, 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:42klaxonamiconn: good idea. i am pretty sure the hd i dying, it makes the sound of heads re-seeking.
20:06:21amiconnThis might still be caused by a hw problem of the recorder, e.g. flakey power to the hd
20:06:32klaxonand i forgot it was in my saddle bag when i rode home. probably spun up while bouncing around under my saddle (bicycle)
20:07:20klaxonthat is a good suggestion, before installing a new hd. i had not thought of that, thanks.
20:07:32_aLFperhaps out of topic : did you try to read SMART information ?
20:08:06klaxon_aLF: no, i suspose i need an ibm tool for that?
20:08:52_aLFwww.hdtune.com
20:08:53amiconn_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_aLFhdtune work under windows, smartctl works under linux
20:09:44amiconn_aLF: Ok, thanks. I didn't know these tools
20:10:10_aLFwhen my harddisk started to crash, I seen a lot of errors with smartctl
20:10:13klaxon_aLF: great! thanks!
20:10:34_aLF(and I quickly made a backup ...)
20:11:25_aLFnote: smartctl under linux says "pre-failed" on some variables. HDTune says that all is ok
20:12:06_aLFso if you can try a knoppix (or another linux installation) and smartctl
20:13:46klaxoni'll try both.
20:14:52klaxonabout 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:28klaxonwhich 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:15amiconnBagder: 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:34amiconnhi again...
22:16:54amiconnDMA read with background bitswap works!
22:16:57[IDC]Dragonmirc didn't tell me I got disconnected
22:17:10[IDC]Dragonwhow, nice!
22:17:25amiconnI use HydraIRC, and have it set to auto-reconnect when I get disconnected
22:17:28[IDC]Dragonwhat's is the concept now?
22:18:17amiconnStart reading one sector with DMA, and while DMA is running, swap previous sector, yield, then poll for end of DMA
22:19:02amiconnRead speed is increased by ~70 % against CVS version, and the box stays responsive, thanks to the yield
22:19:09[IDC]Dragon:-)
22:19:27amiconnReading 1 MB now takes almost exactly 3 seconds
22:19:33[IDC]Dragonyou read into DRAM or IRAM?
22:19:53amiconnI read directly to DRAM, and swap in place with the existing bitswap
22:20:23amiconnCurently converting the writing, with 2 sector buffers
22:21:16 Quit scott666_ (Read error: 238 (Connection timed out))
22:21:23[IDC]Dragonyeah, with the relatively slow transfer, memory performance doesn't matter that much
22:21:48[IDC]Dragonsector buffers where?
22:22:10 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22:22:24amiconnI'll try both IRAM and DRAM. I suspect IRAM won't increase the performance significantly
22:22:51[IDC]Dragonmaybe not even the code location
22:22:53amiconn(but take 1032 bytes of IRAM)
22:23:34amiconnOf 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]Dragongood
22:24:11[IDC]Dragonand it doesn't need to yield
22:24:24amiconnNope, and it can't either
22:24:43[IDC]Dragonhow about reading singles?
22:25:38amiconnThis 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]Dragonfat+dir handling does a lot of these
22:26:51[IDC]Dragonyou still don't like sector DMA+run swapping behind?
22:27:09amiconnSingle 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]Dragonaha
22:28:56amiconnI doubt that the run-behind will gain much, but I can try anyway later
22:30:18amiconnFor single sector transfers, a significant part of the total time needed is the access time of the card.
22:31:47[IDC]Dragonnot nice
22:32:50[IDC]Dragondo you know how access time, transfer and swap are in relation?
22:33:59amiconnFor 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:53amiconnswap 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:30amiconnAccess 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]Dragonnow _that_ is slow!
22:38:43amiconnThe 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:29amiconnThe 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:08amiconnAgain, these are worst-case times (but still, the MMC specs says that you should take these *10 for calculating timeout
22:41:09amiconn)
22:42:12amiconnPerhaps the card finds a problem while flashing a sector, and relocates the data internally. Flashing is relatively slow afaik
22:50:37[IDC]Dragonhave you seen the post from Mark?
22:50:46amiconnyes
22:50:50[IDC]Dragonhis box has a Samsung tuner!
22:51:18amiconnAh, there is another posting
22:53:03 Join JoeBorn [0] (~41d6673c@labb.contactor.se)
22:53:12amiconnSamsung tuner! Somehow I expected this. What else should that tuner bit be good for?
22:54:04***Saving seen data "./dancer.seen"
22:54:16amiconnThat 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:03amiconnIf you try to adapt the while-recording screen, recording should work out of the box imho
22:55:35[IDC]Dragonmaybe, yes (to both of your points)
22:56:45[IDC]Dragonbut I'll wait for you new r/w
22:56:51amiconnThe 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]Dragonis playback smooth now?
22:57:36amiconnYes, as afr as I tried. Will have to try hight bitrates and/or mp2
22:57:47amiconns/afr/far/
23:00
23:09:32 Quit wake ("leaving")
23:14:56[IDC]Dragonthe paint onmy Ondio's buttons already starts to peel off!
23:15:10[IDC]DragonI had it in a pocket today
23:16:24[IDC]Dragonanother topic: it operates down to 2.6V
23:16:41[IDC]Dragonso it can really suck the batteries flat
23:17:19amiconnInteresting. 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]DragonI did, it never comes
23:18:35[IDC]Dragonright now I have it closed, but should check what the supply voltage does
23:19:19amiconnHmm. What is that signal be good for then? The archos hardware design is really a bit strange at some points
23:19:57[IDC]DragonI guess they just had the pin left over
23:31:40amiconnNow there is a bug in my routines...
23:32:19[IDC]Dragon:-(
23:33:44amiconnIt 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]Dragonyou have a test that verifies data, right?
23:38:46amiconnYes, but that doesn't help much in this case. I'll do this test after I solved the mystery.
23:44:49amiconnThe problem is within the reading...
23:44:58[IDC]DragonI now fixed the battery display
23:45:20amiconnNice
23:53:25 Join gromit`` [0] (~gromit@ALagny-151-2-4-90.w82-121.abo.wanadoo.fr)

Previous day | Next day