--- Log for 09.03.110 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 21 hours ago 00.02.42 # i think rbutil fails on 10.4 ppc because of the mac tts acting up somehow. and the 10.4 intel rbspeex just uses the wrong sdk. that leaves us with noise with rbspeex on 10.4 ppc and intel 00.06.43 # just to clarify - the TTS itself works fine there. So it can "only" be the integration in RbUtil (or another sdk issue). I'd love to test a different TTS but I'd need to find a binary that works on 10.4 PPC and gave up searching earlier (haven't tried too long though). If someone has a link I'd be thankful, I really don't want to compile anything on those Macs 00.08.41 # an espeak binary or similar that is 00.09.35 # could a themesite admin delete my basicblueart and basicblackart the original author has his versions up aswell and it seems a bit silly having both up. and as he is the original author his should stay. 00.09.38 # bluebrother mentioned that the tts interface is somehow different in 10.4 so i think its that what causes the rbutil hangs on 10.4 ppc. 00.11.46 Quit CaptainKewllllll (Quit: Page closed) 00.12.46 # Stephen__: which targe/lcdsize have these themes ? 00.13.03 # e200 thanks domonoky 00.13.09 # 176x220 00.16.24 Quit MaadMan (Ping timeout: 245 seconds) 00.17.01 # New commit by 03kugel (r25078): Fix a bunch of boot.lds files so that they build with newer ld. The stack/bss sections need NOLOAD. otherwise the linker would try to include those ... 00.17.05 # New commit by 03kugel (r25079): Use ldr instead of adr, so that it compiles with a newer ld, although setting lr at that point hardly matters anyway. 00.17.37 Quit stripwax (Quit: http://miranda-im.org) 00.18.57 Quit ender` (Quit: Why do people give each other flowers? To celebrate various important occasions, they're killing living creatures? Why restrict it to plants? "Sweetheart, let's make up. Have this deceased squirrel.") 00.23.28 Join fml [0] (~53ecea55@giant.haxx.se) 00.23.53 # pixelma: hello. Could you please test FS#11088 ? I can't build at the moment. 00.27.39 Quit karashata (Quit: The fluffy dragon has left completely!) 00.28.09 # Stephen__: sorry, admin interface is somehow acting up, will do that tomorrow or so. please ping me if i forget it :-) 00.28.38 # will do there's no rush anyway domonoky thanks again 00.28.41 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.1) 00.29.12 # * TheSeven spotted an FTL bug! 00.29.24 # w00t! 00.29.32 # now *that*'s was caused nandfsck to be that slow 00.29.38 # an FTL bug, or *the* FTL bug? 00.30.05 # nothing critical, just causing a lot of overhead during recovery 00.30.40 # but it's the bug i have been wondering about where it could be coming from since several days, which i just spotted by accident 00.32.27 # ...or anybody who is able to build the manual: please try FS#11088 00.32.47 # New commit by 03kugel (r25080): Fix red. 00.34.49 Quit fml (Quit: CGI:IRC) 00.36.34 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 00.37.47 Quit domonoky (Read error: Connection reset by peer) 00.39.47 Quit Zarggg (Ping timeout: 268 seconds) 00.40.58 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 00.42.33 Join yelped [0] (~ad44f423@giant.haxx.se) 00.43.13 # New commit by 03kugel (r25081): Make mini2440 compile again. 00.43.24 # Anyone wants to check this out, please? http://forums.rockbox.org/index.php?topic=22573.0 00.44.20 Quit yelped (Client Quit) 00.46.28 # what the hells the point in that? come in and say "can you look at this" (and several people have replied to his thread anyway), and then leave before anyone can answer? 00.46.36 # pffffffft! 00.46.47 Quit jgarvey (Quit: Leaving) 00.46.56 Quit flydutch (Quit: /* empty */) 00.54.22 # the answer would have been that nagging won't really help 00.56.56 # New commit by 03kugel (r25082): Fix two warnings that appear with gcc4.4.3. The one in recording.c ("compact_view is used uninitialized" seems to be false positive unfortunately). 00.58.34 *** Saving seen data "./dancer.seen" 00.59.35 Join CaptainKewllllll [0] (~quassel@207.237.107.203) 01.00.02 Quit CaptainKewllllll (Remote host closed the connection) 01.01.33 # re: r25082 : does gcc warn about dead code by default ? 01.02.03 # kugel: when trying the same diff than you, gcc wouldn't give a warning, so it might ignore dead return statements 01.03.04 # funman: I think it doesn't see that it's dead code 01.04.07 # exit is a macro which expands to a differently called function. maybe the new gcc doesn't get trapped by the pure "exit" anymore. or it's more stupid if you like 01.05.38 # I think 4.4.x has a new feature, __attribute__((never_reached)), maybe they gave up some detection in favor of letting devs decide themselve 01.06.20 # oh, that was 4.5 01.06.47 # and it was __builtin_unreachable() 01.07.04 # kugel: when disassembling the function (for arm), the return was removed (so gcc saw it was dead code) 01.07.37 # interesting 01.07.40 # iiuc, longjmp() was marked as noreturn, perhaps based only on the function name 01.07.51 # then I guess the warning sensitivity has changed 01.08.17 # I think it's good if it warns and still optimises it away 01.09.25 # ah, longjmp (in setjmp_arm.S) doesn't use bx lr but rather the opcode for it, so perhaps gas sees it as no return 01.11.00 # do you think gas removes the return? 01.11.19 # did you check gcc -S as well? 01.11.33 # no i didn't 01.11.49 # do we support armv4 non -T CPUs ? 01.12.07 # no 01.12.12 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 01.12.32 # well, there's no target. I assume we would support them as we don't do thumb anyway :9 01.12.36 # then setjmp_arm.S could perhaps be changed (and an extra warning introduced?) 01.12.36 # i think pre -T CPUs were well before mp3 players 01.12.55 # funman: that file is imported, we rather avoid to change imported code 01.13.36 # kugel: only if it harms syncing. one-liner doesn't, and I doubt we would need to sync it in the future considering the small size 01.13.53 # what would you like to change? 01.14.28 # RET => bx lr 01.14.39 # it would save 8 bytes of binsize ! 01.14.40 Quit planetbeing (Remote host closed the connection) 01.14.45 Nick planetbeing__ is now known as planetbeing (~planetbei@32.154.30.76) 01.14.53 Join planetbeing_ [0] (~planetbei@198.107.160.46) 01.17.56 Quit liar (Quit: Verlassend) 01.17.57 Join n1s [0] (~n1s@rockbox/developer/n1s) 01.21.29 # hm os_exit is noreturn, but not longjmp 01.22.26 # New commit by 03funman (r25083): Use bx lr unconditionally in setjmp_arm.S ... 01.22.54 # awesome #ifdef :D 01.23.21 # self descriptive ^^ 01.24.55 # (this change didn't add a warning with gcc 4.4.2, although configure warned me about not using 4.4.3) 01.25.16 # + using arm-elf-eabi-gcc 01.25.50 Quit DerPapst (Quit: Leaving.) 01.27.05 Part toffe82 01.28.55 # the rating of the build system is strange 01.29.29 # previous round I had an avg of 130, and a round speed of 170. this round I start with an avg of 31 01.29.44 # and get round speed of 312 because I only get bootloader :\ 01.32.06 Quit karashata (Quit: The fluffy dragon has left completely!) 01.42.13 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 01.43.38 Quit funman (Quit: free(random());) 01.51.34 Quit guymann (Quit: update time!) 01.57.20 Join Strife89 [0] (~michael@adsl-154-2-188.mcn.bellsouth.net) 01.59.37 Quit iq (Remote host closed the connection) 02.02.56 Quit Strife89 (Ping timeout: 248 seconds) 02.04.58 Join Strife89 [0] (~michael@adsl-154-2-188.mcn.bellsouth.net) 02.10.09 Join CaptainKewl [0] (~jason@207.237.107.203) 02.13.33 Quit Stephen__ (Quit: Leaving) 02.17.19 Join noob1 [0] (~ad15ebf0@giant.haxx.se) 02.18.44 Quit noob1 (Client Quit) 02.18.52 Join noob1 [0] (~ad15ebf0@giant.haxx.se) 02.19.20 # pixelma: still awake? 02.19.44 Join planetbeing__ [0] (~planetbei@198.107.160.46) 02.20.16 Quit froggyman (Ping timeout: 265 seconds) 02.21.50 Quit planetbeing_ (Ping timeout: 276 seconds) 02.22.05 Join Noob123456 [0] (~ad15ebf0@giant.haxx.se) 02.23.54 Quit noob1 (Quit: CGI:IRC (Ping timeout)) 02.24.58 Join webguest113 [0] (~ad15ebf0@giant.haxx.se) 02.26.04 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 02.27.04 Quit Noob123456 (Quit: CGI:IRC (Ping timeout)) 02.29.38 # n1s: seen my mail? You could save me a lot of logs downloading and grepping :) 02.29.56 Quit webguest113 (Quit: CGI:IRC (Ping timeout)) 02.33.35 # kugel: no, i hadn't, writing reply 02.34.14 Join noob1 [0] (~ad15ebf0@giant.haxx.se) 02.37.55 Join yelped [0] (~ad44f423@giant.haxx.se) 02.38.24 # Sorry for leaving before so suddenly, had to go. 02.39.50 # Question for anyone that knows: WPS function: Next/Prev on Ipod 5th Gen is supposed to go to next track and pervious track according to the manual, but mine just fast tracks and doesn't go to next song. How to I fix that. 02.40.14 Quit MethoS- (Remote host closed the connection) 02.41.10 # noob1: are you just pressing them a short while or holding them in? 02.41.12 Quit Sajber^ (Read error: Connection reset by peer) 02.41.28 # short 02.41.35 # I understand holding it long should fast track 02.41.49 # but pressing it quickly does nothing except fast track 1 second. 02.42.13 # noob1: then you probably have the "track lock" (or w/e) it's called enabled 02.44.42 # n1s: why are the test_codec results you posted so odd? 02.44.51 # does test_codec not work correctly on the beast? 02.45.14 # saratoga: ? (they are decoding times) 02.45.26 # oh not MHz? 02.45.34 # yep, seconds 02.45.41 # ok 02.45.50 # maybe should have mentioned that... 02.45.52 # do you have the raw logs for svn anywhere? 02.45.56 # i'll put them on the wiki 02.46.06 # no, Unhelpful made the pdf 02.46.30 # and all my logs are on my desktop on the other side of the world unfortunately 02.46.41 # ok i'll bug him to post the logs or else update teh wiki himself (its easy now that we have a perl script to generate the wiki tables) 02.47.02 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 02.47.18 # i don't know how usefull it is to post these results now since most codecs have changed since then (and yeah the script is nice) 02.47.30 Quit yelped (Quit: CGI:IRC (Ping timeout)) 02.50.29 Join planetbeing_ [0] (~planetbei@32.154.30.76) 02.50.53 # n1s: it'll be a nice before and after for the mdct lib 02.51.02 Quit planetbeing_ (Remote host closed the connection) 02.51.17 # ah, yes 02.51.33 # n1s: thanks 02.51.40 # how did the speed change over the old mdct on cf btw? 02.51.47 # Found the option, "Prevent Skip playing" 02.51.49 Quit komputes (Ping timeout: 245 seconds) 02.51.54 Join planetbeing_ [0] (~planetbei@32.154.30.76) 02.52.17 # n1s: it got marginally faster 02.52.30 # but thats mostly because we have no ASM at all for CF, not even for simple stuff like butterflies 02.52.30 Quit noob1 (Quit: CGI:IRC (EOF)) 02.52.56 # ah, nice, there are a few places that stand out as good asm candidates :) 02.53.16 # yeah everywhere theres arm asm :) 02.53.30 # but FFT8 is a pretty obvious place, FFT16 woudln't hurt either 02.53.45 # mainly gcc basically doesn't use movem so it does a lot of move.l stores which can stall etc 02.53.46 # the transform macros using EMAC would help a lot 02.53.54 Quit planetbeing__ (Ping timeout: 245 seconds) 02.54.09 # i think i'll look at it when i get home 02.54.20 # could probably shave 5-10MHz off Vorbis/WMA/AAC/ATRAC/Cook/AC3 02.54.34 # *that* would be amazing 02.56.04 Quit planetbeing_ (Client Quit) 02.56.50 # thats basically what we've done for arm over the last 2 years of playing with the MDCT :) 02.58.38 *** Saving seen data "./dancer.seen" 02.59.36 # * chrisb enjoying rockbox on sansa e200 now 02.59.59 # "Unhelpful -O, but on my e200 flac was faster with -O2 than svn with -O2" 03.01.07 Quit karashata (Quit: The fluffy dragon has left completely!) 03.01.20 # n1s: how do you enable -O2 in the code? 03.02.45 # kugel: edit the makefile for the codec 03.03.41 # you can get an example from tremor for example 03.04.01 # you have to regex the make strings usually, but theres examples in various codecs like tremor 03.04.10 # libtremor.make 03.05.09 # will try. thanks 03.05.18 Join BiptoN [0] (~4cad70c0@giant.haxx.se) 03.05.24 # * kugel now has a script to download the logs properly 03.06.56 # if flac is faster with -O2 and the new compiler, there's no real reason to stick to 4.0.3, is there? 03.10.18 Quit BiptoN (Quit: CGI:IRC (Ping timeout)) 03.10.33 # if the codecs are faster overall and everything still works i don't think so 03.11.24 Join iq [0] (~iq@unaffiliated/iq) 03.14.37 Join planetbeing_ [0] (~planetbei@32.154.30.76) 03.15.19 # wow, 704% rt, instad of 593% 03.17.20 # flac_8 improved by 100 percentage points as well 03.20.00 # nice 03.20.40 # stripwax: I took a shot at converting svn tremor over to our mdct, it compiles but the output is wrong, not sure why yet 03.20.42 # http://duke.edu/~mgg6/rockbox/tremor_ffmpeg_imdct.patch 03.20.46 # if you want to take a look 03.25.26 # i have to get back to work so I can't debug it anymore right now 03.27.51 # flac svn is also improved by -O2 but not as much 03.31.14 # kugel: which target? 03.31.29 # e200v1 03.31.40 # I can only test flac on PP, so.. 03.36.17 # kugel: maybe its worth commiting the change then? 03.37.14 # I haven't verified the output, or coldfire 03.38.05 # iirc 02 made no or little difference on coldfire with gcc 3.4 03.38.33 # probably it was slightly slower or i would have committed the change already ;) 03.38.44 # but testing is of course nice 03.39.08 # tremor does -O3 on cf and -O2 on the rest, so it can be arch dependant in the .make 03.39.16 Quit Adnyxo (Quit: Leaving) 03.39.17 # yes 03.39.29 # yeah i wouldn't touch CF its been picked clean already 03.39.31 Join Connor [0] (~Connor@ip72-204-35-60.fv.ks.cox.net) 03.39.33 # Hello, I have a question about rockbox on my 5.5G 80 gig iPod Video. Whenever I pick a song from my database, the iPod pops up a "searching for files" box, and it scrolls from 2700 to 0, and then plays the song. I have the database loaded to ram and dircache enabled. Any way to fix th 03.41.21 # saratoga, kugel a nice way to find the optimal O level is to do what Unhelpful did when he made those benchmarks: remove all the individual codec O flags and set it in the codecs.make and then do 3 test runs over the test set, at O1, O2 and O3 and just compare logs 03.41.36 # n1s you ever hear of this bug? 03.41.43 # Or, what I believe to be a bug? 03.41.56 # nope, never used database 03.42.04 # n1s what mp3 player are you using? 03.42.08 # maybe try searching the forums 03.42.12 # It didn't help much. 03.42.14 # i doubt many people up at this hour have used the database 03.42.20 # i have a h300, c200v1 and gigabeast 03.42.39 # saratoga what do you recommend doing? 03.42.47 # Aside from not using the database. 03.43.07 # either searching or asking during the day on IRC 03.43.07 # well if only a test_codec run would last an hour or so :( 03.43.09 # JdGordon: Around? 03.43.18 # Connor: so what problem does this cause? 03.43.33 # kugel: that's why the beast is nice :) 03.43.39 # n1s a 10-20 second delay in a song starting to play. 03.43.49 # ah, it takes that long 03.43.53 # Yeah 03.44.11 # n1s: you can hardly compare its performance to the PPs one can you ? 03.44.14 # I'll try it not saved to ram. 03.44.52 # Connor: how big is the list you're selecting 03.45.01 # kugel 2700 songs. 03.45.02 # kugel: no, you probably can't but a full test_codec run takes much less than an hour 03.45.11 # it enqueues all songs in the current list, so it may take a while to fetch all and put them into a playlist 03.45.27 Quit JdGordon (Ping timeout: 260 seconds) 03.45.56 # Hmm. How do I keep the songs from being put into a playlist? 03.46.02 # Or is this required? 03.46.02 # oh so you're creating a 2700 song playlist 03.46.09 # I guess? 03.46.11 # ah, yes it's basically a limitation in the design of the database/playlist stuff 03.46.31 # I just want to play my music without a 20 second delay of picking a song from the list of songs to the time the music actually starts. 03.46.31 # Connor: browse something which gets you a smaller list 03.46.39 # :/ 03.46.46 # Connor: make you database searches return fewer results or i suppose long press the son and insert it 03.46.54 # s/son/song/ 03.46.58 # So there's nothing I can do? 03.47.16 # Connor: Connor: make you database searches return fewer results or i suppose long press the son and insert it 03.47.29 # don't choose 2700 song lists. I'm sure the database has enough filters which lead to smaller lists 03.47.55 # Well I usually have music on shuffle. 03.48.12 # is that 2700 all of your songs? 03.48.31 # Yes. 03.48.42 # I'm not sure why you need the database then 03.48.53 # couldn't you just make a single playlist with all your songs and shuffle that? 03.49.05 # instead of endlessly regenerating a new one from the database 03.49.13 # you could simply go to resume playback after boot without even entering the database. or, once you play all those songs save the playlist on disk 03.49.30 # Hmm, how would I play my music without the database then? 03.49.58 # play the playlist 03.50.19 # I am confused. 03.50.34 Join BiptoN [0] (~4cad70c0@giant.haxx.se) 03.50.46 # i think the problem is that you're trying to create a gigantic playlist everytime you use the database, which your slow cpu can't handle well 03.51.01 # so i'm saying just save the playlist to disk and play it instead of trying to regenerate it everytime 03.51.05 # saratoga I think that is the problem. 03.51.10 # And how would I go about saving the playlist? 03.51.30 # i don't know the buttons on your player, but its in the manual 03.51.44 # or of course you could always do it on your PC from iTunes or whatever 03.52.17 # Connor: in the main menu->playlists->save current playlist 03.52.24 # Thank you. 03.52.32 # hm, what is the charging time estimate based on? 03.52.39 # And all I have to do is select a song, have it build the playlist, and then save it? 03.52.41 # is it assuming a linear charging curve? 03.53.05 # Connor: that should work yes 03.53.11 # Thank you 03.54.32 # and is battery_level_dangerous just a warning level, or causing a shutdown? 03.54.45 # TheSeven: i think it's done the same way as discharging but with a different curve 03.55.05 # TheSeven: I think it shuts down at that level 03.55.16 # but I'm not sure 03.55.19 # the existence of battery_level_shutoff proposes the earlier, but my ipod did shut off at "dangerous" during the bench 03.55.43 # n1s: the difference is that while discharging has a more-or-less constant current, the charging on li-ion is highly non-linear 03.56.16 # on most targets we have no access to current, so I assume its all based on voltage 03.56.29 # there is a voltage to percentage mapping for charging, but no mapping to charging time 03.56.32 # I think the battery estimation is based on the current voltage and the CURRENT_* defines from the config file 03.56.47 # are there current_* things for charging? 03.57.11 # I think there is one 03.57.31 # reading the current won't help either, what we really need is a mapping from percentage to remaining charging time 03.57.42 # maybe not 03.57.53 # (and no, a constant doesn't suit that purpose at all) 03.58.34 # * TheSeven wonders where that charging time estimation code is 03.59.02 # TheSeven: it is done the same way for both charging and discharging but with different curves mapping percent to voltages 03.59.51 # n1s: the voltage to percent part is clean, i'm just saying that we would also need a percentage to charge completion time mapping 04.00.11 # need for what? 04.00.22 # to predict the charging time 04.00.37 # ah, yes 04.00.49 # (and the "voltage while charging" mapping is somewhat superfluous if we have a battery that's calibrated well) 04.01.43 # i think that the time estimation is now just done by reading the voltage at an interval, and then extrapolating from percent charged over a window 04.02.05 # which doesn't make any sense either for li-ion 04.02.44 Quit Strife89 (Quit: Bed.) 04.03.43 # powermgmt_est_runningtime_min = (100 - level)*battery_capacity*60 / 100 / (CURRENT_MAX_CHG - runcurrent()); 04.03.45 # aha. 04.03.58 # it's most likely a thing from the archos days 04.03.58 # that doesn't make any sense at all 04.05.02 # it's assuming a 100% efficiency of the battery, a constant input current until it is 100% charged, and that the power consumption of the player will be deducted from that, which ist just *all wrong* for nano2g 04.05.50 # on nn2g (if we allow it to draw 500mA) it will do a CC chage at 120mA until the voltage hits 4.32V and then do a CV charge at that level from that point on 04.06.22 # yeah, i was wrong, i though power_history list was used by apparently that is only used by the debug menu and the archos charging code 04.06.45 # if we limit it to 100mA, the archos or whatever scheme will fit better, as during the CC phase, the input current will be limited to 100mA, so the battery current will be 100mA minus the player's current consumption 04.06.55 # TheSeven: yeah, most li-ion chargers should be the same 04.07.21 # the funny thing is that there doesn't seem to be a charge completion event 04.07.35 # it will keep the battery floating at 4.32V until you remove USB power 04.07.57 # but then, if you re-plug it, it won't start charging unless it's below some limit (in the range of 4.2V somewhere) 04.10.01 # taht's a bit weird 04.10.43 # and i haven't yet foudn a GPIO that indicates whether it's actually charging, which is a bit nasty 04.17.30 # are links supported? MUSIC/Beethoven/Symphony5.ogg MUSIC/VonKarajan/Symphony5.ogg can these be links? 04.17.54 # The OF must know its charged somehow....as it displays a fullscreen battery cell to indicate charging is finished. 04.17.57 # hard or soft links? 04.18.02 # neither 04.18.05 Quit planetbeing_ (Quit: planetbeing_) 04.18.19 # *Nano2g that is. 04.18.34 # saratoga: how do people handle this case? 04.18.48 # i don't know what that case is 04.19.24 # one song, with two or more "parent" artists 04.20.11 # jam the info into id3 ? 04.20.18 # New commit by 03nls (r25084): Simplify makefile 04.23.07 # New commit by 03nls (r25085): Statically init array to 0 instead of runtime memset 04.25.20 # does anyone know if the idea to port to Arhos 5 IMT has been discussed? 04.26.48 # kugel: last i checked i still can't use mpegplayer with my eabi build, unsure if it's an eabi or 4.4 issue 04.27.04 # BiptoN: I don't think so 04.28.29 # n1s: heh, I wasn't sure whether I don't understand the .make files enough or if that was really messed up :) 04.28.50 # Unhelpful: hrm, I haven't checked actually 04.29.44 # yeah that makefile had 2 rules for making the same objects, i guess make selected the last one (which was correct) 04.33.27 Join CGL [0] (~CGL@190.207.198.83) 04.37.22 Quit BiptoN (Quit: CGI:IRC (EOF)) 04.40.54 Quit TheSeven (Disconnected by services) 04.41.09 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.41.19 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.42.36 Join planetbeing_ [0] (~planetbei@32.153.134.172) 04.45.11 # Unhelpful: shit, indeed 04.45.22 # data abort. the disassembly looks fine though 04.45.56 Quit planetbeing (Ping timeout: 240 seconds) 04.45.59 Nick planetbeing_ is now known as planetbeing (~planetbei@32.153.134.172) 04.46.27 # have you further looked at it? 04.48.23 Quit kugel (Remote host closed the connection) 04.53.11 Join Barahir [0] (~jonathan@gssn-5f756b67.pool.mediaWays.net) 04.56.41 Quit Barahir_ (Ping timeout: 256 seconds) 04.58.37 Quit panni_ (Read error: Connection reset by peer) 04.58.39 *** Saving seen data "./dancer.seen" 04.59.55 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 05.02.52 # Unhelpful: you should put your test codec results for the beast on the wiki 05.02.58 # we have no scores at all for it on the page 05.03.27 # if you have old pre-MDCT logs, even better, we could do before and after 05.04.16 Quit mt (Ping timeout: 240 seconds) 05.05.57 # kugel: (for the logs) the bootloader you sent me worked on the e200 05.08.58 Join mt [0] (~mtee@rockbox/developer/mt) 05.16.18 # kugel: crashed? :D 05.20.09 # should probably check doom also, it and mpegplayer both had warnings related to short enums 05.23.00 Join demi` [0] (WarMinion@187.36.78.223) 05.25.17 Part demi` 05.27.13 # also might be a struct thing, if we have yuv->rgb asm that expects a struct rgb something like { u8 r; u8 g; u8 b;} then it's probably only 75% of its expected size 05.32.31 Quit Horscht (Quit: Verlassend) 05.32.54 Quit n1s (Quit: Lmnar) 05.45.08 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 05.51.36 Join n1s [0] (~n1s@rockbox/developer/n1s) 05.58.43 Join Rob2223 [0] (~Miranda@p4FDCB2E3.dip.t-dialin.net) 06.02.36 Quit Rob2222 (Ping timeout: 265 seconds) 06.12.22 # New commit by 03theseven (r25086): Nano2G battery calibration 06.23.50 Quit anewuser () 06.30.41 Join FOAD_ [0] (~dok@dinah.blub.net) 06.34.00 Quit FOAD (Ping timeout: 264 seconds) 06.34.00 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 06.41.44 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 06.43.29 Quit planetbeing_ (Ping timeout: 248 seconds) 06.58.41 *** Saving seen data "./dancer.seen" 07.08.21 Join Codefest_ [0] (~dce36163@gateway/web/freenode/x-nnmiloyogbqgiito) 07.09.17 Quit Codefest_ (Quit: Page closed) 07.14.59 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 07.37.10 Join Codefest [0] (~dce36163@gateway/web/freenode/x-dknjfupnxbguftxh) 07.37.14 # We invite you to be a part of the Largest Online Coding festival in the Indian Subcontinent.[ http://itbhu.ac.in/codefest ] Sit right in front of your systems and take part in challenging and mind boggling competitions on application development, algorithm design etc. PS:Attractive Prizes.Adobe & BT certificates. 07.37.42 # We invite you to be a part of the Largest Online Coding festival in the Indian Subcontinent.[ http://itbhu.ac.in/codefest ] Sit right in front of your systems and take part in challenging and mind boggling competitions on application development, algorithm design etc. PS:Attractive Prizes.Adobe & BT certificates. 07.37.47 Part Codefest 07.39.08 Quit CaptainKewl (Remote host closed the connection) 07.41.03 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 07.44.54 Quit planetbeing__ (Ping timeout: 276 seconds) 07.49.04 Join stoffel [0] (~quassel@p57B4D513.dip.t-dialin.net) 07.57.37 Quit JdGordon (Ping timeout: 248 seconds) 07.57.44 Quit CGL (Quit: Saliendo) 07.57.53 Quit n1s (Ping timeout: 258 seconds) 08.01.10 # * S_a_i_n_t shakes his fist at stupid "spam & leave" guy.....Grrrrrrrrrrr!!! 08.01.33 # s/guy/bot/dickface/ 08.09.32 Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) 08.11.35 Quit Xerion (Ping timeout: 240 seconds) 08.11.35 Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) 08.12.28 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.12.28 Quit Zagor (Changing host) 08.12.28 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.13.48 Quit chrisb (Ping timeout: 245 seconds) 08.19.17 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.21.32 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) 08.22.53 Join ender` [0] (krneki@foo.eternallybored.org) 08.28.36 Quit mc2739 (Ping timeout: 256 seconds) 08.29.16 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 08.50.34 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.53.43 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.56.07 Quit Zagor (Quit: Clint excited) 08.58.05 Quit JdGordon (Ping timeout: 245 seconds) 08.58.42 *** Saving seen data "./dancer.seen" 09.07.24 Quit planetbeing_ (Quit: planetbeing_) 09.08.51 Join petur [0] (~petur@213.49.144.150) 09.08.57 Quit petur (Changing host) 09.08.57 Join petur [0] (~petur@rockbox/developer/petur) 09.13.12 Part Speedy2 ("Konversation terminated!") 09.14.14 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 09.14.55 Quit stripwax (Client Quit) 09.18.39 Join gill0r_ [0] (~gill0r@f055214210.adsl.alicedsl.de) 09.21.41 Quit gill0r (Ping timeout: 252 seconds) 09.22.38 Join FOAD_ [0] (~dok@dinah.blub.net) 09.25.36 Join liar [0] (~liar@212067224009.public.telering.at) 09.26.05 Quit FOAD (Ping timeout: 252 seconds) 09.26.05 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 09.37.58 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 09.40.18 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr) 09.42.06 Quit liar (Read error: Connection reset by peer) 09.57.37 Join liar [0] (~liar@213162066167.public.t-mobile.at) 10.05.29 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 10.05.30 Quit Zagor (Changing host) 10.05.30 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 10.09.08 Quit lyngaas (Ping timeout: 240 seconds) 10.09.45 Quit planetbeing (Remote host closed the connection) 10.11.39 Quit shai (Quit: Leaving) 10.12.00 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 10.14.44 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 10.19.46 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.20.12 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 10.48.05 Quit liar (Read error: Connection reset by peer) 10.51.27 Quit BHSPitMonkey (Remote host closed the connection) 10.58.45 *** Saving seen data "./dancer.seen" 11.04.06 Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) 11.04.07 Quit DataGhost (Changing host) 11.04.07 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 11.07.25 # * petur wonders if somebody already applied for participation in GSoC 11.10.52 # Have we? i.e. has someone filled in the paperwork? 11.11.13 # which is what I'm asking ;) 11.11.52 # Ah, I thought you meant students... 11.12.08 # * linuxstb pings scorche|sh and Bagder 11.35.43 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.43.13 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 11.45.26 Join liar [0] (~liar@213162066165.public.t-mobile.at) 11.47.53 # does any coldfire wizard here know how the syntax for trapf.{wl} is? 11.59.10 Quit shai (Quit: Leaving) 12.03.12 Join Sajber^ [0] (~Sajber^@92-115.anonymous.at.anonine.com) 12.03.46 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.04.24 Quit Kitar|st (Ping timeout: 260 seconds) 12.05.31 # ok, using it with a literal value works but that is not very nice, 12.06.03 Join Kitar|st [0] (Kitr88@BSN-182-30-133.dial-up.dsl.siol.net) 12.18.05 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 12.18.24 # Hello and goodday everybody. 12.21.37 # Just tried installing iloader on my iPod Nano Black 2G yesterday but I kinda screwed up afterwards. Not totally but I cannot seem to get back to my old state. But, it did worked. So you can add me to the list of 7 tested devices ;) 12.24.19 # Do you know what you did wrong? 12.24.35 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 12.24.35 # I did make back-ups of the files appleos.bin and norflash.bak but i cannot seem to recover them. Tried to write them back with ipodpatcher for nano 2G with all different parameters and it did write to the firmware partition successfully but nothing changes. iloader keeps appearing at the ipod. Also uninstalling the bootloader succeeded and when repeating it it said bootloader already uninstalled, but iloader keeps appearing.. 12.25.05 # also dd'ing random data in linux to /dev/sdd and sdd1/sdd2 every possible way. Nothing changes :( 12.25.37 # perhaps someone knows how this is happening or has the same problem 12.26.04 # you need to flash norflash bask to nor, but you'll need to ask TheSeven about how exactly to do that. 12.26.16 # Ohh ok 12.26.59 # yes well.. the ipod starts with a recoveryscreen 'norloader' and quicky says to switch the hold switch and i do and then ibugger pops up 12.27.20 # but this norloader screen only appears for 10ms or so haha 12.27.42 # But I think i'll just have to wait for the TheSeven then. 12.27.49 # at the present state (with norloader installed) even if the apple OS is in the firmware partition, and the bootloader is installed to OSOS, the device isn't really aware of this... 12.28.06 # as the norloader takes no notice of them 12.29.04 # but it does sound very wrong, it will probably flash up quickly like that if the iLoader directory is not on the disk 12.29.12 # or if it cannot find the right files. 12.31.44 # TheSeven will be asleep at the moment, but I'm sure he won't mind if you PM him and let him know the state you've got yourself into. He wrote the installer, iLoader, iBugger...and a good deal of code for the Nano2g...so he really is the authority on this. 12.31.49 Quit stoffel (Remote host closed the connection) 12.33.37 Join hebz0rl [0] (~hebz0rl@dslb-088-067-222-007.pools.arcor-ip.net) 12.40.14 Quit DataGhost (Ping timeout: 252 seconds) 12.47.23 # Marctraider: if you use norloader iloader will be in the NOR flash. if you write random stuff to the NAND(/dev/sd?) that will not stop iloader from starting 12.49.21 # back 12.50.09 # S_a_i_n_t: thanks for the help already I will pm him later today, i've read everything you wrote 12.50.26 # liar: ok 12.50.55 # but norloader popups just 10ms when resetting ipod and instantly goes to iloader 12.51.16 # in that 10ms it tells to switch the hold button. When i do it starts ibugger. 12.51.21 # yes, thats normal 12.53.32 # i dont understand the problem, do you want to uninstall norloader? 12.53.36 # I DID manage to change one thing... namely that I got another screen with 3 options; telling there is a flash error or something. Then it gives me three options: Disk mode, ibugger, and something else. but this is also still part of the iloader.. I find it strange if ipodpatcher tells me it uninstalled iloader it still loads. But i'm not that into this stuff so i can be very wrong ofcourse. 12.54.16 # woops 12.54.21 # * TheSeven needs to catch up 12.54.26 # liar: The prob is i want to recover my ipod and i have 2 back-up files norflash.bak and appleos.bin. 12.54.34 # oh 12.54.44 # here we go :D 12.55.01 # * S_a_i_n_t thought TheSeven was still asleep... ;) 12.55.04 # TheSeven: Can i contact you later today for my problem? (I dont blame you ofcourse it was totally my own risk :) 12.55.26 # But I need to take the children out of school 12.55.28 # :( 12.56.01 # I'll be back as soon as i Can, please read what i've posted here TheSeven, see you later today perhaps. 12.56.25 # S_a_i_n_t: I was until a minute ago ;-) 12.56.36 # hehe :D 12.57.02 # hehe, I didn't build an uninstaller yet, but I can quickly make one 12.57.09 # lol? 12.57.12 # oh! ok... 12.57.25 # be back later ;) 12.57.43 # (you could always go back using ibugger and genflasher, but i'll prepare an automated way) 12.58.43 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 12.58.48 *** Saving seen data "./dancer.seen" 13.02.43 Join roolku [0] (~roolku@cpc2-sgyl16-0-0-cust17.sgyl.cable.virginmedia.com) 13.04.48 # Zagor: did you get my email regarding the build system problems? 13.05.34 Join perfectdrug_ [0] (~marko@p5B0EF811.dip.t-dialin.net) 13.06.24 Quit karashata (Quit: The fluffy dragon has left completely!) 13.09.32 Quit perfectdrug (Ping timeout: 258 seconds) 13.10.16 Join krazykit` [0] (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net) 13.12.57 Quit moos (Ping timeout: 264 seconds) 13.13.34 # n1s: What are you trying to do with trapf? 13.13.38 Quit krazykit (Ping timeout: 240 seconds) 13.14.25 # This instruction is meant for avoiding an extra branch in single instruction alternatives. 13.14.33 Join moos [0] (moos@rockbox/staff/moos) 13.14.46 # amiconn: according to the programmers manual it can be used to jump forward 2 or 4 bytes so yeah i try to hump past one instruction to avoid doing a bra 13.15.02 # eh s/hump/jump/ 13.15.06 Quit Marctraider (Ping timeout: 276 seconds) 13.15.08 # As such, you cannot use it as a mnemonic in the assembler (except the operand-less form, which is essentially a single cycle nop) 13.15.46 # yeah, that's what i gathered :( 13.15.52 # It's ugly, but I know of no other way than to use .word 13.15.57 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 13.16.34 # doesn't work well with inline asm unless you hardcode the registers, and a single cycle save is probably not worth it 13.17.14 # i wonder why the assembler can't handle it though 13.17.54 # The assembler can't handle it because you effectively turn the next one or two instructions (or one insn plus one extension word) into data 13.19.28 # I used this in two places: The remote lcd driver for the irivers, and the bit-banging i2c for the pcf50606 on H300, X5 and M5 13.20.06 # Libspeex also uses this in the filters on coldfire 13.21.00 # Oh, and the dsp code 13.22.54 # so that's why grep gave no hits 13.24.21 # If you grep for 'trapf' you'll find those places, because they say in a comment what this .word means 13.24.40 # (apart from the one in dsp_cf, since that says 'tpf') 13.26.25 # ah, i forgot the -r swithch, duh 13.27.20 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 13.27.33 Join moos [0] (moos@rockbox/staff/moos) 13.29.13 # aha, you only have to .word encode the trapf instr not the following ones, that makes it nicer 13.35.32 # amiconn: thanks, i had misunderstood it a bit and thought you'd have to use .word for the instructions following the trapf 13.36.18 # Marctraider: http://l4n.clustur.com/index.php/ILoader_Howto#Uninstallation 13.44.41 # TheSeven: I think I may have found a reason as to why the Nano1g is so much slower than the Nano2g...can you take a look at this please? 13.44.42 # http://pastebin.com/jeJnV1JL 13.45.33 # It seems a little odd to me, but I don;t know much about the CPU's of either target, or the similarities and differences. 13.45.59 # that looks sane, as it specifies the *default* freq 13.46.19 # (which is the highest possible on nano2g, and the lowest possible on nano1g for some reason) 13.47.08 # but soon after boot, the boosting code will take over and adjust that dynamically (between 48 and 192MHz on the 2g, and between 24 and whatever on the 1g) 13.47.52 # S_a_i_n_t: The Nano1g has an 80MHz CPU - I would expect it to be slower... 13.48.48 # linuxstb: we're talking about a ~factor 50 slowdown during disk accesses or whatever, making the pictureflow init take a minute on the 1g and a second on the 2g 13.49.01 # S_a_i_n_t: erm, regarding your symmetry thing, it's totally unusable for me 13.49.10 # something seems to have went wrong with it ;-) 13.49.26 # heh...why's that? 13.49.53 # Is that problem evident just in pictureflow? 13.50.20 # it seems to assume a wrong screen size, scrollbars, icons and the backdrop are missing, and the wps is some brown unreadable mess that looks roughly like the default wps, just in weird colors 13.50.27 # TheSeven: The default freq is usually the one that can be used with the pll disabled 13.50.38 # as long as you have the right fonts, it should run sweet. ;/ 13.50.45 # It is not used during normal operation, apart from the radio screen when not recording 13.50.45 # amiconn: that would be 32kHz on the 2g then :-P 13.50.50 # that's really fucking screwed up... 13.51.28 # The frequency used during operation is the *normal* frequency, unless the cpu can't cope, in which case we switch to the *max* frequency (boost) 13.51.35 # skin buffer: 57.8K used 13.52.01 # where is cpu_freq used at all then? 13.52.20 # ? 13.52.25 Join Lss [0] (~Lss@cm48.omega219.maxonline.com.sg) 13.52.56 # #define CPU_FREQ 191692800 to be exact 13.55.53 # S_a_i_n_t: oh nice. rebooted it, and now i just get a black screen 13.56.17 # and that's with a build without the ftl changes 13.56.43 # i read the files back from the ipod and compared, they're fine 13.58.02 # Something *must* be fucked up on your end...or *perhaps* its currepted somehow on the RB server...but I doubt it. 13.58.23 # I have the same theme running on 2 1g's and 2 2g's here at home. 13.58.40 # if i just load the wps, i'll get the default wps instead 13.58.52 # TheSeven: It is mostly used in a target specific way 13.58.58 # and it has been check out by perfectdrug on a sim he built...and reported it worked fine ;/ 13.59.39 # On targets without boosting it's also used to define the operating frequency in general 14.00.19 # amiconn: I set it to the operating frequency during boot (which is also the PLL speed, boosting is just done through divisors) 14.00.37 # CPU_FREQ is a fixed value 14.01.20 # cpu_frequency is reflecting the current value, and gets initialised to CPU_FREQ 14.01.26 # wrong evaluation order ;-) (I set it to the (operating frequency during boot )) 14.03.05 # So you can use CPU_FREQ on Nano G2 as you want. Having a CPUFREQ_DEFAULT that's fairly low would probably make sense though 14.03.31 # (although I don't think there are many occasions when this frequency is chosen - Nano G2 doesn't have a radio, does it?) 14.03.55 # only through accessories 14.04.05 # (which aren't implemented yet) 14.05.11 # * amiconn thinks he found the bug that caused the non-working battery bench 14.05.53 # There is a pair of functions to hook into a "disk is spinning" status. register_storage_idle_func() and unregister_storage_idle_func() 14.06.23 # The latter can optionally call the registered function (a last time, directly), and battery_bench uses that 14.06.43 # But if the target in question doesn't implement storage callbacks, that doesn't work 14.14.19 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.14.20 Quit roolku () 14.15.25 # Can I do an appeal to iPod Nano 1st / 2nd gen owners to test this theme *please* : http://themes.rockbox.org/index.php?themeid=634&target=ipodnano1g it is working on four of my target devices (two nano1g's and two nano2g's) but is apparently failing in spectacular fasion on TheSeven's Nano2g :-/ 14.17.00 Join anewuser [0] (anewuser@unaffiliated/anewuser) 14.17.02 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.21.45 Join Schmogel [0] (~Miranda@p3EE21AAA.dip0.t-ipconnect.de) 14.24.20 Quit anewuser (Ping timeout: 260 seconds) 14.25.59 Join anewuser [0] (anewuser@unaffiliated/anewuser) 14.26.23 Quit Marctraider (Ping timeout: 252 seconds) 14.26.34 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 14.26.55 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 14.30.09 # TheSeven: In order to make idle notification work you need to implement the call_storage_idle_notifys(false) call in the nand thread (compare to how other storage drivers do this), and enable it for nano G2 in ata_idle_notify.h 14.30.40 # It's nevertheless a bug in battery_bench that it doesn't work without idle notification 14.31.33 Join froggymana [0] (~187b533e@giant.haxx.se) 14.39.39 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 14.53.43 Join FOAD_ [0] (~dok@dinah.blub.net) 14.54.01 Join CGL [0] (~CGL@190.207.198.83) 14.57.33 Quit FOAD (Ping timeout: 245 seconds) 14.57.33 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 14.58.51 *** Saving seen data "./dancer.seen" 15.00.52 # TheSeven: thanks i'll check it out 15.00.56 # and report back 15.01.17 # i thought with ipodpatcher you could uninstall the bootloader and everything was fine, but i thought wrong i guess ;) 15.01.43 # that only applies to the old osos bootloaders, not to the nor ones 15.02.04 # ok 15.02.27 # you actually need to *reinstall* the old apple bootloader, overwriting iloader, and the place where it is stored can't be accessed directly from a pc 15.06.31 # mhh ok 15.06.43 # im trying the uninstaller now as we speak 15.07.22 # I assume one has a problem if one doesnt have norflash.bak backupped? 15.07.23 # :p 15.07.44 # .....yes. 15.08.24 # ok. Well thats not the case dont worry, but i just thought about it 15.08.35 # *phew* 15.08.42 # you freaked me out there... 15.08.43 # well, *in theory* one could build it from several pieces scattered around in apple firmware images and the iloader flash, but that won't be fun and requires some more advanced tools and knowledge about how this stuff works 15.09.01 # its not *so* bad, but you could never have a "stock" ipod again. 15.09.09 # *if that were the case that is. 15.09.10 # And i have one more question. The actual reason why i wanted to try this is because i wanted to edit the apple firmware to get rid of that stupid EU volume limit. 15.09.20 # i see 15.09.21 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 15.09.47 # I have edited an appleos.bin to remove the EU volume cap, can i use this one to replace my original? 15.09.50 # it is easy to "uncap" the ipod 15.10.00 # you can also do that without iloader, but it will require decrypting, patching and re-encrypting the firmware 15.10.02 # TheSeven could point you to a link I believe 15.10.15 # ehm 15.10.24 # (which is well possible, just a bit of work) 15.10.28 # well ill try to uninstall first, uncapping comes later i guess 15.10.57 # uninstall = copy 2 files and reboot it, then restore using itunes 15.10.58 # * S_a_i_n_t lives in NZ...so has iPods that can deafen him :D 15.10.59 # hehe 15.11.21 # TheSeven: aight! 15.11.25 # * TheSeven didn't notice *much* difference in the output levels whether it's capped or not 15.11.54 # and afterwards you can patch the firmware using ibugger, ipodcrypt and ipodpatcher 15.11.55 # do i need to rename it to iLoader.conf or .cfg? 15.12.01 # .cfg 15.12.03 # ok 15.12.08 # did i misspell it somewhere? 15.12.18 # i think so 15.12.29 # cfg vs conf 15.12.33 # ok, fixed 15.12.39 # no serious thing though ;) 15.12.45 # i was just confused for a sec 15.12.53 # brb 15.12.56 # that's why it needed to be fixed ;-) 15.13.05 # And with it uncapped, or with Rockbox which the "capping" is unaffected bym an iPod Nano 1st/2nd gen is plenty capable of destrying a cheap pair of IEM's 15.13.30 # even a halfway decent pair...if you take it up past 0dB 15.14.00 # my nano won't go above -1dB with 16 Ohms headphones 15.14.30 # *wont* go, or sounds shit if you go past? 15.14.41 # does the iloader screendissapear in some time or do i now just have to restore with itunes? 15.14.42 # both 15.14.56 # Marctraider: which screen exactly? 15.14.57 # ok the screen goes of but nothing happens 15.15.06 # * S_a_i_n_t got himself some sennheiser IE8's 15.15.11 # please press play and extract an iloader theme etc etc. Iloader free your nano! 15.15.21 # hm, it didn't find the iloader.cfg file then 15.15.27 # press play and fix it 15.15.34 # ok 15.15.37 # brb 15.15.52 # I can take both my 1 & 2 g's up to -6dB...but it sounds pretty dodgy past -3 15.16.07 # S_a_i_n_t: it sound shit *because* the output amplifier can't go above -1dB, or actually 20% less at 16 ohms 15.16.31 # the IE8's can take then punishment on -6db...but your ears can't (not for long anyway) 15.16.38 Quit DerPapst (Read error: Connection reset by peer) 15.16.58 # so the actual output level the headphones get will be around -3dB maximum. the amp isn't capable of supplying more 15.17.28 # arg, this stupid data abort 15.17.44 # how can I debug those better than getting the failure address? 15.17.46 # Ahhh...so the reading of -6 is not actually true? 15.17.57 Quit robin0800 (Read error: Connection reset by peer) 15.18.01 # which reading? 15.18.08 # the volume 15.18.11 # I would like a reg dump and/or the current ins 15.18.17 # you mean +6? 15.18.18 # mine goes up to -6dB 15.18.23 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 15.18.27 # ahh, yes 15.18.35 # +6 15.18.41 # sorry, forgot to shift 15.18.50 # maximum RMS output power of the amp is ~32mW, which is -3dB 15.19.11 # (which you'll get when setting it to -1dB, due to some inaccuracies) 15.19.25 # everything above that will just clip at 16 ohms 15.19.35 # Hmmm...howcome it displays up to +6dB then? 15.19.48 # oh, right. I get it now. 15.20.17 # it will apply up to +6dB to audio data that doesn't go above -9dB ;-) 15.20.45 # kugel: you can hack up the exception handler to print a regdump etc 15.21.07 # btw, when it's feeding into a line load instead of headphones, it will reach +1dB (and the setting will be accurate) 15.21.10 # I think funman once had a patch for that stuff 15.21.19 # yes 15.21.47 # n1s: why didn't that go into svn? 15.22.30 # * TheSeven likes the "crashkernel" approach, that would also allow to get a memory dump and look at the hardware 15.23.04 # n1s: it seems to be on the tracker (grepping logs is awesome :) ) 15.23.19 # TheSeven: i think it was because it used some cpu feature that some cpus were missing or something like that 15.23.46 # we should be able to get around that, at least for ARM, which would be quite helpful for a start 15.23.59 # yeah, it was arm only afaik 15.24.12 # this one should be committed 15.24.19 # but you should ask funman or whoever was against it :) 15.24.30 # kugel, whic fs# 15.24.30 # ehm 15.24.31 # the problem seems to be proper #ifdef'ing for ARMs without cp15 15.24.32 # TheSeven 15.24.42 # n1s: FS#10296 15.24.49 # thanks 15.27.19 # yeah, just a whitelist #ifdef including it for cores we know have the necessary features should be fine 15.28.00 Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com) 15.28.23 Join funman [0] (~fun@rockbox/developer/funman) 15.29.56 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 15.30.30 # join #qt 15.30.37 # take 2 15.30.52 # FS#10296 displays fault status and address causing the data abort (not the adress _where_ it happened), but we need to examine each model and see if it supports those registers (they are mandatory in ARMv6+, we need to check v4/v5) 15.31.27 # is there a armv5 which doesnt support it? 15.31.56 # i doubt v4 supports those 15.32.11 # we could extend our ARM_ARCH define to include some bitmask for certain features 15.32.32 # why not just check for the arm revision? most features are consistent across revisions 15.32.37 # preglow: 922t does, at least 15.33.18 # Torne knows the details, the registers are present if a MMU or a MPU is present 15.33.31 # yeah, that's what i expected, most v4s don't have that, if any 15.33.49 # sansa AMS at least do 15.34.11 # so, why would the cpu throw a data abort on address 60B4AE04? does it know where an address is good or bad? 15.34.45 # i'm wrong, btw 15.34.51 # loads of armv4s have mmus 15.34.53 # the address if foobar, btw 15.34.58 # kugel: That's not valid ram or rom, is it? 15.35.09 # preglow: we already knew you were wrong :p 15.35.21 # amiconn: no 15.35.23 # yeah, but not the extent to which i was :> 15.35.31 # kugel: you should look at lr and print a bit of stack to see where it comes from (perhaps a borked function pointer?) 15.36.10 # though you will have a different stack pointer so you need to switch to supervisor mode before reading the stack 15.36.21 # funman: or if they feel like it 15.36.31 # funman: it has occasionally been present on chips with neither :) 15.36.37 # it's not there on arm7tdmi though 15.36.52 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.36.54 # funman: how can I get lr? 15.36.56 # funman: also, I was going to work on that patch for you.. 15.37.08 # funman: to add support for ARMv6 and to make it ifdef'ed right. I just hadn't gotten around to it :) 15.37.25 # lr - 8 seems to the be the fault address 15.37.29 # Torne: well i'll let you do ;) i try to look for a good place in headers to discriminate CPUs 15.37.57 # funman: well your code is fine for armv5, but it won't work for prefetch/undef on armv6 as they have a separate IFSR :) 15.38.32 # funman: the fault is in an .S function, btw 15.39.18 # kugel: Is this the mpegplayer crash with eabi? 15.39.40 # yes 15.40.03 # it doesn't seem to be caused by short enums, I added a dummy with the value of INT_MAX to all 15.40.15 # Subtle difference in parameter passing between old abi and eabi? 15.40.25 # Which file+function? 15.41.20 # Torne: We "only" need to check TCC77x TCC780x DM320 AT91SAM9260 PNX0101 S3C2440 DSC25 and S5L870x CPUs 15.41.25 # I only know that the passing of 64bit types has changed. but the function in question doesn't have those 15.41.42 # amiconn: idct_arm.S:mpeg2_idct_add 15.42.06 # funman: pnx0101 is arm7tdmi iirc and the only port using it is dead 15.42.51 # fault 8 is "precise external abort, nontranslation" apparently 15.44.47 # * kugel still thinks we should remove dead ports from svn to make it easier for people to work on active code 15.46.47 # kugel: it's not in they way much 15.46.55 # TCC780x DM320 and S3C2440 do have an mmu (they use mmu-arm.S), I don't know about TCC77x (iaudio7/m200/c100/logikdax, all abandonned?), AT91SAM9260 (lyreproto1 = abandoned?), DSC25 (archos av300 = no code = abandoned) and S5L870x (meizus, nano2g) 15.47.43 # n1s: what's the point in keeping them? It's not like we can't recover their code from the svn history 15.47.48 # s5l870x have a mmu code so they're ok (why specific code btw?) 15.48.55 # kugel: true but since tey don't really get in the way i don't think removing them is very important but i wouldn't be against it 15.49.05 # funman: well, if they have a "standard" ARM cache or MMU or MPU they must have CP15 15.49.25 # I see that tcc77x manipulate cp15 cache registers 15.49.56 # do we not have a CPU type define of some kind? 15.50.07 # funman: non-standard caches I believe 15.50.08 # #define ARM946EJ-S or similar 15.50.16 # Torne: no, only V4 V5 and V6 15.50.22 # Well, then I think we should? :) 15.50.28 # since that's sufficient to determine cp15 presence afaik 15.50.42 # and it also determines dozens of other things 15.50.42 # what about ARM_CACHE_PRESENT ? 15.50.50 # which we may not have a need for right now, but may be usefu lone day :) 15.51.01 # is that an existing define? 15.51.06 # funman: s5l8700/s5l8701 doesn't have a mmu 15.51.10 # not all ARMs with caches have cp15, see portalplayer 15.51.13 # there is a CPU_ARM7TDMI 15.51.15 # they have weird external cache 15.51.16 # define 15.51.30 # Yeah.. do we not have more of those? 15.51.33 Quit froggymana (Quit: CGI:IRC) 15.51.40 Quit anewuser () 15.51.50 # btw, why do we need to access cp15 at all? 15.52.06 # Torne: i don't think so 15.52.17 # TheSeven: what's mmu-s5l8700.S for ? 15.52.40 # only cache coherency stuff 15.53.00 # TheSeven: fsr and far 15.53.01 # it actually has a MPU 15.53.06 # Torne: hm or MMU_PRESENT ? this would make #ifdef simpler if we only check this information in system-arm.c 15.53.33 # funman: Well, I would suggest that we define the specific CPU type in the target configs 15.53.44 # and then use that to infer a bunch of other defines like MMU/cache/etc 15.53.54 # and then use *those* to enable specific code 15.54.04 # This is probably a reasonable amount of effort from where we are now though 15.54.08 # but i think useful 15.54.49 # funman: lemme find an example 15.56.12 # kugel: Hmm, that's really odd. Do you know whether it works on the beast using eabi? 15.56.24 # no 15.56.56 # http://developer.symbian.org/xref/oss/xref/Symbian3/sf/os/kernelhwsrv/kernel/eka/include/nkern/nk_cpu.h <- is this publically visible? 15.56.59 # i think it should be :) 15.57.03 # it's been open sourced 15.57.05 Join b0hoon [0] (~quassel@62.87.184.82) 15.57.19 # the top of the file has all Symbian's implications for CPU type -> features 15.57.23 # we'd want something like that 15.58.03 # * amiconn builds an eabi toolchain 15.58.21 # Torne: sounds good, perhaps in a new cpu_arm.h file 15.58.41 # funman: that way you can write a single api for cache/mmu/etc that works for whatever 15.58.49 # without target-specific defines 15.58.52 # just ARM feature defines 15.58.55 # "#if !defined(__CPU_ARM1136_ERRATUM_411920_FIXED)" :) 15.58.59 # kugel: Yeah 15.59.13 # If you get silicon that has a fix for the erratum you can define that to turn our workaround off 15.59.18 # regaining whatever was lost by the workaround :) 15.59.25 # see now this code is all open i can talk about it ;) 15.59.39 # you'll notice there are a *lot* of erratums that are relevant :) 15.59.42 # ARM are awesome like that 16.00.16 # symbian (core) is OSS since a while 16.00.51 # eclipse public license 1.0 isn't compatible with GPL but we can use the idea of this file 16.00.58 # Yes 16.00.59 # amiconn: the parameter passing looks different in the disassemblies 16.01.00 # I didn't mean to copy it 16.01.04 # just the concept 16.01.22 # Torne: it would have been faster :P but screw those millions of licenses 16.01.46 # reinventing the wheel is good fun after all 16.02.07 # http://www.arm.com/images/proc-A946E-s.gif <- this diagram shows a MPU for the arm946e-s used in tcc77x 16.03.02 # nobody is listed having an iaudio7 on RockboxTesting :/ 16.04.24 # it's also a dead port 16.04.41 # too bad vitja left :/ 16.05.03 # btw I contacted pbxy over the forums, he was the first to run code on Clipv2 and he might come back in the effort 16.05.46 # kugel: Hmm, binutils did build, but gcc doesn't build: 16.05.57 # configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+ 16.06.08 # Does that sound familiar? 16.06.09 # yea, you need those since 4.4 to buiiöd gcc 16.06.50 # you can install them from your distros package manager 16.08.33 # If I would know the package names... 16.08.48 Quit Adnyxo (Ping timeout: 264 seconds) 16.08.53 # libgmp and libmpfr I think 16.08.54 # libgmp3 iirc 16.09.12 # maybe -dev even 16.10.22 Join Farthen_ [0] (~chatzilla@e179237206.adsl.alicedsl.de) 16.11.09 # yeah libgmp3-dev and libmpfr-dev on debian 16.11.29 # Ah. The latter also depends on the former 16.12.29 # TheSeven: do all the s5l870x have the same CPU ? tools/configure say 'arm940tbe' 16.13.28 # ah, be is bigendian for meizum*, ysp3; nano2g is littleendian 16.13.44 # afaik the 8700/8701 have an arm940tdmi 16.13.55 # does it need the -dev packages? 16.14.16 # the 8702 has an arm926ej-s 16.14.29 # do we have targets usign the 8702 ? 16.14.33 # not yet 16.14.36 # I thought both libs are auxillary utils for the build process. I can't remember anymore if I tried without -dev 16.14.40 # that would be nano3g and classic 16.16.23 # * amiconn curses rockboxdev.sh 16.16.32 # amiconn: in the meanwhile: http://pastie.org/861451 if you're interested in how it's called 16.16.58 # If the process is interrupted for whatever reason, and you forget to clean up the intermediate mess, it *will* fail next time 16.17.23 # Torne: is there a difference between 't' and 'tdmi' suffixes? 16.18.23 # just a shorthand I think 16.18.40 # Doesn't each letter in tdmi mean something? 16.18.46 # I don't think there's any t which doesn't support dmi as well 16.18.50 # t is for thumb, not sure what is dmi 16.19.14 # Ah yes, "Thumb Instruction, Debugger, Multiplier, ICE" 16.19.15 # d is debug, m is fast multiplier, i..I forgot :) 16.19.55 # ICE? 16.20.42 # in-circuit emulator 16.21.22 # * linuxstb doesn't know what that is though ;) 16.21.34 # * n1s googles 16.21.49 # * n1s finds http://en.wikipedia.org/wiki/In-circuit_emulator 16.21.51 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.22.01 # Torne: I've compiled the list of ARM CPUs on FS#10296 16.22.33 # it appears to mean jtag basically 16.22.46 # JTAG is a protocol, ICE is a thing to access over it :) 16.25.46 # funman: you probably want to print the entire FSR, not just the bits from it, because some of the other bits mean something on various processors 16.25.58 # kugel: That call looks fishy. The new gcc version is a bit short to tell what it's actually trying to do 16.26.00 # and some of htem mean something but aren't documented publicly :) 16.26.24 # it also appeared fishy to me 16.26.32 # You can clearly see that either r0 or r1 must be wrong, because they're identical when calling mpeg2_idct_add() 16.26.41 # it appears only the arm7tdmi (PP, pnx0101, dsc25 SoCs) don't have those registers 16.26.56 # compiling with -O0 would show how it expects the parameter passing, right? 16.27.22 # funman, Torne: There already is a macro for arm7tdmi specifically 16.27.33 # amiconn: this isn't the only feature that should be conditional on chip type, though 16.27.48 # amiconn: all the MMU/cache stuff should really be derived from ARM CPU type, not from target 16.28.05 # at least where the target uses ARM's standard macrocells 16.28.22 # which is also true of basically everything but PP 16.29.34 # * funman agrees and will let Torne do the work 16.29.43 # haha 16.29.46 # yeah thanks for that 16.30.09 # well, i will, at some point, if nobody else does. but i can't make many promises re when tha tmight be 16.30.14 # final fantasy xiii came out today 16.30.18 # :) 16.30.36 # funman: Went to Tokyohackerspace today, but left the JTAG cables on the board for now :) 16.30.38 # for now i'll just check ARM_ARCH < 6 and !CPU_ARM7TDMI 16.30.51 # funman: you can do it for 6 as well, it'll just be incomplete 16.30.59 # ranmachan: didn't test already, it'd be good if someone with an e200v2 tests it first 16.31.06 # Sadly a bit cramped in there, would be nice to fit a connector... 16.31.09 # just i suggest you make it print the whole FSR val instead of just those two fields 16.31.26 # although I could move the check after the known-to-be-working button check, i'm a bit lazy those days :) 16.31.28 # funman: Well, with the ifdefs it should only be used on C200V2. 16.31.29 Join MethoS- [0] (~clemens@134.102.106.250) 16.31.57 # i noticed that, perhaps we should just commit it now and check incrementally on each other model 16.32.06 # Torne: sure 16.32.23 # i have an armv6 manual handy, i can add the armv6 code unless you prefer to do it 16.32.27 # Well, do the armv6 stuff too 16.32.36 # it's basically just checking IFSR instead of DFSR 16.32.47 # DFSR on ARMv6 is at the same place as the unified FSR on armv5 16.32.59 # so you just need to check a different cp15 reg if it's a prefetch abort. 16.33.15 # (and obviously for prefetch abort, the FAR is irrelevant, it's lr that tells you where the abort was) 16.33.17 # 'on armv5' => but it's the same on armv4 & armv5 ? 16.33.21 # yes 16.33.27 # armv4/5 have one fault status register for all faults 16.33.37 # armv6 makes that register for data aborts only, and adds a new one for prefetch aborts 16.33.53 # hm, that -O0 doesn't appear to have worked 16.34.55 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.35.23 Quit leavittx (Read error: Connection reset by peer) 16.37.55 # Torne: domain & status bits will always be the same, i.e. there could be additional info in bits 31:8, but 7:0 still have the same meaning ? 16.38.46 # status is [10,3:0] 16.38.48 # not just 3:0 16.38.53 # so you are printing the wrong bits anyway 16.39.20 # Oh, that's onlt armv6 16.39.24 # amiconn: eabi doesn't seem to care about r1 at all 16.39.28 # also armv6 has bit 11 for "write" 16.39.33 # so you can differentiate read/write easier :) 16.40.10 # amiconn: this is with -O0: http://pastie.org/861489 16.40.13 # funman: er, so "sort of". the domain field will always be 7:4 but the status encodings were greatly expanded in armv6 16.40.20 # as well as the extra bit for "write" 16.40.36 # funman: read ARM ARM rev I or later :) 16.40.53 # where ARM = Architecture Reference Manual ? 16.41.13 # and I is capital i 16.41.16 # got that 16.42.07 # amiconn: of course not even the -O0 version works 16.43.55 # 1 parameter seems to be passed via stack 16.45.35 # Hello guys, TheSeven has helped me with my ipod black nano 2G and its recovered to original Ipod firmware, WITH EU volume limit removed! :) i'm just glad i didnt have to throw my ipod away... going for a smoke now see'yal later! 16.52.44 Quit advcomp2019 (Ping timeout: 260 seconds) 16.53.40 Join Strife89 [0] (~michael@168.16.232.173) 16.53.45 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 16.54.35 # pixelma: want to test something re stkov in properties? 16.55.05 # later, sure 16.55.20 # amiconn: it seems like this from old to new gcc: r0 = r0; r1 > r2; r2 > r3; r3 > stack 16.56.31 # kugel: have you got something that's become 8 bytes because of the eabi requirements? 16.56.42 # it sounds like the first arg is 8 bytes big.. 16.57.00 # no, void mpeg2_idct_add(const int last, int16_t * block, uint8_t * dest, const int stride); 16.57.21 # yes, it appears this rule applies. but it shouldnt 16.57.23 # ..const int? 16.57.46 # pixelma: ok, then try declaring the mp3entry struct on line 69 outside the function so it's not on the stack; it's the only obviously large stack eating thing in the plugin except for the fact that gcc might go crazy with inlining since all functions are static 16.58.10 # Torne: is there a problem with that? 16.58.16 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.58.18 # not that i know f 16.58.32 # i've just never found declaring parameters as const to be useful :) 16.58.42 # well, values 16.58.46 # it rather sounds like the 2nd arg is 8 bytes now 16.58.47 # n1s: umm, well, how? 16.58.52 *** Saving seen data "./dancer.seen" 16.59.02 # ah well, that doesn't make sense either :) 16.59.52 # const params make sense. that tells the caller that the regiser being left untouched 16.59.53 # pixelma: just move the line outside the function 17.00.24 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 17.00.31 # r0-r3 are caller saved, so if the caller needs them after the call it may omitt the saving 17.01.06 Part LinusN 17.01.31 # pixelma: above the function even (or it won't build) 17.02.12 # Torne: the stack parameter goes away when I swap the 2nd and 4th parameter 17.02.42 Quit n1s (Quit: Lmnar) 17.05.13 # wooh, mpegplayer runs now 17.05.20 # but, what the hell is this!? 17.06.06 # maybe I should write to the gcc ml 17.06.11 # that appears to be a bug 17.07.10 # kugel: yes, sounds like it might be 17.07.16 # kugel: however your argument for const params is wrong. 17.07.26 # kugel: You still have to save r0-r3 17.07.43 # why? 17.07.45 # calling them const only guarantees that the called function doesn't assign to those variable *names*, it says nothing about the registers 17.07.51 # The function is still free to overwrite r0-r3 17.08.05 # The parameters don't necessarily stay in those registers. 17.08.20 # good point 17.08.23 # the const *only* protects you from accidentally assigning to the params when you meant to write something else 17.08.29 # there is no difference in the generated asm, no optimisation benefit. 17.08.55 Join CaptainKewllllll [0] (~2669ecc2@gateway/web/freenode/x-gbpvdlabrmxzmter) 17.08.59 # Torne: can you check http://www.rockbox.org/tracker/task/10296?getfile=21548 ? 17.10.06 # perhaps I could enhance comments "no MPU/MMU" can refer to arm7tdmi or to !arm7tdmi in the context 17.10.28 # funman: looks good, except don't print FAR for prefetch aborts 17.10.33 # it's not updated 17.10.50 # so it would just be the address of the last data abort, which is not useful ;) 17.11.03 # hm right 17.11.25 # also you might consider for undef aborts, fetching the instructoin and printing that 17.11.39 # (you know it's fetchable or you wouldn't get an undef) 17.11.55 # it's not vital, though, i guess, you can find it in the elf binary 17.12.50 # meh probably not worth it 17.12.56 # it's gonna be vanishingly infrequent 17.13.21 # Do all the targets we're using here have room for 7 lines of text on screen? 17.13.29 # i assume yes, but.. 17.13.47 # assuming 8 pixels font yes 17.13.53 # most should handle 7 in the 8px sysfont 17.14.10 # ok, cool. 17.14.31 # length should be ok, i had tested back then on Clip (128x64) 17.14.46 Part b0hoon ("GTG Bye.") 17.15.02 Quit liar (Quit: Verlassend) 17.17.49 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.19.53 # New commit by 03funman (r25087): Display Fault status address register on data/prefetch aborts ... 17.20.43 # anyone know what ARM1136 revision the i.MX31 is? :) 17.21.45 # debug menu could print the ID code on arm 17.22.14 Quit MethoS- (Remote host closed the connection) 17.27.45 # again, only if it has cp15, but yes ;) 17.28.59 # Torne: it does, cycle counter is somewhere in cp15 ;) 17.29.22 # s/cycle counter/terribly generic performance counter/ ;) 17.29.40 # New commit by 03funman (r25088): mkamsboot: Use audio master irq_enrd0 usb_status bit instead of gpio on C200V2 ... 17.30.10 # Unhelpful: what? 17.31.43 # cp15 is the system control coprocessor, yes? i've used parts of its functionality on beast. 17.31.45 # funman: any news on the clip+? sound (even if it's just radio) would be nice :) 17.32.35 # ThomasAH: no, when we have sound we'll send the 'gentlemen' email 17.32.45 # * kugel sent the mail 17.32.57 # funman: what is a 'gentlemen' email? 17.33.06 # Unhelpful: i meant funman's point about the id code 17.33.10 # Unhelpful: not perfctrs. 17.33.36 # ah, "Gentlemen, we have SOUND!" ... found a few 17.33.43 # ThomasAH: see http://www.rockbox.org/wiki/GentlemenMails 17.33.58 # Torne: ah, so the beast's CP15 may not have the ID code? 17.34.08 # ThomasAH: I've been looking at the clocks setup for awhile now trying to sort things out but it's being rather finicky.... 17.34.43 # Unhelpful: no, all ARMs with cp15 have the id register, but arm7tdmi does not have cp15 and thus no id register 17.35.10 # kugel: Is that only for this function, or all functions? 17.35.21 # In fact that looks like a gcc bug to me 17.35.28 # Torne: isn't cp15 mandatory & standardized on armv6 ? 17.35.34 # Torne: ...ah... i think my error was in thinking funman was replying to your anyone know what ARM1136 revision the i.MX31 is? :) 17.35.46 # it's possible that other functions are hit as well 17.35.56 # Unhelpful: but i was ! :) 17.35.59 # FlynDice: clock works fine for me after setting it on both sides in the correct order :) 17.36.05 # We could work around it by reordering the parameters of the idct_* functions. Of course that needs adjusting all asm implementations, not just arm 17.36.13 # FlynDice: or clocks as in ram speed and such? 17.36.34 # I think the problem is exposed by the fact that mpeg2_idct_add() is written in asm. if it was written in C it would probably follow the same strange calling convention gcc dictates here 17.36.49 # ThomasAH: er not the time but fclk, pcclk etc... 17.36.51 # kugel: what "strange" calling convention? 17.37.00 # funman: yes.. we should do that, just not on arm7tdmi :) 17.37.25 # This *might* because the 2nd and 3rd parameters are pointers - gcc may consider them as (potential) 64 bit parameters, so r1 is skipped 17.37.34 # Unhelpful: the gcc generated call appears to violate the standard calling convention 17.37.49 # FlynDice: this is for running without disabled caches I assume? 17.38.03 # amiconn: ...are pointers 64b on ARM? and since when? 17.38.26 # No - that's why I said it may be a gcc bug 17.38.37 # amiconn: that wouldn't make sense. how can it put something into r3 if r2 was a 64bit type (i.e. would take space in r3 as well)? 17.38.50 # And also why I asked whether it's just this function, or all 17.38.57 # kugel: what if you cast the pointers to uint? 17.39.06 # (in the call) 17.39.50 # ThomasAH: Not sure, but the clocks setup right now just "happens" to work so perhaps that will help. Right now the as3525 fclk is at 6 MHz... clk_main(24MHz)/4 17.39.58 Quit Strife89 (Ping timeout: 256 seconds) 17.40.08 # make that as3525v2 17.40.19 # kugel: And if it's more than just that one, be prepared to see spectacular crashes on various arm targets. Everywhere - not just in plugins 17.40.47 # Unhelpful: same result 17.41.28 # amiconn: I assume there's no crash as long as the called function is also compiled by gcc 17.41.51 # FlynDice: I'm not familiar with such details. fclk is like the FSB speed on PC hardware? 17.42.03 # ThomasAH: That's wrong, FCLK is 120 MHZ PCLK is at 6 MHz 17.42.08 # Yes, but there are numerous asm functions in the core as well 17.42.15 # ...e.g. ata transfer 17.42.45 # my hdd based yh925 behaved fine in the core 17.43.04 # it appears to be dependant on the order of the parameters as well. swapping the 2nd and 4th one helps 17.43.19 # (in the prototype only) 17.43.40 # ThomasAH: and the bus is fastbus mode which means the processor is only clocked at 6 MHz right now 17.45.17 # FlynDice: thanks for the explanation, I probably have to read more about it 17.45.28 # kugel: it definately sounds like an 8-byte-alignment issue 17.45.34 # FlynDice: I have dualboot now on the clip+, but when booting rockbox, it's stuck at the rockbox logo. (With I & D cache disabled) 17.45.40 # AAPCS requires that 8-byte values be passed in r0/r1 or r2/r3 17.45.56 # but there is no 8byte value being passed 17.46.01 # Well yes 17.46.06 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 17.46.09 # but that's why it goes away when you reorder them, i mean 17.46.16 # see algorithm in AAPCS section 3.3 17.46.26 # not that gcc necessarily quite does that. 17.46.40 # * ThomasAH has to leave ... bye! 17.47.01 # mt: btw, bootloader doesn't use MMU nor caches, I/D caches needs only to be disabled in rockbox.sansa 17.47.05 # my AAPCS doesn't have section 3.3 :( 17.47.36 # er 5.5 17.47.37 # sorry 17.48.27 # mt: try putting an mci_delay() after the second MCI_CLKDIV down at line 460 of sd-as3525v2 17.48.48 # * amiconn wonders whether this a general gcc-eabi bug, a gcc 4.4.3 bug, or a quirk in arm eabi 17.49.04 # What's the earliest gcc supporting eabi? 17.49.28 # amiconn: the ABI is fine, but other than that I can't say :) 17.49.39 # mt: I didn't need this until a few days ago but I think funman's clip+ needed it all along 17.50.09 # FlynDice: storage should be initialized after LCD, so i'm not sure if that's the problem 17.50.21 # Well, the reason why I am wondering is because two of those parameters are pointers, and two are ints 17.50.43 # In svn they are int/ptr/ptr/int, and that causes the strange gcc behaviour 17.50.58 # well, the order should not matter 17.51.02 # I guess that both int/int/ptr/ptr and ptr/ptr/int/int would work fine 17.51.03 # because the width of all those types is 4 17.51.22 # i can't see any reason in AAPCS why it should spill no matter the order 17.51.27 # and have never seen this happen in other code 17.51.43 # So it's probably a gcc bug 17.52.04 # yeah 17.52.13 # can I make gcc not call ld? 17.52.21 # hmm? 17.52.25 # sure, -c 17.52.27 # funman: mine started hanging there last week and I added the delay and it seemed to make it work at least 17.52.48 # kugel: What are you trying to do? 17.52.54 # i've not hacked on my Clip+ for 1 week or so 17.52.56 Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) 17.52.56 Quit DataGhost (Changing host) 17.52.56 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 17.54.09 # they want a self-contained C file to reproduce this problem 17.54.30 # Ah, yes 17.54.58 # gcc -E perhaps ? so all #include are replaced by the header content 17.55.00 # Btw, because you asked why the SH1 patch isn't pushed upstream: The gcc team is strange if you report a bug 17.55.19 # I only have bare metal cross compilers, so I need a crt0.o to verify my test case shows the problem 17.55.43 # kugel: can't you just check the asm ? 17.56.12 Quit fyrestorm (Read error: Connection reset by peer) 17.56.14 # ah yes 17.56.41 # * amiconn now has an eabi beast build 17.57.01 # Is everything else other than USB working fine on the e200v2 ? ( I've seen the wiki, but I don't have a v2 to check myself ) 17.57.29 # why is http://forums.rockbox.org/index.php?topic=24146.msg163344 locked : not posted in the correct forum? 17.58.11 # It would be moved then... 17.58.16 # kugel: gcc produces the same mess for ARMv6 17.59.24 # hm, the test case doesn't show the problem 17.59.54 # gevaerts: i thought forum mods locked topics before moving them, but it seems no one is viewing this topic (was when i checked it) 17.59.58 Join chrisb [0] (~chrisb@pool-71-175-246-16.phlapa.east.verizon.net) 18.00.34 # funman: no, you'd see a redirect message then, not the original 18.03.12 # kugel : Any idea about my e200v2 question ? 18.04.35 Join guymann [0] (~charlie@adsl-69-177-38-66.adsl.snet.net) 18.05.03 # mt: that sounds about right 18.05.58 # * amiconn builds gcc 4.3.4 for arm eabi 18.06.21 # funman: I'll unlock and move it 18.07.08 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.13.33 Quit LambdaCalculus37 (Quit: This computer has gone to sleep) 18.15.09 Quit pamaury (Quit: Quitte) 18.21.00 Join MethoS- [0] (~clemens@134.102.106.250) 18.24.19 # FlynDice: mci_delay() didn't work 18.29.45 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.30.32 Join Buschel [0] (~ab@p54A3DD46.dip.t-dialin.net) 18.31.42 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 18.33.10 Quit petur (Quit: *plop*) 18.34.00 Join CFP [0] (~Create@ip-247.net-81-220-136.rev.numericable.fr) 18.34.39 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.37.22 # gsoc project application time has begun !! who fills out our application ? ie who wants to be our gsoc admin ? 18.38.49 # * chrisb enjoying his sansa e200 today 18.39.06 # it took a while to understand the background database update 18.40.23 Join fml [0] (~53ecea55@giant.haxx.se) 18.40.29 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.41.22 # domonoky: hello. If you're able to build manuals, could you please try FS#11088 and tell me whether it compiles? I have no build environment at the moment. 18.42.49 # fml: sorry i also cant build the manual at moment. 18.46.06 # domonoky: ok, no problem. Anybody else with latex and build environment installed? 18.46.30 # Hmm, arm-elf-eabi-gcc 4.3.4 produces the same nonsense 18.46.41 # fml: I can try after another build finished.. will take some minutes 18.48.13 Quit Marctraider (Ping timeout: 240 seconds) 18.49.05 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 18.50.30 Quit anewuser () 18.50.53 # Buschel: ok, thanks! 18.51.22 # amiconn: :'( 18.51.34 # * amiconn is going to try 4.0.4 18.52.53 # that one can't do eabi afaik 18.54.08 Quit Tomis (Ping timeout: 260 seconds) 18.54.45 # Well, it just configured for eabi 18.55.26 Join Tomis [0] (~Tomis@70.134.97.221) 18.55.40 # "The commercial ARM RealView C/C++ compiler was the first to support EABI, and usable EABI support came into GCC from version 4.1.0." 18.55.41 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 18.55.44 # http://wiki.debian.org/ArmEabiPort 18.56.16 # did you try code sourcery gcc ? 18.56.22 # fml: the patch compiled and I have a .pdf file as result. Shall I check for something? 18.57.11 # hardware.bug tests advice to use CodeSourcery 2009q1 over FSF GCC 4.3.4 (for free compilers) 18.57.58 # I've tried 2009q3 18.58.56 *** Saving seen data "./dancer.seen" 18.59.50 # Buschel: not necessarily, I just wanted to know whether it compiles. But if you have a minute you can look at some table with button maps and tell me what vertical spaces (with or without patch) looks nicer. Or you could just post the PDF to a binpaste so that I could compare as well. 19.03.23 Quit chrisb (Ping timeout: 245 seconds) 19.04.15 Join carpathia [0] (~raven9@lan22.covernet.pl) 19.04.54 Part carpathia 19.05.44 # mt: I don't know what else to suggest besides trying to turn it on several times. While I've been playing with the clock setup I've found it will hang right there on startup sometimes but if I turn on/off several times it will finally boot up. 19.06.26 # kugel: which build are you seeing the mpegplayer for ? 19.06.56 # * kugel can't parse that 19.07.11 # kugel: which build are you seeing the mpegplayer problem for ? 19.07.48 # eabi builds with the 4.4.x compiler (apparently 4.3.4 too) 19.07.58 # it's not clear whether eabi or the new compiler causes it 19.08.06 # it's definitely a compiler bug though 19.08.20 # i meant, any target? i'm building fuze to see if i can make a reduced test case 19.08.36 # yes fuze 19.10.28 Quit DerPapst (Quit: Leaving.) 19.11.28 # funman: beast also shows the problem 19.12.00 # I alreday tried gcc 4.3.4, with the same result 19.12.21 Join Strife89 [0] (~michael@168.16.232.173) 19.23.32 # fml: did you see my pm? 19.25.29 Quit Strife89 (Quit: Be right back.) 19.26.59 # i have a test case: the problem seems to be struct addressing 19.27.48 # together with attribute aligned 19.28.13 # Buschel: sorry, no. But now I see it. 19.28.23 # funman: oh, interesting 19.31.40 # it looks you'reright 19.32.08 # http://pastie.org/861764 19.32.51 # aligned(4) = no problem, aligned(8) = problem 19.32.53 # http://pastie.org/861766 "fixes2 the problem 19.32.53 # So it could be worked around by using an intermediate variable? 19.32.59 # yes 19.33.21 # Buschel: actually, I don't quite like both. The reason is that in many places, the tables with the buttons directly follow section captions which isn't good style. I tried to eliminae the not needed table envs since they are there for nothing. We even fight their nature (being floating) via redefining placement to H (=here!, i.e. not floating at all) 19.33.23 # Eh, volatile? 19.33.29 # funman: align(16) = problem as well? 19.33.33 # kugel: yes 19.33.40 # amiconn: I wanted to make sure gcc doesn't optimize it away 19.33.55 # kugel: you want to report the test case to gcc ? 19.33.56 # I forgot I use -O0 anyway 19.34.02 # funman: sure, will do 19.34.05 # Using volatile will slow down things... 19.34.35 # not in this case I think 19.34.45 # the memory isn't even derefenced 19.35.03 # Try without it... 19.35.18 # I think in many (most? all?) cases the sections should be replaced with table captions. But that's too much to do and will probably also require some rewording. So I'll leave it. 19.35.19 # (and -O2 or whatever the standard level is) 19.37.14 # kugel: i had to use (volatile int16_t*) -not uint- and cast block to non volatile, now it looks fine 19.38.48 Join Stephen__ [0] (~S@86.45.50.221) 19.39.49 Join mitk [0] (~mitk@chello089078013146.chello.pl) 19.39.58 # it needs volatile 19.40.14 # in the declaration 19.40.26 # if -O0 is not used 19.40.32 Quit fml (Quit: CGI:IRC) 19.40.49 # http://pastie.org/861778 : builds & runs with default flags 19.41.35 Join planetbeing_ [0] (~planetbei@32.153.111.89) 19.41.36 Quit planetbeing (Read error: Connection reset by peer) 19.41.37 Nick planetbeing_ is now known as planetbeing (~planetbei@32.153.111.89) 19.41.54 Join Strife89 [0] (~michael@168.16.237.214) 19.42.32 Join planetbeing_ [0] (~planetbei@c-24-21-138-231.hsd1.or.comcast.net) 19.42.38 Nick Farthen_ is now known as Farthen (~chatzilla@e179237206.adsl.alicedsl.de) 19.43.03 # Hi, can an dev take a look at FS#11082 - Polish character set for 08-Atadore font? 19.43.11 # kugel: http://pastie.org/861780 even shorter testcase 19.43.23 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.43.44 # working with aligned(4), not with aligned(8) 19.44.11 Join leavittx [0] (~leavittx@89.221.199.187) 19.44.26 Join stoffel [0] (~quassel@p57B4A686.dip.t-dialin.net) 19.44.47 # perhaps gcc assumes aligned on 64 bits means 64 bits 19.45.27 # funman: what happens in the disassembly? 19.45.36 # block is on stack, or in r3? 19.45.47 # just look if r1 is modified or not 19.45.56 # I didn't compile it :) 19.46.04 # r0 is always 0 19.46.28 # s.member goes into r1 for aligned(4) , into r2-r3 for aligned(8) - and thus leaves r1 untouched - 19.46.32 # funman: You're passing a pointer - and why should the pointer be aligned 19.46.33 # ? 19.47.15 # S_a_i_n_t: I'm confused. The iLoader release you installed managed to boot /.rockbox/rockbox.ipod? I just found a bug that *must* have prevented this from working 19.47.25 # amiconn: DCTblock is "int16_t * ATTR_ALIGN(16)" in mpeg2_internal.h 19.47.52 # Yeah and? 19.48.28 # You're passing a pointer to it. That pointer is 32 bit. Alignment of its destination shouldn't matter at all 19.49.31 # I don't understand what you're asking me 19.50.39 # I don't know if alignement of the pointer is relevant for I don't know mpeg2dec code 19.51.01 # volatile fixes your test case as well 19.51.47 # Eh, wait. The struct member is aligned? 19.52.39 # The block this member points to should be 16 byte aligned for performance reasons (cache line alignment, resp. alignment for line burst on coldfire) 19.52.48 # The pointer itself doesn't need to be aligned 19.52.57 Join Strife1989 [0] (~michael@168.16.237.214) 19.53.49 # should it be int16 ATTR * ? 19.53.51 Join michaelcarr [0] (~michael@168.16.237.214) 19.54.43 # Imo it should be int16_t * DCTblock; 19.54.59 # I'll check the svn log, perhaps there is a reason for this strange alignment 19.55.24 Quit Strife89 (Disconnected by services) 19.55.27 Nick michaelcarr is now known as Strife89 (~michael@168.16.237.214) 19.55.51 Quit CGL (Read error: Operation timed out) 19.57.57 Quit Strife1989 (Ping timeout: 268 seconds) 20.00.01 # funman: it seems likely that gcc confuses something here 20.00.36 # 64bit values must be 8byte aligned afaik, maybe now treats all 8+ byte aligned data as 64bit 20.02.03 # There may be a bug in gcc, but it is also a bug in rockbox that was revealed by eabi 20.02.53 # a bug? 20.03.04 # yes 20.03.11 # hardly a bug. valid code, just unneeded 20.03.24 # Unnecessary padding -> waste of ram 20.03.28 # Huh. "make: *** No rule to make target `/home/michael/rockbox/apps/codecs/libmusepack/musepack.h', needed by `/home/michael/rockbox/ipod_color/apps/codecs/mpc.o'. Stop. 20.03.28 # " 20.03.45 # Strife89: make dep or full rebuild 20.04.20 # kugel: Try removing the attribute from the pointer, build and run 20.04.46 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 20.05.04 # * amiconn spots a possible optimisation for pp5020 20.05.37 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 20.06.03 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 20.07.02 # amiconn: works 20.07.27 Quit CFP (Quit: Quitte) 20.07.41 # It works on the beast as well 20.08.14 # Shall I commit? 20.08.25 Quit Schmogel (Ping timeout: 265 seconds) 20.08.40 Quit planetbeing_ (Ping timeout: 276 seconds) 20.09.15 # amiconn: you found what was that attribute for in the log ? 20.09.19 # New commit by 03b0hoon (r25089): Packard Bell Vibe 500: reset all allowed devices like in the OF. 20.09.46 # funman: Seems it was just a mistake when taking the buffer itself out of the struct. At least there is no explanation 20.11.22 # it it serves no purpose for optimization, just commit the change 20.11.48 # funman: very good work on this find! 20.12.30 # It *may* have to do with dualcore on PP. I'll try it in a moment 20.13.44 # * kugel bets the underlying bug is as simple as "if (eabi && var_align >= 8) ..." instead of "if (eabi && var_size >= 8) ..." 20.15.58 # bluebroth3r: ok, in my RbUtil testing on PPC I had the wrong TTS set... the Utility doesn't hang with the correct one and "Test TTS" sounds correctly. But again the speex talk files are just noise, going to test my Ondio again 20.16.52 # Hmm. The decoder struct is dynamically allocated (as part of a larger struct) so that's pretty unlikely 20.17.03 # bluebroth3r: and I think RbUtil shouldn't freeze like that with the wrong TTS configuration 20.17.11 # The internal allocation mechanism only aligns to 32bit 20.17.32 # arr 20.17.45 # kugel: Be prepared for some fun when switching to eabi... 20.18.08 # "region `PLUGIN_IRAM' overflowed by 340 bytes" in mp3_enc for ipod color... 20.18.13 Join krabador [0] (~darkham@host128-181-dynamic.246-95-r.retail.telecomitalia.it) 20.19.40 # can you actually make sure a struct member is 16byte aligned if the whole struct isn't, and if the struct is dynamically alocated? 20.20.04 # That's my point 20.20.24 Quit planetbeing__ (Quit: planetbeing__) 20.21.12 # Another point is that even on PP libmpeg2 doesn't run dualcore itself. The core split is between video and audio 20.21.22 # ...and audio is handled by libmad 20.22.25 # isn't libmad itself dual-core'ized as well? 20.22.35 # Nope 20.22.57 # mpa.codec is, libmad itself just offers the building blocks 20.22.59 # bluebroth3r: same effect - MP3 talk clips work :) 20.23.06 # ah, ok 20.23.16 Quit perfectdrug_ (Quit: perfectdrug_) 20.23.19 Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net) 20.23.33 # In mpegplayer it is used on one core 20.24.20 # Iirc audio and buffering runs on CPU and video on COP (and the greylib also runs on COP on greyscale PP targets) 20.25.40 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 20.26.43 Join perfectdrug [0] (~marko@p5B0EF811.dip.t-dialin.net) 20.27.47 Quit flydutch (Quit: /* empty */) 20.28.08 Join lark1313 [0] (~9d7f9bd6@giant.haxx.se) 20.28.20 # ls 20.28.34 # libmad is actually a couple API calls one for parsing and mdct, one for subband filterbank 20.28.44 # we just run them on seperate cores in mpa.c 20.28.51 # which is why it was such a trivial change 20.28.59 # very nice of them to write the codec in such an odd way 20.29.34 Join Schmogel [0] (~Miranda@p3EE21AAA.dip0.t-ipconnect.de) 20.30.25 Quit lark1313 (Client Quit) 20.30.51 Quit mitk (Quit: Leaving) 20.30.56 Quit funman (Quit: free(random());) 20.35.51 Quit LambdaCalculus37 (Quit: This computer has gone to sleep) 20.38.33 Quit krabador (Quit: Sto andando via) 20.41.38 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 20.44.14 Quit planetbeing_ (Ping timeout: 276 seconds) 20.45.37 # New commit by 03Domonoky (r25090): put zip size and zip contents into the db, (updated on checkwps runs) so it doesnt need to always look that up. 20.46.31 Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-fgmoonyfuhfrzchz) 20.46.59 Quit Seed (Ping timeout: 252 seconds) 20.47.05 Quit Schmogel (Ping timeout: 265 seconds) 20.47.36 Join CGL [0] (~CGL@190.79.151.231) 20.48.12 # hmm 20.48.39 # mpegplayer runs on the Color, but there are some video glitches 20.50.15 # New commit by 03Domonoky (r25091): try to fix the themesite. 20.52.19 # Buschel: SVN 470.27%, 26.4 MHz, align patch 470.63%, 26.38 MHz Impressive! 20.52.30 # hehe :) 20.52.53 # AlexP: no effect... 20.53.25 # not as such, no 20.56.05 # AlexP: thanks for testing and enough for today... 20.56.49 Join Schmogel [0] (~Miranda@p3EE21AAA.dip0.t-ipconnect.de) 20.56.59 # no worries 20.57.55 Join Seed [0] (~ben@bzq-84-108-232-45.cablep.bezeqint.net) 20.58.59 *** Saving seen data "./dancer.seen" 21.01.55 # Doesn't happen on oldabi so must be an eabi problem (or just a glitch) 21.02.29 # New commit by 03amiconn (r25092): Get rid of unnecessary alignment of struct member which also caused arm-elf-eabi-gcc to mess up parameter passing to mpeg2_idct_add(). 21.02.49 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 21.06.51 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.06.51 Quit pixelma (Disconnected by services) 21.06.55 Quit amiconn (Disconnected by services) 21.06.57 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.07.04 Quit stoffel (Remote host closed the connection) 21.07.08 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.12.33 Join DerPapst [0] (~DerPapst@p5797CBAE.dip.t-dialin.net) 21.16.35 Quit LambdaCalculus37 (Quit: Fwump) 21.22.32 Quit JdGordon (Ping timeout: 260 seconds) 21.22.32 # New commit by 03Domonoky (r25093): Add search function. 21.24.02 Quit mt (Read error: Connection reset by peer) 21.24.11 # amiconn: the latest answer on gcc-help suggests "char __attribute__((aligned(8))) *member;" to say it points to something 8byte aligned 21.24.18 # and he says it's indeed a bug 21.24.49 # but was never discovered because it's triggered by bizzare code :) 21.25.57 Quit TheSeven (Read error: Connection reset by peer) 21.26.12 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 21.26.22 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 21.27.42 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 21.27.45 # what sort of glitch did you see? 21.28.02 Quit Highlander (Quit: Quitte) 21.28.38 Join Digital_Pioneer [0] (~nathan@adsl-99-30-246-242.dsl.ltrkar.sbcglobal.net) 21.28.45 Join banzairun [0] (~c6180687@giant.haxx.se) 21.29.07 # is this thing on? 21.29.11 # Hi. I'm trying to install rockbox on a friend's Fuze, following this tutorial: http://ubuntu-tutorials.com/2009/06/12/install-rockbox-on-your-sansa-fuze/ and nothing happened... 21.30.08 # hi, I'm a dumbass newb asking a question that likely has an obvious answer that I nonetheless can't find on the web page... 21.30.24 Quit dfkt (Ping timeout: 264 seconds) 21.30.33 # f.5g) 21.30.50 # I just installed rock box on an ipod video 80gb 5.5g 21.31.15 # can I get my clickwheel itunes store games to work from the rockbox interface? 21.31.55 # banzairun: no, they don't work in rockbox. but you could boot the original apple firmware 21.32.10 # thanks 21.32.17 # how do I switch between them? 21.32.38 # i think you need to hold the left arrow key right after you have reset it 21.32.59 # oh so prob like left is one OS and right is the other? 21.34.18 # no, it starts rockbox if you do nothing. and if you press the left arrow key it starts the apple firmware 21.34.44 # Digital_Pioneer: is it a fuze v1 or a v2? 21.34.47 # banzairun: please see the manual -> turn on Hold switch immediately after turn on. 21.34.51 # ok how disappointing tho... was hoping for ipod install0us :) 21.35.04 # Buschel: ooops, then i mixed them up ;-) 21.36.32 # Farthen: Pretty sure it's a v1, it just calls itself a Fuze. 21.38.03 # look at the OF version, it must be 1.xx.xx 21.38.11 # Digital_Pioneer: then i'd suggeset to just follow the manual here: http://download.rockbox.org/daily/manual/rockbox-sansafuze.pdf 21.39.36 # Digital_Pioneer: I highly recommend you to use our automated installer, Rockbox Utility, instead of downloading a suspicious package from someone 21.40.59 Quit gill0r_ (Remote host closed the connection) 21.41.11 Join gill0r [0] (~gill0r@f055214210.adsl.alicedsl.de) 21.42.37 # bluebroth3r: To build rbutil I do qmake, make inside the rbutilqt directory yes? As I'm getting the same errors as http://forums.rockbox.org/index.php?topic=23932.0 (I'm also on Arch) 21.43.57 # Or anyone else who has any ideas (domonoky?) :) 21.44.03 # kugel: It doesn't run. Something about a libpng? 21.44.35 # New commit by 03Domonoky (r25094): try to fix checkwps again. 21.44.55 # AlexP: Yup, same thing here. Arch. 21.45.14 # what are other eabi blockers? testing all codecs/plugins, testing all platforms, or at least all cpu architecture+version? 21.46.03 Quit gill0r (Remote host closed the connection) 21.47.50 # AlexP: hm, it misses some speex symbols. do you have libspeex-dev installed on this machine ? ( the rbspeex makefile can use both, system speex and rockboxs own) 21.48.18 # arch doesn't do -dev packages, everything is included in the same package 21.48.29 # i.e. libusb is both libusb and libusb-dev 21.48.50 # I have various speek things in /usr/lib 21.48.53 # *speex 21.49.09 # But it looks like the Arch speex package is incomplete? 21.49.12 # you could try if you can build rbspeex itself successfully. 21.49.13 Quit bluebroth3r (Ping timeout: 246 seconds) 21.49.36 # OK, I'll try to build rbspeex 21.49.58 # I built rbspeex no problem, but what then? 21.50.17 # Unhelpful: Bootloaders need to be checked for all targets affected too. 21.50.32 # domonoky: Yes, rbspeex builds fine 21.50.53 Join bluebrother [0] (~dom@g224239027.adsl.alicedsl.de) 21.50.53 Quit bluebrother (Changing host) 21.50.53 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 21.52.34 # other things to check: does the rbspeex.a really miss the symbols ? and you could try to modify the rbspeex Makefile to always use rockboxs speex lib, and try building rbutil again. 21.52.44 # Llorean: that's scary on targets with crap recovery :/ 21.53.26 # Unhelpful: I think it's mostly been tested on those already 21.53.40 # domonoky: The rbutil makefile? 21.54.06 # amiconn: here? what does your triton and jupiter clients say? they are bouncing. 21.54.14 # AlexP: no the rbspeex makefile. rbutil just calls that to create the .a file. 21.54.21 # ah, OK 21.54.48 Quit shaggy-h () 21.55.18 # make sure to clean both rbutil and rbspeex before rebuilding :-) 21.57.12 # Zagor: "2010-03-09 21:56:45 HELLO failed: error duplicate name!" 21.57.15 # AlexP: rbutil is on AUR, trying -svn now. 21.57.21 # ...over and over 21.57.29 # Digital_Pioneer: Interesting 21.57.59 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 21.58.17 # amiconn: that's so strange. on my side it says "Disconnect: client jupiter-amiconn reason connection lost" 21.58.28 # Unhelpful: so, now to fix doom :'( 22.00.59 Quit Strife89 (Quit: Going home.) 22.01.01 # kugel: The glitch was occasional "defective" macroblocks 22.01.33 # But it does indeed look like it was just a glitch. Works fine in another test after a full rebuild 22.01.45 # I don't see any glitches on e200/fuze 22.02.02 Join Altreus [0] (~al@p4-10018.uk2net.com) 22.02.26 # help! My ipodpatcher tells me "Firmware partition doesn't contain Apple copyright, aborting." 22.02.39 # Is there a way I can tell it to do it anyway? 22.02.44 # have you installed ipodlinux or something weird like that? 22.02.54 Quit Buschel (Ping timeout: 276 seconds) 22.02.54 # no, that's what I was trying to do in the first place 22.03.04 # what ipod? 22.03.08 # 1g mini 22.03.26 # you could try a restore with itunes, that will fix the partitions if they're screwed up 22.03.43 # I don't have itunes, or even Windows or a Mac 22.04.05 # The ipod is older than all the computers that have ever been used to access it 22.04.12 # none of which exists any more :( 22.04.34 # banzairun - to reboot into the Apple firmware, you put the Hold switch to 'Hold' immediately after turning it on. (pressing left - that won't work - on an ipod 5.5g anyway) 22.05.00 # Zagor: I wonder how the client script managed to get into this state 22.05.18 # Altreus: theres instructions for manually restoring an ipod on the wiki, search there 22.05.22 # Doesn't seem the first time that this happens, and also not just on my boxes 22.05.27 # thanks, I'll try 22.08.00 Quit stripwax (Quit: http://miranda-im.org) 22.11.38 Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) 22.11.43 # saratoga: It worked! Thanks for pointing that out :) 22.11.50 Quit bmbl (Ping timeout: 245 seconds) 22.11.54 # no problem 22.12.36 # AlexP: Any luck? 22.12.57 # Digital_Pioneer: nope, but I am poking around in the dark, so that isn't surprising :) 22.13.01 # :) 22.13.35 # Digital_Pioneer: i don't know why you couldn't use rbutil, but theres still the command line utils 22.15.50 Join endlesswonder [0] (~chris3o3@c-24-118-138-250.hsd1.mn.comcast.net) 22.16.02 # why no support for Classic v6? 22.16.26 # encryption has only just been broken, nobody has done the huge amount of reverse engineering work needed 22.16.37 # is there a tool for Classic to be able to navigate by the Folders you have the Songs on your PC? 22.16.55 # Don't know, but that isn't a Rockbox question 22.17.18 # doing a search for each single file is not all that intuitive nor quick 22.17.38 # I understand, but this is an on-topic channel :) 22.17.42 # esp. if you have a LOT of songs in different folders, that are not organized into albums by iTunes 22.18.40 # i mean come on now - just place my damn songs on the iPod as I originally had them on my PC! 22.18.57 # i went thru the meticulous time consuming effort to organize them via folers 22.19.28 # New commit by 03Domonoky (r25095): try to fix search feature. 22.19.42 # endlesswonder: if you just want to chat, checkout rockbox-community 22.19.47 # thats the offtopic channel 22.19.49 # yes 22.19.50 Quit efyx_ (Remote host closed the connection) 22.20.24 # yay now I have an ipod that refuses to work until I give it mains power 22.20.37 # keep things as simple as possible 22.20.42 # but no simpler 22.21.01 # unfortunately programmers get the idea adding fancy features & graphics, makes everyone happier 22.21.14 # That's not programmers. that's managers. 22.21.44 # functionality and making things seen and unseen for the purpose and user's preference makes for far more Happy people. 22.21.46 # endlesswonder: Please, stay on topic 22.21.52 # i.e. stop 22.22.10 # * scorche settles down to get some GSoC stuff hammered out 22.22.21 # ah, good work 22.22.31 # great, looking forward to GSOC this year 22.23.14 # i doubt anyone would be a better software designer than me 22.23.24 # this is not just fluff 22.23.25 # ;) 22.24.02 # endlesswonder: For the last time - #rockbox-community for chat 22.28.02 # gevaerts, ping 22.28.17 # or domonoky 22.28.39 # pong 22.28.44 Quit arbingordon (Quit: `) 22.29.07 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) 22.29.12 # i acn't remember who but it ws about removing my basic blue/black art themes aqs the original author has upped his. 22.29.17 # cant* 22.31.57 Quit Marctraider () 22.32.19 # New commit by 03zagor (r25096): Build failure blocks are lifted after 10 minues. 22.38.18 # New commit by 03Domonoky (r25097): dont show themes multiple times. 22.39.41 # Stephen__: done 22.39.49 # thanks domonoky 22.43.01 # Devs: Please help this page out: http://www.rockbox.org/wiki/SummerOfCode2010 22.46.53 Join Casainho [0] (~chatzilla@87.196.110.217) 22.47.23 # Bleh. For some reason eabi gcc doesn't build on opensolaris because 'patch' cannot find the files to patch?! 22.47.56 # The patch works the same way as the gcc patches for other toolchains, so I wonder why 22.50.01 # amiconn: maybe it doesn't accept/handle -p1 ? 22.50.14 # the eabi patch was made against 4.4.2 22.50.44 # It does so for m68k, sh, and plain arm 22.51.10 # maybe it still looks at the patch paths (it says gcc-4.4.2 in the diff) 22.51.35 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 22.51.54 # funman, Torne: is there a way to get the fault address on arm7tdmi as well= 22.51.55 # ? 22.54.55 Join karashata [0] (~karashata@74-220-162-11.wightman.ca) 22.55.05 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.58.51 Nick krazykit` is now known as krazykit (~kkit@ppp-70-225-142-162.dsl.ipltin.ameritech.net) 22.59.00 *** Saving seen data "./dancer.seen" 23.02.24 # kugel: no 23.02.44 # kugel: it's possible there is on PP, but I don't know of one 23.02.48 # kugel: the cache controller might know it 23.03.21 # I doubt it 23.03.22 # but in general, no, ARMs have no way to know the address which caused the abort if they don't have an mmu/mpu 23.03.44 Quit Tuplis (Read error: Operation timed out) 23.03.52 # kugel: i only said we should *test* doom! 23.05.07 # the regs are untouched by the handlers or mode switching? 23.06.04 # kugel: hm? 23.06.25 # well could I hack something together if I know the reg where the address is in? 23.06.35 # you could just dump theuser mode registers, sure 23.06.46 # but i expect we either stack or overwrite several of them :) 23.06.49 # otherwise you can't get to the handler 23.07.40 # I want to know what r4 contains 23.08.13 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.08.18 # * amiconn *hates* this beast usb bug 23.10.22 # kugel: well, we don't save any registers, and they will most/all have been overwritten by the time you get to UIE 23.10.57 # if you want to handle exceptions properly the thing to do is push all the user registers onto the abort mode stack and pass a pointer to UIE 23.11.21 # On the beast doom just crashes with eabi 23.12.27 # Hmm, different problem this time... 23.13.13 Quit kugel (Ping timeout: 246 seconds) 23.13.22 Quit DerPapst (Quit: Leaving.) 23.14.03 Quit Digital_Pioneer (Ping timeout: 268 seconds) 23.20.34 # Hmm, opensolaris 'patch' fails if the patch file is a multi-file patch 23.20.35 Join Digital_Pioneer [0] (~nathan@adsl-99-59-248-52.dsl.ltrkar.sbcglobal.net) 23.21.15 # * amiconn wonders how his sh patch worked back when he created it 23.21.18 Quit hebz0rl (Quit: Ex-Chat) 23.21.38 Quit tvelocity (Quit: Αποχώρησε) 23.25.06 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.26.11 Quit Casainho (Ping timeout: 264 seconds) 23.34.49 # Unhelpful: I'm getting unaligned access in M_LoadDefaults() 23.35.20 # on this line: *defaults[i].location.pi = defaults[i].defaultvalue.i; (the lhs is unaliged) 23.36.48 Quit alexbobp (Ping timeout: 248 seconds) 23.37.52 Quit Stephen__ (Ping timeout: 260 seconds) 23.38.34 # defaults is a static array, that's why its strange 23.40.50 # ghah! This is another gnu vs. non-gnu problem 23.41.01 # It works when using 'gpatch' instead of 'patch' 23.41.18 Join Marctraider [0] (~marctraid@82-170-60-93.ip.telfort.nl) 23.42.13 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.42.18 # amiconn: does doom start on the beast and an eabi build? 23.42.34 # Yes, it starts, but then fails 23.42.53 # It hangs after some time (time varies), then powers off 23.43.17 # If it runs long enough to start the demo animation, there are graphis errors 23.44.48 Quit planetbeing__ (Ping timeout: 264 seconds) 23.45.48 Join Stephen__ [0] (~S@86.45.50.221) 23.45.48 Quit jgarvey (Quit: Leaving) 23.46.40 Join Hillshum [0] (~hillshum@75-165-226-200.slkc.qwest.net) 23.47.53 Quit stripwax (Quit: http://miranda-im.org) 23.48.24 Quit evilnick_B (Quit: Page closed) 23.48.26 # data abort as soon as I select the difficulty (after executing the .wad). on my e200 it creases as soon as doom.rock launches 23.48.34 # crashes* 23.49.52 # I think the reason is probably the same 23.50.20 # Data aborts might be disabled on the beast, so unaligned accesses don't crash, but they still give wrong results 23.50.49 Quit piotrekm (Quit: piotrekm) 23.51.04 # wait what? 23.51.19 # unaligned reads work on armv6 23.51.27 # They do? 23.51.47 # Yes, if you disable alignment aborts it does them properly, with multiple cache accesses 23.52.04 # Ah, hmm 23.52.12 # we shouldn't disbale alignment aborts, though ;) 23.52.20 # since it's still slower 23.52.25 # and code that works that way won't work on other chips 23.52.42 # On earlier arms which allow disabling that check, unaligned accesses work, but not the way one would expect 23.52.52 # Yes, they rotate the aligned word 23.52.58 # but armv6 and later do it properly 23.52.59 Quit Zagor (Quit: Clint excited) 23.53.32 # Then there much be another problem. They're probably related though 23.53.38 # s/much/must/ 23.54.16 # err, only the first array element is unaligned 23.54.56 # * kugel likes that doom has printf() :)