| 00:12:10 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 01:00 |
| 01:55:36 | | Quit advcomp2019__ (Read error: Connection reset by peer) |
| 01:56:00 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 01:56:13 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:22:34 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 02:27:39 | | Quit ZincAlloy (Ping timeout: 268 seconds) |
| 03:00 |
| 03:56:16 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:32:54 | | Join nihilazo [0] (~nihilazo@2607:f298:5:101d:f816:3eff:fe1a:29a3) |
| 05:56:17 | *** | No seen item changed, no save performed. |
| 06:00 |
| 06:03:52 | | Quit nihilazo (Remote host closed the connection) |
| 07:00 |
| 07:46:02 | | Join massiveH [0] (~massiveH@ool-18e4ebfe.dyn.optonline.net) |
| 07:56:19 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:20:02 | munkis | _bilgus you have any issues with my committing the new playmode? |
| 08:21:47 | q3k | user890104: are you working on nano3/4g support? i was about to attempt that out of boredom, too |
| 08:23:14 | user890104 | q3k: i rebased Castor's bootloader code to master branch, and sorted out the target ids/modelnum mess (the patch is from ~2018 and more targets were added since then) |
| 08:23:40 | q3k | ah, do you have a link to that bootloader code? i was trawling through nano4g related stuff recently and haven't seen that yet |
| 08:23:45 | user890104 | the bootloader builds and runs on target, also he made a n4g one but it didn't run in his test |
| 08:24:10 | user890104 | here you are: user890104/rockbox/-/tree/nano3g4g">https://gitlab.com/user890104/rockbox/-/tree/nano3g4g |
| 08:24:41 | q3k | cool, it'll probably land in master before i actually get to my nano4g stuff, but it's good to know i can build off of something that already exists |
| 08:24:42 | user890104 | i also have his original commit tree, but squashed them so rebasing is easier |
| 08:25:47 | user890104 | yes, please do! it's mostly copied from emCORE, and we had some nice progress there, but all developers left so i'm just maintaining the freemyipod site and telling stories |
| 08:26:05 | q3k | oh, cool :) |
| 08:26:39 | q3k | i'm not sure how much time i'll have for anything, i just recently baited myself into messing around with nano4g stuff out of nostalgia |
| 08:26:58 | user890104 | heads up about dirty fixes (commented out rockbox code), and large portions of comments in spanish |
| 08:27:14 | q3k | freemyipod has been a great way to catch up to the current knowledge |
| 08:27:51 | user890104 | about n4g, there's openiBoot, and since ipod touch 2g has the same SoC, we could use some code from there |
| 08:28:36 | q3k | right, but isn't most of the SoC support from oib also present in embios/emcore, and effectively in this rebase you're doing here? |
| 08:29:09 | user890104 | both n3g and n4g lack nand (ftl/vfl/etc.) implementation, i have the notes and IDA db of bendikt93, and someone else i think is also reversing/implementing the missing bits |
| 08:29:16 | q3k | haven't scrolled through much, but there's interrupts, mmu, pmic, uart, ... anything else we need? |
| 08:29:50 | q3k | (... clocking/clock tree) |
| 08:29:52 | user890104 | well, it basically boots, but some things are missing, e.g. battery adc is not implemented |
| 08:30:19 | user890104 | i don't remember if there was support for n4g adc in emcore |
| 08:30:43 | q3k | and i also assume all the things to actually make rockbox usable on it (audio codec, gpu/framebuffer, proper power saving, ...) is something that's nano-specific anyway? |
| 08:31:02 | q3k | like, the battery adc - is it a SoC thing, or some discrete/nano-specific thing? |
| 08:31:22 | user890104 | i'm also not sure how would be the best way to collaborate in this, should I make a gerrit patch, or give you access to my repo? |
| 08:31:58 | user890104 | well, different nanos have different (but similar) chips, so most registers are the same, but they are not tested so Castor left them commented out |
| 08:31:59 | q3k | my preferred way would be if you would slowly chunk up that giant rebase into smaller bits and send me gerrit CRs, but i realize it's a lot of work |
| 08:32:19 | user890104 | well, i'm going to do this anyway :) |
| 08:32:41 | q3k | well, lemme log into the rockbox gerrit then so that you can add me to reviewers whenever you have something ready |
| 08:32:58 | q3k | i like reviewing code, so i'll gladly do that... just at best effort SLA |
| 08:33:27 | q3k | there, username q3k |
| 08:33:45 | user890104 | for nano3g, i think it uses the same (or very similar) codec to n2g, so audio output should mostly work |
| 08:34:14 | q3k | also fwiw i don't even have gear to test on yet, n4g should arrive monday, i can go also find an n3g somewhere |
| 08:34:27 | q3k | if me being a second pair of eyes on this will help, i'll gladly do that |
| 08:35:55 | q3k | there, bidding on an n3g now :) |
| 08:41:53 | | Quit massiveH (Quit: Leaving) |
| 08:42:46 | | Join zizzy [0] (sid385519@id-385519.lymington.irccloud.com) |
| 08:42:53 | zizzy | hello there |
| 08:42:58 | zizzy | q3k: here I am |
| 08:43:32 | zizzy | I haven't bought the n4g yet :P |
| 08:43:53 | q3k | (brought a friend who i'm also trying to nostalgia-bait into doing some n3g/n4g research) |
| 08:44:04 | user890104 | ah, nice |
| 08:44:57 | user890104 | i also have 2 ipod touch 2gs with the MB model number (exploitable bootrom), and there's a somehow working port of emcore for touch2g, so in the long term it might be possible to get rockbox running on touch2g |
| 08:45:08 | user890104 | (SoC is the same as n4g) |
| 08:47:08 | q3k | i lost my touch2g that was vulnerable to seg24k/usb0xa1, unfortunately. i'm also more personally interested in the non-touch variants for some reason, mostly because it's less explored space |
| 08:48:14 | q3k | fwiw my general goal is to just explore things around (maybe even look a bit more into early boot things, maybe even try some hw attacks on the SoC to extract secrets), with secondary goals being rockbox support and/or a linux port |
| 08:48:55 | q3k | but first i need to catch up on the current state of the art once i have hardware in hand. |
| 08:49:13 | user890104 | sounds like a good plan |
| 08:49:32 | q3k | and i think zizzy is more interested in the original firmware just because it's also fairly obscure |
| 08:50:33 | user890104 | yeah, all the EFI stuff is strange for a music player, and it also has module for ISO9660 booting IIRC |
| 08:50:55 | user890104 | no idea where apple copy/pasted from |
| 09:00 |
| 09:04:12 | zizzy | ...it has EFI? |
| 09:04:32 | zizzy | I remember seeing EFI Version in diags screen |
| 09:05:03 | zizzy | but I thought this is a remain from their dev environment |
| 09:12:30 | | Quit Romster (Ping timeout: 260 seconds) |
| 09:14:19 | user890104 | no, all drivers from n3g and up are EFI |
| 09:17:28 | _bilgus | munkis looks fine to me |
| 09:20:15 | rb-bluebot | Build Server message: New build round started. Revision 13ac485625, 303 builds, 12 clients. |
| 09:23:50 | munkis | what effects would increasing my plugin buffer size have? |
| 09:28:54 | | Join dfgg [0] (~dfgg@user/dfgg) |
| 09:30:12 | _bilgus | lower playtime the audio buffer would suffer |
| 09:30:56 | _bilgus | plugins get compiled every time so the chnage in address wouldnt hurt anything |
| 09:31:53 | _bilgus | but otherwise I doubt much else |
| 09:32:06 | | Join Romster [0] (~romster@user/romster) |
| 09:32:37 | _bilgus | i'm thinking about splitting pictureflow out to two separate plugins |
| 09:33:00 | _bilgus | I think it might already do an overlay IDR |
| 09:33:57 | _bilgus | My thoughts are a standalone db generator so frankenpod can get their wish |
| 09:34:34 | _bilgus | too many songs to build a pf album before it runs out of ram |
| 09:35:38 | rb-bluebot | Build Server message: Build round completed after 923 seconds. |
| 09:35:39 | rb-bluebot | Build Server message: Revision 13ac485625 result: All green |
| 09:36:57 | _bilgus | woot |
| 09:38:37 | munkis | for some reason I thought the audio buffer was fixed size. |
| 09:47:53 | _bilgus | fixed at compile time but i'm sure there is a lower limit i'd look at the clipv1 for a minimum sz |
| 09:48:33 | _bilgus | it only has 2mb of ram so if it can do it you should be able |
| 09:51:00 | munkis | I've just noticed that plugins seem to be slightly slower now, and was wondering if it was a result. |
| 09:51:42 | munkis | my audio buffer is probably still larger than the clips entire ram. |
| 09:53:37 | munkis | additionally what would be likely to case a failure of the assert at line 420 of firmware/kernel/queue.c (likely backlight related) |
| 09:54:23 | _bilgus | every bin increase erodes the plugin buffer so you might be on to something |
| 09:56:20 | *** | Saving seen data "./dancer.seen" |
| 09:56:53 | _bilgus | Is that even enabled in your build? |
| 09:57:24 | _bilgus | #if defined(DEBUG) || defined(SIMULATOR) |
| 09:57:24 | _bilgus | #define KERNEL_OBJECT_CHECKS 1 /* Always 1 for DEBUG and sim*/ |
| 09:57:38 | munkis | how do bin increases erode the plugin buf? |
| 09:57:49 | _bilgus | they gotta go somewhere |
| 09:57:55 | munkis | and yes i have DEBUG enable on my driver build. |
| 09:57:57 | _bilgus | the plugin buf is at the end |
| 09:58:32 | _bilgus | as our bin increases it overflows into the remaining plugin buf |
| 09:59:39 | munkis | yeah but #define PLUGIN_BUFFER_SIZE 0xwhatever implies that it is fixed size and would herefore come off of something before it |
| 10:00 |
| 10:03:25 | munkis | huh my build is ~30K larger than the official build |
| 10:03:55 | _bilgus | mmm you might b right it might be eating the audio buffer |
| 10:04:23 | _bilgus | looking at the lds it calculates dram end using the plugin buf |
| 10:04:45 | _bilgus | even worse IMO but I suppose makes sense |
| 10:05:11 | _bilgus | with the last commit? |
| 10:05:34 | munkis | what do you mean? |
| 10:05:49 | munkis | no this is a build tha doesn't havee that. |
| 10:10:57 | munkis | I think it's a bug in g#1310, Ill try reverting it and see what happens. |
| 10:10:59 | rb-bluebot | Gerrit review #1310 at https://gerrit.rockbox.org/r/c/rockbox/+/1310 : fuze+: don't block system on backlight change by Amaury Pouly |
| 10:11:43 | munkis | or well probably actually 1308 |
| 10:12:03 | munkis | I'll ee what happens if I revert them. |
| 10:22:04 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 10:26:11 | | Quit advcomp2019__ (Ping timeout: 264 seconds) |
| 11:00 |
| 11:56:23 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:45:02 | | Quit advcomp2019_ (Read error: Connection reset by peer) |
| 12:47:10 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 12:49:51 | | Quit Piece_Maker (Read error: Connection reset by peer) |
| 12:53:33 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 12:54:11 | | Quit advcomp2019 (Read error: Connection reset by peer) |
| 13:00 |
| 13:00:39 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 13:08:47 | | Join ZincAlloy [0] (~Adium@95.90.188.174) |
| 13:13:18 | | Quit ZincAlloy (Ping timeout: 260 seconds) |
| 13:17:50 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:4883:2218:965c:f614) |
| 13:56:27 | *** | Saving seen data "./dancer.seen" |
| 13:56:46 | munkis | well disabling saves almost a k |
| 13:57:37 | | Join tertu2 [0] (~tertu@user/tertu) |
| 13:58:58 | | Quit tertu (Ping timeout: 260 seconds) |
| 14:00 |
| 14:09:23 | | Quit ufdm_ (Quit: Leaving) |
| 14:09:35 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 15:00 |
| 15:23:11 | | Quit rasher (Ping timeout: 246 seconds) |
| 15:23:12 | | Quit dys (Ping timeout: 260 seconds) |
| 15:24:16 | | Quit Guest6805 (Changing host) |
| 15:24:16 | | Join Guest6805 [0] (~yang@fsf/member/yang) |
| 15:24:26 | | Nick Guest6805 is now known as yang (~yang@fsf/member/yang) |
| 15:24:57 | | Join rasher [0] (~rasher@user/rasher) |
| 15:56:31 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:18:41 | _bilgus | 1k vs 30k thats a big discrepancy |
| 16:19:55 | | Join dys [0] (~dys@user/dys) |
| 16:30:13 | munkis | my daily is ~45 commits ahead of master. |
| 17:00 |
| 17:25:58 | | Join ats_ [0] (~ats@cartman.offog.org) |
| 17:26:01 | | Join SammysHP_ [0] (~SammysHP@faol.sammyshp.de) |
| 17:26:42 | | Join GeekShadow [0] (~antoine@82-64-164-139.subs.proxad.net) |
| 17:26:48 | | Quit SammysHP (Ping timeout: 246 seconds) |
| 17:26:48 | | Quit ats (Ping timeout: 246 seconds) |
| 17:26:48 | | Nick SammysHP_ is now known as SammysHP (~SammysHP@faol.sammyshp.de) |
| 17:26:48 | | Quit kadoban (Ping timeout: 246 seconds) |
| 17:27:27 | | Quit Rondom (Ping timeout: 268 seconds) |
| 17:27:36 | | Join Rondom [0] (~rondom@user/rondom) |
| 17:28:23 | | Quit GeekShad1w (Ping timeout: 264 seconds) |
| 17:29:10 | | Quit Piece_Maker (Quit: ZNC 1.8.2 - https://znc.in) |
| 17:29:18 | | Quit toruvinn (Ping timeout: 268 seconds) |
| 17:29:25 | | Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 17:31:36 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 17:36:23 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 17:56:32 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:39:51 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:30:46 | | Quit _bilgus (Ping timeout: 260 seconds) |
| 19:56:34 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:09:41 | | Join massiveH [0] (~massiveH@ool-18e4ebfe.dyn.optonline.net) |
| 20:25:16 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 21:00 |
| 21:34:23 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 21:56:36 | *** | No seen item changed, no save performed. |
| 22:00 |
| 22:38:13 | | Quit cockroach (Quit: leaving) |
| 23:00 |
| 23:50:26 | | Quit massiveH (Read error: Connection reset by peer) |
| 23:55:10 | | Join massiveH [0] (~massiveH@ool-18e4ebfe.dyn.optonline.net) |
| 23:56:38 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).