| 00:18:01 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 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:00 |
| 02:18:04 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:46:22 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 03:55:56 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 04:00 |
| 04:18:06 | *** | No seen item changed, no save performed. |
| 06:00 |
| 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:00 |
| 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 | amachronic | speachy: I'm happy with moving the m3k to unstable. |
| 08:00 |
| 08:02:22 | fs-bluebot | Build Server message: New build round started. Revision 39939a164b, 298 builds, 9 clients. |
| 08:02:54 | speachy | amachronic: okeydokey, it is done! congratulations btw |
| 08:15:05 | fs-bluebot | Build Server message: Build round completed after 762 seconds. |
| 08:15:08 | fs-bluebot | 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 | speachy | 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 | fs-bluebot | Build Server message: New build round started. Revision 03695429cf, 298 builds, 9 clients. |
| 08:47:57 | speachy | let's see if this takes care of everything. |
| 08:49:33 | chris_s | @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 | chris_s | to systematically/quickly provoke or test for it on a player that I don't regularly use. |
| 08:50:07 | speachy | awesome. I didn't expect a regression on stick player (since I kept hte same sleep command) |
| 08:50:11 | speachy | stock |
| 08:50:45 | speachy | but I wonder what the impact would be if we unconditionally used STANDBY_IMMEDIATE instead of SLEEP across the board |
| 08:50:52 | speachy | the 6g+ stuff already does that |
| 08:53:23 | speachy | 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 | speachy | once the build is green again (hopefully no other GCC11 issues remain) I'll merge that power management change |
| 08:55:36 | speachy | chris_s: thanks for the sanity checking |
| 08:56:26 | chris_s | 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 | speachy | I think so! |
| 08:56:50 | chris_s | ok |
| 08:59:46 | fs-bluebot | Build Server message: Build round completed after 736 seconds. |
| 08:59:48 | amachronic | speachy, I forgot to mention −− are the unstable ports supposed to have a bootloader build available? |
| 08:59:49 | fs-bluebot | Build Server message: Revision 03695429cf result: 0 errors 90 warnings |
| 09:00 |
| 09:01:28 | fs-bluebot | Build Server message: New build round started. Revision 0271c0ed36, 298 builds, 9 clients. |
| 09:01:41 | speachy | damnit, managed to not submit all three together |
| 09:02:36 | speachy | amachronic: Yeah.. I think it would be a good idead to generate a binary bootloader build. |
| 09:03:23 | speachy | 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 | speachy | bootloader and spl, I guess |
| 09:03:41 | amachronic | yep |
| 09:04:31 | speachy | 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 | amachronic | It is, I just haven't gone through the trouble. |
| 09:05:01 | amachronic | As of now, the bootloader will show the version if you boot without the SD card in. |
| 09:05:21 | speachy | that's good enough IMO |
| 09:05:24 | amachronic | and spl + bootloader should be built from same revision |
| 09:05:56 | speachy | if they're technically independent though, we could end up in a situation where someone mis-matches them. |
| 09:06:09 | speachy | (s/could/will/) |
| 09:06:27 | amachronic | yes, but assuming we only provide sync'd up builds, then that's somebody else's fault for doing things wrong |
| 09:06:52 | speachy | I'm thinking purely of the support burden |
| 09:06:58 | amachronic | I might try to eliminate the separate SPL anyway, but I'm not sure how feasible it is. |
| 09:07:15 | amachronic | ie. use linker tricks to make the SPL part of the normal bootloader build |
| 09:08:19 | * | speachy nods. Ideally! |
| 09:08:36 | amachronic | mainly the extra complications of slicing up the resulting binary are why I've not bothered |
| 09:10:25 | amachronic | also some code is #ifdef'd due to SPL constraints and sorting it out is a PITA... |
| 09:12:17 | amachronic | 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 | fs-bluebot | Build Server message: Build round completed after 712 seconds. |
| 09:13:23 | fs-bluebot | Build Server message: Revision 0271c0ed36 result: 0 errors 162 warnings |
| 09:13:24 | fs-bluebot | Build Server message: New build round started. Revision aab72f969f, 298 builds, 9 clients. |
| 09:24:43 | fs-bluebot | Build Server message: Build round completed after 679 seconds. |
| 09:24:45 | fs-bluebot | Build Server message: Revision aab72f969f result: 0 errors 180 warnings |
| 09:26:14 | fs-bluebot | 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 | amachronic | 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 | fs-bluebot | Build Server message: Build round completed after 751 seconds. |
| 09:38:47 | fs-bluebot | 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 | fs-bluebot | https://www.rockbox.org/tracker/task/13133 Opus files with embedded artwork 45.8KiB or larger skip near beginning (bugs, closed) |
| 09:39:27 | fs-bluebot | Gerrit review #2057 at https://gerrit.rockbox.org/r/c/rockbox/+/2057 : Sync opus codec to upstream git by William Wilgus |
| 09:39:35 | speachy | ok, final warning is in the opus code |
| 09:40:47 | speachy | let's see if upstream opus still has the same warning.. |
| 09:40:57 | speachy | ....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 | fs-bluebot | 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 | speachy | no.. it's a possibly unintialized use of a variable |
| 09:49:26 | speachy | 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 | speachy | (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 | speachy | 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 | speachy | 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 | speachy | ah |
| 09:56:32 | _bilgus | its the next on the chopping block when it doesn't fit anymore |
| 09:56:52 | speachy | fuzev1 has an sd card |
| 09:57:14 | speachy | (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 | speachy | 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 | speachy | yeah, fuzev1 has same overall specs as v2 |
| 09:58:19 | speachy | 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 |
| 10:00:50 | speachy | 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 | speachy | 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 | speachy | 2mb targets: logix_dax, c100, clip, m200v4, c200v2 |
| 10:04:25 | _bilgus | logix_dax huh |
| 10:04:52 | speachy | logik_dax, rather |
| 10:04:57 | speachy | I wonder if that even compiles.. |
| 10:05:25 | speachy | nope! |
| 10:06:44 | _bilgus | a 1 gb device and no sd card |
| 10:07:09 | speachy | 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 | speachy | none of the tcc77x series targets even compile. |
| 10:18:17 | *** | Saving seen data "./dancer.seen" |
| 10:22:10 | speachy | 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 | fs-bluebot | Build Server message: New build round started. Revision 14c6bb798d, 298 builds, 7 clients. |
| 10:23:20 | speachy | ok, landing opus. let's see what goes kaboom. |
| 10:24:10 | speachy | 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 | speachy | 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 | speachy | amachronic: with respect to M3K USB DMA, are the buffers used for the initial setup aligned correctly? |
| 10:38:14 | speachy | eg see usb_storage_init_connection() |
| 10:38:32 | fs-bluebot | Build Server message: Build round completed after 926 seconds. |
| 10:38:35 | fs-bluebot | Build Server message: Revision 14c6bb798d result: All green |
| 10:47:48 | | Quit ubervison (Quit: Leaving) |
| 10:55:32 | speachy | should probably nuke ifp7xx too since that was never finished. |
| 11:00 |
| 11:12:04 | speachy | _bilgus: g#3357 |
| 11:12:06 | fs-bluebot | 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 | speachy | about 7K lines removed total. |
| 11:33:34 | speachy | and g#3358, whick nukes about 4K lines. |
| 11:33:37 | fs-bluebot | 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 | speachy | the ifp790 had 256MB of storage... |
| 11:39:14 | speachy | and used an AA battery |
| 12:00 |
| 12:06:01 | | Join amachronic [0] (~amachroni@82.132.186.244) |
| 12:12:46 | amachronic | speachy re USB: I haven't checked alignment, but the code looks ok. |
| 12:13:06 | amachronic | IIRC, it's the GET_MAX_LUN control request which typically hangs |
| 12:18:20 | *** | Saving seen data "./dancer.seen" |
| 12:28:42 | bertrik | i remember there being something weird about scsi get_max_lun, some kind of off-by-one thing in the spec |
| 12:35:58 | speachy | 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 |
| 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 | speachy | at least they compile! |
| 13:46:23 | speachy | The "Elio TPJ-1022" doesn't even make it past 'make dep' |
| 13:48:26 | _bilgus | no point in dead weight |
| 13:48:46 | speachy | wait, my ifp7xx nuking broke something |
| 13:48:59 | speachy | tpj1022 doesn't build but it's mostly plugins. |
| 13:51:38 | speachy | something in 3358 is busted... grr. |
| 13:53:42 | speachy | ok, fixed. |
| 13:54:13 | speachy | https://www.rockbox.org/wiki/ElioTPJ |
| 13:55:59 | speachy | last commit for this target was back in 2009. |
| 13:57:56 | speachy | disable plugins and it... still doesn't compile. vorbis codec doesn't fit in IRAM |
| 14:00 |
| 14:03:39 | speachy | None of the Meizu targets (M3, M6SL, M6SP) build either |
| 14:07:30 | speachy | 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 | lemon_jesus | 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 | lemon_jesus | 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 | lemon_jesus | abstraction layers, please shoot me a message <3 |
| 14:23:27 | speachy | 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 | calebccff | lemon_jesus: that's pretty cool |
| 14:55:41 | TheLemonMan | lemon_jesus, I like your nick |
| 15:00 |
| 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:00 |
| 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:00 |
| 17:04:49 | | Join amachronic [0] (~amachroni@82.132.184.192) |
| 17:11:13 | amachronic | 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 21:55:05 | | Quit Soap_ (Read error: Connection reset by peer) |
| 22:00 |
| 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 | shuteye1 | 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 | shuteye1 | make this behaviour stop such that the volume level does not decrease at all? |
| 23:00 |
| 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) |
icon identifies that the person is a core developer (has commit access).