--- Log for 22.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 days and 3 hours ago 00.02.09 # no, as I said, I haven't even try to investigate the problem yet 00.02.29 # the only thing I've done so far is: select an audio file, play it, notice sound is garbage, stop here 00.02.37 # litterally :) 00.02.45 # ok :) 00.03.09 # I need to try aplay and investigate the codec interface that Sony is using 00.03.24 # it uses some nonstandard stuff 00.04.08 # yes, some linux SoC do that 00.05.51 Quit ender` (Quit: "I'm the head wizard now. I've only got to give an order and a thousand wizards will ... uh ... disobey, come to think of it, or say 'What?', or start to argue. But they have to take notice." — Archchancellor (Terry Pratchett: Lords and Ladies)) 00.06.08 # but maybe you should just adjust alsa swparms/hwparms 00.08.34 # I haven't had a look at what rockbox alsa driver does, I don't know if it's only a pcm driver or if it can set sampling rate and all, the problem might just be there 00.09.33 # Mihail: why does it work with the old code? it's just so much more efficient than it handles the events without a problem? also, it does it even if the battery isn't charged. 00.11.02 # furrywolf: IMHO old code just hide this problem 00.11.42 # -8 does not work either. 00.11.47 Quit skapazzo (Quit: leaving) 00.12.13 # logf.txt? 00.12.14 # same thing, freezes when cable is plugged, flashes usb image after cable unplugged, doesn't get enumerated. 00.12.57 Quit atsampson (Ping timeout: 255 seconds) 00.13.22 # http://fw.bushytails.net/tmp/logf.06.txt 00.13.57 # by "hides the problem", do you mean "handles interrupts efficiently"? :P 00.15.12 # it stop INT_AUDIO interrupts for some time, so others parts can work 00.17.46 # try http://knk.square7.ch/rb/rockbox-fuzev1-usb-9.zip - try do as datasheet say :) 00.20.00 Join atsampson [0] (~ats@cartman.offog.org) 00.20.15 # are you turning the charger off when you get the end-of-charge interrupt? 00.20.48 # also, if you %x your debug, it makes translating it to bits much easier. :) 00.21.08 # rockbox already do that 00.21.27 # are you sure? 00.21.44 # 99% :) 00.21.45 # because it shouldn't generate an end-of-charge interrupt if the charger is off! 00.22.48 # yes, so I not sure is it software issue 00.25.24 # -9 seems to work 00.25.36 # shows usb image, enumerates 00.25.52 # bah, I think I uploaded the wrong log file last time. sorry. 00.26.16 # great, datasheet was right :) 00.27.01 # * pamaury spots an unlikely claim 00.27.09 # datasheets are never right ;) 00.28.01 # http://fw.bushytails.net/tmp/logf.07.txt there's the logfile from -9. do you want me to reinstall -8 and upload the proper logf for it? 00.28.34 # I forgot to dump the log, so you got -7's log again. heh. 00.28.47 # no, as -9 work 00.29.17 # I'll do clean patch for gerrit 00.29.45 # is it a chipset feature, that it generates the endofch interrupt continually until the charger is turned off, but the new code is too busy handling the interrupt to turn the charger off? 00.29.59 # what does -9 do differently? 00.30.44 # since the device seems to go out to lunch on plugging it in, it's quite possible it's never turning the charger off. 00.31.57 # datasheet say about EoC: "The interrupt must not be enabled if the charger block is disabled" 00.32.06 # lol 00.32.28 # so if the charger is off, the pin floats, and generates random interrupts? 00.33.06 # probably, on AMSv2 datasheet don't say this 00.33.16 # although I'm much more fond of the theory that it's wasting so much time busy-looping to handle the interrupt, it never makes it to the charger off step. 00.33.28 # also, it was failing before with the battery only half charged. 00.34.34 # * furrywolf leaves it running unplugged for a while to draw the battery down a bit. random track pick was cult of luna - mariner - wreck of the ss needle. about ten minutes long, should run the battery down a little. :) 00.35.31 # completely random feature request: an option not to use the very uppermost row of pixels. at least on my unit, it's under the bezel. 00.36.34 # __builtin: are you *sure* you want to port SDL to rockbox ? 00.37.07 # also, a hardware question: is the line out dock better audio quality? because the headphones jack sounds like it has some annoying equalization applied to it. 00.38.46 # so your -9 version disables the charger interrupt on turning the charger off. does it get re-enabled when the charger is turned back on? 00.39.16 # not sure, I have plans for future - check and improve audio quality and battery life time on AMSv1 00.39.30 # yes, it back on 00.39.41 # presumably if I let it fully charge, unplug it, listen to music for a while, then plug it back in, it had better turn the charger back on, and any interrupts it needs. :) 00.43.22 # did you reverse-engineer the proper charge voltage and current limit from the stock firmware? 00.43.32 # <__builtin> pamaury: too late now :) 00.43.49 # <__builtin> though it's surely not impossible, it's been done for ipodlinux in the past 00.44.30 *** Saving seen data "./dancer.seen" 00.44.39 Quit xorly (Ping timeout: 248 seconds) 00.45.18 # pamaury: BTW if you can, just play sound in original FW and "cat /proc/asound/card0/pcm0p/sub0/hw_params" than do same in rockbox and compare 00.47.33 Quit pamaury (Ping timeout: 252 seconds) 00.53.24 # <__builtin> hmm, this is a tough bug to fix 00.53.38 # <__builtin> when I try to build SDL under the simulator it thinks it's being built for linux 00.57.32 Quit Milardo (Quit: Page closed) 00.59.04 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 00.59.48 # furrywolf: was wrong, try: http://knk.square7.ch/rb/rockbox-fuzev1-usb-10.zip 01.00.32 # -9 was wrong 01.21.48 # ok 01.25.08 Join Jinx [0] (Dojo@unaffiliated/jinx) 01.25.33 # am I missing something? no dump log file option? 01.25.44 # in any case, it did not work. back to freezing, then showing usb image after unplug, no enumeration. 01.26.27 # it was clean build without debug 01.27.32 # it looks like your player have broken end of charging detection 01.27.42 # also, it's been playing music since I installed -9, unplugged, so you can rule out anything to do with the fully charged detection... 01.28.59 # given as the stock firmware works fine, I highly doubt that... 01.29.06 # and the old code works fine. 01.29.06 # heh 01.29.39 # it could well be "doesn't behave the way rockbox thinks it does", but I doubt it's behaving differently than sandisk thinks it does. 01.30.24 # pamaury: to add insult to injury: According to a review on some german site, these things also have a ADSP-BF606 on board (dual-core blackfin DSP) 01.30.46 # LOL, checking the news. there was a women's rights (i.e. anti-trump) march in town. it was supposedly going to be peaceful. now the city police are calling for backup from both the county sheriff and the highway patrol... lol 01.33.14 # perhaps you want the endofch to be edge, not level? 01.33.40 # it sounds like it stays high, according to the datasheet. 01.33.59 # with the interrupt set to trigger on high level, not low-high edge, it might keep firing them. 01.34.05 # but, again, the battery is no longer fully charged. 01.34.53 # according to the view battery debug, the battery is at 81% 01.36.09 # when I plug in the usb cable on the show battery screen, it shows charger: present immediately before freezing, but still shows discharging. when I unplug the usb cable, it flashes charging. 01.40.49 # I assume installing the build environment is non-trivial? 01.43.03 # sure, I build it manually :) 01.43.11 # not sure 01.43.53 # I mean I assume I need to install various cross-compilers and such, and it's not easy to make it all work. 01.44.23 # try http://knk.square7.ch/rb/rockbox-fuzev1-usb-11.zip it have bigger logf 01.45.04 # are you have linux? 01.45.08 # yes 01.46.06 # you need binutils-arm and gcc-arm cross-compiler 01.46.33 # we have some script to download and build it 01.48.13 # https://www.rockbox.org/wiki/HowToCompile 01.49.04 # I'll check that after -11 finishes downloading... my connection can't do two things at once and have either one be useful. 01.52.46 # http://fw.bushytails.net/tmp/logf.08.txt 01.56.49 # is the charger enabled at boot, or disabled until enabled by some event? 01.58.40 # enabled by event 01.59.16 # but I enable EoC in same event 01.59.24 # does the endofch bit read high whenever the charger is disabled? 01.59.47 # I assume the 68 is the first irq register, in decimal? 01.59.53 # in -10 -11 - no 02.00.00 # hex 02.00.41 # so you changed it from decimal to hex. that's why it doesn't make sense now. lol 02.01.00 # :) 02.06.47 # do we have a datasheet for the I2C control and interrupt registers? 02.07.04 # no 02.07.09 Quit ZincAlloy (Quit: Leaving.) 02.07.47 # hrmm 02.07.55 # I really don't like doing actual reads/writes inside an isr. 02.08.04 # over the bus the interrupt is for 02.08.28 # http://knk.square7.ch/rb/rockbox-fuzev1-usb-12.zip with more info 02.09.20 Quit dys (Ping timeout: 240 seconds) 02.10.29 Quit jhMikeS (Ping timeout: 258 seconds) 02.11.39 # that build works 02.12.58 Join dys [0] (~dys@tmo-099-104.customers.d1-online.com) 02.13.12 # logf.txt? 02.13.13 # let me guess, you didn't change anything, so it works because of some timing change with more debug? :) 02.13.22 # http://fw.bushytails.net/tmp/logf.09.txt 02.13.26 # it takes a while to upload things. it's 500k! 02.13.26 # no :) 02.25.46 # last try for today: http://knk.square7.ch/rb/rockbox-fuzev1-usb-13.zip 02.26.20 # I tried doing a git clone... didn't realize how large it is. 02.27.16 # ~200 MB in packed state 02.27.57 # yeah, that'll take forever. heh. 02.31.38 # panic 02.31.46 # sd read error. hrmm. 02.32.18 # <__builtin> ohhhh 02.32.35 # well, I did use a sd card that I'd written "BAD" on with a sharpie... 02.32.49 # <__builtin> I figured out why SDL won't work... it's including the system SDL header... 02.33.08 # __builtin: :) 02.33.35 # your last build is corrupting ram 02.33.58 # sd panics, garbage written onto the lcd, etc. heh. 02.34.19 # it fails hard quite quickly after connecting the usb cable. 02.34.32 # not going to get a logf out of it. 02.35.41 # very strange 02.35.49 # <__builtin> that explains everything... 02.36.29 # the last crash overwrote the fonts. :P 02.37.36 # <__builtin> wow... now it works :D 02.38.38 # my last attempt ate the firmware. 02.41.02 # -12 still works fine. heh. 02.41.36 # http://fw.bushytails.net/tmp/rockbox02.jpg that's the closest you're going to get to a logf from -13. :) 02.41.56 # -13 just bad number :) 02.42.24 # it works until the usb cable is connected, then self-destructs. I'm assuming you're clobbering ram. 02.43.11 # or the stack is growing into other things 02.43.33 # http://knk.square7.ch/rb/rockbox-fuzev1-usb-14.zip 02.44.32 *** Saving seen data "./dancer.seen" 02.50.07 # that one worked, however my internet connection is being so crappy I don't know if I'll get the logf uploaded 02.50.33 # uploading 02.50.39 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7025:ed00:9835:fcfc:58a8:daa8) 02.51.46 # it worked, but a little oddly. it acted like it was plugged, unplugged, then plugged, and then it worked. but everything flashed by pretty quickly, so I'm not sure. 02.52.01 # http://fw.bushytails.net/tmp/logf.10.txt 02.52.46 # wow, lots of values for ENRD0 in that one. 02.56.12 # good, now I go to sleep 02.56.37 # so what did you figure out? 02.57.49 # not sure, what is with usb, is it work normal or reconnect after few seconds? 02.58.01 # it reconnected at least once 02.58.36 # tried again, now it's looping continually. 02.58.50 # shows usb plug, shows loading, shows main menu, shows usb plug, etc etc. 02.59.39 # bad, try upload new logf after few loops 03.02.51 # this is going to take a while to upload 03.02.55 # 1.6MB! 03.03.47 # fortunately it compresses well 03.05.15 # http://fw.bushytails.net/tmp/logf.11.txt 03.07.44 # ok, I'll check it tomorrow 03.07.58 # ok, cyas 03.08.12 Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) 03.08.42 # bah, I spent all afternoon on this again, and didn't get done the things I needed to get done. 03.18.23 # <__builtin> crap, the ported SDL is screwing with the sim a lot 03.39.20 Quit dys (Ping timeout: 240 seconds) 03.48.04 Join dys [0] (~dys@tmo-113-173.customers.d1-online.com) 04.17.06 Quit athidhep (Ping timeout: 256 seconds) 04.44.33 *** Saving seen data "./dancer.seen" 04.55.37 Join Senji_ [0] (~Senji@85.187.103.250) 04.58.29 Quit Senji (Ping timeout: 240 seconds) 05.53.39 Join naleo [0] (~naleo@unaffiliated/naleo) 05.59.51 Nick JdGordon_ is now known as JdGordon (~jonno@rockbox/developer/JdGordon) 06.15.05 Join athidhep [0] (~afoakf@unaffiliated/athidhep) 06.17.23 Quit TheSeven (Disconnected by services) 06.17.35 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.44.37 *** Saving seen data "./dancer.seen" 07.09.35 Quit dys (Ping timeout: 240 seconds) 07.12.09 Quit Strife89 (Ping timeout: 260 seconds) 07.21.23 Quit furrywolf (Ping timeout: 252 seconds) 07.42.29 Quit alexweissman (Remote host closed the connection) 07.45.39 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.45.39 Quit pixelma (Quit: .) 07.45.50 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.45.51 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.50.35 Quit amiconn (Client Quit) 07.50.35 Quit pixelma (Client Quit) 07.55.03 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.55.04 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.00.32 Join naleo_ [0] (~naleo@unaffiliated/naleo) 08.00.44 Quit naleo (Read error: Connection reset by peer) 08.05.48 Join ender` [0] (krneki@foo.eternallybored.org) 08.16.56 Quit naleo_ (Ping timeout: 248 seconds) 08.20.29 Quit shmibs (Quit: leaving =o) 08.28.31 Join shmibs [0] (~shmibs@shmibbles.me) 08.30.18 Join Barbadus [0] (62e117a1@gateway/web/freenode/ip.98.225.23.161) 08.33.26 # Are themes and forums currently down? 08.44.41 *** Saving seen data "./dancer.seen" 09.01.24 Quit Barbadus (Ping timeout: 260 seconds) 09.20.30 Quit MrZeus1 (Ping timeout: 255 seconds) 09.25.33 Quit kugel (Read error: Connection reset by peer) 09.44.59 Join fishbulb [0] (~fishbulb@unaffiliated/fishbulb) 10.08.01 Join dys [0] (~dys@tmo-109-78.customers.d1-online.com) 10.09.20 Join Echo [0] (c25a5869@gateway/web/freenode/ip.194.90.88.105) 10.09.43 Nick Echo is now known as Guest44936 (c25a5869@gateway/web/freenode/ip.194.90.88.105) 10.10.43 # Hi 10.11.08 # I cant brows to the theme page on rockbox website 10.11.39 # Any idea why and how to fix it? 10.13.45 # Guest44936: Because the server's been having problems. It's been up and down for at least a month. 10.14.40 # scorche` is rebuilding it anew, but I'm not sure what the ETC is on that project, or what it means for the server in the interem. 10.15.27 # Ow well, hope they manage to get it working 10.16.33 # Keep checking randomly. It may be up and down through the process. You can also hang here for updates. 10.16.46 # In the meanwhile, any one have an offline copy of "Information Beauty" theme for sansa clip plus? 10.17.07 # That, I can help with. Give me a couple minutes. 10.17.25 # Greate, thanks 10.22.04 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:15fe:7dc0:97ad:53c) 10.22.40 # Guest44936: Hmmm... Maybe I don't have it hanging around in it's original form. I've got an edit of it I did for the zip that just adds a couple lines. 10.24.18 # Ah. Looks like I do have an editor backup that should be it. Just a moment while I upload it. 10.28.01 # Guest44936: http://pastebin.com/fqN2m8zq 10.28.42 # I don't certify that it is an unmodified version, but looking at the diff between it and the clip zip version I made and my memory, I believe it is. 10.29.07 # Drop it in .rockbox/wps 10.29.21 # That's all the theme is, AFAICT. 10.44.44 *** Saving seen data "./dancer.seen" 10.46.03 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 10.49.14 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 10.49.16 # Thanks, but it doesn't work 10.50.33 # I think there are more files needed (.sbs, .fms) or some dirrectory 10.56.56 # Either that, or there was an extra save and it's bad. 10.57.07 # Guest44936: Lemme check. 10.59.54 # Guest44936: Ah. There was, and I just somehow never noticed. You can find it at http://pastebin.com/T9JZf5jp 11.02.15 # Hope that works. find tells me that should be the lot of the files from a backup of working system. Headed to bed now, but I'll read the scrollback in the morning. 11.03.00 # It works now, thanks 11.03.41 # Still a minor difference but it's good for now, until the theme site starts working again 11.03.59 # Thanks a lot 11.04.44 # And for all of you listening, the .cfg file should be in .rockbox/themes, not like the other files 11.05.23 # I have informationbeauty 1.0 on my Clip+ 11.05.28 # should I extract it? 11.05.46 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.05.49 # Informative beauty* 11.18.13 # If you can it would be grate 11.18.15 # thanks 11.18.53 Quit athidhep (Ping timeout: 260 seconds) 11.19.17 Join n3m9 [0] (~n3m9@ANantes-652-1-4-13.w90-25.abo.wanadoo.fr) 11.22.38 # Guest44936: https://drive.google.com/file/d/0B7z2DypmySvnMTZTNldId0dFYmc/view?usp=sharing 11.27.53 # Thanks, that helps a lot 11.28.29 # I don't know if that's the latest version on the theme site. I haven't updated the themes on my Clip+ for ages 11.28.46 # TorC: There was only one difference- the first line in your version was not in the original file 11.36.42 # That is good enough until the site gets back online, thanks 11.37.20 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7025:ed00:a494:9314:2854:cf60) 11.41.07 Quit ZincAlloy (Quit: Leaving.) 11.44.26 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 11.49.39 Join parchd [0] (~parchd@unaffiliated/parchd) 11.56.30 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 12.00.28 # pamaury: NWZ-A820. Too old? 12.03.41 # yeah 12.05.27 # I can't find a S7xx series :( 12.12.47 # pamaury do you use any of the players daily? 12.20.52 # not recently 12.26.12 # why ? 12.28.01 # *Panic* Incorrect CPU mode on Clip+ with fresh build 12.28.03 # hum 12.30.00 Join Boltermor [0] (~Boltermor@subscr-46-148-172-69.dhcp-docsis.net.tomkow.pl) 12.30.14 # so power the Clip+ on with a USB charger causes this panic screen everytime 12.31.05 # well, plugging the USB charger while already powered on too 12.32.39 # oh, USB connection too 12.32.46 # okay, so USB is broken 12.34.40 # jhMikeS identified some incorrect behaviours and added a panic to detect them so we can fix them 12.35.21 # ah 12.35.33 # could someone tell me why the h300 has a noticable hiss compared to (my laptop for example) 12.36.04 # fishbulb: we already discussed it some days ago, no? 12.36.16 # not really, just that "it's not the dac" 12.36.52 # but if we couldn't answer the question for sure last time, why would we today? 12.37.35 # ok I can't quite remember. 12.38.00 # jhMikeS: I have the panic screen on my Clip+ when connecting to USB. Tell me if I can help 12.38.32 # I'm not sure where on the board to look, there have been people replacing caps but that only alters the "colour" 12.39.09 Part robertd1 12.41.05 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 12.42.04 # THD and all the rest of the amp specs helps knowing "this is good/bad" but I'm not sure what about the board is crappy 12.43.09 # I'm not sure anyone can tell you. 12.43.49 # as it was explained to you here https://www.rockbox.org/irc/log-20170117, the hiss probably comes from somewhere in analog domain after the DAC 12.44.23 # I don't know how you can find out where exactly 12.44.45 *** Saving seen data "./dancer.seen" 12.44.50 # that looks like a job for a very knowledgeable person 12.45.16 # ah logs 12.47.00 Quit n3m9 (Read error: Connection reset by peer) 12.48.20 # I should probably stick to pinterest or something right now 12.49.21 Join skapazzo [0] (~skapazzo@151.9.205.1) 13.00.51 Quit idonob (Read error: Connection reset by peer) 13.01.33 # lebellium: I will try on my clip+ this afternoon 13.01.55 # ok 13.02.06 # basically Mihail was investigating a problem on amsv1 and in the process jhMikeS discovered that some code in apps was doing very dangerous operations 13.02.19 # so I suggested that we panic when that happen 13.02.25 # instead of hoping for the best 13.02.29 # no problem 13.02.40 # so it's possible we see a few panic in the future until we fix it :) 13.02.40 # it's just that for now I have to use OF :D 13.03.09 # no way to charge it, unless it charges on the panic screen 13.03.11 # lebellium: but I think on the clip+, you need to talk to Mihail 13.03.39 # because he is working on the usb charging issue, his code is what causes the panic but it's unclear how to solve it 13.07.05 # I'm not sure I understood properly. Has the code done dangerous operations for a while? 13.11.38 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 13.19.16 Quit Boltermor (Quit: Leaving) 13.20.47 # lebellium: yes 13.22.44 Quit idonob (Ping timeout: 245 seconds) 13.24.02 # would it be easy to port the jz4760 port to other devices, once one of them got support? 13.25.39 # yes and no 13.25.55 # ? 13.26.06 # first no because no port is easy, there is always some rever engineering necessary that might or might not be hard 13.26.06 # what would need to be changed, other than UI? 13.26.27 # button, lcd drivers for starters 13.26.56 # do they not use a common interface for LCDs? 13.27.24 # yeah but LCD itself is completely different, LCDs are complicated beats, you need to send commands to them and those commands change with every lcd 13.27.55 # huh 13.28.10 # i guess it didn't help that the lcd on mine is literally no name 13.28.20 # also installation is not always easy, if the devices provides an easy way to install a firmware, but if the device runs linux, once may need to patch uboot, doing so in a "we don't redistriute binaries without code" way might be a lot of work 13.28.25 # is this how it is for all embedded devices? 13.28.30 # (the lcd i mean) 13.28.32 # yes 13.28.39 # most LCD in rockbox are no name 13.28.56 # actually an LCD is made up of two parts: controller + panel 13.29.24 # usually given the sequence of command in the original firmware, we can guess what the controller is (or at least is close to), that helps with the process 13.29.31 # i guess laptops had it better 13.29.34 # but some we have no clue, we just do what the OF does 13.30.04 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 13.30.21 # so there's the LCD, what else need to be changed? 13.30.39 # embedded systems are completely different from laptops though 13.30.50 # yeah i guess 13.31.03 # button driver, usually it's no too much work though 13.31.13 # installation as I said, can be a tricky point 13.32.15 # the recent ingenic devices do use uboot afaik 13.32.29 # they use uboot only if they run linux 13.32.45 # yeah but the recent ones all do it seems 13.32.56 # X1 gen2, all those X1000 devices 13.34.16 # what about the battery? 13.34.36 # battery is easy 13.35.00 Quit girafe2 (Read error: Connection reset by peer) 13.35.24 # there's also the PMU which seems different on some devices 13.42.49 # yeah but it's probably not a huge deal 13.42.52 # hopefully 14.07.21 Quit parchd (Ping timeout: 240 seconds) 14.18.21 Quit gluytium (Ping timeout: 264 seconds) 14.25.55 Join gluytium [0] (U2FsdGVkX1@ma.sdf.org) 14.44.47 *** Saving seen data "./dancer.seen" 14.49.30 Join parchd [0] (~parchd@unaffiliated/parchd) 16.01.27 Quit parchd (Ping timeout: 248 seconds) 16.02.47 Quit MrZeus1 (Ping timeout: 255 seconds) 16.09.43 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 16.18.43 Quit jhMikeS (Ping timeout: 276 seconds) 16.19.51 Join furrywolf [0] (~randyg@72-57-75-247.pools.spcsdns.net) 16.38.20 Join JanC_ [0] (~janc@lugwv/member/JanC) 16.39.35 Nick JanC is now known as Guest57312 (~janc@lugwv/member/JanC) 16.39.35 Quit Guest57312 (Killed (hitchcock.freenode.net (Nickname regained by services))) 16.39.35 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 16.44.51 *** Saving seen data "./dancer.seen" 17.06.03 Quit fishbulb (Ping timeout: 245 seconds) 17.27.12 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 17.28.17 Join Bilgus_ [0] (~Bilgus@gateway/tor-sasl/bilgus) 17.31.09 Quit Bilgus (Ping timeout: 240 seconds) 17.55.25 Join _mt_ [0] (~MT@2601:482:4402:7b60:5c71:55a1:a0d1:1f60) 18.22.46 Nick __builtin is now known as builtin (~xray@rockbox/developer/builtin) 18.44.53 *** Saving seen data "./dancer.seen" 19.09.47 Join Mihail [0] (25d4bc5c@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.188.92) 19.10.14 # pamaury: I want rework powermgmt-ascodec.c: I want to replace ascodec_endofch() on detecting by voltage (as we currently do for recharge detection). As you can see from furrywolf's case - we can't fully trust EoC. So detecting by voltage should by safe and flexible - we can easily set any voltages (for your g#1412). Is it acceptable? 19.10.16 # 3Gerrit review #1412 at http://gerrit.rockbox.org/r/1412 : 3WIP: Implement final charge voltage selection, enable it on ascodec basec chargers. by Amaury Pouly 19.14.59 Join Strife89 [0] (~quassel@adsl-98-67-57-203.mcn.bellsouth.net) 19.15.08 # it works!! 19.15.18 # * builtin can draw a 100x100 rectangle! 19.15.37 # with a bunch of artifacts, of course 19.15.40 Nick builtin is now known as __builtin (~xray@rockbox/developer/builtin) 19.16.27 # Mihail: detecting by voltage is not very accurate though, for Li-Ion, only current draw can reliable detect end of charge 19.18.00 # *reliably 19.19.12 # __builtin: Which target(s) are you testing on, by the way? (Curious.) 19.19.22 # <__builtin> Strife89: ipod6g 19.19.27 # Ahhh 19.19.36 # <__builtin> it's still buggy as hell 19.20.02 # Here I am imagining trying to do that on my targets, which all have tiny, low-res screens. (Clip Zip, Clip+, c200v1) 19.28.04 # <__builtin> ahh, I think I know what the bug is 19.28.30 # <__builtin> TLSF isn't getting reset between runs 19.34.37 # <__builtin> hmm, not sure why, but everything's being drawn at half height too 19.39.33 # <__builtin> heh, dividing the stride by 2 fixes everything :) 19.46.58 # <__builtin> time to write some input drivers 19.53.25 Quit pamaury (Remote host closed the connection) 19.53.52 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 19.54.46 # another bug... I can't browse the last 10% or so of my playlist. 19.55.35 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 19.55.55 # As I scroll down towards the end of the playlist, first acceleration stops working (that is, spinning the wheel faster no longer scrolls more than one line), then the time to scroll each line becomes stupid, until it takes several seconds per track. 19.56.14 # playlist is only ~3900 tracks. 19.58.46 # charge voltage is constant for the last, to ass-pull a number, 20% of the charge. it can't be used to detect end of charge. 20.02.33 # furrywolf: I think we can add detection broken EoC - if we have EoC at low voltage we should switch it off and detect end of charge by voltage 20.04.09 # I think that is asking for trouble, what exactly is wrong with EoC? 20.06.04 # Mihail says my player sets the endofch flag when it's not done charging. I still think it's more likely to be some sequencing issue with turning the charger on/off or something. 20.06.24 # <__builtin> Strife89: feel free to try g#1521 20.06.26 # 3Gerrit review #1521 at http://gerrit.rockbox.org/r/1521 : 3[WIP] Port of SDL 1.2.15 by Franklin Wei 20.06.33 # the playlist bug is... wtf? how can a bug as bad as not being able to use the bottom 10% of your playlist not fixed yet? lol 20.06.45 # <__builtin> if it uploads... 20.07.08 # IIRC there is a configurable EoC voltage flag 20.07.55 # that sets the actual charge output voltage. 20.08.19 # at least if I remember the datasheet right. 20.08.27 # and I hope we're setting it based on reverse-engineering, not randomly. :) 20.09.25 # https://github.com/Rockbox/rockbox/blob/1f8ea9fe27313228e5df67ce6447830b5c30e5e3/firmware/target/arm/as3525/ascodec-as3525.c#L312 20.09.42 # that also sets up the eoc threshold 20.12.27 # I don't see a setting for the eoc threshold 20.12.38 # I can't reproduce problem with EoC on my players and we have only one report about this problem, so it looks like hardware problem 20.13.32 # * furrywolf thinks ungodly slow interrupt handling is the problem 20.13.55 # doing an i2c transfer in the isr is just... ugh 20.15.49 # VCHG_trick Charger Endpoint Voltage (trickle 20.15.50 # charge) 20.15.50 # BVDD<=3V, CHG_IN = 4.4V 0.70* 20.15.50 DBUG Enqueued KICK Bilgus_ 20.15.50 # CHG_IN 20.15.50 # 0.72* 20.15.51 *** Alert Mode level 1 20.15.51 # CHG_IN 20.15.53 # 0.74* 20.15.57 # CHG_IN 20.15.59 # V 20.16.58 # Bilgus_: that's not something we can set, as far as I can see... 20.17.10 # so if charge volts is 3.7v trickle chg is 2.59 - 2.73v 20.17.22 # no its strickly a % 20.17.23 # no 20.17.37 # you are mis-interpreting what those numbers are, and do. :) 20.17.58 # CHG_IN is the voltage applied to the charger pin - USB bus voltage, wall charger, whatever. 20.18.21 # and the trickle charge is the very initial charge of a completely drained battery, usually not even used, not the final finishing charge. 20.18.46 # that's just saying what it will trickle charge an over-drained battery to before switching to the main charge cycle 20.20.13 # BVDD<=3V, CHG_IN = 4.4V yep you are right 20.20.40 # the final charge is constant voltage. to detect end of charge, it looks for when the charge current drops below a specific threshold, which is Ichg_off, and is a percentage of the programmer charge current. 20.21.08 # programmed 20.22.12 # typical is 10%. so if you program it for 150ma charging, it declares the battery charged (and you should turn off the charger) when the charge current drops below 15ma. 20.23.49 # setting vChg though sets that constant voltage though 20.24.03 # yes 20.24.25 # and it needs to be set based on either the battery cell datasheet, or reverse-engineering the stock firmware. it is _not_ something you can screw with. 20.25.24 # knowing that voltage won't let you know when it's done charging, though. when it hits the constant voltage point, it will still be drawing the full charge current, and the battery might only be 70-80% charged. then you wait for the charge current to decrease, and declare it charged when it drops below a certain threshold. 20.25.52 *** Alert Mode OFF 20.26.08 # the charger should be doing all of this for you... mihail says my charger is broken, but I doubt it. 20.26.16 # i'm pretty sure we set Ichg as .5c or less 20.26.32 # since the stock firmware, and the non-overly-slow i2c code, both work fine. 20.27.28 # yes thats my point if you start screwing with EoC rather than relying on the built-in (SAFE) you are asking for trouble 20.29.31 # and actually there is a patch up on gerrit that allows you to go under the set Vchg #g1412 20.29.32 # 3Gerrit review #1412 at http://gerrit.rockbox.org/r/1412 : 3WIP: Implement final charge voltage selection, enable it on ascodec basec chargers. by Amaury Pouly 20.30.46 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:6189:5124:b028:c993) 20.31.00 # pamaury and I set that one up to allow you to undercharge a battery read < the max Vchg (which came from the batt data sheet) 20.32.02 # undercharging gives you longer battery life at the expense of shorter runtime 20.32.18 # yep 20.33.20 # doesn't take into account DoD but hey its a start 20.33.47 # any ideas about the playlist speed bug? it's bad enough I'm surprised it exists, but it does... 20.34.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.35.32 # pamaury: I just bought a NW-A25. I needed so spend some money \o/ 20.35.49 # oh wow, that's petty money, how much ? 20.36.10 # http://www.ebay.fr/itm/332098977109?_trksid=p2060353.m2748.l2649&ssPageName=STRK%3AMEBIDX%3AIT 20.36.38 # there is a PHA-1A DAC/AMP with 20.36.44 # have you tried GS>Display>Scrolling and screwing around with the settings to see if it changes anything? 20.36.49 # wow, that's not even expensive !! 20.37.25 # furrywolf: your player do hundreds INT_AUDIO calls on USB insert: how it related to i2c? All other players do one call on insert and two on disconnect. 20.37.43 # pamaury: yeah, next one is A30 :D 20.37.57 # Mihail: because you do an i2c transfer _in the isr_, which is a very slow thing, and should not be done in an isr. :) 20.38.38 # why all other work? 20.39.05 # dunno. why does the stock firmware work? why does the async version work? 20.39.25 # old code was even slower 20.39.54 # are you sure it charge right? 20.40.11 # are you sure? the old code looks like it handles an interrupt many, many times faster, since all the isr does is stick it in a queue, not actually go and do the transfer then. 20.40.28 # the bars in the battery graphic increase, until it's full... 20.40.53 # the old code might be slower but it has a way to switch tasks 20.40.56 # the new driver won't work in an isr without always disabling interrupts for the entire transfer 20.41.11 # and that sucks 20.41.20 # it stop INT_AUDIO until all read will be done 20.41.40 # no, it stops all interrupts, and blocks the entire system while it waits for an i2c transfer to complete. 20.41.51 # lebellium: that one will kill your wallet ;) 20.41.59 # both be initiated and completed 20.42.13 # Mihail: no, because if a thread is using it, INT_AUDIO still happens and can reenter the functions 20.42.14 # pamaury: I decided that in 2017 I'll spend 2/3 of my wage into Sony players. Sounds reasonable 20.42.16 # \o/ 20.42.22 # haha 20.42.37 # or buy it 80€, put rockbox, change destination, sell it 200€ ;) 20.42.44 Quit pamaury (Remote host closed the connection) 20.43.13 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 20.43.13 # * furrywolf really doesn't think going and fetching something off an i2c bus is appropriate behavior for an isr. 20.43.48 # furrywolf: you mean in bulk? 20.44.38 # jhMikeS: old code: void INT_AUDIO(void) { VIC_INT_EN_CLEAR = INTERRUPT_AUDIO; 20.44.57 *** Saving seen data "./dancer.seen" 20.45.07 # Mihail: that's within the ISR to ack the interrupt 20.45.26 # jhMikeS: the register that contains the charger, usb, etc flags isn't memory-mapped... it's off in an accessory hanging off the i2c bus. so to determine what triggered the interrupt, it has to initiate and complete a transfer over the i2c bus. 20.45.44 # nvm 20.45.56 # furrywolf: indeed 20.45.56 # the old code queued a "we should go read that register at some point", the new code blocks the system and goes and reads it in the isr. 20.46.36 # Mihail: was thinking 20.47.21 # Mihail: no, that's right, it masks INT_AUDIO until it's serviced. threads using the driver do not, so INT_AUDIO can disrupt them 20.47.40 # Mihail: how about making the isr just set a flag and return, and have a thread that looks for the flag being set, and then fetches the register, performs appropriate actions, and clears the flag? 20.48.09 # furrywolf: i don't understand the argument against it. it is NOT complicated code it's simple and I understand the reason for it. go look at linux or something if you want complicated. 20.48.09 Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) 20.48.26 # jhMikeS: it's not complicated. but it's ungodly awfully slow. 20.48.28 # furrywolf: it's sort of how I wrote every single driver for imx31 20.48.51 Join naleo_ [0] (~naleo@unaffiliated/naleo) 20.48.52 # furrywolf: there will be lags because of other threads running in between, sure 20.48.53 # ISRs should be _fast_. they should do as little as possible. slow things, like i2c transfers, shouldn't happen in them. 20.49.46 # in any case I want move i2c reading from INT_AUDIO 20.49.54 # furrywolf: I think I misunderstood. yes, doing the whole thing stuck in an ISR occupies everything for a long time 20.50.11 # furrywolf: how much time does the i2c transfer takes? 20.50.41 # up to 1/2 second i think 20.51.05 # Mihail: everything was fine before. now you're going to introduce all sorts of gymnastics to avoid something that wasn't a problem. 20.51.10 # funman: a lot. it runs at a 400khz clock, and needs to send a request to the accessory and wait for the data to come back from it. and with it in the isr, with interrupts disabled, it blocks the whole system to do it. 20.51.56 # funman: 190 us for reading 20.52.03 # see I think we should go back to interrupt based code and fix the issue there, it is the proper way to do it 20.53.10 # Bilgus_: I was running my v2 with interrupt-based code once I fixed the issue with the frequency switching code being called from a tick task. I just needed a less absurd minimum voltage. 20.53.24 # the interrupt based code has the advantage of actually working on my player, so I can't argue with that. :) 20.53.26 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.53.43 # * jhMikeS isn't sure where these voltage values are taken from and why anyone presumes they're okay. they seem really low. 20.54.07 Quit dfkt (Read error: Connection reset by peer) 20.54.53 # maybe they are optimized for several-years-old-players :) 20.55.06 # furrywolf: right now it's all dead because I put asserts in to nuke things if blocking functions are called from ISR 20.55.35 # funman: chips require less voltage as they age? 20.55.47 # TIL 20.56.07 # lol 20.57.03 # jhMikeS: https://www.rockbox.org/irc/log-20170121#16:14:34 20.57.57 # furrywolf: I'm tweaking the ISR one so it only inits and posts to semaphores if the transfer actually demands it. it takes some overhead out. 21.00.59 # Mihail: yeah, Fuze v2 needs increase I'd say. Mine does to have everything work properly and i2c interrupts seem a bit more demanding. 21.01.08 # saratoga said each player was tested for minimum working voltage and then was set at a thresh above that 21.01.45 # ^ yeah that 21.02.13 # still guesswork with nothing but a bunch of anecdotes. 21.02.21 # how much does this voltage drop actually help? 21.02.33 # oh on runtime? no clue 21.03.09 # so.....if it's worth doing it better help runtime imo 21.03.33 # only a whole lot of testing is going to tell you that 21.03.37 # I don't mean 5 or 10 minutes or something 21.04.23 # CVDD1 scaling add 50-70% 21.04.58 # Mihail: I guess that's worthwhile 21.05.27 # on what players 21.05.35 # AMSv2 21.05.40 # I get 12h on OF something like 16 on RB 21.06.02 # 23-26 hours on clip zip 21.06.46 # I also work on CVDD2 scaling - should by > 30 hours 21.07.57 # Any way in Bootloader to do some level testing and set it dynamically? 21.09.52 # Bilgus_: what you mean? 21.09.56 # Mihail: is the 50-70% just voltage scaling compared to scaling only frequency or is it both compared to always running maximum frequency? 21.10.07 Quit _mt_ (Ping timeout: 255 seconds) 21.10.33 # like lower it till it fails to make a benchmark and set it back one level 21.10.34 Quit naleo_ (Ping timeout: 276 seconds) 21.12.27 # jhMikeS: we need frequency scaling to set low voltage. Frequency scaling don't and much runtime by it self. 21.12.44 # *add much 21.13.10 # pamaury: oh and actually, this A25 is my 100th player! Finally! 21.13.18 # wow, a hundred 21.13.26 # you definitely don't use most of them ;) 21.15.53 # <__builtin> daaang, lebellium 21.16.13 # * __builtin is riding at 2 functioning players 21.18.12 # <__builtin> and around ~5 dead ones 21.18.21 # pamaury: Indeed. I can't use all of them even if I wanted. The ones I use the most are still the Clip+ and Clip Zip. But those days I use my E585 and A15 quite much! 21.19.20 # that means we need rockbox on them ;) 21.21.28 # sure 21.21.46 # there is much expectation as you already saw with the dest_tool 21.25.36 Quit Strife89 (Ping timeout: 256 seconds) 21.26.30 # __builtin: that's not a good ratio! I only have 7 dead ones among the 100 21.28.32 Join parchd [0] (~parchd@unaffiliated/parchd) 21.28.41 # how does battery charge current and usb negotiated current interact? 21.30.01 # that is, is it trying to pull 200ma without first negotiating for it? 21.31.19 # I imagine it just doesn't 21.32.34 # hrmm... 21.34.22 # jhMikeS: didn't know what we were talking about.. i am a bit out of the loop these days :) 21.35.29 # and in that case maybe it would be a good idea to set 100ma on data connection on the players that allow it 21.35.44 # Mihail: on your next version, add debug output for VBUS and CHG_IN off the adc, please. :) 21.36.18 # though it might negotiate I'm not familiar enough with the usb part to tell you 21.36.39 # furrywolf: you can check it in debug menu 21.36.52 # not while the device is frozen I can't. lol 21.37.28 # although I could flash your irq-based one and try then 21.38.28 # ah do you think the device is kicking your USB port? 21.38.46 # furrywolf: or v3.13 21.39.02 # what debug option shows VBUS and CHG_IN? 21.39.20 # View IO ports 21.39.49 # that only shows gpio, nothing from the adc 21.40.03 # hit the down button 21.40.08 # furrywolf: Bilgus_on players that support it, it only draws what the host allows 21.40.18 # at least it is supposed to 21.40.26 # <__builtin> hmm... this is not goot 21.40.28 # <__builtin> *good 21.40.40 # but not that many port implement it I think 21.40.48 # <__builtin> something's seriously wrong with the filesystem on my build at least 21.40.48 Join _mt_ [0] (~MT@2601:482:4402:7b60:5c71:55a1:a0d1:1f60) 21.41.20 # hah! vbus is dipping down to 4.3, chg_in down to 4.1. 21.42.02 # 4.1 into a charger trying to charge a battery to 4.2v might cause spurious endofch interrupts. 21.42.08 Quit parchd (Ping timeout: 240 seconds) 21.44.12 # I should try to find something with a 500ma port and see if it behaves differently. 21.46.36 # although it's probably not the problem, since when the battery is actually mostly charged, it wouldn't pull enough current to cause an issue. 21.47.57 # oh well, it was worth thinking about. 21.51.03 Join saratoga [0] (c036de1c@gateway/web/freenode/ip.192.54.222.28) 21.51.09 # latest devel insta-panics on usb connect 21.51.16 # voltage scaling seems to make a large difference on AMSv2, I suspect its a combination of the cpu using less power and the SOC peripherals draining less 21.51.22 # furrywolf: :) 21.51.40 # "Incorrect CPU mode in mutex_lock (0x13 != 01F) 21.51.59 # crap, I forgot an 'x'? 21.52.09 # more likely I typoed it. :P 21.52.14 # frequency scaling alone make relatively little difference on all AMS (v1 and v2), i think probably the rest of the SOC consumes a sizable fraction of total power 21.52.18 # isn't it normal since the code still mutex_lock in ISR ? 21.52.27 # i think on v1 adding it in gave maybe an extra 2 hours 21.52.29 # yes, the x is there. my typo. 21.52.37 # whew 21.52.51 # now go fix your bug instead of complaining about my typing. :P 21.53.01 # it's not my bug 21.53.33 # it's Mihail's bug 21.53.35 # * jhMikeS just makes the kernel code do stuff 21.54.18 # 2 hours on a player with 12-hour life is not a trivial improvement. 21.54.39 # i think the problem with voltage scaling on the fuzev2 is that 90% of people have clip players, so we estimated the fuzev2 voltages from just a couple players and a safety margin 21.55.13 # hard to estimate a distribution from a few samples 21.55.25 # * jhMikeS has the third Fuze v2 in existence 21.55.28 # where does the automatic installer save its cached downloads? 21.55.34 # i tried for a long time to find one 21.55.45 # i think i bought 3 or 4 fuzes over the years and they're all v1s 21.55.55 # i don't think sandisk made very many of them 21.56.18 # maybe why no one has noticed that the voltage is too low 21.56.40 # johnb2 has a fuzev2 as well 21.56.52 # minimum voltage could also be random - some individual chips will work better at lower voltage than others. 21.57.05 # ^true 21.57.07 # by the way, amsv1 frequency scaling is still disabled due to random crashes which are probably fixed by now by subsequent improvements :) 21.57.15 # yes there will be a distribution 21.57.19 # and I doubt sandisk is going to disclose their minimum voltage binning practices. :) 21.57.27 # * jhMikeS did some revisions to the interrupt I2C driver and now the fuzev2 seems to be running at the low voltage with no immediate issue 21.57.27 # i doubt they know 21.57.33 # not at this point at least 21.57.56 # jhMikeS: now convince Mihail to switch back to the interrupt i2c driver. :) 21.58.02 # they made these chips over a long period of time as well, who knows if theyy're even all identical 21.58.14 # furrywolf: why convince him when I can pull rank? 21.58.28 # that's a form of convincing. blackmail would work too. 21.59.07 # * jhMikeS guesses he's RB old fogey since he came here in 2006 (iirc) 21.59.17 # then again i guess its on a 130 nm process (?) so probably the equipment was 10 years old at the time and not changing too much 21.59.20 # the non-interrupt one is a lot cleaner... but doing i2c bus transfers inside an isr just rubs me the wrong way. 21.59.43 # my guess is that the OF uses a very safe and possibly very suboptimal voltage 22.00.03 Join Senji [0] (~Senji@85.187.103.250) 22.00.08 # furrywolf: me too, besides not letting other threads run concurrently on a pretty quick CPU 22.00.16 # dunno, battery life is a big advertising point. they might push it more than usual. 22.00.41 Quit Senji_ (Read error: Connection reset by peer) 22.01.26 # I haven't looked at the simulator... does it actually emulate the hardware, or is it just a replacement api that sticks everything in a window and ignores actual hardware calls? 22.01.45 # furrywolf: it replaces api 22.01.45 # doesn't emulate anything 22.02.05 # basically it replaces the "os part" of rockbox 22.02.17 # someone tried writing an emulator for PP, it could half boot actually 22.02.32 # but its a lot of work to get everything exactly right 22.02.40 # the problem with emulators is that they are a lot of work, and that doesn't even help figuring out when you don't know 22.02.41 # furrywolf: I made the driver a bit more "regular" and killed some overhead. also, fixed a neglected sem wait 22.02.55 # too bad we don't have a hardware emulator for reverse-engineering the stock firmware. 22.03.06 # pamaury: that e200 emulator actually helped uncover some good stuff though 22.03.15 # i am sure the manufacturer specs extremely conservative voltages so that they have the option of shipping lower binnned parts in the future 22.03.21 # UGH I hate the time settings that use string choice talk about a convoluted way to set times 22.03.23 # remember the write the firmware before the parts actually ship 22.03.34 # watch in real time as the stock firmware twiddles the speed and voltage bits 22.03.40 # we have the advantage of developing for a platform that shipped long ago, so we know what the hardware actually needs 22.04.05 # furrywolf: yep, fuzev2 seems happy with voltages in HEAD running interrupt driver 22.04.38 # completely off-topic question: the time I've spent this morning not playing with my mp3 player has been spent trying to organize my living room... how the heck is it now WORSE? lol 22.04.43 # * furrywolf should work harder and irc less 22.05.03 # furrywolf: I think it was just a couple driver bugs + the action.c bug causing the issue. 22.05.14 # i should get back to work as well 22.06.33 # anyone know if we have a ms_to_ticks and ticks_to_ms function somewhere else? , I've placed min in misc.c 22.06.44 # mine* 22.07.41 # does view i/o ports intentionally or accidentally disable usb? 22.08.20 # furrywolf: the debug screens tend not to ack USB 22.10.25 Quit _mt_ (Ping timeout: 255 seconds) 22.11.19 # usb seems to behave less poorly when connected to a device with 500ma ports. I think part of the issue may be spurious endofch interrupts due to usb voltage sag, due to turning the charger on full power prior to negotiation. 22.11.46 # and the spurious interrupts cause the slow-as-fuck interrupt handler to consume too much cpu. 22.14.38 # also, when you hold down the power switch while on the i/o ports screen, it seems to update about ten times too fast. lol 22.15.32 # specifically, it does not freeze when connected to either a wall usb charger, or to my snap-on modis. I didn't check to see if it enumerated on the modis, since wince is annoying to do anything with, and it's pretty locked down. 22.16.30 # furrywolf: that's probably the effect of gui boost 22.18.54 # pamaury: debug menu update immediately on any button press, or 10 times per second if no press 22.19.14 # ah 22.19.43 Join _mt_ [0] (~MT@2601:482:4402:7b60:5c71:55a1:a0d1:1f60) 22.19.47 Quit StaticAmbience (Ping timeout: 260 seconds) 22.20.18 # it looks like the charger is smart enough to deal with low usb power, but it generates extra interrupts while doing so. 22.22.34 Quit robertd1 (Ping timeout: 240 seconds) 22.24.31 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 22.27.21 # hello, is there some little player that is already in sell (at little cost, like sansa clip +) that support rockbox nowadays ? 22.30.11 # no 22.30.32 # your best option is still finding a second-handed Clip+ or Clip Zip 22.33.05 Join fishbulb [0] (~fishbulb@unaffiliated/fishbulb) 22.34.36 # <__builtin> or hope that the agptek "ROCKER" is real 22.34.43 # <__builtin> and actually runs rockbox 22.35.18 # real for sure 22.35.22 # the latter, no :P 22.35.37 Quit _mt_ (Ping timeout: 255 seconds) 22.44.59 *** Saving seen data "./dancer.seen" 22.46.17 # Guest44936: Not surprised. Remember, I'd edited it to take (some) advantage of the zip's taller screen and added a couple lines. 22.50.59 Join naleo_ [0] (~naleo@unaffiliated/naleo) 22.51.35 Join MrZeus1 [0] (~MrZeus@2a02:c7f:7025:ed00:d10f:861d:c41:1227) 22.53.56 # pamaury: I want move ascodec_read() from INT_AUDIO to power thread as you say, but we have one target (m200v4) without charging. We don't have dev builds for it and wiki say "port has received little attention and is extremely buggy" so I not sure is it work at all. What should I do? 22.54.54 # don't worry about the m200v4 22.55.08 # the player reboots if you try to change the volume, it isn't really usable 22.55.25 # hardly any were ever made so it is unlikely anyone will want to work on it again 22.56.14 # ok, thanks! 22.57.48 # that sounds like a challenge. I must find this rare m200v4 :P 22.58.05 # most of the m200s out there are v3s IIRC 22.59.22 Join Strife89 [0] (~quassel@adsl-98-80-185-9.mcn.bellsouth.net) 23.00.03 Join semitones [0] (~znc@unaffiliated/semitones) 23.00.16 # Mihail: why not still go for the async interrupt version ? jhMikeS says he as a cleaned ip version that works 23.01.24 # g1522 23.01.25 # 3Gerrit review #1522 at http://gerrit.rockbox.org/r/1522 : 3AMS: Gloriously return ascodec to interrupt-based I2C2 driver by Michael Sevakis 23.09.44 # we should carefully test it - if no problems - I agree 23.10.54 # have at it. so far it's played through one album for about an hour and it's on the second 23.11.27 # lebellium : the problem is second-handed clips will probably start to have problem with these old batteries 23.11.44 # volates are 1.1875/0.8750 23.12.27 # jhMikeS: you should try connect/disconnect USB 20-40 times 23.13.49 # I forgot to plug USB. when I do there's something still trying to set CPU frequency from in ISR somewhere. 23.14.04 # <__builtin> there we go, input works now :D 23.14.32 # where the hell is that coming from? 23.15.01 Quit alexweissman (Remote host closed the connection) 23.15.34 # firmware/target/arm/as3525/usb-as3525.c ? 23.15.58 # usb_enable() 23.16.28 # girafe, the batteries are very easy to change 23.16.46 # hardest part was opening the player 23.17.06 # Mihail: why is that being called from and ISR? 23.17.26 # is there a good source of clip batteries? 23.17.40 # I don't know 23.17.47 # it shouldn't be 23.18.32 # china? 23.19.16 # I found one on ebay US but it was a bit expensive imo $10 23.19.52 # If i needed like say 10 I'd probably look for the source and wait a few months (what I assume this guy did) 23.22.44 # Clip have soldered batteries, no? 23.23.12 # Replacing anything soldered is not what I would call "easy" for a normal user 23.23.40 # yes soldered 23.24.08 # a normal user doesn't have a soldering iron at home 23.24.12 # you can get low temp solder and do it with a bic lighter and a nail if need be 23.24.14 # jhMikeS: usb_enable is called from usb thread usually no ? 23.25.05 # if you can't do that then get conductive epoxy and glue em but that stuff is $$ 23.25.14 # last time I used a soldering iron was at secondary school, in "IT/technologies" class. That's probably the same for girafe who's french too 23.25.49 # biggest part to soldering is Flux and not burning yourself/item 23.26.19 # but I get where the normal user is afraid of it 23.26.19 # you can get a soldering iron for less than 10 on Amazon, making the battery more expensive 23.26.30 # but those little battery powered microsoldering irons might be better for something like this 23.26.50 # btw the place I bought the battery from now wants ~17 for it 23.27.03 # Mihail: Looks like that might have been a stack issue 23.27.11 # @saratoga, those battery powered ones are awesome 23.27.22 # Mihail: i just plugged and unplugged a bunch of times with no problem 23.29.31 # 323036P is the part number, and the guy puts like 10 each time to keep the supply low 23.29.57 # (on the ebay listing) 23.30.56 # what does "genuine" mean in the listing? 23.31.05 # does it come from Sandisk or the same supplier? 23.31.08 Quit saratoga (Ping timeout: 260 seconds) 23.31.13 # Doubt it 23.31.17 # jhMikeS: ok, I'll try check on my players. Before I have "Unhandled IRQ" panic time to time. 23.31.26 # It does look the part though 23.31.42 # BAk is the manufacturer 23.33.15 # I saved my original Clip+ Battery BAK 323036P 3F05 1.07Wh +3.7V 290mAh 23.33.48 # so it's the same manufacturer? 23.34.02 # Hello all -- I have a Clip+ that it seems the NAND may be dying -- it hung and I was waiting for the battery to run out to try reinstalling the bootloader. TorC was helping me 23.34.04 # Well who knows 23.34.10 # Mihail: btw, there's a bug by boosting in usb_enable: it stays at highest even if only using it to charge 23.34.19 # I may need help scouring the forums for the version of the bootloader that will work. 23.34.27 # WHich I don't understand too well 23.35.05 # you're right lebellium :) 23.35.46 # i'm just sad to see there's no mean in 2017 to buy the same good hardware that few years ago 23.35.52 Join alexweissman [0] (~alexweiss@149-160-186-148.dhcp-bl.indiana.edu) 23.36.56 # I'm seeming to have trouble connecting to the forums -- does anybody know of a bootloader version that would allow me to recover the Clip+ from this state: where holding the power button down 30s doesn't work anymore 23.37.09 # girafe: SanDisk released the Clip Sport and Clip Jam which are not discontinued yet but the hardware is worse than the Clip+/Zip and not enough for Rockbox. SanDisk ruined it all! 23.37.12 # jhMikeS: it not problem as we on charge :) We should do voltage rising before we try use USB 23.39.11 # semitones, the forum is down atm, but if the nand is already dead it is too late anyways 23.39.14 # maybe. it's annoying though since I have to turn off that boost to have it scale when plugged 23.40.02 Quit alexweissman (Remote host closed the connection) 23.40.05 # heh, kinda like linksys, where every new version had less flash and less ram than the previous version? 23.42.11 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 23.43.36 # dongs have you gotten your new NAND to test with yet? 23.43.58 # Bilgus_, i don't know if the nand is dead - I'm not even sure what that is 23.44.43 # when you plug it to the pc does it show 32mb RAW partition? 23.44.48 # All I could tell you is that just earlier this week, it was working, then it started having issues hanging, where the power off and on would fix it, and 2 days ago, that trick stopped working. So I've waited for the battery to run out completely to try the next troubleshooting step 23.45.11 # Bilgus_, plugging it in before showed nothing. I'm about to plug it in now, except that TorC said to have the bootloader ready to install when I did 23.46.18 # then wait till the forums come back up 23.47.03 # lebellium : hard to understand why, would it not be costless for sandisk to sell again the same hardware rather than using a new one, even less powerful 23.47.55 Join alexweissman [0] (~alexweiss@149-160-186-148.dhcp-bl.indiana.edu) 23.53.34 # semitones: johnb2 has a ready-made one. 23.54.19 # perfect! I am having trouble finding it 23.54.39 Quit paulk-collins (Ping timeout: 240 seconds) 23.54.51 # He's not on IRC right now, but I think he reads the logs. 23.56.07 # Actually, check the logs. Try Dec 30th or so. I think he posted a link to download it separately from the forums around that time. 23.58.08 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 23.58.40 # 8 johnb3 Regarding the modified boot loader: it was Mihail on the forums.