--- Log for 13.11.120  Server: barjavel.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 6 days and 13 hours ago

00.00.16 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
00.00.42 Quit    [7] (Ping timeout: 260 seconds)
00.00.58 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
00.06.49 ***     Saving seen data "./dancer.seen"
00.07.54 Quit    Rower (Ping timeout: 272 seconds)
00.10.43 #       <braewoods> _bilgus: checked it. white screen, no signs of life.
00.10.53 #       <braewoods> _bilgus: i waited a bit.
00.11.04 #       <braewoods> _bilgus: not sure what it was supposed to do.
00.11.41 #       <braewoods> _bilgus: basically, on a successful build the LCD does these things.
00.11.47 #       <braewoods> it flashes (it seems to default to white BG)
00.11.52 #       <braewoods> then it changes to black
00.11.58 #       <braewoods> then it starts to print text
00.12.00 #       <braewoods> on the LCD
00.12.06 #       <braewoods> and eventually it switches control to rockbox
00.13.01 #       <braewoods> so it starts as black on white and then flickers, changing to white on black
00.13.04 #       <braewoods> and prints text
00.13.06 #       <braewoods> then boots
00.13.19 #       <braewoods> why it's not working for BL is beyond me
00.13.27 #       <braewoods> but it does work fine in the plugin iriver_flash
00.13.37 #       <braewoods> i see it working when you boot up properly
00.14.04 #       <braewoods> we need to fix this somehow though or else i can't do what i planned to
00.14.12 #       <braewoods> since it needs a functional LCD during boot to work
00.14.31 #       <braewoods> (the H120 bootloader has a navigation menu, otherwise silent boot would be fine)
00.19.09 #       <braewoods> _bilgus: i think we may want to check the code for BOOTLOADER exclusions or exclusives
00.19.22 #       <braewoods> _bilgus: we may need to pull something into the bootloader for it to function correctly
00.19.27 #       <braewoods> or exclude something
00.20.01 #       <braewoods> the fact the main firmware works suggests either some critical code is run in a different order
00.20.07 #       <braewoods> or it isn't done at all
00.20.09 #       <braewoods> or both
00.27.17 #       <braewoods> nothing stands out in crt0.S
00.27.20 #       <braewoods> unsurprisingly
00.27.24 #       <braewoods> it's probably not responsible
00.29.09 #       <braewoods> _bilgus: one thing i noticed. the BL for the H1x0 and H3x0 both have manual power control. their power_init excludes the automatic drive power on that is present in the normal code.
00.29.27 #       <braewoods> i wonder if we could use the HD spinup to signal code has been reached
00.29.49 #       <braewoods> it may trigger whenever it is powered up
00.30.18 #       <braewoods> the sound of that would be a viable way to send a simple signal
00.32.10 #       <braewoods> but the fact i don't even heard that means the BL fails to reach the storage activation code later on
00.32.46 #       <braewoods> so yea... somehow the init code for the BL and/or LCD appears to be getting stuck
00.33.14 #       <braewoods> it doesn't even boot at all if i wait a bit
00.33.40 #       <braewoods> either it's doing something that causes it to behave erratically like a null PTR dereference
00.34.18 #       <braewoods> there's an idea
00.34.26 #       <braewoods> hm
00.34.46 #       <braewoods> _bilgus: one thing i notice, the update functions only do something when the LCD is turned on
00.34.55 #       <braewoods> i wonder what would happen if the functions were no-ops for the BL
00.34.59 #       <braewoods> would it still boot?
00.35.18 #       <braewoods> anyway
00.35.22 #       <braewoods> bbl, got some stuff to do
00.39.16 Quit    advcomp2019_ (Ping timeout: 256 seconds)
00.39.25 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
00.52.07 Quit    atsampson (Ping timeout: 272 seconds)
02.03.10 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
02.06.51 ***     Saving seen data "./dancer.seen"
02.30.48 Quit    advcomp2019 (Ping timeout: 258 seconds)
02.31.48 Quit    Topy44 (Ping timeout: 260 seconds)
02.42.46 Join    Topy44 [0] (1WCuRkVvSJ@bellatrix.uberspace.de)
02.47.15 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
03.06.26 Quit    ac_laptop (Ping timeout: 256 seconds)
04.06.54 ***     Saving seen data "./dancer.seen"
05.06.54 Quit    Oksana (Read error: Connection reset by peer)
05.23.16 Join    edhelas [0] (9d94237298@149-210-220-39.colo.transip.net)
05.38.25 Join    prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net)
05.42.16 Quit    Stanley00 ()
06.06.58 ***     Saving seen data "./dancer.seen"
06.12.42 Quit    mendel_munkis (Ping timeout: 272 seconds)
06.13.10 Join    mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net)
06.17.38 #       <_bilgus> braewoods, I figured it was an issue of the dma still but the math looks fine AFAICT
06.17.56 #       <braewoods> _bilgus: i see
06.21.30 #       <_bilgus> well another thing to try is to give it a different screen buffer static and see if it works
06.22.49 #       <braewoods> _bilgus: do whatever you want to try. and if it would help you along i can send you one of the units.
06.27.04 #       <braewoods> _bilgus: maybe DMA is just a red herring. i'm not sure at this point.
06.31.38 Join    MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:e8a4:66e6:8ec1:5d59)
06.32.55 Quit    mendelmunkis (Remote host closed the connection)
06.33.39 Join    mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net)
06.34.54 #       <_bilgus> I mean trying to not have you do that but maybe it'll make it a bit faster
06.35.34 #       <braewoods> _bilgus: it won't cost me much. did you also want to test the LCD remote?
06.36.13 #       <braewoods> how about this
06.36.19 #       <braewoods> we see how far we get over the weekend
06.36.27 #       * braewoods shrugs.
06.36.33 #       <_bilgus> sounds good
06.36.54 #       <braewoods> though it was interesting how some changes to the LCD code in 2009 broke it for 10 years
06.37.02 #       <braewoods> and then again recently
06.37.08 #       <braewoods> so what really broke it?
06.37.30 #       <braewoods> we may not need the workaround if we can find out what really is going on.
06.39.01 #       <braewoods> _bilgus: let me know when you got a new build
06.41.05 #       <_bilgus> here is a build to try before I leave for the morning this one gives it a real 'slightly' oversized framebuffer
06.41.32 #       <_bilgus> I can't actually decipher what line sized chunks actually means for the DMA
06.42.20 #       <_bilgus> its entirely possible its falling off the end of the world and has always been doing that it just doesn't matter till the wrong thing is after it
06.46.49 #       <braewoods> _bilgus: that was interesting.
06.47.06 #       <braewoods> it booted.. but the screen was random garbage until RB booted
06.47.24 #       <braewoods> that's the main change
06.49.11 #       <_bilgus> yeah there is just un initialized data there
06.49.26 #       <_bilgus> of so entirely possible its a null pointer issue
06.50.03 #       <_bilgus> next one lets try making routing it back to the real framebuffer
06.50.11 #       <_bilgus> but bigger
06.51.12 #       <braewoods> _bilgus: one thing to note, address 0 is mapped to the ROM on these targets
06.51.28 #       <braewoods> so reads to test will be returning data from the ROM
06.51.46 #       <braewoods> writes will silently fail if nothing else
06.52.04 #       <braewoods> you need a really long command sequence to specific addresses to even modify it
06.52.07 #       <braewoods> so unlikely to harm it
06.52.36 #       <_bilgus> I just came to a realization that the lcd code needs initd properly before HBADDR is valid I bet its missing
06.52.50 #       <braewoods> FBADDR?
06.53.06 #       <braewoods> perhaps so
06.53.08 #       <_bilgus> its the macro that gets the buffer
06.53.26 #       <braewoods> that was the only direct change to the LCD code
06.53.33 #       <braewoods> that i saw for H300 specific code
06.58.38 #       <_bilgus> hmm not finding the lcd_init
07.00.40 #       <_bilgus> ha
07.00.45 #       <_bilgus> ok another try
07.03.07 #       <braewoods> _bilgus: i thought lcd_init was called from iriver_h300.c
07.03.50 #       <_bilgus> it is and it is after the backlight init
07.04.37 #       <_bilgus> same link
07.04.43 #       <_bilgus> I think this should work
07.05.25 #       <braewoods> will try it. moment.
07.05.57 #       <_bilgus> I think someone rewrote it to take into account when screen is off and neglected to make sure it was init'd before calling lcd code
07.08.19 Join    atsampson [0] (~ats@cartman.offog.org)
07.08.30 #       <braewoods> _bilgus: it appears to working normally now.
07.09.07 #       <braewoods> the lcd screen turns black
07.09.12 #       <braewoods> and prints stuff
07.09.16 #       <braewoods> then loads rockbox
07.09.28 #       <braewoods> i wonder if we can try disabling my workaround.
07.09.32 #       <braewoods> for DMA
07.18.14 #       <_bilgus> I think your workaround is still needed
07.18.31 #       <braewoods> ok
07.18.37 #       <braewoods> what was your fix?
07.18.55 #       <_bilgus> I'll rework this tonight and should have one more for you saturday morning
07.19.15 #       <_bilgus> I moved the lcd_init to before the backlight init
07.19.35 #       <braewoods> ok
07.20.01 #       <_bilgus> I saw the patch yesterday about making lcd_off = backlight_off
07.20.50 #       <_bilgus> didn't occur to me they started pulling in the lcd stuff before init with that patch
07.23.58 #       <_bilgus> up on gerrit bbl
07.37.33 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
07.47.37 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08.06.59 ***     Saving seen data "./dancer.seen"
08.20.42 #       <braewoods> wow. the latitude 3350 is incrediblely repair friendly.
08.20.59 #       <braewoods> almost everything is exposed for repair by just removing the bottom cover
08.37.18 Quit    massiveH (Quit: Leaving)
08.43.17 Quit    edhelas (Remote host closed the connection)
09.17.56 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
09.48.43 Nick    mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net)
09.49.54 #       <speachy> ok, v8 of my usb insertion prompt is up, now with sane bootloader handling and manual updates.
09.50.30 #       <speachy> I'm tempted to change the default to mass storage (ie the existing behavior) and commit it as-is, even with the WPS wonkiness.
09.50.38 #       <braewoods> speachy: meaning?
09.50.51 #       <braewoods> it will be selectable what it does when connected to usb?
09.52.04 #       <braewoods> just keep in mind not all RB ports can charge over usb, if that's somehow relevant to what you're doing.
09.52.23 #       <braewoods> e.g., H120 only charges over the barrel jack.
09.52.39 #       <speachy> it's only enabled for targets with HAVE_USB_POWER
09.52.43 #       <braewoods> ah.
09.52.57 #       <braewoods> h300 should support that
09.53.23 #       <braewoods> in other news it seems bilgus found the bug making the H300 bootloaders fail
09.54.13 #       <braewoods> LCD is his area so i'll let him figure out how he wants to finalize the fix.
09.55.07 #       <braewoods> once that's all said and done I can finally start updating the H300 BL
09.55.31 #       <braewoods> and work on pushing out a new set of bootloaders
09.55.33 #       <speachy> the actual fix is pretty simple, but I don't know if he intends to commit the other changes he made along the way.
09.55.38 #       <braewoods> indeed
09.55.41 #       <braewoods> i'll wait and see
09.56.42 #       <braewoods> the OF is still useful for one thing i've found
09.56.53 #       <braewoods> it's good for recovering from a bad bootloader build
09.57.02 #       <speachy> ...for flashing new images?  :D
09.57.09 #       <braewoods> yea, basically.
09.57.24 #       <mendel_munkis> just don't force ask
09.57.26 #       <braewoods> but once i'm done i'll be discarding the OF
09.57.36 #       <braewoods> the OF is useful for development but not much else
09.57.53 #       <braewoods> i found a way to make the risk of bootloader bricking nearly 0
09.58.02 #       <braewoods> made this whole debugging possible
09.58.35 #       <braewoods> i basically had to reset the unit quickly and power on again
09.58.40 #       <braewoods> it tricked the BL into booting the OF
10.00.06 #       <speachy> mendel_munkis: the patch currently defaults to ask (which IMO is more user-friendly) but there's a config setting to change that.
10.03.39 #       <braewoods> speachy: so basically it sounds like you're implementing an android feature.
10.03.54 #       <braewoods> it won't expose file access over usb until you do so
10.07.00 ***     Saving seen data "./dancer.seen"
10.16.03 #       <speachy> yep
10.31.21 Quit    amsomniac (Remote host closed the connection)
10.50.40 Quit    Huntereb (Read error: Connection reset by peer)
11.25.48 #       <_bilgus> I'm going to pull the lcd stuff out of backlight_init and put it where it is supposed to be
11.30.16 #       <braewoods> _bilgus: go ahead and i'll retest my own patch to see if it is still needed.
11.31.12 #       <_bilgus> Its built on top of your patch you might just want to hit head and move the lcd_init and remote_lcd_int above the backlight
11.32.06 #       <braewoods> _bilgus: it sounds like you were wanting to fix it in the subroutines and not the bootloader?
11.33.09 #       <_bilgus> its going to be the same issue for bot it just happens that by the time the fw is running the lcd has been initialized by someone else
11.33.39 #       <_bilgus> we shall make sure that doesn't happen again --
11.36.24 #       <mendel_munkis> looking at docs/CREDITS line 401 anyone know if that is one name or two?
11.38.42 #       <braewoods>  mendel_munkis: one. that's how it is presented in the commmits.
11.38.54 #       <braewoods> 5047b2e180ee72d869d6a50eabac5ebe5fdbd9cc ...
11.39.10 #       <braewoods> etc
11.41.34 #       <mendel_munkis> thanks.
11.46.27 Join    advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
11.47.01 Quit    advcomp2019 (Ping timeout: 264 seconds)
11.53.03 #       <_bilgus> well it appears everyone else that has a screen that is not viewable when BL off does it the same so I will fix the other things I saw and just make sure backlight_init is after lcd_init
11.53.28 #       <_bilgus> (everywhere)
11.57.30 #       <braewoods> _bilgus: incidently, there's some units that work w/o the backlight being on but not many
11.57.44 #       <braewoods> the H120's screen doesn't need to use a backlight all the time
11.58.04 #       <braewoods> then again it's a rather simple screen
11.58.09 #       <braewoods> monochrome or grayscale
12.07.01 ***     Saving seen data "./dancer.seen"
12.34.01 #       <braewoods> speachy: regarding your USB changes... i'd go for 3 configurable options.
12.34.12 #       <braewoods> speachy: Charge Only, UMS, and Ask
12.34.38 #       <braewoods> meaning you can make it automatically choose for you or ask every time
12.43.07 #       <mendel_munkis> that's what the patch does
12.44.35 #       <braewoods> oh.
12.46.37 #       <braewoods> go figure. pretty much all the MTP libraries i can find are C++.
12.49.11 #       <_bilgus> braewoods, at you leisure can you test the bootloade at the same link?
12.49.21 #       <braewoods> ok. let me get it setup.
12.49.41 #       <_bilgus> I found 4 other bootloaders with the same bug
12.52.43 #       <braewoods> _bilgus: works.
12.52.53 #       <braewoods> nothing unusual though the print out seems a bit sparse
12.53.26 #       <_bilgus> like something is missing now?
12.53.56 #       <braewoods> or maybe i'm just imagining it.
12.54.09 #       <braewoods> i thought maybe some printfs were still removed / commented out
12.54.14 #       <braewoods> that's all
12.55.18 #       <_bilgus> uh i'll check before I commit them real quick
12.56.03 #       <braewoods> _bilgus: so in other words... my discovery of this bug fixed other bootloaders that would have been left unbootable as well?
12.56.49 #       <braewoods> just i didn't originally know it would turn out to be a general issue
13.00.37 #       <_bilgus> its hard to say but most likely
13.01.18 #       <_bilgus> I didn't check if they all had lcd_update() in their backlight_init() but at least 2 did
13.01.47 #       <_bilgus> so those would have surely crashed
13.02.47 #       <mendel_munkis> this is strange. in September I rebased my daily driver branch on master built the new toolchain and rebuilt. today I went to rebuild based on master and I see a bunch of what look like toolchain issues.
13.04.49 #       <braewoods> mendel_munkis: were you building for PP or ColdFire?
13.05.02 #       <braewoods> speachy released a new toolchain in october
13.05.04 #       <braewoods> for those
13.05.12 #       <_bilgus> braewoods, can you unset the WIP on your gerrit #2968
13.05.15 #       <fs-bluebot> Gerrit review #2968 at http://gerrit.rockbox.org/r/2968 : h300: fix one long-standing bootloader bug by James Buren
13.05.29 #       <_bilgus> its not letting me remove the WIP label
13.06.11 #       <mendel_munkis> nope its arm
13.06.29 #       <braewoods> mendel_munkis: PP is arm
13.07.04 #       <braewoods> mendel_munkis: probably should delete the old toolchain and run the script again
13.07.11 #       <braewoods> it was changed in October
13.07.31 #       <braewoods> _bilgus: how do you remove WIP?
13.07.36 #       <mendel_munkis> it's not pp
13.07.42 #       <_bilgus> set review
13.07.50 #       <braewoods> ok
13.07.52 #       <braewoods> done
13.07.58 #       <mendel_munkis> but thanks for the advice
13.08.03 #       <fs-bluebot> Build Server message: New build round started. Revision f65fb2a, 293 builds, 8 clients.
13.08.10 #       <braewoods> mendel_munkis: uhm....
13.08.12 #       <_bilgus> thank you
13.08.17 #       <braewoods> mendel_munkis: he updated the arm toolchain.
13.08.25 #       <braewoods> mendel_munkis: just PP is the most common arm target
13.08.29 #       <braewoods> that i know of for RB
13.08.47 #       <mendel_munkis> oh I though you where saying he updated the pp subset of the arm toolchain.
13.08.52 #       <braewoods> nah.
13.09.13 #       <braewoods> you should try rebuilding it
13.09.17 #       <braewoods> it's based on GCC 4.9.x nw
13.09.19 #       <braewoods> now
13.10.01 #       <braewoods> we ended up disabling a new "feature" of GCC 4.9.x since it was generating bad code
13.10.03 #       <braewoods> for now
13.10.22 #       <mendel_munkis> yeah thats what I have. I just rechecked the calendar my last build was in october
13.10.31 #       <mendel_munkis> but I will rebuild and see what happens
13.10.48 #       <braewoods> well it was late october when it landed
13.11.06 #       <braewoods> err
13.11.08 #       <braewoods> no
13.11.10 #       <braewoods> around october 13th
13.14.05 #       <_bilgus> I'll be setting up new toolchains from scratch probably this weekend I'll try to do it as noob as possible (not that hard lol) and write down some notes
13.15.14 #       <braewoods> _bilgus: did you check the H120?
13.15.25 #       <braewoods> it also has the backlight initialized before lcd
13.17.47 #       <_bilgus> no I just greped backlight_init prior to lcd_init
13.17.54 #       <_bilgus> but I'll look
13.18.09 #       <braewoods> in current master
13.18.14 #       <braewoods> iriver_h1x0.c
13.18.27 #       <braewoods> line 488 and 491
13.18.42 #       <_bilgus> yep sure does
13.18.53 #       <_bilgus> lets see if I can up my grep skills
13.19.02 #       <braewoods> though oddly the H120 actually worked with master
13.19.04 #       <braewoods> so
13.19.06 #       <braewoods> i dunno
13.19.18 #       <braewoods> maybe just some targets have this issue
13.20.18 #       <braewoods> though if i'm being honest some of these #ifdefs in the bootloader are pointless
13.20.25 #       <braewoods> e.g., #ifdef CPU_COLDFIRE
13.20.26 #       <mendel_munkis> so now I have to go check if my build server is up to date as well.
13.20.35 #       <_bilgus> it all depends if someone optimized them
13.20.55 #       <braewoods> the target for that BL is always a coldifre
13.21.03 #       <braewoods> so why is it useful to have that ifdef?
13.21.18 #       <braewoods> lol
13.21.19 #       <_bilgus> tying lcd_enable(false/true) and backlight_on/off
13.21.38 #       <braewoods> _bilgus: if you need me to I can test an H120 bootloader
13.21.48 #       <braewoods> i have a unit still with the OF so the recovery method should work for it
13.22.01 #       <_bilgus> I'll just search a little deeper and submit another patch
13.22.20 #       <_bilgus> but feel free more testing the better
13.22.29 #       <braewoods> i'll need to anyway
13.22.32 #       <braewoods> at some point
13.22.40 #       <braewoods> it is pretty much feature complete
13.22.42 #       <braewoods> but
13.23.05 #       <braewoods> i plan to wait to build its final release for V7 until I'm done with the H300
13.23.15 #       <braewoods> these will do a lot of the port
13.23.18 #       <fs-bluebot> Build Server message: Build round completed after 915 seconds.
13.23.22 #       <fs-bluebot> Build Server message: Revision f65fb2a result: All green
13.25.07 Quit    bonfire (Quit: Leaving)
13.25.17 #       <braewoods> _bilgus: serious question. i noticed you patched my fixes too.
13.25.33 #       <braewoods> _bilgus: why'd you change these loops with an empty body with 2 ;;s?
13.25.49 #       <braewoods> that's basically, empty loop statement / body and another empty statement outside it
13.26.05 #       <braewoods> the second ; is technically not part of the loop
13.26.21 #       <braewoods> though it does nothing so it will be optimized away
13.26.28 #       <braewoods> but still, why? utterly redundant.
13.26.53 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13.27.07 #       <_bilgus> it just helps show that it is an empty loop
13.27.14 #       <braewoods> I see.
13.27.39 #       <_bilgus> some people do {} and others just a space
13.28.23 #       <braewoods> it's kinda funny how we have void / null statements just to satisfy the language grammar in some situations
13.28.43 #       <braewoods> shell has the same problem, you have a null statement (:) for these situations
13.29.17 #       <braewoods> otherwise there's no point to these
13.30.02 #       <_bilgus> actually clang will throw warnings if a while loop is empty so its just something thats stuck
13.30.38 #       <_bilgus> others probably do too but I'm not familar with any
13.30.49 #       <braewoods> i just found shell a weird special case
13.31.11 #       <braewoods> it's a syntax error to have an empty loop / conditional / function body
13.31.25 #       <braewoods> there's no way to denote an empty body like in C
13.31.39 #       <braewoods> you have to provide a statement period
13.32.11 #       <_bilgus> I'm sure if you go back far enough there was a very valid optimization reason when it was birthed
13.32.47 #       <_bilgus> that whole technical baggage thing
13.32.58 #       <braewoods> probably to due with shell being line oriented
13.33.27 #       <braewoods> you can use semicolons to put multiple statements on one line but that's the only time you'd use it
13.33.36 #       <braewoods> line endings normally terminate them
13.33.39 #       <_bilgus> huzzah I moved to my text search and was able to find the others I missed
13.34.05 #       <_bilgus> yeah I hate when people do that statement;statement;statement;
13.34.28 #       <braewoods> you can also do this in C though i can't say i know very many situations where it's wise
13.34.33 #       <braewoods> the comma operator
13.34.47 #       <braewoods> the main time where you have to use it is in for loops
13.34.50 #       <_bilgus> and I also find int x =0, y = 0; mildly triggering too
13.35.09 #       <braewoods> why? it can be useful in that case. it's not a statement, it's a declaration.
13.35.31 #       <_bilgus> sure but just put them on their own line so you don't miss one
13.35.56 #       <braewoods> if anything i'd whine about how pointers work in this situation
13.36.10 #       <_bilgus> Ive also had situations of the compiler screwing up and making the rest an int after the first declare
13.36.10 #       <braewoods> unless it's part of a typedef the pointer does not propagate
13.36.38 #       <_bilgus> I haven't seen that one in a long time but it left a lasting scar
13.36.52 #       <braewoods> you mean the situations where C defaults to int?
13.37.04 #       <braewoods> which are normally warnings these days
13.37.32 #       <braewoods> interesting side note
13.37.46 #       <_bilgus> no like this LONG y = 0, x = 0 and x becoming an int
13.38.00 #       <braewoods> eh? i thought x would be long too.
13.38.14 #       <braewoods> integer literals default to type int. you can only modify this by casting or adding an appropriate suffix.
13.38.31 #       <braewoods> L makes it become 'long', a second L makes it become long long.
13.38.38 #       <braewoods> and 'U' makes it unsigned
13.38.48 #       <_bilgus> yeah and people often fail to do that
13.39.25 #       <_bilgus> half the issues in our lua port when I picked it up were from things like that
13.39.56 #       <braewoods> i can't say that seems to be an actual issue?
13.40.05 #       <braewoods> long x, y; produces 2 longs
13.40.08 #       <braewoods> from my tests
13.40.13 #       <braewoods> confirmed with sizeof
13.40.14 #       <_bilgus> I haven't run into that bug in a long while but I also don't tempt fate
13.40.22 #       <braewoods> oh. it's a compiler bug.
13.41.07 #       <braewoods> another thing i learned about enums and integers
13.41.26 #       <_bilgus> enums are always an integer type
13.41.36 #       <braewoods> there's not much you can do to control the actual type the compiler chooses to use for your enum
13.41.38 #       <braewoods> i know
13.42.00 #       <braewoods> about the only option i found was to assign a ridiculiously large value to it
13.42.04 #       <mendel_munkis> same set of issues.
13.42.07 #       <braewoods> to increase the size
13.42.11 #       <_bilgus> well you can always force it with a properly sized item
13.42.13 #       <braewoods> mendel_munkis: can you be more specific?
13.42.29 #       <mendel_munkis> just to make sure I should be running gcc 4.9.4?
13.42.33 #       <braewoods> yes
13.42.41 #       <braewoods> i mainly work with coldfire
13.42.53 #       <_bilgus> mendel what device is this?
13.43.18 #       <mendel_munkis> fuze+. (the issues are with nonstandard plugins)
13.43.45 #       <braewoods> "non-standard"?
13.43.47 #       <_bilgus> non standard plugins?
13.44.02 #       <_bilgus> lol like ones you previously made?
13.44.03 #       <mendel_munkis> random stuff from flyspray and suchlike
13.44.25 #       <mendel_munkis> so this is all on me
13.44.29 #       <_bilgus> simple question but did you try nuking the directory?
13.44.32 #       <braewoods> meaning they're third party?
13.44.40 #       * braewoods nukes it from orbit just to be sure.
13.45.20 #       <_bilgus> there are a few make clens that are very specific
13.45.43 #       <_bilgus> so if you had objects from other builds lying around it wouldn't touch em
13.46.25 #       <_bilgus> ask me how I know :P
13.46.33 #       <mendel_munkis> I did make clean but just nuked am trying again
13.48.29 #       <mendel_munkis> yeah same stuff. pretty sure it's new warnings introduced in the new toolchain. I am just surprised I didn't see them before
13.52.25 #       <_bilgus> odd just warnings though?
13.53.29 #       <mendel_munkis> well so far, besides for some stuff that's due to api changes
13.54.47 Join    yang [0] (~yang@freenode/sponsor/fsf.member.yang)
13.59.20 #       <fs-bluebot> Build Server message: New build round started. Revision 47e1f96, 293 builds, 8 clients.
13.59.39 #       <_bilgus> ok that should be the rest of em thank you braewoods..
14.00.09 #       <braewoods> _bilgus: did you use sed? i don't recall grep having any multiline options
14.00.36 #       <_bilgus> no I used jedit
14.00.46 #       <braewoods> oh
14.00.48 #       <braewoods> huh
14.00.50 #       <braewoods> jedit...
14.00.53 #       <_bilgus> then I was able to use (?ms)
14.01.02 #       <braewoods> i never knew people still used it
14.01.09 #       <_bilgus> thats why I missed the other 4
14.01.35 #       <_bilgus> I only use it for text searching I dislike its editor
14.01.47 #       <braewoods> what do you use?
14.01.58 #       <_bilgus> Geany ofc
14.02.05 #       <braewoods> i switched to sublime text a few years ago. best software i ever bought.
14.02.06 #       <braewoods> lol
14.03.58 #       <_bilgus> just having a dark profile available helps a lot
14.04.17 #       <braewoods> for geany?
14.04.24 #       <braewoods> ST3 has plenty of dark color schemes
14.04.30 #       <braewoods> but yea
14.04.32 #       <braewoods> it's not an IDE
14.04.57 #       <_bilgus> for whatever editor you prefer
14.07.05 ***     Saving seen data "./dancer.seen"
14.13.31 #       <_bilgus> speachy you can go ahead and submit what you have and I can revisit it later to make it work with the wps but agree on the override setting I think it'd drive me nuts eventually otherwise
14.14.20 #       <fs-bluebot> Build Server message: Build round completed after 900 seconds.
14.14.22 #       <fs-bluebot> Build Server message: Revision 47e1f96 result: All green
14.14.58 #       <fs-bluebot> Build Server message: New build round started. Revision 6c3cc1c, 293 builds, 8 clients.
14.28.19 #       <fs-bluebot> Build Server message: Build round completed after 800 seconds.
14.28.24 #       <fs-bluebot> Build Server message: Revision 6c3cc1c result: All green
14.41.00 #       <_bilgus> huh theSony A10 and A20 both have 3k size decreases from that skin patch any one with either device able to test HEAD?
14.43.35 #       <mendel_munkis> well the plugin author implemented rbendian.h on his own. and that wasn't even the issue
14.49.58 #       <yang> I have an old MP3 player with FM radio, noname model "friend mp3 FD 100-B FM" which works on 1 x AAA battery. Would anyone like to adopt it ? I don't know how usefull would it be for your project...
14.51.13 #       <yang> it has 128 MB RAM
14.51.58 #       <yang> I am not aware if it can be reused in your project
14.56.28 #       <_bilgus> yang no probably not especially if they aren't widely available thanks though
14.57.16 #       <braewoods> like i told them elsewhere... probably not. and would it even be practical?
14.57.21 #       <braewoods> that won't hold much
14.57.32 #       <mendel_munkis> ok well I think I fixed that issue but now I'm seeing things I know I already fixed.
14.59.04 #       <yang> ok _bilgus
15.01.23 #       <lemon_jesus> hey gang, who's the resident expert on NAND drivers? I'm trying to RE the ipod nano 3g nand driver a bit and I've hit a wall where my knowledge runs out and google searches aren't turning up much.
15.09.52 Quit    ac_laptop (Ping timeout: 260 seconds)
15.10.23 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
15.11.33 #       <_bilgus> lemon_jesus, maybe wodz but I haven't seen our other one in a long while if one is lurking your best bet would be to idle a day or so and put a post on the forum
15.16.07 #       <lemon_jesus> cool, I'll post to the forums and stick around. hopefully someone can help me out.
15.31.02 #       <bluebrother> hmm. So I'm looking into keeping voicefile installs separate in Rockbox Utilty. We do offer current builds and releases, but we have voice files for releases and daily builds. But don't offer daily builds for install. That's a bit ... inconsistent.
15.32.00 #       <bluebrother> so shouldn't we add daily builds back and offer prebuilt voice files for both release and daily builds?
15.35.56 #       <bluebrother> speachy: can you add a [daily] section to build-info with the same items [bleeding] has?
15.36.06 #       <speachy> bluebrother: was about to propose something like that
15.36.17 #       <bluebrother> :)
15.37.17 #       <speachy> so you'd want a timestamp and a revision that corresponds to whatever the daily build is?  same format?
15.38.00 #       <bluebrother> yeah. So we can show that the same way we do for the dev builds.
15.39.13 #       <bluebrother> thinking about it, having something with the list of voice file languages might be good to.
15.39.43 #       <speachy> I could generate several more languages than are being done, but I've only enabled those that I've been told sound okay
15.40.26 #       <bluebrother> if we have a list that are announced in build-info that wouldn't matter much :)
15.40.41 #       <bluebrother> and we could have that list in the [release] section too.
15.40.54 #       * bluebrother checks things
15.42.25 #       <bluebrother> can you add voices=<english,english-us,francais,...>? Using the same strings we have in the voice file filenames? Both to [daily] and [release]?
15.42.37 #       <speachy> there's already a build-info being generated, though not combined into the main build-info file
15.42.40 #       <speachy> [dailies]
15.42.47 #       <speachy> date = "20201113"
15.42.49 #       <speachy> rev = 362f7a3
15.42.51 #       <speachy> is that okay?
15.42.54 #       <bluebrother> oh. Right. I guess that was the file used before.
15.43.04 #       <bluebrother> yep, that's good.
15.43.20 #       <speachy> okay, I'll update the daily script to combine that one in there too
15.43.33 #       <bluebrother> nice.
15.43.49 #       <bluebrother> then I'll add support for those.
15.44.06 #       <bluebrother> have to rework the whole rbutil.ini first though, it's getting kinda messy :)
15.47.23 Quit    livvy (Ping timeout: 240 seconds)
15.48.14 Join    amsomniac [0] (~nadya@2601:181:8300:4db::b45)
15.48.15 Join    livvy [0] (~livvy@gateway/tor-sasl/livvy)
15.48.25 Quit    emacsomancer (Read error: Connection reset by peer)
15.49.53 Join    emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
15.55.49 #       <speachy> bluebrother: build-info should have daily builds in it now
15.57.15 #       <speachy> you want the voices=whatever tag to be under release and dailies both?
15.57.56 #       <bluebrother> yes please.
15.58.45 #       <bluebrother> also, can you change dailies/date to dailies/timestamp (so it uses the same name)? Would simplify things a bit for me.
16.02.10 #       <speachy> is the abbreviated format okay?
16.03.20 #       <bluebrother> yes.
16.03.46 #       <speachy> done
16.03.52 #       <speachy> (new one updated)
16.04.45 Quit    t0mato (Ping timeout: 240 seconds)
16.05.17 #       <speachy> for the release voice, do you want it under the main [release] tag?
16.07.08 ***     Saving seen data "./dancer.seen"
16.07.43 #       <speachy> I think we may be better off putting voices in a separate hierarchy.  voices/3.15=.... voices/3.14=... voices/daily=....
16.09.21 Quit    emacsomancer (Read error: Connection reset by peer)
16.10.20 Join    emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
16.10.52 #       <bluebrother> hmm. We only support installing the latest release, so having them separate wouldn't provide anything extra.
16.11.53 #       <bluebrother> but then again, having them below [release] would kinda break things for retired targets. Unless we make sure we always have all announced voices for older releases as well.
16.11.54 Quit    Rower (Ping timeout: 258 seconds)
16.12.08 #       <speachy> well, "latest release" isn't the same for all targets
16.12.22 #       <bluebrother> that's what got me thinking :)
16.12.36 Join    t0mato [0] (t0mato@gateway/vpn/mullvad/t0mato)
16.12.50 #       <bluebrother> so a separate hierarchy would make sense.
16.13.11 #       <bluebrother> just thinking how to get that done best in Rockbox Utility.
16.13.52 #       <speachy> I mean, the voice list for all previous releases is just "english" but the next release will expand that considerably.
16.15.08 Quit    emacsomancer (Read error: Connection reset by peer)
16.15.44 Join    emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
16.17.23 #       <speachy> the defined-but-disabled daily voice list consists of: deustch,norsk,russian,srpski
16.20.21 #       <bluebrother> yeps. And if someone is really motivated we could always add voice files for older releases :)
16.24.56 Quit    t0mato (Ping timeout: 258 seconds)
16.27.04 #       <speachy> okay, here's what's in the new build-info:
16.27.13 #       <speachy> [voices]
16.27.14 #       <speachy> 3.15=english
16.27.16 #       <speachy> 3.13=english
16.27.18 #       <speachy> daily=english,english-us,francais,greek,italiano,polski,slovak
16.31.36 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
16.33.56 #       <bluebrother> nice. Now I have to fix all the stuff I broke while restructuring :) Might take a while.
16.34.02 #       <bluebrother> thanks.
16.39.41 Join    t0mato [0] (t0mato@gateway/vpn/mullvad/t0mato)
16.41.03 #       <fs-bluebot> Build Server message: New build round started. Revision fc4fff0, 293 builds, 8 clients.
16.47.12 Quit    lebellium (Quit: Leaving)
16.52.35 #       <fs-bluebot> Build Server message: Build round completed after 692 seconds.
16.52.38 #       <fs-bluebot> Build Server message: Revision fc4fff0 result: All green
16.52.39 #       <fs-bluebot> Build Server message: New build round started. Revision 60f581e, 293 builds, 8 clients.
17.03.10 Join    TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls)
17.11.49 #       <fs-bluebot> Build Server message: Build round completed after 1151 seconds.
17.11.58 #       <fs-bluebot> Build Server message: Revision 60f581e result: 12 errors 0 warnings
17.31.43 Quit    livvy (Ping timeout: 240 seconds)
17.32.30 Join    livvy [0] (~livvy@gateway/tor-sasl/livvy)
18.07.10 ***     Saving seen data "./dancer.seen"
18.17.07 #       <fs-bluebot> Build Server message: New build round started. Revision 610ad6f, 293 builds, 9 clients.
18.24.25 #       <speachy> whew, the only errors were due to a missing #include.
18.30.30 #       <fs-bluebot> Build Server message: Build round completed after 802 seconds.
18.30.36 #       <fs-bluebot> Build Server message: Revision 610ad6f result: 12 errors 2 warnings
18.34.14 Quit    efqw (Quit: Connection closed for inactivity)
18.40.43 #       <_bilgus> oh well it can onlt be all green for so long :p
18.45.13 #       <speachy> yuck, looks like rewriting the ibasso usb code is needed to fix this properly.  I think it predates the other hosted usb stuff.
18.46.34 #       <_bilgus> I have all the aux menus for bluetooth done I still need to write the dynamic menus kinda stuck on the best way forward
18.47.56 #       <_bilgus> I'm thinking I can use the multi-line select feature to display the name and mac but I need to figure how to make that co-exist with the single line stuff
18.48.55 #       <_bilgus> speaking of speach are you in a hurry for the rocker to be sent back/ on I think from here I can make due with the sim
18.49.04 #       <_bilgus> speachy *
18.49.07 #       <speachy> no particular hurry
18.50.08 #       <_bilgus> in that case I'll try to make a driver to go with it but that'll probably take me awhile
18.50.19 #       <_bilgus> not my forte
18.50.35 #       <speachy> the ibasso stuff is wayyyy too expensive on ebay
18.50.56 #       <_bilgus> probably to do with rb TBH
18.51.15 #       <_bilgus> maybe you should ask for donated players on the frontpage
18.52.08 #       <speachy> $115 is the cheapest dx50, dx90s are about $190.
18.52.25 #       <speachy> don't think it's RB; more likely "audiophile" nonsense
18.52.46 #       <speachy> (these were pretty high-end units in their day; modern iBassos are pretty expensive too)
18.52.59 #       <speachy> yay, dinner's ready
19.03.21 #       <fs-bluebot> Build Server message: New build round started. Revision 43f9074, 293 builds, 9 clients.
19.26.39 #       <fs-bluebot> Build Server message: Build round completed after 1396 seconds.
19.26.46 #       <fs-bluebot> Build Server message: Revision 43f9074 result: 8 errors 2 warnings
19.30.03 #       <_bilgus> oops sorry didn't mean to get in the middle of your thing
19.31.32 Part    amsomniac
19.32.54 #       <speachy> somehow ended up with fewer errors this time around
19.48.28 Quit    prof_wolfff (Ping timeout: 256 seconds)
19.58.49 Join    fs-bluebot_ [0] (~fs-bluebo@55d40b77.access.ecotel.net)
19.59.11 Quit    bluebrother (Disconnected by services)
19.59.16 Join    bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
20.01.26 Quit    fs-bluebot (Ping timeout: 265 seconds)
20.04.22 #       <fs-bluebot_> Build Server message: New build round started. Revision 03cd773, 293 builds, 9 clients.
20.04.25 #       <speachy> yuck, the dx50/90 port is definitely in need of some major TLC.
20.04.53 #       <speachy> I think this should get it building again but the usb interaction needs to be rewritten in the model of the other hosted targets.
20.07.13 ***     Saving seen data "./dancer.seen"
20.24.25 #       <fs-bluebot_> Build Server message: Build round completed after 1203 seconds.
20.24.26 #       <fs-bluebot_> Build Server message: Revision 03cd773 result: All green
20.25.56 #       <speachy> excellent.
20.29.54 #       <speachy> so.  wonder if it's worth using more rb funds to pick up a DX50.
20.30.54 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
20.41.27 Quit    MrZeus (Ping timeout: 260 seconds)
20.46.11 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
21.04.43 Quit    ac_laptop (Ping timeout: 260 seconds)
21.52.04 Join    captainkewl [0] (60ffd643@pool-96-255-214-67.washdc.fios.verizon.net)
22.07.16 ***     Saving seen data "./dancer.seen"
22.08.22 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
22.49.32 Quit    captainkewl (Remote host closed the connection)
23.00.37 Quit    ac_laptop (Ping timeout: 260 seconds)
23.41.43 #       <speachy> lovely, for some reason the server's http logs... didn't log anything for nearly a week
23.52.35 #       <_bilgus> tellin all of yall its sabotage!