--- Log for 30.05.110 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 8 hours ago 00.01.48 # wodz: fuze would do it ? 220x176 00.02.24 *** Saving seen data "./dancer.seen" 00.04.38 # yes 00.05.57 # * jae wishes he still had his Fuze... but he's happy seeing that v2 is coming along nicely (right?) 00.06.18 # funman: to speedup testing You can increase log rate in powermgmt.c 00.06.58 # thanks 00.08.47 # i changed 60*HZ to just HZ line 690, is that enough? 00.08.54 # no 00.09.07 # 722 also 00.09.38 Quit pamaury (Quit: exit(rand());) 00.10.41 Quit slck (Ping timeout: 260 seconds) 00.12.06 # looks fine 00.13.04 # cool 00.14.39 # funman: isn't such line to thin for You? 00.15.03 # hm it's visible enough i think 00.16.26 # I was thinking of adding some grid also but honestly I have no idea how to setup portably light gray lines 00.17.02 Join slck [0] (Venci@Slackware.SlackPix.Com) 00.17.11 Quit Soap_Hotel (Quit: CGI:IRC (Ping timeout)) 00.18.09 # a grid? 00.18.52 # yes like gnuplot can do for example 00.19.18 # it is easier to see abolute values than 00.19.40 # are values really important? i use this screen to see if it's increasing or decreasing 00.20.52 # because it is autoscaled I would like to see at first glance if values changes much or only slightly 00.21.14 Join Soap_Hotel [0] (www-data@giant.haxx.se) 00.21.37 # perhaps just make the grid 1pixel and the line wider 00.22.33 # making line wider is not so easy I am afraid 00.24.12 # but maybe ploting copy of the curve shifted 1px down will be enough 00.24.27 Quit bmbl (Quit: Bye!) 00.29.26 Join TillW [0] (~Till@CPE0018395fb63b-CM00195ee38f2c.cpe.net.cable.rogers.com) 00.33.43 Quit TillW (Client Quit) 00.35.41 # % grep -E 'ldm.*pc' .|wc -l 102 00.36.01 # some of them are not run on armv4 so they are ok 00.38.21 Quit kramer3d (Ping timeout: 260 seconds) 00.40.13 Quit orzech (Ping timeout: 248 seconds) 00.41.32 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 00.42.07 Join orzech [0] (~orzech@elj74.internetdsl.tpnet.pl) 00.42.25 # JdGordon: the patch needs more work, it goes wrong if the system boots with sysfont and then the user selects a font later (it will try to bufalloc then which is bad) 00.42.33 # JdGordon: also the min/max values should be tweaked 00.42.56 # New commit by 03funman (r26399): fuze*/e200v2 YUV lcd code: remove a useless instruction forgotten in r21795 00.43.20 # is there some reason to update the bootloader on fuzev1 if it hasn't been built recently (like last year) 00.43.35 # no 00.43.59 Join kramer3d [0] (~kramer@ip98-169-198-182.dc.dc.cox.net) 00.44.01 Quit kramer3d (Changing host) 00.44.01 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 00.44.54 # does anyone know how much ram the Clip/Clip + has? 00.46.40 # where did tools/configure go? 00.46.45 Join robin0800 [0] (~quassel@149.254.61.40) 00.47.22 # r0b-: 2MB+384kB iram for the v1, 8MB+1MB iram for others 00.47.26 # tmzt: never moved 00.47.52 # weird 00.48.04 # i know the Clip's cannot play Doom :P 00.48.09 # damn 3 color LCD 00.48.13 # 2 Color 00.48.14 # it failed to build, I ran make clean and now the tools directory is gone 00.48.25 # r0b-: while you're correcting, it's not an LCD 00.48.32 # oLED 00.49.29 # JdGordon: i'll look at it soon maybe, i have some beast stuff to fix as well tho. 00.50.06 Quit wodz (Quit: Leaving) 00.53.34 Quit robin0800 (Remote host closed the connection) 00.53.47 Quit aevin (Ping timeout: 240 seconds) 00.54.03 Join robin0800 [0] (~quassel@149.254.61.40) 00.58.35 Join evilnick__ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 00.59.56 # The AAPCS requires that all sub-routine call and return sequences support inter-working between ARM and 00.59.59 # Thumb states. 01.02.02 Quit evilnick_ (Ping timeout: 265 seconds) 01.04.41 Quit saratoga (Changing host) 01.04.41 Join saratoga [0] (~9803c6dd@rockbox/developer/saratoga) 01.10.30 Quit funman (Quit: free(random());) 01.10.48 # wb saratoga 01.12.06 Quit ender` (Quit: In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.) 01.16.02 # Tuesday is the 8 year anniversary of Rockbox 1.0 01.17.29 # We'll have to celebrate! 01.21.01 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 01.22.24 Quit whydoubt (Read error: Operation timed out) 01.22.29 Join whydoubt [0] (~whydoubt@ip68-12-76-9.ok.ok.cox.net) 01.28.38 Quit orzech (Ping timeout: 260 seconds) 01.30.12 Join orzech [0] (~orzech@elj74.internetdsl.tpnet.pl) 01.32.59 # by porting rockbox 1.0 to all current targets? 01.33.47 Quit petur (Quit: Zzzzz) 01.35.02 Quit halmi (Read error: Connection reset by peer) 01.42.48 Quit slck (Ping timeout: 276 seconds) 01.42.50 Join slck [0] (Venci@Slackware.SlackPix.Com) 01.45.58 Quit Soap_Hotel (Quit: CGI:IRC (Ping timeout)) 01.51.03 Quit pyther (Quit: Lost terminal) 01.51.23 Quit bertrik (Ping timeout: 245 seconds) 01.53.20 Quit DataGhost (Ping timeout: 240 seconds) 01.55.01 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 02.01.26 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.188) 02.02.28 *** Saving seen data "./dancer.seen" 02.12.00 # funman: you'd mentioned being able to adjust the display clock on clip... is this the actual rate at which the display refreshes? and could we maybe temporarily make it *faster*? 02.16.58 Quit shodan45 (Remote host closed the connection) 02.17.21 Join shodan45 [0] (~chris@adsl-068-212-080-078.sip.msy.bellsouth.net) 02.26.40 Quit efyx_ (Remote host closed the connection) 02.28.46 Nick keanu is now known as [keanu] (~keanu@unaffiliated/keanu) 02.36.46 Quit wincent (Ping timeout: 260 seconds) 02.44.24 Quit robin0800 (Remote host closed the connection) 02.50.15 Nick kramer3d is now known as kramnap (~kramer@unaffiliated/kramer3d) 03.05.56 Quit domonoky1 (Read error: Connection reset by peer) 03.13.53 # OK, as it seems we could have found a difference between the FuzeV2s that allow RB firmware. 03.15.13 Join steve|m1 [0] (~steve@p4FD477C3.dip.t-dialin.net) 03.15.17 # http://forums.rockbox.org/index.php?topic=14064.msg167552#msg167552 03.17.28 # Rob2223: since the model number doesn't even tell you if you get a v1 or v2 player, I doubt it tells you about some minor change to the frimware update 03.18.03 Quit steve|m (Ping timeout: 276 seconds) 03.18.32 Quit steve|m1 (Client Quit) 03.18.38 # hmm, I just wonder how much different model numbers are out there!? 03.18.53 Join steve|m [0] (~steve@p4FD477C3.dip.t-dialin.net) 03.18.54 # probably a lot 03.19.54 # well i asked a third person with the problem 03.20.00 # hope i get an answer 03.20.08 # New commit by 03bieber (r26400): Themeditor: Got the ParseTreeNode class in good shape, preparing to start on ParseTreeModel 03.21.07 # your best bet is probably to figure out what changed in the firmware files 03.21.28 # thats just not easy 03.21.32 # a already tried 03.21.36 # yes but its actually useful 03.22.05 # even if the serial numbers do mean something its not clear to me how that helps at all 03.22.36 # when i return my brand new player i would like to get a player that accepts RB in the 2nd try 03.22.51 # i only bought it for RB so i will retuen it in 10 days 03.23.01 # as long i have the chance to 03.23.01 # bieber: hey, is there an easyish way to get a nice debug output for a skin with your parser? 03.24.06 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 03.24.13 # If you stick a skin_debug_tree(test) in main.cpp it'll give you the ASCII debug info 03.24.13 # Hopefully in a few minutes here I'll have a Qt treeview working 03.26.18 # cool 03.26.38 # also did you see my qeustion last night? 03.27.22 # The one about using skin instead of WPS? 03.27.27 # yeah 03.27.43 # Yeah, I'm pretty sure that's taken care of now 03.27.53 # It was just in ParseTreeModel.h/cpp, right? 03.27.55 # great :) 03.28.11 # possibly, I saw it in one of the .h's 03.28.22 # Okay, it should be clear 03.29.02 # still WPS in the comment 03.29.08 # parsetreemodel.h 03.29.12 Quit merbanan (Read error: Operation timed out) 03.30.52 # saratoga: I fear that the new check has something to do with the hardware or some code that is already in the players. Cause the same .33 files working for some players and for some they dont :( 03.31.37 # Thanks, got it 03.33.14 # Rob2223: maybe the update depends on some code on the AMS ROM, and that got updated in newer players 03.34.44 # they might have run out of the original run of AMS chips and had to order another batch or something from the fab 03.35.48 # hmm 03.35.59 # and they tooks the chance for a rom upgrade?! 03.36.19 # do you know if the AMS rom is used by the player? 03.37.51 # i assume its used to load the firmware file off the flash memory 03.38.12 # theres no other memory on the device, so i don't know what else could load the firmware 03.38.35 # are there not files on a hidden partition? 03.39.14 Join moparx [0] (~moparx@unaffiliated/moparx) 03.39.18 # i mean is the original firmware from a firmware upgrade file the only data in the hidden space?! 03.39.38 # i didnt found any information about that 03.40.37 # none of this is in a partition 03.40.47 # the ROM is memory mapped 03.41.15 # the as3525 datasheet explains how it works on the fuze/clipv1, probably not much different on the clip+ 03.41.19 # well ok, maybe bad word coice from me. the area to where the file is flashed at the firmware upgrade process 03.41.50 # couldnt there be other files/data? 03.42.21 # yeah i think i know the memory mapped procedure 03.43.04 # i thought the firmware is flashed onto a hidden part of the 2GB memory 03.43.18 # is it flashed into the SOC rom? 03.43.41 # as I said above, its loaded from the NAND 03.44.35 # unless the NAND can be memory mapped, its probably copied into RAM by whatever code is already on the ROM 03.45.09 # so the nand is the 2gb/4gb/8gb chip, right? 03.45.24 # yes, NAND is a type of flash memory 03.46.02 # so the firmware upgrade copies the fusp.bin forom the fat partinioned part of the NAD to another area of the nand thats not in the FAT partition 03.46.16 # yup 03.46.24 # (sorry for my grammar, im already damn tired) 03.46.44 # to at the hidden place of the nand could be some more information 03.47.09 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 03.47.17 # or maybe even the firmware upgrade routine could be thare and it did never get touched by the firmware upgrade process 03.47.23 # AFAIK the hidden part is a verbatim copy of the firmware bin, at least on the V1 players 03.47.24 # *there 03.47.32 # not sure if anyone ever dumped it on the newer devices 03.47.37 # New commit by 03bieber (r26401): Theme Editor: Got a barely functional treeview in place 03.47.53 # bieber: at a high level, how does the parse tree get new branches? 03.48.12 # or, whats the breakdown? 03.48.17 # JdGordon: Okay, now it displays the file in a treeview. The formatting sucks atm, but that'll get better when I have some more time to work on it 03.48.48 # S_a_i_n_t: Sorry, I haven't even tried to do a eabi toolchain on Cygwin. I guess it's possible but I just have a "stock" install. Well, I also added Python for analysis scripts, but the rest is standard. 03.48.48 # At the highest level, everything gets broken down into either a SUBLINES branch or a LINE branch 03.48.58 # if that were for the V2, too, then the code that rejects newer firmware must be in the .33 firmware upgrade anywhere. 03.49.42 # S_a_i_n_t: for that matter I'm not really sure what eabi is, so I'm probably not the guy to ask. :) 03.49.51 # Also, while looking over the stuff from the treeview, I just noticed another bug in my parser. Apparently when scanning for sublines, it's stopping any time it encounters a newline, even if it's at the end of a comment 03.49.53 # saratoga: my only ida atm would be disassemble the FW and trying to analyze it but even if i am able to read assembler i dont think that i will find that part :( 03.50.06 # bieber: ok, viewports actually need to be the hieghest level 03.50.41 # i think comparing the firmware files is probably easier 03.50.42 # is that going to be difficult without giving the parser too much knowledge about what a viewport is? 03.50.56 # if you figure out whats different it doesn't matter how the firmware update is implemented 03.51.38 # That would really be beyond the realm of the parser, since at that point you're dividing things up according to the way the renderer will interpret it, rather than just the semantic structure of the document 03.51.40 # bieber: also (a request only) can #( and #) or )# be added for multi line comments? 03.52.01 # Multi-line comments will be easy 03.52.18 # saratoga: the problem is from .28/.31 to .33 are many differences in the firmware file. 03.52.45 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 03.52.52 # yes but you only care about changes to the header 03.53.13 # bieber: I'd still argue that the document structure goes viewport > line > subline 03.53.17 # remove the firmware bits and compare whats left 03.53.26 # maybe it is not obvious because the defualt viewport isnt put into the document 03.53.54 # So %V tags can never be conditional, and they can always be viewed as marking a new section of the document? 03.54.31 # yes, but that include %Vi and %Vl... maybe add a char to the param list saying "start a new top level node"? 03.54.41 # saratoga: theres no change in the header to 0x400 but the checksums :( 03.55.05 # JdGordon: If it's just those three cases, I can hardcode it easy enough 03.55.27 # that would work also :) I was just thinking more for keeping the parser very generic 03.55.44 # saratoga: have .31 to 33. open on right screen and .28 to .33 open on left screen. i already compared the header today 03.56.52 # New commit by 03bieber (r26402): Theme Editor: Fixed parsing bug that allowed comments to form a new logical line in a skin document 03.57.15 # Rob2223: did you try dumping firmware libraries and looking at whatever was left? 03.57.29 # perhaps theres more to the header then just the first 0x400 bytes 03.58.00 # since older players can still take this upgrade files, i assume the header didn't change much, but that doesn't mean they didn't add another header somewhere further back 03.58.05 # is there a tool for? 03.58.14 # i just compared the .bin binary 03.58.23 # you haven't actually dumped one of the bin files? 03.59.07 # utils\AMS\hacking\amsinfo 03.59.10 # JdGordon: I'll have it divide documents up by viewports whenever I have a chance to code some more, it shouldn't take me long 03.59.11 # no i compared the fuzpa.bins 03.59.30 Quit DerPapst (Quit: Leaving.) 04.00.08 # saratoga: you didnt have a compiled win26/64 version at hand, or? 04.00.11 # you'll probably want to look at the amsinfo tool's parser to get a feel for how the file works 04.00.57 # yeah, good idea. i read all i could found until now 04.01.01 # f.e. http://daniel.haxx.se/sansa/ams.html 04.01.36 # saratoga: have you a compiler chain set up? 04.01.53 # i don't know how to compile stuff for windows, and since you'll have to change the code anyway i'm not sure how much use a binary would be 04.02.12 # bieber: sweet, and please remember to add the default node so if the first non comment isnt %V it will still work as expected 04.02.32 *** Saving seen data "./dancer.seen" 04.02.58 # Got it 04.10.49 Quit GeekShadow (Ping timeout: 264 seconds) 04.15.05 Join JdGord [0] (~jd@110.23.121.142) 04.18.27 Quit orzech (Ping timeout: 260 seconds) 04.19.10 # saratoga: i just compiled it with a gcc windows version i had, but i just get "ERROR: reading firmware: No error" when im trying to dump .33. may i ask why you sayed i _have_ to modify the source? hope i didnt bother you 04.19.52 # Rob2223: well if the tool already knew what the difference between the firmware files was, you probably wouldn't be having this problem 04.21.04 # it doesnt dump the older 02.01.17 either. but i see what you say. 04.22.51 # Rob2223: it works for me 04.23.47 # then my compilation is bad :( 04.24.03 # wth... 04.24.17 # or a windows issue 04.25.16 Quit moparx (Ping timeout: 276 seconds) 04.29.48 Join Thetorminator [0] (www-data@giant.haxx.se) 04.31.19 Quit Thetorminator (Client Quit) 04.32.26 # New commit by 03jdgordon (r26403): zip up the output after doing all the skins 04.32.45 # New commit by 03jdgordon (r26404): and woops 04.36.19 # saratoga: ill give up for now. i dont see why it compiles without error but just doesnt work. but im over-tired. too. will try tomorrow under linux. but thx for your help 04.36.21 # skimming the amsinfo output, theres an extra 100KB (exactly) of "unknown" blocks 04.36.35 # it may not actually run on Windows 04.37.10 # could you zip/rar me a dup of .28 .31 .33 taht i could check the diff? 04.37.52 # ah well, dont want to bother, i hope it runs under kubuntu 04.38.54 # heh if I edit the tool to dump the unknowns i get about 5000 512 byte files 04.39.13 # i guess figuring out how the blocks fit together into files would be helpful 04.39.22 Quit Barahir_ (Ping timeout: 265 seconds) 04.39.32 # ow 04.40.35 Join Barahir [0] (~jonathan@frnk-590fdc4a.pool.mediaWays.net) 04.40.46 # well, assuming these blocks have the same sequence and the same filename i could compare them with total commander directory sync. 04.40.55 # ok i bet linux has something like that, too 04.41.40 Quit amiconn (Disconnected by services) 04.41.42 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.42.04 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.42.34 Quit pixelma (Disconnected by services) 04.42.36 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.42.55 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.44.23 # saratoga: are you still on this? i have to go to bed. 04.45.04 # i'm working on something else now 04.45.18 # ok. then thx for help :) 04.56.48 # grrrr 05.00.26 # bieber: is tag_table.[ch] technically outside of the parser? the reason I ask is because I want to add a bunch of info to that struct which is only really relevant to the actual build (not the theme editor or parser in general) 05.02.19 # the extra info will make tag_table.c more annoying for you, but if a tag is ever added or changed it means only fiddling with one place to make the changed tag acpeted everywhere 05.07.22 # this is even ignoring the fact that some tags are target dependant...which I guess makes perfect sense to keep ignorin 05.07.23 # g 05.32.30 Nick kramnap is now known as kramer3d (~kramer@unaffiliated/kramer3d) 05.37.11 Quit [CGL] (Ping timeout: 245 seconds) 05.41.12 Join [CGL] [0] (~CGL@190.207.226.198) 05.45.35 Quit Battousai (Remote host closed the connection) 05.45.48 Join Battousai [0] (~bryan@gentoo/developer/battousai) 05.47.40 # bieber: FS#11333 05.52.31 Join SliMM2 [0] (~SliMM@nat67.mia.three.co.uk) 05.55.04 # Hello. 05.55.04 # What are the key mappings of the Spectrum emulator on an iPod? 05.57.18 Quit Battousai (Quit: No Ping reply in 180 seconds.) 05.58.12 Join Battousai [0] (~bryan@gentoo/developer/battousai) 06.02.36 *** Saving seen data "./dancer.seen" 06.06.51 Join Leanne [0] (~Leanne@CPE00259ce0fdb2-CM0014f8cc807a.cpe.net.cable.rogers.com) 06.10.59 Quit SliMM2 (Quit: SliMM2) 06.56.48 Quit JdGord (Quit: Bye) 07.05.01 Quit Horscht (Ping timeout: 240 seconds) 07.06.25 # funman: (for the logs) someone else reported their clip dying when they installed rockbox (using rbutil), do you have a theory about that? 07.06.31 # this one was also a clipv2 07.09.03 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.09.35 # hey so even if I use rockbox utility for mac....the ipod has to be formatted for windows to make it work? 07.16.08 Quit shodan45 (Remote host closed the connection) 07.24.58 Part toffe82 07.25.59 # Leanne: the ipod has to be formatted as FAT. it's the only filesystem rockbox knows. 07.38.58 Quit Leanne (Ping timeout: 258 seconds) 07.46.48 # JdGordon: It shouldn't be any problem at all, since I'm just using a function to look up info from the table and pick out the field I need for the parser 07.47.19 # cool :) 07.51.53 # New commit by 03bieber (r26405): Applied JdGordon's patch to add tokens to the Theme Editor tag table 07.56.11 Quit JdGordon (Quit: Leaving.) 08.00.04 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 08.02.40 *** Saving seen data "./dancer.seen" 08.02.55 Quit Horscht (Ping timeout: 260 seconds) 08.07.52 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 08.12.15 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.27.05 Join ucchan [0] (~ucchan@softbank126102044027.bbtec.net) 08.29.37 # S_a_i_n_t: both binutils and gcc (arm-elf-ebmi) build success on my cygwin ! 08.31.29 Join Leanne [0] (~Leanne@CPE00259ce0fdb2-CM0014f8cc807a.cpe.net.cable.rogers.com) 08.32.30 # The reason for the problem of INCLUDE_PATH (not find ) is that the setting of my window's native PATH was broken. 08.32.34 Quit kramer3d (Quit: Leaving) 08.34.37 # Then binutils and arm-elf-gcc-ebmi were normally created without changing rockboxdev.sh. 08.37.03 # how do I tell what gen my ipod classic is? 08.37.19 # actually....can any ipod classic use rockbox? or all of them are no dice? 08.45.22 Quit r0b- (Ping timeout: 264 seconds) 08.45.26 Join vaguerant [0] (~vaguerant@CPE-58-175-76-199.dqzk1.lon.bigpond.net.au) 08.45.31 Quit vaguerant (Changing host) 08.45.32 Join vaguerant [0] (~vaguerant@wikipedia/vague-rant) 08.46.26 Quit Leanne (Ping timeout: 258 seconds) 08.46.48 Join r0b- [0] (~nnscript@adsl-76-235-218-36.dsl.klmzmi.sbcglobal.net) 08.49.16 # Kind of a dumb question re: RoLo; does it just boot original firmwares renamed with an appropriate extension? 08.49.57 # So like clppa.bin from SanDisk (the Clip+ firmware) renamed to ANYTHING.sansa for booting on Clip+? 08.50.28 # i don't think thats going to work 08.51.02 # AFAIK we don't actually have code to load the OF images into RAM, we always let the sandisk software do that 08.53.14 # it might work.. unlikely though 08.54.46 # you'd probably have to setup memory correctly for it too 08.54.53 Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) 09.01.50 Quit JdGordon (Ping timeout: 240 seconds) 09.04.51 Join Rob2222 [0] (~Miranda@p4FDC9BB0.dip.t-dialin.net) 09.08.01 Quit Rob2223 (Ping timeout: 245 seconds) 09.14.10 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.19.35 # ucchan: I am glad you managed to get it working, my windows native PATH is as it should be, I tried to build arm-elf-eabi last night...and fell asleep, when I woke up it had failed. :'( 09.20.27 # On kugel's suggestion I'm trying to build eabi by modifyine line 29 of rockboxdev.sh to "make" instead of "make -j4" 09.20.45 # seems promising so far, it got further than it did last night ;) 09.21.07 # s/modifyine/modifying/ 09.23.46 # crap! 09.23.57 # It just failed to build again... 09.23.59 # cygwin 1.7's packages are downloding now. maybe tomorrow, I can try build on cygwin 1.7. 09.25.15 # ucchan: My eabi build just failed again...I really don;t know much about this, other than it's breaking and I don't know how to fix it. 09.27.56 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.28.21 Join BHSPitMini [0] (~BHSPitMon@adsl-66-140-45-134.dsl.rcsntx.swbell.net) 09.29.01 # If anyone wants to look at my arm-elf-eabi build errors: http://pastebin.org/291879 09.29.02 # Cygwin 1.5 and 1.7 can be used at the same time. Should install cygwin 1.5 ? 09.29.13 # Any insight would be *greatly* appreciated. 09.30.10 # ucchan: Perhaps I should try that. I'd really like to know why it doesn't work though. 09.30.22 # I don't like things to get the better of me like this. 09.32.03 # wrong cygwin's gcc-4 ? 09.32.16 Join stoffel [0] (~quassel@p57B4C89B.dip.t-dialin.net) 09.34.23 # I'm thinking about just installing ALL of the CygWin-Devel packages...then if it works, narrowing down what I actually need. 09.34.47 # I suspect that the base packages on the Rockbox Cygwin wiki don;t accomodate for eabi 09.35.35 # The packages on download.rockbox.org are from 2006~2007...so, that may well be correct. 09.39.22 # ucchan: Hmmm, pastebin cut the end off my cygwin output 09.39.34 # this is the part where it actually errors 09.39.34 # http://pastebin.org/291895 09.39.44 # does that mean anything to you/anyone? 09.41.51 # ucchan: did you see my email? 09.42.09 # not install libiconv? 09.42.31 # ucchan: checking the cygwin ow. 09.42.34 # *now 09.42.55 # "checking my cygwin packages now" rather 09.43.37 # i finally got my beast back together... not the origional hard disk, im onyl getting a white lcd.. is that normal? 09.46.04 Quit vaguerant (Ping timeout: 260 seconds) 09.51.02 Quit JdGordon (Quit: Leaving.) 09.51.06 # I installed cygwin 1.7 packages. I try build binutils and gcc-arm-elf-eabi on cygwin 1.7. 09.51.32 Join DerPapst [0] (~Alexander@p4FE8F365.dip.t-dialin.net) 09.51.58 # ucchan: Could you just try running rockboxdev.sh and see if that fails for you also? 09.52.04 # it would be really good to know 09.52.13 # it's OK if you'd rather not though. 09.52.23 Join flydutch [0] (~flydutch@host23-166-dynamic.15-87-r.retail.telecomitalia.it) 09.53.08 # ucchan: By the way, turns out the libiconv wasn't installed. So, I'm trying again. 09.53.44 # I'm making a list of packages the rockbox wiki doesn't include so that if I manage to build arm-elf-eabi toolchain I can update the wiki 09.56.48 Join petur [0] (~petur@rockbox/developer/petur) 09.58.37 Join Akranis [0] (~Akranis@h212n2-vrr-d2.ias.bredband.telia.com) 10.00.55 # Because a necessary package did not suffice, the build has not been done yet. 10.02.44 *** Saving seen data "./dancer.seen" 10.05.50 # I installed libiconv (and it's dependencies)...trying again. 10.06.18 # Building the eabi toolchain on cygwin 1.7 does work 10.06.19 # I'd like to do this (and taking notes as I go) so I can update the wiki at the end of it if I finally get it right. 10.07.00 Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 10.07.00 Quit DataGhost (Changing host) 10.07.00 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 10.07.23 # amiconn: Oh, I'm sure it does...but obviously not if you follow the rockbox wiki dorections. There are obviously packages needed that are not noted. 10.07.38 # You need libmpfr-devel for gcc 4.4 and higher 10.07.46 # On cygwin 1.7 I can even get arm-elf to build using rockboxdev.sh :/ 10.08.04 # *can't 10.08.38 # * amiconn installed cygwin 1.7 on this box back when it was beta 10.09.11 # Even then building the rb toolchains was no problem 10.09.36 # * amiconn isn't using it much these days, because it's so slow 10.13.20 # mpfr can build gcc-3.4.4 (I build yesterday) 10.14.03 Quit Barahir (Ping timeout: 260 seconds) 10.14.07 # sorry noise my comment 10.15.22 Join Barahir [0] (~jonathan@frnk-590ff4d2.pool.mediaWays.net) 10.21.42 # OK...right. Installed libiconv, libmpfr, gmp, and a bizallion dependencies for them...*fingers crossed* 10.22.12 # I start rockboxdev.sh now... 10.22.43 # You don't need a bazillion packages... just libmpfr-devel (+ dependencies) like I said 10.24.30 # the "bazillion" is the dependencies. 10.24.47 # I also needed libiconv according to a previous error it spat at me. 10.25.17 Quit CaptainKwel (Quit: Ex-Chat) 10.25.34 # It'd probably be safer to just instal ALL the devel packages....but I' trying to nut this out to update the wiki. 10.26.15 # I don't have libiconv explicitly on my list 10.26.42 # Maybe it's a dependency of some other package I do install anyway for a rockbox dev envrionment 10.26.52 # http://pastebin.org/291895 10.27.00 # (error from trying to build eabi) 10.27.00 Join ender` [0] (krneki@foo.eternallybored.org) 10.27.02 # * amiconn has a list of just 20 packages 10.27.28 # Of course those will install some more as dependencies 10.28.08 # I've been trying to note everything I've installed so far...but I fear I've missed a few dependencies. 10.28.20 # Which, should be ok as long as I got the main packages. 10.30.38 # http://rockbox.pastebin.ca/1874209 10.34.36 # amiconn: Thanks...I'll see if this build works. Then I'll compare it with my installed packages. 10.35.09 # It may seem a stupid question, but what did you do to output your installed packages like thst? 10.35.20 # I'm guessing you didn't type it out by hand. 10.36.40 # though...not listing dependencies, I'm not sure it'll help much. 10.37.56 Join mischasworld [0] (~quassel@f050226205.adsl.alicedsl.de) 10.44.55 # I did type that list by hand 10.45.43 # It's not the list of installed packages, it's just the list what packages I selected in addition to the default. It also doesn't include dependencies 10.47.33 Join merbanan [0] (~banan@c-94-255-222-11.cust.bredband2.com) 10.48.33 # now binutils build success. 10.58.01 # surely there's a way to get cygwin to output installed packages...but, I can't seem to find it. :/ 11.00.02 Quit merbanan (Ping timeout: 240 seconds) 11.04.49 Join bluebrother [0] (~dom@g226068163.adsl.alicedsl.de) 11.04.49 Quit bluebrother (Changing host) 11.04.49 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.08.01 Quit bluebroth3r (Ping timeout: 252 seconds) 11.19.22 Quit JdGordon1 (Quit: Leaving.) 11.26.10 Join ender1 [0] (krneki@foo.eternallybored.org) 11.26.47 Quit ender` (Disconnected by services) 11.26.52 Nick ender1 is now known as ender` (krneki@foo.eternallybored.org) 11.29.02 Join halmi [0] (~netbook@80-123-32-145.adsl.highway.telekom.at) 11.31.42 Join funman [0] (~fun@rockbox/developer/funman) 11.37.17 # saratoga: no idea what went wrong for his clip 11.40.54 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.41.33 # http://img31.imageshack.us/img31/4421/clipt.png <- building with -mthumb -Os makes no difference for battery life 11.42.29 Quit halmi (Quit: halmi) 11.44.10 # amiconn: what do you think of losing 4 bytes per ASM function and 1 cycle per return on arm7tdmi (no difference on others) to make armv4t able to return to thumb code (change ldm sp!, {...,pc } to ldm sp!, {....,lr} + bx lr ? is that a big deal ? 11.46.58 # I think a #if !defined(THUMB) || ARM_ARCH == 4 would be just too much 11.50.14 Join Buschel [0] (~ab@p54A3A6F3.dip.t-dialin.net) 12.01.12 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 12.02.46 *** Saving seen data "./dancer.seen" 12.04.40 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.08.34 # kugel: using bx in system-arm.h macros reduces ram usage by 2.75kB (if we do that and don't make the macros real functions we can leave them inlined on ARM builds) 12.09.32 # anyone with a Cowon D2 willing to test a patch? 12.10.05 # funman: nice 12.11.02 # i think making them functions will make the code smaller though because there will be just one bl each time they are called 12.11.58 # btw i was expecting some change for battery life (for good or for bad) since memory use is modified but nothing :/ 12.15.02 Quit BHSPitMini (Ping timeout: 240 seconds) 12.15.07 Join JdGord [0] (~jd@110.23.121.142) 12.21.32 # making them functions makes things bigger :? 12.26.07 Quit JdGord (Ping timeout: 252 seconds) 12.27.13 Quit Barahir (Ping timeout: 252 seconds) 12.27.21 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 12.27.41 # ah no, saves 1344 bytes 12.27.58 # ...win 12.28.53 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 12.31.08 Quit ucchan (Ping timeout: 248 seconds) 12.32.18 # New commit by 03bertrik (r26406): Slovak language update ... 12.41.11 # bertrik: are you backporting it to 3.6? 12.41.42 # no 12.43.01 # Is there something wrong with the commit I just did? 12.44.04 # bertrik: language updates should be applied to the branch, too 12.45.09 # kugel: fs#10030.. whats the story? 12.47.03 # I don't know how to do that 12.49.46 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.50.54 # bertrik: svn co the branch, then commit... 12.51.12 # I'm bored so I can do it for you 12.52.40 # New commit by 03jdgordon (r26407): Slovak language update ... 12.52.48 # thanks 13.01.39 # funman: Does thumb actually improve performance? 13.02.09 # AC3 and AAC are a bit faster on armv5 13.02.35 # AAC is among the slowest codecs but AC3 is quite fast 13.02.40 # I am thinking of PP especially 13.02.55 # http://www.rockbox.org/tracker/task/6734?getfile=21994 13.03.05 # i have no PP to test 13.03.18 Join ucchan [0] (~ucchan@softbank126102044027.bbtec.net) 13.03.45 Quit stoffel (Remote host closed the connection) 13.03.59 # you just need the diff to target/arm/*.S I pasted yesterday and the script on the FS# task to test 13.04.24 # mpegplayer won't work and perhaps some codecs but every test_file which loaded into 8MB of memory decoded fine 13.04.59 # err, I didn't run test_codec on clipv1, so on armv4t at least mp3 will work, dunno for others 13.05.31 # I'm leaving for a while, binutils and gcc (arm-elf-eabi) already built. no error, install succeed ! built on cygwin 1.7. 13.08.18 # amiconn: i'll run test_codec on fuzev1 13.08.33 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 13.09.00 # I try build other targets cross comilers. maybe rockboxdev.sh no problem on cygwin 1.5/1.7. 13.10.10 # domonoky: I've got the updater script "working" (I tihnk)... can i get the zips from the theme site? 13.10.57 # I've got it making a diff of the changes which I was hoping could be auto emailed to the theme authors 13.13.44 # JdGordon: i can get you all the zips, but what should the theme authors do wit hthe diff ? 13.14.07 # just have a look I guess... more to make sure it didnt do anything stupid 13.15.11 # also with the zip, I need to know if it is for a mono display or not 13.15.24 Join Barahir [0] (~jonathan@frnk-590fe185.pool.mediaWays.net) 13.16.33 # if a zip is mono or not, is only noted in the DB, so i cant tell you that if i download all the zips somewhere. 13.17.23 # also there are all those old zips with outdated themes, you cant know which is the newest without info from the db. 13.17.37 # you could perhaps do some check on the bitmaps depth with the script? 13.17.47 # * S_a_i_n_t has no idea if that's actually possible or not. 13.18.17 # domonoky: you need to do a db query to get the zips anyway right? can you do 2 then? one for mono and one for others? 13.18.30 # %V needs different handling for mono which is why i ask 13.19.02 # JdGordon: i dont need a query to get the zips, i could just download the zips from the server... 13.19.26 # "(21:17:22) domonoky: also there are all those old zips with outdated themes, you cant know which is the newest without info from the db." ye, that needs the db too... 13.20.29 # right, but if we only want to work on the latest zips? 13.20.31 # or too hard? 13.22.53 # its not really hard, but its a few hours work. I would have to write a php script with the correct querys etc, i probably wont have enough time for that till devcon. 13.23.43 # probably a good time to leave it to then :) you and scorche can decide how to handle the theme site split 13.25.28 # jup, if we have a working skinupdater, we should be able todo that a devcon. 13.26.07 # faster to run it locally ont he server instead of here 13.29.05 # * S_a_i_n_t notes that FS#11270 is getting rather fancy now...is anyone considering this for a commit? 13.33.07 Join Kitr88 [0] (~Kitar_st@BSN-143-105-94.dial-up.dsl.siol.net) 13.33.21 Quit Kitar|st (Read error: Connection reset by peer) 13.33.38 # * kugel wonders why saratoga is always refering to me as the pictureflow guy 13.34.30 Join Kitar|st [0] (Kitar_st@BSN-182-53-132.dial-up.dsl.siol.net) 13.35.13 # kugel: cos you like shiny :) 13.37.22 Quit Kitr88 (Ping timeout: 240 seconds) 13.38.54 # AlexP: hey! i finally got my beast back together... when i turn it on the LCD is white.... how do i get i up and running? 13.39.01 Quit AlexP (Remote host closed the connection) 13.39.16 Join AlexP [0] (~ap@rockbox/staff/AlexP) 13.39.29 # not using the origional hard disk if that changes anything 13.40.32 Quit yosafbridge (Ping timeout: 245 seconds) 13.41.16 # http://pastie.org/984182 < test_codec arm/thumb results on fuzev1 13.42.34 Join teru [0] (~teru@M016207.ppp.dion.ne.jp) 13.42.53 # wma/mp3 are faster, aac/mpc/cook/vorbis are slower 13.44.57 # I'm surprised that it has so little influence 13.45.22 # i thought it would be much slower 13.46.07 # 11270 looks ok.. is it actually ready to be checked in? 13.46.20 # Doesn't this just prove that the critical bits are asm anyway? 13.46.43 # speeds vary between 98.77% and 100.18% 13.47.39 Quit ucchan (Quit: Leaving...) 13.47.56 # gevaerts: yeah probably 13.48.39 # on clipv1: 97.87% <-> 104.64% 13.48.41 # clipv2* 13.49.31 # * kugel wonders how thumb can be faster 13.49.43 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 13.50.08 # less code to load from ram 13.50.23 # -> more things in cache 13.50.36 # thumb could be a win on low-iram systems 13.51.14 # depends what you put there, if it's data (tables) then it doesn't change 13.51.28 # neither if it's 32bits asm routines 13.51.46 # well one must try, i think this includes the gigabeats? no other dap? 13.53.53 Quit AlexP (Quit: Please insert girder) 13.54.54 # New commit by 03jdgordon (r26408): add support for the possible viewport colour tags (%Vf and %Vb). use -c to disable them 13.55.56 # hm i misread the tests 13.56.07 # on clipv2 everything is faster, except aac 13.57.18 # well I had read correctly, I misread the test_codec parser output 13.59.59 Quit teru (Quit: Quit) 14.01.35 # I misread fuzev1 results though, only mp3 and wma are faster 14.01.39 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.02.46 # fuzev1 has 8kB + 8kB (I+D) caches 14.02.47 *** Saving seen data "./dancer.seen" 14.06.14 Join teru [0] (~teru@M016207.ppp.dion.ne.jp) 14.13.17 # clipv2 has 16kB + 16kB, perhaps thumb has less influence 14.13.45 # I have put codec numbers on FS#6734 14.15.11 # someone wants to test on PP ? 14.17.29 Join wincent [0] (~wincent@f055222219.adsl.alicedsl.de) 14.19.23 Quit mischasworld (Ping timeout: 276 seconds) 14.21.22 # funman: if you do me a build, sure 14.21.35 # which target? 14.21.40 # e200v1 14.22.52 # may i ask that tumb is you talking about every day? 14.24.42 # http://en.wikipedia.org/wiki/ARM_architecture#Thumb 14.24.59 # ty funman 14.26.05 # ah, smaller opcode to sace code data size, nice 14.29.40 # kugel: http://rafael.carre.perso.sfr.fr/rockbox.zip (i only tested wma/mp3/mpc/vorbis/cook/aac, others might not work) 14.31.02 # funman: doesn't boot 14.31.17 # freeze at bootlogo of the bootloader 14.32.03 # let me change lcd code 14.33.45 # kugel: try again? (same url) 14.34.00 # give me some minutes, I need to unbrick it first :) 14.34.22 # there's no hardware power off ? :/ 14.34.36 # it should be in UIE() undefined instruction 14.34.56 # hmm well UIE() use lcd ops, which cause another undefined instruction :p 14.36.07 # funman: nevermind, I forgot that I can boot the OF :p 14.36.10 # do you use opened devices where you can reconnect the battery to unbrick? 14.37.32 # funman: still no boot 14.37.48 Quit teru (Quit: Quit) 14.39.06 Join halmi [0] (~netbook@80-123-32-145.adsl.highway.telekom.at) 14.39.34 # Rob2222: if you can revive a player by just reconnecting the battery, it's stuck, but it's not anywhere near bricked 14.39.59 # i wonder about the ldm.*pc in thread.c -> it seems to work on clipv1/fuzev1 14.40.31 # funman: because it works on arm9 14.40.44 # nope, on armv5 14.40.52 # gevaerts: ok. good point. so you use these special usb mode or a jtag, i assume. ok 14.41.00 # only arm7 has the ldm pc constraints AFAIK 14.41.05 # armv4t 14.42.59 # and armv7+ can use mov pc, 14.43.00 # Rob2222: it will depend on the player. Actually, us developers don't generally count players that can be revived using a special USB mode as bricked either :) 14.43.26 Join aevin [0] (eivindsy@unaffiliated/aevin) 14.43.30 # If you need soldering, it's bricked. If not, it's merely being annoying 14.43.31 # funman: arm7tdmi, not armv7 14.43.43 # no, i said armv7 14.43.51 # but I said arm7 14.43.57 # armv4t must use 'bx' 14.44.08 # armv5t+ can use ldm ... { , pc } 14.44.12 # armv7+ can use mov pc, xx 14.44.58 # I'm not sure about that 14.45.27 # gevaerts: ok 14.45.37 # kugel: well prove me wrong 14.45.55 # I'm trying to, but google fails on me :) 14.46.09 # then perhaps it's right? 14.48.30 # build updated with thread.c:load_context() change 14.48.51 # ranma: VIC_INT_EN_CLEAR = X; while (VIC_INT_ENABLE & X) ; => still crashes 14.49.43 # if i disable DMAC interrupt just after enabling the channel nothing happens (progress bar doesn't move) so I guess there is some race condition 14.52.26 # funman: same url? 14.53.21 # yeah 14.53.32 Join stoffel [0] (~quassel@p57B4C89B.dip.t-dialin.net) 14.53.49 # funman: no boot :( 14.54.09 # :/ 14.56.00 # ah i must check for ldr pc, [X] 14.58.26 Join mischasworld [0] (~quassel@f050226205.adsl.alicedsl.de) 15.02.53 # nothing harmful :/ 15.05.54 # "(((ldr|mov) *)|(ldm.*))pc" should cover all armv4 returns which don't preserve T bit ? 15.06.35 Join einhirn [0] (~Miranda@p5485027D.dip0.t-ipconnect.de) 15.11.10 # nrv2e_d8.S use 'mov pc, lr' and comment says "stay in current (THUMB) mode", but according to http://www.riscosopen.org/wiki/documentation/pages/ARMv7+compatibility+primer this can't work 15.11.57 Quit mischasworld (Remote host closed the connection) 15.16.00 Quit funman (Quit: tiuq\) 15.20.42 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 15.27.05 # Rob2222 didnt you try to rockbox a Fuze V2? 15.33.56 Quit bmbl (Ping timeout: 258 seconds) 15.38.13 Join MethoS- [0] (~clemens@134.102.106.250) 15.38.46 Join anewuser [0] (anewuser@unaffiliated/anewuser) 15.38.46 Quit MethoS- (Remote host closed the connection) 15.40.01 Quit Zarggg (Quit: Zarggg) 15.43.18 Join selectohh [0] (~irc@ip216-239-95-167.vif.net) 15.44.17 # does anyone know if there is guidelines / a website with guidelines for submitting a plugin to be accepted in the build? like how it needs to be commented or some stuff like that? 15.44.33 # check the wiki 15.44.49 # selectohh: only docs/CONTRIBUTING 15.44.49 # one sec, I'll find the link. 15.44.55 # i saw something kind of general for patches.. nothing for plugins 15.45.23 Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:fbf0:beb1:ba3d) 15.46.12 # oh ok, i see the docs/CONTRIBUTING. thanks i think that's what i was looking for. i did google the heck out of this but for some reason google seems to overlook svn for me. 15.47.22 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 15.48.13 # have any of you tried rockbox on the Fuze v2? 15.50.31 # r0b-: do you have an actual question? 15.51.02 # not at this moment 15.51.04 Part r0b- 15.56.04 Quit einhirn (Read error: Connection reset by peer) 16.01.02 Quit esperegu (Ping timeout: 240 seconds) 16.02.47 Join lpereira [0] (~lucien@170.184.84-79.rev.gaoland.net) 16.02.49 *** Saving seen data "./dancer.seen" 16.02.53 Join AlexP [0] (~ap@rockbox/staff/AlexP) 16.05.27 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 16.05.43 Join funman [0] (~fun@rockbox/developer/funman) 16.07.22 Quit AlexP (Ping timeout: 240 seconds) 16.07.48 Join Abaoji [0] (~full@cpe-173-88-79-182.columbus.res.rr.com) 16.08.09 # JdGordon: Do you remember at all what I was going to add to skinwishlist the other day? 16.08.15 Join AlexP [0] (~ap@rockbox/staff/AlexP) 16.08.21 # haha... no :p 16.08.31 # grep the irc logs maybe? 16.08.32 # neither :/ 16.08.44 # I need stuff outside the skins to play with... 16.08.54 # unless you want to talk about tag changes... 16.09.01 # yes, yes you do...or you'll go insane. 16.09.08 Quit AlexP (Remote host closed the connection) 16.09.08 # too late! 16.09.15 # :D 16.10.19 # Hi everyone, I have a Sansa E200 series running most current version of Rockbox. I know Rockbox has dual-boot function. I wondering if it's possible to permanently disable manufacturer's firmware[i.e. Sansa] and use Rockbox as default firmware. 16.12.04 # you can, but it is not advisable... 16.12.10 # I accidently did it to mine :p 16.12.15 # just ignore the OF 16.12.46 # I want to disable the manufacturer's firmware because I bought a new FM transmitter http://www.amazon.com/Satechi-Transmitter-Charger-Sansa-e260/dp/B001BVUE6M/ref=sr_1_3?ie=UTF8&s=electronics&qid=1275228674&sr=8-3 and everytime when I when turn off the player, Rockbox won't be able to load. 16.13.12 # JdGrodon: How to disable? 16.14.37 # Abaoji: you mean the OF boots when you turn on the e200 when attached to that thing? 16.14.55 # sorry what's OF? 16.15.08 # original firmware 16.15.14 # the manufacturer's firmware 16.15.28 # yes OF boot when I attached to my FM transmitter 16.16.09 Join AlexP [0] (~ap@rockbox/staff/AlexP) 16.16.26 # Abaoji: e200v1 or v2? 16.16.35 # v2 16.16.53 # so dock works with e200v2? nice 16.17.01 # well, it's possible but strongly discouraging 16.17.14 # discouraged* 16.17.25 # gevaerts: ping 16.17.39 Join esperegu [0] (~quassel@145.116.15.244) 16.18.05 # I understand the risk. but I already invested so much in the FM transmitter already, I want it to work perfectly. So can you pm me the instruction? 16.19.17 # disable the usb check in rbutil/mkamsboot/dualboot/dualboot.S, recompile mkamsboot and use that for installing rockbox 16.19.29 # JdGordon: Sorry, I was disconnected for a bit - you asked something? 16.19.30 Join orzech [0] (~orzech@elj74.internetdsl.tpnet.pl) 16.19.50 # Abaoji: are you running the latest bootloader? Does your e200 boot to the OF or to rockbox if you connect it to a PC when it's switched off? 16.19.52 # white LCD on my beast... new hard disk.. what do I do? 16.19.53 # kugel: gnip 16.20.15 # * bertrik plans to fix the samsung yp-s3 bootloader to he can demo it at devcon 16.20.28 # gevaerts: I started #ifdef SIMULATOR conversion here: http://pastie.org/984303 16.20.35 # not all need to be converted 16.20.38 # gevaerts: it boot to rockbox first, but it didn't work so it revert to OF. 16.20.52 # JdGordon: er, don't know - I've not seen that 16.21.08 # When I put the new disk in it just went through that partitioning/reformatting bit 16.21.10 # maybe i didnt put it together properly then.. what does it do when no disk is connected? 16.21.17 # Abaoji: how long ago did you install the bootloader? 16.21.19 # JdGordon: Could you have semi disconnected the lcd? 16.21.30 # probably 16.21.53 # gevaerts: half year ago, lemme check the version.. 16.22.48 # kugel: the very first changed line in that diff is wrong :) 16.22.49 # kugel: how do you recomplile mkamsboot? 16.22.52 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 16.23.27 # Abaoji: ignore me. I didn't see that you said it's a v2... 16.23.37 # AlexP: hehe the ribbon came completly out 16.23.50 # JdGordon: That'd do it :) 16.23.58 # Abaoji: e200v2 shouldn't "boot to rockbox first", please check the bootloader's version 16.24.03 # gevaerts: oops, in fact I haven't even test compiled 16.24.11 # ok ok I will check again 16.24.23 # I just wanted to show where things are going to 16.25.36 Quit halmi (Read error: Connection reset by peer) 16.31.13 # kugel: are you just converting the #ifdefs mostly blindly, or are you also checking if the ifdefs actually make sense, and if they e.g. should be handled differently for RaaA and the sim? 16.31.16 # I'm getting compiler warnings trying to get the samsung yp-s3 bootloader to build, it complains about format expecting 'unsigned int' but argument having type 'long unsigned int'. The argument is a uint32_t defined in stdint.h 16.31.52 # Why is uint32_t defined as 'unsigned long' instead of simply 'unsigned int'? 16.33.08 # gevaerts: the latter 16.33.26 # bertrik: both are 32 bits, so any will do 16.33.30 # (this is for sprintf) 16.33.33 # I left some #ifdef SIMULATOR as is, for instance those which are for debugging purpose only 16.34.35 # funman, yes I know they are for our targets, but the compiler thinks they are different. Somehow a decision was made to make it explicitly 'long' 16.35.00 # the sizes are the same, the types are different 16.35.03 Quit orzech (Quit: leaving) 16.35.23 # printing a uint32_t requires special format strings usually, like PRId32 16.35.40 # gevaerts: basically, those that are relevant for RaaA are converted, the others not 16.36.00 # but we don't have these defines in rockbox, so you can just cast it to anything, that's what other parts of rockbox do already 16.36.05 # kugel: probably out of scope for RaaA, but I think some of the ifdefs shouldn't be there for the sim at all, like e.g. battery_voltage in plugin.c. It's probably useful to ask MrSomeone to review the things again later on for that :) 16.36.57 # yes, it would be a lot of work I think 16.37.09 Quit bertrik (Quit: De groeten) 16.37.12 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 16.37.40 # In some cases the ifdef is only there because people didn't feel like adding a stub I think 16.37.57 # that too 16.37.58 # But anyway, your job is to not make the sim worse, not to improve it :) 16.38.05 # :) 16.39.08 # AlexP: "contact manufacturer for repair"? 16.40.46 # JdGordon: I can't rememeber the exact messages - can you send it a firmware with sendfirm? 16.40.57 # If not, maybe the disk cable isn't fully in? 16.41.04 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 16.43.40 # usb connects :) 16.44.10 # funman, really? uint32_t would still fit in an unsigned int on most (if not all) targets. I don't see the need for a long, I notice only disadvantages 16.45.40 # there's no difference between long and int on our 32 bits targets, except that the C language treats them differently, and so *printf need different format specifiers 16.45.46 # int isn't better, or worse, than long 16.46.07 # it's just a different type, but since they have the same size you are free to cast them to each other 16.47.28 Quit solexx (Ping timeout: 260 seconds) 16.48.38 Quit Akranis (Ping timeout: 264 seconds) 16.49.02 # if you want to print uint32_t properly, we should have a #define PRIu32 "lu" (for unsigned long) and you would use printf("XXX%"PRIu32"blabla", (uint32_t)x) 16.49.04 Join solexx [0] (~jrschulz@e177131196.adsl.alicedsl.de) 16.49.19 Quit togetic (Quit: WeeChat 0.3.0) 16.49.20 # well, int is more likely to be 32bit across platforms 16.49.28 # or we could do PRIu32 "u" if we define uint32_t to unsgiend int 16.50.45 # AlexP: where do i find sendfirm? 16.51.08 # kugel: I've just looked at some random occurences of SIMULATOR in apps/, and I can only wish you good luck... 16.51.26 # JdGordon: utils/MTP 16.52.37 Join Akranis [0] (~Akranis@h212n2-vrr-d2.ias.bredband.telia.com) 16.53.04 Quit Akranis (Client Quit) 16.53.44 # gevaerts: hehe 16.53.58 # * gevaerts adds an idea to the DevCon2010 page :) 16.54.39 # we can change memory voltage from 1.8V to 1.7V on as3525v1, it seems OF does that 16.56.48 # kugel: have a look at e.g. apps/plugins/zxbox/spmain.c. Why on earth do those depend on !SIMULATOR? 16.57.50 # excellent question 16.58.17 # My guess is "possibly historical reasons" 16.59.25 # should I fix those most useless ones, ignore them or convert them? 17.01.03 # I'd say ignore them. Anything else will make the eventual commit less clean 17.01.57 # ok, ignoring them possibly also shows how useless they are since RaaA doesn't define SIMULATOR 17.03.56 # bertrik: gcc has a limits.h itself, are you sure it's not that one which is included? 17.06.31 # I'm not sure I understand any of this any longer, is there someone here who knows and can explain in simple words why we use longs for 32-bit units? 17.07.18 Quit Abaoji () 17.08.57 # bertrik: my guess is "because the logic to define them was borrowed from somewhere that did it like that" 17.09.21 # i'd say "why not?" 17.09.33 # some of the most strange things in firmware actually come from newlib :) 17.09.34 # funman, casting hell in printf-like functions 17.10.06 # * kugel thinks using int instead wouldn't hurt 17.12.14 # Just inverting the order in stdint.h should achieve that 17.13.07 # it's an OK workaround, but i guess existing casts will need to be changed 17.14.28 # inttypes.h say /* could possibly have (f)printf format specifies here */ 17.15.06 # gevaerts: re your devcon idea.. is that cracking kugels whip? or doing his work for him? :D 17.15.31 Join AdB3 [0] (www-data@giant.haxx.se) 17.15.44 Quit AdB3 (Client Quit) 17.15.55 # JdGordon: neither I think. The fact that e.g. cpu_frequency is not just stubbed but #ifdeffed all over the place is not really related to RaaA 17.15.58 Join adb3 [0] (www-data@giant.haxx.se) 17.16.49 # yes, getting rid of all of them would be great 17.18.25 Join simonrvn [0] (simon@210.156-ppp.3menatwork.com) 17.18.57 # I'm always in favor of stubbing, for target builds too 17.19.10 # Hi 17.19.21 # I want to build a RB plugin / skin 17.19.46 # Those two are quite different :) 17.19.54 # Know 17.20.00 # * I Know 17.20.36 # the issue is that the skin need display images generated by the plugin 17.20.50 # bertrik: http://pastie.org/984370 , can you use "%"PRId32" xx" instead of "%d xx" ? 17.21.30 # I think that would technically be called a viewer 17.21.30 # * kugel finds these PRIdX ugly 17.22.13 # funman: "%h" is a format specifier? 17.22.25 # I always thought short/char just use %d 17.22.29 # i think it's actually hd 17.22.41 # funman: Is that on Clip+? Crash == "Unhandled masked IRQ 04: INT_DMAC[...]"? 17.22.42 # just learned about h and hh in man 2 printf 17.22.43 # funman, I'm totally unfamiliar with the PRI stuff, to be honest 17.22.47 # ranma: clipv2 17.23.00 # adb3: what do you want to do? 17.23.01 # bertrik: well that's just how you should print (u)intXX_t 17.23.25 # since the header can use int, long, or whatever fits in the desired width 17.24.17 # I would like my MP3 player to feel like Serato's ScratchLive... 17.25.00 # 1st, I would like to have a similar look 17.25.07 # the skin part 17.25.17 # New commit by 03jdgordon (r26409): Accept FS#11313 by Chris Savery. Add composer to the track info screen and some general cleen up. 17.25.19 # however our format.c doesn't know 'h' so we could use d (my linux header does that) 17.26.29 # then I would like to be able to see the 'overviews' (waveform-ish image of the track which is encoded in the ID3 tag) 17.26.40 # funman: I think char/short is not valid in va_arg() so there would be no advantage of %h 17.26.58 # http://pastie.org/984370 (edited) <- ok for commit? 17.27.26 # kugel: yep, i just said that ;) 17.27.37 # adb3: well, right now we have no way for a plugin to draw onto the wps. There is a WIP patch that would enable that, but nothing in svn 17.27.50 # funman: I mean generally not our format.c 17.27.54 # I have the already done that last part in python 17.28.10 # va_arg() has some constraints IIRC 17.28.31 # well, my target is a WIP... (Cowon D2+) 17.28.32 # funman, wait, please let me try it first 17.29.18 # Maybe the problem only happens on AMSv2? 17.29.46 # ranma: fuzev1 too 17.30.10 # Gordan: what are thinking??? 17.30.30 # not very much 17.31.01 # lol 17.31.04 # well...I'm wondering how python will help you with an RB plugin. 17.31.20 # just prototyping.... 17.31.31 # but havin access to all those libraries was nice 17.31.52 # even so...better to do it in code that will actually runon the device. 17.32.03 # i know 17.32.33 # kugel: where would this restriction come from ? 17.32.52 # I don't know and I can't find anymore where I read about it 17.32.56 # Hmm, so then I wonder why I haven't been able to reproduce it here :( 17.33.15 # if our format.c works it just means that short/char/int have the same size as parameters 17.33.29 # ranma: it just takes 5 minutes to crash 17.33.39 # New commit by 03jdgordon (r26410): fix red. no replaygain on hwcodec 17.33.55 # I left it running for at least 20 minutes IIRC 17.35.27 # * JdGordon has a topic that should be discussed at devcon, but doesnt know how to bring it up in email as he wont be there :( 17.35.39 # funman, I don't really like it much to have a PRId32 macro in printf statements 17.36.05 # IRC protocol/antiflaming? 17.36.34 # bertrik: that's probably why virtually nobody uses it. but it's in fact iso c99 17.36.44 # JdGordan: wps - refresh my memory... its the 'display', what gets rendered 17.36.53 # yes 17.37.06 # it's needed for portable code which uses intXX_t 17.37.52 # Do you just play an mp3? Because AFAICS the pcm_play_dma_get_peak_buffer() is only called from plugins and the pcmbuf_beep (keyclick I suppose) 17.38.05 # and this patch??? 17.38.09 # ranma: yep, just playing 17.38.30 # funman, ok thanks for the explanation. 17.38.35 # http://pastie.org/984370 <- i added *intptr_t 17.39.02 # The alternatives are either casting the arguments, or adding an 'l' to the % formatter, right? 17.39.21 # s/alternatives/workarounds/ yes 17.39.41 # or just using an int in the first place ;) 17.39.50 # http://www.rockbox.org/tracker/task/11027 17.40.14 # funman: shouldn PTR be %(l)X? 17.40.54 # no 17.41.11 # instead for x/X we should have PRIxN (N= 8, 32, PTR) 17.41.29 # ah I see 17.41.35 # and PRIo for octal 17.42.00 # i skipped also MAX, SCN (scanf), LEAST, FAST 17.42.42 # we don't use int_least* or int_fast*, dunno about scanf 17.42.57 # well it's used 17.43.02 # funman: I just put a breakpoint on pcm_play_dma_get_peak_buffer, it's not called during normal playback so far, only if I seek or pause/unpause. 17.43.24 # ranma: perhaps it doesn't come from this function 17.43.47 # i just reverted 26316 from current svn and it still crashed in 5 mins 17.46.38 # But you blamed it on 26311 in 26316 and the former only changes pcm_play_dma_get_peak_buffer :) 17.47.00 # Maybe I should update to current and see if I can reproduce it then... 17.47.11 # perhaps i blamed wrongly, i don't know 17.47.44 # JdGordon, adb3: FS#11027 isn't really a work in progress. It's more of a failed experiment... 17.48.10 # yeah, I saw that last comment.. must have forgotten that was how it ended :/ 17.48.26 # maybe skipping the skin would be easier, just make a plugin which draws everything. Plugins must be able to control playback 17.48.37 # adb3: yes, they are 17.49.10 # Anyway, with INT_AUDIO the fact that it didn't lock up when you were getting the interrupt storms seems a strong indication to me that the VIC is working correctly. :) 17.49.57 Quit DerPapst (Quit: Leaving.) 17.50.07 # http://pastie.org/984370 <- adding scanf macros will duplicate each d,i,x,u entry, just not the X 17.50.41 # ranma: i just had panicf unhandled interrupt with INT_AUDIO in vic raw status several times 17.50.56 # when plugging usb cable 17.51.01 # perhaps plugging/unplugging 17.52.19 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 17.52.30 Quit linuxstb (Ping timeout: 240 seconds) 17.53.34 # We don't have a cabbie radio screen right? Maybe a nice idea to discuss / design one at devcon? 17.53.59 # and at the beginning of the port we had this message several times (unhandled interrupt with no unmasked source) but i don't remember the cause (if we ever foudn it) 17.55.17 # bertrik: we dont, I've been tring to get the forum to do one, but they are useless 17.55.21 # JdGordan: the seccond part of the plugin would be to utilize Serato's music library format, so that users could view their tracks in the order they are use to. Somebody else has made a Java tool for working with Serato's library & crates 17.58.04 Quit GeekShadow (Ping timeout: 258 seconds) 17.59.51 # funman: do we have scanf? 17.59.54 # anyways, thank you for your help. I have to go DJ now. It seems like this will be a rather large project, but by no means imposible... have to start coding up concepts 18.00.10 # New commit by 03funman (r26411): inttypes.h: add (some) iso c99 fprintf format specifiers ... 18.00.23 # kugel: yep i see it in firmware/libc (sscanf) 18.00.58 # afaict only imported plugins use it 18.00.59 # ooh one more question: whats the ID3 library / functionality??? 18.01.15 # rockboy/zxbox/doom/pdbox and lua exports it too 18.02.52 *** Saving seen data "./dancer.seen" 18.03.02 # adb3: ? 18.05.05 # I need to read obscure ID3 tags (a GEOB tag....) 18.05.43 # funman: weird, I'm pretty sure I've never hit the unhandled interrupt panic so far... :( 18.07.39 # adb3: you'll probably need to hack up the metadata parser then also 18.07.50 # Yeah! 18.07.58 # New commit by 03funman (r26412): inttypes.h: remove excessive PRI*PTR declaration when long isn't 64 bits 18.07.59 # sometimes the wiki really pisses me off 18.08.10 # it does? 18.08.13 # theres no real order... 18.08.17 # only sometimes? 18.08.47 # adb3: how *should* it be ordered? 18.08.54 # I'm genunely curious. 18.09.08 # wow...typo 18.09.31 # its seems comprehensive, but trying to navigate to a topic (sometimes even a direction) is hard 18.10.02 # its always: wiki > main > page 18.10.10 # funman: Hmm, you said you were using a newer gcc, right? I sure hope it's not compiler related :) 18.10.23 # what's with the player sim red? i hit that sometimes 18.10.30 # * ranma is still using arm-elf-gcc (GCC) 4.0.3 18.10.31 # not wiki > field > topic > page 18.10.32 # ranma: i hit it with 4.0.3 18.10.41 # Hmm, ok. 18.10.47 # adb3: Well, pretty much everything you'll be interested in is in DocsIndex 18.10.49 # i use default gcc, too 18.11.16 # funman: minor bug in the dependancy stuff probably 18.11.53 # ranma: i'll try on fuzev1, gcc 4.0.3, and reverting between those 2 revisions to check again (but later) 18.12.00 # adb3: There is also a search, so the ordering doesn't really matter. 18.12.56 # * ranma is compiling 26412 with 26316 reverted for testing 18.13.19 # Hrmm, no wodz around 18.14.10 # Configure 'normal' and -g added manually to Makefile (if I use (D)ebug it's crashing) 18.18.03 # hm, only 130 ifdefs to go 18.19.21 # ah no, 200 18.20.21 Quit adb3 (Quit: CGI:IRC (EOF)) 18.20.45 Join newnick [0] (www-data@giant.haxx.se) 18.20.59 Nick newnick is now known as adb3 (www-data@giant.haxx.se) 18.26.07 Quit efyx (Remote host closed the connection) 18.31.07 Quit stoffel (Remote host closed the connection) 18.32.55 Join efyx [0] (~efyx@82.225.185.146) 18.37.33 Join domonoky1 [0] (~Domonoky@agsb-4d048723.pool.mediaWays.net) 18.38.41 Quit domonoky (Ping timeout: 260 seconds) 18.40.52 Quit adb3 (Quit: CGI:IRC (EOF)) 18.42.57 Quit Rob2222 (Quit: Rob2222) 18.43.21 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 18.51.10 Quit TheSeven (Ping timeout: 240 seconds) 18.52.46 # * kugel is confused by the define in spc_codec.h 18.54.21 # ranma: why -g ? do you use gdb? 18.57.48 Join Rob2222 [0] (~Miranda@p4FDC9BB0.dip.t-dialin.net) 19.01.22 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 19.10.46 Quit efyx (Quit: Quitte) 19.12.09 Quit n17ikh (Ping timeout: 260 seconds) 19.13.30 Join kugel_ [0] (~kugel@e178189109.adsl.alicedsl.de) 19.13.46 Quit kugel (Disconnected by services) 19.13.50 Nick kugel_ is now known as kugel (~kugel@e178189109.adsl.alicedsl.de) 19.14.01 Quit kugel (Changing host) 19.14.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.18.14 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 19.22.35 Join DerPapst [0] (~Alexander@p4FE8F365.dip.t-dialin.net) 19.23.34 # ranma: fuzev1, 15 minutes mp3 OK with r26412, now trying r26316 (should be OK too) 19.31.24 Join kugel_ [0] (~kugel@e178191204.adsl.alicedsl.de) 19.31.44 Quit kugel (Disconnected by services) 19.31.48 Nick kugel_ is now known as kugel (~kugel@e178191204.adsl.alicedsl.de) 19.31.52 Quit kugel (Changing host) 19.31.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.32.33 Quit robin0800 (Remote host closed the connection) 19.33.29 # in case you missed it, the initial report was on http://forums.rockbox.org/index.php?topic=14064.msg167344#msg167344 19.38.09 Join stoffel [0] (~quassel@p57B4C89B.dip.t-dialin.net) 19.38.14 Join epicfailguy [0] (EPICFAIL@75-170-228-21.desm.qwest.net) 19.39.31 Join MethoS- [0] (~clemens@134.102.106.250) 19.40.53 Quit stoffel (Remote host closed the connection) 19.40.57 Quit wincent (Read error: Connection reset by peer) 19.42.59 Join stoffel [0] (~quassel@p57B4C89B.dip.t-dialin.net) 19.43.31 Join wincent [0] (~wincent@f055121235.adsl.alicedsl.de) 19.44.17 Join CaptainKwel [0] (~jason@207-237-113-115.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 19.46.12 # Is the patch that allows Doom to build under eabi in SVN? 19.48.35 # yes 19.48.46 # also, it did build, it just didn't run very well 19.48.48 # *excellent* 19.49.03 # It didn't to begin with ;) 19.53.30 # gevaerts: some plugins use #ifdef SIMULATOR because it's more powerful :( 19.54.00 # in what way? 19.54.27 Quit wincent (Changing host) 19.54.27 Join wincent [0] (~wincent@rockbox/developer/wincent) 19.55.12 # gevaerts: e.g. beatbox.c, although that one seems it isn't compiled anymore 19.55.22 # IS the Nano2g *really* "incomplete, less usable, has problems that limit it to advanced users"? 19.55.35 Quit stoffel (Remote host closed the connection) 19.55.58 # I know it isn't "stable", but it doesn't really fit the "unstable" definition. 19.56.27 # is complete in the sense 'with the features AND the bugs' ? 19.56.40 # (nitpicking I know) 19.56.48 # S_a_i_n_t: that's not meant as *and* 19.57.14 # gevaerts: but, it isn;t really *any* of those is it? 19.57.32 # isn't it just the wonky FTL? 19.57.40 # S_a_i_n_t: what are the problems with FTL ? 19.57.52 # S_a_i_n_t: haven't you just said yourself it wouldn't be stable? 19.57.59 # funman: Nothing anymore...as far as I know. 19.58.21 # that means it's "less stable" and fits very good under unstable 19.58.28 # It used to WSOD daily, but...mine are what I would consider to be more stable than my Nano1gs 19.58.33 # S_a_i_n_t: in that case the developers who know about it should propose promoting it to stable 19.59.09 Quit n17ikh (Ping timeout: 248 seconds) 19.59.13 # TheSeven has AFAIK 20.00.49 Join ssorgatem [0] (~ssorgatem@83.55.235.224) 20.01.36 # ranma: r26315 & r25316 played fine 15 minutes on fuzev1 .. 20.02.47 # kugel: those beatbox #ifdefs look interesting indeed 20.02.53 *** Saving seen data "./dancer.seen" 20.03.15 # the exact same is in midi 20.03.47 # kugel: err, sorry. I should have said "wasn't it the FTL", instead of "isn't". That and the HID, but HID has been removed from the Nano2g, so is no longer a problem. 20.04.00 # I know the sim is limited to 44.1 (for no real reason IIUC) but being a sim it shouldn't use more of X just because it can 20.04.25 # S_a_i_n_t: without HID it's "incomplete" :p 20.04.29 # kugel: I fully agree. 20.04.52 # do *all* the stable targets have HID ? 20.05.03 # (legitimate question) 20.05.06 # S_a_i_n_t: if he thinks it's stable, and nobody opposes that, he should promote it (or ask for help with promoting it) 20.05.12 # S_a_i_n_t: nope 20.05.57 # ideally, before thursday ;) 20.06.10 # Well, I don't think it's "rock solid", but it's no longer "unstable"...I'm a little afraid to cause a flamewar :/ 20.06.17 # funman: that's different again :) 20.06.42 # TheSeven seems to have fallen off the radar a little lately. 20.06.53 # Uni I think. 20.07.56 # S_a_i_n_t: Is it "stable" with the rockbox bootloader? IIRC there was some discussion a few days ago about differences 20.08.14 # I use the rockbox bootloader in mine. 20.08.19 # And it's ANCIENT 20.08.55 # the GF uses iLoader in hers. I personally wouldn;t say that eaither is more stable than the other, iLoader just does more. 20.09.05 # I (personally) don't actually care which bootloader people should use, but the rockbox one is the one that's documented in the manual 20.09.45 # Yes, if I was pushed...I'd probably have to lean toward iLoader, but only because of the boot-time options. 20.10.59 # gevaerts: it turns out I can ignore most ifdef SIMULATOR actually 20.11.09 Quit flydutch (Quit: /* empty */) 20.11.46 # the majority is a) debugging, b) within HAVE_RECORDING (which RaaA won't have (initially)) or c) within #if CONFIG_CODEC == HWCODEC 20.12.06 # but, there is the benefit of "non-scary installation" withthe Rockbox Nano2G bootloader with it being NAND based and not NOR. 20.12.52 # There was *some* bricking risk in the early days, but not anymore as I understand it. 20.13.05 # kugel: right, that was my impression too. (a) is the only one that should still be there in the long term I think 20.13.52 # still quite a job to check all 20.15.28 # S_a_i_n_t: I'd say find TheSeven the next time he's online. I really don't want to declare a target stable based only on hearsay (I don't have one, and since I've not been following it closely I don't know what issues there have been for various people, how serious or general they were, and if they were resolved), and I suspect that other non-owner devs will feel the same 20.15.50 # Oh, I agree totally. 20.19.53 # ranma: ah on the forum the crash report for fuzev1 says '3 crashes in 2 hours' 20.21.02 # a difference between as3525v1 & v2 is the CPU: v2 run boosted 20.22.38 Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-lvhzqjdwsmmexgit) 20.23.31 # does the thumb patch simply ignore files with ASM blocks in them? 20.24.52 # saratoga_: i posted 2 gcc frontends, the first runs preprocessor, remove unused static inline functions, and then just grep for 'asm' -> if there is no match the file is built with -mthumb, else with default (no thumb) 20.25.14 # the second one (both are .py scripts) just tries to build with -mthumb, and falls back to default only if it fails 20.25.34 # funman: then thats why the codecs don't get slower 20.25.38 # so if the asm is valid thumb assembler it will be built with thumb 20.25.40 # they'll all have an ASM block 20.25.54 # but they use rockbox functions anyway? 20.25.55 # for the fixed multiply code 20.26.13 # and perhaps there is some c files in codecs which don't have asm 20.26.18 # yeah 20.26.34 # things like bitsream.c/h on the ffmpeg based codecs probably get smaller 20.26.50 Quit solexx (Quit: leaving) 20.27.10 # but anything that does multiplication will have an ASM block, so all the core of each codec, if not all the helper functions 20.27.16 # in the 2nd script youcan uncomment the secodn to last line so it shows files not built with thumb on stderr 20.27.31 # do any codecs get much smaller? 20.27.49 # didn't check any .rock or .codec 20.28.39 # might be worth comparing to http://www.rockbox.org/wiki/CodecMemoryUsage 20.28.47 # but i doubt its a big deal 20.29.02 # most codecs are pretty small anyway, and the space is largely data tables 20.29.06 # New commit by 03Buschel (r26413): Submit FS#11240 by Raphael Jakse. Allows to reduce volume on WM8985 to -89 dB (e.g. used for Cowon D2). Below -57 dB the line out is affected. The ... 20.33.38 # so, who can tell me the benefit of using arm-elf-eabi as opposed to arm-elf? 20.34.00 # so far, all I see is a binsize decrease. build time seems to be extended. 20.34.12 # New commit by 03Buschel (r26414): Fix FS#9193. Remove recording source for iPod Video and iPod nano 1G. The manual already describes the correct behaviour. 20.34.59 # S_a_i_n_t: bin size 20.35.46 # Oh, is that it? I guess with the drama I went through to build the toolchain I was expecting it to wash my dishes and do the vaccuuming ;) 20.36.24 # S_a_i_n_t: some codecs run faster as well it makes it possible to remove a hack which adresses gcc's inability to make proper calls of static functions across memory sections 20.38.17 # Awesome, if binsize was the only advantage I'd have a hard time seeing the point. 20.38.32 # I'm glad there's more to it. 20.40.36 # saratoga_: http://pastie.org/984641 20.42.06 # if you know how to alter shell $(()) precision please tell ^^ 20.42.43 # looks about right 20.43.34 # maybe its worth just disabling thumb for the codecs so the compile goes faster 20.47.24 # saratoga_: http://pastie.org/984641 (edited) 20.47.56 # big improvements are only for small codecs 20.53.05 # it would be nice if there was a #pragma -mno-thumb or something like that 20.53.16 Quit leavittx (Ping timeout: 258 seconds) 21.00.43 Join leavittx [0] (~leavittx@89.221.199.187) 21.02.37 # the codecs that improve are mostly the PCM ones, since they don't really do any processing, they're just bitstream parsing and a memcpy 21.04.12 Quit leavittx (Read error: Connection reset by peer) 21.05.52 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 21.10.15 # perhaps we can get better results if we separate asm functions from C functions 21.11.54 # buildtime for clipv1 using eabi: 220s 1st run, then 50s with ccache. thumb: 275s 1st run, then 110s with ccache 21.12.08 # doesn't the codeclib also have inline asm in .h files? 21.12.48 # you're thinking in the core or in codecs? 21.13.02 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 21.13.04 # yeah all the mul 21.13.49 # i wouldn't worry about codecs anyway 21.14.25 # so we can reduce binsize but it's only an improvement on targets with small buffer 21.14.35 # e.g. clipv1/c200v2/m200v4 21.14.43 # you mean the codec buffer size? 21.14.44 Quit bieber (Ping timeout: 258 seconds) 21.14.47 # no just rockbox 21.14.50 # oh 21.14.57 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 21.15.08 # yeah its worthwhile for the main binary, but for codecs I think the possible gains are quite small 21.15.14 # ape is one of the biggest and it's only down by 1% 21.15.22 # in translate.rockbox.org, what does the "changed source" column mean? 21.15.44 # and how can that be fixed? 21.15.53 # saratoga_: it reduces of ~100kB but over 8MB that's useless 21.16.29 # ssorgatem: the string has been translated in the past, but the original english has changed since 21.16.59 # ssorgatem: the source string of string in a .lang file doesn't match with the corresponding source string in english.lang 21.17.03 # well perhaps not useless: you can load 100kB bigger files in test_codec ;) 21.17.14 # the biggest codecs are wma and aac, and they're so big mostly because of enormous lookup tables 21.17.35 # WMA has a 64KB random number table because I was too lazy to figure out how to shrink it :) 21.18.03 # mm, also, if I try the automatic code cleanup tool 21.18.07 # it gives my 404 21.18.08 # :p which one? 21.18.21 # from translate.rockbox.org 21.18.29 # are there others? 21.19.06 # ssorgatem: this was for saratoga_, not for you 21.19.08 # noisetable_exp 21.19.27 # but the size of the codec buffer is determined by AAC and Vorbis due to their malloc 21.19.39 # so shrinking it doesn't accomplish anything 21.20.02 # that reminds me, still no mail on tremor ML 21.21.27 # yeah i need to bug them 21.21.38 # also to compute the RMS error between the new and old versions 21.21.40 Quit esperegu (Read error: Connection reset by peer) 21.21.44 # and check that 96khz files still work 21.22.30 # New commit by 03funman (r26415): Fix LANG_TAGNAVI_UNTAGGED source string 21.22.30 Join wodz [0] (~wodz@chello087206240004.chello.pl) 21.24.09 Join Casainho [0] (~chatzilla@bl20-126-252.dsl.telepac.pt) 21.24.30 # amiconn: ? 21.24.49 # hello :-) 21.25.13 # so, how can I fix the "changed source" thing? 21.25.27 # does anyone here knows the "sb" format for image files of SigmaTel SoC? there are a few targets where Rockbox run with this SoC... 21.26.47 Quit efyx (Remote host closed the connection) 21.27.17 # New commit by 03funman (r26416): french translation update 21.27.46 # because we at Lyre, we started using i.MX233 ARM9 from FreeScale that seems to be an reincarnation of Sigmatel SoC, and that uses encrypted firmware images 21.29.11 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 21.30.59 # Casainho: if you have a question just ask it 21.32.08 # http://www.rockbox.org/wiki/SigmaTelSTMP3xxx 21.32.12 # i don't htink much is known 21.32.18 # we've never had a port to one of their devices 21.32.39 # my question is: does anyone knows if on Rockbox sources are code to build a 'sb' type image, from an elf file? 21.32.57 # no there's not 21.33.23 # there's only code for TCC and PP i think 21.33.28 # imx233 is of type STMP36xx 21.33.38 # are you sure? 21.33.41 # i don't think it is 21.35.06 # i think freescale has reference manuals for all the MX series, maybe they're a better place to start 21.35.52 # when I run the 'elftosb2 -v' on Linux, I get: elftosb 2.2.1 21.35.54 # Copyright (c) 2004-2007 SigmaTel, Inc. All rights reserved. 21.36.32 # this forum message on FreeScale, talks about this: http://forums.freescale.com/t5/i-MX-Microprocessors/sb-loader-amp-Linux/td-p/53083 21.36.44 # FreeScale bought SigmaTel 21.37.47 # for imx233, the firmware image must be encrypted! and we have now a blink LED code... but from factory, keys are 0 21.38.31 # and we have the Linux 'elftosb2' executable that encrypts the elf files, but we would like to have the sources for 'elftosb' 21.39.02 # so, maybe Rockbox had some code to build that encrypted firmware images, for STMP36xx 21.39.37 # anyone knows how is the Rockbox bootloader installed on STMP36xx devices? 21.40.09 # can you ask them for the sb format description? 21.40.14 # Casainho: we don't have any code for this gsoc 21.40.23 # soc* 21.40.25 # they seem fairly open about this, maybe they have a document 21.40.34 Quit saratoga_ (Quit: Page closed) 21.42.12 # kugel: you mean, for STMP36xx or i.MX233? 21.42.46 # Casainho: both. you know where to look for what we actually have 21.42.54 # I updated catalan language translation: http://www.rockbox.org/tracker/task/11334 21.43.09 # kugel: ok, thanks. 21.44.19 # funman: don't forget to update the branch :) 21.44.38 # oops right, another reason to clone rockbox with branches! 21.47.40 Join merbanan [0] (~banan@c-94-255-222-11.cust.bredband2.com) 21.52.36 # here some pictures and details of current state of our Open Hardware board, now blinking a LED: http://lyre.sourceforge.net/?q=content/imx233-boots-usdcard-and-blink-led 21.52.50 # * S_a_i_n_t notices something new at compile time "genversion.sh" and "version.sh"...have I gone insane? 21.52.58 # these *are* new, yes? 21.53.15 # version.sh is rather old. 21.53.38 # it's been around since quite a while (earlier called svnversion.sh) 21.55.46 # i added genversion.sh a few days ago but i didn't add anything to hide it from make output 21.56.40 # aha...I'm quite accustomed to spotting irregularities at compile time, it just looked odd to me seeing such a long line. 22.02.55 *** Saving seen data "./dancer.seen" 22.04.29 Quit Buschel (Ping timeout: 276 seconds) 22.11.47 # saratoga: +586333.33% realtime 22.11.47 # +0.04MHz needed for realtime 22.12.34 # i used a normal build and only replaced rockbox.sansa with thumb built, but some codecs didn't play well 22.12.56 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.16.34 # aac is between 0.92% and 1.88% slower, cook bugs, mpc 0.09(!)% slower, wma 0.37(!)% faster, mp3 is the same, mpc 0.09(!)% slower 22.16.54 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 22.18.46 Join DataGhost_ [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 22.18.46 Quit DataGhost (Disconnected by services) 22.18.47 Nick DataGhost_ is now known as DataGhost (~dataghost@17-18-ftth.onsnetstudenten.nl) 22.21.34 # is it worth profiling to see which codecs api functions are slowed/enhanced ? 22.21.52 # not for 0.09% I'd say 22.22.25 # also to see where the 2% slower comes from 22.22.29 # and what makes wma faster 22.24.42 # gevaerts: I'm done with apps/ I think 22.26.28 # maybe huffman decoding is faster on WMA in thumb mode 22.26.53 # thats basically just load, shift, store, etc 22.27.03 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 22.27.21 Quit elinenbe (Read error: Connection reset by peer) 22.27.27 # saratoga: but huffman is in the codec, i only changed rockbox.sansa 22.27.45 # even codeclib is built in the .codec 22.28.00 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 22.28.35 # ah sorry misunderstood 22.29.36 # kugel: Nice!. Now firmware? 22.29.50 # yea 22.30.09 # That shouldn't be too much either I think 22.30.20 # mainly dircache and other file related things? 22.31.41 # haven't grepped yet 22.33.00 # some ifdefs are in files I'm sure we won't compile in RaaA 22.34.31 # backlight.c for instance 22.34.41 # right 22.35.46 Quit lpereira (Quit: Leaving.) 22.37.44 Quit guymann (Ping timeout: 252 seconds) 22.38.15 Join guymann [0] (~charlie@69.182.31.160) 22.38.26 # kugel: actually, I think backlight.c should be able to lose all of the SIMULATOR ifdefs rather easily 22.39.56 # wodz: I'm working on optimising the greylib phase output routines; coldfire first 22.40.20 # First question - did you run test_fps.rock on the HD200 already? 22.40.37 # If so, please post your results on http://www.rockbox.org/wiki/LcdFrameRate 22.41.14 # Second thing - I do have a patch for HD200 already... after getting aforementioned baseline, it needs testing (for correctness and speed) 22.41.36 # * amiconn is fiddling with arm in the meantime 22.41.49 # It's all based on jhMikeS's idea 22.43.26 # amiconn: HD200 scored ~146fps (greylib) in test_fps.rock (but it runs boosted). About testing - post patch somewhere if I have time I'll test it tomorrow 22.43.41 # I need all data, not just plain FPS 22.43.58 # ok - I don't have device at hand now 22.43.59 # In this specific case the cpu load percentage is what's most important 22.44.46 # (because that is what the patch should reduce - it will also increase fps a bit if the isr load reduction is significant enough) 22.45.31 # On iriver H1x0, isr load is reduced from 41% to 37% unboosted, and from 19% to 17% boosted 22.48.14 Quit S_a_i_n_t (Read error: No route to host) 22.50.02 # Hmm, the latter I obviously remember wrong 22.50.19 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.19) 22.53.54 # Llorean, does http://forums.rockbox.org/index.php?topic=10030.msg167580 fit your description? 22.53.58 # amiconn: which PP don't use lcd-as-memframe.S ? 22.54.17 # funman: http://img197.imageshack.us/img197/2202/dscf5461p.jpg 22.54.34 # funman: Many... 22.54.44 # wodz: nice, you want me to test on clip? 22.54.50 # Afaik e200v1 is the only PP which does use it 22.54.57 # amiconn: nice, e200v1 didn't boot when built with thumb 22.55.14 # perhaps on other targets the lcd worsk before the undefined instruction 22.55.16 # I would expect such effects 22.55.33 # funman: fuze rather 22.55.57 # Many .S files return using ldm, which doesn't handle interworking on armv4t 22.56.29 # amiconn: well supposedly the one in lcd-as-memframe.S was fixed in this build, many parts of the code don't handle interworking 22.56.51 # i'm checking them all and will post a patch on flyspray 22.57.31 Quit bmbl (Quit: Bye!) 23.00.27 Quit wodz (Quit: Leaving) 23.02.05 # I have r18607. Well, it's working, but current stable build is r26416 so I think there's some improvements. 23.04.19 # wow, that's almost 2 years old 23.04.47 Quit S_a_i_n_t (Ping timeout: 240 seconds) 23.05.47 # bluebrother: I'm also consider to buy a Sandisk Sansa Clip+ now cause my iPod can't last forever and I can't go back to non-Rockbox. 23.06.25 # amiconn: can you explain the 3rd line in thread.c::load_context() for ARM ? it was added in r14879 for dual core 23.06.45 # %0 points to start of thread context struct, which is the saved registers 23.07.12 # ldm %0 { r0, pc } will load saved r0 in r0 and saved r1 in pc <- why r1, and not [%0, #40] ? 23.07.27 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 23.08.44 Quit GeekShadow (Read error: Connection reset by peer) 23.08.50 Join Highlander_ [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 23.09.16 # e.g. why does it load thread_entry->context->r[1] in pc 23.09.39 # jhMikeS is the thread.c expert nowadays... 23.09.46 # okay 23.10.14 # it's r4/r5 btw not r0/r1 23.12.03 Quit Highlander (Ping timeout: 240 seconds) 23.17.34 # jhMikeS: ping ^ 23.24.49 # funman: yessir? 23.26.28 # can you explain the 3rd line in thread.c::load_context() for ARM ? it was added in r14879 for dual core 23.28.48 # it may have been optimized a bit, but I don't think it was changed to support it. It goes to start_thread. 23.29.38 # start_thread calls the real entry as defined in create_thread 23.31.31 # if there were an issue there, I doubt rockbox would run on any ARM...but, what is the concern? 23.32.06 # something with thumb code? 23.32.19 # it's how i came to this yes 23.32.26 # the 3 first lines are equivalent to: 23.32.40 # thread_entry *t = addr; 23.32.49 Quit petur (Quit: Zzzzz) 23.33.17 # if (t->context->start) { 23.33.28 # r0 = t->context->r[0]; 23.33.33 # pc = t->context->r[1]; 23.33.36 # } 23.33.37 # ? 23.36.06 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100423140709]) 23.36.36 # funman: yes, look at THREAD_STARTUP_INIT 23.36.52 # aaah ok 23.37.07 # now it makes sense ;) 23.37.49 # FS#11335 - Make ARM assembly functions thumb-friendly 23.39.48 # is there a speed gain from it? 23.39.49 # * funman slaps self - should test patches before posting them 23.40.11 # jhMikeS: see the other task : FS#6734 23.40.55 Quit Topy44 (Quit: No Ping reply in 180 seconds.) 23.42.00 Join Topy44 [0] (~topy@my.fastsh.it) 23.42.39 # funman: why "no effect on newer cpus"? 23.43.00 # same number of cycles 23.43.16 # New commit by 03bertrik (r26417): Update Samsung YP-S3 bootloader demo 23.43.40 # but, it can reduce the amount of instruction cache missed, maybe 23.43.46 # funman: but there's 1 instruction more, why is that free? 23.44.05 # kugel: ldm doesn't take same number of cycles if you load pc or not 23.44.19 # jhMikeS: wouldn't it increase it, if functions are bigger? 23.44.22 # ah ok, I didn't know that 23.44.53 # funman: that's what I meant, thumb could help a bit, even if the instructions are still they same cycle count 23.45.19 # jhMikeS: ah for thumb, yes but the effect is small on the codecs 23.45.34 # loopy code? 23.45.37 # the patch works btw 23.45.44 # loopy? 23.45.59 # funman: do you think the e200v1 build is fixed with the new patch? 23.46.00 # lots of repetitive execution in the codecs 23.46.25 # more like important code is not built in thumb 23.46.28 # kugel: dunno 23.46.39 Quit Topy44 (Client Quit) 23.47.37 Join Topy44 [0] (~topy@my.fastsh.it) 23.48.27 # funman: if anything is ARMv6, don't worry about changing the instructions. it always sets T if the pc is loaded 23.48.55 # jhMikeS: yes, i have put that in the task description 23.49.03 # ARMv5 works too 23.49.28 # ah, even ARMv5 does it right 23.50.03 # i'm not sure about mov pc, lr 23.50.18 # i've read that it works only on armv7 23.50.25 # probably in the docs 23.50.35 # but we use that in nrv2e code for mkamsboot on armv4t and it works 23.51.09 Quit merbanan (Ping timeout: 248 seconds) 23.52.09 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.52.29 # armv6 docs say you have to use 'bx lr' 23.52.45 # jhMikeS: I've found a way to apply your nice optimisation in lcd-as-gray.S so that it works on mini2g as well 23.52.55 # mov pc, lr restores the spsr into cpsr 23.53.02 # No speedup there because the serial lcd i/f is the limiting factor 23.53.22 # amiconn: does it speed up the other at least? 23.53.32 # No slowdown though, and less binsize. Also, smaller ifdefed code blocks in the .S file 23.54.02 # Yes. On my G2, it reduces ISR load (without GREY_ON_COP) from 33% to 30% 23.54.39 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 23.54.53 # not bad I guess esp. if it's at worst not a loss for mini2g 23.56.05 # I implemented a similar trick on CF (H1x0, M5 and HD200 first), using mulu.l instead of all this or'ing 23.57.35 # kugel: http://rafael.carre.perso.sfr.fr/rockbox.zip (e200v1) 23.58.25 Quit bertrik (Quit: De groeten)