Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2020-08-02

00:10:27 Quit bzed (Read error: Connection reset by peer)
00:12:34 Join bzed [0] (~bzed@shell.bzed.at)
00:24:23***Saving seen data "./dancer.seen"
00:26:25fs-bluebotBuild Server message: New build round started. Revision affaa94, 280 builds, 10 clients.
00:41:00fs-bluebotBuild Server message: Build round completed after 876 seconds.
00:41:02fs-bluebotBuild Server message: Revision affaa94 result: All green
00:43:52 Quit ac_laptop (Ping timeout: 246 seconds)
00:52:26 Join Lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com)
00:54:13 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
01:00
01:04:38 Quit Huntereb (Ping timeout: 256 seconds)
01:26:55 Quit ac_laptop (Ping timeout: 246 seconds)
02:00
02:12:06 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
02:15:04 Quit J_Darnley (Ping timeout: 256 seconds)
02:24:26***Saving seen data "./dancer.seen"
04:00
04:00:30 Quit S|h|a|w|n (Read error: Connection reset by peer)
04:12:33 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr)
04:24:30***Saving seen data "./dancer.seen"
04:44:08 Join mendel_munkis_ [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net)
04:46:25 Quit mendel_munkis (Ping timeout: 240 seconds)
04:52:11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:00
05:00:48 Nick mendel_munkis_ is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net)
05:02:24mendel_munkispamaury: I am trying to figure out the relative speeds of writing and reading to/from registers but can't figure out where in the datasheet to look. can you give me any pointers?
05:13:43pamaurymendel_munkis: you mean hardware registers?
05:13:49mendel_munkisyes.
05:14:47pamaurywell I don't have any figures, it might depend on which bus it is but most internal buses run at least several tens of MHz, so probably it takes at least one cycle, a bit more for a read. Why does it matter?
05:16:37pamauryto be more precise (I have to leave but I git you pointer from what I remember): there is the "slow" APB bus (look up ts frequency, probably 24Mhz) and the fast APH bus (frequency can change, at least 100Mhz)
05:17:17mendel_munkisI am thinking of replacing the "set on init" in the freescale RTC with a set conditional on elapsed Seconds and was wondering if replaceing a write with a read would slow things down at all.
05:21:13pamaurysorry AHB so APH
05:21:45pamaurynot I think it's completely okay, one read every second is nothing
05:21:56pamauryI need to leave but I stay online and read things later
05:25:03pamauryif you put it on gerrit I'll have a look. I guess this is for the alarm? Isn't the IRQ working?
05:26:02mendel_munkisno this a reworking of the loss of power fix.
05:27:05pamaurywhy is that needed btw? There is a brownout IRQ/FIQ for loss of power
05:29:55mendel_munkisMy recent 2601 and 2616 patches are primally meant to deal with the case of a total loss of power to chip (battery removal) A way of making that only run where necessary occurred to me and that is what I am trying to implement.
06:00
06:15:20 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
06:24:34***Saving seen data "./dancer.seen"
06:52:23 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:61b4:47c2:35f0:2ce0)
07:00
07:34:03 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
07:36:08 Quit jdarnley (Ping timeout: 256 seconds)
07:36:08 Join mendel_munkis_ [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net)
07:38:46 Quit mendel_munkis (Ping timeout: 260 seconds)
07:48:34 Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net)
07:51:34 Quit mendel_munkis_ (Ping timeout: 246 seconds)
07:54:30 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
07:55:31 Quit J_Darnley (Ping timeout: 265 seconds)
07:57:59 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net)
08:00
08:24:38***Saving seen data "./dancer.seen"
08:25:32 Quit __Bilgus_ (Remote host closed the connection)
08:30:43 Join __Bilgus_ [0] (41ba23be@65.186.35.190)
09:00
09:02:51 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
09:04:05 Quit jdarnley (Ping timeout: 240 seconds)
09:16:04 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
09:17:39 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
09:19:20 Quit J_Darnley (Ping timeout: 256 seconds)
09:27:25 Quit sakax (Remote host closed the connection)
09:33:58 Quit mendel_munkis (Remote host closed the connection)
09:36:59 Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net)
09:43:06 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net)
09:56:10__Bilgus_mendel_munkis did you find the do_setting and do_menu code for displaying the settings?
09:56:51mendel_munkisyes. thanks now I just need to test before I put it up on gerrit.
09:57:12mendel_munkis(I managed to freeze my fuzeplus so I have to wait for the battery to drain)
10:00
10:00:17__Bilgus_I've found several ways to do that to the Fuze+
10:00:55mendel_munkisMy new favorite is opening a plugin while battery_bench is running.
10:00:58__Bilgus_freaked me out the first time I've also corrupted the install so bad I had to recover it
10:01:32mendel_munkisand unlike most of the other sansas holding power for a minute wont reset the chip
10:01:35__Bilgus_I think battery bench might be a TSR as well does it not handle it?
10:02:07__Bilgus_Ive locked up the clip+ that bad before too
10:02:28mendel_munkisusually running a plugin during battery bench will pop it up asking if you want to exit. if you do it will load the plugin that you had selected.
10:02:49__Bilgus_yeah thats the TSR handler
10:02:54mendel_munkisI tried running a lua plugin erlier today selected close battery_bench and then nada.
10:03:05__Bilgus_that uses a lot of ram though
10:03:16__Bilgus_I bet the TSR stack isn't big enough
10:03:41__Bilgus_well the thread it calls back into
10:04:43speachyyeah, I've been running into that with my attempts to throw up a prompt on usb insertion
10:05:11__Bilgus_tahts the same reason you get a playlist control file error too I think
10:05:17__Bilgus_thats*
10:10:32__Bilgus_the stack in battery bench is static
10:11:08__Bilgus_I used the rest of the plugin buffer in that VoiceTSR plugin
10:11:37__Bilgus_mendel would you be willing to try again with a patch once your fuze is back up
10:11:56__Bilgus_like maybe don't charge it fully in case it BSODs again
10:12:09mendel_munkissure. however I first need to test a patch of my own.
10:12:26mendel_munkisalso I am not sure I can reproduce it right now.
10:12:31__Bilgus_I'm just going to put it on gerrit so at your leisure
10:24:41***Saving seen data "./dancer.seen"
11:00
11:15:23__Bilgus_I wonder how hard it would be to make the USB screen a plugin
11:51:16__Bilgus_mendel_munkis #g2625
11:51:29__Bilgus_ g#2625
11:51:31fs-bluebotGerrit review #2625 at http://gerrit.rockbox.org/r/2625 : Battery_Bench use plugin buffer for thread stack, stop scrolling by William Wilgus
11:51:57__Bilgus_it also stops the scrolling message after you choose to continue the battery bench
11:52:31__Bilgus_that was kinda annoying, I've tested it on the ClipZip and works fine I could probably just push it
12:00
12:09:02 Quit livvy (Remote host closed the connection)
12:09:16 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
12:24:45***Saving seen data "./dancer.seen"
12:28:50 Quit koniu (Remote host closed the connection)
12:29:41 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
12:39:34pamaurymendel_munkis: why did you want to detect complete battery loss?
12:43:32pamauryI think one possibility (which is essentially what the OF uses to prevent time rollback) is use a persistent register that stores the boot time. If the battery is removed or empty, the SECONDS counter will be less than this and hence you can detect that.
12:50:37 Join MrZeus [0] (~MrZeus@4e6942be.skybroadband.com)
13:00
13:25:37mendel_munkispamaury: because there are some registers which need to be set only after a full power loss.
13:26:18mendel_munkismy solution is very similar to the one you mentioned
13:42:12 Quit pamaury (Ping timeout: 256 seconds)
13:47:13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:58:07mendel_munkisI take it theres no way to force poweroff a fuse+ besides removing the battery?
14:00
14:05:01 Quit pamaury (Ping timeout: 264 seconds)
14:10:51 Join mixfix41 [0] (~hoodfame@unaffiliated/mixfix41)
14:22:59speachy__Bilgus_: 2625 looks sane.
14:24:47***Saving seen data "./dancer.seen"
14:45:01 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
14:45:49pamaurymendel_munkis: depends what you meant to power off. You can power off programmatically sure, it's not going to reset the analog registers like the RTC though
15:00
15:12:38 Quit jdarnley (Read error: Connection reset by peer)
15:16:06fs-bluebotBuild Server message: New build round started. Revision da0dbc5, 280 builds, 11 clients.
15:16:48 Quit pamaury (Ping timeout: 265 seconds)
15:29:24fs-bluebotBuild Server message: Build round completed after 798 seconds.
15:29:26fs-bluebotBuild Server message: Revision da0dbc5 result: All green
15:37:34mendel_munkisno I just meant power down the chip.
15:38:14 Quit pixelma (Quit: .)
15:38:14 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
15:38:21mendel_munkis(while it's not responding)
15:41:11 Join amiconn [0] (jens@rockbox/developer/amiconn)
15:41:11 Join pixelma [0] (marianne@rockbox/staff/pixelma)
15:45:08 Quit fauweh (Quit: )
15:50:09 Join fauweh [0] (~root@ithaqua.unzane.com)
16:00
16:12:47 Quit fauweh (Quit: )
16:14:05 Join fauweh [0] (~root@ithaqua.unzane.com)
16:24:49***Saving seen data "./dancer.seen"
16:35:35 Quit MrZeus (Quit: Leaving)
16:35:51 Join MrZeus [0] (~MrZeus@4e6942be.skybroadband.com)
16:36:29 Quit MrZeus (Read error: Connection reset by peer)
16:45:45 Join MrZeus [0] (~MrZeus@4e6942be.skybroadband.com)
17:00
17:06:35 Quit lebellium (Quit: Leaving)
18:00
18:24:52***Saving seen data "./dancer.seen"
18:28:29 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
18:28:44pamaurymendel_munkis: on the fuze+, holding power for 10 seconds will always power down
19:00
19:00:10 Quit koniu (Remote host closed the connection)
19:00:35 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
19:03:25 Quit pamaury (Ping timeout: 240 seconds)
19:31:38 Quit MrZeus (Read error: Connection reset by peer)
19:37:07 Join MrZeus [0] (~MrZeus@4e6942be.skybroadband.com)
19:38:27 Join JdGordon [0] (~jonno@119-18-24-143.771218.mel.nbn.aussiebb.net)
19:54:44 Quit ac_laptop (Quit: WeeChat 2.8)
19:57:32 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:59:15 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
20:00
20:02:01 Quit MrZeus (Ping timeout: 246 seconds)
20:24:55***Saving seen data "./dancer.seen"
20:28:10 Quit ac_laptop (Ping timeout: 256 seconds)
20:50:08 Part chrisb
21:00
21:19:30 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
21:41:42 Quit ZincAlloy (Quit: Leaving.)
22:00
22:24:58***Saving seen data "./dancer.seen"
22:30:58 Quit benedikt93_ (Ping timeout: 256 seconds)
22:31:33 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93)
23:00
23:28:18 Join flab [0] (~beard@flab.tech)
23:28:48 Join bzed_ [0] (~bzed@shell.bzed.at)
23:28:49 Quit bzed (Read error: Connection reset by peer)
23:28:53 Nick bzed_ is now known as bzed (~bzed@shell.bzed.at)
23:29:01 Quit flabrus (Ping timeout: 264 seconds)
23:34:32 Quit TheSeven (Ping timeout: 260 seconds)
23:34:55 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23:44:18 Quit ac_laptop (Ping timeout: 260 seconds)
23:54:31fs-bluebotBuild Server message: New build round started. Revision a74517a, 280 builds, 10 clients.
23:57:52 Quit funman (Ping timeout: 260 seconds)
23:57:59 Join funman [0] (~fun@chui-pas.net)

Previous day | Next day