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).

#rockbox log for 2004-10-04

00:51:22DEBUGLost contact with server (snapshot: netstuff.c line 597)
00:51:22***Saving seen data "./dancer.seen"
00:51:22***Cleanup
00:51:22***Cleanup
00:51:22***No seen item changed, no save performed.
00:51:22***Exit
00:51:22***Started Dancer V4.16
00:51:22***Connected to irc.freenode.net on port 6667
00:51:22***Logfile for #rockbox started
00:51:23***Server message 501: 'logbot :Unknown MODE flag'
00:51:23Mode"logbot :+i" by logbot
00:51:23 Join logbot [242] (~bjst@labb.contactor.se)
00:51:23 Join gromit`` [0] (~gromit@ALagny-151-1-41-197.w83-114.abo.wanadoo.fr)
00:51:23 Join bagawk [0] (Lee@bagawk.user)
00:51:23 Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net)
00:51:23 Join mattzz [0] (~mattzz@c227123.adsl.hansenet.de)
00:51:23 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
00:51:23 Join DeepB [0] (~x@107.Red-217-127-93.pooles.rima-tde.net)
00:51:23 Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
00:51:23 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
00:51:23 Join Ka_ [0] (~tkirk@pcp261180pcs.howard01.md.comcast.net)
00:51:23 Join Hadaka [0] (naked@naked.iki.fi)
00:51:23 Join mbr [0] (~mb@stz-softwaretechnik.com)
00:51:23 Join plok [0] (s336156@student.uq.edu.au)
00:51:23 Join dwihno [0] (~dw@81.8.224.89)
00:51:23 Join elinenbe [0] (~elinenbe_@65.115.46.225)
00:51:23 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
00:51:23 Join ze [0] (psyco@adsl-63-205-44-84.dsl.lsan03.pacbell.net)
00:51:23 Join silencer- [0] (~silencer@zen.via.ecp.fr)
00:51:23 Join webmind [0] (~random@217-195-236-172.dsl.esined.net)
01:00
01:00:03bagawkhi logbot :)
01:00:23 Quit bagawk ("umount /dev/brain")
01:00:38 Quit _aLF ("bye")
01:07:42amiconn:)) mmc driver is now faster for writing as well: 17..80 %
01:18:57 Quit plok ("Leaving")
02:00
02:05:58 Quit mattzz ("Client exiting")
02:09:16 Part amiconn
02:51:24***Saving seen data "./dancer.seen"
02:59:45 Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc)
03:00
03:02:36 Join iRiverMan [0] (~acbfbf7f@labb.contactor.se)
03:02:43iRiverManhi
03:28:35 Quit iRiverMan ("CGI:IRC (Ping timeout)")
03:33:41 Quit silencer- (Read error: 104 (Connection reset by peer))
04:00
04:25:06 Part DeepB
04:51:27***Saving seen data "./dancer.seen"
05:00
05:01:19 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
06:00
06:23:50 Quit scott666_ ("i'll be back...eventually...")
06:23:50 Quit kramerica (Read error: 104 (Connection reset by peer))
06:51:31***Saving seen data "./dancer.seen"
06:53:39 Join LinusN [0] (~linus@labb.contactor.se)
07:00
07:12:58 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
07:16:11 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
07:55:50 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net)
07:57:33 Quit AciD (Read error: 110 (Connection timed out))
08:00
08:00:04 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
08:02:08 Join webguest28 [0] (~401829cb@labb.contactor.se)
08:03:26webguest28test
08:03:58 Quit webguest28 (Client Quit)
08:20:46 Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net)
08:20:48 Quit kramerica (Read error: 232 (Connection reset by peer))
08:38:34 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
08:41:02 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
08:49:48 Join webguest80 [0] (~d996a082@labb.contactor.se)
08:50:27 Part webguest80
08:51:34***Saving seen data "./dancer.seen"
08:58:22 Join [IDC]Dragon [0] (~idc-drago@p50861B66.dip.t-dialin.net)
08:58:58[IDC]DragonHello Jens, do you read?
09:00
09:07:33LinusN[IDC]Dragon: better call for "amiconn", as his IRC client might call for his attention when seeing his nick
09:07:42LinusNat least mine does
09:08:11[IDC]Dragonjust trying to be nice at first ;-)
09:09:02[IDC]DragonLinusN: did you read about the interrupted playback from MMC?
09:09:57 Join Zagor [242] (~bjst@labb.contactor.se)
09:10:03[IDC]Dragonperhaps the mpeg thread needs some fine-tuning wrt initial load, chunksize, etc.
09:10:18[IDC]DragonHi Zagor!
09:10:26Zagorih
09:10:28Zagorhi
09:10:59[IDC]Dragonhow was the Rockbox-free weekend? (I also had one)
09:11:32Zagorvery good, thanks. i went up north and spent the weekend outdoors.
09:13:24LinusN[IDC]Dragon: no, i haven'
09:13:31LinusNt heard about iinterrupted playback
09:13:48LinusNi also had a rb free weekend :-)
09:14:21LinusN[IDC]Dragon: i think it might have to do with the dynamic watermark levels
09:14:29[IDC]Dragonplayback works now (I goofed), a bit jerky
09:14:53[IDC]Dragonbut we better discuss that when amiconn is alert
09:14:57LinusNthey are calculated from the disk spinup time, doesn't really apply to mmc
09:15:26[IDC]Dragonspinup is fast, transfer is slow ;-)
09:15:41[IDC]Dragonthanks to our SH
09:15:52LinusNso we need to revise the watermark handling
09:16:19LinusNwe need to do that anyway, since the spinup time measurement bugs
09:16:37[IDC]Dragondo you think so? what would happen if spinup time measures very fast?
09:17:23LinusNthe watermark level will be set quite low
09:17:30[IDC]Dragonso?
09:17:56LinusNand there is increased risk of buffer underrun
09:20:36*[IDC]Dragon loads some songs on the ondio
09:23:08[IDC]DragonUSB1 is slooow
09:25:32 Quit Nibbler (Read error: 238 (Connection timed out))
09:49:58amiconn[IDC]Dragon: Now I'm around. And: My client alerts me if either my realname or my nick is mentioned. Of course this only helps when I'm around ;)
09:49:59 Quit kramerica (Read error: 54 (Connection reset by peer))
09:52:41 Join MisticJeff [0] (~MisticJef@lv-65-173-87-243.dyn.sprint-hsd.net)
09:53:08MisticJeffZagor, LinusN... good morning
09:53:13Zagormorning
09:53:24MisticJeffdid you get my email
09:55:20Zagoryes
09:56:26LinusNMisticJeff: morning
09:56:43MisticJeffgood morning
09:57:14MisticJeffdon't know whether that will work for you or not but thought i'd throw it out there
09:57:35 Join amiconn_ [0] (~jens@pD9E7E4F2.dip.t-dialin.net)
10:00
10:02:45 Join ashridah [0] (ashridah@220.253.120.65)
10:03:24BagderZagor: I and LinusN discussed how to deal with the wildcard sources concept now when iriver enters
10:04:00BagderI suggest we introduce a concept with a special file like 'SOURCES' that is preprocessed that mention what source files to build
10:04:21LinusNi think that's the way to go
10:04:26Zagorsounds good
10:04:33Bagder(so LinusN's weekend wasn't _entirely_ rb-free :-)
10:04:40LinusN:-)
10:05:08Bagderok, so I'll start working on setting up such a concept
10:05:33 Join kramerica [0] (~lkd@207.195.113.154)
10:05:38Bagderit'll be easier to build for iriver target once we have that fixed
10:05:40LinusNfunny, the iriver has separate i2c busses for each i2c slave...
10:05:49LinusNBagder: great
10:09:31 Quit amiconn (Nick collision from services.)
10:09:32 Nick amiconn_ is now known as amiconn (~jens@pD9E7E4F2.dip.t-dialin.net)
10:10:58 Quit [IDC]Dragon (Read error: 110 (Connection timed out))
10:11:58Bagder-m1 is a sh-specific gcc option, isn't it?
10:12:06LinusNyes
10:12:16Bagderneeds to be moved to configure then
10:12:37LinusNit's supposed to be -m5349, but the gcc docs are lying
10:13:26Bagderso what is it?
10:14:18LinusNlemme check
10:15:31LinusN-m5200 might do
10:16:34Bagderok
10:17:15Bagder-fomit-frame-pointer -fschedule-insns is only used in the apps makefile
10:17:19Bagderis that on purpose?
10:17:31LinusNi don't think so
10:18:58Bagderok, making them global
10:19:13Bagderoh
10:19:25Bagderthey're added in the firmware as well, but only if non-debug
10:19:32LinusNof course
10:19:45Bagderwe'll need to set them up conditionally in the configure script instead
10:28:56 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
10:30:16 Join methangas [0] (methangas@0x50c61ce6.virnxx10.adsl-dhcp.tele.dk)
10:42:47amiconnhi Jörg
10:42:48 Quit kramerica (Read error: 104 (Connection reset by peer))
10:46:45[IDC]DragonHello Jens
10:47:07[IDC]Dragonconcgratulations to your latest achievements
10:47:29LinusN[IDC]Dragon and amiconn: are you really sure that you are supposed to speak i2c with the tuner on the ondio?
10:47:54[IDC]Dragonpretty much, yes (why?)
10:47:57LinusNi mean, then busenable wouldn't have been present in the 10-pin header
10:49:13[IDC]Dragon?
10:49:34[IDC]Dragonthe bus enable is necessary because the pins are shared with the LCD
10:49:52[IDC]Dragonwell, at least the clock
10:50:00LinusNah
10:50:29LinusNfunny, why didn't they connect it to the i2c bus instead?
10:50:58[IDC]DragonI guess this is because they have the option to mount the Samsung tuner instead
10:51:08LinusNperhaps
10:51:10[IDC]Dragonwith the classic hookup
10:51:38[IDC]Dragonone pin is unused, which before was with SPI
10:51:39***Saving seen data "./dancer.seen"
10:51:56LinusNi see now
10:52:54[IDC]Dragonon the iriver, you are also facing multiple I2Cs, I read above?
10:54:26[IDC]Dragonso you'd also benefit from a multi-instance capable driver, if worth the effort
10:56:23amiconn[IDC]Dragon: I thought for a while that you may be right and the mask bit 3 does tell whether there is a tuner or not, because from the Archos site I learned that there is an "original Ondio 128", which shares firmware with the "Ondio 128 FM recorder". However, the Ondio 128 also features a radio
10:56:24 Part oxygen77 ("Cho")
10:57:22*[IDC]Dragon waits for the wide user base to tell us
10:57:57[IDC]Dragonmaybe the original one has a backlight
10:58:22amiconnor maybe the original one has a Samsung tuner
10:58:49amiconnDid you try to dig for the FAT16 bug?
11:00
11:01:10[IDC]Dragonafk, meeting
11:01:24[IDC]Dragonyes, I did, no success yet
11:01:35 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
11:06:19LinusNyes, a multi-instance i2c driver is a must
11:07:03LinusNthose koreans must have a bad dictionary entry for "bus"
11:09:09 Join wizzzard [0] (~merlin@dsl-082-082-234-199.arcor-ip.net)
11:21:27ashridahheh
11:22:23Zagorbus: A long motor vehicle for carrying passengers, usually along a fixed route.
11:22:40Zagorwhat's that got to do with i2c? ;)
11:23:54LinusN:-)
11:24:25LinusNsee? even your dictionary is wrong! ;-)
11:24:38 Quit Nibbler (Read error: 238 (Connection timed out))
11:28:42amiconnZagor: (merriam-webster) bus: (3) a set of parallel conductors in a computer system that forms a main transmission path
11:30:05 Join Chronic007 [0] (~Miranda@24.30.163.142)
11:30:37 Join iRiverMan [0] (~acbefb5d@labb.contactor.se)
11:30:48iRiverManmornign
11:35:55Chronic007shhhhhhh.....we don't want to interrupt the technical discussions of the rockbox team.....they may fleet away into private discussions...then I'll have no break from the manotony of my homework.....hahahahahha
11:36:01iRiverMancan't wit to see rockbox on the iriver
11:38:00Chronic007; - )
11:38:18ashridahit's not going to happen overnight.
11:38:40iRiverManwill it happen eventually
11:38:52iRiverMani got an ihp-120 to replace my busted Archos Recorder 10
11:39:08ashridahthey've gotten the debugger working. things progress.
11:39:11iRiverMan:)
11:39:34iRiverManthe iriver can record to wav or mp3, has a radio tuner and supports wav, mp3, wma, asf and ogg
11:39:35Chronic007yeaaaa Linus!!!!
11:40:21Chronic007Wonder if PaulS has had any luck with his unit
11:40:54iRiverManwill rockbox on the iriver be the same as rockbox on the archos?
11:41:22LinusNiRiverMan: yes
11:41:41LinusNmore or less, of course
11:41:51iRiverManand if you wanted to, could u revert back to the iriver firmware from rockbox if u wish?
11:41:51LinusNthe platforms are different
11:41:55LinusNyes
11:42:14iRiverMancool
11:42:24iRiverManthe iriver firmware is good, but playlist handling is a bit poor
11:43:20iRiverManso far the only way to shuffle playlists is to manually shuffle them in Winamp
11:43:32iRiverManbut at least it can shuffle the hard drive without a playlist
11:43:35LinusNthe iriver fw annoys the hell out of me
11:43:40iRiverManwhy linus?
11:43:47iRiverMani have an iriver ihp-120
11:43:53LinusNone keypress too many, and i'm back in the Playing screen
11:44:05iRiverManwell nothing practice wouldn't fix
11:44:19iRiverManafter all it is much more advanced than the Archos
11:44:21Chronic007Linus: I agree...and scrolling soooo slow
11:44:40LinusNand the silly joystick is too slippery
11:44:51iRiverManlinus the joystick is not slippery
11:45:08LinusNi can't hold it for long until it slides under my finger
11:45:11iRiverManman 5 gigabites transferred in 5 minutes over the USB2.0 port!
11:45:23iRiverMani use my thumb on the joystic
11:45:33LinusNi'll have to put some hot glue or something on it
11:45:44LinusNi use the thumb as well
11:45:46iRiverManI still think its a better machine than the archos
11:45:52LinusNabsolutely
11:46:04LinusNlightyears ahead, imho
11:46:06iRiverMan:)
11:46:14iRiverMani've got the hitachi HD for my old archos lying around
11:46:29iRiverMani decided to save the HD from the Archos
11:46:32iRiverMan10gb Hitachi
11:46:55iRiverManthe iriver uses the 20gb Toshiba drive
11:47:12LinusNi want at least 40...
11:47:22iRiverMani don't like the look of the 40gb iriver
11:47:28iRiverManthe 20gb one looks better
11:47:34LinusNperhaps
11:47:57iRiverManlinus u may kill me if i say this but i very nearly bought an ipod before choosing the iriver
11:48:03Chronic007I can't wait till somone figures out how to upgrage the h140 to 80gig
11:48:27Chronic007: -)
11:48:27ashridahChronic007: you'll have to wait till someone crams the 80g into the 40g drive's formfactor.
11:48:39Chronic007already been done
11:48:47iRiverManif they can add more "pixie dust"
11:48:57dwihnofaerie dust! :)
11:49:03iRiverManok faerie dust then
11:49:18iRiverManDoes anyone know any ogg rippers around
11:49:19ashridahChronic007: yeah? where/how/who/howmuch? :)
11:49:53iRiverMani wonder if the iriver can be reprogrammed to play atrac3 or aac
11:49:58Chronic007someone was posting about it at the irver@lounge forums lemme see if I can find the thread......BRB
11:50:36iRiverManor mp3pro eveb
11:50:38iRiverManeven
11:51:50LinusNiRiverMan: yes, yes and yes
11:52:19LinusNhowever, there are patent and license issues
11:52:55LinusNso we might not be able to do it because of that
11:52:56iRiverManlol
11:52:57iRiverManok
11:53:07iRiverManwell mp3pro is not protected
11:53:50LinusNthen again i wonder why anyone would want mp3pro
11:54:26iRiverManbecause a 64kbs mp3pro sounds as good as 128kbs mp3 in half the file size
11:54:54iRiverManso u can squeeze more music on a device
11:55:44iRiverMani've compared a 64kbs mp3pro to its original 40mb wav file and the quality is almost as good
11:56:38iRiverMan:-)
11:57:02iRiverManand the quality is certainly better than wma
11:58:00LinusNlunch time
11:58:55iRiverMandon't eat too much
11:59:06iRiverMan:D
12:00
12:00:26Chronic007Ashridah: Ok back with report, Buckaroo Banzai posted in the @lounge forums "Toshiba announced the start of the production of 30GB and 60GB 1.8" harddisks at the end of august or september" - well it was 60g not 80g sorry didn;t mean to get your hopes up.
12:00:50iRiverManlol
12:01:05iRiverManwhaever happened to those dataplay disks?
12:02:14 Join webguest60 [0] (~82ec60fd@labb.contactor.se)
12:02:41webguest60Anybody here?
12:03:04Zagorwebguest60: yes
12:03:38iRiverManhi
12:03:49webguest60I am looking for information about the mas3587f which is built into some of the rockbox....
12:06:14Zagorwhat do you want to know?
12:06:14webguest60Where can I buy the mas3587f circuit? Small order, 2 or 3 circuits....
12:06:32webguest60Preferably in Sweden...
12:06:36Zagorno idea. tried the usual places?
12:06:59webguest60yepp, no go...
12:07:23webguest60just a place in easterneurope...
12:08:17 Quit iRiverMan ("CGI:IRC (EOF)")
12:08:21Zagorit's a very specialized circuit, not many companies carry it. eastern europe is probably as close as you will get.
12:09:43webguest60Arrow Electronics sell them in sweden, but only for industries, which probably mean at least 500 circuits a batch :) crap
12:10:56Zagoryou can always ask for a few samples
12:12:28webguest60yeah, or contact their customers (sometimes works),
12:17:35 Part MisticJeff
12:18:33 Join R3nTiL [0] (~zorroz@227-250-30-217.kgts.ru)
12:24:44webguest60thanks anyway! bye
12:24:47 Quit webguest60 ("CGI:IRC")
12:31:34BagderSRC := $(shell cat SOURCES | $(CC) -DMEMORYSIZE=$(MEMORYSIZE) $(INCLUDES) $(TARGET) $(DEFINES) -E -P -include "config.h" -)
12:31:38Bagderkinda nice ;-)
12:32:02Bagdereven better than include since this "takes" immediately
12:32:11Zagorskip 'cat' and it will work on windows too
12:32:43Bagdercat works on cygwin
12:32:52Bagderwe already use cat like that for the link files
12:34:15Zagorwhy pipe at all?
12:34:18 Part wizzzard ("Kopete 0.9.0 : http://kopete.kde.org")
12:36:49LinusNgcc has issues with the file naming
12:37:16LinusNit doesn't accept all file extensions for preprocessing, iirc
12:37:53Bagderright, but I probably use < SOURCES
12:37:58LinusNor rather, it tries to be smart, behaving differently for different file types
12:38:30Bagder"I can" even
12:41:08amiconn[IDC]Dragon: r u there?
12:51:43***Saving seen data "./dancer.seen"
13:00
13:02:18 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
13:10:10 Quit R3nTiL ()
13:13:29Zagorthis is a wonderful optical illusion: http://web.mit.edu/persci/people/adelson/checkershadow_illusion.html
13:17:45methangasyeah i love that one, i didnt believe it until i edited everything else out and putted them next to each other
13:25:10 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net)
13:28:22 Quit Nibbler (Read error: 238 (Connection timed out))
13:30:49[IDC]Dragonback again
13:31:12[IDC]Dragontriggering Jens amiconn
13:31:17amiconn[IDC]Dragon: Perhaps the following may give you a hint what's going wrong with fat 16:
13:32:13amiconn(1) At the point the panic occurs, the code tries to write 96 sectors before the first allowed sector. Maybe a coincidence, but the size of the root dir is 32 sectors...
13:33:04amiconn(2) The panic does not occur when the FAT16 partition is located at the beginning of the disk, because the 96 sectors then wrap around (unsigned) to a very high sector number
13:33:35[IDC]Dragonoh, so I should panic for that, too
13:34:37amiconnThe FAT code in general (both FAT16 and FAT32) should panic if it tries to access areas outside the partition
13:35:31amiconnFurthermore, you assign the root dir "virtual" cluster numbers < 0. I wonder how you handle the case that the root dir size is not an integer number of clusters
13:36:54[IDC]DragonI do
13:37:18[IDC]Dragonthen the start sector of the "file" is not zero
13:38:26[IDC]Dragonlook into fat_open_root()
13:39:31amiconnAh ok.
13:42:19[IDC]Dragonamiconn: the -96 sector, is that the very first one to be written?
13:46:53oxygen77hello, anybody here with some knowledge in XLIB?
13:48:14Zagoroxygen77: a bit
13:50:53oxygen77cool
13:51:16oxygen77I'm doing a X simulator for the graphical lib of linav
13:51:29oxygen77I can draw in black and white
13:51:44oxygen77but now I'm trying to use colors
13:52:18oxygen77is there a way to use directly RGB?
13:53:23[IDC]DragonZagor: what am I missing in that optical illusion?
13:53:44ZagorA and B is the same color
13:54:07[IDC]Dragonaha? nice
13:55:22amiconn[IDC]Dragon: Dunno which write causes that; it's the first write that tries to write in the forbidden area and hence causes the panic
13:56:02[IDC]Dragonreally strange that it doesn't happen in the test suite
13:56:40[IDC]DragonI stared at the code for endianess or other porting problems, but found none
14:00
14:00:55amiconn[IDC]Dragon: We would need a way to backtrace the call. However, I have no idea how to do this
14:05:05[IDC]Dragonthat's possible, but the worst part is that the player display is so small
14:05:42amiconnThere is lcd_puts_scroll() ...
14:05:51[IDC]DragonI was thinking about how I can set something up
14:06:03[IDC]Dragonon my gdb-capable recorder
14:06:37[IDC]DragonI need to install another disk
14:08:17amiconnI could try to display a part of the stack frame, the figure out what's going on with a disassembler listing
14:08:36amiconns/the/then
14:08:55Zagor[IDC]Dragon: you can always repartition the disk you have, and make a small fat16 partition on it
14:09:02[IDC]Dragonbut before I do that, I wait for my USB2 card, which is on order
14:09:19[IDC]Dragonthe USB2 on my mainboard is unreliable
14:09:31amiconn[IDC]Dragon: I could do that with my recorder as well, my old 20 GB disk is still laying around...
14:10:25[IDC]DragonZagor: I thought about shrinking my partition, to create a little FAT16 one at the end
14:10:43[IDC]Dragonbut I prefer not to endanger the data on it
14:11:21[IDC]DragonI have a "spare" (=empty) 20 GB disk
14:15:31[IDC]Dragonamiconn: in your new code, I noticed that the delayed write is mapped to the normal write
14:16:15[IDC]DragonI don't think that's such a good idea, iirc the WPS calls this once per second to save the resume position
14:16:19Bagderstand clear for yet another Makefile commit
14:16:31[IDC]Dragonso we'll have a lot of flash wear
14:17:01[IDC]DragonBagder: uh oh :-/
14:17:19Bagderthis is just another step forward towards easier life
14:17:37Bagderlike less fixed recorder <=> bitmap <=> FM associations
14:23:53amiconn[IDC]Dragon: I mapped the delayed write to the normal write because there is no spinup. This was already there with my first version supporting writing. I didn't know that this is accessed *that* often...
14:24:36BagderLinusN: here?
14:25:12LinusNyup
14:25:26Bagderis it really intended to use -O for debug builds?
14:25:39LinusNyes
14:25:43Bagderok
14:25:45amiconn[IDC]Dragon: Now that I though about it a bit, I think the backtracing won't be hard.
14:26:07LinusNBagder: otherwise the inlining doesn't work, and the scheduler messes up
14:26:13[IDC]Dragonno, we can just store an array of the params
14:26:14LinusNiirc
14:26:15Bagderah, right
14:26:55[IDC]Dragonwe could even log to fixed sectors
14:27:58amiconn[IDC]Dragon: I think the idea of displaying the stack frame on panic and the backtracing by hand with disassembled rockbox isn't hard
14:28:30[IDC]Dragonthis is very low
14:29:16[IDC]Dragonbut we couldeven write the stack to disk, for more comfy handling
14:29:56[IDC]DragonI once have made a little memory scroll screen (for recorder)
14:30:59 Join Yokalosh [0] (~3efec181@labb.contactor.se)
14:31:01[IDC]DragonLinusN: how would you like the idea to be able to scroll back through the stack on panic?
14:31:28LinusNsounds really nice
14:31:28 Quit Yokalosh (Client Quit)
14:31:59LinusNstill, our panic numbers help a lot today
14:32:19LinusNi haven't felt much need for a more detailed trace
14:33:08[IDC]Dragonyou had gdb...
14:33:45LinusNyes, but the panic numbers have often been enough for traceback
14:34:24LinusNwith the panic numbers i can see the exact call chain
14:34:40LinusNwell, not always exact, but close
14:35:29LinusNstill, if you can produce a stack dump, i won't protest
14:35:44LinusNunless it bloates the code, of course
14:37:46[IDC]Dragonprobably not, a key loop and a printf
14:38:57LinusNthen go for it
14:39:37LinusNi still want the panic codes
14:40:57[IDC]Dragonprobably the keys don't work any more...
14:41:35[IDC]Dragon... without interrupts ticking
14:43:37LinusNtrue
14:51:46***Saving seen data "./dancer.seen"
14:55:23amiconn[IDC]Dragon: How would you write the stack to disk? Obviously we can't use the file system, because that's what we try to debug
15:00
15:01:15[IDC]Dragonamiconn: raw sector writing is OK
15:03:04 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
15:03:42Bagdercommitted
15:07:29mbrHi
15:07:36mbrOne question regarding the new button handling.
15:07:46mbrI think it inverted old UP/DOWN behaviour on recorder in some places
15:08:18mbrZagor did the changes, right?
15:08:42Zagoryes
15:08:48mbrHi
15:09:07mbrfor example Recent and List Bookmarks changed
15:09:15mbrPreviously DOWN got the next older entry, now it is UP
15:09:22mbris this intended?
15:09:50mbrAnother example is Debug -> View battery UP/DOWN
15:10:10mbrNow I need to use UP to get the next page
15:10:26mbrIn fact most debug screens are inverted.
15:10:36Bagderplease cvs update and try the new make
15:10:45Zagoryes, there was a lot of mixups in the debug screens
15:11:05Zagordown is now INC in all screens
15:11:21Zagoruh, pposite :)
15:12:11amiconnZagor: Any new button code in the pipe? The problem with the double-left exists in many places..
15:12:30Zagoryes, i'll fix it.
15:12:31*[IDC]Dragon barely dares to ask about the Ondio menu button
15:13:07mbrI find the Bookmark behaviour a little bit confusing
15:13:26mbrI think DOWN should get the next older
15:14:08Zagorpossibly, yes
15:15:49amiconnZagor: If we have buttons that react both on short & long press, we have to trigger on the release for short presses. However, for long presses we have to trigger on the repeat (already), so the (trailing) release has to be "eaten". Otherwise it triggers another item
15:16:54amiconnSame goes for buttons with a single function only, that trigger on the keypress itself.
15:17:20LinusNamiconn: we might want it a little more sophisticated
15:17:49amiconnLinusN: In what respect?
15:17:51LinusNlike providing some feedback on the down event, but performing the action on release
15:18:12LinusNto make the interface appear more "snappy"
15:20:18amiconnLinusN: Another topic, concerning interrupts, yield() and the mmc driver:
15:21:19amiconnI would make the mmc driver yield() between transfers, because otherwise the ui appears locked for several seconds.
15:22:01amiconnIn order to do this, I'd have to do many things within ISRs, otherwise the performance would drop significantly
15:23:03LinusNexplain
15:23:15amiconnThere would be ISRs (well, one) that may run a bit long, and in order to not block other interrupts, I'd have to enable interrupts within that ISR
15:23:49*oxygen77 is away: chui pas là
15:24:00amiconnWhile this is fine with my ISR, this may screw the set_irq_level() logic in other code (?)
15:25:19 Quit Nibbler (Read error: 238 (Connection timed out))
15:25:39amiconnExplanation: With ata, there is one, possibly, long, wait before the start of data transfer. Once the transfer starts, it is done at once.
15:26:36amiconnWith MMC, there is a wait before each block transfer, where the start of block mark has to be polled for. The block transfer itself can be done with dma.
15:27:09amiconnThe wait itself is _relatively_ short, so yielding there would significantly drop performance
15:27:40amiconnFurthermore, if doing block transfers with dma, the bitswap has to be done afterwards.
15:28:43Bagderok, last chance for makefile comments until tonight
15:29:21amiconnSo my idea was to let an isr capture the end-of-block interrupt, then wait for the next block by polling (with interrupts enabled)
15:30:30amiconnThe bitswap is done in the mmc thread, on demand by the isr
15:32:14amiconnBoth the mmc thread and the thread calling the mmc driver could then yield, and while a block transfer is running, other threads could run. (typically for 512*8*4 = 16384 clock cycles)
15:32:40amiconnBagder: New configure necessary to test that?
15:32:45Bagderyes
15:32:54LinusNBagder: hang on
15:33:03Bagdergcc opts moved out from the makefiles to the root makefile
15:33:17Bagderanother coldfire prep
15:33:50LinusNls
15:34:22LinusNoops
15:34:23Bagdercheck apps/SOURCES for an example of how this works
15:35:07LinusNthis is great, now we can exclude the grayscale stuff for the player
15:35:30Bagderyes, very easily
15:35:46LinusNand lcd-player... driver stuff for the recorder etc
15:36:00LinusNme likes it
15:36:05Bagderit should make it easier for your early iriver builds too
15:36:14LinusNabsolutely
15:39:29amiconnBagder: YOur new make logic seems to work. Unrelated to this, I get a linker error for the fmr linking rombox "region FLASH is full"
15:39:59BagderI noticed that one too
15:40:05BagderI don't know why though
15:41:06amiconnI think it's clear. Rombox doesn't fit into flash, so the linker errors out
15:41:27Bagderbut why doesn't it fit all of a sudden=
15:41:28Bagder?
15:41:39Bagderor didn't it before either?
15:42:18Zagorfm never fit afair
15:43:14LinusNthe bleeding edge builds fail too
15:43:58Bagderbtw, I bet the daily build will need attention due to the configure needing to be re-run
15:45:14LinusNyou'll have to reconfigure manually
15:45:36LinusNor fix the scripts
15:45:42LinusNZagor?
15:46:17BagderI have no time now, the scripts should be fixed to do it every time
15:46:25*Bagder runs off
15:46:27Zagorwe don't reconfigure anymore, remember?
15:46:34Zagorit's all from the scratch all the time
15:46:40LinusNnot the daily builds
15:46:44LinusNonly the bleeding edge
15:46:56LinusNseparate scripts
15:47:04Zagor!??
15:47:10Zagorwell I did them that way
15:47:30LinusNlast time i checked, only the bleeding edge builds were fixed
15:47:53LinusNi had to run configure manually
15:48:05LinusNthat's why there were no daily builds for a few days
15:49:11Zagorah, found and fixed. a trailing "update" was left.
15:49:41LinusNgoodie
15:49:57Zagorbleeding works though
15:52:23LinusNgotta go, cu guys
15:52:41 Part LinusN
16:00
16:24:02*oxygen77 is back (gone 01:00:12)
16:24:28 Part oxygen77 ("Cho")
16:33:46 Quit ashridah ("sleep")
16:41:12 Part Zagor
16:43:30 Join WhiteStar [0] (mithrandir@pD9E1EA4A.dip.t-dialin.net)
16:43:35WhiteStarHi
16:44:23WhiteStarDoes somebody want to buy a new JB Car Kit?
16:44:47[IDC]Dragonwhat's that?
16:45:19WhiteStarEr, sorry, it's the Travel kit
16:45:22WhiteStarhttp://archos.com/products/prw_500179.html
16:45:59[IDC]Dragonno, thanks
16:46:34WhiteStari had to send my jbr back in and got the money back, but i still have the travel kit...
16:48:18WhiteStarIs the Gmini 20 any good, besides being unable to run rockbox?
16:51:12[IDC]Dragonthe 220 is definitely cute
16:51:21[IDC]Dragonbesides, I don't know
16:51:49***Saving seen data "./dancer.seen"
16:53:50WhiteStarokay thanks
16:54:28 Join mecraw [0] (~lmarlow@69.2.235.2)
16:56:04 Join mattzz [0] (~mattzz@c159207.adsl.hansenet.de)
17:00
17:01:01 Join webguest42 [0] (~3f7cde02@labb.contactor.se)
17:01:47 Quit webguest42 (Client Quit)
17:04:19 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
17:08:52[IDC]Dragonamiconn: r u there?
17:11:07amiconnyeps
17:11:45[IDC]DragonI suggest using sleep_thread() in the driver
17:12:05[IDC]Dragonfar less overhead than yield()
17:12:35[IDC]Dragoneven the I2C driver uses that while waiting for ack
17:14:30[IDC]Dragonyield() wakes up all threads
17:15:24amiconnyes, but does sleep_thread() allow other threads to run?
17:15:42[IDC]Dragonsleep_thread() will directly enter CPU sleep mode if all other threads are sleeping
17:16:03[IDC]Dragonbut then walk around
17:17:32[IDC]Dragoncausing n context switches
17:18:00WhiteStarhow much would a JB Studio 10 be worth today?
17:18:24[IDC]Dragonand n-1 threads calling sleep_thread() again, in their wait loop
17:18:39amiconnWhiteStar: I bought one from eBay for ~90 €
17:19:32amiconn[IDC]Dragon: I wonder if one walk-around is done in less than ~1.3 ms. Otherwise, performance would drop significantly
17:21:41WhiteStarhum. well i need a mobile HDD and it should be with mp3-player, so archos seems to be the best choice...
17:21:53WhiteStaralthough i had to retourn the JBR0
17:21:56WhiteStar*20
17:22:33[IDC]Dragonamiconn: 1.3 ms is 1000 cycles!
17:24:26[IDC]Dragonbut you can easily measure it, to check
17:25:07amiconn1.3 ms is 16384 cycles (transfer of 512 bytes over SCI @ 3 MBit/s)
17:26:19[IDC]Dragonah, sorry, I had it reciproc and all mesed up
17:26:32[IDC]Dragonmessed
17:26:36[IDC]Dragonsee?
17:27:05 Quit Nibbler (Read error: 238 (Connection timed out))
17:27:27[IDC]Dragonwell, but definitely enough to walk around our ~5 threads
17:28:15 Join gromit``` [0] (~gromit@ALagny-151-1-27-41.w83-114.abo.wanadoo.fr)
17:28:28[IDC]Dragonif we sleep the CPU, it needs an interrupt to wake it up again
17:29:02[IDC]Dragonso you can't do that in a pure polling environment, I'd say
17:36:02amiconnYes. I can't do that while polling for start of data, hence I wanted to do it while the sector transfer is running. Then I capture the end-of-dma-transfer interrupt
17:36:46amiconn(That needs dma implemented first, of course)
17:38:24[IDC]Dragonwill that be any faster than now? (or: are you transmitting/receiving back to back currently?)
17:39:14WhiteStarbyebye ^^
17:40:29amiconn[IDC]Dragon: (1) What do you mean with back to back? (2) I think it wil be faster than the current implementation, because with the polling approach, there are short pauses between the individual bytes
17:40:59[IDC]Dragonthat's what I meant with back-to-back, yes
17:41:13[IDC]Dragonif the clock is continuous
17:42:17 Quit gromit`` (Read error: 110 (Connection timed out))
17:42:46[IDC]DragonI'd guess you're just a little bit slower now (haven't checked with the scope)
17:43:07 Quit WhiteStar ("( www.nnscript.de :: NoNameScript 3.79 :: www.XLhost.de )")
17:43:59[IDC]DragonI'd like to correct me: yield() is no more expensive, and it returns the control to you without interrupt
17:45:58[IDC]Dragonso perhaps do this in your polling loop, at least once
17:46:44[IDC]Dragon(I know, with polling we don't have the whole sector worth of time)
17:51:08amiconnThe problem is that the polling time can vastly differ: from a few 100 clocks to several 10000's
17:51:40[IDC]Dragonif some other thread has something to do, yes
17:51:58[IDC]Dragonbut that's why we yield, isn't it?
17:52:31[IDC]Dragonor, you mean the MMC time?
17:58:13amiconnI mean mmc time
17:58:29[IDC]Dragonok
17:58:46[IDC]Dragonstill it more or less matches
18:00
18:01:02amiconnThe problem here is that while polling, the mmc has to be clocked, and this can't be done via dma, because we need to catch the first data byte != 0xFF
18:03:13amiconn(away)
18:06:34[IDC]Dragonthen how about: 1) send command, 2) yield, 3) poll
18:07:39 Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
18:07:40_aLFhi
18:11:40[IDC]Dragonamiconn: I'm getting some wild ideas:
18:11:56[IDC]Dragonbyte != FF means falling edge
18:12:38[IDC]Dragoninfortunately, RxD1 has no dual function as an interrupt
18:14:35[IDC]Dragonperhaps we can clock SCK1 using the Programmable Timing Pattern Controller
18:15:20[IDC]Dragonand have the serial in an async mode which gives an interrupt when falling
18:20:09[IDC]Dragonlike, setting it to highest baudrate, falling is the start bit, it will give an interrupt somewhat late
18:30:14[IDC]Dragoneither the TPC clock has to be much slower than the async baudrate, such that a framing error interrupt occurs within one TPC cycle,
18:30:49[IDC]Dragonor the rates have to match and the information in the async receive is recycled
18:31:24[IDC]Dragoneither case would require a fast stop of the TPG
18:38:35 Quit AciD (Connection timed out)
18:39:21[IDC]DragonI'm off
18:39:30 Quit [IDC]Dragon ("CGI:IRC")
18:45:10 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
18:49:42 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!")
18:51:50***Saving seen data "./dancer.seen"
18:53:16 Join salimfadhley [0] (~sal@host-83-146-34-206.bulldogdsl.com)
19:00
19:04:02 Quit mattzz ("Client exiting")
19:22:56 Join [IDC]Dragon [0] (~idc-drago@pD9FF886E.dip.t-dialin.net)
19:23:07[IDC]Dragonhi again
19:23:17amiconnKa_:
19:23:26amiconnerh, I mean: hi
19:23:56amiconnFound your wild ideas. Unfortunately, this won't work, for several reasons
19:24:01[IDC]Dragonguess my wild ideas are not too practical :-/
19:24:38[IDC]DragonI was just thinking aloud
19:24:56amiconn(1) We have to maintain byte sync as long as /CS is low. /CS has to stay low during the whole transfer. Hence no async mode or single clocks possible
19:25:44amiconn(2) The first bit of the byte we have to catch is _not_ 0, only the last one is. Furthermore, we need the correct value of that byte
19:27:05amiconnI had some similar wild ideas, that also wouldn't work, like receiving into a TPC register and compare-matching the byte
19:28:34amiconnThe problem with that is that the dma has to be stopped *immediately* after receiving the first byte
19:34:18amiconnI just made MMC writing another 15% faster (still polling). Same thing for reading is on its way...
20:00
20:13:21 Part salimfadhley ("I am slowly drifting away from you....")
20:23:36 Join webguest89 [0] (~8446da7f@labb.contactor.se)
20:25:08 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
20:30:45amiconn[IDC]Dragon: r u there
20:30:47amiconn?
20:44:58 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
20:44:58 Quit kramerica (Read error: 104 (Connection reset by peer))
20:45:07 Quit webguest89 ("CGI:IRC (EOF)")
20:47:01 Quit Sebulba03 (Read error: 104 (Connection reset by peer))
20:51:54***Saving seen data "./dancer.seen"
20:59:23 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
21:00
21:11:18 Quit Nibbler ("¿")
21:11:18 Quit kramerica (Read error: 104 (Connection reset by peer))
21:11:52 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de)
21:29:37amiconn[IDC]Dragon: knock knock!
21:35:10 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca)
21:47:17 Join scott666_ [0] (~scott666@24.245.58.48)
21:47:18 Quit kramerica (Read error: 104 (Connection reset by peer))
22:00
22:06:43 Nick scott666_ is now known as scott666 (~scott666@24.245.58.48)
22:07:03 Join Paco_ [0] (~Miranda@80.119.248.127)
22:09:40 Quit Nibbler ("¿")
22:27:02[IDC]Dragonamiconn: I'm here
22:27:16[IDC]Dragongirlfriend took over the PC
22:27:16amiconnAh, finally ;)
22:27:41amiconnI traced back the call to transfer() which causes the panic.
22:27:51[IDC]Dragonand?
22:28:14 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- Get hot chicks here!")
22:29:21amiconnIt happens when I go to info->debug->dump rom contents in the write call for the first file (boot rom). Call sequence is as follows:
22:32:29 Join webguest33 [0] (~c7e73180@labb.contactor.se)
22:33:19amiconn(file.c) write(fd, 0, 0x1000); −−> readwrite(fd, 0, 0x1000, true)
22:33:24amiconnfd is unknown from the backtrace, but shouldn't be too interesting
22:33:40webguest33hi all
22:34:12webguest33I have a UI question/comment
22:34:34amiconn[IDC]Dragon: From readwrite(), the first call to (fat.c) fat_readwrite(&file->fatfile, 128, 0, true)
22:34:49webguest33If you're listening to music loud to stay awake driving late at night,
22:34:59webguest33and resume is set to YES
22:35:32webguest33You can be VERY startled the following morning :)
22:36:06amiconn[IDC]Dragon: Then the _last_ call to transfer(168, 112, 8182, true) causes the panic.
22:36:08webguest33would it make sense to resume at some less loud volume, at least if some time has passed?
22:36:57amiconn[IDC]Dragon: This is of course correct, since the first valid sector is 264 (== 168 + 96)
22:42:03amiconnSummary: (file.c) write(fd, 0, 0x1000) (line 565) −−> readwrite(fd, 0, 0x1000, true) (line 471) −−> (fat.c) fat_readwrite(&file->fatfile, 128, 0, true) (line 1969) −−> transfer(168, 112, 8192, true) −−> panic
22:42:44[IDC]Dragonwhy the panic then?
22:43:37amiconnIt seems like the code writes the beginning of the file into a sigle cluster, and tries to write the whole remainder into a single cluster chain. Somehow it gets the start sector wrong
22:44:10amiconnWhy panic? Because sector 168 is forbidden, first valid sector is 264
22:44:57[IDC]Dragonah, the panic is correct, see above
22:45:17[IDC]Dragonis this with the image you gave me?
22:46:22amiconnYes, although not precisely, since this would require to put back the image first.
22:47:13 Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc)
22:49:19[IDC]Dragonbtw, how did you trace?
22:51:06amiconnI defined a static array of 32 longs. Then I put a copy loop at the start of transfer(), which copied 32 values from the stack into the array. Within the if() that detects the panic condition, I put an output loop that shows me the 32 values, 2 at a time.
22:51:09[IDC]Dragontracing the sim: first, I get a lot of single sector transfers, the FAT entries
22:51:57***Saving seen data "./dancer.seen"
22:52:24[IDC]Dragonthen 16 sectors, a cluster
22:52:24amiconnThis revealed that the call came from fat_readwrite, and the parameters as well. Then I moved that copy loop to the start of fat_readwrite(), which revealed the call from readwrite() and the parameters as well
22:53:35[IDC]Dragonpoor Jens
22:53:42amiconnHuh?
22:54:04[IDC]Dragontedious work, I mean
22:54:39amiconnWell, it wasn't that hard, althoguh it required a bit of disassembling
22:55:27[IDC]Dragondo you have the image from before this action?
22:56:29amiconnOne thing I discovered: You extended cluster2sec() (precisely: first_sector_of_cluster() for the cluster < 0 case (fat16 root dir). However, you did not do that for the reverse function, sec2cluster()
22:58:30[IDC]Dragonit's not used fot FAT16
22:58:38amiconnMaybe that it's not necessary, since this is only used within fat_opendir(), which is not used for fat16 root
22:59:07amiconnAH
22:59:41[IDC]Dragonhow about the image before?
23:00
23:00:10amiconnYes, I still have the image as I sent it to you
23:00:46[IDC]Dragonyou said your state was different
23:02:07amiconnYes because in order to use the exact state again, I would have to put the image back on the box before every experiment.
23:02:43amiconnThis is an USB1.1 box....
23:02:48[IDC]Dragonor, just the fat and the root dir
23:02:57amiconnHmm.
23:03:12 Join Zagor [0] (foobar@h254n2fls31o265.telia.com)
23:03:29[IDC]Dragonevening Björn
23:03:33Zagorhi
23:03:49amiconnZagor: evening
23:03:55amiconn[IDC]Dragon: Have to figure out the exact location, and split the image file accordingly
23:04:33amiconnAnd I have to do that twice (once for each function trace)
23:05:25[IDC]Dragon?
23:06:01amiconnNot the "figure out and split file", but the write back to the box
23:06:31amiconnZagor: How would you split a large file at a given position, on the unix command line?
23:09:29Zagorwith dd
23:10:43amiconnAh, probably using the "seek" option?
23:11:38Zagoryes, seek or skip
23:12:19Zagor(they do the same thing, only using different block sizes)
23:12:21 Quit AciD (Read error: 110 (Connection timed out))
23:12:58[IDC]Dragonwith your image, I get 8 single cluster writes
23:13:02 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
23:13:24[IDC]Dragonplus the fat+dir sectors interspersed
23:13:40amiconnAh, seek is for output, skip is for input. Nice, so I can use both, and don't have to split the file beforehand (and one possible error source less)
23:14:36[IDC]DragonI have to leave soon, but try to dump my transfer() parameters
23:19:37 Join erik____ [0] (~erik@foxtail.org)
23:20:41 Part Paco_
23:20:48amiconn[IDC]Dragon: The offending call to transfer() looks exactly the same as I told above with the original image
23:22:45[IDC]Dragonwith that manysectors?
23:23:15amiconnyes. The stack frame looks identical
23:23:21[IDC]DragonI get no more than a cluster each time
23:23:35[IDC]Dragondo you see the single sectors as well?
23:24:02amiconnNo. I catch only the call that causes the panic
23:24:27[IDC]Dragonjust in case you would:
23:24:44[IDC]DragonI get sigle sector writes like the following:
23:24:51[IDC]Dragontwice to 264
23:25:09 Quit erik____ ("Leaving")
23:25:14[IDC]Dragonthen 265 to 279 all in single sectors
23:25:46[IDC]Dragon(16 calls to transfer() )
23:26:02amiconnThe fat_readwrite() call looks identical too
23:26:11[IDC]Dragonthen 8 cluster-size calls for the payload
23:26:52[IDC]Dragonto 680, 696, 712, 728, 744, 760, 776, 792
23:27:03amiconnThat is the output from the LDEBUGF() macros I guess?
23:27:10[IDC]Dragonthen 2 single sectors, 801 and 264
23:27:50[IDC]Dragonthat's my breakpoint at transfer()
23:28:00*[IDC]Dragon sees something
23:28:10amiconnTelling you just the transfer() calling parameters?
23:28:21[IDC]Dragonthis test code does not combine consecutive access
23:28:31amiconnAhhah!!
23:28:41[IDC]Dragonprobably because the max transfer size is faked low
23:29:08[IDC]DragonZagor: do you remember how this is handled?
23:30:41amiconnBtw: There is an _ugly_ _hard coded_ dependency to ata behaviour in fat.c: It tries to combine consecutive sectors into one ata call, but max. 256 because this is the maximum ata can handle. However, this is not true with MMC
23:31:30 Quit webguest33 ("CGI:IRC")
23:31:33[IDC]Dragonwhere it the combining? I can't find it
23:32:15amiconnfat.c, lines 1912ff
23:32:34Zagoramiconn: well I wouldn't call it terribly ugly, but yeah there is a limit
23:32:43amiconnThe ata dependency is in line 1955
23:33:05[IDC]Dragonthe hard coded 256?
23:33:11amiconnyes
23:33:26[IDC]Dragonwhy does it not combine here, then?
23:34:10amiconnI dunno.
23:34:25[IDC]Dragonperhaps the test code feeds small chunks
23:34:56amiconnI'll put a parameter output at the start of transfer(), and retry. Then we can compare the sector numbers & counts
23:35:42[IDC]Dragonyes, there is an 8 K chunk size
23:36:07[IDC]Dragonamiconn: you can save that effort
23:36:14amiconnOkay.
23:43:19[IDC]DragonI increased the size to 64K, but this still went smooth
23:43:44amiconnHmm.
23:43:55[IDC]Dragonwhat a pity, I was really hoping for the problem to show up
23:44:54[IDC]Dragonit's writing the payload in one swoop, from sector 680 on
23:45:30[IDC]Dragonthe fat+dir traffic looks similar
23:48:05amiconnI wonder why the target code tries to write 112 of the 128 sectors starting at sector 168 then
23:49:00amiconnDo you display write accesses only? I'm asking because if I would display read accesses too, it would be tedious to click through at box startup
23:49:27 Quit mecraw ("Trillian (http://www.ceruleanstudios.com)")
23:49:47 Join mecraw [0] (~lmarlow@69.2.235.2)
23:51:07[IDC]DragonI broke on read, too,but skipped those
23:52:55[IDC]DragonI really gotta go now
23:53:07[IDC]Dragonmaybe we'll nail it tomorrow!
23:53:13 Quit [IDC]Dragon ()

Previous day | Next day