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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-11-19

00:02:44karinkaim currently on bl version 5
00:08:43karinkaand i dont know if i have the eu or the us version'
00:09:51***Saving seen data "./dancer.seen"
00:10:36karinkaokay v5 is the current version?
00:12:49karinkajust gonna leave it plugged in for a bit
00:13:10 Quit karinka (Quit: karinka)
00:13:34 Join karinka [0] (
00:26:46karinkaupdating to 3.15 stable with rockbox utility
00:26:51karinkacause lazy
00:28:32karinkabattery is reporting above 4v
00:33:20karinkaill keep an eye out for issues with the H2
00:33:27karinkajust gonna take a bit
00:33:42karinkaits taken days for me to understand rockbox
00:33:46karinkain general
00:59:59 Join Rower [0] (
01:28:05Strife89Yeah v5 is the last known stable bootloader for the H3x0, sorry
01:32:48karinkaah 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:02:10 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
02:09:52***Saving seen data "./dancer.seen"
02:25:24 Join petur [0] (~petur@
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] (
02:54:20 Part karinka ("Good Bye")
02:54:33 Join karinka [0] (
02:54:42 Nick karinka is now known as borkitall (
02:55:30borkitalljust changed my nick, just letting yall know
02:55:34borkitallfrom karinka
02:55:48borkitallah its there lul im not used to irc
04:05:12 Join prof_wolfff [0] (
04:09:54***Saving seen data "./dancer.seen"
06:09:56***No seen item changed, no save performed.
06:35:10 Quit Misanthropos (Read error: Connection reset by peer)
06:36:17braewoodsborkitall: 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:31braewoodsmain problem is rbutil hasn't been updated yet so we can't fully release it yet.
06:39:03braewoodsspeachy: something up with RB website? everything times out.
06:39:57braewoodsyet gerrit still works over git
06:40:07*braewoods boggles.
06:45:27 Join Misanthropos [0] (~Misanthro@
06:48:26 Quit Stanley00 ()
06:51:08 Quit ac_laptop (Ping timeout: 260 seconds)
06:52:06speachybraewoods: wokik engine wedged the web server. thanks for letting me know.
06:53:52braewoodsspeachy: i assume we'll be releasing the new bootloaders whenever rbutil is ready for an update?
06:54:29braewoodssince it has checksums that are compiled in
06:54:46speachyyeah... though I'd really prefer that this stuff get un-compiled-in so this doesn't happen in the future
06:55:07speachythat shouldn't be hardcoded
06:55:17braewoodspossible but rbutil would need to be expanded to take them from the website then.
06:55:30braewoodsthe only part that can be hard-coded is the checksum for the OF
06:55:44braewoodsthat's pretty much static
06:56:32braewoodsbluebrother^: any ideas how this could be done?
06:56:57braewoodsbluebrother^: 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:39braewoodsthe existing one was taken from fwpatcher
06:57:45braewoodsthat should probably stay but
06:57:54braewoodsrbutil needs to be more flexible
06:58:36braewoodsspeachy: i think one of my projects after MTP is going to be seeing if i can add support for some missing chips
06:59:02braewoodsit would be interesting if we could have composite output on a few targets that support it
06:59:19braewoodsthe chip in the hdd6330 is documented so
06:59:31braewoodsshould be possible to write a driver for NTSC/PAL output
07:10:20speachylooks 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:30braewoodsspeachy: 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:22braewoodsjust trying to a see if it's possible for length to ever be too large to process all at once before returning
07:36:08gevaertsWhat do you mean by "sent to a usb core driver at once"?
07:36:31braewoodsthe transfer_complete callback
07:36:52braewoodshow large can length be at one time?
07:38:01*gevaerts used to know this without having to check...
07:38:28braewoodsmostly curious so i can see how to structure MTP support
07:38:55braewoodswhether i need to do multiple passes through the buffer processing stuff
07:39:02braewoodsor whether one sufficiently large one will do
07:42:36gevaertsThe 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:35braewoodsgevaerts: or i can just make multiple passes until all the data has been received
07:43:56braewoodswell that helps i guess
07:44:06braewoodsi'm wanting to layer MTP into multiple layers
07:44:18braewoodsthe IO layer (usb code)
07:44:25braewoodsthe MTP parsing layer
07:44:41braewoodsand the MTP higher level stuff for RB to hook into to expose stuff over MTP
07:44:49gevaertsUnless I'm seriously misremembering, that's what mass storage does (at least for some chips)
07:45:47braewoodsgevaerts: ok.
07:45:53braewoodsgevaerts: thanks.
07:46:16braewoodsi'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:23braewoodsit seemed to be the best ROI
07:47:35gevaertsThe 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:51braewoodsok. sure.
07:48:02braewoodsi'll do multiple passes since the buffer may be smaller.
07:48:09braewoodsseems to be no way around it
07:48:28speachyyeah, 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:29speachybraewoods: don't go overboard with abstraction layers. our USB stack and driver interface is bespoke.
07:50:10speachyand there is little room for reuse at anything other than the highest layers.
07:50:20speachyeven our Filesystem/etc interface is unique.
07:51:07speachyabstracting 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:05speachythere's arguably some advantage for hosted targets to re-use the MTP stuff, but on those there are already mature native solutions.
07:52:13braewoodsspeachy: ok...
07:52:24speachythis is one of those "premature optimization" things.
07:52:42braewoodsspeachy: i was wanting to allow for apps to provide MTP services too
07:53:01braewoodseither way, some abstraction for "storage" providers seemed prudent
07:53:19speachyrockbox already provides an abstraction at that layer. code to that API.
07:53:45speachyand if this ever gets reused outside of rockbox, then at that point a proper storage API can be provided.
07:53:51braewoodsyea but i still need to write code to allow external code to interface with it?
07:54:27braewoodsi was thinking of separating the fulfillment of services to other codes so i could manage it and extend it later
07:54:55braewoodse.g., the core handles processing of MTP requests and dispatches them to the appropriate provider
07:55:00speachymy 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:18braewoodsoh i'm just speaking internally
07:55:28braewoodslike one provider might be based on...
07:55:35braewoodsthat cache for files?
07:56:32braewoodsi just thought it'd be interesting if external stuff could provide their own implementations of MTP storage providers
07:56:45speachy"External stuff"?
07:56:46braewoodsone would use dircache and serve real files
07:56:52speachyah, I see.
07:56:59braewoodsexternal modules
07:57:07braewoodswithin RB
07:57:13braewoodsexternal to the MTP core code
07:57:21gevaertsYou mean like the debug thing you mentioned?
07:57:22braewoodsso it isn't limited to just using the filesystem resources
07:57:22speachyno.. the right place for that is within the FS layer. it already exports "fake" directories, for example
07:57:39braewoodsspeachy: example?
07:57:51braewoodsgevaerts: yea, possibly.
07:57:59braewoodsit just sounded cool at first
07:58:21braewoodsi just trying to think of how to handle the MTP implementation
07:58:23braewoodsi am*
07:58:31speachyeg 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:45braewoodsso like unix
07:59:15braewoodsspeachy: does that show up in dircache?
07:59:20braewoodsi assume no?
07:59:34braewoodsthough i guess mtp should stick to just serving real file resourcs
07:59:50speachythey're returned as directory entries, so yeah, they'll end up exposed to whatever that walks teh filesystem
08:00:16braewoodsoh, i see.
08:00:25braewoodsso i could add that by extending the FS module.
08:00:29braewoodsok, ok.
08:01:00braewoodsjust if we're going to have MTP i need to know how best to implement it
08:01:10braewoodsthere's a lot i don't know about RB
08:01:26speachy(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:28braewoodsi thought i needed abstractions like this but i guess i don't
08:01:53braewoodsspeachy: we may be able to use umtp-responder for the hosted targets
08:02:05braewoodsbut it's not suitable for RB native targets. it's too tied to POSIX.
08:02:07braewoodsand Linux
08:03:09braewoodsit's a daemon that uses usb-gadget API to provide an MTP responder process.
08:03:23braewoodsC code
08:03:35braewoodsand also GPLv3
08:03:47speachymy 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:25speachythat 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:56speachyexternal API needs shouldn't require much more than that, actually.
08:06:00speachyI saw umtp-responder; my worry about it is that if it needs something that isn't present on our sourceless vendor kernels.
08:07:19speachy(And honestly it might make more sense to start with umtp-responder, and port that to rockbox's API instead)
08:07:39speachy(but it would be nice to be able to use it for both native and hosted targets!)
08:09:23speachycompiled on x86_64 the binary is just shy of 100K.
08:09:46speachyno external libraries other than pthread.
08:10:00***Saving seen data "./dancer.seen"
08:15:50speachyscrap everyting that interfaces with the OS, keep only files starting with mtp_
08:22:03braewoodsspeachy: maybe... just felt i would need to do a lot of gutting and refactoring for that to really work.
08:22:09braewoodsi looked through the source already.
08:22:31speachyperhaps.. 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:07braewoodsno idea.
08:23:21braewoodsi was planning to use it as a reference if nothing else.
08:23:28braewoodsit's easier to follow than the C++ stuff.
08:25:23braewoodsjust 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:37braewoodsi've not seen any generic libraries so to speak except for the client side
08:25:38speachywould 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:27speachyon the client side it's a lot simpler, yeah.
08:26:44speachy(or rather the OS-interface layer is a lot smaller)
08:27:08braewoodse.g., every smart phone OS has their own solution
08:27:11braewoodsamong other things
08:27:23braewoodsit wouldn't be unusual for RB to do the same
08:27:29braewoodsin this situation
08:27:36speachymost of those things were written around the same time.
08:27:45speachyie when there wasn't an option for reuse
08:27:51speachyand started out quasi-proprietary
08:27:56braewoodsI see.
08:28:29speachyand once you had something that worked, why invest the effort into switching to something else?
08:29:31speachy(also, incompatible licensing is another typical reason for reinventing the wheel. see: android everything)
08:30:44speachyI mean, we can't use the otherwise-awesome bluekitchen/btstack for that reason
08:46:02 Join Moarc [0] (
09:18:16speachyhuh, appears that my patch to de-mangle the ATA timing for SSDs on the iPods seems to work.
09:22:26braewoodsspeachy: IOW, the iflash issue?
09:22:44speachymore specifically, the iFlash mSATA issue
09:22:55speachythe iFlash SD stuff has long since been solved, I think.
09:26:52speachythe power management fix I did some point over the summer.
09:28:01_bilgusnice I'll update that stickied post
09:29:28speachyyeah, they _must_ use a recent nightly or dev build.
09:30:28speachyok, anyone have a relatively trivial commit ready?
09:31:11speachyI'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] (
09:54:14speachy_bilgus: you should also edit the first post in the topic too..
09:55:23fs-bluebotBuild Server message: New build round started. Revision 6d62a7a1bd, 293 builds, 9 clients.
09:55:40speachyok, let's see what breaks on the www side when this is done.
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] (
10:13:27fs-bluebotBuild Server message: Build round completed after 1083 seconds.
10:13:29fs-bluebotBuild Server message: Revision 6d62a7a1bd result: All green
10:14:03speachysweeet, 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:04fs-bluebotBuild Server message: New build round started. Revision b7b0c7c648, 293 builds, 9 clients.
10:16:17 Join Rower [0] (
10:29:19fs-bluebotBuild Server message: Build round completed after 794 seconds.
10:29:21fs-bluebotBuild Server message: Revision b7b0c7c648 result: All green
10:36:08 Join wodz [0] (
10:36:38wodzany progress with BT ui mockup?
10:42:41wodzwill read response if any later
10:42:45 Quit wodz (Quit: Leaving)
10:45:48 Quit massiveH (Quit: Leaving)
10:47:55mendelmunkiswhy does the gigabeat have two button-target.h? (plus one for the gigabeat-s)
10:48:24braewoodsspeachy: kinda weird. the players that used the f-flex interface have 0 adapters available that i can tell.
10:48:39braewoodsbut since the pin-out is documented
10:48:47braewoodsi guess someone could design one.
10:48:53braewoodsbut how would you get it produced?
10:50:41braewoodsthe ribbon cable is soldered to the original drive so you can't just reuse that
10:51:18braewoodsguess i'll ask some hardware guys that have designed stuff before
11:08:23braewoodsone idea is if it's possible to find a generic ribbon cable that fits
11:08:35braewoodsthen try to connect it to an adapter of sorts
11:08:41braewoodsbut would take up too much space i'm sure
11:27:09_bilguss peachy done.
11:28:16_bilguswodz 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:33speachyI 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] (
12:05:47 Join Rower- [0] (
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:44speachyhuh. now it's working.
12:30:59speachywodz: can you write up what's needed to set things up on the ALSA side of things? sample config device strings?
12:33:33fs-bluebotBuild Server message: New build round started. Revision 497618e51e, 293 builds, 9 clients.
12:44:09 Join Rower [0] (
12:45:48 Quit Rower- (Ping timeout: 260 seconds)
12:55:53fs-bluebotBuild Server message: Build round completed after 1340 seconds.
12:55:55fs-bluebotBuild Server message: Revision 497618e51e result: All green
13:00:54fs-bluebotGerrit review #3044 at : Bluetooth Menu WIP by William Wilgus
13:01:41_bilgusbasically 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_bilgusI think I want drop down menus and context menus but its just context menu atm
13:03:30_bilgusthere 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:43braewoods_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:00braewoods_bilgus: how hard would it be to extend that concept with another type of second video output?
13:10:49braewoods_bilgus: some of the players i've noticed have a composite video output.
13:11:09braewoodsso i was pondering the possibility of adding support as a secondary video output of the main rockbox screen
13:14:08_bilgusit really wouldn't be hard to add it as another screen but there is nothing that uses it in the code
13:14:37_bilgusbetter option would be a screen mirror but that incurs a speed penalty
13:15:29_bilgusnow 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:37braewoods_bilgus: ok. noted. i'll look into it later. i think i could write a driver for it.
13:16:04_bilgusbe easier as an either or make it main use remote
13:16:28braewoodshonestly adding the OTG for h300 is a higher priority to me
13:16:34braewoodsMTP even higher
13:16:54braewoodsright now i'm trying to fix my H10 so i have something to test MTP on
13:17:31braewoodsdecisions, decisions, though.
13:18:04braewoodsi am going to try something first though :)
13:18:24braewoodsi want to see if increasing the buffer size for UMS mode will help with the slow write speeds at all
13:18:45braewoodsi doubt it but it can't hurt to try increasing it for a special test build
13:18:47bluebrother^braewoods: I have an idea how we could approach this. Need to give it some thought though.
13:19:01bluebrother^wasn't an issue the last 10+ years. Nobody released new bootloaders :)
13:19:02braewoodsbluebrother^: sure. take your time. i just updated the existing method.
13:19:09braewoodsin git
13:19:26braewoodsbut it needs a new build to propagate.
13:19:35braewoodsin either case that will be true
13:19:50braewoodsbluebrother^: here's what i know. the only part you can hard-code is the hashes for the OF.
13:19:51bluebrother^btw, I've been wondering if we should retire fwpatcher.
13:20:04braewoodsi'm not a fan of it but i patched it up to work.
13:20:06 Join prof_wolfff [0] (
13:20:23braewoodsthough i can't see why it would be useful in this day and age.
13:20:25bluebrother^well, usually you shouldn't use fwpatcher anymore since Rockbox Utility can do the work :)
13:20:29braewoodsrbutil does the same thing.
13:21:15braewoodsbluebrother^: 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:47braewoodsthey can both be pairs in a file
13:21:50braewoodshash:hash or so
13:21:54bluebrother^we already have bootloaders/bootloader-info
13:22:22bluebrother^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:32bluebrother^and the scripting creating build-info would simply append that.
13:23:16bluebrother^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:18braewoodsthis is mainly an issue due to how we install the bootloaders on these units
13:23:29speachythere's already a 'bootloaders-info' file on d.r.o
13:23:47bluebrother^speachy: right, but I'd prefer that to be part of build-info
13:24:00braewoodsi don't care how we do it, just want to get these out to people.
13:24:00bluebrother^is that file generated dynamically? We could have those hashes in git.
13:24:08bluebrother^and simply cat them together
13:24:19speachyno idea how it's supposed to be auto-generated, and that file doesn't match the build-info syntax
13:25:04bluebrother^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:09bluebrother^I'd change the format a bit.
13:25:25braewoodsbluebrother^: do what you need to do. let me know if you need anything from me.
13:25:35braewoodsjust needs to be easier to release bootloaders.
13:26:04braewoodsi mean, cutting the release will work fine this time i guess, but should we update the approach?
13:26:37bluebrother^well, the question is how long Rockbox will continue to live :P
13:26:48braewoodsit's lasted this long.
13:27:05braewoodsmay as well plan for it to last for another 10 years at least.
13:27:26bluebrother^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:38speachyrockbox will live as long as folks like us are crazy enough to keep it going.
13:28:01braewoodsi've already got people clamoring for the updated bootloader.
13:28:10bluebrother^true. But where will the world be in 10 years? And will there still be hardware?
13:28:22bluebrother^anyway, just asking. I'm not against updating things.
13:28:24braewoodswho really knows?
13:28:38bluebrother^let's guess ... nobody? ;-)
13:28:41braewoodsit may not matter but we'll be glad if it does end up helping us in the future.
13:28:58bluebrother^indeed. And it could be a nice programming exercise ;-)
13:29:47bluebrother^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:53speachywell, 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:30bluebrother^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:53bluebrother^speachy: true to that :)
13:31:08braewoodsi'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:12braewoodsas it stands RB would mainly be limited to being on the output end of it
13:32:24speachya better question is if there will ever be any new native targets.
13:32:25braewoodsprobably doable though
13:32:40braewoodsquite possible but we may have to design it ourselves
13:33:01braewoodsthat would probably make a good kickstarter project though
13:33:13speachywe barely have the resources to maintain the status-quo, new hardware is going to take a lot of work.
13:33:55braewoodsif we had kernel sources to one that ran Linux we could probably find a way to replace the kernel
13:34:18braewoodsas an alternative
13:34:29speachywe kinda do on the fiio m3k, at least. I'd be willng to bet the Sony players have full kernel sources too.
13:34:58braewoodsi 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_bilgusplenty of those
13:35:37braewoodssome are unlikely to be solved due to missing datasheets
13:35:49braewoodsthe ones i intend to focus on are the ones that are actually realistically possible
13:35:58braewoodsusually due to documentation
13:36:20braewoodsthe OTG for the h300 is probably possible to implement
13:36:21speachyI'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:46braewoodsultimately we'd need a some kind of casing to put it all in
13:36:50speachyincluding schematics and full source code for everything including the bootloader.
13:37:05braewoodsis that something pine could also provide?
13:37:40speachythat'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:38:19braewoodsspeachy: i guess my suggestion was a good one?
13:38:29braewoodsthey were the only ones i could think of that have practical experience in this area
13:38:39speachythey like rockbox, but they don't know if the economics would be worthwhile.
13:39:03braewoodsmaybe it goes nowhere but i kinda noticed that we're running out of hardware targets for new stuff
13:39:17braewoodsso maybe the only viable option left for native is DIY
13:39:24speachythe newer chinese DAPs are touchscreen monstrosities built mostly on android now.
13:40:09speachywith a few exceptions, but we're not likely to see something new in the price point of the AGPTek Rocker.
13:40:30braewoodsit would probably be fine if we had kernel source
13:42:22speachyI'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_bilgusok moved to hilbylinux re compiling now
13:43:39braewoodsthink i'm going to use 4K buffers for MTP for now
13:43:45braewoodsi just need to choose something.
13:44:01braewoodsit can be adjusted later
13:45:04braewoodsspeachy: 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:40braewoodsthe datasheets imply a limit on that.
13:45:40braewoodsno idea honestly though
13:45:40speachybraewoods: generally speaking, yes, it's only one "advanced" function at a time.
13:46:08gevaertsNot just that. I suspect too many at a time would also confuse everyone
13:46:25braewoodsindeed. we'll probably want to make MTP and UMS mutually exclusive so as to conserve the resources.
13:46:38braewoodsUMS uses 2 endpoints, MTP uses 3.
13:47:07speachyno, they need to be mutually exclusive.
13:47:33braewoodsok. i thought i was agreeing though for different reasons.
13:52:24borkitallokay i left the h320 charging overnight
13:52:32borkitallits in bootloader usb mode
13:55:22gevaertsYou do have USB_NUM_ENDPOINTS to look at. Looks like nothing has fewer than 3
14:02:05bluebrother^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:35bluebrother^so tools like ipodpatcher, mks5lboot etc.
14:03:59speachynot a fan of cmake, and I thought the choice of qmake was driven by rbutil being qt-based?
14:04:13bluebrother^yes, but Qt also moves to cmake.
14:04:28bluebrother^and to be honest, cmake is a lot more advanced than qmake these days.
14:04:45speachysure, mirror what upstream uses
14:05:00bluebrother^having qmake generate a Makefile that calls other hand written Makefiles is ... well, fragile.
14:05:20borkitallthe new battery is reporting 4.12v, is this normal for a new battery? its 3.7v 1700mAh
14:05:29braewoodsborkitall: yes
14:05:30bluebrother^but since we're using a Makefile generator I figure it doesn't matter too much if it's qmake or cmake.
14:05:46braewoodsborkitall: voltage is used to estimate how full the battery is
14:06:33borkitallstill getting used to irc
14:08:24speachybluebrother^: I just don't want to have to rely on cmake to build anyting used by the main rb builds.
14:08:37speachybut if it makes sense to ditch qmake, so be it.
14:09:02bluebrother^yeah, would be only stuff in rbutil/ and utils/
14:09:12bluebrother^plus, I'm planning to merge those two folders.
14:09:31bluebrother^since having a separate rbutil/ doesn't make too much sense anymore these days.
14:10:05***Saving seen data "./dancer.seen"
14:10:07bluebrother^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:36braewoodsspeachy: we may have a problem. i just tried to run a development build on my H10 and it freezes.
14:10:50braewoodsand now it's getting system files stuff. i'll need to wipe it again.
14:11:14braewoodsi wonder if PP devices are bugged?
14:11:16speachybraewoods: assmuming the 3.15 release worked, I'd try the oldest daily build as a sanity check first.
14:11:39speachythe ipods work, at least...
14:11:45braewoodsalso oddly there's a weird different from RB UMS and the proprietary UMS mode
14:11:59braewoodsthe total sector count is one less in RB mode
14:12:26braewoodssdc: p1 size 62453633 extends beyond EOD, enabling native capacity
14:12:30borkitallso if i understand this, 1.7A is the max i should use with a 1700mAh battery
14:12:32borkitallat 5v
14:12:33braewoodsis the error resulting from it
14:12:48braewoodsborkitall: eh? you mean for charging?
14:13:06braewoodsdischarge rate is heavily defined by the battery
14:14:28borkitalli dont care about the discarge rate
14:14:51borkitalljust would like to know what charging to use, as i dont know where the stock charger is
14:15:13borkitallsorry if im unclear
14:15:29braewoodsborkitall: well
14:15:39braewoodsyou can get by with usb barrel jack adapter
14:15:43braewoodsor just charge over usb
14:16:30braewoodsi know the H320 and H340 use the 4mm barrel jack
14:16:51speachyso rb reports an odd drive sector size?
14:16:52braewoodsone example
14:17:10braewoodsspeachy: yes. it's one less than the max size reported when i'm in the iriver UMS
14:17:32braewoodsspeachy: i worked around it before by making my partition slightly smaller
14:17:52braewoodsnot sure what the issue really is, if any
14:17:52speachythis is h10? h1xx?
14:17:58braewoodsspeachy: H10
14:18:09braewoodsit happened before I performed the CF mod
14:18:19braewoodsas well
14:18:26braewoodsmaybe this unit is just iffy
14:18:41borkitallbraewoods: thanks yeah i got one of those
14:18:50speachyI'd be curious to see what the actual drive reports.
14:19:03braewoodsi can't open it to find out. one of the screws got stripped
14:19:12speachydump the identify info
14:19:15speachyit'll be in there.
14:19:29braewoodsi'll check it out after i repair it
14:19:56braewoodsi'll check my other H10 to see if it has the same inconsistency
14:20:05braewoodsi forgot about it until recently
14:24:28speachybraewoods: it _appears_ that total sector reported is lifted straight from the drive.
14:24:47braewoodscould it be iriver is reporting it wrong?
14:25:00speachycould be.
14:25:02braewoodsanyway i'll check what i find out.
14:25:20speachythe identfy info will be authatorative.
14:28:48braewoodsno issue on H320
14:29:12braewoodsseems to be an H10 bug
14:42:19_bilgus3044 has a few bug fixes I'll try to get it fleshed out a bit more this evening and incorporate any new suggestions
15:02:59 Join Rower- [0] (
15:04:36 Quit Rower (Ping timeout: 240 seconds)
15:42:54Strife89speachy: 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:25Strife89(Other than the Kingspec 1.8" line, which gets expensive for the 128 GB model.
15:43:43speachynope. 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@
15:44:17Strife89Well shoot
15:45:08Strife89And 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@
15:52:44 Quit Bilgus_ph (Client Quit)
16:01:38 Join ac_laptop [0] (~ac_laptop@
16:09:43braewoodsStrife89: you have an H320?
16:09:51braewoodsStrife89: how'd the new bootloader work for you?
16:09:53 Quit Rower- ()
16:10:09***Saving seen data "./dancer.seen"
16:11:13Strife89Flashing it and rebooting went well!
16:12:00 Quit Acou_Bass (Quit: ZNC 1.8.1 -
16:12:27braewoodsStrife89: great. so you want flash storage?
16:12:41Strife89I do
16:13:11Strife89TBH I'm just window shopping right now, though. Money's tight.
16:13:21braewoodsI used those CF card adapters when I modded my H120.
16:13:38braewoodsthey need a bit of work as the jumper is too tall.
16:13:48braewoodsbut it's probably your best option
16:13:56braewoodssome kind of CF card or an adapter
16:14:14braewoodsin either case speed isn't going to incredible
16:14:25braewoodsi saw my CF card max out at 13 MB/s when doing block operations
16:14:33braewoodsbut it's better than many RB targets
16:15:00braewoodsStrife89: how much storage you wanting?
16:15:13braewoodsthe most economical is probaly SD cards
16:15:17Strife8960-100 GB would be best
16:15:33braewoodsyou can find 64GB CF cards for around $30 used lately
16:15:38Strife89(so a 64 or 128 GB SD/CF card, probably)
16:15:44braewoodsthat and the adapter is around $40
16:16:36braewoodsi've seen kingston cf cards for around $60-80 for 128GB or more
16:16:48braewoodsbut at that point SD cards start to sound better
16:16:54Strife89I 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:13braewoodsthe SD card adapters are also hit or miss
16:17:16Strife89I have speachy to thank for getting it to behave in Rockbox
16:17:38braewoodsthe best option is true CF cards with a passive adapter if you want any guarantees about stability
16:17:39 Join Acou_Bass [0] (
16:18:10braewoodswhat continent you on?
16:18:13braewoodsi'll see what i can find
16:18:36Strife89North America (southeastern United States)
16:19:38braewoodsok, kingston canvas focus is the cheapest CF card for 128GB
16:20:21braewoodsor here
16:20:33braewoodsor 256GB for $60
16:20:43Strife89That's pretty good
16:21:13Strife89Any known-good CF adapters still out there?
16:21:32braewoodsfor your h320
16:21:41braewoodsthe easiest is the 50 pin one that's entirely passive
16:22:14braewoodsthis for example
16:22:22braewoodsbut you'll need to modify it slightly to use it in H320
16:22:41braewoodsthe jumper is too tall
16:22:49braewoodsyou have to find a way to solve that
16:23:09braewoodsjumper needs to be closed/bridged to avoid issues with the adapter
16:23:13braewoodsyou can bend it over
16:23:20braewoodsand somehow bridge it
16:23:32braewoodscut it and solder the pins
16:23:38braewoodsanything to reduce the overall height
16:23:54braewoodssince it's purely passive there's very little that can go wrong.
16:24:01braewoodsmain reason i prefer it
16:25:15Strife89I'll keep that for later, thanks!
16:25:48braewoodsyou may also need to clip off the plastic tabs
16:25:55braewoodson the unit
16:26:00braewoodsi mean
16:26:19braewoodsit got in the way when i installed the one in my h120
16:26:35speachyis that an LED on the pcb?
16:26:49braewoodsmaybe but it's not populated
16:27:16braewoodsoh, you mean the ZIF adapters?
16:27:40braewoodsStrife89: i prefer the 64gb cards. i don't need more storage.
16:29:53Strife89I'm a data hoarder :P
16:30:13Strife89And I, uh, acquire lots and lots of video game soundtracks
16:30:18braewoodsI see.
16:30:43braewoodseither way the CF cards should give a modest speed boost over the original hard drive
16:31:03braewoods13 MB/s is the fastest i've ever gotten over UMS on any RB target
16:31:16braewoodsi got that on a gogear HDD1630 after upgrading to a CF card
16:31:34Strife89Sounds pretty good, overall
16:31:53braewoodsand also on the H120
16:32:00braewoodsi assume the H320 will also achieve similar speeds
16:32:06braewoodssince it uses the same ATA/USB stuff
16:32:45braewoodsi'm going to try some experiments, see if increasing the UMS write buffer helps IO at all
16:32:48braewoodsincrease it to 64k
16:33:10Strife89I'm more worried about power saving and shake/impact resistance anyway :)
16:33:18braewoodsyou got that in spades
16:33:23braewoodsCF cards also tend to be faster
16:33:28Strife89But faster r/w speeds will definitely be nice, too
16:33:34braewoodsmeans faster syncing
16:33:46braewoodsbut it seems to me that the real world speeds differ heavily
16:33:54braewoodsthe iriver H10 has terrible write speeds
16:33:59braewoodsbut i've seen 20+ MB/s read speeds
16:34:10Strife89and faster seek times, of course
16:34:14braewoodsbut it caps around 4-5 MB/s write
16:34:28braewoodskinda weird considering it was a CF mod
16:34:38braewoodsthe card it has can do 10 mb/s in a regular usb adapter
16:34:48braewoodsthe card isn't the bottleneck
16:34:50braewoodssomething else is
16:35:56braewoodsStrife89: it's entirely optional but you may want to replace the OF before doing the CF mod
16:36:11braewoodsthe OF is worthless in a CF modded H320 anyway since it doesn't like them
16:36:12Strife89As in flashing Rockbox
16:36:23braewoodsthat's a new feature of the V8 bootloader
16:36:34Strife89Oh good, I was hoping so
16:36:46braewoodsit works, i tested it during my trial runs before release
16:36:57braewoodsi ported over the code used in the H100
16:37:44braewoodsbut that was one reason I did my development on a non-modded H320
16:37:50braewoodsi needed the OF to recover from bad flashes
16:38:16braewoodsit was broken for a long time, the bootloader
16:38:57braewoodsturned out someone added code to switch the H300 LCD code to using DMA but that broke the bootloader
16:39:15braewoodsso i had to port the old method of updating it so the bootloader would work again
16:40:44braewoodsincidently 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:12braewoodsgood if the main bootloader payload is somehow unable to boot
16:46:06 Join Acou_Bass [0] (
16:58:43 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
17:29:31braewoodsspeachy: can you read schematics?
17:37:46braewoodsi was trying to find a new battery for my hdd1630 but the existing ones are too tall.
17:37:58braewoodseven though they claim to be compatible they don't fit the case
17:38:15braewoodsso i'm trying to find one that fits the case and terminal and has the same pin out
17:38:26braewoodsso how do i determine my existing pin out?
17:38:30braewoodsor is that standardized?
17:38:32speachyfor the battery?
17:38:37braewoodsand the terminal
17:38:49braewoodsi have the board schematics for the header
17:38:54speachythere's no inherent standard, although I have yet to see one of those batteries where red wasn't + and black -.
17:39:04speachysometimes there's a sense line too, typically white or yellow
17:39:14braewoodsthe HDD1630 is 3 pin
17:39:37 Nick mendelmunkis is now known as mendel_munkis (
17:39:41braewoodsU502 is the battery part
17:39:47braewoodsi think it's saying...
17:40:03braewoodspin 1 is connected to ground?
17:40:16braewoodspin 2 goes to BAT_P
17:40:24braewoodspin 3 is BAT_P
17:40:42braewoodssorry, i suck at reading these.
17:41:34braewoodsi can use a multimeter to figure out which battery terminals are what
17:41:49speachyokay, pin 1 is ground, pin 2 is positive, pin 3 is sense
17:42:00braewoodsok. thank you.
17:42:24braewoodsthat's what i thought
17:43:03speachyyep, in the photo it's clearly blk-red-wht
17:44:11speachyyou may or may not be able to find a battery with the right size/type connector.
17:44:48braewoodsit is what it is but i figured the ipod mini would be a good place to check
17:44:53speachy(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:21braewoodsit's closest to the ipod mini in terms of size
17:45:32braewoodsalso uses microdrive
17:51:02braewoodsyea it matches the known viable replacement
17:51:11braewoodsonly flaw is it doesn't fit the case too well
17:51:30braewoodsi guess there's always plan B
17:51:45braewoodsfind an alternative that fits and just reterminate the battery connector
17:51:57braewoodsthough not what i'd prefer to do. lol
17:54:12braewoodsipod mini battery would probably fit but the pins don't look right
17:54:29braewoodsdifferent layout
18:10:13***Saving seen data "./dancer.seen"
18:19:46 Part borkitall
18:45:23braewoodsspeachy: you said the pins were easy to swap. how would you do so? what tools?
18:45:48braewoodsi'm guessing these batteries are 1.25mm jst but i can't even find what tools you'd use to terminate these
19:03:56braewoodsfound it i guess
19:04:13braewoodsguess my best bet is to find a battery and swap the pins
19:04:17braewoodsdidn't realize you could do that
19:06:22 Join borkitall [0] (
19:06:41speachyif 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:16speachythere'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 -
19:19:44 Join Acou_Bass [0] (
19:19:44braewoodsspeachy: i saw that in a video
19:52:43 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
19:52:59 Join fs-bluebot_ [0] (
19:55:36 Quit fs-bluebot (Ping timeout: 260 seconds)
19:56:36 Quit bluebrother^ (Ping timeout: 272 seconds)
20:00:10 Join thanevim [0] (
20:03:31thanevimHi 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:41thanevimFor 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] (
20:41:55braewoodsthanevim: can you be more specific about the message?
20:43:01thanevimThe message itself reads "No partition found. Insert USB cable and fix it."
20:43:23thanevimThis is a Fuze v2 2GB model for the record
20:43:55braewoodsit means it can't find the partition rockbox is on
20:44:03braewoodsall the bootloaders say something similar if that happens
20:44:54thanevimThat 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:19thanevimIt 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:02thanevimRegardless, it would at least be nice if there's a fix that doesn't require loading from microSD if possible
20:47:16braewoods_bilgus: may know more as i believe he was working on sansa bootloaders
20:47:35braewoodsi'm not really familiar with those targets too well
20:47:54braewoodsi mostly focus on HDD units
20:48:04braewoodslike the iriver h100 and h300
20:48:18thanevimUnderstandable. I'll wait for bilgus to speak, and post in here if I find anything
20:49:54_bilgusthanevim, that message just means rb folder is missing
20:51:11_bilguswhen you plug usb does it mount the internal drive?
20:51:43thanevimNot inside that bootloader, but once you said that, I rebooted the original, and it does show internal memory that contains .rockbox/
20:51:48_bilgusif so download the dev version for your device and copy the .rockbox folder from the zip to the device drive
20:51:50braewoodsthanevim: 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:23thanevimThat makes sense, given these things are ~10 years old
20:52:37braewoodsthe sd card can be replaced
20:52:43braewoodsyour internal storage, not so easily if at all
20:53:09thanevimYeah.. I remember trying to no avail in my first sansa...
20:53:20braewoodspart of why i don't bother with RB targets that only have intenrla storage you can't replace
20:53:20_bilgusagain use a dev version same idea just copy .rockbox to the root of the sd car formatted to FAT32
20:53:34thanevimOk, I'll try that now
20:55:54braewoodsfrom appaearances the fuze v2's battery is soldered
20:56:02braewoodsthose can still be replaced but you need the right tools
20:56:23braewoodsif you need help hunting for a replacement battery let us know
20:56:33thanevimAppreciate it
20:57:08braewoodsthough if there was room i'd want to solder a battery header. lol
20:57:29thanevimThat'd makes sense, to prolong life
20:57:44braewoodsyea. desoldering can damage the PCB and such.
20:57:54braewoodsso if you can, it's best to resolder a socket or header.
20:59:55thanevimBooted the dev version, still seeing Incompatible version for the applets/games/etc
21:00:55braewoodsdid you copy it to both the internal and SD card?
21:01:34_bilgusno just one or the other but you can do both
21:01:52braewoodswell if it works it would tell us something
21:02:10_bilgusif you ar egetting incompatible version message the you need to rename the folder and try again
21:02:23braewoodsor that
21:02:32_bilgusdon't delete rename it and copy again
21:02:40thanevimIt 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_bilgusthat makes sure it gets coppied to a new location
21:03:14thanevimAnd the original firmware is currently hanging on Refreshing your media
21:03:30_bilgusthe internal flah dying is entirely possible thats why I made the boot from sd option
21:06:26mendel_munkisis there a list of which targets support which key combos?
21:07:04mendel_munkis(if any)
21:08:54thanevimThanks 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:17braewoodslooks like 602040 battery is my best option
21:30:36braewoodsspeachy: i'm finding it hard to find batteries with the third wire for the sensor. is it essential?
21:55:54speachyI would assume so.
21:57:19speachythat'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:36speachyor charging might not work. or it might overcharge. or..
22:01:04speachydepends on how the BQ4032 (ie the battery charger IC) works.
22:01:22speachyer. BQ24032
22:04:58speachyd'oh, that's the temperature sense. looking at the datasheet, without the TS connected, it won't charge the battery.
22:05:52speachy(to use it with a 2-wire battery you'd need to modify the circuit slightly.
22:08:18speachythat pin needs to be in the 0.5->2.5 range. (+-3%)
22:08:29speachy2.5v, that is
22:09:01_bilgusbraewoods, the third wire can be bypassed with a sutible resistor
22:09:32 Quit ac_laptop (Ping timeout: 260 seconds)
22:09:47_bilgusyou'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:29speachyit's connected to vcc.
23:03:38 Join ac_laptop [0] (~ac_laptop@
23:31:08 Quit Xeha (Ping timeout: 256 seconds)

Previous day | Next day