00:01:38 | | Quit xz ("http://www.mibbit.com ajax IRC Client") |
00:02:20 | Zagor | kugel: reboot on mp3 is nice fuze feature :-) |
00:04:00 | kugel | oh yea :S |
00:05:09 | JdGordon | Zagor: does your boost patch for CF need a whole rebuild? or is jus rockbox.irivier good enough? I want to test it, but i dont want to be stuck for a 3 hour drive with no working rockbox... |
00:05:39 | Zagor | JdGordon: rockbox.iriver is enough |
00:06:38 | Zagor | you could also use "configure −−rbdir=.rockbox.testing" |
00:07:30 | amiconn | Unhelpful: I checked the aspect ratio of the iAudio remote (which is used as the main LCD on M3). It is very close to 13:14 (pixels are wider than tall) |
00:07:55 | amiconn | Right now we're ignoring this and treat them as square |
00:09:36 | kugel | Zagor: indeed, boosting is noticeably faster |
00:09:47 | kugel | and I already hoped all problems would be vanished :S |
00:10:27 | Zagor | yeah, hope is nice :-) |
00:10:55 | | Quit bluebrother ("leaving") |
00:11:14 | kugel | not if it's destroyed seconds later :( |
00:11:31 | kugel | Zagor: −−rbdir will only work if clocks are re-set in the main and not only in the bootloader (which is e.g. not so given on ams) |
00:11:48 | * | kugel has no idea for cf though |
00:12:31 | Zagor | kugel: that's one of many reasons we should avoid relying on bootloader for initialization |
00:12:55 | | Quit mcuelenaere () |
00:12:57 | * | kugel surely agrees |
00:13:17 | * | JdGordon is a dill and has the wps updating from the playback thread in the playback patch :/ |
00:13:51 | kugel | JdGordon: btw: forget what I said about your patch earlier today (maybe yesterday for you??) |
00:14:02 | kugel | I actually failed and hadn't applied it |
00:14:09 | JdGordon | haha |
00:14:13 | amiconn | meh |
00:14:47 | * | amiconn still gets this endless refresh loop on the build details page quite often |
00:15:56 | | Quit flydutch ("/* empty */") |
00:16:19 | | Quit MethoS- (Remote closed the connection) |
00:16:32 | kugel | Zagor: did your fuze arrive yet? |
00:17:10 | Zagor | yeah, that's how I got mp3 reboots :) |
00:17:13 | | Quit crwl (Read error: 60 (Operation timed out)) |
00:17:17 | | Quit solexx (Read error: 110 (Connection timed out)) |
00:17:21 | kugel | I slightly suspected that ;) |
00:18:09 | kugel | Zagor: the slowdowns on aac are actually noticeable with backlight fading applied |
00:18:17 | kugel | I wouldn't have noticed them without |
00:18:53 | kugel | that means a) we aren't fast enough or b) the timer gets messed up or confused (I tend to b actually) |
00:19:09 | | Quit m0f0x_ (Client Quit) |
00:19:34 | | Quit parafin (Remote closed the connection) |
00:20:19 | | Join parafin [0] (i=parafin@paraf.in) |
00:20:42 | JdGordon | Zagor: seems to be working fine on my CF modded h300... boost ratio is 41%, but thats meaninglyess because I have no idea what that ratio is with svn |
00:21:18 | Zagor | JdGordon: I would expect it to be higher with the patch since the normal clock is less than half of svn |
00:24:07 | | Quit gregzx_ (Read error: 110 (Connection timed out)) |
00:25:44 | | Join xz [0] (i=d9843bde@gateway/web/ajax/mibbit.com/x-0321925316232b17) |
00:26:02 | xz | Hi all! Maybe somebody knows whether there will be rockbox on the Gigabeat V30 (MEV30)? |
00:26:28 | scorche | xz: whenever someone works on it.. |
00:27:45 | | Join japc [0] (n=japc@bl7-248-115.dsl.telepac.pt) |
00:29:33 | | Quit merbanan (Remote closed the connection) |
00:31:59 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
00:32:13 | | Join Calcipher [0] (n=Calciphe@cpe-68-173-193-88.nyc.res.rr.com) |
00:35:36 | Calcipher | would anyone here be able to shed some light on why a Cygwin set up that I have used to successfully build Rb with, gives me arm errors when trying to build the D2 bootloader |
00:36:20 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
00:37:11 | Bagder | how old arm setup? |
00:37:55 | Calcipher | well, atleast 6 months |
00:38:11 | Calcipher | so... I'm guessing thats probably already the answer hm? |
00:38:27 | Calcipher | update cygwin? |
00:38:34 | Bagder | if it's older than 2007-10-19 I figure it could be that |
00:38:46 | xz | I've read that Gigabeat V is very similar to the Gigabeat S. And there is already almost compleeted version on S. Will somebody do port for V? |
00:39:10 | Bagder | xz: if an owner joins in and do the work! |
00:39:20 | Bagder | one or many |
00:40:58 | Calcipher | Bagder, When I'm using this cygwin setup, I can't get anything done unless I first issue the "export PATH:$PATH/opt/arm/bin |
00:41:09 | Calcipher | I never knew why |
00:41:21 | Bagder | because you didn't edit the correct setup file I'd guess |
00:41:32 | Calcipher | well thats not exactly the command but almost |
00:41:50 | * | Bagder is not a cygwin guru |
00:42:04 | Calcipher | ah, think its probably a safe bet to redo my set up |
00:42:35 | Calcipher | I am not any kind of command line interface guru |
00:43:16 | Calcipher | and only when experimenting with some plugins and patches did I venture into the debian setup that you all offered |
00:43:37 | kugel | Calcipher: you need to add the compiler binaries to the PATH environement variable. Look for a file ".profile" in your home dir |
00:43:44 | Calcipher | and when I realized I was not sure what I was doing in there, I tried cygwin with success |
00:44:18 | Calcipher | with the vmware debian, I really could not figure out how to access the files I was editng in windows |
00:44:20 | kugel | files with dots at the beginning are hidden by default |
00:44:29 | | Quit xz (Remote closed the connection) |
00:44:30 | | Quit GodEater_ (Connection reset by peer) |
00:44:37 | | Quit ender` (" If I had only finished this sentence,") |
00:44:59 | Calcipher | ok |
00:45:20 | kugel | Zagor: I guess you also already noticed the strange pixel corruption? |
00:45:47 | Zagor | yes |
00:45:51 | Calcipher | kugel, any idea what directory that profile file would be in? |
00:46:02 | kugel | in your home dir |
00:46:16 | kugel | type "cd ~" and you'll be in there |
00:46:36 | Calcipher | Is that THE Zagor, USB hope lives |
00:46:49 | Calcipher | thanks |
00:46:52 | kugel | o.O |
00:47:09 | Zagor | haha. I'm not the usb guru anymore. I "just" got the ball rolling. |
00:48:03 | kugel | Zagor: it seems those pixel corruptions happens for bitmaps wider than ~210px |
00:48:07 | Calcipher | We are all grateful |
00:48:13 | Zagor | Calcipher: :-) |
00:48:35 | Zagor | kugel: I am getting spurious BUTTON_OFF events. do you get that too? |
00:48:44 | kugel | not at all |
00:48:54 | kugel | but I remember lucent had those too |
00:49:36 | pixelma | kugel: do you still have the screenshot available somewhere? Just remembered someting from the beginning of the c200 port and like to compare |
00:49:36 | | Join gartral1 [0] (n=Gartral@adsl-75-33-65-127.dsl.bcvloh.sbcglobal.net) |
00:49:42 | pixelma | something too |
00:50:21 | pixelma | of the display corruption I mean |
00:50:30 | gartral1 | umm, sleep after backlight off hangs after the e200s backlight fades out, and stays there untill a hard reboot is preformed |
00:50:36 | | Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
00:50:41 | kugel | http://www.alice-dsl.net/simonemartitz/rockbox/mainmenu1.png http://www.alice-dsl.net/simonemartitz/rockbox/wps.png |
00:51:00 | Zagor | kugel: something is strange. it barely copes with a 112kbps vorbis file. cpu is peaked 100% yet doesn't manage to fill the pcm buffer! |
00:51:18 | kugel | that's not new to me :) |
00:51:29 | Zagor | clock settings must be wrong |
00:51:35 | kugel | ogg is just slightly better than aac |
00:52:00 | kugel | well, guess why I was hoping so heavily on your boost fix ;) |
00:52:04 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
00:52:15 | gartral1 | i dont notice *too* much lag from oga files |
00:52:27 | | Quit neddy ("Leaving.") |
00:52:40 | | Quit GodEater_ (Remote closed the connection) |
00:54:32 | *** | Saving seen data "./dancer.seen" |
00:54:34 | kugel | Zagor: there's only one clock that may differ between the ams sansas (DBOP) but that's as of now the same for all too |
00:55:10 | kugel | Zagor: what I had in my mind is that the memory set up is wrong. |
00:55:23 | kugel | basically, those with 2MB play fine, those with 8MB are bad |
00:55:26 | gartral1 | hey JdGordon around at all? |
00:55:35 | | Quit Nico_P (Remote closed the connection) |
00:55:45 | Zagor | kugel: yeah, that's definitely a possibility |
00:56:20 | kugel | Zagor: especially this part in system-as3525.c: /* 16 bits external bus, high performance SDRAM, 64 Mbits = 8 Mbytes */ #define MEMORY_MODEL 0x5 |
00:56:42 | kugel | "high performance", I don't know whether this is a fact, or assumption |
00:57:15 | preglow | my h120 battery seems to be getting worse :/ |
00:58:01 | gartral1 | preglow: perhaps the battery is just crystallizing? |
00:58:05 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
00:58:22 | amiconn | kugel, Zagor: Is there a cache in the as3525, and is it enabled? |
00:58:32 | | Join gregzx [0] (n=chatzill@dsl211.neoplus.adsl.tpnet.pl) |
00:58:52 | Zagor | amiconn: a) yes, b) I don't know |
00:59:25 | Zagor | but the difference between clip and fuze suggest something other than general cpu setup |
00:59:30 | kugel | I think IRAM is enabled. clip uses it for codecs, and I can put lcd data fine into it |
00:59:48 | kugel | I don't know about other caches |
01:00 |
01:00:11 | amiconn | I was just thinking about the cache because of the 2MB vs. 8MB memory target differences |
01:00:28 | amiconn | Afaik the whole codec resides in iram on the 2MB ones |
01:01:03 | amiconn | But I guess that doesn't apply to the 8MB models. Codec in SDRAM and cache not enabled would explain performance problems... |
01:01:48 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-3aa0241c509d0ad6) |
01:01:52 | amiconn | ...even if it uses some IRAM for critical parts |
01:02:02 | Zagor | true |
01:02:50 | | Quit plus_M (Remote closed the connection) |
01:05:02 | Zagor | well it looks like they get enabled in the bootloader at least |
01:05:10 | | Join scorche|1h [0] (n=scorche@squisch.net) |
01:06:19 | gartral1 | umm... should firmware_flash.rock really be avaiible for the e200 v1s yet? i dont see a working USB stack/// |
01:07:28 | preglow | gartral1: doing what? :P |
01:08:06 | * | kugel tries codecs in iram |
01:08:39 | kugel | BTW: Yes, apps/codecs/SOURCES should be dependant on CODEC_SIZE instead of MEMORY > 2 |
01:08:46 | gartral1 | my e250 v1 has firmware_flash.rock... i thougt that flashinf the firmware was the last step in a supported device |
01:08:56 | pixelma | kugel: thanks, I remembered now that the glitch in the c200 lcd driver was not screendumpable, so it's probably something else |
01:09:22 | Zagor | kugel: indeed |
01:09:51 | gartral1 | [brb] |
01:10:00 | amiconn | kugel: Why? |
01:10:01 | | Join Hillshum [0] (n=Hillshum@75-165-245-240.slkc.qwest.net) |
01:10:25 | amiconn | You sure want a larger codec buffer on the 8MB targets, enabling all codecs |
01:10:34 | Zagor | amiconn: because that's what causes it to link or not |
01:10:51 | kugel | amiconn: "why" regarding? |
01:10:56 | Hillshum | Should I be getting a jabber msg after registering in flyspray? |
01:11:18 | Zagor | Hillshum: no, we don't use the jabber feature |
01:11:31 | Hillshum | saying so might help |
01:11:36 | | Quit blithe (Read error: 110 (Connection timed out)) |
01:11:46 | Zagor | very true... |
01:11:53 | | Quit scorche|sh (Read error: 104 (Connection reset by peer)) |
01:12:01 | Hillshum | can I add an email now? |
01:12:07 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
01:12:32 | | Quit troy_ (Read error: 104 (Connection reset by peer)) |
01:13:01 | Zagor | Hillshum: I can do it. what's your login? |
01:13:08 | Hillshum | Hillshum |
01:13:11 | gevaerts | gartral1: flashing has nothing to do with finishing a port. |
01:14:41 | Zagor | Hillshum: uh, seems I can't until you're registered... :-( |
01:15:08 | Hillshum | Maybe the jabber choice made it not tick |
01:15:17 | Zagor | Hillshum: but email is mandatory. did you fill it in? |
01:15:22 | Hillshum | yeah |
01:15:28 | kugel | what's needed to get the codecs into IRAM like 2MB ams sansas? |
01:15:42 | kugel | I changed app.lds and apps/codecs/SOURCES |
01:15:59 | Zagor | kugel: to use the same link script. |
01:16:17 | gartral1 | gevaerts: but doesnt it break the original FW? |
01:16:30 | kugel | the codecs compiled (only those that fit) but I get codec failure |
01:16:45 | | Join webguest00 [0] (n=5b84f61a@gateway/web/cgi-irc/labb.contactor.se/x-924526a8d1d4c6bf) |
01:16:47 | gevaerts | gartral1: huh? |
01:17:10 | gartral1 | doesnt flashing rockbox break the OFW? |
01:17:20 | Zagor | kugel: apps/plugins/plugin.lds is used for linking codecs and plugins |
01:17:23 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
01:17:38 | Zagor | and is controlled by #defines |
01:17:44 | Calcipher | could someone provide a compiled d2 bootloader?, for fw 2.57? |
01:17:56 | kugel | well, of course I didn't look under plugins :/ |
01:18:19 | * | kugel finds that only slightly missleading |
01:18:50 | Hillshum | Zagor: worked but I thing I held CAPSLK to long and got HIllshum |
01:18:55 | Llorean | gartral1: Where did you read that it does? |
01:19:18 | Calcipher | I just want to try the rb setup on the Cowon D2, I most likely will need to return the thing since its so hard to see |
01:19:47 | gevaerts | gartral1: also, how did you get firmware_flash.rock? |
01:20:04 | Llorean | Calcipher: It's not ready to use or we'd be providing one normally. |
01:20:12 | Zagor | kugel: they are so similar we don't want two different files |
01:20:29 | kugel | I understand that |
01:20:39 | | Quit scorche|1h (Read error: 54 (Connection reset by peer)) |
01:20:44 | kugel | thus the "slightly" :p |
01:20:55 | gartral1 | Llorean: somewhere in an M5 wiki.. gevaerts: i got it with r19767 |
01:21:14 | Llorean | gartral1: So some random site? |
01:21:23 | | Quit Makuseru (Read error: 104 (Connection reset by peer)) |
01:21:42 | gevaerts | gartral1: the official e200 build for r19767 does not have that file |
01:21:43 | gartral1 | Llorean: no, on rockbox.org, but i dont know where |
01:21:45 | | Quit webguest00 ("CGI:IRC (Ping timeout)") |
01:21:59 | gartral1 | gevaerts: well its on my dap >.> |
01:22:02 | Llorean | gartral1: Installing Rockbox on the X5/M5 normally breaks dual boot because we don't support it on that. |
01:22:15 | | Join scorche|sh [0] (n=scorche@squisch.net) |
01:22:21 | | Join blithe [0] (n=blithe@stiletto.djblithe.com) |
01:22:21 | Calcipher | •Llorean• how is the port coming? I may just keep the player in anticipation |
01:22:27 | Llorean | gartral1: But flashing Rockbox on targets where we do have dual boot shouldn't disable dual boot. |
01:22:37 | Llorean | Calcipher: it's more or less stalled at the moment. |
01:22:50 | gevaerts | Also, firmware_flash.rock is for flashing archoses |
01:23:12 | gartral1 | Llorean: well, ill leave it alone, and wait till theres a working USB stack |
01:23:25 | gartral1 | i dont wanna brick my e250 |
01:23:29 | kugel | Zagor: hm, still codec failure |
01:23:40 | kugel | I did make veryclean and deleted the .rockbox folder |
01:24:16 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-a2d5d31e20ca32ce) |
01:24:22 | Zagor | clip also uses a different codec buffer size |
01:24:44 | gartral1 | hmm, Llorean, ido build my own, but i edit anything.. could it be a build mistake? |
01:25:00 | Zagor | I have to go to bed. see you tomorrow. |
01:25:03 | pixelma | gartral1: I don't see any firmware_flash.rock in the downloadable e200 build |
01:25:05 | | Quit Zagor ("Clint excited") |
01:25:07 | gartral1 | night Zambezi |
01:25:13 | gartral1 | oops |
01:25:29 | Zambezi | gartral1: Np. ;-) |
01:25:44 | Zambezi | gartral1: I'm actually about to go to bed. :-) |
01:25:56 | gartral1 | lol, happy mistake! |
01:27:06 | gartral1 | here, i still have my built rockbox.zip, want me too upload it? all i did was change the bootsplash too my own image |
01:27:10 | | Quit Hillshum (Remote closed the connection) |
01:27:38 | | Quit itcheg (Remote closed the connection) |
01:28:31 | kugel | wow |
01:28:44 | gartral1 | kugel: what? |
01:29:04 | | Quit at0m ("CGI:IRC (Ping timeout)") |
01:29:12 | kugel | i got it |
01:29:46 | * | gartral1 stands at a slant, tottally confused |
01:30:06 | | Join notplus_M [0] (i=plus@li26-205.members.linode.com) |
01:30:11 | | Quit amiconn (Remote closed the connection) |
01:30:11 | | Quit pixelma (Remote closed the connection) |
01:30:25 | kugel | the iram and codec stuff |
01:30:45 | gartral1 | http://drop.io/wco4uas# <−− my rockbox.zip, built for a sansa e250 V1 |
01:32:08 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-37bb0bb2a298e3eb) |
01:32:15 | | Part notplus_M |
01:33:41 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
01:33:45 | | Join pixelma [0] (n=pixelma@rockbox/staff/pixelma) |
01:37:54 | | Quit amiconn (Remote closed the connection) |
01:37:55 | | Quit pixelma (Remote closed the connection) |
01:38:39 | | Join pixelma [0] (n=pixelma@rockbox/staff/pixelma) |
01:38:41 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
01:40:45 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
01:41:51 | | Join neddy [0] (n=john@nat/sun/x-80f1718f56edefdb) |
01:42:41 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
01:43:53 | | Quit Thundercloud (Remote closed the connection) |
01:44:04 | | Quit Seed (Read error: 110 (Connection timed out)) |
01:44:34 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
01:45:46 | pixelma | gartral1: I'd guess there are unrelated changes in your source too, probably in apps/plugins/SOURCES |
01:47:04 | scorche | gartral1: do a diff and you should see this.. |
01:47:07 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
01:47:58 | | Quit DerDome ("Leaving.") |
01:48:35 | | Quit fdinel (Read error: 104 (Connection reset by peer)) |
01:51:28 | | Quit markun ("leaving") |
01:53:37 | | Join CaptainKewl [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) |
01:55:09 | gartral1 | scorche: nope, just showing my bootsplash change |
01:55:58 | gartral1 | of course, it helpsdoing the diff in the right folder... |
01:56:52 | | Quit PaulJam (".") |
01:58:07 | | Join markun [50] (n=markun@rockbox/developer/markun) |
01:59:50 | gartral1 | http://gar.pastebin.com/m7df25664 |
02:00 |
02:01:18 | gartral1 | i changed one file... apps/bitmaps/native/SOURCES |
02:07:13 | * | gartral1 is baffles by strange, sudden appearence of firmware_flash.rock |
02:07:22 | gartral1 | baffled even |
02:08:43 | | Quit moos ("Rockbox rules the DAP world") |
02:11:01 | gartral1 | there absolutly no reason for it too have shown up as far as i see |
02:17:32 | | Part facta |
02:23:47 | lucent | okay, 120 builds down, 100 more to go |
02:25:47 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
02:25:57 | gartral1 | wellp, i figured out why firmware_flash was compiled in... |
02:26:13 | gartral1 | make.deps lists t |
02:36:53 | lucent | hi fdinel, how are you? :) |
02:39:38 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
02:41:08 | | Quit Acksaw (Read error: 145 (Connection timed out)) |
02:43:48 | | Quit GodEater_ (Remote closed the connection) |
02:45:23 | gartral1 | oooookay... this firmware_flash is being persistent |
02:47:43 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
02:48:25 | gartral1 | i has found discrepancy! it only want too compile firmware_flash.rock with make reconf! |
02:50:21 | lucent | make reconf being buggy, no surprise there |
02:50:28 | lucent | good find! |
02:50:50 | gartral1 | it compile a firmware_flash for the e200s...! |
02:50:58 | gartral1 | compiled* |
02:53:34 | gartral1 | or not.. |
02:54:27 | | Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) |
02:54:35 | gartral1 | great, now theres a rockbox_flash AND firmware_flash |
02:54:36 | *** | Saving seen data "./dancer.seen" |
02:55:11 | gartral1 | and this was with a veryclean build folder |
02:55:13 | lucent | #define BM_MAX_WIDTH (((LCD_WIDTH) + 7) & ~7) |
02:55:19 | lucent | what exactly is going on here? |
02:55:26 | lucent | what the heck is ~7 |
02:55:31 | gartral1 | is that in my diff? |
02:55:32 | lucent | xor? |
02:55:56 | lucent | 1's complement? |
02:56:22 | gartral1 | thats something the diff program thre in there, that doesnt physically exists in any code according too grep |
02:57:11 | gartral1 | the past day, me and building rockbox just got buggyer and buggyer, im surprised it still work |
02:57:26 | gartral1 | works* damn S key |
02:59:45 | gartral1 | lucent: where did you find that? |
03:00 |
03:00:32 | | Quit BHSPitLappy (Read error: 60 (Operation timed out)) |
03:01:07 | lucent | gartral1: it's a patch by Unhelpful, and comments out this logic instead hard coding it with a value, which fixes bitmap rendering on fuze 8gb |
03:01:15 | lucent | gartral1: apps/recorder/bmp.h |
03:01:53 | | Quit Barahir (Read error: 60 (Operation timed out)) |
03:02:22 | | Join ze [0] (i=ze@76.91.72.105) |
03:02:25 | gartral1 | ohh.. i thought you were talking about my entry, lol |
03:04:30 | | Join Barahir [0] (n=jonathan@X9fa4.x.pppool.de) |
03:05:40 | gartral1 | so what too do with this mal-loaded firmware_flash? |
03:05:54 | | Quit Acky (Read error: 54 (Connection reset by peer)) |
03:06:33 | lucent | I don't know |
03:06:36 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
03:06:46 | lucent | fix the build system, look at svn log for who submitted make reconf |
03:08:20 | gartral1 | ok, note too self, reconf baaaaad |
03:16:50 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-5bbf5cd1537f3c99) |
03:17:35 | | Join shodanX [0] (n=shodanX@port-92-194-1-134.dynamic.qsc.de) |
03:20:32 | gartral1 | ima delete it |
03:22:14 | gartral1 | well, that didnt phase it at all |
03:22:54 | lucent | gartral1: save yourself some trouble and talk to the person who implemented make reconf |
03:25:16 | gartral1 | well lucent, i dont know who that is, but, the convo, and links remain in the backlog |
03:26:29 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
03:27:28 | lucent | gartral1: I did suggest how you can find out who that is |
03:27:39 | lucent | svn log and look for a reference to reconf |
03:28:45 | gartral1 | i hadnt seen that, please excuse me if i seem a little slow... |
03:29:41 | lucent | gartral1: I don't assume you are a super hero with mind reading powers, forgive me if I don't make myself clear or obvious |
03:30:50 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
03:32:39 | gartral1 | i dont think im like that, i think im an 18 year old with asperger's syndrome... and it makes it very hard for me too keep my focus in one area for an extended length of time :( |
03:33:58 | lucent | hm, what does rockpaint do after 10 seconds? |
03:34:18 | lucent | I have an observation that rockpaint and no button press for 10 seconds = power off on 8gb fuze |
03:34:26 | lucent | I doubt it's supposed to be doing that |
03:34:27 | gartral1 | Daniel Stenberg is who it reports as the contributer |
03:34:59 | | Quit shodanX_ (Read error: 110 (Connection timed out)) |
03:35:00 | lucent | there you go |
03:35:29 | gartral1 | but that doesnt help me get in contact with him, thats just his name |
03:35:31 | lucent | I'm not sure if you would be welcome to file a bug on that |
03:36:16 | lucent | some of the curmudgeons here get their panties in a bundle if you do or don't file a bug, depending on what the bug report is |
03:36:41 | lucent | I suggest filing a bug with "reconf" somewhere in the task name |
03:36:43 | scorche | lucent: you sure have a nice way of talking about people... |
03:36:55 | scorche | gartral1: you might want to have a look at the IrcNicks wiki page |
03:37:06 | gartral1 | thanks scorche |
03:38:04 | gartral1 | ohh.. its dan from haxx, oh boy |
03:38:49 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
03:44:40 | gartral1 | ok, FS http://www.rockbox.org/tracker/task/9798 all set, hope i didnt misspell anything |
03:44:54 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-860498d4d7a706c3) |
03:46:23 | gartral1 | i did however forget too mention this is build r19767... |
03:47:37 | lucent | thanks for your task submission gartral1 ! |
03:47:40 | * | lucent :) |
03:48:08 | gartral1 | gaahhh you all see a "1" at the end of my name?" |
03:48:23 | lucent | why, you do not? |
03:48:28 | gartral1 | nope |
03:48:46 | lucent | must be some Purple IRC quirk |
03:48:46 | gartral1 | i see me as "gartral" without the quotes |
03:48:51 | | Quit itcheg (Client Quit) |
03:49:01 | lucent | use a real client and you would see |
03:49:24 | gartral1 | nope, happens on all clients, pidgin is the only one that locally hides it |
03:49:27 | scorche | lucent: that would be gaim...either way, this has drifted away from #rockbox chat... |
03:50:23 | lucent | oh libpurple, yeah |
03:50:33 | * | scorche coughs |
03:50:44 | * | gartral1 points too pm |
03:51:51 | lucent | scorche: you meant Pidgin IM? |
03:52:16 | scorche | same thing...now move this conversation somewhere else |
03:52:40 | lucent | what conversation, anyways I'm regression testing bmp read sizes on fuze |
03:52:58 | lucent | what does '~' mean in C as an operator on a value? |
03:53:02 | lucent | like ~7 |
03:53:33 | * | gartral1 only kows the charecter in question is called a tilda |
03:54:21 | scorche | tilde |
03:54:31 | scorche | lucent: http://en.wikipedia.org/wiki/Tilde#Computer_languages |
03:55:11 | lucent | well I'm batch compiling, firefox isn't so happy right now |
03:55:46 | lucent | I was hoping for a quick hand expanding the define in apps/recorder/bmp.h with BM_MAX_WIDTH |
03:56:16 | * | gartral1 sticks his tongue out at scorche "anyone else run into that problem with make reconf, or is it another local quirk too blame of JdGordon's build server? |
03:56:18 | gartral1 | " |
03:59:06 | lucent | #define BM_MAX_WIDTH (((LCD_WIDTH) + 7) & ~7) |
03:59:22 | | Part gartral1 |
03:59:26 | lucent | I don't quite grasp what that is indending to do |
03:59:34 | lucent | intending* |
03:59:40 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
04:00 |
04:00:03 | saratoga2 | lucent: looks like that rounds to the nearest byte to me |
04:00:19 | lucent | oh |
04:00:48 | lucent | it looks terrible, is that normal for a define to have logic that depends on the width of a datatype? |
04:00:56 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-0bd7fe75b3c2a509) |
04:01:22 | saratoga2 | how does it depend on that? |
04:01:50 | lucent | bitwise AND against the bitwise inversion of 7? |
04:02:04 | saratoga2 | theres no assumption of bitness there |
04:02:27 | lucent | oh not for ~7 ? |
04:02:37 | lucent | hm |
04:03:24 | saratoga2 | i can't reproduce that firmware flash bug report using the latest SVN so I'm inclined to just close it |
04:03:28 | lucent | I guess these all default to int |
04:03:49 | | Quit fenugrec ("Leaving") |
04:03:59 | | Part Aurix_Lexico |
04:04:14 | saratoga2 | it doesn't actually matter what they default to, so long as its large enough to hold LCD_WIDTH+7 |
04:07:26 | | Join blkhawk- [0] (n=blkhawk@f051067222.adsl.alicedsl.de) |
04:09:28 | | Quit Barahir (niven.freenode.net irc.freenode.net) |
04:09:28 | NSplit | niven.freenode.net irc.freenode.net |
04:09:28 | | Quit axionix (niven.freenode.net irc.freenode.net) |
04:09:28 | | Quit blkhawk (niven.freenode.net irc.freenode.net) |
04:09:50 | | Join gartral1 [0] (n=Gartral@adsl-75-33-65-127.dsl.bcvloh.sbcglobal.net) |
04:09:53 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
04:09:54 | | Part gartral1 |
04:10:06 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@f051067222.adsl.alicedsl.de) |
04:10:06 | | Join gartral1 [0] (n=Gartral@adsl-75-33-65-127.dsl.bcvloh.sbcglobal.net) |
04:10:20 | gartral1 | and USB reboot is broken again |
04:11:14 | NHeal | niven.freenode.net irc.freenode.net |
04:11:14 | NJoin | axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) |
04:19:18 | | Join Barahir [0] (n=jonathan@BAI242b.bai.pppool.de) |
04:24:49 | | Quit undertakingyou (Read error: 104 (Connection reset by peer)) |
04:29:26 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
04:34:03 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-16746a238ca6193e) |
04:39:11 | | Part gartral1 |
04:47:48 | | Join audimage [0] (n=littlebe@ip72-204-51-60.fv.ks.cox.net) |
04:49:00 | audimage | Hello I am installing rockbox with ubuntu on an ipod video 30 gb and i keep getting this message saying "short read" then image movement failed |
04:51:09 | audimage | hello? |
04:53:13 | gregorovius | audimage: be patient, there's not that many people around at this time |
04:53:28 | gregorovius | stay connected and somebody will answer eventually |
04:54:12 | gregorovius | also, what version of rockbox are you installing? are you using the graphical utility? |
04:54:38 | *** | Saving seen data "./dancer.seen" |
04:55:21 | | Join blkhawk- [0] (n=blkhawk@e179202171.adsl.alicedsl.de) |
04:55:57 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
05:00 |
05:01:48 | | Quit gregorovius () |
05:03:59 | | Quit ze ("!@#%$#") |
05:11:01 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-857845038a18beaa) |
05:11:13 | | Join Barahir_ [0] (n=jonathan@Xa764.x.pppool.de) |
05:11:29 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
05:11:36 | | Join hd [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
05:12:18 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@e179202171.adsl.alicedsl.de) |
05:12:53 | | Part audimage |
05:18:38 | Unhelpful | kugel/lucent: the max read width is normally set to LCD_WIDTH, rounded up to the nearest multiple of 8. that's what that is. |
05:19:09 | Unhelpful | n+7, then zero the last three bits. |
05:21:31 | * | Unhelpful is pretty sure literals are int, unless you explicitly make them unsigned with a U suffix, or longer/longerer with L or LL |
05:25:30 | | Quit HellDragon (Read error: 110 (Connection timed out)) |
05:25:43 | | Quit Barahir (Read error: 110 (Connection timed out)) |
05:28:29 | | Quit BHSPitLappy (Read error: 110 (Connection timed out)) |
05:29:15 | saratoga2 | is anyone familar with the cp15 cache control register on ARM? |
05:29:34 | saratoga2 | i'm getting odd results when i read it on the Fuze which makes me think either we don't have it configured or i'm reading it wrong |
05:30:35 | Unhelpful | ... hrm. the performance monitor control register is "in CP15 c15"... fuze isn't arm11, is it? |
05:30:37 | | Quit hd (Connection timed out) |
05:30:56 | saratoga2 | Unhelpful: all arm processors have a CP15, though different ones have different things in it |
05:31:06 | saratoga2 | fuze is just arm 9 though |
05:31:57 | | Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
05:31:59 | | Quit HellDragon (Client Quit) |
05:32:08 | | Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
05:33:29 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
05:36:22 | soap | Hmm, just noticed an odd trend in the IpodRuntime wiki page. WilliamPoetra's nice and systematic testing of Rockbox vs OF on his 80GB iPod Video with 8GB CF card shows a very interesting trend. |
05:36:57 | soap | The higher the bitrate of the MP3 the closer to Apple runtime he got. At first glance it appears to be a linear trend. |
05:40:14 | saratoga2 | is that because the apple runtime decreased or because rockbox increased? |
05:42:16 | soap | both decreased, Apple decreased faster |
05:42:20 | | Quit Horscht ("http://www.geisterfahrer.org") |
05:42:48 | saratoga2 | might be due to the mp3 dual core patch making rockbox more effiecient at higher bitrates |
05:43:05 | | Join bricknail [0] (n=Administ@209-161-229-194.dsl.look.ca) |
05:43:10 | saratoga2 | or more likely their encoder being more efficient at low bitrates and the effect becoming smaller as the bitrate increases |
05:43:19 | soap | hmm, I wonder how accurate his numbers are though. 20 minute decrease in runtime (apple) from 128 -> 192, yet 55 minute decrease from 192->256 |
05:43:26 | bricknail | Hi folks :) |
05:43:26 | soap | this is pre dual-core. |
05:44:07 | soap | I'm prepping for the end-all-be-all. I think this might be my first benchmark where rockbox beats apple. |
05:45:31 | soap | (end-all-be-all being just a bit of hyperbole) |
05:46:38 | soap | but I do rather expect to find you all have doubled iPod Video runtime in one year's time. |
05:48:15 | | Quit Calcipher ("—I-n-v-i-s-i-o-n— 2.0 Build 3515 with A Pack Fix By www.ircmadeasy.com") |
05:48:18 | saratoga2 | kugel: [for the logs] I'm wondering if the cache is actually enabled on the Fuze |
05:48:39 | saratoga2 | i tried to dump the CP15 reg1, which should be cache control and got a value indicating it was disabled |
05:49:10 | saratoga2 | but i'm not 100% sure I did it correctly, although a disabled cache might explain the poor SDRAM performance |
05:49:37 | | Part bricknail |
05:51:43 | | Quit reacocard (Remote closed the connection) |
05:54:16 | | Join ze [0] (i=ze@76.91.72.105) |
06:00 |
06:00:12 | | Join reacocard [0] (i=reacocar@saga.silenceisdefeat.com) |
06:02:20 | | Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) |
06:10:20 | | Quit saratoga2 ("CGI:IRC (EOF)") |
06:15:04 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
06:18:36 | | Quit pixelma (Read error: 110 (Connection timed out)) |
06:19:07 | | Quit amiconn (Nick collision from services.) |
06:19:09 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
06:38:42 | | Join EspeonEefi [0] (i=eefi@STRATTON-SIX-FOURTY-SIX.MIT.EDU) |
06:41:59 | | Quit __lifeless (Read error: 110 (Connection timed out)) |
06:45:03 | | Quit timc`` ("Leaving") |
06:49:49 | | Join miepchen^schlaf [0] (n=miepel@p579ECCF3.dip.t-dialin.net) |
06:53:26 | | Join JackZhou [0] (n=4b77e266@gateway/web/cgi-irc/labb.contactor.se/x-026913953bc9cb66) |
06:53:37 | JackZhou | Hey, can someone give me write permissions? |
06:54:37 | JackZhou | (can anyone read this?) |
06:54:39 | *** | Saving seen data "./dancer.seen" |
06:58:05 | JackZhou | (I was referring the wiki when I asked for write permissions) |
06:59:14 | Dhraakellian | hmm... kde4-webkitpart, kde4-yakuake, and ktorrent are included in the 4.2rc1 ymp, but they're not selected by default |
06:59:19 | | Quit jhulst (Remote closed the connection) |
06:59:39 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
06:59:52 | * | Dhraakellian can see JackZhou's text but cannot do anything about it |
07:00 |
07:00:30 | Dhraakellian | and ohfrack, sorry. thought I was one tab over. |
07:00:46 | * | JackZhou assures Dhraakellian it's not a problem. |
07:03:55 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
07:08:17 | JackZhou | If any moderator or admin of the wiki comes, could you give me permissions to edit? (I have a theme I want to submit), thanks =) |
07:08:23 | | Quit JackZhou ("CGI:IRC") |
07:11:57 | | Quit ze ("gah") |
07:18:27 | | Quit JdGordon (Remote closed the connection) |
07:20:49 | | Join ze [0] (i=ze@76.91.72.105) |
07:20:53 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
07:21:56 | | Join advlaptop2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
07:39:44 | JdGordon | Unhelpful: I dont think it was you're change.. but do you think we can trim the "looking for AA" printf's in the sim? |
07:50:31 | Unhelpful | that wasn't me... and we probably can? i'd also like to remove the AA "size" searching, or perhaps replace size, since it's already a string, with "label"... and let %Cl supply a label |
07:58:56 | | Quit shodanX ("leaving") |
07:59:25 | | Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
08:00 |
08:02:22 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
08:06:08 | kugel | saratoga: (for the logs) interesting. Have you docs regarding this? the mpmc pl172 sheet says there's cache but not how to enable/disable it, the pl175 sheet seems to be more verbose. but I just see you mean the processor cache, I'll definitely have a look |
08:06:16 | | Quit kugel (Client Quit) |
08:12:50 | | Quit Seed ("cu, Andre") |
08:16:35 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:18:29 | | Join ender1 [0] (i=krneki@foo.eternallybored.org) |
08:24:47 | | Join Rob2222 [0] (n=Miranda@p4FDCE2A3.dip.t-dialin.net) |
08:25:23 | | Quit ender` (Read error: 60 (Operation timed out)) |
08:25:26 | jhMikeS | Are all Sansa clips as3525? They're on woot for 9.99. |
08:26:58 | | Join Bagderr [241] (n=daniel@rockbox/developer/bagder) |
08:27:23 | | Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) |
08:28:40 | | Quit Rob2223 (Read error: 60 (Operation timed out)) |
08:40:13 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
08:40:23 | lucent | jhMikeS: holy damn |
08:40:40 | * | lucent buys one |
08:41:02 | | Quit BigBambi (Read error: 113 (No route to host)) |
08:42:05 | lucent | jhMikeS: all the Clips should be as3525 yeah |
08:43:01 | | Join _lifeless [0] (n=lifeless@90.151.41.197) |
08:43:34 | jhMikeS | wheee! |
08:44:00 | lucent | those would be great gifts for any rockbox developers you know |
08:45:08 | | Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) |
08:45:14 | lucent | though 1gb is a bit light |
08:46:10 | jhMikeS | perhaps, but it's cheap and enough to develop on |
08:46:49 | lucent | I've owned the 2gb Clip and know that they come in 3 revisions so far |
08:46:58 | Zagor | 3? |
08:47:07 | lucent | (1.x.x.x) and (2.x.x.x and 3.x.x.x) |
08:47:15 | lucent | all are as3525 I think though |
08:47:34 | lucent | there's two different firmwares from SanDisk |
08:47:43 | advcomp2019 | lucent, we talked about that clip deal in -community already |
08:47:45 | Zagor | where have you found 3.x? I just got the just-released 8GB clip, and it is 2.x. |
08:48:12 | lucent | am I making things up again? uh oh |
08:48:12 | advcomp2019 | lucent, where is the v3 clips? |
08:48:22 | * | lucent checks website to verify |
08:48:36 | jhMikeS | confabulator! |
08:48:57 | Zagor | haha |
08:49:05 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
08:49:06 | advcomp2019 | lucent, i only know of v1 and v2 |
08:49:20 | lucent | okay I fail, only 2 hardware revisions on Clip |
08:50:05 | | Quit nuonguy ("This computer has gone to sleep") |
08:50:25 | Zagor | lucent: phew :) |
08:50:54 | | Quit jhulst (Read error: 113 (No route to host)) |
08:54:44 | *** | Saving seen data "./dancer.seen" |
08:58:30 | | Join Xerion_ [0] (n=xerion@82-170-197-160.ip.telfort.nl) |
09:00 |
09:00:35 | amiconn | jhMikeS: Depending on what you want to do, an 1GB might not be sufficient |
09:00:51 | amiconn | We still need that bank switching going, which applies only to the larger ones |
09:02:06 | linuxstb | Unhelpful: What use is a label - %Cl ? IMO we can just remove all that size searching stuff. |
09:02:34 | | Quit FlynDice ("Konversation terminated!") |
09:02:55 | Unhelpful | linuxstb: possibly a theme might have a "wide" cover art, and use it for front-and-back. pictureflow could search with a label. other things like that. |
09:04:40 | linuxstb | Hmm, OK. |
09:06:05 | Unhelpful | people who are terrified that i have stolen all their batteries could use it to go back to prescaled AA per theme? ;) |
09:08:23 | | Join petur [50] (n=petur@rockbox/developer/petur) |
09:11:10 | jhMikeS | amiconn: it should let me mess around a bit even if I don't get into the SD controller too much. I don't have anything that would need bank switching even now. |
09:12:07 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
09:14:17 | amiconn | Zagor: What is this boost test plugin good for? Afaics, it just does what you can also do via System->Debug->CPU Frequency |
09:14:27 | | Quit Xerion (Read error: 110 (Connection timed out)) |
09:14:27 | | Nick Xerion_ is now known as Xerion (n=xerion@82-170-197-160.ip.telfort.nl) |
09:14:33 | Zagor | amiconn: it shows if boost actually makes a difference |
09:15:33 | Zagor | System->Debug->CPU Frequency just prints the frequency. that worked fine on the clip. yet boost didn't. |
09:15:50 | amiconn | Ah, using a counter |
09:16:47 | amiconn | There's performance estimation by counting in the debug menu for PP targets as well, although in another debug menu item |
09:17:10 | Zagor | aha, I haven't seen that |
09:17:13 | amiconn | I wonder whether this should be put into the CPU Frequency debug screen, and enabled for other targets |
09:17:41 | Zagor | yeah maybe |
09:17:48 | amiconn | That one even forbids interrupts for a short period in order to get stable readings (causes a little audio glitch due to this) |
09:19:33 | amiconn | Otoh we could do the opposite, and do away with some debug menu stuff in favour of plugins |
09:19:47 | amiconn | *test* plugins |
09:22:04 | | Quit BHSPitLappy (Remote closed the connection) |
09:22:38 | Unhelpful | amiconn: as in, not-built-by-default test plugins? what about having a "debug" category for plugins, and perhaps even displaying such things under the debug menu? |
09:23:08 | | Join crwl [0] (n=crawlie@a91-154-18-71.elisa-laajakaista.fi) |
09:23:13 | linuxstb | Shouldn't test_boost be added to plugins/CATEGORIES? |
09:23:28 | * | B4gder likes the debug plugin category idea |
09:25:41 | jhMikeS | call them deblugins? |
09:25:56 | * | B4gder looks at jhMikeS in silence |
09:27:00 | jhMikeS | :D |
09:28:57 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
09:29:31 | | Quit advlaptop2019 ("Leaving") |
09:30:02 | Unhelpful | jhMikeS: didn't you write align_buffer? do you have any idea if mpegplayer cares about it aligning the end of the buffer? i know that pictureflow and resize.c don't care |
09:30:15 | | Quit advcomp2019 (Nick collision from services.) |
09:30:18 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
09:32:39 | | Quit kachna (Read error: 60 (Operation timed out)) |
09:32:54 | jhMikeS | Unhelpful: It does to ward off cache alignment issues |
09:34:26 | Unhelpful | would it be worth cache aligning the 3 rows of extended-precision pixels that the scalers use? |
09:34:57 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
09:35:05 | jhMikeS | If 16-byte alignment would reduce the number of misses it might |
09:35:36 | kugel | Zagor: I got the codecs in iram working, I updated the sansaV2 page with my findings |
09:36:36 | Unhelpful | well, generally the scalers are scanning though one of those lines, or several of them, from start to finish, in parallel |
09:37:18 | Zagor | kugel: "Not only that playback doesn't actually work when codecs are in SDRAM" <−− but it does. it's just very slow. |
09:37:31 | Zagor | apart from mp3 then :-) |
09:37:57 | B4gder | the entire codecs are in iram? |
09:38:05 | jhMikeS | It could eliminate a load for each row |
09:38:05 | Zagor | B4gder: on clip yes |
09:38:08 | B4gder | wow |
09:38:21 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
09:38:36 | Zagor | B4gder: but that also makes it not support all codecs |
09:38:39 | JdGordon | who knows hwcodec mpeg.c the most? |
09:38:43 | B4gder | ah, right |
09:39:08 | B4gder | JdGordon: I would guess perhaps linusn |
09:39:10 | | Quit kugel (Remote closed the connection) |
09:39:31 | JdGordon | ok, ill try to figure this out myself untill he pops in |
09:40:21 | Unhelpful | at the cost of increasing the size needed for scaling by a little bit... this would mostly hit stuff that uses a fixed-size buffer to load scaled bitmaps, since the macro that calculates the size would get a bit more complicated, and of course would request larger buffers. |
09:41:07 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
09:41:16 | jhMikeS | Unhelpful: A planar version for the thumbnailer would be nice in mpegplayer. You have both buffers in RAM so it should be simple. |
09:41:45 | kugel | Zagor: well, aac doesn't work, ogg doesn't really work too (for some of my oggs) |
09:41:55 | kugel | but indeed, "not working" is slightly wrong |
09:43:32 | Unhelpful | if you mean to use it to scale video, i suspect you'd want to trade off some accuracy for more speed. that said, if it's built without HAVE_LCD_COLOR defined, you already get a scaler for 8-bit unsigned single-channel data |
09:44:14 | jhMikeS | Unhelpful: Not for the playback but the previewing so it's not super speed critical. |
09:45:38 | * | JdGordon would really really like a hwcodec target.. or failing that.. a tester... |
09:45:46 | | Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) |
09:46:05 | Unhelpful | i didn't even know there was a preview mode... you might be descending into #ifdef hell if you wanted to get the greyscale scaler built in pluginlib on a color target, but it would certainly be possible. |
09:47:51 | jhMikeS | It's done YUV420->YUV420 so all channels are separated. It uses brensenham already but only nearest-neighbor. |
09:50:29 | Unhelpful | are the channels unsigned? a signed version of the scaler would be possible... but add a lot more mess. |
09:56:16 | | Quit kugel (Remote closed the connection) |
09:56:31 | | Join GarrettW [0] (i=garrettw@h61.19.255.206.cable.lngv.cablelynx.com) |
10:00 |
10:01:00 | JdGordon | would anyone object to a new "rule" for the sim that no printf/debugf's get into svn unless they can are disabled by default? |
10:02:02 | lucent | too verbose? |
10:02:04 | B4gder | seems reasonable |
10:02:46 | Zagor | JdGordon: aye |
10:02:56 | | Join grndslm [0] (n=grndslm@24-119-80-142.cpe.cableone.net) |
10:05:05 | | Nick Barahir_ is now known as Barahir (n=jonathan@Xa764.x.pppool.de) |
10:11:12 | | Part Severian ("Leaving") |
10:13:18 | Zagor | fuze and clip have very different CPU_FREQ defines: 75MHz vs 250MHz |
10:20:30 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
10:23:08 | Unhelpful | jhMikeS: come to think of it... are you dealing in whole images, already in memory, when you talk about scaling in mpegplayer for previews? it might be more worthwhile to adapt resize.c than to try to use it as-is. |
10:23:46 | Unhelpful | it's callback-orient, and designed around only having access to part of the source image. it could be a good deal simpler if it were just scaling a region already in memory. |
10:28:12 | Zagor | anyone yearning to calculade sdram timings? |
10:28:32 | | Quit Thundercloud (Remote closed the connection) |
10:30:04 | Zagor | I'm not happy about system-as3525.c only setting things up in the bootloader |
10:31:42 | Zagor | I can sympathize with not wanting to reinit lcd in the app, but pretty much everything else should be done. otherwise we have to upgrade bootloaders as soon as we improve something |
10:32:24 | Zagor | I also don't see why system_init() should set the cpu to idle frequency |
10:32:53 | Zagor | and we should rename CPUFREQ_DEFAULT to CPUFREQ_IDLE to make it clearer what it means |
10:32:53 | jhMikeS | Unhelpful: Yes, whole images in src and dest |
10:33:06 | * | Unhelpful notices something rather odd linked from the build table: http://build.rockbox.org/cvsmod/chlog-20090113T173618Z.html |
10:33:27 | jhMikeS | Zagor: I agree. What's so "default" about it? I found it unclear at first. |
10:33:28 | B4gder | Unhelpful: that's how it looks when the build has been restarted |
10:33:32 | B4gder | manually, or automatically |
10:33:39 | B4gder | it's a little flaw in the scripting |
10:34:28 | B4gder | mr someone will fix that eventually! |
10:34:57 | Unhelpful | jhMikeS: i suggest, perhaps, copying resize.c with a new filename, and editing. you'll want the greyscale versions of things, and you'll want to just read direct from lines in source, without all that nonsense about fetching image chunks... |
10:36:07 | Unhelpful | B4gder: ahhh.. ok, that explains it. before i noticed that it had from/to the same revision, i wondered what i'd done wrong with the commit. |
10:36:49 | | Part GarrettW |
10:42:01 | * | jhMikeS thinks it a bit odd that bitmap related items would still be hanging out in /apps/recorder |
10:44:01 | | Part linuxstb ("Leaving") |
10:45:32 | * | Zagor adds sdram datasheet links to SansaFuze |
10:48:57 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
10:50:09 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
10:50:48 | | Quit EspeonEefi ("ã•よãªã‚‰") |
10:54:47 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:05:10 | | Quit GodEater_ ("http://www.mibbit.com ajax IRC Client") |
11:05:22 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
11:05:52 | gevaerts | pre-last-bugfix c200 build dependencies at http://files.hostname.be/scaled.png |
11:06:47 | * | B4gder has no comments |
11:08:19 | | Join gartral [0] (n=Gartral@75.33.65.127) |
11:08:27 | gartral | morning all |
11:10:20 | | Join kachna [0] (n=kachna@r3g248.net.upc.cz) |
11:12:07 | | Join BigBambi [0] (i=86ceaf37@rockbox/staff/BigBambi) |
11:15:11 | Zagor | I also think it would be a good idea to have a CPUFREQ_BOOST different from CPUFREQ_MAX. _BOOST would then be the highest no-pll, no-voltage-change speed and _MAX the pull-all-stops maximum performance possible |
11:15:33 | | Part gartral |
11:15:57 | Zagor | as I understand it mpegplayer is the only thing that really needs every MHz we can give it |
11:16:11 | * | JdGordon offers a special prize to anyone who tests 9795 on hwcodec |
11:18:19 | amiconn | Zagor: APE codec is another one, and iirc one of the nonstreaming codecs also needs every possible bit of performance |
11:18:20 | JdGordon | of course the other option is commiting once its bug free on swcodec and fixing hwcodec bugs afterwards.... |
11:18:46 | Zagor | amiconn: they run 100% boosted? |
11:19:46 | Zagor | anyway, anything that reallly needs all power is going to want to run at max speed constantly. and in those cases PLL delay is not a concern since we won't be switching speeds a lot |
11:20:23 | B4gder | we need full, high and super speed! |
11:20:25 | amiconn | No, but they definitely want to boost to max. on demand, not to some artifically limited frequency |
11:20:28 | Zagor | warp! |
11:21:10 | Unhelpful | cpu_to_plaid(bool enable) |
11:21:38 | Zagor | amiconn: either they need all the power, or they don't. I doubt any of our code"wants" anything. |
11:22:53 | Zagor | if normal boosting is not enough, toggling a max boost on and off (which may be only a few percent faster) is not going to be enough |
11:23:36 | amiconn | Did you see my suggested clock frequencies for coldfire? |
11:23:47 | Zagor | no, where did you put them? |
11:25:39 | amiconn | In here... |
11:25:57 | * | amiconn wonders whether Zagor ever checks his backlogs for pings |
11:26:25 | Zagor | we could even have dual levels of boost. quick boost used in the code around parts that need speedup, and longer "max" boosts around whole "tasks" that need lots of power. |
11:27:05 | Zagor | you know I do |
11:27:07 | kugel | Zagor: I suggest multple "performance levels" too some time ago, but it didn |
11:27:13 | kugel | it didn't seem to be liked |
11:27:15 | amiconn | Imho that would be unnecessarily complex on targets with fixed voltage |
11:28:00 | Zagor | amiconn: so what do you want? stay with the current slow pll system? |
11:28:45 | JdGordon | kugel: got a min to test out 9795 on your targets? |
11:29:08 | Zagor | kugel: I don't think it's a very nice option either. but it is an option. |
11:29:55 | | Quit kugel (Remote closed the connection) |
11:36:36 | JdGordon | shouldnt the on/play button on the h300 always jump to the wps like on the e200? |
11:51:42 | | Quit japc (Read error: 110 (Connection timed out)) |
11:59:18 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
12:00 |
12:06:29 | | Quit timc`` (Read error: 145 (Connection timed out)) |
12:07:32 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
12:16:40 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
12:21:18 | | Join fyrestorm [0] (n=fyre@cpe-68-173-235-77.nyc.res.rr.com) |
12:31:30 | Zagor | ape insane looks useful. 2.48% realtime on H10... |
12:32:44 | B4gder | we should drop all other codecs than ape |
12:33:56 | Zagor | Decode time - 10519.85s. no wonder people don't bother testing it. |
12:35:22 | Zagor | if someone wants to contribute but can't code, generating and uploading the sample set for CodecPerformanceComparison would be useful. |
12:38:44 | Zagor | amiconn: I think 30MHz is too high for normal freq |
12:39:31 | Zagor | unless we *only* do the clkdiv change, and don't to boost optimising. |
12:40:38 | Zagor | with "boost reform", I want as high boost and as low normal as possible |
12:41:41 | Zagor | and btw, your frequency suggestion line didn't ping me because you didn't write my nick. |
12:48:38 | | Part moos ("Rockbox rules the DAP world") |
12:48:55 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
12:54:48 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:05:13 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
13:05:53 | kugel | JdGordon: sure |
13:06:01 | JdGordon | thanks |
13:07:58 | JdGordon | well the hwcodec sim is useless.... This is definetly looking like post commit fixes :/ |
13:08:42 | pixelma | JdGordon: which patch is that? Might try later |
13:09:36 | JdGordon | 9795, very minor change to hwcodec, but need to make sure it still works... look out to make sure next track gets updated and no crazy id3 info... |
13:11:52 | kugel | JdGordon: a damnit, I don't have the cables with me :/ |
13:12:09 | kugel | but I'll test and post to the tracker |
13:12:35 | JdGordon | :) ok |
13:13:50 | pixelma | JdGordon: next track info is a bit harder to test on hwcodec as this is only available when the next track is already buffered (usually happens during the last 1-1.5 minutesof the now playing track and the there is this thing about updating dynamic content. The way of forcing updates with sublines in my WPS works quite well though |
13:14:30 | JdGordon | pixelma: yeah, but as long as its getting updated its enough to say its working |
13:14:59 | JdGordon | with that patch the wps will only do a full redraw when the new track starts or when the next track id3 info is avilaable |
13:16:18 | pixelma | aha |
13:16:59 | Zagor | from system-pp502x.c: PLL_CONTROL = 0x8a121403; /* 80 MHz = (20/3 * 24MHz) / 2 */ |
13:17:20 | Zagor | but 20/3*24/2 = 72 |
13:18:06 | BigBambi | (20/3)*24 = 160 |
13:18:12 | BigBambi | 160/2 = 80 |
13:18:15 | pixelma | Zagor: you sure? |
13:19:05 | Zagor | meh, bc fooled me with rounding errors. :-( |
13:19:12 | B4gder | scale=3 |
13:19:13 | B4gder | :-) |
13:19:15 | Zagor | indeed |
13:19:28 | B4gder | or bc -l |
13:19:45 | Zagor | anyway, do we have any kind of bit description for the PLL_CONTROL register? |
13:20:10 | Zagor | someone seems to have it at least, judging from the code comment. saratoga? |
13:20:23 | pixelma | if you only rely on technics |
13:21:23 | Zagor | pixelma: ? |
13:21:28 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
13:24:16 | | Quit kugel (Remote closed the connection) |
13:28:58 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
13:29:58 | Zagor | actually most of the bits are deductible from the comments |
13:30:39 | Zagor | it feels good having to RE our own code... :) |
13:39:53 | | Quit AndyIL (Read error: 110 (Connection timed out)) |
13:42:38 | | Quit gromit`` (niven.freenode.net irc.freenode.net) |
13:42:38 | NSplit | niven.freenode.net irc.freenode.net |
13:42:38 | | Quit jfc (niven.freenode.net irc.freenode.net) |
13:42:38 | | Quit preglow (niven.freenode.net irc.freenode.net) |
13:42:38 | | Quit Zambezi (niven.freenode.net irc.freenode.net) |
13:45:03 | NHeal | niven.freenode.net irc.freenode.net |
13:45:03 | NJoin | gromit`` [0] (n=gromit@ALagny-154-1-6-203.w83-112.abo.wanadoo.fr) |
13:45:03 | NJoin | jfc [0] (n=john@dpc691978010.direcpc.com) |
13:45:03 | NJoin | preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) |
13:45:03 | NJoin | Zambezi [0] (i=stolgfor@91.205.60.130) |
13:48:49 | | Join lasser [0] (n=chatzill@Wace4.w.pppool.de) |
13:51:16 | Zagor | "The PP5022 PLL must be run at >= 96MHz" <−− but aren't we running it at 24 MHz? /* 30 MHz = (5/1 * 24MHz) / 4 */ |
13:52:10 | Zagor | or what clock does "run at" refer to? |
13:53:16 | | Quit culture (Read error: 60 (Operation timed out)) |
13:53:36 | | Join PaulJam [0] (n=PaulJam_@vpn-3089.gwdg.de) |
14:00 |
14:02:30 | | Join TheSphinX^ [0] (n=cold@p54A5C0AE.dip.t-dialin.net) |
14:07:35 | robin0800 | just updated sansa c240 to 19770 connect to charger rockbox tries to load usb symbol appears and player reboots |
14:08:14 | * | gevaerts blames jhMikeS :) |
14:08:19 | JdGordon | are we going to need to roll out new sansa bootloaders to fix this? |
14:08:30 | JdGordon | e200 has the same issue apparently |
14:08:45 | gevaerts | No. Bootloaders have nothing to do with this |
14:09:31 | gevaerts | jhMikeS: I now remember that this is actually why the old code didn't reboot before enumeration. That way you could easily distinguish between a charger and a PC |
14:11:28 | | Quit XavierGr () |
14:11:56 | amiconn | Zagor: The VCO of the PP5022 PLL needs to be run at >=96MHz. That's why 80 MHz runs it at 160, and post-divides by 2 |
14:12:11 | Zagor | ah, ok. thanks. |
14:12:19 | amiconn | I have some documentation of the PP clock control that I wanted to put in the wiki for ages... |
14:12:49 | Zagor | that would be great. there are some bits I haven't figured out yet. |
14:13:36 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
14:19:25 | | Join japc [0] (n=japc@194.65.5.235) |
14:24:55 | Zagor | jhMikeS: what is the purpose of scale_suspend_core()? |
14:25:58 | jhMikeS | Zagor: I'll have to look again |
14:26:25 | jhMikeS | Zagor: Ah, right. It prevents memory corruption by stalling the other core. |
14:26:51 | jhMikeS | It will data abort and other nasty things otherwise |
14:27:45 | jhMikeS | gevaerts: I didn't have trouble connecting for charging when I was working on things. |
14:28:17 | gevaerts | jhMikeS: connecting in what way? To a PC or to a standalone charger? |
14:29:24 | Zagor | jhMikeS: what causes this corruption? |
14:30:20 | jhMikeS | gevaerts: I only have a PC available, no standalone. Perhaps I should look at that then. |
14:31:18 | gevaerts | jhMikeS: that's it then. A standalone charger gets detected as a connection but doesn't do anything on the bus. Waiting for the first real packet is a good way (and the only way I can think of) to distinguish them |
14:31:30 | jhMikeS | Zagor: I don't know why it's needed from a hardware perspective but it's needed. The OF does this stalling trick as well. |
14:31:40 | Zagor | jhMikeS: ok |
14:33:36 | amiconn | The apple firmware doesn't seem to do this, btw |
14:33:58 | amiconn | (or maybe I overlooked it...) |
14:34:37 | robin0800 | amiconn: apples don't charge in rockbox yet? |
14:34:40 | jhMikeS | amiconn: It blows up pretty quickly on PP5020 without it. The 5024 seems more resistant or they fixed the issue. |
14:36:12 | | Quit advcomp2019 (Read error: 110 (Connection timed out)) |
14:37:09 | jhMikeS | gevaerts: Makes sense. I neglected to consider that problem. This problem ends up in a somewhat circular dependency. |
14:38:39 | gevaerts | jhMikeS: on the other hand, targets without any usb code at all (like the AMS sansa) are probably better off with the new behaviour |
14:38:41 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
14:41:10 | | Part B4gder |
14:41:13 | jhMikeS | All I know is things behaved badly on Windows and the stack would be unusable until reboot if some threads didn't ack. It matches how the targets without a stack behave. |
14:45:49 | | Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-cba0f2de3ea4c3e0) |
14:46:00 | jhMikeS | OF doesn't require special actions with a plain charger? |
14:48:25 | robin0800 | jhMikeS: were looking to charge and play in rockbox? |
14:49:29 | jhMikeS | robin0800: I know how to avoid a USB connection. It's another issue that seems a bit tough to get a good solution for. |
14:50:30 | robin0800 | jhMikeS: is it easier to do this in the bootloader check for computer or charger or nothing? |
14:52:10 | jhMikeS | gevaerts: I wonder if the OTGMIRROR register will tell anything (if it can be polled for anything meaningful). |
14:52:55 | jhMikeS | robin0800: Not really. It makes sense to find a solution in the firmware. |
14:54:52 | *** | Saving seen data "./dancer.seen" |
14:56:21 | Zagor | amiconn, jhMikeS: why are we using different PLL settings for 80 MHz on PP5020? does its' PLL_CONTROL register differ from PP5024? |
14:56:47 | Zagor | (10/3 * 24) vs (20/3 * 24 / 2) |
15:00 |
15:00:36 | jhMikeS | Zagor: Ask Buschel about that one. |
15:00:57 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-641c7a6af039c893) |
15:01:49 | * | jhMikeS seems to recall him being the one that last worked heavily on clocking |
15:02:30 | Zagor | ok |
15:08:10 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
15:09:44 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-c9333a3439abb47c) |
15:10:31 | saratoga | kugel: the cache control is standard arm922 stuff, so its not in the AMS datasheets, but is in the ARM ones: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0184b/DDI0184.pdf |
15:10:52 | saratoga | CP15 is a "coprocessor" on that ARM9 chip that handles cache + MMU |
15:11:02 | saratoga | we set it during bootup, but maybe not correctly |
15:11:49 | saratoga | you can read/set it with coprocessor instructions like MCR/MRC |
15:14:10 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
15:15:18 | gevaerts | jhMikeS: I wouldn't count too much on OTGMIRROR |
15:16:02 | Zagor | saratoga: we should set it up in the application init too |
15:16:53 | amiconn | Zagor: Yes PP5020 and 5022(5024) are different |
15:17:29 | | Join Schmogel [0] (n=Miranda@essn-4db6d9f1.pool.einsundeins.de) |
15:17:34 | amiconn | PP5020 doesn't have the lock indicator bit and the post divider. It also doesn't require running the PLL at >=96MHz |
15:19:25 | Zagor | ah right, no postdiv |
15:22:20 | jhMikeS | gevaerts: What's the problem there? |
15:24:12 | amiconn | In turn, PP5020 needs the >66MHz unlocking (similar to PP5002) |
15:24:53 | gevaerts | jhMikeS: not sure. It may work, but the problem I see is that while we know that a dumb charger will provide 5V, we don't know anything else about it, so I fear that there could be lots of false positives. Also, for targets that don't do OTG we don't know much about the PHY |
15:25:04 | saratoga | Zagor: system_init sets it in the bootloader, so maybe i'm just not reading it properly |
15:26:06 | Zagor | saratoga: yes, I mean we should change that so it doesn't only do it in bootloader |
15:26:25 | Zagor | to avoid having to upgrade the bootloader if/when we improve things in this area |
15:28:17 | Zagor | amiconn: does that mean we always have to wait for PLL on 5020? |
15:33:07 | jhMikeS | gevaerts: That looks like it's meant to tell the hardware the status of a non-standard PHY anyway. |
15:44:01 | pixelma | LambdaCalculus37: IIRC, puntuation closes these button macros too, so you don't need the {} if a comma, period or else follows. You'll only notice them missing if a space follows them as that would be eaten. |
15:44:42 | pixelma | can't find where I read this at the moment but am quite sure |
15:47:26 | LambdaCalculus37 | pixelma: I'll take your word for it, but I closed the button macros like that mostly for consistency's sake. |
15:48:12 | LambdaCalculus37 | I had also found one button macro that was closed with a () instead of a {} in the H10 manual, so I fixed that. |
15:49:22 | jhMikeS | gevaerts: what about the port status bits in PORTSC1? |
15:49:39 | jhMikeS | err *Line Status |
15:50:24 | jhMikeS | It seems to respond properly |
15:51:29 | * | LambdaCalculus37 remembers that he should've also changed the title of the Gigabeat F manual to read "Gigabeat F and X" |
15:51:47 | pixelma | LambdaCalculus37: I also meant punctuation... I'm trying to remember now if having the {} before punctuation means that LaTeX is now allowed to break the line between the button label and the punctuation. Better ask bluebrother when he's around |
15:52:34 | | Nick ender1 is now known as ender` (i=krneki@foo.eternallybored.org) |
15:52:58 | LambdaCalculus37 | pixelma: I'll ask him. |
15:54:18 | gevaerts | jhMikeS: line status may be useful, but I'm not sure how exactly to interpret the data from it. You need the usb 2.0 spec chapter 7 for help. |
15:54:53 | amiconn | Zagor: On PP I'd just switch clock sources between PLL and 24MHz for instant boosting |
15:54:56 | jhMikeS | It seems to be in SE0 state until I unplug the cable. I just checked with the while loop |
15:55:22 | amiconn | That means we're limited to 24MHz for unboosted though |
15:55:54 | * | jhMikeS now goes to the spec since this seems like a simple way to probe it |
15:56:06 | Zagor | unless we feed the PLL with 16MHz |
15:56:21 | amiconn | We can't |
15:56:38 | Zagor | how come? |
15:57:14 | amiconn | We only have a 24MHz source |
15:57:48 | Zagor | ok, so the CLOCK_SOURCE register can't really use all the options in the comment? |
15:58:42 | gevaerts | jhMikeS: maybe you could also intercept bus reset (see usb-drv-arc.c, bus_reset()). If that works, I'm a bit more confident that we're doing things properly |
15:59:26 | amiconn | No. It can only use the sources which are actually connected |
16:00 |
16:03:39 | jhMikeS | gevaerts: Why is reading the disconnect condition possibly improper? |
16:07:23 | Zagor | amiconn: please post your docs in twiki as soon as you can. |
16:09:30 | | Quit lasser ("ChatZilla 0.9.84 [Iceweasel 3.0.5/2008122011]") |
16:09:37 | jhMikeS | gevaerts: SE0 is the HUB driving the reset condition, correct? |
16:15:41 | | Join MethoS [0] (n=lem@host-091-097-244-073.ewe-ip-backbone.de) |
16:23:35 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-63299e776e7532fb) |
16:26:45 | | Quit kachna (Read error: 113 (No route to host)) |
16:35:29 | | Join flydutch [0] (n=flydutch@host72-163-dynamic.14-87-r.retail.telecomitalia.it) |
16:41:43 | gevaerts | jhMikeS: yes |
16:51:13 | jhMikeS | Setting up to look at the interrupt doesnt' seem to work too nicely. PORTSCX however shows the state without even going to RUN mode. |
16:52:59 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
16:54:53 | *** | Saving seen data "./dancer.seen" |
16:56:51 | | Join {phoenix} [0] (n=dirk@p54B4794A.dip.t-dialin.net) |
16:57:00 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) |
16:59:24 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
17:00 |
17:06:37 | | Quit Zagor ("Client exiting") |
17:06:59 | kugel | wow |
17:07:10 | kugel | he exits just as I want to ping him |
17:08:34 | LambdaCalculus37 | kugel: He knew you were coming. :P |
17:08:40 | * | LambdaCalculus37 runs |
17:11:03 | LambdaCalculus37 | jhMikeS: Ping |
17:16:17 | kugel | saratoga: I'm looking at this data sheet now. What do you think we're missing? What have you already tried? |
17:17:24 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
17:18:53 | | Part LinusN |
17:22:41 | | Quit robin0800 (Remote closed the connection) |
17:22:46 | | Quit Horscht ("I am root. If you see me laughing, you better have a backup") |
17:26:24 | | Join goffa_ [0] (n=goffa@216.220.23.105) |
17:28:33 | | Part josch |
17:34:59 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
17:35:07 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
17:35:51 | | Join tim__ [0] (n=aoeu@124.93.243.83) |
17:36:55 | | Quit timc`` (Read error: 104 (Connection reset by peer)) |
17:38:49 | | Quit goffa (Read error: 110 (Connection timed out)) |
17:40:09 | | Join m0f0x [0] (n=m0f0x@189-47-44-65.dsl.telesp.net.br) |
17:43:47 | | Join LambdaCalculus3_ [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-bf0239822b71cb74) |
17:43:57 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
17:45:07 | jhMikeS | LambdaCalculus37: here |
17:46:04 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
17:46:12 | | Nick LambdaCalculus3_ is now known as LambdaCalculus37 (i=44a04303@gateway/web/ajax/mibbit.com/x-bf0239822b71cb74) |
17:47:10 | LambdaCalculus37 | jhMikeS: I noticed a dithering option in Mpegplayer on the Gigabeat F. Any reason why this can't be enabled for the beast as well? |
17:47:42 | jhMikeS | LambdaCalculus37: None at all. I guess it just hadn't been done. |
17:48:17 | Llorean | Dithering certainly looks nicer on the F. |
17:48:31 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
17:49:52 | LambdaCalculus37 | Llorean: Would look nice on the S as well. Currently video playback is rather splotchy-looking. |
17:52:37 | | Quit thegeek_ (Read error: 104 (Connection reset by peer)) |
17:53:34 | | Quit BigBambi ("http://www.mibbit.com ajax IRC Client") |
17:55:06 | | Quit thegeek (Read error: 113 (No route to host)) |
17:56:59 | Llorean | I don't know much about image processing. Doesn't the Gigabeat S have a higher depth screen? Can we take advantage of that (either along with, or instead of, dithering) as another option? |
17:58:42 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
17:59:31 | Llorean | Or is the dithering there because we were stuck on lower bit-depth screens before? |
18:00 |
18:00:14 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
18:01:07 | LambdaCalculus37 | Llorean: The S is the same resolution as the F (240x320), but the screen is a little larger. |
18:01:12 | | Quit fyrestorm ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
18:01:29 | LambdaCalculus37 | IIRC the color depth is the same. |
18:01:52 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
18:01:52 | Llorean | LambdaCalculus37: I'm aware the resolution is the same. I do have both. :) |
18:02:11 | Llorean | But i thought it was higher color depth. |
18:03:31 | Llorean | I could be thinking of the D2 maybe. |
18:03:59 | pixelma | maybe the Fuze? |
18:04:23 | Llorean | Not the Fuze. This was before V2 Sansas were progressing at all. |
18:04:42 | Llorean | And it's one of the players I have. So it's either the S or the D2. But I could've also just misread / been misinformed. |
18:04:48 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
18:05:09 | | Quit petur ("work->home") |
18:06:40 | Llorean | Looks like I was thinking of the D2 |
18:06:41 | | Join saratoga_lab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-5b1da023c280c156) |
18:06:44 | Llorean | 24-bit color there. |
18:07:24 | | Quit moos ("Rockbox rules the DAP world") |
18:08:11 | LambdaCalculus37 | Llorean: And most of the other color targets are 16-bit color, correct? |
18:08:16 | Llorean | Yes |
18:08:25 | Llorean | In fact I believe almost all of them are. |
18:08:37 | LambdaCalculus37 | I think it was the X5 that wasn't; 18-bit color dithered down to 16-bit, IIRC. |
18:08:38 | saratoga_lab | i just noticed that the ffmpeg people seem to be nearly finished with their WMA Pro decoder |
18:08:39 | Llorean | Memory suggests to me one might be 18-bit and we're running it at 16-bit, but I'm not certain. |
18:08:45 | saratoga_lab | perhaps we can have one soon too |
18:09:08 | LambdaCalculus37 | saratoga_lab: :) |
18:09:10 | Llorean | The more audio codecs the better, in my book |
18:09:25 | LambdaCalculus37 | Llorean: Even the obscure ones? ;) |
18:10:39 | domonoky | LambdaCalculus37: yes, those too :-) rockbox should play everything .. |
18:11:07 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
18:13:29 | kugel | jhMikeS: any idea what would be against using arm_mmu.c code for as3525? |
18:13:58 | LambdaCalculus37 | Domonoky: And I'm talking "obscure as hell" codecs... TwinVQ, for example. |
18:14:05 | LambdaCalculus37 | http://en.wikipedia.org/wiki/TwinVQ |
18:14:41 | kugel | also, do you have an idea if arm922t needs special handling, or can it code of existing targets (I assume the imx31l doesn't fit, but maybe the "generic"?)? |
18:14:57 | domonoky | LambdaCalculus37: if we can get them to run, why not ? |
18:15:09 | | Join Lear [0] (n=chatzill@rockbox/developer/lear) |
18:15:57 | * | gevaerts would draw the line at codecs for which no sample file and no encoder can be found |
18:16:16 | LambdaCalculus37 | domonoky: I used to have music encoded in that format years ago. Sadly, it's all gone now, and I think that only xmms and Winamp are the only players that can still play it. |
18:16:27 | LambdaCalculus37 | gevaerts: There is some information on TwinVQ on the Wikipedia page. |
18:17:01 | | Quit dfkt (Read error: 60 (Operation timed out)) |
18:17:24 | * | domonoky thinks that without samples and encoder it gets hard to test the decoder.. :-) |
18:17:35 | | Join red0nkulous [0] (n=redonkul@mail.prestigeengineering.com) |
18:17:38 | gevaerts | exactly :) |
18:18:01 | * | LambdaCalculus37 could whip up samples with this: http://www.fairstars.com/cdripper/index.htm |
18:18:31 | saratoga_lab | ffmpeg certainly hides their SOC projects well |
18:18:37 | saratoga_lab | still haven't found the SVN for it |
18:19:38 | | Join DerDome [0] (n=DerDome@dslb-082-083-254-169.pools.arcor-ip.net) |
18:19:38 | LambdaCalculus37 | saratoga_lab: Has ffmpeg ever worked on WMA Lossless, or is planning on it? |
18:19:53 | saratoga_lab | I don't think anyone looked at WMA lossless |
18:21:31 | saratoga_lab | ah here we go http://svn.mplayerhq.hu/soc/wmapro/ |
18:22:14 | kugel | jhMikeS: what does memory_init() do for gigabeats? I never see it being called |
18:22:43 | | Join BdN3504 [0] (n=55b2234c@gateway/web/cgi-irc/labb.contactor.se/x-98f4b6fdb61b999f) |
18:23:02 | Llorean | saratoga_lab: wmapro files (to a user) usually just look like wma still, right? They're still wma extension, and the normal user won't know they're different? |
18:23:40 | | Quit tim__ (Read error: 54 (Connection reset by peer)) |
18:23:50 | | Join tim__ [0] (n=aoeu@124.93.243.83) |
18:23:57 | BdN3504 | hey guys! I already posted a question over a year ago in this thread: http://forums.rockbox.org/index.php?topic=9194.msg102782#msg102782 and now i got a second gigabeat dock and i want to get that usb jack on the side going. |
18:24:38 | Llorean | BdN3504: Hardware modifications to accessories don't really belong here. |
18:24:50 | BdN3504 | ooh, so where do i go then? |
18:25:24 | gevaerts | BdN3504: IIRC the gigabeat F host is OHCI, so you should be able to write a driver easily ;) |
18:26:08 | | Join tvelocity [0] (n=tony@adsl17-88.her.forthnet.gr) |
18:28:44 | BdN3504 | hm, in that thread i was told i would have to rewire the device, now i've taken it apart and the only thing that has surfaced is a pcb which i don't know wha to do with at all... |
18:29:19 | Llorean | BdN3504: I already told you that the hardware work is off-topic here... |
18:29:37 | BdN3504 | well then, tell me where this belongs... |
18:29:48 | Llorean | I don't know where it belongs. |
18:30:03 | BdN3504 | hm then i'll just bump that thread again |
18:30:10 | Llorean | It doesn't really belong there either. |
18:30:28 | Llorean | The software work, sure. But modifying the hardware, that's something for a Gigabeat community somewhere. |
18:32:10 | Llorean | Oh, and since it's the pc you want talking with it, none of it has anything to do with Rockbox at all |
18:32:22 | saratoga_lab | Llorean: yeah they just look like normal wma files |
18:32:33 | saratoga_lab | though they're rare enough that people seldom mix them by accident |
18:32:38 | Llorean | Gotcha |
18:34:21 | | Quit nuonguy ("This computer has gone to sleep") |
18:34:24 | | Quit TheSphinX^ ("XChat@Linux") |
18:34:32 | | Quit evilnick (Read error: 54 (Connection reset by peer)) |
18:35:40 | | Quit mcuelenaere (Read error: 113 (No route to host)) |
18:35:40 | | Quit BdN3504 ("CGI:IRC (EOF)") |
18:36:20 | jhMikeS | kugel: 1) I don't know enough about as3525 to say. 2) memory_init is doing nothing for gigabeat S atm. |
18:37:27 | kugel | jhMikeS: same for fx it seems. |
18:37:50 | kugel | as3525 seems to match with the non-imx code |
18:40:01 | | Nick dfkt_dt is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
18:40:40 | jhMikeS | FX does it all in crt0.S |
18:40:58 | jhMikeS | I think it calls memory_init from there |
18:41:11 | | Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) |
18:41:46 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
18:43:30 | | Join PaulJam_ [0] (n=PaulJam_@vpn-3019.gwdg.de) |
18:47:53 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
18:48:20 | | Quit dfkt (Nick collision from services.) |
18:48:28 | | Nick dfkt_dt is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
18:48:46 | | Join tessarakt [0] (n=jens@e180075174.adsl.alicedsl.de) |
18:48:51 | | Quit PaulJam (Nick collision from services.) |
18:48:56 | | Nick PaulJam_ is now known as PaulJam (n=PaulJam_@vpn-3019.gwdg.de) |
18:51:04 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:53:00 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
18:54:54 | *** | Saving seen data "./dancer.seen" |
18:57:42 | kugel | jhMikeS: hm, I grepped |
18:58:23 | kugel | saratoga_lab: actually, yes, we enable I and DCache |
18:58:31 | kugel | but not the MMU |
19:00 |
19:02:11 | saratoga_lab | kugel: ok then i must have done something wrong when i read out the values |
19:02:49 | kugel | the targets having having such stuff to it in a very different way :/ |
19:04:35 | | Quit AndyI () |
19:05:17 | kugel | saratoga_lab: it seems we could use mmu-arm.c. |
19:05:18 | | Quit tim__ (Read error: 110 (Connection timed out)) |
19:05:57 | | Join tim__ [0] (n=aoeu@124.93.243.83) |
19:05:59 | kugel | my fuze doesn't boot though when i call mmu_init() (that one enables caches too) instead of having the using what's already there |
19:06:34 | kugel | now I moved it out of the bootloader at all, and the fuze is much slower than before, so enabling chaches and mmu seems to be too late for the main build |
19:08:02 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
19:09:26 | amiconn | Llorean: X5 is pseudo 18 bit (18 bit transferred to the lcd controller which then dithers to 16 bit internally because the internal memory only holds 16 bit) |
19:09:48 | amiconn | So we decided it's not worth to use 18 bit, but use 16 bit to have better control over dithering |
19:09:54 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-099-242.ewe-ip-backbone.de) |
19:13:11 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
19:15:29 | preglow | can you switch off the hardware dithering? |
19:18:14 | | Quit neddy (Connection timed out) |
19:18:21 | kugel | saratoga_lab: meh, the fuze doesn't want to boot with MMU enabled |
19:19:09 | kugel | maybe it needs to be done in crt0.S too (or even in dual_boot.S?) |
19:20:38 | kugel | there's defintiely something wrong if a 250MHz can hardly code with vorbis |
19:21:11 | kugel | cope* |
19:24:34 | | Join UISim [0] (n=55b2234c@gateway/web/cgi-irc/labb.contactor.se/x-45ee1937ee18fe98) |
19:26:40 | | Quit UISim (Client Quit) |
19:28:45 | saratoga_lab | i don't know much about mmus, but wouldn't booting with one require us to have a page fault handler and all that written? |
19:32:28 | kugel | saratoga_lab: "When the MMU is turned off, as happens on reset, no address mapping occurs and all regions are marked as noncachable and nonbufferable." |
19:32:42 | kugel | doesn't that mean cache is unused without mmu? |
19:34:06 | | Quit grndslm (Remote closed the connection) |
19:34:33 | saratoga_lab | kugel: they probably mean you have to reinistialize the cache after turning off the MMU |
19:34:58 | saratoga_lab | probably has to do with the change betwen physical and virtual addresses in the CPU's memory |
19:38:12 | | Quit tessarakt (Read error: 110 (Connection timed out)) |
19:38:21 | kugel | marked noncachable, that rather reads like caching isn't possible instead of you need to re-enable cache (or invalidate) |
19:39:13 | | Quit Horscht ("electromagnetic radiation from satellite debris") |
19:39:24 | | Quit japc (Read error: 110 (Connection timed out)) |
19:40:11 | | Quit dfkt (Read error: 145 (Connection timed out)) |
19:42:46 | domonoky | perhaps you just need to mark them cacheable again ? |
19:55:52 | amiconn | preglow: That's what we do - switch the controller to 16 bit mode even though it's configured (by pin wiring) for 18 bit mode |
19:56:08 | amiconn | And we do use the pseudo-18 bit mode for video |
19:56:39 | amiconn | The H300 could do true 18 bit - if irver had it configured for this ... :\ |
19:57:14 | | Join FlynDice [0] (n=jack@m160436d0.tmodns.net) |
19:59:38 | | Quit {phoenix} (Remote closed the connection) |
19:59:41 | kugel | domonoky: the mmu is never turned on |
19:59:46 | kugel | and if I do so, the fuze doesn't boot |
20:00 |
20:00:16 | domonoky | kugel: it probably doesnt boot, because you didnt set it up correctly ? |
20:00:44 | | Join mingw [0] (n=55b2234c@gateway/web/cgi-irc/labb.contactor.se/x-f6b3e3092c52a761) |
20:00:57 | amiconn | kugel: Afaik you need the MMU in order to mark regions as cacheable |
20:00:58 | kugel | domonoky: it seems. although I used code that apparently works on all other targets equipped with an mmu |
20:01:14 | amiconn | (on arm implementations using cp15) |
20:01:18 | kugel | amiconn: i assumed that too |
20:01:53 | mingw | hello. i want to make usable ui simulator. for that i need mingw32 installed. i am working with rockbox vmware environment. how do i install mingw32? |
20:02:03 | * | domonoky checked the datasheet a bit, and it really looks like we need to enable the mmu to benefit from the cache. |
20:02:04 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
20:02:12 | | Join culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) |
20:03:28 | kugel | mingw: http://www.rockbox.org/twiki/bin/view/Main/UiSimulator#Building_Windows_sim_in_Linux |
20:03:47 | | Join gregzx [0] (n=chatzill@dsl211.neoplus.adsl.tpnet.pl) |
20:04:26 | mingw | if i run ./configure −−host=i586-mingw32msvc −−prefix=${HOME}/mingw32-sdl i get "your compiler cannot produce win32 executables!" |
20:04:40 | kugel | domonoky: the fx activates the mmu in crt0.S (i.e. very very early), but the creative zvm/m:robe 500 at the end of system_inti() (I don't know if that is even working for the latter ones though) |
20:06:11 | domonoky | kugel: it shouldnt matter when you do the mmu init, aslong as you do it correctly. |
20:06:29 | | Quit tim__ (Read error: 60 (Operation timed out)) |
20:06:38 | kugel | domonoky: I reused mmu-arm.c, and I double checked the code with the datasheet. it doesn't appear wrong to me |
20:06:53 | mingw | ok, i downloaded mingw32-linux-x86-glibc-2.5.tar.gz where do i have to unpack these files? |
20:09:09 | rasher | mingw: you should instead apt-get install mingw32 |
20:09:30 | | Quit tyfoo ("Carpe diem") |
20:10:47 | mingw | 10q. i have dug out an old irc post where all this is explained already. |
20:10:49 | | Quit mingw ("CGI:IRC") |
20:11:00 | | Quit PaulJam (".") |
20:11:59 | | Quit FlynDice () |
20:12:18 | rasher | I wonder why he's not just reading the wiki... |
20:12:24 | rasher | But then he left. |
20:12:44 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
20:14:11 | | Join PaulJam [0] (n=PaulJam_@vpn-3058.gwdg.de) |
20:15:41 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-19e512a9468e2fe5) |
20:16:50 | | Join z35 [0] (n=z35@h162.96.91.75.dynamic.ip.windstream.net) |
20:19:16 | kugel | domonoky, saratoga_lab: 3.9.1 Enabling the MMU seems interesting |
20:22:16 | kugel | wow, if I'd only understand half of it :/ |
20:25:53 | | Join tessarakt [0] (n=jens@e180074066.adsl.alicedsl.de) |
20:26:37 | | Join dfkt [0] (n=dfkt@unaffiliated/dfkt) |
20:30:15 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-1841017940b5b763) |
20:30:40 | | Quit GodEater_ (Remote closed the connection) |
20:30:41 | | Quit LambdaCalculus37 (Remote closed the connection) |
20:30:41 | | Quit evilnick (Read error: 104 (Connection reset by peer)) |
20:31:46 | | Quit gregzx (Read error: 110 (Connection timed out)) |
20:31:47 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
20:33:00 | | Join LambdaCalculus37 [0] (i=44a04303@rockbox/staff/LambdaCalculus37) |
20:33:50 | | Join evilnick_ [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-9a63fd5a4ed5bfb9) |
20:34:47 | | Nick BigBambi is now known as evilnick (n=Alex@rockbox/staff/BigBambi) |
20:34:56 | | Nick evilnick is now known as BigBambi (n=Alex@rockbox/staff/BigBambi) |
20:35:08 | | Nick evilnick_ is now known as evilnick (i=0c140464@gateway/web/ajax/mibbit.com/x-9a63fd5a4ed5bfb9) |
20:36:36 | | Join neddy [0] (n=john@nat/sun/x-8bea604141cdf2e5) |
20:36:58 | | Join tusjen [0] (n=Administ@159.80-202-81.nextgentel.com) |
20:39:01 | * | amiconn is puzzled about r19770 |
20:45:53 | | Part tusjen |
20:48:40 | | Quit timc`` (Connection timed out) |
20:48:59 | kugel | jhMikeS: setting up the mmu appears to be rather similar to gigabeats |
20:49:37 | kugel | 1. Program the TTB and domain access control registers. 2. Program level 1 and level 2 page tables as required. 3. Enable the MMU by setting bit 0 in the control register. |
20:49:58 | kugel | from what I've seen that's the same on gigabeats? |
20:50:11 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
20:51:00 | amiconn | No surprise there |
20:51:45 | amiconn | ARM CP15 is standardized if present. and both S3C2440 and AS3525 are ARM9 (v4) with a CP15 |
20:52:11 | kugel | I didn't know the fx is arm v4 too |
20:52:18 | amiconn | The actual memory areas are probably a bit different though |
20:52:19 | kugel | well, that makes sense then, indeed |
20:52:49 | kugel | doesn't look like. SDRAM is mapped to 0x30000000 too |
20:53:41 | kugel | so, maybe clever c&p from gigabeat fx could do the hob |
20:53:45 | kugel | job |
20:54:49 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
20:54:58 | *** | Saving seen data "./dancer.seen" |
20:57:30 | amiconn | S3C2440 is ARM920T, AS3525 is ARM922T. The only difference is cache size, iirc |
20:57:49 | amiconn | (16K on ARM920T, 8K on ARM922T) |
20:58:33 | | Join PaulJam_ [0] (i=Paule@vpn-3065.gwdg.de) |
21:00 |
21:01:10 | kugel | hm, that sounds good |
21:01:35 | kugel | the datasheet says the only difference is cache, 920T has 16KB I and D |
21:02:26 | amiconn | What is definitely different between the SoCs is amount of IRAM, and probably the register address space(s) |
21:03:02 | amiconn | On gigabeat F/X iram isn't used because it's so small |
21:03:51 | kugel | how big? |
21:04:04 | kugel | I think I didn't pay much attention on that one yet |
21:04:29 | | Join Willwolfe [0] (n=chatzill@net35-14.netkaster.ca) |
21:04:53 | amiconn | Just 4KB iirc - that's smaller than the caches |
21:05:21 | amiconn | On SH1 we do use IRAM even though it's also just 4KB, but then SH1 has no cache at all |
21:05:59 | | Quit Willwolfe (Client Quit) |
21:06:25 | kugel | hm, ok, that's explaining why it's mapping 0x1000 |
21:13:18 | | Quit PaulJam (Read error: 110 (Connection timed out)) |
21:13:55 | | Nick PaulJam_ is now known as PaulJam (i=Paule@vpn-3065.gwdg.de) |
21:14:22 | | Join gregzx [0] (n=chatzill@drz221.neoplus.adsl.tpnet.pl) |
21:15:53 | | Join Jaykay [0] (n=chatzill@p579E7199.dip.t-dialin.net) |
21:17:17 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
21:19:45 | | Join FlynDice [0] (n=jack@m140436d0.tmodns.net) |
21:20:29 | | Nick m0f0x is now known as colesterol_dog (n=m0f0x@189-47-44-65.dsl.telesp.net.br) |
21:22:52 | | Join merbanan [0] (n=banan@83.233.243.20) |
21:29:33 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
21:34:50 | | Quit suom1 (Read error: 104 (Connection reset by peer)) |
21:35:08 | | Nick jhulst is now known as nitroaardvark (n=jhulst@unaffiliated/jhulst) |
21:35:44 | | Nick nitroaardvark is now known as l33tc0d3r (n=jhulst@unaffiliated/jhulst) |
21:35:48 | | Join suom1 [0] (i=markus@2001:4c40:1:0:0:0:0:11) |
21:35:52 | kugel | I believe I have the MMU running |
21:36:12 | | Part l33tc0d3r ("Konversation terminated!") |
21:36:37 | kugel | but the main build doesn't boot anymore, it's hanging in the bootloader, at "Executing" |
21:37:16 | kugel | jhMikeS: ping |
21:52:22 | saratoga | when you say turn on the MMU do you mean just turning on some hardware or do you mean turning on physical -> virtual address translation? |
21:52:38 | | Quit merbanan (Remote closed the connection) |
21:53:47 | kugel | saratoga the former |
21:53:47 | | Quit timc`` (Connection timed out) |
21:54:04 | saratoga | ah ok i misunderstood |
21:54:10 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
21:54:30 | saratoga | i suppose it would make sense to require the MMU on to control how caching works even without using VM |
21:54:41 | kugel | saratoga: well, my fuze doesn't refuse to boot anymore (and I copied the mmu setup from fx), so I suppose it's turned on. maybe some more is needed |
21:55:28 | kugel | the main build doesn't start, probably directly at main(), so something is still wrong |
21:55:29 | | Join BXCracer [0] (n=bxcracer@78-62-4-159.static.zebra.lt) |
21:59:02 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
21:59:14 | | Quit timc`` (Operation timed out) |
22:00 |
22:01:55 | | Join timc`` [0] (n=aoeu@124.93.243.83) |
22:05:21 | | Quit SUSaiyan (Read error: 104 (Connection reset by peer)) |
22:08:50 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
22:11:18 | | Quit dfkt (Read error: 110 (Connection timed out)) |
22:12:01 | | Quit neddy (Read error: 145 (Connection timed out)) |
22:27:54 | | Quit n17ikh|Lappy () |
22:29:04 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
22:29:35 | | Join Jaykay_ [0] (n=chatzill@p579E7F59.dip.t-dialin.net) |
22:30:58 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
22:31:25 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
22:33:10 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-7719288cd2bfcb1e) |
22:37:39 | | Quit robin0800 (Remote closed the connection) |
22:40:02 | | Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-8ed2141444ee02ea) |
22:41:50 | at0m | hi, is there a way to maintain "running time" between different RockBox updates? |
22:42:05 | at0m | i couldnt find any info on that on the forum or wiki... |
22:45:14 | PaulJam | Zagor: while testing you patch i noticed ocasionally some audio glitches during the first few seconds of a track. in an audio editor it looks like there are a few milliseconds of silence inserted. could that be related to the patch? |
22:45:33 | Zagor | it might |
22:45:38 | PaulJam | (the zero wait boost patch) |
22:46:41 | Zagor | is it repeatable? |
22:47:28 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
22:48:27 | PaulJam | maybe, i'm still testing, but i may have found a place in the playlist where this happens repeatable. |
22:48:36 | rasher | Could it be a simple performance issue? |
22:49:07 | PaulJam | i don't think so, boost is below 20% |
22:49:41 | Zagor | PaulJam: does it happen when you start from empty, or in the middle of a playlist? only in the beginning of tracks? |
22:49:52 | rasher | well if it needed to boost right there, and didn't, that could still be enough |
22:51:19 | | Quit timc`` (Read error: 104 (Connection reset by peer)) |
22:51:20 | | Join tim__ [0] (n=aoeu@124.93.243.83) |
22:51:43 | | Quit Lear ("ChatZilla 0.9.84 [Firefox 3.1b3pre/20090109073009]") |
22:51:48 | saratoga_lab | this optimization sounds very interesting: http://rob.opendot.cl/index.php/2008/08/22/aac-decoder/ |
22:52:02 | saratoga_lab | since it sounds like its independent of the exact IMDCT used |
22:53:19 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
22:53:56 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
22:54:30 | kugel | saratoga_lab: 135% compared to FAAD? isn't faad used in rockbox? |
22:54:30 | PaulJam | it happens in the middle of the playlist and only during the first few seconds of the song. when i rewind to the beginning of the song the glitches are still there, but when i stop, resume and the rewind to the beginning it plays fine. I'm now trying if it is repeatable if i start playback at the previous song. |
22:55:01 | *** | Saving seen data "./dancer.seen" |
22:55:12 | saratoga_lab | kugel: yeah but they're comparing to the fp version |
22:55:24 | saratoga_lab | and we're much faster then stock libfaad |
22:55:41 | kugel | ffmpeg aac uses fp I suppose? |
22:55:58 | saratoga_lab | yes, they're all fp |
22:57:57 | saratoga_lab | i want a gsoc student to do codec stuff |
22:58:14 | saratoga_lab | that or preglow to get interested again |
22:58:16 | | Quit Jaykay_ (Read error: 110 (Connection timed out)) |
22:59:03 | kugel | if not, ape will run faster than aac soon :p |
22:59:28 | | Join hillshum [0] (n=hillshum@75-165-245-240.slkc.qwest.net) |
23:00 |
23:04:48 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
23:04:57 | | Join japc [0] (n=japc@bl7-248-115.dsl.telepac.pt) |
23:07:05 | pixelma | bluebrother: wanted to ask you about the latest manual changes, especially about the closing {} after the button macros that are followed by punctuation (in the end of the diff). I think they aren't necessary but was unsure whether they could even lead to weird linebreaks? |
23:07:57 | | Join ibseco [0] (n=ibseco@BAH4004.bah.pppool.de) |
23:07:57 | saratoga_lab | there synced my TODO list with MrSomeOnes |
23:09:28 | | Quit bmbl ("Woah!") |
23:09:36 | PaulJam | Zagor: hmm, with a clean build it doesn't seem to happen, but i'll do some more testing (maybe my reproduction recipe isn't 100% reliable). |
23:09:46 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
23:10:09 | Zagor | PaulJam: ok. thank you for testing. |
23:10:10 | bluebrother | pixelma: from my understanding a {} won't introduce a possible line break, it just exists horizontal mode |
23:11:14 | | Quit bertrik (Remote closed the connection) |
23:12:38 | pixelma | ok. Do I remember correctly though that they aren't necessary? He said he introduced them for consistency and if it doesn't hurt, I won't change that, just for my understanding |
23:14:34 | | Quit bluebrother (Nick collision from services.) |
23:14:39 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
23:14:47 | bluebrother | they are not necessary unless the following is a space. A protected space (\ ) can result in nasty double-spaces though. Thus a macro without arguments like the button macros should always get ended with an empty statement |
23:15:29 | bluebrother | If the following is a punctuation the empty statement can be omitted as the punctuation breaks horizontal mode by itself. |
23:16:14 | | Join hd [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
23:16:23 | pixelma | I see, thanks |
23:16:41 | Zagor | c200 ran at 20/80 MHz stabilizes nicely around 11% boost (27MHz)with 320kbit mp3 |
23:17:15 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-fb738b8acec24239) |
23:17:19 | kugel | 20MHz? this is possible? |
23:17:25 | Zagor | yep |
23:17:26 | | Quit HellDragon (Connection timed out) |
23:17:38 | | Quit domonoky (Read error: 54 (Connection reset by peer)) |
23:17:44 | saratoga_lab | Zagor: this is with free bosting? |
23:17:49 | Zagor | saratoga_lab: yes |
23:17:55 | kugel | I just want say that 24MHz isn't enough to drive the UI sufficiently (imo) |
23:17:57 | saratoga_lab | ugh sorry gloves make it hard to type |
23:18:04 | saratoga_lab | Zagor: patch today?? |
23:18:20 | Zagor | saratoga_lab: yes, coming soon |
23:18:31 | saratoga_lab | i played around with 24 and 30mhz vs. boosted a while ago and honestly both kind of sucked for scrolling |
23:18:32 | kugel | 20 will be worse I gues |
23:18:36 | Zagor | kugel: I think 20 MHz is just fine for the c200 |
23:18:43 | pixelma | kugel: don't forget that the c200 screen is a lot smaller, so quicker updates |
23:18:48 | saratoga_lab | true |
23:18:48 | Zagor | it differs a lot for different targets |
23:18:51 | kugel | pixelma: sure |
23:18:59 | saratoga_lab | but if we have free boosting this becomes a nonissue anyway |
23:19:13 | kugel | but I guess there's not going to be #ifdef C200 or something like that? |
23:19:26 | BigBambi | boost on ui time? |
23:19:36 | | Nick hd is now known as HellDragon (n=jd@Wikipedia/HellDragon) |
23:19:38 | saratoga_lab | also, 20mhz core clock + more mp3 optimzation could get us really close to 30 hours battery on the e200v1 |
23:19:48 | Zagor | BigBambi: yes, if the coldfire test turns out well |
23:19:55 | kugel | saratoga_lab: except for text editor, I find scrolling perfectly on my e200 |
23:20:35 | saratoga_lab | kugel: its fine but you can definately see a change in scroll speed as it boosts and unboosts |
23:20:56 | kugel | possibly |
23:21:25 | saratoga_lab | get a large directory and just keep scrolling, as the PCM buffer goes down and up the scroll speed will change, at both 24 and 30 mhz |
23:21:49 | kugel | I don't pay much attention to that since it just works fine in my opinion (mostly) |
23:21:59 | | Quit itcheg (Client Quit) |
23:22:13 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-5dfed8fc632ee82b) |
23:22:20 | kugel | yea, large dris / text editor are an issue, but I don't have large dirs and never use the text editor M) |
23:22:29 | kugel | ;) * |
23:22:31 | saratoga_lab | yeah i agree, its not a huge issue, at least until we get really low core clocks |
23:23:42 | kugel | but well, e200 wouldn't be the only target in need of a ui boost |
23:25:34 | kugel | saratoga_lab: btw: I did some work on the buttonlight again for the fuze, but I cannot really get it working |
23:26:06 | kugel | I know why it doesn't work (microsd occupying the pins), but weirdly enough sometimes it works as expected |
23:26:30 | Zagor | I don't think of it as UI boost. We simply boost the stuff we want to run quickly. UI, ATA, codecs, whatever |
23:26:59 | saratoga_lab | considering all the random issues we have, i wouldn't be surprised if its related to whatever is screwing up codecs |
23:27:01 | bluebrother | nice. Nokia announced Qt to offer a LGPL license starting with 4.5. |
23:28:24 | | Join akur [0] (n=akur@bl6-146-119.dsl.telepac.pt) |
23:28:28 | | Part akur |
23:28:57 | | Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) |
23:31:02 | | Join undertakingyou [0] (n=will@undertakingyou.dsl.xmission.com) |
23:33:23 | Zagor | amiconn: can't we use the "SLOW" clock source on PP5020? that's fed by 24MHz |
23:35:14 | Zagor | since it is coupled to a divider, we could run it at 12, 6, 3, 1.5 MHz... |
23:35:34 | Zagor | I'll try it on my PP5022 |
23:36:25 | saratoga_lab | hmm if we're going to drop the core clock on PP it might make sense to look into DSP on COP again |
23:37:47 | Zagor | I don't know how far we want to drop it. It depends how we want to do things. |
23:37:58 | | Quit jgarvey ("Leaving") |
23:37:58 | Zagor | I just want to see if we have that option. |
23:38:00 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
23:38:26 | Zagor | what runs on COP today? |
23:42:28 | saratoga_lab | Zagor: part of libmad and mpegplayer |
23:42:32 | saratoga_lab | i don't think any of the core does |
23:42:47 | saratoga_lab | oh the graylib |
23:44:20 | | Quit DerDome ("Leaving.") |
23:44:30 | Zagor | I haven't really looked at the dual-core aspects at all. why don't we run for example the whole codecs on COP? |
23:44:47 | saratoga_lab | Zagor: the individual codecs aren't thread safe |
23:44:58 | saratoga_lab | since they touch the codec buffer |
23:45:17 | | Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) |
23:45:22 | saratoga_lab | i don't know enough about buffering or playback to say how hard that is to fix |
23:45:33 | Llorean | And running a whole codec one one core might result in higher boost ratios than splitting effectively right? |
23:45:55 | Zagor | isn't that all the more reason not to split them? let them roam free with their chunk of memory and just synchronize file and pcm buffer access. |
23:46:02 | saratoga_lab | well right now we run it all on one core anyway, it just happens to be the main core rather then the cop [ignoring mp3] |
23:46:40 | saratoga_lab | i'd love to synchronize file and pcm buffer access, it'd increase runtime for all codecs, i just don't know anything about doing it |
23:46:40 | Llorean | Yeah, codecs that can't be split probably make more sense to drop on the other core. I just meant, if there's a way to split them effectively that may be even better (in some cases) |
23:46:44 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
23:46:51 | Zagor | Llorean: agreed |
23:47:27 | | Quit J-23 ("ZNC - http://znc.sourceforge.net") |
23:47:56 | saratoga_lab | i don't even know how codecs access the file buffer, do they request a chunk or what? |
23:48:13 | Zagor | yes |
23:48:26 | saratoga_lab | well that ought to be fairly easy to make thread safe then |
23:48:46 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
23:48:55 | saratoga_lab | just make that function block until the other core is done writing to the file buffer |
23:49:19 | Zagor | they access file buffer via request_buffer() and pcm buffer via pcmbuf_insert(). so synchronizing should be fairly simple. |
23:49:32 | saratoga_lab | though i guess you'd need some way to lock the file buffer while the codec is running to prevent buffering while the other thread is working |
23:49:45 | saratoga_lab | that or memcpy the request_buffer results |
23:49:47 | Zagor | there's a few other buffer access functions too, but the point is they don't access the buffer directly |
23:50:46 | linuxstb | Codecs can either use request_buffer() (where they are given a pointer to the data), followed by "advance_buffer" to say they are done with it, or read_buffer(), where a memcpy happens. |
23:50:55 | linuxstb | (or names similar to those...) |
23:52:16 | saratoga_lab | on PP it might be worth memcpying always so that buffer access is always thread safe |
23:53:17 | saratoga_lab | though i guess you'd still have to worry about what all the other codec api functions are touching |
23:55:48 | Zagor | a little housekeeping should be enough, so we keep tracks of what the codec "owns" |
23:55:53 | | Quit hillshum (Read error: 110 (Connection timed out)) |
23:55:54 | saratoga_lab | i should probably not talk about this since i dont' understand threading anyway |
23:56:13 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |