--- Log for 22.11.120 Server: tepper.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 12 hours ago 00.09.21 # Build Server message: Build round completed after 728 seconds. 00.09.24 # Build Server message: Revision 2eb191a3f4 result: All green 00.10.41 # 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 # Build Server message: New build round started. Revision 6b3b4df6f6, 293 builds, 9 clients. 00.12.12 # (resulted in a substantial upload speed difference from my colocated builder) 00.12.52 # that and ccache resulting in nothing actually changing for most of the builds. :) 00.13.22 # 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 # we could, but I don't see the benefit 00.14.50 # 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 # I still want to push manual generation to the builders, to be done on every commit 00.17.41 # 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 # Reduction of special cases. 00.19.06 # "to do it" ? 00.19.19 # <_bilgus_> voices 00.20.22 # <_bilgus_> like in rbutil on their hardware 00.20.46 # 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 # 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 # builds.pm includes the languages and settings we use for the various TTS engines. 00.23.33 # 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 # Build Server message: Build round completed after 722 seconds. 00.24.10 # Build Server message: Revision 6b3b4df6f6 result: All green 00.24.22 # 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.32.02 Quit massiveH (Quit: Leaving) 01.54.44 *** Saving seen data "./dancer.seen" 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.54.04 Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) 05.17.03 Quit borkitall (Quit: borkitall) 05.31.42 # current Rockbox Utility main screen: https://imgur.com/a/ziAnEQH 05.32.33 # 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.07.38 Join johnb7 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) 06.09.51 # 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 # 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 # _bilgus_: thanks 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.22.54 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 08.34.44 # johnb7: The hardware rev possibility is because the Eros Q II looks identical, except for a slightly thicker case. 08.34.54 # and has incompatible guts. 08.35.22 # and there's a possibility that the v1.3 is based on the newer Q II. 08.35.51 # (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 # I see 08.41.59 # (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 # 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 # Build Server message: New build round started. Revision 1b9eebb39d, 293 builds, 9 clients. 08.46.02 # 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 # braewoods: ^^^ 08.46.39 # I'll put the files up when I have 'em. 08.47.02 # speachy: like i said before: https://braewoods.net/iriver-bootloaders.zip 08.47.19 # ah, that's the problem :) 08.47.38 # i put them there until they could be made official 08.48.14 # crap. Seems I lost my template for build-info. Didn't save the file :/ 08.49.11 # they're up. 08.50.09 # thanks 08.50.22 # we can drop fwpatcher at some point but for now i guess it needs to stay 08.50.50 # at least until rbutil is more polished 08.50.56 # about how to handle this situation 08.51.28 # regarding the script it uses for checksums... 08.51.42 # i setup the local files needed to make it work 08.51.46 # what a pain that was 08.51.56 # i'm tempted to archive that for future updates 08.54.42 # as in calculating those checksums? 08.55.12 # bluebrother: yea. perl script in the fwpatcher directory is used to generate the checksum table compiled into it or rbutil. 08.55.13 # and what polishing you're missing apart from reading the before-after checksums from some file? 08.55.40 # those aren't simple md5sums? 08.55.40 # that's it afaik. i was waiting for a solution to the hard-coded checksum issue to be implemented. 08.55.46 # they are md5sums 08.55.48 # afaik 08.55.58 # ah. So now the bootloaders will work again with current git. 08.56.01 # Build Server message: Build round completed after 682 seconds. 08.56.03 # Build Server message: Revision 1b9eebb39d result: All green 08.56.04 # Build Server message: New build round started. Revision e8f8df4ee0, 293 builds, 9 clients. 08.56.25 # but you can check the script to be sure or w/e 08.56.28 # I was thinking about finishing up some leftovers and then try to get Rockbox Utility 1.5.0 done. 08.56.47 # and leave that hardcoded checksums as well as the sudo issue for 1.6.0 08.56.49 # but i still had to setup the firmware archive the script needed 08.57.03 # that's what was the most tedious. haha 08.57.28 # we can rewrite the script to generate the new checksum files when you get around toi t 08.58.04 # that's the only part i think it worth scavenging from fwpatcher 09.13.27 # Build Server message: Build round completed after 1043 seconds. 09.13.30 # Build Server message: Revision e8f8df4ee0 result: All green 09.43.21 Join johnb3 [0] (~johnb2@p5b3af81e.dip0.t-ipconnect.de) 09.45.19 # Build Server message: New build round started. Revision 25529e4fe0, 293 builds, 9 clients. 09.54.53 *** Saving seen data "./dancer.seen" 09.57.12 # Build Server message: Build round completed after 713 seconds. 09.57.15 # Build Server message: Revision 25529e4fe0 result: All green 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 # 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 # bluebrother^: so for the [daily] section, daily builds use a datecode in their filename, not a shash. 10.09.24 # 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 # daily could also stick to the date. 10.09.54 # I think that's preferable, since you can't really tell at a gaance what date a given hash corresponds to 10.10.03 # true. 10.10.21 # (plus that whole alphabetical sorting thing.. :) 10.10.49 # sorting? Who needs sorting? :P 10.12.07 # 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 # (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 # 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 # fixing [development] to reflect the true state of successful builds is another matter. 10.14.22 # should be able to get something usable by tonight. 10.15.16 Quit prof_wolfff (Ping timeout: 240 seconds) 10.15.42 # great. Right now having [daily] work is my next goal, so I can add support for daily builds. 10.15.57 # then people will be able to install our voices :) 10.16.58 # 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 # with respect to the [bootloader] section, I think we should have explicit player = filename,hash 10.18.10 # or somethign like that 10.18.55 # 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 # think it's worth putting in a format string for the URLs too? 10.19.24 # but maybe use player = hash,filename so it uses the same order as the rest? 10.19.50 # if we have the URLs as part of the config we wouldn't need a format string here, right? 10.19.57 # eg voices.dailyurl = https://d.r.o/daily/%target%/voice-%target%-%lang%.zip 10.20.15 # ah, for that part. 10.20.20 # forgot about this case :) 10.20.32 # (I intend to put explicit URLs for everything) 10.21.50 # hmm. how about using release/voiceurl = ... instead? 10.22.22 # the thing is I'm trying to look up things by going /, so that would make it more straightforward. 10.22.44 # you mean release/voiceurl = url_template ? 10.22.55 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 10.22.57 # yes. 10.23.04 # and daily/voiceurl = url_template 10.23.07 # I like that 10.23.07 # and obviously the same for daily/voiceurl, etc. 10.24.13 # right now I have to go release/ for releases, and manually construct things for dev builds. That's why I'd like to have development/. And in the same way we can add further info, like voiceurl 10.24.37 # you can check the template format I'm currently using in rbutil/rbutilqt/rbutil.ini 10.24.54 # just introduced a similar split there. 10.25.55 # hmm, why did I put a url for dev voices in there? We don't have that. 10.26.01 # but it's filtered in the UI anyway. 10.26.42 # 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 # 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 # I have it running on 7c498b9043-201030 10.36.37 # I will check with the dev build 10.36.43 # _bilgus: the iriver h1xx/h3xx only 10.40.49 # 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 # ok. think i know what my next project will be. 10.52.03 # putting mtp on hold for now since i can't test it right now 10.52.11 # i'll look into the OTG chip on the H300 10.52.32 # luckily there's linux kernel source for it so i can at least compare notes about it. 10.53.14 # _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 # bluebrother^: oh, will the next version be https-enabled? (including templates) 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 # so can anyone with a fuze+ look at/comment on fs#13020 ? 11.13.49 # 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 # speachy: yes. 11.25.41 # bluebrother^: does rbutil care about source downloads too? 11.27.13 # 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 # bluebrother^: also: https://download.rockbox.org/daily/build-info 11.27.58 # hm. 11.28.00 # braewoods: possible, sure, but it's going to take a decent amount of work to abstract away from the rockbox API. 11.28.14 # yea, that's the other issue. 11.28.20 # it's not enough to just make the chip work. 11.28.29 # we also need a way to make it co-exist with the other one. 11.29.28 # actually... i wonder... 11.29.49 # 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 # it may be possible to just disable our UMS on the H300 if that theory is right. 11.30.54 # either way this won't matter to the new bootloaders 11.31.03 # i wasn't planning to have OTG enabled when it is running 11.31.11 # i plan to keep it disabled like it currently is 11.31.18 # only useful once RB is booted 11.33.11 # rofl 11.33.33 # the linux kernel only implements half of the ISP1362 functionality. only so it can provide USB host functionality. 11.36.05 # bluebrother^: now has voiceurl and sourceurl templates too. 11.43.15 # 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.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 # 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 # 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 # (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 # 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 # 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 # I'm actually adding that too. 12.19.49 # buildurl pointing to what? 12.20.04 # the build 12.20.29 # pretty much what rbutil.ini has as build_url right now 12.20.54 # so we're consistent for all downloads we do :) 12.20.57 # ah, ok. 12.21.19 # could even leave out the individual urls then, unless we want to / need to specify different ones depending on the target. 12.21.24 # I'm adding 'manualurl=/bla-html.zip' and 'manualpdfurl="/.../bla.pdf' 12.21.59 # ok. 12.22.15 # not sure if we should keep having a link to the html manual though. 12.22.45 # 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 # are we expecting those different versions to end up in different locations? 12.23.17 # I think the html manual is only useful for online browsing; otherwise pdf is far better. 12.24.26 # 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 # being able to read it online is just an additional benefit :) 12.25.12 # 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 # ok 12.25.32 # should I use 'voiceurl' or 'voice_url' ? 12.25.33 # 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 # doesn't matter to me :) 12.26.49 # well, I mean rbutil.ini uses the underscore 12.26.52 # I'd vote for consistency. Apart from that I don't care too much if its whateverurl or whatever_url :) 12.27.31 # 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 # but then again, since rbutil.ini is internal to Rockbox Utility I could also easily change it there. 12.28.08 # nothing uses the infra side of things yet. 12.28.15 # so that's easy to change 12.28.27 # 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 # Build Server message: New build round started. Revision f598ef9c27, 293 builds, 9 clients. 12.32.01 # what should I use in the daily stuff? %REVISION% or someting else? (ie to map to the datecode) 12.33.14 # 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 # rbutil.ini currently uses RELVERSION, but that's something I'd like to change. 12.34.03 # there's also a bit of an inconsistency with TARGET and MODEL. I need to clean that up as well. 12.34.12 # bit rot :) 12.35.56 # 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 # daily now uses %MODEL% and %REVISION% 12.36.32 # release uses RELVERSION 12.36.44 # and bleeding/development has no templates at all yet. 12.36.58 # it'll have to wait until tonight though; I need to run now. 12.37.45 # just use VERSION for all of those. So daily REVISION -> VERSION, release RELVERSION -> VERSION. That will simplify things for me. 12.37.49 # ty. 12.37.56 # ok. 12.39.00 # and with templates, we can ditch the per-item URLs? 12.39.08 # yes. 12.39.19 # ok. I'd rather do templates in build-info anyway. 12.39.53 # 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 # but if there is no per-item url we'll simply use the template. 12.40.27 # so hopefully best of both worlds :) 12.40.58 # need to fix/add a font package for daily builds. 12.42.32 # didn't we have a fonts pack for dailies? 12.42.39 # no, just a symlink to the last release 12.42.49 # which is missing now. 12.42.56 # gotta scoot 12.42.57 # ah. Well, build-info could simply point to that file. 12.43.03 # Build Server message: Build round completed after 665 seconds. 12.43.10 # ok, cya 12.43.13 # Build Server message: Revision f598ef9c27 result: All green 12.43.14 # Build Server message: New build round started. Revision 64fe7e03a8, 293 builds, 9 clients. 12.45.51 # bluebrother^: current output: http://download.rockbox.org/build-info 12.46.37 # the [daily] stuff will be updated tonight. 12.46.44 # [development] is all that remains. 12.50.49 # <_bilgus_> cd .. 13.00.26 # Build Server message: Build round completed after 1032 seconds. 13.00.28 # Build Server message: Revision 64fe7e03a8 result: All green 13.01.54 # hm. 13.02.06 # interesting. the h300 schematic is rather helpful. 13.02.31 # 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 # hm. 13.23.50 # on iriver h300... 2 DMA channels are already used for PCM... 13.23.56 # 1 DMA channel is used by the LCD 13.24.02 # that leaves one unused 13.25.25 # isp1362 can use up to 2 DMA channels... 13.25.44 # _bilgus: how do I know if DMA is possible for a chip? 13.26.20 # 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 # ok.. 13.26.46 # who could I ask then? 13.27.10 # i can always use PIO if i must but 13.27.13 # from what i can tell 13.27.21 # the isp1362 interrupt lines are connected 13.27.26 # but i don't know if the DMA pins are 13.27.31 # <_bilgus> wods or pamaury I imagine 13.29.29 # just looking at the driver code i realize there's a lot of time the code is spending twiddling its thumbs 13.29.41 # so i'd like to find a way to let it do other stuff if possible 13.29.44 # while waiting on the cihp 13.29.46 # 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 # i think it's save to say DMA is probably not an option 13.35.14 # but hm 13.36.05 Join _bilgus [0] (~bilgus@2603-6011-c806-2b0c-a4c5-a909-4cf2-6673.res6.spectrum.com) 13.45.03 # _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 # or so 13.45.47 # 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.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 # _bilgus__: in theory but i'll look at it later. 14.44.56 # i still need to get this working first 14.51.25 Quit johnb7 (Ping timeout: 246 seconds) 14.51.54 # 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.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 # speachy: is USB_NUM_ENDPOINTS including or excluding the 2 control endpoints? 15.46.56 # the isp1362 technically has 16 endpoints but only 14 can be programmed 15.47.06 # so not sure which to put 15.55.03 *** Saving seen data "./dancer.seen" 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.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 # 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 # speachy: you mean the isp1362? 17.56.18 # 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 # 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 # right now trying to figure out how to detect the presence of USB cable 17.57.11 # i think i need to configure the interrupts 17.57.32 # my theory is that i can leave the chip asleep and have it wake up when a cable is detected 17.57.56 # ok, it has a 16-bit parallel bus. so it's presumably directly mapped into the SoC's address space somewhere. 17.58.01 # it is 17.58.16 # just a lot of problems to solve. 17.58.31 # i basically see needing to split where different usb code delegates to 17.58.57 # the USB data port on the h300 is connected to the 50606 chip that manages usb charging 17.59.04 # so yeah, DMA is possible, assuming the dragonball has a spare memory-memory DMA channel you can use. 17.59.16 # and the cypress chip which does USB UMS, all transparent to rockbox 17.59.20 # for the most part 17.59.51 # so the issue is how to delegate the usb stack to the OTG chip and everything else to the hardwar 17.59.52 # hardware 18.00.16 # well one thing at a time 18.00.41 # i expect i may end up adding conditional code to turn off part of the usb stack or reroute it 18.01.00 # like i know i'll be disabling UMS in the usb stack since that's already hardware controlled 18.01.09 # 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 # 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.40 # bluebrother: This should be complete: https://download.rockbox.org/build-info 19.01.32 # 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 # ok, now there will be daily fonts packages generated again. and font_url in [daily] and [development] point at it. 19.37.43 # wow. didn't expect to find this. 19.37.50 # https://www.nxp.com/docs/en/application-note/AN2645.pdf 19.38.06 # "Interfacing the Philips™ ISP1362 USB OTG Controller to the MCF5249 ColdFire Microprocessor" 19.38.27 # this is helpful for at least understanding how to interface with the interrupts 19.38.59 # 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 # time to find out if i can trigger the interrupts 19.55.09 *** Saving seen data "./dancer.seen" 20.18.42 Join borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au) 20.24.43 # hey guys, im trying to find where in the settings i can add silence between tracks 20.26.25 # im having a look in the iriver manual atm 20.26.35 # the h320 20.29.25 # 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 # Hi, I've stumbled over chatlogs talking about the Sony NW-A Series of Walkmans 20.42.12 # What OS are they running and how's the firmware encrypted? 20.42.17 # Does anyone know? 20.47.22 # 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.29.49 # 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 # 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.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.55.13 *** Saving seen data "./dancer.seen"