| 00:02:44 | karinka | im currently on bl version 5 |
| 00:08:43 | karinka | and i dont know if i have the eu or the us version' |
| 00:09:51 | *** | Saving seen data "./dancer.seen" |
| 00:10:36 | karinka | okay v5 is the current version? |
| 00:12:49 | karinka | just gonna leave it plugged in for a bit |
| 00:13:10 | | Quit karinka (Quit: karinka) |
| 00:13:34 | | Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 00:26:46 | karinka | updating to 3.15 stable with rockbox utility |
| 00:26:51 | karinka | cause lazy |
| 00:28:32 | karinka | battery is reporting above 4v |
| 00:33:20 | karinka | ill keep an eye out for issues with the H2 |
| 00:33:27 | karinka | just gonna take a bit |
| 00:33:42 | karinka | its taken days for me to understand rockbox |
| 00:33:46 | karinka | in general |
| 00:59:59 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 01:00 |
| 01:28:05 | Strife89 | Yeah v5 is the last known stable bootloader for the H3x0, sorry |
| 01:32:48 | karinka | ah okay, good to know its stable at least |
| 01:34:48 | | Quit Stanley00 (Remote host closed the connection) |
| 01:37:17 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 01:45:35 | | Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00) |
| 01:48:56 | | Quit Stanley00 (Ping timeout: 240 seconds) |
| 01:50:15 | | Quit Stanley|00 (Remote host closed the connection) |
| 01:50:50 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 01:59:44 | | Quit Stanley00 (Remote host closed the connection) |
| 02:00 |
| 02:02:10 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 02:09:52 | *** | Saving seen data "./dancer.seen" |
| 02:25:24 | | Join petur [0] (~petur@199.59.5.11) |
| 02:25:24 | | Quit petur (Changing host) |
| 02:25:24 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 02:27:13 | | Quit dys (Ping timeout: 264 seconds) |
| 02:33:04 | | Join dys [0] (~dys@aurora.ydns.eu) |
| 02:54:20 | | Part karinka ("Good Bye") |
| 02:54:33 | | Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 02:54:42 | | Nick karinka is now known as borkitall (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 02:55:30 | borkitall | just changed my nick, just letting yall know |
| 02:55:34 | borkitall | from karinka |
| 02:55:48 | borkitall | ah its there lul im not used to irc |
| 04:00 |
| 04:05:12 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 04:09:54 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:09:56 | *** | No seen item changed, no save performed. |
| 06:35:10 | | Quit Misanthropos (Read error: Connection reset by peer) |
| 06:36:17 | braewoods | borkitall: Strife89 is right and wrong. it's still the one rbutil will be using for first installs but a newer one is being prepared. you can install it now if you want via iriver_flash from a development build. |
| 06:36:31 | braewoods | main problem is rbutil hasn't been updated yet so we can't fully release it yet. |
| 06:39:03 | braewoods | speachy: something up with RB website? everything times out. |
| 06:39:57 | braewoods | yet gerrit still works over git |
| 06:40:07 | * | braewoods boggles. |
| 06:45:27 | | Join Misanthropos [0] (~Misanthro@91.240.65.140) |
| 06:48:26 | | Quit Stanley00 () |
| 06:51:08 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 06:52:06 | speachy | braewoods: wokik engine wedged the web server. thanks for letting me know. |
| 06:52:09 | speachy | wiki |
| 06:53:52 | braewoods | speachy: i assume we'll be releasing the new bootloaders whenever rbutil is ready for an update? |
| 06:54:29 | braewoods | since it has checksums that are compiled in |
| 06:54:46 | speachy | yeah... though I'd really prefer that this stuff get un-compiled-in so this doesn't happen in the future |
| 06:55:07 | speachy | that shouldn't be hardcoded |
| 06:55:17 | braewoods | possible but rbutil would need to be expanded to take them from the website then. |
| 06:55:30 | braewoods | the only part that can be hard-coded is the checksum for the OF |
| 06:55:44 | braewoods | that's pretty much static |
| 06:56:17 | braewoods | hm |
| 06:56:32 | braewoods | bluebrother^: any ideas how this could be done? |
| 06:56:57 | braewoods | bluebrother^: i think we want to move the iriver h100/h300 patching to use checksums from a file instead of a hard-coded table |
| 06:57:39 | braewoods | the existing one was taken from fwpatcher |
| 06:57:45 | braewoods | that should probably stay but |
| 06:57:54 | braewoods | rbutil needs to be more flexible |
| 06:58:36 | braewoods | speachy: i think one of my projects after MTP is going to be seeing if i can add support for some missing chips |
| 06:59:02 | braewoods | it would be interesting if we could have composite output on a few targets that support it |
| 06:59:19 | braewoods | the chip in the hdd6330 is documented so |
| 06:59:31 | braewoods | should be possible to write a driver for NTSC/PAL output |
| 07:00 |
| 07:10:20 | speachy | looks like it went down about ~0130. so everything www was offline for ~5h |
| 07:28:52 | | Quit ArsenArsen (Quit: bye) |
| 07:29:13 | | Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen) |
| 07:31:30 | braewoods | speachy: what defines the largest amount of data that can be sent to a usb core driver at once? the hardware chip's buffer size? |
| 07:32:22 | braewoods | just trying to a see if it's possible for length to ever be too large to process all at once before returning |
| 07:36:08 | gevaerts | What do you mean by "sent to a usb core driver at once"? |
| 07:36:31 | braewoods | the transfer_complete callback |
| 07:36:52 | braewoods | how large can length be at one time? |
| 07:38:01 | * | gevaerts used to know this without having to check... |
| 07:38:28 | braewoods | mostly curious so i can see how to structure MTP support |
| 07:38:55 | braewoods | whether i need to do multiple passes through the buffer processing stuff |
| 07:39:02 | braewoods | or whether one sufficiently large one will do |
| 07:42:36 | gevaerts | The transfer_complete will have the length (or maximally that, not sure if shorter is possible) set with usb_drv_recv() or usb_drv_send_nonblocking(). You'll have to have that size buffer available of course. That doesn't mean that that's the same size advertised as the block size to the host (speaking in mass storage terms now...), you can do one block in several transfers |
| 07:43:35 | braewoods | gevaerts: or i can just make multiple passes until all the data has been received |
| 07:43:42 | gevaerts | Yes |
| 07:43:56 | braewoods | well that helps i guess |
| 07:44:06 | braewoods | i'm wanting to layer MTP into multiple layers |
| 07:44:18 | braewoods | the IO layer (usb code) |
| 07:44:25 | braewoods | the MTP parsing layer |
| 07:44:41 | braewoods | and the MTP higher level stuff for RB to hook into to expose stuff over MTP |
| 07:44:49 | gevaerts | Unless I'm seriously misremembering, that's what mass storage does (at least for some chips) |
| 07:45:47 | braewoods | gevaerts: ok. |
| 07:45:53 | braewoods | gevaerts: thanks. |
| 07:46:16 | braewoods | i'm just trying to separate MTP from our usb stack so we can still use the code even on other targets where we use a different usb stack |
| 07:46:23 | braewoods | it seemed to be the best ROI |
| 07:47:35 | gevaerts | The ARC USB core (PP502x, imx31, maybe more?) can handle more than 64K at a time (not sure how much exactly) so that one is easy for mass storage (all OSes do 64K), but the AMS driver can only do 63K (the chip can do more, but that's more complex to set up and we could get away with not doing that). Other chips I have no idea |
| 07:47:51 | braewoods | ok. sure. |
| 07:48:02 | braewoods | i'll do multiple passes since the buffer may be smaller. |
| 07:48:09 | braewoods | seems to be no way around it |
| 07:48:28 | speachy | yeah, generally for bulk transfers you set up a DMA transfer across the entire buffer, and the controller will send out chunks and only tell the system when it's all done. |
| 07:49:29 | speachy | braewoods: don't go overboard with abstraction layers. our USB stack and driver interface is bespoke. |
| 07:50:10 | speachy | and there is little room for reuse at anything other than the highest layers. |
| 07:50:20 | speachy | even our Filesystem/etc interface is unique. |
| 07:51:07 | speachy | abstracting all of those "external" APIs is all well and good, but without a second non-rockbox user, it's just going to be tied to how our stack/etc works anyway. |
| 07:52:05 | speachy | there's arguably some advantage for hosted targets to re-use the MTP stuff, but on those there are already mature native solutions. |
| 07:52:13 | braewoods | speachy: ok... |
| 07:52:24 | speachy | this is one of those "premature optimization" things. |
| 07:52:42 | braewoods | speachy: i was wanting to allow for apps to provide MTP services too |
| 07:52:44 | braewoods | maye |
| 07:52:46 | braewoods | maybe |
| 07:53:01 | braewoods | either way, some abstraction for "storage" providers seemed prudent |
| 07:53:19 | speachy | rockbox already provides an abstraction at that layer. code to that API. |
| 07:53:45 | speachy | and if this ever gets reused outside of rockbox, then at that point a proper storage API can be provided. |
| 07:53:51 | braewoods | yea but i still need to write code to allow external code to interface with it? |
| 07:54:27 | braewoods | i was thinking of separating the fulfillment of services to other codes so i could manage it and extend it later |
| 07:54:55 | braewoods | e.g., the core handles processing of MTP requests and dispatches them to the appropriate provider |
| 07:55:00 | speachy | my naive understanding is that MTP's external storage needs are pretty straightforward, essentially "enumerate contents of path X", "read file [ +offset/len]", "write file [+offset/len]" ? |
| 07:55:18 | braewoods | oh i'm just speaking internally |
| 07:55:28 | braewoods | like one provider might be based on... |
| 07:55:35 | braewoods | that cache for files? |
| 07:56:32 | braewoods | i just thought it'd be interesting if external stuff could provide their own implementations of MTP storage providers |
| 07:56:45 | speachy | "External stuff"? |
| 07:56:46 | braewoods | one would use dircache and serve real files |
| 07:56:52 | speachy | ah, I see. |
| 07:56:59 | braewoods | external modules |
| 07:57:07 | braewoods | within RB |
| 07:57:13 | braewoods | external to the MTP core code |
| 07:57:21 | gevaerts | You mean like the debug thing you mentioned? |
| 07:57:22 | braewoods | so it isn't limited to just using the filesystem resources |
| 07:57:22 | speachy | no.. the right place for that is within the FS layer. it already exports "fake" directories, for example |
| 07:57:39 | braewoods | speachy: example? |
| 07:57:51 | braewoods | gevaerts: yea, possibly. |
| 07:57:59 | braewoods | it just sounded cool at first |
| 07:58:21 | braewoods | i just trying to think of how to handle the MTP implementation |
| 07:58:23 | braewoods | i am* |
| 07:58:31 | speachy | eg when there's more htan one storage device, at the top level there are "symlinks" exposed that map to the different storage devices, but the result appears to be a single contiguous filesystem. |
| 07:58:45 | braewoods | so like unix |
| 07:59:15 | braewoods | speachy: does that show up in dircache? |
| 07:59:20 | braewoods | i assume no? |
| 07:59:34 | braewoods | though i guess mtp should stick to just serving real file resourcs |
| 07:59:50 | speachy | they're returned as directory entries, so yeah, they'll end up exposed to whatever that walks teh filesystem |
| 08:00 |
| 08:00:16 | braewoods | oh, i see. |
| 08:00:25 | braewoods | so i could add that by extending the FS module. |
| 08:00:29 | speachy | yep. |
| 08:00:29 | braewoods | ok, ok. |
| 08:01:00 | braewoods | just if we're going to have MTP i need to know how best to implement it |
| 08:01:10 | braewoods | there's a lot i don't know about RB |
| 08:01:26 | speachy | (and since RB's "special filenames" stuff is in the VFS layer, it applies no matter what the underlying storage backend is −− including native POSIX) |
| 08:01:28 | braewoods | i thought i needed abstractions like this but i guess i don't |
| 08:01:53 | braewoods | speachy: we may be able to use umtp-responder for the hosted targets |
| 08:02:05 | braewoods | but it's not suitable for RB native targets. it's too tied to POSIX. |
| 08:02:07 | braewoods | and Linux |
| 08:03:09 | braewoods | it's a daemon that uses usb-gadget API to provide an MTP responder process. |
| 08:03:23 | braewoods | C code |
| 08:03:35 | braewoods | and also GPLv3 |
| 08:03:47 | speachy | my advice would be to ignore the external APIs entirely for now. Write the pure MTP code that uses stubs. usb_receive(), usb_send() on one side, and the basic filesytem actions on the other. model the FS stuff on posix: opendir/readdir/open/read/write/close/unlink/etc |
| 08:04:25 | speachy | that can be easily tested on a PC to get the basic kinks out, and from there it can be shoehorned into rockbox's native APIs. |
| 08:04:56 | speachy | external API needs shouldn't require much more than that, actually. |
| 08:06:00 | speachy | I saw umtp-responder; my worry about it is that if it needs something that isn't present on our sourceless vendor kernels. |
| 08:07:19 | speachy | (And honestly it might make more sense to start with umtp-responder, and port that to rockbox's API instead) |
| 08:07:39 | speachy | (but it would be nice to be able to use it for both native and hosted targets!) |
| 08:09:23 | speachy | compiled on x86_64 the binary is just shy of 100K. |
| 08:09:46 | speachy | no external libraries other than pthread. |
| 08:10:00 | *** | Saving seen data "./dancer.seen" |
| 08:15:50 | speachy | scrap everyting that interfaces with the OS, keep only files starting with mtp_ |
| 08:22:03 | braewoods | speachy: maybe... just felt i would need to do a lot of gutting and refactoring for that to really work. |
| 08:22:09 | braewoods | i looked through the source already. |
| 08:22:31 | speachy | perhaps.. but is it more work than starting from scratch and having to re-implement 85% of what's there? |
| 08:22:36 | | Quit Moarc (Ping timeout: 265 seconds) |
| 08:23:07 | braewoods | no idea. |
| 08:23:21 | braewoods | i was planning to use it as a reference if nothing else. |
| 08:23:28 | braewoods | it's easier to follow than the C++ stuff. |
| 08:25:23 | braewoods | just i've noticed people usually end up reinventing the wheel for MTP responders because of how much they are tied to their host implementation. |
| 08:25:37 | braewoods | i've not seen any generic libraries so to speak except for the client side |
| 08:25:38 | speachy | would also be useful to take umtp-responder and profile its memory use. should give us a ballpark estimation of the real-world memory usage requirements. |
| 08:26:27 | speachy | on the client side it's a lot simpler, yeah. |
| 08:26:44 | speachy | (or rather the OS-interface layer is a lot smaller) |
| 08:27:08 | braewoods | e.g., every smart phone OS has their own solution |
| 08:27:11 | braewoods | among other things |
| 08:27:16 | braewoods | so |
| 08:27:23 | braewoods | it wouldn't be unusual for RB to do the same |
| 08:27:29 | braewoods | in this situation |
| 08:27:36 | speachy | most of those things were written around the same time. |
| 08:27:45 | speachy | ie when there wasn't an option for reuse |
| 08:27:51 | speachy | and started out quasi-proprietary |
| 08:27:56 | braewoods | I see. |
| 08:28:29 | speachy | and once you had something that worked, why invest the effort into switching to something else? |
| 08:29:31 | speachy | (also, incompatible licensing is another typical reason for reinventing the wheel. see: android everything) |
| 08:30:44 | speachy | I mean, we can't use the otherwise-awesome bluekitchen/btstack for that reason |
| 08:46:02 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 09:00 |
| 09:18:16 | speachy | huh, appears that my patch to de-mangle the ATA timing for SSDs on the iPods seems to work. |
| 09:22:26 | braewoods | speachy: IOW, the iflash issue? |
| 09:22:44 | speachy | more specifically, the iFlash mSATA issue |
| 09:22:55 | speachy | the iFlash SD stuff has long since been solved, I think. |
| 09:26:19 | _bilgus | oh? |
| 09:26:52 | speachy | the power management fix I did some point over the summer. |
| 09:28:01 | _bilgus | nice I'll update that stickied post |
| 09:29:28 | speachy | yeah, they _must_ use a recent nightly or dev build. |
| 09:30:28 | speachy | ok, anyone have a relatively trivial commit ready? |
| 09:31:11 | speachy | I've updated the build hooks/etc to use 10-char commit IDs instead of truncating to 7, and I need to make sure nothing breaks.. |
| 09:35:45 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:54:14 | speachy | _bilgus: you should also edit the first post in the topic too.. |
| 09:55:23 | fs-bluebot | Build Server message: New build round started. Revision 6d62a7a1bd, 293 builds, 9 clients. |
| 09:55:40 | speachy | ok, let's see what breaks on the www side when this is done. |
| 10:00 |
| 10:10:02 | *** | Saving seen data "./dancer.seen" |
| 10:10:42 | | Quit mutax (Read error: Connection reset by peer) |
| 10:11:56 | | Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) |
| 10:13:27 | fs-bluebot | Build Server message: Build round completed after 1083 seconds. |
| 10:13:29 | fs-bluebot | Build Server message: Revision 6d62a7a1bd result: All green |
| 10:14:03 | speachy | sweeet, it's sane. |
| 10:14:56 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 10:15:15 | | Quit Rower (Read error: No route to host) |
| 10:16:04 | fs-bluebot | Build Server message: New build round started. Revision b7b0c7c648, 293 builds, 9 clients. |
| 10:16:17 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 10:29:19 | fs-bluebot | Build Server message: Build round completed after 794 seconds. |
| 10:29:21 | fs-bluebot | Build Server message: Revision b7b0c7c648 result: All green |
| 10:36:08 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 10:36:38 | wodz | any progress with BT ui mockup? |
| 10:42:41 | wodz | will read response if any later |
| 10:42:45 | | Quit wodz (Quit: Leaving) |
| 10:45:48 | | Quit massiveH (Quit: Leaving) |
| 10:47:55 | mendelmunkis | why does the gigabeat have two button-target.h? (plus one for the gigabeat-s) |
| 10:48:24 | braewoods | speachy: kinda weird. the players that used the f-flex interface have 0 adapters available that i can tell. |
| 10:48:39 | braewoods | but since the pin-out is documented |
| 10:48:47 | braewoods | i guess someone could design one. |
| 10:48:53 | braewoods | but how would you get it produced? |
| 10:50:41 | braewoods | the ribbon cable is soldered to the original drive so you can't just reuse that |
| 10:51:18 | braewoods | guess i'll ask some hardware guys that have designed stuff before |
| 11:00 |
| 11:08:10 | braewoods | hm |
| 11:08:23 | braewoods | one idea is if it's possible to find a generic ribbon cable that fits |
| 11:08:35 | braewoods | then try to connect it to an adapter of sorts |
| 11:08:41 | braewoods | but would take up too much space i'm sure |
| 11:27:09 | _bilgus | s peachy done. |
| 11:28:16 | _bilgus | wodz no I'll try to have it done by this weekend I have my multiline stuff worked out I still need to set up the dynamic part I'll try to do that tonight and get it up on gerrit |
| 11:29:33 | speachy | I still need to figure out WTF is causing that bluetooth code to segfault on the other Hiby-based players. |
| 11:55:27 | | Join Skyrider [0] (~Skyrider@v220200567215119438.goodsrv.de) |
| 12:00 |
| 12:05:47 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 12:08:19 | | Quit Rower (Ping timeout: 265 seconds) |
| 12:10:03 | *** | Saving seen data "./dancer.seen" |
| 12:10:17 | | Quit petur (Quit: Connection reset by beer) |
| 12:27:44 | speachy | huh. now it's working. |
| 12:28:11 | braewoods | heisenbugs! |
| 12:30:59 | speachy | wodz: can you write up what's needed to set things up on the ALSA side of things? sample config device strings? |
| 12:33:33 | fs-bluebot | Build Server message: New build round started. Revision 497618e51e, 293 builds, 9 clients. |
| 12:44:09 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 12:45:48 | | Quit Rower- (Ping timeout: 260 seconds) |
| 12:55:53 | fs-bluebot | Build Server message: Build round completed after 1340 seconds. |
| 12:55:55 | fs-bluebot | Build Server message: Revision 497618e51e result: All green |
| 13:00 |
| 13:00:51 | _bilgus | wodz g#3044 |
| 13:00:54 | fs-bluebot | Gerrit review #3044 at https://gerrit.rockbox.org/r/c/rockbox/+/3044 : Bluetooth Menu WIP by William Wilgus |
| 13:01:41 | _bilgus | basically the menus are laid out they are all dummies atm the trusted menu isn't built yet but its similar to the scan menu |
| 13:02:03 | _bilgus | I think I want drop down menus and context menus but its just context menu atm |
| 13:03:30 | _bilgus | there are still a few quirks to work out and some code cleanup in order but i'll get to it soon enough critiques welcome or ideas |
| 13:09:43 | braewoods | _bilgus: serious question. you know the RB system that manages to output to 2 screens? right now that's just remote LCD and regular LCD. |
| 13:10:00 | braewoods | _bilgus: how hard would it be to extend that concept with another type of second video output? |
| 13:10:49 | braewoods | _bilgus: some of the players i've noticed have a composite video output. |
| 13:11:09 | braewoods | so i was pondering the possibility of adding support as a secondary video output of the main rockbox screen |
| 13:14:08 | _bilgus | it really wouldn't be hard to add it as another screen but there is nothing that uses it in the code |
| 13:14:37 | _bilgus | better option would be a screen mirror but that incurs a speed penalty |
| 13:15:29 | _bilgus | now a days I don't see it being high on a wish list for anyone but its your time do as you wish :) |
| 13:15:37 | braewoods | _bilgus: ok. noted. i'll look into it later. i think i could write a driver for it. |
| 13:16:04 | _bilgus | be easier as an either or make it main use remote |
| 13:16:28 | braewoods | honestly adding the OTG for h300 is a higher priority to me |
| 13:16:34 | braewoods | MTP even higher |
| 13:16:54 | braewoods | right now i'm trying to fix my H10 so i have something to test MTP on |
| 13:17:31 | braewoods | decisions, decisions, though. |
| 13:18:04 | braewoods | i am going to try something first though :) |
| 13:18:24 | braewoods | i want to see if increasing the buffer size for UMS mode will help with the slow write speeds at all |
| 13:18:45 | braewoods | i doubt it but it can't hurt to try increasing it for a special test build |
| 13:18:47 | bluebrother^ | braewoods: I have an idea how we could approach this. Need to give it some thought though. |
| 13:19:01 | bluebrother^ | wasn't an issue the last 10+ years. Nobody released new bootloaders :) |
| 13:19:02 | braewoods | bluebrother^: sure. take your time. i just updated the existing method. |
| 13:19:09 | braewoods | in git |
| 13:19:26 | braewoods | but it needs a new build to propagate. |
| 13:19:35 | braewoods | in either case that will be true |
| 13:19:50 | braewoods | bluebrother^: here's what i know. the only part you can hard-code is the hashes for the OF. |
| 13:19:51 | bluebrother^ | btw, I've been wondering if we should retire fwpatcher. |
| 13:20:04 | braewoods | i'm not a fan of it but i patched it up to work. |
| 13:20:06 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 13:20:23 | braewoods | though i can't see why it would be useful in this day and age. |
| 13:20:25 | bluebrother^ | well, usually you shouldn't use fwpatcher anymore since Rockbox Utility can do the work :) |
| 13:20:29 | braewoods | rbutil does the same thing. |
| 13:21:07 | bluebrother^ | exactly |
| 13:21:15 | braewoods | bluebrother^: so ideally we'd have hashes for the firmware images be hard-coded and the final checksums will be on the bootloader site. |
| 13:21:41 | braewoods | or |
| 13:21:47 | braewoods | they can both be pairs in a file |
| 13:21:50 | braewoods | hash:hash or so |
| 13:21:54 | bluebrother^ | we already have bootloaders/bootloader-info |
| 13:21:56 | braewoods | before:after |
| 13:22:22 | bluebrother^ | but I'd prefer to merge that with build-info, so we don't end up with that much different files. For the bootloader hashes they could simply come from a file in git. |
| 13:22:32 | bluebrother^ | and the scripting creating build-info would simply append that. |
| 13:23:16 | bluebrother^ | I'd also like to have hashes for all other bootloader as well, so we can check if the download was successful. Not terribly important, but since the bootloader is usually the critical part an additional check won't hurt. |
| 13:23:18 | braewoods | this is mainly an issue due to how we install the bootloaders on these units |
| 13:23:29 | speachy | there's already a 'bootloaders-info' file on d.r.o |
| 13:23:47 | bluebrother^ | speachy: right, but I'd prefer that to be part of build-info |
| 13:24:00 | braewoods | i don't care how we do it, just want to get these out to people. |
| 13:24:00 | bluebrother^ | is that file generated dynamically? We could have those hashes in git. |
| 13:24:08 | bluebrother^ | and simply cat them together |
| 13:24:19 | speachy | no idea how it's supposed to be auto-generated, and that file doesn't match the build-info syntax |
| 13:25:04 | bluebrother^ | braewoods: I'll think about what needs to get finished for a new Rockbox Utility release the weekend. I still have quite some stuff on my todo, but we could now create a 1.5.0, and once I did that bump to 1.6.0. |
| 13:25:09 | bluebrother^ | I'd change the format a bit. |
| 13:25:25 | braewoods | bluebrother^: do what you need to do. let me know if you need anything from me. |
| 13:25:35 | braewoods | just needs to be easier to release bootloaders. |
| 13:26:04 | braewoods | i mean, cutting the release will work fine this time i guess, but should we update the approach? |
| 13:26:37 | bluebrother^ | well, the question is how long Rockbox will continue to live :P |
| 13:26:48 | braewoods | it's lasted this long. |
| 13:27:05 | braewoods | may as well plan for it to last for another 10 years at least. |
| 13:27:26 | bluebrother^ | given that the bootloader haven't been changed in 10 years we could simply ignore the fact and keep things as-is. But since I'm trying to get more info from the download server we could as well tackle it. |
| 13:27:38 | speachy | rockbox will live as long as folks like us are crazy enough to keep it going. |
| 13:28:01 | braewoods | i've already got people clamoring for the updated bootloader. |
| 13:28:03 | braewoods | lol |
| 13:28:10 | bluebrother^ | true. But where will the world be in 10 years? And will there still be hardware? |
| 13:28:22 | bluebrother^ | anyway, just asking. I'm not against updating things. |
| 13:28:24 | braewoods | who really knows? |
| 13:28:38 | bluebrother^ | let's guess ... nobody? ;-) |
| 13:28:41 | braewoods | it may not matter but we'll be glad if it does end up helping us in the future. |
| 13:28:58 | bluebrother^ | indeed. And it could be a nice programming exercise ;-) |
| 13:29:47 | bluebrother^ | so right now Rockbox Utility has been updated for Qt5, new players have been added, and we can now build it again for all platforms. That's good enough for 1.5.0. |
| 13:29:53 | speachy | well, assuming we don't descent into a post-apolcalyptic wasteland, there will be hardware. heck, even if the world goes to hell and folks have to duel mask-wielding fanatics with tricked-out Pursuit Specials, they'll still want to have rockin' tunes over bluetooth. |
| 13:30:30 | bluebrother^ | not too much work to finish that up I've been working on. And the further improvement (especially when it comes to bootloader installation, so we finally get rid of that sudo problem) would justify 1.6.0. |
| 13:30:53 | bluebrother^ | speachy: true to that :) |
| 13:31:08 | braewoods | i'm also working on MTP support... it should be available for anything with functional OTG when i'm done. |
| 13:31:47 | * | bluebrother^ would really like to see USB Audio. Just because it would be kinda cool. |
| 13:32:12 | braewoods | as it stands RB would mainly be limited to being on the output end of it |
| 13:32:24 | speachy | a better question is if there will ever be any new native targets. |
| 13:32:25 | braewoods | probably doable though |
| 13:32:40 | braewoods | quite possible but we may have to design it ourselves |
| 13:33:01 | braewoods | that would probably make a good kickstarter project though |
| 13:33:13 | speachy | we barely have the resources to maintain the status-quo, new hardware is going to take a lot of work. |
| 13:33:20 | braewoods | indeed |
| 13:33:55 | braewoods | if we had kernel sources to one that ran Linux we could probably find a way to replace the kernel |
| 13:34:18 | braewoods | as an alternative |
| 13:34:29 | speachy | we kinda do on the fiio m3k, at least. I'd be willng to bet the Sony players have full kernel sources too. |
| 13:34:58 | braewoods | i may eventually feel up to doing porting work but i feel more inclined to fix up the loose ends someone else left behind |
| 13:35:15 | _bilgus | plenty of those |
| 13:35:21 | braewoods | indeed |
| 13:35:37 | braewoods | some are unlikely to be solved due to missing datasheets |
| 13:35:49 | braewoods | the ones i intend to focus on are the ones that are actually realistically possible |
| 13:35:58 | braewoods | usually due to documentation |
| 13:36:20 | braewoods | the OTG for the h300 is probably possible to implement |
| 13:36:21 | speachy | I'm content to see how the Pine64 thing comes along. I have one of their PineCubes now, and a couple other boards (same basic hw platform) on the way too. |
| 13:36:46 | braewoods | ultimately we'd need a some kind of casing to put it all in |
| 13:36:50 | speachy | including schematics and full source code for everything including the bootloader. |
| 13:37:05 | braewoods | is that something pine could also provide? |
| 13:37:40 | speachy | that's what they're looking into now; if they can re-use an exisitng case design that drastically cuts the NRE required since tooling is _expensive_. |
| 13:37:49 | braewoods | indeed |
| 13:38:19 | braewoods | speachy: i guess my suggestion was a good one? |
| 13:38:29 | braewoods | they were the only ones i could think of that have practical experience in this area |
| 13:38:39 | speachy | they like rockbox, but they don't know if the economics would be worthwhile. |
| 13:39:03 | braewoods | maybe it goes nowhere but i kinda noticed that we're running out of hardware targets for new stuff |
| 13:39:17 | braewoods | so maybe the only viable option left for native is DIY |
| 13:39:24 | speachy | the newer chinese DAPs are touchscreen monstrosities built mostly on android now. |
| 13:40:09 | speachy | with a few exceptions, but we're not likely to see something new in the price point of the AGPTek Rocker. |
| 13:40:30 | braewoods | it would probably be fine if we had kernel source |
| 13:42:22 | speachy | I've passed on a ton of info to the SFC about various makers' blatant GPL violations, but enforcing anyting against a chinese company is not likely to ever bear fruit. |
| 13:42:25 | _bilgus | ok moved to hilbylinux re compiling now |
| 13:43:39 | braewoods | think i'm going to use 4K buffers for MTP for now |
| 13:43:45 | braewoods | i just need to choose something. |
| 13:44:01 | braewoods | it can be adjusted later |
| 13:45:04 | braewoods | speachy: as we add more USB drivers we may need to make it configurable which ones activate and such. if we have too many endpoints we may exhaust the hardware's supply. |
| 13:45:40 | braewoods | the datasheets imply a limit on that. |
| 13:45:40 | braewoods | no idea honestly though |
| 13:45:40 | speachy | braewoods: generally speaking, yes, it's only one "advanced" function at a time. |
| 13:46:08 | gevaerts | Not just that. I suspect too many at a time would also confuse everyone |
| 13:46:25 | braewoods | indeed. we'll probably want to make MTP and UMS mutually exclusive so as to conserve the resources. |
| 13:46:38 | braewoods | UMS uses 2 endpoints, MTP uses 3. |
| 13:47:07 | speachy | no, they need to be mutually exclusive. |
| 13:47:33 | braewoods | ok. i thought i was agreeing though for different reasons. |
| 13:52:24 | borkitall | okay i left the h320 charging overnight |
| 13:52:32 | borkitall | its in bootloader usb mode |
| 13:55:22 | gevaerts | You do have USB_NUM_ENDPOINTS to look at. Looks like nothing has fewer than 3 |
| 14:00 |
| 14:02:05 | bluebrother^ | any thoughts on moving Rockbox Utility from qmake to cmake? That would also simplify all those tools, since we could simply use cmake for them as well. |
| 14:02:35 | bluebrother^ | so tools like ipodpatcher, mks5lboot etc. |
| 14:03:59 | speachy | not a fan of cmake, and I thought the choice of qmake was driven by rbutil being qt-based? |
| 14:04:13 | bluebrother^ | yes, but Qt also moves to cmake. |
| 14:04:28 | bluebrother^ | and to be honest, cmake is a lot more advanced than qmake these days. |
| 14:04:45 | speachy | sure, mirror what upstream uses |
| 14:05:00 | bluebrother^ | having qmake generate a Makefile that calls other hand written Makefiles is ... well, fragile. |
| 14:05:20 | borkitall | the new battery is reporting 4.12v, is this normal for a new battery? its 3.7v 1700mAh |
| 14:05:29 | braewoods | borkitall: yes |
| 14:05:30 | bluebrother^ | but since we're using a Makefile generator I figure it doesn't matter too much if it's qmake or cmake. |
| 14:05:46 | braewoods | borkitall: voltage is used to estimate how full the battery is |
| 14:06:26 | borkitall | awesome |
| 14:06:33 | borkitall | still getting used to irc |
| 14:08:24 | speachy | bluebrother^: I just don't want to have to rely on cmake to build anyting used by the main rb builds. |
| 14:08:37 | speachy | but if it makes sense to ditch qmake, so be it. |
| 14:09:02 | bluebrother^ | yeah, would be only stuff in rbutil/ and utils/ |
| 14:09:12 | bluebrother^ | plus, I'm planning to merge those two folders. |
| 14:09:31 | bluebrother^ | since having a separate rbutil/ doesn't make too much sense anymore these days. |
| 14:10:05 | *** | Saving seen data "./dancer.seen" |
| 14:10:07 | bluebrother^ | so tools/ would be the stuff required to build Rockbox itself (and not use cmake), utils/ would (at least partially) use cmake and only be additional tools. |
| 14:10:36 | braewoods | speachy: we may have a problem. i just tried to run a development build on my H10 and it freezes. |
| 14:10:50 | braewoods | and now it's getting system files stuff. i'll need to wipe it again. |
| 14:11:14 | braewoods | i wonder if PP devices are bugged? |
| 14:11:16 | speachy | braewoods: assmuming the 3.15 release worked, I'd try the oldest daily build as a sanity check first. |
| 14:11:39 | speachy | the ipods work, at least... |
| 14:11:45 | braewoods | also oddly there's a weird different from RB UMS and the proprietary UMS mode |
| 14:11:59 | braewoods | the total sector count is one less in RB mode |
| 14:12:26 | braewoods | sdc: p1 size 62453633 extends beyond EOD, enabling native capacity |
| 14:12:30 | borkitall | so if i understand this, 1.7A is the max i should use with a 1700mAh battery |
| 14:12:32 | borkitall | at 5v |
| 14:12:33 | braewoods | is the error resulting from it |
| 14:12:48 | braewoods | borkitall: eh? you mean for charging? |
| 14:13:06 | braewoods | discharge rate is heavily defined by the battery |
| 14:14:10 | borkitall | yes |
| 14:14:28 | borkitall | i dont care about the discarge rate |
| 14:14:51 | borkitall | just would like to know what charging to use, as i dont know where the stock charger is |
| 14:15:13 | borkitall | sorry if im unclear |
| 14:15:29 | braewoods | borkitall: well |
| 14:15:39 | braewoods | you can get by with usb barrel jack adapter |
| 14:15:43 | braewoods | or just charge over usb |
| 14:16:30 | braewoods | i know the H320 and H340 use the 4mm barrel jack |
| 14:16:48 | braewoods | https://www.ebay.com/itm/100cm-USB-4-0mm-x-1-7mm-DC-Barrel-Jack-5V-1A-Charger-Power-Cable-Adapter-4mm/383567985013 |
| 14:16:51 | speachy | so rb reports an odd drive sector size? |
| 14:16:52 | braewoods | one example |
| 14:17:10 | braewoods | speachy: yes. it's one less than the max size reported when i'm in the iriver UMS |
| 14:17:32 | braewoods | speachy: i worked around it before by making my partition slightly smaller |
| 14:17:52 | braewoods | not sure what the issue really is, if any |
| 14:17:52 | speachy | this is h10? h1xx? |
| 14:17:58 | braewoods | speachy: H10 |
| 14:18:09 | braewoods | it happened before I performed the CF mod |
| 14:18:19 | braewoods | as well |
| 14:18:26 | braewoods | maybe this unit is just iffy |
| 14:18:41 | borkitall | braewoods: thanks yeah i got one of those |
| 14:18:41 | braewoods | brb |
| 14:18:50 | speachy | I'd be curious to see what the actual drive reports. |
| 14:19:03 | braewoods | i can't open it to find out. one of the screws got stripped |
| 14:19:12 | speachy | dump the identify info |
| 14:19:15 | speachy | it'll be in there. |
| 14:19:19 | braewoods | ok. |
| 14:19:29 | braewoods | i'll check it out after i repair it |
| 14:19:31 | braewoods | ugh |
| 14:19:56 | braewoods | i'll check my other H10 to see if it has the same inconsistency |
| 14:20:05 | braewoods | i forgot about it until recently |
| 14:24:28 | speachy | braewoods: it _appears_ that total sector reported is lifted straight from the drive. |
| 14:24:47 | braewoods | could it be iriver is reporting it wrong? |
| 14:25:00 | speachy | could be. |
| 14:25:02 | braewoods | anyway i'll check what i find out. |
| 14:25:20 | speachy | the identfy info will be authatorative. |
| 14:28:48 | braewoods | no issue on H320 |
| 14:28:50 | braewoods | hm |
| 14:29:12 | braewoods | seems to be an H10 bug |
| 14:42:19 | _bilgus | 3044 has a few bug fixes I'll try to get it fleshed out a bit more this evening and incorporate any new suggestions |
| 15:00 |
| 15:02:59 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 15:04:36 | | Quit Rower (Ping timeout: 240 seconds) |
| 15:42:54 | Strife89 | speachy: I've been mulling over giving my iRiver flash storage, but I don't think I want to get another iFlash. Know any good alternatives? |
| 15:43:25 | Strife89 | (Other than the Kingspec 1.8" line, which gets expensive for the 128 GB model. https://smile.amazon.com/KingSpec-128GB-1-8-5mm-KSD-ZF18-6-128MS/dp/B008NAI0YC) |
| 15:43:43 | speachy | nope. AFAIK all of the others are all based on the same chipset anyway. even the kingspec, which IIRC is just an eMMC with the same controller |
| 15:44:02 | | Join Bilgus_ph [0] (~irc@65.186.35.190) |
| 15:44:17 | Strife89 | Well shoot |
| 15:45:08 | Strife89 | And that means the Kingspec probably gets the same workaround as the iFlash, doesn't it (disabling putting the disk to sleep) |
| 15:48:16 | | Quit Bilgus_ph (Remote host closed the connection) |
| 15:52:28 | | Join Bilgus_ph [0] (~irc@65.186.35.190) |
| 15:52:44 | | Quit Bilgus_ph (Client Quit) |
| 16:00 |
| 16:01:38 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:09:43 | braewoods | Strife89: you have an H320? |
| 16:09:51 | braewoods | Strife89: how'd the new bootloader work for you? |
| 16:09:53 | | Quit Rower- () |
| 16:10:09 | *** | Saving seen data "./dancer.seen" |
| 16:11:07 | Strife89 | Yep |
| 16:11:13 | Strife89 | Flashing it and rebooting went well! |
| 16:12:00 | | Quit Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in) |
| 16:12:27 | braewoods | Strife89: great. so you want flash storage? |
| 16:12:32 | Strife89 | https://usercontent.irccloud-cdn.com/file/yig03Emd/IMG_20201119_161144.jpg |
| 16:12:41 | Strife89 | I do |
| 16:13:03 | braewoods | Hm. |
| 16:13:11 | Strife89 | TBH I'm just window shopping right now, though. Money's tight. |
| 16:13:21 | braewoods | I used those CF card adapters when I modded my H120. |
| 16:13:38 | braewoods | they need a bit of work as the jumper is too tall. |
| 16:13:48 | braewoods | but it's probably your best option |
| 16:13:56 | braewoods | some kind of CF card or an adapter |
| 16:14:14 | braewoods | in either case speed isn't going to incredible |
| 16:14:25 | braewoods | i saw my CF card max out at 13 MB/s when doing block operations |
| 16:14:33 | braewoods | but it's better than many RB targets |
| 16:15:00 | braewoods | Strife89: how much storage you wanting? |
| 16:15:13 | braewoods | the most economical is probaly SD cards |
| 16:15:17 | Strife89 | 60-100 GB would be best |
| 16:15:23 | braewoods | ah. |
| 16:15:33 | braewoods | you can find 64GB CF cards for around $30 used lately |
| 16:15:38 | Strife89 | (so a 64 or 128 GB SD/CF card, probably) |
| 16:15:44 | braewoods | that and the adapter is around $40 |
| 16:16:36 | braewoods | i've seen kingston cf cards for around $60-80 for 128GB or more |
| 16:16:48 | braewoods | but at that point SD cards start to sound better |
| 16:16:54 | Strife89 | I bought an iFlash Solo for an iPod Color a while back, and while it works pretty well now, it was rough at first |
| 16:17:13 | braewoods | the SD card adapters are also hit or miss |
| 16:17:16 | Strife89 | I have speachy to thank for getting it to behave in Rockbox |
| 16:17:38 | braewoods | the best option is true CF cards with a passive adapter if you want any guarantees about stability |
| 16:17:39 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 16:18:10 | braewoods | what continent you on? |
| 16:18:13 | braewoods | i'll see what i can find |
| 16:18:36 | Strife89 | North America (southeastern United States) |
| 16:18:57 | braewoods | ah |
| 16:19:38 | braewoods | ok, kingston canvas focus is the cheapest CF card for 128GB |
| 16:19:46 | braewoods | $40ish |
| 16:19:49 | braewoods | ebay |
| 16:20:17 | braewoods | https://www.amazon.com/Kingston-128GB-Performance-Professional-CFF/dp/B07M5M5KYZ |
| 16:20:21 | braewoods | or here |
| 16:20:33 | braewoods | or 256GB for $60 |
| 16:20:43 | Strife89 | That's pretty good |
| 16:21:13 | Strife89 | Any known-good CF adapters still out there? |
| 16:21:28 | braewoods | yea. |
| 16:21:32 | braewoods | for your h320 |
| 16:21:41 | braewoods | the easiest is the 50 pin one that's entirely passive |
| 16:22:11 | braewoods | https://www.amazon.com/SinLoon-AdapterCompact-Converter-Adapter-Toshiba/dp/B07YSJ12T3 |
| 16:22:14 | braewoods | this for example |
| 16:22:22 | braewoods | but you'll need to modify it slightly to use it in H320 |
| 16:22:41 | braewoods | the jumper is too tall |
| 16:22:49 | braewoods | you have to find a way to solve that |
| 16:23:09 | braewoods | jumper needs to be closed/bridged to avoid issues with the adapter |
| 16:23:13 | braewoods | you can bend it over |
| 16:23:20 | braewoods | and somehow bridge it |
| 16:23:32 | braewoods | cut it and solder the pins |
| 16:23:34 | braewoods | etc |
| 16:23:38 | braewoods | anything to reduce the overall height |
| 16:23:54 | braewoods | since it's purely passive there's very little that can go wrong. |
| 16:24:01 | braewoods | main reason i prefer it |
| 16:25:15 | Strife89 | I'll keep that for later, thanks! |
| 16:25:48 | braewoods | you may also need to clip off the plastic tabs |
| 16:25:55 | braewoods | on the unit |
| 16:25:58 | braewoods | adapter |
| 16:26:00 | braewoods | i mean |
| 16:26:19 | braewoods | it got in the way when i installed the one in my h120 |
| 16:26:35 | speachy | is that an LED on the pcb? |
| 16:26:49 | braewoods | maybe but it's not populated |
| 16:27:16 | braewoods | oh, you mean the ZIF adapters? |
| 16:27:40 | braewoods | Strife89: i prefer the 64gb cards. i don't need more storage. |
| 16:29:53 | Strife89 | I'm a data hoarder :P |
| 16:30:13 | Strife89 | And I, uh, acquire lots and lots of video game soundtracks |
| 16:30:18 | braewoods | I see. |
| 16:30:43 | braewoods | either way the CF cards should give a modest speed boost over the original hard drive |
| 16:31:03 | braewoods | 13 MB/s is the fastest i've ever gotten over UMS on any RB target |
| 16:31:16 | braewoods | i got that on a gogear HDD1630 after upgrading to a CF card |
| 16:31:34 | Strife89 | Sounds pretty good, overall |
| 16:31:53 | braewoods | and also on the H120 |
| 16:32:00 | braewoods | i assume the H320 will also achieve similar speeds |
| 16:32:06 | braewoods | since it uses the same ATA/USB stuff |
| 16:32:45 | braewoods | i'm going to try some experiments, see if increasing the UMS write buffer helps IO at all |
| 16:32:48 | braewoods | increase it to 64k |
| 16:32:51 | braewoods | :-) |
| 16:33:10 | Strife89 | I'm more worried about power saving and shake/impact resistance anyway :) |
| 16:33:18 | braewoods | you got that in spades |
| 16:33:23 | braewoods | CF cards also tend to be faster |
| 16:33:28 | Strife89 | But faster r/w speeds will definitely be nice, too |
| 16:33:34 | braewoods | means faster syncing |
| 16:33:46 | braewoods | but it seems to me that the real world speeds differ heavily |
| 16:33:54 | braewoods | the iriver H10 has terrible write speeds |
| 16:33:59 | braewoods | but i've seen 20+ MB/s read speeds |
| 16:34:10 | Strife89 | and faster seek times, of course |
| 16:34:14 | braewoods | but it caps around 4-5 MB/s write |
| 16:34:28 | braewoods | kinda weird considering it was a CF mod |
| 16:34:38 | braewoods | the card it has can do 10 mb/s in a regular usb adapter |
| 16:34:44 | braewoods | so |
| 16:34:48 | braewoods | the card isn't the bottleneck |
| 16:34:50 | braewoods | something else is |
| 16:35:56 | braewoods | Strife89: it's entirely optional but you may want to replace the OF before doing the CF mod |
| 16:36:11 | braewoods | the OF is worthless in a CF modded H320 anyway since it doesn't like them |
| 16:36:12 | Strife89 | As in flashing Rockbox |
| 16:36:17 | braewoods | yea |
| 16:36:18 | Strife89 | ? |
| 16:36:23 | braewoods | that's a new feature of the V8 bootloader |
| 16:36:34 | Strife89 | Oh good, I was hoping so |
| 16:36:46 | braewoods | it works, i tested it during my trial runs before release |
| 16:36:57 | braewoods | i ported over the code used in the H100 |
| 16:37:44 | braewoods | but that was one reason I did my development on a non-modded H320 |
| 16:37:50 | braewoods | i needed the OF to recover from bad flashes |
| 16:38:16 | braewoods | it was broken for a long time, the bootloader |
| 16:38:57 | braewoods | turned out someone added code to switch the H300 LCD code to using DMA but that broke the bootloader |
| 16:39:15 | braewoods | so i had to port the old method of updating it so the bootloader would work again |
| 16:40:44 | braewoods | incidently the new BL has a fallback that if the OF has been replaced, it will attempt to boot the ROM RB image if the reset cookie was tripped |
| 16:40:55 | | Quit Acou_Bass (Ping timeout: 246 seconds) |
| 16:41:12 | braewoods | good if the main bootloader payload is somehow unable to boot |
| 16:46:06 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 16:58:43 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 17:00 |
| 17:29:31 | braewoods | speachy: can you read schematics? |
| 17:37:07 | speachy | yeah? |
| 17:37:46 | braewoods | i was trying to find a new battery for my hdd1630 but the existing ones are too tall. |
| 17:37:58 | braewoods | even though they claim to be compatible they don't fit the case |
| 17:38:15 | braewoods | so i'm trying to find one that fits the case and terminal and has the same pin out |
| 17:38:26 | braewoods | so how do i determine my existing pin out? |
| 17:38:30 | braewoods | or is that standardized? |
| 17:38:32 | speachy | for the battery? |
| 17:38:37 | braewoods | and the terminal |
| 17:38:49 | braewoods | i have the board schematics for the header |
| 17:38:54 | speachy | there's no inherent standard, although I have yet to see one of those batteries where red wasn't + and black -. |
| 17:38:54 | braewoods | https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/PHILIPS_HDD1420_ServiceManual.pdf |
| 17:39:04 | speachy | sometimes there's a sense line too, typically white or yellow |
| 17:39:14 | braewoods | the HDD1630 is 3 pin |
| 17:39:37 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 17:39:41 | braewoods | U502 is the battery part |
| 17:39:47 | braewoods | i think it's saying... |
| 17:40:03 | braewoods | pin 1 is connected to ground? |
| 17:40:16 | braewoods | pin 2 goes to BAT_P |
| 17:40:19 | braewoods | err |
| 17:40:21 | braewoods | BAT_T |
| 17:40:24 | braewoods | pin 3 is BAT_P |
| 17:40:42 | braewoods | sorry, i suck at reading these. |
| 17:41:34 | braewoods | i can use a multimeter to figure out which battery terminals are what |
| 17:41:45 | braewoods | fbut |
| 17:41:47 | braewoods | but |
| 17:41:49 | braewoods | eh |
| 17:41:49 | speachy | okay, pin 1 is ground, pin 2 is positive, pin 3 is sense |
| 17:42:00 | braewoods | ok. thank you. |
| 17:42:24 | braewoods | that's what i thought |
| 17:43:03 | speachy | yep, in the photo it's clearly blk-red-wht |
| 17:44:11 | speachy | you may or may not be able to find a battery with the right size/type connector. |
| 17:44:48 | braewoods | it is what it is but i figured the ipod mini would be a good place to check |
| 17:44:53 | speachy | (IIRC back in the day the H1xx series used an ipod battery, but with the + and - swapped. easy enough to swap pins on the connector) |
| 17:45:21 | braewoods | it's closest to the ipod mini in terms of size |
| 17:45:32 | braewoods | also uses microdrive |
| 17:51:02 | braewoods | yea it matches the known viable replacement |
| 17:51:11 | braewoods | only flaw is it doesn't fit the case too well |
| 17:51:30 | braewoods | i guess there's always plan B |
| 17:51:45 | braewoods | find an alternative that fits and just reterminate the battery connector |
| 17:51:57 | braewoods | though not what i'd prefer to do. lol |
| 17:54:12 | braewoods | ipod mini battery would probably fit but the pins don't look right |
| 17:54:29 | braewoods | different layout |
| 18:00 |
| 18:10:13 | *** | Saving seen data "./dancer.seen" |
| 18:19:46 | | Part borkitall |
| 18:45:23 | braewoods | speachy: you said the pins were easy to swap. how would you do so? what tools? |
| 18:45:48 | braewoods | i'm guessing these batteries are 1.25mm jst but i can't even find what tools you'd use to terminate these |
| 19:00 |
| 19:03:21 | braewoods | oh. |
| 19:03:56 | braewoods | found it i guess |
| 19:04:13 | braewoods | guess my best bet is to find a battery and swap the pins |
| 19:04:17 | braewoods | didn't realize you could do that |
| 19:06:22 | | Join borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 19:06:41 | speachy | if it's the same _connector_ the pins are easy to swap. if the connector differs (and the actual pins themselves don't have the same size/profile) then you're SOL. |
| 19:07:16 | speachy | there's a tiny plastic flap that you need to lift out of the way so you can pull the pin out. |
| 19:14:04 | | Quit Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in) |
| 19:19:44 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 19:19:44 | braewoods | speachy: i saw that in a video |
| 19:52:43 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:52:59 | | Join fs-bluebot_ [0] (~fs-bluebo@55d4017f.access.ecotel.net) |
| 19:55:36 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 19:56:36 | | Quit bluebrother^ (Ping timeout: 272 seconds) |
| 20:00 |
| 20:00:10 | | Join thanevim [0] (4989016d@c-73-137-1-109.hsd1.ga.comcast.net) |
| 20:03:31 | thanevim | Hi everyone. Glad to see this still around. I just bought a Fuze v2 off of ebay, and it boots, plays music, even took a firmware upgrade for the rockbox install. Bootloader starts, but it presents a partition error. Not finding anything online about this, any help? |
| 20:06:41 | thanevim | For the record, it does still play music in the original firmware after Rockbox install. |
| 20:08:21 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 20:09:43 | | Quit prof_wolfff (Ping timeout: 265 seconds) |
| 20:10:15 | *** | Saving seen data "./dancer.seen" |
| 20:29:33 | | Quit thanevim (Remote host closed the connection) |
| 20:30:43 | | Join thanevim [0] (4989016d@c-73-137-1-109.hsd1.ga.comcast.net) |
| 20:41:55 | braewoods | thanevim: can you be more specific about the message? |
| 20:43:01 | thanevim | The message itself reads "No partition found. Insert USB cable and fix it." |
| 20:43:23 | thanevim | This is a Fuze v2 2GB model for the record |
| 20:43:55 | braewoods | it means it can't find the partition rockbox is on |
| 20:44:03 | braewoods | all the bootloaders say something similar if that happens |
| 20:44:54 | thanevim | That makes sense. I did find something mentioning format in the original fw if this error occurs, however that plus reinstall from the rbutil still resulted in the same error |
| 20:46:19 | thanevim | It seems there's a workaround by dropping .rocknox onto a microSD, but that's resulting in all of the applets showing Incompatible Version (potentially because the version on /wiki/SansaAMS isn't the same that the util uses?) |
| 20:47:02 | thanevim | Regardless, it would at least be nice if there's a fix that doesn't require loading from microSD if possible |
| 20:47:16 | braewoods | _bilgus: may know more as i believe he was working on sansa bootloaders |
| 20:47:35 | braewoods | i'm not really familiar with those targets too well |
| 20:47:54 | braewoods | i mostly focus on HDD units |
| 20:48:04 | braewoods | like the iriver h100 and h300 |
| 20:48:18 | thanevim | Understandable. I'll wait for bilgus to speak, and post in here if I find anything |
| 20:49:54 | _bilgus | thanevim, that message just means rb folder is missing |
| 20:51:11 | _bilgus | when you plug usb does it mount the internal drive? |
| 20:51:43 | thanevim | Not inside that bootloader, but once you said that, I rebooted the original, and it does show internal memory that contains .rockbox/ |
| 20:51:48 | _bilgus | if so download the dev version for your device and copy the .rockbox folder from the zip to the device drive |
| 20:51:50 | braewoods | thanevim: small tip. try to use sd card for most of your writes. a common failure with these players is wearing out the internal flash. |
| 20:52:23 | thanevim | That makes sense, given these things are ~10 years old |
| 20:52:37 | braewoods | the sd card can be replaced |
| 20:52:43 | braewoods | your internal storage, not so easily if at all |
| 20:53:09 | thanevim | Yeah.. I remember trying to no avail in my first sansa... |
| 20:53:20 | braewoods | part of why i don't bother with RB targets that only have intenrla storage you can't replace |
| 20:53:20 | _bilgus | again use a dev version same idea just copy .rockbox to the root of the sd car formatted to FAT32 |
| 20:53:34 | thanevim | Ok, I'll try that now |
| 20:55:54 | braewoods | from appaearances the fuze v2's battery is soldered |
| 20:56:02 | braewoods | those can still be replaced but you need the right tools |
| 20:56:23 | braewoods | if you need help hunting for a replacement battery let us know |
| 20:56:33 | thanevim | Appreciate it |
| 20:57:08 | braewoods | though if there was room i'd want to solder a battery header. lol |
| 20:57:29 | thanevim | That'd makes sense, to prolong life |
| 20:57:44 | braewoods | yea. desoldering can damage the PCB and such. |
| 20:57:54 | braewoods | so if you can, it's best to resolder a socket or header. |
| 20:59:55 | thanevim | Booted the dev version, still seeing Incompatible version for the applets/games/etc |
| 21:00 |
| 21:00:55 | braewoods | did you copy it to both the internal and SD card? |
| 21:01:34 | _bilgus | no just one or the other but you can do both |
| 21:01:52 | braewoods | well if it works it would tell us something |
| 21:02:10 | _bilgus | if you ar egetting incompatible version message the you need to rename the folder and try again |
| 21:02:23 | braewoods | or that |
| 21:02:32 | _bilgus | don't delete rename it and copy again |
| 21:02:40 | thanevim | It was just the sd. Did so out of fear that the internal flash is dying, since it has been causing Explorer to hang |
| 21:02:52 | _bilgus | that makes sure it gets coppied to a new location |
| 21:03:14 | thanevim | And the original firmware is currently hanging on Refreshing your media |
| 21:03:30 | _bilgus | the internal flah dying is entirely possible thats why I made the boot from sd option |
| 21:06:26 | mendel_munkis | is there a list of which targets support which key combos? |
| 21:07:04 | mendel_munkis | (if any) |
| 21:08:54 | thanevim | Thanks for the help. I'll be afk for a bit, then resume hacking this poor piece of tech. |
| 21:16:43 | | Quit livvy (Ping timeout: 240 seconds) |
| 21:26:17 | braewoods | looks like 602040 battery is my best option |
| 21:30:36 | braewoods | speachy: i'm finding it hard to find batteries with the third wire for the sensor. is it essential? |
| 21:55:54 | speachy | I would assume so. |
| 21:57:19 | speachy | that's how the battery level is checked. leave it off and you could end up (eg) the system force-shutting down because it thinks the battery is below the critical voltage level. |
| 21:57:36 | speachy | or charging might not work. or it might overcharge. or.. |
| 22:00 |
| 22:01:04 | speachy | depends on how the BQ4032 (ie the battery charger IC) works. |
| 22:01:22 | speachy | er. BQ24032 |
| 22:04:58 | speachy | d'oh, that's the temperature sense. looking at the datasheet, without the TS connected, it won't charge the battery. |
| 22:05:52 | speachy | (to use it with a 2-wire battery you'd need to modify the circuit slightly. |
| 22:08:18 | speachy | that pin needs to be in the 0.5->2.5 range. (+-3%) |
| 22:08:29 | speachy | 2.5v, that is |
| 22:09:01 | _bilgus | braewoods, the third wire can be bypassed with a sutible resistor |
| 22:09:32 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 22:09:47 | _bilgus | you'll need an old battery to figure it out value and if its connected to ground or vcc |
| 22:10:18 | *** | Saving seen data "./dancer.seen" |
| 22:11:29 | speachy | it's connected to vcc. |
| 23:00 |
| 23:03:38 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 23:31:08 | | Quit Xeha (Ping timeout: 256 seconds) |
icon identifies that the person is a core developer (has commit access).