Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-11-05

00:12:10 Join __builtin [0] (~quassel@rockbox/developer/builtin)
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:22:34 Join ZincAlloy [0] (
02:27:39 Quit ZincAlloy (Ping timeout: 268 seconds)
03:56:16***Saving seen data "./dancer.seen"
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:03:52 Quit nihilazo (Remote host closed the connection)
07:46:02 Join massiveH [0] (
07:56:19***Saving seen data "./dancer.seen"
08:20:02munkis_bilgus you have any issues with my committing the new playmode?
08:21:47q3kuser890104: are you working on nano3/4g support? i was about to attempt that out of boredom, too
08:23:14user890104q3k: 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:40q3kah, 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:45user890104the bootloader builds and runs on target, also he made a n4g one but it didn't run in his test
08:24:10user890104here you are: user890104/rockbox/-/tree/nano3g4g">
08:24:41q3kcool, 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:42user890104i also have his original commit tree, but squashed them so rebasing is easier
08:25:47user890104yes, 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:05q3koh, cool :)
08:26:39q3ki'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:58user890104heads up about dirty fixes (commented out rockbox code), and large portions of comments in spanish
08:27:14q3kfreemyipod has been a great way to catch up to the current knowledge
08:27:51user890104about n4g, there's openiBoot, and since ipod touch 2g has the same SoC, we could use some code from there
08:28:36q3kright, 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:09user890104both 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:16q3khaven't scrolled through much, but there's interrupts, mmu, pmic, uart, ... anything else we need?
08:29:50q3k(... clocking/clock tree)
08:29:52user890104well, it basically boots, but some things are missing, e.g. battery adc is not implemented
08:30:19user890104i don't remember if there was support for n4g adc in emcore
08:30:43q3kand 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:02q3klike, the battery adc - is it a SoC thing, or some discrete/nano-specific thing?
08:31:22user890104i'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:58user890104well, 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:59q3kmy 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:19user890104well, i'm going to do this anyway :)
08:32:41q3kwell, lemme log into the rockbox gerrit then so that you can add me to reviewers whenever you have something ready
08:32:58q3ki like reviewing code, so i'll gladly do that... just at best effort SLA
08:33:27q3kthere, username q3k
08:33:45user890104for nano3g, i think it uses the same (or very similar) codec to n2g, so audio output should mostly work
08:34:14q3kalso 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:27q3kif me being a second pair of eyes on this will help, i'll gladly do that
08:35:55q3kthere, bidding on an n3g now :)
08:41:53 Quit massiveH (Quit: Leaving)
08:42:46 Join zizzy [0] (
08:42:53zizzyhello there
08:42:58zizzyq3k: here I am
08:43:32zizzyI haven't bought the n4g yet :P
08:43:53q3k(brought a friend who i'm also trying to nostalgia-bait into doing some n3g/n4g research)
08:44:04user890104ah, nice
08:44:57user890104i 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:08user890104(SoC is the same as n4g)
08:47:08q3ki 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:14q3kfwiw 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:55q3kbut first i need to catch up on the current state of the art once i have hardware in hand.
08:49:13user890104sounds like a good plan
08:49:32q3kand i think zizzy is more interested in the original firmware just because it's also fairly obscure
08:50:33user890104yeah, all the EFI stuff is strange for a music player, and it also has module for ISO9660 booting IIRC
08:50:55user890104no idea where apple copy/pasted from
09:00 has EFI?
09:04:32zizzyI remember seeing EFI Version in diags screen
09:05:03zizzybut I thought this is a remain from their dev environment
09:12:30 Quit Romster (Ping timeout: 260 seconds)
09:14:19user890104no, all drivers from n3g and up are EFI
09:17:28_bilgusmunkis looks fine to me
09:20:15rb-bluebotBuild Server message: New build round started. Revision 13ac485625, 303 builds, 12 clients.
09:23:50munkiswhat effects would increasing my plugin buffer size have?
09:28:54 Join dfgg [0] (~dfgg@user/dfgg)
09:30:12_bilguslower playtime the audio buffer would suffer
09:30:56_bilgusplugins get compiled every time so the chnage in address wouldnt hurt anything
09:31:53_bilgusbut otherwise I doubt much else
09:32:06 Join Romster [0] (~romster@user/romster)
09:32:37_bilgusi'm thinking about splitting pictureflow out to two separate plugins
09:33:00_bilgusI think it might already do an overlay IDR
09:33:57_bilgusMy thoughts are a standalone db generator so frankenpod can get their wish
09:34:34_bilgustoo many songs to build a pf album before it runs out of ram
09:35:38rb-bluebotBuild Server message: Build round completed after 923 seconds.
09:35:39rb-bluebotBuild Server message: Revision 13ac485625 result: All green
09:38:37munkisfor some reason I thought the audio buffer was fixed size.
09:47:53_bilgusfixed 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_bilgusit only has 2mb of ram so if it can do it you should be able
09:51:00munkisI've just noticed that plugins seem to be slightly slower now, and was wondering if it was a result.
09:51:42munkismy audio buffer is probably still larger than the clips entire ram.
09:53:37munkisadditionally 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_bilgusevery bin increase erodes the plugin buffer so you might be on to something
09:56:20***Saving seen data "./dancer.seen"
09:56:53_bilgusIs 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:38munkishow do bin increases erode the plugin buf?
09:57:49_bilgusthey gotta go somewhere
09:57:55munkisand yes i have DEBUG enable on my driver build.
09:57:57_bilgusthe plugin buf is at the end
09:58:32_bilgusas our bin increases it overflows into the remaining plugin buf
09:59:39munkisyeah but #define PLUGIN_BUFFER_SIZE 0xwhatever implies that it is fixed size and would herefore come off of something before it
10:03:25munkishuh my build is ~30K larger than the official build
10:03:55_bilgusmmm you might b right it might be eating the audio buffer
10:04:23_bilguslooking at the lds it calculates dram end using the plugin buf
10:04:45_bilguseven worse IMO but I suppose makes sense
10:05:11_bilguswith the last commit?
10:05:34munkiswhat do you mean?
10:05:49munkisno this is a build tha doesn't havee that.
10:10:57munkisI think it's a bug in g#1310, Ill try reverting it and see what happens.
10:10:59rb-bluebotGerrit review #1310 at : fuze+: don't block system on backlight change by Amaury Pouly
10:11:43munkisor well probably actually 1308
10:12:03munkisI'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:56:23***Saving seen data "./dancer.seen"
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] (
12:54:11 Quit advcomp2019 (Read error: Connection reset by peer)
13:00:39 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
13:08:47 Join ZincAlloy [0] (~Adium@
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:46munkiswell disabling saves almost a k
13:57:37 Join tertu2 [0] (~tertu@user/tertu)
13:58:58 Quit tertu (Ping timeout: 260 seconds)
14:09:23 Quit ufdm_ (Quit: Leaving)
14:09:35 Join ufdm [0] (
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:18:41_bilgus1k vs 30k thats a big discrepancy
16:19:55 Join dys [0] (~dys@user/dys)
16:30:13munkismy daily is ~45 commits ahead of master.
17:25:58 Join ats_ [0] (
17:26:01 Join SammysHP_ [0] (
17:26:42 Join GeekShadow [0] (
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 (
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 -
17:29:18 Quit toruvinn (Ping timeout: 268 seconds)
17:29:25 Join toruvinn [0] (
17:31:36 Join kadoban [0] (~kadoban@user/kadoban)
17:36:23 Join Piece_Maker [0] (
17:56:32***Saving seen data "./dancer.seen"
18:39:51 Quit ZincAlloy (Quit: Leaving.)
19:30:46 Quit _bilgus (Ping timeout: 260 seconds)
19:56:34***Saving seen data "./dancer.seen"
20:09:41 Join massiveH [0] (
20:25:16 Join _bilgus [0] (~bilgus@
21:34:23 Join cockroach [0] (~blattodea@user/cockroach)
21:56:36***No seen item changed, no save performed.
22:38:13 Quit cockroach (Quit: leaving)
23:50:26 Quit massiveH (Read error: Connection reset by peer)
23:55:10 Join massiveH [0] (
23:56:38***Saving seen data "./dancer.seen"

Previous day | Next day