--- Log for 02.08.120 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 4 days and 9 hours ago 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.25 # Build Server message: New build round started. Revision affaa94, 280 builds, 10 clients. 00.41.00 # Build Server message: Build round completed after 876 seconds. 00.41.02 # Build 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.04.38 Quit Huntereb (Ping timeout: 256 seconds) 01.26.55 Quit ac_laptop (Ping timeout: 246 seconds) 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.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.48 Nick mendel_munkis_ is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net) 05.02.24 # pamaury: 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.43 # mendel_munkis: you mean hardware registers? 05.13.49 # yes. 05.14.47 # well 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.37 # to 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.17 # I 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.13 # sorry AHB so APH 05.21.45 # not I think it's completely okay, one read every second is nothing 05.21.56 # I need to leave but I stay online and read things later 05.25.03 # if you put it on gerrit I'll have a look. I guess this is for the alarm? Isn't the IRQ working? 05.26.02 # no this a reworking of the loss of power fix. 05.27.05 # why is that needed btw? There is a brownout IRQ/FIQ for loss of power 05.29.55 # My 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.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.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.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.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.51 # yes. thanks now I just need to test before I put it up on gerrit. 09.57.12 # (I managed to freeze my fuzeplus so I have to wait for the battery to drain) 10.00.17 # <__Bilgus_> I've found several ways to do that to the Fuze+ 10.00.55 # My 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.32 # and 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.28 # usually 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.54 # I 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.43 # yeah, 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.09 # sure. however I first need to test a patch of my own. 10.12.26 # also 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.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.31 # Gerrit 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.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.34 # mendel_munkis: why did you want to detect complete battery loss? 12.43.32 # I 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.25.37 # pamaury: because there are some registers which need to be set only after a full power loss. 13.26.18 # my 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.07 # I take it theres no way to force poweroff a fuse+ besides removing the battery? 14.05.01 Quit pamaury (Ping timeout: 264 seconds) 14.10.51 Join mixfix41 [0] (~hoodfame@unaffiliated/mixfix41) 14.22.59 # __Bilgus_: 2625 looks sane. 14.24.47 *** Saving seen data "./dancer.seen" 14.45.01 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 14.45.49 # mendel_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.12.38 Quit jdarnley (Read error: Connection reset by peer) 15.16.06 # Build Server message: New build round started. Revision da0dbc5, 280 builds, 11 clients. 15.16.48 Quit pamaury (Ping timeout: 265 seconds) 15.29.24 # Build Server message: Build round completed after 798 seconds. 15.29.26 # Build Server message: Revision da0dbc5 result: All green 15.37.34 # no 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.21 # (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.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.06.35 Quit lebellium (Quit: Leaving) 18.24.52 *** Saving seen data "./dancer.seen" 18.28.29 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 18.28.44 # mendel_munkis: on the fuze+, holding power for 10 seconds will always power down 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.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.19.30 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 21.41.42 Quit ZincAlloy (Quit: Leaving.) 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.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.31 # Build 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)