| 00:01:09 | jlbiasini | Ok i'm recompiling but it might take while because I'm also recompiling my kernel |
| 00:01:16 | jlbiasini | pamaury: http://pastebin.com/yt2HSJiP |
| 00:01:45 | jlbiasini | that's a nasty |
| 00:02:27 | pamaury | indeed |
| 00:02:52 | jlbiasini | oh wait I did not #include <sigaction.h> |
| 00:03:14 | jlbiasini | just asm/signal |
| 00:03:32 | | Join dynion [0] (~52a896aa@www.haxx.se) |
| 00:03:40 | pamaury | try sigaction and remove asm/signal |
| 00:05:49 | | Quit Strife89 (Ping timeout: 245 seconds) |
| 00:07:14 | jlbiasini | pamaury: http://pastebin.com/5eK4TeY2 |
| 00:08:55 | | Quit nomada (Ping timeout: 255 seconds) |
| 00:09:17 | pamaury | ok, don't mind, if it works with this that's fine, we'll see this tomorrow |
| 00:10:11 | | Quit dynion (Quit: CGI:IRC) |
| 00:10:13 | jlbiasini | no it doesn't but obvouisly it's just about to find which file to include |
| 00:10:16 | | Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) |
| 00:10:31 | jlbiasini | well at least it does with the parameter remplace |
| 00:10:36 | jlbiasini | manually |
| 00:10:51 | jlbiasini | Anyway I'm going to bed to |
| 00:11:10 | | Quit jlbiasini (Quit: jlbiasini) |
| 00:12:34 | | Quit mt_ (Ping timeout: 248 seconds) |
| 00:18:13 | | Quit Rower (Quit: Hmmm...) |
| 00:18:18 | | Quit Tim_Elliott (Quit: Leaving) |
| 00:20:15 | | Join mt [0] (~quassel@41.233.134.80) |
| 00:20:16 | | Quit mt (Changing host) |
| 00:20:16 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 00:27:52 | | Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 19.0/20130116072953]) |
| 00:36:50 | | Join [Saint] [0] (~quassel@101.98.158.103) |
| 00:37:11 | | Nick [Saint] is now known as Guest78563 (~quassel@101.98.158.103) |
| 00:40:04 | | Quit Edsansaclipplus (Quit: CGI:IRC) |
| 00:42:17 | [Saint_] | I got some totally unexpected results with test_codec and the 10 band eq. |
| 00:42:29 | [Saint_] | I'll put them up on the gerrit page now. |
| 00:43:04 | [Saint_] | long story short, it turns out that when compared to the 5 band eq, the 10 band eq made decoding slightly faster. |
| 00:43:34 | [Saint_] | possibly because it actually needed to boost occasionally? (a classic)...dunno. |
| 00:44:10 | gevaerts | I don't think test_codec output goes through the eq |
| 00:44:41 | [Saint_] | Ahhhhhh...right. |
| 00:44:58 | [Saint_] | I thought "with dsp" used the eq. |
| 00:45:24 | gevaerts | Ah, is there a "with dsp" option? |
| 00:45:33 | [Saint_] | Ok, well...that's entirely disinteresting then ;) |
| 00:45:33 | * | gevaerts isn't sure then |
| 00:46:04 | [Saint_] | there's a few test_codec options, speed test, and speed test with dsp is what I used. |
| 00:46:19 | [Saint_] | you can also restrict boosting iirc. |
| 00:47:10 | * | gevaerts recommends waiting for someone knowledgeable to wander in |
| 00:51:12 | | Part zaphee |
| 00:52:38 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 00:53:28 | | Quit Guest38472 (Read error: Connection reset by peer) |
| 00:54:50 | | Join TheSphinX_ [0] (~briehl@p5B321F9C.dip.t-dialin.net) |
| 00:57:20 | | Quit TheSphinX^ (Ping timeout: 240 seconds) |
| 01:00 |
| 01:07:35 | * | [Saint_] is fairly willing to assume that the 'with dsp' option is actually using the eq. |
| 01:07:45 | [Saint_] | the code got me lost, though. |
| 01:08:03 | | Quit pamaury (Ping timeout: 256 seconds) |
| 01:14:57 | | Quit funman (Ping timeout: 252 seconds) |
| 01:16:04 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 01:18:33 | | Quit ParkerR (Excess Flood) |
| 01:19:51 | | Join TheSphinX^ [0] (~briehl@p579CCF09.dip.t-dialin.net) |
| 01:20:39 | | Quit bluebrother (Disconnected by services) |
| 01:20:42 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 01:21:29 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 01:21:51 | | Quit fs-bluebot (Ping timeout: 248 seconds) |
| 01:22:55 | | Quit TheSphinX_ (Ping timeout: 245 seconds) |
| 01:23:08 | | Join fs-bluebot [0] (~fs-bluebo@g224236060.adsl.alicedsl.de) |
| 01:25:23 | | Join funman_ [0] (~fun@rockbox/developer/funman) |
| 01:25:38 | | Quit ParkerR (Excess Flood) |
| 01:27:34 | [Saint_] | nicely formatted test_codec results of 10 band eq documented at g386 now: |
| 01:27:36 | fs-bluebot | Gerrit review #386 at http://gerrit.rockbox.org/r/386 : 10 Band EQ w/Presets adapted from VLC by Hayden Pearce (changes/86/386/4) |
| 01:29:08 | | Quit funman (Ping timeout: 276 seconds) |
| 01:29:12 | [Saint_] | the classic is a bit of a beast. flac_8 in ~9MHz, lame_320 and vorbis_500 in ~30MHz |
| 01:30:01 | JdGordon | [Saint_]: are you going to deal with the inline comments? |
| 01:30:45 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 01:31:11 | [Saint_] | I didn't quite understand your comment. I'm not reinventing the wheel...it's exactly the same as it's done in git HEAD, just...more of it. |
| 01:32:05 | [Saint_] | Comments on the task I adapted it from said it would be accepted as is if it was proven to run on all targets. |
| 01:32:22 | [Saint_] | Basically all I did was change the frequency stepping and add presets. |
| 01:32:48 | [Saint_] | and sync an ancient patch to HEAD |
| 01:33:59 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 01:34:25 | JdGordon | replacing those magic values with a #define would make it much nicer |
| 01:34:38 | JdGordon | easier to change how many bands are available |
| 01:34:52 | JdGordon | i.e the low ram targets may only want 5 bands |
| 01:35:24 | [Saint_] | from what I can see, it _should_ run on all targets that have the eq already. there's a 1~2MHz increase or less in CPU usage, and the small screen targets already scroll to accommodatethe gui eq screen so I thought it was pretty much good to go. |
| 01:36:56 | [Saint_] | sorry, that is poorly worded. that cpu usage increase is caused by using the dsp anyway...the increase from the extra bands is very trivial. |
| 01:37:02 | [Saint_] | ~1MHz or less. |
| 01:40:22 | soap | 1Mhz smells way too low. |
| 01:40:37 | [Saint_] | soap: since you seem to know about these things, do you think I should be using 32, 64, 125, 250, ... or 30, 60, 120, 250, ... |
| 01:41:12 | soap | I'm searching now as I can't believe saratoga or buschel hasn't already profiled this, but for a long time the video just about died on Senab's build with more bands turned on. |
| 01:41:26 | [Saint_] | and, I thought about that...but maybe it causes boosting more often? the classic can do all the codecs I tested fine without boosting in theory but I didn't disable boosting for the test_codec runs I did. |
| 01:41:27 | soap | and that's after MP3 was already below 30Mhz. |
| 01:41:55 | soap | my memory may be faulty as shit, so don't hold the boat on my account. |
| 01:42:07 | | Quit prof_wolfff (Ping timeout: 248 seconds) |
| 01:42:28 | [Saint_] | do you have a suggestion about the frequency stepping? 32, 64, ... vs 30, 60, ...? |
| 01:44:11 | | Quit Raptors (Read error: Connection reset by peer) |
| 01:44:40 | soap | My headphones / truck can't do 30 and my ears can't hear 16 in music, so put them where you like! ;) The center points will be changeable, no? |
| 01:45:16 | [Saint_] | correct. |
| 01:45:50 | [Saint_] | It confuses me, if ISO 266 is indeed a preferred standard, then why does virtually nothing seem to use it? :-S |
| 01:47:16 | soap | what do you mean? |
| 01:47:16 | soap | http://www.gearhounds.com/ProductImages/MXR_10_BAND_EQ_M108_Lg.jpg |
| 01:47:25 | soap | http://www.dak.com/reviews/imagesR4/3211_EQ_Slidersss.jpg |
| 01:48:27 | soap | 10-bands on even octaves starting at 30 has long been standard. Isn't that what ISO 266 is asking for? |
| 01:48:42 | [Saint_] | well, according the the patch I was reading from ISO 266 standard is 30, 60, 120, 250 |
| 01:48:53 | | Nick funman_ is now known as funman (~fun@rockbox/developer/funman) |
| 01:49:01 | [Saint_] | but lots of stuff is at 32, 64, 125, 250, ... |
| 01:49:28 | soap | you see a 15 band hardware EQ it's most likely 2/3rds of an octave, again with the same range |
| 01:50:07 | soap | the real number is 31.25 |
| 01:50:16 | soap | 1000/16 |
| 01:50:26 | soap | excuse me - 32 |
| 01:50:53 | soap | different people have rounded the text on hardware eqs differently. |
| 01:52:21 | [Saint_] | I don't think we can do decimals, the accepted values is just in Hz, so 32, ~, 16000. |
| 01:52:55 | [Saint_] | I wasn't sure what to do with the rounding, as its clearly closer to 31, but it seems to be common to use 32 and double from there. |
| 01:53:48 | [Saint_] | double from 16 or 32, then round to 125 and double from there. |
| 01:55:46 | *** | Saving seen data "./dancer.seen" |
| 01:55:49 | | Nick [Saint_] is now known as [Saint] (~saint@rockbox/user/saint) |
| 01:56:05 | | Quit mt (Read error: Connection reset by peer) |
| 01:57:42 | [Saint] | if anyone else wants to do the same/similar test with other targets, I would appreciate it. |
| 01:57:48 | | Join froggymana [0] (~me@dhcp-155-92-103-232.nebula.msoe.edu) |
| 01:57:48 | | Quit froggymana (Changing host) |
| 01:57:48 | | Join froggymana [0] (~me@unaffiliated/froggyman) |
| 01:58:00 | [Saint] | I will test on an iPod Color this evening. |
| 01:58:02 | | Join mt [0] (~quassel@41.233.134.80) |
| 01:58:02 | | Quit mt (Changing host) |
| 01:58:02 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 01:58:13 | | Quit froggymana (Remote host closed the connection) |
| 01:58:49 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
| 02:00 |
| 02:00:17 | [Saint] | The way I did it was three runs of test_codec for each case: speed test HEAD w/oDSP, speed test HEAD w/DSP, speed test 10 Band EQ patch w/DSP; average the results. |
| 02:00:20 | soap | the ipod color should answer the PP question once and for all |
| 02:01:14 | [Saint] | One run is probably enough, I did three and averaged just to try to get a clearer picture and hopefully eliminate the possibility of a 'miracle run'. |
| 02:02:32 | [Saint] | I don't have any AMS players I can get to easily, so if someone got bored and had a Clip/Fuze/etc laying around, go nuts. |
| 02:03:51 | [Saint] | I've been trying out the presets today, and although they're kinda kludged they're really not too bad. |
| 02:06:11 | | Quit ParkerR (Excess Flood) |
| 02:06:20 | [Saint] | One thing this made me think of, as well, is that Rockbox really needs a "first run script". Something capable of inclusion into a build that runs once after boot and then wipes itself out. SO that one can easily remove depricated files. |
| 02:07:09 | [Saint] | For example, were this committed, there would be several 5 band EQ presets leftover in the users eqs folder that would be useless. |
| 02:08:56 | [Saint] | could probably do it with LUA and the rockboot feature or whatever it's called. |
| 02:09:09 | [Saint] | </brainfart> |
| 02:09:28 | | Quit ender| (Read error: Operation timed out) |
| 02:09:45 | soap | the worst that could happen is they load an old .cfg and only the first 5 bands get set, right? You didn't change the .cfg format did you? |
| 02:10:39 | [Saint] | no. |
| 02:11:39 | [Saint] | I just thought it might be nice to have a way to guarantee we could wipe out depricated files without user intervention. |
| 02:12:09 | soap | what if the user created their own files i the /.rockbox/eqs? |
| 02:12:14 | soap | would you wipe those too? |
| 02:12:24 | soap | or just the rockbox-issued ones? |
| 02:12:41 | [Saint] | Only known files, ones that came with a previous binary. |
| 02:12:47 | [Saint] | SHouldn't ever wipe user files. |
| 02:12:49 | soap | own files IN /.rockbox/eqs |
| 02:12:53 | soap | right |
| 02:13:04 | soap | so just ship new preset replacements for all |
| 02:13:24 | | Join TheSphinX_ [0] (~briehl@91.50.35.246) |
| 02:13:27 | soap | only use 5 bands of the possible 10 of the ones you don't feel up to reworking. define the other five bands as off. |
| 02:14:02 | [Saint] | Ah, right, yes. good point. |
| 02:14:09 | [Saint] | I can do that, genius. |
| 02:14:39 | [Saint] | Another is caused by me renaming Default to Flat to be more obvious, but I can undo that I guess. |
| 02:14:59 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 02:15:01 | | Quit TheSphinX^ (Read error: Operation timed out) |
| 02:15:18 | Torne | or just ship two opies |
| 02:15:21 | Torne | they rae tiny |
| 02:15:23 | Torne | nobody cares |
| 02:15:49 | [Saint] | have Default (the previous, 5 band eq), and Flat (the new, 10 band eq)? |
| 02:16:02 | Torne | no, i mean, just ship two copies of exactly the same flat 10 band preset |
| 02:16:06 | Torne | with both names |
| 02:16:10 | [Saint] | Ah. |
| 02:16:14 | Torne | because it's a tiny textfile and who cares |
| 02:16:29 | soap | user confusion. "I had selected default and found rockbox so warm and balanced. I then tried flat and all the subtle foot tapping goodness went away and the soundstage collapsed" |
| 02:16:38 | Torne | lol |
| 02:17:02 | [Saint] | audiophile trap for patrick82 wannabes |
| 02:17:03 | [Saint] | ;) |
| 02:17:28 | soap | then ship one called "Apple.cfg" and another "Cowon.cfg" and make them both flat. |
| 02:17:34 | soap | if you /really/ want to troll. |
| 02:18:58 | [Saint] | But, anyway, ok...yeah, I'll convert the existing 5 band presets to 10 band and and just leave the new frequency steps with 0 values. |
| 02:19:37 | [Saint] | but...hum...no, I don't really like that idea. |
| 02:19:46 | [Saint] | maybe I should try and guestimate the gaps. |
| 02:21:00 | [Saint] | it would be nice if there was a way to wipe them out... |
| 02:22:44 | [Saint] | yeah, I might try and fill the blanks instead of leaving the values blank. |
| 02:25:47 | | Join ender| [0] (whatever@2a01:260:4094:1:42:42:42:42) |
| 02:28:56 | [Saint] | Ok, I'll do that when I get back home from my pending missions out and about, then as far as I'm concerned it should be able to be committed unless anyone comes up with a target that it completely destroys runtime/realtime playback on. |
| 02:30:24 | [Saint] | I'll bench the iPod Color and a Nano2G as well, and maybe a Fuze if I can find it. I could probably also do RaaA but I'm not sure if that really matters. |
| 02:33:05 | [Saint] | Do you think it might help if I provided test binaries and put them on the forum? |
| 02:35:27 | Torne | i have found generally that if i do that i get maybe one or two people testing half a dozen common players |
| 02:35:31 | Torne | which is better than nothing |
| 02:35:43 | Torne | it depends how much you have scripted making the test builds :) |
| 02:35:58 | Torne | if you have a sinlge command to do it and can jut leave it for a couple hours and get a dir of zips then it's worth it ;) |
| 02:36:04 | Torne | i think our release script will do it in fact no? |
| 02:41:04 | saratoga | [Saint]: something is wrong with those benchmarks |
| 02:41:16 | saratoga | its probably about 1-2 MHz per EQ band on ARMv5 |
| 02:42:06 | [Saint] | Well, I can only go by what test_codec gave me...is test_codec actually using the EQ with the "speed test with DSP" option? |
| 02:42:29 | [Saint] | As near as I can figure it is. |
| 02:42:58 | saratoga | it should |
| 02:43:07 | saratoga | are all 10 bands actually enabled though? |
| 02:43:18 | [Saint] | The other thing I thought of is that perhaps I should do the test with boosting disabled. |
| 02:43:20 | [Saint] | yes. |
| 02:43:52 | [Saint] | I thought perhaps this actually caused more boosting during decoding and thats why there was a very trivial difference. |
| 02:44:25 | saratoga | the codec results are done at constant clock speed |
| 02:44:36 | [Saint] | but, anyway, yeah...that's the average of three runs on test_codec. |
| 02:44:47 | [Saint] | besides doing them again, not sure what else I can do. |
| 02:44:51 | saratoga | basically what those results probably indicate is that the EQ isn't enabled in test_codec for some reason |
| 02:45:01 | [Saint] | I'll be testing other targets tonight as well. |
| 02:45:33 | [Saint] | well the with/without DSP runs are clearly different... |
| 02:45:48 | [Saint] | There just doesn't seem to be much difference in adding 5 more bands. |
| 02:46:10 | [Saint] | But there is a clear difference with speed test with and without DSP. |
| 02:46:32 | [Saint] | +~2MHz on the Classic |
| 02:49:22 | saratoga | the difference is due to the normal DSP code |
| 02:49:27 | saratoga | the EQ isn't being called though |
| 02:49:51 | saratoga | looking at the code i don't see how it wouldn't be called |
| 02:50:01 | saratoga | are you sure you actually have all 10 bands configured in settings? |
| 02:51:00 | Torne | you know i keep getting tempted to make a little thing for our website thta just asks you a series of questions to determine if your ipod is supported or not |
| 02:51:04 | Torne | well not just ipod, player |
| 02:51:41 | Torne | people do not read our list, and even when they do there are things not on the list (like early wip ports), and then they constantly get their model wrong |
| 02:51:50 | saratoga | "Is it listed on the front page" "No? |
| 02:51:54 | saratoga | "Go away" |
| 02:51:58 | Torne | saratoga: right but that doesn't help if they don't know what it is |
| 02:52:01 | Torne | which lots of people don't |
| 02:52:08 | Torne | e.g. all the ipodvideo/classic confused folks |
| 02:52:44 | Torne | are there still ports on TargetStatus that aren't listed on the front page at all? |
| 02:52:49 | Torne | or did someone fix that |
| 02:53:11 | Torne | yeah, there are |
| 02:53:12 | Torne | e.g. xfi |
| 02:53:28 | [Saint] | [14:50:03] <saratoga> are you sure you actually have all 10 bands configured in settings? <−− quite |
| 02:54:41 | [Saint] | perhaps I should do the tests with a very aggressive and unrealistic amount of gain/precut on each band? |
| 02:55:15 | [Saint] | At the moment I'm using a quite sane "Pop" preset. |
| 02:55:48 | [Saint] | But, iiuc, it shouldn't matter even if I have "Flat/Default enabled. |
| 02:56:47 | [Saint] | By my understanding it shouldn't matter if the EQ is on, but all values are set flat, it should still consume additional CPU cycles...correct? |
| 02:57:12 | Torne | i would hope not |
| 02:57:18 | Torne | iwould hope we skip processing for bands that are on 0db |
| 02:58:10 | [Saint] | I got lost quite quickly in the code. |
| 02:58:14 | [Saint] | quite quickly. |
| 02:58:31 | Torne | well set every band to 1db an dsee :) |
| 02:59:58 | [Saint] | I'll re-test when I get back from my missions, I'll do the same test, but this time with very aggressive gain/precut, basically creating an artificial 'worst case scenario'. |
| 03:00 |
| 03:00:09 | saratoga | just looking at the code its about 5 multiplies, loads and stores per sample, and you do 88200 samples per second |
| 03:00:10 | [Saint] | See if that makes a considerable difference. |
| 03:00:43 | saratoga | so figure 2 cycles per op times ~10 ops times 100k samples = 2MHz per band |
| 03:02:05 | [Saint] | but, anyway, yeah...I'm procrastinating. I need to get on with my missions. Leave a comment on the tracker if you test on other targets before I get a chance to, or leave a message in the logs for me. o/ |
| 03:03:10 | saratoga | (for armv5, figure about double that on armv4 due to half speed multiplier and load unit) |
| 03:07:38 | | Quit Guest78563 (Ping timeout: 276 seconds) |
| 03:38:58 | | Quit user890104 (Read error: Operation timed out) |
| 03:39:24 | | Join Xerion_ [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
| 03:39:27 | | Join user890104 [0] (Venci@unaffiliated/user890104) |
| 03:40:00 | | Quit Xerion (Read error: Connection reset by peer) |
| 03:40:01 | | Nick Xerion_ is now known as Xerion (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
| 03:55:47 | *** | Saving seen data "./dancer.seen" |
| 03:57:11 | saratoga | " Assume a band is disabled if the gain is zero " |
| 03:57:18 | saratoga | looks like they're skipped if there is no gain |
| 04:00 |
| 04:04:27 | | Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) |
| 04:08:01 | | Join TheSphinX^ [0] (~briehl@p579CCA5E.dip.t-dialin.net) |
| 04:11:47 | | Quit TheSphinX_ (Ping timeout: 245 seconds) |
| 04:12:55 | | Join [Saint_] [0] (~quassel@101.98.158.103) |
| 04:13:19 | | Nick [Saint_] is now known as Guest62018 (~quassel@101.98.158.103) |
| 04:27:13 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:27:14 | | Quit amiconn (Disconnected by services) |
| 04:27:16 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:27:19 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 04:27:45 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:27:45 | | Quit pixelma (Disconnected by services) |
| 04:27:47 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 05:00 |
| 05:17:53 | | Join thegeek_ [0] (~thegeek@110.36.34.95.customer.cdi.no) |
| 05:18:55 | | Quit TheSeven (Disconnected by services) |
| 05:19:05 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 05:20:50 | | Quit thegeek (Ping timeout: 240 seconds) |
| 05:22:43 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
| 05:26:37 | | Quit jhMikeS (Ping timeout: 256 seconds) |
| 05:32:05 | | Join TheSphinX_ [0] (~briehl@p5B321DFB.dip.t-dialin.net) |
| 05:34:27 | | Quit TheSphinX^ (Ping timeout: 248 seconds) |
| 05:55:51 | *** | Saving seen data "./dancer.seen" |
| 05:56:36 | | Join TheSphinX^ [0] (~briehl@p579CC972.dip.t-dialin.net) |
| 05:56:47 | | Quit [Saint] (Remote host closed the connection) |
| 06:00 |
| 06:00:11 | | Quit TheSphinX_ (Ping timeout: 264 seconds) |
| 06:03:49 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 06:12:57 | | Quit saratoga (Ping timeout: 245 seconds) |
| 07:00 |
| 07:10:48 | | Quit SuperBrainAK (Quit: pbly going to sleep /_\) |
| 07:12:28 | | Quit Buglouse (Read error: Operation timed out) |
| 07:14:33 | | Join webguest59 [0] (~6378e8b5@www.haxx.se) |
| 07:17:04 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 07:19:25 | | Quit scorche` (Ping timeout: 256 seconds) |
| 07:21:17 | | Quit webguest59 (Quit: CGI:IRC (EOF)) |
| 07:26:09 | | Join Roboturner913 [0] (6378e8b5@gateway/web/freenode/ip.99.120.232.181) |
| 07:27:29 | Roboturner913 | Who knows stuff about the Fuze+? |
| 07:28:12 | Roboturner913 | Specifically, I am trying to figure out a nasty screen flicker.... |
| 07:29:38 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 07:36:18 | | Quit Roboturner913 (Quit: Page closed) |
| 07:39:49 | | Quit Buglouse (Ping timeout: 255 seconds) |
| 07:40:29 | | Join enriched [0] (~quassel@101.98.163.139) |
| 07:53:07 | | Join jhMikeS [0] (~jethead71@50.4.240.19) |
| 07:53:07 | | Quit jhMikeS (Changing host) |
| 07:53:07 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 07:55:53 | *** | Saving seen data "./dancer.seen" |
| 07:58:41 | | Join melmothX [0] (~melmoth@unaffiliated/melmothx) |
| 07:59:50 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 08:00 |
| 08:00:56 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 08:01:54 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 08:19:58 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 08:22:27 | | Quit Buglouse (Ping timeout: 248 seconds) |
| 08:33:25 | | Join Zagor [0] (~bjst@sestofw01.enea.se) |
| 08:33:25 | | Quit Zagor (Changing host) |
| 08:33:25 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 08:37:43 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 09:00 |
| 09:00:32 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 09:01:57 | | Quit Buglouse (Ping timeout: 246 seconds) |
| 09:05:51 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 09:10:59 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:18:03 | | Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) |
| 09:20:23 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 09:26:53 | | Quit bertrik (Ping timeout: 276 seconds) |
| 09:38:28 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 09:44:23 | | Join pystar89 [0] (~pystar89@ip-37-24-1-174.unitymediagroup.de) |
| 09:52:35 | | Quit Buglouse (Ping timeout: 276 seconds) |
| 09:55:54 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:00:48 | | Quit Guest62018 (Ping timeout: 248 seconds) |
| 10:02:53 | | Join jlbiasini [0] (~metaphysi@109.103.46.91) |
| 10:25:30 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 10:27:41 | jlbiasini | pamaury: kugel: I found the missing include it's <signal.h> and not <asm/signal.h> |
| 10:42:05 | | Quit Buglouse (Ping timeout: 252 seconds) |
| 10:46:11 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 10:46:49 | | Join bebna [0] (~a.fasold@94.101.33.114) |
| 10:52:27 | kugel | jlbiasini: pamaury said the thread-unix.c includes it already |
| 10:54:10 | jlbiasini | kugel: no it doesn't |
| 10:56:15 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 10:57:18 | jlbiasini | kugel so here we go http://gerrit.rockbox.org/r/#/c/387/ |
| 11:00 |
| 11:02:32 | wodz | how it is possible that other sims (as well as our buildfarm) does not signal problem? |
| 11:16:03 | kugel | jlbiasini: it's includedd a few lines above |
| 11:16:04 | jlbiasini | no idea or perhaps I'm missing a dev package on my debian? |
| 11:16:23 | jlbiasini | stupid me |
| 11:16:25 | kugel | the third include is <signal.h> |
| 11:16:46 | kugel | you just added it a second time. but perhaps the order is important |
| 11:16:48 | jlbiasini | How is it possible that it doesn't work if not double??? |
| 11:16:59 | jlbiasini | ah right ! |
| 11:17:17 | jlbiasini | I will try |
| 11:17:49 | kugel | sigcation needs _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE. I guess one of the header after define one of them |
| 11:24:58 | wodz | What about pushing g#339 and g#340? The only reason this is not merged yet is that dreamlayers is not active anymore. The patch is widely tested and closes quite serious problem on many targets advertised as stable. |
| 11:25:01 | fs-bluebot | Gerrit review #339 at http://gerrit.rockbox.org/r/339 : Fix FS #12391 : Memory corruption on PP502x after commit_discard_idcache() by Boris Gjenero (changes/39/339/1) |
| 11:25:21 | JdGordon | so push it |
| 11:26:33 | wodz | done |
| 11:27:02 | jlbiasini | kugel: ok I don't understand anything now it's working |
| 11:27:15 | jlbiasini | I reinstall the git tree |
| 11:27:55 | jlbiasini | I didn't had any unstashed change reported and everything up to date... quite a mystery... |
| 11:36:11 | | Join [Saint_] [0] (~quassel@101.98.158.103) |
| 11:36:35 | | Nick [Saint_] is now known as Guest25974 (~quassel@101.98.158.103) |
| 11:48:34 | | Quit efyx (Ping timeout: 248 seconds) |
| 11:50:46 | | Quit TheSphinX^ (Read error: Operation timed out) |
| 11:53:13 | [Saint] | new results at g386 |
| 11:53:36 | | Quit fs-bluebot (Read error: Connection reset by peer) |
| 11:53:59 | [Saint] | I must've accidentally reset the EQ to 0 during the initial testing. |
| 11:54:00 | wodz | hmm, magically bootloaders can't find commit_discard_dcache() when linking |
| 11:54:14 | [Saint] | New results show a clear increase in CPU usage. |
| 11:54:27 | [Saint] | But, not as much as I had been lead to believe it would be. |
| 11:54:59 | [Saint] | Except for flac...which got crippled by it. |
| 11:55:54 | | Join TheSphinX^ [0] (~briehl@87.156.195.228) |
| 11:55:56 | *** | Saving seen data "./dancer.seen" |
| 11:56:37 | [Saint] | lame 320 and vorbis 500 saw a ~5MHz gain for realtime decoding (~30MHz vs ~36MHz), but flac 8 /almost/ doubled in CPU usage from ~9MHz to ~15MHz. |
| 11:57:36 | wodz | ah right it doesn't build quite big part of system-pp502x.c for bootloader |
| 11:58:30 | wodz | 15 is still not much - below boost threshold |
| 12:00 |
| 12:01:51 | | Join efyx [0] (~efyx@91.179.16.102) |
| 12:04:35 | | Quit Buglouse (Ping timeout: 245 seconds) |
| 12:06:09 | wodz | Hmm, I think I'll revert last commit. I don't have time now to dive into code how this should be arranged. For bootloaders cache_init() is not called so I think using cache functions is not safe there. Comments are a bit scary. |
| 12:07:14 | kugel | [Saint]: cpu increase should be constant, regardless of the codec |
| 12:08:04 | gevaerts | [Saint]: are you forcing boost during testcodec runs? |
| 12:08:14 | [Saint] | No. |
| 12:08:41 | gevaerts | I'd consider doing that to reduce variables |
| 12:09:05 | wodz | test_codec boost by itself |
| 12:09:12 | wodz | *boosts |
| 12:09:41 | wodz | you have to *force unboost* to test unboosted performance |
| 12:09:56 | [Saint] | Aha, right. Ok. Good to know. |
| 12:11:52 | | Quit jlbiasini (Quit: jlbiasini) |
| 12:12:17 | kugel | gevaerts: testcodec always boosts |
| 12:12:33 | gevaerts | kugel: [Saint] told me it doesn't :) |
| 12:12:41 | * | gevaerts learns never to believe [Saint]! |
| 12:12:44 | kugel | he's wrong then :) |
| 12:13:58 | gevaerts | [Saint]: by the way, could you run a set of APE benchmarks on the classic one of these days? |
| 12:14:17 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 12:17:50 | [Saint] | APE crashes and burns. |
| 12:17:56 | [Saint] | And I don't know why. |
| 12:18:03 | [Saint] | So does wmapro |
| 12:18:11 | [Saint] | All I get is high pitched noise. |
| 12:18:31 | gevaerts | I meant in test_codec |
| 12:18:37 | [Saint] | It either outputs a terrible noise, or skips the file completely. |
| 12:18:43 | gevaerts | Still, if it's buggy, not worth trying :) |
| 12:19:02 | [Saint] | I don't know what the problem with it is... |
| 12:19:17 | [Saint] | I thought it was my test_files library became corrupt...but, nope. |
| 12:19:56 | [Saint] | I first noticed it when I saw test_codec claiming 16000000% realtime for APE |
| 12:22:58 | wodz | I don't understand it. HAVE_ATA_DMA for PP was disabled in 55fab77 so before it had to build cleanly. Now enabling it again spits errors for bootloaders. In the meantime I don't see any significant changes. |
| 12:23:10 | wodz | any clues? |
| 12:30:36 | pamaury | wodz: missing include when in bootloader ? |
| 12:30:56 | pamaury | previously it did not use commit_discard perhaps ? |
| 12:32:40 | wodz | it did previously (aka when HAVE_ATA_DMA) cpucache_invalidate() but since then names have changed |
| 12:33:46 | | Join redhot [0] (~kvirc@195.238.92.36) |
| 12:34:00 | wodz | but it should not compile cpucache_invalidate() at all then |
| 12:47:05 | | Quit Poodlemastah (Ping timeout: 245 seconds) |
| 12:48:50 | wodz | Ok, in ancient version cpucache_invalidate() was empty stub in bootloader build. I wonder how it was supposed to work with dma transfers. |
| 12:49:38 | | Part redhot ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") |
| 12:49:52 | | Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) |
| 12:49:52 | | Quit mt (Read error: Connection reset by peer) |
| 12:50:44 | | Quit petur (Quit: *plop*) |
| 12:51:04 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 12:51:36 | wodz | is it possible to define HAVE_ATA_DMA only for non bootloader builds? |
| 12:52:18 | | Quit mt (Read error: Connection reset by peer) |
| 12:53:27 | pamaury | wodz: Probably, depends on where it is defined |
| 12:53:32 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 12:53:56 | wodz | HAVE_ATA_DMA is defined in firmware/export/config/xxx.h files |
| 12:55:39 | wodz | yea it works but looks ugly |
| 12:57:01 | | Join mt_ [0] (~quassel@41.233.134.80) |
| 12:57:02 | | Quit mt (Read error: Connection reset by peer) |
| 12:57:05 | wodz | oh, we stub out some lcd functions this way so this is not new technique :-) |
| 12:58:00 | | Quit Poodlemastah (Read error: Connection reset by peer) |
| 12:58:00 | | Quit mt_ (Read error: Connection reset by peer) |
| 12:58:40 | | Join mt [0] (~quassel@41.233.134.80) |
| 12:58:41 | | Quit mt (Changing host) |
| 12:58:41 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 12:59:36 | pamaury | we already do that for many things |
| 13:00 |
| 13:00:19 | wodz | pamaury: sure in many places but not so much in config/xxx.h |
| 13:00:42 | pamaury | nearly all config files do it ! |
| 13:01:13 | kugel | wodz: sure it's possible |
| 13:01:23 | | Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) |
| 13:01:31 | kugel | just define it within #ifndef BOOTLOADER |
| 13:04:47 | | Quit Guest25974 (Ping timeout: 248 seconds) |
| 13:07:15 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 13:19:34 | | Quit Buglouse (Ping timeout: 255 seconds) |
| 13:31:50 | | Join jlbiasini [0] (~metaphysi@109.103.46.91) |
| 13:35:09 | | Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) |
| 13:39:10 | pamaury | jlbiasini: I don't understand your gerrit patch ?! |
| 13:39:56 | jlbiasini | nothing to understand it's abandonned |
| 13:40:18 | jlbiasini | You did experienced the same errors as I was yesteday didn't you ? |
| 13:40:40 | pamaury | no |
| 13:40:52 | jlbiasini | I reinstalled my tree and now I can't reproduce it anymore |
| 13:42:15 | jlbiasini | stange because I didn't had any thing unstaged. In fact I had this signal.h include so I didn't so there was already one, but kugel was suspecting perhaps the order ofthe include matters |
| 13:42:59 | jlbiasini | but after it worked once, it was always working even after reseting the file... mystery... |
| 13:44:14 | wodz | just like our 'lib/libtlsf.a: could not read symbols: Archive has no index; run ranlib to add one' random error :-) |
| 13:44:54 | wodz | I'd love to hit it locally and inspect intermediate files to understand whats going on |
| 13:47:16 | pamaury | is it always the same bot ? |
| 13:51:14 | wodz | no |
| 13:51:31 | pamaury | are we building with make -j ? |
| 13:51:55 | wodz | with -jn where n is num of cores AFAIK |
| 13:54:00 | pamaury | sometimes it can yield very strange results |
| 13:55:07 | Zagor | pamaury: -j can give strange results if you don't take care of your dependencies. we take rather good care of ours. |
| 13:55:21 | wodz | apparently not good enough |
| 13:55:58 | *** | Saving seen data "./dancer.seen" |
| 13:56:05 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 13:56:06 | pamaury | I can tell you for sure that even in Makefiles with perfect dependencies I've hit some weird errors, usually only happen once, of course |
| 13:56:23 | Zagor | wodz: that's entirely possible, of course. bugs happen. |
| 13:56:40 | Zagor | pamaury: you talk like -j is black magic. it's just parallell compilation. |
| 13:56:40 | pamaury | I'm not blaming make though, that could be a bug in the compilers |
| 13:56:44 | kugel | what makes you think it's a make -j error? just because it's strange? |
| 13:56:47 | pamaury | yes |
| 13:57:11 | pamaury | because you get it only with make -j and not with make ? |
| 13:57:36 | kugel | how do you know? |
| 13:58:39 | wodz | With limited number of builds on our farm this days we could switch to -j1 for a week or so and see if strange problems go away. |
| 13:59:22 | pamaury | Sight, I'm not saying "this is make's fault", I said (please read) 1) i'm not blaming make 2) i've got errors only with make -j 3) which I don't have with make |
| 13:59:22 | pamaury | That's all, conclude what ever you want |
| 13:59:57 | pamaury | Correlation is not implication, as one says |
| 14:00 |
| 14:00:19 | Zagor | libtlsf certainly look suspicious |
| 14:01:22 | wodz | Zagor: In which way? |
| 14:02:32 | Zagor | wodz: in that it's very often failing there. |
| 14:03:27 | wodz | actually this is the only static lib we produce which seems to trigger this error |
| 14:04:28 | wodz | could it be that codecs for example do not depend on libtlsf.a ? |
| 14:04:43 | Zagor | I'll take a peek |
| 14:05:00 | | Join amee2woof [0] (~thomas@ve504.cugnet.net) |
| 14:05:17 | wodz | in plugins IMO we explicitly compile tlsf.c file |
| 14:05:53 | wodz | :q |
| 14:07:23 | | Quit Buglouse (Ping timeout: 276 seconds) |
| 14:07:27 | wodz | ok, mikmod and pdbox do use libtlsf but do not compile a copy and I recall seeing failures there |
| 14:08:00 | | Quit __jae__ (Read error: Operation timed out) |
| 14:09:21 | | Join __jae__ [0] (~jae@dedicated.jaerhard.com) |
| 14:10:22 | | Join amayer_ [0] (~amayer@mail.weberadvertising.com) |
| 14:12:57 | Zagor | aac codec for instance does not specify dependency on libtlsf.a, so it is linked before libtlsf is completed |
| 14:13:29 | pamaury | ouch |
| 14:15:24 | wodz | maybe make libplugin.a depended on libflsf.a |
| 14:16:27 | Zagor | but only a few codecs use tlsf, right? |
| 14:16:35 | wodz | yes |
| 14:16:43 | wodz | I mean libcodec |
| 14:17:06 | Zagor | then adding it as a depencency for all would affect build performance. all codecs would have to wait for tlsf to complete before linking. |
| 14:17:32 | Zagor | we specify in codecs.make which codecs use which libs. it feels to me like tlsf should be specified there. |
| 14:17:44 | wodz | could be |
| 14:17:54 | Zagor | though I'm a bit confused because I don't even see tlsf specified there at all |
| 14:18:24 | wodz | It quite new move to have it compiled as separate lib |
| 14:18:52 | wodz | the dependency bit has been omitted apparently |
| 14:22:06 | Zagor | but where is it even linked? that's supposed to be handled in that file too |
| 14:23:39 | Zagor | ahh, libtlsf.make adds it to EXTRA_LIBS |
| 14:24:02 | wodz | hmm, so it should propagate down to all codecs |
| 14:25:26 | Zagor | I think that's a bad idea. all codecs should not be linked with tlsf |
| 14:25:49 | Zagor | those using it should list it in codecs.make |
| 14:26:27 | wodz | thats another matter, but if libtlsf.a is added to EXTRA_LIBS why it fails? |
| 14:27:11 | wodz | currently the very first codec should compile and link libtlsf.a |
| 14:27:27 | Zagor | you're thinking serially. don't. :-) |
| 14:27:34 | Zagor | they are all build at the same time |
| 14:27:42 | Zagor | (potentially) |
| 14:27:44 | | Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) |
| 14:28:05 | pamaury | that's nasty, it starts building the codec before having the dependency ?! |
| 14:28:50 | Zagor | pamaury: yes, since we haven't said the lib is a dependency |
| 14:28:52 | wodz | ah, you mean one codec started producing libtlsf.a but didn't write file completely while the second tried to link with this incomplete .a ? |
| 14:29:01 | Zagor | wodz: yes |
| 14:30:04 | wodz | I don't see how individual dependency could solve this |
| 14:31:10 | | Quit wodz (Quit: Leaving) |
| 14:43:44 | | Quit einhirn (Ping timeout: 245 seconds) |
| 14:53:38 | | Quit AlexP (Ping timeout: 248 seconds) |
| 14:55:43 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 14:55:45 | | Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) |
| 14:57:39 | | Quit jlbiasini (Ping timeout: 256 seconds) |
| 14:58:37 | | Join jlbiasini [0] (~metaphysi@109.103.46.91) |
| 15:00 |
| 15:00:42 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 15:08:01 | | Quit einhirn (Ping timeout: 255 seconds) |
| 15:19:50 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
| 15:19:50 | | Quit n1s (Changing host) |
| 15:19:50 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 15:33:48 | copper | Hmmm, the Clip Zip port is still marked "unstable" on the homepage |
| 15:35:00 | | Quit pamaury (Ping timeout: 245 seconds) |
| 15:36:32 | Zagor | as a matter of fact, *only* vorbis uses tlsf |
| 15:37:03 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 15:37:17 | | Quit AlexP (Remote host closed the connection) |
| 15:37:33 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 15:37:35 | Zagor | I can't remembed the purpose of EXTRA_LIBS. the name is too generic. |
| 15:38:51 | Zagor | and when I remove libtlsf from it, only libsetjmp remains |
| 15:39:18 | | Quit mortalis (Quit: Leaving) |
| 15:45:55 | | Quit Poodlemastah (Quit: ZNC - http://znc.in) |
| 15:51:22 | | Join eckoit [0] (~ryan@50.65.10.24) |
| 15:56:00 | *** | Saving seen data "./dancer.seen" |
| 15:56:43 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 16:00 |
| 16:07:37 | Zagor | that should fix the tlsf dependency problems |
| 16:07:49 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 16:09:47 | | Quit kevku (Ping timeout: 264 seconds) |
| 16:12:36 | Zagor | ...except it didn't. hmm. |
| 16:25:02 | | Part LinusN |
| 16:26:01 | | Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) |
| 16:26:13 | | Quit Poodlemastah (Client Quit) |
| 16:31:45 | | Quit jlbiasini (Quit: jlbiasini) |
| 16:48:48 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 17:00 |
| 17:07:07 | | Join PurlingNayuki [0] (~PurlingNa@121.35.227.58) |
| 17:08:34 | PurlingNayuki | There're still several major bugs with RaaA... but really works fine with me. |
| 17:12:01 | kugel | Zagor: some plugins too, no? |
| 17:12:30 | | Quit PurlingNayuki (Quit: Leaving.) |
| 17:12:41 | Zagor | kugel: yes, I fixed both codecs and plugins |
| 17:12:52 | Zagor | though the tlsf dependency issue remains. not sure why. |
| 17:13:38 | funman | copper: unstable means incomplete manual and maybe broken graphics for a couple of games in this case |
| 17:14:04 | copper | there was a lot of talk about promoting it to stable, I thought it was a done deal |
| 17:14:34 | funman | no idea sorry |
| 17:15:54 | gevaerts | copper: IIRC (but it's a bit vague) that this discussion was after 3.12, and promoting to stable at random times between releases has some awkward side effects |
| 17:16:12 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 17:16:43 | | Quit the-kyle (Remote host closed the connection) |
| 17:17:07 | | Join WalkGood [0] (~4@unaffiliated/walkgood) |
| 17:18:02 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 17:21:44 | | Join Ward [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) |
| 17:22:08 | | Nick Ward is now known as Guest54714 (~Mirandaha@176-120-190-109.dsl.ovh.fr) |
| 17:39:27 | | Quit Zagor (Quit: Clint excited) |
| 17:40:55 | | Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) |
| 17:42:18 | | Quit the-kyle (Remote host closed the connection) |
| 17:43:33 | | Quit bebna (Quit: Leaving.) |
| 17:43:55 | | Join dynion [0] (~52a896aa@www.haxx.se) |
| 17:44:16 | dynion | hey guys! think i might have found a bug... or it's just a human error...] |
| 17:44:52 | dynion | the video 5th gen goes into ipod after every reboot |
| 17:45:01 | dynion | instead of rockbox |
| 17:45:26 | | Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) |
| 17:46:05 | dynion | [saint] ? |
| 17:46:10 | Torne | you are probably leaving the hold switch on |
| 17:46:12 | Torne | read the manual |
| 17:46:47 | dynion | nope |
| 17:46:59 | dynion | even without hold it doesnt go into rockbox |
| 17:47:27 | Torne | or you are holding menu to turn it on, which also dualboots the original firmware |
| 17:47:44 | dynion | or is the rockboc installation gone after one time |
| 17:47:47 | dynion | ah... ok:) |
| 17:47:56 | Torne | press the select button one time to turn it on normally |
| 17:48:52 | dynion | well first i have to get it out completely |
| 17:48:56 | dynion | instead of the sleep mode |
| 17:49:27 | dynion | god this is a frustrating os... now i know why i hated apple |
| 17:50:09 | dynion | should i re-rockbox it before doing it again? cause i can't get it offline properly |
| 17:51:08 | Torne | the manual explains how dualbooting works |
| 17:51:17 | dynion | oh you didnt mean the apple manual |
| 17:51:19 | Torne | to ge tback out of the apple OS you have to hard reset |
| 17:51:27 | dynion | you guys made your own... awesome:D |
| 17:53:34 | | Join Bug2000 [0] (~bug2000@unaffiliated/bug2000) |
| 17:56:01 | *** | Saving seen data "./dancer.seen" |
| 17:57:21 | dynion | Thanks torne! |
| 17:57:29 | dynion | Human error it is:D |
| 17:58:08 | dynion | so from now on... if i want to start it just use the big round button:D sounds idiot-proof enough |
| 17:59:20 | | Quit dynion (Quit: CGI:IRC (EOF)) |
| 18:00 |
| 18:00:17 | | Join pretty_function [0] (~sigBART@123.252.212.119) |
| 18:00:45 | | Quit pretty_function (Client Quit) |
| 18:26:38 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 18:26:48 | | Quit preglow (Ping timeout: 240 seconds) |
| 18:27:34 | | Join preglow [0] (thomj@skrotnisse.pvv.ntnu.no) |
| 18:27:35 | | Quit preglow (Changing host) |
| 18:27:35 | | Join preglow [0] (thomj@rockbox/developer/preglow) |
| 18:27:40 | | Quit aevin_ (Ping timeout: 264 seconds) |
| 18:27:57 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 18:30:46 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 18:39:20 | | Join lorenzo92 [0] (~chatzilla@95.237.104.74) |
| 18:45:12 | | Join TheSphinX_ [0] (~briehl@p5B321E02.dip.t-dialin.net) |
| 18:46:26 | | Quit melmothX (Remote host closed the connection) |
| 18:46:55 | | Join melmothX [0] (~melmoth@unaffiliated/melmothx) |
| 18:47:33 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
| 18:48:42 | | Join TheSphinX^ [0] (~briehl@p579CC7C8.dip.t-dialin.net) |
| 18:49:02 | * | lorenzo92 implementing backlight controller for R1 in rb |
| 18:52:13 | | Quit TheSphinX_ (Ping timeout: 260 seconds) |
| 18:54:12 | | Join TheSphinX_ [0] (~briehl@p5B3229FD.dip.t-dialin.net) |
| 18:57:04 | | Quit Bug2000 (Read error: Connection reset by peer) |
| 18:57:19 | | Quit TheSphinX^ (Ping timeout: 248 seconds) |
| 18:58:13 | | Quit melmothX (Quit: #) |
| 18:59:43 | | Join TheSphinX^ [0] (~briehl@p579CC32C.dip.t-dialin.net) |
| 19:00 |
| 19:00:24 | | Quit TheSphinX_ (Read error: Operation timed out) |
| 19:06:00 | | Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) |
| 19:06:37 | | Quit pamaury (Ping timeout: 255 seconds) |
| 19:07:02 | | Quit lorenzo92 (Ping timeout: 276 seconds) |
| 19:07:59 | | Quit Rower (Quit: sover) |
| 19:08:09 | | Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) |
| 19:13:10 | | Part eckoit |
| 19:14:48 | | Join mt_ [0] (~quassel@41.233.134.80) |
| 19:14:48 | | Quit mt (Read error: Connection reset by peer) |
| 19:27:06 | [Saint] | [03:33:49] <copper> Hmmm, the Clip Zip port is still marked "unstable" on the homepage <−− you expect otherwise? |
| 19:27:28 | copper | <copper> there was a lot of talk about promoting it to stable, I thought it was a done deal |
| 19:27:51 | | Join xela [0] (~xela@i59F7927D.versanet.de) |
| 19:28:36 | xela | hey all. i managed to get a 240gb toshiba to work in a ipod video. problem now is replay "stutters" a couple of times when playing a song. |
| 19:30:09 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 19:32:15 | | Join lorenzo92 [0] (~chatzilla@95.237.104.74) |
| 19:32:17 | xela | does this ring a bell for somebody? |
| 19:34:02 | | Quit lorenzo92 (Client Quit) |
| 19:34:22 | | Join lorenzo92 [0] (~chatzilla@95.237.104.74) |
| 19:34:28 | | Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 19:35:49 | | Quit lebellium (Ping timeout: 245 seconds) |
| 19:36:15 | [Saint] | copper: "stable" has less to do with the stability of the port, and more to do with meeting a set of requirements: complete manual, all applicable plugins, rbutil support, etc. |
| 19:36:36 | copper | yeah I know, I thought those requirements were met |
| 19:36:40 | [Saint] | Apparently it's lacking in at least one of those areas, which doesn't entirely surprise me. |
| 19:36:44 | [Saint] | It's a very new port. |
| 19:37:57 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 19:38:03 | [Saint] | Changing the port classifications to something a little more obvious has been discussed quite a few times, but no one ever seems to come up with anything better than unusable, unstable, and stable. |
| 19:38:32 | [Saint] | but it is often amusing, and confusing, that unusable and unstable rarely actually mean that literally. |
| 19:38:34 | | Quit lebellium (Read error: Connection reset by peer) |
| 19:39:02 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 19:39:34 | | Quit lebellium_ (Ping timeout: 245 seconds) |
| 19:43:56 | | Quit lebellium (Read error: Network is unreachable) |
| 19:44:27 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 19:44:49 | | Quit zoktar (Quit: -) |
| 19:46:15 | | Quit akaWolf (Ping timeout: 245 seconds) |
| 19:53:17 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
| 19:53:58 | | Quit lebellium (Read error: Connection reset by peer) |
| 19:54:29 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 19:56:03 | *** | Saving seen data "./dancer.seen" |
| 19:57:36 | | Quit xela (Ping timeout: 256 seconds) |
| 20:00 |
| 20:01:46 | | Join xela [0] (~xela@i59F7927D.versanet.de) |
| 20:05:14 | n1s | xela: does it stutter only when rebuffering? |
| 20:09:08 | | Quit amayer_ (Quit: amayer_) |
| 20:11:44 | | Join amayer_ [0] (~amayer@mail.weberadvertising.com) |
| 20:12:09 | | Quit WalkGood (Ping timeout: 256 seconds) |
| 20:17:17 | | Join nomada [0] (~nomada@irc.consciente.de) |
| 20:18:02 | | Quit Strife89 (Quit: ------->) |
| 20:19:40 | xela | nls: when does rebuffering take place |
| 20:20:41 | | Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) |
| 20:21:19 | n1s | just before the buffer is empty or when skipping out of what's buffered, the disk will spin up then and if it takes too long for some reason that will cause a dropout. You can also see the buffer state in the "buffering thread" screen in the debug menu |
| 20:27:47 | | Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) |
| 20:29:50 | xela | nls hard to see it happen |
| 20:31:41 | [Saint] | It's quite easy to see it happen, actually. |
| 20:32:34 | [Saint] | System - Debug - View buffering thread |
| 20:32:39 | [Saint] | xela: ^ |
| 20:32:49 | [Saint] | You can see the buffer empty and fill in realtime. |
| 20:32:59 | [Saint] | (with playback, of course) |
| 20:33:07 | xela | i know but to start a replay and then do it in time |
| 20:33:36 | [Saint] | You don't need to, it will refill the buffer again fairly quickly. |
| 20:33:47 | [Saint] | It isn't as it it only happenes once. |
| 20:34:24 | n1s | and if you use lossy music it should take a half hour or more for it to empty if you playlist is long enough |
| 20:34:53 | [Saint] | s/lossy/really hideously lossy/ |
| 20:35:45 | n1s | it could be the 64MB model! |
| 20:37:12 | [Saint] | Oh...guess you're right, actually. A rough guess with my classic suggests it will take about ~30 mins to deplete the buffer with lame 320 |
| 20:37:29 | [Saint] | (64MB ~59MB available buffer) |
| 20:38:38 | [Saint] | Allowing playback control in the view buffering thread screen might be a good idea. |
| 20:38:53 | [Saint] | The you could actually cause a rebuffer and watch it happen. |
| 20:39:19 | [Saint] | afaik the keys (on at least a few targets) are free to allow play/pause and seeking. |
| 20:41:12 | n1s | i thought you could skip from that screen |
| 20:41:17 | | Join TheSphinX_ [0] (~briehl@p5B323AA1.dip.t-dialin.net) |
| 20:41:44 | xela | i will try |
| 20:42:09 | xela | it stutter doesnt happen when the playback continues from track to track |
| 20:42:15 | xela | only when i start the playback |
| 20:42:18 | xela | and not always |
| 20:43:56 | [Saint] | n1s: apparently not on the Classic? |
| 20:44:11 | [Saint] | Unless for <some_awesome_reason> the keys are no longer << and >> |
| 20:44:16 | xela | nls/Saint: skipping doesnt work there |
| 20:44:29 | [Saint] | I seem to recall it used to, as n1s said. |
| 20:44:32 | [Saint] | It likely broke. |
| 20:44:49 | | Quit TheSphinX^ (Ping timeout: 276 seconds) |
| 20:46:10 | n1s | i can do it on my c200 with the down/menu button but it has a rather old build |
| 20:46:16 | * | lorenzo92 backlight and charger detection working on R1! |
| 20:46:45 | xela | nls seems like i can skip with the wheel |
| 20:48:09 | n1s | xela: skip untill the number on the left of the slash after "usfl" drops to 0 and it should rebuffer |
| 20:49:53 | xela | tried it |
| 20:50:13 | xela | nls it takes a little while until playback starts because the disk spins up |
| 20:50:18 | xela | but it doesnt stutter |
| 20:50:24 | xela | so the effect is different |
| 20:50:46 | n1s | hmm, yeah a small dropout is expected when skipping like this |
| 20:52:49 | xela | and not every song stutters |
| 20:53:42 | n1s | xela: in the buffer thread screen, is pcm almost full most of the time? |
| 20:55:00 | xela | yes |
| 20:58:08 | xela | nls: yes |
| 20:58:37 | n1s | hmm, i'm out of ideas then |
| 20:59:12 | xela | i am not quite sure whether or not it happens only with vbr files |
| 20:59:55 | n1s | what codec? |
| 21:00 |
| 21:00:34 | n1s | xela: and is this with a very recent build? |
| 21:01:15 | xela | 3.12 |
| 21:01:29 | xela | (Buffer: 59.3MB) |
| 21:01:35 | | Quit dv_ (Read error: Connection reset by peer) |
| 21:02:41 | | Join dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at) |
| 21:03:27 | n1s | perhaps it's worth it to test with a current build, there were changes to enable ata dma for the ipod video among others today so that might help but it's just a wild guess |
| 21:03:51 | xela | nls: and to describe the stuttering: the playback starts for about 1-2 seconds, then a gap of maybe 0.5-1 second and then conitnues. sometimes up to three "stutters" |
| 21:04:36 | xela | nls: it used to work like a charm before i replaced the hd (but was an older build on the old hd). so my guess would have been a different timing/whatnot of the new hd |
| 21:05:37 | n1s | so only when starting playback? |
| 21:05:51 | xela | yes |
| 21:06:15 | [Saint] | Hum, yes...seems skipping int eh buffering thread view is broken. |
| 21:07:12 | lorenzo92 | kugel: pff we will need to find a clean way to select the right io pin to start the radio, I mean, R0 and R1 have the same chip but different RST pin ^^ |
| 21:07:13 | n1s | perhaps the new disk is slower and rockbox doesn't wait enough before starting but this would surprise me, might be worth trying current build still |
| 21:07:39 | xela | [Saint] I am able to skip using the wheel. but behaviour seems to be slightly different (since it doesnt stutter then) |
| 21:08:00 | xela | nls are there nightlies somewhere? |
| 21:08:31 | [Saint] | Ohhhhhhhhhhhhhhhh! |
| 21:08:47 | [Saint] | << and >> are irrlevant, and skipping is done with the scrollwheel... |
| 21:08:48 | n1s | xela: http://build.rockbox.org/ apparently we call the current builds dev builds now, they are the very latest rev |
| 21:08:54 | [Saint] | how, ...obvious. :-S |
| 21:09:12 | | Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) |
| 21:09:20 | n1s | [Saint]: yeah it's on various unexpected buttons on all targets it seems :) |
| 21:09:27 | pixelma | [Saint]: well, this menu is for people who know what they do... it even says "keep out" ;) |
| 21:10:02 | [Saint] | skipping tracks with the volume control seems /very/ non-obvious to me ;) |
| 21:10:17 | [Saint] | Especially considering the fact that the << and >> buttons are free. |
| 21:10:33 | xela | [Saint] << is used to leave the view |
| 21:10:44 | [Saint] | Apparently I'll be looking at key maps today, yay...my favourite thing. |
| 21:10:52 | n1s | [Saint]: you have git access, don't you? :P |
| 21:10:59 | [Saint] | xela: menu+select is more consistent, imo. |
| 21:11:10 | [Saint] | n1s: Not direct, no. |
| 21:11:39 | | Quit y4n (Quit: PÆNTS ØLF!) |
| 21:11:43 | pixelma | I've been told that it was put on non-obvios buttons in this menu on purpose (long time ago though) |
| 21:11:48 | [Saint] | Although this isn't a plugin, the keymap could be greatly improved by allowing full playback control and using menu+select to exit the screen. |
| 21:11:52 | n1s | ah, well left leaves the view on most targets it seems so perhaps that's why as this feature was probably added in later |
| 21:11:56 | pixelma | non-obvious too |
| 21:12:37 | [Saint] | I say treat it like a plugin on the devices we can. |
| 21:12:52 | [Saint] | all scrollwheel targets should be able to have full playback control in this screen. |
| 21:13:18 | n1s | i think there are even debug screens that can't be left at all on some targets :) |
| 21:13:28 | [Saint] | Heh. |
| 21:18:04 | xela | nls: checked with latest dev build stuttering still there |
| 21:20:46 | | Join eckoit [0] (~ryan@96.53.108.182) |
| 21:22:25 | xela | [Saint]: menu+select is ok, especiall if there is a hint in the view |
| 21:22:38 | [Saint] | There wouldn't be. |
| 21:22:51 | [Saint] | But you'll notice that many plugins on iPod exit this way. |
| 21:22:59 | [Saint] | its jsut that this screen isn't a plugin. |
| 21:23:11 | [Saint] | We can treat it as such, though. |
| 21:28:40 | xela | nls: i wonder how else i could debug/hunt down the stutter thing |
| 21:29:09 | xela | nls: is there something like an error log like if some ata stuff timed out of such? |
| 21:29:30 | Marex | Hi |
| 21:29:41 | Marex | anyone can help me with a STMP3780/MX233 junker ? |
| 21:30:03 | Marex | is it possible to dump the memory map of that device somehow ? pinmux and DRAM config would be probably emough |
| 21:30:28 | Marex | I want to give u-boot a stab on these, since we now have u-boot ported to mx233 as well |
| 21:31:44 | | Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) |
| 21:32:13 | wodz | Marex: what you mean by 'dump memory map of the device'? |
| 21:33:39 | Marex | I mean dump the registers of the DRAM controller and the PINMUX controller |
| 21:33:44 | Marex | sorry |
| 21:34:11 | wodz | you mean the values or what? |
| 21:34:14 | Marex | yep |
| 21:34:34 | lorenzo92 | Marex: ask pamaury ;) there is also the hwtool for that :) |
| 21:34:44 | Marex | now that's the nick Im looking for ;-) |
| 21:34:55 | Marex | pamaury_: poke ? |
| 21:34:58 | Marex | lorenzo92: thanks |
| 21:35:16 | wodz | anyway there is the thing called hwemul in utils/imxtools |
| 21:35:22 | lorenzo92 | Marex: you're welcome |
| 21:35:42 | pamaury_ | Marex: yes ? |
| 21:35:53 | | Nick pamaury_ is now known as pamaury (~quassel@rockbox/developer/pamaury) |
| 21:36:07 | Marex | pamaury: can I dump the DRAM controller and PINMUX controller register values somehow ? |
| 21:36:28 | Marex | pamaury: from the running firmware that is, I'd like to give u-boot a stab at this XFi3 device now that we have it ported to mx233 |
| 21:36:39 | Marex | it'd give me a portable hacking rig |
| 21:37:29 | pamaury | I don't quite understand for what you want to use u-boot but hey. You could write a plugin to dump all the values but I'm not sure of the use of it |
| 21:37:37 | Marex | pamaury: the thing is, we have our own HW init altogether, so I need to dump the values from the running firmware, to be able to process them and put them into our HW init code |
| 21:38:11 | Marex | pamaury: actually −− is the bootloader in that device locked with some key? Or is the CPU pristine (with no signing key) ? |
| 21:39:50 | | Join einhirn [0] (~Miranda@p4FC74D02.dip0.t-ipconnect.de) |
| 21:39:52 | pamaury | ok, so for the dram value: we keep the OF init code (original firmware) does the low-level init of dram and then we only change them to change the frequency (I took them from linux). For the pinmux, well, it's the same thing: the OF init does the init pinmux cfg and we change it. On the X-Fi3 the device is locked with key "0" |
| 21:39:53 | Marex | pamaury: the plan here is I want to turn this device into portable hacking rig to be able to test at least some Linux drivers if I have no EVK around ... |
| 21:40:14 | Marex | pamaury: ah ok .. key 0 is stock key, right ? |
| 21:40:25 | Marex | pamaury: I ordered also fuze+, that one is locked or not ? |
| 21:40:46 | pamaury | same thing, locked with key only containing zeroes |
| 21:40:51 | Marex | ah, super :) |
| 21:41:06 | | Join anxt [0] (~user@64.141.19.175) |
| 21:41:14 | | Join einhirn_ [0] (Miranda@bsod.vpn.tu-clausthal.de) |
| 21:41:15 | Marex | pamaury: ok, so is it possible somehow to dump the registers from the running firmware then ? |
| 21:41:30 | Marex | pamaury: I dont care if I have to reflash the device or whatever ;-) |
| 21:41:56 | pamaury | if you can run rockbox on it that's trivial yes |
| 21:42:21 | pamaury | there is a simpler way however |
| 21:42:23 | Marex | pamaury: I didnt manage to compile one from latest git with emdebian 4.7.2-4 toolchain |
| 21:42:34 | Marex | pamaury: oh, please educate me :) |
| 21:43:32 | pamaury | we use our own toolchain. I wrote a tool which allows one to poke at the registers remotely (from the PC). If you first run the OF init code and then that code, you can read the DRAM and PINMUX registers easily |
| 21:43:51 | Marex | pamaury: hm .. you mean the USB loader ? |
| 21:44:14 | pamaury | yes, you put the device in recovery mode send code by usb |
| 21:44:16 | Marex | funny thing −− I wrote one as well by reverse engineering the USB protocol between MFGtool and MX28 :/ |
| 21:44:31 | | Quit einhirn (Ping timeout: 256 seconds) |
| 21:44:33 | Marex | were I to know you had the same thing going, I'd just stick with yours :) |
| 21:44:51 | pamaury | I think the mx28 and mx233 use the same protocol |
| 21:45:02 | [Saint] | Nothing wrong with occasionally reinventing the wheel ;) |
| 21:45:03 | Marex | pamaury: I'm able to jumpstart mx233 chip as well, yep |
| 21:45:05 | | Part eckoit |
| 21:45:40 | Marex | pamaury: ok ... so I need the init code (.sb ? bootstream?), load it into the device via USB ? |
| 21:45:41 | pamaury | anyway, this piece of code is in our repository, in utils/imxtools/hwemul. It would be better if you manage to compile it yourself. Otherwise I can send you a built one |
| 21:45:52 | Marex | lemme try |
| 21:46:15 | pamaury | you might have to build the other directories under utils/imxtools/ before |
| 21:47:02 | Marex | ok, hwemul_tool ready |
| 21:47:37 | pamaury | you need to build the code in dev/, did you ? |
| 21:47:54 | pamaury | (utils/imxtools/hwemul/dev) |
| 21:48:19 | Marex | ah dang |
| 21:48:25 | Marex | /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: error: no memory region specified for loadable section `.note.gnu.build-id' |
| 21:48:48 | Marex | this is my LD generating −−build-id ... it's some new stuff in recent binutils |
| 21:49:02 | pamaury | hum, ok, you'll need to modify the linker script file to drop it, you know how do to this ? |
| 21:49:27 | pamaury | in your case that's hwemul.lds |
| 21:49:49 | Marex | yea ... I fought this before |
| 21:50:04 | Marex | is there any way to actually configure the cross toolchain prefix ? |
| 21:50:36 | Marex | I might just use tools/configure and use a different toolchain I have sitting around (might just be fastest) |
| 21:50:55 | pamaury | for the main binary of rockbox I think so, for this little tool no, you'll have to edit the Makefile: the first lines |
| 21:50:59 | Marex | I have this arm-linux-gnueabi- toolchain here which has linker that doesn't generate this junk |
| 21:51:13 | Marex | pamaury: ok then, hang on a bit |
| 21:51:53 | Marex | ../lib/hwemul.h:26:24: fatal error: hwemul_soc.h: No such file or directory |
| 21:51:58 | Marex | is this intended ? ;-) |
| 21:52:06 | Marex | I think you missed some file when commiting this stuff |
| 21:52:49 | pamaury | you need to generate a register map |
| 21:53:11 | pamaury | I'm in the process of changing this but hey, you'll have to do it, let me remember how do to this ^^ |
| 21:53:54 | pamaury | you need to compile the lib/ before |
| 21:54:06 | pamaury | and before this the imxtools/regtools/ ^^ |
| 21:54:56 | Marex | ok, compiled, hwemul_tool ready |
| 21:55:31 | pamaury | so you have successfully compiled hwemul_tool and the dev/ dir ? |
| 21:56:04 | *** | Saving seen data "./dancer.seen" |
| 21:57:16 | xela | nls, [Saint] thanks a lot so far, maybe more another time |
| 21:57:45 | Marex | yep |
| 21:58:03 | Marex | pamaury: yes |
| 21:58:08 | Marex | Real key: 467cc254f81be8e78d765a2e63339fc9 |
| 21:58:10 | Marex | is this right ? |
| 21:58:28 | Marex | ah ... it's AES'd 0x00 key |
| 21:58:30 | Marex | nevermind |
| 21:58:50 | pamaury | the real key is random ^^ If you want i'll explain you the firmware format...later :) |
| 21:58:58 | Marex | there's a document on that |
| 21:59:01 | pamaury | so first, we'll do a little test |
| 21:59:06 | | Quit xela (Quit: Verlassend) |
| 21:59:18 | Marex | http://elk.informatik.fh-augsburg.de/gnublin-cdrom/Datasheets/imx28/iMX28_SB_Description.pdf |
| 21:59:23 | pamaury | Marex: yeah, at the time I first wrote the tools there was none ^^ |
| 21:59:53 | pamaury | so, in dev/ you should have hwemul.sb, can you send it to the device in recovery mode ? |
| 21:59:54 | Marex | heh :) |
| 22:00 |
| 22:00:00 | Marex | pamaury: let's try |
| 22:00:04 | pamaury | our loader is imxtools/sbloader |
| 22:00:27 | pamaury | (sbloader 0 hwemul.sb) |
| 22:00:35 | anxt | hi, i just installed rockbox via the gui tool, I have some dir ##MUSIC## and ##PORT# is this same to rm -rf ? |
| 22:00:52 | pamaury | the device should appear as fee1:dead in lsusb in case of success |
| 22:02:06 | Marex | I have to hold vol-up, right ? |
| 22:02:20 | pamaury | on which device ? |
| 22:02:24 | Marex | xfi3 |
| 22:02:52 | pamaury | it's power |
| 22:03:21 | pamaury | a reliable way to trigger it: plug usb, hold power, reset the device |
| 22:05:36 | Marex | ok, loaded |
| 22:05:54 | pamaury | does it appaear as feel1:dead in lsusb ? |
| 22:05:58 | Marex | yep |
| 22:06:06 | pamaury | cool :) |
| 22:06:10 | pamaury | now run hwemul_tool |
| 22:06:43 | Marex | running |
| 22:06:51 | pamaury | now you have a kind of shell |
| 22:07:02 | pamaury | (type help) |
| 22:07:16 | pamaury | you can read by address (read 0x10) or by name if you load a soc description |
| 22:07:28 | Marex | oh, so read32 is what I want to do now |
| 22:07:30 | Marex | nice :) |
| 22:08:06 | Marex | the STMP3780 is about the same thing as MX23, right ? |
| 22:08:33 | pamaury | to do this do: |
| 22:08:35 | pamaury | soc imx233 |
| 22:08:35 | pamaury | read HW_PINCTRL_CTRL |
| 22:08:40 | pamaury | STMP3780=MX233, same chip |
| 22:09:14 | Marex | pamaury: I'm ok with memory addresses |
| 22:09:54 | pamaury | now I should warn you: the tool runs out of iram so currently the dram is not initialised |
| 22:09:58 | Marex | pamaury: is there not some kind of a difference between STMP3780 and MX233 ? I mean, the bootrom recovery code identifies as 066f:3780 on mx23 too, but I recall the bootrom on STMP3780 is older |
| 22:10:21 | Marex | pamaury: you mean SRAM ? ( stuff at 0x0 ) |
| 22:10:27 | pamaury | yes |
| 22:10:33 | pamaury | there are several versions of the bootrom mostly to fix bugs |
| 22:10:41 | Marex | pamaury: ok, how do I go about initing it with the original bootloader ? |
| 22:10:44 | Marex | pamaury: heh :) |
| 22:11:01 | pamaury | first download a firmware upgrade for the zen x-fi3 from creative |
| 22:11:19 | Marex | pamaury: FYI have you ever seen the bootrom sources ? |
| 22:11:41 | pamaury | no |
| 22:11:54 | pamaury | but i've disassembled it :) |
| 22:12:19 | Marex | disassembly might just have been way easier to read |
| 22:12:23 | pamaury | did you ? |
| 22:12:52 | Marex | pamaury: no |
| 22:13:11 | pamaury | it has a terrible architecture anyway, and has bugs |
| 22:13:29 | Marex | mx28 is good in that it's industrial design |
| 22:13:40 | Marex | and the bugs there were mostly ironed out by FSL guys |
| 22:13:55 | Marex | all right, firmware update downloaded |
| 22:14:09 | pamaury | you'll need to run cabextract on it |
| 22:14:10 | | Quit thomasjfox (Ping timeout: 245 seconds) |
| 22:14:28 | Marex | ah good, it's this |
| 22:14:50 | pamaury | you should get a file called firmware.sb it in, right ? |
| 22:14:56 | Marex | firmware.sb :) |
| 22:15:21 | Marex | so zenfwupdater is some sbloader with a pretty face ? |
| 22:15:34 | pamaury | now, run imxtools/sbtoelf -z firmware.sb -o ZENXFI3 |
| 22:15:38 | Marex | all right, I have firmware.sb |
| 22:15:38 | Marex | ok |
| 22:16:25 | Marex | ok, got it |
| 22:16:47 | pamaury | we have some zen* code but it's for older zens, this one is completely different. You should get files called ZENXFI3*. You want to keep the ZENXFI3.____.* ones, remove the others |
| 22:17:11 | Marex | ok, I have it in /tmp anyway |
| 22:17:27 | Marex | 14 megs of junk, nice |
| 22:17:33 | pamaury | you should copy them in hwemul/dev/ |
| 22:17:58 | Marex | ok ? |
| 22:18:00 | pamaury | let's assume you put them in hwemul/dev/tmp/ |
| 22:18:12 | pamaury | now edit hwemul.db (in hwemul/dev) |
| 22:18:42 | pamaury | in the sources section, add an entry for all the ZENXFI3.____. files except the last one (number 3 iirc) |
| 22:19:00 | pamaury | for example: boot0 = "tmp/ZENXFI3.____.0.elf"; |
| 22:19:43 | Marex | yep |
| 22:19:47 | Marex | #4 is the last one |
| 22:19:51 | Marex | done |
| 22:20:17 | Marex | now load them and jump them one after another ? |
| 22:20:33 | pamaury | call them |
| 22:20:48 | pamaury | not jump :) |
| 22:20:50 | Marex | ok |
| 22:20:51 | pamaury | so load boot0; call boot0; load boot1; call boot1; |
| 22:20:56 | Marex | yep |
| 22:21:01 | | Join sakax [0] (~sakax@d8D862D2D.access.telenet.be) |
| 22:21:40 | pamaury | and then you should be able to "make" again and get a brand new hwemul.sb file which init the dram |
| 22:22:08 | Marex | yea ... you should add hwemul.db into Makefile dep list |
| 22:22:25 | Marex | transfer error at send step 30 |
| 22:22:27 | pamaury | ah, I was unsure it was, i'll do it then ^^ |
| 22:22:32 | Marex | ;-) |
| 22:22:35 | pamaury | hum, try again ? |
| 22:23:02 | pamaury | then maybe I made an error, you should only load the first 3 ___.x.elf files instead of 4, |
| 22:23:09 | pamaury | let me check |
| 22:23:13 | amayer_ | [Saint]: if i hold menu on a classic while plugging into pc and the headphones output constant buzz and player freezes would that be related to g#379 |
| 22:23:43 | pamaury | yeah, only load the 0, 1 and 2, not the 3 |
| 22:23:54 | Marex | good |
| 22:23:54 | Marex | got it |
| 22:24:01 | amayer_ | bluebrother^: is fsbluebot down? |
| 22:24:29 | pamaury | Marex: and then run everything again: go into recovery mode, run sbloader, hwemul_tool and you're done ! |
| 22:24:59 | Marex | yep, done ... and RAM seems to be online |
| 22:25:06 | Marex | at least reading it doesn't crash the chip |
| 22:25:17 | Marex | readline support would be nice ;-) |
| 22:25:19 | pamaury | reading never crashes |
| 22:25:39 | Marex | pamaury: really ? if you read RAM which is dead, it'll jump into DABT handler |
| 22:25:41 | pamaury | yeah I know, that's really just a dev tool, I didn't put too much effort in it |
| 22:25:58 | Marex | no prob, I can relate to that at times |
| 22:26:01 | pamaury | Marex: my experience is that only a few memory ranges trigger an abort |
| 22:26:05 | pamaury | very strange |
| 22:26:17 | Marex | pamaury: we use that in U-Boot to detect the DRAM size at runtime ;-) |
| 22:26:36 | pamaury | hum, then the dram is part of this region :) |
| 22:26:56 | pamaury | are you a uboot dev or just hacking uboot ? |
| 22:27:28 | sakax | hello guys - how is the nano2g usb thingy going? :) |
| 22:29:06 | wodz | sakax: stalled |
| 22:29:55 | sakax | :( |
| 22:33:33 | wodz | so on arm forth plugin takes 92560 bytes in mem + stacks (~8k I think) |
| 22:38:55 | | Quit pamaury (Ping timeout: 256 seconds) |
| 22:39:29 | * | lorenzo92 nice 58v battery, seems I'm wrong with a variable type :D |
| 22:52:04 | lorenzo92 | where do I configure battery ADC reading precision? right now I have 5mV but R1 fuel gauge is more precise 1.25... |
| 22:52:30 | | Quit n1s (Quit: Ex-Chat) |
| 22:52:39 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 22:54:47 | pamaury | wodz: is that the size of the entire forth kernel ? |
| 22:55:45 | wodz | yes but this number is when compiled with -Os |
| 22:55:57 | wodz | -Os build on x86 doesn't run correctly |
| 22:58:05 | wodz | I also implemented just a few hooks to our pluginapi just to see if it is working |
| 22:59:35 | | Join [Saint_] [0] (~quassel@101.98.158.103) |
| 22:59:36 | wodz | 133352 is for arm with -O0 (-O0 works as simulator plugin) |
| 22:59:54 | wodz | tomorrow I'll test on actual target |
| 22:59:59 | | Nick [Saint_] is now known as Guest33140 (~quassel@101.98.158.103) |
| 23:00 |
| 23:00:25 | [Saint] | amayer_: I highly doubt it, but that patch is really quite aggressive...it would't surprise me if it caused any number of errors. |
| 23:00:30 | | Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130117041235]) |
| 23:01:35 | | Quit amayer_ (Quit: amayer_) |
| 23:02:23 | [Saint] | amayer_: you might want to try (if you haven't already) verifying it only happens with the patch applied, and if so, comment on the gerrit thread, and if so, filing a bug report. |
| 23:02:46 | [Saint] | errr...bum, I messed that up. |
| 23:03:38 | [Saint] | Check if it happens without the patch applied; if it does - file a bug report; if it doesn't - mention your findings in the gerrit thread for the task. |
| 23:04:00 | [Saint] | Aaaaaaaaaaaaannnnnnnd, he's gone. |
| 23:04:04 | [Saint] | Double bums. |
| 23:04:57 | [Saint] | Can someone please assist me with a simple pass/fail test regarding EQ presets? |
| 23:05:05 | [Saint] | Test procedure: |
| 23:05:30 | [Saint] | Verify EQ is enabled; apply an EQ preset, check if EQ is still enabled. |
| 23:05:39 | [Saint] | Expected result: |
| 23:05:44 | [Saint] | EQ remains enabled |
| 23:12:27 | wodz | g#388 |
| 23:15:49 | | Quit kevku (Ping timeout: 245 seconds) |
| 23:16:24 | [Saint] | wodz: nice :) |
| 23:16:46 | [Saint] | (unfortunately, bluebot is on holiday though? :)) |
| 23:19:33 | pamaury | someone on the fuze+ forums reported 29 hours of playback with eq and mp3 at 320Kbps, I didn't know that was *that* power consuming |
| 23:33:12 | | Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 23:34:41 | | Quit Strife89 (Quit: Heading home.) |
| 23:35:26 | | Join TheSphinX^ [0] (~briehl@p5B321E8C.dip.t-dialin.net) |
| 23:38:36 | | Quit TheSphinX_ (Ping timeout: 252 seconds) |
| 23:38:49 | | Quit wodz (Quit: Leaving) |
| 23:42:31 | kugel | pamaury: with rockbox? |
| 23:42:36 | kugel | is 29h good or bad? |
| 23:43:03 | pamaury | better than the OF (~20h) and worse than mine with basic mp3 (~39h) |
| 23:43:17 | pamaury | (~35 sorry) |
| 23:43:32 | pamaury | yes with rockbox |
| 23:44:56 | | Join Tim_Elliott [0] (~Tim@68.179.137.177) |
| 23:45:58 | | Quit Tim_Elliott (Client Quit) |
| 23:46:19 | kugel | the OF is really this bad? |
| 23:46:28 | pamaury | yeah |
| 23:47:06 | | Quit SuperBrainAK (Ping timeout: 256 seconds) |
| 23:48:30 | | Join TheSphin- [0] (~briehl@p5B322E7D.dip.t-dialin.net) |
| 23:51:07 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
| 23:56:07 | *** | Saving seen data "./dancer.seen" |
| 23:57:52 | | Quit prof_wolfff (Ping timeout: 256 seconds) |
| 23:58:27 | kugel | nice |
icon identifies that the person is a core developer (has commit access).