| 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:00 |
| 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:00 |
| 03:06:26 | | Quit ac_laptop (Ping timeout: 256 seconds) |
| 04:00 |
| 04:06:54 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 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:00 |
| 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 |
| 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:00 |
| 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:00 |
| 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 |
| 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:00 |
| 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:00 |
| 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 |
| 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 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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 |
| 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! |
icon identifies that the person is a core developer (has commit access).