--- Log for 12.12.110 Server: anthony.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 23 hours ago 00.01.01 # But I can use mkamsboot to keep my player from booting to the OF when I plug in the cable when the player is powered off? 00.01.31 # It will create a bootloader that will function in that way? 00.01.42 # assuming you are good at ARM asm, yes 00.02.50 # So it doesn't work automatically since I patched my Rockbox for USB support? 00.02.54 # saratoga: so the ASMv2 USB patch doesn't apply to the bootloaders? 00.03.31 # its not even the bootloaders, its the code compiled into rbutil and mkamsboot 00.03.35 # and no thats not changed by it 00.04.19 # the amsv2 usb patch applies to the usb drive; as far as I know, no bootloader has a complete usb stack 00.05.02 # So the bootloader can't pass control to Rockbox if the player is powered off? 00.07.05 # what do you mean ? the bootloader passes control to rockbox in any case except on targets where rockbox doesn't have a usb stack, in which case is usually loads the OF when usb is connected at power on 00.07.17 # That's the case of amsv2 based targets 00.07.33 # mmmh, kugel's threading patch doesn't use target/hosted/sdl/thread-sdl.c anymore, right? 00.07.57 Quit casainho (Remote host closed the connection) 00.08.07 # see http://svn.rockbox.org/viewvc.cgi?view=rev&revision=27618 00.08.16 # The amsv2 usb patch is an attempt at having stable usb in rockbox and thus at having (finally) a working usb stack in rockbox 00.08.42 # i was almost glad i started to get that one in my head, when i noticed its not being compiled anyway 00.08.54 # so now i'm scratching my balls over where the threading went 0.0 00.08.56 Join casainho [0] (~chatzilla@2.81.126.39) 00.10.37 # TheSeven: Cool, I just enabled 16 bit register writes 00.10.44 # how? 00.11.04 *** Saving seen data "./dancer.seen" 00.11.04 # LCD_CON |= 0x100 plus some minor tweaks 00.11.16 # pamaury: I have enabled the USB patches, but when my player is powered off and I plug in a cable, it loads the OF instead of passing to Rockbox. If it's powered on before I plug in the cable, it works as expected, although it is a bit slow sometimes, but every mp3 player I have purchased in the past, because they are cheap for the most part, were slow also, so I don't really notice the difference. 00.11.20 Quit kevku (Ping timeout: 272 seconds) 00.12.34 # pamaury: Is it not passing to Rockbox because I haven'tused mkamsboot since I enabled USB? 00.13.14 # Buschel: tweaks in config regs or just software things? 00.13.17 # I guess so, I think the bootloader only loads rockbox if it's compiled with ROCKBOX_HAS_USB in config.h and friends (like in my patch) 00.13.42 # TheSeven: just in the register write functions in the lcd driver -- nothing else 00.14.21 # * TheSeven needs to figure out how to do that for DMA then 00.14.34 # it can't handle 32bit, right? 00.14.48 # it could, didn't try yet 00.15.00 # the_Kyle: maybe i was unclear, it doesn't boot rockbox because no one has written code to do so 00.15.44 # you can fix this by implementing the equivilent of the patch I linked above for AMSv2 using your knowledge or ARM asm, or else wait until USB support is stable enough that its enabled by default and we release a new rbutil with support 00.16.56 # Buschel: let me know if it does :) 00.17.51 # what's the better option? duplicating the ATA driver for the ipod classic, fixing it for all the other targets, or producing another #ifdef hell? 00.17.51 # saratoga: So there's no code at all at this point to pass to Rockbox when a cable is plugged in while powered off? I can just be sure it's powered on before I plug in the cable, I was just hoping there was a way to avoid loading the OF in the event I forget to turn the power on e.g. before charging. 00.18.15 # correct 00.18.19 # i won't be able to map that to the ipod classic's hardware as-is 00.18.53 # whats wrong with the current ATA driver? 00.19.16 # it assumes that the task file is directly mapped on the system bus 00.20.09 # (which is only partially true on the classic) 00.21.00 # Not even if ROCKBOX_HAS_USB is enabled, which according to pamaury should work? 00.21.59 # you're welcome to look at that patch and see for yourself if it changes mkamsboot 00.22.45 # the_Kyle: my assumption is the bootloader has the code for it; if like saratoga says, there is no code for it, it won't work 00.23.37 Quit froggyman (Read error: Connection reset by peer) 00.24.49 # Thanks for the help. I'll take a look at things, but I'll probably have to wait until USB is more stable, since I don't have enough knowledge of the code, especially the low-level stuff like the bootloader, to be able to patch it. 00.25.02 # TheSeven: 32bit does not seem to work 00.25.05 # * TheSeven wonders if he should introduce macros to read/write ATA task file regs 00.26.11 # hmm, lcd controller can't handle the speed of DMA transfers at 124 MHz on HD300 :-( 00.26.39 # wodz: shouldn't DMA usually have some kind of flow control? 00.26.51 Join AlexP_ [0] (~alex@rockbox/staff/AlexP) 00.27.05 # TheSeven: you mean wait states? 00.27.08 # For now, I'll just be sure the player is powered on before charging it or manipulating files. I just don't like the stuff that the OF puts on the player. It rewrites its idea of what it thinks the directory structure should be and everything. 00.27.22 Join Horschti [0] (~Horschti@xbmc/user/horscht) 00.27.39 # wodz: usually there is a DMAREQ line from the peripheral to the DMA controller that tells it that it's ready to send/receive more data 00.27.57 # not the case here 00.28.19 # lcd is connected to lower half of the bus and that's all 00.28.20 # so you're basically doing memory2memory on a peripheral? 00.28.26 # yes 00.28.53 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.29.32 Quit AlexP (Ping timeout: 264 seconds) 00.29.58 Nick AlexP_ is now known as AlexP (~alex@rockbox/staff/AlexP) 00.30.06 # How do I know at which freq cpu is running? Maybe I could use DMA transfer when not boosting? 00.30.35 # the_Kyle: from what I understand, boot-to-rockbox-with-usb is reasonably easy to change (although I'm not exactly sure where), it's just not exactly safe. The change is basically in the only part of the code that can cause your clip to be bricked (or very nearly so, requiring opening it and shorting pins) if you get it wrong 00.31.09 Quit Horscht (Ping timeout: 265 seconds) 00.31.31 # wodz: there's a global cpu_frequency variable 00.31.59 # but you would need to make sure to interrupt the DMA transfer if a boosting request comes in while it's already running 00.32.06 # Ouch. I don't think I want to do that. I'll just wait, or at least wait for a patch that has been tested and found to be at least somewhat safe. 00.32.42 # This is my primary player, and a sim isn't going to tell me if it's safe or not. 00.33.22 # well, basically it should be safe if you know what you're doing, are careful, and double- and triple-check things before flashing :) 00.33.41 # (and possibly ask other people to review) 00.34.00 # but if you've never dealt with ARM assembly code before, this isn't really the place where you should start :) 00.34.54 # I can get help. You all have been nothing but helpful so far. I just don't know that I know enough about the code to mess with it in that way. 00.43.40 # ha, this seems to work. 45 MHz speedup is from 438 -> 728 fps, boosted fps is unchanged 1098 00.43.43 Quit {phoenix} (Read error: Connection reset by peer) 00.44.22 # seems to be a good day for LCD speed ups :) 00.44.39 Quit Horschti (Ping timeout: 265 seconds) 00.45.54 # am I correct that boost/unboost changes on tick? 00.46.18 Join Horscht [0] (~Horschti@p4FD4AE7D.dip.t-dialin.net) 00.46.19 Quit Horscht (Changing host) 00.46.19 Join Horscht [0] (~Horschti@xbmc/user/horscht) 00.46.41 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 00.46.52 # I mean the shortest possible interval between freq change is 10ms? 00.47.21 Join Horschti [0] (~Horschti@xbmc/user/horscht) 00.49.40 Quit ender` (Quit: The problem with political jokes is they get elected. -- Henry Cate, VII) 00.50.02 # TheSeven: now it seems like I have a reached a maximum speed on my LCD -> 64.5 fps unboosted and 129.5 fps boosted 00.50.12 # (for RGB full screen) 00.50.35 # Is recording sampling done on a hardware level, or is it done in Rockbox? I get a lot of aliasing if I set the recording frequency below 44KHz. 00.50.35 Quit leavittx (Ping timeout: 255 seconds) 00.51.02 # 32 seems OK, actually, but below that it starts getting bad. 00.51.09 # hardware 00.51.28 Quit Horscht (Ping timeout: 276 seconds) 00.55.16 # New commit by 03wodz (r28799): HD300 - further speedup of lcd_update() by utilizing DMA transfer when unboosted. The gain is 438 -> 728 fps @ 45MHz. 00.57.19 # r28799 build result: All green 00.57.43 Join saratoga_ [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) 00.58.05 # ok i think all the libmad algorithmic stuff is working, now the asm part 01.00.31 Quit wodz (Quit: Leaving) 01.02.10 # * TheSeven desperately tries to make the ipod classic port even compile :/ 01.05.28 Join webguest79 [0] (~4a46f324@giant.haxx.se) 01.05.32 # hi 01.06.14 # do we have any define that allows to determine if we're being included from an asm file? 01.06.39 # _ASM ? Or something like that 01.06.54 # That's pretty common to have one, rockbox should be no exception 01.07.45 Quit webguest79 (Client Quit) 01.08.47 Join GeekShadow [0] (~Antoine@93.21.177.169) 01.08.47 Quit GeekShadow (Changing host) 01.08.47 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 01.09.45 # apparently a handful of files uses "#define ASM", but most don't define anything 01.09.53 Quit casainho (Ping timeout: 245 seconds) 01.10.13 # perhaps it's on the as command line ? 01.10.39 # why would some files have one then? 01.11.03 # * TheSeven discovers that the ATA mess is much deeper than he thought 01.11.55 # don't know; perhaps there is none and we should have one 01.12.03 Quit dantje_ (Quit: Ex-Chat) 01.12.27 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 01.25.43 Quit JesusFreak316 (Ping timeout: 245 seconds) 01.26.13 # wow 01.26.33 # now i'm *just* getting errors about undefined references during linking 01.34.07 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 01.39.51 # is there any chance that an owner of an iPod nano 2G with an ILI type LCD can verify FS#11807 ? 01.44.10 # the ilitek one seems to be quite common actually 01.44.22 # type 3 is the one that barely anybody has 01.45.33 # I would really like to see a test before I commit. I hate to be forced to fix afterwards... 01.48.32 # what do people think of that automatic resume patch on the tracker? 01.51.53 Quit shai_ (Ping timeout: 260 seconds) 01.52.07 # New commit by 03theseven (r28800): usb-s3c6400x.[ch], button-clickwheel.c: Move s5l8701-specific parts to where they belong, prepare for s5l8702 01.53.15 Quit bertrik (Quit: :tiuQ) 01.53.54 # r28800 build result: 0 errors, 71 warnings (theseven committed) 01.55.44 Quit ReimuHakurei (Ping timeout: 265 seconds) 01.59.35 Quit Buschel (Ping timeout: 240 seconds) 02.00.01 # New commit by 03theseven (r28801): Fix yellow, already assign values for various S5L8702 defines 02.00.14 Join Horscht [0] (~Horschti@xbmc/user/horscht) 02.01.44 # * TheSeven wonders if that meier crossfeed thing will be committed one day 02.01.51 # r28801 build result: 0 errors, 66 warnings (theseven committed) 02.01.56 # arrrrrrrrrrrr 02.02.00 Join ReimuHakurei [0] (~reimu@74.112.212.15) 02.02.33 Quit Horschti (Ping timeout: 264 seconds) 02.03.16 # New commit by 03theseven (r28802): Really fix yellow this time, SVN only committed half of what I wanted... 02.03.52 Quit factor (Ping timeout: 241 seconds) 02.05.24 # r28802 build result: All green 02.06.13 Quit ReimuHakurei (Ping timeout: 241 seconds) 02.08.26 Join timccc [0] (~timccc@112.166.15.141) 02.11.08 *** Saving seen data "./dancer.seen" 02.11.27 Join simonrvn [0] (simon@210.23-ppp.3menatwork.com) 02.17.35 Quit GeekShadow (Remote host closed the connection) 02.21.12 Quit Judas_PhD (Quit: This is a quitting message) 02.24.29 Quit pamaury (Remote host closed the connection) 02.29.47 Join Horschti [0] (~Horschti@xbmc/user/horscht) 02.33.21 Quit Horscht (Ping timeout: 259 seconds) 02.35.56 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com) 02.38.15 Join Topy [0] (~Topy44@f049005073.adsl.alicedsl.de) 02.38.15 Quit T44 (Read error: Connection reset by peer) 02.39.36 Quit jfc (Ping timeout: 255 seconds) 02.40.54 Join Horscht [0] (~Horschti@xbmc/user/horscht) 02.43.33 Quit Horschti (Ping timeout: 240 seconds) 02.50.20 Join Horschti [0] (~Horschti@xbmc/user/horscht) 02.54.18 Quit Horscht (Ping timeout: 260 seconds) 02.56.01 Quit linuxguy3 (Ping timeout: 272 seconds) 02.56.59 Quit fdinel (Ping timeout: 245 seconds) 02.57.22 Join linuxguy3 [0] (~timj@75.57.165.250) 03.00.08 Join Horscht [0] (~Horschti@xbmc/user/horscht) 03.02.00 Quit Keripo (Quit: Leaving.) 03.02.34 Join Keripo [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 03.03.03 Quit Horschti (Ping timeout: 260 seconds) 03.03.05 Quit Keripo (Client Quit) 03.04.59 # does eterm in the rockbox dev image not allow copy and paste? 03.05.52 # New commit by 03moos (r28803): Update the list of targets used on english.lang file. 03.07.46 # New commit by 03moos (r28804): Merge the translation of too strings for a generic use. 03.08.07 # r28803 build result: All green 03.10.00 Join Keripo [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 03.10.33 # r28804 build result: All green 03.11.05 Join Horschti [0] (~Horschti@xbmc/user/horscht) 03.13.08 Quit Horscht (Ping timeout: 240 seconds) 03.16.51 Quit mystica555_ (Read error: Operation timed out) 03.21.27 Join Horscht [0] (~Horschti@xbmc/user/horscht) 03.21.39 # wow our VMware image is really terrible 03.21.51 # i'm just trying it now, i see why people try and use cygwin 03.22.20 # just downloading an ubuntu or debian image from sourceforge and running in current virtualbox for Windows is 100x less annoying 03.24.53 Quit Horschti (Ping timeout: 276 seconds) 03.25.13 Join mortalscan [0] (~mortalsca@109.169.55.155) 03.26.22 # anyone know how to uninstall the old arm compiler? 03.26.59 Join cjcopi [0] (~craig@adsl-76-241-82-218.dsl.bcvloh.sbcglobal.net) 03.29.16 Join Horschti [0] (~Horschti@xbmc/user/horscht) 03.31.51 # New commit by 03moos (r28805): Punctuation consistency, revert part of r27363. 03.33.09 Quit Horscht (Ping timeout: 264 seconds) 03.33.58 # r28805 build result: All green 03.39.22 Join Horscht [0] (~Horschti@p4FD4E5A1.dip.t-dialin.net) 03.39.25 Quit Horscht (Changing host) 03.39.25 Join Horscht [0] (~Horschti@xbmc/user/horscht) 03.41.06 Join TheSphinX^ [0] (~cold@p54A5BD59.dip.t-dialin.net) 03.42.15 Quit Horschti (Ping timeout: 260 seconds) 03.42.31 Quit TheSphinX^ (Client Quit) 03.43.41 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.71) 03.49.15 Join Horschti [0] (~Horschti@xbmc/user/horscht) 03.49.59 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 03.53.01 Quit Horscht (Ping timeout: 272 seconds) 03.53.03 Join T44 [0] (~Topy44@f049002207.adsl.alicedsl.de) 03.55.16 Quit Horschti (Quit: Verlassend) 03.56.47 Quit Topy (Ping timeout: 240 seconds) 04.01.00 # omg does the version of vmware player we tell people to use really not support 2 processors 04.01.39 # make 7zip 04.02.24 # ^^^ hmm well it definitely doesn't support 'taking control of the windows keyboard when brought to focus' 04.03.44 # meh - use vmware server 04.03.58 # the wiki explicitly states to use this version 04.04.14 # i'll update, test and then change the wiki 04.04.29 # is there any reason we use vmware instead of virtualbox? 04.04.53 # last i checked virtualbox is nice because its open source and will let you use an unlimited number of cores without paying 04.05.04 # although maybe vmware has that now too 04.06.07 Quit saratoga (Ping timeout: 265 seconds) 04.08.28 # heh apt-get fails on our image as well due to missing download servers 04.10.02 Quit BHSPitMonkey (Ping timeout: 272 seconds) 04.11.10 *** Saving seen data "./dancer.seen" 04.11.49 # yeah - it is way out of date - i made an updated one a while back, but didnt have time to properly test it - and people on the forum faled to properly test it enough to put on the wiki as well 04.11.55 # i will eventually make another 04.12.01 Join DerPapst1 [0] (~Alexander@p5DE5A096.dip.t-dialin.net) 04.12.28 # i'm just going to upload the same one with the new compiler 04.13.43 # how the hell do i turn this thing off 04.13.47 # no matter what i do it just reboots 04.14.24 Quit DerPapst (Ping timeout: 245 seconds) 04.14.34 # there is a power off option 04.15.27 # even shutdown -h just reboots 04.15.54 Quit Keripo (Read error: Connection reset by peer) 04.18.43 Join Keripo [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 04.20.07 # haha vmware wants me to register to update 04.20.09 # i'll get right on that 04.21.52 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-30-16.tampfl.fios.verizon.net) 04.21.57 Quit Keripo (Read error: Connection reset by peer) 04.24.35 Join Keripo [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 04.30.15 Quit designate72 (Quit: Leaving) 04.32.02 Quit pixelma (Disconnected by services) 04.32.03 Quit amiconn (Disconnected by services) 04.32.03 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.32.04 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.32.07 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.32.23 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.34.38 Join froggyman [0] (~seth@unaffiliated/froggyman) 04.35.41 Quit TheSeven (Ping timeout: 250 seconds) 04.36.04 Join ReimuHakurei [0] (reimu@68-179-162-48.bsr-c5-d1.evv.dhcp.sigecom.net) 04.38.23 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 04.39.08 Quit JesusFreak316 (Remote host closed the connection) 04.39.36 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.39.40 Quit efyx (Remote host closed the connection) 04.41.47 Join Barahir [0] (~jonathan@frnk-590ff236.pool.mediaWays.net) 04.41.54 # does rockboxdev.sh leave temp files around? 04.41.59 # my image got a lot bigger when i ran it 04.42.17 Quit Barahir_ (Read error: Operation timed out) 04.47.37 # due to dead space no longer being zeroed out? 04.47.43 Quit froggyman (Quit: Bye) 04.47.47 # soap: probably that, how do i zero it? 04.48.11 # cat /dev/zero > zero.txt 04.48.18 # that should completely fill up the drive 04.48.23 # then rm zero.txt 04.50.01 Quit the_Kyle (Quit: Leaving.) 04.51.37 Join the_Kyle [0] (~kyle@71.23.64.127) 04.54.00 Quit elcan (Read error: Connection reset by peer) 04.54.07 Join elcan [0] (user36@pr0.us) 04.56.02 Quit sasquatch (Quit: WeeChat 0.3.2) 04.56.28 Join sasquatch [0] (~username@p4FF2DF34.dip.t-dialin.net) 04.57.47 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 05.01.34 Join froggyman [0] (~seth@unaffiliated/froggyman) 05.02.04 # saratoga_: I believe (depending on what you actually did, however) it leaves some temp files in the form of tmp/rbdev-build and tmp/rbdev-dl which easily adds up to a few hundred MBs. 05.06.19 # wow got it 20MB smaller the original :) 05.07.10 Quit the_Kyle (Quit: Leaving.) 05.09.25 Join the_Kyle [0] (~kyle@71.23.64.127) 05.09.58 Quit froggyman (Quit: Bye) 05.10.46 Quit InsDel (Read error: Connection reset by peer) 05.14.12 Quit mortalscan (Quit: Leaving) 05.18.08 Quit saratoga_ (Ping timeout: 265 seconds) 05.45.04 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 06.10.30 Quit timccc (Remote host closed the connection) 06.11.01 Join timccc [0] (~timccc@112.166.15.141) 06.11.13 *** Saving seen data "./dancer.seen" 06.15.17 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.35.53 Join froggyman [0] (~seth@98.115.0.7) 06.35.53 Quit froggyman (Changing host) 06.35.53 Join froggyman [0] (~seth@unaffiliated/froggyman) 06.35.56 Join telliott [0] (~IceChat77@d27-96-170-180.evv.wideopenwest.com) 06.36.04 Quit shai (Ping timeout: 245 seconds) 06.38.08 Quit Judas_PhD (Quit: This is a quitting message) 06.40.07 Quit froggyman (Client Quit) 06.43.19 Quit ReimuHakurei (Ping timeout: 272 seconds) 06.47.28 Quit Keripo (Quit: Leaving.) 06.48.25 Quit DerPapst1 (Quit: Leaving.) 06.53.16 Join ReimuHakurei [0] (reimu@68-179-162-48.bsr-c5-d1.evv.dhcp.sigecom.net) 06.58.22 Join Topy44 [0] (~Topy44@f049002207.adsl.alicedsl.de) 07.14.07 Join froggyman [0] (~seth@98.115.0.7) 07.14.08 Quit froggyman (Changing host) 07.14.08 Join froggyman [0] (~seth@unaffiliated/froggyman) 07.23.02 Quit telliott (Quit: Easy as 3.14159265358979323846...) 07.40.13 Join Keripo [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 07.49.34 Quit Primula (Quit: o.O) 08.11.16 *** Saving seen data "./dancer.seen" 08.56.56 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 08.58.52 # Anyone here use the ZXBox plugin? 08.59.30 # * S_a_i_n_t is trying to figure out if it is broken, or if the images he is trying to load are broken. 09.00.55 # sometimes, haven't tried in a while though 09.08.47 Quit Keripo (Ping timeout: 255 seconds) 09.08.54 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 09.10.06 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.15.00 Join Buschel [0] (~chatzilla@p54B663AD.dip.t-dialin.net) 09.15.52 Quit Buschel (Client Quit) 09.34.04 Join Horscht [0] (~Horschti@xbmc/user/horscht) 09.58.55 Join bmbl [0] (~bmbl@dsl107-128.pool.bitel.net) 09.58.55 Quit bmbl (Changing host) 09.58.55 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 09.59.47 Join Buschel [0] (~chatzilla@p54B663AD.dip.t-dialin.net) 10.02.25 Join stoffel [0] (~quassel@p57B4AD99.dip.t-dialin.net) 10.03.59 # S_a_i_n_t: yesterday you mentioned that you "mostly have LDS176 LCDs" in your nano 2Gs. does this mean you also have a target with an ILI type? 10.07.51 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.07.51 Quit bertrik (Changing host) 10.07.51 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 10.08.58 Join leavittx [0] (~leavittx@89.221.199.187) 10.10.27 Join {phoenix} [0] (~dirk@p57AA5050.dip.t-dialin.net) 10.11.20 *** Saving seen data "./dancer.seen" 10.14.13 Quit ReimuHakurei (Ping timeout: 272 seconds) 10.17.12 # Buschel: IIUC, there's 3 LCD types that the Nano2G uses...one of which seems to be quite rare. IIRC, I have 5 type 1, (7) LCD Nano2Gs and 1 type 2, (5) (I *think* that's it...anyway, I think its in the car) LCD Nano2G 10.18.04 # I'll need to double check which type exactly the other one is, but...I do know I have 2 different LCD types. 10.18.41 # well, it would be great to have the LCD driver patch on other LCD types as well 10.18.41 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 10.20.04 # TheSeven has the "rare" type (is it the LEADIS LCD? my menory is broken today) also if my memory serves. 10.20.09 # Buschel: ^ 10.20.27 # I *think* he does...rather. 10.20.40 # the LDS type seems to be the common case -- that is what TheSeven and I own 10.23.51 # with the LDS176 screened Nano2Gs I have, there seems to be a "bright" and a "dark" version...I have several, and I have RB'd several for friends also. 10.24.05 Quit Judas_PhD (Quit: This is a quitting message) 10.24.47 # According to debug, the screens are the same...but some are definitely a lot clearer/brighter than others and it doesn't seem to have anything to do with how old/new the Nano in question is. 10.25.28 # is this also visible in Apple OS? or just when those targets were rb'ed 10.28.54 # It is visible in the Apple OS also. 10.30.22 # Hmmm...I'm sure (almost positive) that the Nano2G has three possible LCDs but the driver only seems to handle 2. My mistake. 10.31.19 # you wre right. TheSeven also stated there are three types of which 1 is very seldom 10.34.47 # Ah, right...I thought so, but the code only suggests we know how to deal with 2 of them. 10.36.21 # perhaps the third type is the bright or dim LDS176 type screens I have seen/own. 10.36.53 # could you test the patch on those units? 10.37.19 # for now it was only verified on my "golden device" ;) 10.37.30 # yep. I can do so in the next hour or so. just need to run out for a bit presently. 10.37.45 # "golden device"? 10.37.51 # * S_a_i_n_t lols. 10.38.33 # S_a_i_n_t: that would be perfect :) 10.39.11 # okay 10.39.27 # does the SDL target have a fucking quit key 10.39.47 # i can't get the profiling info when i kill it with ^C ffs 10.41.14 # any hints? 10.42.31 # I don't believe it has a quit key, fucking or otherwise. 10.54.10 Quit BHSPitMonkey (Remote host closed the connection) 10.56.58 Join JdGordon1 [0] (~jonno@111-220-247-133.wbroadband.net.au) 10.58.28 Join JdGordon2 [0] (~jonno@111-220-247-133.wbroadband.net.au) 11.00.04 Quit JdGordon (Ping timeout: 250 seconds) 11.01.04 Quit JdGordon1 (Ping timeout: 240 seconds) 11.01.07 Join JdGord [0] (6fdcf785@gateway/web/freenode/ip.111.220.247.133) 11.02.29 Quit JdGordon2 (Ping timeout: 240 seconds) 11.05.05 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 11.08.34 Quit JdGord (Ping timeout: 265 seconds) 11.11.17 Join pamaury [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) 11.11.18 Quit pamaury (Changing host) 11.11.18 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.18.38 # Buschel: FS#11807 *PANIC* my nano 2G. 11.19.14 # Utchybann: good! 11.19.15 # :) 11.19.24 # what type of LCD do you have? 11.19.38 # LCD is LDS176 11.19.50 # hmm, same than mine... 11.20.02 # what is the exact error dislayed? 11.20.14 # full panic message is : Unhandled IRQ 1A: INT_SPI 11.20.43 # I get the same error on my 2 nano 2g (both have same LCD type). 11.20.49 # is this with version v05? 11.21.11 # my fault. I download the patch last night. 11.21.14 # v03 11.21.38 # hmm, v03 is changing much less than v05... 11.24.01 # is it supposed to work with r28805 ? 11.24.57 # I did not update since this night, my patch works against r28799 11.25.11 # that's what I use here 11.26.09 # let me check with v05 and r28799 11.26.53 Join stooo [0] (~sto@f051077202.adsl.alicedsl.de) 11.27.25 # does it crash instantly or after a while? 11.28.26 # instantly 11.29.14 # I don't even see the rockbox logo. 11.30.12 # do you also update the bootloader or just rockbox.ipod 11.30.35 # Can someone with a fuze v2 test the patch in http://www.rockbox.org/tracker/task/11798 for me? 11.30.48 # make zip; unzip rockbox.zip -d /media/ipod 11.31.04 # so no bootloader update 11.31.47 # ok 11.33.43 # r28799+lcd_v05 seems to work. no panic 11.34.25 # maybe the panic is connected to anything that was done after r28799... 11.34.44 # what is the speed you reach with test_fps? 11.36.20 # I guess, I have to compile test_fps ... 11.36.37 # yes 11.39.07 Join bimbel [0] (~bmbl@unaffiliated/bmbl) 11.39.25 Quit bmbl (Disconnected by services) 11.39.31 Nick bimbel is now known as bmbl (~bmbl@unaffiliated/bmbl) 11.53.55 # Main 1/1: 64.5 fps, 1/4: 258.0; YUV 1/1 34.5, 1/4 137.5 (CPU 48 Mhz) 11.54.39 Join dantje [0] (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) 11.55.04 # exactly my numbers. 11.55.39 # 129, 516; 109.5 434.5 (CPU 192Ã) 11.56.15 # nearly the same for me (only really minor diffs though) 11.56.45 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.57.35 # nice. I will try r28805 + lcd_v05. 11.58.22 # btw, everything working fine when using lcd sleep? 11.59.18 # lcd sleep ? you mean the total lcd power off after a few seconds ? 11.59.37 # yes. does it sleep well and wakes up as it is supposed to do? 11.59.52 # yes. 11.59.56 # good 12.01.45 # anyone notice the stock android is more happy to kill the rockbox service than the custom roms? (specifically CM) 12.03.11 Join casainho [0] (~chatzilla@bl20-126-39.dsl.telepac.pt) 12.05.14 # r28805 + lcd_v05 => panic. 12.05.56 # can you track this down to the change which introduces this? 12.07.08 # I'm trying 12.08.44 # hmm, r28805 => panic. 12.09.10 # try r28800 and r28801 12.11.21 Join ender` [0] (krneki@foo.eternallybored.org) 12.11.24 *** Saving seen data "./dancer.seen" 12.12.02 # for me r2880[012] should be seen as a single commit. 12.13.56 Quit casainho (Ping timeout: 240 seconds) 12.16.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.19.54 # r28800 => panic. 12.20.21 # there we go 12.20.58 # TheSeven: something is wrong in r28800 (PANIC Unhandled IRQ 1A: INT_SPI). 12.21.06 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 12.22.23 Join casainho [0] (~chatzilla@bl20-126-39.dsl.telepac.pt) 12.22.37 # hello 12.22.49 # does anyone knows why Rockbox bootloader takes so much memory? Binary size: 51360 12.22.50 # Actual size: 51360 12.22.52 # RAM usage: 354448 12.23.16 # would be possible to make it less than 32kBytes? 12.23.18 # I will revert to r28799+lcd_v05 and report issue if any. 12.23.43 # casainho, maybe the LCD frame buffer? 12.23.44 Join TheLemonMan [0] (~lem0n@ppp-250-151.98-62.inwind.it) 12.23.53 # Utchybann: could you try to only keep the clickwheel driver at pre-r28800? 12.24.07 # bertrik: like having a bootloader that doesn't write/use LCD? 12.24.42 # yes, something like that. But can't you confirm first by looking into the map file? 12.25.18 # bertrik: hmmm, I will try to look and see if I understand.. 12.25.43 Quit S_a_i_n_t (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 12.26.27 # Anyone with a sansa fuze v2 online here now? 12.27.22 # bertrik: can you please look? http://pastebin.com/vn6JgDuV 12.30.34 Join Rob2222 [0] (~Miranda@p4FFF1422.dip.t-dialin.net) 12.32.03 # casainho, see line 1740/1741, using about 150k for the LCD framebuffer (I guess 320*240 16 bit?) 12.32.23 # I also saw some kind of codepage table taking 64kB 12.33.31 # It will probably be hard to reduce it to less than 32 kB 12.33.33 # Utchybann: looks like clickwheel driver is the problem. the ISR for the wheel driver was renamed without a match in system-s5l8700.c 12.33.48 # Utchybann: recompiling now 12.34.55 # bertrik: ok. However my LCD now is 1bit, 64X48... 12.35.21 # bertrik: ok, I may need to think on a 1st and 2nd bootloader... Thanks! 12.35.33 # Buschel: sorry. I have to go now. 12.35.40 # see you 12.36.04 # Buschel, for some reason the interrupt handlers of many rockbox targets are not declared and it's up to the linker to connect them, defaulting to some unhandler using "weak linking" IIRC 12.39.06 # yes, I will fix this issue in a few minute (hopefully) 12.41.55 # New commit by 03Buschel (r28806): Fix bug introduced with r28800 (missing interrupt handler). 12.42.00 # got it 12.44.41 # r28806 build result: All green 12.48.39 Join bertrik_ [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 12.48.39 Quit bertrik_ (Changing host) 12.48.39 Join bertrik_ [0] (~bertrik@rockbox/developer/bertrik) 12.48.47 Quit bertrik (Read error: No route to host) 12.50.21 Nick bertrik_ is now known as bertrik (~bertrik@rockbox/developer/bertrik) 13.16.39 Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) 13.17.29 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 13.36.44 Quit Rob2222 (Ping timeout: 240 seconds) 13.39.37 Join moos [0] (moos@rockbox/staff/moos) 13.39.45 Quit bluebroth3r (Ping timeout: 240 seconds) 13.40.38 # New commit by 03theseven (r28807): iPod Nano 2G: Correct clickwheel interrupt handler name, this time consistently. 13.41.07 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.41.10 # bertrik: hi, still no found someone with a Fuzev2? 13.41.32 # * JdGordon has a fuzev2 i tinhk 13.41.38 # do we need one? 13.41.43 Join bluebrother [0] (~dom@g231121031.adsl.alicedsl.de) 13.41.43 Quit bluebrother (Changing host) 13.41.43 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.42.12 # Hello, JdGordon: it seems bertrik need testing for http://www.rockbox.org/tracker/task/11798 13.42.43 # r28807 build result: All green 13.46.12 # ok, I'm charging both fuzzes (one is v1 one is v2, dunno which is which)... I'll try to remember to test tomorow 13.46.19 # which probably means nagging me :D 13.46.43 # do the fuze OF's trickle charge if the batt is completly flat? 13.47.25 # ah no, hub was overloaded... 13.48.14 # it have to charge yes 13.48.30 # can you do a build for me with the patch please? 13.49.07 # of course just few instants 13.50.06 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 13.50.08 # isnt that for the clip+? 13.50.13 # or fuzev2 also? 13.52.04 # readinf the logs, bertrik seems to need testing for fuve v2 too 13.52.13 # maybe an AMSv2 thing 13.53.58 # JdGordon, I think the hardware indeed charges with a low current when the battery voltage is very low 13.54.22 # changed usb ports and its going now, I tihnk the huyb was just overloaded 13.54.44 # 2xfuzes, ipod, phone, sd reader, external hard disk, keyboard dongle 13.55.29 # I could just commit and see who complains :) 13.55.44 # building... :) 13.56.17 # bertrik: I wont be able to test till tomorow morning, but yeah if oyu commit and it breaks I'm sure we'll know about it pretty quicjky 13.57.33 # if you have few minutes, I could search mine and test, if nedded 13.58.07 # moos, very much appreciated if you could do that 13.58.34 # no problem, I will. 13.58.56 # have you seen any problem accessing the uSD card on your fuze v2, suddenly several people seem to have problems with it 13.59.27 # bertrik: nope, never encountered any... 14.03.47 Quit antil33t (Read error: Connection reset by peer) 14.03.56 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 14.11.26 *** Saving seen data "./dancer.seen" 14.13.50 Quit slooopy (Quit: Verlassend) 14.16.18 Quit Kupop (Ping timeout: 264 seconds) 14.26.37 Quit casainho (Read error: Operation timed out) 14.27.24 # bertrik: all seems to working weel 14.27.32 # thanks for testing 14.27.40 # tried with 2 micro sdhc cards class2 14.28.01 Join Kitr88 [0] (~Kitarist@BSN-182-96-58.dial-up.dsl.siol.net) 14.28.06 # did some copy/past, playing some sonds without problems 14.28.09 # I'm trying to make the sd driver for AMSv2 more similar to the AMSv1 sd driver (porting some bugfixes) 14.28.27 # nice! good luck on this 14.28.47 # don't hesitate to ask again for tests :) 14.30.32 # the fuze v2 seemed more "sensitive" to small changes, for example when we changed the main clock from 240 MHz to 248 MHz, fuze v2 sd card communication failed for some people 14.31.05 Quit Kitar|st (Ping timeout: 276 seconds) 14.31.45 Join MethoS- [0] (~clemens@134.102.106.250) 14.32.21 Quit Kitr88 (Ping timeout: 255 seconds) 14.33.15 # ohoh, strange thing. (btw I enabled adjustable frequencies here, and no problems for me neither so far) 14.33.33 # there are maybe few hardware differences somwhere 14.35.55 # yeah, there is a newer hardware variant where the sd connections actually seem to make sense, e.g. not sharing the button light with some sd card control line :P 14.37.43 Join Kitar|st [0] (Kitarist@89.142.57.133) 14.38.19 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) 14.41.20 Quit MethoS- (Remote host closed the connection) 14.43.31 # * Buschel could adapt iPod video's asm yuv blit to nano 2g 14.44.59 # bertrik: silly them, like always :) 14.47.30 Quit antil33t (Read error: Connection reset by peer) 14.47.39 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 14.49.45 Quit notlistening (Remote host closed the connection) 14.53.42 Quit teru (Quit: Quit) 14.57.19 # YUV is now nearly twice as fast as in svn :) 14.57.57 # woot! :) 14.58.00 # good job 14.58.28 # still some room for tweaking left 15.01.41 Quit antil33t (Read error: Connection reset by peer) 15.01.49 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 15.04.10 # New commit by 03bertrik (r28808): AMSv2: only switch sd cards to high speed mode for for v2 sd cards, just like is done for AMSv1 15.06.22 # r28808 build result: All green 15.15.38 # hm, the RCA sent as part of the APP_CMD in the AMSv1 driver is always 0, while it is equal to the RCA of the selected card in the AMSv2 driver 15.16.42 # oh, I think I confused myself 15.22.51 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.27.08 Quit stoffel (Ping timeout: 240 seconds) 15.29.54 Quit InsDel (Read error: Connection reset by peer) 15.30.28 Nick Stummi_ is now known as Stummi (Stummi@rockbox/developer/Stummi) 15.31.50 # does anybody have some information about the audio codec used in the ipod classic? 15.32.03 # apparently it's a cirrus one, but i don't know anything more than that 15.32.11 # does rockbox support any cirrus codec? 15.32.31 # are there publicly-available cirrus codec datasheets? 15.32.38 # do they maybe have an identification register? 15.33.06 # no, don't think we have any other targets with cirrus codecs 15.33.59 # do we have pictures of the cirrus chip? 15.45.20 # omg, the lcd code of the fuze+ bootloader is crazy 15.45.41 Join hebz0rl [0] (~hebz0rl@dslb-088-067-216-208.pools.arcor-ip.net) 15.45.56 # either is supports a large number of lcd types, either it is horribly bloated 15.47.49 Join DerPapst [0] (~Alexander@p4FE8FCF4.dip.t-dialin.net) 15.49.01 # bertrik: not of the die 15.49.06 # and the package is apple-branded 15.53.36 Quit antil33t (Read error: Connection reset by peer) 15.53.44 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 16.01.38 # New commit by 03Buschel (r28809): FS#11708 - Major speedup of iPod nano 2G. Part 1: Loop unrolling and reduction of FIFO register polling. +50% for RGB, +34% for YUV. 16.03.32 # New commit by 03gevaerts (r28810): Add MikMod plugin, ported by Jason Yu, with some minor work by Craig Mann and William Peters (FS#8806) 16.03.46 # r28809 build result: All green 16.04.59 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 16.05.58 # r28810 build result: All green 16.08.47 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.10.48 # New commit by 03Buschel (r28811): FS#11807 - Major speedup of iPod nano 2G. Part 2: Use 16 bit data width and simplify write commands. Gives another +27% for YUV. 16.11.28 *** Saving seen data "./dancer.seen" 16.12.42 # r28811 build result: All green 16.16.13 # nice fix, got faster *and* smaller :) 16.16.21 # Must be a bug :) 16.16.56 # New commit by 03Buschel (r28812): FS#11807 - Major speedup of iPod nano 2G. Part 3: Unify different write commands. No change in speed. 16.18.33 Join stooo1 [0] (~sto@f051077202.adsl.alicedsl.de) 16.18.36 Quit stooo (Read error: Connection reset by peer) 16.18.52 # r28812 build result: All green 16.22.12 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 16.23.22 # New commit by 03Buschel (r28813): FS#11807 - Major speedup of iPod nano 2G. Part 4: Introduce asm for yuv blitting. Overall speedup of part1-4 is +50% for RGB and +93% for YUV. 16.25.18 # r28813 build result: All green 16.31.00 # New commit by 03bertrik (r28814): AMSv2: handle sd card ACMDs similar to how it's done for AMSv1 16.32.40 Quit DerPapst (Read error: Connection reset by peer) 16.32.51 # r28814 build result: All green 16.33.14 Join DerPapst [0] (~Alexander@p4FE8FCF4.dip.t-dialin.net) 16.41.24 Join jpt9 [0] (~jpt9@unaffiliated/jpt9) 16.41.33 # Help! How do I get out of Doom on my Sansa Clip v2? 16.42.03 # Never mind. 16.42.47 Join ReimuHakurei [0] (reimu@68-179-162-48.bsr-c5-d1.evv.dhcp.sigecom.net) 16.46.30 # New commit by 03Buschel (r28815): iPod nano 2G does use less current since the latest optimizations. 16.48.26 Quit ReimuHakurei (Ping timeout: 240 seconds) 16.48.28 # r28815 build result: All green 16.49.22 # My god... it does temporally dithered PictureFlow... 16.49.26 # This is insane. 16.59.21 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 17.02.52 Quit T44 (Quit: Leaving) 17.12.34 # Buschel: someone should probably do some real current measurements 17.12.48 # i know for sure that the adc readings are way off, i'd suspect by ~7mA 17.13.23 # TheSeven: the numbers do pretty well match the achievable runtime 400 mAh / 17 mA => 23.5h 17.13.35 # TheSeven: I had it running for 24+ h 17.13.46 # yeah, but your ipod probably doesn't have anything near 400mAh any more 17.14.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.15.09 # well, we either correc the default capacity or use "real" mA's for the current. right now both match perfectly -- maybe because both have the same amount of deviation from reality :) 17.16.25 # btw, we really should check if we introduce the measured/averaged current consumption for the runtime estimation. this should work quite well for non-HDD targets 17.16.51 # FS#10890 17.16.56 Quit JdGordon (Ping timeout: 265 seconds) 17.17.33 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 17.17.34 # for now it is only available for nano 2G and Video 5G... 17.20.02 # GodEater: does it still not find the compiler for you? 17.24.45 # gevaerts: could/should we use mikmod's .mod detection for the metadata parser? 17.25.36 # kugel: I don't know. I think we want the metadata parser to agree with the codec 17.26.22 Quit Llorean (Quit: Leaving.) 17.27.31 Join ReimuHakurei [0] (reimu@68-179-162-48.bsr-c5-d1.evv.dhcp.sigecom.net) 17.29.34 # gevaerts: i.e.? 17.30.33 # hey kugel :) 17.31.23 # New commit by 03nls (r28816): FS#11802 by Li Jie fixing a typo in the doom buttonmap for SA9200. 17.31.34 # kugel: hm, I'm not sure *at all* now :) 17.31.59 # i've been pondering today... if it saps cpu time on end, it'll have to spend the time somewhere. so i swept what little i know about profiling out form under the carpet.... and failed miserably >_< 17.32.39 Quit efyx (Remote host closed the connection) 17.33.04 # nls: backporting candidate? 17.33.14 # r28816 build result: All green 17.33.24 # i've added -pg to the GCCOPTS variable and recompiled (freshly configured in a new build dir). but i can't coerce it to produce the file with the profiling data 17.33.41 # Buschel: assuming a constant inner resistance of the battery and constant current reading offset, the offset would be 7mA 17.33.49 # TheSeven: no, that player is classed as "unusable" so it's not part of the release 17.34.10 # kugel: I haven't actually looked at the code. What I'm mainly concerned about (maybe "concerned" is a bit strong) is that we don't need (or want) the metadata parser to have code to support mod variants the codec doesn't support 17.34.11 # (i'm currently using a compensated-by-7mA current reading to compensate for the inner resistance) 17.34.19 # n1s: oh, right 17.34.34 # since i couldn't find out what keybinding is Quit (and noone else here seems to know) i tried attaching gdb and called exit() from inside the program 17.34.43 # but not even that got it to dump the profiling data 17.34.44 # gevaerts: what does the codec support? 17.35.04 # * kugel thinks the codec should perhaps be dropped 17.35.39 # codec? 17.35.41 # kugel: I don't know exactly 17.35.41 # amee2k: IIRC currently the only exit way is the X button on the window :) 17.36.03 # hehe. which doesn't exist when i run it full screen >_> 17.36.09 # TheSeven: hmm, this would mean my (internally measured) 18mA - 7mA = 11mA real current. 11mA * 24h (real runtime) => 264 mAh battery capacity. sounds reasonable, I always thought that nano's had 300mAh and not 400mAh batteries... 17.36.25 # Dropping the codec would imply not supporting mod files in regular playlists any more for people who only have "simple" mod files 17.36.28 # amee2k: should be easy enough to add an exit combo, though 17.37.12 # gevaerts: we could make the playlist code call the plugin :) 17.37.19 # didn't we want something like that anyway? 17.37.29 # (for movies?) 17.37.36 # Sure we could, but that's going to be nontrivial 17.37.36 # mmmh, i think i found where the key presses are evaluated. no idea how to properly trigger the rockbox shutdown though 17.38.08 # i tried tracing how the ipod center button + play/pause shutdown works, but couldn't find it yet 17.38.15 # amee2k, kugel: you could add a shutdown menu item on android and call exit from there? 17.38.38 # amee2k: center button + play/pause isn't shutdown on ipod 17.38.45 # It's emergency hardware reset 17.38.46 # kugel: assuming that its is aplugin only because it needs more memory than a regular codec wouldn't it be easier to let codecs steal the buffer than hacking up the playlist code? 17.38.55 # s/its/it/ 17.39.24 # isn't the problem that the buffer is in use while a codec is running? 17.39.31 # n1s: hack up the playlist code, or hack up the buffering code? Yes, nice choice there :) 17.39.38 # (does stealing the audio buffer from a plugin neccessarily stop playback?) 17.39.48 # TheSeven: yes 17.39.50 # (stealing only parts of it, not the entire buffer of course) 17.39.58 Quit ze_ (Quit: Ex-Chat) 17.40.01 # it's an all or nothing thing 17.40.03 # You can't steal parts of it with the current code 17.41.02 # * TheSeven proposes some kind of steal-from-audiobuffer-malloc thing and grabs his pitchfork just in case... ;) 17.41.17 # kugel: why doesn't sys_poweroff() just call exit() in the app? 17.41.29 Quit bluebrother (*.net *.split) 17.41.29 Quit bmbl (*.net *.split) 17.41.29 Quit sasquatch (*.net *.split) 17.41.29 Quit elcan (*.net *.split) 17.41.29 Quit simonrvn (*.net *.split) 17.41.29 Quit _jhMikeS_ (*.net *.split) 17.41.29 Quit yosafbridge (*.net *.split) 17.41.29 Quit pjm0616 (*.net *.split) 17.41.30 Quit crwl (*.net *.split) 17.41.30 Quit zu (*.net *.split) 17.41.30 Quit literal (*.net *.split) 17.41.30 # i think it would be nicer (not nice, but nicer) to let some codecs steal the buffer which would trigger a full rebuffer when they exit than playing some files in plugins 17.41.54 # n1s: and where does the codec get its data input from then? 17.42.08 # gevaerts: which app? 17.42.23 # kugel: well, any, really 17.42.36 # Or the sim too actually 17.42.55 # sys_poweroff is never called IIRC 17.43.09 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.43.09 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 17.43.09 Join sasquatch [0] (~username@p4FF2DF34.dip.t-dialin.net) 17.43.09 Join elcan [0] (user36@pr0.us) 17.43.09 Join simonrvn [0] (simon@210.23-ppp.3menatwork.com) 17.43.09 Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) 17.43.09 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 17.43.09 Join pjm0616 [0] (~user@110.9.28.120) 17.43.09 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 17.43.09 Join zu [0] (~zu@ks355000.kimsufi.com) 17.43.09 Join literal [0] (hinrik@v.nix.is) 17.43.21 # TheSeven: right, it needs to be a little cleverer than just taking the buffer 17.44.44 # isn't the root problem that it needs to read the file non-linearly? 17.45.38 # could some interface to peek ahead in the audio buffer data without consuming it solve it? 17.45.57 # It also may need to keep more data in RAM 17.46.42 # how much? could that be handled by stealing the plugin buffer? 17.47.00 Quit bluebrother (*.net *.split) 17.47.00 Quit bmbl (*.net *.split) 17.47.00 Quit sasquatch (*.net *.split) 17.47.00 Quit elcan (*.net *.split) 17.47.00 Quit simonrvn (*.net *.split) 17.47.01 Quit _jhMikeS_ (*.net *.split) 17.47.01 Quit yosafbridge (*.net *.split) 17.47.01 Quit pjm0616 (*.net *.split) 17.47.01 Quit crwl (*.net *.split) 17.47.01 Quit zu (*.net *.split) 17.47.01 Quit literal (*.net *.split) 17.47.13 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 17.47.38 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.47.38 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 17.47.38 Join sasquatch [0] (~username@p4FF2DF34.dip.t-dialin.net) 17.47.38 Join elcan [0] (user36@pr0.us) 17.47.38 Join simonrvn [0] (simon@210.23-ppp.3menatwork.com) 17.47.38 Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) 17.47.38 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 17.47.38 Join pjm0616 [0] (~user@110.9.28.120) 17.47.38 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 17.47.38 Join zu [0] (~zu@ks355000.kimsufi.com) 17.47.38 Join literal [0] (hinrik@v.nix.is) 17.47.53 # I don't think that's enough in general. Also, that's not at all a clean thing to do right now 17.48.12 # i don't think there is a clean option right now 17.48.30 # so we either need to do major restructuring or go for a dirty solution 17.49.15 # kugel: it doesn't seem to be effective either. at least not when i attach gdb to call it 17.49.29 # the cleanest way to do such things would probably relocateable codecs/plugins allocated from the audio buffer 17.49.34 # amee2k: what did yo do? 17.50.05 # at least for high-mem targets 17.50.10 # attach gdb to the process, then "call sys_poweroff()" 17.50.24 # that does nothing 17.50.55 # button-sdl.c is where you'd add a exit combo 17.51.00 # TheSeven: how does that solve the problem? 17.51.21 # mmm just wanted to see if it works at all 17.51.44 # also, lots of stuff in apps/ seems to have calls to it 17.51.53 # plugins/codecs could allocate as many space as they need and we wouldn't waste memory for things that aren't loaded at that time 17.52.14 # multiple plugins at the same time (pebbles?) would also be possible 17.52.50 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 17.52.54 # Oh, sure it would allow lots of things, but I don't see how it handles the need for codecs to use more memory on its own 17.53.24 # what i'm thinking of is roughly the following: 17.53.27 # amee2k: http://pastie.org/1370432 should map F6 to exit 17.54.21 # we would need a way to alloc chunks of buffer without stopping playback 17.54.22 # we have core .text/.bss at static addresses, maybe some buffers for e.g. dircache, and the rest is used as general-purpose memory 17.55.07 # in that general-purpose memory codecs and plugins (probably with their .text/.bss sections separated) could be loaded, and audio buffer data would float around them 17.55.39 # as long as it's only four non-audio chunks in that buffer, i don't think fragmentation will be a concern on >=8MB targets 17.56.26 # and the mod codec could calculate how much memory it needs and size its .bss chunk accordingly 17.56.59 # yeah, I know, no MMU, WhyNoMalloc etc., but I can't think of a better way right now. 17.57.07 # TheSeven: yes, but you'd still need dynamic resizing of the audio buffer, which on its own (without relocation) would solve the problem too 17.57.45 # kugel: sys_poweroff() is called by the sim if you hold the shutdown button 17.58.10 # So I don't really know why that one doesn't just exit() 17.59.00 # What RaaA would do with that is its own problem of course, but possibly a Player-like Shutdown item in the root menu might be a good idea 17.59.32 # gevaerts: hmm, that might be true, but it won't allow e.g. the whole codec, plugin and audio buffer space to be used by a huge codec 18.00.11 # TheSeven: I'd argue that that's not desirable anyway :) 18.00.40 # kugel: system-sdl.c, likes 68..70 ... wtf is that stub?! 18.00.44 # gevaerts: the sdl exit code does a lot of cleanup before the exit() call 18.00.49 # s/likes/lines/ 18.00.59 # yes all the different schemes come down to being able to resize the audio buffer on the fly 18.01.13 # amee2k: yes it is :) 18.01.33 # was that what i called from gdb? 18.02.19 # Taking away the *entire* audio buffer will probably introduce lots of fun issues, codecs habe the entire codec buffer today, and the plugin buffer is used by some non-plugin things already (the playlist viewer?) 18.02.51 Quit stooo1 (Ping timeout: 265 seconds) 18.05.00 # Hey. I'm on Vista Ultimate, running the latest version of Rockbox Utility. I have a Sansa Clip v2, and I'm trying to generate a voice file for it... 18.05.17 # Rockbox Utility keeps crashing around 72% or so through the encoding process. 18.05.32 # Any ideas? 18.06.16 # Talkfiles seem to work fine, though. 18.06.53 Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) 18.11.29 *** Saving seen data "./dancer.seen" 18.12.21 Quit ReimuHakurei (Ping timeout: 240 seconds) 18.15.21 Quit moos (Ping timeout: 276 seconds) 18.18.22 # New commit by 03Buschel (r28817): Tab police. 18.20.50 # r28817 build result: All green 18.21.32 Quit Topy44 (Ping timeout: 245 seconds) 18.22.35 # Buschel: please don't do that, it makes merging upstream changes a lot more annoying 18.23.36 Join stoffel [0] (~quassel@p57B4AD99.dip.t-dialin.net) 18.23.42 # hmm, thought this would be no with the right tools... will keep my fingers off this in future 18.24.50 # wanted to type "no problem", of course 18.24.57 # also the indentation is messed up in some places see codebook.c:91-93 18.25.40 # svn merge cant ignore whitespace differences afaiu so it creates conflicts all over the place 18.29.05 # just revert, if you are expecting issues with the next upstream merge 18.34.01 # i'll do it in a bit then 18.36.29 Quit designate72 (Quit: Leaving) 18.45.25 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.50.07 # what instruction is best for getting the two least significant bits of a register into some condition bits? 18.54.04 Join casainho [0] (~chatzilla@2.81.156.5) 18.57.57 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 18.59.09 # New commit by 03nls (r28818): Revert tab police as it makes merging upstream changes more annoying and messed up indentation in some places. 18.59.59 Part jpt9 19.01.09 # r28818 build result: All green 19.01.29 # TheSeven: tst? 19.02.39 # it looks like MOV Ry, Rx,LSL#31 might be the best option 19.02.46 Join saratoga [0] (600afc5f@gateway/web/freenode/ip.96.10.252.95) 19.03.14 # er, MOVS of course 19.04.47 # does anyone know why the AMSv1 players briefly get confused and try to enter USB mode when plugging in an AC charger? 19.05.17 # it seems they detect any power on the dock connector as USB, try to connect, realize there is no USB device, and then disconnect 19.05.25 Join ReimuHakurei [0] (~reimu@74.112.212.15) 19.05.30 # the e200v1 however doesn't do this 19.05.58 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 19.06.04 # saratoga: my fuze does that when i connect a regular usb connection while rb is running 19.06.22 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 19.06.23 # i can only connect successfully if i insert the cable while the fuze is off 19.06.24 # instead of going into USB mode? 19.06.26 # yes 19.07.04 # on the fuzev1? 19.07.12 # yes 19.07.22 Quit ReimuHakurei (Read error: Connection reset by peer) 19.07.25 # might be worth fileing a bug report on that if you haven't 19.08.03 # so we know theres a dev with usb problems on the fuze and not just the occasional user 19.08.21 # eh, now it seems to work but it used to do that... 19.08.56 # i should probably try to bisect it to see if any recent change fixed it 19.12.58 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 19.16.33 # i won't do that today though 19.22.46 Quit Llorean (Quit: Leaving.) 19.24.38 Quit efyx (Remote host closed the connection) 19.28.09 # how can i run make in a way so it shows the full commands that it runs? 19.28.20 # and not just "CC " 19.29.29 # amee2k: make V=1 19.31.25 # hm. 19.32.27 # thanks for your quit patch, it works (except for a typo on line 35 ;) but i'm still not getting any profiling info >_< 19.32.48 # i didn't even test compile it :p 19.33.09 # i kinda figured that from the typo :) 19.33.34 # but now i'm beginning to doubt that i'm compiling with the proper profiling options here 19.34.08 # also, if it works then who cares if it was tested >_> 19.38.57 Join mortalscan [0] (~mortalsca@109.169.55.155) 19.46.07 Quit shai (Ping timeout: 245 seconds) 19.46.19 # saratoga: regarding amsv1 USB, thats how ranma set it up. It tries to make a data connection and then times out to charge mode. I find it rather annoying, but do not know enough to fix it. 19.47.09 # is there a GPIO or ADC pin we can read to check for a charger? 19.47.16 # IIRC thats how PP does it 19.48.36 # In what way does it "try to connect"? 19.49.12 # We don't do explicit charger detection on any target 19.50.23 # gevaerts: playback stops, you get the USB screen, then it disconnects and you get the WPS again 19.51.25 # That's weird 19.51.44 # * gevaerts looks at code 19.52.06 # where would this be in the code? 19.52.28 # http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/usb-drv-as3525.c?view=annotate line 675 19.52.42 # usb.c is where everything comes together 19.52.47 # * gevaerts looks there now 19.53.00 # It's been a while since I looked at this though 19.55.45 # saratoga: I think on amsv1 dbop_din bit 9 can be used for dock/charger 19.56.21 Quit Strife89 (Ping timeout: 240 seconds) 19.56.22 # mc2739: doesn't that depend on the charging device to short some pin on the dock though? 19.57.06 Join funkyjive [0] (~43027688@giant.haxx.se) 19.57.41 # OK, the PP code sends USB_POWERED or USB_UNPOWERED on connect (or disconnect), and USB_INSERTED when it detects some activity on the bus 19.57.42 Join Strife89 [0] (~Strife89@adsl-67-57-58.mcn.bellsouth.net) 19.57.45 # PP seems to have some code for determining if theres a USB controller, but i don't understand it 19.57.46 # saratoga: that might be correct, I have confirmed that with dock connections, but I do not have a charge only device 19.57.59 # AMS sends USB_INSERTED directly 19.58.10 # how easy is that to fix? 19.58.29 # I think I'd like to report a bug, but I'd like to run it by you guys to make sure it is not "works as designed" 19.58.44 # mc2739: as I understand it, theres no analog 'usb connected' wire to sense, you have to actually ask the wire to do something and see if a controller responds 19.59.01 # when you have an album with a large number of tracks, you can see that rockbox sorts the track numbers alphabetically and not numerically as it should ... 19.59.20 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.59.52 # funkyjive: you mean in the file browser? 20.00.43 # When I go Database->Album->Album Name 20.01.05 # gevaerts: thanks for your tip the other day, btw. you are totally the man. 20.01.27 # I think the problem occurs when you have over 99 tracks .... 20.01.49 # right. I don't know about the database really 20.02.45 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 20.03.11 # when I look at this particular album, it goes 01,02 ... 08, 09,10,100,101 .... 109,11,110,111,112 .. 119, 12 20.03.46 # that is very weird naiming 20.03.47 # I think I am going to try to side-step it by seeing if I can tag the track numbers to make sure they are 0 padded .... 20.05.22 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 20.05.29 Quit BHSPitMonkey (Remote host closed the connection) 20.07.51 # I do know that it orders the tracks correctly on my wifes Sansa View. So to me it feels like a bug .... 20.08.06 Quit Llorean (Quit: Leaving.) 20.09.39 # saratoga: it may be reasonably easy to change, but I'm not sure 20.11.19 # One difference is that PP uses a different model. While most drivers still use the usb.c tick task to poll for status changes, the ARC driver sends events on status change 20.11.27 # it looks like a bug for this has been opened: 11695 20.11.30 *** Saving seen data "./dancer.seen" 20.12.06 Join ReimuHakurei [0] (~reimu@74.112.212.15) 20.13.01 # saratoga: if you want to have a go, firmware/target/arm/as3525/usb-drv-as3525.c around line 758 is probably where you want to start. If you get the USB_DEV_INTR_USB_RESET interrupt, usb_detect() in usb-as3525.c should start returning USB_INSERTED instead of USB_POWERED (it currently always says INSERTED) 20.13.25 # This should of course be cleared when you disconnect 20.18.19 # * gevaerts test-compiles a quick patch 20.20.44 # saratoga, n1s, mc2739: http://pastebin.com/xEV4Saiy 20.20.55 # It compiles, but it's totally untested 20.21.22 # gevaerts: i'll test later 20.22.07 # My guess is that all USB drivers apart from ARC have this problem 20.22.50 # And I think it could be handled in a way that the driver doesn't actually have to know about this 20.34.53 # gevaerts: e200v2 will not enter USB mode with your patch - charging mode only 20.36.20 # hm, that's not what I wanted to achieve... 20.38.43 # mc2739: in usb.c, move the #ifdef USB_DETECT_BY_DRV on line 247 down one case, so the USB_POWERED case is handled 20.40.22 # That would give you http://pastebin.com/vdJRKEVg 20.40.58 # It also wouldn't be a fully ready-for-commit fix any more unfortunately. I'm not sure if that case can be enabled for all targets 20.41.07 Quit Mataniko (Ping timeout: 245 seconds) 20.41.30 # Anyone with a nano2g around? Doesit suffer from the same problem? 20.41.45 # fuze is the same (only charges with patch 20.41.46 # ) 20.43.24 # gevaerts: with that change I not enter USB mode - testing dock connection next 20.43.54 # not? 20.44.35 # sorry - remove not 20.44.47 # ok :) 20.44.57 # with the change usb works fine here 20.45.13 # dock connection = charging only 20.45.43 # without any interruption? 20.45.55 # Playback continues as expected? 20.46.00 # correct 20.46.16 # great 20.46.23 # So all we need is a clean way to do this 20.46.38 # Preferably one that also gets the other targets 20.46.52 Quit Buschel (Ping timeout: 240 seconds) 20.46.55 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 20.47.37 # usb.c is a mess :\ 20.48.24 # thanks for looking into this 20.48.27 Quit saratoga (Quit: Page closed) 20.50.15 # ah, right... 20.51.10 # I am totally puzzled why usb works in bootloader and not in rb itself on HD300. I compared gpios and there is no relevant difference between bootloader and rb. Bridge enumerates correctly but can't access disk??? as I get 'Device offlined - not ready after error recovery' 20.51.31 # anyone have any clue? 20.51.39 # wodz: ata driver issues? 20.52.03 # gevaerts: at what level? 20.52.41 # No idea really... It sounds as if the hard drive somehow isn't in the proper state 20.52.49 # Buschel (for the logs): With some improvements, I'm getting 206fps quarter and 51fps full RGB in emBIOS with DMA 20.55.13 # without DMA, it's a whopping 0.01% slower 20.55.29 # n1s, mc2739: http://pastebin.com/BHPDwpFz 20.55.36 # That one should be commit-ready 20.57.26 # ok, testing, i get one hunk failing in usb-as3525.c for some reason 20.57.52 # did you revert my previous patch? 20.58.03 # yes, it happened with that too 20.58.15 # weird 20.58.50 # what does freeze_lock() do? 20.58.54 # patch says "patch unexpectedly ends in middle of line" and the last hunk fails but i applied it manually 20.59.08 # Right. That's a pastebin issue 20.59.19 # oh 20.59.27 # I've seen that too 21.00.30 # wodz: it locks the player and freezes the user, in punishment for misuse of rockbox ;) 21.01.15 # pamaury: that is expaining everything :-) 21.01.28 # *explaining 21.02.44 # gevaerts: works fine here 21.03.45 # New commit by 03gevaerts (r28819): Move AMSv1 USB to the USB_DETECT_BY_DRV model, so connecting to a dumb charger works without interrupting playback 21.03.48 Nick balintx is now known as _balintx (~balintx@fibhost-67-58-201.fibernet.hu) 21.04.00 # A similar thing should probably be done for other drivers 21.04.24 # gevaerts: USB and dock connection work fine here, too 21.04.41 # what exactly does one need to do for this? 21.05.41 # r28819 build result: 5 errors, 0 warnings (gevaerts committed) 21.06.09 # TheSeven: usb_detect() should return USB_POWERED, USB_INSERTED, USB_EXTRACTED or (optionally, less important) USB_UNPOWERED, instead of just USB_INSERTED or USB_EXTRACTED. 21.06.16 Quit user890104 () 21.06.38 # unpowered being bus activity but no power? 21.06.40 # The best way to distinguish between those is to use the bus reset interrupt (which you should already handle) 21.06.51 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 21.07.14 Quit _balintx (Remote host closed the connection) 21.07.42 # * gevaerts dislikes that red 21.08.02 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 21.12.02 # I'm puzzled. Why does this red happen *only* for m200v4? 21.14.40 # gevaerts: could it be that m200v4 does not have HAVE_USB_POWER defined 21.14.53 # ah, right 21.15.55 # I actually think we should remove those #ifdefs from the enum 21.16.12 # They won't be used, but an unused enum value also doesn't really hurt 21.16.44 Quit bmbl (Quit: Verlassend) 21.17.38 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 21.20.17 # New commit by 03gevaerts (r28820): Only return USB_POWERED if USB_DETECT_BY_DRV is actually defined, which might not be the case for e.g. bootloaders (also fix red) 21.20.47 Quit GeekShadow (Quit: The cake is a lie !) 21.22.32 # r28820 build result: All green 21.22.42 # Buschel: exact same FPS values in rockbox with SVN head 21.24.23 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 21.24.53 Quit n1s (Quit: Lämnar) 21.33.25 # * TheSeven wonders how to fix those dozens of compilation errors that are still remaining for the ipod classic 21.33.57 # btw, at which stage should I first commit it? 21.34.01 Quit Kupop (Ping timeout: 255 seconds) 21.34.43 # When it compiles I'd say 21.35.42 Join Buschel [0] (~chatzilla@p54A3BA20.dip.t-dialin.net) 21.35.53 Join saratoga [0] (9803c57f@gateway/web/freenode/ip.152.3.197.127) 21.36.30 # * TheSeven wonders if this is a good idea: http://pastie.org/1370996 21.36.56 Quit funkyjive (Quit: CGI:IRC (EOF)) 21.37.06 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 21.37.18 # right now those values are duplicated across a dozen files 21.37.45 # and I need to wrap the task file accesses into a macro, as one can't access them that easily on the classic 21.40.29 # TheSeven: good to see rockbox headrev reaches the ultimate DMA emBIOS transfer rates as well 21.40.56 # TheSeven: seems like the datarate from S5L to LCD is the limiting factor 21.42.27 # Buschel: do you get the same numbers? 21.42.33 # TheSeven: I tried to raise the clock of the IF between S5L and LCD (lowest 3 bits in LCD_CON), but HCLK/4 is the maximum working one -- even when unboosted 21.43.04 # TheSeven: no, mine are much higher -> full RGB 129.5, quarter RGB 516.0 21.43.11 # (for boosted) 21.43.36 # hm, so what could be affecting it? 21.44.33 # either some different setting in S5L's LCD IF or some setting of the LCD 21.44.36 # Buschel: do you know the bus width of the LCD interface? 21.44.49 # should be 8 bit 21.44.59 # if it's 8 bits, the maximum at 24Mhz should be like ~500fps, if it's serial it should be ~60fps 21.45.10 # (for full RGB) 21.46.30 # how do get those numbers? 21.47.44 # weird ubuntu requires texinfo to run rockboxdev.sh 21.48.12 # doesn't building gcc require it? 21.51.52 Quit factor (Ping timeout: 240 seconds) 21.55.14 # TheSeven: from the preliminary S5L spec the IF should be serial, 3 pin-SPI MPU 21.55.26 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 21.55.53 # Buschel: doesn't that mean that your fps numbers can't be right? 21.56.52 # Utchybann, measured my numbers on his nano as well 21.57.02 # there seem to be differences somewhere... 21.57.38 # oops, didn't want to add that "," in my former post 21.57.57 # TheSeven: look at firmware/target/coldfire/ata-target.h and compare with your pastie 21.58.47 # wodz: that's why i have that #ifndef hell 21.59.05 # IIRC all other targets had identical values, which are needlessly duplicated 21.59.16 Join BHSPitMonkey [0] (~stephen@68-191-210-67.dhcp.dntn.tx.charter.com) 21.59.17 # (and I would have to duplicate them once again) 21.59.23 Quit BHSPitMonkey (Changing host) 21.59.23 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 22.00.11 Quit Llorean (Quit: Leaving.) 22.01.28 Join Keripo1 [0] (~Keripo@eng428.wireless-resnet.upenn.edu) 22.02.17 # well, I don't like this massive ifdefs but I have no cleaner proposition 22.04.02 Quit Keripo (Ping timeout: 265 seconds) 22.04.51 # one would need an "if this is not defined, define it as xyz" preprocessor command :) 22.05.06 # can preprocessor macros expand to preprocessor directives? :) 22.05.43 # I don't think so 22.06.07 Quit factor (Read error: Operation timed out) 22.06.14 Quit stoffel (Remote host closed the connection) 22.07.01 # what do you want to do ? 22.07.07 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 22.07.29 # TheSeven: maybe just add comment on top of this stating that if you need something else for your target define this in ata-target.h in target tree and point to colfire dir for reference 22.08.30 Quit froggyman (Remote host closed the connection) 22.08.33 # maybe one huge #ifndef TARGET_DEFINES_ATA_CONSTANTS around it, instead of individual ifndefs? 22.11.07 # That may look nicer, but I think it's more error prone 22.11.10 # looks hacky for me 22.11.31 *** Saving seen data "./dancer.seen" 22.12.18 # TheSeven: it might be that the S5L spec has an error in the LCD_CON description as well. maybe the LCD IF is not set to HCLK/4, but to HCLK/2. this would perfectly match the measurements 48MHz serial IF = ~6 MB/s = ~130 fps 22.12.26 # * gevaerts doesn't think that a long list of #ifndef XX #define XX is that bad 22.12.57 Join yahya69 [0] (~yahya69@p5DCE36E5.dip.t-dialin.net) 22.13.04 # TheSeven: still does not explain why your LCD is slower... 22.13.33 # I'd protect the #defines by a single ifdef using one of them (i.e. not an extra TARGET_DEFINES_ATA_CONSTANTS) 22.13.58 # kugel: but what if a target only needs to override one or two? 22.14.50 # how likely is that? you'd need to duplicate all then 22.16.33 Quit Kupop (Ping timeout: 240 seconds) 22.18.17 Quit mc2739 (Quit: leaving) 22.18.47 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 22.19.12 Part yahya69 22.24.12 Quit soap (Quit: soap) 22.24.30 Quit Keripo1 (Quit: Leaving.) 22.25.07 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 22.26.46 Quit liar (Ping timeout: 240 seconds) 22.28.07 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 22.29.52 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.37.22 # TheSeven: what is your LCD_PHTIME set to? 22.38.17 Join yahya69 [0] (~yahya69@p5DCE36E5.dip.t-dialin.net) 22.40.35 # * TheSeven needs to look up the address 22.41.22 Join soap [0] (~soap@rockbox/staff/soap) 22.41.32 # if I want to computer the numerical value of a pointer, whats the right cast? 22.41.35 # (int) gives me a warning 22.41.49 # (u)intptr_t 22.42.08 # Buschel: 0xa1f9602 22.42.18 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 22.42.32 # (if i'm assuming correctly that it's at 0x3c600020) 22.43.12 # 0x38600020 22.43.28 # ah, right, ahb, damn... 22.43.38 # that would be 0x88 22.44.10 Join MethoS- [0] (~clemens@134.102.106.250) 22.44.28 Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) 22.44.44 # hmm, what happens if you set it to 0x44 or 0x22? 22.44.59 Quit InsDel (Client Quit) 22.46.00 # 128 (full) / 512 (quarter) fps at 0x22 \o/ 22.46.35 # :o) 22.46.46 # there we go 22.46.58 # does 0x11 work? 22.47.07 # that isn't even allowed according to the datasheet 22.47.16 # I know :) 22.47.26 # but seems to work 22.47.39 # 171/682 fps with DMA 22.47.50 # wow 22.47.51 Join InsDel [0] (~haqr.net@unaffiliated/insdel) 22.47.56 # let's try without 22.48.07 # (we might be hitting DMA bandwidth limits :) ) 22.48.11 Quit dantje (Quit: Ex-Chat) 22.49.23 # hm, no, the other way round 22.49.34 # 350/87 fps 22.49.56 # hehe, this recalls me comment in some engineering software - "here we define mass for all elements - let's try without" 22.49.57 # ? 350 fps full, 87 quarter ? 22.50.31 # we have too much lcd_puts_* functions 22.50.38 # I feel bad in adding even more 22.51.09 # Buschel: no, i reversed the order for some reason 22.51.39 # ahh, ok. maybe this is caused by transmission errors / repeats? 22.51.44 # whether the framebuffer is in DRAM or IRAM doesn't seem to make a difference 22.52.14 # yes, the limiting factor is still the LCD IF 22.52.50 # Buschel: it's probably caused by us needing to check the fifo all the time (i'm writing using a stmcsfd r12, {r0-r3} instruction) 22.53.08 # when using DMA, there are hardware signals for this :) 22.53.25 # btw, this is with burst size 4, data size 16 bits 22.54.05 # i wonder why there is no factor 2 speedup for the 0x22 vs. 0x11 thing 22.54.08 # * TheSeven goes for 0x00 :) 22.54.24 # Infinite speedup? :) 22.54.45 # 195fps full screen, 774fps quarter :) 22.54.59 # now that's insane :) 22.55.00 # bertrik: do you still need testing on the fuze? 22.55.34 # what about graphic glitches? 22.55.43 Join Rob2222 [0] (~Miranda@p4FFF119B.dip.t-dialin.net) 22.55.49 # TheSeven: that's fast :) 22.55.54 # 1291µs for a quarter update, 5107µs for full screen 22.56.02 # (averaged across 1000 iterations) 22.56.25 # * TheSeven tries 10000 22.56.49 # using DMA? what when using rockbox svn and just changing LCD_PHTIME? 22.58.40 # * TheSeven would need to recompile rockbox to test that :) 22.59.03 # didn't you have a fast machine? ;) 22.59.19 Quit Zarggg (Quit: Zarggg) 22.59.24 # i'm compiling rockbox on a 2.0GHz singlecore P4 with DDR1 RAM 22.59.33 # takes several minutes for a complete rebuild of one target 22.59.54 # Buschel: you said the LCD IF would be the bottleneck? :) 23.00.26 # 257 fps full screen, 1014 fps quarter from IRAM 23.00.42 # I still think so. 195 fps is ~9 MB/s. RAM is much faster. 23.00.58 # Buschel: SDRAM latencies... 23.00.58 # oops ;) 23.01.56 # * TheSeven thinks those frame rates are pretty much ridiculous, considering the LCD's internal panel scanning will probably much slower 23.02.29 # high rates reduce the CPU load for WPS'es 23.03.01 # apparently scheduling overhead starts to get a significant impact :) 23.07.45 # crap just realized i'd have to unroll this code another 2x to make it optimal on ARM11 because of the 64 bit aligned loads thing 23.08.00 # woah 23.08.16 # somehow i didn't realize that if I made each variable half as big i'd have 2x the possible alignments :) 23.08.19 # 16% cpu load even though I use DMA 23.09.24 # accessing the debugger to read the CPU load made it drop a whole FPS :) 23.10.37 # oh, wait 23.10.57 # 16% CPU load by the thread issuing the LCD updates, 84% by the scheduler! 23.11.08 # (waiting for DMA seems to yield instead of sleep) 23.13.00 Quit TheLemonMan (Quit: free(me)) 23.15.05 # gevaerts: you where right - this must be rockbox ata driver which screw up usb bridge on HD300. If I cut off power to the drive and enable it again before enabling USB bridge - it works but panics after cable unplug 23.16.54 Join JdGord [0] (~jonno@122.110.159.167) 23.16.54 # Buschel: making it sleep properly clips the FPS rates to 99fps for DMA because of the scheduler's 100Hz tick (no adaptive wakeups yet), but reduces CPU load to <1% :) 23.17.55 # shouldn't this also reduce current consumption? 23.19.02 Quit {phoenix} (Remote host closed the connection) 23.19.22 # Buschel: probably 23.19.30 # but it won't be terribly much 23.20.24 # now we'll need to figure out what the minimum allowed values for that register are for the individual LCD types 23.21.17 # what does apple set it to? 23.22.31 # should be 0x22 on my nano 23.26.52 # identify_info.bin is in little endian or big endian? 23.34.10 # someone with an ilitek lcd around? 23.34.19 # they seem to be set to 0x88 indeed 23.37.03 Join thegeek_ [0] (~nnscript@172.80-203-148.nextgentel.com) 23.37.27 Join Sudos_ [0] (~windstar_@c-68-38-20-238.hsd1.nj.comcast.net) 23.38.32 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 23.39.30 Quit hebz0rl (Quit: Leaving) 23.40.02 Join pamaury_ [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) 23.40.16 Join mortalscan_ [0] (~mortalsca@109.169.55.155) 23.40.16 Join ack [0] (~ack@mingbai.org) 23.41.01 Join factor_ [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 23.41.21 Join Utchy [0] (~Utchy@rps6752.ovh.net) 23.41.31 # if the arm manual lists a 3 cycle result latency, does that mean using it on the next op incurs 2 stall cycles or 3 stall cycles? 23.41.41 # e.g. if something is fully pipelined is the latency 0 or 1 23.42.03 Join liar_ [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.42.47 Quit Sudos (Ping timeout: 240 seconds) 23.42.48 Quit mortalscan (Ping timeout: 240 seconds) 23.42.48 Quit ack` (Ping timeout: 240 seconds) 23.42.48 Quit factor (Ping timeout: 240 seconds) 23.42.48 Quit pamaury (Ping timeout: 240 seconds) 23.42.48 Quit tchan (Ping timeout: 240 seconds) 23.42.48 Quit thegeek (Ping timeout: 240 seconds) 23.42.49 Quit liar (Ping timeout: 240 seconds) 23.42.49 Quit yahya69 (Ping timeout: 240 seconds) 23.42.49 Quit guymann (Ping timeout: 240 seconds) 23.42.49 Quit Utchybann (Ping timeout: 240 seconds) 23.42.49 Quit leavittx (Ping timeout: 240 seconds) 23.42.50 Quit Guinness` (Ping timeout: 240 seconds) 23.42.50 Join leavittx [0] (~leavittx@89.221.199.187) 23.42.50 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 23.43.21 Quit robin0800 (Read error: Connection reset by peer) 23.43.27 # * Buschel is puzzled by the logic of LCD_PHTIME and LCD_CON registers 23.43.28 # ah its 2 cycles of stall 23.43.51 # TheSeven: the spec again contradicts what is measured... 23.46.16 # will get some sleep now, see you 23.46.20 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 23.46.21 Quit pamaury_ (Read error: Connection reset by peer) 23.46.25 Join guymann [0] (~charles@69.0.8.105) 23.51.45 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 23.52.55 Quit JdGord (Quit: Bye) 23.55.41 Quit the_Kyle (Ping timeout: 265 seconds)