--- Log for 11.03.109 Server: grisham.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 4 days ago 00.02.45 # bluebrother: like me... 00.03.21 # the same as me, I meant 00.04.32 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 00.05.13 Quit bertrik (Read error: 113 (No route to host)) 00.05.20 # kkurbjun: 16kb boundary? 00.05.23 Nick bertrik_ is now known as bertrik (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 00.05.47 # I don't think I paid attention on that 00.06.13 # That's just what I remember from someone else's work, I'm not 100% positive on that. 00.06.14 # any idea for the size? I wasn't sure how big the ttb would be 00.06.48 # IIRC, the ds mentions 4096 entries 00.08.19 # it should just be 0x4000 bytes if I remember correct. I don't remember the exact terminology, but it depends on how you setup the primary and secondary entries. We only use the most basic framing for the MMU so I think we only use/setup the primary entries. 00.08.28 Join Conic_ [0] (n=conicpp@c-75-68-165-66.hsd1.vt.comcast.net) 00.08.57 # if you use more advanced mmu features you need more space 00.08.58 # I just did a half-assed attempt at enabling the MMU on my clip and it still boots ... 00.09.33 # Are we under feature freeze yet? I wanted to commit the common piece of FS#9708 (ATA DMA) which adds nothing unless HAVE_ATA_DMA is defined (except for the FS#9721 which is apparently a bugfix) and probably for Gigabeat S soon (which shouldn't matter). 00.10.05 # jhMikeS: We are 00.10.27 # jhMikeS: Is it a feature, or a bug fix? 00.10.58 # bluebrother (other Germans): wikipedia gives another idea... "Würdigung" but the article is called "Credits (Film)". I'd like to avoid Denglisch though 00.11.24 # rasher: FS#9721 is a bugfix according to dreamlayers which is included in the ATA DMA patch. Other than that, the common portion changes nothing at all. 00.11.26 # err... Credit 00.11.39 Quit __lifeless (Remote closed the connection) 00.11.55 Join __lifeless [0] (n=lifeless@89.20.104.81) 00.11.57 # jhMikeS: if its code thats not enabled yet it should be pretty safe to commit 00.12.22 # jhMikeS: I don't think I'm qualified to have an opinion on that. I was simply stating fact, not trying to be harsh 00.12.25 Join tim__ [0] (n=aoeu@124.93.243.83) 00.12.35 # jhMikeS: If it's not "new features" but rather "fixes and improvements" it's probably fine during the freeze anyway. 00.12.49 # Since gigabeat S isn't technically supported and that bit only affects i.MX31 code specifically, I suppose that's ok, right? 00.13.01 # There's a fine line between fixes and improvements. 00.13.01 Quit tyfoo (Read error: 104 (Connection reset by peer)) 00.13.20 Quit midgey () 00.13.33 # I don't think improvements are appropriate during a feature freeze. But if it's all inactive code, there can hardly be any harm 00.13.47 # Well, the Gigabeat S is still up for debate as including as a release target, isn't it? 00.13.57 # I didn't think that unreleased targets were part of the feature freeze. I've been committing to the MR500 since the freeze. 00.14.18 # kkurbjun: That's fine 00.14.19 # kkurbjun: Targets we aren't releasing aren't part of the freeze. Targets we _may_ release are. 00.14.29 Quit tvelocity (Remote closed the connection) 00.14.57 # ok, that makes sense. (and what I was running under :) ) 00.14.59 Quit Conic (Read error: 60 (Operation timed out)) 00.15.15 # ok, we still _may_ release on Gigabeat S? 00.15.35 # I think so 00.15.58 # jhMikeS: It's almost entirely down to installation now, I believe. 00.16.04 # Whether we can make an installer. 00.16.14 Quit bmbl ("Woah!") 00.16.21 # Or rather, get the installer working in Windows, I guess. 00.16.36 Join Conic [0] (n=conicpp@c-75-68-165-66.hsd1.vt.comcast.net) 00.17.42 Quit Conic_ (Read error: 60 (Operation timed out)) 00.18.32 # Well, there hasn't been much progress on any of the issues - i.e. there's no bootloader released yet, and don't we have a problem with the single-boot bootloader on v1.2 beasts? 00.18.34 Join moos [0] (i=Mustapha@rockbox/staff/moos) 00.18.48 # The beast hasn't even reached "supported" status yet... 00.19.10 # Not looking good for the Gigabeat S 00.19.20 # linuxstb: Well "supported" and "released" have pretty much the same requirements. 00.20.04 # Yes, although "release" should come a period of time after "supported" - to make sure it's ready. 00.20.38 Quit timc`` (Connection timed out) 00.20.39 # Although the beast is quite special, as I doubt "supported" status will suddenly bring lots of new users. 00.20.44 # I'm not sure I see that strong a reason. Especially when it's a case like this where it's been widely used, and we're waiting for the tools, not the build, to be ready for a release 00.21.38 # There's no point debating until "supported" status is reached anyway... 00.21.43 # I think we should not include it in the release and just make it "supported" once the installation is worked out 00.21.52 # I guess I won't add ATA code to support DMA at this point, active or not, unless at least one target uses it though. 00.22.19 # We may as well just say "The Beast is not being released in 3.2" right now, and not even worry about it. 00.22.51 # * jhMikeS wonders if anyone at all ever tested the bootloader padding patch :) 00.22.55 # Llorean: +1 00.23.11 # jhMikeS: There's a bootloader padding patch? ;) 00.23.11 # * someone that actually has the 1.2 issue of course 00.23.14 # yes 00.23.24 # not in FS but on my ftp 00.23.30 # :) 00.23.46 # * linuxstb stops searching flyspray... 00.23.53 # it makes it about the size of the retailos just to see if there's anything to the idea 00.24.16 # Is that a patch to beastpatcher/mknkboot or do you just build a huge bootloader.bin? 00.24.18 # jhMikeS: I would be perfectly willing to attempt to develop the 1.2 issue if you could tell me how to get my computer to see my Gigabeast in MTP mode. :) 00.24.33 Quit amiconn (Nick collision from services.) 00.24.34 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 00.24.42 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.24.42 Quit pixelma (Nick collision from services.) 00.24.52 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.24.55 # http://jhmikes.cleansoap.org/gigabeat-s-padded-bootloader.patch 00.24.57 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.25.48 # Llorean: did you ever install those libUSB drivers? 00.25.57 # Llorean: if you put the gigabeast in recovery mode you should be able to use the updater to version 1.2 (under windows) 00.26.04 # jhMikeS: What libUSB drivers? 00.26.08 # toffe82: Even if the OF won't connect? 00.26.34 # you have problem with usb ? 00.26.57 # Llorean: If OF won't connect, it could be one of those on-board fuses got blown out 00.27.00 # Neither my, nor I think BigBambi's, Gigabeat S will connect in the original firmware 00.27.03 # Windows asks for drivers 00.27.23 # jhMikeS: UMS works fine in Rockbox. But windows demands drivers for it in MTP mode. 00.27.38 # ah 00.27.53 # I have the same problem of usb with one of my S , but going in recovery mode , usb is working 00.28.13 # jhMikeS: It's quite strange. Bigbambi's reporting the same behaviour, and some internet searching seems to indicate it's not Rockbox caused at least. 00.28.21 # toffe82: Okay. 00.28.59 # Llorean: So it just started "doing it" out of nowhere? 00.29.05 # rasher: this snippet should be able to use the forum as a login backend: http://mcuelenaere.pastebin.com/feeb5bad 00.30.12 # Llorean: Hmmm...reinstall WMP? Does it depend upon the host it's plugged into? 00.30.16 Join planetbeing [0] (n=planetbe@ip67-88-206-98.z206-88-67.customer.algx.net) 00.30.33 Quit bertrik ("Leaving") 00.30.49 # jhMikeS: I have a Gigabeat S where the single-boot bootloader fails to work 00.31.26 Quit bluebrother ("leaving") 00.31.32 # perrikwp: you can try the patch out. if that works, we at least have a direction to go. 00.32.34 # jhMikeS: ok I'll try it 00.32.50 # perrikwp: thanks 00.33.19 # mcuelenaere: not bad! Would be nice if we could get the user's badges as well 00.33.40 # jhMikeS: Your patch just adds 12MB of zeros to the end of bootloader.bin? 00.33.44 # oh yes, forgot about that part :/ 00.33.47 Join homielowe [0] (n=homielow@unaffiliated/homielowe) 00.33.47 # linuxstb: yep 00.34.00 # jhMikeS: OK, so that's easy to replicate in beastpatcher. 00.34.06 # BTW is the config class a bad idea? It has the advantage over using defines that trying to change the value is a *syntax error*, whereas attempting to change a define just silently fails 00.34.24 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.34.32 # linuxstb: it uses the linker to add it to bootloader.bin so the CE file is valid 00.34.37 # jhMikeS: we should implement an option to force usb on the S, to fix the problem of a blown fuse , If you remeber, you told me how to do a long time ago 00.34.58 # it will prevent some usb problem 00.34.59 # jhMikeS: I've tried it on two different Windows computers (vista-32 and vista-64) with the same behaviour. 00.35.17 # jhMikeS: I'm not actually *sure* it ever connected in MTP mode. I *want* to say it did, but I'm not certain 00.35.34 # Llorean: How'd RB ever end up installed then? 00.35.40 # jhMikeS: Linux computer. 00.36.07 # ah, so technically it does depend on the host in a way 00.36.25 # you can upload the 1.2 via linux , with sendfirm , no? 00.36.50 # rasher: something like this should do: http://mcuelenaere.pastebin.com/f68f28dcf 00.36.57 # toffe82: Does that do a full update? I thought there was also a file that gets flashed? 00.37.01 # jhMikeS: It depends on the host OS I guess. But BigBambi reported XP didn't work either. 00.37.06 Quit ender` (" But there, everything has its drawbacks, as the man said when his mother-in-law died, and they came down upon him for the f") 00.37.20 # toffe82: yeah, I recall. That patch wouldn't apply but could be synced. 00.37.21 # rasher: I don't think the config class is a bad idea, you're using the OO principal anyway.. 00.37.30 # linuxstb: perhaps you are right 00.38.05 # jhMikeS: it would be nice, we just have to decide what would be the key to press to force it on and off 00.38.36 # mcuelenaere: Did you ever look at beastpatcher again, or is your version still not compiling? 00.38.42 # mcuelenaere: it does have the disadvantage that the value must be completely static. It can't be computed (1000*1000 doesn't work, 1000000 does) 00.38.49 # So it makes things a bit awkward 00.38.51 # toffe82: You mean just the bootloader right? I'm not sure what would be acceptable in the firmware. 00.38.55 Join Martyn [0] (n=martinb@63.98.100.163) 00.39.04 # linuxstb: no, I haven't looked at it since I tried using MingW + VS 00.39.12 # (it did compile, but it didn't run) 00.39.32 # jhMikeS: I think it was in the bootloader 00.40.00 # but it should be also in the firmware if not you cannot connect 00.40.06 # toffe82: It was, yes. I was wondering if you wanted a way to force it within the firmware. 00.40.16 # rasher: oh, I didn't know that. Isn't the PHP compiler smart enough to do const bleh = (100*10); -> const bleh = 1000; ? 00.40.16 # toffe82: What's this problem? 00.40.25 # fat32 filesystem check works. Where should I post the availability of the plugin? 00.40.52 # It won't format a card, yet, but I can at least check fat32 fs and make sure it's not broken 00.40.57 # * jhMikeS wonders about just ordering fuses from digikey and fixing the board :) 00.40.59 # linuxstb: IMO I think the DLL-way seems the best option (and you could pack it in the executable if you really wanted to have one file) 00.41.11 # linuxstb: a fuse must be blown on one of my S and it didn't connect in the OF , but it works in recovery, because recovery force the usb to wait 00.41.12 # s/IMO// 00.41.15 *** Saving seen data "./dancer.seen" 00.41.28 # toffe82: And it doesn't connect in Rockbox either? 00.41.34 # jhMikeS: I didn't find the fuse ;) 00.41.59 # and it is easier by software, so if somebody has the same problem... 00.42.11 # Martyn: Post a patch to the patch tracker. 00.42.12 # toffe82: weird, they sell the I-sense resistor and other parts 00.42.20 # linuxstb: I don't remebrer but I think not 00.43.22 # it would be nice to say , use rockbox to fix your broken S :) 00.44.26 # mcuelenaere: How would you pack it in the executable? I don't care how it's done, but a single .exe would be nice... 00.44.43 # * rasher thinks a filesystem checker is more useful than a formatter 00.44.50 # we can do any key combo so some hard to do by mistake keypress is possible 00.45.13 # rasher: Assuming it repairs as well? 00.45.13 # the window key :) 00.45.15 # linuxstb: by using the same principal as Self-Extracting executables do? 00.45.27 # * mcuelenaere isn't yet sure how to do it, but he knows it is do-able :) 00.45.38 # ;) I thought you knew of a tool to do it... 00.46.06 # and then you could dynamically load the DLL in the exe 00.46.29 # it is a bit ugly, but it should work 00.46.33 Quit BigBambi ("No Ping reply in 30 seconds.") 00.46.53 # toffe82: a new key to replace that would be nice as well (a custom rockbox logo key :) 00.47.02 # :) 00.47.49 Join BigBambi_ [0] (n=alex@152.27.192-77.rev.gaoland.net) 00.47.51 # we need a key to connect and disconnect 00.48.02 # mcuelenaere: A quick google just shows methods that write the .dll to a temporary file on disk... 00.48.19 # yeah, I was thinking something like that 00.48.22 # using bin2c 00.48.51 # I'm not sure whether that bloats the executable (in RAM) much though 00.48.56 # linuxstb: Will do 00.49.06 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 00.49.14 # toffe82: 3 keys or two? (back+menu+volup)? 00.49.18 # mcuelenaere: I don't think that matters much - beastpatcher is tiny (and so is that dll) 00.49.27 # probably 00.49.36 # jhMikeS: and the 380 00.49.40 Join Conic_ [0] (n=conicpp@c-75-68-165-66.hsd1.vt.comcast.net) 00.49.41 # vsoory 00.50.17 # 380? ?? 00.50.23 # jhMikeS: how do you do it with one hand while plug in 00.50.23 # I don't think we should have a key combination in the main build with a purpose of solving broken hardware issues. 00.50.31 # wrong windows ;) 00.50.55 Quit mcuelenaere ("Gnight") 00.51.16 # jhMikeS: do I need to use sendfirm to upload the new nk.bin or can I just replace the current nk.bin in the TFAT partition using Rockbox USB? 00.51.19 Quit Conic_ (Client Quit) 00.51.25 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.51.50 # Did the current sansa build work? 00.51.56 # perrikwp: Just dump it in there with USB. 00.52.13 # jhMikeS: ok thanks 00.52.18 # jhMikeS: Is that a fair test? Wouldn't it be better to use sendfirm? 00.53.00 # Martyn: you know that you can check the build table, here: http://build.rockbox.org/dev.cgi right? 00.53.05 # linuxstb: makes no difference to tell whether the bootloader actually functions 00.53.31 # n1s : Oh! no didn't know :) 00.53.44 # n1s : I have a script that tries to get the build every day, and I saw it failed. Thanks :) 00.54.21 # Llorean: do we know if this problem happened on other target ? 00.54.59 # n1s : Ah, and I see the bright red 'ld' on the chart :) thanks, this will make my life a lot easier. 00.55.07 # toffe82: It's still a hardware problem. Maybe a #define so it's easy to compile for, but we shouldn't put aside a button combination (even a complex one) to deal with issues only on damaged targets. 00.55.15 # if someone *does* accidentally trigger it, they will think they have a bug. 00.55.47 # we can change the usb screen sprecailly for this case 00.56.08 # That's even more additional code unnecessary for people with unbroken units. 00.56.18 # yes 00.56.25 Join midgey|web [0] (i=8dd5376f@gateway/web/ajax/mibbit.com/x-29256aceb54eabee) 00.56.37 # * amiconn agrees with Llorean 00.56.57 # Plain rockbox shouldn't contain code for working around defective hardware 00.56.59 # it's a fairly trivial task from the bootloader but not so much in the firmware 00.57.01 # you say this until you will have the problem :) 00.57.04 # I just don't think we should have code for broken hardware compiled in by default. I see no problem with having it ifdeffed out so people with the hardware issue just need to define something to get it available. 00.57.24 # toffe82: If I had the problem, I'd have no problem changing a #define in config-gigabeats.h 00.57.28 # jhMikeS: didn't work, says firmware upgrade or restoration required after attempting to boot 00.57.35 # I already compile my GigabeatS build with a different plugin buffer size 00.57.46 # People still wanting to use such units can always make their own build, thanks to opensource 00.57.51 # Llorean: I am thinking about people who are not programmer 00.57.56 # perrikwp: Thanks. Interesting, I wonder just what it does expect. 00.58.21 # toffe82: A #define doesn't require any programming knowledge. You can be told how to do it fairly simply. A tutorial could be made. 00.58.37 # yes 00.58.39 Quit Conic (Read error: 110 (Connection timed out)) 00.58.55 # toffe82: If you really feel dedicated to these people, you could provide an unsupported build in the forum for them, so they don't have to compile at all. 00.58.58 # If we start doing such stuff, it'd be hard to tell where to stop. What about partially broken LCDs? Do we need to support adjustable margins because of those? 00.59.24 # jhMikeS: the single-bootloader unpadded works for first boot but the second reboot onward it doesn't, if that helps any 00.59.25 # amiconn: What about buttons that die easily (sticks), do we need to make backup control sets for players with wobbly sticks? 00.59.43 # toffe82: How common is this issue then? And what's the actual workaround? 00.59.50 # Yeah, you'll probably find many more examples 00.59.52 # amiconn: it is more difficult in the case of the lcd , because you don't know how it is broken 00.59.56 # Llorean: that's already in the gigabeat fx (keypad sensativity 01.00.14 # kkurbjun: That's not a broken hardware workaround. 01.00.42 # yes it is, at least on mine high sensativity causes erratic button behavior 01.00.49 # linuxstb: I had one lwith this problem from 6 or 7 Ibought 01.00.55 # I thought that was why it was made an option 01.01.16 # it is not really a common problem 01.01.18 # the problem is that the front plate can get depressed and cause problems 01.02.07 # kkurbjun: The high sensitivity can also just be very difficult to use for people with larger fingers trying to press center. 01.02.07 Quit planetbeing () 01.02.11 # It's like adjustable scroll speed. 01.02.17 # There is no one option that _can_ suit everyone. 01.02.37 # I remember 2 person having usb problem on the F , but I don';t know if this ca n fix it 01.02.46 # perrikwp: does the dual-boot require booting into the OF as well first to work or is it possible to never boot into retailos? 01.02.57 # :), ok, so it's justified 01.03.29 # I have to go.... bye 01.03.34 # perrikwp: I'm wondering if the presence of those .edb files and others matters 01.03.38 Part toffe82 01.04.43 # jhMikeS: I'm not sure I follow your question, could you rephrase it? 01.05.42 # perrikwp: Retailos creates a bunch of other files but only if you boot into it at least one. I was wondering if the presence of those files makes the difference. 01.05.50 Quit n1s ("Lmnar") 01.06.33 # But if you dumped the bootloader in from a working install, that seems to indicate that it doesn't. 01.07.02 # let me restore the OF, then try the padded single-boot loader again 01.07.18 # jhMikeS: hi, I remenber that when I encountred "File not found" problems with my beast, at 100% of cases, those OF files wasn't created, but I remenber to already pointed you this :) 01.07.54 # moos: I've gotten that one myself many times and it's the reason the untar code is still there :) 01.08.11 # moos: Maybe the problem is that Rockbox doesn't like "virgin" TFAT partitions, but once the OF writes to it, it's OK? 01.08.23 # when the OF dirs/files wasn't be created, I was sure that rockbox will refuse to boot even when you advise me to create the dirs with th fles... 01.08.58 # * linuxstb had that problem once, and thinks he did boot into the OF (after a recovery) and that got it working again 01.09.18 Quit Reptile211 ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]") 01.09.54 # linuxstb: those weeks I have no more beast (hope to get it back very soon). I tried laot of time in different configurations, but I remenber that the crapyness was the "random" bit :( 01.10.35 # jhMikeS: even after untaring, rockbox said me "File not found" 01.10.57 # * moos thinks we need to get ride of OF totaly :) 01.11.00 # linuxstb: I've had it happen many times where the first time a file is created, even in rockbox it can end up lost. But after the first time, it seems to not fail again. 01.12.31 # but imagine this OF format the thing even if you don't want so 01.13.06 # jhMikeS: ok reloaded OF, ran it once, used sendfirm to send padded single-bootloader, still didn't work 01.13.44 # That happened to me one time when our USB wasn't 100% reliable, and after USB deconection, BOUM stack overflow on rb folowed by the OF formating process 01.14.04 # Is it possible to downgrade a 1.2 beast back to 1.1? 01.14.27 # linuxstb: I think so, why not? 01.14.47 # perrikwp: hmmm...it wats something fancy. it must check the actual nk.bin image for something beyond a valid format. 01.15.29 # moos: Where would you get the files from? I thought there was more to it than just an nk.bin (i.e. what gets flashed) ? I may be wrong though.,.. 01.15.41 # jhMikeS: maybe some checksum or key? 01.15.48 # Were any of these 1.2 beast previously 1.1 beasts that didn't complain about single boot? 01.15.56 Quit Wraith| (Read error: 110 (Connection timed out)) 01.16.30 # perrikwp: Do you have a v1.1 nk.bin you can restore? Or have you tried that? 01.16.35 # perrikwp: Perhaps it expects certain sections to be present that the single boot bootloader doesn't include? 01.16.45 # linuxstb: maybe...in my mind that is the same process with a nk.bin then the ability to recover and then get back to 1.1, but I must be wrong 01.17.05 # amiconn: custom list would be handy for partially broken lcds 01.17.21 # * moos is frustrated to not have his beast currently :( 01.17.40 # it's "how to we support broken hardware" day? 01.17.56 # jhMikeS: I no longer have the original v1.1 restore cd, otherwise I would have tried that 01.18.53 Quit Thundercloud (Remote closed the connection) 01.21.12 # There was a restore CD? 01.21.52 # jhMikeS: how hard it will to do the same flash rewriter as gigabeat F/X? http://www.rockbox.org/tracker/task/7505 01.22.01 Quit jhMikeS (Read error: 104 (Connection reset by peer)) 01.22.03 # mine came with some v1 software cd, but I threw it out 01.22.08 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 01.22.16 # jhMikeS: how hard it will to do the same flash rewriter as gigabeat F/X? http://www.rockbox.org/tracker/task/7505 01.22.43 # I don't know if it contained restore software or not 01.23.45 # moos: I have no idea. I don't have any means at hand to unbrick it. 01.24.23 # no BDM or something to debugg resurect it? 01.25.06 # nope 01.25.17 # or JTAG 01.25.30 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 01.25.38 # none of that on hand atm 01.26.02 # * moos thinks that we can at least offer you one beast for experiments :) 01.26.41 # perrikwp: If it was the same as mine, the CD just contained WMP10 01.26.51 # oh ok 01.26.59 Join z35 [0] (n=z35@h184.121.88.75.dynamic.ip.windstream.net) 01.27.47 # any idea's on where I could find a v1.1 nk.bin legally to test it out? 01.28.30 # * linuxstb PMs perrikwp 01.33.19 Quit MethoS- (Remote closed the connection) 01.36.38 # jhMikeS: would I have to use recovery mode to downgrade 1.2 to 1.1 or just use sendfirm during a normal MTP transfer in the OF? 01.38.49 # perrikwp: I can't imagine it should matter unless the recovery mode is capable of doing something simply sending a file won't do. 01.41.29 # jhMikeS: ok loaded v1.1, confirmed it booted up and changed, re-tried the padded single-bootloader, still a no-go 01.42.42 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 01.43.02 # I can't see why the nk.bin version would matter unless it would change the flash code 01.43.56 # jhMikeS: maybe something was flashed during the v1.2 upgrade and simply changing the nk.bin version doesn't matter 01.44.57 # jhMikeS: O well, I guess there is not much more I can do to help, I guess I will have to stick to using the slow dual-boot bootloader 01.50.52 # perrikwp: that's what I've wondered about and whether a previously well behaved beast "turned bad" 01.51.08 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-88f695c1cc6fbb7a) 01.51.15 # but thanks for testing this stuff out 01.52.09 # your welcome 01.58.40 Join vertic39 [0] (n=email@dslc-082-082-043-138.pools.arcor-ip.net) 01.59.06 # hey still someone here? I rockboxed my Ipod but now the original firmware suddenly booted - what did I wrong? 02.01.21 # lmao .. I did a combination ... accidently .. lol 02.03.52 Join vertic23 [0] (n=email@p4FDE2F5D.dip.t-dialin.net) 02.04.34 Quit vertic39 (Read error: 104 (Connection reset by peer)) 02.05.47 # jhMikeS: i've manage to "break" single-boot on my beast by upgrading. i don't think a downgrade is possible, as we don't have an installer for the whole thing, and it's probably a pre-boot flash bit that validates the on-disk firmware 02.06.31 Quit awake_ (Read error: 104 (Connection reset by peer)) 02.07.14 Quit moos ("Time to catch some sleep") 02.07.20 # it's kind of spotty, installing a single-boot firmware might let me get through the bootloader itself a few times, but seems to trigger restore if i actually install and run rockbox 02.09.31 Quit tim__ (Read error: 104 (Connection reset by peer)) 02.09.35 Join tim__ [0] (n=aoeu@124.93.243.83) 02.09.52 Quit Hadaka (Read error: 60 (Operation timed out)) 02.10.44 # hmm I can't get rid of the original firmware 02.11.16 # I am doing it exactly as told... first hold on hold off ... then play + middle button... 02.11.52 Join moredhel [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 02.11.55 # vertic23: if you have the newer OF boot flash, i'm not sure we know a way for you to get *rid* of the OF yet 02.12.16 # rockbox is installed 02.12.25 # but I pressed some buttons :P 02.12.35 # and then the original firmware bootet... accidently 02.12.59 # and it were... unfortunately the right combination I pressed :P 02.13.03 # to load original firmware 02.14.33 # to load the OF, you simply need to have the hold switch on while booting, if you've installed a dual-boot RB bootloader. 02.15.12 # well I want my rockbox back ;D 02.15.16 # you *can* turn the beast on while the hold switch is on, by the way - it will load the OF and then go to sleep 02.15.36 # Unhelpful: I must say I almost had a psychic premonition of exactly this sort of thing happening and resolved never to upgrade it :) 02.15.37 Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 02.15.52 # Unhelpful: so what am I doing wrong now? I don't get the point 02.15.53 # :P 02.16.18 # you'll need to get a pin or paper clip and turn the battery switch off while it's unlpugged, since you can't turn the OF "off" with the buttons 02.16.31 # then turn make sure the hold switch is off, and turn it on 02.16.44 # aight 02.17.37 # it's dark where is the switch ;P 02.17.40 Join tmzt_ [0] (n=tmzt@adsl-76-253-134-255.dsl.akrnoh.sbcglobal.net) 02.18.04 Join soap_ [0] (n=soap@cpe-76-181-69-157.columbus.res.rr.com) 02.18.08 Quit perrikwp (grisham.freenode.net irc.freenode.net) 02.18.08 NSplit grisham.freenode.net irc.freenode.net 02.18.08 Quit avis (grisham.freenode.net irc.freenode.net) 02.18.08 Quit tmzt (grisham.freenode.net irc.freenode.net) 02.18.08 Quit soap (grisham.freenode.net irc.freenode.net) 02.18.08 Quit Slasheri (grisham.freenode.net irc.freenode.net) 02.18.08 Quit jon-kha (grisham.freenode.net irc.freenode.net) 02.18.12 # Unhelpful: it can't be excessively picky since it allows the bootloader to be present. I just wonder what aspect needs to be mocked for it to pass. 02.18.19 NHeal grisham.freenode.net irc.freenode.net 02.18.19 NJoin perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-d5bd2766e6fc94bc) 02.18.19 NJoin avis [0] (n=ident@pdpc/supporter/student/avis) 02.18.19 NJoin tmzt [0] (n=tmzt@adsl-76-253-134-255.dsl.akrnoh.sbcglobal.net) 02.18.19 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 02.18.19 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 02.18.35 # i'd love to know, i want dual-boot back ;) 02.18.35 Join Naked [0] (i=naked@naked.iki.fi) 02.18.41 Quit tmzt (Connection reset by peer) 02.18.46 Nick Naked is now known as Hadaka (i=naked@naked.iki.fi) 02.18.52 # Slasheri: i understand you're the one to pester with tagcache questions? :) 02.18.58 # ...well so I reinstall rockbox is the fastest, right? :P 02.19.04 # Unhelpful: I thought you needed single-boot, not dual :) 02.20.34 # jhMikeS: well, it'd be nice if the player could not get into needs-a-paperclip state with it turned off and the lock switch engaged. yes, single-boot is what i'd like to get back, but the *whole* point was to see if it was the upgrade ROM that was the trouble, and to have a guinea pig beast handy that's "broken" 02.21.12 # vertic23: why would you need to reinstall? you only *started* the OF, unless you've gone and loaded the OF nk.bin again. 02.21.23 Quit moredhel (Read error: 60 (Operation timed out)) 02.21.50 # well-- wahhhhh what to do? 02.22.05 # it's dark can't look for tools or sumthing my gf is sleeping 02.22.10 # and I need music ;P 02.23.17 # in the FAQ is written I need to reset the ipod (video 30GB) like it said on the apple page.. 02.23.29 Quit miepchen^schla (Read error: 110 (Connection timed out)) 02.23.51 # Unhelpful: Needs-a-paperclip state? What's this? I think we're talking about two different players here. :) 02.24.13 # I go and reinstall rockbox now :E 02.24.19 # maybe the installer is helping me... 02.24.22 # will it? :P 02.24.27 # jhMikeS: the OF will start with the hold switch engaged - it immediately goes to sleep. you can't get back without a paperclip. :/ 02.24.40 # vertic23: you really just need to turn it off, as i explained. 02.24.52 # read above .. no tools here 02.24.53 # on a beast? 02.25.04 # and I don't find the hole 02.25.25 # jhMikeS: yes. or at least, it's done so for me in the past 02.25.45 # c'mon.. will the installer help me? 02.27.05 # yes / no / maybe 02.28.15 # * jhMikeS votes "maybe yes, maybe no" (since he has no idea) 02.28.16 Quit arohtar (Read error: 110 (Connection timed out)) 02.28.29 # vertic23: if you load the bootloader again, the OF should reboot, probably. 02.28.36 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-7c312f4eeb07e53f) 02.29.11 # ...load the bootloader again - in "steps" this means?? 02.30.57 # youre name sticks to ya :P 02.32.38 # took 10 seconds 02.32.45 # to restore the bootloader with the utility 02.32.46 # ^^ 02.32.55 # :P 02.33.26 # to restore the bootloader that never even needed restored. i told you what i knew would work, i can't tell you if something you guessed at will work. 02.33.56 Quit faemir (Connection timed out) 02.34.19 # jhMikeS: yes, on a beast, i just tried it again... power off, hold switch engaged, press the power button and it boots into the OF, then sleeps. 02.34.56 # Unhelpful: And plugging the charger or USB won't kick it back up? 02.35.40 # it's asleep, not off. if you plug it in or whatever, the OF wakes up. you have to flip the battery switch, while it's not plugged in, to turn it off 02.36.04 # heh thx anyways 02.36.07 # finally music 02.36.25 # the fact that this can happen while the unit is off and locked is quite possibly *more* annoying than the longer load time on dual-boot 02.36.39 # Unhelpful: what you describe sounds normal 02.37.12 # "Hold" *really* shouldn't be the OF trigger on the beast. 02.37.28 # i didn't mean to imply it wasn't, only to say that it's pretty annoying 02.37.34 # "Hold" should probably just enter a 'charging' mode if a charger is inserted, and USB mode if USB is inserted 02.38.10 # Llorean: Unless we reverse the loading (which requires a "single boot" bootloader btw), there is no other switch avaiable without keypad port scanning. 02.38.35 # jhMikeS: Is there a reason we can't scan for the actual buttons? 02.38.47 # Right now it's very easy to plug it into a car charger, and get stuck in the OF until you're home. 02.39.08 # Perhaps not but the included code would have to have much of the code that button-imx31.c has 02.39.50 # I'd rather see that, than a bootloader that can allow you to accidentally make Rockbox unusable when you try to charge it. 02.39.59 # But that's personal opinion 02.40.05 # I'm afraid to turn on the hold switch now, basically. 02.40.09 Quit gevaerts (Nick collision from services.) 02.40.21 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 02.40.45 # i rather like the idea of the rb boot being able to chain-load the OF nk.bin, but i'm not sure how big a mess that would really be 02.41.19 *** Saving seen data "./dancer.seen" 02.43.05 Join Strife89 [0] (n=nds@204.116.244.200) 02.43.35 Nick tmzt_ is now known as tmzt (n=tmzt@adsl-76-253-134-255.dsl.akrnoh.sbcglobal.net) 02.43.52 # Unhelpful: Perhaps the bootloader embedded with the OF could actually have a section outside the normal bootloader execution. I think I just got an idea. Have that stub code call some other code on the side and run OF depending on what gets returned. 02.45.16 Quit midgey|web ("http://www.mibbit.com ajax IRC Client") 02.48.32 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 02.48.42 # kkurbjun: yo.. nice work! 02.50.07 # :), thanks 02.50.25 # it's nice to actually hear sound from this thing 02.50.36 # how unstable is it? i dont have mine back yet so i cant play 02.51.15 # I'm not sure what is causing the problem it just resets when I try to play music.. it never plays and then when I start pressing buttons rockbox resets 02.51.29 # but doom, rockboy and the sound test all work fine 02.52.13 # the cube demo is messed up too, so I think something may not be initialized right when the player is started up 02.53.34 Join sbhsu__ [0] (n=a6530466@Zion.dorm.au.edu.tw) 03.05.20 # kkurbjun: ams sansas reboot too on mp3 03.05.31 # at least those that don't have the codecs in iramn 03.05.33 # iram* 03.06.12 Join midgey [0] (n=tjross@71.238.148.140) 03.06.31 Quit sbhsu (Read error: 110 (Connection timed out)) 03.06.35 Quit sbhsu_ (Read error: 110 (Connection timed out)) 03.06.40 # Speaking of Sansas, are there any notable differences in charging with Rockbox versus the OF? 03.07.25 # kugel, hmm, do you know the reason for the reboot? 03.07.41 # My c250 is 19 months old and the battery is showing its age. 03.07.47 Quit Nico_P (Remote closed the connection) 03.07.54 # Possibly prematurely. 03.08.30 # kkurbjun: No, no idea 03.08.39 # Strife89: Is it charging differently in the OF than in Rockbox? 03.09.08 # Well, that's what I'm trying to find out, Llorean. 03.09.56 # Strife89: Isn't that done by charging it a few times in each and comparing the results? 03.10.04 # I'm wondering if it's just me and my charging habits or if Rockbox has a role in my battery's aging. 03.10.20 # I'd say "it's been in use for nearly two years" has a significant role in its aging. 03.10.44 # Lithium based batteries are hardly immortal. They're expected to lose a measurable amount of their capacity each year. 03.11.06 # A not-insignificant amount either. 03.11.27 # Mainly, I've noticed that the highest the battery goes dropped from 94% to 88% over the last two weeks. 03.12.21 # And has the weather changed? 03.12.47 Quit nuonguy ("This computer has gone to sleep") 03.12.47 # Different humidity and temperatures can cause this sort of thing. As well, it may just be inaccuracies in the measurements. Has runtime changed significantly too? 03.12.55 # This is based on charging with Rockbox, unplugging and powering off at 100%, then reading the level at next power on. 03.13.22 # Llorean: Yes, it's gotten cold, then much warmer recently. 03.13.52 # Full runtime I have not measured. 03.13.58 Join Taylor_ [0] (n=Taylor@c-24-91-82-205.hsd1.ma.comcast.net) 03.15.01 # Hello everyone. Just a quick question - are the Sansa fuzes' supported yet? (And I only ask as a devlopment need, not because Im trying to be a pain :) ) 03.15.14 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]") 03.15.15 # Taylor_: They would be listed on the front page if they were. 03.15.36 # Ok 03.15.46 Quit Tristan ("changing servers") 03.15.54 # I just heard some "rumblings" on the forums, so thats why I was a little mixed up. So thanks 03.15.54 # Llorean: I'll do a battery bench or two in the near future. 03.16.07 Join kugel [0] (i=kugel@rockbox/developer/kugel) 03.16.32 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 03.17.31 # Taylor_: don't worry. We will announce it when it happens. So just have patience, and please just read the front page. Rumors in the forums are often (usually) just people misunderstanding something. 03.17.41 # Also, much as I hate it, I'll probably see what happens after I charge with the OF. 03.18.53 # Ok thanks. And as I said, Im not trying to be a pain :P I just need one of these target mp3 players for my project 03.19.04 Quit Strife89 ("To bed.") 03.19.14 # Taylor_: You could always work on it. It's never going to happen if people keep sitting around hoping someone else will get the work done. 03.19.34 # Well I am going to. Thats why I asked :) 03.19.53 # I might get one in the near future. 03.20.09 # Wanted to make sure it was "un-hackable" to work on! 03.20.31 # I don't even know what you mean by that. 03.21.09 # Umm.. Basically I wanted to know which Sansa was __Unhackable_ 03.21.16 # I want to work on that 03.21.19 # None of them, so far. 03.21.26 # If they were unhackable, we couldn't put Rockbox on them. 03.21.41 # Yes; the fuze :) 03.21.59 # There's a pretty significant difference between "no Rockbox port is completed" and "unhackable" 03.22.06 # Unless you mean "not yet hacked fully" 03.22.17 # Hmm 03.22.42 Quit jhMikeS (Nick collision from services.) 03.22.44 # just a little confused. I don't care if the fuze has been "sort of hacked" or "fully hacked" 03.22.48 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 03.22.55 Join Llorean1 [0] (n=DarkkOne@c-98-200-198-144.hsd1.tx.comcast.net) 03.23.10 # So im guessing code has been run on the fuze then? 03.24.10 # Any and all work done should be discussed either in the forum thread or the wiki page. I personally don't know the status, I can never remember which CPU is in the Fuze and which in the View 03.24.25 # But I'm *fairly* certain the Fuze is the AMS one, which would mean yes, if it is, code has been run 03.24.32 Quit Llorean1 (Client Quit) 03.24.58 # OK 03.25.03 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 03.25.09 # well, Im sure I will like to work on it 03.25.31 Join Llorean1 [0] (n=DarkkOne@c-98-200-198-144.hsd1.tx.comcast.net) 03.25.42 # Generally, "unhackable" would mean to me "cannot be hacked" 03.25.47 # I have some Staples money hanging around an Im pretty sure they sell Sansa's :) 03.25.51 Quit Llorean (Nick collision from services.) 03.25.56 Nick Llorean1 is now known as Llorean (n=DarkkOne@c-98-200-198-144.hsd1.tx.comcast.net) 03.26.36 # 2G refurb fuzes at Newegg 03.26.52 # whoops $30.00 03.28.27 # Unfortunately when we dumped the contents of the chip on the 2g, it was utility flash and not the Bootrom. So we didn't get anything much useful other than more encrypted data! 03.28.49 # (Im talking about the 2g nano) 03.40.36 Join midijunkie [0] (n=Miranda@pD9545B04.dip0.t-ipconnect.de) 03.56.41 Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) 04.11.43 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 04.11.48 Join timc`` [0] (n=aoeu@124.93.243.83) 04.12.59 Quit midijunkie ("?(???~~)?") 04.14.24 Quit tim__ (Connection timed out) 04.15.09 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]") 04.17.25 Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 04.17.50 Quit blkhawk (Read error: 60 (Operation timed out)) 04.19.36 Quit Tristan ("changing servers") 04.21.41 # JdGordon, I just got mp3's playing! 04.21.52 # It was just a problem with the codec linker script 04.22.14 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 04.22.33 # nice job! 04.22.50 Quit Tristan (SendQ exceeded) 04.23.35 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 04.24.11 Quit Tristan (SendQ exceeded) 04.24.50 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 04.25.13 Join blkhawk [0] (n=blkhawk@f051166017.adsl.alicedsl.de) 04.25.21 Join AndyIL [0] (i=AndyI@212.14.205.32) 04.25.26 Quit Tristan (SendQ exceeded) 04.25.56 # kkurbjun: nice 04.27.02 # I'll commit it in a bit, but it's working really well. Skipping tracks back and forth causes some sound glitches when it's skipping, but I'm pretty sure it's because the DMA transfers never stop right now 04.27.03 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 04.27.33 Quit Taylor_ ("Leaving") 04.29.04 Quit sbhsu__ (Read error: 110 (Connection timed out)) 04.31.40 # kkurbjun: hows the touchscreen? ill try to work on that when i get mine 04.32.21 # theres a c4000 dsp core on the mrobe 500 right? 04.32.28 # It's just using up, down, left, right and select now. It doesn't select items from lists like it used to 04.32.44 # yeah, it's a c5409 I think 04.32.58 # oh, what did you decide to d about the binary file? just commit it as it? 04.33.13 Quit Tristan ("changing servers") 04.33.23 # It's actually suppisingly easy to program for, I have to thank Cat for doing the initial legwork on it though 04.33.33 # yeah, it's a binary file that's in SVN 04.33.50 # kkurbjun: does rockbox do anything with the DSP? 04.33.51 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 04.33.55 # if you do a normal build from the latest checkout you won't have to compile the dsp code 04.34.02 # ok, greayt 04.34.09 # nice work, im heading out now 04.34.43 # saratoga: yeah, it uses it to control the DMA transfers from the SDRAM to the DSP memory and then another transfer from the DSP memory to the McBSP (IIS) interface 04.34.57 # this is done in assembly? 04.35.28 # no, it's written in C, TI released a version of their compiler for linux thanks to neuros 04.35.43 # it is setup so that you can use it in "open source" projects 04.36.04 # http://open.neurostechnology.com/node/1020 04.36.08 # kkurbjun: do you need the TI compiler installed to build for the mrobe then? 04.36.44 Quit AndyI (Read error: 110 (Connection timed out)) 04.36.58 # no, you can build without the TI compiler, initially Cat and I were talking about integrating the DSP code build with the main build, but since we only have a linux compiler it would mess up cygwin devs and the like 04.37.21 Part Martyn 04.37.33 # so there is just a .h file that has the binary image of the dsp code 04.38.18 # dsp/dsp-image.h in the tms320dm320/dsp directory under target/arm 04.38.33 # how well does the c compiler work for generating fast code? 04.38.48 # for something like mpeg player would it be useful or would you still want to use assembly? 04.38.53 Join gartral [0] (n=gareth@adsl-75-33-64-115.dsl.bcvloh.sbcglobal.net) 04.39.18 # you could probably use the C compiler just fine, I think it's just an older version of what they have in the code studio product 04.39.36 # I havn't looked at the disassembly to see how efficient it is though 04.39.42 Quit jhMikeS (Nick collision from services.) 04.39.48 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 04.39.50 # I'm not really familiar with the DSP assembly 04.39.54 # does it use plain c or are there extensions to handle the DSP features? 04.40.09 # and does gcc have an assembler for it ? 04.41.02 # there's some extensions that I'm aware of for mapping addresses but I havn't really looked into fully utilizing the DSP, binutils has support I think. 04.41.22 *** Saving seen data "./dancer.seen" 04.41.34 # right now like I said the code is just setting up the dma transfers and monitoring the buffers 04.41.58 # are you thinking about trying your hand at one of those DSP's? 04.42.15 # i've wanted to for a while now, but there was no suitable target 04.42.51 # well now you have one :-D 04.43.09 # the m:robe's are going for around 50-70 depending on the condition 04.43.20 # yes they seem quite cheap on ebay 04.43.23 # I just saw a nearly new one sell for about 50 on ebay 04.43.50 # the OF on them is really terrible 04.44.57 # if you go to that neuros link and login there's the manual and the latest versions of the different compilers TI released if you are interested in taking a look at what features they support 04.45.27 # i'll look through it 04.50.36 Quit Aurix_Lexico (Read error: 110 (Connection timed out)) 05.02.10 Join gartral1 [0] (n=gareth@adsl-75-33-64-115.dsl.bcvloh.sbcglobal.net) 05.02.10 Quit gartral (Read error: 104 (Connection reset by peer)) 05.02.21 Part gartral1 05.12.29 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 05.17.06 Join yhuang [0] (n=yhuang@unaffiliated/yhuang) 05.17.32 Join sbhsu__ [0] (n=a6530466@Zion.dorm.au.edu.tw) 05.21.03 Quit killan (Read error: 54 (Connection reset by peer)) 05.21.18 Join killan [0] (n=nnscript@c-02fc70d5.06-397-67626721.cust.bredbandsbolaget.se) 05.25.55 Quit timc`` (Read error: 104 (Connection reset by peer)) 05.26.08 Join timc`` [0] (n=aoeu@124.93.243.83) 05.30.16 Join gartral [0] (n=gareth@adsl-75-33-64-115.dsl.bcvloh.sbcglobal.net) 05.30.24 Part gartral 05.30.25 Quit midgey (Read error: 104 (Connection reset by peer)) 05.31.14 Quit sbhsu (Read error: 110 (Connection timed out)) 05.31.42 Quit sbhsu_ (Read error: 113 (No route to host)) 05.32.07 Join PatWilborn [0] (n=4a20af79@gateway/web/cgi-irc/labb.contactor.se/x-8bf0c2e787444e9b) 05.32.22 Join midgey [0] (n=tjross@71.238.148.140) 05.34.09 Quit PatWilborn (Client Quit) 05.39.10 Quit Horscht ("Verlassend") 05.55.15 Join StealthyXIIGer [0] (n=baduser@c-68-62-18-116.hsd1.mi.comcast.net) 06.06.45 Quit saratoga ("CGI:IRC (EOF)") 06.31.29 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 06.36.22 Quit nuonguy ("This computer has gone to sleep") 06.38.33 Quit Ubuntuxer ("Leaving.") 06.41.24 *** Saving seen data "./dancer.seen" 06.43.07 Quit z35 ("Leaving") 06.54.25 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 06.55.16 Quit agaffney (Read error: 104 (Connection reset by peer)) 06.59.04 Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) 07.14.06 Quit agaffney (Read error: 104 (Connection reset by peer)) 07.14.28 Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) 07.19.46 Quit timc`` (Read error: 145 (Connection timed out)) 07.25.49 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 07.29.44 Quit jhMikeS (Nick collision from services.) 07.29.50 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 07.37.34 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.39.18 Join timc`` [0] (n=aoeu@124.93.243.83) 07.56.52 # kkurbjun: congratulations on the mrobe work 08.00.27 Quit sarixe (Read error: 104 (Connection reset by peer)) 08.00.49 Join Wraith| [0] (n=Wraith@c-69-250-112-82.hsd1.dc.comcast.net) 08.04.47 Quit jhMikeS (Nick collision from services.) 08.04.53 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 08.06.19 Quit Wraith| (Read error: 104 (Connection reset by peer)) 08.08.27 Quit BHSPitMonkey (Remote closed the connection) 08.19.26 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 08.27.19 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.29.18 Quit timc`` (Read error: 104 (Connection reset by peer)) 08.29.26 Join timc`` [0] (n=aoeu@124.93.243.83) 08.30.52 Join Nitekreeper [0] (n=724cd23d@gateway/web/cgi-irc/labb.contactor.se/x-cb30a846486dcdd4) 08.31.00 # Anyone there? 08.31.10 Quit Nitekreeper (Client Quit) 08.41.27 *** Saving seen data "./dancer.seen" 08.48.13 Join Rob2223 [0] (n=Miranda@p4FDCD3CA.dip.t-dialin.net) 08.50.25 Join arohtar [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 08.50.58 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.51.19 Quit jon-kha (Read error: 131 (Connection reset by peer)) 08.51.32 Join jon-kha [0] (i=jon-kha@kahvi.eu.org) 08.56.10 Quit faemir (Read error: 60 (Operation timed out)) 08.58.59 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 08.59.04 Join flydutch [0] (n=flydutch@host238-166-dynamic.15-87-r.retail.telecomitalia.it) 09.03.23 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 09.03.39 Quit HellDragon (Read error: 104 (Connection reset by peer)) 09.05.25 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.05.44 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.06.16 # * B4gder spots a Ladies and Gentlemen commit! 09.07.03 # is soap's build server having a hw problem again? 09.18.12 # Looks like it. 09.19.36 # The Onda is not yet in the binsize table 09.19.42 # ah 09.20.00 # I forgot to add it there 09.23.08 # I gotta do something about the source package too, it takes too long to build 09.23.48 Quit Llorean (Read error: 110 (Connection timed out)) 09.24.45 # yet it has been downloaded 388 times during March, which indicates it is being used 09.25.17 # The Onda build or the source? 09.25.25 # the source 7z package 09.30.32 Join midijunkie [0] (n=Miranda@pD95470A6.dip0.t-ipconnect.de) 09.36.25 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.38.12 Join gartral1 [0] (n=gareth@75.33.64.115) 09.38.20 Part gartral1 09.49.29 Join n1s [0] (n=n1s@rockbox/developer/n1s) 09.54.23 Quit Thundercloud (Remote closed the connection) 09.55.54 Quit midijunkie (Read error: 104 (Connection reset by peer)) 09.59.13 Part pondlife 10.13.10 Quit midgey () 10.22.29 Quit homielowe () 10.30.22 Quit linuxstb (Read error: 113 (No route to host)) 10.30.50 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 10.35.01 Join gartral1 [0] (n=gareth@75.33.64.115) 10.35.11 # gsoc2009 students should be told that a weekly summary need to be posted to the -dev list or something 10.35.53 # to encourage frequent and early discussions around the project 10.36.11 Join nibbler_ [0] (n=Nibbler@p578b2a6e.dip0.t-ipconnect.de) 10.36.26 # some projects find it useful to ahve the students keep a current blog...i think that the least we can do is a weekly summary and being active in IRC 10.37.01 # yes, I think that'd fit us the best 10.40.00 # make bi-weekly irc visits mandatory 10.40.42 # that is a bit less than i would like, honestly 10.41.17 # as in, twice weekly minimum 10.41.29 *** Saving seen data "./dancer.seen" 10.41.39 # unless they have a valid, acceptable reason, i dont see why they cant be always in here...they dont have to talk, but at least be here 10.42.04 # don't want to leave their comp on all night? 10.42.19 # they dont have to 10.42.19 # have dialup :p 10.42.35 # what's that? 10.42.39 # :-] 10.42.44 # have a shared computer 10.42.54 # or something like only have net access @ uni/place of work 10.42.59 # unless they have a valid, acceptable reason... 10.43.04 # daurn: they are still expected to work on a computer so they would use one 10.43.19 Quit arohtar (Client Quit) 10.44.07 # scorche: in that way/tone you could say anything. 10.44.18 # what is your point? 10.44.26 # this is done on a case-by-case basis 10.45.07 # this isnt some broad rule that will apply to thousands of people...we will probably have 4-6 students that will be getting close attention 10.48.13 # :P 10.54.09 Quit Zambezi (Read error: 104 (Connection reset by peer)) 10.58.29 Join Zambezi [0] (i=marvel@bnc.dotbnc.se) 11.02.30 Part gartral1 11.03.30 Join gartral1 [0] (n=gareth@75.33.64.115) 11.05.34 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 11.06.10 Quit sbhsu__ (Read error: 60 (Operation timed out)) 11.10.14 Quit __lifeless (Remote closed the connection) 11.10.31 Join __lifeless [0] (n=lifeless@90.151.213.84) 11.10.53 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 11.12.39 Part gartral1 11.19.20 Join _lifeless [0] (n=lifeless@90.151.46.234) 11.30.07 Join tvelocity [0] (n=tony@adsl24-106.her.forthnet.gr) 11.35.05 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 11.35.26 Quit __lifeless (Read error: 110 (Connection timed out)) 11.43.02 Join __lifeless [0] (n=lifeless@89.20.119.163) 11.53.58 # Is there a problem with the -dev list? I just received a mail from someone unable to post to it (haven't checked yet if he's subscribed, but I'd guess so) 11.54.16 # Maybe recent subscribers or something? 11.54.35 # I'm not aware of any problems 11.54.45 # We had the gsoc guy also 11.55.05 # No, devcon 11.55.19 # yes, but we also get newcomers posting, like yday 11.56.07 # rasher: if you tell me the guys email in PM I can see if he's subscribed 11.58.12 Quit _lifeless (Read error: 110 (Connection timed out)) 12.09.04 # didn't the devcon guy say he had a general mail problem? 12.09.59 # I think this one turned out to be "not sending with the subscribed mail as From: header" 12.21.04 Join _lifeless [0] (n=lifeless@94.50.14.83) 12.21.45 Quit __lifeless (Remote closed the connection) 12.26.57 Join __lifeless [0] (n=lifeless@94.50.3.30) 12.30.21 Quit nibbler_ (Read error: 110 (Connection timed out)) 12.37.18 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.41.10 Quit _lifeless (Read error: 110 (Connection timed out)) 12.41.31 *** Saving seen data "./dancer.seen" 12.46.15 Join nibbler_ [0] (n=Nibbler@p578b2a6e.dip0.t-ipconnect.de) 12.54.36 Quit SirFunk (Read error: 110 (Connection timed out)) 12.55.35 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 13.16.17 Join moos [0] (i=Mustapha@rockbox/staff/moos) 13.25.39 Quit timc`` ("Leaving") 13.27.11 Quit n17ikh (Read error: 104 (Connection reset by peer)) 13.27.20 Join kachna [0] (n=kachna@r3g248.net.upc.cz) 13.28.15 Join n17ikh [0] (n=n17ikh@130.127.74.89) 13.29.30 # Did I dream it, or is it now possible to select a track/album for playback from pictureflow? (It seems to work fine during playback now.) 13.36.19 # Seems that's the main thing missing for it to be a usable alternate browser for those who don't care about battery life ;) 13.36.24 # pondlife: I think that is on the Unhelpful's TODO list 13.36.29 # Ah, ok 13.36.37 Quit obo (Remote closed the connection) 13.36.38 # I thought it might be a keymap missing (on H300) 13.36.59 Join petur [50] (n=petur@rockbox/developer/petur) 13.37.06 Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) 13.37.14 # It need a bit more work IIRC 13.39.28 # It's certainly a lot faster/more stable than it used to be. I like. 13.41.21 # yup Unhelpful reworked it and amiconn helped too to optimize 13.48.51 Join fyrestorm [0] (n=fyre@cpe-24-90-81-53.nyc.res.rr.com) 13.53.49 Join LambdaCalculus37 [0] (n=44a04303@rockbox/staff/LambdaCalculus37) 13.54.26 # * LambdaCalculus37 congratulates kkurbjun on getting sound on the m:robe 500 :) 13.54.54 # * moos joins LambdaCalculus37 in the dance :) 13.55.09 # yeah, really cool 13.55.18 # Why hasn't a "Ladies and Gentlemen" mail been sent, though? 13.55.22 # I wonder how that helps (or not) the creatives 13.55.47 # * B4gder now detects that the size info for the onda looks screwed up 13.55.54 # http://build.rockbox.org/cvsmod/sizes-20090311T110617Z 13.56.07 # B4gder: IIRC the ZVM also uses a DM320 core, so that means mculenaere might be able to adjust the sound output for the ZVM. 13.56.23 # yeah, that's what I'm thinking too 14.00.21 Quit fyrestorm ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]") 14.04.27 # pondlife: there's a keypad patch in the tracker as there are quite a few problems due to the fact that pf currently uses plugiinlib actionswith combined contexts 14.04.49 # or better: a controls patch, not keymap 14.04.58 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 14.07.35 # * LambdaCalculus37 pokes kkurbjun 14.09.29 # pondlife: hmm... misread 14.10.57 # the mentioned patch is not for playback from pf, just fixing bugs in the controls on other targets (just let you know then ;) ) 14.11.46 # I was very pleased to find I could now run the plugin without interrupting playback, that seems to be the biggest hurdle overcome. 14.12.32 # Having said that, it seems to corrupt tagcache data (or maybe dircache data) if rebuffering occurs while in pictureflow. Will try to repro and report properly later. 14.15.58 Join Munkie [0] (n=29b13251@gateway/web/cgi-irc/labb.contactor.se/x-cfe76a0e28507712) 14.16.07 Quit Munkie (Client Quit) 14.17.07 Join tyfoo [0] (n=tyfoo@77-20-31-238-dynip.superkabel.de) 14.20.16 # Is ID3v2->v1 fallback supposed to work for individual frames, or just for the entire tag? 14.21.28 Quit kachna (Read error: 110 (Connection timed out)) 14.21.58 # I have a bunch of files with most info in v1 tags, but replaygain (and nothing else) in v2 tags. They show up as untagged in the WPS 14.31.27 Join draft [0] (n=draft@51-128.cable.lpoy.dnainternet.fi) 14.31.48 # doesn't Rockbox support iPod Nano (2nd gen)? 14.31.58 # nope 14.32.09 # :( 14.32.13 # which is why the front page of rockbox.org says so! ;-) 14.32.35 # has Apple protected the bootloader somehow? are there any progress in cracking it? 14.33.25 # they have encrypted the firmware as well as using new proprietary hardware 14.34.20 Join Lynx_ [0] (n=Lynx@141.5.8.11) 14.34.28 # Is it really any more proprietary than the old ones? 14.34.57 # does it get more proprietary? 14.35.00 # The hardware in the nano 2nd gen is similar to that of the Meizu M3 and M6; same SoC being used. 14.35.26 # But yes, the real show stopper is the firmware encryption, which no one has been able to figure out. 14.36.21 # scorche: just think it's not the most important point to stress 14.36.40 Join goffa [0] (n=goffa@216.220.23.105) 14.36.54 # woo, a speaking player 14.37.18 # rasher: though r/e new hardware is yet another task that takes a lot of effort.. 14.37.28 # (the shuffle thing just posted to the dev ml) 14.39.05 # Sure, but ALL targets are using proprietary hardware. It's nothing specific to the new ipods 14.41.32 *** Saving seen data "./dancer.seen" 14.46.52 Part B4gder 14.48.06 Join fyrestorm [0] (n=fyre@cpe-24-90-81-53.nyc.res.rr.com) 14.52.16 Quit goffa_ (Read error: 110 (Connection timed out)) 14.55.37 Quit draft ("Lost terminal") 14.59.34 # pondlife: it caches a lot of tag data at startup, it doesn't hit tagcache again until you enter tracklist view 15.00.46 Join midgey [0] (n=tjross@71.238.148.140) 15.07.30 Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 15.13.52 # Unhelpful: The problem I saw wais that the database browser became corrupted. i.e. silly tag names, or only one album listed... Not managed to repro i from a cold boot though. 15.15.56 Join barrywardell [0] (n=barry@rockbox/developer/barrywardell) 15.18.47 Quit robin0800 (Remote closed the connection) 15.19.30 Join MrSpeedy [0] (n=misko@92.52.42.149) 15.25.11 Join midijunkie [0] (n=Miranda@pD95470A6.dip0.t-ipconnect.de) 15.28.46 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 15.30.55 Join robin0800_ [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 15.33.10 Quit yhuang ("Leaving") 15.34.01 Quit midijunkie (Read error: 104 (Connection reset by peer)) 15.37.01 # pixelma: you'd said long mode press for menu, short for select, in the album list on ondio? it's just that a long press of the select button is the context menu on the targets i have... i think the application menu should maybe go somewhere else? 15.38.21 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 15.38.51 # pondlife: i had some weirdness when i tried to use db queries while PF was running... no corruption, though, just a very obvious pause, bizarrely only on my e200, when each title was loaded :/ 15.39.10 # I think it happened after playback rebuffered 15.40.40 # context menu for a specific item in lists is on long "right" while select is on a short "right" on the Ondio. But that won't be possible in the horizontally scrolling album list, so short "mode" would be my next choice for select and long "mode" is menu almost everywhere (if possible) 15.40.53 Quit avis (Remote closed the connection) 15.41.09 # there is no context menu in the pf album list, is there? 15.41.32 Join jaykay [0] (n=chatzill@p579E6C7E.dip.t-dialin.net) 15.42.05 # pixelma: there's no context menu anywhere, only the app menu, but surely we'll want a context menu for insert/queue, next/last etc? 15.42.28 # on an album? 15.43.17 # why not though, it is possible in other browsers too 15.43.22 # exactly 15.43.58 # but, maybe the app menu should *be* the context menu, with settings/quit below all the other stuff? 15.45.38 # hmm... maybe a short "off" for the settings menu and long "off" for quit. Just a first idea, but I can't imagine e.g. up or down used for that (or for the context menu), guess I'd never expect it there 15.46.58 # wait... pf stops playback on these lowmem targets curently, not sure it will ever change and how much sense a context menu there... 15.47.10 # +makes 15.48.40 Quit robin0800 (Read error: 110 (Connection timed out)) 15.48.45 # actually, i'd talked about it with amiconn, and while you couldn't use it to start bunches of albums, it could always say, "i need to exit to play this for you, is that ok?", then clean up everything except a reference to the item to play, release the audio buffer, start playback, and exit 15.49.07 Join toffe82 [0] (n=chatzill@74.0.180.178) 15.49.14 # i... can *use* a long press of power? on my targets, that's shutdown 15.51.12 # it is on the Ondio too, but it's already used for e.g. pause vs. stop in the WPS. Shutdown is an even longer press and even though I don't have to wait too long for shutdown I can't remember accidentally switching off when I just wanted to stop playback 15.52.16 # discussion seems familiar, ah, talked to pondlife about it recently :) 15.52.23 # heh 15.52.42 # it was about general keymapping problems though, not pictureflow 15.53.04 # I'd still like to bring more consistency across targets where possible... 15.53.58 Join avis [0] (n=ident@pdpc/supporter/student/avis) 15.54.37 # i'm working on that, but it basically means going over target keymaps and figuring out how which of their actions will be hidden by stealing l/r for scrolling, and where those can be remapped. it's taking a while :) 15.57.01 # some plugins already use quit from a menu (not directly with a button). That could be another possibilty although I like being able to quit with a button too 15.58.44 # I think longer term we should expect pictureflow to be an (optional?) third browser- i.e files / database-text / database-pictures. 15.58.59 # i like having a dedicated quit, but i think the actions need to be prioritized in terms of putting the most important ones on keys that the user can figure out... scrolling first, then select/cancel/context, then app menu, then quit button 16.00.22 # I don't know if it helps to think of it as a slot-in replacement for the database browser when deciding on buttons or not... ;) 16.01.49 # it does, actually, i can steal mappings from whichever context that uses ;) 16.02.36 # You've got scrolling through the (album) list, going down to a list of tracks (and back up), then context menus/play etc. when a track is highlighted. 16.02.44 # Plus exit to top level/menu. 16.03.29 # I guess the plugin menu is an extra function though 16.04.42 # can we easily call into a core function to display a context menu for an item we've found in the DB? if not, and PF has to implement the context menu itself, it might as well also be the app menu. 16.04.49 # if so, that's a different story :/ 16.09.03 Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-2d4e2bcf2d585674) 16.09.52 # Bagder: you have the change for the hdd6330 to test it or do I miss something ? 16.11.43 Join timc [0] (n=aoeu@124.93.243.83) 16.16.26 # Unhelpful: It's probably not available at the moment, but I'd prefer if you could reuse the main one. Bit of a high-level function for the plugin API though! 16.19.43 Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) 16.23.23 Join StealthyXIIGer [0] (n=baduser@c-68-62-18-116.hsd1.mi.comcast.net) 16.25.22 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 16.25.29 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.25.44 # kkurbjun: congrats on the DM320 work! 16.26.16 # LambdaCalculus37: yes, the ZVM has a DM320 core; but last time I checked I was unable to access the DSP from the ARM core 16.26.40 # mcuelenaere: Do you think kkurbjun's work may help you out in getting sound working? 16.27.10 # it certainly does, but I should first be able to access the DSP 16.27.37 # then I should adjust the current code to work with the TLV320 and see if it's connected on the same McBSP 16.29.32 Quit nibbler_ (Read error: 110 (Connection timed out)) 16.29.51 Join Llorean [0] (n=DarkkOne@c-98-200-198-144.hsd1.tx.comcast.net) 16.33.52 Join MethoS- [0] (n=lem@host-091-097-241-144.ewe-ip-backbone.de) 16.33.54 Join goffa_ [0] (n=goffa@216.220.23.105) 16.34.51 # mcuelenaere: And kkurbjun hasn't sent out a "Ladies and Gentlemen" mail, the lazy bum. :P 16.35.09 # he did put it in a commit message though :) 16.35.55 # shouldn't this be added to the Ladies And Gentlemen wiki page? 16.36.26 # Yes, but it's that excitement of seeing that email in your box just calling to you, "Ladies and Gentlemen, we have SOUND!" 16.37.24 # mcuelenaere: I'll add it. 16.37.25 # we never sent out a Gigabeat "we have sound" email either 16.38.07 # markun: fix that now :) 16.38.20 # gevaerts: nah, it can wait :) 16.38.53 Quit jaykay (Read error: 110 (Connection timed out)) 16.39.22 # * mcuelenaere wonders whether distorted audio qualifies as 'sound' 16.39.25 Join ucchan [0] (n=ucchan@softbank219205178111.bbtec.net) 16.40.34 # mcuelenaere: It did for jhMikeS, when he was getting the Gigabeast sound working initially. :) 16.40.48 # His mail said that the first noise it made was an awful pulsing sound. 16.40.56 # in that case, the VX747 has had 'sound' for quite some time now 16.41.19 # s/has had/has/ 16.41.36 *** Saving seen data "./dancer.seen" 16.41.44 Quit midgey () 16.42.44 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.42.59 # Looks like I'll have to fix this. Should the mail go to both the regular and the -dev ML? 16.43.21 # kkurbjun: haha, your iramsize=0 trick helps on the fuze too, no reboot on mp3 anymore 16.43.25 # LambdaCalculus37: the M:Robe 500? 16.44.14 # mcuelenaere: Yes. 16.45.20 # looks like it isn't being consistenly sent to both 16.45.31 # s/it isn't/most aren't/ 16.45.33 # LambdaCalculus37: do you know the first sng played? 16.45.40 # the rover? 16.45.41 # or song 16.45.57 # usually it is sent to the dev list 16.46.02 # pixelma: No, but maybe kkurbjun can respond and tell us. 16.46.47 # Actually, there are quite a few players where we have no idea what the first song played was. 16.48.11 Quit MethoS- (Read error: 104 (Connection reset by peer)) 16.48.23 # given that the first sound counts, he probably heard some pumpgun sounds of doom :) 16.49.23 Quit goffa (Read error: 110 (Connection timed out)) 16.49.29 # kugel: Or the sounds of Mario jumping in Super Mario Land; he did say Rockboy had sound, too. :) 16.49.29 # If it is not a code freeze still, could you commit the following Bug's patches? 16.49.41 # FS#9206, FS#9614, FS#9692, FS#9707, FS#9736, FS#9780, FS#9970, FS#9973. 16.49.53 # LambdaCalculus37: maybe it was "PIKACHUU" 16.50.13 Join MethoS- [0] (n=lem@host-091-097-241-144.ewe-ip-backbone.de) 16.50.18 # ucchan: we are in freeze, but pure bug fixes are accepted 16.51.22 # ucchan: Are those all bugs with fixes, or new features? 16.53.27 # ucchan: isn't FS#9614 a new feature instead of a bug? 16.53.29 # The above task is all bug only. 16.54.10 # FS#9614 is bug. 16.54.31 # "make tools" does not succeed. 16.55.16 # because it doesn't exist 16.55.23 # is there a need for 'make tools'? 16.57.03 # I think that "make tools" needs. 16.57.37 # Execute "make help" shows "tools - builds the tools only" 16.57.50 # ah, in that case it is a bug 17.01.29 Join Linton [0] (n=irc_twin@user-544653bc.lns3-c12.dsl.pol.co.uk) 17.03.08 Quit robin0800_ (Remote closed the connection) 17.03.22 # ucchan: make tools is done when you build a normal build. I guess it has been build before 17.03.36 # did you run make veryclean before trying make tools? 17.03.42 Quit Zagor ("Don't panic") 17.05.57 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 17.08.15 Quit robin0800 (Remote closed the connection) 17.08.25 Join MTee [0] (n=MTee@41.233.154.103) 17.10.37 Quit bmbl ("Woah!") 17.10.58 # On the Sansa Clip, does anyone else have Rockbox running with no display or sound? I suspect a bootloader problem since I don't even see a splash screen. 17.11.53 # kugel: running 'make tools' from a newly configured target gives the same "Nothing to be done for 'tools'" 17.12.34 # (even with make veryclean) 17.13.29 # I think it's a documentation bug 17.13.41 # Linton: Display and sound both work on the Clip. 17.13.53 # Linton: Can you still boot the OF? Press the Home button as you turn it on. 17.14.03 # OF boot works fine. 17.14.11 # rasher, "make help"'s bug? 17.14.15 # (USB or Home) 17.14.28 # ucchan: Yes. Since the set of tools is dependent on which target you're working with 17.14.48 # Ah wait. 17.14.51 # Ignore me. 17.14.52 # Linton: Well, you do know that the Clip isn't a supported target yet, right? Unless you're looking to help development work, expect a few bumps in the road. 17.15.01 # * mcuelenaere committed FS#9614 17.15.09 # Rockbox also runs (saves files to disc, button lights work) but no sound or display. 17.15.23 # I was thinking of "make" in the tools dir 17.15.46 # Once you have the makefile we already know which tools are needed of course. 17.16.04 # LambdaCalculus37:I know it's not going to be all plain sailing, but no display or sound leaves me a bit stuck as to what to do next 17.16.44 # Linton: Try rolling the bootloader again, and use a different OF for the upgrade (I used the .30 firmware myself). 17.16.53 # Does anyone have a known-working bootloader-sansa.clip file, so that I could rule that in or out as a cause 17.17.07 # I've tried .30 and .29 17.18.36 # Is "Generating dependencies" necessary to build the execution file that exists in tools? 17.18.42 # Linton: I might. 17.18.47 # Let me check. 17.19.50 # kugel: you got mp3 on fuze? 17.20.04 # mcuelenaere, commit thanks! 17.20.33 # ucchan: what did you do to produce FS#9970 ? (I tried Gigabeat S simulator with logf enabled) 17.23.54 # For FS#9970, When Archos series's simulator was build, I found this bug. 17.25.00 # * mcuelenaere also can't reproduce FS#9973 17.25.43 # It makes an error of this because "drivers/serial.c" is not a build object when "SMULATOR" is defined. 17.26.05 # see firmware/SOURCES. 17.26.55 Join kkurbjunW [0] (n=karlk@12.41.166.10) 17.27.21 # Thanks LambdaCalculus37, midgey, and mcuelenaere 17.27.48 # * mcuelenaere now gets 'error: SYSFONT_WIDTH undeclared here (not in a function)' when doing a simulator build (with logf) for the Archos Studio 17.28.30 # without logf it builds 17.28.54 # kkurbjunW: So are you going to send that mail? ;) 17.29.45 # :), it would be a follow up to Cat's email over a year ago. He had sound working then, but it didn't use the decoder, it was streaming pre-decoded pcm from a file 17.30.05 # I think that counts 17.31.07 # :), I'll send something out as a followup 17.31.27 Join MethoS-- [0] (n=lem@host-091-097-244-074.ewe-ip-backbone.de) 17.31.59 # I also will do the build again when for archos player's simulator. 17.33.30 # the Player/Studio is the one with a charcell display, the error sounds related (no sysfont) 17.34.59 Join yhuang [0] (n=yhuang@unaffiliated/yhuang) 17.36.12 # Linton: What model of Clip do you have? 17.37.13 # pixelma: what do you mean? is it a known bug? 17.38.23 Join perrikwp|lab [0] (i=98214c9d@gateway/web/ajax/mibbit.com/x-6386c77ca6a24aff) 17.38.39 # not that I know of but thought it could help finding where to look at 17.40.31 # Archos recorder seems to suffer from FS#9970 17.41.39 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-2a5b59c63096ae7a) 17.44.05 # ucchan: what error message is FS#9973 supposed to give? 17.44.16 Join Conic [0] (n=conicpp@c-75-68-165-66.hsd1.vt.comcast.net) 17.44.39 # gevaerts: Seems start screen set to Database doesn't work either 17.44.50 # gevaerts: When booting with usb attached on pp... 17.45.01 # I build succeed the Archos/Studio's simulator under Cygwin/MinGW. 17.45.16 # ucchan: with logf enabled? 17.45.38 # Sorry "logf" is not enable. 17.46.01 # FlynDice: yea, with disabling IRAM though 17.46.54 Quit MethoS- (Read error: 113 (No route to host)) 17.47.04 # LambdaCalculus37: my Clip is a 2GB, V1, without radio - I think the lack of radio is probably the unusual feature here. Have any previous reports of Rockbox working or not working mentioned if a non-FM Clip was used? 17.47.09 Join midgey|web [0] (i=8dd43638@gateway/web/ajax/mibbit.com/x-a47ea607f0727049) 17.47.37 # When "logf" is em 17.48.02 # When "logf" is enable, then the simulator build faqilure. 17.48.04 # midgey|web: I nearly missed that translation! 17.48.13 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 17.48.31 # ucchan: yes, that's what I was talking about 17.48.33 # logf.c:135 undefined reference to 'serial_tx' 17.48.45 # hmm no, I commited your fix for that just now 17.49.04 # rasher: what are your thoughts on the arabic update? 17.49.21 # midgey|web: I posted a comment 17.49.40 # ah yes 17.49.48 # Linton: I'm not very sure. The one developer who did the bulk of the work hasn't been around lately, and I don't know if any other devs with a Clip have tried the build on a Clip without radio. 17.49.52 # Do we have a HWUSB target without bootloader usb? 17.50.04 # rasher: it seems like most of those insertions are simply copying over the english phrases 17.51.01 # midgey|web: Didn't he say he didn't do them all anyway? 17.51.16 # shouldn't '(A)dvanced' in the configure script have a '(B)ootloader' option to enable logf bootloader builds? 17.51.23 # Sorry my source is old. (base on r 20289) 17.51.30 # midgey|web: I think we should just cut out the untranslated ones and commit the ones he's translated 17.51.42 # i agree 17.52.15 # I will check for current source. 17.52.30 # ucchan: what error message is FS#9973 supposed to give? 17.52.46 # kkurbjunW: I just tried enabling mmu again, using mr500 code. doesn't work :( 17.53.01 # midgey|web: Doesn't look like it'll be too much work actually 17.53.04 # I'll get on it 17.53.51 # kugel: Yeah, I didn't look into it too much, but I think the problem was that when the codecs were run they were overwriting other portions of the iram that they shouldn't be since we weren't properly monitoring how much the core was using versus the codecs. Didn't bertrik say that he got it running yesterday with an attempt? 17.54.47 # I didn't notice bertrik getting it to work 17.54.57 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 17.55.07 # I think it's in the logs somewhere that he did an initial attempt and it was still booting 17.55.12 # * LambdaCalculus37 saw the mail :) 17.55.33 # kkurbjunW: indeed 17.56.16 # LambdaCalculus37: you're adding the song to the wiki page? 17.56.41 # kkurbjunW: weird. maybe it has something to do with the usage of the iram. the fuze doesn't use it much, but the clip heavily for codecs 17.56.54 # thus, on the fuze the codec buffer is in dram 17.57.00 Quit MrSpeedy ("Leaving.") 17.57.24 # not sure if that makes enough difference to have the mmu working on the clip but not on the fuze 17.58.55 # mcuelenaere: Just did. 17.58.57 # I might be wrong, I was just looking at it briefly and it didn't look right to me so I tried changing it and it worked great. 17.59.21 # LambdaCalculus37: yeah, I got the 'RobertMenes has been editing the topic for ..' message :) 17.59.26 # kkurbjunW: this is what I have now http://pastebin.ca/1358296 17.59.51 # On the m:robe with the cache enabled and the small size of the iram it doesn't make much sense to pursue the iram that much, at least not in my opinion 18.00.48 # I am thinking about completely getting rid of the iram use on the m:robe since I can make all the irq jumps with a branch instead of an LDR which would potentially be less cycles.. I havn't actually counted the cycles yet though 18.00.51 Part Linton 18.00.59 # kkurbjunW: Just curious... isn't the mr500 another target with 64MB of RAM? 18.01.50 # LambdaCalculus37: yep, 64 megs of ram a DSP and a couple of other co-processors to help with mpeg2, mpeg4, and decoding some other codecs 18.01.58 # kugel: I'm looking at it now 18.01.59 # kkurbjunW: we have 320k iram on the ams sansas 18.02.04 # yeah, I remember that 18.02.14 # and I think you are right that it makes sense to use it there 18.02.24 # kkurbjunW: regarding the DM320 and IRQ: have you seen FS#8687 ? 18.02.41 # well, particularly because it means over 15% extra ram for the low mem ones 18.03.21 Quit SirFunk (Connection timed out) 18.04.11 # mcuelenaere: yeah, I looked at that feature before.. It could save some time on interrupts as well 18.04.42 # I would be interested in getting it working eventually 18.05.20 Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") 18.06.40 # * kugel eagerly awaits gevearts then 18.06.45 # bertrik, I mean 18.07.23 # midgey|web: result was about 125 newly translated strings. Not bad 18.07.35 # not at all 18.07.45 # kugel, make sure that the ttb_base calculation matches the app and boot .lds. Enabling the MMU in the code that you are mapping over might be problematic. If you enabled it in the bootloader running from IRAM first it might work better. Otherwise like you said see what bertrik has. 18.09.47 # kkurbjunW: I put the ttb into iram for this try. there should be nothing in this area on the fuze 18.10.31 # I dont know if the ttb can be in the iram the MMU may not be able to access it to determine the mappings. 18.11.13 # I'm not positive on that, but I would bet that it can't use the iram. On some chips DMA transfers can't be run from IRAM 18.11.21 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 18.11.28 # For FS#9970, the simulator build failure under MINGW.(No rule target sysfont.h) 18.11.52 # But under Cygwin, this problem does not occur. 18.12.08 # rasher: Hey, save me some language patches to commit. :P 18.12.30 # ucchan: I have the same error for native Linux 18.13.14 # LambdaCalculus37: You could find out what's wrong with FS#9998 18.13.37 # kkurbjunW: it didn't work when I tried to have the ttb at the end of dram (and I paid attention to not overlap with other regions) 18.14.16 # Is this Makefile's bug? 18.15.27 # ucchan: I don't know what's causing this 18.15.54 # rasher: The patch doesn't apply cleanly at all, because the path is completely wrong. http://pastebin.com/m9fd646a 18.16.27 Quit perrikwp|lab ("http://www.mibbit.com ajax IRC Client") 18.16.31 # LambdaCalculus37: sure, but even after you do -p5 or whatever it was, it still doesn't apply at all 18.16.40 Quit Horscht ("Verlassend") 18.16.52 # rasher: I'll try it tonight after work. 18.17.16 # Do you know where it fails booting? Does it happen right after you start to enable the MMU? What happens if you just run the map everything over itself? 18.17.23 # * LambdaCalculus37 assigns the task to himself so he can work on it 18.17.59 # * mcuelenaere wonders what's faster: a for-loop looking for the first set bit or a call to find_first_set_bit() (on MIPS target, so CLZ is available as instruction) 18.18.15 # With a bit of luck, TomerS will have an answer 18.19.23 # many of the new strings seem to miss the user: line completely 18.19.38 # in the hebrew lang patch 18.19.46 # rasher: it seems the second file mostly reverts hebrew strings to english 18.19.57 # Ah, sounds like he used an old file as a base... 18.20.43 # kkurbjunW: my clip doesn't boot either, with or without ttb in dram 18.21.07 # kkurbjunW: the mcr command to enable the mmu makes it not boot 18.21.12 # rasher: and it looks very messy (still the ### present and the serial bitrate phrases look incomplete) 18.21.22 # I think the patch is reversed 18.23.30 # Yes, it's very messy. 18.23.41 # midgey|web: that doesn't sound unlikely 18.24.05 # Maybe we should tell TomerS to do it again, and this time, make a diff from the lang file currently in SVN. 18.24.09 # Maybe it applies on top of the other one 18.24.22 # I think I have a unified version 18.24.27 # I'll add it to the task 18.25.20 # midgey|web: Sure; maybe I'll commit it later on tonight. 18.25.22 Join Ubuntuxer [0] (n=herbert@dslb-092-073-025-168.pools.arcor-ip.net) 18.25.28 # For the problem of sysfont.h, it did not occur when 08-Schumacher-Clean.bdf existed in folder fonts. 18.26.31 # kkurbjunW: looking at other targets code, I don't really see what I'm doing differently or wrong :( 18.27.00 Part pondlife 18.27.23 Quit midgey|web ("http://www.mibbit.com ajax IRC Client") 18.28.36 Quit __lifeless (Remote closed the connection) 18.29.31 Join _lifeless [0] (n=lifeless@94.50.3.30) 18.30.46 # Hmm, ran into another issue on my iPod 60g 5G running yesterday's build. If I have it docked and exit out of the USB connectivity screen and try to play anything, it crashes with a "Data Abort" 18.31.10 Quit linuxstb (Read error: 60 (Operation timed out)) 18.32.19 # i think that was fixed a week ago, are you running an old build? 18.33.22 Quit _Auron_ (Read error: 104 (Connection reset by peer)) 18.33.49 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 18.34.03 # saratoga: Yesterday's build 18.34.14 # Haven't tried today 18.35.00 # Sorry very late, for FS#9973: When Archos's simulator builds, output "No rule to make target ../rockbox.ucl needed by build Stop" 18.35.08 Join archivator [0] (n=archivat@77.70.28.57) 18.35.18 Join _Auron_ [0] (n=DarkAuro@ppp-70-249-146-14.dsl.rcsntx.swbell.net) 18.35.41 # lol, ipod finally got some form of voice support :-P 18.35.58 # lostlogic: What do you mean finally - they're the first in the world! 18.36.21 # rasher: oh, sorry, MY BAD! *rolleyes* 18.40.07 # gevaerts: ping :) 18.40.19 # Hi, I would like to improve the game menus and uniform them. I have noticed that the code style is very different between the games. e.g. some guys used always static functions, but I don't see the necessity 18.40.57 # kugel: pong 18.40.59 # Ubuntuxer: It's the other way around. you need to look for reasons for functions to be non-static 18.41.23 # gevaerts: so, what's the status of the meizus? :p 18.41.39 *** Saving seen data "./dancer.seen" 18.42.21 # the forum thread is hardly suitable if you just want a quick overview of the status 18.42.51 # but then actually in a plugin, which consist of one file, all functions can be static 18.43.02 # gevaerts: is this table up-to-date? http://www.rockbox.org/twiki/bin/view/Main/TargetStatus#New_Platforms_Currently_Under_De 18.43.05 # kugel: basically unchanged since months. We have a mostly working lcd driver for the M3, and we can read its buttons. M6sp and M6sl need work on crt0.s, and they have formerly-working button readout (clock and timing issues make it not work now) 18.43.22 # Ah yes, backlight toggling works well :) 18.43.39 # but no fading? 18.43.41 # kugel: yes, that's correct 18.43.41 # fail! :) 18.44.40 # kugel: we're leaving some little things for you! 18.45.28 # looks like http://www.rockbox.org/twiki/bin/view/Main/MeizuM6Port is out of date 18.46.48 # gevaerts: first things are interrupts and then USB? 18.46.49 # gevaerts: You can imagine I'll be gladly doing the backlight fading work 18.47.20 # markun: that's an option, yes. LCD on the M6 would of course also be nice 18.47.38 # of course 18.47.44 # * gevaerts wonders if we could manage to get a port to supported state without working LCD :) 18.47.56 # kugel: are you thinking of working on the meizu port? 18.48.46 # markun: not without such a device, I guess. I was just curious about the status 18.49.18 Join vertic39 [0] (n=email@dslc-082-082-043-138.pools.arcor-ip.net) 18.49.55 # Someone get kugel a Meizu! :) 18.54.10 Quit ucchan ("Leaving...") 18.55.41 # What do you think about uniform the menus? Every game should have a game menu similary to chooper, except that resume game isn't displayed, if it isn't available. 18.57.33 # that would be nice 18.57.38 # * kugel wonders why resume should be unavailable 18.58.03 # kugel: if the game doesn't implement resume... 18.58.41 # oh, resume the game? I thought about resuming playback in the playback menus :S 18.58.54 # * markun thought the same :) 18.58.57 # yes, I have written a very small patch for brickmania 9953 18.59.26 Join {phoenix} [0] (n=dirk@p54B47D81.dip.t-dialin.net) 18.59.44 Quit yhuang ("Leaving") 18.59.57 # saratoga: I can play mp3 on my fuze when I disable the IRAM 19.00.21 # this is interesting, I just wonder what needs fixing in this case 19.00.40 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 19.03.58 Part Ubuntuxer 19.06.02 Join ibseco [0] (n=ibseco@BAH6efc.bah.pppool.de) 19.07.10 Quit vertic23 (Connection timed out) 19.07.20 Quit ibseco (Connection reset by peer) 19.07.58 Join PaulJam [0] (n=Paule@p54BECA0C.dip.t-dialin.net) 19.08.21 Join ibseco [0] (n=ibseco@BAH6efc.bah.pppool.de) 19.12.09 Join miepchen^schlaf [0] (n=miepel@p579EC99E.dip.t-dialin.net) 19.19.09 # kugel: maybe we don't link the codecs right? do the IRAM addresses in your map file corrispond to the real IRAM? 19.19.39 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.19.44 # mp3 uses more IRAM then most codecs, maybe its more sensitive to that 19.22.15 Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-bba19433e09abf0c) 19.23.30 # * kugel checks the map 19.26.56 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 19.27.15 # saratoga: it seems it's using plugin buffer 19.27.33 # I don't understand maps fully, but the map shows addresses within the plugin buffer only 19.29.38 # aac too 19.30.21 # kugel: the plugin buffer is actually the codec buffer 19.30.28 # i think its because the script is shared with plugins 19.31.46 # kugel: does IRAM really start at 0x0 ? 19.31.57 Join z35 [0] (n=z35@h184.121.88.75.dynamic.ip.windstream.net) 19.32.46 # saratoga: yea 19.33.24 # aren't there interupt vectors and such there? 19.34.45 # afaik, no 19.35.24 Join insertnext_us [0] (n=54982c8a@gateway/web/cgi-irc/labb.contactor.se/x-753d4cfd29d2c20d) 19.35.42 Quit insertnext_us (Client Quit) 19.35.50 Join webguest87 [0] (n=54982c8a@gateway/web/cgi-irc/labb.contactor.se/x-1293863e922b9877) 19.36.00 # I thought the MajorChanges page was more or less reserved for supported targets 19.36.43 # (having sound on a new port is great though, I don't want to devalue that fact or anything) 19.36.55 # hmm my build shows most of the IRAM stuff on PP is in DRAM on the e200v2 19.37.02 # that seems a bit odd 19.37.10 # is ICONST not defined on AMS? 19.38.04 # saratoga: something is definitely wrong 19.38.22 # mpa.map says it's start address is: 0x30680000 19.38.29 # hi, H140, using latest current build, if a album/track is "Inserted Next" to the playing playlist it updates the dynamic playlist but actual playback continues with prior playlist 19.38.34 # which should be neither codec nor plugin ram 19.38.49 # kugel, I would expect the interupt vectors to be in iram at 0x0, most of the crt0.s code for arm targets stores a copy in dram and copies it to iram when the code starts 19.39.05 # we have 0x800000 total ram, plugin should start at 0x700000, codec at 0x620000 19.40.11 # i wonder if the crashes we get are due to sections being linked on top of one another 19.40.42 # eh, the other way around 19.41.03 # plugin should start at 0x720000 and codec at 0x620000 19.42.05 # but I can't spot anything obviously wrong in the .lds files 19.42.40 # using build r20287-090311 for ^^^ 19.43.33 # webguest87: really? 19.44.06 # yes, I have been able to duplicate it quite readily sith album inserting 19.44.45 # I use Insert several times consequestively then I use Inser Next, it updates the playlist but playback is the prior playlist 19.45.20 # bertrik: No, there are announcements of sound on new targets on the MajorChanges page as well. 19.45.42 # Kugel, I use dircahce, file tree browsing 19.46.18 # could this be related to the problem in FS#7423 ? 19.46.48 # LambdaCalculus37, in that case the clip (and probably other ams sansas) are missing :) 19.47.15 # bertrik: That'll be funman's fault. ;) 19.47.16 # bertrik: how did you get the mmu running? 19.48.05 Quit gevaerts ("hardware maintenance time") 19.49.10 # kugel, not sure if it's actually running, but at least it doesn't crash 19.49.18 # can I see a patch? 19.50.37 Quit PaulJam (".") 19.51.33 # * kugel 's e200 won't connect 19.51.45 # kugel, http://pastebin.ca/1358391 19.52.53 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 19.53.16 # there is some asm code in system-as3525 to explicitly enable the caches. I thought this was no longer necessary after enable_mmu() but rockbox seemed slower without it 19.54.25 Quit webguest87 ("CGI:IRC") 19.54.27 # bertrik: you didn't define a TTB_SIZE. mmu-arm.S needs this macro 19.54.29 Join yhuang [0] (n=yhuang@unaffiliated/yhuang) 19.55.11 # also, you don't seem to mark the ram as cachable. I didn't try that, but I'd think we want to cache it, else we wouldn't need the dcache at all 19.55.46 # I didn't get any error about a missing TTB_SIZE 19.55.50 # bertrik: if it was slower, it probably means the icache is inactive too, which would mean enable_mmu failed 19.56.17 # can't even find it in mmu-arm.s :S 19.56.29 Join webguest87 [0] (n=54982c8a@gateway/web/cgi-irc/labb.contactor.se/x-5fa5a3342c267c16) 19.56.34 # oh, I was wrong 19.56.57 # IIRC it needed it before jhMikeS did the assembly rework 19.57.59 # seems it disappeared in that rework 19.58.17 # I think I'll do a comparison between the code in mmu-arm.S and the arm922T datasheet 19.58.27 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 19.58.45 # PaulJam; Kugel, my issue with Insert next is as described in FS#7423 19.59.50 # webguest87: ah so that's an old issue? 20.00.06 # for a moment I thought I caused it with recent commits 20.00.08 # appears so, it needs some luv 20.01.17 # bertrik: I think you didn't succeed. I assume neither is enabled if you experienced a much slower rockbox without the asm below your additions 20.01.46 Join Reptile211 [0] (n=chatzill@host-216-66-248-9.static.linkline.com) 20.02.09 # kugel, I think that the icache is typically enabled in crt0.s for the targets that need the MMU. 20.02.13 # bertrik: but you can try to read back the dcache register to see if it's enabled 20.02.24 Quit webguest87 ("CGI:IRC") 20.02.48 # kkurbjunW: the mr500 doesnt do that? 20.03.58 # oh, you're right, the mr500 is different 20.04.04 # kkurbjunW: can you tell why TTB_SIZE doesn't appear to be used anymore? 20.04.52 Quit jhMikeS (Nick collision from services.) 20.04.58 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 20.05.01 # I would guess that we just assume the size since it is consistent on all the targets that use the MMU, we don't do secondary mappings on any of the targets 20.05.12 # hm, it was never used, it seems 20.05.18 # but I don't know for sure, jhMikeS might be able to answer 20.06.06 # kkurbjunW: I tried to do all the mmu stuff in crt0.S, without success 20.06.19 # same no-boot symptoms 20.06.39 Quit fyrestorm (Read error: 131 (Connection reset by peer)) 20.07.03 # yeah, it looks like that is the assumption in the code, for a 32 bit space you have a known amount of memory needed to store the ttb table 20.07.52 # like I said though that is just to do the top level mapping, if you need to define area's with finer detail than 1 mb, you will need more space for the ttb 20.08.14 # but I don't see a need for that since we are not using any protected memory or anything like that 20.08.49 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 20.10.40 # * kugel takes a course in hex numbers again :S 20.10.52 # kugel, I didn't see the code that bertrik was talking about before in system-as3525, but I would remove that and let enable mmu take care of enabling the i/dcache 20.11.28 # kkurbjunW: that was his plan. He said rockbox was noticeably slower then 20.11.54 # and I experienced this too when I removed that code without doing mmu_enable() 20.12.12 # enable_mmu() even 20.12.29 # It's the same code as in enable mmu.. I don't see why that would be a problem 20.12.56 # experineced the crash on startup, or slower operation? 20.12.57 # that'S why I think the enable_mmu call didn't succeed at all. I don't know why 20.13.28 # he said rockbox was much slower but didn't crash 20.13.30 Join arohtar [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 20.13.47 # which matches my experience without enabling any cache 20.13.54 # try that while enabling sections of memory for caching and see if it's still slow 20.14.18 # I could remap a section and see if the memory is really remapped 20.14.25 Join Lynx [0] (n=Lynx@xdsl-87-78-176-238.netcologne.de) 20.15.36 # saratoga: forget my talk about wrong addresses. 20.15.53 # but I still don't find any iram-like address in mpa.map 20.16.31 # * amiconn still doesn't know whether the gfx drawing optimisations should be in MajorChanges 20.16.32 # ah wait, there's some 20.17.15 # amiconn: why not? major speed ups are major changes, imo 20.17.15 # amiconn, how much faster did it get? 20.17.33 # amiconn: according to Buschel they make a real difference on the ipod video, so I'd say yes 20.18.18 # http://svn.rockbox.org/viewvc.cgi?view=rev;revision=20242 20.18.21 # i think we should put more in the major changes page 20.18.35 # most people don't read the SVN logs, but would still like to know when things are improved 20.18.55 # saratoga: what does the /DISCARD/ stand for? 20.18.56 Quit _lifeless (Read error: 110 (Connection timed out)) 20.19.00 # We have a category in MajorChanges for "Enhancement, improvement or optimization" 20.19.22 # I'd say _any_ visible / easily measurable speed up probably qualifies as an optimization. 20.19.35 # amiconn, if it's a directly observable improvement for users, I would add it 20.20.04 Quit Seed ("cu, Andre") 20.20.13 # exactly my opinion too 20.20.52 Join ucchan [0] (n=ucchan@lo194.061.geragera.co.jp) 20.21.09 # That reminds me - I should brush up my gfx performance test plugin and commit it 20.21.24 # kugel: i've seent hat in map files but i don't know what it means 20.21.38 # Does a test plugin count as a feature commit? Guess not (it doesn't touch the core at all) 20.21.57 # amiconn: speaking of which, has anyone ever profiled any rockbox themes to figure out where they spend their CPU time? 20.22.29 Join raphi [0] (n=raphi@pub082136127100.dh-hfc.datazug.ch) 20.22.57 # amiconn: Don't test plugins mostly not compile by default anyway, or have we stopped doing that? 20.23.14 # they don't compile by default 20.23.17 # They are not compiled by defalut 20.23.28 # though i wouldn't mind enabling some of them by default 20.23.43 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 20.24.11 # * kugel would like to have a debug build which just builds them all 20.24.38 # I don't think they should be included in official builds, but then not building them means that breakage won't be detected 20.26.30 Quit timc (Read error: 60 (Operation timed out)) 20.26.45 # Could we just compile them by default, and intentionally exclude them from "make zip" and maybe add "make debugzip"? 20.26.55 Join timc [0] (n=aoeu@124.93.243.83) 20.27.01 # they're so harmless i don't see why we couldn't just distribute them 20.28.08 Quit arohtar (Client Quit) 20.28.21 Join arohtar [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 20.28.50 # Cluttering the list of plugins, questions "what's this for", slower downloads... 20.29.15 # if they are not in the CATEGORIES file they shouldn't show up in the menu iirc 20.29.46 # They are in the categories file, because they're very cumbersome to reach if they weren't. 20.29.55 # And some even need to be (viewers) 20.30.00 Quit faemir (Read error: 110 (Connection timed out)) 20.30.49 # saratoga: moving the iram start (and reducing the size) for codecs throws an undefined instruction 20.31.20 Quit ucchan ("Leaving...") 20.32.28 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 20.32.58 Quit Lynx_ (Connection timed out) 20.32.58 Nick Lynx is now known as Lynx_ (n=Lynx@xdsl-87-78-176-238.netcologne.de) 20.34.13 Join goffa [0] (n=goffa@216.220.23.105) 20.34.31 # now prefetch abort TT 20.37.58 Join Munkie [0] (n=29b13251@gateway/web/cgi-irc/labb.contactor.se/x-161fb54d7bc5fad8) 20.40.01 # when is 2.3 coming out and whats new in the release? 20.40.11 Quit SirFunk_ (Read error: 110 (Connection timed out)) 20.40.18 # 2.3 came out years ago... 20.40.18 # Munkie: that was released years ago ;) 20.40.20 # Munkie: 2.3 is long ago 20.40.27 # * n1s wins! 20.40.29 # we're so funny :) 20.40.36 # n1s: gevaerts won 20.40.44 # not i my logs! 20.40.53 # oh, in my logs I won! :p 20.40.53 # Munkie: What's new in 3.2 is everything we have now that wasn't in 3.1 20.40.59 # Speaking of 3.2, what do we do about USB? 20.41.09 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 20.41.39 # gevaerts: It works "okay" now. We don't _have_ to change it, right? 20.41.41 *** Saving seen data "./dancer.seen" 20.41.49 # Though we should apply that iPod charging patch probably. 20.42.04 # Llorean: it still doesn't work at all for some people, and I have no idea why 20.42.05 # I know it's sorta a new feature, but it's also a _very_ important fix if it works right 20.42.20 # gevaerts: Are they all using Ubuntu 9.04 (or newer Linux kernels possibly?) 20.43.00 # I've seen reports about recent ubuntu, osx, xp and vista. 20.43.55 # I think we should still include it. Rebooting manually is still an option, and wider testing might help track it down. 20.43.55 # The vista one is what I've looked into most, as there was a dev on the other end. For some reason the controller never seems to send out data, and I don't think it's actually related to the host OS 20.44.04 # Llorean: I agree 20.44.18 # If we disable it, I'd only do that for the release and leave it enabled in trunk 20.45.03 # If we disable it, we get less testers, and a smaller chance to resolve remaining issues 20.45.05 # I think as long as we include in the release notes "USB Enabled. Should work in nearly all cases. If your player refuses to connect, manual dual boot is still available." 20.45.30 # as long as we don't claim that 3.2 is a bugfix and stability release, there's no reason to exclude features 20.45.35 # gevaerts: So are we initializing the controller wrong possible? What hardware was it? 20.45.35 # I agree there. 20.45.38 Quit goffa_ (Read error: 110 (Connection timed out)) 20.45.47 # Llorean: e200 20.46.31 # kugel: "more testers" isn't a valid reason to enable things in a *release* IMO 20.46.41 # in trunk, sure 20.46.42 # gevaerts: Did you have him try booting the OF briefly, then going back into Rockbox? 20.47.05 # saratoga: ping 20.47.07 # gevaerts: it always is. it's vital for open source 20.47.15 # kugel: not in a *release*! 20.47.25 # kugel: The whole point of a release is that it's not supposed to be "testing" 20.48.15 # gevaerts: USB can be disabled at the last minute anyway. 20.48.27 # Llorean: true. We have 12 more days 20.48.37 # its a point release so it can be not cmpletly rock solid 20.48.56 # But I think unless we have evidence that we're still doing something wrong, we should probably go with "it's expected to work" 20.49.00 # gevaerts: back 20.49.04 Quit Munkie ("CGI:IRC") 20.49.28 # saratoga: if you have time, can you try disabling the queue_broadcast() lines in usb_storage,c? 20.49.47 # * gevaerts just thought of that one... 20.50.17 # saratoga: I get prefetch aborts if I shrink the iram for codecs (in the same way it's done on pp) 20.50.34 # It may increase latency by other threads being more active (see also FS#10006). You never know... 20.50.46 # what's a prefetch abort anyway? 20.51.02 # gevaerts: all of them? 20.51.13 # kugel: i think its when you try to fetch an op from an invalid location 20.51.23 # saratoga: only the READ and WRITE ones. The others should be harmless 20.52.05 # Although nothing actually makes use of them yet, so disabling them all won't break anything 20.53.11 # kugel: speaking of usb event broadcasts, have you seen FS#10006? 20.53.20 # linuxstb : hello ? 20.53.27 # kugel: I don't really know enough about this kind of thing to speculate, but it really sounds like we're not seeting up memory correctly 20.53.29 # gevaerts: any broadcast will interrupt backlight fading IIUC 20.54.41 # hm 20.55.14 # * gevaerts thinks that on the one hand that is a bug, but on the other hand these USB broadcasts may actually be abusing the broadcast system a bit 20.55.14 # fading can only happen if the queue is timed out 20.55.46 # why? By design, or an implementation decision? 20.55.55 # both, more the latter 20.56.05 # it was jhMikeS's idea to make it timeout based 20.56.19 Quit LambdaCalculus37 ("CGI:IRC 0.5.9 (2006/06/06)") 20.56.25 # it works well as long as nothing is constantly broadcasting, of course 20.56.56 # as this shows... How often can something broadcast and not stop backlight fading? 20.57.02 Quit Reptile211 (Read error: 104 (Connection reset by peer)) 20.57.27 # gevaerts: the disk never mounts with those two lines commented out 20.57.36 # windows reports that the device isn't recognized 20.57.47 # that's weird... 20.57.48 # gevaerts: actually, when it starts fading, no broadcast should be happen, since it will do 1 fading step on each consecutive timeout 20.58.23 # kugel: well, you can't guarantee that... 20.58.30 # I know 20.59.31 # Do I need to learn about vlc, vlc tables, sub-band coding..etc. to be able to use the source of the cook decoder ? 20.59.44 # saratoga: can you try plain r20139? 21.00.02 # to be honest, I was never a fan of the timeout way, but there were problems with too many posts going the "normal" way 21.00.31 # kugel: I guess an occasional broadcast at a bad moment just makes that particular fade a bit jerky. Are there other consequences? 21.00.55 # no 21.02.05 # ok. so as long as I don't send more often than the biggest timeout you use, we should be mostly fine. 21.02.30 # no 21.02.32 # * gevaerts now sends up to every 2 or 3 miliseconds. That's probably too often... 21.03.00 # if a broadcast happens, the queue_wait_w_tmo will be interrupted. then the next queue_wait_w_tmo will start 21.03.12 Quit stripwax ("http://miranda-im.org") 21.03.20 # well yes. We're not absolutely fine, only mostly so :) 21.03.44 # ah, well, mostly might be correct :) 21.03.47 # How long can your timeouts realistically get? 21.03.58 # backlight-sw-fading.h 21.04.27 # typically between 20 and 30ms, max is 40 21.05.07 # Another option is just not to fade when USB is connected. If we've got USB charging, it might make sense to simply leave the backlight on, or have a button to toggle it on/off manually. 21.05.08 # OK. I was thinking of only sending status updates every half-second or second or so. We should be fine then 21.05.09 # HZ/, I mean 21.05.52 Quit balou (Read error: 110 (Connection timed out)) 21.05.52 # so between 25 and 50 ms? 21.05.55 Quit bzed (Read error: 110 (Connection timed out)) 21.06.11 # hm, no... 21.06.18 # * gevaerts can't think straight 21.06.47 # the whole formula is a mess 21.06.50 # :P 21.07.14 # for e200, it's supposed to be HZ/25 21.07.25 Quit Thundercloud (Remote closed the connection) 21.07.27 # (HZ/(MIN(_FADE_DELAY, 40))) means that you'll always wait longer than HZ/40, right? 21.08.23 # no, never shorter than HZ/40 21.08.49 Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D") 21.09.10 # The MIN() is after the /, so you divide by it. That means an upper limit on time, or am I confused? 21.09.37 # the higher the divisor is, the lower is the number of ticks to wait 21.09.38 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 21.09.48 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-388f39eed0316d50) 21.09.59 # yes, and you limit the divisor to 40. It can't get higher 21.10.02 # * gevaerts thinks more 21.10.31 # * gevaerts sees that the biggest MAX_BRIGHTNESS_SETTING for reasonably finished targets is 32 21.10.34 # the divisor can get lower. and lower divisors mean more ticks 21.11.03 # The divisor can get higher. 21.11.09 # MIN(X,40) means the smallest it can be is 40 21.11.14 # Er 21.11.18 # Biggest 21.11.29 # * Llorean is apparently not thinking well either 21.11.31 # Ignore me 21.11.38 # if X is <40, then X is taken 21.12.07 # let's just work this out... MAX_BRIGHTNESS_SETTING goes from 12 to 32 on involved targets 21.12.14 # X is 25 for the e200. This the number of ticks to wait between each fade step is HZ/25 (40ms) 21.12.18 Quit yhuang ("Leaving") 21.12.41 Quit raphi ("Verlassend") 21.13.16 # if you had X==20, it would be HZ/20 > 50ms 21.13.39 # MIN(_FADE_DELAY, 40) is always between 25 and 40, so FADE_DELAY is always between 2.5 and 4, so between 25ms and 40ms 21.14.18 # yea, until a target with <= 10 brightness levels comes in, that's true 21.14.18 # * gevaerts hopes that he's right this time... 21.14.37 # true, but we can solve that when we get there... 21.15.05 Join JdGordon| [0] (i=836b0055@gateway/web/ajax/mibbit.com/x-600b6f4f3674b259) 21.15.36 Join ibseco_ [0] (n=ibseco@BAH6efc.bah.pppool.de) 21.15.56 # * gevaerts can't rememver now, was fade length configurable, or was it always one step per timeout? 21.16.05 # it's not configurable 21.16.15 # 1 step per timeout 21.16.23 # death to configurability! 21.16.25 # ok, so the longest fade right now would be 800ms? 21.17.25 # huh? 21.17.54 # seems correct 21.18.27 # gevaerts: doing 1s would probably aid bandwith messurements too (if someone implements it) 21.19.24 # kugel: I was thinking about having the other side worry about all that, but I was probably wrong 21.20.06 # gevaerts: do I need logf for this? 21.20.30 # saratoga: not really. If it still goes wrong, we know where... 21.20.37 # (just not why) 21.20.40 Join MethoS- [0] (n=lem@dyndsl-085-016-163-078.ewe-ip-backbone.de) 21.23.11 Join [1]shawn [0] (n=shawn@203.199.114.33) 21.23.28 Quit [1]shawn (Client Quit) 21.24.14 Join ch4os [0] (n=ch4os@gentoo/user/ch4os) 21.24.28 # gevaerts: no change 21.24.40 # :( 21.24.43 # mounts but eventually disconnects during long transfers 21.24.52 Join bzed [0] (n=bzed@devel.recluse.de) 21.25.38 # gevaerts: I think I'll get rid of the calculation there, it's not so much cases anyway 21.28.51 # The problem with this USB issue is that it *does* work for a while, so a disconnect can easily cause filesystem corruption... 21.31.07 Quit ibseco (Read error: 113 (No route to host)) 21.31.07 Nick ibseco_ is now known as ibseco (n=ibseco@BAH6efc.bah.pppool.de) 21.31.38 # gevaerts: for what its worth, after about 15 of these my disk still passes check disk just fine 21.31.46 # maybe just luck though 21.31.51 # saratoga: yes, but you're just reading 21.32.00 # no i mean about 15 writing 21.32.05 # eventually i stopped doing that 21.32.08 # ah ok 21.32.33 # after I reformatted I didn't want to risk complicating our tests 21.32.42 # but before that i did many write tests, apparently without corruption 21.32.51 Join BdN3504 [0] (n=55b23de0@gateway/web/cgi-irc/labb.contactor.se/x-7142f5d608028c02) 21.34.57 # * gevaerts re-reads last night's log 21.35.36 # Hey, i have something strange to report: I'm using vmware and have compiled a build and when i change to that build directory and open the rockbox-info.txt file there is this line: r20252M-090311 which is weird because the vm tells me i checked out revision 20293 21.36.40 # saratoga: is that a dual-boot machine? i.e. are the working linux and xp setups the same hardware? 21.37.12 Quit MethoS-- (Read error: 113 (No route to host)) 21.37.20 Join Reptile211 [0] (n=chatzill@host-216-66-248-9.static.linkline.com) 21.37.32 Quit timc (Connection timed out) 21.39.33 # saratoga: did you ever see problems while actually writing, or only when reading? 21.39.34 Quit StealthyXIIGer (Connection timed out) 21.41.10 Join timc [0] (n=aoeu@124.93.243.83) 21.45.34 Quit Horscht ("Verlassend") 21.46.30 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.46.31 Quit BdN3504 ("CGI:IRC (EOF)") 21.46.40 Join nibbler_ [0] (n=Nibbler@pD9E33476.dip.t-dialin.net) 21.48.10 # gevaerts: reading and writing had the exact same issues 21.48.18 # i don't have linux on this machine but I could probably find a live cd 21.48.22 Join tessarakt [0] (n=jens@e180074044.adsl.alicedsl.de) 21.48.48 # that would be helpful. I'd really like to know if this is OS or hardware dependent 21.50.45 # ok i will try this live cd i found right now 21.51.35 Quit saratoga ("CGI:IRC (EOF)") 21.54.50 # bertik: kugel: I tried bertik's mmu patch. It seems the function calls are inside the "#ifdef BOOTLOADER" section. I moved them out and I can boot but the action is very slow as if dcache got disabled in the process 21.55.18 # er icache I mean 21.55.31 Quit Reptile211 ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]") 21.56.21 Quit barrywardell (Remote closed the connection) 22.05.31 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-380a65a9bb474ec7) 22.09.53 Nick BigBambi_ is now known as BigBambi (n=alex@rockbox/staff/BigBambi) 22.10.14 # kkurbjunW: I'm not sure whether 'I2C driver 10%' (OlympusMR500Info) is correct, the IC driver on the ZVM works rather good; there could be some issues with wrong clock setup but other than that it should work fine 22.11.25 # FlynDice: yep, that's what I assume too 22.11.57 # Bagder: is the build master stuck? 22.12.06 # mcuelenaere: I was just filling it out with a low number for now since I am not in front of the source to check. If there are other numbers that should be updated I am fine with that 22.12.26 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.12.31 # I was mainly just getting a place holder in there for now to start documenting areas that interested parties could look 22.12.52 # kkurbjunW: I'm not really asking to correct it, I was just wondering whether you knew of the DM320 IC driver 22.13.23 # gevaerts: looks like it, but it'll restart itself in a short while 22.13.45 # ah ok. I didn't follow development on that side very much lately... 22.13.46 # no, I haven't used it, I don't know if there is anything on the i2c interface for the m:robe 500 offhand 22.14.06 # thanks for the pointer in either case 22.14.35 # Bagder: did you add kugel.homedns.org? 22.14.53 # no, I missed that. We'll look into it immediately 22.15.18 # what port number? 22.15.35 Join jaykay [0] (n=chatzill@p579E6802.dip.t-dialin.net) 22.15.52 # kkurbjunW: oh, isn't there anything connected through IC with the M:Robe 500? 22.16.19 # the touchscreen is isnt it? 22.16.20 # Bagder: good question. I don't think I have specified a port. I never use a port when I ssh to my machine 22.16.26 # I'm not sure offhand, I think most things use the SPI interface 22.16.37 # "ssh: connect to host kugel.homedns.org port 22: Connection refused" 22.16.40 # JdGordon: I thought that was with SPI 22.16.49 # Bagder: yea, it's offline right now :) 22.16.49 # you're probably right 22.16.49 # * mcuelenaere would guess the RTC is, but he will check the source 22.16.55 # kugel: oh 22.17.03 # I think the RTC is SPI too 22.17.06 # kugel: all compilers and sdl installed? 22.17.08 # I'm right now turning it on, will take some minutes 22.17.13 # yes 22.17.26 # yeah, RTC is SPI too 22.17.44 # Are there many non-mips-enabled servers left? 22.17.59 # gevaerts: 10 something 22.18.17 # anyway, it would be nice if you could check whether my IC implementation is correct; that way I could eliminate at least one problem with the PIC on the ZVM :) 22.18.18 # but we only have two mips builds atm, it's not a big problem 22.18.41 # * gevaerts has a mips-enabled build server that's turned off... 22.18.44 # Bagder: the VX767 could get added too.. 22.18.49 # mcuelenaere: I'll check it out sometime - I just need to find something that uses it first :-D 22.18.57 # ok, no hurry :) 22.18.57 # mcuelenaere: I'll be happy to! 22.19.05 # well it doesn't compile currently :) 22.19.16 # the problem is, the only one I know with such a target is wpyh 22.19.20 # ah then I won't be as happy... 22.19.23 # kkurbjunW: feel like working on the flash loader? 22.19.32 # and I didn't got the LCD working with the little testing I did 22.19.53 # (it isn't easy to debug issues when not having the DAP next to you) 22.20.02 # grep -v "^#" config.pm | grep -c :mipsel 22.20.03 # 20 22.20.18 # grep -v "^#" config.pm | grep -c :arm 22.20.18 # 31 22.21.00 # JdGordon|: We need to do alot more initialization work first. As it stands I would be surprised if the LCD, sound, or external memory worked without the OF 22.21.10 # I do want to do it though 22.21.34 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 22.21.45 # but I think we need to get more of the lowlevel stuff done before it's worth trying to tackle 22.21.51 # what kind of fm chip does the mrobe have? 22.21.55 # meh, why doesn't it work? 22.21.58 # (assuming it has one) 22.22.18 Join _lifeless [0] (n=lifeless@90.151.42.77) 22.22.24 Join JdGordon| [0] (i=836b0055@gateway/web/ajax/mibbit.com/x-d9ab83b4dceab112) 22.22.30 # ah ok 22.23.03 # bertrik: to my knowledge the m:robe 500 doesn't have one 22.23.08 # the 100 might have one 22.23.47 # mcuelenaere: what is the pic used for on the ZVM? 22.24.08 # kkurbjunW: the pic used for what? 22.24.18 # kugel: I'm getting in a bit over my head here, can we massage the TTB_BASE_ADDR or map_section variables to make this work? 22.24.32 # oh there are multiple pics on the zvm? 22.24.32 # s/the pic used for what/what pic/ 22.24.37 # oh you mean the PIC? 22.24.49 # yeah 22.24.56 # * mcuelenaere assumed pic -> picture :P 22.25.02 # :) 22.25.34 # kkurbjunW: it's used for almost all user input (so buttons, touchpad, USB insert, power charger insert, etc) + backlight control and probably other stuff 22.25.43 # I think it's described on CreativeZVMPort 22.26.04 Join buk_ [0] (n=buk@fac34-2-82-228-151-145.fbx.proxad.net) 22.27.00 # kkurbjunW: http://www.rockbox.org/twiki/bin/view/Main/CreativeZVMPort#How_internals_are_connected 22.27.14 # oh gotcha 22.29.54 Join MethoS-- [0] (n=lem@host-091-096-209-136.ewe-ip-backbone.de) 22.32.25 Quit saratoga ("CGI:IRC (EOF)") 22.36.23 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 22.41.29 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 22.41.45 *** Saving seen data "./dancer.seen" 22.42.49 # LambdaCalculus37: did you get around to sending the ipod cable yet? 22.42.59 Quit arohtar (Client Quit) 22.43.12 Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) 22.43.22 # JdGordon|: I'm going to mail it tomorrow. 22.43.33 # Didn't have a chance to. 22.43.43 # ok, cool... no worries 22.43.51 # i havnt got my ipod back yet anyway so no rush 22.43.58 # just wondering if it was lost in the mail or what 22.44.13 # Ill fix up paypal tonight if i get a chance 22.44.31 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-6819a4608411782f) 22.45.59 # midgey: Ping 22.46.39 Quit MethoS- (Read error: 113 (No route to host)) 22.48.16 Quit archivator () 22.49.04 # gavaerts: same thing in ubuntu 22.49.09 # here is the dmesg output: http://pastebin.com/m3c61d82f 22.49.34 Quit kugel (Nick collision from services.) 22.49.39 Join kugel [0] (n=kugel@rockbox/developer/kugel) 22.49.54 Quit tvelocity ("Αποχώρησε") 22.50.24 # saratoga: Thanks. That at least means that I still understand a bit of this (i.e. that the logf output doesn't match something triggered by host OS behaviour) 22.52.02 # ok i have to run 22.52.05 Quit saratoga ("CGI:IRC") 22.52.37 # rasher: midgey's new patch at FS#9998 applies clean. I'm going to commit it now. 22.53.12 # Hello Again, all. I was wondering, does Rockbox have an app that can "talk" to DFUs of mp3 players? (thats either on the web or I can take a look at?) thanks 22.55.23 # taylor_: If it's a "real" DFU mode (as in, as per the spec) there should either be existing tools, or at least the specification that you can investigate. 22.55.52 # We have meizu_dfu in SVN, which can talk to the DFU mode of the Meizu M6 and M3 players. 22.56.00 # ok thanks. Do you know of any link readily available? or will I need to do a little googling? :P 22.56.12 # ok cool thanls! 22.57.22 # do you know if these are for linux? I guess ill take a look.... 22.58.46 # openmoko also has dfu tools 23.00.29 # and may I ask also...What exactly can you do with a DFU? other than obviously updating firmware 23.01.35 # We don't really use DFU in most cases. As far as I know ,all of our supported targets at least have non-DFU update modes, so far. 23.02.21 Part moos ("Rockbox rules the DAP world") 23.03.45 # Again, the DFU spec would be where to go to find out what you're *supposed* to be able to do in DFU 23.04.05 # Bearing in mind that the idea of someone strictly following the spec, outside of cases like OpenMoko, is probably pretty laughable. 23.05.15 # hmmmm can seem to find meizu_dfu. What branch is it under? (Im in SVN) 23.05.51 # taylor_: utils/meizu_dfu/ 23.06.33 # Ah ha.. Thanks Bagder! I was looking right at it ;) 23.07.49 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 23.11.57 Quit miepchen^schlaf () 23.12.19 # taylor_: hi, we can use the dfu mode to flash our firmware, but we can also abuse it to run our code directly without flashing 23.12.50 # Really? How so? 23.12.51 # at least it works like that for the Meizus 23.13.09 # it waits for 2 images. The first is the flash writer, the 2nd is the firmware 23.13.28 # instead of the flash writer we can just send our test code and it gets executed 23.13.44 # Hmmm 23.13.54 # Bagder: the VX767 should compile now, so you can add it to the build table 23.13.54 # I wonder if it would be that easy on the ipods. Prob not 23.14.20 # I guess not, but in the meizu case we are also lucky because nothing is encrypted 23.14.36 # True 23.14.41 # ipods are encrypted 23.14.42 # and since we have pretty much all the documentation it's a wonder we haven't finished the port yet :) 23.14.42 # too bas 23.14.44 # taylor_: AFAIK the iPods use a custom version of DFU 23.14.47 Join Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) 23.15.31 # the dfu tool from OpenMoko didn't work with the meizus 23.15.57 # markun: Do the meizus follow the DFU spec, or was there some changes from it? 23.16.18 # Llorean: I'm not sure actually. Maybe gevaerts knows? 23.17.01 # markun: I was able to get meizu_dfu to notice my 2nd gen nano by replacing the USB IDs. 23.17.02 # Maybe we should be careful about what we call "DFU mode" in cases where it's not actually DFU mode as described as a USB standard. 23.17.52 Join MethoS- [0] (n=lem@dyndsl-085-016-164-053.ewe-ip-backbone.de) 23.18.31 # * gevaerts has only committed meizu_dfu, he didn't make it work... 23.18.54 # Yes, that was wpyh's wizardry that made it work. 23.18.58 Nick taylor_ is now known as davidc__ (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 23.19.15 Nick davidc__ is now known as taylor__ (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 23.19.33 # * Llorean just suddenly realized he hasn't yet gotten a response from admin@usb.org 23.21.05 Quit {phoenix} (Remote closed the connection) 23.21.05 # it is annoying when organizations fulfill those bad expectations you have... 23.21.06 Quit taylor__ ("Leaving") 23.21.30 # Llorean: afaiu (from what gevaerts have said about it) the dfu spec is only about the transfer protocol, not what is transferred or what the device does with it 23.21.36 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 23.22.24 Join timc`` [0] (n=aoeu@124.93.243.83) 23.22.45 # n1s: That would still be a standard though. I'm just curious if our "dfu" tool should be abstracted rather than being device specific, or if we should remove the "dfu" from the name. 23.23.57 # kugel: http://forums.rockbox.org/index.php?topic=20914 might be of interest. 23.24.04 Quit jaykay (Read error: 110 (Connection timed out)) 23.24.08 Quit MethoS-- (Read error: 60 (Operation timed out)) 23.25.00 Part CaptainKwel 23.26.49 Quit BUMBACL0T () 23.29.51 Quit avis (Remote closed the connection) 23.30.48 # Llorean: he came here today, and he pretty much said FS#7423 is his issue. 23.31.13 # I cannot reproduce it just by inserting and inserting as next in random sequence 23.31.24 # but the post is newer than that and says the 7423 patch doesn't help 23.31.31 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 23.31.33 # Are you following his recipe there? 23.32.39 Quit LambdaCalculus37 ("hungry!") 23.32.44 Quit jgarvey ("Leaving") 23.34.06 # what unit does cycles have in __timer_set() ? 23.35.16 # mcuelenaere: is usb working on the ZVM? 23.35.27 # kkurbjunW: no 23.35.40 # Llorean: I cannot reproduce using his recipe 23.35.43 # it does yield some packets on enumeration 23.35.46 # but it stops for some reason 23.36.01 # I can only reproduce FS#7423 23.36.42 # kkurbjunW: how's USB connected with the core on the M:Robe? On the ZVM this is through EMIF 23.37.15 # I'm not really sure at all, USB is an unfamiliar territory for me 23.37.28 Quit intrados (Read error: 60 (Operation timed out)) 23.37.28 # I'm trying to figure out where I would start to implement it 23.37.56 # there's another chip on the board that sits between the SOC and the computer 23.38.07 # the computer? 23.38.20 Quit tyfoo (Read error: 104 (Connection reset by peer)) 23.38.29 # well, you have the computer, a USB cable, then a controller, and then the DM320 23.38.43 # is EMIF an interface on the DM320? 23.38.48 # Could be a separate PHY 23.38.56 # kugel: I've asked him to clarify the recipe. He's slightly imprecise. 23.39.18 # kkurbjunW: EMIF = External Memory Interface 23.39.25 # don't you have the DM320 data sheets? 23.39.28 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 23.39.34 Quit timc (Connection reset by peer) 23.39.36 # gevaerts: it's this Renesas device: http://documentation.renesas.com/eng/products/assp/rej03f0101_m66591ds.pdf 23.39.39 # not on hand 23.40.07 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 23.40.31 # kkurbjunW: 'not on hand' -> is that to me? 23.41.09 # I would guess it is connected as an external memory interface based on the data/address lines from the device.. mcuelenaere, yeah, I don't have them available at the moment 23.41.30 # but you do have access to them? 23.43.09 # well, I have access to what I have in other places.. as far as the total scope of the DM320 documents potentially available, I am not sure specifically what I have. 23.43.52 # kkurbjunW: that's apparently the full USB controller. Nice to see that you have a full datasheet :) 23.44.37 # kkurbjunW: but you have access to the NDA datasheets, right? If not, you should mail Catalin/Neuros 23.44.53 # I mailed Catalin and he forwarded me to someone at Neuros, who gave me them 23.45.34 # gevaerts: quite possibly there are even linux drivers for it 23.45.50 # :), gevaerts, what does that mean in terms of implementing the software usb interface? I've been looking at the existing implementations and I'm not sure exactly where to start.. 23.46.34 # kkurbjunW: you should ask mcuelenaere. I've never started a rockbox driver from scratch... 23.47.10 # Bagder: true. I guess I should also look there to see if I find hints about this PP USB issue saratoga and others are seeing... 23.47.52 # kkurbjunW: the first step is finding out how to communicate with the USB controller, then try receiving some EP0 SETUP packages 23.49.40 # Llorean: more precise than the usual recipes though 23.49.44 # kkurbjunW: CS3 starts at 0x50000000, CS4 at 0x60000000 23.50.32 # mcuelenaere: I'll have to ask cat about talking to it, he had done some initial USB work on linux for the renesas controller. 23.50.44 # oh so you already know how to talk to it 23.51.00 # I'm not sure exactly how far cat got with it 23.52.03 # * mcuelenaere looks at cat's site 23.56.02 # There's this branch, but I'm not sure what was changed offhand, when I get home I'll check it out relative to another branch and see what the difference is: http://svn.devjavu.com/mrobefan/mrobe-bsp/branches/cat-usb/ 23.56.34 # hm, the linux driver for this ARC controller doesn't do as much error handling as we do... 23.57.43 Join MethoS-- [0] (n=lem@dyndsl-085-016-166-239.ewe-ip-backbone.de) 23.57.43 Quit timc`` (Connection timed out) 23.58.15 # * mcuelenaere wonders why everyone (except neuros) seems to pick an external USB chip instead of using the one already on-board in the DM320.. 23.58.32 # speed? 23.58.58 # * Bagder recalls neuros osd1 and usb problems being a frequent subject