--- Log for 23.04.121 Server: tepper.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 18 hours ago 00.18.01 *** Saving seen data "./dancer.seen" 01.02.59 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 01.06.11 Quit advcomp2019_ (Ping timeout: 260 seconds) 01.22.25 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 01.26.41 Quit ZincAlloy (Ping timeout: 240 seconds) 01.32.50 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:909:ccbb:53e3:9ccf) 01.37.23 Quit ZincAlloy (Ping timeout: 248 seconds) 01.52.45 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 01.56.46 Quit ZincAlloy (Ping timeout: 240 seconds) 02.18.04 *** Saving seen data "./dancer.seen" 03.46.22 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 03.55.56 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 04.18.06 *** No seen item changed, no save performed. 06.18.10 *** No seen item changed, no save performed. 06.41.52 Quit bzed (Read error: Connection reset by peer) 06.44.11 Join bzed [0] (~bzed@shell.bzed.at) 07.28.00 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-4838-97bf-8052-9106.res6.spectrum.com) 07.33.22 Join amachronic [0] (~amachroni@82.132.185.202) 07.35.27 # speachy: I'm happy with moving the m3k to unstable. 08.02.22 # Build Server message: New build round started. Revision 39939a164b, 298 builds, 9 clients. 08.02.54 # amachronic: okeydokey, it is done! congratulations btw 08.15.05 # Build Server message: Build round completed after 762 seconds. 08.15.08 # Build Server message: Revision 39939a164b result: 60 errors 120 warnings 08.18.13 *** Saving seen data "./dancer.seen" 08.24.26 # * speachy raises an eyebrow. 08.26.34 # looks like the gcc 11 toolchain is generating some problems with simulator builds. Errors are all false positives from the log parser, but the warnings are legit. 08.43.29 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 08.47.29 # Build Server message: New build round started. Revision 03695429cf, 298 builds, 9 clients. 08.47.57 # let's see if this takes care of everything. 08.49.33 # @speachy Re pwr management changes: iPod color/photo (stock) looking good so far, too (except for what I mentioned earlier which seems to be a separate issue). I'm *fairly* confident but not certain yet that UDMA2 causes the same trouble as it does on the 4G though. "Unfortunately", *that* problem occurs rarely enough that I've found it difficult 08.49.34 # to systematically/quickly provoke or test for it on a player that I don't regularly use. 08.50.07 # awesome. I didn't expect a regression on stick player (since I kept hte same sleep command) 08.50.11 # stock 08.50.45 # but I wonder what the impact would be if we unconditionally used STANDBY_IMMEDIATE instead of SLEEP across the board 08.50.52 # the 6g+ stuff already does that 08.53.23 # I wonder if the UDMA2 stuff is related to dynamic cpu clocking -- if we have a path that downclocks the CPU while a transfer is in progress that could cause badness. 08.55.31 # once the build is green again (hopefully no other GCC11 issues remain) I'll merge that power management change 08.55.36 # chris_s: thanks for the sanity checking 08.56.26 # sure, would it help at all if I tested a build with dynamic cpu clocking disabled and UDMA 2 enabled to see if the problem remains? 08.56.44 # I think so! 08.56.50 # ok 08.59.46 # Build Server message: Build round completed after 736 seconds. 08.59.48 # speachy, I forgot to mention -- are the unstable ports supposed to have a bootloader build available? 08.59.49 # Build Server message: Revision 03695429cf result: 0 errors 90 warnings 09.01.28 # Build Server message: New build round started. Revision 0271c0ed36, 298 builds, 9 clients. 09.01.41 # damnit, managed to not submit all three together 09.02.36 # amachronic: Yeah.. I think it would be a good idead to generate a binary bootloader build. 09.03.23 # it's not strictly necessary (some of the targets are only "unstable" because of very convoluted installation requirements) but we do want to allow folks to install without having to compile anything. 09.03.33 # bootloader and spl, I guess 09.03.41 # yep 09.04.31 # hmm.. is it feasible to add in a queryable version number for the spl and bootloader? (ie somethign that can be read via rockbox's debug menu?) 09.04.49 # It is, I just haven't gone through the trouble. 09.05.01 # As of now, the bootloader will show the version if you boot without the SD card in. 09.05.21 # that's good enough IMO 09.05.24 # and spl + bootloader should be built from same revision 09.05.56 # if they're technically independent though, we could end up in a situation where someone mis-matches them. 09.06.09 # (s/could/will/) 09.06.27 # yes, but assuming we only provide sync'd up builds, then that's somebody else's fault for doing things wrong 09.06.52 # I'm thinking purely of the support burden 09.06.58 # I might try to eliminate the separate SPL anyway, but I'm not sure how feasible it is. 09.07.15 # ie. use linker tricks to make the SPL part of the normal bootloader build 09.08.19 # * speachy nods. Ideally! 09.08.36 # mainly the extra complications of slicing up the resulting binary are why I've not bothered 09.10.25 # also some code is #ifdef'd due to SPL constraints and sorting it out is a PITA... 09.12.17 # after adding USB the bootloader size is also pushing dangerously close to the limit, probably that needs to be fixed too or it will cause annoyances later 09.13.20 # Build Server message: Build round completed after 712 seconds. 09.13.23 # Build Server message: Revision 0271c0ed36 result: 0 errors 162 warnings 09.13.24 # Build Server message: New build round started. Revision aab72f969f, 298 builds, 9 clients. 09.24.43 # Build Server message: Build round completed after 679 seconds. 09.24.45 # Build Server message: Revision aab72f969f result: 0 errors 180 warnings 09.26.14 # Build Server message: New build round started. Revision 75d9393796, 298 builds, 9 clients. 09.28.42 Quit chris_s (Quit: Ping timeout (120 seconds)) 09.30.32 # hmm, maybe I should rework the bootloader & installation process a bit given that USB works now. 09.35.36 Quit amachronic (Quit: amachronic) 09.38.45 # Build Server message: Build round completed after 751 seconds. 09.38.47 # Build Server message: Revision 75d9393796 result: 0 errors 8 warnings 09.39.24 # <_bilgus> speachy re - g#2057 I left a comment -- I still have the sample files reffd in the FS#13133 bug report if you wanna push to wards upstream opus 09.39.27 # https://www.rockbox.org/tracker/task/13133 Opus files with embedded artwork 45.8KiB or larger skip near beginning (bugs, closed) 09.39.27 # Gerrit review #2057 at https://gerrit.rockbox.org/r/c/rockbox/+/2057 : Sync opus codec to upstream git by William Wilgus 09.39.35 # ok, final warning is in the opus code 09.40.47 # let's see if upstream opus still has the same warning.. 09.40.57 # ....nope 09.42.21 # <_bilgus> entirely possible its a warning from my AA fix 09.43.01 # <_bilgus> or even g#2231 09.43.03 # Gerrit review #2231 at https://gerrit.rockbox.org/r/c/rockbox/+/2231 : opus reset decoder on seek completion to prevent stack overflow by William Wilgus 09.48.13 # no.. it's a possibly unintialized use of a variable 09.49.26 # a fixed array is initialized up to the index specified in a function argument, then passd into another function. presumably that other function might access it beyond the initialized boundary. 09.50.01 # (newer compiler has better code flow analysis basically) 09.50.14 # <_bilgus> looking at the rebase commit it appears that the sync won't wipe out those fixes 09.51.04 # <_bilgus> and the targets I was initially worried about are pretty much gone too 09.51.13 # I rebased that commit so I could see if this warning was already fixed upstream 09.51.55 # <_bilgus> might as well push then sounds like a good reason 09.52.17 # <_bilgus> testing reqd' ofc 09.52.27 # gone how? I mean, we didn't drop anything other than hwcodec 09.54.43 # <_bilgus> the clip v1 and fuze v1 09.54.52 # <_bilgus> like gone from the face of the earth 09.55.50 # <_bilgus> no sd card and 2mb of ram the flash is surely toasted 09.56.11 # ah 09.56.32 # <_bilgus> its the next on the chopping block when it doesn't fit anymore 09.56.52 # fuzev1 has an sd card 09.57.14 # (I have a busted one amongst my pile of v2s) 09.57.18 # <_bilgus> oh did it thought the v1s all had no sd 09.57.41 # I think it was one the m200 or c200 series that lacked an sd card 09.57.44 # <_bilgus> presumeably its also has more ram then? 09.57.56 # yeah, fuzev1 has same overall specs as v2 09.58.19 # just a better-integrated SoC (AMSv2 plus memory-on-package) 09.58.20 # <_bilgus> it probably was the bootdata patch shows which did and didn't have a sd 10.00.50 # well, those sample file still play 10.00.55 # <_bilgus> The clipv1, c200,e200,m200 all were removed due to space constraints in the firmware image 10.01.42 # <_bilgus> and later the e200 v1 was later re-added 10.01.50 # IIRC those are our only 2MB targets too? 10.01.52 # <_bilgus> later later 10.02.05 # <_bilgus> 2 for emphasis 10.02.32 # <_bilgus> probably.. 10.03.47 # 2mb targets: logix_dax, c100, clip, m200v4, c200v2 10.04.25 # <_bilgus> logix_dax huh 10.04.52 # logik_dax, rather 10.04.57 # I wonder if that even compiles.. 10.05.25 # nope! 10.06.44 # <_bilgus> a 1 gb device and no sd card 10.07.09 # same platform as the sansa c100 10.07.23 # <_bilgus> and runs off 1 AA 10.07.53 # <_bilgus> yeah rather than fix it I'd say bye bye 10.08.06 # <_bilgus> last mention of it was 2009 10.08.07 Quit pamaury (Ping timeout: 260 seconds) 10.09.05 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.09.37 # <_bilgus> looks like it never was finished 10.16.04 # none of the tcc77x series targets even compile. 10.18.17 *** Saving seen data "./dancer.seen" 10.22.10 # c100 was never finished, logidax doesn't link after the build errors are fixed, m200's keymap goes boom, and iaudio7 is even more broken 10.23.06 # Build Server message: New build round started. Revision 14c6bb798d, 298 builds, 7 clients. 10.23.20 # ok, landing opus. let's see what goes kaboom. 10.24.10 # any objections to just nuking the entire tcc77x series? It's completely b0rked and I can't see anyone caring enough to recussitate them. 10.27.32 # <_bilgus> lets ask on the forum to be sure but I see no reason to keep em 10.27.44 # these never saw any release, ever 10.28.24 # <_bilgus> oh then just nuke em 10.34.46 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc) 10.37.56 # amachronic: with respect to M3K USB DMA, are the buffers used for the initial setup aligned correctly? 10.38.14 # eg see usb_storage_init_connection() 10.38.32 # Build Server message: Build round completed after 926 seconds. 10.38.35 # Build Server message: Revision 14c6bb798d result: All green 10.47.48 Quit ubervison (Quit: Leaving) 10.55.32 # should probably nuke ifp7xx too since that was never finished. 11.12.04 # _bilgus: g#3357 11.12.06 # Gerrit review #3357 at https://gerrit.rockbox.org/r/c/rockbox/+/3357 : Nuke all TCC77x targets: iAudio 7, Sansa C100, M200(v1-3), Logik DAX by Solomon Peachy 11.12.57 # about 7K lines removed total. 11.33.34 # and g#3358, whick nukes about 4K lines. 11.33.37 # Gerrit review #3358 at https://gerrit.rockbox.org/r/c/rockbox/+/3358 : Nuke the nonfunctional iriver ifp-7xx port by Solomon Peachy 11.35.31 Quit pamaury (Ping timeout: 252 seconds) 11.39.06 # the ifp790 had 256MB of storage... 11.39.14 # and used an AA battery 12.06.01 Join amachronic [0] (~amachroni@82.132.186.244) 12.12.46 # speachy re USB: I haven't checked alignment, but the code looks ok. 12.13.06 # IIRC, it's the GET_MAX_LUN control request which typically hangs 12.18.20 *** Saving seen data "./dancer.seen" 12.28.42 # i remember there being something weird about scsi get_max_lun, some kind of off-by-one thing in the spec 12.35.58 # so after those nukes go through, there are only three <=2MB targets in the tree: sansa clip, m200v4, and c200v2 12.41.27 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:2199:9df5:aae6:f93a) 12.49.07 Join MrZeus_ [0] (~MrZeus@2a02:c7f:a0aa:4400:e0b6:2d44:2a99:b71a) 13.00.01 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.00.03 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 13.14.57 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 13.40.24 # <_bilgus> their days are numbered 13.42.56 # at least they compile! 13.46.23 # The "Elio TPJ-1022" doesn't even make it past 'make dep' 13.48.26 # <_bilgus> no point in dead weight 13.48.46 # wait, my ifp7xx nuking broke something 13.48.59 # tpj1022 doesn't build but it's mostly plugins. 13.51.38 # something in 3358 is busted... grr. 13.53.42 # ok, fixed. 13.54.13 # https://www.rockbox.org/wiki/ElioTPJ 13.55.59 # last commit for this target was back in 2009. 13.57.56 # disable plugins and it... still doesn't compile. vorbis codec doesn't fit in IRAM 14.03.39 # None of the Meizu targets (M3, M6SL, M6SP) build either 14.07.30 # ditto on the Lyre targets ("proto 1" and mini2440) 14.13.57 Join lemon_jesus [0] (~lemon_jes@208.59.79.137) 14.18.23 *** Saving seen data "./dancer.seen" 14.22.46 # hey gang, I don't know if this is the right place to put this, but I figured some of you might be interested. I've been working on a flash upgrade mod for the iPod Nano 3G for the past year. so far, I'm unsuccessful, but I've developed some neato firmware modding techniques. currently (thanks to the Rockbox bootloader), I'm able to put the NAND 14.22.46 # chip's ID where the NAND_LBA number goes in the diagnostic menu, but I'm stumped as to why I'm unable to actually read and write to the chip. my guess is the chip is being addressed weird, so the next step for me is signal level debugging. I made a video about my progress: https://youtu.be/5zk2CDQ5N9A - if you have knowledge about NAND and NAND 14.22.46 # abstraction layers, please shoot me a message <3 14.23.27 # I don't think any one active here can help, but best of luck all the same! 14.24.06 Quit lebellium (Ping timeout: 240 seconds) 14.51.06 Join calebccff [0] (~calebconn@connolly.tech) 14.51.07 # lemon_jesus: that's pretty cool 14.55.41 # lemon_jesus, I like your nick 15.29.17 Quit Acou_Bass (Remote host closed the connection) 15.31.58 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 15.58.11 Quit amachronic (Quit: amachronic) 16.03.28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.15.14 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 16.18.26 *** Saving seen data "./dancer.seen" 16.21.05 Quit mendel_munkis (Remote host closed the connection) 16.21.19 Join mendel_munkis [0] (~mendelmun@ool-43568247.dyn.optonline.net) 16.22.26 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 16.22.26 Quit amiconn (Killed (egan.freenode.net (Nickname regained by services))) 16.22.26 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 16.22.38 Join pixelma_ [0] (marianne@rockbox/staff/pixelma) 16.22.38 Nick pixelma is now known as Guest96352 (marianne@rockbox/staff/pixelma) 16.22.38 Quit Guest96352 (Killed (egan.freenode.net (Nickname regained by services))) 16.22.38 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) 16.23.07 Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) 16.27.18 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 16.38.34 Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) 17.04.49 Join amachronic [0] (~amachroni@82.132.184.192) 17.11.13 # speachy: just so you know, I'm going to rework the M3K bootloader (yet again...) so it's probably best to hold off releasing a binary. 17.16.34 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.22.08 Quit amachronic (Quit: amachronic) 17.51.00 Quit calebccff (Quit: Idle timeout reached: 10800s) 18.05.03 Quit APLU (Ping timeout: 260 seconds) 18.08.27 Join APLU [0] (~mulx@eva.aplu.fr) 18.14.56 Quit kugel (Ping timeout: 245 seconds) 18.15.58 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.18.29 *** Saving seen data "./dancer.seen" 18.29.42 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 18.31.20 Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in) 18.42.20 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 18.48.27 Quit pamaury (Ping timeout: 260 seconds) 19.15.52 Quit ac_laptop (Ping timeout: 252 seconds) 19.32.46 Quit daswf852 (Ping timeout: 240 seconds) 19.51.51 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.16.04 Quit ac_laptop (Ping timeout: 268 seconds) 20.16.39 Quit MrZeus_ (Ping timeout: 260 seconds) 20.18.33 *** Saving seen data "./dancer.seen" 20.26.45 Quit ZincAlloy (Quit: Leaving.) 20.29.15 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 21.55.05 Quit Soap_ (Read error: Connection reset by peer) 22.07.52 Quit cockroach (Quit: leaving) 22.18.36 *** Saving seen data "./dancer.seen" 22.49.07 Join shuteye1 [0] (ae732d7f@cpe3c7c3f341f00-cm98524a8b1128.cpe.net.cable.rogers.com) 22.54.54 # Freshly rockboxed Xduoo X3 (original) running a daily build from last week. My line-out jack works for a while, then significantly lowers in volume at a random interval to the point where the audio is barely heard via an amplified source. Pressing one of the volume buttons on the player brings the volume back to normal level, is there any way to 22.54.55 # make this behaviour stop such that the volume level does not decrease at all? 23.05.29 Quit Saijin-Naib (Ping timeout: 250 seconds) 23.32.29 # <_bilgus> shuteye1, there was recently a patch that messed with the LO level 23.32.31 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev)