| 00:09:21 | fs-bluebot_ | Build Server message: Build round completed after 728 seconds. |
| 00:09:24 | fs-bluebot_ | Build Server message: Revision 2eb191a3f4 result: All green |
| 00:10:41 | speachy | huh, looks like these improved build times are solely due to getting rid of the excessive logging in th upload cgi script |
| 00:11:27 | _bilgus_ | wow quite a difference |
| 00:12:06 | fs-bluebot_ | Build Server message: New build round started. Revision 6b3b4df6f6, 293 builds, 9 clients. |
| 00:12:12 | speachy | (resulted in a substantial upload speed difference from my colocated builder) |
| 00:12:52 | speachy | that and ccache resulting in nothing actually changing for most of the builds. :) |
| 00:13:22 | speachy | hopefully tonight's manual and voice builds will be problem-free |
| 00:14:04 | _bilgus_ | any way to make it do full builds once a day or every n builds? |
| 00:14:25 | _bilgus_ | like remove the cache |
| 00:14:38 | speachy | we could, but I don't see the benefit |
| 00:14:50 | speachy | ccache has proven to be quite reliable |
| 00:15:20 | _bilgus_ | I figure it might catch weird hard to find compat issues |
| 00:15:42 | _bilgus_ | but I'll defer to your trust in it |
| 00:16:58 | speachy | I still want to push manual generation to the builders, to be done on every commit |
| 00:17:41 | speachy | voices still are best done centrally, though rewriting teh script to use more than one CPU would help. |
| 00:17:54 | _bilgus_ | what will that solve just lazy manual building current? |
| 00:18:48 | _bilgus_ | I wish we could just supply code to do it at user level |
| 00:18:57 | speachy | Reduction of special cases. |
| 00:19:06 | speachy | "to do it" ? |
| 00:19:19 | _bilgus_ | voices |
| 00:20:22 | _bilgus_ | like in rbutil on their hardware |
| 00:20:46 | speachy | up until recently, if you were't using english, rbutil was the only practical choice. |
| 00:21:19 | _bilgus_ | oh it already allows that? |
| 00:21:22 | speachy | but the central voice thingey uses ./configure to do everything |
| 00:22:22 | _bilgus_ | sorry rbutil is not a thing I use |
| 00:23:04 | speachy | builds.pm includes the languages and settings we use for the various TTS engines. |
| 00:23:33 | speachy | more are certainly possible but I only speak English and Bad English, so I'm not exactly a good judge of what sounds usable. |
| 00:24:07 | fs-bluebot_ | Build Server message: Build round completed after 722 seconds. |
| 00:24:10 | fs-bluebot_ | Build Server message: Revision 6b3b4df6f6 result: All green |
| 00:24:22 | speachy | if you want voiced filenames/etc too, rbutil is much simpler than the cmdline scripts |
| 00:24:52 | _bilgus_ | braewoods, your things in |
| 00:28:42 | | Join _bilgus [0] (~bilgus@2603-6011-c806-2b0c-0527-d970-c1c7-2800.res6.spectrum.com) |
| 01:00 |
| 01:32:02 | | Quit massiveH (Quit: Leaving) |
| 01:54:44 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:39:59 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 03:54:45 | *** | No seen item changed, no save performed. |
| 04:00 |
| 04:54:04 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 05:00 |
| 05:17:03 | | Quit borkitall (Quit: borkitall) |
| 05:31:42 | bluebrother | current Rockbox Utility main screen: https://imgur.com/a/ziAnEQH |
| 05:32:33 | bluebrother | voice language is currently fixed to english, but right now does the same thing as we had before. Language selection support to follow. |
| 05:54:47 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:07:38 | | Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 06:09:51 | johnb7 | speachy As for the HifiWalker firmware: if youf feel they could have actually changed some hardware components, then I should not try to circumvent the name string ... |
| 06:11:02 | johnb7 | Anyway, I posted questions on their f...book homepage. Maybe they are more inclined to answer there. |
| 06:17:16 | | Quit johnb7 (Ping timeout: 246 seconds) |
| 06:34:18 | braewoods | _bilgus_: thanks |
| 07:00 |
| 07:06:59 | | Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 07:32:10 | | Quit johnb7 (Ping timeout: 246 seconds) |
| 07:54:49 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:22:54 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 08:34:44 | speachy | johnb7: The hardware rev possibility is because the Eros Q II looks identical, except for a slightly thicker case. |
| 08:34:54 | speachy | and has incompatible guts. |
| 08:35:22 | speachy | and there's a possibility that the v1.3 is based on the newer Q II. |
| 08:35:51 | speachy | (the Q II is not based on a HibyOS platform, so the SW load wouldn't work anyway) |
| 08:35:59 | | Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 08:36:57 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 08:37:04 | johnb7 | I see |
| 08:41:59 | speachy | (but I doubt it, given that it tries and fails to do the update, which at least implies hibyos is in use) |
| 08:42:11 | speachy | the point is thought that we don't know what we don't know. |
| 08:43:53 | | Quit johnb7 (Ping timeout: 260 seconds) |
| 08:44:38 | fs-bluebot_ | Build Server message: New build round started. Revision 1b9eebb39d, 293 builds, 9 clients. |
| 08:46:02 | bluebrother | speachy: can you put the iriver v8 bootloaders to bootloader/iriver/8.0 ? Right now the bootloader installation doesn't work anymore since the checksums don't match :) |
| 08:46:24 | speachy | braewoods: ^^^ |
| 08:46:39 | speachy | I'll put the files up when I have 'em. |
| 08:47:02 | braewoods | speachy: like i said before: braewoods.net/iriver-bootloaders.zip">https://braewoods.net/iriver-bootloaders.zip |
| 08:47:19 | bluebrother | ah, that's the problem :) |
| 08:47:38 | braewoods | i put them there until they could be made official |
| 08:48:14 | bluebrother | crap. Seems I lost my template for build-info. Didn't save the file :/ |
| 08:49:11 | speachy | they're up. |
| 08:50:09 | bluebrother | thanks |
| 08:50:22 | braewoods | we can drop fwpatcher at some point but for now i guess it needs to stay |
| 08:50:50 | braewoods | at least until rbutil is more polished |
| 08:50:56 | braewoods | about how to handle this situation |
| 08:51:28 | braewoods | regarding the script it uses for checksums... |
| 08:51:42 | braewoods | i setup the local files needed to make it work |
| 08:51:46 | braewoods | what a pain that was |
| 08:51:56 | braewoods | i'm tempted to archive that for future updates |
| 08:54:42 | bluebrother | as in calculating those checksums? |
| 08:55:12 | braewoods | bluebrother: yea. perl script in the fwpatcher directory is used to generate the checksum table compiled into it or rbutil. |
| 08:55:13 | bluebrother | and what polishing you're missing apart from reading the before-after checksums from some file? |
| 08:55:40 | bluebrother | those aren't simple md5sums? |
| 08:55:40 | braewoods | that's it afaik. i was waiting for a solution to the hard-coded checksum issue to be implemented. |
| 08:55:46 | braewoods | they are md5sums |
| 08:55:48 | braewoods | afaik |
| 08:55:58 | bluebrother | ah. So now the bootloaders will work again with current git. |
| 08:56:01 | fs-bluebot_ | Build Server message: Build round completed after 682 seconds. |
| 08:56:03 | fs-bluebot_ | Build Server message: Revision 1b9eebb39d result: All green |
| 08:56:04 | fs-bluebot_ | Build Server message: New build round started. Revision e8f8df4ee0, 293 builds, 9 clients. |
| 08:56:25 | braewoods | but you can check the script to be sure or w/e |
| 08:56:28 | bluebrother | I was thinking about finishing up some leftovers and then try to get Rockbox Utility 1.5.0 done. |
| 08:56:47 | bluebrother | and leave that hardcoded checksums as well as the sudo issue for 1.6.0 |
| 08:56:49 | braewoods | but i still had to setup the firmware archive the script needed |
| 08:57:03 | braewoods | that's what was the most tedious. haha |
| 08:57:28 | braewoods | we can rewrite the script to generate the new checksum files when you get around toi t |
| 08:58:04 | braewoods | that's the only part i think it worth scavenging from fwpatcher |
| 09:00 |
| 09:13:27 | fs-bluebot_ | Build Server message: Build round completed after 1043 seconds. |
| 09:13:30 | fs-bluebot_ | Build Server message: Revision e8f8df4ee0 result: All green |
| 09:43:21 | | Join johnb3 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 09:45:19 | fs-bluebot_ | Build Server message: New build round started. Revision 25529e4fe0, 293 builds, 9 clients. |
| 09:54:53 | *** | Saving seen data "./dancer.seen" |
| 09:57:12 | fs-bluebot_ | Build Server message: Build round completed after 713 seconds. |
| 09:57:15 | fs-bluebot_ | Build Server message: Revision 25529e4fe0 result: All green |
| 10:00 |
| 10:06:18 | | Join fs-bluebot [0] (~fs-bluebo@55d4acd0.access.ecotel.net) |
| 10:06:25 | | Quit bluebrother (Disconnected by services) |
| 10:06:30 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 10:07:48 | bluebrother^ | speachy: what / how I'd like to see things in build-info: https://pastebin.com/SKdJTJZT |
| 10:08:12 | | Quit fs-bluebot_ (Ping timeout: 272 seconds) |
| 10:09:16 | speachy | bluebrother^: so for the [daily] section, daily builds use a datecode in their filename, not a shash. |
| 10:09:24 | bluebrother^ | that's basically have daily / dev builds use the same format as for releases. Rockbox Utility will also allow an optional url appended, which, if present, will take precedence. |
| 10:09:37 | bluebrother^ | daily could also stick to the date. |
| 10:09:54 | speachy | I think that's preferable, since you can't really tell at a gaance what date a given hash corresponds to |
| 10:10:03 | bluebrother^ | true. |
| 10:10:21 | speachy | (plus that whole alphabetical sorting thing.. :) |
| 10:10:49 | bluebrother^ | sorting? Who needs sorting? :P |
| 10:12:07 | speachy | I like the new [development] and [daily] sections. especially the dev stuff; as sometimes a build fails and there's no way to capture that a given target might not be on the same rev as the others. |
| 10:12:24 | speachy | (actually that's not captured on the bleeding edge main www site either) |
| 10:13:13 | _bilgus | woot finally have the toolchains installed again |
| 10:13:15 | speachy | I can get the [daily] knocked out this evening, |
| 10:13:17 | | Quit vup (Quit: vup) |
| 10:13:58 | | Join vup [0] (~~~~@46.101.193.235) |
| 10:13:59 | speachy | fixing [development] to reflect the true state of successful builds is another matter. |
| 10:14:22 | speachy | should be able to get something usable by tonight. |
| 10:15:16 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 10:15:42 | bluebrother^ | great. Right now having [daily] work is my next goal, so I can add support for daily builds. |
| 10:15:57 | bluebrother^ | then people will be able to install our voices :) |
| 10:16:58 | bluebrother^ | and once the rest is in place adjust things for the development stuff. Works right now (since it's been like that anyway), but I'd like to avoid introducing another special case for daily builds :) |
| 10:17:47 | speachy | with respect to the [bootloader] section, I think we should have explicit player = filename,hash |
| 10:18:10 | speachy | or somethign like that |
| 10:18:55 | bluebrother^ | I'm fine with that too. Currently the filenames are hard coded in rbutil.ini, but getting that from the server might be a good idea. Less stuff hard coded in Rockbox Utility = good :) |
| 10:19:04 | speachy | think it's worth putting in a format string for the URLs too? |
| 10:19:24 | bluebrother^ | but maybe use player = hash,filename so it uses the same order as the rest? |
| 10:19:50 | bluebrother^ | if we have the URLs as part of the config we wouldn't need a format string here, right? |
| 10:19:57 | speachy | eg voices.dailyurl = https://d.r.o/daily/%target%/voice-%target%-%lang%.zip |
| 10:20:15 | bluebrother^ | ah, for that part. |
| 10:20:20 | bluebrother^ | forgot about this case :) |
| 10:20:32 | speachy | (I intend to put explicit URLs for everything) |
| 10:21:50 | bluebrother^ | hmm. how about using release/voiceurl = ... instead? |
| 10:22:22 | bluebrother^ | the thing is I'm trying to look up things by going <buildtype>/<player>, so that would make it more straightforward. |
| 10:22:44 | speachy | you mean release/voiceurl = url_template ? |
| 10:22:55 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 10:22:57 | bluebrother^ | yes. |
| 10:23:04 | speachy | and daily/voiceurl = url_template |
| 10:23:07 | speachy | I like that |
| 10:23:07 | bluebrother^ | and obviously the same for daily/voiceurl, etc. |
| 10:24:13 | bluebrother^ | right now I have to go release/<player> for releases, and manually construct things for dev builds. That's why I'd like to have development/<player>. And in the same way we can add further info, like voiceurl |
| 10:24:37 | bluebrother^ | you can check the template format I'm currently using in rbutil/rbutilqt/rbutil.ini |
| 10:24:54 | bluebrother^ | just introduced a similar split there. |
| 10:25:55 | bluebrother^ | hmm, why did I put a url for dev voices in there? We don't have that. |
| 10:26:01 | bluebrother^ | but it's filtered in the UI anyway. |
| 10:26:42 | bluebrother^ | though checking if we get a valid url might be better. In case that changes at some point in the future. |
| 10:30:51 | | Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 10:31:27 | _bilgus | johnb have you tried mb on the CLip+ was anything relatively recent? |
| 10:31:47 | _bilgus | https://forums.rockbox.org/index.php/topic,51844.msg247371.html#msg247371 |
| 10:31:52 | johnb7 | let me check |
| 10:32:13 | _bilgus | I can't reproduce with the old bootloader of the (self compiled new one) |
| 10:32:50 | _bilgus | also speachy just to be sure we didn't upload a new bootloader to DRO? |
| 10:34:40 | _bilgus | yeah I just verified its the one from 2019 for sure maybe he compiled his own bootloader for some reason |
| 10:35:38 | _bilgus | I guess we could have broken something in the main FW in the past days I'll try a daily instead of whats in my tree |
| 10:36:22 | johnb7 | I have it running on 7c498b9043-201030 |
| 10:36:37 | johnb7 | I will check with the dev build |
| 10:36:43 | speachy | _bilgus: the iriver h1xx/h3xx only |
| 10:40:49 | johnb7 | works fine for me |
| 10:41:37 | _bilgus | johnb thanks, I'll try rebuilding the bootloader from head just to be sure |
| 10:41:56 | _bilgus | I guess we will have to wait to hear from him |
| 10:42:00 | _bilgus | them |
| 10:42:26 | _bilgus | probably just an error in the redirect file it is rather rigid |
| 10:51:52 | braewoods | ok. think i know what my next project will be. |
| 10:52:03 | braewoods | putting mtp on hold for now since i can't test it right now |
| 10:52:11 | braewoods | i'll look into the OTG chip on the H300 |
| 10:52:32 | braewoods | luckily there's linux kernel source for it so i can at least compare notes about it. |
| 10:53:14 | johnb7 | _bilgus: I attached a sample redirect file to the post ... |
| 10:59:02 | _bilgus | thanks I'm still rebuilding just to be sure |
| 10:59:05 | speachy | bluebrother^: oh, will the next version be https-enabled? (including templates) |
| 11:00 |
| 11:09:02 | _bilgus | ok so something is afoot I can reproduce what he is reporting now just need to figure out why |
| 11:13:47 | speachy | so can anyone with a fuze+ look at/comment on fs#13020 ? |
| 11:13:49 | fs-bluebot | https://www.rockbox.org/tracker/task/13020 Hissing/Static on Sansa Fuze+ (bugs, unconfirmed) |
| 11:17:58 | | Quit johnb7 (Ping timeout: 256 seconds) |
| 11:20:38 | bluebrother^ | speachy: yes. |
| 11:25:41 | speachy | bluebrother^: does rbutil care about source downloads too? |
| 11:27:13 | braewoods | speachy: something that occurred to me. most rockbox targets only have one USB hardware subsystem to deal with. but the H300 has 2 technically. the Cypress chip that deals with UMS paired with another chip for USB charging. but the OTG chip is separate from that. is it possible to let cypress to continue to manage UMS for the H300 while offloading all other USB to the OTG? |
| 11:27:14 | speachy | bluebrother^: also: https://download.rockbox.org/daily/build-info |
| 11:27:58 | braewoods | hm. |
| 11:28:00 | speachy | braewoods: possible, sure, but it's going to take a decent amount of work to abstract away from the rockbox API. |
| 11:28:14 | braewoods | yea, that's the other issue. |
| 11:28:20 | braewoods | it's not enough to just make the chip work. |
| 11:28:29 | braewoods | we also need a way to make it co-exist with the other one. |
| 11:29:28 | braewoods | actually... i wonder... |
| 11:29:49 | braewoods | i'll see what i can do but i think the cypress chip does most of the work for us. i don't recall H300 actually using the UMS code we have. |
| 11:30:10 | braewoods | it may be possible to just disable our UMS on the H300 if that theory is right. |
| 11:30:54 | braewoods | either way this won't matter to the new bootloaders |
| 11:31:03 | braewoods | i wasn't planning to have OTG enabled when it is running |
| 11:31:11 | braewoods | i plan to keep it disabled like it currently is |
| 11:31:18 | braewoods | only useful once RB is booted |
| 11:33:11 | braewoods | rofl |
| 11:33:33 | braewoods | the linux kernel only implements half of the ISP1362 functionality. only so it can provide USB host functionality. |
| 11:36:05 | speachy | bluebrother^: now has voiceurl and sourceurl templates too. |
| 11:43:15 | speachy | bluebrother^: let me know if it looks sane (especially the template) and I'll implement [development] for the same way. |
| 11:54:57 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:07:44 | | Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) |
| 12:08:27 | | Quit Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in) |
| 12:10:45 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 12:11:09 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 12:11:17 | speachy | bluebrother^: also, in the [release] section, is it kosher to add a url to the entries? eg archosfmrecorder=3.15,https://d.r.o/whatever |
| 12:11:22 | thanevim | Sorry if this is terribly offtopic, but Rockbox may see a spike in new users as a result of getting shown on Techmoan's latest YouTube video |
| 12:11:50 | speachy | (will the old/existing releases use that URL or ignore it? if they use it, I guess it needs to be http not https?) |
| 12:12:04 | thanevim | Just a heads up, since he gets tens of thousands of views in each video, and this one specifically got 43k today alone |
| 12:15:59 | _bilgus_ | thanevim, cool thanks :) |
| 12:19:37 | bluebrother^ | speachy: that daily part looks good to me. Adding a manualurl= too would be good as well. And since we're adding all those a buildurl= would also make sense. |
| 12:19:44 | speachy | I'm actually adding that too. |
| 12:19:49 | speachy | buildurl pointing to what? |
| 12:20:04 | bluebrother^ | the build |
| 12:20:29 | bluebrother^ | pretty much what rbutil.ini has as build_url right now |
| 12:20:54 | bluebrother^ | so we're consistent for all downloads we do :) |
| 12:20:57 | speachy | ah, ok. |
| 12:21:19 | bluebrother^ | could even leave out the individual urls then, unless we want to / need to specify different ones depending on the target. |
| 12:21:24 | speachy | I'm adding 'manualurl=/bla-html.zip' and 'manualpdfurl="/.../bla.pdf' |
| 12:21:59 | bluebrother^ | ok. |
| 12:22:15 | bluebrother^ | not sure if we should keep having a link to the html manual though. |
| 12:22:45 | bluebrother^ | so previously I had three: pdf, zip, and html (online). Just changed that so I only have one URL, and use %FORMAT% to put in the extension. |
| 12:23:08 | bluebrother^ | are we expecting those different versions to end up in different locations? |
| 12:23:17 | speachy | I think the html manual is only useful for online browsing; otherwise pdf is far better. |
| 12:24:26 | bluebrother^ | there's one exception: screen readers. At least in the past the pdf wasn't friendly for those, which is one of the reasons why we even added the html version. |
| 12:24:47 | bluebrother^ | being able to read it online is just an additional benefit :) |
| 12:25:12 | bluebrother^ | so I've now also made a selection if you want to get the manual in pdf, zipped html, or extracted html |
| 12:25:19 | speachy | ok |
| 12:25:32 | speachy | should I use 'voiceurl' or 'voice_url' ? |
| 12:25:33 | bluebrother^ | we had a link to the online manual before. I removed that one for now, not sure if we want to keep that. |
| 12:26:12 | bluebrother^ | doesn't matter to me :) |
| 12:26:49 | speachy | well, I mean rbutil.ini uses the underscore |
| 12:26:52 | bluebrother^ | I'd vote for consistency. Apart from that I don't care too much if its whateverurl or whatever_url :) |
| 12:27:31 | bluebrother^ | yes, but I have to rework that anyway. You started without _. But using the same as in rbutil.ini could be useful. |
| 12:27:49 | bluebrother^ | but then again, since rbutil.ini is internal to Rockbox Utility I could also easily change it there. |
| 12:28:08 | speachy | nothing uses the infra side of things yet. |
| 12:28:15 | speachy | so that's easy to change |
| 12:28:27 | bluebrother^ | right. So I guess you could simply do it as rbutil does. |
| 12:31:25 | | Quit johnb7 (Ping timeout: 264 seconds) |
| 12:31:50 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 12:31:59 | fs-bluebot | Build Server message: New build round started. Revision f598ef9c27, 293 builds, 9 clients. |
| 12:32:01 | speachy | what should I use in the daily stuff? %REVISION% or someting else? (ie to map to the datecode) |
| 12:33:14 | bluebrother^ | I'd use %VERSION%, and change all others to that as well. For a daily build the datecode is the version, for a release it's the release version number. Then I can internally treat them the same. |
| 12:33:34 | bluebrother^ | rbutil.ini currently uses RELVERSION, but that's something I'd like to change. |
| 12:34:03 | bluebrother^ | there's also a bit of an inconsistency with TARGET and MODEL. I need to clean that up as well. |
| 12:34:12 | bluebrother^ | bit rot :) |
| 12:35:56 | speachy | so, um, tell me what you want it all to say, and I'll make it so on the build-info side |
| 12:36:17 | speachy | daily now uses %MODEL% and %REVISION% |
| 12:36:32 | speachy | release uses RELVERSION |
| 12:36:44 | speachy | and bleeding/development has no templates at all yet. |
| 12:36:58 | speachy | it'll have to wait until tonight though; I need to run now. |
| 12:37:45 | bluebrother^ | just use VERSION for all of those. So daily REVISION -> VERSION, release RELVERSION -> VERSION. That will simplify things for me. |
| 12:37:49 | bluebrother^ | ty. |
| 12:37:56 | speachy | ok. |
| 12:39:00 | speachy | and with templates, we can ditch the per-item URLs? |
| 12:39:08 | bluebrother^ | yes. |
| 12:39:19 | speachy | ok. I'd rather do templates in build-info anyway. |
| 12:39:53 | bluebrother^ | we'd still have the option to add them on an as-needed base. Might prove useful for release candidates (which are the ones that was originally added) |
| 12:40:14 | bluebrother^ | but if there is no per-item url we'll simply use the template. |
| 12:40:27 | bluebrother^ | so hopefully best of both worlds :) |
| 12:40:58 | speachy | need to fix/add a font package for daily builds. |
| 12:42:32 | bluebrother^ | didn't we have a fonts pack for dailies? |
| 12:42:39 | speachy | no, just a symlink to the last release |
| 12:42:49 | speachy | which is missing now. |
| 12:42:56 | speachy | gotta scoot |
| 12:42:57 | bluebrother^ | ah. Well, build-info could simply point to that file. |
| 12:43:03 | fs-bluebot | Build Server message: Build round completed after 665 seconds. |
| 12:43:10 | bluebrother^ | ok, cya |
| 12:43:13 | fs-bluebot | Build Server message: Revision f598ef9c27 result: All green |
| 12:43:14 | fs-bluebot | Build Server message: New build round started. Revision 64fe7e03a8, 293 builds, 9 clients. |
| 12:45:51 | speachy | bluebrother^: current output: http://download.rockbox.org/build-info |
| 12:46:37 | speachy | the [daily] stuff will be updated tonight. |
| 12:46:44 | speachy | [development] is all that remains. |
| 12:50:49 | _bilgus_ | cd .. |
| 13:00 |
| 13:00:26 | fs-bluebot | Build Server message: Build round completed after 1032 seconds. |
| 13:00:28 | fs-bluebot | Build Server message: Revision 64fe7e03a8 result: All green |
| 13:01:54 | braewoods | hm. |
| 13:02:06 | braewoods | interesting. the h300 schematic is rather helpful. |
| 13:02:31 | braewoods | i need to figure out how to access the ISP1362 pins to even begin to write this driver |
| 13:07:16 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 13:11:34 | _bilgus | Nope no issues with the clip+ bootloader at head or the clip+ firmware at head |
| 13:12:12 | _bilgus | I managed to fall into the trap of using linux text editors leaving a newline |
| 13:14:25 | | Quit JanC (Remote host closed the connection) |
| 13:14:48 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 13:23:27 | braewoods | hm. |
| 13:23:50 | braewoods | on iriver h300... 2 DMA channels are already used for PCM... |
| 13:23:56 | braewoods | 1 DMA channel is used by the LCD |
| 13:24:02 | braewoods | that leaves one unused |
| 13:25:25 | braewoods | isp1362 can use up to 2 DMA channels... |
| 13:25:44 | braewoods | _bilgus: how do I know if DMA is possible for a chip? |
| 13:26:20 | braewoods | the ISP1362 datasheet mentions certain of its pins... but i don't know if it is even possible to use DMA with it. |
| 13:26:28 | _bilgus | not my forte bud |
| 13:26:37 | braewoods | ok.. |
| 13:26:46 | braewoods | who could I ask then? |
| 13:27:10 | braewoods | i can always use PIO if i must but |
| 13:27:13 | braewoods | from what i can tell |
| 13:27:21 | braewoods | the isp1362 interrupt lines are connected |
| 13:27:26 | braewoods | but i don't know if the DMA pins are |
| 13:27:31 | _bilgus | wods or pamaury I imagine |
| 13:29:29 | braewoods | just looking at the driver code i realize there's a lot of time the code is spending twiddling its thumbs |
| 13:29:41 | braewoods | so i'd like to find a way to let it do other stuff if possible |
| 13:29:44 | braewoods | while waiting on the cihp |
| 13:29:46 | braewoods | chip |
| 13:30:31 | | Quit mendel_munkis (Remote host closed the connection) |
| 13:30:49 | | Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 13:34:12 | | Quit _bilgus (Remote host closed the connection) |
| 13:34:21 | braewoods | i think it's save to say DMA is probably not an option |
| 13:35:14 | braewoods | but hm |
| 13:36:05 | | Join _bilgus [0] (~bilgus@2603-6011-c806-2b0c-a4c5-a909-4cf2-6673.res6.spectrum.com) |
| 13:45:03 | braewoods | _bilgus: i think i know what i can do. i can't use the DMA pins of the chip but i can probably use the unused coldfire DMA channel to copy data from the chip when it signals that there's data to read. |
| 13:45:16 | braewoods | or so |
| 13:45:47 | braewoods | may as well. if the dma channel hasn't found a use in these 15 years i don't think it would be a problem to use it now. |
| 13:47:11 | | Join _bilgus__ [0] (~bilgus@65.186.35.190) |
| 13:47:26 | | Quit _bilgus (Read error: Connection reset by peer) |
| 13:51:47 | | Quit _bilgus__ (Ping timeout: 265 seconds) |
| 13:54:59 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:11:22 | | Join johnb7 [0] (~johnb2@p4fd10e62.dip0.t-ipconnect.de) |
| 14:21:27 | | Join _bilgus__ [0] (~bilgus@2603-6011-c806-2b0c-a4c5-a909-4cf2-6673.res6.spectrum.com) |
| 14:24:23 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 14:37:16 | | Quit Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in) |
| 14:42:59 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 14:43:03 | _bilgus__ | braewoods, what will that get you though? I guess you set upthe transfer and pool for completion later? |
| 14:44:45 | braewoods | _bilgus__: in theory but i'll look at it later. |
| 14:44:56 | braewoods | i still need to get this working first |
| 14:51:25 | | Quit johnb7 (Ping timeout: 246 seconds) |
| 14:51:54 | yang | Which iriver model is this? https://www.bolha.com/image-w920x690/walkman/garmin-kamero-jvc-kamerasony-slika-5644523.jpg |
| 14:55:06 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
| 15:00 |
| 15:09:43 | | Quit livvy (Ping timeout: 240 seconds) |
| 15:22:54 | | Quit fs-bluebot (*.net *.split) |
| 15:22:54 | | Quit lebellium (*.net *.split) |
| 15:22:54 | | Quit J_Darnley (*.net *.split) |
| 15:22:54 | | Quit Ckat (*.net *.split) |
| 15:24:10 | _bilgus__ | yang, iriver IPF? |
| 15:25:02 | _bilgus__ | sorry IFP |
| 15:25:21 | | Join fs-bluebot [0] (~fs-bluebo@55d4acd0.access.ecotel.net) |
| 15:25:21 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 15:25:21 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 15:25:21 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 15:25:42 | _bilgus__ | https://www.amazon.com/iriver-iFP-380T-128-MP3-Player/dp/B0001ZRN0O |
| 15:33:16 | | Quit Airwave (Quit: WeeChat 2.3) |
| 15:41:51 | braewoods | speachy: is USB_NUM_ENDPOINTS including or excluding the 2 control endpoints? |
| 15:46:56 | braewoods | the isp1362 technically has 16 endpoints but only 14 can be programmed |
| 15:47:06 | braewoods | so not sure which to put |
| 15:55:03 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:10:05 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 16:10:20 | | Join fs-bluebot_ [0] (~fs-bluebo@55d4b50b.access.ecotel.net) |
| 16:10:44 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 16:11:40 | | Quit bluebrother^ (Ping timeout: 256 seconds) |
| 17:00 |
| 17:03:32 | | Quit lebellium (Quit: Leaving) |
| 17:31:19 | | Quit kakaka (Remote host closed the connection) |
| 17:31:53 | | Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) |
| 17:44:04 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 17:55:06 | *** | Saving seen data "./dancer.seen" |
| 17:55:24 | speachy | braewoods: depends on how the chip is attached to the SoC. Is it on the main/parallel memory bus? Or is it on a serial bus ala SPI? |
| 17:56:00 | braewoods | speachy: you mean the isp1362? |
| 17:56:18 | speachy | if it's on the memory bus, you can use the SoC's built-in DMA controller to write data to the chip. Or perhaps the chip has its own busmastering capabilities. |
| 17:56:20 | braewoods | it's connected directly to the GPIO pins in some places. the rest is accessed through special addresses. |
| 17:56:31 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 17:56:31 | | Nick amiconn is now known as Guest40560 (jens@rockbox/developer/amiconn) |
| 17:56:31 | | Quit Guest40560 (Killed (moon.freenode.net (Nickname regained by services))) |
| 17:56:31 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 17:56:38 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 17:56:38 | | Nick pixelma is now known as Guest61771 (marianne@rockbox/staff/pixelma) |
| 17:56:38 | | Quit Guest61771 (Killed (moon.freenode.net (Nickname regained by services))) |
| 17:56:38 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 17:56:52 | braewoods | right now trying to figure out how to detect the presence of USB cable |
| 17:57:11 | braewoods | i think i need to configure the interrupts |
| 17:57:32 | braewoods | my theory is that i can leave the chip asleep and have it wake up when a cable is detected |
| 17:57:56 | speachy | ok, it has a 16-bit parallel bus. so it's presumably directly mapped into the SoC's address space somewhere. |
| 17:58:01 | braewoods | it is |
| 17:58:16 | braewoods | just a lot of problems to solve. |
| 17:58:31 | braewoods | i basically see needing to split where different usb code delegates to |
| 17:58:57 | braewoods | the USB data port on the h300 is connected to the 50606 chip that manages usb charging |
| 17:59:04 | speachy | so yeah, DMA is possible, assuming the dragonball has a spare memory-memory DMA channel you can use. |
| 17:59:16 | braewoods | and the cypress chip which does USB UMS, all transparent to rockbox |
| 17:59:20 | braewoods | for the most part |
| 17:59:51 | braewoods | so the issue is how to delegate the usb stack to the OTG chip and everything else to the hardwar |
| 17:59:52 | braewoods | hardware |
| 18:00 |
| 18:00:16 | braewoods | well one thing at a time |
| 18:00:41 | braewoods | i expect i may end up adding conditional code to turn off part of the usb stack or reroute it |
| 18:01:00 | braewoods | like i know i'll be disabling UMS in the usb stack since that's already hardware controlled |
| 18:01:09 | braewoods | on a different port no less |
| 18:01:09 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 18:02:46 | | Join borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 18:02:51 | | Quit borkitall (Client Quit) |
| 18:05:43 | | Quit livvy (Ping timeout: 240 seconds) |
| 18:37:13 | speachy | anyone recall what's needed to build a font package? |
| 18:37:28 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 18:39:49 | | Join borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 18:46:23 | | Quit borkitall (Quit: borkitall) |
| 18:56:23 | | Quit livvy (Ping timeout: 240 seconds) |
| 19:00 |
| 19:00:40 | speachy | bluebrother: This should be complete: https://download.rockbox.org/build-info |
| 19:01:32 | speachy | Has everything you asked for except bootloader stuff, and font_url for daily&development builds. |
| 19:09:36 | | Quit bluebrother (Disconnected by services) |
| 19:09:41 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:10:22 | | Join fs-bluebot [0] (~fs-bluebo@55d49e45.access.ecotel.net) |
| 19:12:49 | | Quit fs-bluebot_ (Ping timeout: 264 seconds) |
| 19:17:49 | speachy | ok, now there will be daily fonts packages generated again. and font_url in [daily] and [development] point at it. |
| 19:37:43 | braewoods | wow. didn't expect to find this. |
| 19:37:50 | braewoods | https://www.nxp.com/docs/en/application-note/AN2645.pdf |
| 19:38:06 | braewoods | "Interfacing the Philips™ ISP1362 USB OTG Controller to the MCF5249 ColdFire Microprocessor" |
| 19:38:27 | braewoods | this is helpful for at least understanding how to interface with the interrupts |
| 19:38:59 | braewoods | oh, so that's why the gpio pins 5, 6, 7 were chosen? the GPIO interrupts are apparently bound to these pins. |
| 19:40:26 | braewoods | time to find out if i can trigger the interrupts |
| 19:55:09 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:18:42 | | Join borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au) |
| 20:24:43 | borkitall | hey guys, im trying to find where in the settings i can add silence between tracks |
| 20:26:25 | borkitall | im having a look in the iriver manual atm |
| 20:26:35 | borkitall | the h320 |
| 20:29:25 | borkitall | i remember seeing it somewhere, just dont know exactly where |
| 20:41:38 | | Join DarkestEx [0] (5fd0e159@HSI-KBW-095-208-225-089.hsi5.kabel-badenwuerttemberg.de) |
| 20:42:02 | DarkestEx | Hi, I've stumbled over chatlogs talking about the Sony NW-A Series of Walkmans |
| 20:42:12 | DarkestEx | What OS are they running and how's the firmware encrypted? |
| 20:42:17 | DarkestEx | Does anyone know? |
| 20:47:22 | DarkestEx | Browsing through the git repo, it appears that I have found the answer to the first question: https://github.com/Rockbox/rockbox/blob/master/utils/nwztools/upgtools/upgtool.c |
| 21:00 |
| 21:29:49 | DarkestEx | To answer the second question, it actually runs Linux (that took quite a while to get there): https://oss.sony.net/Products/Linux/Audio/NW-ZX300.html |
| 21:30:28 | DarkestEx | Bye |
| 21:30:31 | | Part DarkestEx |
| 21:54:22 | | Quit prof_wolfff (Ping timeout: 272 seconds) |
| 21:55:12 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:09:56 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 22:31:40 | | Quit prof_wolfff (Ping timeout: 246 seconds) |
| 22:35:55 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:00 |
| 23:55:13 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).