--- Log for 02.05.110 Server: bartol.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 13 hours ago 00.02.22 # Strife89: oh, a patch to move some C standard library into a separate subdir, so that OS libraries can be used instead of our own 00.08.29 # strpcasecmp == strcasecmp? 00.09.17 Join ollebe [0] (~olle@root.rot.sgsnet.se) 00.10.02 # kugel: what is the solution to the fprintf problem ? 00.10.18 Join Unhelpful [0] (~quassel@71.173.205.32) 00.10.18 Quit Unhelpful (Changing host) 00.10.18 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 00.10.39 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 00.10.55 Quit dfkt (Disconnected by services) 00.11.00 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 00.11.21 # kugel: yes strpcasecmp seems to be a locally implemented strcasecmp 00.11.35 # well, it's a macro expanding to our fdprintf (which takes a file descripter, not a FILE * stream). fprintf is called only stderr which is mapped to an fd instead 00.12.26 # ... from before it was in the plugin.h one might presume 00.12.55 *** Saving seen data "./dancer.seen" 00.22.17 Part Moguta 00.22.50 Quit MuscleNerd (Read error: Connection reset by peer) 00.27.24 # So, telechips bootloader, doesn't seem to work so good. Built iAudio 7 bootloader, modified the main() function to just change GPIO port C, but I have zero response on those pins. Do I need to do anything with bootloader.bin other than use tccboot? 00.27.54 Join MuscleNerd [0] (eric@adsl-75-16-57-151.dsl.irvnca.sbcglobal.net) 00.29.32 # My telechips CPU is a newer version of the 77X series from what I've compared in the spec sheets, with the IO addresses on the 8200 being remapped so many bits higher (0x80003020 for port C instead of 0x80000320 in the 77X series) 00.30.12 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 00.31.45 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 00.31.49 # I am really bummed with SDL Audio right now. 00.32.21 # I want it to ... behave! 00.32.58 # I don't think it's right to go with a different architecture just because the sim doesn't act like the target. 00.33.33 Quit halmi_ (Read error: Connection reset by peer) 00.34.22 Quit pamaury (Quit: Quitte) 00.35.21 Join halmi [0] (~netbook@188-22-114-197.adsl.highway.telekom.at) 00.36.55 # Blue_Dude: crazy stuttering? 00.37.06 # I tihnk thats the same issue I had which made me give up :/ 00.37.20 # The SDL callback doesn't work the same way as the target. 00.37.55 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 00.38.11 # And it insists on creating a 44112 byte buffer no matter what you ask for. 00.39.11 # It doesn't behave like a real DMA ISR callback so I'm kinda screwed. 00.42.42 # All this begs the question: if it needs a workaround to get the sim to work, is it worth doing at all? 00.43.11 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-divqxufwzqjtwtgv) 00.43.43 # Blue_Dude: did you ask the SDL people about it? 00.44.18 # One possible solution is a way to get the sound.c driver to sleep for a tick or so. But I tried it and it bombed. I think sleeping that thread was a bad idea. 00.44.45 # RandomInsano: are you sure you've got everything linked correctly for the new CPU? 00.44.46 # saratoga: not yet. I spent a good part of the day away from the internet trying to get it to work. 00.45.33 # And it seems to be an SDL issue. Maybe I just don't know enough about it to get it to behave. Or maybe it's a Cygwin thing. :( 00.46.41 # hard to believe the SDL buffer sizes are hard coded 00.46.41 # Blue_Dude: it is definitly worth doing, even if SDL needs special casing 00.47.21 # I don't think it's hard coded. It's just that the lib function has a lot of latitude to decide what's best given the hardware. 00.47.49 # JdGordon: I think this is beyond special casing. I'm not sure it'll work at all on the sim. 00.48.26 Join Xqtftqx [0] (~Xqtftqx@d118-75-250-46.try.wideopenwest.com) 00.49.05 # Blue_Dude: don't people do games in SDL? how could a 1/4 or 1/8 second buffer be acceptable for all cases? 00.49.10 # there must be a way to change it 00.49.16 Join Chern [0] (~Chern@78.150.144.205) 00.49.17 Join n00b81 [0] (~185b52cd@gateway/web/freenode/x-sfccbafswtwhibcz) 00.49.26 # 'lo 00.49.29 # * Xqtftqx is listening to: Fort Minor - The Rising Tied - Remember The Name (feat. Styles Of Beyond) - (0:17/3:50) 00.49.34 # Good song 00.50.01 # Xqtftqx: Please turn that off in here 00.50.11 # y? 00.50.22 # This is an on-topic channel only 00.50.31 # We don't want to know what you are listening to 00.50.39 # O, im sorry 00.50.48 # Beats me. There has to be a way around it. I tried changing the way the audio channel was init'ed but it didn't seem to have any effect on buffer size. 00.50.59 # * Xqtftqx is listening to: Ke$ha - Animal - Take It Off - (0:04/3:35) 00.51.01 # that better? 00.51.08 # Xqtftqx: Stop it now 00.51.33 # Xqtftqx: stick by the rules mate 00.51.53 Quit kisak_ (Quit: Lost terminal) 00.53.35 # AlexP, what kind of songs do you like? Rockbox is for music players, so i believe its relevant 00.53.41 Mode "#rockbox +o AlexP" by ChanServ (ChanServ@services.) 00.53.55 # Xqtftqx: Last warning. Stay on topic or leave (or be muted) 00.54.28 # Xqtftqx: this is for development chat, not user preferences 00.54.37 # Chern: And support :) 00.55.01 # Im sorry. 00.57.06 # AlexP: that is a rather bad mix 00.57.19 # It seems to work quite well usually 00.57.38 # And it doesn't separate the devs from users which we don't want 00.57.46 # i've wanted different channels for a while since it makes skimming the logs a lot easier, but most people don't 00.57.56 # aah, I guess that is alright for small developments 00.57.57 # I don't see why not. 00.58.13 # One argument is that you end up having to read both anyway 00.58.22 # As quite often stuff moves between areas 00.58.51 Mode "#rockbox -o AlexP" by ChanServ (ChanServ@services.) 00.59.00 # so do you work for your own enjoyment? or do you slave for the users? 00.59.01 # support topics often turn into development topics, so it makes going through logs harder as you would likely have to go back and forth 00.59.46 # Chern: Hard to speak for everyone, but principally for ourselves 00.59.58 # devs are slaves to their own improvement requests. 01.00.00 # Chern: Of course we do care about users, but not as the be all and end all 01.00.17 # i.e. if users want something the devs don't, then the devs win :) 01.00.51 # And it depends on the person of course :) 01.01.22 # Blue_Dude: you hold a strong opinion 01.02.05 # Merely ironic commentary. Don't consider it too deeply. 01.02.49 # I was thinking of porting rockbox to the Playstation Portable, has anyone attempted to do such a thing 01.02.58 # Nope :) 01.03.12 # It wouldn't make much sense as is IMO, you would want it as an app 01.03.22 # well rockbox isn't an app, is it? 01.03.27 # Nope 01.03.33 # It is a complete firmware/OS 01.03.41 # indeed 01.03.42 # Rockbox is an operating system. 01.03.48 # thats an OS 01.04.10 # Yeah, so using it as an OS wouldn't make much sense on the PSP IMO 01.04.12 # is there any reason to run rockbox as an app on the PSP though? 01.04.20 # it seems like a good firmware replacement target 01.04.25 # indeed 01.04.27 # But e.g. the simulator runs on a PC as an app 01.04.28 # thats how those hacked media players on the gameboy work 01.04.40 # saratoga: Oh, as a dual boot? 01.04.42 # use the built in software as a bootloader basically 01.04.53 # I'm displaying my PSP ignorance here 01.05.06 # well that the DS not the PSP, but hardware wise they're not entirely different 01.05.14 # yes they are 01.05.17 # I thought of it more as a platform, but I guess that isn't quite true 01.05.25 # unless you really want networking while you're playing music i'm not sure what the app option gets you 01.05.37 # yeah 01.05.48 # actually i've always wanted to do a nintendo DS port of rockbox, but never really had the time 01.06.15 # well, I was hoping someone would have done it already 01.06.37 # replaced the onboard firmware os thingy to the rockbox 01.06.49 # faster loading times and more features 01.07.35 # http://sites.google.com/site/linuxonpspproject/ 01.07.42 # these guys have a tool chain and drivers for the PSP 01.07.57 # That's not complete at all 01.08.13 # Most of the drivers haven't been RE'd yet. 01.08.36 Quit rbert (Ping timeout: 276 seconds) 01.09.03 # driver? 01.09.13 # so many warnings with when using the __attribute__((format)) feature of gcc :\ 01.09.13 Nick bgs100 is now known as bgs000 (znc@unaffiliated/bgs100) 01.09.21 # Chern: to talk to the hardware 01.10.08 # whats missing? 01.10.15 # drivers 01.11.02 # for what? 01.11.12 # * AlexP seems to be constantly misunderstanding Chern 01.11.34 # Chern: I thought you must be non-English first language and not know the word :P Sorry :) 01.11.54 # Yeah sorry 01.11.57 # I'm Scottish 01.12.09 # Nearly as bad :) 01.12.21 # well, "driver" is more of a technical term than and English word 01.12.35 # Depends on the language 01.12.42 # It is often translated 01.12.52 # But yes, I would expect most people to know it 01.13.07 # we are taught that a driver is a car operator 01.13.49 # Anyway, we are creeping off-topic 01.14.17 # yes, shouldn't probably do that 01.14.22 # Aw, what the bloody hell? 01.14.32 # Why are we *mixing* in SDL audio? 01.14.45 # is there a MIPS port of rockbox existing? 01.15.02 # It runs on a MIPS target, yes 01.15.04 Quit ender` (Quit: You don't have to think too hard when you talk to teachers. -- J. D. Salinger) 01.15.15 # but there is more to it than the arch 01.15.16 # Chern: such as the gigbeat 01.15.23 # gigabeat is ARM 01.15.32 # uggh :P 01.15.33 # AlexP: I realise this 01.15.48 # sure :) 01.15.54 Nick bgs000 is now known as bgs100 (znc@unaffiliated/bgs100) 01.16.13 # AlexP: but it makes starting the port a bit easier ;-) 01.16.46 # what? 01.16.55 # the hardest part would be breaking the chain of trust in the system 01.17.22 # i think thats already done 01.17.32 # as evidenced by the linux port 01.17.38 # from boot 01.17.57 # The linux port is an app. 01.18.08 # there is the existing flaw in which they initialize a checksum with a value of 0 in the IPL page 01.18.09 # That just runs via a custom firmware environment. 01.18.49 Join Silverwolf [0] (~richard@d149-67-106-191.col.wideopenwest.com) 01.19.05 # does rockbox make use of a MMU? 01.19.31 # Chern: no 01.19.38 # n00b81: what does that mean? 01.19.44 # thats good, as there isn't one 01.19.55 # Blue_Dude: you could try my alsa pcm driver shows the same behavior 01.20.05 Quit Silverwolf (Client Quit) 01.20.17 # alsa? 01.20.22 Quit geertvdijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 01.20.32 # saratoga: it's a boot controlled via hybrid or C-IPL firmware 01.20.42 # removes DRM for unsigned code 01.20.49 # http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/alsa-sim 01.21.41 # What is it? 01.22.04 # hm, forget it, I don't think alsa is going to work on cygwin 01.22.04 # Is there a list of what rockbox requires hardware wise? 01.22.19 # or can someone give me a rough idea 01.22.28 # Chern: couple dozen MHz, couple MB of RAM, storage space for music 01.23.04 # anything more specific? 01.23.10 # nothing else comes to mind 01.23.19 # i guess a compiler if you want to be able to write code 01.23.23 # kugel: I just need a real devel enviroment. :( 01.23.24 # what about a speaker? 01.23.27 # but thats kind of obvious 01.23.36 # i don't think any rockbox devices have a speaker, so no 01.23.53 # some ondas have a speaker and it's enabled 01.24.11 Quit Unhelpful (Remote host closed the connection) 01.24.12 # aah 01.24.20 # so rockbox is only for small machines? 01.24.37 # yes, you may want to look at our front page if you haven't . . . 01.24.43 # we're a firmware for mp3 players 01.25.02 # aah, sorry I thought it was for real machines 01.25.42 # * gevaerts looks at his DAPs. They look real... 01.27.30 # * Chern looks at PS3 01.32.45 Join Unhelpful [0] (~quassel@71.173.205.32) 01.32.45 Quit Unhelpful (Changing host) 01.32.45 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.34.03 Quit n00b81 (Ping timeout: 252 seconds) 01.35.42 # turns out i was wrong about the storage in E10 01.35.59 # if anyone is interested, the SoC has 8 Mbit of NOR flash 01.36.16 # thats just ROM, it won't really matter for rockbox 01.36.41 # how can you be so sure? 01.37.04 # what use would we have for memory we probably can't write to and is too small to store anything we would want to write? 01.37.49 # maybe someday you would want to write your own bootloader to it to replace the OF one if theirs have some flaw, but most targets don't even bother doing that 01.37.58 # i'm trying to figure out the original firmware, and I think an additional 8mbit of flash is relevant 01.38.28 # the firmware has to be stored somewhere, and this is one place where a part of the firmware might reside 01.38.46 # its probably just their bootloader 01.38.58 # 1MB is too small for firmware on typical players 01.40.21 # saratoga: Lots of targets have the full firmware in NOR, so it can be important - we need to insert our bootloader there (e.g. the h1x0, h3x0). 01.42.20 # i didn't say none did it, just that most don't 01.42.51 # * ollebe goes back to the disassembler 01.44.09 # arghhhh 01.44.10 # how does installing work on the hx00? 01.44.45 # Our bootloader is merged with an OF upgrade file, and then the OF is used to flash it to NOR. 01.45.05 # ah so like the sansas 01.45.24 # * Blue_Dude beats head against SDL code. Cries. 01.45.32 # kugel: alsa won't, but you can maybe use alsalib with win32 pcm output, though I don't know why 01.45.38 # saratoga: Which ones? 01.45.55 # AMS at least, PP too I think 01.46.12 # although its technically a NAND flash chip it goes on 01.46.22 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 01.46.24 # since NOR isn't so popular anymore 01.48.01 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 01.48.59 # Yes, similar to AMS. PP is different - both the bootloader and OF are stored on the NAND, and sansapatcher replaces the OF completely with our bootloader, and moves the OF image somewhere else in the firmware partition so we can dual-boot. 01.51.08 # oh ok 01.51.42 # why does friendlyzookeeper have 76 of his 81 posts deleted 01.52.32 # Oh FFS. is SDL just hosed in Cygwin or does anybody else have this problem?! 01.53.12 # You'd think the SDL.dll would work the same as the lib, right? 01.53.58 # RandomInsano: just because it links doesn't mean any of the addresses are correct 01.54.19 # are you sure you've actually put your code into system RAM where the system will execute it? 02.01.03 # OK, I'm done. Anyone know how to get hold of the SDL guys? I'm totally stuck. 02.01.50 # Are we working with anyone there? 02.03.06 # i don't think so 02.03.13 # but presumably they have a mailing list or an IRC channel 02.03.18 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 02.03.28 # its a pretty widely used package 02.04.16 # saratoga: I have no idea. TCC77X RAM location is exactly the same as the TCC8200 02.04.39 # I don't actually know how rockbox does anything really. 02.04.39 # you should probably compare to the OF and check then 02.05.08 # I can barely read assembler. It's inital jump is in the 0x20000000 address space. 02.05.39 # The datasheet confirms where system RAM starts by defaly 02.05.41 # *t 02.06.16 Join Rob2223 [0] (~Miranda@p4FDCB2FD.dip.t-dialin.net) 02.06.23 Quit petur (Quit: Zzzzz) 02.06.28 # i wouldn't trust the datasheet 100%, nor would I assume that the rockbox binary has been made correctly 02.06.33 # either could be wrong 02.06.58 # alternatively, you could try patching the OF with your code to verify that the GPIO pins work the way you think they do 02.07.03 # Then here's the fun problem: how do I find out? 02.07.38 # How can I patch the original firmware? Plunk some compiled assembler then change the original telechips jump call? 02.07.45 # yeah 02.07.58 # RandomInsano: The telechips bootloaders can be built in two ways - either to run as standalone, or to be appended to the OF. I'm not sure what the default is for the iaudio 7... 02.08.05 # That'll be fun to figure out... Any docs to guide me? 02.08.35 # linuxstb: What's the default on your telechips port 02.09.02 # The source is the documentation... I'm just looking now. 02.09.10 # And how can I find out the differences? There isn't a lot of documentation on how everything bulds and compiles 02.09.37 # Sigh. SDL isn't ever going to work the same way as the target hardware. SDL is double buffered and requires the buffer to be full before the callback ends. Since my design requires the hardware to actually DMA, I think we're stuck. 02.09.47 Quit Rob2222 (Ping timeout: 265 seconds) 02.10.50 # All telechips ports seem to at least share the same telechips.c bootloader. I just don't know what the different targets do with the object file created. 02.10.59 # RandomInsano: It looks like the iaudio 7 is built to be appended to the OF. So there is a good chance it will just crash if you try running it now. 02.11.04 # soo, I finished my work so far 02.11.12 # does anyone want to have a look? 02.11.13 # Oooooh. Well, that sucks. 02.11.15 # RandomInsano: The main telechips code is in firmware/target/arm/tcc77x/ 02.11.52 # I've edited the defines to point to the right hardware address for my chip in... tcc77x.h 02.11.56 # RandomInsano: The very first code that is run is crt0.S - you should start by reading that. 02.12.09 Quit DataGhost () 02.12.11 # make sim use host C library: http://pastie.org/942001 02.12.24 # I'm going to have to either go with the current mix in place scheme and abandon just in time mixing. Or have huge mix buffers on the target. Or have really clumsy custom tweaks for the sim. 02.12.28 # I mucked with that a little as well. Can I write my ASM code in there then? 02.12.49 # I'll throw in an infinite loop and stuff. Writing assembler for me is a lot easier than reading it :P 02.12.51 # What a royal pain. I'm off. 02.12.56 *** Saving seen data "./dancer.seen" 02.13.00 # Back Monday! 02.13.37 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 02.13.49 # RandomInsano: If you want to just build a simple standalone binary (i.e. not one that should be appended to the OF), undefine TCCTOOL in firmware/export/config/iaudio7.h 02.14.13 # Undefine it? That's counterintuitive :S 02.14.24 # But I'll give that a shot 02.14.36 # I have to run. Thanks for the help. I'll try it later tonight 02.15.07 Quit CGL (Remote host closed the connection) 02.15.15 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 02.15.32 # RandomInsano: The first thing I would try to do though is to get dual-boot working - i.e. just make your code start the original firmware unconditionally. Then add a small delay before starting the OF, to confirm your code is running OK. 02.17.05 Quit Kupop (Ping timeout: 240 seconds) 02.19.04 Quit RandomInsano (Ping timeout: 264 seconds) 02.19.04 Quit mikroflops (Ping timeout: 246 seconds) 02.24.54 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 02.32.52 # New commit by 03wincent (r25769): pdbox: Fixed loading of sound files, pdpod_drums.pd works now. 02.33.38 # * linuxstb does a double-take... 02.44.35 Quit archivator (Ping timeout: 265 seconds) 02.50.37 Quit halmi (Read error: Connection reset by peer) 02.51.47 Quit matsl (Quit: Leaving) 02.51.58 Quit efyx (Remote host closed the connection) 02.54.03 # saratoga: can I close your raaa task or should I put my work into that one? 02.54.11 # kugel: just close mine 02.55.04 Join wincent [0] (~wincent@g227008032.adsl.alicedsl.de) 02.58.18 Quit wincent (Changing host) 02.58.18 Join wincent [0] (~wincent@rockbox/developer/wincent) 03.00.32 # I must have missed something. pdbox? 03.04.56 # last years soc project 03.05.27 # :-) 03.07.31 # At last, after a months-long bug hunting session. 03.13.32 # http://www.rockbox.org/tracker/task/11234 03.21.37 Quit Xqtftqx (Read error: Connection reset by peer) 03.23.51 # it's a bit funny that iriver seems to link files from kernel.org's fdisk in this firmware 03.24.29 # i remember complaining via email a long time ago, since it should be a GPL violation 03.25.10 # the source file from fdisk seems to be GPLv1 03.28.02 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 03.51.35 Quit mirak (Quit: Ex-Chat) 03.53.07 Join kugel_ [0] (~kugel@g231224082.adsl.alicedsl.de) 03.53.24 Quit kugel (Disconnected by services) 03.53.27 Nick kugel_ is now known as kugel (~kugel@g231224082.adsl.alicedsl.de) 03.53.32 Quit kugel (Changing host) 03.53.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 03.56.26 Quit Rob2223 (Quit: Rob2223) 03.57.38 Join Rob2222 [0] (~Miranda@p4FDCB2FD.dip.t-dialin.net) 04.00.34 Quit Chern (Read error: Connection reset by peer) 04.00.36 Join CGL [0] (~CGL@190.207.188.162) 04.02.55 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 04.03.22 Quit adnyxo (Read error: Connection reset by peer) 04.03.50 Join Barahir_ [0] (~jonathan@gssn-5f75597b.pool.mediaWays.net) 04.07.06 Quit Barahir (Ping timeout: 248 seconds) 04.09.59 Join www [0] (~www@adsl-68-123-102-26.dsl.scrm01.pacbell.net) 04.12.57 *** Saving seen data "./dancer.seen" 04.13.53 Part www 04.15.04 Join rbert [0] (~quassel@95-90-160-27-dynip.superkabel.de) 04.19.32 Quit amiconn (Disconnected by services) 04.19.34 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.19.43 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.19.43 Quit pixelma (Disconnected by services) 04.19.56 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.20.03 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.23.53 Quit rbert (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 04.24.41 Quit Rondom (Disconnected by services) 04.24.58 Join Rondom_ [0] (~quassel@dslb-084-057-134-069.pools.arcor-ip.net) 04.29.22 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 04.30.08 # New commit by 03kugel (r25770): Fix wrong udelay logic that made it be way off. 04.44.49 # New commit by 03jethead71 (r25771): Do some SPC codec optimizing for ARMv6 (as a training exercise), tweak realtime BRR for all CPU that use it, add Gaussian ASM optimization for all ARM ... 04.45.58 Quit wincent (Ping timeout: 260 seconds) 04.47.09 Quit The_Seven (Ping timeout: 260 seconds) 04.48.24 # jhMikeS: the speed up on the F is due to the UNLIKELY macros? 04.48.51 # hmm no you added a lot of ARMv4 ASM too 04.50.37 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.51.37 Quit kugel (Remote host closed the connection) 04.55.14 # saratoga: there was some gain from the macros. The new ASM seemed like most of it for < v6 04.55.40 # whats the advantage of ARMv6? 04.58.29 Join n1s [0] (~n1s@rockbox/developer/n1s) 04.58.57 # getting things done in fewer instructins and taking advantage of piplining for sure 04.59.24 # i was wondering which of the instructions distinquish it from armv4? 05.01.01 # all those funny-looking :) multiplies, packs and saturates. lots of stuff. 05.04.46 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 05.08.55 # saratoga: libmad dct32_arm.S and synth_full_arm.S is about as wrong as it gets for stalling it out (or is it *right* IF you want it stalling? :). 05.09.10 # jhMikeS: yes I had a feeling about that 05.09.28 # its probably written for ARM7TDMI where everything stalls anyway 05.09.49 # loads and muls need to be interleaved properly I guess? 05.09.57 # mults and loads have result latencies but can be one or two cycles throughput 05.10.09 # saratoga: indeed they do 05.10.20 # any interest in looking at it? 05.10.25 # even shifter operands, which count as early registers 05.10.45 # I was looking at it, noting its lack of commentary. :) 05.11.49 Quit Unhelpful (Remote host closed the connection) 05.12.34 # i also wonder if the filterbank really needs to accumulate into a 64 bit variable 05.14.36 Quit GeekShadow (Read error: Connection reset by peer) 05.15.13 # I don't believe colfire does, nor can it anyway. Probably uneeded 05.15.42 # but, you have to if the adds would exceed 32 bits 05.17.00 # armv6 has 32x32->64 and truncate to MS 32 but older ARM doesn't 05.19.11 # so it would have to be a mul then a shift anyway? 05.19.28 Quit phanboy4 (Read error: Connection reset by peer) 05.21.03 # yeah, older arm has no fractional instructions, which I momentarily forgot about. 05.24.07 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 05.28.44 Quit n1s (Quit: Lämnar) 05.32.17 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 05.32.49 Quit Unhelpful (Remote host closed the connection) 05.34.38 Join JdGordon_ [0] (~jd@175.35.72.36) 05.34.38 Quit JdGordon_ (Changing host) 05.34.38 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 05.40.47 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 05.41.14 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 05.41.57 Quit JdGordon_ (Quit: Bye) 05.44.34 Join Unhelpful [0] (~quassel@71.173.205.32) 05.44.35 Quit Unhelpful (Changing host) 05.44.35 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 05.46.03 Quit Unhelpful (Remote host closed the connection) 05.54.49 Join Unhelpful [0] (~quassel@71.173.205.32) 05.54.49 Quit Unhelpful (Changing host) 05.54.49 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 06.03.56 Nick bgs100 is now known as bgs000 (znc@unaffiliated/bgs100) 06.12.35 Quit robin0800 (Remote host closed the connection) 06.12.59 *** Saving seen data "./dancer.seen" 06.20.11 Quit Rob2222 (Read error: Connection reset by peer) 06.20.44 Join Rob2222 [0] (~Miranda@p4FDCB2FD.dip.t-dialin.net) 06.21.34 Quit skfunnyboy () 06.32.36 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 06.37.40 Join n1s [0] (~n1s@rockbox/developer/n1s) 07.03.56 Quit CGL (Quit: Soy spammero http://wiki.n00b2hack.com.ve) 07.23.23 # does test codec still not work on the clipv2? 07.27.11 # jhMikeS: are there any restrictions on writing back to the same register you read on arm9/10/11 ? 07.27.23 # performance wise i mean 07.30.55 # oh good test_codec seems to be working again 07.33.32 Join Strife1989 [0] (~Strife89@adsl-80-130-101.mcn.bellsouth.net) 07.33.58 # saratoga: no, it's about early/late registers and interlocks between results 07.34.00 Quit Horscht (Ping timeout: 252 seconds) 07.34.57 # it's all explained in the ARM6 spec which you can get at the arm site. (which I think you need to register for now) 07.36.07 Quit Strife89 (Ping timeout: 276 seconds) 07.37.37 # i've got the docs, i'm just lazy and tired 07.37.44 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.37.56 # jhMikeS: so basically, just don't use anything immediately after multiplying or loading it? 07.38.10 # ah, ok. with 920T it's just the memory loads that stall afaiu 07.38.12 # FWIW i've only got ARMv5 targets handy 07.38.22 # i think the multiplier does too 07.38.46 # at very least since its 2 cycles latency on a multiply, theres probably an extra stall if you try to use it immediately 07.38.59 # the shifter operands can stall too 07.39.10 # yes 07.39.31 # wait at least the result latency if possible 07.39.45 Join gabe565 [0] (~gabe@ip68-12-136-167.ok.ok.cox.net) 07.40.18 # of course things like the accumulator for an mla are late registers and aren't used immediately, so that can subtract a cycle 07.40.37 Part gabe565 07.40.54 # whats a late register? 07.42.29 # there's the early registers, which are needed upon issuing the instruction, and the late registers, usually result registers that are only updated in later stages, so they're not interlocked until a result is written. each is explained in the spec. 07.43.47 # to clarify, it's specified on a per-instruction or operand type basis 07.44.08 # ah ok so basically the late registers are just things that only need to be ready by the end of the op, and not the beginning? 07.44.13 # err end of the cycle 07.45.47 Join esperegu [0] (~quassel@145.116.15.244) 07.49.11 # that's how I understand it 07.50.02 # i'll try the easy things and see if it makes a difference 07.51.14 # just keep the results and the use a few instructions apart where possible. also, str has an interlock with the source register and the following instruction 07.51.43 # it doesn't have a write buffer? 07.51.53 # like str r0, [r1]. mov r0, #0 can stall 07.52.04 # it does 07.54.24 # looks like it does speed things up a bit 07.55.23 # each smlal i reorder saves us about 10kHz realtime in synth.c :) 07.55.36 # on the clipv2 07.56.04 # there's also flag cycle distance which I'm a bit confused about 07.57.08 # I guess it's the stm instruction that keeps regs locked behind it, not str 08.01.51 # * jhMikeS thinks it's a problem if mp3 decoding takes 42% of what it takes to emulate an especially intense SPC file 08.03.08 Quit xavieran (Ping timeout: 260 seconds) 08.04.07 # jhMikeS: which target? 08.05.27 # the beast. I think the actual MHz might be wrong due to automatic scaling and the plugin the the wrong value for decoding, but the proportion should hold. I'm checking that. 08.08.01 # is there any advantage to trying to issue mul right after a ldm command? i'm wondering if the multiplier can be working at the same time as long as they don't share any registers 08.08.18 # it should 08.13.00 *** Saving seen data "./dancer.seen" 08.14.48 # if I do "ldmia %2!, {r0, r1, r2, r3}", is r0 available before the other registers? 08.15.02 # hmmm...it looks like test_codec uses CPUFREQ_MAX, and constant decoding would cause it to run at 528, so 69-70MHz and about 30MHz for mp3 atm. 08.15.10 # saratoga: yes 08.15.56 Quit n1s (Ping timeout: 264 seconds) 08.16.16 Join xavieran [0] (~xavieran@ppp118-209-16-75.lns20.mel4.internode.on.net) 08.17.19 # saratoga: single cycle for the instruct but, 3,3,4,4,5,5,6 for 1st address 64-bit aligned and 3,4,4,5,5,6,6 for not 64-bit aligned 08.18.10 # wait PROD_ODDBACK_A is defined but never called 08.18.14 # why do we have this 08.18.14 # that's for ldmia rx, { r1-r7 } and not to pc. they don't seem to show it beyond 7 :\ 08.18.20 # i just spent a while rescheduling it 08.18.40 # jhMikeS: those are the cycles when they become available? 08.18.51 # yes, the result latency 08.19.06 # so the S has a 64 bit bus to L1? 08.19.36 # I don't know to be honest 08.20.12 # well if it can fetch two 32 bit words in one clock :) 08.21.48 # of course that makes sense. I've just never read it explicitly stated in a doc since I suppose it wasn't too relevant. :) 08.23.13 # huh FS#6705 already had the unused ASM code in it 08.23.18 # i wonder how that happened 08.25.56 Quit Boldfilter (Quit: Boldfilter) 08.28.17 Join n1s [0] (~n1s@rockbox/developer/n1s) 08.29.59 Join mischasworld [0] (~quassel@f050204199.adsl.alicedsl.de) 08.30.24 # FS#11235 - libmad asm tweaks for ARM9 and above 08.30.28 # very minor improvement 08.30.32 # but better then nothing 08.30.42 # how much? 08.30.49 # 200kHz on my clipv2 08.31.02 # i thought it would be more but it turns out most of the ASM i fixed isn't actually used :( 08.31.24 # i didn't touch the order of the LDM commands either, so maybe theres some further improvement 08.31.25 # ARM11's supposed to do this in 10MHz, not 30 like it is now :) 08.33.03 # its more then 10 MHz IIRC 08.33.43 # i though they claimed like 20MHz, and only by significantly sacrificing accuracy 08.33.57 # * jhMikeS remembers seeing *something* 08.34.06 # what's PP claim? 08.37.06 # http://www.mp3-tech.org/programmer/docs/mp3_wp.pdf 08.37.14 # this says 18MHz on ARM9E 08.37.38 # though since its arm ltd, i'm guessing they're using their emulator and assuming 0 latency memory 08.37.49 # rather then an actual hardware implementation with DRAM 08.38.37 # i guess turning the S clock way down would improve the total mhz since then teh DRAM would look a lot faster 08.39.35 # also I like how almost that entire PDF talks about parts of the decoder that use negligible time 08.40.19 # haha and they brag about figuring out how to do a fourier transform in nlog n time 08.40.21 # great work guys 08.40.26 # agreed, it seems perhaps it's 70-80% faster at 528 than 264. 08.41.00 # Carl Friedrich Gauss wants to high 5 you, but he can't since he figured that out 200 years ago and is now dead 08.41.15 # um...hehe 08.42.10 # "The target architecture is capable of implementing a memory load in 3 cycles and store in 2 cycles. However, by organising the data so that memory access is via consecutive addresses it is possible to achieve effective load and store operations in a single-cycle, which significantly enhances the performance of the convolution operation." 08.42.12 # woah 08.42.16 # we don't do that 08.42.20 # actually we thought that wasn't possible 08.43.04 # yes, keep dependencies spread apart in the stream I always say 08.44.36 # looking at the imdct we also don't exploit the imdct_half trick from ffmpeg, though thats probably not going to make much difference 08.45.08 # what's that? 08.45.38 # basically, the output of the imdct has middle half symmetry, so you really only need to produce half as many samples 08.45.49 # you can generate the rest when windowing 08.46.08 # but the symmetry is kind of ackward, so in reality it doesn't save you much, at least not on arm 08.46.36 # stripwax worked it out a while ago, i think you could save maybe 1 load per PCM sample produced 08.47.07 # and of course you saved memory, but since the mdct is only 36 samples for mp3, thats only 18 bytes saved! 08.47.22 # err 18*4 08.47.34 # saratoga: loading and storing multiple registers at once is a nice improvement on coldfire too (when using asm, gcc seems to never use movem by itself except for storing and loading register on the stack) 08.47.36 Join BHSPitMini [0] (~BHSPitMon@adsl-66-140-45-134.dsl.rcsntx.swbell.net) 08.48.56 # lookinag at synth_full.S, i bet reordering the imdct output wouldn't help much on arm9 since most of the ldr time is probably hidden by stalls in the multiplier anyway 08.49.19 # arm11 might gain though, since it can do much faster ldm then ldr 08.49.49 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.50.11 # n1s: i think cf could be made a lot faster for mp3, its much slower then I would expect given its hardware 08.51.11 # only marginally faster then the clipv2, in spite of having a much more powerful EMAC, and having 0 latency IRAM 08.52.20 # probabaly, yes 08.54.04 # is the CF emac single cycle for multiply accumulate? 08.55.11 # yeah 08.55.28 # it always accumulates 08.55.35 Join xilef [0] (~felix@118.172.101.156.adsl.dynamic.totbb.net) 08.55.37 # or subtracts 08.55.55 # * jhMikeS just sees alot of ldr r10... immediately followed by smlal :\ 08.56.05 # synth_full.S? 08.56.54 # yes 08.58.40 Join stoffel [0] (~quassel@p57B4D47A.dip.t-dialin.net) 09.01.18 # it says RdLo is the late reg, but it also sets the low part before the high one 09.01.27 # jhMikeS, saratoga: Yes, the arm1136 does have 64 bit access to L1 09.02.37 # Afaik the 10MHz are claimed for neon, but that's armv7 09.03.04 # neon, would be very cool 09.03.10 # s/,// 09.05.45 # well i found the paper for the DCT we're using 09.05.55 # it was apparently optimal in 1984, donno if anyone has done better since 09.07.29 Quit esperegu (Read error: Connection reset by peer) 09.07.40 Join esperegu [0] (~quassel@145.116.15.244) 09.14.59 Quit n1s (Ping timeout: 246 seconds) 09.23.41 # Iiuc the optimal implementation of (i)(m)dct depends on the architecture you're running it on 09.27.41 # true 09.28.10 # but for devices like we run on, lowest multiplication count is a pretty good proxy for being optimal 09.28.55 Quit saratoga (Quit: Page closed) 09.29.13 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.31.28 # On coldfire that's not true 09.32.03 # On coldfire, the algorithm should utilise fused multiply-add wherever possible 09.32.28 Quit xilef (Ping timeout: 246 seconds) 09.32.33 # If you look at the coldfire idct for mpegplayer (libmpeg2) you'll see what I mean 09.34.14 Join xilef [0] (~felix@118.172.93.155.adsl.dynamic.totbb.net) 09.38.44 Quit solexx (Ping timeout: 246 seconds) 09.39.18 # The armv6 implementation is based on the same idea 09.40.40 Join solexx [0] (~jrschulz@e176116112.adsl.alicedsl.de) 09.41.25 Quit S_a_i_n_t () 09.46.14 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.110) 09.48.16 # * amiconn spots a few places for optimisation in libmpeg2, both for armv6 and armv4 09.48.44 Join ender` [0] (krneki@foo.eternallybored.org) 09.48.58 # For armv4 it may be beneficial to use 32 bit ints in the idct instead of 16 bit, because it will enable us to use ldm 09.49.23 # (same thing as I've done for the libdemac filters on armv4) 09.53.55 Quit xilef (Quit: leaving) 10.06.43 Quit n1s (Quit: Lämnar) 10.07.55 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.13.03 *** Saving seen data "./dancer.seen" 10.19.04 Join flydutch [0] (~flydutch@host36-202-dynamic.15-87-r.retail.telecomitalia.it) 10.20.45 Join Kitr88 [0] (~Kitar_st@BSN-182-41-48.dial-up.dsl.siol.net) 10.22.05 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.23.01 Quit arbingordon (Quit: `) 10.24.57 Quit Kitar|st (Ping timeout: 276 seconds) 10.25.12 Quit Kitr88 (Ping timeout: 248 seconds) 10.30.34 Join Kitar|st [0] (Kitar_st@BSN-210-237-41.dial-up.dsl.siol.net) 10.38.37 Quit n1s (Ping timeout: 246 seconds) 10.42.04 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 10.46.56 Join DerPapst [0] (~Alexander@p4FE8EE90.dip.t-dialin.net) 10.48.31 Join Buschel [0] (~ab@p54A3A6E2.dip.t-dialin.net) 10.48.53 # some more comment on libmad's synthesis filter: 10.49.37 # a) the asm'ed dct32 is not optimal in terms of number of instructions. the original author stated it in the origin fs entry 10.49.46 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 10.49.54 # (do not know the fs id by hard, but should be easy to find) 10.51.06 # b) the synthesis windowing itself can be further optimized (as ffmpeg or mpc use it). for mpc r17720 gives a solution for taking advantage out of symmetries within the window 10.51.07 Quit BHSPitMini (Ping timeout: 260 seconds) 10.52.24 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.53.15 # b) r17724 that is... 10.56.58 # a) fs #6705 implemented asm'ed dct32 for libmad 11.04.25 # Number of instructions is less important than number of cycles 11.07.25 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.13.04 # amiconn: yes, but I am sure it is fine to assume more instructions is equal to more cycles in this case. the asm code was optimized for size. 11.13.55 # I once changed the libmad dct32 asm-code to fit to the mpc decoding. it was slower than the current c-implementation (compiled with -O1). 11.14.30 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.15.13 # arm7tdmi has several multi-cycle instructions. Among them are multiplies, single loads and stores 11.15.56 # yes, I am fully aware of this fact. 11.16.01 # that dct asm is probably slower than compiled c on arm cores other than 7tdmi too 11.16.31 # Mr. Someone should experiment a little 11.20.00 # the dct on coldfire uses the MUL asm macro which unfortunately hits the mac-movclr stall so that could be improved too 11.23.46 # linuxstb: seems we got a correct sdcfg for the cowon s9 - 0xa1102800 (from: http://iaudiophile.net/forums/showpost.php?p=290112&postcount=28) 11.26.07 # Stalls is what can be reduced in the armv6 idct for mpegplayer too 11.26.38 # Somehow I totally forgot about latencies when doing the current implementation :\ 11.29.27 # dfkt: That's good. Do you think I should commit it to svn? 11.34.12 # i'm tempted to commit the ipod shutdown/startup change (clear iram on shutdown, instead of doing the weird thing of shutting down via the OF's low battery handler) 11.34.40 # it seems to work more or less okay for everyone who's tried it, modulo the odd few freak ipods which weren't behaving like the rest *anyway* 11.35.30 # Torne: Yes, go for it. 11.35.36 # and the leftover-stuff-in-iram explanation does seem plausible given the limited look into the bootrom i've had 11.37.47 Join Schmogel [0] (~Miranda@p3EE22E80.dip0.t-ipconnect.de) 11.38.43 Quit bmbl (Ping timeout: 252 seconds) 11.41.32 # New commit by 03torne (r25772): FS#11149: alternative fix for ipod startup/shutdown issue ... 11.42.52 # New commit by 03dave (r25773): Add support for the Cowon S9, based on the information from http://iaudiophile.net/forums/showthread.php?t=36073 11.43.00 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 11.44.00 Quit JdGordon_ (Quit: Bye) 11.44.57 # linuxstb - that's great. i guess the "watermark" guy will want to try it soon. :) 11.49.50 # linuxstb, do you have a binary of the new version? 11.50.14 # dfkt: I'm just preparing a release now... 11.54.16 # New commit by 03dave (r25774): Take version number from SVN, or via VERSION variable in Makefile - i.e. use "make VERSION=v1.0" to build with that version number. 11.55.04 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.00.15 # dfkt: A new release for Windows is (temporarily) available here - http://linuxstb.cream.org/rockbox/tcctool-win32.zip - it will get moved to the download server as soon as I see an admin of that server here (and then I'll delete it from my site) 12.01.37 # thank you very much, linuxstb 12.08.40 Quit liar (Quit: Verlassend) 12.12.08 # hmm. i'm trying to decide how to add the "autocreate bookmarks only if bookmark file exists" feature from FS#6272, and I'm not sure what the setting value text should be 12.12.29 # "if bookmark file exists" is what the patch currently uses, but i don't like that 12.13.07 *** Saving seen data "./dancer.seen" 12.17.28 # "Only update"? 12.19.51 # hmm 12.19.55 # "if file has bookmarks"? 12.20.05 # though i guess technically bookmarks mostly apply to folders, not files.. 12.23.11 # only update/refersh existing? 12.36.15 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 12.36.23 Join petur [0] (~petur@rockbox/developer/petur) 12.37.43 Quit Buschel (Ping timeout: 260 seconds) 12.41.04 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.47.01 Join loveless [0] (~lloveless@188-195-101-189-dynip.superkabel.de) 12.48.39 Join hebz0rl [0] (~hebz0rl@dslb-088-067-215-174.pools.arcor-ip.net) 12.49.40 # heya, there! I am looking for a tutoring hand with a portaplayer port. any arm devs around? 12.50.09 Quit Unhelpful (Remote host closed the connection) 12.50.59 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 12.55.37 # just ask your question, maybe give more detail (which port etc.). Even when no dev is around currently who could answer it - the channel is logged and many stay connected and could read the question later 12.56.12 # and possibly answer it... you need to be a bit patient though ;) 12.58.08 # and we have several targets with other arm based SoC's... 13.00.43 Quit Llorean (Quit: Leaving.) 13.02.13 # loveless: What player is this? 13.03.03 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 13.05.32 Quit robin0800 (Read error: Connection reset by peer) 13.08.17 # linuxstb: pixelma: I am currently trying to wrap my head around the pp5020 platform and the original firmware/bootloader images of the e200. in parallel, I am looking into the pp6100 of the view which is the designated port target. I am currently in the advanced "is it doable?" phase, having started reversing both of the original firmware images and the original view bootloader. I feel this is the point where I counld use the hel 13.08.17 # p of an experienced rockbox/arm/portaplayer dev. :) 13.09.02 Quit mirak (Quit: Ex-Chat) 13.09.18 # loveless: So you're working on a port to the Sansa View? 13.09.36 # isn't there some initial work by obo? 13.09.45 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 13.10.05 # though I believe he hit a brickwall somewhere and seems to have vanished since :\ 13.11.00 # linuxstb: my first goal is getting the i2c portion of the arm_code.c in the e200tool to play with the view. should require only minor modifications with PROC_ID handling and device control 13.11.04 # yeah, wasn't it in last years gsoc? 13.11.14 # * linuxstb is reading through this thread - http://forums.rockbox.org/index.php?topic=13562.0 13.11.17 Quit pamaury (Quit: Quitte) 13.11.40 # loveless: Why do you need that? 13.12.03 # loveless: have you found any evidence that a similar mode exists in the view as in the sansas? 13.12.19 # where you can send code over usb and run it 13.13.11 # pixelma: the view stubs in rockbox trunk are attributed to Robert Keevil. haven't contacted him yet. 13.13.52 Join Unhelpful [0] (~quassel@71.173.205.32) 13.13.53 Quit Unhelpful (Changing host) 13.13.53 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 13.13.54 # yes, obo in IRC but I haven't seen him in a long time 13.14.02 # linuxstb: it's the fallback when flashing a faulty firmware lets you only get into manufacturing mode 13.15.50 # loveless: Yes, but I don't think you need i2c now do you? i.e. for early development you can just use e200tool to upload and run your own code. i.e. replace "arm_code.c" with your own code. 13.15.54 # ah that's very useful 13.16.01 # last logged in here over 5 months ago (doesn't mean he said something) 13.16.30 # n1s: from what i can tell its not a mode as such. there is a button combination to put the view into the mode where it accepts download of a rom image, but the current pp5020-specific code of the e200tool fails very early in the init at processor detection. the i2c code implemented there should be largely compatible except for the base address, perhaps. 13.17.41 Quit mirak (Quit: Ex-Chat) 13.18.26 # linuxstb: i am not sure i understand. i will have to look into the e200tool again to see how far it can currently access the view. 13.19.20 Join Casainho [0] (~chatzilla@bl8-23-238.dsl.telepac.pt) 13.19.38 # linuxstb: the way i see it, flashing in manufacturing mode is implemented via i2c running in a minimal rom stub that is transferred via usb. 13.19.48 Join CGL [0] (~CGL@190.207.188.162) 13.19.58 # loveless: The way e200tool works is that it firstly uploads an ARM binary (arm_code.c) using "USB boot mode". This code is specific to the older Sansas, and contains a USB driver that is then used to make a new connection to e200tool, where two-way communication happens. 13.20.08 # linuxstb: but please correct me if i am wrong there 13.20.28 # So for testing your code, you simply need to use usb boot mode to upload your code. e200rpatcher does the same thing. 13.20.51 # i.e. you can ignore most of the functionality of e200tool. 13.21.45 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 13.22.25 # linuxstb: so probably the USB code currently fails on view 13.22.34 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 13.22.39 # Yes, but my point is that it doesn't matter., 13.22.47 Quit xavieran (Ping timeout: 276 seconds) 13.23.52 # i.e. at this stage, you want a safe way to run your code on your view. "USB boot mode" (aka manufacturing mode) is simply a way to load a binary into RAM via USB, and that's a feature of your Sansa's boot ROM. This code isn't flashed. 13.24.05 # linuxstb: interesting. i am not too familiar with these processes. it's exactly why I am looking for some tutoring here. :) 13.24.57 # If I was you, I would ignore e200tool, and look at e200rpatcher. 13.25.24 # I am aware of the untouched boot rom, but from there my knowledge about the bootup goes fuzzy 13.25.45 # okay, let me look into that 13.26.43 Join anewuser [0] (anewuser@201.248.225.97) 13.26.43 Quit anewuser (Changing host) 13.26.43 Join anewuser [0] (anewuser@unaffiliated/anewuser) 13.27.48 # linuxstb: so your approch would be to come up with some testing code, push it via manufacturing mode, and see if, say, the led blinks etc. 13.27.51 # e200rpatcher basically just uploads a binary in USB boot mode which is then executed. Currently, you need to compile e200rpatcher with that binary embedded into it, but you could modify it to read it from a file. That binary will be your test code. 13.28.00 # loveless: Yes, exactly. 13.29.22 # The code e200rpatcher uploads is in bootloader/main-e200r-installer.c You compile it by selecting an "I"nstaller build for the e200r. 13.31.32 # linuxstb: okay. i might still stick to my plan of getting i2c in the e200tool working just for getting some practise. ;) you could call me an ARM noob, I guess. although i read a great deal about the platform in general, but i lacked most of the pp specifics. got some idea about the memory layout. 13.32.21 # loveless: I don't think I would do that - if you damage the boot rom, you've likely bricked your sansa... 13.33.38 # no, i don't intend to touch the bootloader. just the usb/i2c code that is uploaded into ram via usb. 13.35.23 # or am I missing something here? 13.35.34 # OK, but in my opinion your time would be better spent on other things - you don't need that code at all... 13.36.19 # I am just looking at the e200rpatcher now. will need some time to feel at home there 13.37.54 # loveless: The main function is do_patching() - which uploads the binary to your Sansa in manufacturing / USB boot mode. The binary e200rpatcher uploads is designed to modify (patch) a hidden part of the NAND disk, hence the name. 13.38.07 Quit stoffel (Ping timeout: 265 seconds) 13.41.33 Quit robin0800 (Remote host closed the connection) 13.43.47 # this may be a dumb question, but what's the difference between the e200 and the e200r build target? 13.44.34 # There isn't an e200r "main build" - the e200 build is used for both. I think the only difference is the mi4 format for the bootloader build. 13.50.00 # okay 13.57.58 Quit n1s (Ping timeout: 248 seconds) 13.59.54 Join arbingordon [0] (~w@unaffiliated/arbingordon) 14.02.29 Join stoffel [0] (~quassel@p57B4D47A.dip.t-dialin.net) 14.05.26 Nick bgs000 is now known as bgs100 (znc@unaffiliated/bgs100) 14.06.00 # I just realized that I have been mixing up manufacturing and recovery mode. it's the recovery mode that puts the bootloader in usb mode, correct? 14.07.15 # I don't think so 14.08.24 Join halmi [0] (~netbook@188-22-118-251.adsl.highway.telekom.at) 14.08.27 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 14.08.34 # did anyone notice my libc-folder patch? 14.09.00 # other than the sheer size of it? ;) 14.09.17 # loveless: Recovery mode is a feature of the main bootloader (which is stored on the NAND disk), and exposes a 16MB RAM disk via USB mass-storage. Manufacturing mode is the "USB boot mode" which e200tool uses. 14.10.18 # right, that was it 14.11.33 # kugel: I had a quick look. I only had two thoughts/questions - why did you need to change some printf sequences, and have you tested checkwps still compiles OK? 14.11.34 Join JdGordon1 [0] (~jonno@110.21.243.210) 14.11.37 Quit bmbl (Ping timeout: 252 seconds) 14.12.45 # the system's *printf exposed some warnings. I haven't checked checkwps but I was about to do it right now 14.13.11 *** Saving seen data "./dancer.seen" 14.13.21 # Are you on a 32-bit or 64-bit host? Can you test both? 14.13.28 # New commit by 03amiconn (r25775): Gigabeat S: Reduce stalling in the ARMv6 IDCT. Also save one instruction per loop, and fix comments. Speeds up fullscreen video decoding by about 5% ... 14.13.51 # I'm on 64bit, I could test 32bit in a vm 14.14.43 # but I added/enabled the gcc feature that's responsible for it for our own sprintf (and it exposed warnings too) so a target build would be a 32bit build 14.14.48 Quit JdGordon1 (Client Quit) 14.14.59 Join JdGordon1 [0] (~jonno@110.21.243.210) 14.15.20 # I thought we already used that? Or was it not being used everywhere? 14.15.55 # we didn't use it for sprintf, but panicf/splashf used it already 14.17.42 # checkwps seems fine 14.18.37 # archosav300 checkwps doesn't build correctly, but the error seems unrelated to my patch (and I'm not sure if it ever built properly) 14.19.37 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 14.19.54 # It's not part of the automated builds (afaik), so you can forget it. 14.20.02 # I doubt it works currently. 14.20.07 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.20.12 # ops, wrong branch, checkwps isn't entirely fine 14.28.23 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 14.32.02 # why does our creat() doesn't have flags? 14.32.17 Quit mikroflops_ (Ping timeout: 260 seconds) 14.32.57 # same for open() 14.34.19 # I thought we aimed for posix compatibility 14.36.21 Quit Casainho (Ping timeout: 240 seconds) 14.36.33 # has anyone got crashes when the bootup database "commit databse" splasah shuld pop up? 14.36.48 Join xavieran [0] (~xavieran@ppp118-209-16-75.lns20.mel4.internode.on.net) 14.38.39 Quit stoffel (Ping timeout: 246 seconds) 14.39.36 Quit halmi (Quit: halmi) 14.40.53 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 14.42.23 # JdGordon1: I have no crashes using r25761, but from your statement in -community, I think I should negate that previous question? 14.42.32 Quit JdGordon1 (Ping timeout: 264 seconds) 14.43.04 # Um, anyway, FYI r25761 is fine (crashless on database init for me at least.) 14.44.25 Join wincent [0] (~wincent@g227008032.adsl.alicedsl.de) 14.45.09 Quit wincent (Changing host) 14.45.09 Join wincent [0] (~wincent@rockbox/developer/wincent) 14.45.24 # grml 14.46.36 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 14.51.25 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 14.53.15 Quit Highlander (Quit: Quitte) 14.55.59 Quit petur (Quit: switching...) 14.56.06 Join Bullet` [0] (~Bullet@AMontsouris-159-1-90-184.w92-140.abo.wanadoo.fr) 14.56.12 Join petur [0] (~petur@rockbox/developer/petur) 14.57.25 Join komputes [0] (~komputes@ubuntu/member/komputes) 14.58.30 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.59.04 # kugel: Maybe the easiest solution is replacing any use of creat() with the equivalent open() - from the manpage, "creat() is equivalent to open() with flags equal to O_CREAT|O_WRONLY|O_TRUNC". mode appears to be optional for open(), but not for creat(). 15.00.56 # but the prototypes needs fixing too 15.01.23 # The prototypes for what? 15.01.57 Quit Kupop (Read error: Connection reset by peer) 15.02.02 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 15.02.39 Quit komputes (Ping timeout: 240 seconds) 15.02.43 # kugel: I'm not entirely convinced that moving to the host's filesystem implementation directly is a good idea 15.02.49 # * S_a_i_n_t congratulates Blue_Dude on FS#11208, acessing the hotkey is still a little tricky (you seem to need some pretty precise timing to do so), but *setting* the hotkey is a million times easier on the iPods with the revised keymap than it is using current SVN. Good work. 15.03.39 Quit DataGhost (Ping timeout: 240 seconds) 15.04.19 # gevaerts: it's not necessary for the sim (changing back should be a few lines), but I do think it's a good idea for RaaA 15.04.30 # linuxstdb: are there any functions in place in e200rpatcher and the bootloader to facilitate debugging info feedback over usb? 15.05.13 # loveless: No. You would need to find other ways until you get the LCD working. 15.05.40 # also, I didn't change the filesystem handling of the sim. it's posix, not standard c. but the sim hacks around with wrapper macros anyway 15.06.51 # kugel: I'm guessing gevaerts is referring to having an ability to obfuscate the filesystem in some way - e.g. hiding system directories from the Rockbox file browser. 15.06.57 # linuxstb: well, I can think of gpio led morse code, but, well, ... ;) 15.07.01 # kugel: maybe. I suspect that for some targets we may have to have our own layer in between anyway 15.08.16 # linuxstb: I didn't change that. the sim always used the host's filesystem api's, with wrapper calls that hide the complete FS except for the working dir 15.08.50 # loveless: The first thing I would do is to upload some code that has a small delay loop and then reboots the device. You can vary that delay loop to give different feedback. This would confirm your code is running. After that, you can try other, more useful things. 15.09.28 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.10.03 # what I changed is that the system's headers are used, which simply clashes with our not really posix compilant functions 15.10.39 # right 15.10.45 # kugel: Are you intending to keep those "sim" wrappers for RaaA? 15.10.46 Quit antil33t (Read error: Connection reset by peer) 15.10.52 # And you can't really use some system headers... 15.10.53 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.12.02 # gevaerts: we can if we change the function prototypes to be posix compliant. I thought we wanted to be posix compliant in some areas, especially in areas we claim to be 15.12.33 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 15.12.40 # linuxstb: I'm not sure yet 15.12.55 # Isn't creat() the only problem so far? 15.13.12 # I thought using $HOME instead of $PWD as root would maybe work better 15.13.40 # linuxstb: well, open lacks the ", ..." part, but the calls should fine 15.13.46 # kugel: I mean, technically it's not easy to use some stuff from /usr/include, and some stuff from elsewhere 15.13.48 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.14.52 # kugel: don't forget that .rockbox needs to be findable too :) 15.16.13 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 15.17.33 Quit M3DLG (Ping timeout: 260 seconds) 15.17.45 Quit n1s (Ping timeout: 268 seconds) 15.23.09 Quit JohannesSM64 (Ping timeout: 260 seconds) 15.23.23 # kugel: Yes, but that optional parameter to open() shouldn't affect anything should it? 15.23.34 # no, I don't think so 15.24.12 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.29.39 Quit efyx (Ping timeout: 240 seconds) 15.29.41 Quit n1s (Ping timeout: 260 seconds) 15.29.41 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 15.30.24 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 15.30.28 Join M3DLG [0] (~M3DLG@212.183.140.49) 15.30.42 # seems to work fine 15.31.46 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.32.12 # kugel: How did you deal with creat() ? 15.32.48 # only a #define to make it open() for testing purpose, running sed should be fine 15.33.37 Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) 15.33.43 Quit Xerion (Read error: Connection reset by peer) 15.33.53 Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) 15.34.12 Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) 15.35.03 # kugel: Another option would be to rename to something like file_create() so it doesn't clash with any POSIX implementation. 15.37.55 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 15.39.15 # linuxstb: do you know on what address the manufacturing mode loads the bootloader.bin? will it be mapped to 0? and can you confirm that the e200 has 8mb dram starting at 0x10000000? 15.39.25 Quit n1s (Ping timeout: 265 seconds) 15.40.54 Join gbl08ma [0] (~3ea94fdf@giant.haxx.se) 15.41.45 Quit gbl08ma (Client Quit) 15.43.39 # The e200 has 32MB SDRAM, plus (I think) 96KB of fast IRAM. I forget the details of how they are mapped at boot time, but I think we remap things ourselves in the Rockbox startup code. Let me check. 15.44.14 # linuxstb: yes, you remap dram to 0 later on 15.44.52 # I would guess that usb boot mode uploads code to IRAM but let me check. 15.44.54 # the e200tool asm_code is located to 0x40004000, iirc 15.45.07 # * kugel isn't sure how to proceed 15.45.08 # Then yes, that's IRAM. 15.50.51 # 3 opens: 1) s/creat(file)/creat(file, 0)/, 2) s/creat(file)/open(file, O_WRONLY|O_CREAT|O_TRUNC)/, 3) s/creat/rb_creat/ 15.50.58 # 3 options* 15.52.01 Quit flydutch (Quit: /* empty */) 15.52.07 # (4: band aid: remove #include "file.h" and hope creat() is never going to be called from checkwps) 15.54.03 # linuxstb: so, 0x10000000-0x12000000 is DRAM and 0x40000000-0x40018000 is IRAM 15.55.12 # kugel: I don't think 1) would work - that would create files with no (zero) permissions. So you would need to use a proper value. Which I think is why it wasn't added (I remember a discussion about this issue with creat() not too long ago). 15.56.39 # I think 3) is probably the cleanest option. I don't like the name "rb_creat()" though... 15.57.14 # loveless: Yes, I think so. With 0x0 being the NOR flash initially (IIRC). 15.57.21 Quit bmbl (Quit: Bye!) 15.58.03 Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) 15.58.18 # linuxstb: I can't find any pp-specific defintition, just firmware/target/arm/sandisk/app.lds:#define IRAMSIZE 0xc000 ... that's 48k IRAM 15.58.51 # See boot.lds in the same directory - that's the linker file for the bootloader (and the e200rpatcher "installer" application). 16.01.04 # linuxstb: how about create()? it's free :) 16.01.24 # My suggested name earlier was file_create(). I still like it ;) 16.03.08 # linuxstb: yes, flash should be mapped to 0. that's where the IVT of the original firmware has to land 16.03.12 # heh, our creat() used to be create(file, flags) (flags as in O_RDONLY, not permission modes) 16.03.44 # linuxstb: btw, do you know the flash size? 16.03.54 # kugel: Ah, that's probably what caused the discussion I remember. So the conclusion then was to remove the flags parameter completely. 16.04.29 # linuxstb: it can't have all 2gb mapped there at init time 16.04.43 # loveless: I'm not sure the e200 even has NOR flash... I've only worked with the ipods, which have either 512KB or 1MB of NOR flash. 16.04.44 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 16.05.11 # linuxstb: okay, so only the nor is mapped down there... kay 16.05.31 # loveless: This is "NOR" flash - which is memory mapped. You're confusing it with the NAND flash, which is read like a disk (one 512-byte sector at a time). 16.05.31 # linuxstd: the nand should go over the controller 16.05.46 # linuxstb: yep (/me's reading the logs right now) 16.07.08 Join Buschel [0] (~ab@p54A3E53C.dip.t-dialin.net) 16.08.32 # linuxstb: ok, I'll go for 3) 16.13.14 *** Saving seen data "./dancer.seen" 16.14.45 # linuxstb: how about fdcreat(e)? we also have some custom fdprintf 16.17.49 # btw, our mkdir has the same issue, but it expands to non-posix functions due to dircache 16.21.52 # saratoga: in libmad's synth.c both several of the arm macros can be removed. PROD_ODD_A/_O(a,b,c,d) can be replaced with PROD_EVEN_A/_O(a,b,c,d+1). PROD_EVEBACK_A/_O and PROD_ODDBACK_A/_O are not use at all. 16.22.09 # saratoga: only PROD_EVEN_A/_O is needed. 16.22.30 # I'll test and commit this clean-up later today 16.27.29 Quit petur (Quit: *plop*) 16.28.56 Quit M3DLG (Ping timeout: 246 seconds) 16.30.51 Join M3DLG [0] (~M3DLG@212.183.140.4) 16.35.09 Join halmi [0] (~netbook@188-22-118-251.adsl.highway.telekom.at) 16.37.25 Quit M3DLG (Ping timeout: 265 seconds) 16.38.13 Quit halmi (Client Quit) 16.39.54 # kugel: Our creat() and open() used to have flags, but that was removed 16.41.23 # s/flags/umode/ 16.41.57 # It makes no sense to keep a parameter that does absolutely nothing in rockbox. It only costs binsize 16.42.14 # well, wasn't it flags actually? I saw in the logs that people used to call it with O_WRONLY 16.43.06 # Flags do exist 16.43.39 # not for creat() 16.43.43 # creat(9 has no flags in posix either, 'cause it wouldn't make sense 16.49.48 # not having mode decreases portability. but that wasn't much of an issue until now 16.50.54 # Yes, but having it costs binsize for no gain 16.51.25 # You could #define things for portability. It's not that you could port a posix app to rockbox without changes anyway... 16.51.59 # I don't want to port a posix app to rockbox, but rockbox to a posix system ;) 16.52.56 # it'd be easy to have the rockbox version be #define open(x,y,z) rockbox_open(x,y) 16.53.36 # yes, unfortunately it's the other way around 16.53.54 # that's easy too, as then you'll just have a wrapper function 16.55.14 # New commit by 03amiconn (r25776): Improve motion compensation for ARM: * Use less registers in the simple copy routines -> less stack usage. * Save a few instructions in constants + ... 16.56.11 # so you're saying I should rather add 0666 to every creat() call, and do a #define open(a,b,c) rockbox_open(a,b) instead of replacing all creat() calls with file_create()? 16.56.47 Quit mirak (Remote host closed the connection) 16.57.35 # I haven't given it enough thought to say which way I prefer really... 16.58.23 # I have done the second, but I don't feel strong about it. I'd rather keep some sort of posix compliance though 17.03.52 # hm, the more I think about it the more I prefer the s/creat(file)/creat(file, 0666)/ way 17.04.27 # (though I'd use 0664 instead) 17.05.21 # kugel: no reason. This is still passed through umask 17.05.32 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 17.06.36 # I think 0664 is more appropriate, why depend on some extra mechanism to make it to 0664 for us? 17.06.55 # extra? that's just how it works! 17.07.11 # because (a) we don't know what the user wants, and (b) the extra mechanism is always there 17.07.34 # the whole point of umask is to allow the user to decide the rights 17.08.44 # indeed, umask is not optional. 0664 is wrong on some systems as well :) 17.08.50 # kugel: There aren't that many calls to creat() in the core anyway - most are in plugins. So the binsize impact shouldn't be much. But if we use a mode for creat(), shouldn't we also be doing it with any calls to open that create a file - there are quite a few of those... 17.10.19 # funman: (logs) http://pastie.org/942447 I've taken your PIO patch and modified it to use the same transfer mechanics that the linux patch uses for PIO. I adjusted most units to bytes vs words except a conversion to words happens just befor the actual transfer. 17.10.21 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 17.12.09 # funman: I get a DTO but there are still bytes left. With rx watermark at 20 there are 84 left but if I change to 80 only 24. 17.12.16 # linuxstb: When umode was removed, it saved quite some binsize 17.12.43 # Even if the function just ignores the argument, each call has to pass it 17.12.44 # the mode would be removed through #defines 17.14.36 # #defines are clever, but at the same time they are problematic 17.15.05 # We have a lot of things which may clash on some systems 17.15.26 Join mt [0] (~mtee@rockbox/developer/mt) 17.15.43 # E.g. you can't build a sim on opensolaris because inttypes somehow clash with the native inttypes 17.15.45 # kugel: you could also define the other way for RaaA 17.16.09 # I tried fixing that by always using native inttypes for sims - but then wavpack doesn't compile on linux... 17.16.09 # #define creat(x) creat(x,666) 17.16.25 # 0666 17.16.28 # right 17.21.32 Join halmi [0] (~netbook@188-22-118-251.adsl.highway.telekom.at) 17.28.41 Quit Xerion (Quit: ) 17.29.18 Nick Rondom_ is now known as Rondom (~quassel@dslb-084-057-134-069.pools.arcor-ip.net) 17.29.35 Quit komputes (Ping timeout: 252 seconds) 17.30.38 Join anewuser [0] (anewuser@unaffiliated/anewuser) 17.36.14 # gevaerts: no that doesn't work well 17.36.31 # the creat() prototype is different which gives warnings 17.36.44 Join Tux^verdreifelt [0] (dly07@piratenpartei/ni/tux) 17.37.01 Part Tux^verdreifelt 17.37.39 # * gevaerts keeps forgetting about the headers 17.38.08 # amiconn: everything builds fine with native inttypes here (i.e. using sys/types.h) 17.38.33 # wavpack doesn't compile because it does some very stupid "unsigned int32_t", but there were just a few, so easy to fix 17.42.47 Join flydutch [0] (~flydutch@host36-202-dynamic.15-87-r.retail.telecomitalia.it) 17.44.29 # kugel: Would it make sense to commit some of these small fixes (e.g. removing unsigned int32_t) as you find them? 17.45.23 # that was basically the only thing that'd make sense to commit separately 17.45.44 # New commit by 03Buschel (r25777): Refacturate arm version of libmad's synthesis filter. Only two asm macros left, renamed asm-implementation for better clarity. No change in speed or ... 17.46.06 # "refacturate"? 17.48.17 # * Buschel hides away 17.48.31 # refactor... 17.48.54 # * Buschel better uses his dictionary before submitting 17.50.09 # somebody should commit something to move this from the front page :o) 17.53.25 # kugel: Looking at your patch on flyspray, there are a few places where you've replaced sys/types.h with inttypes.h, but inttypes.h was already being included. i.e. you're including it twice. 17.56.04 # kugel: But why are you doing that change anyway? Isn't sys/types.h required for things like size_t, off_t etc? 17.56.17 Join DataGhost_ [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) 17.56.17 Quit DataGhost (Disconnected by services) 17.56.18 Nick DataGhost_ is now known as DataGhost (~dataghost@192-18-ftth.onsnetstudenten.nl) 17.56.36 # New commit by 03mt (r25778): Fix intdentation apps/codecs/libwma/asf.h, no functional changes. 18.00.36 # linuxstb: as I understood things we generally use (our) inttypes.h for these things 18.01.13 Quit mirak (Quit: Ex-Chat) 18.01.33 # My understanding was that inttypes is just the int32_t etc types. 18.02.06 # These are normally defined in stdint.h, which is always included by inttypes.h 18.03.00 # Looking at my (Linux) inttypes.h, it also contains some useful-looking macros for dealing with those ints (e.g. in printf) 18.03.05 # statements like " wincent: In Rockbox, it's inttypes.h" make me thing that 18.03.10 # think* 18.03.35 # kugel: What was that in response to? 18.04.44 Quit JohannesSM64 (Ping timeout: 240 seconds) 18.04.49 Join saratoga [0] (~463f90ed@gateway/web/freenode/x-svriiiooefvfgjac) 18.05.00 # " linuxstb: What about stdint.h ?" 18.06.03 # Yes, but that's not about sys/types.h - IIUC, you're replacing that with inttypes.h ? 18.06.59 # I don't see what type the talk was about exactly 18.07.18 # linuxstb: yes, but for the sim inttypes.h includes sys/types.h 18.07.49 # The Rockbox one? If so, then I think that's wrong. My Linux inttypes.h doesn't do that. 18.08.02 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.08.21 # I don't get the difference between all these too, but I do know that our versions somehow inttypes clashed with system's headers 18.08.54 # I'm just looking at my Linux versions to see what they are doing. I think Rockbox should be similar. 18.09.02 Quit Unhelpful (Remote host closed the connection) 18.09.05 # I didn't make it match the system's inttypes.h, I simply made it defining all int-derived types you'd want 18.09.12 # inttypes/stdint seem to be defined by C99. 18.09.33 # anyone object to putting up an official fuzev2 bootloader now? 18.09.35 # sys/types.h is something different. 18.09.38 # we have one for the clipv2 18.10.23 # my sys/types.h defines (u)intN_t, and is included by stdint.h 18.10.30 # saratoga: If it works (i.e. safely dual-boots), then go for it. Don't forget to build it with a real versoin number and tag in svn though. 18.10.40 # kugel: What is "my" ? 18.11.02 # the files on my system 18.11.12 # Yes, but what is your system? 18.11.19 # my inttypes.h includes stdint.h, so at the end it all comes from sys/types.h 18.11.30 # ubuntu 10.04 18.12.21 # So just to be clear, in Ubuntu, sys/types.h includes inttypes.h, and inttypes.h includes stdint.h ? 18.13.03 # inttypes.h includes stdint.h, which includes sys/types.h 18.13.16 *** Saving seen data "./dancer.seen" 18.13.34 # is "v1.0" an ok version? 18.13.56 # saratoga: Perfect - I think that's exactly what others use. 18.14.08 # I don't see why we need released bootloaders for unusable targets, but well.. 18.14.34 # the clipv2 once was unstable which is why it has one 18.15.00 # so that people don't use random bootloaders they find on the internet 18.15.20 # random as in the ones funman regularly posts on abi? 18.15.36 # did he post a bootloader? 18.15.40 # people shouldn't be using rockbox on the fuzev2 at all, so I don't care what bootloders they use 18.15.59 # kugel: OK, but on my Debian unstable system, stdint.h doesn't include sys/types.h. So I don't think you can assume that everywhere. C99 _does_ specify that inttypes.h includes stdint.h though. 18.16.04 # releasing a bootloader somehow implies for me that we're doing support for it 18.16.44 # so it was technically correct to replace sys/types.h with inttypes.h, wasn't it? 18.16.57 # kugel: No - that's what I'm trying to say. 18.17.14 # Well, it depends _why_ that file was using sys/types.h 18.17.28 # If it's for size_t, off_t etc, then it needs to stay. 18.17.46 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 18.17.47 # size_t is also defined in string.h 18.17.49 Join Unhelpful [0] (~quassel@71.173.205.32) 18.17.49 Quit Unhelpful (Changing host) 18.17.49 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 18.18.50 # kugel: I don't see the harm in releasing a bootloader early - it's one of the required steps on the way to making a target unusable. A target isn't supported until we say so on the front page. 18.19.29 # "on the way to making a target unusable"? :) 18.19.47 # s/unusable/unstable/ ;) 18.20.19 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 18.20.43 Join mt2_ [0] (~chatzilla@41.233.137.154) 18.20.49 # kugel: Maybe it's actually the same problem here. Didn't investigate further because opensolaris is kinda slow anyway 18.21.05 # * amiconn probably needs to fix the mmx asm to not use .rept though :\\ 18.21.14 Nick mt2_ is now known as mt2 (~chatzilla@41.233.137.154) 18.21.22 # The native assembler on osx (yuck!) doesn't like it 18.21.30 # kugel: The reference I always use to find out which includes are needed for a specific function are the linux manpages. So for example, the lseek manpage says I need sys/types.h (presumably for off_t). 18.23.08 # kugel: Conclusion: It's not simple ;) 18.23.12 # Using cpp macros instead should be possible, but will be fugly compared to .rept .... 18.23.53 Part Boldfilter 18.24.02 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 18.24.54 # linuxstb: right...a single simple inttypes.h sounded so appealing :( 18.32.07 # New commit by 03Buschel (r25779): Fix a bug introduced with r25777. 18.33.06 Join M3DLG [0] (~M3DLG@212.183.140.39) 18.33.27 Quit JohannesSM64 (Ping timeout: 276 seconds) 18.34.52 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 18.36.09 Nick Strife1989 is now known as Strife89 (~Strife89@adsl-80-130-101.mcn.bellsouth.net) 18.36.36 Join funman [0] (~fun@rockbox/developer/funman) 18.37.06 Join wincent_balin [0] (~wincent@f055045159.adsl.alicedsl.de) 18.40.12 Quit wincent (Ping timeout: 276 seconds) 18.41.56 Quit M3DLG (Ping timeout: 260 seconds) 18.43.59 Join Haz [0] (~haz@5ad3637d.bb.sky.com) 18.44.55 Join M3DLG [0] (~M3DLG@212.183.140.53) 18.46.10 Quit wincent_balin (Changing host) 18.46.10 Join wincent_balin [0] (~wincent@rockbox/developer/wincent) 18.46.49 Quit M3DLG (Read error: Connection reset by peer) 18.47.10 Join M3DLG [0] (~M3DLG@212.183.140.53) 18.47.41 Join petur [0] (~petur@rockbox/developer/petur) 18.47.43 # FlynDice: after INT_DTO I see: "trans crd bytcnt" = 512, so the full sector has been read; "trans fifo bytcnt" = 320 = 48 words; and 48 words left to be transferred 18.48.40 # it seems to me that get_timestamp() in codecs/wma.c is asf-specific and independent of the stream's codec, right ? 18.48.41 # and fifo count = 48 (bytes, not words) 18.49.33 # mt2: correct 18.50.02 # it just parses the header of an ASF packet and gives the time in the file 18.50.13 # unless wma pro changes asf, it should work 18.50.19 # but its only used for seeking anyway 18.51.52 Quit hebz0rl (Quit: Ex-Chat) 18.52.33 # FlynDice: if i use (MCI_FIFO_COUNT >> 2) as loop condition and transfer every word, then I get down to 3 words left, and trans fifo bytcnt is up to 500 (12 bytes = 3 words) 18.54.32 Quit flydutch (Quit: /* empty */) 19.00.49 Join MethoS- [0] (~clemens@134.102.106.250) 19.01.51 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 19.02.38 Quit M3DLG (Ping timeout: 240 seconds) 19.03.01 Join M3DLG [0] (~M3DLG@212.183.140.20) 19.04.33 Quit kugel (Ping timeout: 260 seconds) 19.08.15 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 19.11.04 Quit Kupop (Ping timeout: 264 seconds) 19.11.22 # I don't get how the comment in linux apply : "if we have reached the end of the block we cn read a word and get 1 to 3 bytes" => that implies we would be transferring an odd amount of bytes 19.14.19 Quit petur (Ping timeout: 264 seconds) 19.15.31 Quit togetic (Ping timeout: 264 seconds) 19.15.41 # if i transfer only 'fifoth' == 0x20 bytes at a time, then 96 bytes are left to be transferred, and there are 24 bytes in the fifo after INT_DTO 19.16.16 # linuxstb: still there? how would I go about telling the e200 to reset? b 0 is not an option since the IVT is mapped somewhere else. 19.16.28 Quit M3DLG (Ping timeout: 260 seconds) 19.16.55 # loveless: look at system_reboot() 19.16.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.17.13 # funman: thanks! 19.18.03 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 19.18.18 # funman: I hope it works without system_init() running before 19.18.59 # no idea i only know about the e200v2 19.19.11 # works there? 19.19.25 # yes 19.19.45 # New commit by 03mt (r25780): - Factor out container specific code from apps/codecs/wma.c. ... 19.19.45 # how are they different from the platform view? 19.19.50 Quit GeekShadow (Ping timeout: 276 seconds) 19.20.08 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 19.20.32 # completely 19.20.44 # they only share a compatible DAC 19.20.59 # what about memory layout? 19.22.21 # memory layout is not a DAC so it falls out in the 'completely different' 19.22.24 # * mt2 likes how the build table looks right now 19.22.48 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.23.00 # * funman sets up a bounty of 1 beer to the 1st person who will draw a smiley on the build table 19.23.38 Join hebz0rl [0] (~hebz0rl@dslb-088-067-215-174.pools.arcor-ip.net) 19.24.51 # funman: maybe the 3 left words are shifted away by the >> 2? 19.25.44 # no 19.25.48 # funman: works. nice. now out to find DEV_RS on the view 19.26.29 # kugel: the counter is in bytes but we can do bytes transfer only at the final tail of the transfer, which can't happen anyway 19.26.36 # * Bagder adds committer #91 19.26.45 # \☺/ 19.26.48 Join mirak [0] (~mirak@85-171-108-160.rev.numericable.fr) 19.26.54 # because we transfer sectors which are multiple of 4 bytes 19.27.10 # funman: works on the view, too. same address! neato :) 19.27.30 # kugel: i think the 3 words can't be transferred to the FIFO because of the fifo threshold higher than 3 words 19.27.52 # don't you transfer whole sectors at a time anyway? 19.28.03 # but then if i limit reads to the size of the fifo threshold i miss much more data 19.28.09 # yes, so i don't get what's this linux code 19.28.25 # each sector is split in several transfers to/from the fifo though 19.28.34 # loveless: ah you are working on sansa view ? 19.28.41 # have you found the work of obo ? 19.28.42 Join togetic [0] (~togetic@unaffiliated/ibuffy) 19.28.46 # is there some kind of FIFO_EMPTY vs FIFO_ALMOST_EMPTY irq bit as on the dbop? 19.28.54 # there is EMPTY & FULL 19.29.11 # but empty triggers to early? 19.29.19 # too* 19.29.29 # hm? 19.29.53 Quit hebz0rl (Quit: Ex-Chat) 19.30.08 # we don't check if it's empty 19.30.17 # oh, ok 19.30.43 # New commit by 03mt (r25781): Add the Rockbox GPL header to apps/codecs/libasf/asf.c and fix the one in apps/codecs/wma.c 19.30.53 # we can check : how much has been read from the card, hom much has been transferred to the fifo, how much is present in the fifo 19.31.07 # linuxstb: ok, I'll go through the sys/types.h vs inttypes.h thing again 19.31.21 # but first I'll put up a separate patch to fix the creat() thing 19.32.24 # funman: let's say I am trying to get a grip. I am rather n00bish to ARM/rockbox dev 19.32.26 Join stoffel [0] (~quassel@p57B4D47A.dip.t-dialin.net) 19.33.25 # funman: started with disassembling both original firmwares and decided to turn to rockbox and see what's there for the view already 19.33.36 # New commit by 03archivator (r25782): Add myself to COMMITERS 19.34.07 # yay! I still remember this svn stuff! 19.34.18 # Anyone using git-svn on a regular basis? 19.35.02 Join SARBound [0] (~chatzilla@modemcable013.97-80-70.mc.videotron.ca) 19.35.32 # yeah 19.35.41 # archivator: Welcome ;) 19.35.46 # well, I just installed Rockbox on my Sansa Fuze v1... it is nice! 19.35.51 # archivator: welcome! 19.36.08 # funman: is there a way to compress multiple commits (say, an entire branch) into a single svn commit? 19.36.16 # gevaerts, linuxstb: thanks! 19.36.46 # loveless: i assume you've read http://www.rockbox.org/wiki/SansaView and the forum thread ? obo has been working on the sansa view last year 19.37.07 # funman: yes, I have 19.37.10 Quit Kupop (Ping timeout: 246 seconds) 19.37.24 # archivator: once you have your commits on master it should be as simple as 'git svn dcommit' (I don't use branches) 19.37.52 # ah sorry i misread, git svn dcommit will make separate commits 19.38.25 # why making a single commit ? small commits are easier to check, at the expense of bissection being a bit more complex 19.39.03 # funman: My trees are often "try X", "try Y", "revert X", "try Z", "revert Y" - the git equivalent of spam, really :) 19.39.31 # try git rebase to squash commits 19.39.35 # archivator: congrats ☺ 19.39.36 # funman: does obo still idle out around here? it seems the port had stalled. the view tree is full of stubs 19.39.40 # loveless: nope :/ 19.40.17 Quit SARBound (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 19.40.26 # kugel: What was the conclusion about creat() ? 19.41.29 # not sure, but personally like the idea of adding the mode param to the calls, and wrap it with a define so that it doesn't get through to the file_create() function 19.42.32 # loveless: afaik he bricked one of his views, i don't know if he has others 19.43.03 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 19.44.53 # funman: ouch. seem he's fresh out of views. 19.45.48 Quit funman (Quit: free(random());) 19.48.42 # meh, that's complicated with plugins 19.49.29 # kugel: Yes, just using file_create() directly may be simpler... i.e. s/creat/file_create/. But I don't have any real opinion about which is "best"... 19.53.07 # the file I/O functions handling is already quite tricky right now 19.54.22 # I was wondering if simply using file_open(), file_close() and file_create() everywhere could simplify all that. 19.55.00 # But then that wouldn't look that nice... 19.55.52 # I don't really want to leave posix completely 19.56.23 Quit robin0800 (Remote host closed the connection) 19.56.25 Quit archivator (Ping timeout: 252 seconds) 19.56.57 # Well rockbox is posix alike, but not posix compliant anyway 20.01.06 # meh, here comes my unfamiliarity with the build process... [build-e200rbootbin]$ make ... CC bootloader/main-e200r-installer.c ... {standard input}:96: Error: selected processor does not support `cpsid if'. 20.01.46 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 20.01.54 # compiles fine from system-pp502x.c in the dependecies :/ 20.04.10 # what gcc options are required to get it to assemble cpsid? 20.04.23 # ok, how about this? a static inline creat() *with* the mode param. the core will optimize it away, plugins will have a try cost for the wrapper 20.04.23 # loveless: Did you install the Rockbox toolchain? i.e. arm-elf-gcc using rockboxdev.sh ? 20.04.47 # s/try/tiny/ 20.05.42 # kugel: don't you need a real function for the plugin api? 20.05.49 Quit sinthetek (Ping timeout: 258 seconds) 20.06.12 # gevaerts: yes, that's why static inline. the compiler generates a body once its address is taken 20.06.19 # right 20.06.38 # we do the same thing with some other functions as well 20.09.31 Join BHSPitMini [0] (~BHSPitMon@adsl-66-140-45-134.dsl.rcsntx.swbell.net) 20.11.13 # linuxstb: yes, that's what I did. 20.11.30 # linuxstb: main-e200r-installer.c compiles just fine if I use system_reboot() that comes in via system-pp502x.c and it's respective includes and dependencies. but when I spell out the inner workings of system_reboot() directly in main-e200r-installer.c, the compiler bails out at assembling the cpsid mnemonic. 20.12.23 # linuxstb: it's used for disabling the irqs. 20.12.24 # loveless: Can you upload your main-e200r-installer.c somewhere? e.g. www.pastebin.com 20.12.39 # Are you sure you're using the right system_reboot() ? 20.13.00 # * kugel fails at sed 20.13.19 *** Saving seen data "./dancer.seen" 20.13.24 # linuxstb: it should be this one, but I'll check. 20.14.19 # loveless: Yes, system-pp502x.c should be right. So it's the disable_interrupt() function that's causing the problem? If so, then just comment it out, as interrupts shouldn't be enabled anyway (I think). 20.15.11 Join halmi_ [0] (~netbook@93-82-46-54.adsl.highway.telekom.at) 20.16.29 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 20.17.22 # loveless: But something looks wrong - the cpsid function is for a higher ARM version than the one in the PP chips. So it looks like the ARM_ARCH define isn't being set. 20.18.03 Quit halmi (Ping timeout: 268 seconds) 20.18.13 # linuxstb: yes, right. I was looking in the wrong #if branch for the preprocessor 20.19.33 Quit bluebrother (Ping timeout: 246 seconds) 20.21.12 Join bluebrother [0] (~dom@f053155167.adsl.alicedsl.de) 20.21.12 Quit bluebrother (Changing host) 20.21.12 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 20.22.23 # http://pastie.org/942639 20.27.04 # New commit by 03mt (r25783): - Modify metadata/asf.c to use libasf. ... 20.29.40 # linuxstb: sure enough, using the correct mnemonics solved the problem. gee, I'm so slow on this! :/ 20.31.16 Quit jordan`` (Quit: Coyote finally caught me) 20.34.25 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 20.36.39 # mt2: You could probably have kept the svn history if you had used "svn cp" when splitting files... 20.38.14 # linuxstb: to copy asf.h from libwma to libasf ? 20.38.53 # Yes, but also the main split of wma.c into wma.c and asf.c 20.40.35 # linuxstb: fine, the view finally reboots on my own code. thanks! now on to the important things. ;) 20.40.48 # linuxstb: hmm.. never really used it that way before. 20.43.30 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 20.43.31 Join wombat23 [0] (~beuteltie@adsl-99-39-2-249.dsl.pltn13.sbcglobal.net) 20.44.33 Quit Transformer (Excess Flood) 20.44.34 # linuxstb: How would that work ? svn cp apps/codecs/wma.c apps/codecs/libasf/asf.c -> commit -> modify both files (add/remove necessary code) -> commit ? 20.45.21 # I _think_ you can do both steps together. 20.46.06 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 20.46.38 # Yes, you can 20.50.27 Join petur [0] (~petur@rockbox/developer/petur) 20.51.26 Join rbert [0] (~quassel@95-90-160-245-dynip.superkabel.de) 20.52.42 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 20.52.43 Quit Kupop (Read error: Connection reset by peer) 20.53.22 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 20.55.00 Quit sinthetek (Ping timeout: 265 seconds) 21.00.11 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 21.01.39 # New commit by 03Buschel (r25784): Change naming of arm asm routines in libmad's synthesis to match their functionality. 21.03.31 Quit grndslm (Read error: Connection reset by peer) 21.06.36 Quit pamaury (Quit: Page closed) 21.14.20 Quit arbingordon (Quit: `) 21.15.34 Quit saratoga (Quit: Page closed) 21.16.48 # New commit by 03Buschel (r25785): Remove residual tabs in codec directory. 21.19.42 # mt2: I don't think checking for _CODECLIB_H is the right thing in libasf/asf.h - I think you can use "#ifdef CODEC" (defined in apps/codecs/codecs.make) to see if the file is being compiled as a codec. 21.19.55 Join hebz0rl [0] (~hebz0rl@dslb-088-067-215-174.pools.arcor-ip.net) 21.21.06 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 21.22.57 # linuxstb: okay, will change that.. 21.24.18 # linuxstb: i have a patch fo creat(), what should I do about open()? you said there are some files which use open to create files? 21.26.23 # kugel: Yes, just grep for O_CREAT. I guess those could be changed to use creat if they are using the equivalent flags to creat() 21.26.50 # But I wouldn't say it's important. Personally, I prefer open(), as it's more explicit... 21.27.40 # * kugel wonders how horriby outdated firmware/test is 21.27.57 # That's the FAT driver testing code? 21.28.55 # not the slightest idea ;) 21.32.03 # making open() posix compliant would probably have an impact 21.32.34 # I think you can't inline variadic functions, as they mean passing parameters on the stack 21.32.53 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 21.36.00 # Just so you know, the wiki's TinyMCE does not completely work in Chrome. Some things like Headings and indentation fail. 21.36.22 # New commit by 03amiconn (r25786): Save a few instructions by better use of conditions. 21.38.13 # kugel: Hmm, as the mode is only needed when O_CREAT is used, perhaps we should be using creat. Then (IIUC) we can stick with our two-parameter calls to open() everywhere else. 21.38.26 # New commit by 03amiconn (r25787): Test more possible alignments in the Write & Verify test. Some ata drivers apply optimisations up to line size alignment. 21.38.39 # well, no, some call open with additional flags 21.38.49 # like O_APPEND instead of O_TRUNC 21.39.01 # Can someone with a mic-equipped target please test FS#11219 ? I only got a confirmation from 1 person and I'd to confirm that it still works. :) 21.40.10 # kugel: When also using O_CREAT? 21.41.22 # kugel: I see the answer to that is "yes"... So no, that won't work. 21.42.16 # we can still ignore the mode in rockbox easily, but just changing it to be variadic has an impact 21.42.32 # (an impact I don't really care about, but I guess amiconn does?) 21.45.20 # Well, we should always try to be as efficient as we can. But if it causes complications, I would say it's up for discussion... 21.48.22 Quit S_a_i_n_t () 21.48.49 # linuxstb: Just tested, and it seems CODEC is defined for metadata parsers too .. 21.49.07 # mt2: Strange... 21.49.24 Quit rbert (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 21.50.39 # mt2: Are you sure? For example, libwavpack/wavpack.h uses #ifdef CODEC 21.51.54 Quit stoffel (Read error: Connection reset by peer) 21.52.12 # mt2: Also, looking at lib/codeclib.h, that defines the "ci" pointer. So it should be accessible in libasf/asf.c without needing to explicitly pass it as a parameter - if you #include codeclib.h 21.59.45 Quit Buschel () 22.02.32 # linuxstb: I was wrong about the CODEC define ( misinterpretation of compiler warnings :( ) .. anyway, yes I'll just remove the extra codec_api parameter. 22.07.13 # New commit by 03mt (r25788): Remove unnecessary parameter (struct codec_api* ci) passed to libasf functions, and consequently remove the no-longer needed #ifdef in ... 22.09.32 # * mt2 wishes he could manipulate svn keywords with git svn 22.09.40 # mt2: You left the comment in asf.h.... 22.10.31 # * mt2 slaps forehead - what a weird lack of focus today. 22.12.19 Quit togetic (Ping timeout: 265 seconds) 22.13.22 *** Saving seen data "./dancer.seen" 22.13.29 # New commit by 03mt (r25789): missed a comment 22.14.21 # * kugel is too tired to fix all these open calls :'( 22.16.02 # Bagder: Could you move http://linuxstb.cream.org/rockbox/tcctool-win32.zip to the download server (utils//tcctool/) ? I think it's fine to delete the existing files there. 22.22.55 # bluebrother: have you looked into concurrent voicing for Mac OS X? 22.23.43 Quit esperegu (Read error: Connection reset by peer) 22.26.22 Join merbanan [0] (~banan@c-94-255-217-199.cust.bredband2.com) 22.30.45 # New commit by 03archivator (r25790): FFT plugin: eliminate 64-bit math. This should result in faster and probably more accurate calculations. 22.31.57 # archivator: no, not yet. Will give it a look now (finally some time to look into Rockbox related stuff this weekend) 22.32.42 # New commit by 03archivator (r25791): FFT plugin: The 64-bit sqrt function is no longer needed 22.33.24 # bluebrother: no worries, do keep me informed. :) 22.35.06 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 22.36.09 Quit mirak (Quit: Ex-Chat) 22.37.56 Join robin0800 [0] (~quassel@149.254.61.36) 22.39.14 # Should I post test builds for FS#11219 or just commit it and hope for the best? 22.39.22 Quit Horscht (Ping timeout: 276 seconds) 22.40.30 # archivator: it can't cause things to stop working, right? 22.40.41 Quit Strife89 (Ping timeout: 264 seconds) 22.40.47 Join togetic [0] (~togetic@unaffiliated/ibuffy) 22.40.54 # gevaerts: well, no. It only touches plugins/fft 22.41.39 Quit Bullet` (Quit: Bye les gens =)) 22.43.01 # anyone else haven issues with unzipping in Rockbox Utility? Something with the cache seems to behave strangely, but I'm wondering if I've messed something up on my dev machine 22.44.14 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 22.46.26 Quit togetic (Ping timeout: 260 seconds) 22.51.57 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 22.52.24 Join robin0800 [0] (~quassel@149.254.61.36) 22.54.59 Quit domonoky (Read error: Connection reset by peer) 22.56.24 Quit liar (Quit: Verlassend) 22.56.25 Quit mischasworld (Ping timeout: 276 seconds) 22.56.57 # archivator: commented on FS#11160 22.58.13 # mt2: I'm just looking at your libwmapro files - was it really ffmpeg r228866 (in README.rockbox) ? 22.58.16 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 22.59.12 # bluebrother: awesome. I'll try it out in a few minutes to make sure all the linux engines still work.. 22.59.27 Quit Kupop (Ping timeout: 246 seconds) 23.00.35 Join togetic [0] (~togetic@unaffiliated/ibuffy) 23.00.37 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 23.00.45 # I've only changed one line compared to the 05 patch, so at least my changes won't make a difference for linux :) 23.01.08 # I hope to get around having a more detailed look in the code later. 23.02.53 Join arlaneenalra [0] (~jules@adsl-68-92-124-89.dsl.lgvwtx.swbell.net) 23.04.08 Quit robin0800 (Read error: Connection reset by peer) 23.04.27 Join robin0800 [0] (~quassel@149.254.61.36) 23.04.50 Quit robin0800 (Remote host closed the connection) 23.05.26 # I'm considering looking into rockbox on a fuze v2 and ran into an odd, to me at least, issue. I'm getting 'uses FPA instructions whereas .... does not' 23.05.48 # I'm pretty sure I'm missing some little flag in here somewhere . . . 23.06.20 # Are you using the right compiler, in a clean directory? 23.07.38 Join Luca_S [0] (~5711b744@giant.haxx.se) 23.07.47 # just pulled down the source and rebuilt an s1 gcc with crossdev (it is 4.2.4, if that's the issue I'll have to fight with 4.0.4) 23.08.04 # arlaneenalra: if you're using the vmware image, you need to relaunch the ./rockboxdev.sh script 23.08.20 # I had the same error and running that script fixed it 23.08.25 # That's probably the problem then. You need to enable the correct multilibs - see the tools/rockboxdev.sh script 23.08.50 # ha! I can make open() work without big hit 23.09.12 # but it needs even more hackery around the file IO functions for the codec/plugin api 23.10.47 # linuxstb: that's 22886. ( I know .. :( ) 23.10.56 # mt: No problem ;) 23.11.00 # Luca_S: I'm not running the vmware image . . . 23.11.24 # bluebrother: works as expected with both TTSExes and Festival. 23.11.24 # arlaneenalra: we provide a script to build crosscompilers for a reason :) 23.11.34 # archivator: nice :) 23.16.04 Quit rhodan (Remote host closed the connection) 23.17.24 Quit Luca_S (Quit: CGI:IRC (EOF)) 23.18.13 Join rhodan [0] (~quassel@2001:1608:12:2::38) 23.30.17 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.11) 23.31.34 Join Strife89 [0] (~Strife89@adsl-80-130-101.mcn.bellsouth.net) 23.33.28 # is it safe to just ignore variable parameters? 23.33.55 # i.e. open_wrapper(a, b, ...) { file_open(a,b); }? 23.38.24 # ok, assuming it is, I have a patch to fix open() as well 23.38.43 Quit droidcore (Ping timeout: 245 seconds) 23.41.14 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.42.40 Quit GeekShadow (Read error: Connection reset by peer) 23.43.24 Join droidcore [0] (~mark@69-196-130-202.dsl.teksavvy.com) 23.44.31 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 23.46.18 Quit BHSPitMini (Ping timeout: 252 seconds) 23.46.23 Quit kramer3d (Ping timeout: 246 seconds) 23.48.14 # heh, that's everything quite hackish but I hope that keeps the binsize crowd quiet 23.52.45 # patch at fs#11234, I probably commit tomorrow if nobody objects/makes a comment on the tracker. 23.54.46 Quit bmbl (Quit: Bye!)