--- Log for 12.11.120 Server: barjavel.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 13 hours ago 00.00.04 # wasn't that _bilgus's work? 00.00.19 # oh 00.00.22 # something else 00.00.56 # this_is_a_nick: ask speachy about it since they authored it 00.01.13 # from a quick look it doesn't seem so. 00.01.21 Quit TheSeven (Disconnected by services) 00.01.31 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 00.01.42 # <_bilgus> this_is_a_nick, actually would a hotkey work? 00.02.13 # _bilgus: the rocker has otkeys? 00.02.30 # <_bilgus> wps has a hotkey 00.02.49 # huh. it's cut off in the diff so I didn't notice. 00.03.21 # but yeah if you don't want to recompile setting the hotkey is your best bet 00.03.55 # <_bilgus> this_is_a_nick, Settings>General Settings>Hotkey 00.05.37 # I don't have the Hotkey option. Is it available for the agptek rocker? 00.06.05 # <_bilgus> should be let me check 00.06.18 *** Saving seen data "./dancer.seen" 00.06.27 # I have something called "Set Wps Context Plugin". is that it? 00.07.06 # _bilgus: the keymap doesn't have a hotkey listed for the WPS 00.07.31 # <_bilgus> sure enough it doesn't have a wps hotkey 00.08.08 # I was thinking to add the pitchscreen to the shortcuts, but I couldn't figure out the syntax for the pitchscreen item. 00.08.09 # <_bilgus> ok this_is_a_nick ya got me lets wait for speachy lol 00.11.36 # <_bilgus> this_is_a_nick how about selecT+right 00.11.57 # <_bilgus> we can make that a hotkey 00.12.41 # hm. 00.14.57 # v3.4 to v3.5 looks promising 00.15.01 # let's test it 00.16.55 # does the rocker register 2 keys at once? I don't see any mapping that uses 2 keys. 00.17.21 # <_bilgus> one way to find out right? 00.17.52 # _bilgus: confirmed. something between v3.4 and v3.5 broke it 00.18.12 # <_bilgus> nice 00.19.08 # and wouldn't you know it... this was the release where the h300 code was restructured 00.19.19 # from being the h300 target to being the iriverh300 target 00.19.36 # probably something broke in the rework 00.20.22 # now to attempt a bisect to find when this started 00.20.29 # see if it works if i build the commit before it 00.21.18 # incidently these players don't seem brickable as long as you still have the OF installed 00.21.38 # so probably best to test new bootloaders on this setup 00.22.44 # _bilgus: feels like i'm doing ye old binary search 00.22.58 # take the half point, rebuild, see what changes 00.23.04 # or something 00.23.18 # <_bilgus> binary tree 00.23.24 # <_bilgus> voodoo 00.29.19 # _bilgus: i know git supports checking out Nth commit before the given one 00.29.23 # what about after? 00.29.51 # e.g., git checkout TAG~10 00.29.56 # 10 commits before tag 00.30.13 # braewoods: every commit has a single parent but can have multiple children therefore it is impossible 00.30.21 # i see. 00.30.23 # ok. 00.34.58 # _bilgus: i'm also assuming i may need to fix it multiple times. it's been 10 years, it may be more than one bug at work. 00.36.38 # one thing at a time though 00.36.49 # ok. first bisect on tools/configure 00.36.53 # let's see where it takes me 00.37.37 # <_bilgus> hard to guess at this point 00.38.58 # interesting. this one also fails to boot. 00.39.12 # so let's see where that leaves us... 00.44.31 # ~300 commits after 3.4 00.46.31 # second bisect 00.46.35 # let's see where this takes me 00.46.48 # i did a bisect on bootloader/ firmware/ 00.49.54 # good thing i worked on iriver_flash. i couldn't see myself doing this without it. 00.51.30 # ok this bisect works 00.51.39 # time to mark the new range 00.58.41 Quit this_is_a_nick (Remote host closed the connection) 01.07.04 # <_bilgus> so rocker doesn't let you do select and another key but volup+voldn works 01.08.54 # well i've narrowed it down to a range of 31 commits 01.09.00 # time to do a new bisect on that region 01.18.54 # maybe found something 01.19.10 # some changes to the iriver H300 LCD code 01.19.43 # time to try the commit right before it 01.28.18 # <_bilgus> huh build hook fail? 01.28.43 # ok. commit before boots. 01.28.51 # time to try the commit that looks like the bad one 01.30.44 # found the commit 01.31.58 # _bilgus: see anything odd in e13c6001332882291363bdf2f1155875439fe187 ? 01.33.13 # <_bilgus> have a link to it can't seem to jump to it 01.34.21 # <_bilgus> nm I got it 01.34.44 # https://github.com/Rockbox/rockbox/commit/e13c6001332882291363bdf2f1155875439fe187 01.36.26 # <_bilgus> yeah so it was switched to dma for the lcd 01.36.58 # <_bilgus> maybe they are at different addresses or are they the same chip under the covers? 01.37.09 # * braewoods shrugs 01.37.36 # time to dig into it i guess 01.37.46 # the easiest is to revert it but 01.38.04 # perhaps better just to find out why it is broken 01.38.31 # <_bilgus> yes dont revert stuff that old 01.38.41 # <_bilgus> if def around maybe 01.40.30 Join advcomp2019_ [0] (~advcomp20@65-131-145-101.sxct.qwest.net) 01.40.30 Quit advcomp2019_ (Changing host) 01.40.30 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 01.43.59 Quit advcomp2019 (Ping timeout: 260 seconds) 01.47.08 # <_bilgus> mcf5249 do they both use this chip? 01.47.50 # that's the cpu 01.47.52 # and yes 01.54.15 # strangely this code seems to pose no problem to HEAD normal builds 01.56.04 # _bilgus: what's the icode section? I saw the commit removed ICODE_ATTR 01.56.49 # <_bilgus> too low level for me 01.58.04 # welp 01.58.18 # guess i'm going to be figuring this puppy out 01.58.27 # what exactly broke if nothing else 01.58.51 # honestly i'll probably just disable it in the BL since it doesn't seem to be an issue for the main firmware 01.59.15 # <_bilgus> thats a valid option 01.59.31 # indeed and i don't really know DMA either 01.59.36 # and the BL doesn't need to be super optimized 01.59.43 # it just has a job to do 01.59.47 # <_bilgus> try to do the same for the 120 too so they match ifpossible 02.00.10 # funny story 02.00.15 # <_bilgus> dma just does the increment and copy for you 02.00.19 # the H100 doesn't use DMA on the lcd 02.00.34 # <_bilgus> you set up a len and start address it handles the rest and signals when done 02.00.43 # <_bilgus> hmm. 02.00.54 # <_bilgus> isn't that handy 02.01.10 # that's probably why it still works 02.01.21 # maybe we should just remove DMA from the h300 02.04.29 # seems the only serious user of DMA in the iriver coldfire ports is the h300 lcd 02.05.02 # so... it appears the bootloaders broke due to someone's overzealous optimizations 02.05.25 # DMA seems to be problematic on here 02.05.30 # so maybe it's best to disable it entirely 02.05.38 # at least for the LCD 02.05.59 # speachy: thoughts? 02.06.12 # anyway i'll look into it more tomorrow 02.06.17 # at least i narrowed it down 02.06.22 *** Saving seen data "./dancer.seen" 02.12.48 # speachy: i see 2 solutions. disable DMA for all h300 LCD builds or only disable it for the bootloader. 02.13.01 # though i'm not sure what this optimization even gets us 02.13.14 # LCDs probably don't take that much cpu time 02.13.55 # <_bilgus> you would be amazed 02.14.09 # <_bilgus> if it works in rb i'd leave it 02.14.21 # <_bilgus> just remove from BL 02.20.04 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:9df0:ddb9:3c1c:cc8f) 02.20.58 Quit _bilgus (Read error: Connection reset by peer) 02.21.21 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 02.28.39 Quit _bilgus_ (Remote host closed the connection) 02.29.56 Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) 02.39.43 Quit _bilgus (Remote host closed the connection) 02.41.26 Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) 03.31.48 # ok test patch appears to work 03.31.52 # i'll refine it more tomorrow 03.32.09 # then i'll need to update it for head 03.32.13 # and test it as i go forward 03.32.23 # slow work but i don't want to take any chances 03.33.03 Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) 03.33.13 # i basically need to disable the DMA code on bootloaders 03.33.32 Quit lonoxmont (Ping timeout: 272 seconds) 03.33.51 # <_bilgus> great that you found it though 03.34.31 # _bilgus: i'm probably going to create a DMA macro for this file that depends on BOOTLOADER value. otherwise it's rather unclear why it is there. 03.34.44 # and there's a ton of code to put in conditionals 03.35.05 # e.g., LCD_USE_DMA or something 03.35.08 # <_bilgus> or just give it its own sourcefile in the bootloader 03.35.21 # eh? 03.35.37 # <_bilgus> it should be as simple as including a .c file by the same name as the .h and it'll pull it in 03.35.52 # <_bilgus> placed in the bootloaders/ path 03.36.18 # isn't that a problem for long term maintenance? 03.36.36 # you seem to be advocating for copy pasta? 03.36.57 # <_bilgus> versus if defs or a broken implementation? 03.37.42 Quit prof_wolfff (Ping timeout: 258 seconds) 03.37.55 # how is it better than ifdefs? 03.38.14 # <_bilgus> its at least solidly separate 03.38.51 # true 03.38.57 # just code duplication and all 03.39.03 # <_bilgus> if you have tons of ifdefs then split it in two within the same file same thing but in the same file I guess 03.39.17 Join petur [0] (~petur@199.59.5.11) 03.39.17 Quit petur (Changing host) 03.39.17 Join petur [0] (~petur@rockbox/developer/petur) 03.39.19 # <_bilgus> ifdefs make the code so damn hard to follow 03.39.34 # yet often necessary 03.39.43 Join lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com) 03.40.39 # i'll see what i can cook up 03.40.53 # it seems to be fine on the regular rockbox so 03.40.58 # i guess it should keep the DMA code for that. 03.41.04 # <_bilgus> see I can see dma really coming in handy in transferring files 03.41.21 # <_bilgus> figure the cpu is free to do other things while waiting 03.41.45 # coldfire already uses 2 DMA channels 03.41.46 # <_bilgus> but really we disable this kind of stuff in the bootloaders Ive touched 03.42.08 # i suspect the issue is it tries to setup the DMA stuff too early and it fucks stuff up 03.42.14 # <_bilgus> granted they are extremely space constrained but still 03.42.49 # bootloaders are running very early after all 03.43.27 # it messes with the interrupt vectors to install DMA3 03.43.35 # so maybe that's no buena in the bootloader 03.43.45 # <_bilgus> quite possible 03.43.55 # <_bilgus> or something not setup yet 03.44.47 # either way reliability matters more than speed in the bootloader 03.45.30 # <_bilgus> fosho 03.45.50 # bootloaders in my experience are the most fickle things i've ever worked with 03.46.49 # there was even a grub2 bug that made it hang on fairly recent intel atom boards 03.47.03 # they did some weird stuff in that board 03.47.10 # and they had to workaround the quirks or so to avoid the hang 03.47.18 # apollo lake is still a mess 03.48.04 # <_bilgus> well they go through that so you don't have to 03.48.28 # on the bright side grub2 is a late stage bootloader so it can be fixed 03.48.34 # no brick risk 03.48.52 # <_bilgus> lower you go the more it looks like voodoo.. 03.49.02 # though it's kinda funny... 03.49.36 # most linux bootloaders now have their own kernel so to speak 03.49.40 # <_bilgus> the bootloader hasn't been upgraded since 2006? 03.49.47 # which one? 03.49.49 # h300? 03.49.51 # <_bilgus> h33 03.49.53 # correct 03.50.00 # last reports of it working were from 2008 or 2009 03.50.07 # so i had to narrow it down 03.50.13 # it took like 20 or so builds 03.50.47 # but once i am able to build a working bootloader from HEAD 03.50.56 # i will be pushing the fixes 03.51.14 # then i can commence with my actual development 03.51.20 # but this was a showstopper i had to address first 03.51.29 # <_bilgus> welcome to the rabbit holes 03.52.14 # main problem with my quest to update these suckers is... 03.52.34 # the H100 bootloader is untestable due to how rare that player is. the H120 and H140 are far more common. 03.52.44 # but it is heavily related to the H120 03.52.46 # so 03.52.54 # if the H120 works there's a pretty good chance the H100 does too 03.54.42 # i can see why 04.06.25 *** Saving seen data "./dancer.seen" 04.36.23 Quit kakaka (Ping timeout: 240 seconds) 04.50.01 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 05.08.11 Quit Skyrider (Quit: ZNC - 1.6.0 - http://znc.in) 05.17.07 # _bilgus: joy. i'm going to have to do more bisecting. 05.17.18 # i've only scraped the tip of the iceberg 05.30.10 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 05.40.14 # ok. testing again with my last patch for the first problem. 05.40.25 # then i get to jump ahead and see what happens 05.59.56 # ok. i traced it up to 3.7-final... all working... 06.00.08 # 3.8-final changes the toolchain 06.00.16 # * braewoods ponders. 06.02.11 # guess i'll upgrade to a newer VM base 06.06.26 *** Saving seen data "./dancer.seen" 06.19.28 # heh. 06.19.38 # gentoo meme. so you like scrolling walls of text. 06.25.27 Quit Stanley00 () 06.31.32 # v3.8-final works 06.35.23 # v3.9-final works 06.37.03 # v3.10-final works... yaw 06.45.54 # v3.11-final works somehow or other 06.48.04 # v3.12-final works... 07.01.32 # v3.13-final works 07.02.10 # now the biggest jump so far 07.02.12 # v3.14-final 07.03.50 # works. surprisingly. 07.08.15 # huh. v3.15-final works too with the patch applied 07.11.22 # so what else is responsible? 07.11.24 # hm 07.20.22 # going to test it on code before the toolchain upgrade 07.23.38 # check. 07.23.48 # well that's as far as i can go with this VM 07.25.41 Quit S|h|a|w|n (Read error: Connection reset by peer) 07.26.18 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 07.27.23 Join t0mato [0] (t0mato@gateway/vpn/mullvad/t0mato) 07.31.50 # going to see if i can reproduce it in a container 07.45.50 # braewoods: good worl hunting that down, but I agree with bilgus that reverting lcd dma globally is not the way to proceed. 07.46.37 # speachy: indeed. i've trace it as far back as working to e91f89a410dc4639dbe78f392c11b2a44ff9036a with my current draft patch. 07.47.10 # now i just need to find out what commit broke it since then 07.47.13 # my guess is that something the lcd dma code depends on isn't initialized yet -- perhaps something as basic as global interrupts. 07.47.39 # well if you have a better idea of how to fix it... my patch just disables it for the bootloader. 07.47.45 # but leaves it for the rest 07.51.28 # the most likely culprit is the toolchain update 07.51.50 # oh, just make sue you're re-running configure each time you jump forward. 07.52.05 # i am 07.52.08 # i clean up each time 07.52.39 # the other possibility is the LCD refactor for _bilgus is breaking it 07.52.46 # we'll see 07.53.05 # i'm trying a point before i started modifying H300 code in master 07.55.53 # ok need to build new toolchain 07.58.29 # while i'm at it i'll see if there's any traps in my bootloader 08.02.26 # g#2965 is the next bit of PCM API exorcism 08.05.27 # speachy: good news. the toolchain is not at fault. 08.06.01 # next up... i'll checkout the commit right before the big LCD overhaul 08.06.16 # did you every try using git-bisect? 08.06.27 *** Saving seen data "./dancer.seen" 08.06.49 # speachy: yes. 08.06.54 # it's interesting. 08.07.29 # just seems difficult to use if you don't know what files to monitor... 08.07.59 # if anything, it's simpler. 08.08.14 # remember git operates on the entire tree. 08.08.38 # give it a start point, and and end point, it'll do the binary search for you, all you have to do is tell it if the entire tree is "Good" or "Bad" 08.08.59 # i see 08.09.15 # narrowing it down to a given file or subset might reduce the search speace but it still operates the same way 08.11.01 # huh, bluebot's offline. 08.13.31 # on the bright side this did give me a lot of good testing for the BL flashing for the h300 08.13.41 # so it was valuable in a sense 08.16.49 Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) 08.22.35 Join fs-bluebot [0] (~fs-bluebo@55d44e28.access.ecotel.net) 08.30.17 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 08.32.47 # speachy: found the breakage point. it's after the commit with the LCD overhaul. 08.33.04 # i'll do some digging to find out more about it 08.41.25 # last known working commit for the h300 bootloader with my patch... 08.41.27 # 12f3ed1699d6bef25bed90ba95cbcc1a6bb4934a 08.46.29 # joy. 08.47.12 # _bilgus: perhaps you have some ideas? it breaks somewhere between 12f3ed1699d6bef25bed90ba95cbcc1a6bb4934a and ada919fc1122c314b239212a40d15c5ab131becd 08.55.49 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.07.00 # decided to stage the fix for the first part 09.07.15 # g#2968 09.07.16 # Gerrit review #2968 at http://gerrit.rockbox.org/r/2968 : h300: fix one long-standing bootloader bug by James Buren 09.27.08 # best theory i have for now is the changes to FBADDR 09.27.22 # it involves 2 pointer dereferences whereas the old one didn't use any 09.38.04 # hm. 09.38.08 # looking at H120... 09.38.24 # its lcd update functions are marked with this ICODE_ATTR macro 09.38.37 # that old commit i partially undid? it removed that. 09.38.48 # i wonder if that is playing a part. 09.39.05 # but i can find no explaination for what the icode section does 09.39.09 # or what it is for 09.39.40 # speachy: do you have any idea what the ICODE_ATTR is used for? 09.39.44 # why it is important or isn't? 09.42.39 # <_bilgus> I'd start looking very closely what the screen size macro are doing 09.43.30 # _bilgus: which one? 09.44.11 # <_bilgus> the width and height wait it works as a firmware image but not in the bootloader? 09.44.29 # _bilgus: correct 09.44.50 # it has the same basic behavior as the DMA code i patched out for it 09.44.56 # a frozen white screen 09.45.06 # <_bilgus> lets have a look maybe its out of bounds and somehow doesn't carch it in the bootloader 09.45.40 # i'll try a few things myself 09.45.46 # <_bilgus> yeah thats odd maybe we made a faulty assumption, me and jens with the dma code 09.45.57 # i have one idea already 09.46.13 # <_bilgus> catch it, sorry sun is in my eyes 09.46.16 # _bilgus: but do you know what the ICODE_ATTR does? 09.46.25 # the icode section is not well defined 09.46.33 # i can find nothing about it anywhere 09.47.17 # <_bilgus> no thats lower level than I mess with frequently its either going to be stuff that needs fast ram or perhaps within a memory range' 09.58.58 # <_bilgus> braewoods, FIRST THING LINE 209 09.59.02 # <_bilgus> oops 09.59.06 # ? 09.59.23 # <_bilgus> iriver h300.c 09.59.27 # <_bilgus> font_init(); 09.59.39 # <_bilgus> the font isn't set before init 10.00.07 # <_bilgus> should be FOR_NB_SCREENS(i) 10.00.07 # <_bilgus> global_status.font_id[i] = FONT_SYSFIXED; 10.00.07 # <_bilgus> font_init(); 10.00.24 # <_bilgus> then remove the lcd set font later on 10.02.09 # _bilgus: so what's the proposed solution? 10.02.18 # <_bilgus> ^ 10.02.31 # i'm confuse. 10.02.34 # confused 10.03.03 # FOR_NB_SCREENS(i) ? 10.03.15 # <_bilgus> sorry currently its font init then sets the font for the lcd should be the screens macro set the fonts then init 10.03.48 # <_bilgus> its a macro expands to for screen=0; screen < screens< screen++ 10.04.09 # _bilgus: one problem. the h120 bootloader does the same thing but it still works. 10.04.39 # <_bilgus> yeah but probably getting lucky its initd to 0 in icode attrib 10.05.01 # ok. i'll try it your way. 10.05.08 # where do we put this... 10.05.44 # <_bilgus> here i'll pastebin it for you 10.06.22 # the risk is low in any case 10.06.28 *** No seen item changed, no save performed. 10.06.40 # but if this works then we should patch the other BL too 10.06.56 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:519d:4ff6:24c7:b643) 10.07.34 # <_bilgus> https://pastebin.com/ChyYuSCH 10.07.40 # <_bilgus> just copy pasta 10.11.38 Quit bonfire (Remote host closed the connection) 10.11.43 # erm 10.11.43 # <_bilgus> next i'd try removing the stuff for the remote lcd just to narrow it down 10.11.55 # is this even intended for bootloader use? 10.11.56 Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) 10.12.04 # it's defined in an apps header 10.12.17 # <_bilgus> yes it should work but let me look a little closer 10.14.27 # <_bilgus> no you are right they all do it.. 10.15.04 # <_bilgus> I figured smoking gun removing from initialized ram 10.15.30 # <_bilgus> thats probably what it'll end up being my guess 10.16.25 # <_bilgus> huh font init also brings in buflib 10.17.42 Quit michaelni (Remote host closed the connection) 10.19.18 # <_bilgus> so mainlcd is a colr 16 bit display that is pretty common code there but the remote lcd OTOH not so well tested 10.21.33 # i'll try taking it out. 10.21.47 # though 10.22.08 # i still don't know how it broke. 10.23.34 # _bilgus: that code you showed isn't going to help me... since it's not even part of the bootloader. 10.23.42 # the reference objects and such 10.24.34 # <_bilgus> https://pastebin.com/KKm8Akvv 10.24.46 # <_bilgus> there is with the remote display removed 10.26.27 # <_bilgus> I'll start looking at the font init stuff it pulls in bufferlib so pretty good candidate 10.27.16 # well i think i'd need your help for this regardless since the LCD rework was yours 10.28.56 # <_bilgus> yeah but I think its just a canary 10.29.10 # <_bilgus> once that works bet the dma code can go back in 10.29.33 # maybe it can, maybe it can't. that wasn't working prior to your changes. 10.30.05 # <_bilgus> true but this works in the fw but not in bootloader is an odd thing 10.31.08 # _bilgus: no change with that on head 10.31.38 # but incidently both breakages involve changes to the LCD code at some level 10.32.27 # ok. restored again from a bad bootloader. 10.34.44 # _bilgus: you got an H300 at all? 10.35.34 # <_bilgus> doh printf redirect still calls the remote lcd stuff can you try that again but remove HAVE_REMOTE_LCD & HAVE_REMOTE_LCD_TICKING from iriver300.h? 10.35.56 # <_bilgus> no itd be much easier if I did 10.36.34 # _bilgus: you live in US? 10.37.05 # <_bilgus> yeah midwest 10.37.10 # hm. 10.37.23 # i have a second H320 since I didn't know if i'd need a spare for my work. 10.37.35 # if it would help i can send it to you. 10.38.42 # when i got it the battery was dead so i had to replace it. 10.38.46 # but it works now 10.39.06 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 10.39.44 # <_bilgus> last resort perhaps I still have a rocker that I need to send back 10.40.01 # ah. honestly i'd consider this a gift if you want to keep it. 10.40.16 # <_bilgus> although I'm pretty much done with needing physical hardware on that one now 10.40.47 # i can include an H100 remote too in pretty good condition 10.40.49 # <_bilgus> nah I have enough devices scattered as is 10.40.52 # ok. 10.41.04 # in tht case 10.41.08 # i'll try again.brb 10.42.16 # _bilgus: another round of PCM exorcism: g#2965 10.42.18 # Gerrit review #2965 at http://gerrit.rockbox.org/r/2965 : pcm: Further cleanup of unused bits of the PCM ACPI: by Solomon Peachy 10.43.48 Quit massiveH (Quit: Leaving) 10.46.34 # _bilgus: ok. i'm trying again. 10.46.37 # moment 10.47.08 # i'm testing against HEAD since it's not that far from the LCD changes 10.47.59 # <_bilgus> speachy nice, I assume there are users for the pcm peak stuff? 10.48.05 # nope. 10.48.31 # _bilgus: still white screen 10.48.40 # they've long since been migrated to the mixer_channel_peak stuff instead 10.49.28 # <_bilgus> even better :) 10.49.53 # i wonder if this is partly because the H300 is color while H12 is grayscale 10.49.57 Quit emacsomancer (Quit: WeeChat 2.9) 10.49.59 # H120 10.50.00 # and several of the PCM drivers never actually implemented the pcm_peak stuff, heh. 10.50.57 # <_bilgus> braewoods, what I will do is go through the bootloader and make it work without any lcd and then we can try adding stuff back in till it breaks again 10.51.02 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) 10.51.13 # _bilgus: ok. keep me apprised. 10.51.40 # i did find some stuff but maybe that workaround isn't necessary 10.52.05 # <_bilgus> will you be available this eve I have to head back to work but I'll be free in like 10 hrs from now 10.52.15 # _bilgus: probably 10.53.00 # <_bilgus> I'll try to get something easy with some ifdefs once we reach that point it'll hopefully just jump out 10.53.20 # we shouldn't need to modify crt0.S 10.53.26 # i'm pretty sure it is not at fault at all 10.53.56 # plus if it was malfunctioning more coldfire ports would have issue 10.53.58 # issues 10.54.31 # <_bilgus> it might still be figure if it was getting set to zero before and now its not perhaps someone forgot to init something important 10.54.52 # the code hasn't been modified in ages 10.55.02 # so... 10.55.09 # this code specifically hasn't, but it depends on other code which has. 10.55.24 # either way 10.55.27 # <_bilgus> yeah since it last worked in 2006 and with a similar issue to boot 10.55.52 # i was able to make it work in a 2009 source code 10.56.02 # and then i found a commit that caused that white screen regression 10.56.15 # and tracing forward, that patch worked until you changed the LCD code 10.56.20 # in that recent commit 10.56.32 # no idea how it broke this time 10.57.17 # i was inclined just to play it safe since bootloaders are a pita to deug 10.57.19 # debug 10.57.40 # anyway my other plans are shelved until we find a solution for these issues 10.57.52 # <_bilgus> It doesn't seem like it currently but its actually the desired result 10.57.56 # either way the bootloader on H300 doesn't seem to like LCDs for some reason 10.58.30 # <_bilgus> we want these bugs to pop out early instead of silent corruption 10.58.47 # _bilgus: my offer stands if you find this too difficult to do remotely. i can ship you my other unit. 10.59.10 # Build Server message: New build round started. Revision 388adff, 293 builds, 8 clients. 10.59.29 # hmm, is the vbrfix plugin still relevant now that archos is gone? 11.00.20 # <_bilgus> might have to its so much easier to have it for hardware issues but we'll see what falls out first 11.01.01 # <_bilgus> no clue what it does speachy 11.01.30 # "This plugin adds/fixes the Xing VBR header in an MP3 file." 11.02.45 # "The Xing header contains information about the vbr stream, to calculate average bit rate and to more accurately fw/rew throught the stream" 11.08.39 # at least i can eliminate the toolchain 11.08.57 # the new coldfire one works fine for commits prior to the LCD overhaul 11.09.16 # last known one to work with my patch is 11.09.31 # the one immediately before the first big LCD patch 11.09.35 # the framebuffer commit 11.10.06 # _bilgus: how you want to do this? i can take bootloaders you've built and flash them. 11.10.15 # <_bilgus> braewoods, is that a clean vm? 11.10.17 # that way we can eliminate problems due to source differences 11.10.44 # _bilgus: define clean? i deleted the original toolchain prior to upgrading it. 11.10.56 # and i'm not using VMs for builds 11.10.58 # containers 11.11.01 # <_bilgus> ie no user info in it 11.11.14 # ah. no. just the unprivileged builder. 11.11.29 # <_bilgus> oh nm then I was gonna say upload it to a file host and I'd grab it but nm 11.12.05 # <_bilgus> I try to keep old stuff around for these things 11.12.24 # do you want me to give you a container that's setup for RB coldfire? 11.12.32 # access to one 11.13.00 # <_bilgus> nah I have my toolchain set up here and this nifty 2x faster laptop :p 11.13.13 # ok 11.13.29 # i've been building remotely on my LAN server and just copying the blobs over the network for testing 11.13.29 # <_bilgus> and my new rig should be here sometime soon so just better and better :D 11.13.57 # for the record, LXC containers work great for RB building 11.14.08 # <_bilgus> haha I almost did that with my rig at home but then the realization of slow internet speeds here tempered that expectation 11.14.24 # actually 11.14.43 # it's LAN only for me so i got gigabit speed. 11.15.13 # but yea, that's why i rent a dedicated server 11.15.25 # their bandwidth is ridiculiously cheap compared to what we get 11.16.15 # _bilgus: one of my thoughts was whether the FBADDR macro was derferencing a null ptr 11.16.21 # since i didn't know how it got initialized 11.16.32 # the original code was an address with arithmetic 11.16.36 # no dereferences 11.16.55 # but with no debugger 11.17.01 # all i got is wild guesses lol 11.17.10 # all i know is the LCD seems to be having trouble 11.17.25 # all the issues with the h300 BL point to the LCD 11.18.05 # <_bilgus> I'm sure you are right but why not elsewhere thats odd stuff 11.19.07 # <_bilgus> especially since it works in fw makes me think its a failure to init 11.19.54 # eg the dma engine itself 11.20.01 # those usually require independent init/setup 11.20.41 # <_bilgus> oh braewoods were you testing with the dma stuff still removed? 11.20.59 # _bilgus: yes. 11.21.00 # yes he is 11.21.07 # <_bilgus> oh good lol 11.21.37 # <_bilgus> so i'll build it off that commmit you have up 11.22.01 # it was modified a bit to reflect changes to the LCD code for H300 11.22.16 # though i don't know what broke it specifically 11.22.24 # Build Server message: Build round completed after 1394 seconds. 11.22.36 # Build Server message: Revision 388adff result: All green 11.23.09 # it can easily be flipped by changing the ifdefs 11.23.11 # if need be 11.23.28 # Build Server message: New build round started. Revision b912ad5, 293 builds, 8 clients. 11.23.36 # for now i consider it a WIP because there's other issues it needs to be reconciled with 11.24.38 # _bilgus: though this is a lot less painful thanks to the iriver_flash changes i made 11.24.49 # iriver_flash is a lot faster than the OF is at flashing 11.34.47 # <_bilgus> braewoods, do I need to do anything special making the bootloader or just the bootloader.iriver file? 11.35.12 # i've been using the generated bootloader.iriver 11.35.35 # i added that support in a previous commit 11.35.46 # but you'll have to add it manually if working with something older 11.35.52 # i mean 11.35.57 # bootoutput to configure 11.37.42 # <_bilgus> https://www.mediafire.com/file/y2pzk30qfseuj3j/bootloader.iriver/file 11.38.01 # <_bilgus> its off your g#2968 11.38.04 # Gerrit review #2968 at http://gerrit.rockbox.org/r/2968 : h300: fix one long-standing bootloader bug by James Buren 11.38.11 # with what chnges? 11.38.19 # <_bilgus> so in this ver all lcd stuff is disabled 11.38.27 # ok. 11.38.53 # let me rebuild my rockbox 11.39.19 # <_bilgus> button prompts are intact so do try select or whatever keys normally if its not doing anything 11.39.55 # ok 11.40.55 # gimme a few minutes 11.41.04 # i have to rebuild RB for each BL build 11.41.08 # due to the lookup table 11.42.09 # <_bilgus> g#2969 11.42.11 # Gerrit review #2969 at http://gerrit.rockbox.org/r/2969 : h300 Boiotloader lcd WIP by William Wilgus 11.42.52 # <_bilgus> what lookup table seems bad to be tied in that manner 11.44.01 # _bilgus: tried it. white screen again. 11.44.13 # i used the rescue feature. 11.44.23 # <_bilgus> sur ethe backlight is on but it should boot 11.44.31 # Build Server message: Build round completed after 1264 seconds. 11.44.33 # Build Server message: Revision b912ad5 result: All green 11.44.43 # _bilgus: no progress. but if you insist I can wait longer. 11.44.49 # i'll reflash it 11.45.15 # _bilgus: oh, and, it's the table used by detect_valid_bootloader 11.45.27 # it's a safety feature but just gets in the way during development 11.45.32 # <_bilgus> got ya 11.47.36 # _bilgus: tried again. it's just hung. nothing happens like it should. 11.47.48 # it should boot to RB but i don't even hear the hard drive spinning 11.50.20 # <_bilgus> that worries me let me double check that I got all the lcd things 11.51.25 # on the bright side i don't think bricking is a serious worry due to the cookie checks 11.51.45 # i can hit reset and if i power it back on quickly enough 11.51.51 # it trips the cookie and boots the OF 11.51.55 # <_bilgus> thank goodness well I see one last spot the logf 11.52.40 # intended or not it wouldn't be feasible to explore this issue without it 11.52.41 # <_bilgus> oh nm its ifdefd out 11.53.21 # it's just weird how the BL behaves normally when my patch is applied but doesn't otherwise 11.53.44 Quit petur (Quit: Connection reset by beer) 11.53.50 # _bilgus: would it help if we started from the last known good commit? 11.54.24 # <_bilgus> not yet it really worries me that pulling out the lcd code didn't fix it 11.54.43 # indeed 11.55.08 # <_bilgus> i'll try disabling everything not needed to boot 11.55.21 # what about disabling LCD_REMOTE entirely for the bootloader? 11.55.28 # tried it 11.55.38 # (eg maybe that relies on i2c or something else not initialized yet) 11.55.39 # ah 11.55.41 # i commented it out and the build failed 11.55.46 # when i was doing it 11.56.09 # still strange that one optimization commit broke stuff 11.56.15 # why it did is beyond me 11.56.23 # all it did was add some mutex stuff and the like 11.56.44 # oh! one thing to consider -- grep the bootloader elf dump for traps 11.56.52 # i did already 11.56.56 # ok 11.57.22 # so -fno-delete-null-pointer-checks is enabled? 11.57.29 # (could easily lead to other bugs) 11.57.32 # you enabled it globally, remember? 11.57.46 # I don't recall when it was added vs the commits you're examining 11.57.49 # although it isn't enabled in the last good commit 11.58.03 # either way no traps 11.58.16 # plus a lot of the BL's critical sections are in ASM 12.01.09 # oui. working with the ROM chips is simple compared to this. 12.02.48 # <_bilgus> https://www.mediafire.com/file/y2pzk30qfseuj3j/bootloader.iriver/file 12.03.03 # so what's different now? 12.03.17 # <_bilgus> new one I'm updating the gerrit commit as well 12.03.26 # <_bilgus> this disable the backlight completely 12.03.44 # <_bilgus> in addition to the lcd 12.04.43 # ok. moment. 12.06.31 *** Saving seen data "./dancer.seen" 12.06.51 # that works 12.06.55 # though it's pitch black 12.07.16 # <_bilgus> oh? 12.07.21 # yea. 12.07.25 # <_bilgus> that is odd 12.07.26 # the screen is 100% dark 12.07.32 # until RB finishes loading 12.07.48 # <_bilgus> it looks to me like the assumption is that the device turns on the screen at boot 12.08.17 # <_bilgus> now why does that give issues with the lcd code .... 12.08.30 # well it may not matter but i did notice one difference from the 2006 bootloader and the functional ones i built 12.08.41 # the screen remains white in the V5 bootloader 12.08.45 # <_bilgus> ok so we will reenable the lcd coide but leave the backlight off 12.08.45 # the background 12.09.11 # <_bilgus> still wont see anything but if it works... 12.09.21 # but in the newer ones it 12.09.35 # is black 12.09.39 # dark background 12.09.44 # like black on white in the old 12.09.48 # and white on black in then ew 12.09.52 # kinda weird 12.09.56 #