--- Log for 23.11.113 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 16 days and 18 hours ago 00.02.44 # mortalis: (log) please test if g#364 works for you. 00.02.46 # 3Gerrit review #364 at http://gerrit.rockbox.org/r/364 : 3rk27xx: implement usb driver by Marcin Bukat (changes/64/364/14) 00.02.55 Quit wodz (Quit: Leaving) 00.03.46 Quit Narod () 00.20.11 Quit benedikt93 (Quit: Bye ;)) 00.26.25 Quit krabador (Quit: Sto andando via) 00.30.55 Join krabador [0] (~krabador_@unaffiliated/krabador) 00.49.28 Quit kugel (Ping timeout: 240 seconds) 00.50.12 Join megakacktus [0] (~megakackt@65-128-206-8.mpls.qwest.net) 00.50.26 Part megakacktus 01.10.09 # maybe the radio chip caused a regression, it did at some point in the sansas IIRC 01.10.38 # <[Saint]> That wouldn;t explain the Classic. 01.11.10 # would that explain something on the fuze+ ? As far as I know the chip is powered down when unused 01.11.15 # <[Saint]> Unless we're actually looking at several regressions. 01.11.32 # <[Saint]> Which is highly possible. 01.11.57 # <[Saint]> Unfortunately, there was a period about a year ago where commits were added extremely hastily. 01.12.04 # bertrik: by the way, not sure you remember, is there a power down mode on the stfm1000 ? Because that might explain the poor battery life on the NWZ: they both have the stfm1000 and no tuner power gpio as far as I can tell 01.12.12 # <[Saint]> I believe this is most of the reason why the skin engine is in a giant mess. 01.12.37 # pamaury: no I don't remember 01.13.00 # well, a lot could be said and has already been said on the ski engine 01.13.04 # *skin 01.13.22 Quit bertrik (Remote host closed the connection) 01.13.53 # <[Saint]> I try to negate any issues that may arise there these days by using nothing but the fallback theme 01.13.55 # the fact that it breaks usb is very annoying and I should definitely have a look at it but that will mean hard debugging of some code I don't know 01.14.19 # I wonder if the use of the MMU for debug purpose could help 01.14.28 # <[Saint]> gevaerts and funman did some work in that area. 01.14.33 # <[Saint]> skin engine breakages, I mean. 01.14.55 # Like having a special define which enhance the memory allocator from kugel with some MMU setup, to trap invalid accesses 01.16.06 # I have plenty of ideas in this direction, and I think we could improve the situation much 01.16.32 # * pamaury wishes he could duplicate himself 01.20.58 Quit chrisjj (Quit: Page closed) 01.32.51 Quit toffe82 (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) 01.38.41 *** Saving seen data "./dancer.seen" 01.40.49 Join treaki__ [0] (~treaki@p4FF4BECB.dip0.t-ipconnect.de) 01.43.45 Quit treaki_ (Ping timeout: 272 seconds) 01.58.16 Quit n1s (Quit: Ex-Chat) 02.17.13 # <[Saint]> http://forums.rockbox.org/index.php/topic,43664.msg221527.html#msg221527 is very interesting. 02.17.18 Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 02.17.41 # <[Saint]> The "Prison CLip" apparently has a HW key combo for "nuke firmware". 02.18.29 # and who cleans up the radiation? 02.31.03 Join onder` [0] (~onder@dyn-dsl-to-76-75-106-228.nexicom.net) 02.46.03 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 02.49.29 # Anyone still awake? :) 02.50.10 # <[Saint]> You know better than that by now - no need to ask such things. 02.50.25 # <[Saint]> Ask your question, if anyone can help, they will. 02.50.30 # I'm learning slowly :) 02.51.02 # Thanks. Where can I find the daily build of firmware-zen.nk? 02.53.51 # Or for that matter, any build that includes this commit: http://git.rockbox.org/?p=rockbox.git;a=commit;h=bb8dd053434cbe9c98fe5b9a1095d00ebafb7b61 02.54.00 # chrisjj: there is no daily build for firmware-zen.nk 02.54.17 # we don't provide complete daily builds for the bootloaders 02.54.54 # however if you are looking for the daily build of the main firmware, here it is: http://build.rockbox.org/data/rockbox-creativezen.zip 02.55.36 # or do you want to update the bootloader ? 02.57.11 # Yes, I want to update the bootloader. 02.57.42 Quit krabador (Quit: Sto andando via) 02.57.45 # is there an issue with the bootloader ? 02.59.29 # The issue for which I'm seeking a fix is http://forums.rockbox.org/index.php/topic,13462.msg221277.html#msg221277 . 03.00.39 # ah I see, ok I will upload a new build at the same address as previously 03.03.15 # Thanks A. 03.04.01 # I'm uploading, it will take some time with my poor connection here 03.12.27 # damn, one hour expected before completion 03.15.20 # Thanks A - I'll look forward to trying it in the morning. Off to bed... 03.16.53 Join krabador [0] (~krabador_@unaffiliated/krabador) 03.27.48 Quit [Saint] (Remote host closed the connection) 03.29.52 Join [Saint] [0] (~saint@rockbox/user/saint) 03.31.12 # dammit, dropbox decided to ask for my credential in the middle of the transfer, nice... 03.38.43 *** Saving seen data "./dancer.seen" 03.43.43 Quit pamaury (Ping timeout: 246 seconds) 03.49.14 Quit krabador (Read error: Connection reset by peer) 03.58.51 Join krabador [0] (~krabador@unaffiliated/krabador) 03.59.08 Quit krabador (Read error: Connection reset by peer) 04.31.36 Quit amiconn (Disconnected by services) 04.31.37 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.31.40 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.31.48 Quit pixelma (Disconnected by services) 04.31.50 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.31.52 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.52.00 Join qazwsxedc [0] (44bf2bb6@gateway/web/freenode/ip.68.191.43.182) 04.54.45 # Hello, I'm having some difficulty installing Rockbox on my player and I didn't find anything helpful in the FAQ: 04.55.43 # When I try to install, it keeps telling me that I need to provide a version of the device's firmware; however, no guides I found mention this step at all, and their installations don't require it at all. 04.56.20 # I have a Sandisk Sansa Clip Zip. I apologize if I missed something in the FAQ but any help would be appreciated. 04.59.34 # <[Saint]> The Rockbox manual mentions it clearly, and the installer should point you exactly where you need to go. 05.00.04 # <[Saint]> ANy information that doesn't come from Rockbox itself is irrelevant. 05.01.56 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 05.04.06 # <[Saint]> Rockbox Utility should simply be saying "you need an original firmware", it should also provide you with the link to acquire it. 05.04.53 # <[Saint]> You should be presented with a page with two downloadable choices, the Sansa Firmware Updater (which we don;t care about), and a Manual Firmware Update - the latter is what you want. 05.06.17 # <[Saint]> The Rockbox Clip Zip manual definitely supplies a link to access a firmware file. That much is certain. 05.06.49 Quit TheSeven (Read error: Operation timed out) 05.07.20 # Thanks a ton, Saint. I'm all set now. I apologize for asking such a simple question; I should have done more thorough research. 05.09.22 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.13.52 Join syscrash [0] (~syscrash@poipu/developer/syscrash) 05.24.09 Quit Raptors (Quit: Leaving) 05.35.23 Quit [Saint] (Remote host closed the connection) 05.37.14 Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) 05.37.28 Join [Saint] [0] (~saint@rockbox/user/saint) 05.38.45 *** Saving seen data "./dancer.seen" 05.40.19 Quit kevku (Ping timeout: 260 seconds) 05.41.34 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 05.56.58 Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) 06.21.08 Quit qazwsxedc (Quit: Page closed) 06.59.52 Join pretty_function [0] (~sigBART@123.252.215.188) 06.59.53 Quit pretty_function (Client Quit) 07.05.10 Quit ps-auxw (Remote host closed the connection) 07.20.11 Quit [Saint] (Remote host closed the connection) 07.23.52 Join [Saint] [0] (~saint@rockbox/user/saint) 07.30.07 Quit [Saint] (Read error: Connection reset by peer) 07.30.19 Quit foolsh (Quit: foolsh) 07.31.14 Join [Saint] [0] (~saint@rockbox/user/saint) 07.37.27 Quit cmhobbs (Ping timeout: 272 seconds) 07.38.46 *** Saving seen data "./dancer.seen" 07.39.51 Quit kiwicam (Remote host closed the connection) 07.50.40 Quit saratoga (Ping timeout: 250 seconds) 07.51.32 Quit JdGordon (Ping timeout: 250 seconds) 07.57.10 Quit chrisjj (Ping timeout: 250 seconds) 09.20.59 Join onder`_ [0] (~onder@dyn-dsl-to-76-75-106-228.nexicom.net) 09.21.50 Quit onder` (Ping timeout: 246 seconds) 09.21.56 Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-106-228.nexicom.net) 09.38.50 *** Saving seen data "./dancer.seen" 09.42.15 Quit kevku (Ping timeout: 245 seconds) 09.44.33 Join lorenzo92 [0] (~chatzilla@host101-104-dynamic.7-79-r.retail.telecomitalia.it) 09.45.21 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 09.45.21 Quit bertrik (Changing host) 09.45.21 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.55.16 Join Ward [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 09.55.39 Nick Ward is now known as Guest71608 (~Mirandaha@176-120-190-109.dsl.ovh.fr) 09.57.27 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 10.03.25 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 10.12.20 Quit y4n (Disconnected by services) 10.12.26 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 10.17.17 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 10.37.10 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 10.40.35 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 11.10.21 Quit bertrik (Remote host closed the connection) 11.20.28 Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 11.34.36 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.37.02 Quit Guest71608 (Quit: Blarglarg) 11.38.53 *** Saving seen data "./dancer.seen" 12.12.27 # pamaury: Fuze+ battery bench with revision c4f2a46 from July 23, 2013 (LAME V0, -20 dB, ear buds attached): https://outpost.fr/tmp/LUN.txt 12.12.34 # 41h 17m :D 12.13.10 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 12.17.56 # so we lost over 10 hours of battery life 12.18.59 # Fuze+ with a recent build, 30h 20m: https://outpost.fr/tmp/laE.txt 12.19.50 # I just started a battery benchmark on the Clip+ with the latest revision, lossyFLAC, -24 dB and ear buds attached (like my Classic) 12.20.16 # and after that's completed, I'll start over with the same year old revision as on the Classic 12.23.23 Quit kevku (Read error: Connection reset by peer) 12.34.26 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.34.43 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 12.47.08 Quit lorenzo92 (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) 13.31.32 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.32.58 # copperm some sort of current monitoring will be a lot faster if you're trying to track down what caused the loss 13.33.05 # copper: ^ 13.33.53 # copper: thanks 13.38.23 # n1s: if you have a solution we'll be happy to ear it 13.38.55 *** Saving seen data "./dancer.seen" 13.40.32 Join krabador [0] (~krabador_@unaffiliated/krabador) 13.40.53 # pamaury: saratoga set up some current monitoring for a sansa. I'm not sure of the exact setup but i think he used some rather nice lab equipment but a regular multimeter should be enough to see a ~30% increase in power draw i think 13.41.23 # I'm abroad, I don't have access to any equipement 13.41.41 # n1s: a multimeter connected to what? 13.42.45 # copper: best would be in a battery lead. or if it runs without a battery, on the usb cable 13.42.59 # copper: assuming you setup the power charger correctly, you can probably do it using a modified usb cable and a multimeter 13.43.36 # I'm afraid that's above my pay grade 13.43.54 # the theory is simple: cut the usb cable, put a high precision resistor on the 5V+ line and mesurement the voltage drop 13.44.00 # pamaury: some pmus can give you the current draw too, have you checked if whatever is in the fuze+ can? 13.44.07 # *measure 13.45.11 # yes, it cannot 13.45.15 # I have a cheap (and old) multimeter, but I don't have either a spare USB cable, nor any other means of doing that 13.45.33 # if it could we wouldn't be loosing that amount of time on benchmark 13.45.58 # or at least I'm not aware of any way to measure it 13.46.15 # I should probably try a test_codec 13.46.39 # erm, maybe not 13.46.41 # I don'tk now 13.47.54 # right now I'm really curious to see if my Clip+ shows a battery life regression too 13.48.31 # if that were the case, could we rule out and target specific commits? 13.48.49 # copper: did you start the test ? 13.48.54 # (the case being, three different targets showing the regression: Clip+, Fuze+ and iPod Classic) 13.49.05 # yeah I started the Clip+ test an hour ago 13.49.21 # s/and/any/ 13.50.10 # ah crap 13.50.19 # I should have started the Clip+ benchmark earlier 13.50.28 # now it's probably going to complete after I go to bed 13.50.49 # by the way, mine is finished too 13.50.57 # and? 13.52.06 # I need to do some additions, I had to stop and restart battery bench several times ^^ 13.52.22 # 30h 13.52.34 # so we have a peak battery life in july 13.52.35 # uh? no change from your previous benchmark? 13.53.21 # I didn't expected to reach 40h anyway because in january we were missing some of the power management stuff 13.53.41 # it's probably chance that the two are 30h 13.54.01 # I don't understand: didn't you get 30 hours with a recent build? 13.54.16 # yeah, and 30hour with a very old 13.54.34 # oh, so you didn't run one with the July revision? 13.54.47 # no, you did ;) 13.54.50 # ah ok 13.55.38 # I had you bench the recent one to see if your batteries were comparable and since they are (~30h with HEAD), we can benh different revisions and get consistent results 13.55.45 # if I see the regression on the Clip+, I'll be able to run more benchmarks on that 13.56.02 # I don't really want to run more benchmarks on the Fuze+ and iPod Classic 13.56.12 # My fuze+ is recharging, when it's done I will pick a revision between july and now 13.56.27 # And run another revision on my second fuze+, do a trichotomy 13.56.33 # nice 13.57.51 # ah good, I *knew* I had bring two micro usb cables, I have been looking for the second one since the beginning of my stay 13.58.10 # then maybe I could run a couple more benchmarks on my Fuze+: you could tell me what revision to test, while you're testing a different one 13.59.07 # as you wish, if you prefer not to run too many benh on your Fuze+ that's no problem 13.59.32 # as you wish, if you prefer not to run too many benh on your Fuze+ that's no problem 14.09.29 Quit nosa-j (Ping timeout: 272 seconds) 14.10.40 Join nosa-j [0] (~m00k@66.233.224.206) 14.30.04 Quit nosa-j (Ping timeout: 246 seconds) 14.41.40 Quit krabador (Quit: Sto andando via) 14.47.30 Join mortalis [0] (~mortalis@77.108.98.176) 14.48.56 Join nosa-j [0] (~m00k@66.233.224.206) 14.53.30 Quit kevku (Ping timeout: 245 seconds) 14.53.45 Join ender` [0] (krneki@foo.eternallybored.org) 15.00.17 Quit nosa-j (Ping timeout: 246 seconds) 15.00.53 # pamaury: I'm about ready for another Fuze+ battery benchmark 15.02.05 # er, bbiab 15.08.57 Join nosa-j [0] (~m00k@66.233.224.206) 15.14.15 Quit nosa-j (Ping timeout: 264 seconds) 15.14.23 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 15.25.21 # copper: so here is it: you benchmarked c4f2a46, HEAD is at fb8faa1, there are 237 commits in between. I suggest we split evenly in four: 15.25.21 # c4f2a46 < a2a2e14 < 6ac481e < 5cfb148 < fb8faa1 15.25.21 # I will benchmark a2a2e14 and 5cfb148, and you can do 6ac481e, ok ? 15.25.58 Join nosa-j [0] (~m00k@66.233.224.206) 15.27.27 # pamaury: deal 15.27.46 # brb 15.30.13 Quit nosa-j (Read error: Operation timed out) 15.30.33 Quit K1773R (Quit: /dev/null) 15.30.34 # pamaury: i read up alittel on the imx233 pmu and it seems to be possible to just tell it to run off of 5V no matter what so probably no need to physically alter the device to do the usb cable current measurment thing, perhaps some pmu config changes are needed though, i didn't check the code 15.30.49 # s/alittel/a little/ 15.31.50 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 15.32.08 Quit pamaury (Ping timeout: 246 seconds) 15.33.20 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 15.33.59 Join nosa-j [0] (~m00k@66.233.224.206) 15.38.58 *** Saving seen data "./dancer.seen" 15.42.59 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 15.43.25 # n1s: yes I know, that's my plan but at the moment I'm abroad and I don't have the tools to build such a cable 15.45.46 # I'm wondering, as anyone thought about porting rockbox to qemu ? that way you still get a native target but running inside a box makes it easier to debug 15.46.21 # I think there was a GSoC about it, right ? 15.47.37 # ah it was abandonned 15.47.49 Join matthiaskrgr [0] (matthiaskr@gateway/shell/panicbnc/x-yhiphryeepjsreql) 15.48.17 Part matthiaskrgr 15.51.14 # I see to recall there was a path on FS but I can't find it 15.52.43 # gevaerts: ^ do you know ? 15.57.25 Quit kugel (Ping timeout: 272 seconds) 16.06.37 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 16.13.37 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 16.13.44 Quit cmhobbs (Changing host) 16.13.44 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 16.24.46 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 16.26.00 # pamaury: I tried running rb in jz-qemu long time ago but I lost interest. 16.26.41 # that's mips ? 16.27.14 # yeah 16.27.52 # My plan would be to have an arm target with (possibly) dual role usb. I know qemu support usb host and I think implementing usb device with projects usb-vhci is doable 16.28.00 # pamaury: mortalis checked and ZLP fix didn't fix problems on his box 16.29.36 # pamaury: What is the purpose of dual role usb qemu target? 16.29.47 # play with usb host ^^ 16.30.05 # oh, I thought you want to fix something :P 16.30.15 # yeah I need usb device to fix something 16.30.31 # we know most of the breakage comes in when you plug usb 16.32.30 # I'm wondering what is best: 1) port qemu to some rockbox supported target (like imx233) 2) port rockbox so some qemu supported target 16.33.13 # wait you want to couple two qemu instances one with host and second with device emulations? 16.33.39 # no, you have one qemu instance which acts as a virtual usb device 16.33.55 # the problem is that you need to convince linux it's a real device :) 16.35.17 # (though coupling two qemu instances like this would be fun) 16.38.00 # I think implementing rb supported target in qemu is easier after all. From my experience with jz emulation you have to dive into qemu internals anyway since most targets are emulated only in part needed to boot linux in default config 16.38.17 # We usually configure hardware differently. 16.38.57 # yeah that's true 16.39.27 Quit thomasjfox (Quit: Konversation terminated!) 16.42.08 # pamaury: Comming back to rk27xx usb I am out of ideas. On my box current driver works reasonably stable, comparably to OF for sure. 16.44.27 # how bad does it fail on mortalis's box ? Under normal circumstances or when spamming the device ? 16.45.02 # Last time it failed in normal copying of the file 16.46.10 # I copied a few times in row of varying sizes 10-900MB and all succeeded (checked md5sums) 16.46.24 # *files 16.46.47 # did you try with windows ? 16.47.40 # No, but I can later today. I happens I have w7 box from my work 16.48.16 # I'm out of ideas too, I really don't know what it could be 16.48.58 # Since it's random that would suggest memory corruption or cache problem or non-atomic operations being interrupted by an irq, but I can't spot any in the current code 17.00.43 Quit mc2739 (Quit: leaving) 17.06.47 # how do I get git to revert to the latest revision, after running "git checkout XXXXXXXXXXXXX"? 17.07.02 # "You are not currently on a branch. Please specify which branch you want to rebase against." 17.07.11 # "git pull --rebase" doesn't work 17.07.22 # it wants me to run "git pull " 17.07.34 # wodz: pamaury: it fails with the same test as before - dd if=/dev/urandom of=/media/5AEC-DD59/test bs=1M count=1024 17.08.07 # copper: doesn't git checkout HEAD do it? 17.09.52 # that command completes successfully but doesn't print anything; and then, git pull --rebase still doesn't work 17.10.05 # copper: git reset --hard origin/HEAD 17.10.13 # this will erase all modifications you might have 17.10.27 # git pull --rebase still doesn't work 17.10.37 # "You are not currently on a branch" 17.10.56 # are you in a rebase or a merge ? 17.11.13 # no idea 17.11.39 # even after the hard reset ? that's strange 17.11.49 # try git rebase --abort ? 17.11.59 # copper: "git checkout master" probably is what you want 17.11.59 # No rebase in progress? 17.12.14 # ah yeah you are not in any branch 17.12.17 # mortalis: thank you, that did it 17.12.51 # ok, so the procedure is: "git checkout XXXXXXXXX" to try an older revision, and then "git checkout master" to get back to the latest revision? 17.13.50 # that one possible way 17.14.56 # mortalis: 1) is HID turned off? 2) Have you tried regular file copy? 17.15.08 # mortalis: 3) What system? 17.20.19 # wodz: 1. yes 2. no 3. What exactly do you want to know? 17.21.15 # mortalis: win/linux/bsd 17.21.22 # linux 17.21.28 Join einhirn [0] (~Miranda@p4FF89FFA.dip0.t-ipconnect.de) 17.22.02 # sorry, the first answer was wrong, HID turned on 17.25.06 Join einhirn_ [0] (Miranda@bsod.vpn.tu-clausthal.de) 17.26.01 Quit einhirn (Ping timeout: 265 seconds) 17.26.21 # mortalis: Could you try with HID turned off? 17.26.43 # yes, i'm trying it now 17.28.00 # wodz: failed 17.28.39 # damn 17.28.45 # and device hang 17.29.52 Quit pamaury (Ping timeout: 252 seconds) 17.38.12 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.39.02 *** Saving seen data "./dancer.seen" 17.52.52 Quit mortalis (Ping timeout: 248 seconds) 17.54.13 Join mortalis [0] (~mortalis@77.108.98.176) 18.02.28 # wodz: ihifi 760 passed dd test 18.03.03 # mortalis: thats interesting 18.04.36 # iirc on ihifi rk2705 18.04.43 # 2706 on hifimans 18.05.18 # maybe that the reason of different behavior 18.06.17 # mortalis: Who knows. AFAIK pamaury's rk dap is 2706A 18.06.53 # and now it failed 18.09.07 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.12.26 Join Narod [0] (Narod@p5DDDB2AD.dip0.t-ipconnect.de) 18.17.54 # copper: bench started, I had to switch to 78c060b for the second one because the build was broken 18.23.45 # currently running 6ac481e 18.27.42 Quit wodz (Ping timeout: 246 seconds) 18.38.02 Join rela [0] (~x@pdpc/supporter/active/rela) 18.44.17 Quit rela (Ping timeout: 245 seconds) 18.50.27 Quit Narod () 18.51.57 Quit cmhobbs (Ping timeout: 272 seconds) 18.59.15 Join Narod [0] (Narod@p5DDDB2AD.dip0.t-ipconnect.de) 19.03.16 Quit nosa-j (Ping timeout: 248 seconds) 19.05.48 Join nosa-j [0] (~m00k@66.233.224.206) 19.17.55 Join rela [0] (~x@pdpc/supporter/active/rela) 19.21.19 Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) 19.37.42 Nick syscrash is now known as jvd (~syscrash@poipu/developer/syscrash) 19.39.05 *** Saving seen data "./dancer.seen" 19.40.07 Part jvd 19.45.01 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 20.05.11 Quit mortalis (Remote host closed the connection) 20.11.56 Join Tukeke [0] (~Tukeke@unaffiliated/hlvsv) 20.15.02 Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 20.16.14 Quit gevaerts (Ping timeout: 245 seconds) 20.16.20 Quit evilnick (Ping timeout: 246 seconds) 20.19.15 # * pamaury spots some dubious calculations in buflib 20.20.33 # ah I see, the code doesn't what the doc says, nice 20.20.33 Join lorenzo92 [0] (~chatzilla@host160-109-dynamic.44-79-r.retail.telecomitalia.it) 20.37.20 # that would be too easy, wouldn't it? 20.38.00 Quit y4n (Quit: PÆNTS ØLF!) 20.42.44 Quit nosa-j (Ping timeout: 265 seconds) 20.43.25 Join nosa-j [0] (~m00k@66.233.224.206) 20.46.33 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 20.47.28 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 20.52.00 Quit nosa-j (Ping timeout: 272 seconds) 20.53.25 Join nosa-j [0] (~m00k@66.233.224.206) 20.58.10 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 20.58.35 Quit mc2739 (Client Quit) 21.02.26 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 21.13.39 Quit gevaerts (Ping timeout: 264 seconds) 21.13.40 Join evilnick_ [0] (~evilnick@d54C37FA5.access.telenet.be) 21.13.44 Quit evilnick (Ping timeout: 245 seconds) 21.15.33 # is the recording level trigger screen active even when no encoders are available? i.e. can I see some level monitoring when speaking into the microphone? 21.15.36 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 21.17.09 # lorenzo92: at least on coldfires you can 21.17.38 # thanks, because I have to debug audio in without having any storage yet ^^ 21.24.28 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 21.25.00 Quit gevaerts (Disconnected by services) 21.25.04 Join gevaerts_ [0] (~fg@rockbox/developer/gevaerts) 21.25.34 Nick gevaerts_ is now known as gevaerts (~fg@rockbox/developer/gevaerts) 21.26.12 Quit evilnick_ (Ping timeout: 272 seconds) 21.26.35 Join kiwicam [0] (~quassel@121.99.176.30) 21.39.03 Quit gevaerts (Read error: Operation timed out) 21.39.09 *** Saving seen data "./dancer.seen" 21.39.13 Join evilnick_ [0] (~evilnick@d54C37FA5.access.telenet.be) 21.39.32 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 21.40.24 Quit evilnick (Ping timeout: 272 seconds) 21.41.22 Quit cmhobbs (Ping timeout: 245 seconds) 21.49.19 Quit gevaerts (Disconnected by services) 21.49.22 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 21.49.24 Join gevaerts_ [0] (~fg@rockbox/developer/gevaerts) 21.49.49 Nick gevaerts_ is now known as gevaerts (~fg@rockbox/developer/gevaerts) 21.50.00 Quit evilnick_ (Ping timeout: 246 seconds) 22.02.12 Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) 22.03.21 Quit bluebrother (Disconnected by services) 22.03.26 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.07.00 Quit fs-bluebot (Ping timeout: 272 seconds) 22.08.34 Join fs-bluebot [0] (~fs-bluebo@g231120131.adsl.alicedsl.de) 22.24.11 Join shadows [0] (lucent@unaffiliated/shadows) 22.39.03 Quit Narod () 22.46.30 # hmm, why my commits didn't trigger buildround? 22.46.52 # sometimes the bot is late 22.47.43 # build status also doesn't see the commits 22.48.28 # there is something seriously wrong with gcc: if(a >= -b) {}, a is of type intptr_t and b of type size_t, gcc warns against signed vs unsignec comparison 22.48.40 # so now, someone, explains me how on earth is -b unsigned 22.49.12 # Maybe it first optimises that to a Well, I hope not 22.49.36 # * gevaerts hopes gcc has had more coffee than he had today :) 22.50.23 # Anyway, I'd say something that's always negative is just as unsigned as something that's always positive 22.51.35 Join Narod [0] (Narod@p5DDDB2AD.dip0.t-ipconnect.de) 22.51.35 Join Gallomimia [0] (~gallomimi@209.87.18.21) 22.51.52 # err, what? -(-3) vs -(3) 22.53.52 # btw. playing with rk27xx usb patch I sometimes (read as quite frequently) trigger backlight state corruption 22.53.58 # on disconnect 22.55.05 # the usb core uses an inherently unsafe dma on rk27xx, you cannot limit the amount of received data 22.56.37 # heh, true 22.58.04 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 22.58.04 Quit cmhobbs (Changing host) 22.58.04 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 22.58.10 # but still under normal conditions corruption should be pretty rare 22.58.23 # what is the suggested filesystem to use on large (128gb) microsd storage? 22.58.49 # shadows: If you mean rockbox you have no choice. rb supports only fat 22.59.04 # ah okay 23.00.21 # pamaury: (signed vs unsigned) more interesting is if emitted assembly is correct. 23.01.21 # if it fails on such a trivial statement, I'm wondering whether we should really use it :) 23.02.14 Quit kiwicam (Remote host closed the connection) 23.03.03 # pamaury: Any alternative? clang would be nice but f***sup interrupts handlers on arm 23.03.26 # not speaking about support for SH and coldfire 23.04.33 # you should try to add support for interrupt handlers on arm in llvm then ;) 23.04.45 # pamaury: Do you have any comments about 'structural' changes to hwstub in g#667 23.04.47 # 3Gerrit review #667 at http://gerrit.rockbox.org/r/667 : 3hwstub rk27xx port WIP by Marcin Bukat (changes/67/667/3) 23.07.08 # wodz: http://comments.gmane.org/gmane.comp.compilers.clang.scm/82641 23.07.26 # not sure what is the status but it appears clang may support it now 23.07.37 # let me see 23.08.10 # btw. my dap just passed dd if=/dev/urandom of=/media/845B-E8E3/test bs=1M count=1024 with write speed 1.9MB/s 23.09.24 # wodz: you should remove the #if 0 code about HWSTUB_INFO_STMP in target.c 23.09.59 # if for some reason it may be useful to know details about the rk27xx revision, you can create your own request for target information 23.10.13 # like HWSTUB_INFO_RK27 23.15.57 # pamaury: for now I can think of returning known rk27xx variant (A or B). The code for this is in place but I don't know it is worth separate command for now 23.16.49 # I'm reviewed the patch, mostly it would be nicer if udelay() was moved to target.c and named target_udelay() to match target.h 23.17.01 # as you wish 23.17.03 # oh 23.18.17 # maybe make this request more general as HWSTUB_INFO_SOC or something and return target specific info (regardless of how it is structured) 23.18.18 Quit rela (Read error: Connection reset by peer) 23.18.59 # wodz: yeah that's would make sense since there is TARGET to know the target 23.19.13 # that would be part of another commit preferably 23.21.21 # pamaury: The patch is based on version where target_udelay() was not in target.h 23.21.46 # pamaury: I need to sync to see what changed as well 23.21.47 # ah, hum, then maybe I forgot to commit it ? 23.22.01 # no, git.rockbox.org see it 23.22.02 # ok 23.23.45 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 23.24.08 # wodz: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/089919.html 23.24.20 # apparently interrupt are supported by clang now 23.24.28 # as of october, 1 23.24.44 # hwstub is good candidate to test :-) 23.27.01 # pamaury: what about 'require dumper' in load.lua ? 23.27.43 # nevermind 23.28.01 # it's generic 23.28.20 # it dumps every register it can find provided you loaded a register description for your target 23.30.31 # wodz: and the corresponding llvm commit: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130930/189503.html 23.30.42 # I would never have been able to write this myself oO 23.32.24 Join kiwicam [0] (~quassel@121.99.176.30) 23.32.59 # argh, sorry for gerrit spam 23.33.58 Quit Gallomimia (Read error: Connection reset by peer) 23.34.38 # hum, valgrind doesn't like our simulator 23.34.50 # it fails hard with Thread creation failed. Retryingmake_context(): Operation not permitted 23.36.13 # dd test passed 3 times in row 23.36.54 # pamaury: maybe try it with sdl threads? 23.38.44 # yeah i'm recompiling 23.39.11 *** Saving seen data "./dancer.seen" 23.39.42 Quit cmhobbs (Ping timeout: 245 seconds) 23.39.59 Join Gallomimia [0] (~gallomimi@209.87.18.21) 23.40.17 # <[Saint]> pamaury: I'll admit I skipped the logs a little - but - if you're looking for an ARM qemu supported target to port Rb to - raspberrypi? 23.40.25 # <[Saint]> Costs $25USD 23.40.54 # no actually I will rather add support for the imx233 in qemu 23.41.01 # * [Saint] nods 23.41.19 # I found out that someone at olinuxino wrote some code, maybe I can pickup on this and finish it 23.42.26 # hm rpi as rockbox target ? interesting. 23.45.59 # <[Saint]> As long as we _completely_ ignored the GPU, it should be perfectly possible. 23.46.14 # lol 23.47.12 # [Saint]: you cannot ignore GPU on pi as it is used to bootstrap :P 23.47.59 # <[Saint]> Right, I worded that incorectly. As long as we ignored the GPU past anything the released videocore binary gives access to. 23.48.44 # just run raaa on it, and you don't have to worry about such things 23.48.51 # <[Saint]> It would be more suited as a hosted application target, but it /should/ be possible to run as a native OS on the pi. 23.49.12 # pamaury: Do we really need udc_helper() in case of hwstub? It was used to notify rb usb stack about address and configuration. AFAIK it is not needed in hwemul 23.49.39 # not it's not needed in hwstub 23.50.02 # <[Saint]> Raaa, for some reason, runs absolutely terribly on Raspbian at least. 23.50.24 # <[Saint]> I can't say I've looked into why. 23.50.31 # Anything runs absolutely terribly on a raspberry pi, so that doesn't mean much 23.50.33 # gevaerts: sdl threads work 23.50.50 # <[Saint]> gevaerts: that's not /entirely/ true. ;) 23.51.09 # it's slow as hell though, I guess valgrind accounts just a little for that ;) 23.51.36 # [Saint]: does it enable the asm code? 23.52.16 # unsurpringly my buflib rework fails miserably 23.53.34 # <[Saint]> n1s: I couldn't say - its been a long while since I looked into this. I recall it didn't like compiling inititally but I think that was more due to the spotty state of the raspbian repositories about a year ago. It required a small amount of hand holding. I haven't tried it recently. 23.54.18 # it's likely to make a big difference for the codecs at least 23.55.10 # but otoh the thing should be faster than the gigabeast so that shouldn't matter too much 23.55.26 # <[Saint]> The raspi could make a damn nice target if I was even vaguely interested in fighting with HW acceleration via the GPU. 23.55.43 # * [Saint] wishes he had more motivation to try things. 23.57.17 # <[Saint]> ~$25 "open" audio player with a kickass GPU and a shit-tonne of ARM optimizations gathered over the course of a decade. 23.57.24 # <[Saint]> Damn I wish I wasn't boring... 23.58.40 # except that supporting the kickass GPU probably involves more code that rockbox itself :) 23.58.50 # i think i agree with gevaerts that raaa should be the way to go, but maybe it needs some work