| 00:01:02 | Buschel | pixelma: i have a son, but he is too young for DAPs... my wife will see the trick ;) |
| 00:01:25 | gevaerts | But will she see it in time? :) |
| 00:01:49 | Buschel | hehe :) |
| 00:02:17 | * | Buschel guesses that gevaerts also tried this trick |
| 00:02:33 | Buschel | successful? |
| 00:02:48 | kugel | doing things like IRAM_48K, IRAM_80K, IRAM_128K etc sounds horrid IMO |
| 00:03:00 | | Join Rob2222 [0] (~Miranda@p4FDCA85A.dip.t-dialin.net) |
| 00:03:10 | CIA-5 | New commit by amiconn (r25066): rockbox.dev.sh ... |
| 00:03:18 | Buschel | gevaerts: in fact i treid to buy a nano2g via ebay. she spotted it and was "Not amused" |
| 00:03:28 | Buschel | *tried |
| 00:03:33 | gevaerts | Buschel: sorry, no wife and no children here :) |
| 00:03:59 | Buschel | well, other problems then... but enough of OT :o) |
| 00:04:40 | moos | Buschel: sure that our Rockbox's fund could help here; bug Zagor or Bagder about it, and well done for musepack sv8 by the way |
| 00:04:55 | | Quit ender` (Quit: The best way to accelerate a Macintosh is at 9.8m/sec²) |
| 00:05:13 | amiconn | kugel: That doesn't make much sense. IRAM usage does not just depend on IRAM size, but on various other factors |
| 00:05:22 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 00:05:30 | moos | Buschel: sure that we all for that you get coldifire target at least |
| 00:05:36 | moos | :) |
| 00:06:18 | | Quit Rob2223 (Ping timeout: 245 seconds) |
| 00:06:25 | kugel | amiconn: sure, but I think we want something maintainable. we can probably inject target specific defines at some places; but if we consider too much we end up worse |
| 00:06:27 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 00:06:34 | * | Buschel is fine with his iPod 5.5G |
| 00:06:39 | Buschel | works like charm |
| 00:06:52 | amiconn | kugel: Imo this can only be done per codec. There is no general rule |
| 00:06:56 | | Quit Farthen (Ping timeout: 264 seconds) |
| 00:06:57 | moos | Buschel: testing purpose of course :) |
| 00:07:20 | Buschel | :o) |
| 00:07:33 | moos | a coldfire target would have to be in the rescue kit ;) |
| 00:07:38 | kugel | my suggestion would be a huge improvement over the current situation nevertheless |
| 00:08:03 | Buschel | kugel: i am of the same opinion. |
| 00:08:22 | amiconn | I would expect it to either have neglectibe effect, or change performance of numerous codecs for the worse |
| 00:08:25 | kugel | r25064 speaks for itself |
| 00:09:13 | | Quit dfkt (Ping timeout: 245 seconds) |
| 00:09:17 | Buschel | yep. and if you search for such defines in the codec path, you will find lots more of such CPU-specific definitions. |
| 00:09:34 | kugel | any example where anything other than iram size is considered in the current code? |
| 00:09:44 | amiconn | Yes |
| 00:10:04 | amiconn | PP5002 vs. PP5020 |
| 00:10:27 | kugel | can I see a link to that code? |
| 00:10:30 | amiconn | On PP5002 all performance critical stuff (including code) should be in IRAM, while on PP5020 this would be a bad idea |
| 00:10:32 | TheSeven | hmm. "filetype array full". what does this mean? |
| 00:10:41 | amiconn | libdemac is an example |
| 00:11:09 | amiconn | Soon PP5020 will get even more special handling in order to improve performance |
| 00:11:13 | kugel | another example? that libdemac change was very recent (as the findings w.r.t to PP5020 iram is) |
| 00:11:13 | Buschel | musepack does something similar for ICODE, but not for IBSS and ICONST |
| 00:11:27 | amiconn | No it wasn't |
| 00:11:59 | amiconn | The changes related to those findings are not yet committed |
| 00:12:15 | kugel | is there another example in the current code? |
| 00:12:30 | amiconn | There probably is - I'm not sure |
| 00:12:31 | TheSeven | and what the heck does #define HAVE_USB_HID_MOUSE do? |
| 00:12:48 | amiconn | Buschel said musepack also does it |
| 00:12:49 | Buschel | if we could exchange the "#ifdef'ing CPU" with "#ifdef'ing IRAM_SIZE" we could still define different behaviour for code, constants and variables |
| 00:12:58 | kugel | anyway, if we know special stuff, we can add special handling. new targets should not need explicit action for code which mostly considers iram size only |
| 00:14:31 | amiconn | PP5002 specific ICODE handling in libdemac was committed in October 2008 |
| 00:14:37 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 00:15:28 | kugel | ah I confused it with a different coomit |
| 00:15:47 | amiconn | There's another reason why just IRAM size isn't sufficient: Code will have different size on different architectures |
| 00:15:51 | Buschel | musepack -> mpcdec.h, line 60-68, does also not use icode for all targets with large iram |
| 00:16:15 | amiconn | That also applies to data in some cases (e.g. libdemac filter buffers on ARMv4 are twice the size as on other targets) |
| 00:17:21 | Buschel | amiconn: that is correct. but we could still exchange the #if CPU"-worms with a simple "#if IRAM_CODEC_80K" and keep the hand made optimizations (like we do now) |
| 00:17:48 | amiconn | There are beginnings of target specific IRAM handling in the config/*.h files |
| 00:18:31 | amiconn | The #if CPU worms can be limited to one centralised .h file per codec, I think |
| 00:19:15 | | Quit dfkt_ (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 00:19:50 | Buschel | amiconn: yes, that has been done already. but we have such worms _per codec_. with each new target or iram configuration change you need to check all codecs... |
| 00:21:48 | saratoga | I liked the idea of putting the defines in the codeclib just because its much easier to change them there then editing all the config files everytime we change things |
| 00:22:01 | Buschel | exactly |
| 00:22:16 | saratoga | we used to have some of them in the config files (for vorbis) and it was kind of a mess |
| 00:22:49 | kugel | I think #defines on a per soc basis in the target tree are more promising |
| 00:23:00 | saratoga | I had imaged having all IRAM targets define the 48k level, the >=128k targets define the 80k level and the 192k targets define the 128k level |
| 00:23:47 | saratoga | i suppose the 48k check isn't even needed |
| 00:23:54 | kugel | why do you want to define specific levels? defining the precise number is trivial, and you can still check for the levels in the codec code |
| 00:23:56 | saratoga | so really they'll just be a check for 80 and 128k |
| 00:24:17 | saratoga | because it makes it easier to optimize if you have fewer differences between targets |
| 00:24:26 | kugel | how? |
| 00:24:40 | saratoga | you don't have to keep compiling more and more targets when you change things to see if everything links |
| 00:24:56 | kugel | how's #ifdef IRAM_80K easier than #if IRAM >= 80k? |
| 00:25:06 | saratoga | oh i see what you mean |
| 00:25:26 | saratoga | i don't really think thats different then what i'm suggesting |
| 00:26:09 | * | Buschel better seeks for his bed |
| 00:26:19 | kugel | adding more levels will be much more easier though (if needed), and it looks less obscure. and the numbers are already available (just look at the lot of defines in plugin.lds) |
| 00:26:28 | Buschel | gotta get up early tomorrow. see you! |
| 00:26:51 | saratoga | levels above 128k probably won't help much, 128k is enough IRAM for all the codecs I've looked at |
| 00:27:02 | | Quit Buschel () |
| 00:28:22 | kugel | saratoga: but I can imagine we could want some steps between 80k and 128k for more fine-grained optimisation |
| 00:29:00 | saratoga | yeah if we ever got oddball IRAM sizes maybe |
| 00:29:17 | pixelma | now I don't know what I should test on my M5 :\ |
| 00:29:34 | saratoga | pixelma: see if WMA, Vorbis or MPC files still work |
| 00:29:48 | saratoga | most likely though if it compiles and links there is no problem |
| 00:30:01 | kugel | and the core too, that commit changed both core and codecs |
| 00:30:06 | saratoga | since i think the linker is smart enough to realize if you try to allocate more memory then you have |
| 00:30:21 | saratoga | well yeah but if audio plays the core is fine I think :) |
| 00:30:22 | kugel | I think so too |
| 00:30:22 | pixelma | work at all, or as quick as before, or ? |
| 00:30:30 | saratoga | work at all |
| 00:30:47 | saratoga | you'd probably crash immediately if the memory is double allocated or something like that |
| 00:31:10 | kugel | saratoga: I can also imagine that the current 128k level is just 128k because the targets happened to have that, and that much code actually needs less (like 100k) |
| 00:31:31 | saratoga | yeah its pretty rare to use all the IRAM available in a codec |
| 00:31:49 | saratoga | since usually theres at least some left over due to needing 32KB to put the next best buffer in IRAM and only having 16KB |
| 00:32:41 | soap | any plugins able to break because of the IRAM "move"? |
| 00:32:51 | saratoga | but i've never really seen a convincing case for giving core more IRAM, usually some is needed for things like DMA, stack, or whatever, and anymore just gives you a couple percent faster LCD updates that make no real difference to battery life or UI |
| 00:33:10 | saratoga | soap: i think they'll all have more IRAM, so hopefully nothing breaks |
| 00:33:23 | | Quit merbanan (Ping timeout: 245 seconds) |
| 00:33:49 | saratoga | on most targets during playback it seems like the UI uses less then 3 MHz under normal use |
| 00:33:54 | saratoga | sorry core, not UI |
| 00:33:57 | saratoga | that can use more obviously |
| 00:34:25 | saratoga | maybe DSP could use some, but I think it already uses IRAM if a codec passes it PCM data in an IRAM buffer |
| 00:34:59 | soap | saratoga, more - but possibility of shifting across the DMA accessible line? |
| 00:35:14 | saratoga | ah yeah |
| 00:35:28 | saratoga | i don't know anything about that |
| 00:35:34 | saratoga | i didn't even know any plugins could use DMA |
| 00:35:46 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 00:37:49 | soap | don't know if they can. I was just curious and brought it up out of curiosity in regards to pixelma's query. |
| 00:38:09 | | Quit komputes (Read error: Connection reset by peer) |
| 00:42:24 | | Part Zacam |
| 00:44:24 | | Quit saratoga (Changing host) |
| 00:44:24 | | Join saratoga [0] (~9803c6dd@rockbox/developer/saratoga) |
| 00:45:26 | | Quit efyx_ (Remote host closed the connection) |
| 00:48:10 | | Quit bertrik (Ping timeout: 265 seconds) |
| 00:53:05 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 00:56:00 | | Part froggyman |
| 00:56:52 | soap | TheSeven, creposucre started his discussion on iPod accessories in the FS (#10623) task thread on March 1st of this year, I believe the IRC talk about why /not/ to do it followed shortly - but I haven't looked back through the logs. |
| 00:57:59 | *** | Saving seen data "./dancer.seen" |
| 00:58:20 | | Quit JdGordon (Ping timeout: 240 seconds) |
| 00:58:58 | soap | Though on the 28th of Feb, buschel was saying he knew of no way to detect accessories - so perhaps one side's argument was uninformed? |
| 00:59:28 | soap | (and if there is anyone obsessed with turning things off to save 0.5ma, it's buschel) ;) |
| 01:00 |
| 01:02:50 | TheSeven | can anyone tell me what "filetype array full" is supposed to tell me? |
| 01:02:57 | TheSeven | it appears as a splash during boot |
| 01:10:01 | amiconn | It means that the filetype array is full... |
| 01:10:39 | TheSeven | why does that happen? |
| 01:10:39 | amiconn | I.e. there are more filetypes defined (built-in + config file) than filetypes.c is prepared to handle |
| 01:13:00 | TheSeven | hm, interesting. does it also happen on other targets right now? |
| 01:13:05 | | Quit Sajber^ (Quit: Leaving.) |
| 01:14:09 | amiconn | I don't know. It doesn't happen here on the targets I'm using often, but then I'm not running the very latest builds |
| 01:15:57 | amiconn | It is quite normal for this error to not appear on all targets at the same time |
| 01:16:22 | amiconn | It all depends on the supported file types, which differ somewhat between targets |
| 01:22:07 | | Join CGL [0] (~CGL@190.207.198.83) |
| 01:22:09 | | Quit MethoS- (Remote host closed the connection) |
| 01:27:12 | | Quit Schmogel (Read error: Connection reset by peer) |
| 01:33:44 | saratoga | TheSeven: I do not get it with my e200v1, which should support the same file types as your nano afaik |
| 01:35:17 | TheSeven | besides .ipod/.ipodx (crypt_firmware plugin) |
| 01:35:47 | | Quit xavieran (Quit: ➤➤➤➤➤➤ UniCode shall rein forever! ➤➤➤➤➤➤) |
| 01:36:18 | S_a_i_n_t_ | which doesn't work..... :[ |
| 01:36:57 | saratoga | ok then i better test on hte nano |
| 01:40:04 | saratoga | how long should rolo on the nano2G take? |
| 01:40:32 | | Quit n17ikh () |
| 01:40:41 | S_a_i_n_t_ | crypt_firmware throws a *Panic* Stkov main...but it still does this even when the stack is at 0x8000 (default is 0x2000) |
| 01:40:57 | S_a_i_n_t_ | rolo should take ~10seconds or so |
| 01:41:00 | S_a_i_n_t_ | less even. |
| 01:41:08 | saratoga | hmm then its probably frozen |
| 01:41:58 | | Quit liar (Ping timeout: 252 seconds) |
| 01:42:19 | saratoga | TheSeven: with stock SVN I get no message on startup |
| 01:42:29 | saratoga | although I did crash rolo trying to update using rockbox USB mode |
| 01:42:53 | kugel | S_a_i_n_t_: it should take 2s or so, rather :) |
| 01:45:07 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 01:45:48 | S_a_i_n_t_ | kegul: yes it *should* (;P) but I find sometimes it can take as long as 10 seconds or so. |
| 01:45:57 | S_a_i_n_t_ | I haven't yet found what makes it vary |
| 01:52:19 | TheSeven | saratoga, S_a_i_n_t_: rolo on nano2g can take up to a minute, depending on the FTL state |
| 01:52:44 | TheSeven | as long as it's saying "Flushing storage buffers" it's probably working fine |
| 01:52:57 | TheSeven | it shouldn't say "executing" for more than a second though |
| 01:52:57 | saratoga | it did give me a "clearing buffers" message, then sat at executing for roughly a minute or two |
| 01:53:24 | saratoga | i ejected the disk in windows but didn't stop the USB device, is that a bad idea? |
| 01:53:30 | TheSeven | if it freezes at "executing" (which it is doing quite often) it's safe to reset - the FTL is unmounted at that point |
| 02:00 |
| 02:00:40 | * | TheSeven is working on nano2g battery calibration |
| 02:01:04 | TheSeven | did anyone figure out the nano2g charge completion gpio? (is there even one?) |
| 02:08:16 | CIA-5 | New commit by amiconn (r25067): The GCC patch for building sh-elf-gcc now also fixes 'tr' arguments so that a dumb 'tr' can handle them. Needed for building sh-elf-gcc on ... |
| 02:09:40 | amiconn | Bagder/ Zagor: The website needs updating (/gcc dir) |
| 02:11:18 | | Quit gevaerts (Ping timeout: 256 seconds) |
| 02:11:29 | | Join tari [0] (~adam@2610:130:115:b00:223:54ff:fea4:a5fb) |
| 02:12:48 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 02:16:07 | | Quit n17ikh (Read error: Connection reset by peer) |
| 02:18:27 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 02:19:43 | TheSeven | compensating the battery readings for the inner resistance seems to work quite well and give *way* more accurate measurements during charging |
| 02:20:16 | saratoga | TheSeven: what do you mean? |
| 02:20:32 | TheSeven | inner resistance of the nano2g battery seems to be ~800 milliohms |
| 02:20:46 | | Part LambdaCalculus37 |
| 02:21:12 | TheSeven | i changed the battery reading code to also take the battery current into account and compensate the voltage drop across the inner resistance |
| 02:21:56 | saratoga | interesting idea |
| 02:22:06 | saratoga | i guess that works because you've got an annmeter? |
| 02:22:28 | TheSeven | yes, i have a current ADC |
| 02:23:10 | | Quit DerPapst (Quit: Leaving.) |
| 02:23:10 | | Quit kaniini (Read error: Connection reset by peer) |
| 02:23:12 | | Join kaniini [0] (~kaniini65@dyn75-70.yok.fi) |
| 02:23:25 | TheSeven | (a regular ADC measuring the voltage drop across a 160 milliohm shunt) |
| 02:24:05 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 02:27:15 | kugel | amiconn: why aren't the sh/m68k patches in upstream? did anyone sent it to them? |
| 02:28:06 | kugel | or is upstream fixed and we just use too old versions? |
| 02:28:55 | kugel | saratoga: I can't download your parse_testcodec.pl.txt |
| 02:30:09 | saratoga | kugel: it seems you have to be logged in as me to download it for some reason |
| 02:30:13 | saratoga | i think the wiki is broken |
| 02:30:41 | saratoga | kugel: http://pastebin.com/SjcxpruE |
| 02:35:05 | | Quit Casainho (Ping timeout: 276 seconds) |
| 02:35:33 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 02:36:56 | | Quit CGL (*.net *.split) |
| 02:36:56 | | Quit simabeis (*.net *.split) |
| 02:36:56 | | Quit krazykit (*.net *.split) |
| 02:36:57 | | Quit lyngaas (*.net *.split) |
| 02:36:57 | | Quit maraz (*.net *.split) |
| 02:36:57 | | Quit rvvs89 (*.net *.split) |
| 02:36:57 | | Quit rasher (*.net *.split) |
| 02:38:26 | | Join CGL [0] (~CGL@190.207.198.83) |
| 02:38:26 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
| 02:38:26 | | Join krazykit [0] (~kkit@adsl-76-252-13-109.dsl.ipltin.sbcglobal.net) |
| 02:38:26 | | Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) |
| 02:38:26 | | Join maraz [0] (maraz@kapsi.fi) |
| 02:38:26 | | Join rvvs89 [0] (robotnik@pdpc/supporter/base/rvvs89) |
| 02:38:26 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 02:39:34 | kugel | saratoga: the ape case doesn't work :( |
| 02:39:42 | saratoga | bah |
| 02:39:51 | saratoga | i don't think i t tested it since ape is so slow |
| 02:40:47 | kugel | I can't explain why, though |
| 02:44:14 | kugel | m/ape/ should match ape_c* |
| 02:44:31 | saratoga | pastebin the input file |
| 02:44:40 | | Quit scorche (Ping timeout: 252 seconds) |
| 02:45:16 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 02:45:34 | saratoga | whos alt account is matt0001 anyway |
| 02:45:46 | | Quit planetbeing (Ping timeout: 252 seconds) |
| 02:45:47 | | Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 02:49:11 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 02:51:37 | | Join KennethFechter [0] (~4b21413f@giant.haxx.se) |
| 02:53:10 | kugel | $oldkey is empty after a52_stereo_192.ac3 |
| 02:53:37 | KennethFechter | I am new to the rockbox wiki, and would like to request write permission. I don't know if this is necessary to create a new page for a port. I would like to contribute to a port for the Sony NWZ-728 and other NWZ players. I know there is a page on the walkman NWA, but this player is different |
| 02:53:37 | kugel | alright, got it working |
| 02:53:43 | KennethFechter | brb |
| 02:57:43 | saratoga | KennethFechter: done |
| 02:58:00 | saratoga | KennethFechter: have you found out anything about that player? |
| 02:58:01 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:07:37 | kugel | saratoga: I think so too (re wiki broken) |
| 03:08:37 | kugel | http://www.rockbox.org/wiki/bin/viewfile/Main/CodecPerformanceComparison?filename=parse_testcodec.pl.txt works |
| 03:09:35 | kugel | saratoga: I uploaded latest eabi test codec results |
| 03:09:52 | saratoga | cool |
| 03:10:40 | | Quit Adnyxo (Ping timeout: 248 seconds) |
| 03:13:41 | saratoga | kugel: maybe the EABI results shouldn't go under "current results" since they're not SVN results |
| 03:13:44 | saratoga | its a bit confusing |
| 03:13:48 | saratoga | maybe add an EABI heading? |
| 03:14:57 | kugel | saratoga: they sure are svn results |
| 03:15:03 | kugel | just a different compilre |
| 03:15:19 | saratoga | well i mean not the official build |
| 03:15:35 | saratoga | lots of people looking at the results are probably just users who aren't aware of EABI |
| 03:15:57 | kugel | well, feel free to make it more obvious if you like |
| 03:16:24 | kugel | I don't think lots of *users* are looking at it, understanding the numbers anyway |
| 03:17:09 | kugel | also, I really doubt the difference to the default toolchain is caused by eabi. I think it's mostly a matter of the compiler version |
| 03:19:12 | TheSeven | kugel: we should do another test_codec run on nano2g and see if there is any difference to the last eabi one, which was done *before* i fixed the -mlong-calls thing |
| 03:20:04 | Llorean | kugel: People read that page all the time. |
| 03:20:19 | Llorean | They don't understand the numbers, in most cases, but often users *think* they do |
| 03:20:27 | Llorean | And it should be accurate where those numbers come from |
| 03:20:34 | kugel | it is |
| 03:21:09 | saratoga | i'll clean it up a little |
| 03:21:17 | saratoga | IMO the wiki should be as accessible as possible to users |
| 03:22:24 | Llorean | I think, at least, that non-SVN information should always be under a separate heading than SVN information wherever possible |
| 03:22:33 | | Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 03:22:36 | Llorean | Users should always be able to immediately be able to tell what pertains to what they're actually downloading |
| 03:25:12 | Unhelpful | saratoga: apparently 4.4 is known to have some integer performance regressions - this was mentioned in a review of compilers for ARM as being a problem with one of the specialized gcc-based compilers as well as with gcc itself |
| 03:25:33 | saratoga | yeah its a bit slower |
| 03:25:44 | * | kugel maintains that this is SVN information |
| 03:25:52 | saratoga | but really pretty close, mostly because we leave so little performance critical code up to GCC :) |
| 03:26:01 | KennethFechter | back |
| 03:26:06 | KennethFechter | im looking it up right now |
| 03:26:15 | KennethFechter | also, i have to log off real quick |
| 03:26:44 | kugel | well, not really svn, since I haven't committed the rockboxdev.sh/configure changes for gcc 4.4.3 and binutils 2.20.1 yet :) |
| 03:27:02 | saratoga | there, now with nice CF and PP headings, and one for eabi |
| 03:27:13 | Llorean | kugel: It's not really SVN information unless the results come from the svn build provided by our build servers... |
| 03:27:32 | kugel | no results can come from the build servers |
| 03:27:49 | kugel | until we ship test_codec in current builds |
| 03:27:52 | Llorean | They can come from a build as close as possible to what they provide. |
| 03:28:05 | saratoga | not true, I compile my test_codec on a build server :) |
| 03:28:37 | saratoga | whats teh nano2Gs cpu again? i don't see it on the wiki |
| 03:28:49 | kugel | arm940t |
| 03:29:26 | saratoga | Samsung S5L8701 |
| 03:30:01 | saratoga | now we just need gigabeat and ams scores (once test_codec is updated for the later) |
| 03:31:32 | | Quit KennethFechter (Quit: CGI:IRC (Ping timeout)) |
| 03:34:00 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 03:36:16 | * | S_a_i_n_t_ wonders how to tell configure to use the eabi toolchain he just built... |
| 03:36:21 | S_a_i_n_t_ | Anyone? |
| 03:38:38 | | Quit bzed (Read error: Connection reset by peer) |
| 03:38:40 | | Join bzed [0] (~bzed@devel.recluse.de) |
| 03:39:05 | krazykit | S_a_i_n_t_, checked the logs? i'm sure Unhelpful mentioned his changes at some point |
| 03:39:48 | | Quit Adnyxo (Ping timeout: 260 seconds) |
| 03:43:30 | S_a_i_n_t_ | I haven't no...I was kinda hoping for "Sure, just do 'configure -this' " |
| 03:44:03 | kugel | ahh, codesourcery almost works without changes |
| 03:44:12 | kugel | of course it needs the patch we also apply to gcc |
| 03:44:35 | | Quit komputes (Ping timeout: 265 seconds) |
| 03:45:02 | saratoga | kugel: nice |
| 03:45:06 | saratoga | i'm very interested in how it performs |
| 03:52:07 | | Quit rasher (Ping timeout: 240 seconds) |
| 03:52:10 | | Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) |
| 03:52:11 | | Quit rasher (Changing host) |
| 03:52:11 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 03:53:32 | kugel | saratoga: some plugins needs disabling. binsize seems to be almost the same as in an eabi build |
| 03:54:16 | kugel | doom's bss doesn't fit by 37k apparently! |
| 03:54:58 | | Join chrisb [0] (~chrisb@pool-98-111-169-188.phlapa.east.verizon.net) |
| 03:55:08 | | Join noob1 [0] (~ad15ebf0@giant.haxx.se) |
| 03:55:17 | * | chrisb ordered his sansa e250 from tigerdirect |
| 03:55:49 | noob1 | Is anyone available to help me get my 240gb ipod working with rockbox? |
| 03:57:45 | kugel | saratoga: fingers crossed, but I don't expect a huge difference seeing it's based on the gcc 4.4.x branch |
| 03:58:31 | S_a_i_n_t_ | noob1: First off, what model/generation is your iPod? |
| 03:58:51 | noob1 | ipod video 5th gen 60gb upgraded to 240gb w/ the apricorn kit |
| 03:59:12 | | Join Guest76488 [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 04:00 |
| 04:00:10 | | Nick Guest76488 is now known as froggyman (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 04:00:14 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 04:01:46 | noob1 | @s_a_i_n_t: according to the many posts... all i have to do is reconfigure the .h file to have compat. w/ large disks. I am limited when it comes to compiling etc.. and I don't even know where to begin. I tried searching for the bootloader-ipodvideo.ipod file to install, but the post i found was 2 years old and the link is already dead. |
| 04:02:23 | S_a_i_n_t_ | so...do you *have* a build environment set up? |
| 04:02:37 | noob1 | No i do not. |
| 04:02:42 | S_a_i_n_t_ | aha... |
| 04:03:23 | Unhelpful | S_a_i_n_t_: configure −−eabi? |
| 04:05:26 | kugel | S_a_i_n_t_: if you had checked the help of configure you would have known |
| 04:05:30 | S_a_i_n_t_ | a "bigdisk" build only needs the PHYS_SECTOR redifined and HAVE_LBA48 added....correct? |
| 04:05:56 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 04:07:53 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 04:08:41 | noob1 | I believe so S.a.i.n.t |
| 04:09:57 | noob1 | I think I may have stumbled on a page that has the files already compiled. |
| 04:09:59 | S_a_i_n_t_ | I was kinda asking a dev..but hey, I'll give it a whirl and see if it compiles. If it does, I'll DCC you the build. |
| 04:10:58 | noob1 | i think http://forums.rockbox.org/index.php?topic=22188.0 has the right files. |
| 04:13:42 | S_a_i_n_t_ | Bah....it's easier for me to make the 2/3 changes to me own tree...it's compiling now. |
| 04:13:47 | S_a_i_n_t_ | cross your fingers :D |
| 04:14:21 | noob1 | hmm I don't think DCC works on web client does it? |
| 04:14:21 | noob1 | lol |
| 04:14:22 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 04:15:03 | | Quit Rob2222 (Ping timeout: 245 seconds) |
| 04:17:35 | S_a_i_n_t_ | noob1: forgot to ask...is it 32MB or 64MB? |
| 04:18:02 | S_a_i_n_t_ | if it's 64, I'll stop now and recompile. |
| 04:18:26 | noob1 | You know, I believe it is 64 |
| 04:18:27 | noob1 | lol |
| 04:18:29 | noob1 | so you can stop |
| 04:18:34 | noob1 | Don't recompile |
| 04:18:42 | noob1 | let me try and reboot the iPod, it should work w/ the file I found |
| 04:18:57 | noob1 | I really appreciate your help, after 5 hours of searchign finally found something that worked lol |
| 04:18:57 | S_a_i_n_t_ | you can't just add a patch to a build... |
| 04:19:02 | S_a_i_n_t_ | it needs to be compiled. |
| 04:19:10 | noob1 | it booted up though |
| 04:19:33 | saratoga | that build is oldish, so you might as well use your own if you've compiled it |
| 04:19:43 | S_a_i_n_t_ | did you just grab one of the ancient build for the unsupported page? |
| 04:20:02 | saratoga | why is the source zip for that build 75MB |
| 04:20:09 | saratoga | what the heck did he put in there |
| 04:20:28 | S_a_i_n_t_ | heaps of shit...I think Doom, etc.. |
| 04:20:29 | noob1 | http://forums.rockbox.org/index.php?topic=22188.0 | r23166_ipod_5G_64Mb_bigHDD.zip |
| 04:20:33 | noob1 | is what i downloaded |
| 04:20:40 | saratoga | downloading it now just to see |
| 04:22:33 | noob1 | Will that work or am I like 32074723094 builds back |
| 04:22:56 | S_a_i_n_t_ | it'll work....but you'll miss a WHOLE HEAP of new stuff |
| 04:23:02 | S_a_i_n_t_ | that build is ancient |
| 04:23:11 | noob1 | oh |
| 04:23:16 | noob1 | okay, i'll take yours then |
| 04:23:17 | S_a_i_n_t_ | may as well wait for the build I'm compiling now to finish. |
| 04:23:18 | noob1 | <3 |
| 04:24:17 | noob1 | I'm going to have to digg into the build environment sometime soon here. It's not too hard is it? |
| 04:24:46 | saratoga | http://pastebin.com/dVr6CmtN |
| 04:24:55 | saratoga | heres teh actual patch for big disk from that build |
| 04:24:58 | saratoga | its like 2 lines |
| 04:25:22 | saratoga | noob1: no its not very difficult, its trivial if you've already got linux, a little harder if you have to use a virtualmachine or cygwin |
| 04:25:53 | noob1 | I have Fedora on my laptop, Just finally getting a class on it starting this monday |
| 04:26:05 | S_a_i_n_t_ | Cygwin may or may not be easier...as there are prebuilt cross-compilers. |
| 04:26:08 | noob1 | So i'm hoping that'll make it easier |
| 04:26:15 | saratoga | then you just checkout rockbox svn, and run tools/configure |
| 04:26:26 | saratoga | it'll build the cross compilers |
| 04:26:29 | noob1 | Okay, i'll look into that |
| 04:26:32 | S_a_i_n_t_ | but building the cross-compilers is trivial also. |
| 04:26:45 | saratoga | finally you have to add arm-elf-gcc to your PATH either using the export command or editing your startup script |
| 04:27:09 | saratoga | the wiki has step by step guides for ubuntu, should be the same for your distro |
| 04:27:11 | noob1 | I take it that all of this info you guys are spilling out to me is in the wiki |
| 04:27:14 | noob1 | yup |
| 04:28:07 | noob1 | I'l figure it out, in the mean time i'll take your modification lol as I kinda want my ipod working tomorrow for my flac files. Gonna be a boring day in the datacenter |
| 04:28:44 | S_a_i_n_t_ | well, I'll PM you the link to where I've uploaded the build when it finishes. |
| 04:28:57 | S_a_i_n_t_ | If you need to leave, PM me your email or something. |
| 04:29:05 | noob1 | I'll be here |
| 04:29:09 | S_a_i_n_t_ | cool. |
| 04:30:47 | noob1 | I find it funny that I can set up hardware and program them, but when it comes to software i'm so lost |
| 04:31:55 | S_a_i_n_t_ | No-ones born win C/C++ embedded :P |
| 04:32:22 | noob1 | Linus Torvald would disagree |
| 04:32:22 | noob1 | :P |
| 04:33:16 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 04:39:08 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 04:42:06 | | Quit planetbeing (Ping timeout: 265 seconds) |
| 04:42:07 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 04:42:31 | | Quit TheSeven (Disconnected by services) |
| 04:42:43 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
| 04:42:53 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
| 04:50:02 | | Quit Llorean (Quit: Leaving.) |
| 04:51:54 | chrisb | can rockbox display video on the sansa e250? |
| 04:53:49 | kugel | saratoga: should I compare the codesourcery results to the eabi build, or to the default? |
| 04:53:52 | advcomp2019 | yes look at the mpeg player wiki |
| 04:54:24 | | Join Barahir_ [0] (~jonathan@gssn-5f754beb.pool.mediaWays.net) |
| 04:55:57 | | Quit Barahir (Read error: Operation timed out) |
| 04:58:05 | *** | Saving seen data "./dancer.seen" |
| 04:58:39 | | Quit planetbeing (Quit: planetbeing) |
| 05:00 |
| 05:00:19 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 05:02:23 | saratoga | kugel: default I think |
| 05:02:40 | kugel | good, I just did so :) |
| 05:02:46 | kugel | I updated the wiki |
| 05:03:18 | kugel | the results are puzzeling though |
| 05:04:07 | kugel | ah wait, I mixed something up |
| 05:06:12 | chrisb | advcomp2019: yes, the info on pluginmpegplayer is there |
| 05:06:20 | kugel | :'( |
| 05:06:29 | chrisb | advcomp2019: and the sansa e200 performance is surprisingly good |
| 05:08:21 | saratoga | kugel: fwiw this site recommends the 2009q1 build, which is still gcc4.3: http://hardwarebug.org/2009/08/05/arm-compiler-shoot-out/ |
| 05:09:10 | | Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) |
| 05:09:10 | | Quit Llorean (Changing host) |
| 05:09:10 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 05:09:27 | saratoga | though i guess the 4.4 version is probably better given our experience with gcc versions so far |
| 05:11:10 | kugel | ok,, now my results make more sense |
| 05:11:23 | kugel | it appears cs is even worse than plain gcc |
| 05:11:45 | kugel | saratoga: IIRC we've made tests with 4.3 |
| 05:11:51 | kugel | some codecs didn't work at all |
| 05:11:53 | saratoga | yeah i think they were a little worse |
| 05:11:56 | chrisb | how can the mpeg performance on sansa e200 be better than the iPods? |
| 05:12:04 | saratoga | smaller screen |
| 05:12:33 | saratoga | plus the e200v1 screen is really fast for some reason |
| 05:13:28 | kugel | dma behind the scenes |
| 05:14:18 | kugel | the lcd controller polls from a separate framebuffer automagically. lcd_update() and friends merely do a memcpy to that framebuffer, that's why it appears to fast |
| 05:14:22 | chrisb | screens have the same pixel count |
| 05:15:48 | scorche|sh | ipods have many different sized screens...perhaps you should clarify which one |
| 05:16:51 | saratoga | scorche|sh: can you give bohoon dev rights on the forum |
| 05:18:07 | scorche|sh | when i get home, sure...though if he sent me a pm or email, i would perhaps get to these things much sooner |
| 05:18:16 | saratoga | he probably doesn't know |
| 05:18:30 | saratoga | chrisb: assuming you mean the ipod photo, its probably just due to the screen speed |
| 05:19:35 | | Quit Strife89 (Quit: To bed!) |
| 05:19:40 | scorche|sh | saratoga: well, arent i mentioned twice in the commit access mail? ;0 |
| 05:19:53 | saratoga | yeah thats true |
| 05:19:54 | * | scorche|sh glares at his right parens key |
| 05:20:04 | saratoga | but this is the guy who didn't even contact us until he had the port basically finished |
| 05:20:30 | kugel | saratoga: I can do a test tomorrow, but you could do it yourself as well :) |
| 05:20:46 | kugel | just download their package, and at it to PATH. it's fairly trivial |
| 05:20:51 | | Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 05:20:56 | saratoga | kugel: yeah but i'm lazy and should be working |
| 05:21:02 | saratoga | i've basically lost faith in newer gcc though |
| 05:21:29 | saratoga | at this point we're pretty close to ASM'ing everything that matters on ARM anyway |
| 05:21:55 | kugel | well, looking at the results, we would've probably switched if flac wasn't so bad |
| 05:22:23 | chrisb | the sansa seems to be a bargain product with premium performance |
| 05:22:24 | kugel | you shouldn't forget the binsize decrease 4.4.x gives (a few K alone, about 60k on PP due to long calls removed= |
| 05:23:11 | | Quit planetbeing (Client Quit) |
| 05:24:11 | | Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 05:24:18 | kugel | the major codecs are better or the same, actually |
| 05:25:34 | kugel | it's really only flac which is so sad. the rest is fine |
| 05:26:03 | | Quit saratoga (Ping timeout: 252 seconds) |
| 05:26:50 | kugel | I would eventually switch right now, flac is fast enough anyway |
| 05:29:06 | | Quit anewuser () |
| 05:29:57 | | Quit planetbeing (Quit: planetbeing) |
| 05:30:06 | | Join wind [0] (~74030e7e@giant.haxx.se) |
| 05:32:00 | wind | I wonder how to make a english-Chinese dictionary. |
| 05:34:21 | | Quit kugel (Remote host closed the connection) |
| 05:36:43 | | Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) |
| 05:40:50 | | Quit Horscht (Quit: Verlassend) |
| 05:40:56 | chrisb | wind: that problem has been solved |
| 05:46:07 | | Part froggyman |
| 05:49:31 | | Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 05:53:14 | chrisb | is there any limit on the size of the SD card that sansa e200 rockbox can address? |
| 05:53:33 | chrisb | there seems to be a limit in the native firmware |
| 05:54:23 | S_a_i_n_t_ | The OF does not govern any of rockbox's behaviour |
| 05:56:26 | wind | chrisb:Sorry,I saw it just now.You say it had been solved,what's the meaning? |
| 05:56:53 | chrisb | wind: longman's english-chines dictionary exists |
| 05:57:15 | wind | Can I download? |
| 05:57:18 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.183) |
| 05:57:52 | wind | Could you give me a website? |
| 05:58:48 | | Quit S_a_i_n_t_ (Ping timeout: 245 seconds) |
| 05:59:14 | | Join S_A_I_N_T__ [0] (S_a_i_n_t@203.184.2.3) |
| 06:00 |
| 06:00:19 | chrisb | wind: i don't think that is available for download |
| 06:00:26 | | Quit S_a_i_n_t (Disconnected by services) |
| 06:00:35 | chrisb | http://sourceforge.net/projects/mengdict/ |
| 06:00:43 | | Nick S_A_I_N_T__ is now known as S_a_i_n_t (S_a_i_n_t@203.184.2.3) |
| 06:00:49 | wind | Thanks |
| 06:01:02 | wind | I will try |
| 06:01:28 | chrisb | http://cgibin.erols.com/mandarintools/cedict.html |
| 06:02:00 | wind | Oh,no.it's a Chinese to English electronic dictionary |
| 06:02:25 | wind | I just want a English to Chinese one. |
| 06:03:00 | wind | Thank you all the same. |
| 06:07:42 | | Quit LambdaCalculus37 (Quit: Fwump) |
| 06:13:37 | S_a_i_n_t | wind: I believe (with some effort on your behalf) it is possible to use dict.rock to create a language X/language Y dictionary |
| 06:13:52 | S_a_i_n_t | try the plugins page on the wiki |
| 06:22:08 | wind | S_a_i_n_t:I am doing it,but it's too large. |
| 06:23:23 | S_a_i_n_t | yes, I know...the wordnet files are pretty big. |
| 06:23:44 | S_a_i_n_t | Stardict is even bigger...the .dict file is 4.5 million lines. |
| 06:26:02 | wind | I have read the plugin page.But still confused. |
| 06:27:23 | wind | I think I have to chang the codes of dict.c to make it easy. |
| 06:31:19 | | Quit noob1 (Quit: CGI:IRC) |
| 06:31:22 | | Join noob1 [0] (~ad15ebf0@giant.haxx.se) |
| 06:39:24 | | Quit CaptainKewl (Read error: Connection reset by peer) |
| 06:51:15 | | Join CaptainKewl [0] (~jason@207.237.107.203) |
| 06:54:45 | | Quit JdGordon (Ping timeout: 245 seconds) |
| 06:58:06 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:01:45 | | Quit wind (Quit: CGI:IRC (Ping timeout)) |
| 07:04:13 | | Quit chrisb (Ping timeout: 245 seconds) |
| 07:07:55 | | Quit noob1 (Quit: CGI:IRC) |
| 07:10:45 | | Quit Tomis (Quit: Tomis) |
| 07:11:02 | | Join Tomis [0] (~Tomis@70.134.89.66) |
| 07:14:32 | | Join CaptainKewllllll [0] (~quassel@207.237.107.203) |
| 07:15:53 | | Quit CaptainKewllllll (Remote host closed the connection) |
| 07:29:43 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-soovbmllihzmnrkj) |
| 07:44:01 | | Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 07:44:01 | | Quit Zagor (Changing host) |
| 07:44:01 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 07:46:38 | | Quit mt (Ping timeout: 252 seconds) |
| 07:57:18 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 08:00 |
| 08:00:20 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 08:04:47 | | Quit CaptainKewl (Remote host closed the connection) |
| 08:08:20 | | Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net) |
| 08:10:07 | | Quit FlynDice (Remote host closed the connection) |
| 08:10:15 | | Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net) |
| 08:13:36 | | Quit mt (Ping timeout: 248 seconds) |
| 08:21:06 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:24:52 | | Quit Llorean (Read error: Connection reset by peer) |
| 08:27:48 | | Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net) |
| 08:28:20 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 08:28:30 | | Join stooo [0] (~sto@f050226099.adsl.alicedsl.de) |
| 08:28:41 | | Quit FlynDice (Ping timeout: 276 seconds) |
| 08:29:14 | | Quit stooo (Client Quit) |
| 08:29:55 | | Join patgodo [0] (~chatzilla@g225081210.adsl.alicedsl.de) |
| 08:55:23 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:58:09 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:00:19 | | Quit arbingordon (Ping timeout: 260 seconds) |
| 09:00:58 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 09:02:50 | | Part patgodo |
| 09:06:28 | | Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net) |
| 09:09:38 | | Quit n17ikh (Ping timeout: 276 seconds) |
| 09:14:56 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 09:15:12 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 09:19:32 | | Join gill0r_ [0] (~gill0r@f050132026.adsl.alicedsl.de) |
| 09:23:06 | | Quit gill0r (Ping timeout: 256 seconds) |
| 09:35:27 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 09:35:42 | | Quit planetbeing (Quit: planetbeing) |
| 09:35:42 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 09:40:24 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 09:46:36 | | Join Rob2222 [0] (~Miranda@p4FDCB621.dip.t-dialin.net) |
| 10:00 |
| 10:05:46 | amiconn | S_a_i_n_t: For most disks with hlarge physical sectors it's better to *remove* MAX_PHYS_SECTOR_SIZE |
| 10:06:10 | amiconn | Only disks with silly firmware need this workaround |
| 10:11:03 | | Join DerPapst [0] (~DerPapst@p4FE8F3B2.dip.t-dialin.net) |
| 10:28:13 | | Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr) |
| 10:31:35 | | Join xavieran [0] (~xavieran@ppp118-209-114-195.lns20.mel4.internode.on.net) |
| 10:36:24 | | Quit FlynDice (Remote host closed the connection) |
| 10:36:49 | | Quit DerPapst (Quit: Leaving.) |
| 10:37:52 | S_a_i_n_t | Ah well...bit late for that now. I assume the build is working, as the guy I built it for seems pretty happy. |
| 10:38:35 | | Quit pamaury (Quit: Quitte) |
| 10:39:37 | | Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr) |
| 10:44:26 | | Quit pamaury (Client Quit) |
| 10:49:39 | | Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr) |
| 10:58:13 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:00:54 | S_a_i_n_t | What're the chances of the theme site being able to use the .7z extension? My latest theme is half the size of the zip on the themesite when its in 7z format (which I keep all my themes in locally) and the 7z versions I keep include the fonts as well yet are still ~50% of the size of the zip (without fonts)... |
| 11:04:28 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 11:09:09 | rasher | S_a_i_n_t: unlikely to happen anytime soon. Would require quite a few changes on the themesite and in rbutil, and the gains are minimal |
| 11:11:18 | amiconn | S_a_i_n_t: It also works if you increase MAX_PHYS_SECTOR_SIZE, but performance is worse than if you remove it |
| 11:11:43 | * | S_a_i_n_t did not know this... |
| 11:12:00 | amiconn | MAX_PHYS_SECTOR_SIZE is only necessary if the drive's firmware is unable to split and join large sectors itself. If it does, it does so better than rockbox |
| 11:12:21 | S_a_i_n_t | I did ask, but I needed to knock it up pretty quickly...(as even when you're helping people, they get impatient). |
| 11:12:57 | amiconn | This is why it was added - the original hdd of the 80GB iPod Video is unable to do this itself |
| 11:13:18 | | Quit mt (Ping timeout: 240 seconds) |
| 11:14:15 | amiconn | The proper solution would be probing, but that needs to be done by someone with an 80GB G5.5, preferably also having access to one of the larger disks which handle things themselvs |
| 11:15:46 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 11:21:42 | | Join mischasworld [0] (~quassel@g227018115.adsl.alicedsl.de) |
| 11:32:05 | | Join Hellfish [0] (~chatzilla@lo-2-vpn8.matrix.farlep.net) |
| 11:32:33 | | Quit Hellfish (Client Quit) |
| 11:33:23 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
| 11:39:28 | | Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 11:42:24 | | Quit m3dlg (Ping timeout: 264 seconds) |
| 11:42:59 | | Quit doomcup (Ping timeout: 264 seconds) |
| 11:49:18 | * | amiconn points Zagor to http://www.rockbox.org/irc/log-20100308#02:09:40 |
| 11:49:26 | | Join doomcup [0] (~doomcup@c-24-22-223-47.hsd1.wa.comcast.net) |
| 11:54:42 | Zagor | hmm, I wonder why the front page stopped updating |
| 11:54:47 | | Join Sajber^ [0] (~Sajber^@93-73.anonymous.at.anonine.com) |
| 11:54:58 | | Quit stoffel (Ping timeout: 240 seconds) |
| 11:55:28 | | Quit Sajber^ (Read error: Connection reset by peer) |
| 11:55:28 | Zagor | oh, it didn't |
| 11:55:49 | Zagor | amiconn: /gcc updated |
| 11:55:53 | | Join Sajber^ [0] (~Sajber^@93-73.anonymous.at.anonine.com) |
| 11:58:37 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 11:59:19 | amiconn | Thanks |
| 12:00 |
| 12:00:21 | | Quit Battousai (Read error: Operation timed out) |
| 12:02:05 | | Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) |
| 12:03:36 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 12:05:27 | | Quit Tomis (Quit: Tomis) |
| 12:07:09 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 12:08:42 | | Quit mischasworld (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 12:14:25 | | Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 12:17:03 | | Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net) |
| 12:17:28 | | Join m3dlg [0] (~m3dlg@212.183.140.6) |
| 12:27:59 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 12:41:29 | | Quit teru (Quit: Quit) |
| 12:42:04 | | Quit m3dlg (Quit: RAGE QUIT) |
| 12:54:37 | | Quit moos (Ping timeout: 252 seconds) |
| 12:57:27 | | Quit Kitar|st () |
| 12:58:17 | *** | Saving seen data "./dancer.seen" |
| 12:59:01 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 13:00 |
| 13:03:45 | | Join Casainho [0] (~chatzilla@87.196.54.156) |
| 13:05:53 | | Join perfectdrug_ [0] (~marko@p5B0EC53B.dip.t-dialin.net) |
| 13:08:12 | | Join Kitar|st [0] (Kitr88@89.142.235.223) |
| 13:08:31 | CIA-5 | New commit by nls (r25068): Use the same output func for wav writing and checksum calculation, simplifying the code and possibly speeding up checksum calculation slightly |
| 13:08:52 | | Quit stoffel (Ping timeout: 246 seconds) |
| 13:09:37 | | Quit perfectdrug (Ping timeout: 245 seconds) |
| 13:11:43 | | Quit tari (Quit: Leaving) |
| 13:11:58 | | Join gibbon_ [0] (gibbon_@not.a.servant4you.org) |
| 13:27:58 | | Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net) |
| 13:31:34 | | Quit gill0r_ (Remote host closed the connection) |
| 13:42:12 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 13:47:36 | | Join Farthen [0] (~chatzilla@e179232245.adsl.alicedsl.de) |
| 13:50:38 | | Quit n1s (Ping timeout: 265 seconds) |
| 13:55:06 | | Quit GeekShadow (Ping timeout: 256 seconds) |
| 13:55:20 | | Quit Farthen (Ping timeout: 260 seconds) |
| 14:00 |
| 14:00:08 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 14:00:25 | CIA-5 | New commit by pamaury (r25069): - Fix the control_handler selection in usb_core when a request in sent to an endpoint (use endpoint dir and not EP_CONTROL !) ... |
| 14:02:15 | | Quit ecio1 (Ping timeout: 260 seconds) |
| 14:04:50 | | Part flyback |
| 14:07:44 | | Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 14:09:19 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:09:22 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 14:18:46 | | Quit stoffel (Remote host closed the connection) |
| 14:20:11 | TheSeven | pamaury: could that be related to the hid trouble we're seeing? |
| 14:20:32 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.33) |
| 14:21:24 | | Quit S_a_i_n_t (Ping timeout: 258 seconds) |
| 14:26:25 | | Join nima [0] (~nima@adsl-75-45-230-107.dsl.sfldmi.sbcglobal.net) |
| 14:29:16 | | Quit nimak (Ping timeout: 268 seconds) |
| 14:29:50 | | Join Schmogel [0] (~Miranda@p3EE21F1B.dip0.t-ipconnect.de) |
| 14:31:49 | pamaury | don't think so but you can check |
| 14:32:11 | pamaury | this is more a sanity check and this is needed for a (possibly) upcoming usbaudio driver |
| 14:32:45 | pamaury | what is the hid trouble ? You mean hid during ums transfer has some trouble ? |
| 14:46:02 | | Join froggymana [0] (~187b533e@giant.haxx.se) |
| 14:56:28 | | Quit ecio (Ping timeout: 260 seconds) |
| 14:57:18 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 14:57:19 | | Quit pixelma (Disconnected by services) |
| 14:57:22 | | Quit amiconn (Disconnected by services) |
| 14:57:24 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 14:57:36 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 14:57:50 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 14:58:01 | | Nick perfectdrug_ is now known as perfectdrug (~marko@p5B0EC53B.dip.t-dialin.net) |
| 14:58:20 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:02:26 | | Quit gibbon_ (Quit: Lost terminal) |
| 15:05:35 | | Join gibbon_ [0] (gibbon_@not.a.servant4you.org) |
| 15:06:05 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 15:10:18 | TheSeven | pamaury: HID also has trouble during enumeration, which windows usually works around in some way, but it causes massive trouble on linux |
| 15:11:39 | pamaury | really ? which troubles ? I'm not sure I ran into those problems |
| 15:16:25 | | Quit DerPapst (Read error: Connection reset by peer) |
| 15:18:18 | | Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) |
| 15:19:03 | TheSeven | they could also be nano2g driver problems... |
| 15:19:17 | TheSeven | i can't test right now as I'm running a battery bench |
| 15:19:18 | | Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com) |
| 15:20:04 | TheSeven | btw. what's the opinion on storage speedups that cause high additional memory usage? |
| 15:20:31 | | Quit jgarvey (Client Quit) |
| 15:20:45 | TheSeven | (depending on the kind of optimization this may be in the range of 8KB to 1MB) |
| 15:21:06 | Zagor | TheSeven: usb storage or rockbox use storage? |
| 15:21:10 | TheSeven | both |
| 15:21:19 | pamaury | how ? |
| 15:21:31 | linuxguy3 | how do i differentiate between a fuze v1 and v2 |
| 15:21:34 | linuxguy3 | without opening it |
| 15:21:50 | Torne | firmware version 1.x is a fuze v1, firmware 2.x is a fuze v2 |
| 15:21:52 | TheSeven | parallelizing reads/writes to different banks in the NAND driver and FTL |
| 15:21:53 | | Quit robin0800 (Remote host closed the connection) |
| 15:22:06 | TheSeven | and possibly memory-buffering scattered page commits |
| 15:22:12 | Zagor | TheSeven: more usb speed is always good. do we have any use case where we'd notice in rockbox use? |
| 15:22:36 | TheSeven | probably not, but only doing it part of the time won't work well |
| 15:22:59 | TheSeven | (if you're planning to steal the additional memory from the audio buffer :-) ) |
| 15:24:31 | Zagor | since this is for flash targets, I can't see why not. it's not like we'll be spinning up the drive more often. |
| 15:27:06 | | Join ecio [0] (~ecio@adsl-065-081-069-051.sip.mco.bellsouth.net) |
| 15:27:24 | linuxguy3 | Torne: thx |
| 15:47:18 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:48:02 | | Quit Casainho (Read error: Operation timed out) |
| 15:49:13 | CIA-5 | New commit by kugel (r25070): Update rockboxdev.sh/configure for arm-elf-eabi-gcc 4.4.3 and binutils 2.20.1. ... |
| 15:50:33 | kugel | TheSeven: good question! I also have a patch for sansa ams which increases transfer speed at the expense of ram usage |
| 15:51:54 | kugel | I would like to invite everybody to answer to my proposal on the mailing list! :) |
| 15:52:43 | * | linuxstb only uses FLAC.... ;) |
| 15:52:52 | linuxstb | What's "a good deal slower" ? |
| 15:53:17 | * | linuxstb should probably rtfw |
| 15:53:53 | | Quit froggymana (Quit: CGI:IRC) |
| 15:54:16 | Zagor | kugel: commit first, then discuss? |
| 15:55:11 | kugel | Zagor: hehe, no :) I just updated what has already been there (you can since a while select an optional eabi toolchain in rockboxdev.sh/configure) |
| 15:55:21 | kugel | my mail is about changing our default toolchaib |
| 15:55:26 | kugel | chain* |
| 15:55:40 | Zagor | ah |
| 15:55:51 | linuxstb | kugel: I was also confused by your commit message - it sounded like you had changed it to use arm-elf-eabi, rather than change the version for arm-elf-eabi... |
| 15:55:54 | | Join knine [0] (~kaniini65@dyn75-70.yok.fi) |
| 15:56:11 | Zagor | kugel: it sounds good to me. what does "a good deal slower" for flac mean more specifically? |
| 15:56:21 | linuxstb | Zagor: IIUC, about 10% slower |
| 15:56:30 | kugel | I linked to the wiki page, didn't I? :) |
| 15:56:41 | Zagor | oh, you did :) |
| 15:56:46 | linuxstb | "about 10% slower" is less to type than "a good deal slower"... |
| 15:57:02 | kugel | more 8-9%, but it's still a good deal |
| 15:57:32 | kugel | but I'm inclined to believe that due to the massive ram usage win, flac will still be a netto win w.r.t to battery runtime |
| 15:57:34 | linuxstb | "a good deal" is subjective. |
| 15:57:43 | Zagor | at 593% realtime, we can live with it |
| 15:57:52 | kugel | flac is so fast, this 10% don't really matter. it runs unboosted on all targets anyway |
| 15:58:11 | linuxstb | But anyway, I think you should go ahead as well - now is a good time as we've just done a release. So it gives a while for any bugs to be found. |
| 15:58:32 | kugel | but 60k more ram may have an influence on the battery runtime, especially on typically large flac files |
| 15:59:23 | | Quit kaniini (Ping timeout: 260 seconds) |
| 15:59:28 | Zagor | kugel: just out of curiosity, what distros ship cross compilers? |
| 15:59:34 | * | kugel probably should've linked to http://www.rockbox.org/wiki/CodecPerformanceComparison#EABI_New_gcc_results directly |
| 15:59:40 | linuxstb | kugel: Have you tested the AMS dualboot code with the eabi toolchain? |
| 16:00 |
| 16:00:31 | kugel | no, not really. but is there really a chance that different code is generated in pure assembly? |
| 16:01:17 | * | linuxstb trusts nothing when it comes to gcc |
| 16:01:30 | kugel | yea, but this isn't gcc. it's gas :) |
| 16:01:30 | | Part LinusN |
| 16:01:54 | kugel | it's possible that the flac speed drop comes from a gcc decision to not inline some functions. if we spot those we might be able to recover flac |
| 16:03:02 | | Quit linuxguy3 (Ping timeout: 276 seconds) |
| 16:03:33 | | Join linuxguy3 [0] (~timj@adsl-75-57-163-104.dsl.emhril.sbcglobal.net) |
| 16:03:45 | mc2739 | kugel: I would be happy to test on my e200v2 if you can build a bootloader and mkamsboot for me. If there is a problem, the e200v2 is recoverable and I have recovered it in the past. |
| 16:05:28 | TheSeven | erm, actually you could just build the code with both toolchains and compare the resulting binary. if it's only assembly code, it should be identical |
| 16:05:45 | kugel | Zagor: I was under the impression that at least debian has a crosscompiler .deb, but I can't find it right now. |
| 16:05:57 | kugel | TheSeven: that's my thinking too |
| 16:06:13 | kugel | mc2739: ok, give me a few seconds :) |
| 16:10:17 | | Join merbanan [0] (~banan@c-94-255-221-92.cust.bredband2.com) |
| 16:14:03 | amiconn | TheSeven: Speeding up things by caching should *imo* only be done if it doesn't reduce reliability |
| 16:14:08 | kugel | the size and md5sum of the dualboot binaries is the same, at least |
| 16:14:25 | kugel | nrv2e_d8.arm-bin is different, though (2 byte smaller) |
| 16:14:52 | TheSeven | amiconn: it's just using bigger internal buffers to speed up multi-page writes by writing 4 pages at once |
| 16:15:01 | amiconn | A sudden poweroff is dangerous if you do write caching |
| 16:15:42 | TheSeven | (and possibly buffer a whole flash block in memory during copying operations, if that yields enough speed gain to justify the memory usage) |
| 16:16:17 | TheSeven | a sudden poweroff will have the same effects without that kind of caching |
| 16:16:40 | TheSeven | (and it should be 100% recoverable by nandfsck) |
| 16:16:43 | amiconn | That's why the scatter/gather buffer to support 512-byte accesses on the MK8011GAH (ipod G5.5) always writes immediately |
| 16:17:31 | TheSeven | it won't write 4 times if it's told to write a contiguous 2KB block though, huh? |
| 16:17:41 | kugel | erm, my system doesn't have 'cc' :/ |
| 16:17:43 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 16:17:52 | TheSeven | make CC=gcc |
| 16:18:25 | TheSeven | (at least if the makefile is somewhat sane) |
| 16:18:26 | kugel | sure but I should have cc :) |
| 16:18:51 | amiconn | TheSeven: Physical sectors are 1K on that disk. If you write sequentially using 512 byte blocks, the rockbox code will read 1KB, replace first half, write 1KB, read the same 1KB again, replace second half, write 1KB again |
| 16:19:26 | TheSeven | even if that's done in a single write call? |
| 16:19:39 | amiconn | no |
| 16:19:59 | amiconn | But some code in rockbox uses 512 byte buffers |
| 16:20:10 | TheSeven | some code, but probably not USB transfers |
| 16:20:19 | TheSeven | actually, to buffer those, i wouldn't need any additional memory |
| 16:20:20 | amiconn | No, those *nver* do |
| 16:20:44 | TheSeven | the place where i need the memory is for internal copying-around operations in the FTL |
| 16:20:44 | amiconn | Since the G5.5 presents 2048 byte sectors on the wire, it will never happen |
| 16:21:46 | amiconn | What's especially nasty about sector gathering is that the disk firmware doesn't expect a subsequent write to the *same* sector, so that causes an internal seek |
| 16:22:39 | amiconn | Rockbox doesn't write too often, so I don't think it's a problem. And large writes (e.g. when copying files) aren't affected |
| 16:23:20 | amiconn | This could be solved by caching, but only if we limit the cache-dirty time |
| 16:23:23 | TheSeven | and exactly these could be sped up by a factor of up to 4 depending on the flash on nano2g |
| 16:23:47 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.167) |
| 16:24:39 | amiconn | That would require the ata thread to do the cache flush, but two threads are writing at the same time, i.e. that requires careful locking |
| 16:25:35 | | Quit S_a_i_n_t_ (Ping timeout: 264 seconds) |
| 16:26:01 | amiconn | What amount of ram are we talking about on the Nano G2? |
| 16:26:30 | TheSeven | depending on the way we do it, it'll be from 8K to 1M |
| 16:27:40 | TheSeven | 8K should already yield a significant speedup |
| 16:31:23 | linuxstb | kugel: nrv2e_d8.arm-bin is thumb code, so probably the eabi toolchain doesn't pad it to a multiple of 4 bytes. I can't remember, but it's possible that may cause an issue (e.g. if mkamsboot assumes it is a multiple of 4 bytes) |
| 16:31:50 | kugel | yea, you're right. it's lacking 2 bytes of zero padding |
| 16:32:11 | amiconn | How much ram does the Nano G2 have, again? It's not listed on http://www.rockbox.org/wiki/DeviceChart |
| 16:32:56 | Torne | amiconn: it still seems like it woul dbe nicer to have fat support large sectors |
| 16:33:19 | amiconn | FAT does support large sectors, that's not the problem |
| 16:33:49 | TheSeven | 32MB |
| 16:34:04 | Torne | hrm? |
| 16:34:32 | TheSeven | Torne: the problem only exists if the FAT sector size is smaller than the disk minimum-write unit |
| 16:34:35 | linuxstb | kugel: And I think this will cause a problem - mkamsboot builds the image backwards, starting with the ucl unpack function. So if that's not a multiple of 4, all the earlier data will be unaligned. |
| 16:34:50 | Torne | TheSeven: yes, but that's fine on 5.5g isn't it? |
| 16:35:11 | TheSeven | that should be fine, as long as you don't use weird disks that need 4K writes |
| 16:35:30 | Torne | my point is that if our FAT code supports large sectors you can just format the disk with 4k sectors |
| 16:35:39 | Torne | and then you don't need the read/modify/write code, no? |
| 16:35:45 | Torne | i thought we didn't have the code to do that |
| 16:35:47 | amiconn | The disks with 4K physical sectors known so far have proper partial sector handling |
| 16:35:51 | Torne | well whatever size |
| 16:35:53 | kugel | is there an gas statement to enforce padding? |
| 16:35:57 | linuxstb | kugel: Possibly the easiest fix is to change bin2c to pad to a multiple of 4 bytes. |
| 16:35:58 | TheSeven | .align |
| 16:36:14 | Torne | and even if the disk *does* have proper partial sector handling it's still better to format it with larger sectors and obey that in the fat code, no? will be faster. |
| 16:36:14 | TheSeven | this is a 2^n value, so you'll probably want to do .align 2 |
| 16:36:24 | Torne | am i missing something? |
| 16:36:31 | TheSeven | OF support? |
| 16:36:56 | kugel | it's 8 bytes bigger now with .aign 4 at the end |
| 16:37:05 | TheSeven | [16:35]<TheSeven>this is a 2^n value, so you'll probably want to do .align 2 |
| 16:37:12 | amiconn | TheSeven: I think that on a flash target with such a large amount of RAM, you should really spend that extra ram to improve speed |
| 16:37:19 | amiconn | Especially if it's just 8KB |
| 16:37:36 | Torne | TheSeven: I was assuming that the OF's fat implementation doesn't mind large sector sizes either |
| 16:37:39 | TheSeven | yes, i'll do the 8K one for sure, but I'm not sure if the 1M one makes sense |
| 16:37:51 | Torne | TheSeven: since even quite obscure fat implementations i've seen get it right |
| 16:38:07 | Torne | in fact i was assuming that itunes, if it had any sense, would format the player with larger sectors anyway |
| 16:38:18 | * | TheSeven is paranoid about apple fat implementations since he spotted that hex bug yesterday |
| 16:38:33 | kugel | TheSeven: thanks, I didn't see that remark. the zero padding is now a nop, it should be fine I guess? |
| 16:38:38 | linuxstb | kugel: I think it's safer/cleaner to make bin2c handle the alignment. |
| 16:38:43 | amiconn | Torne: It has to, since it has no choice if the disk is presented as having 2K sectors via usb |
| 16:38:53 | Torne | amiconn: er |
| 16:38:55 | linuxstb | Or at least, it should check that all input files are a multiple of 4. |
| 16:38:58 | Torne | amiconn: i think we're talking cross purposes |
| 16:39:13 | Torne | amiconn: i am talking about the BPB of the FAT filesystem actually listing ht esector size as being whatever the disk's real sector size is |
| 16:39:20 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
| 16:39:22 | Torne | i.e. clusters being in multiples of 1024 bytes or whatever, instead of 512 bytes |
| 16:39:29 | TheSeven | *does* the apple OF use 2K sectors via USB? |
| 16:39:41 | Torne | that has nothing to with USB, unless i'm very much misundertanding |
| 16:39:54 | amiconn | TheSeven: On the iPod Video G5.5 - yes. On all older ipods - no |
| 16:40:21 | TheSeven | Torne: if the USB driver presents the device to the host as having 2K blocks, the host just can |
| 16:40:30 | TheSeven | can't go below that with it's fat sector size |
| 16:40:37 | amiconn | Torne: It has very much to do with it. Windows cannot handle a fat partition when the logical sector size differs from the physical sector size (as presented via usb or other interface) |
| 16:40:57 | Torne | ..er, but that's fine, no? |
| 16:41:02 | amiconn | On linux you can use 2^n multiples, but not fractions |
| 16:41:07 | Torne | my point was that we want it to be that big.. |
| 16:41:16 | TheSeven | amiconn: even if it's bigger? |
| 16:41:17 | Torne | so if it is already that big, and our fat code handles it being tha tbig.. |
| 16:41:26 | Torne | then why do we need the code in the ata driver to handle it? |
| 16:41:30 | TheSeven | then we'll need to stick with the of values if we want to be compatible |
| 16:41:43 | Torne | we shouldn't be generating unaligned accesses anyway, surely |
| 16:42:07 | TheSeven | Torne: because changing that opens a can of stkov's |
| 16:42:21 | amiconn | Torne: Again, our fat code handles large *logical* sector sizes |
| 16:42:32 | amiconn | That has nothing to do with access sizes. |
| 16:42:33 | TheSeven | we're currently trying to clean that out on the nano2g, which actually *does* present 2K-sectors to the FAT code |
| 16:43:20 | Torne | amiconn: Yes, that was what I was asking. Why don't we use the sector size as the access size? that's what it's for. are there really that many places where it's on the stack? (this seems odd) |
| 16:43:36 | amiconn | There are several reasons |
| 16:43:49 | amiconn | Stack usage, and ram usage |
| 16:44:17 | TheSeven | and some hardwired 512 values at some places, which are hopyfully all caught by now |
| 16:44:38 | amiconn | When support for the G5.5 was added, the first approach was to increase the buffers. This resulted in great instability (probably stack overflows) |
| 16:44:44 | Torne | isn't there just one buffer in the fat code? |
| 16:44:45 | linuxstb | Are people still reporting stack overflows on the Nano2G? |
| 16:44:52 | TheSeven | yes |
| 16:45:03 | TheSeven | pictureflow, rockboy and some game are still stkov'ing |
| 16:45:20 | linuxstb | What about dircache or the database? |
| 16:45:27 | TheSeven | those apparently work fine |
| 16:45:31 | amiconn | Torne: No. Every file descriptor has a several buffers for various purposes. |
| 16:45:42 | TheSeven | (dircache was fixed to not have sector buffers on the stack by pamaury some weeks ago) |
| 16:45:49 | | Join CaptainKewllllll [0] (~2669ecc2@gateway/web/freenode/x-fyxcglrbqvywkrui) |
| 16:46:08 | linuxstb | TheSeven: Ah OK. I didn't notice that dircache fix. |
| 16:46:51 | * | pixelma is somehow reminded of the broken "properties" on coldfire |
| 16:46:59 | Torne | amiconn: hm, ok, so that's one per fd looking at file.c |
| 16:47:11 | Torne | anyway, yes |
| 16:47:44 | TheSeven | ah, and battery bench is also stkov'ing with the default stack size, for whatever reason |
| 16:47:46 | Torne | i just don't see why there is a need for them to be on the stack ever, or that we need so many of them that having them in .data would be unreasonable.. |
| 16:47:58 | kugel | linuxstb: alright. I get identical dualboot output now |
| 16:48:41 | pamaury | linuxstb: r24708 |
| 16:49:46 | kugel | linuxstb: I verified that the bin2c change still produces the same output with the old toolchain. should I just commit that regardless? |
| 16:50:22 | linuxstb | kugel: Yes, I think so - it's a sensible thing to check. |
| 16:50:28 | amiconn | Torne: That's for files. Check dir_uncached.h and fat.h how many buffers *one* open dir needs: It's 6 sector-sized buffers |
| 16:50:50 | linuxstb | kugel: So are you padding in bin2c or giving an error if the size isn't a multiple of 4? |
| 16:50:52 | kugel | http://pastie.org/859675 is the diff |
| 16:50:57 | kugel | the former |
| 16:52:22 | linuxstb | You could just use a memset instead of the for() loop... And your "/* Append 0" comment isn't closed. |
| 16:53:07 | kugel | it is with the next line, but I didn't mean to add a comment there anyway |
| 16:53:54 | Torne | amiconn: ok i have to ask, why do we cache three sectors per dirent? |
| 16:54:00 | Torne | that seems like a weird number |
| 16:54:28 | kugel | I didn't think of memset :) |
| 16:55:45 | amiconn | I think it has to do with the maximum number of slots a longname entry can occupy |
| 16:57:45 | Torne | amiconn: Aha |
| 16:58:01 | Torne | In which case, that's not as bad as you claim |
| 16:58:09 | amiconn | hmm? |
| 16:58:19 | Torne | it's three because you might need 640 bytes for a LFN entry |
| 16:58:23 | *** | Saving seen data "./dancer.seen" |
| 16:58:32 | Torne | i guess 672 with the actuall 8.3 entry as well |
| 16:58:39 | Torne | if your sector size is 2048 then you only need one :) |
| 16:58:42 | Torne | er, two |
| 16:58:46 | amiconn | Yes, so you could reduce it to two with 1K or larger sectors |
| 16:59:06 | amiconn | But you can't go below two regardless how large the sectors are |
| 16:59:24 | amiconn | ...since an entry can always cross a sector boundary |
| 16:59:54 | Torne | well yeah |
| 17:00 |
| 17:00:25 | amiconn | But supporting larger sectors in the fat code natively does not only require making the sectors larger, it also requires making the logical sector size dynamic |
| 17:01:12 | Torne | yeah |
| 17:01:14 | Torne | i realise |
| 17:01:19 | Torne | i just can't help but think that'd be better.. |
| 17:01:26 | amiconn | The rockbox binary is the same for G5 (with 512 byte logical sectors) and G5.5 (with 2048 byte logical sectors) |
| 17:01:58 | Torne | (also you really don't need to keep 3 sectors *around* per directory) |
| 17:02:12 | Torne | you need to have enough sectors to read a LFN for one call to getnext() |
| 17:02:19 | Torne | but there's only really any point in caching the last one |
| 17:02:29 | amiconn | And you still need partial sector support in the ata driver, because a fat with 512 byte logical sectors must be handled even if the disk has 4K physical sectors |
| 17:02:42 | Torne | so you could do it with one sector per open dir, and two sectors globally |
| 17:02:50 | Torne | (i think) |
| 17:04:08 | TheSeven | you just revealed a huge waste of memory on the nano2g :-) |
| 17:05:06 | amiconn | The current way of supporting large logical sectors is quite simple. Just multiply all sector counts in the bpb by (sector_size/512) |
| 17:05:10 | CIA-5 | New commit by kugel (r25071): Make bin2c ensure that the generated C arrays are 32bit aligned. Building nrv2e_d8 with the eabi toolchain breaks this assumption |
| 17:05:13 | CIA-5 | New commit by kugel (r25072): Make it easier to change the toolchain in the dualboot Makefile. |
| 17:05:18 | amiconn | -> You can keep using 512 byte sectors and everything works |
| 17:05:19 | Torne | TheSeven: I guess, if I'm right :) |
| 17:05:47 | amiconn | The only hackish thing that still remains is the method to find the partition (in disk.c) |
| 17:06:27 | Torne | the code in fat_getnext wants to be able to read the whole LFN so it needs to have enough for the 672-byte entry to span the maximum number of sectors, but when you're reading the entries in order you can only ever need to go forwards |
| 17:06:45 | Torne | either the last sector you read into the cache contains the next entry, or no sector in the cache does, surely |
| 17:07:03 | | Quit merbanan (Ping timeout: 260 seconds) |
| 17:07:15 | amiconn | Iirc the longname entries are stored in reverse order |
| 17:08:09 | Torne | yes |
| 17:08:17 | TheSeven | which is even better, as we'll know the size of them when reading the first one |
| 17:08:19 | Torne | it's the lfn entries in reverse order, then the 8.3 entry |
| 17:08:24 | kugel | any idea what "warning: section `.bss' type changed to PROGBITS" means? |
| 17:08:51 | Torne | amiconn: but the entries for a given file are always contiguous |
| 17:09:02 | amiconn | Yes, they have to |
| 17:09:12 | Torne | amiconn: so to read the next entry you at most need to start from the entry after the last file |
| 17:09:25 | Torne | and thus you won't ever re-use the data in the first two sectors of the cache. |
| 17:10:06 | TheSeven | kugel: yes, it means that the bss will be included in the output file, for whatever reason |
| 17:10:19 | amiconn | You first need to find the shortname entry, then go backwards |
| 17:10:52 | | Join kugel_ [0] (~kugel@e178065160.adsl.alicedsl.de) |
| 17:10:53 | Torne | amiconn: yes, and? |
| 17:11:03 | | Quit kugel (Disconnected by services) |
| 17:11:05 | Torne | i'm not saying you need less memory total *in fat_getnext* |
| 17:11:06 | | Nick kugel_ is now known as kugel (~kugel@e178065160.adsl.alicedsl.de) |
| 17:11:08 | amiconn | You will need up to two sectors before the one containing the shortname |
| 17:11:08 | Torne | just over the whole system |
| 17:11:11 | | Quit kugel (Changing host) |
| 17:11:11 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:11:19 | Torne | fat_getnext needs to have 672+change bytes of data |
| 17:11:27 | Torne | but you don't need to keep all of it between invocations |
| 17:11:27 | amiconn | (with 512 byte sectors) |
| 17:11:29 | TheSeven | amiconn: actually, can't we just keep a 672 byte buffer, read the sectors and copy everything belonging to the lfn into that buffer, and then doing the further work on that lfn buffer instead of the raw sector buffer? |
| 17:11:51 | Torne | amiconn: My point is you can make do with one sector of cache per dir, no matter the sector size |
| 17:12:05 | Torne | amiconn: and one global buffer big enough for the extra sectors you need while inside fat_getnext |
| 17:12:11 | Torne | which is less memory overall |
| 17:12:12 | amiconn | I didn't write this code - it's mostly LinusN's work it seems |
| 17:12:26 | Torne | i wasn't asserting you did :) |
| 17:12:38 | Torne | it's slightly more complicated to do it that way, maybe |
| 17:12:43 | Torne | but maybe not really |
| 17:12:54 | amiconn | You'll hit the disk quite a bit more often with that scheme, if there's more than one dir open |
| 17:13:08 | Torne | i don't see how.. |
| 17:13:16 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.1) |
| 17:13:29 | Torne | when you go into fat_getnext you start by looking at the one-sector cache for that dir |
| 17:13:35 | Torne | if that's not enough you read one or two more sectors into the lgobal buffer |
| 17:13:46 | Torne | when you are done you memcpy() the last sector into the cache |
| 17:13:56 | Torne | it does the memcpy() anyway |
| 17:14:08 | amiconn | If you have one global buffer, and then two threads read one dir each, the global buffer contents would have to go back & forth between the two dirs |
| 17:14:26 | Torne | hm? no, the global buffer only ever sees new sectors |
| 17:14:33 | Torne | you never re-read the same sectors unless you restart iterating over the dir |
| 17:14:33 | | Quit S_a_i_n_t (Ping timeout: 246 seconds) |
| 17:14:38 | Torne | exactly the same as now |
| 17:15:29 | * | amiconn somehow can't follow |
| 17:15:45 | Torne | only the first sector of the *current* cache is reused between calls, ever |
| 17:15:59 | Torne | at the end of fat_getnext() it memcpy's the sector it read up to over th ebeginning |
| 17:16:18 | TheSeven | Torne: it can be further optimized to one sector per dir and 640 bytes globally |
| 17:16:36 | amiconn | hmm |
| 17:16:54 | | Join chrisb [0] (~chrisb@pool-98-111-153-193.phlapa.east.verizon.net) |
| 17:17:19 | | Quit kugel (Ping timeout: 260 seconds) |
| 17:17:35 | chrisb | from ffmpeg's perspective, is ogg basically just flac now? |
| 17:17:53 | TheSeven | you'd just read the dir sequentially using as single sector buffer (which won't cause more disk reads), and if you hit lfn stuff, just copy it into the 640 byte buffer until you hit the short entry, and then use the 64 byte buffer to analyze the rest of the entry |
| 17:18:04 | amiconn | I wonder why dir_uncached.c needs another fat_dir structure for the parent dir |
| 17:18:28 | chrisb | ffmpeg -i <file.flv> -vn -ac 2 -ar 44100 filename.ogg gives a flac file in an ogg container |
| 17:21:01 | * | amiconn also wonders whether a global lru sector buffer for both dir and file access would be better |
| 17:21:16 | amiconn | This could then be tuned for lowmem and bigmem targets independently |
| 17:22:11 | TheSeven | lru? you mean mru? |
| 17:22:40 | | Join kugel [0] (~kugel@e178080201.adsl.alicedsl.de) |
| 17:22:41 | | Quit kugel (Changing host) |
| 17:22:41 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:23:00 | kugel | TheSeven: it seems there's a bit of initialized data in it (e.g. current_tick = 0). .ibss is causing it |
| 17:23:02 | TheSeven | well, that way we could get rid of everything besides one sector buffer and one 640 byte buffer on lowmem |
| 17:23:10 | kugel | if I move .ibss to .data it doesn't show the warning |
| 17:23:33 | TheSeven | isn't there .idata or something for that purpose? |
| 17:25:47 | amiconn | Torne: Hmm, one global buffer won't work in a multithreaded environment, even with cooperative threading, as used in rockbox |
| 17:26:05 | TheSeven | why not? |
| 17:26:18 | TheSeven | there must be locking for the mru buffer of course |
| 17:26:20 | amiconn | What if two threads are reading dirs at the same time? |
| 17:26:32 | amiconn | Disk access yields on many targets |
| 17:26:54 | TheSeven | the other threads wanting to read will be blocked |
| 17:27:05 | amiconn | Yes, a global mru cache would need locking |
| 17:27:24 | TheSeven | and yes, this *will* cause thrashing, but well, it's a speed vs. memory tradeoff |
| 17:27:28 | amiconn | This could be done per entry, so other threads would not need to be blocked |
| 17:28:03 | amiconn | But even the current scheme can be improved. Instead of using 3 sector buffers per dir, just use one plus a 640 byte buffer |
| 17:28:32 | linuxstb | chrisb: This is #rockbox... ;) |
| 17:28:44 | TheSeven | how many of those dir structs are there usually? |
| 17:28:58 | TheSeven | this means a 3.4K mem gain for *each* of them on nano2g |
| 17:28:59 | | Quit kugel (Ping timeout: 260 seconds) |
| 17:30:21 | amiconn | MAX_OPEN_DIRS ones, with is either 8 or 12 |
| 17:30:42 | amiconn | Oh, and each has *two* fat_dir entries |
| 17:31:13 | amiconn | For the dir itself and its parent, which I'm not sure why it's necessary |
| 17:31:25 | | Join Omlet [0] (omlet05@162.154-200-80.adsl-dyn.isp.belgacom.be) |
| 17:31:49 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:31:58 | kugel | TheSeven: yes |
| 17:32:17 | pamaury | amiconn: dir_uncached.c needs it to update the entry when metadata change but in reality it's not strictly needed. I thought I commit to change this, perhaps I forgot |
| 17:32:25 | pamaury | Or perhaps I ran into a problem doing this |
| 17:34:11 | pamaury | Oh no sorry, this is the only in file.c, the I don't see why parent_dir is needed :) |
| 17:35:02 | | Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com) |
| 17:36:07 | TheSeven | so this would be an *80K ramsize gain!* |
| 17:36:21 | pamaury | Ah yes, I remember. It's needed because fat_opendir needs the parent_dir and the output fat_dir but in reality this is overkill, there is too much information, it could probably be improved |
| 17:36:24 | Torne | ok, so i am at least partly right? :) |
| 17:36:33 | Torne | sorry, had to step out ;) |
| 17:36:48 | pamaury | let me check if I fixed that in one of my numerous branch :) |
| 17:36:50 | | Join kugel_ [0] (~kugel@e178100011.adsl.alicedsl.de) |
| 17:36:55 | | Quit kugel (Ping timeout: 260 seconds) |
| 17:37:04 | | Nick kugel_ is now known as kugel (~kugel@e178100011.adsl.alicedsl.de) |
| 17:37:09 | | Quit kugel (Changing host) |
| 17:37:09 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:37:20 | chrisb | linuxstb: where should i ask? |
| 17:37:24 | kugel | TheSeven: yes |
| 17:37:53 | TheSeven | chrisb: if you just want to rant about it: #rockbox-community, or if you want real help, maybe #ffmpeg or something |
| 17:38:22 | chrisb | thanks |
| 17:38:56 | pamaury | hum, no. You're right to raise the problem, normally the "hack" I used in dircache:sab_process_dir should apply. I'll have a look |
| 17:39:25 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 17:39:45 | Torne | amiconn: anyway, yeah, i did think we really shouldn't need that many sector sized buffers ;) |
| 17:40:13 | * | TheSeven would still like to figure out where the ones on the stack are coming from |
| 17:43:06 | * | amiconn needs to find out why a sim build on opensolaris produces a broken make.dep |
| 17:43:23 | kugel | TheSeven: I think I could work around by deactivating iram usage in the bootloader. the sections land in the same memory region anyway as per boot.lds. but I would like to get it right |
| 17:44:15 | TheSeven | there should be an .idata section that should be handled like .icode, but with a writable flag |
| 17:44:25 | kugel | there is such a section |
| 17:44:43 | | Join kh [0] (~89840307@giant.haxx.se) |
| 17:44:52 | kugel | that' sour boot.lds http://pastie.org/859773 |
| 17:45:00 | TheSeven | hm, would it be feasible to enforce that calls to the storage apis *have* to use cacheline-aligned buffers? |
| 17:45:10 | Torne | TheSeven: no |
| 17:45:14 | Torne | TheSeven: well sort of |
| 17:45:22 | Torne | TheSeven: I was looking at doing that but I haven't really gotten far. |
| 17:45:41 | Torne | TheSeven: It's done for buffering now where possible if you define the alignment requirement in the config |
| 17:45:55 | Torne | I didn't get around to making sure the fat/etc buffers are aligned by the mask yet |
| 17:45:57 | TheSeven | ok, then I'll use a hack that will use 2K more ramsize and non-cacheline-aligned reads/writes will be *slow* |
| 17:46:17 | Torne | but yeah i don't think we can ever realistically get to the point where *all* calls are cacheline aligned |
| 17:46:46 | TheSeven | so this would be most important for the USB stuff, which probably needs to have cacheline-aligned buffers anyways for the USB BMA |
| 17:46:48 | TheSeven | DMA* |
| 17:46:52 | | Quit komputes (Ping timeout: 256 seconds) |
| 17:47:03 | Torne | Pretty sure the USB buffers are aligned to a very large size |
| 17:47:05 | Torne | way more than 32 bytes |
| 17:47:16 | Torne | they always use DMA on PP502x, at least |
| 17:47:38 | gevaerts | on PP they are aligned to 32 bytes |
| 17:47:41 | TheSeven | Torne: commit a panicf with a stacktrace when they aren't aligned :-P I'm pretty sure they would be gone rather fast (or possibly your commit) |
| 17:47:44 | Torne | haha |
| 17:47:53 | Torne | TheSeven: well, that was more or less what i was going to do on my local build |
| 17:47:58 | Torne | and go around shoving references to STORAGE_ALIGN in there |
| 17:48:02 | Torne | until everything i tried worked. |
| 17:49:01 | | Join kugel_ [0] (~kugel@e178118040.adsl.alicedsl.de) |
| 17:49:07 | | Quit kugel (Disconnected by services) |
| 17:49:12 | amiconn | Aren't usb buffers aligned to 4K on PP502x? |
| 17:49:14 | | Nick kugel_ is now known as kugel (~kugel@e178118040.adsl.alicedsl.de) |
| 17:49:19 | | Quit kugel (Changing host) |
| 17:49:19 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:49:40 | gevaerts | no |
| 17:49:49 | Torne | TheSeven: anyway, yeah, if you want to align more stuff that'd be great, but requiring that it's aligned is probably a nonstarter |
| 17:50:08 | Torne | TheSeven: since that includes every bit of app code which happens to read/write more than a sector |
| 17:50:15 | TheSeven | i'll require it in a way that non-aligned things are 4 times slower |
| 17:50:19 | kugel | TheSeven: boot.lds lacks the NOLOAD directives |
| 17:50:22 | gevaerts | There's one data structure that's aligned to 4K for the USB controller, but not the data buffers |
| 17:50:22 | | Quit kh (Quit: CGI:IRC (EOF)) |
| 17:50:31 | kugel | adding it seems to help |
| 17:53:03 | gevaerts | As far as the ARC controller is concerned, you don't actually need to align data at all, but not aligning leads to cache issues |
| 17:54:53 | pamaury | which structures should be aligned ? |
| 17:55:46 | linuxstb | TheSeven: Are you planning to incorporate your norloader work into Rockbox, or is it strictly iloader? |
| 17:56:02 | TheSeven | pamaury: everything that gets passed to storage_read and storage_write |
| 17:56:33 | TheSeven | linuxstb: I'm not entirely sure about that, because it currently depends on quite a lot of non-rockbox stuff |
| 17:56:34 | Torne | if anyone else does do somet alignment stuff, btw, please use STORAGE_ALIGN_MASK :) |
| 17:56:47 | Torne | so that the existing code we did for pp502x can be used |
| 17:57:10 | gevaerts | pamaury: as far as the ARC controller is concerned, transfer descriptors need to be 32-byte aligned, and the queue head array has to be 4k aligned |
| 17:57:11 | Torne | buffering is mostly aligned to that mask already, if you define it, it's just only defined on pp502x |
| 17:57:18 | TheSeven | we would need to have some well-tested recovery code (i'm currently using ibugger for that), and we need to deal with things like diskmode and diagmode |
| 17:57:29 | gevaerts | oh, 2k actually |
| 17:57:32 | pamaury | gevaerts: yes I know those restrictions |
| 17:57:48 | TheSeven | (or have our own "diskmode" in-flash rockbox, which i wouldn't like right now because USB isn't stable yet) |
| 17:58:23 | TheSeven | and of course nandfsck... which i wouldn't really want to include in rockbox for ramsize reasons (it needs 2MB or something of heap) |
| 17:59:19 | TheSeven | torne: which define do you mean? |
| 17:59:32 | TheSeven | ah, spotted it :-) |
| 17:59:54 | | Quit kugel (Ping timeout: 258 seconds) |
| 18:00 |
| 18:00:18 | TheSeven | linuxstb: i don't really see how we could include norloader into rockbox's design |
| 18:01:11 | | Quit petur (Quit: work->home) |
| 18:01:18 | linuxstb | TheSeven: Wouldn't it just be a separate application in bootloader/ ? i.e. it would use the Rockbox firmware code and then add stuff itself. |
| 18:02:05 | linuxstb | Complicated stuff could go into firmware/ and then only be used by norloader, and not the main Rockbox build. |
| 18:02:43 | TheSeven | actually, norloader should be standalone and not use things from the rockbox tree for safety reasons, as it's only some basic hardware setup that we won't need to do anywhere else and because of the bricking risk |
| 18:03:00 | TheSeven | you could compare that to AMS dualboot |
| 18:03:50 | | Join Omlet05 [0] (~omlet05@221.154-200-80.adsl-dyn.isp.belgacom.be) |
| 18:03:56 | TheSeven | (the norloader binary is actually <4K, plus recovery image and crypto headers = 8,8K) |
| 18:04:20 | TheSeven | and it shouldn't ever need to be changed |
| 18:04:36 | linuxstb | OK, so that's fine then - just a standalone app somewhere. |
| 18:04:47 | TheSeven | yes, like it currently is |
| 18:05:02 | | Quit Omlet (Ping timeout: 245 seconds) |
| 18:05:04 | TheSeven | we could possibly make the rockbox bootloader boot from flash, but for that we should add things like allowing to enter disk mode |
| 18:05:27 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 18:06:11 | linuxstb | TheSeven: Yes, but it's not in Rockbox SVN, or documented in the Rockbox wiki. I guess that was my original question. |
| 18:07:12 | TheSeven | then there's the question of a sane installation process for whatever solution you prefer |
| 18:08:10 | TheSeven | i've written a standalone installer for norloader/iloader/whatever else you want, which is quite flexible (you can also make it do things like creating other files in the file system - actually it could install a full rockbox) |
| 18:08:42 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 18:08:50 | kugel | mc2739: sent |
| 18:09:10 | TheSeven | we couldn't implement that functionality as a rockbox plugin, but we could of course go for some easier solution that just flashes an image to the nor |
| 18:09:36 | linuxstb | Why couldn't that be a plugin? |
| 18:09:48 | TheSeven | because of it's size |
| 18:10:07 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 18:10:22 | linuxstb | The size of what? |
| 18:10:23 | TheSeven | it needs about 16MB of malloc space for libucl |
| 18:10:32 | linuxstb | That's fine. |
| 18:10:49 | kugel | no problem unless you want music playing while it's running :) |
| 18:10:53 | linuxstb | Plugins can grab the 28MB or so audio buffer. |
| 18:11:18 | TheSeven | actually we could also decide to not compress the images at all - which could still fit into the flash, depending on what we want to do with it |
| 18:11:38 | TheSeven | and honestly, the iloader-installer is just overkill for the application you're thinking of |
| 18:11:43 | | Quit pamaury (Quit: Quitte) |
| 18:12:23 | TheSeven | it's for advanced users that want to get the absolute maximum out of their ipods, both in terms of space and functionality |
| 18:12:29 | kugel | haha, something is strange with the bootloaders and eabi |
| 18:12:35 | TheSeven | (and who are comfortable with some data loss risk) |
| 18:12:47 | kugel | it just wanted to create a 788597788 bytes bootloader.bin |
| 18:12:55 | | Join Omlet [0] (omlet05@191.150-242-81.adsl-dyn.isp.belgacom.be) |
| 18:13:04 | TheSeven | which target? |
| 18:13:10 | kugel | e200v1 this time |
| 18:13:32 | TheSeven | could it be possible that it's IRAM is at 0x2f00xxxx or 0x2f01xxxx? |
| 18:14:35 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 18:14:57 | kugel | could be :) |
| 18:15:00 | TheSeven | if you "just" want to install a rockbox bootloader into the nor and keep the firmware partition, a more trivial solution can be found |
| 18:15:26 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 18:15:27 | | Quit Omlet05 (Ping timeout: 246 seconds) |
| 18:16:11 | TheSeven | kugel: did you get what i mean? |
| 18:16:21 | kugel | yes :) |
| 18:16:44 | linuxstb | TheSeven: I think I'm still a bit confused - there seems to be lots of ways to do this... Maybe we would just want to support the two extremes - i.e. the current method of installation, and a "wipe all Apple code completely and remove the firmware partition" method for people that only want to use Rockbox. |
| 18:16:58 | kugel | NOLOAD helps here as well |
| 18:17:24 | | Quit kugel (Read error: Connection reset by peer) |
| 18:17:54 | TheSeven | linuxstb: that would still be 3 options: rockbox bootloader via firmware partition, rockbox bootloader via nor, and iloader via nor |
| 18:18:32 | TheSeven | iloader's advantage is the configurable menu, for people that like it |
| 18:18:57 | amiconn | Torne: Actually you could even reduce the lfn buffer to 512 bytes if you pre-decode the entries |
| 18:19:05 | TheSeven | (and it doesn't lose the OF either) |
| 18:19:31 | TheSeven | the rockbox via nor way could also wipe all the apple stuff completely, or try to be compatible |
| 18:19:33 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 18:19:45 | TheSeven | but honestly I don't see any advantages of the rockbox bootloader over iloader |
| 18:19:53 | | Join Omlet05 [0] (omlet05@157.99-240-81.adsl-dyn.isp.belgacom.be) |
| 18:20:34 | kugel | is there a reason the boot.lds files don't have NOLOAD for bss/stack? other than historical reasons of course :) |
| 18:21:12 | linuxstb | Well, "Rockbox" as a project never supports third-party bootloaders. So you should make the rockbox bootloader do what iloader can do. As long as it can be configured (and I would argue by default) to boot straight into Rockbox, I would be happy with a configurable bootloader. |
| 18:21:36 | TheSeven | linuxstb: other people aren't, for whatever reason |
| 18:22:29 | linuxstb | TheSeven: Let them speak up then... |
| 18:22:34 | | Quit Omlet (Ping timeout: 256 seconds) |
| 18:22:51 | gevaerts | Speaking of bootloaders, why is there a mini2440 rockbox bootloader at all? |
| 18:22:59 | TheSeven | actually, i'm not even sure if I want the "rockbox project" to support that, as it probably will always be a highly-experimental bleeding-ede thing |
| 18:23:19 | TheSeven | gevaerts: because "Rockbox" as a project never supports third-party bootloaders, be it u-boot or not :-P |
| 18:23:33 | TheSeven | bleeding-edge, even |
| 18:23:53 | gevaerts | TheSeven: u-boot comes factory-installed, and rockbox does work with various factory-flashed bootloaders :) |
| 18:24:40 | Torne | Being able to support booting with u-boot is probably useful, tbh :) |
| 18:25:04 | TheSeven | is there even a way to not support that? :-P |
| 18:25:16 | Torne | TheSeven: Sure.. |
| 18:25:34 | Torne | u-boot doens't promise to load you anywhere in particular, for a start |
| 18:25:49 | TheSeven | you can tell it to do it, though |
| 18:25:52 | | Join einhirn [0] (~Miranda@p5485A43E.dip0.t-ipconnect.de) |
| 18:26:07 | Torne | no, you can tell the user to do it |
| 18:26:14 | TheSeven | or the config file ;-) |
| 18:26:21 | Torne | ..confwhat? :) |
| 18:26:42 | * | TheSeven is confused |
| 18:26:52 | Torne | u-boot doesn't have a config file |
| 18:27:07 | TheSeven | it does on the beagle board at least |
| 18:27:23 | TheSeven | linuxstb: the question is whether we need the norloader => rb bootloader option, i.e. if anyone would want to use that |
| 18:27:24 | Torne | it doesn't on the vast majority of targets |
| 18:27:35 | Torne | its environment is stored in binary in flash |
| 18:27:36 | TheSeven | then fix it :-) |
| 18:27:44 | Torne | on many targets it doesn't have *filesystem* support |
| 18:27:56 | Torne | most copies of u-boot can't access anything but flash/serial/ethernet |
| 18:28:04 | TheSeven | well, then tell the environment to load rockbox at a certain address |
| 18:28:19 | Torne | yes, my point is that's the user's job |
| 18:28:20 | Torne | you can't do it |
| 18:28:45 | Torne | if you want to support being loaded by u-boot in the general case you need to behave like linux kernels do ;) |
| 18:28:51 | TheSeven | well, it's also the users job to copy rockbox into the flash... |
| 18:29:12 | TheSeven | so that's just one additional command to setup the environment accordingly |
| 18:29:30 | TheSeven | it's also a matter of copy'n'paste, so... |
| 18:29:39 | Torne | er |
| 18:29:43 | * | gevaerts 's main point is that he thinks that an installation procedure that starts with "remove u-boot" is silly |
| 18:29:45 | | Join Omlet [0] (omlet05@19.105-244-81.adsl-dyn.isp.belgacom.be) |
| 18:29:45 | Torne | but linux doesn't generally need any config at all |
| 18:29:57 | Torne | at least not on systems with a filesystem |
| 18:30:01 | Torne | you drop uImage on the card, it boots it |
| 18:30:25 | TheSeven | yes, but on those systems you should also be able to drop a uboot config on the card |
| 18:30:36 | Torne | no |
| 18:30:40 | Torne | that's not automatic, sorry :) |
| 18:30:49 | Torne | i don't know if the config file thing is even in mainline |
| 18:30:53 | Torne | not last time i checked |
| 18:30:56 | * | TheSeven considers uboot stupid then => thus it will need to be removed :-P |
| 18:31:00 | Torne | i think that is a beagle-specific hack |
| 18:31:28 | Torne | the default place to load linux to on ARM is, er, 64kb fro mthe bottom of ram? |
| 18:31:30 | Torne | maybe 128kb? i forget |
| 18:31:32 | TheSeven | what about making a uImage that removes uboot and replaces it with somethign sane? :-P |
| 18:31:42 | Torne | to make room for the atags to be at start of ram plus 0x200 |
| 18:31:46 | gevaerts | Speaking of beagles, has nobody ported rockbox to them yet? |
| 18:31:56 | Torne | gevaerts: i pondered doing an omap3 port |
| 18:32:03 | Torne | but haven't seen a particular motivation to care |
| 18:32:13 | Torne | i don't have a beagle but i have other omap3 devices which are baiscally identical |
| 18:32:37 | TheSeven | hm, it doesn't fit well to that board, no proper means of input and the like |
| 18:32:47 | | Quit Omlet05 (Ping timeout: 264 seconds) |
| 18:32:52 | Torne | it doesn't fit well to mini2440 either :) |
| 18:32:56 | TheSeven | just a single button, and of course usb host to support a usb keyboard |
| 18:33:05 | TheSeven | the mini has a touchscreen at least, and several user buttons |
| 18:33:06 | Torne | but pandora, perhaps |
| 18:33:12 | Torne | which is another omap3. |
| 18:33:24 | Torne | or the overo, for people who desperately want to make their own mp3 player |
| 18:33:31 | | Join JdGordon [0] (~18168145@gateway/web/freenode/x-ovaiklpdgkjwshjt) |
| 18:33:33 | gevaerts | n900? You'd need a phone stack for people not to complain though |
| 18:33:34 | Torne | the overo on a pinto-th breakout is small enough to make a pocket flash player :) |
| 18:34:05 | Torne | i am still not entirely sure why casainho is using mini2440 and not something much smaller :) |
| 18:34:30 | TheSeven | well, apparently he wants to switch to Cortex M-series now |
| 18:34:36 | TheSeven | M3 IIRC, thumb-only :-/ |
| 18:34:40 | Torne | nothing wrong with that |
| 18:34:44 | Torne | M3 should be powerful enough |
| 18:34:50 | Torne | you will jus thave to fix whatever doesn't compile for thumb2 |
| 18:35:05 | TheSeven | and *all* of the asm code |
| 18:35:16 | Torne | well that too :) |
| 18:35:24 | Torne | thumb2 is not bad though |
| 18:35:35 | TheSeven | and the reason for the M3 is obviously the packaging |
| 18:35:43 | gevaerts | That's been done four times already, so it is possible :) |
| 18:36:07 | TheSeven | and i'm not sure if those "solderable" packages he likes will have enough pins to satisfy his needs |
| 18:36:14 | Torne | he probably misses the point that available M3 SoCs probably don't have sufficient caching abilities |
| 18:36:30 | Torne | I dunno the full scope of what there is out there, but most of the ones i know of only have L1 cache in a limited amount |
| 18:36:39 | TheSeven | and I can't really follow why he is going for 2MB of SDRAM for price reasons, instead of at least 4MB |
| 18:36:39 | Torne | and thus accessing sdram will be fairly shit |
| 18:37:13 | | Join Omlet05 [0] (omlet05@203.4-65-87.adsl-dyn.isp.belgacom.be) |
| 18:37:37 | Torne | but yeah, the pandora is a vague possibility |
| 18:37:57 | Torne | if we had a decent port to that we *might* be able to go for 100+hr battery life, too |
| 18:38:02 | Torne | which might impress people ;) |
| 18:38:49 | Torne | we might want to redo all the codecs to use NEON tho ;) |
| 18:39:00 | JdGordon | nope, our support still sucks enough that 100hr batt life wont change peoples minds |
| 18:39:10 | Torne | JdGordon: hehe |
| 18:39:22 | Torne | the pandora's battery is just *massive* compared to the power consumption o fthe omap |
| 18:39:36 | | Quit Omlet (Read error: Connection reset by peer) |
| 18:39:42 | Torne | advantage of being a relatively large handheld, i guess |
| 18:39:50 | Torne | anyway time i went. |
| 18:40:19 | TheSeven | how much capacity does it have btw? |
| 18:44:53 | | Quit Omlet05 (Ping timeout: 276 seconds) |
| 18:49:08 | CIA-5 | New commit by kugel (r25073): Correct search&replace error. |
| 18:51:16 | * | domonoky sees gevaerts complaining about the mini2440 install. if you dont like it, improve it ! :-) |
| 18:51:31 | JdGordon | gevaerts: oh you got one? |
| 18:51:47 | gevaerts | domonoky: I'm not complaining! I'm just questioning the sanity of whoever designed it! ;) |
| 18:51:57 | gevaerts | JdGordon: no |
| 18:52:09 | | Join Omlet [0] (omlet05@241.164-244-81.adsl-dyn.isp.belgacom.be) |
| 18:52:12 | TheSeven | we like to moan about things we don't use ;-) |
| 18:52:25 | JdGordon | righto :) |
| 18:52:42 | domonoky | gevaerts: :-) it probably was just the easiest way. using the bootloader to get the initial drivers working is easier, then a full build. |
| 18:53:24 | TheSeven | actually, this is a *devboard*, not a supported target... |
| 18:53:53 | gevaerts | domonoky: well yes, but throwing u-boot out removes a lot of flexibility. It's perfectly possible to use a "bootloader" as a minimal bootstrap port and never use it to actually load boots |
| 18:54:15 | kugel | my invitation for my proposal on the dev ml is still valid :) |
| 18:54:36 | kugel | Zagor: if we switch, how would updating the build clients work? |
| 18:54:37 | domonoky | gevaerts: you dont need u-boot on the mini2440. just flip a switch and boot linux/windows or something else from flash. |
| 18:55:31 | domonoky | and i think doesnt even come with u-boot, but some different bootloader thingy which needs serial + usb to operate with :-) |
| 18:55:48 | kugel | ideally it should be trivial to restore uboot as well, using the tools on the shipped dvd |
| 18:56:10 | domonoky | on mini2440 rockbox is on sdcard. the nand flash is untouched and still able to boot the preinstalled linux. |
| 18:56:12 | gevaerts | kugel: some build clients should have the eabi toolchain before the switch, after that it's just a different toolchain that's tested for by the server |
| 18:56:21 | kugel | domonoky: yes. do we actually remove uboot? wasn't it supervivi? |
| 18:56:40 | JdGordon | yes, supervivi |
| 18:56:42 | kugel | gevaerts: but do we want a new target, or reuse the existing arm one? |
| 18:56:45 | JdGordon | which is important to keep :p |
| 18:56:50 | domonoky | supervivi is the name, that lives in nor, and gets overwritten by our bootloader |
| 18:56:51 | gevaerts | As far as the build system is concerned, you don't have to switch all targets at the same time |
| 18:58:04 | gevaerts | kugel: hm, if we reuse the existing one we might have interesting issues, but changing target names every time we update a compiler also doesn't sound like a good idea |
| 18:58:24 | *** | Saving seen data "./dancer.seen" |
| 18:58:37 | kugel | well, we could add a version number so it's a bit less ugly :) |
| 18:58:55 | gevaerts | Yes, maybe we should do somethin like that |
| 18:59:23 | TheSeven | hm, before we switch to eabi, mr. someone should finally go after that stupid yellow! |
| 19:00 |
| 19:00:43 | | Join Seed [0] (~ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 19:01:15 | | Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 19:02:36 | kugel | r25071 was an interesting revision for the c200v2 :) |
| 19:04:12 | | Quit shai (Ping timeout: 245 seconds) |
| 19:14:33 | | Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) |
| 19:15:09 | | Quit Omlet (Ping timeout: 245 seconds) |
| 19:19:10 | | Join Omlet [0] (omlet05@198.3-65-87.adsl-dyn.isp.belgacom.be) |
| 19:21:55 | | Quit arbingordon (Quit: `) |
| 19:24:01 | | Quit DerPapst (Quit: Leaving.) |
| 19:24:18 | | Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-uvogbzafnafatpea) |
| 19:26:18 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 19:27:16 | | Quit anewuser () |
| 19:27:37 | | Quit CGL (Ping timeout: 240 seconds) |
| 19:29:17 | | Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 19:30:15 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:32:43 | | Quit einhirn (Read error: Connection reset by peer) |
| 19:34:30 | | Join gill0r [0] (~gill0r@f050132026.adsl.alicedsl.de) |
| 19:37:00 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 19:38:55 | Llorean | kugel: Some iRivers do run ARM cpus. |
| 19:39:11 | Llorean | The H10 is PortalPlayer based. |
| 19:39:56 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:40:47 | kugel | Llorean: yes, I forgot about this one sorry. but IIRC know alex wallis has h100 so I assumed he meant that one |
| 19:41:44 | Llorean | Yeah, but it's better not to post statements like "they don't run ARM cpus" when someone just asks about "iRivers". It leaves misleading information in the archives. |
| 19:42:29 | Llorean | Anyone looking through the archives for information may not know he's most likely asking about an H100. |
| 19:43:47 | kugel | as I said, I completely forgot about the h10 |
| 19:44:34 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 19:50:33 | pixelma | domonoky, bluebroth3r: got the rbspeexenc and dec now, what should I do with them now? |
| 19:51:02 | | Join DerPapst [0] (~DerPapst@p4FE8EBD6.dip.t-dialin.net) |
| 19:51:54 | domonoky | try to encode and then decode again on one of the generated wav files, and see it had the problem too |
| 19:52:44 | domonoky | pixelma: did you try to generate talk files with filte/espeak/etc on these macs ? |
| 19:53:39 | | Quit jd (Read error: Connection reset by peer) |
| 19:53:55 | | Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 19:53:56 | | Quit jd (Changing host) |
| 19:53:56 | | Join jd [0] (~jd@Wikipedia/HellDragon) |
| 20:00 |
| 20:00:20 | pixelma | domonoky: can you help me a bit on how to use them, I'm a commandline newbie (maybe privately though)? And if I should try Intel MacOS 10.4 first I got to switch computers and join through a webclient... |
| 20:00:59 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 20:03:01 | domonoky | lets start with pp :-) |
| 20:03:53 | Zagor | kugel: that's a good question. the distributed build system doesn't manage the compilers, so we somehow need to make everyone upgrade manually. |
| 20:04:09 | pixelma | domonoky: well, I got no intermediate files from there but I could try with the others (or some other wav) |
| 20:04:31 | pixelma | talk generation hangs completely there... |
| 20:04:49 | | Join stoffel [0] (~quassel@p57B4C7BB.dip.t-dialin.net) |
| 20:04:51 | pixelma | hmm... reminds me to also try espeak or so |
| 20:06:29 | domonoky | rbspeexdec just takes the in and output filenames as parameters. rbspeexenc should work with just input and outputfilename too (using default options). |
| 20:07:19 | domonoky | lets try with some different wav files, and see what works. Just remember which result used which wav file :-) |
| 20:08:36 | | Join petur [0] (~peter@d54C6F9B2.access.telenet.be) |
| 20:08:37 | | Quit petur (Changing host) |
| 20:08:37 | | Join petur [0] (~peter@rockbox/developer/petur) |
| 20:08:48 | domonoky | a quick test with espeak or similar would be also good. if it works, we know that rbspeex is fine, and you dont need to test it :-) |
| 20:12:41 | pixelma | I need to find an espeak binary for 10.4 (PPC) first :\ |
| 20:12:59 | pixelma | or flite |
| 20:13:43 | | Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) |
| 20:14:41 | | Quit stoffel (Remote host closed the connection) |
| 20:18:11 | domonoky | espeak provides mac 10.4 binarys. if you are lucky they are built universally. |
| 20:18:44 | Zagor | an easy fix is to update rbclient to check the gcc version |
| 20:19:01 | pixelma | domonoky: didn't find a binary yet |
| 20:19:17 | domonoky | http://espeak.sourceforge.net/download.html ? |
| 20:21:09 | Zagor | btw, emdebian.org builds cross-compiler debs. such as: http://www.emdebian.org/toolchains/search.php?package=gcc-4.4-arm-linux-gnueabi&arch=&distro=sid |
| 20:21:45 | Zagor | their binutils is version "2.20-5" though. I don't know if that includes the fixes from 2.20.1. |
| 20:22:38 | | Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net) |
| 20:23:34 | | Quit ecio (Quit: Leaving) |
| 20:25:14 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 20:25:21 | funman | pacakges.debian.org usually give the patches applied (on the right of the page), but I don't see it on your link |
| 20:27:06 | Zagor | emdebian.org != debian.org |
| 20:28:10 | Zagor | well, it's part of debian but they don't have the same full web system |
| 20:40:24 | kugel | because their webserver is an embedded system! ;) |
| 20:41:55 | JdGordon | emdebian is annoying :/ .. it doent just work |
| 20:46:57 | | Quit tvelocity (Read error: Operation timed out) |
| 20:47:02 | | Join moos [0] (moos@rockbox/staff/moos) |
| 20:50:02 | | Quit pamaury (Ping timeout: 252 seconds) |
| 20:50:11 | | Quit n17ikh (Ping timeout: 260 seconds) |
| 20:52:40 | | Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) |
| 20:56:44 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 20:57:30 | | Join Tomis [0] (~Tomis@70.134.101.40) |
| 20:58:27 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:05:35 | chrisb | how long should a first install take? 1 minute, 5 minutes, 15 minutes? target is sansa e200 |
| 21:06:56 | | Quit amiconn (Disconnected by services) |
| 21:06:57 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 21:07:00 | | Quit pixelma (Disconnected by services) |
| 21:07:01 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 21:07:15 | | Quit MaadMan (Quit: Verlassend) |
| 21:07:18 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 21:07:24 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 21:07:42 | | Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) |
| 21:08:33 | Zagor | chrisb: a minute tops |
| 21:09:27 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 21:09:58 | Llorean | Zagor: Unless your download is really, really slow. |
| 21:10:21 | Llorean | chrisb: But the installation part should be very quick, it's just unzipping and copying a couple megs of files pretty much |
| 21:12:48 | | Quit Tomis (Ping timeout: 248 seconds) |
| 21:14:28 | | Join Buschel [0] (~ab@p54A3BBBC.dip.t-dialin.net) |
| 21:16:32 | | Join Tomis [0] (~Tomis@70.134.80.2) |
| 21:28:17 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 21:29:02 | Lear | Bushel: You've noticed that ReplayGain for MPC doesn't show up in the track info screen? |
| 21:29:36 | Lear | I have a fix for that... |
| 21:29:44 | Buschel | fix it :o) |
| 21:30:01 | Buschel | and: no, i haven't noticed |
| 21:30:27 | Lear | Ok, will apply it later (haven't tested it yet). |
| 21:30:43 | Buschel | can you post the patch somewhere? |
| 21:31:48 | Lear | Sure (I can commit it myself though). |
| 21:32:04 | pixelma | aha, bluebroth3r: rbspeexenc is at least executed on the 10.5 Mac |
| 21:32:09 | kugel | looks like nobody is against the gcc update, so I suggest we start asking the build clients to get eabi toolchains ready so that we can switch over in a few days or week |
| 21:32:32 | pixelma | same file I tested on the 10.4 Intel Mac |
| 21:32:33 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 21:32:37 | bluebroth3r | pixelma: nice. A ! in the folder name shouldn't matter but not really sure about this. |
| 21:33:10 | Lear | Buschel: http://pastie.org/860155 |
| 21:33:44 | pixelma | bluebroth3r: well, if it works on 10.5 then I assume it's fine. So it looks like you still have a non-working crosscompiled binary |
| 21:34:10 | pixelma | IIUC... going to try the PPC too once more |
| 21:34:33 | Buschel | Lear: hmm, just checked. it shows. but only, if present... |
| 21:34:42 | Buschel | Lear: with svn that is |
| 21:35:39 | linuxstb | bluebroth3r: Are you able to compile rbspeex* on ppc? Can you add a #warning into the endian-ness check in apps/codecs/libspeex/speex_header.c ? (around line 52) |
| 21:35:46 | linuxstb | (unless you've already checked that...) |
| 21:37:05 | Lear | Buschel: Didn't show for me (on target). But the patch is silly. I'd forgotten what parse_replaygain_int did. It was a couple of years ago, so... :) |
| 21:37:16 | pixelma | the files I test are crosscompiled on a later OSX (and Intel) so it could all come from that fact |
| 21:38:00 | bluebroth3r | linuxstb: haven't checked that, will try |
| 21:38:10 | Lear | The files in question have ReplayGain, according to Foobar though. |
| 21:38:11 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 21:38:17 | Buschel | Lear: just checked a file (that definately has replay gain data) on pc sim. this works fine. |
| 21:39:20 | | Join planetbeing__ [0] (~planetbei@166.134.250.66) |
| 21:39:32 | | Quit planetbeing (Read error: Connection reset by peer) |
| 21:39:35 | | Nick planetbeing__ is now known as planetbeing (~planetbei@166.134.250.66) |
| 21:40:49 | | Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
| 21:41:18 | bertrik | I'll update my build client to advertise eabi build capability |
| 21:41:29 | bluebroth3r | linuxstb: my #warning gets hit (directly after the #elif line) when building for ppc |
| 21:41:47 | chrisb | Zagor: thanks |
| 21:42:06 | chrisb | Llorean: thanks |
| 21:43:10 | | Quit planetbeing_ (Ping timeout: 252 seconds) |
| 21:47:18 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:48:30 | | Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 21:50:25 | * | chrisb realizes he was doing the complete install with extras, etc. |
| 21:50:51 | bertrik | what should I put in the archlist parameter to advertise arm-elf-eabi build capability? |
| 21:51:08 | moos | Lear; Buschel: I remenber to have encountred this "no replaygain info" on the tag browser bug on the past. But that was few years ago too :) IIRC rockbox didn't like much mixed ape+id3 tags for mpcs |
| 21:52:25 | funman | bertrik: i think Zagor said earlier that the buildsystem doesn't recognize different gcc versions. I don't know if the buildsystem has a way to append −−eabi to configure arguments though |
| 21:53:17 | Zagor | the system doesn't support alternative compilers, or options, for each target |
| 21:54:29 | Buschel | moos: the current implementation jsut checks the mpc header itself. mpc has generic replay gain support... |
| 21:56:45 | moos | Buschel: this was ages ago (rockbow wise). You didn't meet rockbox yet, then ther was few bugs and messes you fixed since (plus all the cool optimisations you made since too :) |
| 21:57:33 | | Join Stephen__ [0] (~S@86.45.50.221) |
| 21:59:27 | moos | if the tag contained apev2 info and id3 infos, that caused tag reading problems. This time I did fixed my tags for the musepack albums I have :) And that was preglow that was working on this front this time |
| 21:59:40 | moos | don't tried since |
| 22:00 |
| 22:00:34 | Buschel | Lear reports this bug on a sv8 file with a replay gain tag. i will need to debug this... my (single) tagged sv8 file works fine |
| 22:01:34 | linuxstb | To "go live" with eabi, could we simply change ARG_ARM_EABI in tools/configure to default to 1? |
| 22:01:41 | * | moos bets that Lear will find/fix himself :) |
| 22:02:43 | kugel | linuxstb: basically, yes |
| 22:02:48 | * | Buschel just recognizes he already has 3 sv8 with working replay gain tags |
| 22:02:52 | * | linuxstb wonders why those ARG_* variables are defaulted to the empty string, and not 0 (for the 1/0 options) |
| 22:03:49 | | Join Tomis2 [0] (~Tomis@70.134.100.226) |
| 22:04:20 | kugel | the PP bootloader need some changes which are safe AFAICS. the stack/bss sections aren't marked with NOLOAD, and the new ld wants to put those into the binary for that reason |
| 22:04:52 | moos | Buschel: could be particular circumstences, let's him find himself, since he seems to have the culprit file :) |
| 22:05:27 | | Quit Tomis (Ping timeout: 245 seconds) |
| 22:05:27 | | Nick Tomis2 is now known as Tomis (~Tomis@70.134.100.226) |
| 22:06:48 | funman | has there been reports of filesystem corruption on e200v1/c200v1 these days ? |
| 22:07:01 | | Join JdGordon1 [0] (~jonno@c-71-231-54-21.hsd1.wa.comcast.net) |
| 22:07:26 | Seed | Buschel: hi |
| 22:07:46 | | Quit JdGordon (Ping timeout: 252 seconds) |
| 22:08:27 | Buschel | Seed: hi :o) |
| 22:08:47 | | Quit mikroflops (Ping timeout: 264 seconds) |
| 22:09:31 | | Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) |
| 22:09:35 | JdGordon1 | anyone getting lots of data aborts recently? |
| 22:09:44 | linuxstb | kugel: Why "basically" ? |
| 22:10:22 | kugel | nothing verifies if the compiler is really eabi-capable. that's all |
| 22:10:52 | kugel | but it throws the usual warning if the compiler is not gcc 4.4.3, so I don't think that's a problem |
| 22:11:36 | saratoga | funman: not in a very long while that I've seen |
| 22:11:38 | linuxstb | kugel: But doesn't the compiler have the name arm-elf-eabi-gcc ? |
| 22:12:07 | saratoga | stripwax: seen my email about back porting the new mdct to Tremor? |
| 22:13:08 | stripwax | saratoga - not yet, but that's just down to busy-ness. let me go take a look.. |
| 22:13:45 | stripwax | oh, I did see a mail where you said something like 'stripwax and I need to figure out what's up with the bitrev' - but that didn't actually mean a whole lot to me :) |
| 22:13:53 | saratoga | stripwax: basically we have permission from Lorenm (the split-radix ffmpeg porter) to relicense his code as BSD |
| 22:14:20 | saratoga | AFAIK once the bitrev stuff is figured out we can simply remove the init code for computing the bitrev table and then the entire mdct will be BSD licensed |
| 22:14:22 | stripwax | ok cool |
| 22:14:31 | saratoga | i tried truncating the bitrev table but it did not work |
| 22:14:40 | saratoga | i thought you had some idea how to do that correctly? |
| 22:14:54 | funman | saratoga: i noticed sd_read_sectors() doesn't switch banks properly when a read request overlap on 2 banks |
| 22:15:01 | | Quit JdGordon1 (Ping timeout: 276 seconds) |
| 22:15:15 | stripwax | so as long as the bitrev table is big enough then we're good to go .. and it's currently statically created so not sure what's left to do .. ? |
| 22:15:27 | stripwax | i.e. I thought we had no more init code |
| 22:15:36 | saratoga | well ideally i wanted to get it to the right size before we removed the init code (currently ifdef'ed out) |
| 22:15:42 | saratoga | but i suppose thats not really necessary |
| 22:16:07 | saratoga | funman: well I haven't heard any complaint but i suppose the occasional audio file ending up with a garbled bit in the middle might never be reported |
| 22:16:30 | stripwax | if you want to half the size of the table, you need to right shift every element by one bit; etc |
| 22:16:38 | kugel | linuxstb: yes, configure forces the prefix to be "arm-elf-eabi-", so I guess it's not a problem at all |
| 22:17:30 | kugel | funman: I saw this too recently. but it's been like that for ages I believe |
| 22:17:32 | saratoga | stripwax: also since you wrote so much of the code, would you mind comparing the few bits that aren't written by us or Tremor to ffmpeg's logs and be sure that they're Loren's? |
| 22:17:32 | funman | saratoga: sd_write_sectors() should be affected in the same way |
| 22:17:33 | saratoga | http://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/mdct.c;h=87908d3d667a35dbb74ff0189682e28e1c7f1320;hb=HEAD |
| 22:17:40 | saratoga | http://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/fft.c;h=facc6e05d968b2f44c398ab7afdb0b97c5b6196a;hb=HEAD |
| 22:17:46 | saratoga | shouldn't take more then a few minutes |
| 22:17:56 | saratoga | i listed everythign I could find in the email but a second pair of eyes would be nice |
| 22:18:03 | kugel | funman: there have been reports in the past, but not anymore since some other fixes in that are |
| 22:18:06 | kugel | area |
| 22:18:06 | saratoga | last thing I want is to overlook a few lines of LGPL'ed code |
| 22:19:10 | funman | kugel: iirc those fixes were related to usb ? |
| 22:19:22 | saratoga | there were ones for the SD driver, mostly concerning delays |
| 22:19:30 | funman | saratoga: LGPL code in rockbox would be ok ? |
| 22:19:31 | kugel | no, the problems were exposed by usb. but the problem was in the storage driver |
| 22:19:36 | saratoga | also i wonder if the function names need to be changed? its not clear to me if the LGPL covers the name of the functions if the code inside is changed |
| 22:19:49 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 22:20:14 | funman | saratoga: see recent threads on ffmpeg-devel ML about this problem (it's about variable names mentioned in specifications, but it's the same for function names) |
| 22:20:36 | saratoga | funman: i read those but IMO a function declaration is somewhat longer then a single character variable name |
| 22:20:59 | funman | function prototypes aren't copyrightable IMO |
| 22:21:03 | saratoga | i wonder if its worth changing just so that people don't carelessly assume we have relicensed the whole ffmpeg code |
| 22:21:09 | saratoga | ok that makes sense |
| 22:21:28 | funman | it defines the data it operates on, not how it operates |
| 22:22:02 | saratoga | its not even the prototype actually, since we don't use those, just the names |
| 22:22:10 | saratoga | so its even more ok |
| 22:22:54 | kugel | saratoga: willing to test an eabi bootlaoder on your e200v2? |
| 22:23:03 | saratoga | stripwax: anyway if you could take a quick look and let me know if I've missed anything that would be great, then we can remove teh LGPL notices on the code and switch to BSD headers |
| 22:23:20 | saratoga | kugel: maybe, i've never actually tried unbricking one |
| 22:23:31 | saratoga | maybe getting someone whos unbricked before to try it would be better |
| 22:23:39 | kugel | ok, we can wait for mc2739, he said he was prepared for unbricking |
| 22:24:18 | saratoga | i guess maybe putting dual rockbox/GPL and BSD headers would be nicer, that way its clear that its our code but we're letting others use it under bsd if they want |
| 22:24:57 | kugel | is tremor bsd or why do we need bsd? |
| 22:26:07 | kugel | funman: was there a reason our boot.lds doesn't have NOLOAD for stack/bss or was that due to c&p? |
| 22:27:51 | stripwax | saratoga - ok (but a bit confused) - we're talking about just giving the ffmpeg ifft/imdct (under bsd) to upstream Tremor, or also about putting our changes into upstream ffmpeg (latter seems much harder on the face of it and maybe not as desirable) |
| 22:28:51 | kugel | why should it be undesirable= |
| 22:29:01 | funman | kugel: c&p (or another shameful reason) |
| 22:29:01 | | Quit anewuser () |
| 22:29:21 | Buschel | pixelma: did you encounter any issues when testing your m5 (or x5?) with the new iram config? |
| 22:29:57 | funman | saratoga: dual BSD/GPL licensing ? I would just put BSD licensing with a rockbox ASCII header, but the choice is yours of course |
| 22:30:17 | stripwax | kugel - ffmpeg has a bunch of flexibility that tremor imdct does not - I don't think we'd want to remove flexibility from upstream ffmepg - but hard to add our changes to upstream ffmpeg without a lot of effort/rewriting I think |
| 22:30:33 | stripwax | ^tremor imdct^tremor imdct and rockbox's ffmpeg-derived imdct |
| 22:31:57 | linuxstb | funman: I would agree. Dual BSD/GPL seems a bit pointless (unless I've missed something...) |
| 22:32:01 | kugel | saratoga: you can also add that the rockbox header must not be removed if you insist on showing that it is our code :) |
| 22:33:54 | funman | then that becomes BSD 3 clauses? |
| 22:34:47 | | Quit Zagor (Quit: Clint excited) |
| 22:35:36 | kugel | bsd has 4 originally, IIRC |
| 22:37:53 | kugel | stripwax: is that ^ the new s/x/y/? :) |
| 22:38:48 | pixelma | Buschel: haven't tested my M5 yet |
| 22:39:12 | stripwax | kugel - yeah |
| 22:39:12 | Buschel | ok, give me a sign, if something goes wrong |
| 22:40:40 | saratoga | pure BSD with rockbox header also seems fine to me |
| 22:40:52 | saratoga | kugel: yes Tremor is BSD to encourage companies to support Vorbis |
| 22:41:24 | saratoga | i don't see much point in porting our changes upstream to ffmpeg right now, they have no support for fixed point codecs and some of our changes will be undesirable to them regardless |
| 22:44:33 | kugel | I thought they wanted to maintain 1 fixed point and 1 floating point code path per codec? |
| 22:44:57 | saratoga | they didn't seem very serious about it when we talked to them |
| 22:45:02 | saratoga | so for now I think thats not happening |
| 22:45:27 | funman | kugel: IMO not necessarily, there are fixed-point only codecs in the tree i think |
| 22:47:11 | kugel | at some point someone will make a librbcodec anyway which will beat ffmpeg :) |
| 22:47:30 | kugel | hm, maybe not :) |
| 22:47:51 | | Quit efyx_ (Remote host closed the connection) |
| 22:48:06 | Stephen__ | any theme admins about ? |
| 22:48:14 | | Quit planetbeing__ (Quit: planetbeing__) |
| 22:48:20 | kugel | Stephen__: yes |
| 22:48:51 | Stephen__ | can you tell thru checkwps whatsa wrong with the nanos electricbarsofcolour ? theres a user on the forum asking about it |
| 22:49:13 | kugel | not without compiling it myself |
| 22:49:17 | S_a_i_n_t_ | I have a theory on that theme...."its ugly" :P |
| 22:49:32 | Stephen__ | I have an idea whats wrong but not sure |
| 22:49:38 | Stephen__ | I like that theme :op |
| 22:50:09 | S_a_i_n_t_ | <bias>nah...Symmetry is the best Nano theme ever</bias> |
| 22:50:11 | S_a_i_n_t_ | :D |
| 22:51:20 | Stephen__ | nope not what i thought was wrong anyway |
| 22:52:33 | pixelma | tried removing the 0|0| in the backdrop tag? Not sure if it breaks something but it's at least not necessary |
| 22:52:58 | Stephen__ | just noticed my e200 theme of same is broke too. |
| 22:53:13 | S_a_i_n_t_ | backdrop shoulldn't have any positioning tags...that could well be it. |
| 22:53:15 | | Join TMM [0] (~hp@pdpc/supporter/professional/TMM) |
| 22:53:33 | S_a_i_n_t_ | *shouldn't even.. |
| 22:54:39 | | Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-wlaaqorjquxlykkg) |
| 22:54:44 | Stephen__ | will check now just about to update my one |
| 22:58:30 | *** | Saving seen data "./dancer.seen" |
| 22:58:31 | | Join kugel_ [0] (~kugel@e178077210.adsl.alicedsl.de) |
| 22:58:35 | | Quit froggyman (Read error: Connection reset by peer) |
| 22:59:02 | Stephen__ | nope that's not it |
| 22:59:11 | | Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 23:00 |
| 23:00:11 | | Join JdGordon [0] (~jonno@m0e0e36d0.tmodns.net) |
| 23:02:06 | | Quit kugel (Ping timeout: 265 seconds) |
| 23:03:07 | | Quit kugel_ (Ping timeout: 260 seconds) |
| 23:10:57 | | Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 23:11:06 | Stephen__ | time to set p a new sim and test |
| 23:13:38 | | Quit pamaury (Quit: Page closed) |
| 23:15:25 | | Join planetbeing_ [0] (~planetbei@32.154.30.76) |
| 23:15:35 | | Join kugel [0] (~kugel@e178085094.adsl.alicedsl.de) |
| 23:15:39 | | Join planetbeing__ [0] (~planetbei@32.154.30.76) |
| 23:15:48 | | Quit kugel (Changing host) |
| 23:15:48 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 23:16:12 | | Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) |
| 23:18:26 | | Quit JdGordon (Quit: Bye) |
| 23:18:29 | | Quit planetbeing (Ping timeout: 245 seconds) |
| 23:18:29 | | Nick planetbeing_ is now known as planetbeing (~planetbei@32.154.30.76) |
| 23:21:08 | Stephen__ | whats the command for building the sim without plugins again ? |
| 23:21:42 | linuxstb | "make help" |
| 23:21:54 | linuxstb | (I expect "make bin" would do that) |
| 23:23:16 | | Quit nima (Read error: Connection reset by peer) |
| 23:26:07 | | Quit evilnick_B (Quit: Page closed) |
| 23:28:08 | | Join nima [0] (~nima@adsl-75-45-227-18.dsl.sfldmi.sbcglobal.net) |
| 23:30:13 | CIA-5 | New commit by peter (r25074): change histogram display principle to scrolling and simplify the code a bit |
| 23:32:06 | kugel | Stephen__: you're going to need codecs to see the wps though |
| 23:32:32 | Stephen__ | true. then jus without plugins. i know theres a && in there |
| 23:33:08 | kugel | make bin && make codecs |
| 23:33:34 | kugel | don't forget make install at the end |
| 23:34:25 | Stephen__ | thanks kugel |
| 23:37:42 | | Quit bmbl (Quit: Bye!) |
| 23:38:00 | Llorean | More forum spam, user kar22 |
| 23:38:28 | CIA-5 | New commit by Domonoky (r25075): fix automatic upgrade of db. store checkwps output in db. display it as mouseover on the "doesnt work on x build". |
| 23:39:18 | CIA-5 | New commit by Buschel (r25076): Fix musepack sv8 metadata parser. Thanks to Magnus Holmgren for spotting. |
| 23:39:22 | pixelma | to recap: I was testing rbspeexenc on different Macs and the binaries ran perfectly on an Intel running MacOS 10.5 - could not be executed on an Intel MacOS 10.4 and the PPC binaries worked on such a Mac with 10.4 but produced noise. Any ideas? |
| 23:40:57 | kugel | Unhelpful: you seemed to be interested in a newer gcc as well. any opinion to my proposal on the ml? |
| 23:41:13 | domonoky | the intel binarys are probably built against a 10.5 sdk, the ppc issue is interesting. |
| 23:41:45 | linuxstb | pixelma: Could you test decoding a .spx file on the opposite architecture to the one it was created on (PPC vs Intel) ? i.e. is encoding broken, or decoding, or both? |
| 23:41:55 | domonoky | pixelma: does it produce noise with any test wav ? or only those generated by rbutil (on intel mac) . |
| 23:41:58 | pixelma | originally I tested bluebrother's RbUtil which makes use of the Apple TTS which again ran perfectly on the 10.5 Intel, worked correctly with the 10.4 Intel but only for MP3 voice targets - it produced sound but just noise for a speex voice target, and hung completely on the 10.4 PPC |
| 23:42:18 | CIA-5 | New commit by peter (r25077): fix yellow |
| 23:42:44 | moos | Buschel: well done! You finally found it |
| 23:43:13 | Buschel | well, in fact Lear and I found and fixed it the same time :) |
| 23:43:35 | | Quit p3tur (Remote host closed the connection) |
| 23:43:47 | moos | ohoh goos syncronisation then |
| 23:43:51 | moos | good |
| 23:44:19 | pixelma | domonoky: I just tested the wav generated by "Test TTS" but that sounded correctly when listening to with Rockbox |
| 23:44:44 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 23:44:59 | domonoky | pixelma: it might still be in a wav format rbspeex doesnt like. |
| 23:45:04 | pixelma | (generated by the 10.4 Intel which is probably correct if voice generation for MP3 voice works there |
| 23:45:47 | domonoky | for mp3 lame compresses the generated wav file, which probably supports more wav formats then rbspeex. |
| 23:46:08 | | Quit petur (Quit: Zzzz) |
| 23:47:04 | pixelma | ok, I'll try to test tomorrow with a different wav |
| 23:48:48 | Stephen__ | domonoky, thank you so much for r25075! makes life very much easier! |
| 23:49:01 | pixelma | linuxstb: I tested the 10.5 Intel intermediate speex with rbspeexdec on the PPC and it produced noise too, file size was the same for the resulting wav in all tests (the noise sounded slightly different from the PPC > PPC noise) |
| 23:49:32 | pixelma | domonoky: but why would it work correctly on the 10.5 Intel? |
| 23:49:33 | Buschel | good night! |
| 23:49:35 | | Quit Buschel () |
| 23:52:47 | domonoky | pixelma: everthing works on 10.5 intel ? so this testwav encoded/decoded with rbspeex on this mac is fine ? |
| 23:53:04 | pixelma | yes |
| 23:53:07 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:55:39 | | Quit bertrik (Quit: De groeten) |
| 23:55:54 | domonoky | strange, if we have noise on 10.4 intel and 10.4 ppc it cant be endianess issues.. |
| 23:57:11 | domonoky | and if it works on 10.5 it looks like some sdk issue, but thats pretty unlikely for a software like rbspeex... :-/ |
| 23:57:17 | pixelma | wel in 10.4l we have noise in rbspeexenc on PPC and non-working state on Intel, and RbUtil is the different way around |
icon identifies that the person is a core developer (has commit access).