--- Log for 17.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 14 days ago 00.01.36 # cabbiev2 (I also believe cabbiev3) already display albumart. I don't understand what you want to tell with the tags you quoted - did you add them again? Also, I think you typed %C1 (as the number) but it should be %Cl (lower case L) and needs parameters like position and width and height 00.06.11 Join BdN3504 [0] (n=5ce22714@gateway/web/cgi-irc/labb.contactor.se/x-5978cc22848336b2) 00.07.07 # how do i use the info presented in dmesg to mount a usb device in the vmware image? 00.08.38 # w/o editing Cabbie 2 or 3 it does not display the converted bmp's 00.08.52 # Ipod 60gig 00.09.09 # aaah, sorry i think i got it myself it says scsi 2 so that 00.09.17 # will be sdb right? 00.17.41 # gevaerts: Zagor didn't change anything yet w.r.t to the weird build round times, right? 00.18.12 Quit Robert777 () 00.18.14 # I see 277s now which seems more reasonable than the 400+ which were before 00.18.24 # although, there's 37 clients now, not exactly comparable 00.23.40 # kugel: no. Maybe this runaway speculative build detection had some side effects? 00.23.55 Quit DarkDefender ("Leaving") 00.26.11 Join stephen_ [0] (n=stephen@86-40-168-77-dynamic.b-ras2.srl.dublin.eircom.net) 00.26.44 Quit BdN3504 ("CGI:IRC (EOF)") 00.27.51 # about the cygwin sim build warnings which showed up in the build table too - they are there for quite some time already and it was mentioned here when they started and at a later time I guess too. You can also see them when you crosscompile windows sims under Linux 00.32.30 # gevaerts: possibly 00.35.12 Quit bertrik ("De groeten") 00.37.47 Quit kugel (Remote closed the connection) 00.41.29 Quit stephen_ ("Leaving") 00.42.15 # New commit by 03mt (r21909): Remove an overlooked, unused float from struct COOKContext. 00.42.16 # * roolku discovered another problem with the build system: the mrobe build faild, but is not indicated in red: http://build.rockbox.org/shownewlog.cgi?rev=21908;type=mrobe100 00.42.25 # mrobe100 that is 00.43.41 Quit evilnick_7 ("Page closed") 00.45.12 # infact all builds that have the pegbox plugin have failed? 00.51.52 Join funman_ [0] (n=fun@rockbox/developer/funman) 00.52.32 Nick funman_ is now known as funman (n=fun@rockbox/developer/funman) 00.53.47 # gevaerts: I've updated the storage rework and D2 SD patches, if you could give them a quick once-over for sanity. "works here for me" 00.54.45 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 00.54.50 # shotofadds: where is the SD code for D2 ? 00.55.20 # funman: fs#10415. it's very much based on the PP driver. 00.55.42 # New commit by 03roolku (r21910): remove references to pegbox bitmaps that were removed in r21907 (problem not detected by build system) 00.56.30 Quit flydutch ("/* empty */") 00.58.24 # shotofadds: are the functions at the end of the new file needed ? (sd_sleepnow, sd_disk_is_active, sd_soft_reset, sd_spinup_time) 00.58.52 *** Saving seen data "./dancer.seen" 01.00.08 # funman: they're needed for the storage rework (fs#9545). whether they are needed at all is a whole different discussion... 01.00.40 # i'd like to see a way of getting rid of the nonsensical ones (sd_spin et al) 01.00.51 # zagor/bagder: 2009-07-16 23:58:44 Server refused connection: error duplicate name! <-- on atlas-roolku half way through r21910 01.00.53 # again void functions ? :/ 01.01.31 # feel free to add your thoughts to fs#9545 ;-) 01.01.54 # sd_sleep() and sd_spin() should be removed as well 01.02.44 # perhaps "#define sd_sleep()" in storage.h 01.03.06 # or sd.h (more appropriate since it is included by storage.h) 01.03.09 Join stephen_ [0] (n=stephen@86-40-168-77-dynamic.b-ras2.srl.dublin.eircom.net) 01.03.26 # that could work, yes. 01.03.37 # but right now I must sleep :/ 01.04.17 Quit shotofadds ("Leaving") 01.07.44 # obo: you have problems reading thumb code? 01.09.33 # New commit by 03mt (r21911): Remove a call to av_clip() which limits the PCM output of the decoder to 16-bit. 01.16.28 # what is the difference between #defined HAVE_DISK_STORAGE and #if (CONFIG_STORAGE & STORAGE_ATA) ? (semantically) 01.18.05 # the ipod nano has a ATA controller but no disk storage .. 01.18.15 Quit roolku () 01.18.57 Quit Thundercloud (Remote closed the connection) 01.19.04 # the former is only used be the ifp IIRC 01.19.28 # or maybe I'm confusing things 01.19.43 # it has a nand storage 01.20.24 # amiconn: ok... now i can work on this. i assume that since code has to be word-aligned i should only be changing the size of the padding a word at a time? 01.27.48 Quit jfc (Read error: 104 (Connection reset by peer)) 01.28.10 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 01.28.43 Quit jfc (Read error: 54 (Connection reset by peer)) 01.29.04 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 01.29.34 Quit jfc (Read error: 54 (Connection reset by peer)) 01.29.55 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 01.40.48 Quit jfc (Read error: 54 (Connection reset by peer)) 01.40.55 Quit mt (Read error: 113 (No route to host)) 01.41.06 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.41.15 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 01.47.38 Join JdGordon| [0] (n=Miranda@131.107.0.69) 01.49.54 # ok, i went back to the regular arm asm in libtremor, and left the pad where it was in window.c... without the pad the codec is broken, as it was before in long-call-stub builds. a 4, 8, or 12-byte pad fixes it. 16 is broken again, 20 works again... so there's a 1-in 01.51.18 # a 1-in-4 chance of building a broken codec by "accident", and changing out some of the libtremor asm just happens to "fix" it. i'll start moving the pad around now and see if i can determine what exactly is breaking 01.54.16 # it doesn't like we force a greater-than-word alignment at the start of the data section, so it could easily be something there that breaks, as well 02.00.00 Part toffe82 02.00.14 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.04.48 Quit jfc (Read error: 104 (Connection reset by peer)) 02.05.11 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 02.06.04 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 02.09.19 # New commit by 03funman (r21912): Storage API : remove undeeded target-specific functions ... 02.11.52 Quit n17ikh (simmons.freenode.net irc.freenode.net) 02.11.52 NSplit simmons.freenode.net irc.freenode.net 02.11.52 Quit preglow (simmons.freenode.net irc.freenode.net) 02.11.52 Quit JdGordon (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Bagder (simmons.freenode.net irc.freenode.net) 02.11.52 Quit daurn| (simmons.freenode.net irc.freenode.net) 02.11.52 Quit rasher (simmons.freenode.net irc.freenode.net) 02.11.52 Quit jfc (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Sajber^ (simmons.freenode.net irc.freenode.net) 02.11.52 Quit tom243 (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Torne (simmons.freenode.net irc.freenode.net) 02.11.52 Quit saratoga (simmons.freenode.net irc.freenode.net) 02.11.52 Quit J-23 (simmons.freenode.net irc.freenode.net) 02.11.52 Quit rphillips (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Llorean (simmons.freenode.net irc.freenode.net) 02.11.52 Quit cdleonard (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Zarggg_ (simmons.freenode.net irc.freenode.net) 02.11.52 Quit trisiak (simmons.freenode.net irc.freenode.net) 02.11.52 Quit tmzt (simmons.freenode.net irc.freenode.net) 02.11.52 Quit safetydan (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Horscht (simmons.freenode.net irc.freenode.net) 02.11.52 Quit AndyI (simmons.freenode.net irc.freenode.net) 02.11.52 Quit gibbon_ (simmons.freenode.net irc.freenode.net) 02.11.52 Quit FOAD (simmons.freenode.net irc.freenode.net) 02.11.52 Quit dionoea (simmons.freenode.net irc.freenode.net) 02.11.52 Quit avacore^ (simmons.freenode.net irc.freenode.net) 02.11.52 Quit karma (simmons.freenode.net irc.freenode.net) 02.11.52 Quit vedlith (simmons.freenode.net irc.freenode.net) 02.11.52 Quit advcomp2019 (simmons.freenode.net irc.freenode.net) 02.11.52 Quit dz (simmons.freenode.net irc.freenode.net) 02.11.52 Quit krazykit (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Kohlrabi_ (simmons.freenode.net irc.freenode.net) 02.11.52 Quit soap (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Byan (simmons.freenode.net irc.freenode.net) 02.11.52 Quit Hadaka (simmons.freenode.net irc.freenode.net) 02.11.52 Quit rvvs89 (simmons.freenode.net irc.freenode.net) 02.11.52 Quit jordan` (simmons.freenode.net irc.freenode.net) 02.11.52 Quit obo (simmons.freenode.net irc.freenode.net) 02.11.52 Quit lostlogic (simmons.freenode.net irc.freenode.net) 02.11.52 Quit dys (simmons.freenode.net irc.freenode.net) 02.11.52 Quit fred_2 (simmons.freenode.net irc.freenode.net) 02.11.52 Quit r00s (simmons.freenode.net irc.freenode.net) 02.11.53 Quit jon-kha (simmons.freenode.net irc.freenode.net) 02.11.53 Quit Slasheri (simmons.freenode.net irc.freenode.net) 02.11.53 Quit rwong (simmons.freenode.net irc.freenode.net) 02.11.53 Quit parafin (simmons.freenode.net irc.freenode.net) 02.11.53 Quit bubsy (simmons.freenode.net irc.freenode.net) 02.11.53 Quit Erant (simmons.freenode.net irc.freenode.net) 02.13.45 NHeal simmons.freenode.net irc.freenode.net 02.13.45 NJoin jfc [0] (n=john@dpc6682208002.direcpc.com) 02.13.45 NJoin safetydan [0] (n=deverton@rockbox/developer/safetydan) 02.13.45 NJoin Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 02.13.45 NJoin tom243 [0] (i=chris243@c-24-118-138-250.hsd1.mn.comcast.net) 02.13.45 NJoin Horscht [0] (n=Horscht2@xbmc/user/horscht) 02.13.45 NJoin n17ikh [0] (n=n17ikh@c-68-59-19-150.hsd1.sc.comcast.net) 02.13.45 NJoin rasher [50] (n=rasher@rockbox/developer/rasher) 02.13.45 NJoin preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 02.13.45 NJoin JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 02.13.45 NJoin daurn| [0] (n=daurnima@ppp118-208-169-5.lns10.mel4.internode.on.net) 02.13.45 NJoin Bagder [241] (n=daniel@rockbox/developer/bagder) 02.13.45 NJoin Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 02.13.45 NJoin J-23 [0] (n=zelazko@unix.net.pl) 02.13.45 NJoin AndyI [0] (i=AndyI@212.14.205.32) 02.13.45 NJoin cdleonard [0] (n=cdleonar@86.121.203.175) 02.13.45 NJoin gibbon_ [0] (i=gibbon_@could.become.a.servant4you.org) 02.13.45 NJoin rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) 02.13.45 NJoin dys [0] (n=andreas@krlh-5f736ea8.pool.einsundeins.de) 02.13.45 NJoin FOAD [0] (n=dok@dinah.blub.net) 02.13.45 NJoin saratoga [0] (i=9803c6dd@gateway/web/freenode/x-9b73980ae5d89280) 02.13.45 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 02.13.45 NJoin avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 02.13.45 NJoin Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 02.13.45 NJoin dionoea [0] (n=dionoea@yop.chewa.net) 02.13.45 Join bubsy [0] (i=Bubsy@unaffiliated/bubsy) 02.13.45 Join obo [0] (n=obo@rockbox/developer/obo) 02.13.45 NJoin karma [0] (i=amg@host193-123-47-78-dhcp.bshellz.net) 02.13.45 NJoin vedlith [0] (n=ved2@137-mi2-1.acn.waw.pl) 02.13.45 NJoin advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 02.13.45 NJoin dz [0] (n=dz@alt.dissonance.nl) 02.13.45 NJoin krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 02.13.45 NJoin tmzt [0] (n=tmzt@adsl-99-164-52-98.dsl.akrnoh.sbcglobal.net) 02.13.45 NJoin trisiak [0] (n=tree@chello089078243195.chello.pl) 02.13.45 NJoin Kohlrabi_ [0] (n=Kohlrabi@frustrum.nosebud.de) 02.13.45 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 02.13.45 NJoin soap [50] (n=soap@rockbox/staff/soap) 02.13.45 NJoin Byan [0] (n=notByan@logo.csl.mtu.edu) 02.13.45 NJoin jordan` [0] (i=gromit@78.235.252.137) 02.13.45 NJoin rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 02.13.45 NJoin Hadaka [0] (n=naked@kiiro.naked.iki.fi) 02.13.45 NJoin parafin [0] (i=parafin@paraf.in) 02.13.45 NJoin fred_2 [0] (i=fred@hpc-cluster.hamburgnet.de) 02.13.45 NJoin Erant [0] (i=erant@plz.stfu.kthnx.org) 02.13.45 NJoin lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 02.13.45 NJoin r00s [0] (n=ru@zentrale.profitables.biz) 02.13.45 NJoin rwong [0] (n=ricky@www.roflwaffle.com) 02.13.45 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 02.13.45 # lostlogic: hi 02.13.45 # i wonder if you want to work on sound for yh920 when you don't own the target 02.15.09 Join JdGordon_ [0] (i=ae914296@gateway/web/freenode/x-1ac3b52e465f9ae4) 02.16.57 # *bizarre* - the next section linked forces 16-byte alignment in at the section start and end. so it pretty much has to be something in in .data that can break the codec if it lands on the wrong alignment... and the only thing in the vorbis codec's .data is ci. 02.20.03 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 02.20.13 # funman: I find the 32 bit code easier to read - i.e. immediate values > 8bit, registers defined for each function rather than being passed from one to the next. 02.20.32 # how many codecs have subtrack/cuesheet support built in? 02.20.38 # is it just ogg/flac? 02.20.42 # and .cue obviously 02.20.46 # obo: what do you mean by registers passed between functions ? 02.20.57 # obo: technically immediate values in arm ore still only 8-bit... you just have the option of rotating them 02.21.11 # JdGordon_: i don't know but recently i listened to a .ape with its .cue, i suppose cuesheet support isn't codec dependant since it has to be enabled ? 02.21.56 # is there a list of the steering board on rockbox.org ? 02.21.57 # i dont mean rockboxwise... I know flac has inbuilt cuesheet support (we dont support it yet), and ogg has subtracks... 02.22.11 # RockboxSteeringBoard 02.22.18 # mp4 has chapters, but i don't know if it's used in audio 02.24.44 # JdGordon: ogg subtracks will be quite tricky to support in any meaningful manner, if you mean ogg chaining 02.24.59 # I'm trying to decide what to do with cuesheet handling... possibly making it always enabled and still use the audio buffer for the listing instead of a static buffer 02.25.01 # * linuxstb slaps JdGordon_ for even thinking about chained oggs 02.25.03 # Unhelpful: So if everything after .data is cache line aligned, and the breakage is 1-in-4 in a cache line, the problem must be either in .text, .rodata or .data 02.25.25 # there's no global table of tracks and offsets, just 02.25.37 # funman: in the bootloader it tended to define a hardware register in one function, and then pass it onto other functions as a paramater, adding, subtracting and shifting as it went. In the firmware it tends to doesn't seem to do that. 02.25.40 # that sounds pretty stupid :p 02.27.16 # AA does conversion and resize on load right? would doing the same with .cue files be bad? 02.28.09 # amiconn: i'm less sure now... i put the pad in the linker script so that i could poke around for the section that has broken alignment, and that's how i found that the alignement fix worked in .data - which appears to be after .text and .rodata. 02.28.26 # * JdGordon_ is referring to 9789 for the interested... 02.28.54 # the next section *defined* is ncdata, which is unused and forces cache alignment, then iram, which of course can't have its alignment changed by non-iram padding. 02.30.43 Quit tom243 () 02.34.31 # IRAM doubles as part of .bss after init 02.35.08 # amiconn: right... but the stuff that belongs in iram is moved there, and .bss is cleared. 02.35.47 # Yes, but in either process there might be an error, although this is unlikely since the start of these sections is cacheline aligned 02.35.48 # anyway, moving the pad to the end of .data fixes the codec as well - so apparently the alignment problem is triggered by something in .bss? 02.38.28 # .bss is cacheline aligned? 02.39.24 # It is due to the preceding .ncdata section 02.40.44 # so how can padding the end of .data fix this, then? 02.41.10 # It can't - something else must be changing :\ 02.42.59 # perhaps i'm doing it wrong... but all i did was add the . += 0x4 in this: http://pastie.org/548902 02.44.47 Quit jfc (Read error: 54 (Connection reset by peer)) 02.44.55 Join AJzer [0] (n=6171b58d@gateway/web/cgi-irc/labb.contactor.se/x-79b0e921365b6503) 02.45.08 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 02.45.52 # weird 02.46.14 # Did you compared the .map files for padding of 0/8/8/12 bytes? 02.46.18 # *compare 02.46.28 Quit jfc (Read error: 54 (Connection reset by peer)) 02.46.49 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 02.47.20 Quit jfc (Read error: 54 (Connection reset by peer)) 02.47.20 # So if rbutilqt autodetects ann Unsupported apple player variant, was I bilked? 02.47.41 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 02.48.25 # jfc: if you are going to have connection issues again, please leave this chan untill you sort it all out 02.48.44 # There's no symbol that would be influenced by this... almost looks like a linker bug (??) 02.49.47 Quit jfc (Read error: 54 (Connection reset by peer)) 02.50.09 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 02.50.34 # AJzer: i'm not sure what "bilked" means, but if rbutilqt says it's unsupported, it's unsupported by rockbox 02.50.55 # It means I asked the sales guy if it was 5th gen, and he said yes. And it seems it was not. 02.51.51 # I just want to be sure there's no room for error on the part of Rockbox 02.52.41 Nick n00b81 is now known as taylor_ (n=n00b81@unaffiliated/n00b81) 02.52.42 # amiconn: that'd be a shame... perhaps i should attempt to reproduce with our standard toolchain? if it's not a problem with the linker itself, i should be able to find a "bad" alignment in <= 4 tries 02.53.08 # funman: "cheated" 02.53.18 # I'd like to see the .map files for the 4 cases, together with the info which of the 4 worked 02.53.55 # amiconn: not a problem... i'll throw them on pastebin :) 02.54.07 # AJzer: unlikely, but you can check http://support.apple.com/kb/HT1353 02.54.37 # i've only actually run two of these, though... the determination that there was only one broken alignment in four was made when the padding was still in window.c 02.55.02 # Yeah, it's vague enough to not clarify anything. But thanks for your help. 02.55.16 Quit webmind (Read error: 60 (Operation timed out)) 02.56.05 # AJzer: That link shouldn't be vague at all 02.57.07 # amiconn: 0 padding: http://pastie.org/548910 4: http://pastie.org/548911 8: http://pastie.org/548912 12: http://pastie.org/548913 02.58.55 *** Saving seen data "./dancer.seen" 02.58.56 # the 0 padding should be identical to bulding with this toolchain with an unmodified mapfile, and is the case that was broken originally. files skip immediately without any error splash, so they may be quitting due to some error or the codec thinks its reached end-of-track prematurely. 02.58.58 Join stettberger_ [0] (n=stettber@peer.zerties.org) 02.59.32 Join karma_ [0] (i=amg@host193-123-47-78-dhcp.bshellz.net) 03.00.45 # evilnick_home: There is no visible way to tell the difference between an Ipod Classic 80GB (6th gen), and the Ipod Video 80GB (5.5 gen). That is what I mean by vague. 03.02.04 Join toffe82 [0] (n=chatzill@ppp-71-140-90-107.dsl.frs2ca.pacbell.net) 03.02.13 # isn't the case different ? (polished for classic) 03.02.51 # Unhelpful: It is a linker bug.... Compare the .iram load address in the broken case with that of the other 3 03.03.05 Quit stettberger (Read error: 104 (Connection reset by peer)) 03.03.11 # ...and with a build produced by our standard toolchain 03.03.13 # I thought that the Classics all had metallic fronts 03.03.31 # if I have a classic, it's got a black matte front. 03.03.33 # AJzer: That page says "You can distinguish the iPod classic from the iPod (5th generation) by the last three digits of the serial number. The iPod classic serial number's last three digits will be one of the following: Y5N, YMU, YMV, and YMX." 03.03.43 # amiconn: it's not aligned! 03.04.08 Join webmind [0] (n=webmind@shell.puscii.nl) 03.04.17 # In the 0-pad case it *should* be 0x01e96f20, because that's what 'iramcopy' is set to (in the preceding section, due to alignment 03.04.23 # they arnt digits! 03.04.46 # linuxstb: thanks. I've read through that damn page numerous times and missed this. 03.04.47 # But somehow the linker manages to ignore the alignment 03.05.03 # The wonders of using dev snapshots :\ 03.05.15 # AJzer: But rbutil won't lie about that either... 03.06.05 # amiconn: blast... the call stubs aren't generated in any released binutils, though. :/ 03.06.28 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.06.38 # * amiconn wonders what the linker will do when padding by 16 bytes 03.07.44 Quit karma (Connection reset by peer) 03.08.12 # It is in fact interesting that the code didn't crash. The .icode functions all end up shifted in iram 03.08.14 # when the padding was in window.c, 16 came back around to being broken. 03.08.35 # linuxstb: software can be particular, and imperfect. I felt it was worth checking before going through the process of returns. 03.08.48 # Yeah, but what about .data? This seems to be a bug in section handling 03.09.08 Quit JdGordon_ (Ping timeout: 180 seconds) 03.11.30 # i'm trying it now... 03.14.31 Quit AJzer ("CGI:IRC") 03.15.40 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 03.16.32 # the address moves to the next aligned value (0x01e96f30) at pad = 12. bumping the padding to 16 changes it to 0x01e96f28 03.16.35 # Hi guys any deve;p[ment on the MicroSD cpu boost sisue I have seen the post on the forums. Does that still need testing? 03.16.47 Quit jfc (Read error: 104 (Connection reset by peer)) 03.17.08 # SansaAMS related 03.17.09 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.17.42 Quit jfc (Read error: 104 (Connection reset by peer)) 03.18.03 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.18.17 # i guess i'd better 1) see if a fresh snapshot has fixed this then 2) find out what the binutils folks want for a bug report 03.18.34 Quit jfc (Read error: 104 (Connection reset by peer)) 03.18.34 # notlistening: ping flyndice 03.18.55 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.19.46 Quit jfc (Read error: 104 (Connection reset by peer)) 03.20.06 # funman, now i am being an irc idiot how do i ping? 03.20.07 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.20.12 # it being fixed in a newer snapshot isn't exactly a giant help for us, though... the snapshots are numbered, but it looks like they just use one number for a while, and then change it. i believe this because the timestamp on their 2.19.51 snapshot is *days* later than when i built it. :/ 03.20.23 Quit DataGhost (Read error: 110 (Connection timed out)) 03.20.38 Quit jfc (Read error: 104 (Connection reset by peer)) 03.20.59 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.21.17 # notlistening: in all likelihood he will notice that his name has been said... most clients will highlight the channel if your nick is used, and i usually search the logs for my nick if i've been gone a bit, and most other devs probably do as well 03.21.30 Quit jfc (Read error: 104 (Connection reset by peer)) 03.21.51 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.22.06 # It's clearly a bug in that 'iramcopy' is calculated as 0x01e96f20, and section .iram says 'AT ( iramcopy)', yet the linker uses a slightly different load address 03.22.22 Quit jfc (Read error: 104 (Connection reset by peer)) 03.22.43 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.23.06 Mode "#rockbox +o JdGordon " by ChanServ (ChanServ@services.) 03.23.14 Quit jfc (Read error: 104 (Connection reset by peer)) 03.23.16 # notlistening: just someting like "flyndice: ping" (when he'll be here, but i hope he reads the logs) 03.23.18 # the previous snapshot is from november, and there are naturally quite a few daily and weekly diffs since then. 03.23.35 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 03.23.47 Mode "#rockbox +b *!john@dpc6682208002.direcpc.com " by JdGordon (n=jonno@rockbox/developer/JdGordon) 03.24.48 # or "flyndice: ", or "see my prior report" or such if you've just said what the problem was. it irritates me a little bit when i come back and there's an "unhelpful: PING" and i can't find anything about what somebody thought i'd need to know about. 03.25.39 Mode "#rockbox -o JdGordon " by ChanServ (ChanServ@services.) 03.26.58 # thanks for the tip Unhelpful 03.34.09 Mode "#rockbox +o JdGordon " by ChanServ (ChanServ@services.) 03.34.15 Mode "#rockbox -b *!john@dpc6682208002.direcpc.com " by JdGordon (n=jonno@rockbox/developer/JdGordon) 03.34.17 Mode "#rockbox -o JdGordon " by ChanServ (ChanServ@services.) 03.35.29 Quit Sajber^ (Read error: 54 (Connection reset by peer)) 03.37.48 Quit notlistening ("Leaving") 03.38.59 Join Lss__ [0] (n=Lss@cm40.delta91.maxonline.com.sg) 03.39.31 Quit Riku (Read error: 54 (Connection reset by peer)) 03.40.54 # 2009-07-16 20:14:37 Server refused connection: error duplicate name! 03.40.54 # Address the above issue(s), then restart! 03.41.12 # EST - FWIW. Is this a known issue with the new build client or is there something I am doing wrong? 03.41.30 # you're probably using a -name that is already used? 03.41.50 # maybe an old connection that didn't time out yet 03.45.05 Quit funman ("free(random());") 03.46.26 # amiconn: i would think if we find some non-release binutils revision that makes this work we'd need to add support to rockboxdev.sh for checking out that revision, in order to use these features... since the snapshot version numbers don't appear to represent a specific revision. 03.48.30 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 04.05.31 Quit Xerion (Read error: 110 (Connection timed out)) 04.05.31 Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 04.07.01 Quit TheSeven (Nick collision from services.) 04.07.17 Join The_Seven [0] (n=theseven@dslb-084-056-176-104.pools.arcor-ip.net) 04.07.21 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-176-104.pools.arcor-ip.net) 04.18.39 Join dys` [0] (n=andreas@krlh-5f7069bf.pool.einsundeins.de) 04.30.59 Quit dys (Connection timed out) 04.36.52 Quit efyx_ (Remote closed the connection) 04.38.46 Quit martian67 (Read error: 60 (Operation timed out)) 04.38.58 Quit taylor_ ("Leaving") 04.41.33 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 04.51.53 Nick karma_ is now known as karma (i=amg@host193-123-47-78-dhcp.bshellz.net) 04.55.29 # amiconn: hrm... that binutils snapshot works correctly without the -meabi=4 hack. i wonder if the problem exists when it's linking eabi objects build with a proper eabi toolchain? i don't see how that case would differ, unless gcc inserts some attributes that change things... 04.56.23 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 04.57.07 Quit martian67_ (SendQ exceeded) 04.59.00 *** Saving seen data "./dancer.seen" 05.02.57 Quit KBH (Read error: 104 (Connection reset by peer)) 05.03.10 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 05.03.55 Quit martian67 (Success) 05.06.32 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 05.14.30 Join _lifeless [0] (n=lifeless@188.16.87.95) 05.31.34 Join __lifeless [0] (n=lifeless@188.16.87.95) 05.34.35 Join dash32 [0] (n=dash32@84.171.84.70) 05.36.23 Quit patmulchrone (Remote closed the connection) 05.38.26 Quit cdleonard (Read error: 110 (Connection timed out)) 05.40.46 Quit Horscht ("Verlassend") 05.44.04 # New commit by 03kkurbjun (r21913): M:Robe 500: Start of interrupt support. 05.48.32 Quit _lifeless (Read error: 113 (No route to host)) 05.49.32 # bah! yes, this binutils has this problem with a proper eabi gcc, also. i wonder what the problem really is, though? it seems just bizarre that it would correctly calculate the value of iramcopy, but then use an incorrect address when something else refers to that address. 05.59.53 Join RandAl [0] (n=chatzill@76.235.56.133) 06.00.04 Nick RandAl is now known as Rand_Althor (n=chatzill@76.235.56.133) 06.00.11 # Off-topic question: Anyone ever re-soldered the headphone jack on a c200? 06.00.59 Nick adi|away is now known as aditya (n=aditya@59.95.5.10) 06.14.35 Quit dash32 (Remote closed the connection) 06.18.16 Join goffa [0] (n=goffa@216.220.23.105) 06.19.12 Join dash32 [0] (n=dash32@84.171.84.70) 06.22.56 Quit dash32 (Remote closed the connection) 06.23.07 Quit Rand_Althor ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 06.29.37 # New commit by 03kkurbjun (r21914): M:Robe 500: Fix simulator build and include some small changes for the 640x480 setup. 06.52.26 Join cdleonard [0] (n=cdleonar@86.121.201.241) 06.59.02 *** Saving seen data "./dancer.seen" 07.00.13 Join courtc_ [0] (n=court@unaffiliated/courtc) 07.02.26 Quit courtc (Read error: 111 (Connection refused)) 07.08.12 # New commit by 03kkurbjun (r21915): Jewels: Simplify support for new target screen sizes. Just adding new bitmaps for the target should now be enough. 07.10.21 # hello! 07.10.44 # I'm trying to look at the iAudio7 port but it fails to compile with 'unsupported instruction on ldrd' 07.11.03 # is that *exactly* what it says? "on ldrd"? 07.12.30 # no; not exactly. I'll give you the exact message 07.15.27 # /home/cdleonard/files/work/rockbox/trunk/apps/recorder/jpeg_idct_arm.S:197: Error: selected processor does not support `ldrd r4,.Lpool4' 07.15.38 # and more like that 07.16.06 Quit CaptainKwel (Remote closed the connection) 07.17.03 # that's interesting. the iaudio7 should, to my knowledge, support that instruction... 07.17.09 # here are the full messages: http://pastebin.com/mb53ee3f 07.17.57 # it seems iAudio7 sets -mcpu=arm9. Maybe that's a bit too general? 07.19.16 # the architecture numbers seem very confusing 07.20.09 # it sets -mcpu=arm9e; sorry 07.23.02 # to the best of my knowledge arm9e CPUs should support that instruction. you might try setting it to the more-specific arm946e-s, which i *think* is the core in the iaudio7's SoC. i had a similar problem when working on our development toolchain, with it failing to build libgcc for -mcpu=arm9e because the assembler claimed that ldrd was not a supported instruction. 07.26.13 # this page says so http://www.rockbox.org/twiki/bin/view/Main/CowonIaudio7Info 07.27.43 # but now arm-elf-as fails with 'unknown cpu `arm946e-s'' 07.29.04 # and if I set it to just 'arm946e' (also listed as a supported cpu in the manual) I get errors in SOURCES files 07.29.48 # like this: http://pastebin.com/ma3940cc 07.30.08 # I don't get it; why would an error be printed for one of those files? 07.32.08 # those files are still run through GCC to use its preprocessor. and arm946e is not listed as a valid -mcpu option here, while arm946e-s is 07.33.32 # ah! i see the issue... gcc knows "arm946e-s", but not "arm946e"... and for the assembler it's the other way around. 07.33.41 # but as doesn't recognize arm946e-s; but it does recognize arm946e 07.33.45 # yes 07.34.07 # something about this patch: http://www.rockbox.org/gcc/rockbox-multilibs-arm-elf-gcc-4.0.3.diff ? 07.36.01 # no, that patch is not in any way your problem, it only specifies the flags used to build libgcc. the reason that the accepted CPUs don't match between as and gcc is likely due to differences between gcc and binutils versions... perhaps a newer binutils would help? i can't promise that will *work* though ;) 07.40.00 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.41.35 Nick stettberger_ is now known as stettberger (n=stettber@peer.zerties.org) 07.42.41 # are you sure I need different versions? that patch seems to list mcpu options 07.42.56 # (i have no idea what multilibs are about) 07.44.02 Part toffe82 07.44.04 # i am sure that as from binutils-2.16 doesn't support the same cpu options with the same names as gcc-4.0.3. 07.44.12 # the patch is really not your problem. 07.49.09 # but this version mismatch has been there for quite a while; right? 07.51.36 # right, but we don't normally build with -mcpu=arm946e-s anywhere. we use -mcpu=arm9e, which works fine, apparently, unless you try to use certain instructions - the file where you're having the problem is relatively new, and it's quite possible nobody's tried to build for iaudo7 since it was introduced. 07.58.08 # http://sourceware.org/binutils/docs-2.16/as/ARM-Options.html#ARM-Options 07.58.12 # http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/ARM-Options.html#ARM-Options 07.58.19 Quit amiconn (Nick collision from services.) 07.58.20 # it seems the mismatch is real 07.58.22 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 07.58.40 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 07.59.00 Quit pixelma (Nick collision from services.) 07.59.00 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 07.59.18 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 07.59.29 # binutils-2.17 support arm946e-s 08.01.28 # yes; and it seems less risky than upgrading gcc 08.02.45 # i would suspect you'd actually need to *downgrade* gcc, since it seems to be *newer* versions of binutils that support arm946e-s 08.04.39 Quit amiconn (Nick collision from services.) 08.04.42 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 08.04.44 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 08.04.44 Quit pixelma (Nick collision from services.) 08.05.00 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 08.05.02 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 08.05.40 Quit J-23 (Read error: 113 (No route to host)) 08.11.55 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 08.11.55 Quit pixelma (Nick collision from services.) 08.11.56 Quit amiconn (Nick collision from services.) 08.11.59 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 08.12.11 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 08.12.17 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 08.24.19 Join stoffel [0] (n=quassel@p57B4DA3B.dip.t-dialin.net) 08.28.13 # Unhelpful: Such is the nature of bugs - things don't work as expected... Did you try a fresh snapshot already? 08.28.50 # If we have a known-good non-release binutils, we could just tarball it and host it ourselves 08.30.26 Join Harryy [0] (n=Harry@botters/harryy) 08.30.56 # How is Rockbox for Zune going? I read around in 2006 that it was very possible, did not see anything else after that point. 08.31.17 Quit safetydan ("Leaving.") 08.32.26 # amiconn: i tried a fresh snapshot, no luck. we could also conceivably patch in the needed bits (about the new relocation types and stub generation) to a released binutils 08.33.00 # Somehow I thought that the latest release would already support it... 08.33.27 # * amiconn wonders how fast the binutils people are at fixing reported bugs 08.33.28 # any idea about this -mcpu=arm9e issue? i can't find anything *besides* binutils that says it doesn't support the ldrd instruction. 08.34.02 # i don't know... i've been trying to come up with a synthetic test case for the bug without any luck. :/ 08.34.24 # Imo we should update the required binutils for arm, and then use arm946e-s 08.35.14 # Harryy: actually it's not looking so good 08.35.18 # even the newest does this with -mcpu=arm9e - i had the same thing happen while building libgcc 08.35.56 # Harryy: Internally it's very similar to the Gigabeat S, but the exploit to run our code has been fixed in the Zune. 08.37.32 # ok; I tried to build with binutils 2.17 but it fails to link; something about FPA instructions 08.38.22 # http://pastebin.com/m7f478d97 08.38.34 # i have what certainly seem to be the same elements that trigger it in our case - a low and high segment of memory, a section with a target address different from its load address, which is calculated in the same fashion... but nothing goes wrong. :/ 08.38.58 # this is with -mcpu=arm946e-s 08.39.08 # markun: could someone not hard-flash it? why does it get insta-protected by M$? 08.39.32 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 08.39.32 Quit pixelma (Nick collision from services.) 08.39.32 Quit amiconn (Nick collision from services.) 08.39.33 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 08.39.47 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 08.39.51 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 08.40.09 # Unhelpful: Yes, since arm9e obviously doesn't support that instruction, but the jpeg decoder asm stuff uses it for armv5 08.40.14 # But since our arm9e is actually an arm946e-s which supports it, going for the latter option would be a good thing 08.42.06 # amiconn: it doesn't? the quick reference sheet notes the instruction as supported on armv5e processors, and the infocenter docs for arm9e-s include it as well - i can't find anything there for just "arm9e" 08.42.08 # markun: do you think Zune will work in the near future? Or if I should rip apart my zune and use it as a HDD? right now it is laying around as I never use Linux 08.43.18 # Harryy: i don't think there's been any real progress in quite some time 08.43.19 # I meant never use Winblows 08.43.54 # Unhelpful: bah. So I should call Microfail and tell them to port it to Linux? :3 08.44.00 # "or else!"? 08.44.24 # good luck. 08.44.54 # they never said it would work with linux, or that you could run your own code on it. 08.45.13 # hrm :| 08.45.19 Join Rob2223 [0] (n=Miranda@79.220.200.191) 08.45.21 # it doesn't even work under Wine 08.45.24 # money hunry pigs 08.46.27 # wine doesn't support USB devices at all, does it? other than using platform drivers for things like mass storage? 08.46.32 # I dunno 08.46.40 # the Zune.exe will not even install 08.46.55 # won't even launch the install GUI :\ 08.47.37 # so, what do you suggest? I break my zune and use it as an external HDD? 08.48.00 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.48.27 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.51.16 # Unhelpful: I think the 'arm9e' option is meant to produce generic code which should run on all arm9xx. Iirc someone said that some eearly arm9 revisions don't suppor ldrd/strd 08.51.25 # any thoughts about my link issue? 08.51.45 # maybe I need to build libgcc differently? 08.56.47 Part Harryy 08.58.09 # did you build your gcc and binutils together? i would recommend you use the rockboxdev.sh script and change the binutils version there. you may also want to edit the patch and replace the arm9e with arm946e-s, so that you'll have a processor-specific libgcc as well 08.59.04 *** Saving seen data "./dancer.seen" 08.59.14 # edit the multilib patch? 08.59.24 # yes. 08.59.51 # if you just edit the downloaded copy in-place, the script should use it without downloading it again. 09.00.06 # have we got any way to lock the audio buffer so calls to bufgetdata() are guarenteed safe? or are they fine as long as there is no thread switching during the call? 09.01.14 # ok; I'll try that 09.02.25 Join petur [50] (n=petur@rockbox/developer/petur) 09.03.02 Quit stephen_ ("Leaving") 09.03.11 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.03.14 # http://www.overclockers.com.au/image.php?pic=images/newspics/17jul9/12.jpg 09.03.20 # got all you beer lovers 09.04.03 # * petur is more a Murphy's fan 09.05.03 # * petur wonders what happened to the buildclient on his NAS after midnight 09.06.31 # Unhelpful: Check infocenter.arm.com. The ARM946E-S r0 is an ARMv5TExP which lacks ldrd/strd, the ARM946E-S r1p1 is a full ARMv5TE and supports ldrd/strd 09.06.45 # Weird - we'd have to distinguish revisions... 09.08.01 # ah... that's horrid. the quickref sheet simply reads "ARM v5E, and 6 and above" :/ 09.08.59 # i had actually wondered about the "5E" business, though - we don't have any way to distinguish it from "5", but most of the interesting ARMv5 instructions are 5E-only 09.09.06 # Same applies to ARM966E-S revions, btw 09.09.58 # The ARM reference manual states "Version 5TE and above, excluding ARMv5TExP" for ldrd/strd 09.12.40 # ew. perhaps we need to define an ARM_FEATURES or such... do we actually have any ARM9 targets *without* ldrd and friends? 09.13.07 # I don't know - I don't have *any* arm9 target, only arm7 and arm11 09.13.40 # it's the same here, only a beast and e200 :/ 09.13.47 # Since the SoC manufacturers probably won't tell what revision of the arm core is used, this will probably need on-target testing 09.14.24 # it seems like that would be important to know if you're to generate code for it :/ 09.15.14 # We do have arm9 targets without ldrd/strd, but those I know are clearly distinguishable since they're armv5, not armv5 (Gigabeat F/X is ARM920T) 09.15.39 # err I mean armv4, not armv5 09.16.28 # ARM architecture versions vs. arm versions is messy like that. Even revisions are important :\ 09.18.07 Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 09.19.23 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 09.23.21 # it compiled! I still got errors in apps/plugins/flipit and brickmania; but I also got a rockbox.zip 09.23.36 # I guess the plugin errors are normal for platforms that are not fully supported? 09.24.48 # plugins often need adaptations to new platforms - they may select a bitmap based on display size, and not find the right one at all, for example. 09.25.31 Nick courtc_ is now known as courtc (n=court@unaffiliated/courtc) 09.25.56 # ugh... trying to bisect binutils history for the link bug is going to be a nightmre. they still use cvs! 09.26.19 Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 09.29.12 Quit KBH (Read error: 60 (Operation timed out)) 09.30.59 Join mt [0] (n=mt@rockbox/developer/mt) 09.31.47 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.34.11 Quit HBK (Read error: 110 (Connection timed out)) 09.34.34 # Unhelpful: We could play safe and not use ldrd/strd on all armv5 09.37.13 # amiconn: yes, but i don't think that all support smulxy and friends, either 09.37.22 # They do 09.37.34 # Check the reference manual 09.38.46 # It's ldrd, strd, mcrr, mrrc and pld which aren't supported in the v5TExP variant 09.41.11 # we could have a flag of some sort for that variant. ldrd is a fair saving vs two ldr, isn't it? 09.42.22 Quit bertrik (Read error: 113 (No route to host)) 09.43.36 # any ideas how best to report this binutils problem? they have a bugzilla, but i don't as yet have a test case that doesn't involve all of rockbox :/ 09.44.42 # On armv5, ldrd just saves an instruction, it doesn't save cycles (ldr is 1-cycle w/o interlocks, ldrd is 2 cycles w/o interlocks) 09.45.20 # ah... so it's only of benefit to code size on armv5 09.45.25 # On armv6 this is no longer true, but that's not a problem 09.46.06 # Yeah. Code size *might* have a slight effect on speed though, because of the cache 09.46.50 Quit MrDuck (Read error: 113 (No route to host)) 09.46.54 # it's going to be quite a small difference, compared to the difference it makes on armv6 09.48.00 # am i reading wrong, or does armv6 have an interlock on a shifted input register, where early versions do not? 09.48.47 Quit Thundercloud (Remote closed the connection) 09.49.13 # armv6 does much more pipelining (even ldm/stm are single cycle), hence there are more interlocks 09.50.09 # Variable shift input means an extra cycle on armv5 and earlier. Not so on armv6, there it means having an "early reg" 09.53.20 # the shifted register seems to be an "early reg" on armv6 even if it's shift-by-immediate 09.53.54 # per the example interlocks section for arm1136jf-s 09.56.11 Join robin0800 [0] (n=robin080@81.98.157.181) 09.56.24 Join KBH [0] (n=hbk@71.96.74.73) 09.58.22 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 10.14.19 Quit HBK- (Read error: 110 (Connection timed out)) 10.14.44 Quit KBH (Read error: 110 (Connection timed out)) 10.21.23 Join icefest [0] (n=chatzill@d58-110-115-114.meb3.vic.optusnet.com.au) 10.21.29 # Hello 10.21.42 # ceebs 10.21.45 Quit icefest (Client Quit) 10.30.50 Quit BHSPitMonkey (Remote closed the connection) 10.35.18 # Unhelpful: Seems we have only two places in rockbox which try to use ldrd/strd on armv5 - the libdemac predictor and the jpeg idct 10.35.38 # The former is an easy fix - I'd just have to change a preprocessor conditional 10.36.01 # Do you think this should be the way to go? 10.36.22 # (actually two preprocessor conditionals - one for ldrd and one for strd) 10.39.38 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 10.42.04 Quit __lifeless (Read error: 110 (Connection timed out)) 10.44.16 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 10.45.04 Quit m67_l3 (SendQ exceeded) 10.45.17 # I managed to upload stuff to my iAudio7 with tcctool but nothing shows up (only the buttons light up) 10.45.54 # the wiki says the lcd should work 10.45.56 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 10.46.18 # What "stuff" did you upload? I think only one person has ever worked on the iAudio7 port, and he doesn't seem to be around any more... 10.46.50 # I first uploaded rockbox.bin directly 10.47.15 # then I used tools/scramble -tcc=crc and uploaded the result 10.47.17 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 10.47.22 # nothing happened both times 10.47.51 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 10.48.21 # You could try a bootloader build, and upload that. 10.48.38 # from what I understand using tcctool loads a binary into RAM which is lost on a device reboot 10.48.46 # Yes 10.49.02 # so it's perfectly safe. 10.49.06 # * linuxstb wrote tcctool 10.50.27 # I don't understand what the bootloader does; how is it different from a normal build? The normal build is what you're supposed to use on a perfectly supported device, right? 10.51.50 # http://forums.rockbox.org/index.php?topic=15360.0 vitja mentioned replacing stuff in the original firmware 10.51.56 # A bootloader build is simpler, and is designed to load rockbox from the main firmware partition. In a new port, the bootloader is normally developed work, so it more likely to be working. 10.52.30 # maybe that's the only way the lcd works? 10.53.00 # "In a new port, the bootloader is normally developed work, so it more likely to be working." what? 10.53.19 # s/work/first/ 10.53.27 # try the bootloader first. I'm not sure if the main binary is always linked at the right addresses to work with tcctool 10.53.28 # ah 10.53.46 Quit martian67_ (Success) 10.56.20 # ok; and the bootloader can also be uploaded using tcctool? 10.57.43 # It should be able to, yes. Unless it's being built to be appended to the original firmware and flashed. 10.58.23 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 10.59.08 *** Saving seen data "./dancer.seen" 11.01.34 # amiconn: the latter isn't hard, either, really... but there may be a few parts where ldrd is used in shared armv5/armv6 code, and those might need checks against ARM_ARCH added 11.01.54 # These are the only two places 11.02.26 # so I can either use {scramble -tcc=crc and tcctool} or {mktccboot and flashing} 11.02.40 # There is only one more file that uses ldrd/strd at all, and that is the armv6 idct for libmpeg2. But as said, that is used for armv6 only 11.02.49 # grep told me... 11.04.15 # grep is such a helpful friend to have :D 11.07.04 # cdleonard: I've just built an iaudio7 bootloader, and it looks like it's being built to be used with mktccboot. You need to remove the line "#define TCCBOOT" from firmware/config-iaudio7.h in order to build a standalone file you can test with tcctool 11.07.49 Join MrDuck [0] (n=kachna@r3g248.net.upc.cz) 11.08.27 # wait; can't I upload a mktccboot image with tcctool? 11.09.31 # Yes, you can probably do that as well. 11.09.48 Part karma 11.13.53 # amiconn: they're in one file, but the bulk of each idct function for sizes 4 and up is split for armv4, armv5, and armv6. should i go ahead and commit? 11.17.59 # New commit by 03amiconn (r21916): Don't use ldrd/strd on ARMv5 since not all revisions support them and the gain from using them is minimal (basically code size only). 11.21.01 # New commit by 03unhelpful (r21917): Remove ldrd from ARMv5 JPEG IDCT, remove old debug code selecting ARMv5 code for one function even when building for ARMv6. 11.24.40 # yes; mktccboot and then tcctool worked 11.25.11 # I get the OF if hold is off and otherwise a white screen 11.25.15 # yay! 11.25.53 Join _lifeless [0] (n=lifeless@188.16.69.242) 11.27.19 # cdleonard: we *said* unsupported! ;) 11.27.53 # cdleonard: if you unpack the rockbox.zip you got earlier on the device, and you then run the bootloader with tcctool, *and* you're lucky, you may end up with rockbox running! 11.29.19 # you mean the bootloader tries to load rockbox from the flash drive? 11.30.28 # I thought it was just a smaller build with no plugins 11.31.16 # no, that is not what the bootloader is. :) 11.32.04 # this should be in the wiki 11.33.45 # so what is the point in using a bootloader and a .bin file on the flash drive instead of just uploading the whole .bin file with tcctool? 11.35.48 # the bootloader is, on many targets, installed in places that are less convenient to update. the main rockbox binary is usually installed on whatever visible storage the device offers, so that you can update it with the device in mass-storage mode, while the bootloader may be in a hidden partition, or some bit of flash, or whatever makes sense for the device in question. 11.39.13 # ok; so the iAudio7 has a mass-storage partition and some tiny private buffer to boot from. And tcctool replaces that private buffer with something else without overwriting it 11.39.51 # "replaces without overwriting"? 11.40.33 # makes the device boot from a file on the PC instead 11.40.43 # ignoring it's own private magic 11.46.58 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 11.48.27 # http://forums.rockbox.org/index.php?topic=10164.msg109942#msg109942 11.48.53 # those links are broken; where can I go to RTFM for tcc77x? 11.54.27 # cdleonard: The "tiny buffer" is the 1MB (I think) of NOR flash. When the device boots, the code in NOR flash is what is executed first. 11.59.28 # cdleonard: So you still haven't got anything sensible displayed on the LCD? 12.01.02 # no 12.01.36 # Then I would suggest trying older SVN revisions - from the time the lcd driver was first committed for the iaudio 7. Maybe something has got broken. 12.01.55 # I didn't try putting the normal build on the drive 12.01.56 # The iAudio7 port is essentially unmaintained now,.. 12.02.18 # I guess I could also try to play with button leds in the bootloader; see something moving 12.02.35 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.03.15 # Looking at the bootloader code (bootloader/telechips.c), you should see the Rockbox logo displayed when the bootloader runs. So if that isn't showing, something is wrong. 12.03.19 # Hmm, something in the new build system is borked 12.04.11 # One of my clients definitely did some builds in the last two rounds, but isn't listed at all?? 12.06.26 Quit robin0800 ("Leaving") 12.07.04 # Hmm, actually only in one of those rounds. In the other, it didn't receive any build command, but the client still thinks it's properly connected 12.07.40 # Hmmm, and the other client died with 'duplicate name' before those two round, but *is* listed??? 12.08.01 # * amiconn summons Zagor 12.08.42 # Also, disconnects (for whatever reason) while a build is running doesn't clean up 12.09.09 Join robin0800 [0] (n=robin080@81.98.157.181) 12.09.37 Quit robin0800 (Client Quit) 12.10.34 Join AndyIL [0] (i=AndyI@212.14.205.32) 12.13.05 # amiconn: the latest builds also don't appear on http://build.rockbox.org/dev.cgi 12.15.37 # Oh, hmm, that explains it 12.15.57 # There's still the 'duplicate name' issue though 12.16.34 # * amiconn didn't compare revisions - another reason why timestamps on dev.cgi would be A Good Thing 12.19.29 Join robin0800 [0] (n=robin080@81.98.157.181) 12.21.27 Quit AndyI (Read error: 110 (Connection timed out)) 12.24.07 Quit robin0800 ("Leaving") 12.24.26 Join robin0800 [0] (n=robin080@81.98.157.181) 12.26.08 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 12.26.43 # LambdaCalculus37 (logs): have you seen FS#10445? 12.32.33 Quit robin0800 ("Leaving") 12.32.51 Join robin0800 [0] (n=robin080@81.98.157.181) 12.39.18 Join _zic [0] (n=user@83-156-153-127.rev.libertysurf.net) 12.40.26 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.54.03 # mcuelenaere: remember http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/lua/liolib.c?r1=21715&r2=21714&pathrev=21715 ? in fact we need this but rather if(!rb->file_exists(filename) && *mode == ('a'|'w')) 12.54.06 # amiconn: if you want to add anything to it or follow it, we have a bug report in for binutils now: http://sourceware.org/bugzilla/show_bug.cgi?id=10409 12.59.11 *** Saving seen data "./dancer.seen" 13.01.21 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.02.03 # amiconn: hrm, also, moving the first ". = ALIGN(16)" in .ncdata into .data after the contents seems to fix the weird offset bug. 13.02.53 # Bagder: Zagor: The current builds page looks like it is stuck on r21884 13.03.12 # But then it will introduce unnecessary padding on targets which don't use .ncdata 13.03.31 # Grahack: hmm you're right 13.03.50 # you can't do && *mode == ('a' | 'w') in C though ;) 13.04.36 # amiconn: not saying that's a fix we should use, just documenting the behavior in case it means anything to somebody else :) 13.05.36 # mcuelenaere: it compiled but didn't work, maybe if(!rb->file_exists(filename) && (*mode == 'a' || *mode == 'w')) ? 13.06.06 # Grahack: yes it compiles, but it doesn't do the intended behaviour; *mode == 'a' || *mode == 'w' will work indeed 13.07.46 # ('a'|'w') == 'w', in fact 13.08.09 # by fluke 13.09.55 # New commit by 03mcuelenaere (r21918): Lua IOlib: when opening files for writing/appending, check if they exist and if not, add O_CREAT. 13.10.13 # Torne: binary? 13.10.34 # I mean bitwise 13.10.41 # ok, thanks for the C lesson guys. You see how I'm happy this Lua plugin exists ! and what is "by fluke" ? 13.12.21 # Grahack: http://www.google.com/search?q=define:fluke&hl=en ;) 13.14.21 Join mc2739_ [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.14.49 Quit mc2739 (Nick collision from services.) 13.14.51 Nick mc2739_ is now known as mc2739 (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.17.54 Join __lifeless [0] (n=lifeless@188.16.115.214) 13.24.05 # ah, buildsystem is working again... 13.24.54 # but http://build.rockbox.org/ still has old binaries 13.25.37 # erm.. buildsystem not ok, still missing 2 builds 13.26.24 Quit dmb (Read error: 113 (No route to host)) 13.34.46 Quit _lifeless (Read error: 101 (Network is unreachable)) 13.35.00 Join ucchan [0] (n=ucchan@FLA1Adp241.kng.mesh.ad.jp) 13.37.00 Join mc2739_ [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.37.16 Quit mc2739 (Nick collision from services.) 13.37.18 Nick mc2739_ is now known as mc2739 (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.45.02 # Grahack: "by chance" 13.45.06 # though it's not chance, really 13.45.11 # it's just bitwise or 13.49.25 Join junker [0] (n=chatzill@host-233-121-3-96.midco.net) 13.54.19 # that applies to all ascii character on certain boundries right? 13.56.20 # tmzt: if the set bits in one are a subset of those in the other 13.56.46 # right, okay. sorry for the offtopic 13.56.58 # that would be a hard bug to track down though 13.58.34 Quit mc2739 (Read error: 110 (Connection timed out)) 14.01.09 Quit aditya (Read error: 110 (Connection timed out)) 14.01.17 Quit DarkDefender ("Leaving") 14.01.56 Join aditya [0] (n=aditya@59.96.92.46) 14.05.39 Join dfkt_ [0] (i=dfkt@chello062178002170.1.11.univie.teleweb.at) 14.05.52 Join _lifeless [0] (n=lifeless@188.16.121.178) 14.06.02 Quit junker (Read error: 110 (Connection timed out)) 14.07.58 Quit dfkt_ (Client Quit) 14.08.49 Quit dfkt (Read error: 104 (Connection reset by peer)) 14.09.56 Join MarcGuay [0] (n=chatzill@ip216-239-79-254.vif.net) 14.10.23 Quit MarcGuay (Client Quit) 14.10.54 Quit _zic ("Ухожу") 14.20.10 Quit robin0800 ("Leaving") 14.22.13 Quit __lifeless (Read error: 110 (Connection timed out)) 14.22.57 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.23.07 Join robin0800 [0] (n=robin080@81.98.157.181) 14.30.25 # is the build system supposed to remember scores for "come and go" clients that it's seen before ? 14.31.37 Join dash32 [0] (n=dash32@84.171.84.70) 14.31.41 Join ReKleSS [0] (n=ReKleSS@114.78.149.10) 14.35.20 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 14.35.25 # yes 14.36.46 # hrm 14.36.59 # my laptop keeps being told it has a score of zero the first time I bring it back into the build system 14.37.37 # could I get write permission on the wiki? (name is JeremyChin) 14.37.43 # I'd like to put up my H120 reflashing thing 14.37.57 # I sort of doubt anybody's actually going to attempt it, though... 14.38.42 # ReKleSS: done 14.38.45 # thanks 14.38.54 # you're welcome 14.40.05 # * GodEater prods linuxstb to update IPodNano2GPort 14.40.26 # GodEater: Do I have to do _everything_.... ;) 14.40.43 # no, but you understand most of what's been done better than me :) 14.41.05 # I imagine you can probably copy and paste most of your forum post anyway 14.44.21 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 14.48.03 # GodEater: OK, I'll have a look later. I think I've just figured out how to properly control my type of LCD, so things are looking good. 14.51.36 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-d7d4b04603c63a02) 14.53.57 Join faemir [0] (n=faemir@78.33.109.163) 14.54.10 # excellent news 14.54.25 # * GodEater wishes we had a message forwarding bot on linux4nano to send dev news this way 14.54.37 # GodEater: isn't it called GodEater? 14.54.43 # :) 14.54.49 # :P 14.54.55 # not in the last few days it hasn't been 14.55.00 # I've been snowed at work :( 14.56.27 Quit stoffel (Read error: 113 (No route to host)) 14.59.12 *** Saving seen data "./dancer.seen" 14.59.38 Join GreatBeaver [0] (n=chatzill@c-71-59-18-236.hsd1.ga.comcast.net) 14.59.42 # hi 15.00.11 # i wrote a guide on using the mk8025gal in the iriver h120, if someone wants he can post it on the rockbox forum talking about the h120 http://www.head-fi.org/forums/f6/iriver-h120-80gb-hdd-guide-434921/ 15.00.37 Quit gevaerts (Nick collision from services.) 15.00.47 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 15.01.41 Quit antil33t (Read error: 104 (Connection reset by peer)) 15.01.55 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.02.11 Quit obo (Read error: 110 (Connection timed out)) 15.05.34 # GreatBeaver: we encourage people to post static content like guides to our wiki, not the forums. 15.06.58 Join _zic [0] (n=user@83-156-153-127.rev.libertysurf.net) 15.07.39 Quit _zic (Client Quit) 15.07.55 Join _zic [0] (n=user@83-156-153-127.rev.libertysurf.net) 15.07.58 # Maybe we just want a link from the HardDriveReplacement page to that forum thread? 15.14.05 Quit mt (Read error: 113 (No route to host)) 15.16.29 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 15.16.29 Quit robin0800 ("Leaving") 15.24.23 Quit _zic (Remote closed the connection) 15.27.17 # * linuxstb wonders about the capital P in IPodNano2GPort 15.29.19 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 15.30.53 Quit ucchan (Read error: 104 (Connection reset by peer)) 15.31.27 Join robin0800 [0] (n=robin080@81.98.157.181) 15.32.17 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-bdfd7fa976ec2ece) 15.35.30 # linuxstb: Sorry, that was my mistake. :) 15.35.45 # * linuxstb glares at LambdaCalculus37 ;) 15.38.10 # LambdaCalculus37: Tried anything on your Nano yet? 15.40.29 # linuxstb: I got a logo on mine. :) 15.41.18 # Was that before or after my change to support the second LCD type? 15.41.36 # After. 15.41.41 # Before, it didn't work. 15.41.43 # linuxstb: could you do that for me please/ 15.42.04 # i know i had a lot of hard time finding info on harddrives for the H120, i think if its on wikia it would help a lot of people 15.42.28 # Wikia ? 15.43.04 # rockbox's wiki? 15.43.08 # does rockbox have a wiki? 15.43.28 # yes, but it's not called wikia :) 15.44.22 # what is it called? 15.44.25 # the wiki 15.44.53 # I managed to get my iAudio7 blinking whenever buttons are pressed; but lcd doesn't work 15.45.11 # i cant find it 15.45.11 # at least I know it doesn't hang or crash during init 15.45.25 # cdleonard: Not even with older versions of Rockbox? 15.46.14 # didn't try that 15.46.18 # can someone link the rockbox wiki? 15.46.22 # i keep searching for it but cant find 15.47.17 # from http://www.rockbox.org/tracker/task/9245 I guess I should try r18435 15.47.18 # http://www.rockbox.org then click on "wiki" in the left menu of every page 15.48.47 # i dont think my guide fits anywhere there 15.51.20 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 15.53.52 Quit LambdaCalculus37 () 15.54.42 Quit MrDuck (Connection timed out) 15.54.44 # * GodEater is amazed GreatBeaver managed to read the entire rockbox wiki in 1 and hald minutes 15.54.49 # *half 15.57.36 Join funman [0] (n=fun@rockbox/developer/funman) 16.03.27 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 16.04.14 Join Ypsy [0] (n=ypsy@geekpadawan.de) 16.04.24 # Hi there 16.04.45 # Any Sansa Fuze users here? 16.04.55 # Ypsy: You should just ask your question. 16.05.35 # Well, I cba to read through all that 24 pages about rockbox on the fuze and just wanted to ask if there is a beta version of rockbox for it :P 16.06.02 # Look in the "testing builds" forum 16.06.04 # there is a test build which deadlocks and corrupt the microsd content 16.06.13 # And you'll find that.... 16.06.21 # * linuxstb doesn't think funman is selling it very well... 16.07.22 # he's just being honest 16.07.29 # he's clearly not cut out for a salesman job 16.07.40 # Dont have a microsd yet so whatever :P 16.07.59 # I imagine you'll enjoy just the deadlocks then 16.08.34 Join DerPapst [0] (n=DerPapst@p4FE8F00E.dip.t-dialin.net) 16.08.43 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 16.08.46 # i'm not sure deadlocks (well, now they are panics) happen when using the internal storage 16.08.58 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.09.09 # funman: so it'll be an exciting journey for him then! 16.09.45 Part Grahack 16.09.52 # a forum user will send me his problematic microsd card, i'll see what i can do with it 16.12.41 # * mcuelenaere just permanently flashed Rockbox to his VX747 :) 16.16.57 Quit efyx_ (Remote closed the connection) 16.17.52 # linuxstb: I tried r18435 and r19597 (another vitje commit) and got the same result: white screen on startup 16.18.15 # backlight can be controlled but lcd doesn't seem to do anything useful 16.18.46 # cdleonard: Is your iaudio 7 relatively new? It's not uncommon for manufacturers to change LCD types 16.19.45 # it's a 16gb model; and it's reasonably new 16.19.59 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.20.04 # back says CWS-iAUDIO-7(B); note the (B) 16.20.12 # Is there a stable of the fuze version in sight? 16.20.27 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 16.21.31 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 16.22.14 # Ypsy: maybe, but who can say ? 16.22.42 # if the people working on it knew what to fix to get a stable one, they'd have fixed it already right ? 16.23.02 # but since they don't, they don't know how long it'll take to work out what the problems are. 16.23.14 # so it's impossible to guess when a stable build might turn up 16.23.26 # okies, but they're still working on it, are they? 16.23.38 # funman is working like a slave :) 16.23.48 # haha :) good to hear ;) 16.23.50 # I used mktccboot with OF v1.18; while the original developer probably used 1.17; could that be a problem? 16.24.24 # this new version is almost twice as big; which seems strange: http://www.cowonamerica.com/download/iaudio_7_jsfw.html 16.25.04 # cdleonard: Yes, it's worth trying older OFs as well. 16.25.40 # Although maybe not... Our code should be run before the OF, so that should affect things. 16.26.03 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.26.27 # * GodEater hands linuxstb a extra "not" 16.27.13 # GodEater: Thankyou. 16.27.37 # any time 16.27.40 # I'm here to help 16.28.27 # other than that I guess I have to disassemble the OF; right? 16.29.24 # cdleonard: Yes. Although it would be good to find someone who can get Rockbox working on their iAudio 7. As I said, I think vitja was the only person who ever did any work on it. 16.29.44 # So the code in SVN may not even be working... 16.30.45 # New commit by 03mcuelenaere (r21919): Onda VX747: add dual-boot capability + make it possible to permanently 'stick' Rockbox to your DAP 16.31.25 # buttons and lights do work; so at least some code can run inside the device 16.31.28 # * GodEater notices his load average starting to climb 16.31.42 # can I retire the old build client's directory now by the way ? 16.31.59 # * GodEater noticed no follow up email from Zagor to say the switch over had officially occured 16.32.13 # GodEater: yes you can 16.32.19 # Zagor: thanks 16.32.55 Quit funman ("free(random());") 16.32.56 # Zagor: Any idea on the duplicate name issue? It still happens occasionally. Bad if you want to leave the client running unattended... 16.33.06 Join __lifeless [0] (n=lifeless@188.16.117.104) 16.33.25 # amiconn: do you have a time when it occurred last? 16.33.33 # Oh, and the client doesn't clean up if the connection gets lost (for whatever reason) while a build is running 16.33.42 # ah yes, during last night all my clients got disconnected with duplicate-name issues 16.34.03 # mine too 16.34.10 # Zagor: Today, 07:11:23 CEST on jupiter 16.34.21 # 2009-07-17 06:13:48 Server refused connection: error duplicate name! 16.34.31 # GMT 16.34.34 # on atlas 16.34.36 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.34.53 # GodEater: Real GMT or GMT+1 for summertime? 16.35.03 # erm 16.35.04 # the good news is I've found and fixed the ping problems 16.35.05 # er 16.35.09 # uhm 16.35.15 # prolly GMT+1 16.35.22 # he guessed wildly 16.35.26 # That's almost the same time as on mine, then 16.35.31 # yes 16.35.34 # Do you sync from NTP? 16.36.06 # * GodEater goes to check 16.36.38 # doesn't look like it 16.36.42 # * GodEater fixes 16.37.02 # So the difference could be just clock drift on your side, and it happened at the same time 16.37.29 # very likely 16.37.56 # I have a problem on my gigabeat X60, 2 times this week, the music stop (not the same) and I can't do anything, only have the lcd on and off ?? 16.37.57 # I have 15:37 here currently 16.38.07 Join mc2739 [0] (n=mc2739@adsl-71-149-166-159.dsl.snantx.sbcglobal.net) 16.38.21 # GMT then 16.38.23 # the first time I had also a message , cannot read the playlist or something like this 16.38.37 # GMT+1 (no summer time) 16.38.48 # My duplicates are: hal 00:45:50, monster 02:10:55, rb1 06:32:06, rb2 05:46:51, rb3 02:13:31, rb4 02:13:31, all GMT+2 16.39.02 # Zagor: The current builds page looks like it has not updated since r21884 16.39.04 # does GMT include summertime :? 16.39.37 # mc2739: oh right, I'll fix that 16.39.50 # kugel: it's technically BST 16.39.55 # "British Summer Time" 16.39.57 # my question is, why the power button doesn't work and pressing a button switch the lcd on and off ? 16.40.29 # I guess we should refer to UTC instead? 16.43.00 # kugel: is your client gone? 16.43.07 # apparently 16.43.25 Quit _lifeless (Read error: 110 (Connection timed out)) 16.43.31 # it's taken off, until late august 16.46.15 # haha, now other clients have the chance to feel how it is to have 100k points :) 16.47.55 # that would have happened anyway :) I decided to go back to a single client, and that machine had around 150k before, split over four clients 16.48.34 Join J-23_ [0] (n=zelazko@unix.net.pl) 16.49.17 # amiconn: I'm not sure what we can do. the server didn't get the disconnection of your client until a full 10 seconds after the duplicate name 16.49.36 Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) 16.50.10 # the only thing I can suggest is that we instead of exit 22 waits maybe 10 seconds and retry 16.50.37 # hmm could the VX747 bootloader red be a false alarm? 16.51.19 # mcuelenaere: the build log says "Build Status: Failed" so it definitely is something wrong. exactly what is unclear to me though, 16.51.36 # Zagor: perhaps the 'mipsel-elf-gcc: no input files ' line? 16.51.52 # full unparsed log: http://build.rockbox.org/data/21919-ondavx747boot.log 16.52.07 # mcuelenaere: probably 16.53.11 # actually, no. the "failed" is written by rbclient if the specified output file isn't produced 16.53.38 # ah, how does it determine the specified output? 16.53.38 # gevaerts: why did youß 16.53.43 # (I renamed the bootloader to ccpmp.bin) 16.53.55 # mcuelenaere: it's listed in the "builds" file. in this case it is "rockboot.vx747" 16.54.05 # gevaerts: what 150k do you mean (my machine had a rating of 230k) 16.54.40 # mcuelenaere: if the rename is permanent, please change the builds file too 16.55.08 # Zagor: www/buildserver/builds ? 16.55.15 # mcuelenaere: yes 16.56.49 # New commit by 03mcuelenaere (r21920): Update builds file with new VX747 bootloader filename 16.56.58 Quit ReKleSS ("Leaving") 16.59.14 *** Saving seen data "./dancer.seen" 16.59.46 Quit Xerion (" ") 17.01.05 # Zagor: Maybe double the retry interval every time? This way a real duplcate wouldn't cause too much server load 17.01.58 # Hmm, or maybe exit if the client gets a "duplcate name" message on startup, but not on retry 17.02.32 # Every 10 seconds won't cause any measurable server load either. 17.03.24 # I'm adding logging to the next client update, to easier see what the client is doing 17.04.20 Join mnk200 [0] (n=mankind@bl13-17-153.dsl.telepac.pt) 17.05.55 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 17.07.02 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 17.07.21 # kugel: that 230k was before rounds got faster 17.08.33 # gevaerts: I don't mean the score on the client page 17.09.00 # I mean the "230000 puts you in the fast category" 17.09.28 # kugel: yes, but that's the average score 17.10.20 # ? 17.11.13 # New commit by 03zagor (r21921): Added logging. Added output file missing message. Added sleep+retry instead of exit 22 on HELLO failure (to cure duplicate name exits). 17.14.22 # kugel: don't worry. I also have no idea what we're actually talking about :) 17.15.55 # gevaerts: so which 150k did you mean? 17.16.11 # kugel: the sum of rb* 17.16.59 Join roolku [0] (n=roolku@77-99-113-75.cable.ubr16.sgyl.blueyonder.co.uk) 17.18.05 # Zagor: did you see my coment from last night: the build system didn't spot the failed builds when images are missing such as: http://build.rockbox.org/shownewlog.cgi?rev=21908;type=mrobe100 17.19.08 # roolku: thanks, i'll look at tat 17.19.09 # that 17.19.10 # Zagor: also lots of clients failed because of the duplicate name issue (4 of mine and I others commented as well) - you can see the decline in numbers in the build table 17.19.27 # yes last nights server wasn't my best :) 17.19.34 # gevaerts: I don't think they'll just sum up 17.19.53 # kugel: no, but they would have 100k even without your client stopping 17.20.00 # sure ;) 17.20.05 # blah blah :P 17.20.11 # New commit by 03zagor (r21922): Bugfixed socket data reading. ... 17.20.42 # Why are you switching to single client? Didn't you "prove" yourself that multiple clients are better? 17.22.35 Join rockbox [0] (n=anilbpai@59.92.203.122) 17.22.49 # hi 17.22.53 # newbie here 17.23.01 # original name though 17.23.28 Quit petur ("beer time!") 17.23.32 # how can i get started with ? 17.23.55 # where "?" is what exactly? 17.25.18 # roolku: what are you trying to do? 17.25.34 # eh, rockbox .. 17.25.55 # roolku: sorry :) 17.36.39 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 17.36.42 Quit rockbox (Read error: 60 (Operation timed out)) 17.37.53 Quit Zagor ("Leaving") 17.38.12 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.42.04 # gevaerts: do you have an opinion on the dev-ml discussion about funman's commit? It's your code... 17.44.52 # not really, except that I'm not convinced that those functions belong in the plugin api 17.45.23 # spinnung up a disk because you're going to read from an sd card soon is not optimal 17.45.59 # esp. if there's no disk there 17.47.18 # that's the better case, as it will just be a stub. The problem is that those plugin api things are based on the assumption that there's only one storage device 17.48.49 # ata_spin() is not for spinning up a disk - that's done automatically. It is for keeping the disk spinning when the code knows the next access will happen very soon 17.49.19 # linuxstb: about DSP_SET_SAMPLE_DEPTH, do you happen to remember how that value is calculated? 17.49.28 Quit nls (Read error: 110 (Connection timed out)) 17.49.32 Join funman [0] (n=fun@rockbox/developer/funman) 17.49.49 # And ata_sleep() is for quick sleep, without waiting for the timeout. Both make very much sense for plugins as well (mpegplayer, video, ...), and having an empty function for them for non-hdd is safe 17.49.50 # what about disk_spin() ? (more explicit on its usage) 17.50.18 # amiconn: sure, but what about a player with both a hard drive and some flash thing? 17.50.25 # What about it? 17.50.39 # what do the functions do? 17.51.09 # The same as they do on single storage, I'd expect 17.51.18 # in case of multi driver targets, only the internal storage would be a disk, we could separate ata_spin/ata_sleep from storage driver 17.51.35 # funman: not sure :) How about USB? 17.51.57 # gevaerts: Can you control usb hdd spinup/spindown from the host? 17.52.12 # gevaerts: what's the link with USB ? 17.52.52 # amiconn: not sure, but I'd expect so 17.53.20 # funman: usb host. More disks 17.53.41 # I still don't get it, sorry 17.54.02 # "only the internal storage would be a disk" is not true for those 17.54.46 # amiconn: my point is that those functions apply to the drive having the files the plugin is working with. The way they are defined, the core doesn't know which drive this is 17.54.50 # I meant the removable storage can not be a hard disk 17.56.13 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-7b57b702622b978a) 17.56.20 # Not atm, no. But I'd go KISS first, and just apply it to all drives. We can still add differentiation later 17.59.04 # So if I want to separate ata_sleep/ata_spin from storage driver, there should be a way (in the future) to know (dynamically) if said storage uses a disk or not 18.01.23 # No, the purpose of the multi-storage layer is that the app doesn't need to know that 18.02.43 # funman: what's the point of separating it? 18.03.17 # What could be added later is a way to track which storage the app uses, and only apply *_spin() to that one 18.03.21 # i have explained that in my mail to rockbox-dev i think 18.03.46 # funman: not in a way that makes it clear to me 18.03.48 # separate unrelated code, because i think physical storage type is not related to the storage driver (ata/nand/sd/mmc) 18.04.03 Quit dash32 ("Verlassend") 18.04.19 # In theory, yes (not counting cf mods) 18.04.44 # It doesn't hurt to use ata_spin() and ata_sleep() on a cf - it just doesn't change anything 18.05.13 # it annoys me when i read the code 18.06.01 # funman: so you want to basically rename storage_spin() to disk_spin()? 18.06.03 # what is bad with making this code really dependant on HAVE_DISK_STORAGE ? (which is the only time when it has an effect) 18.06.17 # gevaerts: yes 18.06.23 # saratoga: Sorry, I don't. preglow might... 18.06.33 # funman: More ifdefs for nothing 18.06.34 # funman: the problem with the disk_*() names I see is that it (IMHO) really doesn 18.06.55 # t belong in disk.c, while the names would imply that. I don't know how important this si 18.06.56 # saratoga: Or you could try searching the IRC logs - I'm sure it's been discussed here 18.06.57 # amiconn: clear separation IMO 18.07.24 # disk_ is entirely different module, related to handling partitions 18.07.26 # funman: HAVE_DISK_STORAGE means that there is at least one disk, not that the driver you're looking at deals with disks 18.07.37 # gevaerts: well disk.c is wrongly named as well, i didn't know where to put these new disk_spin functions 18.07.53 # funman: spindle_spin()? :) 18.08.08 # And storage_ abstracts from the storage types. So having *_spin() and *_sleep() for all drivers actually provides better abstraction 18.08.25 # Anyway, I think they do belong in storage.c, because they make use of the storage.c indirection layer 18.08.57 # what about keeping this discussion on the ML where it started? 18.09.17 # i'm still not convinced, and we could better track each other arguments on the ML 18.10.18 # * gevaerts would like to see the stubs eliminated, but when he tried it turned out to be difficult 18.10.47 # Well you need those stubs anyway for the plugin api 18.11.01 # that was the sticking point, yes 18.11.03 # only when they are needed at all? 18.11.32 # * amiconn wonders why funman doesn't understand the advantage of less ifdefing 18.11.46 # funman: so you'd add #ifdef HAVE_DISK_STORAGE around the stubs? 18.12.04 # amiconn: i do understand them, do you understand the advantage of less stubs and code separation ? 18.12.14 # Why should the app care what storage is in use? It tells the lower layers whether it's okay to send the storage to sleep, or whether it wants it to stay quickly accessible 18.12.15 # gevaerts: no, i already did 18.12.27 # This *is* code separation 18.12.46 # the storage, or the disk ? 18.12.57 # how would the app know? 18.13.03 # Whether the storage layer actually needs to do something in response to this info simply doesn't matter for the app 18.13.23 Quit aditya (Read error: 110 (Connection timed out)) 18.13.36 # * gevaerts agrees with amiconn. It would be nice if the app could give some hints about which bit of storage it cares about, but it's better not to try to handle too many changes at the same time 18.14.37 # Yeah, that's another thing. I think that later the app could pass e.g. a path, which can be used by the storage layer to decide which driver is responsible 18.15.06 # In fact that might not be necessary 18.15.17 # the storage rework patch is already quite complex. I'd like to separate it in different bits, not make it bigger 18.15.48 # The main purpose of ata_spin() is to keep the gui responsive when browsing, and for that, it makes much sense to broadcast it to all underlying storage driver 18.16.29 # ata_sleep() otoh is meant to be sent whenever some buffering ends, in order to save timeout_seconds of disk power 18.16.35 # i think removing this special case for hard disks makes things simpler 18.16.55 # So that can be broadcast as well - it is very likely that only one disk is spinning if there are several 18.17.05 # What special case???? 18.17.21 # disk spinning / sleeping 18.17.31 # ahem... 18.17.31 # removing it, *from the storage layer* 18.17.51 # I wonder if you have noticed r21912 and its discussion on the dev ML 18.17.53 # Can RBUtility debug builds still be builded? 18.17.56 # * gevaerts sees that funman missed some stubs anyway :) 18.17.57 # Rockbox strives to save power, so it is *necessary* for the app layer to tell the storage layer about these cases 18.18.39 # amiconn: not to the storage layer, but to the harddisk-specific driver 18.19.04 # funman: that means the apps need to know what sort of storage they are using 18.19.06 # * amiconn wonders whether he can't explain things anymore :\\ 18.19.25 # funman: The app layer shouldn't have to care whether this is hdd or some other storage 18.20.07 # well using storage_sleep() implies you know about hard disks 18.20.41 # Yes, but you don't need to know whether it actually *is* a hard disk 18.21.23 # I don't know what is "quick sleep", or "timeout" 18.22.32 # since you are writing this code specifically for the case if there is a harddisk, why not mentioning it explicitely? 18.22.56 # Better abstraction *and* less ifdefing - I already said that 18.23.33 # The only "drawback" is calling an empty stub on non-hdd targets, which means a whopping 8 bytes of binsize 18.24.42 # there is also the drawback of seeing the stubs defined which was more my real concern, rather than saving 8 bytes 18.25.05 # What drawback is that? 18.25.18 # Seeing the stubs annoy me 18.25.57 # Then don't look... why stubs that provide better abstraction would be annoying is beyond me, really 18.26.23 # They are not the only stubs in rockbox - sometimes stubs are the best soltion 18.26.23 # Here I don't see the need for abstraction 18.26.45 # Ok you convinced me 18.27.26 # * kugel finds it sad that amiconn never bothers to express his opinion on the ml 18.27.45 # me too 18.28.13 # irc is so much more convenient. And it's logged, so no disadvantage related to that 18.28.31 # mailing list is threaded 18.28.34 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 18.29.03 # I think we should re-implement the whole damn lot in C++ and hide the 'stubs' in the abstract storage driver base class ;-) 18.29.15 # eurgh 18.29.20 # *much* better 18.32.45 # amiconn, funman: If we make it inline, it would expand to nothing for the core, but an empty function for plugins, or am I wrong here? 18.33.15 # I saw that if a inline is non-static, gcc inlines but also creates the function body (so that it's addressable) 18.33.19 # i think you can't export a static function 18.33.33 # funman: inline, not static inline 18.34.09 # Hmm, actually it could be static inline in the .h. Gcc should include a body in plugin.c in this case 18.34.37 # New commit by 03funman (r21923): Revert r21912 : "Storage API : remove undeeded target-specific functions" ... 18.34.43 # New commit by 03funman (r21924): remove nand_soft_reset and nand_disk_is_active already voided in storage.h 18.34.47 # it doesn't create a body at all, IIUC, if it's static. At least that's what I saw in chopper 18.35.08 # ata.c wants it to be an ordinary fucntion though, as does the storage layer for true multistorage if that either includes ata or usb 18.35.13 # * kugel looked in the disassembly due to related weirdnesses 18.36.12 # oh, the front page is quick today 18.37.14 # kugel: It will create a body as soon as you take the function address 18.37.58 # ah, I understand. but it still wouldn't work for ata.c? 18.38.20 # ata.h would define it non-static as normal 18.38.25 # the declaration could be different for each storage type 18.42.00 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.49.13 Join obo [0] (n=obo@rockbox/developer/obo) 18.58.41 # I'm looking at clipv2 again, I'm embedding a rockbox.sansa binary with mkamsboot but I see weird behaviour : no LCD, reboot on keypress 18.59.06 # I believe this is a problem with the as3514 code, there could be incompatible differences with the audio codec used in as3531 18.59.13 # funman: maybe a panic before lcd init? 18.59.17 *** Saving seen data "./dancer.seen" 18.59.26 # ah thanks i didn't about that 18.59.49 # did the lcd actually work on the clipv2? 18.59.59 # yes 19.02.51 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 19.03.45 Join readability [0] (n=chad@206.248.173.89) 19.05.42 # funman: I'm getting the fuzev2 in ~1 month, probably 19.06.07 # I hope the lcd driver is similar to the v1, I might be able to implement it then 19.06.56 # have you looked in the OF if the init procedure differ 19.06.57 # ? 19.07.10 # no, not yet 19.08.12 Join aditya [0] (n=aditya@59.96.92.46) 19.10.25 Quit obo (Remote closed the connection) 19.10.40 Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) 19.12.54 # funman: so you're in touch with a uclinux guy that made code for AMS? 19.13.19 # regarding the storage_* functions, I think it'd be best to proceed with the multistorage patch as-is, and then look at removing the "redundant" stubs later. KISS, as was mentioned earlier.. 19.13.31 # agree 19.13.43 # so... with that in mind, is there anything else that needs to be done to FS#9545 before it can be committed? 19.13.45 # commit early, commit often :) 19.14.43 # * shotofadds wonders about the high-score possibilities of this patch :) 19.14.59 # maybe I'll leave it to gevaerts ;-) 19.15.09 # many .h files, generally a good way to break things :) 19.15.23 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 19.15.52 # does it remove the uber-guly IF_MV stuff also? 19.15.58 # * kugel looks 19.16.14 # yea, IF_MV is IF_MD now :S 19.16.49 # kugel: not in all places :) 19.16.59 # There's IF_MV() and IF_MD() now! 19.17.04 # ughh... 19.18.52 # * gevaerts seems to remember that there were still some open issues 19.19.28 # kugel: i contacted the person working at AMS who works on linux and uboot (not uclinux) ports 19.19.45 # He told me he couldn't do anything and advised me to contact the product marketing manager 19.20.08 # the one who stopped answering my emails some month ago (and is still continuing, i have no answer to my yesterday's mail) 19.20.15 # gevaerts: could drive be a part of struct storage_info? 19.20.45 # why? 19.20.59 # funman: I wonder if at least 1 sd controller is still the pl180 one 19.21.19 # gevaerts: wouldn't it make sense and save a parameter to many functions? 19.21.30 # kugel: what do you mean ? 19.21.51 # kugel: what functions? struct storage_info isn't passed to any functions... 19.21.55 # either the internal or external one (that of course applies to the fuzev2= 19.21.56 # ) 19.22.12 # gevaerts: "void mmc_get_info(IF_MD2(int drive,) struct storage_info *info)" 19.22.30 # kugel: the controller in the clipv2 is not a pl180 for sure, and I didn't see 2 different drivers in the fuzev2 OF either 19.22.31 # kugel: that's to get information *from* a drive 19.22.49 # the person from AMS let me know the SD controller is made by synopsys 19.22.53 # gevaerts: so what? 19.23.00 # funman: both? 19.23.09 # kugel: what exactly are you proposing? 19.23.12 # I mean, IIUC the 3525 ones use 2 controllers 19.23.26 # gevaerts: have a int drive member in struct storage_info 19.23.36 # kugel: again, why? 19.23.43 # and anyhow get rid of IF_MV :) 19.23.43 # kugel: he didn't give me any details, I suppose the 2nd controller was added by SanDisk to the AMS design like they did for the AS3525 (which only has 1 PL180 controller according to the datasheet) 19.23.53 # How does that help you do that? 19.24.07 # kugel: the storage_info struct isn't filled when given to this function 19.24.26 # it will be filled, but the drive number could be filled before 19.24.30 # only allocated 19.24.42 # whatever, nevermind 19.24.59 # kugel: so yes, you could remove the IF_MD() from *_get_info(). What does that gain you? 19.25.10 # It's still everywhere else 19.25.12 # less uglyness 19.25.13 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-c4584eed183a0db2) 19.25.22 # more inconsistency 19.25.23 # kugel: if you want to work on it, fs#10047 has a description of all registers i could understand, and working code for sending commands to the card 19.25.29 # i.e. *more* uglyness 19.26.01 # I'm also not seeing that saving a drive parameter is worth obfuscicating code (and pre-processing function paramters is obfuscicating imo) 19.26.07 # obfuscating* 19.26.17 # LambdaCalculus37: seen FS#10445? 19.26.59 # funman: if the microsd is still "powert by" pl180, I could hopefully boot rockbox off the microsd 19.28.38 # gevaerts: what do you not understand? 19.28.51 Join nls [0] (n=n1s@cm-84.215.127.139.getinternet.no) 19.28.55 # kugel: i didn't see pl180 code 19.29.24 # and since the RAM is large enough, you can skip the bootloader process and embed rockbox directly into the firmware file (for testing purposes) 19.29.25 # kugel: why you feel it's good to pass the drive parameter from *_get_info() in a different way than to all other storage functions 19.30.07 # it would be part of the plan to get rid of IF_MV completely :) 19.30.24 # * gevaerts gives up 19.30.30 # funman: is the firmware part of the OF big enough? 19.30.35 # gevaerts: still not clear? 19.30.46 # get a coffee! :p 19.31.11 # mcuelenaere: No, I haven't. What is it? 19.31.44 # LambdaCalculus37: didn't you commit r21908? 19.31.56 # mcuelenaere: I did. 19.32.08 # mcuelenaere: the guy filled his flyspray info wrongly 19.32.34 # mcuelenaere: I see what he said. He should've just posted that on the mailing list. 19.32.40 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 19.32.42 # kugel: you mean his name? I think it's correct 19.32.43 # kugel: for clipv2 yes (80kb left) 19.32.56 # * bertrik has an idea 19.33.00 # mcuelenaere: it ends with i in his flyspray info too 19.33.11 # isn't it supposed to be ending with an i? 19.33.13 # I have this firmware image and I wonder if there's a filesystem image in it 19.33.27 # mcuelenaere: oh, I read it the other way around 19.33.31 # nevermind then 19.33.31 # I guess I could use one of those lost file / partition scanners to find it 19.33.54 # bertrik: perhaps look at hal/mount for filesystem signatures detection 19.34.02 # anyway, it's a minor thing :) 19.34.05 # funman: how would you load rockbox.sansa into ram? 19.34.05 Nick evilnick is now known as eviltroll (i=0c140464@gateway/web/freenode/x-bdfd7fa976ec2ece) 19.34.08 Quit faemir (Remote closed the connection) 19.34.21 # or in the firmware file 19.34.22 # funman, what is hal/mount? 19.34.27 # kugel: mkamsboot 19.34.43 # bertrik: hal is a freedesktop library / daemon for hardware detection 19.34.53 # is 80K big enough? 19.35.03 # mount is a standard unix command to mount filesystems (it can detect filesystem types) 19.35.19 # but mount can't scan a file, or can it? 19.35.28 # kugel: http://pastie.org/549620 19.35.47 # bertrik: no but you could see how it detects filesystems and look in your file for known filesystem signatures (magic values) 19.35.55 Nick Ypsy is now known as YpsyZNC (n=ypsy@geekpadawan.de) 19.36.11 # too much work, I'd rather try a program already made for that 19.37.14 # funman: ah, the firmware part is 400k 19.37.21 # * kugel didn't know 19.38.02 Quit wincent (Read error: 110 (Connection timed out)) 19.38.54 # kugel: so if you pass drive always, and get rid of IF_MV that way, why do you want the drive in struct storage_info? 19.38.57 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 19.39.49 # I had that idea before I knew it was only used for that single function (I thought was more, but it was just the same function for ata/nand/sd/mmc) 19.40.06 # so you didn't even look at the code?> 19.40.20 # I skimmed the diff and looked at the struct definition 19.40.23 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.40.43 # and grepped firmware/* 19.40.46 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 19.41.09 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.41.10 # shotofadds: before it can be committed, things like NUM_VOLUMES, MAX_NUM_DRIVES need to be cleaned up 19.42.00 # ok, can't find anything in the firmware image with testdisk 19.42.26 # Argh, why am I having trouble restoring the HDD1630? I'm trying to put it into recovery mode to restore Rockbox onto it. 19.42.32 # toffe82: Ping 19.42.41 # Or lowlight: Ping 19.42.50 # LambdaCalculus37: pong 19.43.01 # funman: btw, before mkamsboot 1.1, the (c) should be updated 19.43.06 Quit einhirn (Client Quit) 19.43.24 # toffe82: Do you know how to get service and recovery mode working on the HDD1630? I'm using the instructions here: http://www.rockbox.org/twiki/bin/view/Main/GoGearHDD6330#Service_Mode_I_found_2_methods_I 19.43.27 # kugel: i'm not sure large modifications were made this year 19.43.28 # But nothing works. 19.43.34 # kugel: I told you several times that it's only used in *get_info(). You ignored that and kept pretending to know better 19.43.36 Quit aaron424 (Remote closed the connection) 19.43.37 # it doesn't matter 19.43.50 # gevaerts: no, you read my sentences wrong then 19.44.01 # i would just remove the copyright notice if linuxstb agrees 19.44.20 # why? 19.44.35 Join stoffel [0] (n=quassel@p57B4DA3B.dip.t-dialin.net) 19.44.39 # because it is useless 19.44.43 # kugel: and every time someone tries to tell you that you're wrong, you try to ridicule them or you accuse them of misreading what you say 19.45.37 # LambdaCalculus37: it is not on the wiki of the 1630 ? 19.45.42 Quit fdinel (Client Quit) 19.46.24 # I though there was 2 separate pages ??? 19.46.30 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.46.48 # toffe82: Just the one page AFAIK. 19.47.29 # it is not in the service manual ? 19.47.33 Quit fdinel (Client Quit) 19.47.53 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.48.23 # funman: I've no objection 19.48.32 # (but no opinion either way...) 19.49.33 # * kugel is curious what funman is going to answer (test build thread) 19.51.06 # New commit by 03funman (r21925): mkamsboot: remove runtime copyright notice ... 19.51.30 # kugel: i won't answer 19.51.33 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 19.51.36 Quit fdinel (Client Quit) 19.52.01 Quit flydutch ("/* empty */") 19.52.10 # toffe82: I have the USB mass storage image on the screen. 19.52.23 # But what appears in Disk Utility is a read-only device. 19.52.55 Quit mnk200 (Client Quit) 19.53.02 # funman: can you explain it to me then? I mean, what you said makes sense, but it still seems to have fixed the problems 19.53.14 # Wait... switching to my Windows box got it to appear as a mass storage device. 19.53.32 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.53.35 # I query'd with him, fsck reported errors on the internal partition, and crapped out due to 512 filesystems on the microsd 19.53.35 # ARGH... no drive appears, though. 19.53.41 # LambdaCalculus37: :) 19.54.07 # I think it is really dependant of the time you press the buttons 19.54.24 # kugel: there is still no known cause to problems with SD driver, so anything might randomly affect the transfers 19.54.32 Quit nls (Read error: 60 (Operation timed out)) 19.54.55 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz) 19.55.24 # perhaps this could be related to bad blocks, I think SD can't handle bad blocks in every situation. The SD specification might have more details on this topic 19.57.00 # SD as in what? the card, the controller or our driver? 19.57.20 # kugel: I think the IF_MV() thing is already a lot better than it was. Due to the way the storage_* macros work, it's confined to the actual drivers. Code that just calls storage_* doesn't need them anymore 19.58.15 # kugel: card and/or controller (hardware) 19.58.45 # New commit by 03dave (r21926): Improvments to Nano 2G LCD driver. This now works reliably on both LCD types. 19.59.00 # funman: the guy got his FS corruption before installing rockbox IIUC 19.59.08 # gevaerts: yea, that's true 19.59.22 # that was by accident actually :) 20.00.16 # hehe 20.00.23 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.03.23 # funman: he installed the bootloader but couldn't install rockbox.zip because of read-only filesystem 20.08.54 # something is definitely weird with our sd driver 20.09.47 # * gevaerts thinks about how to get rid of this explicit MAX_NUM_DRIVES definition. Maybe just set it in config-*? It's only applicable to multi-driver anyway, so it wouldn't appear in many files 20.09.51 # kugel: help welcome 20.10.08 Join stoffel_ [0] (n=quassel@p57B4DA3B.dip.t-dialin.net) 20.10.43 # gevaerts: how different is a drive from a volume with that patch? 20.11.12 # kugel: totally. That's one of the points. A drive is really a physical drive, while a volume is a filesystem 20.11.42 # does it already allow more than 2 filesystems in rockbox? 20.11.57 # sure, if you set NUM_VOLUMES high enough 20.12.17 Nick dys` is now known as dys (n=andreas@krlh-5f7069bf.pool.einsundeins.de) 20.12.36 # is there a way to disable the nvram.bin-feature without recompiling? 20.12.37 # which is one of the other issues. What's a good default setting for NUM_VOLUMES? It's not NUM_VOLUMES_PER_DRIVE... 20.12.47 # re: MAX_NUM_DRIVES: Couldn't you simply merge HAVE_MULTIDRIVE and MAX_NUM_DRIVE, in some sort of #define CONFIG_NUM_DRIVES X (X being 1 for single drive targets) 20.13.09 # defined in config-* 20.13.26 # * dys wants to prevent unneccessary writes to his precious 32GB cf card 20.13.30 # kugel: it doesn't use MAX_NUM_DRIVES for single-driver targets, so that bit is easy :) 20.13.32 # not sure about volumes though 20.14.02 # but yes, defining the number of drives in config-* sounds reasonable 20.14.18 # gevaerts: I was thinking to do it similar as with dual-core which has also a NUM_CORES define 20.14.59 # I think for single core it's actually set in config.h (#ifndef NUM_CORES \n #define NUM_CORES 1 \n #endif) 20.15.26 # there's no HAVE_DUAL_CORE #define 20.15.59 # kugel: the main annoyance with NUM_VOLUMES on e.g. a two drive player (like the sansas) is that it needs to be at least 2. Now if someone partitions the internal flash with two filesystems, suddenly the microsd slot stops working (from the user point of view. It's still there over USB) 20.16.47 # We could add extra code to allow single-volume-per-drive multidrive, but I don't really like that either 20.16.54 # I'm thinking that, at least for internal storage, NUM_VOLUME could be determined at runtime 20.17.16 # you can't. The space needs to be allocated at boot 20.17.30 # yes, exactly 20.17.48 # detect volumes at boot and allocate space before showing the main menu 20.17.57 # i.e. what tagcache and the like do 20.18.22 # kugel: you need the space before you can even mount the first filesystem. This gets tricky 20.18.54 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-62adc1062d939e90) 20.19.11 # Maybe just assume NUM_DRIVES*4? We don't do extended partitions IIRC, so 4 is always enough. The only problem is a bit of wasted RAM, especially on the ondios 20.19.18 # the first filesystem could be statically allocated (there must be at least 1 volume anyway) 20.19.50 # you'll need more complicated data structures then. Right now it's just an array 20.19.58 # the bootloader would probably doesn't support multivolume anyway 20.20.06 # * gevaerts decides to measure the RAM usage overhead per extra allowed volume 20.20.43 # any further volume could be perfectly allocated from the audio buffer 20.20.44 # mcuelenaere: So zenutils can extract the Dell DJ bootloader? 20.20.46 # LambdaCalculus37: it can also split the .bin file 20.20.54 # mcuelenaere: A good sign? :) 20.20.57 # why would you need several partitions if they all are fat32 ? 20.21.14 # LambdaCalculus37: let's see if it has the keys to decrypt the main firmware ) 20.21.15 # :) 20.21.38 # kugel: I'll first see how much the simple solution costs. It doesn't make sense to write complex allocation code if it's only a few hundred bytes 20.21.47 # I agree fully 20.22.32 # no point in saving 200 bytes of RAM if you need 1K of code to do that 20.23.55 # and external drives would still be problematic 20.24.11 # they would at least require stopping playback if it was detected at runtime 20.24.21 # ah yes. That too... 20.25.47 Quit kugel (Remote closed the connection) 20.26.04 # LambdaCalculus37: seems like these older firmwares don't even use 'real' encryption 20.26.34 # I can send you the decrypted/splitted firmware if you want 20.26.55 # mcuelenaere: Sure, email it over. 20.27.04 # Do you need my email address? 20.27.09 # I'll upload it 20.27.19 # Okay. 20.28.41 # http://www.mediafire.com/?zxgkingmntu 20.29.01 # for a rough description of what most of the files mean, see http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort 20.29.12 Quit funman ("free(random());") 20.29.16 # (FBOOT & FRESC aren't encrypted) 20.29.34 # CENC.dec is the decrypted version of CENC 20.31.25 Quit BryanJacobs ("Java user signed off") 20.31.36 # How much RAM do the v2 sansas have? 20.31.44 # Depends on the target 20.32.03 # I know. I want to know all of them :) 20.33.32 # * gevaerts is trying to evaluate the cost of various multivolume options 20.39.55 # mcuelenaere: I need to get a disk dump of the Dell DJ as well. 20.40.17 # LambdaCalculus37: why? the file system is probably the same/an older version as the ZVM 20.40.37 # LambdaCalculus37: does the Dell DJ communicate with a PC over MTP or NJB? 20.40.51 # mcuelenaere: NJB IIRC. 20.41.00 # ah then it uses the older file system I think 20.41.20 # mcuelenaere: I wanted to be sure. 20.43.17 # OK. The total cost per volume on targets that already have more than one drive is 104 bytes 20.44.25 # That would mean that if we want to keep multidrive handling simple without risking not finding any volumes at all on the second drive because the first has more than one, it costs exactly 624 bytes 20.48.04 # SCREW bin/ram costs.... keep the damn code simple and eat the other costs 20.48.19 # seriously... its less than 1KB... 20.48.32 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.49.02 # JdGordon|: I agree 20.49.43 # * gevaerts tends to agree as well, but he still did want to know the numbers first 20.49.50 # how does the filebrowser present the volumes? 20.50.09 # I don't remember :\ 20.50.12 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 20.50.26 # I hope no driver letters :) 20.50.37 # C:\rockbox :p 20.50.52 # 20.51.06 # or iirc 20.51.26 Quit n00b81 ("Leaving") 20.51.46 # OK. For Ondio the unmodified FS#9545 has zero ramsize cost 20.51.58 # so those 624 bytes are really all of them 20.53.07 # is this with num_drives*4? 20.53.23 # yes, but done by hand for now 20.53.36 # i.e. #define NUM_VOLUMES 8 20.54.20 # yea, the 600bytes are damn worth it then 20.54.40 # what for? 20.55.09 # pixelma: scroll back a bit 20.56.35 # well... "multivolume options" is a bit too general and I thought someone could give me a short summary instead having to look it up myself... oh. well... :\ 20.56.42 # pixelma: the storage rework patch (FS#9545) has the interesting side effect of making one pool of volumes on a multi-drive device. That means that while on e.g. ondio without HAVE_MULTIVOLUME you have one partition per drive, with FS#9545 you just have two partitions, no matter on which drive, so two partitions on the first drive will hide the second drive 20.57.22 # So one proposal is to just always use HAVE_MULTIVOLUME, and allow 8 volumes. That's the maximum rockbox can handle anyway. The cost of that is 624 bytes 20.58.12 # the YP-S3 LCD init looks quite similar to other LCDs already in rockbox, but there's not an exact match it seems 20.58.30 # on bigmem targets this is a no-brainer I think. The only targets where I'm not entirely sure would be ondio and c200v2 20.58.50 # as if someone would partition a 128MB disk, except accidentally.... ;) 20.59.18 *** Saving seen data "./dancer.seen" 20.59.22 # kugel: any idea how/why using a FM transmitter on an Ipod via IAP can garble the next tag? 20.59.33 # pixelma: there is that :) 20.59.51 # itcheg: No, no idea. I have never worked with any of that 21.00.20 # ok, was asking more from the wps perspective 21.00.33 # itcheg: JdGordon| may have an idea though, he reworked next-track stuff a bit few month ago 21.00.58 # hmm let me double check my wps then 21.01.35 Quit Zarggg_ (Read error: 110 (Connection timed out)) 21.02.03 Join salty-horse [0] (n=ori@bzq-79-178-135-87.red.bezeqint.net) 21.02.16 # kugel: can you tell me off hand if there is anything wrong with this: %s%alNext: %Ia;%t4%s%alNext: %?It<%It|%Fn> 21.02.21 # is there a reason why the clock plugin is so big? (144KB) 21.02.35 # pretty images 21.03.35 # JdGordon|: any idea how next tag can be affected by an ipod accessory? 21.03.59 # that is when used total nonsense shows 21.04.13 # no idea 21.04.28 # are you actually changing the track? or just having it connect 21.04.50 # I guess I can file a bug, although I have no idea what info to include to make it usefull 21.04.56 # pixelma: I'm probably extrapolating from how I would behave. I guess you're right, and this won't be a problem anyway 21.06.20 # itcheg: extaclty when is the next track info getting garbeled? always? or only after changing tracks with it? or? 21.06.36 # itcheg: no a new bug report, we have a task that collects IAP bugs 21.07.07 # It's not always have not been able to figure out exactly, but it only happens when I'm using the accessory 21.07.56 # I used the iap patch before it was committed some months back and never had an issue 21.08.15 # JdGordon|: I suspect your playback events 21.08.20 # +wor 21.08.23 # work* 21.08.29 # so not sure if something changed in iap or (more likely?) the whole wps change 21.08.32 # or other 21.08.58 # * gevaerts has seen a garbled next track on his gigabeat F a few days ago... 21.09.12 # ... are you changing the track from the transmitter? 21.10.51 Join mirak [0] (n=mirak@85-169-192-191.rev.numericable.fr) 21.13.15 Join dash32 [0] (n=dash32@p54AB5446.dip.t-dialin.net) 21.15.20 Join _zic [0] (n=user@83-156-153-127.rev.libertysurf.net) 21.18.01 # gevaerts: The volume pool issue already exists in svn 21.18.30 # oh indeed... 21.18.33 Nick eviltroll is now known as evilnick (i=0c140464@gateway/web/freenode/x-bdfd7fa976ec2ece) 21.18.33 # * gevaerts must be blind 21.18.38 # Imo it would be a good solution to limit both the total number of volumes and the number of volumes per drive 21.18.54 # The latter limit should default to 1 imo 21.19.36 # IIUC the targets defines the drive count? 21.19.40 # shouldn't be too hard. Just have disk_mount() stop when it reaches the limit 21.19.59 # oh, volume per drive 21.20.19 Quit mirak ("Ex-Chat") 21.22.00 # hm, this is easier than I expected. Just add an "&& mounted < VOLUMES_PER_DRIVE" to the main for loop in disk_mount() 21.22.45 # amiconn: what do you think about the global number of volumes being limited to just NUM_DRIVES*VOLUMES_PER_DRIVE? 21.22.52 # gevaerts: do you remember "when" you saw the garbled next track? like was it after a track change (auto or manual?) or near begining/end of playlist? or? 21.24.27 # JdGordon|: the garbled one was the last one in the playlist. I restarted playing from a bookmark, but I don't remember if the info was garbled when I restarted, or only a while later. I think it was garbled as soon as it was shown (i.e. just after an automatic track change) 21.25.01 # Or do we need a separate total maximum number of volumes? 21.26.15 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 21.31.42 # JdGordon|: I'm not making invoking any changes from IAP, I'm not sure as to any pattern, I don't think it was end of playlist etc. 21.32.24 Quit Galois ("Leaving") 21.33.04 # I will try and discern a pattern 21.33.58 # it happens a lot but not always 21.34.00 Join nls [0] (n=n1s@cm-84.215.127.139.getinternet.no) 21.35.10 Quit stoffel (Remote closed the connection) 21.35.43 # gevaerts, markun do you remember which id you got from the meizu m6 lcd? 21.36.05 # 0x0154 IIRC 21.36.48 # ok thanks 21.36.55 # * gevaerts can remember this because he spent a long time trying to read that number from a flashing backlight :) 21.37.48 Quit DerPapst ("Leaving.") 21.40.33 # bertrik: this is on m6sl by the way 21.41.45 Join mt [0] (n=mt@41.233.138.250) 21.42.44 # does the iriver g120 have car adapter mode? 21.42.47 # h120 21.43.15 # gevaerts, the LCD I'm looking at now seems to expect 0x1503 back from register 0 21.44.39 # Zagor: the h300 at least starts the OF on AC power if off, dunno about h100 21.45.34 # saratoga: fixp_mult_su() which multiplies a 32-bit number by a 16-bit fraction, won't it be faster if the fraction was represented with 32 bits ? then we could use the values in the library's trig table directly. 21.45.54 # not completely sure if it's really the LCD id, could also be some kind of verification of a previously written data 21.45.55 # nls: starts OF, i.e does not boot into rockbox? 21.46.18 # is it usual for LCDs to have an LCD ID register at address 0? 21.46.54 # how come running time doesnt work on my rockbox h120 atm? 21.47.05 # problem with 3.3? 21.47.09 # Zagor: yes, this is fixed in svn but not present in the official booltoader, still not sure it applies to h100 21.47.19 Join funman [0] (n=fun@rockbox/developer/funman) 21.47.19 # nls: ok 21.47.37 # JdGordon|: before I go crazy testing scenarios can you confirm that this is ok: %s%alNext: %Ia;%t4%s%alNext: %?It<%It|%Fn> 21.48.13 # i see nothing obviously wrong... I thought %s cant go in sublines... but i have no idea 21.49.06 # What happened to sd_disk_is_active()? I'm sure it did exist half a year ago 21.49.52 # weren't the xxx_is_active calls made obsolete with the xxx_idle_notify framework? 21.50.03 # that was the idea 21.50.08 Join kugel_ [0] (n=kugel@e178114251.adsl.alicedsl.de) 21.50.18 Quit kugel (Nick collision from services.) 21.50.20 # anyone know why run timer isnt working on my rockbox for h120? 21.50.20 # it didnt quite work 100% though 21.50.22 Nick kugel_ is now known as kugel (n=kugel@e178114251.adsl.alicedsl.de) 21.50.25 # maybe it was me who removed them now I think about it 21.50.27 # it was working for 5 hours and then it just froze 21.50.42 # i am afraid i damaged something physically in the H120 while modding is that possible? 21.50.47 # ok so I'll add the %s to the subline as well just to make sure... 21.51.11 # Things still call storage_is_active() 21.51.51 # Anyway, I can work around that. I don't need them 21.51.54 # GreatBeaver: yes it is possible to physically damage a player 21.52.06 # thats not what imean 21.52.18 # i mean could the timer have stopped because i damaged something in the player? 21.56.29 # New commit by 03zagor (r21927): Added average score and % cancelled time. 21.56.37 # GreatBeaver: Maybe you could be more specific about what exactly is happening, and use the terms from the manual so we know exactly which feature you're talking about 21.57.23 # Llorean: when you go to system you can see system info, click it and you can see how many hours, minutes, seconds it has been runing 21.57.27 # its been stuck at 0 0 0 21.57.34 # Is the charger plugged in? 21.57.36 # but it was working for 5 hours of time since yesterday 21.57.40 # hmmm yes 21.57.59 # let me try disconnecting 21.58.39 Join w1ll14m [0] (n=54685215@gateway/web/cgi-irc/labb.contactor.se/x-dde9f832bda86e0b) 21.59.07 # cool thanks it works now 21.59.09 Quit LambdaCalculus37 () 21.59.12 # how come it turns off when the charger is on? 21.59.21 # Again, I reference you to the manual 21.59.46 # It should be in there, I hope. 21.59.49 # i did try looking in the manual 22.00.08 # is there a way to use strncpy from a codec (recent changes to svn removed strncpy from codeclib) 22.00.13 # JdGordon|: could you implement a touchscreen region for going to the playlist from wps? 22.00.20 # * bertrik intends to commit FS#10445 - Error in CREDITS (a mis-spelled name) 22.01.23 # Hm, Running Time isn't in the menu 22.01.25 # Er, manual 22.01.37 # GreatBeaver: Running Time is meant to tell you how long it's been running since a charger was last detected. 22.01.39 # Nothing's broken 22.01.45 # oh ok 22.01.52 # w1ll14m: use strlcpy 22.03.37 # kugel: can i call that function like strcpy or do i have to change some? 22.04.46 # New commit by 03bertrik (r21928): FS#10445 - Error in CREDITS 22.05.07 # if you're dealing with proper strings, then no. You also don't have to set the last byte to '\0'. Additionally you can check the return value against the size for tuncation 22.05.16 # w1ll14m: you can check the description on http://www.manpagez.com/man/3/strlcpy/ 22.05.24 # funman, kugel: thanx ;) 22.07.14 # I didn't even notice I added my buildclient in the middle of a build round 22.07.42 # not that it will be any usefull now that the "easy" builds are done 22.09.18 # but the system dealt with it correctly :) 22.10.10 # kugel: to define strlcpy i have to use #define strlcpy ci->strlcpy right ? 22.10.17 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 22.12.22 # FlynDice, is there still need for testers on the sansaAMS SD voltage issue? I applied the pathch from the forums but not sure i did everything required to test it 22.13.38 # what I find a bit weird about this SD voltage issue is that we're lowering the 1.2V CPU voltage, not the 3V peripheral voltage that the SD slot uses 22.16.09 # yeah and from my experience is that i had no issue with my current hard but i do not have lots to test with 22.16.24 # *card 22.16.54 Quit stoffel_ (Remote closed the connection) 22.17.32 # on my e2xxv2 it decreases my runtime from 18 hours or so to 10 22.20.24 Join mc2739 [0] (n=mc2739@rrcs-71-40-9-100.sw.biz.rr.com) 22.22.06 # w1ll14m: yes or you can use ci->srtlcpy directly 22.22.18 # funman: thanx 22.23.10 # there's a bug in the storage rework. It doesn't work properly with sansa+ramdisk 22.24.07 Part salty-horse ("Leaving") 22.24.48 Quit funman ("kde4 sux") 22.27.23 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 22.28.45 # Zagor: In the new build system, how can a client's total time be more than the total time for the build? For example, build round 21928 took 326 seconds, but there are three clients with total times that are higher. 22.29.01 # mc2739: because uploads are done in the background 22.29.50 # Zagor: is the upload counted in the client total, but not the build total? 22.30.08 # exactly 22.30.27 # ah, thanks 22.33.33 Join petur [50] (n=petur@rockbox/developer/petur) 22.37.48 # w1ll14m: you'll need to add strlcpy to the codec api 22.38.40 # nls: thanx, i just found out, i copied strlcpy from plugin.h/c 22.39.04 # yeah that should do it 22.39.20 # what codec needs this btw? 22.39.56 # there is this mikmod patch on flyspray 22.40.14 # ah 22.40.15 # it used strncpy 22.40.28 # also a nice moment to learn a little more about c 22.40.43 # New commit by 03robert (r21929): Add information gleaned from disassembling the main firmware image. Detect lcd type in use. Still no actual output 22.43.08 Join Jaykay [0] (n=chatzill@p5DDC7DFB.dip.t-dialin.net) 22.44.39 # * linuxstb wonders why a codec would need strncpy 22.45.49 # kugel: should be dead simple to add... as long as there is already an ACTION_ for it... 22.46.07 # otherwise is will need a bit of extra work which is why some are missing 22.47.36 # gevaerts: Btw, I observed something USB related on the beast: Since it got USB charging, I cannot use it when it's connected to my hub in rockbox. It works when connecting directly to the laptop 22.48.00 # Bootloader USB works both on the hub and laptop 22.48.08 # hm 22.48.19 # It seems the beast is drawing more than it says (or maybe even more than 500mA) when charging 22.48.39 # The hub doesn't like this - it goes connect-disconnect-connect-disconnect.... 22.48.39 # oh, does your hub have overcurrent protection? 22.48.56 # After a number of cycles, rockbox freezes 22.49.25 # JdGordon|: there is 22.49.41 # so its a 1 line change in wps_parser.c if you want to do it 22.50.04 # gevaerts: Looks like it does, as *should* and uplink port... 22.50.28 # so there are two problems : (a) it draws more than the hub likes (probably), and (b) it freezes after enough connect-disconnect cycles 22.50.35 # yes 22.50.42 # amiconn: well, like so many things it's optional in the USB spec 22.51.25 # It would be good to verify that it's really the charging that causes this 22.52.21 # It is - started happening when charging went in, just that I didn't bother to test different ports until now. Bootloader usb works fine on the hub, and that's what I normally use for updating 22.52.26 # JdGordon|: hm, I'll look into it 22.52.46 # yes, but IIRC charging went in at the same time as USB init rework 22.52.54 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 22.52.56 # hmm 22.53.00 Quit mcuelenaere () 22.55.37 # bah, what did I muck up this time? 22.56.18 # I wondered about the order things happened 22.57.30 # what are the chances that strlcpy will be added to codeclib in the future ? 22.57.54 # w1ll14m: if you can show you need it, 100% I guess 22.59.22 *** Saving seen data "./dancer.seen" 22.59.38 # ah, bad regex 22.59.47 # gevaerts: thanx 22.59.53 # bad is redundant :) 23.00.00 # :) 23.00.07 # regex rocks!1 23.02.45 # there, all green again 23.02.46 # New commit by 03gevaerts (r21930): Allow access to the last sector of the ramdisk as well 23.03.29 # TheSeven: Thank you, I'm not much of a programmer, (can read some assembler) but am fascinated by the project 23.03.40 # woops wrong channel 23.03.49 # itcheg: read it nevertheless 23.03.56 Join faemir [0] (n=faemir@78.33.109.163) 23.03.59 # haha 23.04.48 # * gevaerts can now access three drives on his sansa over USB. Now to do this in rockbox itself... 23.05.03 Join dmb [0] (n=Dmb@unaffiliated/dmb) 23.06.59 Quit itcheg (Ping timeout: 180 seconds) 23.07.39 # gevaerts: ramdisk? 23.07.44 # yes 23.08.00 # easiest way to test multidriver 23.08.08 # Yes, atm 23.08.23 # * amiconn wants to see the tpj port going, and also usb host 23.08.27 # unless it's buggy of course :) 23.08.36 Join r0b- [0] (n=rob@adsl-76-235-176-134.dsl.klmzmi.sbcglobal.net) 23.08.41 # mt: yes that was the idea, but first I wanted to test i using the existing multiply function just to make sure I didn't have any sort of off-by-one errors or similar 23.09.03 # gevaerts: doesn't it start with 0? 23.09.11 # ok according to the hardware info for the E200 the cpu that it uses runs 200MIPS is that accurate? 23.09.14 # some of the speed up will be using the IRAM based trig table in the codeclib, some from the fasted 32x32=64 ASM'ed multiply function 23.09.21 # r0b: no 23.09.29 # whats ir run then 23.09.31 # it* 23.09.38 # 2x80MHz 23.09.43 # I'd think it would be sector 0 to sector MAX-1 (MAX would be 1 too much) 23.09.58 # i know that but im talking in MIPS :P 23.10.02 Quit evilnick ("Page closed") 23.10.04 # MIPS is meaningless 23.10.09 # oh ok 23.10.11 # particularly for ARMv4 23.10.32 # but it can't do 100MIPS anyway no matter how badly you fudge the numbers 23.10.34 # bertrik: ping 23.10.39 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 23.10.43 # thanks saratoga 23.10.48 # kugel: it does, yes. Assume NUM_SECTORS==2, and read(1,1). That's allowed! 23.11.27 # r0b: for codecs and such, number of multiply or multiply-adds per clock is more interesting usually 23.11.57 # kugel: the difference is this "+count" bit 23.12.33 # gevaerts: isn't it an array[NUM_SECTORS]? 23.13.00 # kugel: NUM_SECTORS*SECTOR_SIZE 23.13.24 # start = NUM_SECTORS-1 (the last element of that array), count = 1 would overflow the array 23.13.30 # (1 being a sector) 23.13.35 # i.e. a read(1,1) will read 512 bytes starting from 512 23.14.01 # well another thing is that unless the e200 changed hardware my rockbox says mine has the PP5022C chip 23.14.11 # kugel: work out some examples in the real code, not simplified cases that disregard SECTOR_SIZE 23.14.29 # shotofadds: how hard would it be to release a supported build for the D2 using SD only? it might make more people interested in D2 development if they could use it as a player 23.14.47 Quit dash32 (Read error: 110 (Connection timed out)) 23.14.53 # r0b: I think thats normal 23.15.01 Quit _zic (Remote closed the connection) 23.15.06 # that field is just what the hardware reports its name as I htink 23.15.28 Join dash32 [0] (n=dash32@p54AB6AF3.dip.t-dialin.net) 23.15.29 # r0b-: The PP5024 is basically a PP5022 with tacked-on AS3514, and it reports itself as PP5022 23.15.38 # oh ok 23.15.59 # gevaerts: in the if there's no sector size. 23.16.28 # kugel: no, but in the array declaration there is 23.16.42 # Zagor: Ahem, current build page only has the sources? 23.16.44 # start and count are in sectors, aren't they? 23.16.47 # yes 23.16.50 # saratoga: I've been toying with the idea of a producing such a build to go in the testing forum (I wouldn't necessarily want to call it supported yet). I think it's a good idea, but it'd only be worth it if the multi-driver rework is going to take a long time to complete... 23.17.14 # amiconn: haha, lovely 23.17.17 # kugel: assume an array "char a[64]". Are you allowed to read one byte starting from offset 63? 23.17.35 # shotofadds; which rework is this? i thought the problem was lack of a FTL? 23.17.36 # yes 23.17.41 # 36 clients is quite nice 23.18.05 # you're actually allowing to read from offset 64 too 23.18.10 # kugel: that's basically what's happening here. start+count=64, even if you're 0 based 23.18.11 # amiconn: fixed 23.18.18 Quit jgarvey ("Leaving") 23.18.26 Join Galois [0] (i=djao@efnet.math.uwaterloo.ca) 23.18.30 # i gotta see if i can get my friend to hack my e250 to get video out :) 23.18.40 Quit w1ll14m ("CGI:IRC") 23.18.43 Join w1ll14m [0] (n=54685215@gateway/web/cgi-irc/labb.contactor.se/x-790e25ec920775c8) 23.19.03 # ah, now I understand 23.19.22 # kugel: it's not simple. that bug was there for a reason :) 23.19.36 # hehe 23.19.39 # saratoga: I meant the multi-storage-driver rework (fs#9545) which is needed to provide access to both NAND and SD. 23.19.58 # obviously there's no need for this to produce an SD-only build 23.20.35 # gevaerts: yea, sorry about my confusion. start+count is the end, not the start :/ 23.21.05 # Zagor: I think using total = total/6 + current/6 should work fine enough 23.21.31 # shotofadds: ah ok 23.21.37 # hm well not exactly that, but you get mu point 23.21.48 # moo point ;) 23.21.49 # B4gder: yes :) 23.22.17 # * B4gder might have gotten one too many glasses of wine to be spelling correctly ;-) 23.22.21 # B4gder: who makes http://build.rockbox.org/dist/build-source/rockbox.7z ? it's not updated for the new build. 23.22.27 # gevaerts: looks like we have a similar bug in our sd driver 23.22.35 # lemme check 23.22.53 # http://pastie.org/549926 23.23.06 # (samsa sd driver) 23.23.35 # Zagor: the previous buildmaster.pl script invoked ./mksource after each build round 23.23.43 # kugel: hm, that looks suspiciously similar indeed 23.24.01 # Zagor: present in my ~/rockbox-distbuild 23.24.25 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 23.24.53 # and it looks like this part could actually have dangerious side effects 23.25.50 # B4gder: ok, I'll run it then 23.27.24 Quit stripwax (Read error: 110 (Connection timed out)) 23.28.08 # bertrik: Good news - your Meizu i2c driver is working perfectly on the Nano 2G. 23.28.23 # Zagor: any reason why my build server's directory has 5700 directories in its root? 23.28.38 # linuxstb: Can I pick the first song for audio playback? :) 23.28.43 # saratoga: !! 23.28.44 # they're each small but it seems like this could pretty quickly begin to bog down the file system 23.29.02 Quit bmbl ("Bye!") 23.29.18 # I think perhaps the build client should create more unique dir names, so it can delete them all explicitly each time it starts or restarts 23.29.20 # LambdaCalculus37: It could come soon - I've already located audio codec functions in the diagmode code, and bertrik got sound on his Meizu... 23.29.27 # oh hmm they're pretty old, so maybe this bug has been fixed 23.29.34 # looks like since a week ago they stopped being made 23.29.39 # sorry for the false report! 23.29.43 # saratoga: ah, that sounds good 23.29.54 # linuxstb: Then in that case... 23.30.09 # though amiconn still reports getting some now and again, so B4gders suggestion sounds like a good one 23.31.41 Quit mt (Remote closed the connection) 23.32.56 # Zagor: The buildclient leaks builddir if a disconnect happens during a build. 100% reproducable (didn't have that happen on the latest version yet) 23.33.02 # Zagor: just wondering, if I have a networked file system, can I run the same build dir on multiple machines concurrently or do I need more then 1 checkout? 23.33.21 Quit Galois ("Leaving") 23.33.25 # saratoga: you need one per kernel. the build dir is named after the pid 23.35.13 # amiconn: ok 23.37.23 # gevaerts: this could be a major bug 23.38.09 # if it's crossing banks, transfer is 1 sector too small, i.e. this sector will not be filled with data 23.38.34 # that would provide some interesting data corruption issues 23.38.44 # although, as the same thing happens on reading, this sector should be skipped as well. 23.39.03 # not better... 23.39.18 # i.e. you get whatever was in the buffer 23.39.21 Quit nls ("Lämnar") 23.39.33 # but we would probably handle files created by the of (any music, rockbox itself, due to missing usb) incorrectly 23.40.44 Join Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 23.41.33 # * kugel commits the fix 23.42.03 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 23.42.11 # kugel: were there still known data corruption issues? 23.42.29 Join PaulJam [0] (i=Paule@vpn-3027.gwdg.de) 23.42.57 # well, my fuze functions properly, but it also only has 2GB. I'm not even sure if the 2GB do bank switches at all 23.43.26 # but yea, some people are still reporting fs problems 23.43.42 # amiconn: re: "* amiconn wants to see the tpj port going" - if you are interested in a device, I can give you a unit. The HD is broken, so you would need a hitachi 1.8" drive 23.44.05 # Hmm, not another device with broken hdd. 23.44.10 # :) 23.44.21 # My iPod Photo just ate its drive today :( 23.44.34 # CF mod? 23.44.34 # * linuxstb has a working Elio that I would be glad to donate to anyone.... 23.44.40 # holy cow. rockbox-clip.7z is a whopping 63% of rockbox-clip.zip! 23.44.47 # roolku: you mean there are actually two of those in existence? 23.44.58 # roolku: We should reunite them... 23.45.08 # Same failure as the first drive - starts making *a lot* of noise when accessing certain areas, and becoming extremely slow (basically stalled with myriads of retries) 23.45.13 # you think they might breed? 23.45.17 # I know saratoga mentioned yesterday 7z was more efficient, but I didn't think the difference was this huge. 23.45.30 # gevaerts: and you have the other one of the two Logik Dax(e)s? 23.45.50 # hmm 23.45.52 # pixelma: yes, but those have cousins, the ATMT-170s! 23.45.57 # Zagor: zip is crap and 7zip is crazy good 23.45.59 # And I'm not using it much - that is certainly not due to mechanical stress 23.46.12 # gevaerts: thinking about it again, it > or >= doesn't make any difference 23.46.20 # in this case 23.46.24 # B4gder: we should use 7z for the uploaded targets. it will save us quite a lot of time. 23.46.27 # linuxstb: Iirc bootloader boots, but there is no lcd output yet? 23.46.46 # Zagor: yes, at least if bandwidth is the limiting factor and not the cpu 23.46.47 # for the == case, transfer won't actually change 23.46.50 # Zagor: Do we want to repack on the server? Or wait for rbutil to support 7z? 23.47.03 # (since we tend to often end up with a zip target as the last build despite our efforts to the contrary) 23.47.21 # * amiconn votes for the latter 23.47.28 # amiconn: if it is the same type of drive as the h120, I have a spare 20GB one 23.47.36 # bleh, I forgot about rbutil 23.47.42 # It's a dual platter Photo 23.47.56 # switching to 7z might work as a subtle push on the rbutil team ;-) 23.48.10 # haha 23.48.36 # * gevaerts wants to know why the file browser doesn't want to see his ramdisk 23.48.44 # B4gder, Zagor: Any idea how long repacking would take? The saved upload time might still make up for that 23.48.47 # kugel: when trying to make a H300 build with the custom ui vp v21 patch i get some warnings similar to "apps/gui/list.c:72: warning: implicit declaration of function `printf'" and compiing fails. 23.49.03 # yea, I always forget to take those out :( 23.49.15 # amiconn: it probably wouldn't take very long. it just feels a bit "wrong" 23.49.39 # * B4gder agrees with Zagor 23.49.57 # * gevaerts thinks that providing a transition period would be good 23.50.30 # 7zip could potentially be a bit more inconvenient for the average user (especially if RbUtil doesn't support it yet) 23.50.30 # i.e. make the download links 7z, but make zips for rbutil until there's been a new rbutil for a few weeks 23.50.32 # is it really that many people that install the bleeding edge builds with rbutil? 23.50.35 Quit faemir ("Leaving") 23.50.39 # New commit by 03kugel (r21931): Apply the same fix as r21930 did for the ramdisk for the AMS Sansa driver. ... 23.50.47 # amiconn: Yes, quite a few things work (standard PP) - ATA, most of the buttons (simple gpio). But no LCD. 23.51.19 # amiconn: And I seem to recall it's got a wolfson codec, so the audio driver should be pretty similar to the others. 23.51.27 # yeah 23.51.35 # LCD is 220x176 iirc? 23.51.42 # Yes, I think so. 23.51.46 # * amiconn would expect a pretty standard controller 23.51.49 Quit Zarggg (Read error: 110 (Connection timed out)) 23.52.00 # Do we have access to the OF for disassembly? 23.52.06 # weeh 23.52.08 # Yes, do you want it? 23.52.15 # since when is the front page picking up new commits so quickly? 23.52.36 # * amiconn is interested in both 23.52.38 # kugel: it used to be a cron job, it's a post-commit hook now I think 23.53.04 # gevaerts: no it's still a cronjob, we just run it more often 23.53.09 # ah 23.53.24 # * gevaerts promises to never soread misinformation again 23.53.34 # :) 23.53.45 # the trigger for starting builds is not used for updating the front page 23.54.05 # did you just not bother enough to use a post-commit hook or is it hard to do with the front page? 23.54.18 # gevaerts: what about spreading it though? 23.54.23 # B4gder: it could though. I just added a "roundstart" script which could do just that 23.54.29 # pixelma: I don't know about that yet :) 23.54.33 # yes it could 23.54.46 # but then I'd need to care for starting before the previous ended etc 23.54.53 # kugel: the svn and web servers are different machines, so a post-hook needs to communicate with the www server somehow 23.54.58 # just using a cronjob is much simpler 23.56.47 # gevaerts: I'm massively confused trying to build a sim with the multi-storage patch. LD fails on the D2 sim looking for card_detect_target (referenced at root_menu.c:1100) but e200 sim does not seem to need this. I can't work out the difference :/ 23.57.00 Join Ubuntuxer [0] (n=johannes@dslb-094-220-231-176.pools.arcor-ip.net) 23.57.42 Join tarbo_ [0] (n=me@unaffiliated/tarbo) 23.57.44 # shotofadds: D2 would be multidriver, while e200 would only be multidrive 23.57.54 # Are you working on the patch now? 23.58.05 # If so, maybe we need to coordinate a bit 23.58.21 # no, I'm not changing it at the moment 23.58.32 # ok. I'm safe then