| 00:00:43 | | Quit petur (Quit: Leaving) |
| 00:14:04 | | Quit Bilgus_ (Ping timeout: 240 seconds) |
| 00:14:48 | | Join MrZeus1 [0] (~MrZeus@5ec21d62.skybroadband.com) |
| 00:16:14 | | Quit MrZeus (Ping timeout: 255 seconds) |
| 00:32:05 | | Quit ZincAlloy (Quit: Leaving.) |
| 00:46:10 | | Quit girafe (Quit: Leaving) |
| 00:46:48 | | Quit mutnai (Ping timeout: 260 seconds) |
| 00:47:05 | *** | Saving seen data "./dancer.seen" |
| 00:55:43 | | Quit shdwprince (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 01:00 |
| 01:03:09 | | Quit ender` (Quit: If someone's political stance requires preventing scientists from informing you about your own planet, that's not politics, it's oppression. — Katie Mack) |
| 01:04:47 | pamaury | damn, the Qt folks have some interested twist |
| 01:05:36 | pamaury | they came up with qstyleoptionviewitem, then qstyleoptionviewitemv2, v3, v4, each one inheriting the previous, which means you need v4 to get all the fields |
| 01:05:56 | pamaury | then in 5.7, the decide that qstyleoptionviewitem should have all the fields from v4 and stop this version mess |
| 01:06:00 | pamaury | and deprecate qstyleoptionviewitemv4 |
| 01:06:30 | pamaury | which means the only reliable way of using styled delegate is to use qstyleoptionviewitemv4 if you want to work on Qt4 and 5, but it's also deprecated |
| 01:06:42 | pamaury | that's stupid |
| 01:06:47 | | Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu) |
| 01:12:00 | | Quit alexweissman (Ping timeout: 276 seconds) |
| 01:20:58 | | Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 01:51:05 | | Quit Senji_ (Ping timeout: 256 seconds) |
| 01:53:37 | | Quit pamaury (Ping timeout: 260 seconds) |
| 01:56:21 | chrisjj | pamaury, Thanks. Which difference http://i.imgur.com/nGqKGVg.png is the RAM size? |
| 02:00 |
| 02:01:00 | dunx | qstyleoptionviewitem is quite a mouthful |
| 02:03:02 | [Saint] | do u evn qstyleoption, bruh? |
| 02:03:30 | | Quit xorly (Ping timeout: 252 seconds) |
| 02:05:09 | | Quit __builtin (Ping timeout: 252 seconds) |
| 02:06:30 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 02:34:03 | chrisjj | __builtin, good guess. Number of Creative players owned is 38. |
| 02:38:34 | [Saint] | We had two running theories. |
| 02:39:20 | [Saint] | That you either cycled back around from A~Z to A*, or that you named them after arbitrary objects. Like Nuts, or Cheese, or Air Conditioner. |
| 02:42:14 | | Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) |
| 02:45:01 | | Quit JdGordon (Ping timeout: 240 seconds) |
| 02:47:07 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:00:46 | __builtin | chrisjj: it was far from a guess ;) |
| 03:03:00 | [Saint] | Phases of the moon and a fair dice roll was also something I considered. |
| 03:03:22 | [Saint] | Or plucks from a bag of Scrabble tiles. |
| 03:05:29 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 03:25:52 | | Part robertd1 |
| 03:27:14 | | Quit WakiMiko (Max SendQ exceeded) |
| 03:27:52 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 04:00 |
| 04:06:12 | | Quit MrZeus1 (Ping timeout: 255 seconds) |
| 04:15:06 | | Quit bluebrother (Disconnected by services) |
| 04:15:11 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 04:17:43 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 04:31:17 | | Join fs-bluebot [0] (~fs-bluebo@xd9baf127.dyn.telefonica.de) |
| 04:47:08 | *** | Saving seen data "./dancer.seen" |
| 04:57:32 | | Quit naleo (Ping timeout: 256 seconds) |
| 05:00 |
| 05:02:54 | | Quit Bilgus (Ping timeout: 240 seconds) |
| 05:03:12 | | Quit [Saint] (Remote host closed the connection) |
| 05:04:50 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 05:09:33 | fs-bluebot | Build Server message: New build round started. Revision 58b849c, 255 builds, 15 clients. |
| 05:17:58 | | Join chrisb [0] (~chrisb@pool-71-175-249-93.phlapa.east.verizon.net) |
| 05:21:38 | fs-bluebot | Build Server message: Build round completed after 725 seconds. |
| 05:21:39 | fs-bluebot | Build Server message: Revision 58b849c result: All green |
| 05:22:13 | dys | pamaury: I have the SPI testpoints figured out, but not yet found an accessible reset pin to tristate the blackfin SPI port |
| 05:22:44 | dys | pamaury: Did you happen to spot a reset controller or a supervisor IC by chance? |
| 05:23:23 | | Join naleo [0] (~naleo@unaffiliated/naleo) |
| 05:30:12 | dys | (closing the reset pinhole button powers the unit off… not very helpful) |
| 05:37:25 | | Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 05:53:04 | Bilgus | [Saint], anyone else interested G#1541 is up |
| 05:53:05 | fs-bluebot | Gerrit review #1541 at http://gerrit.rockbox.org/r/1541 : Advanced Auto-Ranging Time Formatting For Menus (hh:mm:ss:mss) by William Wilgus |
| 06:00 |
| 06:11:29 | | Quit TheSeven (Ping timeout: 245 seconds) |
| 06:12:06 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:34:41 | | Quit amazoniantoad (Ping timeout: 255 seconds) |
| 06:43:39 | | Quit advcomp2019_ (Ping timeout: 240 seconds) |
| 06:47:11 | *** | Saving seen data "./dancer.seen" |
| 06:49:24 | | Join amazoniantoad [0] (~golden@2603:3018:600:a000:fc94:8938:f194:b983) |
| 07:00 |
| 07:05:44 | | Quit amazoniantoad (Ping timeout: 255 seconds) |
| 07:18:06 | | Join amazoniantoad [0] (~golden@2603:3018:600:a000:fc94:8938:f194:b983) |
| 07:27:41 | | Quit naleo (Quit: Leaving) |
| 07:37:04 | | Quit chrisb (Ping timeout: 240 seconds) |
| 07:51:09 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 07:56:44 | | Quit [Saint] (Quit: Going down for scheduled maintenance) |
| 08:00 |
| 08:03:22 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 08:07:33 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 08:23:14 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:33:03 | | Quit [Saint] (Read error: Connection reset by peer) |
| 08:34:29 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 08:35:17 | | Quit furrywolf (Ping timeout: 255 seconds) |
| 08:43:51 | | Quit [Saint] (Quit: Quit) |
| 08:44:30 | | Join athidhep [0] (~afoakf@unaffiliated/athidhep) |
| 08:45:49 | | Quit pixelma (Quit: .) |
| 08:45:49 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 08:46:00 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
| 08:46:00 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
| 08:46:44 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 08:47:12 | *** | Saving seen data "./dancer.seen" |
| 08:51:25 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:56:28 | | Quit [Saint] (Read error: Connection reset by peer) |
| 08:58:47 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 09:00 |
| 09:00:17 | | Quit [Saint] (Client Quit) |
| 09:01:17 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 09:14:09 | | Quit The_Prospector (Read error: Connection reset by peer) |
| 09:14:35 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 09:53:22 | | Quit elensil (Ping timeout: 240 seconds) |
| 10:00 |
| 10:09:13 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:887c:5774:10b:f748) |
| 10:28:48 | | Quit petur (Remote host closed the connection) |
| 10:47:16 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:07:30 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 11:22:08 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:59:09 | pamaury | Bilgus: do you think you could have a look at https://www.rockbox.org/tracker/task/10363#comment43861 ? |
| 11:59:29 | pamaury | it's a bug with chessbox and you have worked a lot on plugins now ;) |
| 12:00 |
| 12:06:38 | pamaury | chrisjj: re difference: the RAM size is not written anywhere. It involves putting 4 fields together in an equation. |
| 12:06:38 | pamaury | In this case, register HW_DRAM_CTL11 (0x800E002C) has a field COLUMN_SIZE (10:8) which is 2 in one and 3 in the other. |
| 12:23:44 | | Join shdwprince [0] (~textual@130.180.218.8) |
| 12:25:01 | dys | pamaury: Pulling the unidentified testpoints low via 1kΩ also didn't result in a reset :-/ |
| 12:25:18 | dys | all that's missing from reading the spi flash is telling the blackfin to let go of the lines |
| 12:25:22 | | Part shdwprince |
| 12:37:29 | pamaury | dys: can you sniff the wires when the SoC is starting ? |
| 12:37:53 | pamaury | ie reset the whole thing, the soc starts reading, just capture all the transfers on the wire and with a bit of decoding you have the content of the flash |
| 12:38:39 | pamaury | I had this problem once and that the only solution I came up with when even pulling the pins doesn't work. |
| 12:39:13 | dys | I did watch the action on my scope on startup. No ready-to-use logic analyzer. I could use a fpga board to do the capturing, though that is a bit of an effort… |
| 12:40:17 | dys | i might try forcing the pins. the blackfin lines go through series-termination resistors. maybe they are large enough to foce the lines without doing damage |
| 12:40:24 | pamaury | ah that's a shame. If the speed of that thing is not too high, maybe a micro-controller could capture the traffic ? (assuming you have some place where to store the data) |
| 12:41:08 | dys | it seems to load the 32 Mbit in about two seconds, so probably to fast for a µC |
| 12:47:19 | *** | Saving seen data "./dancer.seen" |
| 12:47:27 | pamaury | yeah unless you have a 100Mhz+ uc it doesn't look easy to sniff it |
| 12:47:32 | pamaury | or fpga |
| 12:48:14 | dys | also, if the blackfin switches the spi to multi-pin data out it adds another problem |
| 12:48:14 | pamaury | if your fpga has enough ram though, it could be "just" a matter of recronstructing the image in RAM and then download it to your PC. |
| 12:48:29 | pamaury | multi-pin data ? what is that ? |
| 12:49:07 | dys | the spi used supports parallel output on four lines IO1…IO4 in the pinout |
| 12:49:41 | dys | the chips on x86 mainboard are routinely used in this mode |
| 12:49:44 | dys | it's a pita to sniff, i can tell |
| 12:51:01 | dys | lunch break over, need to cycle to work now… afk for another 6 hours |
| 12:51:26 | pamaury | ah, I though spi was one wire of data onl |
| 13:00 |
| 13:00:17 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 13:06:09 | chrisjj | pamaury, Thanks. I see that HW_DRAM_CTL11 is read-write. Is this value that's found differing being written by software? |
| 13:14:51 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:464:820c:5fb:4ae2) |
| 13:20:22 | pamaury | yes it is written by the RAM init code that runs really early at boot |
| 13:21:29 | pamaury | but RAM isn't likely to explain the problem, the device has more RAM than expected, that simply means Rockbox uses only half of the RAM available |
| 13:26:29 | chrisjj | Is it theoretically possible to run code inside Rockbox that can detect the amount of RAM available? |
| 13:28:04 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 13:28:14 | wodz | chrisjj: sure, we do that on ipodvideo |
| 13:28:39 | pamaury | wodz: doesn't rockbox assume compile timed defined RAM amount ? |
| 13:28:44 | pamaury | *compile time |
| 13:29:20 | wodz | pamaury: ask gevaerts about details but a few years ago 32 and 64MB build of ipodvideo were merged into one |
| 13:29:58 | pamaury | ah, I remember we indeed had two builds. I will look at the code |
| 13:30:06 | pamaury | although 32MB is already plenty |
| 13:30:39 | wodz | I wouldn't worry about 32MB considering that devices freeze randomly :-) |
| 13:32:08 | chrisjj | Plenty means only that there's no /good/ reason for Rockbox to detect the amount of available RAM :) |
| 13:32:14 | chrisjj | wodz: What devices freeze randomly? |
| 13:32:24 | wodz | chrisjj: yours? |
| 13:32:27 | chrisjj | No. |
| 13:33:06 | chrisjj | On the current build, they often BSoPO after about 22h. |
| 13:33:33 | pamaury | even with voltage fix ? |
| 13:33:33 | pamaury | I think he was referring to your unit N |
| 13:33:46 | | Quit Moarc (Ping timeout: 252 seconds) |
| 13:34:15 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 13:34:40 | wodz | chrisjj: Whatever, your units tend to have some problems and using just half of ram is the smallest |
| 13:34:55 | chrisjj | Yes. On the current build (8fec364f6-170125 voltage fix g1533), they often BSoPO after about 22h. |
| 13:34:56 | fs-bluebot | Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : zen/zenxfi: adjust maximum emi voltage by Amaury Pouly |
| 13:35:39 | pamaury | I thought you said they were working |
| 13:35:55 | pamaury | isn't 22h like empty battery anyway ? |
| 13:36:12 | chrisjj | pamaury, I think he wasn't referring to my Unit N, but even if he was, most Unit N fails are data aborts. |
| 13:36:17 | pamaury | devices tend to power off after they run out of juice |
| 13:36:50 | chrisjj | pamaury, I said there were working while they were working. That was for the first few hours. |
| 13:37:54 | chrisjj | 22h would be battery empty except all these unisa re on mains power. After finding high incidence of BSoPO when /charging/ from low battery, I am avoiding internal power for tests, for now. |
| 13:38:03 | pamaury | wodz: indeed core_allocator_init() has a hack to reduce audiobufend depending on probed memory |
| 13:39:02 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 13:39:47 | pamaury | if they only crash after 20h, that's an improvement |
| 13:42:02 | pamaury | I'll send you another build with any kind of frequency and voltage scaling disabled to see what happens |
| 13:48:59 | pamaury | chrisjj: https://www.dropbox.com/s/atgauqu26zpyf8s/firmware_zen_nodfs.nk?dl=0 (bootloader) |
| 13:49:00 | pamaury | and https://www.dropbox.com/s/ldac8l6ci8jpk33/rockbox_zen_nodfs.zip?dl=0 |
| 13:49:00 | gevaerts | pamaury, wodz: I suspect you can't use the exact same mechanism as the ipod video. That one (ab)uses the fact that on the 32MB one the RAM is mapped twice, so you can use the codec and plugin buffers at the end of the 64MB block on both, and you merely have to adjust the end of the audio buffer |
| 13:49:19 | gevaerts | If the hardware does not map that RAM twice in that way, different approaches will be needed |
| 13:53:06 | pamaury | chrisjj: if you test those builds, can you, after you install both bootloader and rockbox, go to System > Debug > Show HW Info > clock and pastebin what you read ? |
| 13:53:13 | pamaury | gevaerts: I see |
| 13:53:17 | pamaury | looks like a hack anyway |
| 13:53:57 | pamaury | on imx233 I'm mapping the lcd buffer at the end of ram currently so it wouldn't work |
| 13:56:54 | | Quit wodz (Ping timeout: 255 seconds) |
| 13:58:06 | pamaury | chrisjj: re debug screen: I only care about the frequency on each clock (ie for each line the first word (the name) and the last number (the freq)) |
| 13:59:05 | gevaerts | Oh, it's a massive hack |
| 13:59:29 | gevaerts | But it achieved the goal in less than ten lines of code |
| 14:00 |
| 14:01:15 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 14:01:37 | | Quit wodz (Client Quit) |
| 14:01:41 | pamaury | does it really need to be a hack though ? fundamentally only the linker script ough to care about the exact memory size. And these days the audio buf is managed dynamically. Thus it should be possible to have a clean and generic solution where we map the audio buf at the end of ram and we can change it's size very early at boot before anyone uses it |
| 14:01:56 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 14:06:01 | | Quit mutnai (Quit: Page closed) |
| 14:13:23 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 14:18:39 | | Quit dfkt (Ping timeout: 240 seconds) |
| 14:20:56 | | Join The_Prospector|2 [0] (~The_Prosp@c-73-239-179-79.hsd1.wa.comcast.net) |
| 14:21:39 | | Quit wodz (Ping timeout: 240 seconds) |
| 14:23:59 | | Quit The_Prospector (Ping timeout: 245 seconds) |
| 14:24:24 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 14:25:04 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
| 14:26:20 | | Quit dfkt (Client Quit) |
| 14:28:23 | chrisjj | pamaury, Actual minimum run time is 26h12m according to battery_bench and 25h44m according to Running Time. Agreed, an improvement over the ~3h previously - but this could be due only to my switch from internal to external power. |
| 14:34:21 | chrisjj | pamaury, I guess the nodfs build is expected to reduce the incidence of BSoPO. So I shall first text the voltage_fix on internal power to possibly get a high incidence of BSoPO. |
| 14:35:12 | Bilgus | Does it always last exactly that long (like +- 5%?) |
| 14:35:44 | Bilgus | when it crashes that is |
| 14:46:07 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 14:47:20 | *** | Saving seen data "./dancer.seen" |
| 14:53:03 | chrisjj | Bilgus, I don't know if it crashes. The BSoPO may or may not be due to a crash. |
| 14:53:11 | chrisjj | Times are: |
| 14:53:16 | chrisjj | Unit P: After 32h 30m, running |
| 14:53:22 | chrisjj | Unit L: After battery_bench 26h12m and Running Time 25h44m, BSoPO |
| 14:53:28 | chrisjj | Unit G: After battery_bench 28h06m and Running Time 27h25m, BSoPO |
| 14:53:34 | chrisjj | Unit Q: After battery_bench 28h43 Running Time 26h03m, Creative charging screen (black except for battery icon in top right) |
| 14:55:41 | chrisjj | FTR, that's for build 8fec364f6-170125 (voltage fix) on charger-powered Creative ZENs. Which RAM variant these are is unknown. |
| 14:58:16 | Bilgus | huh so battery bench is still running after this black screen or how are you calculating runtime? |
| 15:00 |
| 15:00:52 | chrisjj | ZEN testers' Pro Tip: Running Time Total time is /not/ /necessarily/ /cleared/ when you use Windows Beyond Compare to delete .rockbox from the device and copy to the device a .rockbox from a distribution .ZIP (e.g. rockbox_zen_g1533.zip), then unplug, reset, and power-on. |
| 15:00:54 | fs-bluebot | Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : zen/zenxfi: adjust maximum emi voltage by Amaury Pouly |
| 15:02:02 | chrisjj | Bilgus, this Black Screen of Power Off does look 100% like a power off, so I can't see how BB can still be running. Running Time is not calculated by me, but read from System > Running Time. |
| 15:04:25 | pixelma | what should a black screen of power-off be? I mean if the device powers off the screen goes dark |
| 15:05:04 | chrisjj | Can you suggest other cause for the difference between battery_bench's last entry and Running Time? |
| 15:05:53 | pixelma | maybe one thing doesn't get kept/written as often |
| 15:07:33 | Bilgus | ah probabl what is happening is the last disk flush for run time never gets applied but its like 20 mins i'd think it'd flush in that amount of time |
| 15:08:39 | chrisjj | Greatest discrepancy is 2h40m. |
| 15:09:41 | Bilgus | chriss it sounds annoying but have you tried playing a bunchj of tracks and recording the output on the PC to see if it stops at the same time as battery bench? |
| 15:09:58 | chrisjj | I haven't. |
| 15:10:44 | Bilgus | that would pretty well answer the question without having to babysit the damn thing |
| 15:10:51 | chrisjj | battery_bench writes every minute. Won't this will spin up the 'disc', and so get Running Time flushed to disc? |
| 15:11:11 | Bilgus | you'd think? |
| 15:11:17 | chrisjj | :-) |
| 15:11:38 | gevaerts | For starters, battery_bench does *not* write every minute |
| 15:11:47 | gevaerts | That would make it entirely useless |
| 15:12:05 | chrisjj | So how often does it write? |
| 15:13:29 | Bilgus | conversely If bench were running don't you think that running time would keep incrementing |
| 15:13:29 | chrisjj | (And if true, would someone please correct "# This plugin will log your battery performance in a # file (//battery_bench.txt) every minute.") |
| 15:13:41 | gevaerts | When the "disk" "spins up" (quotes to account for flash being a bit different) for other reasons, when the buffer is full, and on shutdown |
| 15:13:51 | pixelma | I believe on disk access (which happen during rebuffer anyway) |
| 15:14:28 | gevaerts | It records data every minute. Writing that to disk every minute would distort the results enough to make them worthless |
| 15:14:33 | pixelma | rebuffering for playback I mean |
| 15:14:49 | chrisjj | gevaerts, Wow. That's really disappointing. Thanks for the info. |
| 15:15:10 | gevaerts | Yes, it's very disappointing that it works in a sensible way. We should fix that |
| 15:22:36 | chrisjj | pamaury, note the above re relying on battery_bench to record the runtime up to a BSoPO or crash. |
| 15:23:26 | chrisjj | Bilgus, you'd think! :-) |
| 15:26:40 | chrisjj | I don't doubt Running Time is still incrementing a RAM variable (I can see this displayed value incrementing), but how often the persistent version is updated, I don't know. |
| 15:28:43 | | Quit jhMikeS (Ping timeout: 276 seconds) |
| 15:29:08 | gevaerts | At least in the storage spinup callback |
| 15:31:04 | gevaerts | Which storage driver are you looking ar? |
| 15:36:24 | gevaerts | Hmmm |
| 15:38:02 | gevaerts | pamaury: am I right in thinking that (many?) sd drivers call call_storage_idle_notifys() on SYS_TIMEOUT (instead of spindown which is of course not possible), which is triggered by the backlight turning off? |
| 15:41:36 | gevaerts | At first sight it looks to me as if on targets where we don't use rtc nvram (which is most of them), "nvram" is only written to disk from a storage idle callback, and on settings save |
| 15:41:57 | gevaerts | If the storage idle callbacks aren't called near shutdown, that could cause what chrisjj is seeing |
| 15:58:34 | chrisjj | gevaerts, I don't know which storage drive in used in this port, being for ZEN. No save near shutdown would also explain loss of UI changes to Run Time that I've reported. |
| 15:58:37 | chrisjj | How frequent is this storage idle callback? |
| 16:00 |
| 16:06:22 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 16:14:49 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 16:14:58 | | Quit JanC (Remote host closed the connection) |
| 16:16:04 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 16:26:55 | | Quit alexweissman (Remote host closed the connection) |
| 16:35:23 | | Join Bilgus_ph [0] (~Bilgus_ph@108.115.82.231) |
| 16:36:45 | Bilgus_ph | PAMAURY: ill have a look at chessbox in a day or two |
| 16:36:55 | | Quit Bilgus_ph (Remote host closed the connection) |
| 16:46:39 | pamaury | gevaerts: I'll check but yes I think storage idle is called after some storage operation was done and X seconds later no activity was recorded. |
| 16:47:14 | pamaury | I don't know how "nvram" is handled on player where it does not exists, I would expect the code to flush it to disk on shutdown |
| 16:47:23 | *** | Saving seen data "./dancer.seen" |
| 16:48:43 | pamaury | chrisjj: if you let the player plugged for 22h, can you check if the battery isn't low ? Because on imx233, there is smart trick (TM) to make sure battery doesn't discharge after charge timeout |
| 16:48:51 | pamaury | and maybe this trick doesn't work on stmp3700 |
| 16:48:59 | pamaury | which means your battery charges and then discharges |
| 16:49:05 | pamaury | and then the device powers down |
| 16:50:29 | pamaury | actually I am 98.31478% sure it's not working on smtp3700 and battery is discharging after charging times out |
| 16:56:27 | * | pamaury starts his ZEN X-Fi to check |
| 16:57:09 | gevaerts | pamaury: I'd expect it to be called on shutdown as well, but I didn't find that |
| 16:58:06 | pamaury | why ? it doesn't really make sense |
| 16:58:16 | | Join furrywolf [0] (~randyg@107.25.30.188) |
| 16:59:09 | pamaury | I mean it's a hack, I would expect the shutdown to nvram_flush() or something |
| 16:59:28 | * | pamaury looks at the code |
| 17:00 |
| 17:00:40 | gevaerts | I might be wrong of course. Callback hooks are easy to miss |
| 17:07:36 | pamaury | I think you are right, it looks like the nvram code only writes to file on idle callback |
| 17:08:36 | | Join Senji [0] (~Senji@85.187.103.250) |
| 17:08:47 | pamaury | the code in settings.c is a bit confusing |
| 17:09:32 | pamaury | damn, why people don't comment public API x-( |
| 17:09:54 | pamaury | what is status_save() and settings_save(); |
| 17:11:01 | pamaury | gevaerts: do we actually store ALL settings to NVRAM on some targets ? |
| 17:12:16 | gevaerts | No, definitely not |
| 17:12:36 | gevaerts | IIRC nvram is 44 bytes on those systems that actually have it for real |
| 17:12:39 | pamaury | also seriously rtc_read(0x14+i), it really looks like HAVE_RTC_RAM == I_HAVE_FUCKING_ARCHOS |
| 17:12:55 | gevaerts | Yes :) |
| 17:13:36 | chrisjj | pamaury, re storage commits, I'd be interested to know that value of that X. |
| 17:14:02 | pamaury | it doesn't matter, it's a few seconds |
| 17:15:29 | pamaury | gevaerts: when is SYS_TIMEOUT sent ? |
| 17:15:46 | gevaerts | According to my grepping when the backlight goes off |
| 17:16:32 | chrisjj | pamaury, re battery, I have one (P) that I believe* to have been running for 36h. |
| 17:16:42 | chrisjj | * I now have no reliable way I know to find the runtime of a device from the device itself |
| 17:19:59 | pamaury | gevaerts: I think all sd drivers use the same copy pasted code (one of the many reasons I think we need a generic sd/mmc driver). That SYS_TIMEOUT stuff looks shaky |
| 17:20:12 | chrisjj | Ah, scratch that 'believe'. I just tried to check WPS, but that main menu command is 'Resume playback' and gives "Error accessing playlist control file". And the status bar shows the Stopped icon (solid square). So I assume playback actually stopped for some reason in the last 36h, even though there is no BSoPO. |
| 17:20:50 | gevaerts | pamaury: I'm assuming it was something that's done every now and then, but not too often... |
| 17:20:55 | chrisjj | This means the only run that survived past 29hrs was a faulty test. |
| 17:21:24 | pamaury | chrisjj: did you see my comment/question on battery ? |
| 17:21:45 | chrisjj | Yes. My [16:16] is the answer. |
| 17:23:33 | chrisjj | Answering your question, yes the player was plugged for 22h (though not playing for all that) and the best measure of whether battery is low is from the uncalibrated RB meter, which says 50%. |
| 17:24:38 | pamaury | it's not really an answer, a reliable way is to go to System > Debug > Show battery info and check battery voltage |
| 17:24:45 | * | pamaury will commit battery calibration |
| 17:25:15 | pamaury | gevaerts: probably SYS_TIMEOUT is not very well named or deserves a comment |
| 17:25:57 | pamaury | I fail to see why so many things are related to backlight timeout, it doesn't make sens |
| 17:26:37 | gevaerts | I agree, but I suspect it probably never meant to be used outside the backlight files |
| 17:26:53 | pamaury | actually it's incorrect |
| 17:27:00 | pamaury | queue_wait_w_tmo() returns event with sys_timeout |
| 17:27:07 | gevaerts | Oh |
| 17:27:09 | gevaerts | right... |
| 17:27:21 | pamaury | if you queue_wait_w_tmo(&queue, &evt, tmo); and it times out, then evt.id == SYS_TIMEOUT |
| 17:27:33 | pamaury | which makes sense |
| 17:27:35 | chrisjj | 50% looks very low for a unit that's been on charge for 36h, but perhaps the battery is near end of life. 'View battery' page 2 says Pwer status: discharging, Battery status: 3.816V, (4.9%) Charger: present |
| 17:27:42 | gevaerts | OK, so I was totally wrong :) |
| 17:28:03 | * | gevaerts now sees that that queue_post() he found is to backlight_queue |
| 17:28:08 | pamaury | chrisjj: so my suspision looks correct, the battery is discharging when plugged, and the device eventually powers off because of low battery |
| 17:28:31 | chrisjj | pamaury, you haven't get got an accurate battery_bench.txt from me. |
| 17:28:51 | pamaury | you sent me a battery bench file no ? |
| 17:29:16 | chrisjj | I thought not. |
| 17:29:47 | pamaury | gevaerts: so actually the code in sd makes complete sense now |
| 17:30:11 | pamaury | queue_wait_w_tmo(&sdmmc_queue, &ev, HZ); -> SYS_TIMEOUT after a second if no event (hotswap or usb). |
| 17:30:13 | | Quit Bilgus (Remote host closed the connection) |
| 17:30:38 | chrisjj | Your suspicion sounds like good news to me. I.e. the voltage tweak solved the BSoPO enough for devices to reach natural BSoPO due to a separete failure to run off external power. |
| 17:30:41 | | Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 17:30:55 | gevaerts | It makes more sense, yes, but doesn't that now make it write every second? |
| 17:31:13 | pamaury | thus it will (at least on imx233 but I expected other targets), notify idle storage after X seconds of inactivity after some read/write. X is 3 seconds on imx233 currently |
| 17:31:17 | gevaerts | Hmm, no |
| 17:31:24 | gevaerts | Right |
| 17:31:30 | gevaerts | Yes, that makes sense |
| 17:31:34 | pamaury | yeah |
| 17:32:38 | gevaerts | chrisjj: are you playing audio during these runtime tests? |
| 17:33:01 | chrisjj | Yes I am playing audio. But no jack inserted. |
| 17:33:05 | gevaerts | ok |
| 17:33:24 | pamaury | so notify callback is working as expected, however the nvram stuff is a bit more shaky |
| 17:33:47 | chrisjj | So/// is 'battery_bench does *not* write every minute' true, false, or unknown? |
| 17:33:54 | gevaerts | Yes, I'm not sure what storage activity there normally is on shutdown |
| 17:34:50 | pamaury | that depends on the battery bench code I believe |
| 17:35:22 | gevaerts | Actually, I'm fairly sure that *if* there is io on shutdown, the shutdown is going to happen less than three seconds after that, so nvram won't be written |
| 17:35:43 | * | gevaerts said earlier when battery_bench writes |
| 17:35:51 | pamaury | I ebelieve battery bench properly writes it on shutdown |
| 17:35:56 | gevaerts | It does |
| 17:36:04 | gevaerts | Shutdown, buffer full, idle callback |
| 17:36:09 | chrisjj | I think the're's no doubt the battery_bench code is writing every minute. The doubt is whether these writes are being committed to disc every minute. |
| 17:36:22 | pamaury | chrisjj: it doesn't mater |
| 17:36:35 | pamaury | those writes end up on disk |
| 17:36:43 | pamaury | that all what matters |
| 17:36:54 | gevaerts | There's no doubt the battery_bench does *not* write every minute. It stores to its internal buffer every minute, but it does not *write* |
| 17:36:55 | pamaury | (as long as the device doesn't crash obviously) |
| 17:37:22 | gevaerts | Writing every minute would be stupid and would destroy battery runtime on every spinning disk device |
| 17:37:33 | chrisjj | pamaury, Those writes end up on disc even if there is a crash?? Or angry watchdog reset?? |
| 17:38:01 | pamaury | I just said no |
| 17:38:40 | pamaury | but as long as the device properly shutdown because it runs out of batery, it's written to disk |
| 17:39:18 | chrisjj | OK, then your 'those writes end up on disc' is untrue in event of crash or reset. Got you. |
| 17:41:01 | chrisjj | We don't know if there is RB shutdown on these BSoPOs. I am assuming angry watchdog reset does not do RB shutdown. |
| 17:41:01 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 17:41:13 | chrisjj | Did I assuem wrong? |
| 17:42:26 | pamaury | gevaerts: what is eeprom_settings_store() ? |
| 17:43:06 | pamaury | chrisjj: no, watchdog does not shutdown properly |
| 17:43:24 | pamaury | so yes you assume correctly |
| 17:43:46 | gevaerts | pamaury: I don't know the details, but only iriver h1x0 has it |
| 17:44:36 | pamaury | gevaerts: I think clean_shutdown() needs to write the nvram settings |
| 17:45:23 | pamaury | ok wait |
| 17:45:26 | pamaury | *oh wait |
| 17:45:41 | gevaerts | In the batt_safe case, yes. Otherwise, I'd say no |
| 17:45:49 | pamaury | SYS_POWEROFF -> clean_shutdown() -> system_flush() -> call_storage_idle_notifys(true) |
| 17:45:58 | gevaerts | Hmmm |
| 17:46:40 | gevaerts | Right, so it looks like things work as designed |
| 17:46:58 | gevaerts | Which is *not* to save stuff on battery low shutdown :) |
| 17:47:18 | pamaury | yes :) |
| 17:47:20 | gevaerts | Which I think explains everything we see |
| 17:47:52 | gevaerts | Changing that on non-spinning storage *might* be safe, but I'm not convinced |
| 17:49:02 | pamaury | I think the way the code was designed, rockbox force power down only when the battery is really really low and thus spinning will be dangerous |
| 17:49:42 | gevaerts | Spinning takes a surprising amount of power |
| 17:50:04 | chrisjj | So RB is not saving stuff on battery low shutdown, but what's the evidence that is by design? |
| 17:50:09 | pamaury | it also depends on battery calibration |
| 17:50:19 | pamaury | chrisjj: the code |
| 17:50:20 | gevaerts | chrisjj: the code |
| 17:50:24 | pamaury | :D |
| 17:50:25 | gevaerts | if (batt_safe)... |
| 17:50:41 | chrisjj | Ah, some different meaning of the word 'design'. |
| 17:51:05 | pamaury | to be fair, that only happens when battery litterally reaches 0% |
| 17:51:30 | chrisjj | Would someone please provide a value for X that makes this statement true: "battery_bench writes every X minutes". |
| 17:51:50 | pamaury | there is no such value |
| 17:52:09 | chrisjj | So, not even e.g. 60 minutes? |
| 17:52:20 | pamaury | I think the more relevant question is why don't we power down before 0%, or rather why don't we have some configurable percentage to power down before that |
| 17:52:36 | pamaury | chrisjj: no, only on shutdown and when the storage is active |
| 17:52:56 | chrisjj | More relevant to deign yes. Not more relevant to testing current code. |
| 17:53:02 | pamaury | if you load a super huge playlist, this will happen regularly |
| 17:53:04 | chrisjj | OK, got you. |
| 17:53:25 | pamaury | storage takes power, it makes sense to minimize it |
| 17:53:29 | pamaury | especially during battery bench |
| 17:53:33 | chrisjj | Perhaps you'll recall your advice to me to use battery_bench as a source of runtime measure. |
| 17:53:57 | gevaerts | pamaury: isn't that basically the same as redefining 0%? |
| 17:54:07 | chrisjj | ZEN testers' Pro Tip: Do not use battery_bench as a source of runtime measure. In event of crash it can be wrong by >60minutes. |
| 17:54:09 | pamaury | well yes, as long as it does not crash, battery_bench is the best way to measyre runtime |
| 17:54:31 | gevaerts | In the event of a crash, we are interested in debugging the crash, *not* nin battery runtime |
| 17:54:40 | pamaury | if the device crashes randomly, measure battery runtime is usually the least of your problem |
| 17:54:47 | chrisjj | Your advice was for measuring the time up to a fail :-) |
| 17:55:20 | pamaury | well I gues it doesn't work unless you use to super huge playlist then |
| 17:55:29 | chrisjj | It is not about battery runtime. It is about device run time! :-) |
| 17:55:55 | pamaury | gevaerts: not necessarily, if you shutdown at 1%, you cleany save the current config, if you shutdown at 0%, you don't |
| 17:55:57 | chrisjj | I use a 500-track 22hr playlist on Repeat All. |
| 17:56:00 | pamaury | *cleany |
| 17:56:21 | chrisjj | ... and still it appears it doesn't work. |
| 17:57:07 | chrisjj | So, what other options do we have for determining how long a device ran before a BSoPO? |
| 17:57:17 | pamaury | I expect that with the voltage fix it will now work, because it's not crashing anymore |
| 17:57:33 | chrisjj | What makes you think it is not crashing any more? |
| 17:58:28 | | Quit Tristitia (Remote host closed the connection) |
| 17:58:56 | pamaury | because of the runtime: 3 or 4 devices, all stopping around 25h, which is expected battery runtime, coupled with the fact that there is a bug in the charging code that lets battery discharge when plugged too long to a charger |
| 17:59:21 | pamaury | that seems to indicate it powers down simply because the batery is low |
| 18:00 |
| 18:00:11 | pamaury | now the only thing that *may* be wrong is that some part of the code might be confused about running of battery when plugged to a charger |
| 18:02:04 | chrisjj | OK, got it. I'd say we have a non-crash explanation for the BSoOD, but we've not yet shown there are no crashes. |
| 18:02:42 | pamaury | I think four crashes, all around ~25h is *very* unlikely |
| 18:02:49 | chrisjj | I've seen confusion! |
| 18:03:16 | | Quit elensil (Quit: Leaving.) |
| 18:03:25 | pamaury | you can debate whether it's a crash or a clean shutdown, but I think it points heavily towards a low battery shutdown |
| 18:04:26 | * | pamaury thinks the best way to know is to fix the charging code |
| 18:04:30 | chrisjj | I wouldn't leave something so important to debate! I'd test it :-) |
| 18:05:34 | pamaury | gevaerts: don't you think it's a little unclean to do an unclean power down at 0% though ? Wouldn't it make sense to at least save a few things at 1% ? |
| 18:05:40 | * | chrisjj thinks the best way to know is to test. |
| 18:05:53 | pamaury | well stare at your device for 25h |
| 18:06:00 | chrisjj | :-) |
| 18:06:15 | pamaury | and at 24h, give me the battery voltage |
| 18:06:20 | chrisjj | I'd rather record the audio. |
| 18:06:58 | chrisjj | But really is there no way in RB? E.g. a loging plugin. |
| 18:07:11 | pamaury | chrisjj: I just confirmed the charging bug. I've let my ZEN X-Fi charge for 4h starting at 100%. After 3h, charging times out and battery is discharging |
| 18:07:12 | chrisjj | Neddless to say I don't care about battery drain. I'm not using the battery. |
| 18:07:18 | chrisjj | Fast work :-) |
| 18:08:01 | pamaury | So for me, voltage fix + that explains everything except the "unit N" that has the weird dots and data abort on boot |
| 18:08:57 | chrisjj | You recall my owrry about charging timeout two weeks back? IIUC you thought then that this occurred during topoff only. Are we saying you've found drain doesn't reset the timeout or something? |
| 18:11:04 | pamaury | Yeah, after top off is disables the charger but because of the power architecture of the stmp3700 (which is slightly different from imx233), this causes the player to draw power battery instead of usb |
| 18:11:13 | pixelma | pamaury: isn't any low battery value (even 1%) a bit unsafe because in this low end part it is still very very different depending on the shape (i.e. fitness) of the battery? So unless you want to shutdown at a much higher level and throw away some runtime you still can't be safe writing something to disk before a low battery shutdown? |
| 18:11:16 | pamaury | *power from batery |
| 18:11:24 | chrisjj | Gawd! Well, glad to caught it. |
| 18:11:35 | pamaury | pixelma: yeah I guess you are right |
| 18:12:29 | pamaury | still feels a bit wrong though, because I'm sure the playback code will happily read from storage at 1% |
| 18:13:17 | pamaury | actually I don't know when rockbox shutdowns, it probably doesn't wait for 0% |
| 18:13:20 | gevaerts | It will, but in cases where that's dangerous that will immediately pull the voltage down and cause a low-battery shutdown |
| 18:13:29 | * | pamaury reads the code |
| 18:16:32 | pamaury | I think it depends on battery_level_shutoff |
| 18:18:18 | pamaury | actually you are right, it may shutdown at more than 0%, but batt_safe will always be false even in this case |
| 18:34:54 | chrisjj | ZEN Testers' (Semi-)Pro Tip: Despite imx233 in source '\firmware\target\arm\imx233\creative-zen', ZEN uses STMP3760 and this is /slightly/ /different/ https://www.rockbox.org/irc/log-20170127#18:11:04 |
| 18:37:03 | | Quit The_Prospector|2 (Quit: when in doubt, kernel panic) |
| 18:39:43 | chrisjj | pamaury, It sounds to me like I should test a build from you being Version voltage_fix + Fix 'Charge topoff timeout leads to power sourced from battery not charger' + Mod 'Disable reset by watchdog' + nothing else at all. |
| 18:40:51 | pamaury | I don't see the point of disabling reset. And I don't have a fix for charging code yet |
| 18:42:42 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 18:43:40 | * | pamaury thinks Freescale should learn logic, that would simplify there power diagram |
| 18:43:44 | pamaury | *their |
| 18:45:28 | | Quit athidhep (Quit: athidhep) |
| 18:47:27 | *** | Saving seen data "./dancer.seen" |
| 18:48:06 | pamaury | hmmm, I think stmp3700 will require a completely different approach to charging than imx233 |
| 18:50:43 | chrisjj | You previously suggested further test builds to me would have nowdt. The point for me is to eliminate BSoPOs due to crash. Had the last few builds has nowdt, we would not have mistaken (what we now assume to be) the battery low BSoPOs for (what until an hour ago we assumed to be) crash BSoPO, and we wouldn't have wasted a lot of time. |
| 18:51:29 | chrisjj | TLDR; Until we have get proven stable execution, nowdt will save time and confusion. |
| 18:51:48 | chrisjj | d/get/ |
| 18:53:21 | chrisjj | Perhap nowdt could be made a System settings option, off by default, allowing it to go in the master and thereby cut the hassle to you of special builds. |
| 18:53:57 | chrisjj | You can bet I'd find a use for that in production builds for years :-) |
| 18:55:16 | * | chrisjj thinks for now he'll use a different approach to charging: un and replugging the charger even 2.5hrs :-) |
| 18:57:03 | pamaury | nowdt will not be a system setting. At best it can be a debug setting well hidden in debug menu |
| 18:57:04 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 18:58:29 | pamaury | wodz: hey :) did you have time to try anything with audio on nwz ? |
| 18:59:02 | wodz | pamaury: Current desgn is heritage of spinning disk storage. Spinning up disk kills even healthy battery when it is almost empty while playback is sustained for a fair amount of time still. |
| 18:59:32 | wodz | pamaury: Maybe I'll find some time tonight |
| 19:00 |
| 19:00:29 | wodz | It may make sense to change this for flash players |
| 19:05:23 | | Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu) |
| 19:06:17 | chrisjj | Oops, sorry, I did mean a System Debug setting. |
| 19:16:00 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 19:30:44 | * | chrisjj realises charge bug workaround's un- & re-plug doesn't need to be every 2.5hrs. Every 12hrs will suffice... when it is acceptable for test conditions to include battery powered. |
| 19:31:47 | * | chrisjj starts voltage_fix test runs on four ZENs, planning replugging of charger every 12hrs |
| 19:35:00 | chrisjj | Can plugin code get writes to a file to be actually written to disc? E.g. by closing the file and reopening? Or making some special storage manager call? |
| 19:36:03 | pamaury | chrisjj: I think you misunderstood, writes to file end up on disk. What battery bench does is that it only writes when the storage idle callback is called |
| 19:37:12 | pamaury | actually writes are probably cached but open(), write(), close() most probably flushes to disk |
| 19:38:15 | gevaerts | As far as I know, writes are cached up to a full sector |
| 19:38:41 | gevaerts | But you can always call fflush() |
| 19:39:05 | gevaerts | Hmm, maybe not |
| 19:41:06 | | Quit Moarc (Ping timeout: 260 seconds) |
| 19:41:34 | pamaury | I'm not sure we have fflush() |
| 19:41:40 | pamaury | but possibly close() flushes |
| 19:41:47 | pamaury | with have storage flush |
| 19:41:50 | gevaerts | close() definitely does |
| 19:42:19 | pamaury | then I guess open(), write(), close() is good enough |
| 19:42:22 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 19:42:23 | gevaerts | We don't have a filesystem cache as such |
| 19:42:28 | pamaury | it's what batery bench does |
| 19:42:57 | pamaury | ah yeah you're right, it's per file cache for the current sector |
| 19:44:04 | gevaerts | I'm not even sure if it *really* caches the sector in the way you'd normally understand that, or if it just has that because you need to read sectors from disk if you want to support appending on non-full-sector files |
| 19:47:50 | pamaury | well you want to cache a sector just because if you read one byte at a time, you want to be fast, same for writes |
| 19:48:31 | gevaerts | You can't really read one byte at a time |
| 19:48:33 | pamaury | it's the minimal amount of caching you need in a sane design |
| 19:48:45 | pamaury | you could read a sector, take one byte and through it away ;) |
| 19:48:49 | pamaury | *throw |
| 19:48:52 | gevaerts | well yes :) |
| 19:49:54 | | Quit GodEater (Quit: Coyote finally caught me) |
| 19:52:49 | | Quit petur (Quit: Leaving) |
| 19:53:14 | | Quit wodz (Ping timeout: 240 seconds) |
| 19:54:13 | | Join GodEater [0] (~whoknows@176.253.28.187) |
| 19:54:13 | | Quit GodEater (Changing host) |
| 19:54:13 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 19:54:51 | __builtin | afaik we don't do any I/O buffering |
| 19:55:48 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 20:00 |
| 20:06:36 | | Join alexweis_ [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu) |
| 20:07:27 | | Quit alexweissman (Ping timeout: 240 seconds) |
| 20:14:38 | | Quit alexweis_ (Read error: Connection reset by peer) |
| 20:25:36 | jhMikeS | chrisjj: fsync() |
| 20:38:58 | | Quit uwe_android__ (Remote host closed the connection) |
| 20:38:58 | | Quit uwe_mobile__ (Remote host closed the connection) |
| 20:47:28 | *** | Saving seen data "./dancer.seen" |
| 20:48:35 | | Join VargIVeum [0] (6d6804dd@gateway/web/cgi-irc/kiwiirc.com/ip.109.104.4.221) |
| 20:49:02 | | Quit VargIVeum (Client Quit) |
| 21:00 |
| 21:25:17 | | Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu) |
| 21:28:10 | | Join mutnai_ [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 21:29:43 | | Quit alexweissman (Ping timeout: 240 seconds) |
| 21:33:32 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 21:34:26 | lebellium | pamaury: when do you think you'll have time to progress on the nwz port? |
| 21:36:48 | pamaury | this week-end |
| 21:37:55 | lebellium | great |
| 21:38:49 | chrisjj | pamaury, I think I understood correctly, that writes to file end up on disk /provided/ no crash in the meanwhile. |
| 21:39:52 | pamaury | chrisjj: where meanwhile == in the next millisecond or so |
| 21:39:56 | chrisjj | What I'm asking is can plug-in code get writes to file actually written to disc upon request. |
| 21:40:13 | chrisjj | Oh? Millisecond? |
| 21:40:21 | pamaury | write is a write, you write to disk |
| 21:40:42 | pamaury | there is avery small amount of buffering involved but if you open(), write(), close(), it's on disk |
| 21:40:53 | pamaury | what I already explained is that this *not* what battery bench does |
| 21:41:09 | pamaury | battery bench only does open(), write(), close() on storage idle callback |
| 21:41:54 | pamaury | and it registers a storage idle callback every minute or something like that, but that doesn't mean the callback is called every minute |
| 21:42:55 | chrisjj | I'm not asking about battery_bench, but about plug-in code in general. |
| 21:43:24 | chrisjj | So I take it 'writes are cached up to a full sector' is true, meaning writes are in general vulnerable to loss on crash indefinitely, but close() puts it on disc for sure, within ms. |
| 21:43:52 | | Quit furrywolf (Read error: Connection reset by peer) |
| 21:44:02 | pamaury | plugin is no different from any other code, it uses open, write and close |
| 21:44:15 | pamaury | depends on how it's implemented |
| 21:44:17 | | Join furrywolf [0] (~randyg@107.25.30.188) |
| 21:44:31 | pamaury | battery bench is one way of implementing things |
| 21:44:33 | pamaury | the right way |
| 21:45:44 | chrisjj | You're saying it depends on how close() is implemented? |
| 21:45:56 | pamaury | no it depends on how the plugin is implemented |
| 21:46:04 | chrisjj | Great. Thanks. |
| 21:46:24 | pamaury | there is fsync also to force a flush to disk, in case where you don't want to close the file |
| 21:47:10 | chrisjj | Then what I'd like is a plug-in that does what battery_bench says it does do but doesn't do. Logs "in a file every minute." |
| 21:47:23 | __builtin | fsync() isn't exposed in the plugin API though |
| 21:47:27 | chrisjj | Got it, and thanks jhMikeS, |
| 21:48:39 | pamaury | then modify battery bench to log every minute instead of registering an idle callback |
| 21:51:20 | chrisjj | Indeed that's where I'd start. And though it has been said here that makes it useless for its intended purpose, ISTM that's untrue for flash-based devices. |
| 21:51:22 | | Quit mutnai_ (Quit: Page closed) |
| 21:51:31 | | Quit mutnai (Quit: Page closed) |
| 21:52:14 | dys | pamaury: the blackfin was stronger than the rpi SoC, but I eventually found out when I power it up with the DO line grounded, the boot rom appears to halt and tristate everything -> PROFIT |
| 21:52:16 | __builtin | what is `ISTM' supposed to mean? |
| 21:53:39 | lebellium | __builtin: are you really reading?! |
| 21:54:49 | chrisjj | "It Seems To Me" https://www.google.co.uk/search?espv=2&q=ISTM+acronym |
| 21:54:59 | pamaury | chrisjj: it doesn't matter what you think, battery_bench does what it is intended for: evaluating the maximum battery life, whatever the type of storage |
| 21:55:17 | pamaury | dys: cool :) |
| 21:56:00 | __builtin | https://www.rockbox.org/wiki/IrcGuidelines: "Use clear, grammatical, correctly-spelled English." |
| 21:56:13 | chrisjj | pamaury, Does https://www.rockbox.org/tracker/task/9155 'written when the disk is active anyway' still apply? |
| 21:57:52 | pamaury | chrisjj: are you reading what we say ? |
| 21:57:57 | chrisjj | Yup. |
| 21:58:04 | chrisjj | Does that still apply? |
| 21:59:33 | pamaury | We just spend many lines explaining to you that battery bench only writes when the disk is active |
| 21:59:53 | chrisjj | 'Cos if so, it seems to me that battery bench is going to write every time a track longer than 60s is read from store. |
| 22:00 |
| 22:01:08 | pamaury | ? |
| 22:01:19 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 22:01:41 | chrisjj | Store being 'disk' in this case. |
| 22:02:34 | pamaury | I'm not following your logic here |
| 22:02:36 | chrisjj | This might explain why your battery benchmarking procedure works for the discharge part, but fails (here every time) for the charge part when there is a BSoPO. |
| 22:02:48 | chrisjj | OK, sorry to be unclear. |
| 22:03:08 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 22:03:13 | dys | pamaury: we have strings! however, curiously, the first 400kB read ff/00. I hope it's not some lock bit preventing readout |
| 22:04:57 | pamaury | dys: cool :) Even the very first bytes ? I need to double check what the manual says about booting from SPI. Do you have the whole flash dump ? Can you upload it somewhere ? |
| 22:04:57 | chrisjj | If battery bench writes /every/ time the disk is active, and the disc is active every time a track is loaded, and a track is loaded each time one completes (assuming the large playlist that your procedure requires), then ... |
| 22:05:14 | pamaury | chrisjj: that's not how buffering works, at all |
| 22:05:14 | gevaerts | Then your assumptions are incorrect |
| 22:05:45 | | Quit michaelni (Ping timeout: 258 seconds) |
| 22:05:46 | chrisjj | Write buffering, or track buffering? |
| 22:05:47 | | Quit Senji (Ping timeout: 240 seconds) |
| 22:06:22 | pamaury | chrisjj: although I'm not an expert of the (very complex) buffering code, it basically loads as much much as possible, then decodes when needed, and only rebuffers on low watermark. Basically it minimizes disks access and reads as much as it can at a time |
| 22:06:38 | chrisjj | That's my understanding too. |
| 22:07:02 | chrisjj | And since my tests are feeding 2.4Gb of tracks, the buffering must at some time load tracks in play. |
| 22:07:17 | gevaerts | Strictly speaking, no |
| 22:07:31 | gevaerts | Parts of tracks, yes |
| 22:07:32 | chrisjj | But I recognise that if it has a very low watermark... |
| 22:07:43 | chrisjj | .. (though goodness knows why on flash)... |
| 22:07:54 | chrisjj | ... then disc activity is still rare. |
| 22:08:09 | pamaury | with compressed formats, you don't need to rebuffer that much |
| 22:08:10 | chrisjj | Parts of tracks is fine. |
| 22:08:12 | gevaerts | Yes, which is *exactly* the opposite of what you were saying |
| 22:08:15 | gevaerts | Please stop trolling |
| 22:08:45 | pamaury | A typical 3/4MB song will last several minutes. The ZEN has 32MB of memory, you can store almost an hour compressed in RAM |
| 22:08:46 | chrisjj | So, is there anything on e.g. System > Debug that shows disc activity? I'll see what it is doing in these tests. |
| 22:09:14 | chrisjj | Meanwhile if anyone has a better explanation for discharge succeeding and charge failing, I'd love to hear it. |
| 22:10:05 | chrisjj | I'm using 5Mb tracks already compressed. |
| 22:11:23 | chrisjj | How much is stored is not relevant to how frequently load occurs. What is relevant is how much is between low and high watermark. |
| 22:12:18 | pamaury | if you follow the logic up to the end, the watermark must be pretty low, otherwise it doesn't make sense |
| 22:12:46 | __builtin | lebellium: I've found that reading /some things/ is a waste of time and effort :P |
| 22:13:53 | chrisjj | I've seen no logic that says the watermark /must/ be low. Flash would not require it. Perhaps it's low as inherited from real disc requirements. |
| 22:14:04 | prof_wolfff | wodz: just seen your log on nano2g USB probes, at this moment i am out of home so i have no access to my nano2g, i hope to do extensive testing tomorrow at home, anyway... what i see at first look is a bunch of 'hw' errors, it goes forward, at last the host tries to reset the USB device but there is no response from the device and everything ends at this point, the 'hw' errors could come from USB driver, NAND driver or HW itself |
| 22:14:04 | prof_wolfff | but i am really worried because in any case USB bus should reset and enumerate but really it fails to do that, it is not easy to debug this thing, while developing i was using serial debug to do that, i suppose you cannot do that (you need a modified cable to read serial tx), so any clue will be useful for me, i.e. what happens after USB copy fails? i assume there is no panic, right? does HID works well? does RB works well is you di |
| 22:14:04 | prof_wolfff | sconnect USB or just everything hangs? |
| 22:14:11 | chrisjj | Can't I just see from Debug when the buffer is loaded? That would answer the mystery. |
| 22:14:59 | pamaury | there is some buffering debug screen somewhere I think |
| 22:15:11 | pamaury | chrisjj: it still makes sense on flash, despite what you think |
| 22:15:22 | chrisjj | Yup, I've seen it mentioned in IRC but not found it. |
| 22:15:37 | pamaury | read/write require the flash and controller and clocks to be powered, you want to minimize that |
| 22:16:29 | chrisjj | Sure, but flash 'spin-up' is tiny compared to disc spin-up, in power consumption terms. |
| 22:17:18 | amazoniantoad | Is there something like itunes for rockbox? |
| 22:17:49 | scorche | amazoniantoad: in what sense? |
| 22:17:52 | __builtin | amazoniantoad: not really |
| 22:18:07 | amazoniantoad | A library manager I guess. I'd like to have a gui for managing my playlists and stuff |
| 22:18:18 | scorche | not specifically for rockbox, but there are plenty of those sorts of programs around |
| 22:18:34 | amazoniantoad | Will the work with rockbox? |
| 22:18:34 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 22:18:36 | amazoniantoad | they* |
| 22:19:10 | scorche | amazoniantoad: you get to try them and find out! |
| 22:19:17 | gevaerts | scorche: did you see the current state of the forums? |
| 22:19:26 | scorche | rockbox isnt anything special - files are files on disk, etc |
| 22:19:39 | gevaerts | amazoniantoad: if you're *really* bored and motivated, it's actually not impossible to get itunes to work with rockbox |
| 22:19:39 | scorche | gevaerts: nope |
| 22:19:49 | gevaerts | scorche: some database issue now |
| 22:19:58 | scorche | gevaerts: yes - i see that now :) |
| 22:20:03 | scorche | thanks |
| 22:20:07 | amazoniantoad | Well I was considering writing a program to retain my playlists while still sorting the songs to the appropriate bands/albums |
| 22:20:16 | amazoniantoad | But I'm hoping some gui like iTunes will do that for me. |
| 22:20:23 | pamaury | chrisjj: I don't see the point. When you have the choice between one tiny power up, one big read, power down, or multiple tiny power up, one small read, and power down. The first option is still the best |
| 22:21:08 | chrisjj | Let's not mention Shuffle :-) |
| 22:21:15 | scorche | amazoniantoad: there likely is such a thing in existance, but it isnt really the focus of this channel |
| 22:21:19 | gevaerts | The thing is that the playback and buffering system is complex enough that at any given time it's hard to find someone who understands enough of it. Clearly what we want is *two* of those systems |
| 22:21:40 | chrisjj | Regardless, do you have any other idea why charging battery_bench is failing, or any guessed workaround? |
| 22:21:48 | amazoniantoad | scorche, of course. I just though I'd ask. Thanks for the answers guys. This channel is one of the highest quality irc channels I've come across. |
| 22:21:56 | amazoniantoad | Great community here. |
| 22:23:27 | chrisjj | pamaury, actually the better question is: Have you ever got the charging part of your procedure here https://www.rockbox.org/wiki/CreativeZENPort#Battery_Calibration to work? |
| 22:24:15 | scorche | gevaerts: its back |
| 22:24:20 | gevaerts | Yay! |
| 22:24:45 | scorche | gevaerts: feel free to ping me when you notice this |
| 22:25:03 | scorche | i am bouncing the server often enough, but often fail to actually check that it came up cleanly |
| 22:25:25 | gevaerts | scorche: oh, I do, usually when you're asleep :) |
| 22:25:51 | scorche | oh - so you did |
| 22:26:11 | pamaury | chrisjj: I'm pretty sure I did |
| 22:26:22 | chrisjj | OK, nice to know. |
| 22:28:45 | chrisjj | I'll try this on voltage_fix expecting no BSoPO to wipe the battery_bench buffer, and then I'll manually shut down to write it to disk. We'll see. |
| 22:31:59 | chrisjj | pamaury, on a different subject, I've found the unit that acted different on one of your attempted backlight flash fix attempts also acts different on backlight wake on power source going charger -> battery. |
| 22:32:44 | chrisjj | It doesn't wake. |
| 22:33:41 | chrisjj | (Mostly.) |
| 22:35:24 | chrisjj | So I wonder... Did you find out whether RB code can even detect whether the RAM is 32 or 64Gb? |
| 22:36:13 | chrisjj | s/Gb/Mb/ |
| 22:36:42 | chrisjj | (This unit (G) is one of those on the soak test so I've not yet reflashed it to determine whether it is another 64b unit.) |
| 22:36:58 | | Join gbl08ma [0] (~gbl08ma@ec2-52-23-151-127.compute-1.amazonaws.com) |
| 22:37:38 | pamaury | rockbox can detect the size but currently it only uses the size set at compile time. Changing that is not trivial |
| 22:42:39 | prof_wolfff | TheSeven: about nano2g, i did some research on disassembling s5l8702 OF, some of your IDA scripts help me to manage the EFI modules on s5l8702, but really i have not info about s5l8701 and ATM i have not much time so i am a bit lazy to reverse engineering, I would appreciate if you can locate and share any info you have about s5l8701 |
| 22:47:29 | *** | Saving seen data "./dancer.seen" |
| 22:51:51 | | Join VargIVeum [0] (6d6804dd@gateway/web/cgi-irc/kiwiirc.com/ip.109.104.4.221) |
| 22:53:38 | | Quit VargIVeum (Client Quit) |
| 23:00 |
| 23:01:00 | Bilgus | amazoniantoad, how did your bluetooth project work out |
| 23:03:13 | amazoniantoad | Bilgus, not quite done. I was never able to get around to this final step. Will have time in a little bit |
| 23:03:25 | wodz | prof_wolfff: After usb failing the player is stuck in usb screen. The only reaction on physical cable disconnect is backlight on. The only way to recover is hard reset. After reset booting takes considerably longer (I assume apple boot code does some ftl cleanup). Disk mode works flawlessly. |
| 23:03:33 | amazoniantoad | Trying to finish up my program to rip songs from spotify. TAILS is being a bitch though. |
| 23:03:49 | amazoniantoad | I guess it's just all locked down. |
| 23:04:17 | amazoniantoad | Bilgus, I plan on finishing it today though. |
| 23:04:53 | Bilgus | LOOKFOR saver2 by zigzag |
| 23:05:37 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 23:05:53 | amazoniantoad | oh nice. |
| 23:06:16 | chrisjj | pamaury, OK, so RB could be inadvertently sensitive to RAM size. |
| 23:06:20 | scorche | lets not talk about ripping songs from spotify here... |
| 23:06:23 | amazoniantoad | Well I don't know if spotify can see what's going on with that program spotify-ripper. So I'm trying to write up some additional security just in case. |
| 23:06:44 | amazoniantoad | scorche, oh I didn't mean spotify the music app. I meant something totally unrelated to the spotify music streaming service. |
| 23:06:50 | amazoniantoad | Spotify is what we call my uncle joe. |
| 23:06:56 | amazoniantoad | It's his nickname from childhood. |
| 23:07:02 | | Join Exo_ [0] (45786f4c@gateway/web/freenode/ip.69.120.111.76) |
| 23:07:05 | scorche | amazoniantoad: either way, it doesnt have anything to do with Rockbox... |
| 23:07:12 | dys | fan service… http://ansel.ydns.eu/~andreas/getting_serious_with_a_blackfin_port.jpg |
| 23:07:18 | amazoniantoad | I'll make sure to tell my uncle joe. |
| 23:07:50 | wodz | dys: I like that! |
| 23:07:59 | Exo_ | Heya folks... anyone familiar with the H340 and the iflash adapters? |
| 23:08:31 | wodz | pamaury: Could you point me to instruction how to install bootloader on nwz? |
| 23:10:57 | mutnai | anyone here with nw-zx100 ? |
| 23:14:22 | pamaury | wodz: writing instructions... |
| 23:14:45 | wodz | pamaury: Is toolchain rework commited or it sits somewhere on gerrit? |
| 23:17:40 | wodz | found it |
| 23:20:16 | prof_wolfff | wodz: thanks! i will test it tomorrow and send you my findings |
| 23:20:48 | wodz | prof_wolfff: If you want me to test something, ping me |
| 23:22:00 | pamaury | wodz: https://gist.github.com/pamaury/951cbe4e361da46a8ff9027b21381cdd |
| 23:22:19 | pamaury | wodz: it's in the NWZ commit I think |
| 23:22:21 | | Quit amayer (Quit: Leaving) |
| 23:23:13 | pamaury | wodz: what is your device again ? |
| 23:23:26 | prof_wolfff | ok, first i will test it using the latest HEAD and if i cannot find the bug i will send you a debug version to try to locate what is happening |
| 23:23:36 | prof_wolfff | wodz: ^ |
| 23:23:37 | wodz | pamaury: yeah, you should untangle rockboxdev.sh change from that and just commit. |
| 23:23:43 | wodz | pamaury: e474 |
| 23:23:54 | wodz | prof_wolfff: ok |
| 23:25:28 | pamaury | wodz: I'm not i've added E470, let me check, it's kind of trivial right now but not sure it's in the commit |
| 23:26:33 | pamaury | yep, give me 5min to add it |
| 23:27:32 | wodz | pamaury: I compile toolchain now so you have some time :P |
| 23:27:37 | pamaury | ok :) |
| 23:30:35 | fs-bluebot | Build Server message: New build round started. Revision d4303ac, 255 builds, 15 clients. |
| 23:31:58 | | Quit mutnai (Quit: Page closed) |
| 23:32:33 | pamaury | wodz: I updated gerrit |
| 23:32:42 | wodz | great |
| 23:33:30 | pamaury | I tried to compile the bootloader for NWZ-E470 and it works, so you should not encounter any problem |
| 23:33:43 | pamaury | but if you want to speed up thing, I can send you a prebuilt one |
| 23:34:09 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 23:34:50 | wodz | pamaury: Please send as compiling toolchain will take a while |
| 23:36:24 | dys | *sigh* … H74R … The markings on tiny chips are really unforgiving (pamaury) |
| 23:37:17 | dys | If anyone has an idea what this critter could be, I'd be highly interested |
| 23:37:36 | dys | (8-pin case, suspected flash) |
| 23:37:55 | pamaury | wodz: https://www.dropbox.com/s/f49huqibakz9uju/NW_WM_FW_nwze470.UPG?dl=0 |
| 23:38:45 | pamaury | dys: usually on small flashs, the marking does not even correspond to the part name, or can be a small part of it, it's going to be hard :-/ are you sure it's on the spi bus ? could it be i2c ? |
| 23:39:07 | dys | pamaury: can the blackfin boot from i2c, too? |
| 23:39:28 | pamaury | not sure, I'm checking |
| 23:41:08 | furrywolf | ok. I got a new microsd card. who wants to figure out why the original partition table breaks rockbox? (assuming this card does the same thing as the last one, of course) |
| 23:41:17 | wodz | pamaury: http://paste.debian.net/911017 :-/ |
| 23:41:24 | pamaury | dys: apparently not, it supports uart, link port, emmc, sd and spi |
| 23:42:01 | pamaury | wodz: install libmpfr-dev, libgmp-dev and libmpc-dev |
| 23:42:07 | fs-bluebot | Build Server message: Build round completed after 691 seconds. |
| 23:42:08 | fs-bluebot | Build Server message: Revision d4303ac result: All green |
| 23:42:14 | wodz | There was a site to decode smd part *markings* but can't remember the url |
| 23:44:20 | furrywolf | can I assume the first megabyte of the card will contain all relevant info to debugging this? |
| 23:46:21 | wodz | furrywolf: mbr + partition table is fraction of this |
| 23:46:42 | furrywolf | +fat, since someone was suspecting filesystem oddness |
| 23:51:44 | furrywolf | ok, it's currently not working. other than doing the steps to make it work, and taking images every step, anything I should do? |
| 23:52:40 | wodz | pamaury: Any special way to write scripts run from 'debug tools' menu? |
| 23:53:05 | furrywolf | ... ok, I might have just solved it, and it's a lot easier than I thought. cfdisk and fdisk are disagreeing on the partition type. |
| 23:53:19 | furrywolf | cfdisk is saying it's fat32, fdisk says it's ntfs. |
| 23:53:41 | furrywolf | I'm guessing it's set to something funky, and rockbox is ignoring it. |
| 23:54:06 | wodz | furrywolf: What capacity is this card? |
| 23:54:49 | furrywolf | yep, that was it. |
| 23:55:09 | pamaury | wodz: no, just make sure they work with sh, and not bash |
| 23:55:36 | furrywolf | 128gb, originally formatted with exfat. cfdisk shows it as being fat after reformatting it, but fdisk still says ntfs. I went by cfdisk's information before. obviously the partition type is funky and/or cfdisk is broken. |
| 23:55:48 | wodz | pamaury: Does it need to be decorated with #!/bin/sh or something? |
| 23:56:02 | furrywolf | changing the partition type to 0b makes rockbox read it. |
| 23:56:29 | wodz | furrywolf: partition type and filesystem are two different things |
| 23:56:43 | pamaury | wodz: no, I run it with "sh <script>" |
| 23:57:27 | furrywolf | yes. I am aware of this. when I reformatted it before, after it didn't work, I checked with cfdisk, which showed the partition type as fat32, so I assumed mkdosfs had helpfully changed the partition type as well. fdisk shows it doesn't. I don't know what cfdisk is smoking. |
| 23:57:46 | furrywolf | in any case, it's not a rockbox issue, it's a cfdisk issue. |
| 23:58:18 | wodz | pamaury: Where is 'user visible' part of flash mounted from player pov? |
| 23:58:33 | wodz | pamaury: I mean where can I log output of commands |
icon identifies that the person is a core developer (has commit access).