[00:11:21] iorek7: how long was it building the database before it started acting up? [00:11:56] I think rockbox doesn't update the battery reading while the disk is spinning, that might have fooled you [00:13:13] I guess it will take like half an hour for it to deplete the battery while building the database [00:13:58] Yeah, actually, it was probably getting close to that anyway. [00:14:49] that's probably a UX issue that rockbox should fix [00:20:43] Any suggestions for how to fix this? I don't even think I can follow the EmCORE installation procedures at this point: it just keeps power cycling every second or so when it's plugged into my PC; holding menu and select has no effect. [00:33:37] just let it charge [00:34:12] if it goes into that boot loop even with a strong USB power source, disconnect it, lock the hold switch, connect it, and let it sit for a few minutes [00:34:24] then power it up again, and it should be able to get into the boot menu again [00:34:49] it just doesn't have sufficient power right now to spin up the disk, causing it to crash [00:36:15] Cool. I'll try that. Cheers for the help. I have to sign off now, but I'll be back tomorrow. [00:36:31] *** Parts: iorek7 (522d280f@gateway/web/freenode/ip.82.45.40.15) () [00:37:56] (this is another UX issue, this time with the kernel, which should avoid this situation) [00:38:36] if the battery voltage is below 3.4V or so, refuse to spin up the disk, block every thread that attempts to do so, and possibly print a warning message to the console [00:38:53] the way it's constructed right now we can't easily delegate this to the boot menu app :/ [00:39:11] kernel = emCORE? [00:39:14] yes [00:39:54] if we want userspace to be able to take care of this, we need to defer disk spinup until the first attempt to access the disk is being made [00:40:18] why does the kernel need to access the disk? BBT? [00:40:26] mounting FS [00:40:33] (and discovering what kind of disk it has in the first place) [00:40:46] the whole storage_init thing would need to be deferred [00:40:50] ah, i see [00:41:03] i.e. that should be done on the first call to any storage-related API [00:42:01] however some FS-level functions would need an additional guard that causes storage init to happen before they try to use any FAT-related data, even before the first actual storage access [00:42:11] it's certainly doable, just a bit of rework [00:42:41] letting userspace handle it seems a bit cleaner from the UX point of view (the boot menu could display an "empty battery" screen) [00:43:23] just like apple's [00:43:26] however letting the kernel handle it is easier and IMO cleaner from a technical point of view (however the kernel needs to interfere with whatever has control of the LCD) [00:44:11] well, it could freeze all user threads and draw on the LCD [00:44:19] nothing should get in its way [00:44:27] it can't properly restore the LCD state afterwards, that's the problem [00:44:37] i see [00:44:59] can we read the current framebuffer from the lcd controller? [00:45:07] we don't have a kernel-level framebuffer for non-console LCD access right now [00:45:19] keeping a shadow copy of the LCD contents seems like a bit of a waste [00:45:31] (and would also cost performance in the LCD driver) [00:45:44] displaylcd maxes out the CPU on the classic [00:45:53] (the LCD is faster than the dithering code) [00:48:36] hm, the current infrastructure doesn't easily allow for a storage driver to initialize later [00:48:52] if ata_init fails, it ends up not registering the storage device at all [00:49:01] i.e. it would need to fake success, just fail requests [00:49:23] we also can't cleanly tell storage devices that need significant power apart from other ones [00:49:30] (i.e. this would need additional ifdefs) [00:49:54] although blocking flash *writes* on a nano in a low battery condition wouldn't be a bad idea either [00:52:50] storage_init, disk_init_subsystem, disk_init and disk_mount_all would need to be deferred [00:53:18] we should probably ignore this happening at runtime, just check for it during init [00:53:30] and maybe just fail everything related to storage if the battery is low [00:54:37] hm, do we need a fancy UI for a low battery boot condition? [00:55:03] or can we just keep storageinitthread waiting for "power good" before doing anything, printing a console message if the check fails? [00:55:18] basically blocking boot that way until power is good [01:07:01] users would prefer a fancy battery image, like OF [01:08:05] since we're already using the Crystal icons set... http://www.iconarchive.com/show/crystal-clear-icons-by-everaldo/App-battery-icon.html [01:08:25] i'm looking for a more suitable one [01:10:00] http://www.iconarchive.com/show/crystal-clear-icons-by-everaldo/App-laptop-battery-icon.html [01:10:46] this one looks more suitable, with the bars on the right displaying the current charge (only the lowest bar in our case) [01:15:47] well, we'd have to store the image in the boot flash for it to work, so we should keep it down to a few kB [01:16:06] and it would be much easier to implement a kernel-level text based solution [06:08:32] *** Joins: steffengy (~quassel@p57B485D0.dip0.t-ipconnect.de) [06:11:18] *** Quits: steffengy1 (~quassel@p57B49531.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) [06:30:17] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 264 seconds) [06:31:18] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:15:16] *** Quits: krnlyng (~liar@83.175.90.24) (*.net *.split) [08:15:16] *** Quits: steffengy (~quassel@p57B485D0.dip0.t-ipconnect.de) (*.net *.split) [08:26:42] *** Joins: steffengy (~quassel@p57B485D0.dip0.t-ipconnect.de) [08:26:42] *** Joins: krnlyng (~liar@83.175.90.24) [08:28:32] *** Quits: krnlyng (~liar@83.175.90.24) (*.net *.split) [08:28:32] *** Quits: steffengy (~quassel@p57B485D0.dip0.t-ipconnect.de) (*.net *.split) [08:33:25] *** Joins: steffengy (~quassel@p57B485D0.dip0.t-ipconnect.de) [08:33:25] *** Joins: krnlyng (~liar@83.175.90.24) [13:57:17] *** Joins: iorek7 (522d280f@gateway/web/freenode/ip.82.45.40.15) [13:58:47] Just wanted to say thanks to copper and TheSeven for their help yesterday; the database gen did indeed drain my battery. It's up and running now. Cheers! [14:01:28] *** Quits: iorek7 (522d280f@gateway/web/freenode/ip.82.45.40.15) (Client Quit)