| 00:05:27 | chrisjj | So assuming the current fail really is a power-off, does that mean the trigger must be a freeze that prevents your timer IRQ from pacifying the watchdog? Nothing else, to your knowledge? |
| 00:06:55 | pamaury | No that I can think about but how knows. What kills me is that 45697a0bf should be the same as 8e82839f_lcdfix. If you can observe a difference, this is very puzzling to say the least |
| 00:11:45 | pamaury | the only thing that I can think about would be different configure options, but I think I built both as (N)ormal builds, no debug options |
| 00:15:45 | chrisjj | Puzzling, agreed. I'll repeat the tests with sterilised test tubes :-) |
| 00:18:18 | chrisjj | That you built the two with same Normal/Build looks true from the fact the binary sizes are identical. |
| 00:18:36 | chrisjj | The larger version number is presumably absorbed by word alignment. |
| 00:20:20 | chrisjj | I know you don't have binary stability, but any guess as to the binary difference we see? |
| 00:23:11 | | Quit Ruhan (Ping timeout: 240 seconds) |
| 00:24:31 | chrisjj | All of the first few single-byte differences are differences of one e.g. EB -> EA http://i.imgur.com/ToMzPBJ.png . Addresses of shifted data? |
| 00:25:49 | Bilgus | It is hard to say in a compiled binary Disasm then compare |
| 00:26:43 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-qthselhhelhgwuow) |
| 00:27:10 | | Quit ender` (Quit: All great truths begin as blasphemies. –– George Bernard Shaw) |
| 00:27:13 | pamaury | chrisjj: the two contains different strings (ie the revision number), this can change the data section size alignment, make the entire binary to shift by 4 byte, change all addresses |
| 00:29:58 | [Saint] | FWIW, it's not so much that the panic screen 'disables the watchdog', and more that the fact that we panicked means something very fundamental fell over. |
| 00:29:58 | chrisjj | Understood, but ISTM the large version number is absorbed by word alignment in this case. There's no data section displacement. http://i.imgur.com/qRkaNr9.png |
| 00:30:29 | chrisjj | s/large version number/largeR version number/ |
| 00:30:55 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 00:31:32 | [Saint] | I just wanted to be clear because your verbiage seems to suggest that despite repeated clarification that you think that the watchdog service is being disabled deliberately. |
| 00:31:58 | [Saint] | when it's more akin to 'shit totally hit the fan'. |
| 00:32:56 | [Saint] | if a panic was a recoverable state, it wouldn't happen to begin with. |
| 00:33:02 | pamaury | chrisjj: most of the changes I see between the two bins are jumps with slightly different addresses. Comparing diff is inevitably going to be tricky, litterally anything can trigger massive changes in the compile process |
| 00:34:25 | chrisjj | Understood. And I see the gcc version changed. |
| 00:38:37 | pamaury | that's the host gcc, it should make no different, what matters is the arm compiler and it's the same |
| 00:38:58 | chrisjj | Good to hear the compiler is the same. |
| 00:39:03 | *** | Saving seen data "./dancer.seen" |
| 00:39:32 | chrisjj | BTW, re strings, UNIX strings command finds no string changed, other that the version number we know of. |
| 00:41:57 | chrisjj | So, of the 'literally anything can trigger massive changes', it might be useful if we knew even one that might cause today's small changes :-) |
| 00:41:58 | [Saint] | ...which is entirely expected. |
| 00:42:54 | | Quit skapazzo (Quit: leaving) |
| 00:42:59 | [Saint] | even order of operations can change the outcome of non-reproducible builds. |
| 00:43:58 | pamaury | chrisjj: the version number ( 8e82839feM) is included in the binary, so yes there is at least one string that is different. I'm not going to discuss binary changes anymore unless you have something *interesting* to say on the topic. |
| 00:44:21 | chrisjj | Bilgus: pamaury has said source is unchanged so I'm confident disasm would be likewise unchanged. |
| 00:44:35 | [Saint] | well, evidently his definition of interesting is incredibly broad. |
| 00:44:35 | pamaury | rockbox does not have reproducible builds |
| 00:45:40 | [Saint] | you can compile the same build on the same host, with the same host configuration, and still get different yet non-substantive results. |
| 00:45:48 | [Saint] | it's really neither important nor interesting. |
| 00:46:00 | pamaury | and in this case, the source IS DIFFERENT, because the version number is different and it is included in the binary, as I already said 2 times already |
| 00:46:15 | [Saint] | Oh, yes, I know. |
| 00:46:19 | chrisjj | OK. The most interesting this I can say (not saying it is interesting) is that: 1) code behaviour difference, cause unknown 2) code binary differs, cause unknown 3) In the absence of any other explanation for 1, it might be worth considering that there is a causative realtionship. |
| 00:47:13 | [Saint] | Yes, I'm aware this is a different build. Just clarifying that even the same source revision can still produce a different binary and it's non-interesting. |
| 00:47:38 | chrisjj | Good point. Corrting myself: Version number aside, pamaury has said source is unchanged so I'm confident disasm would be likewise unchanged. |
| 00:47:46 | [Saint] | at this stage the only interesting metric is pass/fail. |
| 00:47:49 | [Saint] | that's really it. |
| 00:49:15 | [Saint] | chrisjj: your confidence is unwarranted and no one is really interested in correcting that misunderstanding. |
| 00:49:38 | [Saint] | at this stage it's very clear you can be both confident, and wrong. |
| 00:49:46 | [Saint] | they're not mutually exclusive things. |
| 00:50:11 | chrisjj | Anyone sufficiently unconfident to fancy spending their time comparing the two disasms, please go ahead. |
| 00:50:55 | pamaury | Well let's just hope that it doesn't come to diffing the two bin to understand the difference, because that's going to be a lot of work. |
| 00:51:13 | pamaury | There is another option that we have no considered |
| 00:51:27 | pamaury | chrisjj: did you use RoLo to load the new binary when you changed the firmware ? |
| 00:51:37 | pamaury | or did you do a proper power-down and power up ? |
| 00:51:47 | chrisjj | Good question. I tried both. |
| 00:52:06 | chrisjj | ... thinking that perhaps a ROLO start is unclean. |
| 00:52:14 | pamaury | and both failed ? |
| 00:52:48 | chrisjj | Whoops, my [23:51] crossed with yours. |
| 00:53:52 | chrisjj | Hang on... checking notes. |
| 00:57:03 | pamaury | There is actually another possible explanation, very logical but also very bad: it's a cache+dma problem |
| 00:58:16 | * | chrisjj reaches for garlic |
| 01:00 |
| 01:01:30 | chrisjj | A: Not recorded. Sorry. I can't say for sure that ROLO-started sessions failed or Power-on-started sessions failed, but I can say for sure Reset-started sessions failed. |
| 01:02:04 | chrisjj | I can rerun any tests you need, in the three variants. |
| 01:02:53 | pamaury | chrisjj: please re-run after a clean boot |
| 01:03:05 | chrisjj | Define clean boot, wise one. |
| 01:03:13 | pamaury | power up, power down, power up |
| 01:03:37 | chrisjj | OK. And do you think battery v. external power might affect? |
| 01:04:38 | pamaury | in doubt, just battery. It shouldn't make a difference though |
| 01:04:50 | * | pamaury goes to bed |
| 01:05:46 | chrisjj | OK, though I have to say it makes more of difference that I expect elsewhere. E.g. with external power from charger (not PC), noot attempts to connect to USB. But no matter. Will do. |
| 01:05:56 | | Quit paulk-collins (Quit: Leaving) |
| 01:06:07 | chrisjj | s/noot/boot / (should go to bed too) |
| 01:06:25 | chrisjj | pamaury: And which Version should I test first? |
| 01:09:11 | | Quit The_Prospector (Read error: Connection reset by peer) |
| 01:10:16 | | Quit pamaury (Ping timeout: 260 seconds) |
| 01:11:55 | [Saint] | http://imgur.com/a/IlTn9 |
| 01:12:08 | | Quit cttttt (Read error: Connection reset by peer) |
| 01:12:40 | | Join cttttt [0] (sid135570@gateway/web/irccloud.com/x-gwhjisllgboowodv) |
| 01:12:41 | | Quit anonus (Ping timeout: 255 seconds) |
| 01:13:10 | | Quit Galois (Ping timeout: 240 seconds) |
| 01:13:30 | | Quit megal0maniac (Ping timeout: 240 seconds) |
| 01:13:32 | [Saint] | chrisjj: as with every other target holding any key during plug prevents it from launching USB screen |
| 01:14:26 | | Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) |
| 01:17:00 | chrisjj | [Saint], it is not the USB screen, and holding plug doesn't prevent it. It is boot's attempt to connect to USB, before the .rockbox app launches. |
| 01:17:21 | chrisjj | Thanks anyway for the thought. |
| 01:18:47 | [Saint] | Sorry, I thought you were referring to code that Rockbox actually has control over. |
| 01:22:26 | | Nick __builtin is now known as _builtin (~xray@rockbox/developer/builtin) |
| 01:22:34 | | Nick _builtin is now known as __builtin (~xray@rockbox/developer/builtin) |
| 01:23:06 | * | chrisjj finds builtin's nick changes... fascinating |
| 01:24:04 | chrisjj | [Saint] I was. This code is the Rockbox bootloader. |
| 01:24:33 | [Saint] | chrisjj: at that stage, it isn't. It's a fairly complex process. |
| 01:25:59 | chrisjj | So if this is not Rockbox code, how come the lines above show the Rockbox version number? |
| 01:26:11 | | Join anonus [0] (~anonymous@citadel.niflheim.info) |
| 01:26:35 | * | __builtin can type "Linux" into windows notepad |
| 01:27:27 | [Saint] | Perhaps I'm misinterpreting what you're seeing. |
| 01:31:28 | chrisjj | Or I didn't describe it well enough. |
| 01:31:44 | [Saint] | My understanding is these things have a slightly unusual boot process, not in and of themselves, but in comparison to other targets. I thought you were referring to a host USB mode before the jump to the bootloader. |
| 01:32:13 | chrisjj | On RBed ZEN boot, after CREATIVE and some flashes, I get an image with black background and white text. |
| 01:32:29 | | Quit __builtin (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:32:39 | chrisjj | First line says 'Boot version:' and Rockbox version number. |
| 01:33:31 | chrisjj | When on charger, a line below says "USB connecting". |
| 01:33:44 | [Saint] | And it just stalls there if USB is plugged? Cute. |
| 01:34:00 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 01:34:29 | [Saint] | Apparently it can't tell the difference between charge-only and a USB host. |
| 01:34:58 | [Saint] | It's probably waiting for an imaginary host in the charger to enumerate. |
| 01:35:29 | chrisjj | A: No. It enters "Bootloader USB mode". |
| 01:35:45 | chrisjj | On a charger, it soon times out. No harm done. |
| 01:36:14 | chrisjj | Yes, I agree it can't tell the difference.. until the charger doesn't respond :) |
| 01:37:55 | chrisjj | But that timeout is very impatient. 1-2s. |
| 01:39:22 | chrisjj | Not a problem... unless that same impatience is the cause of the poor engagement I get on the USB mode of the .rockbox app. The device can bounce on and off Windows like a rubber ball. |
| 02:00 |
| 02:30:31 | | Quit elensil (Ping timeout: 240 seconds) |
| 02:39:04 | *** | Saving seen data "./dancer.seen" |
| 02:45:46 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:50:26 | | Quit uwe_ (Ping timeout: 258 seconds) |
| 02:52:47 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:7c38:ddef:a0bd:d3a7) |
| 02:55:23 | | Join uwe_ [0] (~uwe_@dslb-088-067-191-150.088.067.pools.vodafone-ip.de) |
| 03:00 |
| 03:10:55 | | Quit soap (Read error: Connection reset by peer) |
| 03:20:39 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 03:22:18 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 03:26:25 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 04:00 |
| 04:12:25 | __builtin | hmm, looks like the plugin buffer on the c200v2 is too small to run any puzzles without crashing |
| 04:13:59 | [Saint] | can't you just ask for the playback buffer temporarily? |
| 04:14:09 | __builtin | I'll probably use gevaerts's recommended approach and dynamically grab the playback buffer, so yes |
| 04:22:00 | __builtin | problem is, it's impossible for me to test |
| 04:22:17 | __builtin | I don't think the sim accurately simulates how memory is laid out, or does it? |
| 04:23:18 | * | chrisjj is reassured to hear impossible to test is considered a problem for a RB update :) |
| 04:23:30 | * | chrisjj goes to bed. |
| 04:35:56 | | Join Strife1989 [0] (~quassel@adsl-98-67-60-172.mcn.bellsouth.net) |
| 04:38:50 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 04:39:05 | *** | Saving seen data "./dancer.seen" |
| 04:39:21 | | Quit jhMikeS (Ping timeout: 245 seconds) |
| 04:42:02 | | Quit WakiMiko (Max SendQ exceeded) |
| 04:42:40 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 05:00 |
| 05:46:52 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 05:48:57 | Bilgus | I'm having a hard time deciding if a user altered the buffer in a UDF formatting function with embedded nulls short of walking the damn thing |
| 06:00 |
| 06:16:18 | Bilgus | so what I ended up doing was getting rid of the nulls till after I checked user defined string, ORing the characters in the buffer and then walking the string again ORing the chars again if the user didn't just return a string const from elsewhere |
| 06:16:35 | Bilgus | anyone have a better idea> |
| 06:16:37 | Bilgus | ? |
| 06:29:19 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 06:29:41 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:34:30 | Bilgus | oh I mean XOR and amazingly enough it didn't really slow it down by much |
| 06:39:09 | *** | Saving seen data "./dancer.seen" |
| 06:52:18 | | Join Senji [0] (~Senji@85.187.103.250) |
| 07:00 |
| 07:41:11 | | Quit girafe (Read error: Connection reset by peer) |
| 08:00 |
| 08:24:44 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:39:13 | *** | Saving seen data "./dancer.seen" |
| 08:51:35 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 09:00 |
| 09:23:35 | | Join petur [0] (~petur@78-23-23-252.access.telenet.be) |
| 09:23:35 | | Quit petur (Changing host) |
| 09:23:35 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:52:40 | | Part elensil |
| 09:52:58 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:7c38:ddef:a0bd:d3a7) |
| 10:00 |
| 10:02:32 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:19:34 | | Quit krnlyng (Ping timeout: 252 seconds) |
| 10:25:30 | | Quit pamaury (Ping timeout: 240 seconds) |
| 10:30:45 | | Quit [Saint] (Read error: Connection reset by peer) |
| 10:32:20 | | Quit mc2739 (Ping timeout: 258 seconds) |
| 10:32:33 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 10:32:35 | | Join krnlyng [0] (~liar@77.116.89.4.wireless.dyn.drei.com) |
| 10:36:09 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 10:39:14 | *** | Saving seen data "./dancer.seen" |
| 10:42:58 | | Join fujisan [0] (~fujisan@unaffiliated/fujisan) |
| 10:52:11 | | Join robertd1 [0] (~root@201.242.214.237) |
| 11:00 |
| 11:12:33 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 11:25:21 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 11:32:12 | wodz | pamaury: (log) have you seen https://root.cern.ch/cling ? |
| 11:46:55 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:47:19 | pamaury | wodz: no but it seems very similar to other C/C++ interprets (like cint), why ? |
| 11:49:13 | wodz | pamaury: 1) based on llvm 2) still in active development/support 3) I still miss C prototyping environment in hwstub :-) |
| 11:49:56 | wodz | pamaury: btw. did you try to disasm SpiderApp? |
| 11:50:07 | wodz | pamaury: I know it is huge but still |
| 11:51:13 | pamaury | I remember having a quick look but it's very huge |
| 11:51:25 | | Join xorly [0] (~xorly@wced-93-218-32-147.feld.cvut.cz) |
| 11:51:33 | pamaury | wodz: I see, well we could add cling support to hwstub I guess |
| 11:52:22 | pamaury | If we do so, ideally I'd like to be able to call lua from cling and cling from lua |
| 11:52:36 | pamaury | (or at the very least, lua from cling) |
| 11:53:14 | | Join pamaury_ [0] (~quassel@wks-50-63.mpi-sws.org) |
| 11:55:05 | pamaury | wodz: I'm busy right now but I'll have a look at how cling works and how one interacts with it |
| 11:55:56 | pamaury | ideally I'd like to have hwstub_shell be able to be able to handle lua and cling transparently, so it just works |
| 11:55:56 | wodz | pamaury: I'd be nice to have BUT it is really low priority. |
| 11:56:01 | pamaury | yeah |
| 12:00 |
| 12:01:39 | pamaury | wodz: at least with something based on clang with jit, I am more confident that this interpreter is not going to die so soon |
| 12:03:17 | wodz | pamaury: Being used in CERN is advantage too |
| 12:20:03 | | Join elchapolin [0] (~unknown_@ip68-231-28-2.ph.ph.cox.net) |
| 12:21:02 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3c2a:da40:8fef:17cf) |
| 12:23:12 | | Quit elchapolin (Client Quit) |
| 12:29:20 | | Quit petur (Read error: Connection reset by peer) |
| 12:33:35 | | Quit xorly (Ping timeout: 248 seconds) |
| 12:39:16 | *** | Saving seen data "./dancer.seen" |
| 12:39:29 | | Quit fujisan (Quit: Textual IRC Client: www.textualapp.com) |
| 12:41:11 | chrisjj | ZEN on eBay: http://www.ebay.co.uk/itm/272517736901 |
| 12:47:30 | | Quit JdGordon_ (Quit: Lost terminal) |
| 12:53:22 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 13:00 |
| 13:13:51 | chrisjj | pamaury, I'm installing on a further ZEN for testing, and notice the latest .nk is surprisingly small - 113Kb. Is that as it should be? The previous was 24,621Kb. |
| 13:57:53 | pamaury | chrisjj: it does not contain the OF |
| 13:58:14 | pamaury | because we don't dualboot at the moment, so I figured it doesn't make sense to embed 20MB for nothing |
| 14:00 |
| 14:00:11 | | Quit elensil (Ping timeout: 240 seconds) |
| 14:01:04 | pamaury | chrisjj: did you test 8e82839f_lcdfix ? |
| 14:13:11 | Bilgus | Speaking of lua @pamaury I made a script that chrisjj ran on the zen that seemed to be missing rb.pcm_is_playing() is that function tied to specific hardware? or a specific version? |
| 14:17:41 | pamaury | Bilgus: based on the name I would say no but I no nothing about lua for plugins |
| 14:19:02 | pamaury | is it documented somewhere ? |
| 14:19:51 | | Quit Rower (Ping timeout: 272 seconds) |
| 14:20:53 | pamaury | I guess it tries to export all the functions of the plugin API but maybe some of them were forgotten |
| 14:22:21 | Bilgus | hell IDK is anything regarding lua documented? I pulled it from the source header https://github.com/Rockbox/rockbox/blob/1f8ea9fe27313228e5df67ce6447830b5c30e5e3/apps/plugin.h#L665 |
| 14:23:26 | Bilgus | Weird I mean at least it throws up rather than silently failing |
| 14:25:18 | pamaury | Bilgus: it's quite possible tat some functions were added to plugin.h but no one wrote the glue code to export them to lua |
| 14:25:23 | pamaury | Let me have a look |
| 14:26:10 | Bilgus | they work fine on a bunch of sansas no clue about others besides the zen |
| 14:26:53 | pamaury | are you saying that rb.pcm_is_playing() works on some players but not all |
| 14:26:53 | pamaury | ? |
| 14:27:05 | Bilgus | yes |
| 14:28:31 | Bilgus | failed specifically for chrisjj and his zen replaced it with rb.audio_status() and it worked |
| 14:28:37 | pamaury | Bilgus: afaict, pcm_is_playing is not exported at all by lua |
| 14:29:03 | Bilgus | extra weird then |
| 14:29:43 | pamaury | but I don't see audio_status() either |
| 14:30:26 | Bilgus | I think lua actually just parses the header file and makes its own functions from them |
| 14:31:14 | pamaury | ah, I get it |
| 14:31:18 | Bilgus | some black magik stuff |
| 14:31:24 | pamaury | https://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/plugins/lua/rocklib_aux.pl;h=9103fccbda9c0eb69231f60f05d3612a1aae2d9e;hb=1d7f604 |
| 14:31:34 | pamaury | it does some magic to auto export |
| 14:32:09 | Bilgus | yep thats the file |
| 14:32:49 | pamaury | well maybe the parser is broken, let me try to do a zen build, see how it works and what it generates |
| 14:32:55 | Bilgus | just struck me as odd that the zen didn't have it |
| 14:37:09 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 14:38:24 | pamaury | Bilgus: pcm_is_playing has a wrapper generated apparently |
| 14:38:46 | pamaury | (on the ZEN) |
| 14:39:19 | *** | Saving seen data "./dancer.seen" |
| 14:39:48 | pamaury | Bilgus: maybe you could export the rb table to a file to see if it is indeed exported |
| 14:39:53 | pamaury | there is code for that on https://www.rockbox.org/wiki/PluginLua |
| 14:39:59 | | Quit The_Prospector (Quit: when in doubt, kernel panic) |
| 14:40:55 | Bilgus | Wonder why it failed then chrisjj sent this SS https://imgur.com/EGgZmmJ |
| 14:42:25 | Bilgus | http://forums.rockbox.org/index.php/topic,24605.30.html |
| 14:42:49 | Bilgus | maybe chrisjj was using an old release or something IDK |
| 14:43:13 | pamaury | well you can always try it in a ZEN sim |
| 14:43:18 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 14:44:22 | Bilgus | Worked for me |
| 14:44:52 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 14:45:41 | Bilgus | headed to work thanks |
| 14:49:46 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 14:52:09 | | Part robertd1 |
| 14:59:41 | | Quit shmibs (Quit: leaving =o) |
| 15:00 |
| 15:01:05 | | Join shmibs [0] (~shmibs@shmibbles.me) |
| 15:09:51 | | Quit wodz (Ping timeout: 258 seconds) |
| 15:14:26 | | Quit paulk-blaze (Quit: Leaving) |
| 15:23:44 | | Join robertd1 [0] (~root@201.242.214.237) |
| 15:28:04 | | Quit michaelni (Ping timeout: 240 seconds) |
| 15:32:52 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 15:38:34 | | Quit michaelni (Ping timeout: 252 seconds) |
| 15:39:59 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 15:56:36 | parchd | ouch... any setting in rockbox for resetting volume on startup? Last night I had my player hooked up to speakers - just put my headphones on and had a blast of max-volume drums :( |
| 16:00 |
| 16:03:41 | pamaury | parchd: last volume is restored on boot normally |
| 16:04:13 | pamaury | look in the manual |
| 16:08:02 | | Join Bilgus_ph [0] (~Bilgus_ph@108.101.68.49) |
| 16:08:13 | | Quit Bilgus_ph (Remote host closed the connection) |
| 16:10:43 | | Join Bilgus_ph [0] (~Bilgus_ph@108.101.68.49) |
| 16:12:03 | Bilgus_ph | Parchd yes, google 'rockbox.org custom config file' |
| 16:12:20 | | Quit Bilgus_ph (Remote host closed the connection) |
| 16:12:37 | parchd | Bilgus: will do - thanks |
| 16:13:13 | parchd | pamaury: yeah, that is what I expect as the default so it was my own fault, but it was a nasty shock so I wanted to prevent it happening again |
| 16:15:35 | pixelma | look for fixed.cfg (I think it is called) |
| 16:18:35 | parchd | pixelma: thanks - searching for that gave it me immediately |
| 16:26:46 | | Join xorly [0] (~xorly@wced-142-216-32-147.feld.cvut.cz) |
| 16:30:23 | | Quit Moarc (Ping timeout: 248 seconds) |
| 16:30:55 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 16:36:31 | | Nick Strife1989 is now known as Strife89 (~quassel@adsl-98-67-60-172.mcn.bellsouth.net) |
| 16:39:23 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:20:27 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 17:30:20 | __builtin | dammit these PMs on the forum are annoying as heck |
| 17:41:10 | | Quit pamaury_ (Remote host closed the connection) |
| 17:44:02 | | Part __builtin ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
| 17:48:33 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 17:54:25 | | Quit pamaury (Ping timeout: 256 seconds) |
| 18:00 |
| 18:05:50 | | Quit xorly (Ping timeout: 240 seconds) |
| 18:32:33 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 18:37:46 | | Quit robertd1 (Quit: Leaving.) |
| 18:39:26 | *** | Saving seen data "./dancer.seen" |
| 18:49:33 | | Join johnb2 [0] (~johnb2@p5B296EE3.dip0.t-ipconnect.de) |
| 18:56:34 | | Quit parchd (Ping timeout: 240 seconds) |
| 19:00 |
| 19:14:50 | __builtin | ooh, good news |
| 19:15:00 | __builtin | my antialiased line draw is now 51% efficient :D |
| 19:15:14 | __builtin | (in comparison to rb's lcd_drawline()) |
| 19:16:24 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 19:18:21 | __builtin | oh crap, no |
| 19:18:24 | __builtin | that was a fluke :( |
| 19:19:31 | pamaury | chrisjj: I have a test build with code for the LED, could you test it on the ZEN ? (I don't have a ZEN anymore, and the ZEN has a different LED setup then ZEN X-Fi) |
| 19:20:47 | __builtin | still at 32% |
| 19:30:23 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 19:54:49 | | Quit parchd (Quit: real life) |
| 19:59:10 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 20:00 |
| 20:16:00 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 20:33:37 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 20:33:45 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 20:39:29 | *** | Saving seen data "./dancer.seen" |
| 20:55:41 | | Join Finfi [0] (5f29cd2f@gateway/web/freenode/ip.95.41.205.47) |
| 20:55:50 | Finfi | Hi |
| 20:56:13 | Finfi | ...So I've cross-wired pins on my Clip+ and plugged it while in Ubuntu |
| 20:56:39 | Finfi | And this is what sudo fdisk -l gives me: |
| 20:56:55 | Finfi | Disk /dev/sdc: 30,6 MiB, 32096256 bytes, 62688 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes |
| 20:57:09 | Finfi | Is flash drive in this Clip+ dead? |
| 20:58:15 | chrisjj | pamaury, re your 'did you test 8e82839f_lcdfix' - not since we last IRCs last night. I picked be68b6a7b. |
| 20:59:58 | pamaury | chrisjj: and ? |
| 21:00 |
| 21:00:07 | chrisjj | I retested Verions be68b6a7b using clean install (no added/retained files except audio) and clean boot (power-on). |
| 21:00:59 | chrisjj | On Unit Q (the unit that showed fail on this version before, in possibly ROLO or Reset boot), success on two runs (>=6hrs). |
| 21:01:42 | chrisjj | Test had power source = battery. |
| 21:02:59 | chrisjj | Would you like the next test to be 8e82839f_lcdfix? Or the new build with LED blink on panic? |
| 21:05:06 | pamaury | ok so may the fails you saw were false alarm. Could you run https://www.dropbox.com/s/pr1v9cptcps509j/rockbox_led.zip?dl=0 ? |
| 21:05:23 | pamaury | it doesn't blink on panic, at the moment it just gives an extra entry in the debug menu to play with the LED |
| 21:05:31 | pamaury | In System > Debug > Show HW Info > led |
| 21:06:33 | pamaury | the code highligh the led color channel (in your case, only one: blue), press enter to start editing, then press up/down (or left/right can't remember) to dim it. |
| 21:08:58 | chrisjj | I think the many fails I saw were a true alarm. They weren't 100% then, so no big surprise they aren't 100% now. I'd bet they depend on a variable ingredient. My list of candidates includes: Boot type (power-on/reset/ROLO); user settings e.g. theme; power source (battery/external). When I'm sure we've got a stable recipe, i'll retest to find the culprit. |
| 21:11:24 | Finfi | test |
| 21:11:32 | Finfi | Am I even readable? |
| 21:12:33 | | Quit Moarc (Ping timeout: 240 seconds) |
| 21:13:53 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 21:15:08 | pamaury | Finfi: yes |
| 21:15:22 | pamaury | Finfi: wait until someone knowledgeable answers you |
| 21:17:32 | Finfi | ok |
| 21:20:27 | | Quit Moarc (Ping timeout: 255 seconds) |
| 21:20:52 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 21:24:36 | chrisjj | pamaury: that rockbox_led.zip is 3cda546d5-170111 and succeeds in an unclean install with clean boot on my ZEN Unit P. |
| 21:25:31 | chrisjj | By succeeds I mean e.g. System > Debug > View HW Info > led , press Select, press Down -> LED lights. |
| 21:26:08 | Finfi | There's another thing: the output of sudo fdisk -l doesn't change no matter if pins are cross-wired or not |
| 21:31:48 | chrisjj | pamaury, The UI's step values are unstable. The scale has the poor brightness linearity that we'd expect from uncorrected pulse width. The menu offers (in addition to 'blue', where Up/Down alter %age and brightness) 'unknown' on which Up/Down alter a displayed frequency temporarily |
| 21:32:19 | chrisjj | Looks to me ample for PANIC (and other) debugging! |
| 21:32:55 | pamaury | chrisjj: the unknown is a bug, I'll fix. Yeah it's not very linear but for LEDs, I'm not going to calibrate it |
| 21:33:22 | chrisjj | You planning to use intermediate brightness for something? |
| 21:34:52 | pamaury | Probably not but since they are on the PWM channel, you get for free |
| 21:35:18 | pamaury | the debug UI only changes the duty cycle, not the frequency, it's just a test, the code can affect both |
| 21:35:20 | | Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) |
| 21:36:15 | chrisjj | OK. If you change your mind, sqrt(). |
| 21:37:06 | * | __builtin gives chrisjj a friendly reminder that PANIC has no meaning |
| 21:37:23 | pamaury | well it's doesn't make sense to do it in the interface, the API exposes frequency and duty cycle. The duty cycle does not necessarily corresponds to brightness |
| 21:38:25 | * | pamaury is trying to think if any other imx233 target has LEDs |
| 21:38:40 | chrisjj | The duty cycle definitely does not correspond to brightness. Hence my suggestion of sqrt(). However yes, that can be left to the app rather than RB. |
| 21:39:26 | | Quit Finfi (Quit: Page closed) |
| 21:39:51 | pamaury | I mean, if you set freq=1Hz and the duty cycle controls the blinking frequency, thus sqrt() makes no sense |
| 21:39:52 | chrisjj | Did the ZEN I sent die? |
| 21:40:13 | pamaury | chrisjj: it got stolen with my bag last year, along with other players |
| 21:40:23 | chrisjj | Aw, bummer. |
| 21:40:44 | chrisjj | You should have said. I can't replace the others, but I'll send you a ZEN. |
| 21:40:45 | pamaury | I still have the ZEN Mozaic, V, V Plus, MX, X-Fi, X-Fi2, X-Fi3 |
| 21:41:14 | chrisjj | Shame they didn't steal the crappy ones instead :-) |
| 21:41:43 | pamaury | Well that's was quite random, to be honest losing my computer was more annoying |
| 21:41:56 | chrisjj | Sounds like you need a ZEN and a ZEN X-Fi Style. |
| 21:42:14 | pamaury | I have a ZEN X-Fi Style but the battery is dead :-( |
| 21:42:28 | chrisjj | Any others missing from your set? |
| 21:43:05 | pamaury | Not that I can think of. I also have the Touch 2 but not a good device. And I'm not interested in the pre-ZEN generation |
| 21:43:29 | pamaury | I also have the Style M300 |
| 21:44:02 | TorC | chrisjj: pamaury: Was it just one ZEN that is having trouble? If so, have you verified that sleep timer isn't set to turn on on boot set for a couple hours? |
| 21:44:32 | pamaury | chrisjj: please wait a moment, I will dig into my player box to make sure which players I have exactly |
| 21:44:34 | chrisjj | Is your ZEN X-Fi Style on external power good enough for development? Or shall I send you a replacement? |
| 21:44:40 | chrisjj | OK, I'll wait. |
| 21:45:33 | pamaury | chrisjj: if you have a spare X-Fi Style that would be cool. The port should be functional but there are features I cannot test without the battery |
| 21:45:41 | | Join MaxLeiter [0] (~MaxLeiter@unaffiliated/maxleiter) |
| 21:45:45 | | Part MaxLeiter |
| 21:46:13 | chrisjj | OK, it's yours. Re ZEN, what colour do you want? :-) |
| 21:47:17 | pamaury | are there non-blak ZEN ? |
| 21:47:23 | * | pamaury didn't know |
| 21:47:24 | | Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) |
| 21:47:42 | pamaury | Ok just checked, the only I miss are the ZEN and ZEN X-Fi Style |
| 21:47:54 | pamaury | chrisjj: any color is find, I don't really care |
| 21:48:05 | TheLemonMan | the Zen V came also in white |
| 21:48:24 | chrisjj | OK, black. |
| 21:49:08 | | Join Finfi [0] (5f29cd2f@gateway/web/freenode/ip.95.41.205.47) |
| 21:49:12 | Finfi | I'm back |
| 21:49:17 | Finfi | did somebody answer my question? |
| 21:49:27 | Finfi | My case is similar to this: http://forums.rockbox.org/index.php?topic=34186.0 |
| 21:49:59 | * | chrisjj hides pink ZEN from girlfriend. |
| 21:50:06 | TorC | Finfi: You can read the logs for that (see topic), but I had just read the scrollback, and it wasn't answered yet. |
| 21:50:11 | pamaury | Finfi: iirc, if you see a 30MB I think the flash is dead |
| 21:51:01 | Finfi | What is surprising me tho is that it doesn't matter if pins are short-wired or not |
| 21:51:26 | TorC | That's what I recall too. You might want to replace it. There's a build of bootloader that will load RB from uSD if int flash is dead, but IIUC you have to install it before the player dies. |
| 21:52:01 | TorC | Finfi: The thread with links is http://forums.rockbox.org/index.php/topic,51304.msg237134.html#msg237134 |
| 21:52:10 | | Join johnb2 [0] (~johnb2@p5B296EE3.dip0.t-ipconnect.de) |
| 21:53:07 | TorC | *by replace it, I mean the player. dongs was working on replacing the flash nand, but I haven't seen that he succeeded. |
| 21:53:35 | johnb2 | Finfi: I had a similar clip+ recently, i.e. showing the same behaviour. I was able to dd the bin file, but that did not change it. |
| 21:54:27 | johnb2 | I gave up on it. |
| 21:55:46 | chrisjj | pamaury, re sending replacement ZENs, you have mail. |
| 21:56:05 | chrisjj | Meanwhile, which build do you want me to test? I could return to be68b6a7b+memDFS which will hopefully now give us the battery benchmark. |
| 21:56:13 | pamaury | chrisjj: thanks, answered |
| 21:56:26 | | Quit johnb2 (Client Quit) |
| 21:56:39 | pamaury | chrisjj: yeah, we still need to compare memdfs vs no memdfs |
| 21:56:44 | Finfi | Well, thank you all |
| 21:56:46 | pamaury | which logs do you have so far ? |
| 21:57:08 | Finfi | Sadly I don't see any way to bring my Clip+ to life |
| 21:59:00 | chrisjj | pamaury, none complete, and none I would now trust anyway! :) I'll rerun, with clean install & boot. |
| 22:00 |
| 22:00:02 | TorC | Finfi: Not easily, if at all, most likely. It was right around 0000 1/1/1 UTC-8 that the IRC logs would be found if you want to look up on replacing the nand. Some work a little later. Nothing conclusive has showed up on IRC that I've seen. |
| 22:00:03 | pamaury | ok, so in this case, re-run be68b6a7b+memDFS and be68b6a7b |
| 22:00:14 | chrisjj | OK, will do. |
| 22:00:22 | | Quit michaelni (Read error: Connection reset by peer) |
| 22:00:23 | | Quit Finfi (Quit: Page closed) |
| 22:00:44 | chrisjj | TorC: no, it was both ZENs I tried. |
| 22:00:44 | pamaury | I also uploadded one here: https://www.dropbox.com/s/xoum1e0s9z08i40/rockbox_zen_be68b6a7b.zip?dl=0 |
| 22:00:52 | pamaury | Did I upload be68b6a7b+memDFS ? |
| 22:02:35 | chrisjj | I already received be68b6a7b and be68b6a7b+memDFS from you. |
| 22:03:13 | * | pamaury doesn't remember uploading be68b6a7b+memDFS and can't find it on his dropbox |
| 22:03:16 | chrisjj | Your [21:00] be68b6a7b is binary identical to the previous send. |
| 22:04:13 | chrisjj | "rockbox_zen_with_memdfs.zip" |
| 22:04:58 | chrisjj | Recd. here 08 January 2017, 12:52:39 |
| 22:05:27 | pamaury | I must have erased it, but if you have it that's fine |
| 22:07:01 | chrisjj | So we're together: https://www.dropbox.com/s/7omtb6df0e96be1/rockbox_zen_with_memdfs.zip?dl=0 |
| 22:12:21 | pamaury | lebellium: here ? |
| 22:16:51 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 22:17:29 | lebellium | pamaury: yep |
| 22:19:08 | pamaury | lebellium: wanna try rockbox on the A15 ? |
| 22:21:30 | lebellium | yes, good thing to do while eating and drinking a beer :P |
| 22:24:39 | pamaury | lebellium: ok so get g#1481 (I updadted it since last time) |
| 22:24:40 | fs-bluebot | Gerrit review #1481 at http://gerrit.rockbox.org/r/1481 : Initial commit for the Sony NWZ linux port and NWZ-E460 (WIP) by Amaury Pouly |
| 22:28:13 | lebellium | then do the same thing as 2 days ago? |
| 22:28:36 | pamaury | yes |
| 22:28:43 | pamaury | except you select NWZ-A10 in configure |
| 22:28:58 | pamaury | I couldn't test it obviously (it compiles though) so I could have made a mistake |
| 22:29:54 | lebellium | note that YP-R0 and YP-R1 are considered as Application but Linux NWZ as Sony :D |
| 22:32:23 | pamaury | is it ? |
| 22:32:46 | lebellium | Isn't it a RaaA port? |
| 22:32:53 | pamaury | yes it's a RaaA port |
| 22:33:06 | pamaury | although RaaA is kind of vague |
| 22:33:16 | pamaury | it basically means "there is an OS" |
| 22:35:38 | lebellium | ah |
| 22:35:48 | lebellium | I guess I muse have forgot to update something |
| 22:35:51 | lebellium | must* |
| 22:36:01 | lebellium | ubuntu@ubuntu-VirtualBox:~/rockbox/A10/bootloader110117$ ../../rbutil/mknwzboot/mknwzboot -b bootloader-nwza10.sony -o NW_WM_FW.UPG |
| 22:36:02 | lebellium | [ERR] This player is not supported: a10 |
| 22:36:04 | lebellium | [ERR] Invalid boot file |
| 22:36:06 | lebellium | Result: 2 |
| 22:36:19 | | Join chrisb [0] (~chrisb@pool-71-175-247-128.phlapa.east.verizon.net) |
| 22:38:12 | pamaury | lebellium: ah shit, I forgot mknwzboot |
| 22:38:17 | pamaury | I knew I had forgotten something |
| 22:38:45 | pamaury | sorry, swearing is bad |
| 22:39:16 | lebellium | no problem; it still will be much faster than 2 days ago if we only have one issue tonight :D |
| 22:39:30 | *** | Saving seen data "./dancer.seen" |
| 22:40:20 | pamaury | lebellium: gerrit updated |
| 22:43:14 | lebellium | wow |
| 22:43:16 | lebellium | already done |
| 22:43:37 | pamaury | Well you kinda of encountered all the problems last time, now it's much better |
| 22:49:43 | lebellium | pamaury: on device when upgrading: "mount fail" |
| 22:50:49 | pamaury | ah yeah I forgot about that, I think the A10 is using ext4, please wait 5 min |
| 22:53:21 | pamaury | ah yes |
| 22:57:15 | lebellium | I'm building rockbox meanwhile |
| 22:59:36 | pamaury | ok |
| 22:59:45 | pamaury | I have a patch, I'm trying it on my E460 first |
| 22:59:59 | lebellium | If there is any French here interested in NWZ and Rockbox, the E580 is on flash sale https://www.amazon.fr/Sony-NWZ-E585B-Lecteur-MP3-16Go/dp/B00E3PUD1E/ref=sr_1_3?ie=UTF8&qid=1484171942&sr=8-3&keywords=sony+nwz |
| 23:00 |
| 23:00:12 | lebellium | €100 |
| 23:01:27 | pamaury | that's expensive |
| 23:01:32 | pamaury | lebellium: I updated gerrut |
| 23:01:35 | pamaury | *gerrit |
| 23:01:42 | pamaury | you will need to recompile mknwzboot: |
| 23:01:50 | pamaury | make -C rbutils/mknwzboot |
| 23:02:02 | lebellium | pamaury: your price is definitely not the right one. You stole it :P |
| 23:02:09 | lebellium | almost |
| 23:02:29 | pamaury | haha |
| 23:03:02 | pamaury | still 100€ for that is expensive |
| 23:03:18 | * | pamaury wouldn't spend more than 10 ;) |
| 23:08:51 | pamaury | lebellium: is it working now ? |
| 23:09:09 | lebellium | I'm not flash_pamaury! |
| 23:10:05 | * | pamaury works on more bootloader features in the mean time |
| 23:10:20 | lebellium | if you saw me using Ubuntu, you would probably laugh |
| 23:12:27 | pamaury | So let's agree on the bootloader, my plan is: |
| 23:12:28 | pamaury | First boot: show the menu |
| 23:12:28 | pamaury | Subsequent boots: don't show the menu (unless swtch is on) and proceed with the previously chosen option |
| 23:12:28 | DBUG | Enqueued KICK pamaury |
| 23:12:28 | pamaury | When the bootloader is invoked and switch is initially on, power off after X seconds if there are no actions / not switch unhold (which one is better ?) |
| 23:12:28 | pamaury | If switch is off and there is not activity for Y seconds: power off/boot (boot is probably better) |
| 23:14:08 | TorC | I'm not sure what you mean by "not switch unhold", but otherwise I think your plan makes sense. |
| 23:14:41 | TorC | I'd go for boot on timeout and figure that [OF|RB] will handle power off on timeout if needed. |
| 23:15:01 | pamaury | TorC: ah yeah, sorry, the device can detect key stroke even when hold is on. Which means that there is the option to consider a key stroke when hold is on as "activity" |
| 23:15:21 | TorC | Since it is reasonable to figure on accidental boot menu show request. |
| 23:15:34 | TorC | Ah. I don't have the device to know that. |
| 23:15:48 | lebellium | pamaury: bootloader working, keys working, debug menu working, spiderapp working, rockbox can't load and crash even after a reset |
| 23:16:04 | pamaury | So you would boot on timeout always (ie never power off) and let the OF/RB handle it ? |
| 23:16:23 | TorC | But do leave a longish timeout on boot menu, because the assumption is it is wanted. |
| 23:16:34 | pamaury | lebellium: by crash you mean ? |
| 23:17:38 | lebellium | pamaury: well I should rather say "stuck on the rockbox selection logo". The E580 crashed (rebooted) at first until I solved it somehow but this one doesn't reboot, it just gets stuck |
| 23:17:50 | pamaury | TorC: ok so what should be the values of X and Y ? For Y (switch on) it should be small (like 5/10 seconds). For X, not sure |
| 23:17:52 | TorC | Well, it appears the boot menu will only show on request, so there was an intention to turn the device on, IIUC. Unless it's a rattling-around-in-backpack boot, in which case all bets are off. |
| 23:18:08 | pamaury | lebellium: that sounds like a crash indeed |
| 23:18:22 | pamaury | lebellium: can you look at the root of your device, there should be a file called rockbox.txt |
| 23:18:40 | pamaury | rockbox.log |
| 23:18:48 | pamaury | does it contain any useful info ? |
| 23:19:39 | pamaury | TorC: yeah good point |
| 23:19:54 | TorC | If hold switch on (and could be forgotten) will call boot menu, probably 5-10s is good. For other button pushed to more deliberately call bootloader, 30s or so. |
| 23:20:14 | lebellium | pamaury: not sure http://pastebin.com/daM63KE3 |
| 23:20:15 | pamaury | sounds good |
| 23:20:52 | TorC | Of course, hold switch might be used to avoid backpack boot, in which case lock, and power off if hold not released within 5-10s. |
| 23:21:06 | TorC | Assuming you can do that. |
| 23:21:08 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 23:21:40 | pamaury | yeah |
| 23:23:47 | pamaury | lebellium: it's going to be tricky |
| 23:24:14 | lebellium | pamaury: I get more or less the same problem as the E580. I deleted .rockbox but it won't. Some files want to say |
| 23:24:26 | lebellium | stay* |
| 23:24:29 | pamaury | some files want to stay ? |
| 23:25:15 | pamaury | I still don't explain why it happened on the E580 though, that's weird |
| 23:25:17 | lebellium | yes, when I delete rockbox.sony it just comes back (funny) and I have "font" directory with 4 fonts left |
| 23:25:29 | pamaury | hum |
| 23:26:03 | lebellium | I finally managed to deleted it on E580 but I must find how I did it :D |
| 23:26:03 | pamaury | lebellium: try to reset the player, then go straight to usb mode |
| 23:28:27 | | Quit girafe (Read error: Connection reset by peer) |
| 23:28:58 | lebellium | didn't help. Windows just can't delete the files. Linux did it but with this stupid MacOS-like Trash directory. I hate that. Now the device says "cannot boot rockbox", which is expected. I try to copy .rockbox again |
| 23:31:48 | lebellium | now booting |
| 23:31:58 | lebellium | exactly like with the E580 |
| 23:32:19 | pamaury | that sounds like your OS is doing crap |
| 23:32:24 | pamaury | somehow |
| 23:32:28 | pamaury | lebellium: so it's working ? |
| 23:32:44 | lebellium | maybe it's a problem with the VM when mounting and unmounting USB devices |
| 23:32:50 | lebellium | working, great :) |
| 23:33:07 | pamaury | possibly |
| 23:34:11 | lebellium | same battery indicator not stable |
| 23:34:28 | lebellium | it's moving like in charge status |
| 23:35:25 | lebellium | and just powered off because of (untrue) empty battery |
| 23:35:49 | pamaury | hum |
| 23:36:08 | lebellium | playback not crashing but no sound |
| 23:36:46 | pamaury | it's strange, I don't have this funny battery reading problem |
| 23:37:18 | lebellium | I don't know yet if it does it only after fresh install or at each reboot |
| 23:37:27 | lebellium | but it needs some time to stabilize |
| 23:38:06 | lebellium | it said 25%; 1 second later 9% now 12% |
| 23:38:13 | lebellium | now 27% |
| 23:40:48 | lebellium | as on E580 at first I got no sound and somehow now I get sound (crappy, max output) |
| 23:41:15 | pamaury | lebellium: can you go to System > Debug > HW info > power |
| 23:41:44 | pamaury | and tell me how "avg voltage" and "raw voltage" are changing |
| 23:44:15 | lebellium | raw voltage is changing every millisecond or such, I don't even have time to read |
| 23:44:31 | lebellium | avg voltage was stable |
| 23:44:47 | lebellium | and now I got kicked off, powered off |
| 23:46:06 | pamaury | lebellium: is raw voltage changing a lot (like hugely different values) ? |
| 23:46:43 | lebellium | looks like it was switching always between 2 or 3 values (4060mV and down to 3xxxmV) |
| 23:47:09 | lebellium | oh OK |
| 23:47:13 | lebellium | I figured it out |
| 23:47:23 | lebellium | it depends if you're playing a file or not |
| 23:48:08 | pamaury | lebellium: really ?? weird |
| 23:48:11 | lebellium | with no playback it seems stbale |
| 23:48:13 | lebellium | stable* |
| 23:48:23 | pamaury | lebellium: I have updated gerrit |
| 23:48:31 | | Quit xorly (Ping timeout: 240 seconds) |
| 23:48:36 | pamaury | can you updated and recompile rockbox (not bootloader) and see if it's better |
| 23:49:01 | lebellium | ok, then I go to bed |
| 23:49:40 | | Quit skapazzo (Quit: leaving) |
| 23:49:59 | pamaury | ah I think I get it |
| 23:50:36 | pamaury | sometimes the kernel might return -1 because it cannot read the voltage (it needs to send a message to the PMU). And thus the battery reads 4V, 4V, -1V, 4V, etc |
| 23:54:38 | lebellium | Actually it doesn't seems to be related to playback. With no playback it switching between 4042 and 4060mV raw voltage every millisecond now |
| 23:54:49 | pamaury | small variations are normal |
| 23:54:55 | pamaury | huge one not really |
| 23:55:05 | pamaury | but try the new one, it should be much better |
| 23:55:13 | lebellium | just compiled |
| 23:55:14 | lebellium | trying now |
icon identifies that the person is a core developer (has commit access).