--- Log for 05.11.121  Server: sodium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 3 days and 22 hours ago

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] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
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] (~massiveH@ool-18e4ebfe.dyn.optonline.net)
07.56.19 ***     Saving seen data "./dancer.seen"
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: 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.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: 3New 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: 3Build round completed after 923 seconds.
09.35.39 #       <rb-bluebot> Build Server message: 3Revision 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.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> 3Gerrit review #1310 at https://gerrit.rockbox.org/r/c/rockbox/+/1310 : 3fuze+: 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.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] (~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.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.09.23 Quit    ufdm_ (Quit: Leaving)
14.09.35 Join    ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
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 #       <_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.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.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] (~massiveH@ool-18e4ebfe.dyn.optonline.net)
20.25.16 Join    _bilgus [0] (~bilgus@162.154.213.134)
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] (~massiveH@ool-18e4ebfe.dyn.optonline.net)
23.56.38 ***     Saving seen data "./dancer.seen"