--- Log for 10.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 3 hours ago 00.04.09 # ah... I feel like an idiot 00.04.14 # I had the hold switch 00.04.25 # ok working! 00.04.51 # never seen the 240x320 cabbie v2 on such a small screen :D 00.06.07 # lebellium: there is a small bug in the bootloader with respect to HOLD handling 00.06.17 # for now make sure you boot with HOLD on off 00.06.23 # otherwise keys won't work 00.06.28 # I'll fix in my next gerrit update 00.08.28 # lebellium: can you confirm sound is not working ? 00.09.45 # I confirm the sound is not working 00.09.52 # but playback doesn't crash 00.10.43 # it's funny because album art does show up properly with cabbiev2 but not with my theme 00.10.44 # yes, it's "just" a problem with audio output apparently 00.11.24 # oh and it believes the battery is empty 00.11.32 # lebellium: I think you guessed it, to access your files you need to go to the "contents" folder 00.11.46 # I guessed it :) 00.11.47 # I need to figure out how to make it start there by default 00.12.04 # on YP-R0 it's in mnt 00.12.04 # ah ? It is supposed to read battery correctly 00.13.24 # the battery indicator just moves 00.13.30 # not stable 00.14.38 # lebellium: go to System > Debug > View battery 00.14.54 # what does it show ? 00.15.07 # 4.166V 00.16.04 # and rockbox displays an empty battery bar ? 00.16.38 # 4.153V now 00.18.43 # no it's 97% 00.19.18 # I'm confused, you said it was thinking it's empty 00.19.35 # yes, low battery message and shutting down 00.20.01 # now it seems to be stable at 97% but it wasn't 00.21.46 # well I don't know, I'm reading the battery using Sony's power module 00.22.25 # it just moves from 97 to 99 and back to 97% 00.22.29 # we'll see that later 00.24.15 Part robertd1 00.26.34 # well there are several options to read the battery 00.26.55 # the power modules does magic and converts it to a 5 level value (low, 1, 2, 3, 4, full) 00.27.12 # but I found it a bit imprecise so I used the actual voltage 00.27.50 # congrats to pamaury 00.27.52 # https://drive.google.com/file/d/0B7z2DypmySvnSDdLT0JlQzdhWWM/view?usp=sharing 00.27.54 # https://drive.google.com/file/d/0B7z2DypmySvnNDBoSks1ZG91MTA/view?usp=sharing 00.27.55 # https://drive.google.com/file/d/0B7z2DypmySvnN3AteUhNVHdmbXc/view?usp=sharing 00.27.57 # https://drive.google.com/file/d/0B7z2DypmySvnWXN1N3pjdHFXLWM/view?usp=sharing 00.27.59 # https://drive.google.com/file/d/0B7z2DypmySvnSWlPbHB1YWExY2c/view?usp=sharing 00.29.09 # the sony logo is a bit ugly on the E580 00.29.41 # the bootloader extract a 130x130 icon which is ok on the E450 and E460 but on the E580 they added a gradient that makes the cut very visible 00.29.50 # but that's a minor detail 00.30.32 # on E450 you don't see the blue/black difference?! 00.30.45 # the bootloader also misses important features, like warning when the HOLD switch is on (instead of doing nothing), also it misses a timeout (it will happily drain the battery waiting for the user currently) for a default action/shutdown 00.30.56 # lebellium: no, the logo is a bit different 00.31.39 # ok 00.31.47 # I guess we deserve to sleep now! 00.32.28 # yes :) 00.32.41 # tomorrow I'll add the A15 00.33.52 # thanks for the efforts 00.33.54 # good night 00.38.28 # pamaury: be68b6a7b crashed likewise, after 2-3hrs. 00.38.36 *** Saving seen data "./dancer.seen" 00.39.22 # it justs powers off ? are you use you have a long playlist and you have repeat ? 00.39.44 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 00.40.07 # Yes I am sure. 00.40.29 # Playlist has 500 3min tracks and Repeat = All. 00.40.46 # Now I can't say /just/ powers off. 00.40.56 # that's weird. The last commit related to imx233 (so zen indirect) dates from september 00.41.10 # have you tried a dev build from more recently ? 00.41.30 # I can say screen goes black, sound goes silent, keys go non-responsive... and power button press does a power-on operation suggesting power went off. 00.42.09 # potentially sounds like a panic to me 00.42.12 # No I haven't because TMK the official dev builds do not include lcd_fix. 00.42.56 # ZEN panics I've seen don't go black screen. 00.43.31 # Even if there's a backlight timeout, they show black screen on white background that stays indefinitely. 00.43.57 # However, I may never have encountered a panic occurring when backlight is off. 00.44.05 # that depends, a panic in some places may not be able to make the screen work 00.44.14 # How can I determine whether the black screen is hiding a panic display? 00.44.35 # you can't 00.45.03 # I think bisecting is the only option 00.45.31 # bisecting... what? 00.47.25 # <__builtin> binary search through commits to isolate the introduction of a regression 00.48.27 # chrisjj: can I send you another build to try and narrow down the problem ? 00.48.31 # Yup. 00.49.21 # __builtin: note: "official dev builds do not include lcd_fix" without which RB is unstable on ZEN, so I have very few commits to bisect :-) 00.51.11 # the lcd fix only affects the bootloader 00.51.16 # at least that should be the case 00.52.09 # chrisjj: https://www.dropbox.com/s/bvid5emyl0wd206/rockbox_zen_7e0820fe2.zip?dl=0 00.54.22 # Got it... 00.55.21 # Running. 00.55.35 Quit xorly (Ping timeout: 240 seconds) 00.55.36 # And I see a change in the start-up flashes. 00.55.38 Join lebellium_z3c [0] (~AndChat73@89-93-179-5.hfc.dyn.abo.bbox.fr) 00.56.02 # pamaury: I have sound!! 00.56.54 # 7e0820fe2 crashes on the first backlight sleep. 00.56.54 # But totally crappy 00.57.43 # Like the max output at any volume 00.59.28 # 7e0820fe2 - runs #1 and #2 crashed on the first backlight sleep. Runs #3 and #4 has survived backlight sleep. 00.59.44 Quit lebellium_z3c (Client Quit) 01.00.50 Quit shamus (Read error: Connection reset by peer) 01.04.36 # I thought the back sleep problems were long gone 01.06.43 # Certainly on 45697a0bf-161212 (lcd_fix) I had no backlight sleep crashes. 01.06.50 # hum 01.07.01 # ok, let's stop there and resume tomorrow, I'm tired 01.07.35 # They subsequently started only on be68b6a7bM-170108. 01.07.41 # OK. 01.07.45 # I see two options: 1) I introduced a bug since 45697a0bf 2) somehow the lcd_fix also "fixes" the backlight sleep problem but I have no idea how it's possible 01.08.09 # because the lcd_fix is a one-time thing on boot 01.08.14 # One think before you go if you don't mind. Am I correct in saying the master has no lcd_fix version? 01.08.27 # yes 01.09.06 # OK. "I introduced a bug since 45697a0bf " could be one of those changes that makes no difference to ZEN :-) but I think it unlikely. 01.09.15 # I really should push it, I just haven't tried it on the other imx target to make sure it introduces no regression. Because the way I understand it, the lcd_fix is only supposed to fix something in the bootloader 01.09.36 # But lcd_fix included .rockbox update 01.10.09 # yeah but it should make no difference, or at best it should only prevent a possible (but very very unlikely) white screen of death on boot 01.10.41 # I think we have to test 45697a0bf without lcd_fix to be sure 01.10.50 # (ie just 45697a0bf) 01.11.22 # ?? 01.11.47 # The lcd_fix you gave me says "Version: 45697a0bf-161212" 01.12.04 # sorry, the commit right before it 01.12.16 # cd8b33327c9 01.12.18 # I'm tired 01.12.25 # good night 01.13.09 # "cd8b33327c9" Ah, got you. I'll see if have/can get that. Night-night. 01.16.50 Quit pamaury (Ping timeout: 240 seconds) 01.18.15 # __builtin: Can you help me find this past ZEN cd8b33327c9 build on rockbox.org? 01.22.26 # <__builtin> No, I'm busy. 01.30.35 Quit Senji_ (Ping timeout: 240 seconds) 01.31.04 # OK. Anyone else? 01.37.08 Quit WakiMiko (Max SendQ exceeded) 01.37.41 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 01.37.44 Join b-t` [0] (~user@s5596c859.adsl.online.nl) 01.38.02 Quit Bilgus (Remote host closed the connection) 01.38.04 Quit b-t (Write error: Broken pipe) 01.59.04 Quit elensil (Ping timeout: 256 seconds) 02.13.23 Join elensil [0] (~edhelas@2001:1c02:1903:d800:49e3:50f1:371b:c023) 02.14.45 Quit skapazzo (Quit: leaving) 02.23.44 # Is WPS supposed to show the charge level when charging? Here (ZEN cabbieV2) it doens't. 02.38.38 *** Saving seen data "./dancer.seen" 03.19.30 Quit ZincAlloy (Quit: Leaving.) 03.23.35 Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) 03.38.10 Quit o43 (Ping timeout: 240 seconds) 03.47.32 Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) 03.54.06 Join Bilgus [0] (~WW@cpe-174-102-17-217.cinci.res.rr.com) 04.28.55 # <[Saint]> what resolution is the ZEN? 04.28.58 Quit o43 (Ping timeout: 260 seconds) 04.29.35 # <[Saint]> No, lets do it a different way - what do you expect to happen, chrisjj? 04.30.16 # <[Saint]> it should show that a charger is connected, and the battery meter should reflect this. If you're expecting a numeric value, then, no. 04.31.08 # <[Saint]> this is handled by the .sbs and has nothing to do with cabbiev2 directly other than the fact that cabbiev2 uses the fallback statusbar. 04.37.03 Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) 04.37.59 # <[Saint]> Oh, hmmm, sorry, My mistake. I forgot cabbiev2 disabled the .sbs 04.38.42 *** Saving seen data "./dancer.seen" 04.38.58 # <[Saint]> So the answer is no. 04.40.09 # <__builtin> [Saint]: do you have a PortalPlayer iPod you can test something on? 04.40.52 # <[Saint]> It'll show if a charger is connected and not charging, is connected and charging, or the battery state. 04.41.04 # <[Saint]> __builtin: several, but none on my right this very second. 04.41.14 # <[Saint]> what do you need tested? 04.41.23 # <[Saint]> s/my/me/ 04.41.43 # <__builtin> how slow an antialiased line function of mine is 04.42.12 # <__builtin> turns out the PP devices are the slowest devices (by cpu freq, at least) that have a color screen 04.44.49 # <[Saint]> MHz does not speed make. 04.45.11 # <__builtin> yes, I know 04.45.25 # <__builtin> how else should I attempt to quantify speed then? 04.46.33 # <[Saint]> the only adequate and objective metric in my opinion would be the codec performance comparison benchmarks. 04.47.02 # <[Saint]> There you get a sample size of targets performing a known operation. 04.47.41 # <__builtin> well, I can't easily run queries against those (i.e. which are the slowest ones with a color display) 04.48.19 # <__builtin> so cpu frequency will have to do ;) 04.48.22 # <[Saint]> Why not? 04.48.28 # <[Saint]> Oh. You said /easily/ 04.49.00 # <__builtin> yeah -- with cpu frequency anything I need is just a grep and awk away 04.49.02 # <[Saint]> Meh. You know which targets have colour displays, and the output is standardized. You could form a nice little table with some grep magic. 04.50.41 # <[Saint]> you don't need to care about all the codec results as long as you pick one that is consistent amongst the targets you're interested in. 04.51.45 # <[Saint]> frequency falls over, I think, because on the surface it's 80MHz but you've also got the coprocessor to think about so it's realistically dual-core. 04.52.11 # <__builtin> well, in this case it's a single thread doing all the work 04.52.14 # <[Saint]> though there's a lot of fundamental differences. 04.52.26 # <[Saint]> ah. 04.52.36 # <[Saint]> right. 04.52.48 # <__builtin> basically it doesn't *have* to be the slowest device, just slow enough to see if my algorithm is "too slow" 04.54.07 # <__builtin> I tried testing on one of lebellium's c200s, but horrible display makes it hard to really judge anything 04.55.17 # <__builtin> right now antialiased (Wu) lines take about 4x longer than Bresenham (or whatever rockbox uses) 04.59.23 # <[Saint]> serious question, at 220x176 to 240x320, does it matter? 04.59.36 # <[Saint]> is the difference even visible? 05.00.26 # <__builtin> actually, yes 05.00.38 # <__builtin> let me get you some visual evidence 05.03.46 # <[Saint]> that's genuinely surprising. 05.04.34 # <__builtin> https://www.fwei.tk/shot28.png 05.06.34 # <[Saint]> I imagine 176x220 makes a significant difference. 05.09.41 # wow that is quite a difference 05.10.21 # <[Saint]> the problem is, though, it's in simulation and the pixel packing and DPI is completely different. 05.10.41 # <[Saint]> sim can't really tell you shit in this regard. 05.10.58 Quit o43 (Ping timeout: 260 seconds) 05.11.20 # * __builtin is waiting for [Saint] to test it on his device so he can see! 05.11.24 # <__builtin> :P 05.11.43 # __builtin, what kind of algorithm are you using? 05.12.07 # <__builtin> a fixed point adaptation of Wu's algorithm 05.12.07 # is it simple interpolation? 05.13.28 # <__builtin> basically it draws a 2-pixel wide line with different brightness values that add to unity 05.13.54 # <__builtin> and those values are dependent on how much "line" falls into each pixel 05.14.25 # <__builtin> well, good night 05.15.07 # I'm a big fan of pre computed values 05.16.07 # I once did something similar with beizer curves for rounded controls 05.16.59 Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) 05.34.56 Quit o43 (Quit: Lost terminal) 06.30.23 Quit TheSeven (Ping timeout: 258 seconds) 06.31.02 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.38.43 *** Saving seen data "./dancer.seen" 06.46.49 Join gs6 [0] (~na@cpe-70-121-72-128.austin.res.rr.com) 06.46.54 Quit [Saint] (Remote host closed the connection) 06.47.06 # Is Rockbox dead/dying? 06.47.43 # There is no recent Android build, right? 06.48.20 Join [Saint] [0] (~sinner@rockbox/staff/saint) 06.59.45 # the wat I got it was there won't be a recent Android build either as they changed the threading model but there are new ports in progress 07.01.25 # @ gs6 07.02.41 # <[Saint]> ...wut? 07.02.48 # <[Saint]> that first sentence is super awkward. 07.03.34 # <[Saint]> and, no, everything past Android 4.4.4 is dead. 07.03.41 # Okay 07.04.01 # <[Saint]> you can compile for Android 5+, but it is an obscene hack. 07.04.18 # <[Saint]> honestly though, it's 2017. 07.04.32 # <[Saint]> wanting to run Rockbox on modern Android seems like masochism. 07.04.44 # <[Saint]> If you prefer, I could just come over and kick you in the balls. 07.04.50 # Well, I don't know many decent music players for Android 07.05.02 # Rockbox has features VLC doesn't have 07.05.10 # And it's faster 07.05.43 # wat = way :) 07.05.53 # <[Saint]> ah. 07.06.14 # <[Saint]> But, yeah - perhaps you're looking at it through rose tinted glasses. 07.06.33 # It would be cool if there was a new sort of project that's just a music player without support for embedded devices 07.06.52 # 'Cause all the audio features of Rockbox are really cool 07.06.58 # <[Saint]> well, we do run as an SDL app my man. 07.07.23 # <[Saint]> You'll need to compile it yourself, however. 07.07.58 # <[Saint]> for context, the takeaway from that is that it is exactly what you're asking for. 07.08.06 # For Android?? 07.08.10 # SDL? 07.08.20 # Or just desktop? 07.08.24 # <[Saint]> Rockbox on generic x86/64, MIPS, ARM 07.09.00 # Oh, I don't expect SDL Android support to be very good 07.09.18 # Well, it's not in the Play store to try 07.09.24 # <[Saint]> There's no such thing, so, yes - you're quite right. 07.09.29 # <[Saint]> it wouldn't be very good. 07.09.36 # Oh 07.09.53 # I tried a Qt Android app and it was pretty garbage 07.10.08 # VLC for android has plugins now 07.10.12 # Sadly, Android features are so tightly knitted to the UI 07.10.19 # <[Saint]> The reason why Rockbox never made it to the play store is multi faceted. 07.10.34 # <[Saint]> the primary reason is that we much target a specific resolution for the framebuffer. 07.10.46 # Yeah, I remember reading that 07.10.55 # Doesn't seem like a huge issue 07.11.00 # <[Saint]> So instead of a single app, there would be hundreds. 07.11.08 # <[Saint]> it's a very huge issue. 07.11.14 # That's got to be like 5% of what Rockbox does 07.11.24 # It's just the freakin' menu 07.11.59 # But sorry if I'm way off base 07.12.06 # <[Saint]> Well, given that it _won't even boot_ if the application and host don't agree on the framebuffer in modern Android, it is a massive issue. 07.12.19 # <[Saint]> you are, it makes it sound like we're just lazy. 07.12.34 # <[Saint]> there's many very real and fundamental reasons this never happened. 07.12.59 # mainly because saint is lazy :p i'm sure of it 07.13.20 # * [Saint] nods 07.13.51 Quit atsampson (Ping timeout: 240 seconds) 07.15.05 # <[Saint]> Technically speaking you could run a Debian armhf/el/eabi chroot in Android and run the sim or SDL app builds there. 07.15.19 # <[Saint]> but that's a hilarious chain of things just waiting to break. 07.24.33 Quit TorC (Ping timeout: 260 seconds) 07.35.28 # It sounds like the core functionality and the UI are tightly coupled in Rockbox 07.38.23 Join TorC [0] (~TorC@fsf/member/TorC) 07.39.09 # Another thing I'm curious about is how the decoding code compares to ffmpeg 07.40.01 # I wonder if its smaller and more efficient since it had to run on embedded devices 07.42.10 # I think it might be fun to refactor Rockbox and use the JNI to create an Android UI 07.42.40 # But I don't know if it would be easier to start from scratch 07.42.52 # Rockbox has a lot of cool features 07.43.08 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.43.08 Quit pixelma (Quit: .) 07.43.19 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.43.20 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.44.35 # I think there might be a licensing issue though since Rockbox is GPL, right? 07.44.59 # <[Saint]> It is, but no, there wouldn't be. 07.45.16 # If you distributed an apk in the Play store, the user wouldn't be able to view the source 07.45.23 # Or change it 07.45.27 # <[Saint]> So what? 07.45.38 # <[Saint]> These are not mutually exclusive things. 07.45.39 # I think that might be against the GPL terms 07.45.58 # <[Saint]> Source msut be supplied to those distributed a binary in a reasonable format on request. 07.46.02 # <[Saint]> Not proactively. 07.46.07 # Oh really 07.46.11 # <[Saint]> Really really. 07.46.18 # Okay, that's good 07.46.48 # <[Saint]> fun fact: "reasonable format" is unreasonably (pun intended) vague. 07.47.00 # <[Saint]> Technically, you could print it out on A4 letterhead and mail it to them 07.47.21 # Well, if it was on Github with compilation instructions I think that would be sufficient 07.47.37 # <[Saint]> Entirely so. 07.47.56 # <[Saint]> As for how Rockbox compares to ffmpeg in the coded sense - basically identically. 07.48.24 # Does Rockbox predate ffmpeg? 07.49.13 # Maybe it would be better to just port mpv to Android 07.49.18 # <[Saint]> Yes. 07.49.28 # <[Saint]> Rockbox is about 16 years old now. 07.50.08 # But Rockbox has playlist and audio features not in mpv 07.50.36 # <[Saint]> You might want to look at Warble/librockbox. 07.50.48 # Oh, librockbox? 07.50.53 # That sounds cool 07.50.57 # Is that new? 07.50.57 # <[Saint]> It's in our source tree. It's a demo of a standalone playback library. 07.51.07 # Very cool 07.51.08 # <[Saint]> No. It's about 6 years old. 07.51.21 # <[Saint]> Spawned from our last GSOC. 07.51.25 # Was the Android Rockbox not built on that? 07.51.49 # <[Saint]> No. 07.52.16 # So maybe an Android UI and JNI bindings to librockbox could work 07.52.25 # <[Saint]> The Android port uses the same core code all the embedded ports do. 07.52.43 # <[Saint]> Honestly, you'd be better off just using android-ffmpeg. 07.53.14 # <[Saint]> it's infinitely more feature complete than librockbox. librockbox was just a proof of concept. 07.53.19 # Does ffmpeg have equalizer stuff and other signal processing? 07.53.29 # <[Saint]> Yes. 07.53.40 # Oh 07.53.53 # Yeah, I would love to have an android player based on ffmpeg 07.54.04 # I guess VLC might do that 07.54.28 # I just thought VLC for Android was crappy compared to Rockbox 07.54.35 # Much slower and less intuitive 07.55.06 # <[Saint]> You're not wrong about the slower part. 07.55.13 # <[Saint]> Intuitive might be arguable. 07.55.27 # I couldn't do some of the playlist stuff 07.55.31 # <[Saint]> I don't really think there's anything about our UI that's intuitive at all. 07.55.57 # It has been a while since I tried VLC 07.56.00 # <[Saint]> It's the best we can do with the absurd amount of granularity we have though. 07.56.27 # <[Saint]> it's hard to make a UI that holds several hundred settings intuitive. 07.59.35 # Just tried VLC 07.59.39 # It's so garbage 07.59.53 # I can't even explain the amount of shitty things going on 08.00.29 # There's a tooltip that keeps popping up and it cover up everything 08.00.50 # If I try to select VLC in the app switcher, it doesn't work and goes to my home screen 08.01.11 # When I play one file in a directory, it doesn't add the rest to the playlist 08.01.21 # It's laggy as af 08.01.28 # laggy af 08.01.55 # There are weird icons that don't say what they do 08.02.52 # The Rockbox UI is just a straightforward list. Sure, there are a lot of submenus and you have to backtrack a bit, but at least it's not doing annoying or unpredictable stuff 08.03.48 Join ender` [0] (krneki@foo.eternallybored.org) 08.05.04 # Like "playback speed" is an icon of a dude running 08.06.13 # <[Saint]> The one obvious benefit with VLC is HW accelerated decoding on supported targets. So no matter what it's always going to be infinitely more efficient. 08.08.00 # Hm 08.08.08 # Well, I must be lacking it lol 08.08.22 # I have a rather old phone and rockbox is much smoother 08.09.03 # The UI of VLC is not so bad as I mess with it 08.09.14 # Starting to figure it out 08.12.51 # I don't see an option to set the file browser root 08.15.15 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) 08.25.26 Join Moarc [0] (~chujko@a105.net128.okay.pl) 08.38.47 *** Saving seen data "./dancer.seen" 08.39.34 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.39.37 Quit wodz (Client Quit) 08.39.56 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.46.32 Join petur [0] (~petur@91.183.48.77) 08.46.32 Quit petur (Changing host) 08.46.32 Join petur [0] (~petur@rockbox/developer/petur) 08.51.30 Join JdGordon_ [0] (~jonno@124-148-155-218.dyn.iinet.net.au) 08.51.30 Quit JdGordon_ (Changing host) 08.51.30 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 09.13.05 Quit TorC (Ping timeout: 240 seconds) 09.14.08 Join TorC [0] (~TorC@fsf/member/TorC) 09.39.21 Quit TorC (Ping timeout: 245 seconds) 09.50.24 Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) 09.58.59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.06.31 # chrisjj: I'll send you a build for cd8b33327c9 10.19.36 Quit krnlyng (Ping timeout: 258 seconds) 10.30.51 Quit elensil (Ping timeout: 240 seconds) 10.32.16 Quit pamaury (Ping timeout: 245 seconds) 10.32.52 Join krnlyng [0] (~liar@178.114.70.41.wireless.dyn.drei.com) 10.37.17 Quit Tristitia (*.net *.split) 10.37.17 Quit benedikt93 (*.net *.split) 10.37.34 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 10.38.46 Quit scorche (*.net *.split) 10.38.47 Quit mc2739 (*.net *.split) 10.38.47 Quit K1773R (*.net *.split) 10.38.49 *** Saving seen data "./dancer.seen" 10.39.06 Quit prg318 (*.net *.split) 10.39.06 Quit GodEater (*.net *.split) 10.39.06 Quit rogeliodh (*.net *.split) 10.39.09 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.39.19 Join GodEater [0] (~whoknows@176.253.28.187) 10.39.19 Quit GodEater (Changing host) 10.39.19 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 10.39.29 Join scorche [0] (~scorche@rockbox/administrator/scorche) 10.39.48 Join prg318 [0] (~prg318@deadcodersociety/prg318) 10.40.12 Join Tristitia [0] (~tristitia@static-ip-69-64-50-196.inaddr.ip-pool.com) 10.40.25 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 10.41.26 Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) 10.48.58 Join elensil [0] (~edhelas@2001:1c02:1903:d800:611e:2ad2:8fd2:c667) 10.49.56 Quit xorly (Ping timeout: 252 seconds) 10.54.00 Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) 10.54.30 # pamaury: beep_test opens /dev/icx_beep and then calls a few ioctl() ICX_SOUND_BEEP (0x620b4004) and ICX_BEEP_STATUS (0x6201c004) 11.10.51 Join parchd [0] (~parchd@unaffiliated/parchd) 11.21.50 Join TorC [0] (~TorC@fsf/member/TorC) 11.29.32 Quit xorly (Ping timeout: 252 seconds) 11.36.15 Join Piece_Maker [0] (~Acou_Bass@host-89-241-241-2.as13285.net) 11.38.18 Quit Acou_Bass (Ping timeout: 260 seconds) 11.38.18 Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-89-241-241-2.as13285.net) 11.41.53 Join xorly [0] (~xorly@wifi-cl-57.feld.cvut.cz) 11.42.21 Join robertd1 [0] (~root@201.242.214.237) 12.20.33 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) 12.20.33 Quit pamaury (Changing host) 12.20.33 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.23.31 Join Mihail [0] (25d4b372@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.179.114) 12.26.18 # wodz: I want add scaling for CVDD2 on AMSv2 (http://forums.rockbox.org/index.php/topic,51616.0.html). But at low values of CVDD2 internal flash stop working. If I revert voltages to normal - it accept CMD0, CMD8 (response 0x1AA) but stop with timeout on ACMD41 (response 0x40ff8000). I try power off (MCI_PWREN) but internal flash and sd card always 12.26.18 # work, so probably both powered directly to CVDD2. Are you have idea how reset internal flash controller or what should I check/try? 12.26.42 # I am not amsv2 guy, sorry 12.26.47 # Mihail: ^ 12.29.31 # but you know well sd spec :) way to reset sd card without power off? 12.30.21 Quit holyheels (Read error: Connection reset by peer) 12.31.47 # Mihail: Other then usual cmd0 and 74+ clock cycles - no 12.35.59 Quit gs6 (Read error: No route to host) 12.36.01 # I already try it, also try CMD0 with argument of 0xFFFFFFFA and 0xF0F0F0F0 (from emmc spec) - no success :( 12.37.40 # If you have time can you review http://gerrit.rockbox.org/r/#/c/1469/ ? 12.38.51 *** Saving seen data "./dancer.seen" 12.39.07 Quit xorly (Ping timeout: 258 seconds) 12.40.34 # Mihail: Are you sure you want to panic on failed sd transfer? 12.42.56 # I want to remove this checking at all - count > 0 have no sense. But first check if we have this case. 12.43.18 # count < 0 12.43.55 # Mihail: I mean line 776 of gerrit task 12.45.05 # aaa, it is just sanity check so it may make sense 12.46.04 # yes 12.48.27 # probably I should change it to "count < 1" as count == 0 also have no sense 12.49.16 Quit Ruhan (Quit: Connection closed for inactivity) 12.53.11 Join atsampson [0] (~ats@cartman.offog.org) 13.02.10 # pamaury: radio_test binary uses some 'private' IOCTLs. According to the strings this are to access tuner registers, tuner GPIO2 ???, and perform reset. 13.03.06 # pamaury: There are some standard IOCTLs as well, namely VIDIOC_G_TUNER and VIDIOC_S_TUNER 13.04.19 # pamaury: Ah, and VIDIOC_QUERYCAP 13.08.20 Join holyheels [0] (~holyheels@52d3d456.dynamic-ip.k-net.dk) 13.09.50 Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) 13.15.22 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:6580:4f45:dca9:4816) 13.17.39 # pamaury: 'private' IOCTLs are of type 'v' instead of v4l2 'V' 13.27.41 Quit fulon (Ping timeout: 245 seconds) 13.29.18 # pamaury: FYI, the last run of 7e0820fe2 (on the unit (Unit Q) where some previous runs crashed) has gone 10h with no crash. 13.30.28 # Also be68b6a7bM-170108 (memDFS) on a second unit (Unit G) has run with no crashes - 8h so far. 13.31.17 # So, mysterious variation. 13.35.36 Quit parchd (Ping timeout: 245 seconds) 13.49.21 Join mutnai [0] (6db90a3e@gateway/web/freenode/ip.109.185.10.62) 14.00.09 Join skapazzo [0] (~skapazzo@151.9.205.1) 14.01.35 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-evdjrwapctrpofwt) 14.11.37 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 14.26.01 Quit xorly (Ping timeout: 245 seconds) 14.32.50 # chrisjj: that's weird 14.33.13 # it would interesting to bisect on the unit where it crashes though, to see if we can find a particular commit responsible 14.34.03 # pamaury: sony's kernel module definitely supports 'v' IOCTLs but I can't find definition for this in sources 14.34.22 # wodz: not all ioctls are in the headers unfortunately 14.34.39 # it's good to know there exists ioctl to access registers directly though 14.34.59 # this means that we can either try to use v4l2 interface or directly the tuner and reuse some of our drivers, depending on what is best 14.35.18 # pamaury: as well as it seems registers are exposed through /proc 14.35.29 # ah yes I remember that 14.35.43 # wodz: can you try to document this somewhere on the wiki ? Like SonyNWLinuxTuner ? 14.36.23 # direct register access will have the benefit of bypassing region and dependence on nvp thing 14.37.45 # good point 14.38.02 # however we are not sure what tuners are in use 14.38.15 # I think it would be a good idea to gather a list of components for each player 14.38.40 # the soc is easy but for dac and tuner, it's 14.38.43 # you could go for sony nw-s10 series instead of nwz-e580. it supports FLAC , NC headphones included and 77 hours of battery, but no microSD slot. 14.38.43 # tricky 14.38.54 *** Saving seen data "./dancer.seen" 14.38.56 # for Yogurt 14.39.22 # The clean way would be to use standard v4l2 interface and let sony handle the burden 14.39.47 # mutnai: there is no 'instead', I'll support as many as I can. However I don't have a nw-s10, I would need at least someone with the device to run things on it for me 14.39.53 # wodz: agreed 14.40.29 # pamaury: The only thing I am not sure is how 'compliant' sony's driver is 14.43.43 # pamaury: Weird agreed. 14.46.31 # Can we make PANIC send info somewhere apart from the screen? E.g. to \panic.txt? To USB? Even to audio out! 14.46.55 # mutnai: also the S10 is quite expensive 14.47.28 # chrisjj: not really, but we don't know for sure if it's a panic 14.47.37 # does the WEN have a LED ? 14.47.44 # sorry... this was for Yogurt, for yesterday discuss ) 14.48.01 # The ZEN does have a LED. 14.48.02 # chrisjj: what I could do, for debug purposes, is to make backlight blink on panic 14.48.09 # and/or the LED 14.48.14 # that way it's easy to tell 14.48.21 # hell, ioctl code in this sony's radio driver is convoluted :/ 14.48.52 # I'd guess backlight blink on panic will be visible regardless of how messed up the LCD is. 14.49.05 # LED blink on panic would certainly be visible. 14.49.54 Quit paulk-blaze (Remote host closed the connection) 14.50.06 # chrisjj: ok, I'll look into it tonight. LED blinking on panic sounds like a good idea in general on target that have a LED 14.50.18 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 14.51.46 # Is the current LED behaviour due to .rockbox? Or some hardware process? 14.53.02 # it's controllable by software 14.53.30 # on the ZEN X-Fi it's basically a red-green led controlled by two PWN. On LED I think it's a (blue ?) LEd controlled by a PWM 14.53.48 # *On ZEN I think it's a blue LED 14.54.03 Quit fs-bluebot (Ping timeout: 258 seconds) 14.55.05 # Indeed I have only even seen the ZEN LED show blue. 14.55.28 Quit bluebrother (Ping timeout: 248 seconds) 14.56.42 # I know it is controllable by software, but I'm interested to if it is controll/ed/ by software when working under RB. I.e. it is RB itself that is turning the LED from dim to bright on start-up, and off on shut-down? 14.56.55 # Currently rockbox doesn't use LEDs, because I don't know what to do with them ^^ 14.57.18 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 14.57.20 # I think Creative's bootloader send them to some state on boot and we don't touch them but we could 14.57.24 # *set them 14.57.38 # OK, as I suspected. So I take it the LED behaviour under RB is actually due to hardware e.g. the PWM running on auto. 14.58.19 # yeah but PWM can be changed, the point of PWN is that you setting a brightness setting and you let the hardware handle it 14.58.59 # however if you want blinking led, that requires software 14.59.14 # what would you use the LED for ? 14.59.51 # I understand PWM. 15.00.26 # What I don't know is what is causing the LED to go from dim to bright when RB starts. 15.01.01 Quit jhMikeS (Ping timeout: 245 seconds) 15.01.19 # pamaury: unless you can control PWM freq. With low freq you can set fill factor to 50% and voila - you have nice blinking led 15.02.06 # chrisjj: Creative's bootloader as I said 15.02.18 # OK. 15.02.59 # Then what is causing the LED to go from bright to off (as I see) upon this mystery crash to power-off?? 15.03.02 # wodz: ah yeah good point, I was more thinking about a slowing diming LED, indeed if you just want on/off, PWM can do it 15.03.45 # chrisjj: maybe the device simply powers off completely 15.04.03 # on panic you don't need to be fancy with dimming 15.04.28 # pamaury: OK, then that leaves the question of how a RB crash could power off the device completely. 15.04.49 # the watchdog can do that 15.05.29 # On imx233 I enable the watchdog. If the device crashes really hard (typically in interrupt context), the watchdog could trigger and reset the device 15.05.38 # Ah, right... 15.06.00 # And "reset the device" == put into the power-off state? 15.08.26 Join fs-bluebot [0] (~fs-bluebo@xd9baf6fc.dyn.telefonica.de) 15.09.14 # chrisjj: I don't remember, I need to read the datasheet. I think it's a reset, so it reboots but then the bootloader notices that the user is not holding the power button so it disregards the boot and powers off 15.09.33 # Figures. 15.09.53 # A real PITA for debugging! 15.10.25 # Can I ask: why is reset-on-watchdog in use? 15.10.53 # good practice? 15.12.18 # good practice, if you reach this your device in unrecoverable anyway 15.14.00 # Good practice /on stable commercial software/. 15.14.11 # Can you think of any advantage on RB currently? 15.14.51 # can you think of any disadvantage ? 15.15.08 # it the reset button is not accessible that's useful 15.17.55 Quit paulk-blaze (Remote host closed the connection) 15.18.15 # I can think of a big disadvantage. 15.18.20 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 15.19.07 # "your device in unrecoverable anyway" but the PANIC info on screen is not unrecoverable. It stays... unless a watchdog reset wipes it. 15.20.30 # reset on watchdog can make sense in release software on devices without accessible reset button, but on ZEN the reset button is accessible by paper clip. 15.22.08 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 15.22.23 # chrisjj: you don't understand 15.22.31 # watchdog won't trigger on panic 15.22.40 # Please clarify :-) 15.22.41 # watchdog triggers if the entire system freezes 15.22.56 # Understood. 15.23.08 # if watchdog wasn't enabled, your device would go unresponsive, no panic, no thing 15.23.46 # Only because if the software so chooses. 15.24.16 # ? 15.24.28 # pamaury: How do you 'feed' watchdog? 15.24.28 # the software doesn't choose to crash 15.24.46 # Software can choose to use the watchdog to trigger reset... or choose not to. 15.25.11 # chrisjj: That is not the purpose of watchdog. The reset is side effect. 15.25.16 # wodz: I reset the watchdog on every timer IRQ iirc 15.25.28 # chrisjj: a watchdog only does reset 15.25.55 # Understood. Still it is the software's choice. 15.25.57 # you cannot detect the watchdog triggering because by definition it means your software is malfunctioning 15.26.09 # Understood. Anyway, I'm not trying to persuade you to change the RB choice. 15.26.22 # pamaury: That what I thought. You shouldn't do that in IRQ. It may happen that firmware enters infinite loop with irqs on. This will not trigger watchdog. 15.26.23 # chrisjj: let it put differently: how does software detects that it is not working ? 15.26.57 # Hey, you don't want to ask that of me. I'm an honours Computer Scientist :-) 15.27.13 # wodz: not sure what you mean. If the softwarre gets stuck in IRQ context, it will trigger because it is only reset when IRQ is entered 15.27.23 # I'm trying to understand if there's some advantage in RB choosing to engage a watchdog to give reset on freeze. 15.27.33 # chrisjj: what else can you do ? 15.27.34 Quit pamaury_ (Ping timeout: 240 seconds) 15.27.46 # the only other option to let it freeze 15.28.08 # pamaury: I mean if software is stuck in main loop BUT irqs are unmasked it will fire indefinitely and hence watchdog will be happy 15.28.11 # You can do nothing, let the s/w freeze and (hopefully) read the valuable PANIC info from the surviving LED display. 15.28.48 # wodz: I know but there is no easy way to detect that the 'userland' is frowen 15.29.01 # chrisjj: THERE IS NO PANIC ON FRICKING FREEZE 15.29.21 # Understood. But is there a freeze after PANIC?? 15.29.29 # pamaury: Feed watchog in some thread (UI?) 15.30.04 # pamaury: recall what we're seeing. The device powered down after (what you suggested might be) a PANIC. 15.30.45 # chrisjj: then there is no panic, software gets stuckm, watchdog triggers and powers off. The panic screen disabled the watchdog obviously 15.31.56 # Ah, if you're sure panic screen disables the watchdog, then I see no way the power-down state can be hiding a PANIC as (I think) you suggested. 15.32.24 # wodz: I knwo but that means we need so place in apps/ that would do that 15.32.51 # FAOD, this is assuming "panic screen disabled the watchdog obviously" means disabled such that there will be no watchdog expiry and hence no reset cause by watchdog. 15.32.56 # chrisjj: you mentioned the screen was dark, it was not clear if it was a power-down 15.33.31 # chrisjj: you claim the LED is off but you only said that after I suggested it. And inddeed the LED being off seems to indicate it's a real power down 15.33.36 # I actually said also that the state reponds to power press by entering power-up. 15.33.52 # yes but that's no indication 15.34.02 # because the panic screen will also reboot if you hit power 15.34.16 # How so? I know no other state the reponds such. 15.34.40 # wodz: maybe we could have a 'software watchdog' that resets on thread switch ? 15.35.00 # pamaury: ? 15.35.19 # to detect when a thread is stuck 15.36.02 # you setup a timer of expire after 10sec, and reset the timer on every thread switch. If the timer expires, panic 15.36.22 # should work 15.36.29 # pamaury: And does the panic screen turn off the LED?? I thought not. 15.37.56 # pamaury: The canonical way to do that actually is that each thread sets bit in guard variable. When timer expires guard variable is checked if all bits are set. If not trigger some action (panic, reset, whatever) 15.38.35 # that would mean nontrivial changes in the threading code though no ? 15.39.00 # Who said this is trivial change :-) 15.39.02 Quit mutnai (Quit: Page closed) 15.39.07 # haha 15.39.10 # embedded development is non trivial 15.39.31 # generally speaking having such a mecanism in rockbox in general would be nice 15.39.49 # it can use the tick task as a timer 15.42.29 # pamaury: PANIC screen caused by the ZEN USB issue does /not/ turn off the LED. I'll continue to assume no PANIC turns off the LED, unless you advise otherwise. 15.44.42 # pamaury: We do check stack guard on context switch. This shouldn't be too hard to extend to check/set guard bit as well. 15.45.17 # wodz: how does this work exactly ? Each thread has a variable and what/when set/checks the bit 15.45.19 # ? 15.46.01 # each thread sets its bit when it is switched to and regularly one checks if the bits are set and clear them, panic if on bit is not set ? 15.46.48 # pamaury: Yes. There is one guard variable however. Like bitfield. 15.52.01 # ok 15.54.27 Quit wodz (Quit: Ex-Chat) 15.56.26 Quit rela (Ping timeout: 245 seconds) 15.58.39 # pamaury: I confirm that the memDFS fail had LED off. Re your "you claim the LED is off but you only said that after I suggested it.", if you doubt my report, no problem. You should be able to confirm it on the device you have. If you need another device from me, just ask. 16.01.12 # So, the fail state looks to me 100% like a power-off. And you've said the angered watchdog does reset to power-off. So I think it reasonable to conclude that this fail state is due to watchdog angered by e.g. freeze. 16.05.28 # Re your 'what would you use the LED for ?', in PANIC I would blink it ... /if/ that could be done in hardware and no continued software execution, but https://www.rockbox.org/wiki/pub/Main/DataSheets/stmp35xx-ds-1-03.pdf suggests to me not (<< wodz). 16.06.54 # stmp35xx does not apply, you want to look for the stmp37xx datasheet, and yes it can be done 16.07.00 Join fulon [0] (~vshyba@178.62.192.54) 16.08.53 # I looked an could not find the datasheet for the ZEN's STMP3760. I did find your wiki note of differences, and saw no mention of any difference in PWM. 16.09.40 Quit MrZeus (Ping timeout: 256 seconds) 16.10.19 # chrisjj: stmp3760 falls into the scope of stmp3700 16.11.34 # https://www.rockbox.org/wiki/pub/Main/DataSheets/stmp37xx-ds-1-03.pdf 16.14.16 # Thanks. Same applies. I don't see enough division for hardware LED blink. But if you say it can be done in hardware, I'm sure you're right :) 16.15.39 # If you can add LED blink during PANIC screen, that would be great. Perhaps encode some sub-info in the blink rate? Shame the hardware can't do morse code to spell out the PANIC text! :) 16.15.41 # One uses PWM 16.16.21 # the output of the PWN goes to the gate of a transistor that controls the LED input. By changing the frequency and duty cycle, one can dim and blink the LED 16.18.25 # Understood 100%. But to make it /blink/, one needs a long divider... which I don't see on this chip. 16.21.10 # chrisjj: there is plenty of room. The click is 24MHz, each channel has a local divider (CDIV) in range 1-1024 and then the PERIOD (measured in divided clock) can range from 1 to 65525 16.21.49 # so you can basically reach blinking ~1Hz, if my math is correct 16.22.59 # I make it 0.3Hz. Great! 16.25.35 # Then seriously I think you could get three eye-resolvable bits of PANIC info in the pulse rate and width. 16.29.20 Join Senji_ [0] (~Senji@85.187.103.250) 16.34.37 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 16.35.05 # If LED panic is going to go in core RB for users generally, perhaps the easiest encoding would be just rate, measured by eye by counting the number of pulses over e.g. 10secs. 16.35.59 # that seems way overkill to be honest. A blinking led is a good start 16.37.56 # Fari enough. Esp. since I predict we're not going to see a blink in this case. We'll see dark - because the device is powered down. 16.38.11 # BTW, is there a PNIC counter stored anywhere? 16.38.56 *** Saving seen data "./dancer.seen" 16.43.44 Quit paulk-blaze (Ping timeout: 248 seconds) 16.48.58 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 16.50.34 Quit paulk-blaze (Remote host closed the connection) 16.54.19 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 17.26.54 Join aude_ [0] (6df78c7b@gateway/web/freenode/ip.109.247.140.123) 17.28.31 Join n3m9 [0] (~n3m9@ANantes-652-1-183-36.w2-1.abo.wanadoo.fr) 17.28.35 # hi. I recently lost my Clip Zip in a jacket that was stolen (not surprising, there was a Clip Zip with Rockbox in it after all). I'm looking for a new device. any recommendations? :) 17.32.57 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 17.38.16 Join MrZeus [0] (~MrZeus@81.144.218.162) 17.40.01 Quit petur (Read error: Connection reset by peer) 17.43.12 Quit pamaury (Remote host closed the connection) 17.46.10 Join chrisb [0] (~chrisb@pool-71-175-247-154.phlapa.east.verizon.net) 17.46.51 Quit pamaury_ (Ping timeout: 240 seconds) 17.54.52 Quit paulk-blaze (Quit: Leaving) 18.38.35 Join JanC_ [0] (~janc@lugwv/member/JanC) 18.38.57 *** Saving seen data "./dancer.seen" 18.39.48 Quit JanC (Killed (orwell.freenode.net (Nickname regained by services))) 18.39.48 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 18.47.48 Quit aude_ (Quit: Page closed) 18.51.40 Join Senji [0] (~Senji@85.187.103.250) 18.53.31 Quit Senji_ (Ping timeout: 240 seconds) 19.16.01 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 19.17.09 Join parchd [0] (~parchd@unaffiliated/parchd) 19.18.53 Join petur [0] (~petur@rockbox/developer/petur) 19.19.03 # <[Saint]> It really bugs that shit out of me that chrisjj chooses to argue with highly experienced embedded software developers based on nothing but the notion of how he believes things should work in fanciful chrisjj-land. 19.19.20 # <[Saint]> So much so, I'm very highly considering just removing the problem entirely. 19.19.48 # <[Saint]> Take that as fair warning my man. 19.21.22 # There is a difference between walking in nature and being out to feed the trolls 19.22.52 # what's happening? 19.23.06 # <__builtin> chrisb: not you 19.23.40 # chrisjj != chrisb 19.23.44 # ok 19.24.09 # <__builtin> [Saint] and a bunch of others are rather annoyed by chrisjj's, uh, "behavior" 19.24.23 # * chrisb just updated two old sansa e250's to the latest release 19.24.43 Part __builtin ("http://quassel-irc.org - Chat comfortably. Anywhere.") 19.24.47 Join __builtin [0] (~xray@rockbox/developer/builtin) 19.25.18 # <[Saint]> At this point I find it basically impossible to believe that chrisjj isn't going out of his way to antagonize. 19.25.57 # <[Saint]> It's either that, or being entirely socially inept, and needing to take a step backwards and reevaluate things drastically. 19.30.40 Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) 19.40.13 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 19.41.39 # Seems he is just making conversation, what is the issue? 19.41.59 Quit n3m9 (Read error: Connection reset by peer) 19.44.02 # <[Saint]> I find it pretty hard to believe anyone could read the backlog and say that, but so be it. 19.44.36 # <[Saint]> One supposes a lot of it is contextually sensitive with reference to historical action. 19.52.49 # If you dont entertain the thought of being wrong, maybe you put too much faith in being right 19.54.11 # * gevaerts wonders how that statement is in any way relevant for #rockbox 20.12.55 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.27.22 Join johnb2 [0] (~johnb2@p5B296F82.dip0.t-ipconnect.de) 20.32.35 # Database->Autoupdate: am I right assuming, that this is done only once after boot or unplug from USb? 20.35.13 # Mihail: as the forum is down again, would you mind giving the link to the clip+ build here on IRC? 20.38.58 *** Saving seen data "./dancer.seen" 20.40.57 # <[Saint]> johnb2: you are both correct and incorrect. 20.41.08 # <[Saint]> There's another case, insertion of removable media. 20.44.14 # how can i determine the max removable memory the sansa e250 can address? 20.45.49 # <[Saint]> By looking at the sd specification and knowing that it is 4TB and we'll literally never hit that density. 20.46.39 # <[Saint]> which is a long winded way of saying that any capacity you throw at it will work under Rockbox. 20.46.59 # [Saint]: ok, thanks 20.47.01 # <[Saint]> The OF may or may not have arbitrary limitations. 20.47.37 # OF? 20.49.55 # <[Saint]> Original Firmware 20.51.22 # Mihail: never mind, Firefox remembered the URL: http://knk.square7.ch/cvdd2/ 20.55.15 # [Saint] 20.55.46 # pamaury: because of the standby mode, you can't get the boot selection screen once you used the OF -_- Same problem on yp-r0. We solved it by adding a reset function when you press power off several seconds. That way you don't need a pencil everytime to press the reset hole... I don't know if that would be possible on NWZ 20.55.52 Join wodz [0] (~wodz@89.74.169.198) 20.56.00 # thanks, and this is nothing relevant regarding power consumption on a flash based device, right? 20.56.13 Quit alucryd (Remote host closed the connection) 20.56.51 # lebellium: you can plug usb, no need for reset 20.56.55 # pamaury: http://paste.debian.net/908141 20.57.08 # lebellium: I'm not sure it's possible to do that but I'll have a look 20.57.14 # pamaury: I mean when you're not at home 20.57.18 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 20.58.16 # lebellium: I know, I was teasing you ;) 20.58.26 # relevant = significant 20.58.28 # and mentionning that usb "solves it" if you can 20.58.38 # pamaury: also I would display "Rockbox" first instead of "walkman" and make it the default selection after a short timeout 20.58.48 # wodz: ok, fmp doesn't seem very useful at first glance... 21.00.01 # lebellium: the bootloader will (when I implement it) remember the last user choice 21.00.09 # and only show the menu when switch is on 21.00.14 # at least that's my current plan 21.00.15 # nice :) 21.03.00 # I think it is possible install another program on the device to monitor the power button and start it from sysv init 21.05.03 # pamaury: FWIW, 7e0820fe2 (on the unit (Unit Q) where some previous runs crashed) has now gone 17h with no crash. And be68b6a7bM-170108 (memDFS) on a second unit (Unit G) has gone 15h with no crash. 21.06.54 # So even though resuls are no solid repeatable, they should give us enough battery_bench data to determine the memDFS saving, and perhaps enough crashed to determine the casue on a more-debuggable build. 21.07.24 # pamaury: Is there a PANIC counter? 21.07.42 # no, why would there be ? 21.08.45 # OK. Why? So after a reset we can see whether there had been a PANIC hidden by the failed LCD. 21.09.47 # I think you are a bit obsessed with the panic screen. May I remind you that the goal is to avoid panic and not counting how many of them you manage to achieve ? 21.10.18 # <[Saint]> Gotta catch 'em all, PANICmon. 21.10.24 # Thanks, I am duly reminded :) 21.10.38 # And avoiding this panic is exactly what I'd like to do. 21.11.12 # You suggested this black screen is hiding a panic, but we don't know if it is. A panic counter would answer that. 21.11.35 # However your blinking LED will answer it. 21.11.49 # <[Saint]> If you PANIC, there's no guarantee you can iterate the counter. 21.11.53 # <[Saint]> It's irrelevant. 21.11.54 # the LED blinking would answer that. I think we first need to try to run the commit before the lcd_fix 21.12.05 # <[Saint]> You'd have to know you were going to PANIC before you did. 21.12.11 # <[Saint]> And if you knew that, you wouldn't... 21.12.26 # we know that some recentish builds panic, and that the lcd_fix didn't, so the natural commit to try is the parent of the lcd_fix 21.13.14 # <[Saint]> the guts of what I'm saying is that there's no way to reliable implement a PANIC counter, even in a world where it was a rational thing to do. 21.13.16 # OK. 21.14.09 # Though it seems the panic cause is /subsequent/ for the lCD fix, no? 21.14.16 Join Bray90820_ [0] (~bray90820@173-25-204-30.client.mchsi.com) 21.14.19 # s/for the/to the/ 21.14.40 Quit Bray90820 (Ping timeout: 248 seconds) 21.15.02 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) 21.18.41 # chrisjj: I want to rule out the possibility that lcd_fix is actually fixing some crash (elsewhere than in the bootloader) 21.19.01 # when we confirm that, we can properly bisect between this commit (known working) and HEAD 21.19.31 Quit Bray90820_ (Ping timeout: 240 seconds) 21.20.23 # Are you thinking that lcd_fix could have fixed a crash /and/ then that fix got busted by a subsequent commit? 21.23.50 Quit alexweissman (Remote host closed the connection) 21.23.57 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 21.25.39 # that's unlikely but you are the one that want to rigorously test everything usually 21.28.18 # <[Saint]> you mean to say you're not interested in the frequency and distribution of a PANIC that shouldn't happen anyway? 21.28.22 # <[Saint]> ...how could you! 21.28.35 # <[Saint]> 21.29.06 # * gevaerts objects to this meaningless capitalisation! 21.29.15 # panic is not an acronym! 21.29.37 # <__builtin> Power ANd Interrupts Cancelled 21.29.45 # <__builtin> :P 21.30.02 # chrisjj: ok, so let's assume that cd8b3332 work (the parent of lcd_fix) 21.30.21 # OK (I'd guess it will)... 21.30.52 # your tests show that 7e0820fe2 and be68b6a7b have a problem right ? 21.30.57 # Right. 21.31.47 # (I'm still the one who wants to test everything rigourously! :-) ) 21.33.12 # (PAmauryNotInControl ;-) ) 21.41.51 Quit parchd (Ping timeout: 245 seconds) 21.47.38 # pamaury, I'll be happy to test the build before the lcd_fix, but I'm interested to know how this helps pinpoint this crash that's appeared /after/ lcd_fix. 21.50.12 # I'm looking at commits in the range cd8b3332..7e0820fe2 and none of them seems relevant for such a crash :-/ 21.51.27 # let me build 8e82839f and send it to you, just to be sure 21.56.55 # chrisjj: https://www.dropbox.com/s/05hu8qoo5tdp4aq/rockbox_zen_8e82839f.zip?dl=0 22.01.42 # Thanks. Running OK so far on Unit Q. 22.02.56 # pamaury: Do you have any idea what icx_sound_refclk0_change() can do? 22.02.59 # FWIW, this reverts the start-up flash pattern to that of lcd_fix. 22.04.51 # In particular, the second appearance of the CREATIVE word again has a 1D screendoor effect in white. I.e. every second pixel row is solid white, with the CREATIVE word in white on black showing one the other rows. 22.06.07 # The flash pattern differs between units which appear identical hardware-wise, so goodness only knows the cause. This somewhat erodes precision in testing. 22.07.51 Join froggymana [0] (~frogs@unaffiliated/froggyman) 22.08.02 Quit froggyman (Ping timeout: 248 seconds) 22.08.06 Nick froggymana is now known as froggyman (~frogs@unaffiliated/froggyman) 22.10.49 # <[Saint]> My understanding is that there's at least two distinct LCDs used. 22.11.58 # wodz: no clue, but part of the icx sound driver is available in the linux code iirc 22.13.00 # pamaury: anyway there is private ioctl which radio_test associate with SETFREQ which calls this function 22.13.31 # well you could try to look in the em1 manuals if it matches something 22.14.13 # maybe it enables/changes the frequency used by the tuner (some tuners don't use a crystal but let the soc generate the clock for them) 22.15.04 Quit chrisb (Ping timeout: 240 seconds) 22.15.05 # pamaury: e47x don't use em1 AFAIK but something newer 22.16.36 # yeah but it's the evolution, that can still be interesting 22.18.02 # wodz: in arch/arm/mach-emxx/include/mach/icx_sound_fchg.h there is the function you mention 22.18.32 # and it is implemented in sound/arm/icx-beep.c 22.18.49 # pamaury: yeah, just reading it 22.19.02 # it's not really obvious from the code what it does :D 22.20.52 # the header has this comment: 22.20.53 # REFCLKO(MCLK) : 11.2896 [MHz] еее default 22.20.53 # REFCLKO(MCLK) : 10.7987 [MHz] 22.21.13 # and it definitely looks tied to tuner 22.22.28 # pamaury: does si407x output digital or analog signal? 22.22.56 # ah, line level analog output 22.23.30 # analog 22.23.32 # afaik 22.24.23 # RCLK like of tuner needs 32.768kHz signal - maybe thats related 22.25.07 # pamaury: 8e82839f has done bad on Unit Q. Screen black, audio silent, keys unresponsive, LED off. Any other observations you need? 22.26.03 Quit tchan (Ping timeout: 246 seconds) 22.30.26 # chrisjj: no, that's weird 22.30.36 # pamaury: Here I documented somewhat my findings about radio interface https://www.rockbox.org/wiki/SonyNWLinuxTuner 22.30.42 # so let me rebuild 8e82839f+lcd_fix 22.31.34 Quit robertd1 (Ping timeout: 240 seconds) 22.32.07 Join robertd1 [0] (~root@201.242.214.237) 22.35.27 # wodz: may the FM tuner have some unused RDS capabilities? 22.36.48 # chrisjj: https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0 22.37.06 # lebellium: That depends which version of si407x they used actually. If this is si4072 then no, if it is si4073 then it supports RDS. Judging from driver disasm I think it may be si4073 22.38.53 # is it Si470x like the Sansa Clip or really Si407x? I can't find much about the latter 22.38.56 # wodz: it could be that this rclk0 is internally multiplied (in the soc) by say 3 22.38.59 *** Saving seen data "./dancer.seen" 22.39.08 # giving a very good estimate of the 32768kHz 22.39.45 # lebellium: It is easy to check actually r1 has chip id field. 22.40.24 # lebellium: what you mean about real Si407x? 22.41.04 # I mean is Si407x a typo? 22.41.21 # I can't find anything about Si4072 on google 22.41.34 # Si470x is famous 22.42.47 # ah, yes a typo. si470x 22.43.25 # Ok 22.43.28 # clearer to me now 22.43.38 # so it may have the same tuner as the Clip Zip 22.44.52 # pamaury: Do you know if there is a way to trigger running radio_test with OF actually? 22.45.04 # Sony never offered RDS in OF but I never knew if it was an hardware issue or only a software matter 22.45.11 # pamaury: like debug menu or something 22.45.22 # wodz: my guess is that radio_test is run by the service menu (which is a sort of debug menu) 22.45.33 # you can reach via a magic key combination described in the service manual 22.45.33 # pamaury: how to enter this? 22.45.47 # alternatively, the rockbox bootloader gives you an option to run it 22.45.56 # wodz: https://docs.sony.com/release/MDSM/989350201_SM.pdf 22.46.13 # manual list here: rockbox.org/wikiSonyNW 22.46.26 # chrisjj: can you test the build I listed above ? (https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0) 22.46.26 # * wodz reading 22.49.38 # Heh, I am too slow touching buttons. I need some practice :P 22.49.47 # Doing... 22.50.24 # wodz: I've done it so much time on E580 and A10 that I almost know the key combo by heart now :D 22.50.30 # many times* 22.51.07 # note that there was a mistake in the key combo of the E580 service manual 22.51.15 # hopefully it's not wrong in the E470 one 22.51.54 # haha, how fancy 22.52.10 # floating bubbles made my day :P 22.53.44 # pamaury: That latest (8e82839feM-170110) on Unit Q shows the same fail. 22.54.55 # chrisjj: unless I made a mistake, this is the same code as the original lcd_fix 22.57.21 Quit wodz (Quit: Leaving) 22.59.24 # How "same"? They aren't binary identical: http://i.imgur.com/LjZCo1j.png 23.03.09 # we don't have reproducible builds, so that's expected, but it's the same source code 23.03.31 # unless the original lcd_fix is not the commit that I think it is 23.03.48 # can you just try https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0 and report ? 23.07.28 Quit Senji (Ping timeout: 252 seconds) 23.09.31 Join StaticAmbience_ [0] (~Quassel@host217-42-102-78.range217-42.btcentralplus.com) 23.10.09 Quit StaticAmbience (Ping timeout: 246 seconds) 23.11.41 Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) 23.13.44 Quit petur (Remote host closed the connection) 23.13.48 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 23.13.52 Quit StaticAmbience_ (Ping timeout: 258 seconds) 23.16.24 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 23.16.25 # OK... 23.18.32 # Hang on. That's the same one. 23.19.43 # I did try the build of your [21:46] and my [21:53] was the report (same fail). 23.20.27 Quit holyheels (Read error: Connection reset by peer) 23.21.17 # BTW, that 'original lcd_fix' (the first successful LCD fix I know) is Version: 45697a0bf-161212. 23.22.52 # chrisjj: unless I am mistaken, 45697a0bf is 8e82839f + lcd fix (as an extra commit). Thus 45697a0bf is the (or should be the) same as 8e82839f_lcdfix.zip 23.23.06 # I hear you. 23.23.12 # now I am worried because you are claiming that 45697a0bf doesn't have this backlight sleep crash but 8e82839f_lcdfix does... 23.23.49 # Your [22:03] asks me to try the build that I already tried from [21:46]. 23.24.54 # chrisjj: yes, I was unsure if you saw my message 23.25.07 # then I realized I miss your "Doing..." message 23.25.12 # OK, got you. I always check your messages before I write mine :-) 23.25.38 # Yes, I am claiming that 45697a0bf doesn't have this fail that 8e82839f_lcdfix does. 23.27.02 # I wouldn't like to call it a backlight sleep crash because I don't know it is really that. I know only that the device goes to what appears to be power-off state (so obviously backlight is off) without good cause. 23.27.39 # BTW, '45697a0bf doesn't have this fail' is based on hundreds of sessions on six devices. 23.34.11 # chrisjj: can you retest https://www.dropbox.com/s/i04b1468tci9ju1/rockbox_zen_lcd.zip?dl=0 23.34.16 # this is the original lcd fix, afaik 23.34.21 # OK. 23.37.12 # (The zip is binary-identical to the original of 2016-12-12.) 23.40.07 # Your [22:34] on Unit Q is has run OK for 52secs. Continuing... 23.44.56 Quit StaticAmbience (Quit: No Ping reply in 180 seconds.) 23.46.22 Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) 23.52.45 Part robertd1 23.53.39 # Now 14min. 23.56.02 Quit xorly (Ping timeout: 256 seconds) 23.56.25 # pamaury, I'm thinking angry watchdog is the only way we know of RB putting the device into power-off, barring power key press. 23.57.32 # You've said *PANIC* screen disables the watchdog, meaning I presume disables the reset effect of angry watchdog. 23.58.53 Quit chrisjj (Quit: Page closed)