--- Log for 26.10.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 20 hours and 51 minutes ago 00.00.05 # it does it every time when i try to let iriver_flash do its thing with the bootloader 00.00.08 # but 00.00.12 # nothing happens to the flash 00.00.16 # so 00.00.27 # at least it didn't brick but i'm puzzled why it's not working 00.00.45 # <_bilgus> -T$(PLUGINLINK_LDS) -Wl,--gc-sections -Wl,-Map,$*.map 00.01.00 # where would I put that? 00.01.36 # <_bilgus> in the makefile of whatever you are building 00.01.45 # manually? 00.01.56 # <_bilgus> either add it to the flags or manually 00.02.26 # <_bilgus> don't have it in front of me to tell you exactly where but whereever it invokes gcc with flags 00.04.02 # <_bilgus> in a makfile you can add to a set of flags liek this FLAGS+= $(FLAGS) -Wl,-Map,$*.map 00.05.38 # is rockbox.map the file? 00.06.14 # <_bilgus> yep 00.06.24 # 0x0000000032f80000 _pluginbuf = . 00.06.29 # this is the region it is in... 00.06.38 # now what's at ee 00.07.03 # <_bilgus> hazard a guess nothing 00.07.20 # <_bilgus> I'm sorry is this fw or bootloader? 00.07.35 # _bilgus: firmware since iriver_flash is a plugin 00.07.42 # <_bilgus> ah 00.08.43 # <_bilgus> you should have a map file in the build dir called iriverflash.map 00.09.14 # <_bilgus> whereever you built it look in the same directory the zip is in 00.09.24 # 0x0000000032f800ee 00.09.28 # found it 00.09.34 # cfi_get_flash_info 00.09.37 # strange. 00.09.55 # <_bilgus> it clearly read an invalid address 00.10.09 # i'll see what happens 00.10.27 # <_bilgus> stick in some bounding 00.10.47 # bounding? 00.10.52 # right. 00.11.00 # hm. 00.11.03 # <_bilgus> like if addr x > 0xFFFFFF panic 00.11.48 # <_bilgus> maybe not so concrete more like a splash and gracefully try something else 00.12.22 # _bilgus: could it be in the subroutine it calls? 00.12.30 # <_bilgus> I got mad about having to mess with OSD so much and you know what it was my own dumb fault 00.12.34 # cfi_get_flash_info is only ever called with a pointer to a stack allocation 00.12.56 # so hm 00.13.17 # <_bilgus> Idk where you'd get info on what err 7 is 00.13.24 # indeed 00.13.56 # <_bilgus> pointer to whos stack alloc? 00.14.16 # <_bilgus> your control? 00.14.34 # i don't know honestly. 00.14.40 # <_bilgus> also toochain updates?? 00.14.42 # just going by what i'm seeing here 00.15.43 # let me dig around some more 00.16.49 # <_bilgus> cfi_read_id is surely possible 00.17.09 # <_bilgus> here is what I would do remember that thing about concat on the flags above 00.17.31 # <_bilgus> add this to the makefile for iriver flash or even the main plugins make 00.17.56 # i'm getting tired. i'll look at this later. 00.18.03 # <_bilgus> PLUGINFLAGS += -g -Wa,-adhln 00.18.24 # <_bilgus> then you'll get an asm file and you can look and see what is exactly at that address 00.19.29 # <_bilgus> when you do make on the command line do make > ./directory/irivflash.asm 00.19.32 # weird part is 00.19.53 # it makes it well past that function. if i add a return before the first cfi_erase_sector 00.20.01 # so... 00.20.15 # why am i being signaled by that function's address? 00.20.26 # * braewoods boggles. 00.20.34 # <_bilgus> it could always be a fluke but probably not 00.20.38 Quit [7] (Ping timeout: 260 seconds) 00.20.43 # it's reproduceable 00.20.45 # something is up 00.20.55 # anyway 00.21.02 # i'll give another try later 00.21.03 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 00.21.04 # i got an idea or 2 00.21.22 # my idea is simple though 00.21.38 # i'll see if it works with the junker H120 I ordered 00.21.40 # when it arrives 00.21.49 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) 00.21.51 # if it does there's something weird going on 00.21.57 # but if the toolchain works with H120... 00.23.15 Join Moarc [0] (~chujko@a105.net128.okay.pl) 00.24.27 # _bilgus: could Trap7 be delayed in triggering? 00.24.34 # is that why it gets as far as it does? 00.33.24 # hm. 00.33.33 # i found a manual on the coldfire cpu 00.33.52 # 27 is the index of the interrupt 00.36.16 # 0x28 or so? 00.36.20 # right 00.36.25 # 0x27 in base zero 00.37.16 # really generic error 00.37.22 # appears to be 00.37.29 # oh 00.37.32 # Trap #0–15 instructions 00.40.20 # real generic sounding 00.40.25 # no clue what would trigger this 00.41.22 Quit prof_wolfff (Ping timeout: 260 seconds) 00.42.48 # <_bilgus> generally exceptions don't act like that in my experience 00.43.05 # <_bilgus> do be aware it could be flash issues too 00.43.20 # indeed. not sure. 00.43.32 # it starts before a successful erase 00.43.39 # or else i'd have bricked it 00.50.06 # but i'm suspecting some issue with the code 00.50.16 # i'll review the flash interactions 00.59.18 # i wonder 00.59.36 # the actual sample code from the vendor for these flash chips does a length routine to return to read mode 00.59.47 # maybe that's the problem 00.59.59 # the iriver_flash doesn't do it the same way 01.00.31 # maybe that worked by coincidence for the original H120 01.00.33 # or so 01.00.35 # but not here 01.00.40 # hm 01.00.47 # well it's at least worth looking into 01.01.00 # i already found some issues with the implementation just by cursory inspection 01.03.58 # <_bilgus> no one has touched it for so long its probably been forgotten 01.04.50 # _bilgus: well i'll take a look when i'm feeling better 01.05.07 # i think i need to experiment with iriver_flash on the H100 series 01.05.10 # to get some ideas 01.05.53 # something isn't working right 01.06.06 # i don't want to modify the code further without knowing 01.06.11 # if the H100 code is still working 01.06.26 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 01.06.26 # so far i'd just done fixes that were equivalent 01.06.32 # to the original 01.09.06 Quit advcomp2019__ (Ping timeout: 256 seconds) 01.09.18 *** Saving seen data "./dancer.seen" 01.37.27 # _bilgus: i think i found something. 01.37.47 # the h300's flash chip has hardware bootblock protection... the same region the iriver_flash program tries to erase first. 01.38.06 # it doesn't appear to make it past there so 01.38.19 # maybe i need to figure out how to disable this 02.07.15 # <_bilgus> sounds like a pretty plausible cause 02.09.47 # the datasheet says the WP pin needs to be set high for the protection to be lifted 02.10.13 # so the question then is 02.10.24 # how do you set it? assuming it is even connected on the iriver. 02.10.45 # it says if it is left floating it defaults to being unprotected 02.54.40 # <_bilgus> well you tie it high with a 1k resistor or you set it on chip with gpio? 03.09.22 *** No seen item changed, no save performed. 04.10.36 Join advcomp2019 [0] (~advcomp20@65-131-145-101.sxct.qwest.net) 04.10.36 Quit advcomp2019 (Changing host) 04.10.36 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 04.11.33 Quit advcomp2019_ (Ping timeout: 265 seconds) 04.39.17 Quit S|h|a|w|n (Read error: Connection reset by peer) 05.09.26 *** Saving seen data "./dancer.seen" 05.49.21 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 06.05.05 # speachy: I don't know what you did exactly but someone reported to me that some of your recent commits fixed an audio stuttering issues on some old hosted sony players (the audio stutters when the display is off...). Good job :) 06.25.52 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 06.40.45 Join vvrng [0] (~vvrng@m91-128-94-73.cust.tele2.hr) 06.40.54 # hello! 06.42.03 # hello :) 06.42.07 # quick question, what is a recent-ish pmp which runs rockbox good? seems like the sansa clips are the most recent ones which run stable ports, and they're not in production anymore... 06.42.15 # but maybe I'm mistaken! 06.42.39 # maybe I'm not aware of the recent developments 06.56.29 # pamaury: glad to hear it. :D Just.. peeling the onion. 06.58.35 # vvrng: if you want someting new-ish then your only real options are the xduoo x3ii/x20, eros q/k (and clones), and the agptek rocker. 06.58.45 # vvrng: agptek rocker/benjie T6, AIGO: Eros Q / K (aka HIFI WALKER H2, AGPTek H3, and Surfans F20) 06.58.54 # pamaury i'd like to take over your USB Audio work https://gerrit.rockbox.org/r/#/c/rockbox/+/1009/ is there some specific things that I should focus on especially ? I was able to reapply the patch with the latest master (without working audio out… yet on my iPod Mini) 06.59.24 # (putting aside bugs introduced due to active development, they do work quite well for daily use) 07.09.30 *** No seen item changed, no save performed. 07.11.52 # speachy, wodz: thanks, I'm future proofing for when my iPod dies 07.16.37 # I've been using rockbox since 2012 or 2013 and I'd like to sincerely thank the community for the wonderful work 07.25.27 Quit pamaury (Quit: this->disconnect()) 07.34.21 # Build Server message: New build round started. Revision c5d7cd5, 293 builds, 9 clients. 07.40.02 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 07.48.26 # Build Server message: Build round completed after 846 seconds. 07.48.30 # Build Server message: Revision c5d7cd5 result: 1 errors 0 warnings 07.48.31 # Build Server message: New build round started. Revision dd3ea52, 293 builds, 7 clients. 08.00.14 Quit pamaury (Ping timeout: 260 seconds) 08.01.50 # Build Server message: Build round completed after 800 seconds. 08.01.51 # Build Server message: Revision dd3ea52 result: 1 errors 0 warnings 08.27.02 Quit Stanley00 (Remote host closed the connection) 08.31.38 Quit pookie (Quit: All for nothing) 08.33.01 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 08.41.48 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.47.34 # Airwave: I believe I've fixed the statusvar volume thingey. 08.47.48 # Airwave: ... sorry about that. 08.48.20 # Airwave: if you could grab the test build again, same URL as before. 09.08.07 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.09.33 *** Saving seen data "./dancer.seen" 09.27.21 # <_bilgus> WOOT! g#2811 is ready for testing!! 09.27.23 # Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct by William Wilgus 09.29.23 # <_bilgus> speachy I finally got my head out of my ass Turns out 2bit horiz screens are the weird one (ipods?..) so what was done was to translate between the lcd and rockbox native vertical format 09.30.13 # <_bilgus> so we've added LCD_NATIVE_STRIDE() to take care of that automagically 09.30.19 # Build Server message: New build round started. Revision 845e5a4, 293 builds, 9 clients. 09.32.00 # <_bilgus> I did some nice work on the dirty viewport front as well its now nicely integrated and doesn't cause the WPS to refresh needlessly ( the splash ! from last commit was testing) 09.32.41 # <_bilgus> and viewport_clear clears the dirty bit now too 09.33.44 # <_bilgus> and now to retest every target again 09.44.04 Quit mutax (Read error: Connection reset by peer) 09.44.20 Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) 09.46.17 # Build Server message: Build round completed after 956 seconds. 09.46.18 # Build Server message: Revision 845e5a4 result: All green 09.46.36 # edhelas: that's great :) Yes, so first for USB audio to work, the usb driver needs to be able to do isochronous transfers. The current usb api is very ill-suited for that purpose because those transfers are 1) very short and 2) very frequent (>1000/sec). So they can't be answered individually my IRQs and queuing/batching them is essentially. Furthermore, many cores need to handle them in a specific way and that is not implemented for most of 09.46.36 # them anyway. I believe the gerrit task only does it for the ARC core. 09.48.33 # speachy: any advice for my problem? seems i trigger a cpu exception handler when i try to flash the chip. i'm going to try to narrow it down. 09.48.44 # The second thing is that there the synchronization between the usb audio stream and the playback api is nontrivial as I recall, there needs to be some buffering going on to avoid underflow but not too much to avoid latency. There is also the problem of jitter: the audio clock and the host's clock diverge slowly and the audio will eventually under-/overflow. There are several mecanisms in the spec to handle this, with implicit or explicit 09.48.44 # feedback, none of this is implemented in the current code but probably it should. The current code is not very robust with regards to this aspect. 09.53.00 Quit mendel_munkis (Remote host closed the connection) 09.53.12 Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 10.05.54 Quit mendel_munkis (Remote host closed the connection) 10.06.12 Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 10.07.42 # Does rb has "usb dac" support on hosted targets? 10.08.04 # As in the device acts as a USB audio gadget, not connecting to an external dac over OTG 10.09.26 # I'm trying to fix usb mass storage on the m3k. Currently it doesn't actually work. 10.10.41 # And I'd like an option (disabled by default) to load the serial gadget module as well so people can easily get a root shell if they want, since this device doesn't have ADB. 10.15.52 # efqw: the short answer is no 10.16.28 # I suppose it's not a high priority 10.16.51 # Mass storage is more important imo 10.17.29 # Currently rb has working charger/usb detection so I suspect it's simply loading the kmods in the wrong order or something like that 10.17.40 # efqw: on the targets that already have audio gadget support, it probably wouldn't be _that_ bad to hook it up. 10.18.09 # Yeah this is assuming existing support, I just don't know how the i2s stuff would work 10.20.33 # efqw: we'd presumably get the audio data into userspace and pump it back out via our pcm api. 10.21.18 # Yeah I'll dig into the fiio player to find out how they handled that first 10.21.20 # (Assuming the audio gadget stuff presents itself as a normal audio device to userspace) 10.21.42 # I would assume the fiio stuff is a massive hack not shared by anything else 10.21.52 # guess i'll be doing some digging. if it really is this extra layer of write protection then i should be able to deduce it by some trial and error. 10.21.56 # * efqw seriously doubts fiio's ability to do anything "normal" 10.22.37 # braewoods: the last time I had wonky exceptions like that I'd add some canary values at various points of hte code I was trying to run and dump that variable in the panic handler. 10.22.50 # speachy: i see. 10.23.25 # flash write protection in of itself wouldn't trigger an exception. 10.23.27 # speachy: yea, ok. i did some tracing and it only happens after the bootloader is backed up prior to the first erase 10.23.32 # oh. 10.23.34 # i see. 10.23.55 # The binary rev engineered info will be on a separate wiki page, and I hope to put up a 3rd page about the stock fw layout as well. 10.24.49 # or at least I assume the CPU isn't "Writing" it by doing stores to the mmapped region. (if it does, that's unusual -- in-system-writes tend to require going through the flash controller rather than the mmap interface) 10.25.46 # it tries to write to the flash by issuing commands at specific addresses the ROM chip is connected to 10.26.08 Quit massiveH (Quit: Leaving) 10.28.47 # and doesn't the H300 have 32MB RAM? 10.29.00 # yes 10.29.06 # that address in the exception is at ~31.5MB. 10.29.14 # indeed. 10.29.14 # so it's legit. 10.29.33 # i figured that out and trace it to the address of a function in iriver_flash 10.29.53 # cfi_get_flash_info 10.29.58 # strange one 10.30.07 # did youever trace that excepction number to an explanation? 10.30.20 # speachy: no. it's just the generic trap 7 interrupt. 10.30.27 # the manual doesn't specify really 10.30.36 # just listed as part of traps 0 to 15 10.31.00 # anyway i have some ideas 10.31.17 # is pInfo->name valid? 10.31.24 # it should be. 10.31.39 # it is called twice in the program flow 10.31.54 # both times by the same function 10.32.12 # with an argument that is a pointer to a local variable 10.32.39 # speachy: would there be a delay in it getting triggered? 10.32.50 # i noticed it only triggers after a certain point. 10.32.58 # I mean, there's not a lot there in that function. 10.32.59 # but long after the function was called 10.33.12 # it seems to trigger right before the first erase attempt 10.33.30 # i'm considering omitting usage of that function since it is non-critical 10.33.34 # just to see what happens 10.33.38 # bad idea? 10.34.12 # or sanity-check the output immediately after it, and don't call erase. 10.34.45 # output of what? the function? 10.35.03 # hm 10.35.12 # yeah, make sure pInfo is sane. 10.35.56 # speachy: but the weird part is the function was called much earlier than the known failure point 10.36.05 # hm 10.38.26 # <_bilgus> braewoods, make anything local that gets used static 10.38.42 # <_bilgus> maybe there is a use after free situation 10.39.08 # including the plugin functions? 10.39.30 # or is that a problem with the linker? 10.39.40 # i noticed local functions are rarely made static 10.41.54 Quit pamaury (Ping timeout: 272 seconds) 10.42.38 # or you're passing a function pointer to something else, and it's called after it's gone out of scope. 10.42.42 # <_bilgus> static struct flash_info fi; 10.43.07 # <_bilgus> sorry had to find it or even put it up into the header 10.43.52 # <_bilgus> just making it static though will hide that using it after its gone out of scope 10.44.33 # <_bilgus> not that the compiler shouldn't pick up on that but..... 10.44.56 Quit vvrng (Read error: Connection reset by peer) 10.45.17 Join vvrng [0] (~vvrng@m91-128-94-73.cust.tele2.hr) 10.46.18 # <_bilgus> since you are passing this pointer all over the place I'd also check the functions leading up to your crash to see if they mutate it in any way 10.47.06 # _bilgus: well... here's the weird part... it doesn't trigger immediately. seems to trigger while attempting an erase. 10.47.19 # since it exits normally if i just return prior to erase attempt in the bootloader flash code. 10.47.27 # so is it even right? 10.47.35 # the reported function is called earlier 10.48.25 # <_bilgus> I saw that erasure is making copies of data it intends to overwrite those look to be stack allocs are you sure you aren't overflowing the stack? 10.48.43 # _bilgus: where? 10.49.22 # <_bilgus> nm its using the audio buffer 10.50.37 # <_bilgus> this function the one you refer to? cfi_erase_sector 10.50.43 # yes. 10.51.13 # it makes it to line 506 and that's the last known place before the interrupt. 10.52.38 # maybe i should add rb splash calls to see how far it reaches 10.53.10 # hm 10.54.43 # <_bilgus> yes and check your sector size i < SEC_SIZE/2 10.55.08 # <_bilgus> hazard a guess you are falling off the map 10.55.16 # that's expected 10.55.32 # the flash chips deal in 16 bit chunks 10.55.45 # so the sector size is split in half 10.55.55 # <_bilgus> i'm not saying the /2 I'm saying check the addresses 10.55.58 # Oh. 10.56.09 # i checked the math and it should check out 10.56.14 # but ok 10.56.57 # <_bilgus> ok so disable the part that does the actual erase and put in a static int to count up addresses then check it once it completes w/o crashing 10.57.38 # <_bilgus> then check your math vs its math 10.57.57 # ok. i'll stop the actual writes 10.59.29 # i'll gut these functions and see what happens 11.00.15 # <_bilgus> if you feel froggy add a define DEBUG_MODE or something and leave it for the future you 11.04.12 # just disabled the actual writes 11.04.17 # i'll see what happens 11.07.57 # nothing happened. ok. 11.08.19 # checking next thing 11.08.38 # <_bilgus> nothing as in no crash? 11.09.15 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.09.36 *** Saving seen data "./dancer.seen" 11.09.43 # _bilgus: yea. exitted normally. 11.09.54 # i disabled the guts of the 11.10.07 # erase / program routines 11.10.13 # <_bilgus> so now set a file to record the addresses and write it to disk 11.12.30 # _bilgus: how does rockbox do IO? 11.12.36 # standard stdio? 11.12.51 # <_bilgus> semi standard? 11.12.58 # <_bilgus> in plugins its east 11.13.01 # <_bilgus> easy* 11.13.10 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 11.15.03 # <_bilgus> https://github.com/Rockbox/rockbox/blob/master/apps/plugins/chessbox/chessbox_pgn.c 11.15.36 # <_bilgus> there is the one I left in chessbox should be pretty easy to see whats going on 11.17.00 # <_bilgus> pgn_parse_game() 11.18.22 # what controls the size of teh statusbar on non-WPS stuff? is it purely theme-controlled? 11.18.56 # <_bilgus> you mean the one you see from the main menu? 11.19.00 # yeah 11.19.19 # <_bilgus> probably static 11.19.38 # it's sized for the fixed 8pt sysfont, when using a larger font the volume number display is all screwed 11.20.07 # <_bilgus> yeah i'll double check maybe it uses get string size somewhere 11.22.47 # ugh, I think it's sized for UIFONT, but when SYSFONT is larger, badness. 11.26.43 # <_bilgus> statusbar.h ln 33 11.28.28 # <_bilgus> better bet is probaby to force its font size in the set-up for the vp 11.30.29 # that can be done? I thought the FONT_ID was a fixed size. 11.30.57 # <_bilgus> we could actually resize dynamically too, You'd just lock in the font of a proper size 11.31.15 # <_bilgus> say sys_font_8 11.31.53 # the offsets of the elements are all fixed relative to each other 11.32.04 # looks like a new rabbit hole. :D 11.32.14 # <_bilgus> might require adding it but I think the small standard ones are already in (fonts) 11.33.11 # <_bilgus> I guess the 3rd option is to make it aware of the font size at buildtime 11.33.35 # <_bilgus> how though not so sure 11.34.35 # <_bilgus> if we select in our font at ln 172 we can use that to determine the max height at runtime 11.34.57 # <_bilgus> it has font_0 at invocation 11.41.03 # <_bilgus> only reason any of this is now feasible is because the removal of charcell and hwcoded 11.41.16 # <_bilgus> ysay for progress! 11.41.49 # <_bilgus> CLIP V1 will be the next 11.42.05 Quit mutax (Quit: Back to RL) 11.42.15 # to go, you mean? 11.42.18 # <_bilgus> yep 11.42.23 # memory? 11.42.34 # <_bilgus> no ram and no sd slot 11.43.12 # <_bilgus> there aren't many left in my estimation 11.43.21 # <_bilgus> seeing as the flash goes 11.43.42 # I think we have a few other <2MB targets too 11.43.54 # <= 11.45.10 # <_bilgus> I doubt I pushed up binaries to where it matters yet but its something i'll have to pay close attention to 11.45.15 Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) 11.46.48 # <_bilgus> I may have a go at that statusbar code next if you aren't too hurried about it 11.47.05 # <_bilgus> I want to get the bt menu worked out and send this rocker back 11.47.14 # we are stuck with SYSFONT or UIFONT though, because they're the only ones guaranteed to be there 11.53.27 # (ie everything else requires the user to install teh fontpack. so this means we need to make the statusbar dependent on the height of sysfont_fixed or uifont. 11.55.57 # <_bilgus> sounds easy enough to just change the define based on whichever is hardcoded then 11.56.38 # yeah, trying to figure out if there's a way to glean that at build time. 11.57.06 # Build Server message: New build round started. Revision 5d5f816, 293 builds, 9 clients. 11.57.43 # the volume number displayed will now respect numdecimals so we won't get "-300" when it's really -30.0 11.58.04 # this is one of those things I'm surprised went this long 11.58.08 # cd .. 12.00.20 # <_bilgus> lol 12.00.52 # <_bilgus> #ifdef SYSFONT_HEIGHT #ifdef UIFONT_HEIGHT? 12.02.42 # <_bilgus> idk I don't appear to have anything with UIfont 12.03.00 # UIFont can change at runtime, only SYSFONT_FIXED is guaranteed static. 12.03.07 # (and thus can be used in a #define) 12.03.58 # well, I guess we need 16x16 icons now too. :D 12.03.59 # <_bilgus> oh then kinda locked there atm it doesn't currently have the wiring for dynamic resize 12.04.47 # <_bilgus> not it! 12.05.32 # well, the main reason SYSFONT_FIXED is 16px on tehse things is to make the bootloader text readable 12.10.41 # Build Server message: Build round completed after 815 seconds. 12.10.45 # Build Server message: Revision 5d5f816 result: All green 12.14.08 Join fs-bluebot [0] (~fs-bluebo@55d466ce.access.ecotel.net) 12.14.21 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 12.14.58 Quit bluebrother^ (Ping timeout: 258 seconds) 12.15.21 Quit fs-bluebot_ (Ping timeout: 258 seconds) 12.15.37 # _bilgus: ok. i did a dump log and there's nothing odd about the addresses that i can tell. 12.16.00 # it does seem to call the flash functions with sane arguments 12.16.11 # <_bilgus> they don't go higher than the available space? 12.16.36 # that i can tell 12.16.38 # moment 12.18.00 # wow. they can't handle 750KB file 12.18.05 # pastes are so limited 12.19.13 # https://braewoods.net/flash.log 12.19.38 # the first part is erasing then programming the early boot sector 12.19.55 # 0x10000000 is the start of IRAM 12.20.03 # and doesn't exceed iram size of 0xc00 12.20.05 # and doesn't exceed iram size of 0xc000* 12.20.16 # rest is in the ROM address region 12.20.37 # and the flash accesses are all aligned, not surprising but still worth looking at. 12.22.07 # then it loops the erase sector function 16 times to erase the boot sectors 12.22.19 # then it starts to program it 12.22.48 # all i can say is it seems to be something related to the actual attempts to write or erase the flash 12.23.05 # only way to know is to enable it with my new logging and see where it goes 12.30.58 # The Rockbox JPG decoder doesn't support progressive JPEG? 12.31.24 # Correct 12.31.48 # Is there a reason why? 12.35.19 # * gevaerts tries to do some research 12.37.08 # https://www.rockbox.org/irc/log-20090514#08:46:06 12.38.45 # So yes, apparently :) 12.38.52 # _bilgus: g#2908 is my hacky workaround. Make everything use 8px sysfont, except for the bootloaders. 12.38.54 # Gerrit review #2908 at http://gerrit.rockbox.org/r/2908 : statusbar: Make statusbar set to SYSFONT_HEIGHT by Solomon Peachy 12.39.47 # but the statusbar elements will be sized horizontally correctly based on font width, and vertically. 12.40.12 # <_bilgus> please wait to drop that ill I get 2811 done I just did a ws patch on top 12.40.44 # with 16x16 icons it has a good chance of JustWork-ing. 12.42.52 # <_bilgus> i'm gonna puysh this after I verify only WS changes 12.43.16 # okeydokey. 12.46.23 # _bilgus: ok... same error, same function at the given address. 12.46.36 # only when flash stuff is actually enabled in the mutative operations 12.46.41 # nothing in the log. 12.46.49 # did it crash before the buffer flushed? 12.48.26 # <_bilgus> Anyone got anything they wanna push before I tie this up with 3 commits? 12.51.30 # hm. 12.51.38 # i wonder if the WP# is mapped to one of the GPIOs. 12.51.57 # that's the only thing RB can directly manipulate to put something high or low 12.52.03 # and it is a very simple pin 12.52.22 # gpio is the most likely place it would be 12.55.40 # Build Server message: New build round started. Revision 40e98a2, 293 builds, 9 clients. 12.56.27 # <_bilgus> if any errors are found my guess is checkkwps , bootloaders, clipV1 12.58.36 # <_bilgus> hmm I hope it picked that up right I expected Moshe's commit to show but maybe it was able to figure it out on the backend 12.59.24 # _bilgus: when you submit several together it only "reports" the last one in the series. 13.03.47 # <_bilgus> ah ok that makes sense 13.05.05 # ok, 2908 is working, displays a sysfont-sized statusbar with no icon regressions. though without properly sized icons it's not going to look right. :) 13.05.45 # the commit also disables all 16px-sized sysfonts, leaving them only for the bootloaders. 13.08.03 # <_bilgus> oh is this a hosted thing? 13.09.27 # the higher-res ones got the higher-res sysfont so the bootloader would be readable 13.09.39 *** Saving seen data "./dancer.seen" 13.09.47 # <_bilgus> what if instead of that we altered the puts function to double size everything 13.10.30 # no reason to not use higher-res fonts in the BL 13.11.04 # only reason to not use it on the main fw is the statusbar being fixed. 2908 makes it display properly with the clock etc 13.11.06 # <_bilgus> ok nbd I was just saying based on bootloader size issues 13.11.37 # no (practical) limitations on these targets 13.13.52 # the statusbar is skinnable but it's still fixed in height at compile-time 13.14.21 # it's a decent intermediate step towards making the statusbar properly dynamic. 13.15.41 # <_bilgus> I opend sb.c in 2908 and I said YESSS 13.15.54 # * _bilgus hates magic numbers 13.16.45 # the other widths are dependent on the actual icon used, so I left 'em alone. once we get a 16x16 icon set the macros will need revisiting 13.16.55 # Build Server message: Build round completed after 1274 seconds. 13.16.57 # Build Server message: Revision 40e98a2 result: 346 errors 42 warnings 13.17.02 # ohdear 13.17.30 # <_bilgus> lol 13.17.47 # they're all the same basic error 13.18.35 # <_bilgus> ugh next question is how it crept back in 13.18.46 # <_bilgus> give me a second I know what it is 13.19.33 # speachy: i'm considering the practicality of disassembling the stock firmware. any pointers? 13.20.15 # the idea i had was to trace the ASM to see if i can find out what it is doing to erase the flash when it does an upgrade. 13.22.37 # how much free space on tmp does rockboxdev assume? 13.22.56 # mendel_munkis: "as much as is needed" 13.23.03 # realistically it's a couple of GB. 13.23.51 # you can override the default download and build dirs 13.24.04 Quit pamaury (Ping timeout: 256 seconds) 13.24.11 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:d169:f3a5:aa12:572b) 13.24.13 # <_bilgus> and a damn unnamed initializer in reversi 13.24.47 # given the sheer scope of your changes this is a surprisingly small number of issues. 13.24.47 # <_bilgus> now i need to figure out what all it is using lol 13.25.14 # * _bilgus tests on as many targets as he can doesn't always work so well though 13.25.40 # most of the failures on my toolchain bump turned out to be the long tail of bootloaders 13.26.48 # I was just surprised when running it always runs out of space. 13.28.21 # how does resume work again? 13.28.35 # <_bilgus> stores a position in cfg 13.29.03 # <_bilgus> dependent on the playlist possibly 13.29.04 # I meantfor the toolchain buildscripts. 13.29.10 # sorry I wasn't clear 13.29.24 # <_bilgus> lol yeah I was grasping for context 13.30.20 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.30.28 # my approach was to blow it away and re-start 13.31.11 # (the build-dir, I mean. the eventual destination dir is fine to re-build on top of) 13.33.28 # <_bilgus> samn I never did get resume working properly 13.33.50 # <_bilgus> I also learned build one toolchain at a time 13.34.14 # thanks 13.34.18 # <_bilgus> none of that xyrsz stuff unless you want 14 hr redo's 13.38.42 # hey I successfully rebuilt all toolchains simultaneously on uzziyah. 13.43.18 # <_bilgus> so not only did reversi have unnamed initializers for the vp it had a zero prior to font so i'm not sure if it was broken and now fixed or is now broken 13.44.03 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 13.52.31 # I know it worked previously onthe X3. 13.53.19 Quit t0mato (Quit: Ping timeout (120 seconds)) 13.56.26 # <_bilgus> still works, weird 13.58.11 # <_bilgus> red tellow 13.58.14 # <_bilgus> g#2911 13.58.16 # Gerrit review #2911 at http://gerrit.rockbox.org/r/2911 : FIX RED/TELLOW framebuffer viewport rewrite by William Wilgus 13.58.37 # <_bilgus> see the vp init there that 0 prior to font, no vp have an extra elem there 13.59.30 # <_bilgus> ohh yes they do flags 14.04.06 # Build Server message: New build round started. Revision 9b295ce, 293 builds, 9 clients. 14.06.19 # <_bilgus> still gonna be red for the iaudio x5 14.10.14 Join t0mato [0] (~t0mato@193.32.127.159) 14.17.40 # e00v2 is probably in the same red boat 14.24.10 # speachy: Sorry, I was away from the computer. Want me to try the test build? 14.24.32 # Airwave: latest dev build should be good 14.24.38 # Build Server message: Build round completed after 1232 seconds. 14.24.40 # Build Server message: Revision 9b295ce result: 554 errors 0 warnings 14.24.47 # speachy: The one on https://build.rockbox.org/ ? 14.24.49 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 14.25.33 # _bilgus: um... 14.27.53 # <_bilgus> lol 14.29.21 # <_bilgus> because its now current_viewport 14.29.25 # speachy: My theme looks broken when I try this build 14.29.41 # <_bilgus> sorry don't have any of the bootloaders made to test 14.29.57 # Airwave: in what way? 14.30.05 # There are lines between top bar elements. Most of the main screen has a black outline around it 14.30.24 # <_bilgus> what target and is this the one that is up now? 14.31.08 # Airwave: try this: https://download.rockbox.org/daily/agptekrocker/rockbox-agptekrocker-20201026.zip 14.31.17 # _bilgus: It's the Rocker, and yes. 14.32.18 # speachy: Okay, installing. I'm not using the default theme by the way. 14.33.20 # speachy: Yeah it looks good with that one 14.34.45 # Was the top bar showing 10x volume supposed to be fixed in this one? 14.38.01 # Build Server message: New build round started. Revision ada919f, 293 builds, 9 clients. 14.39.40 # <_bilgus> I assume this is a me thing what theme? 14.41.50 # _bilgus: Are you asking me? 14.41.55 # <_bilgus> yes 14.42.06 # Oh, sorry. I use this theme: http://themes.rockbox.org/index.php?themeid=2054&target=gogearsa9200 14.42.44 # <_bilgus> O_o DB Error: attempt to write a readonly database (8) 14.42.44 # <_bilgus> SQL: UPDATE themes SET downloadcnt=downloadcnt+1 WHERE themeid=:id Array ( [:id] => 2054 ) 14.42.55 # _bilgus: reload 14.43.12 # worst case I'll manually unwedge things. 14.43.25 # <_bilgus> i t worked 14.43.26 # Airwave: I do notice that the theme claims "doesn't work with current build" 14.43.45 # Airwave: good choice of theme :) 14.43.46 # <_bilgus> but he was using it 14.43.48 # speachy: Yeah I noticed that too just now. I haven't experienced any issues with it though 14.43.55 # that means checkwps fails 14.43.59 # lebellium: :-D 14.44.07 # lebellium: I honestly love it 14.44.27 # hm. 14.44.31 # i wonder... 14.44.39 # i'm going to compare the datasheets again 14.44.40 # All my themes used to work with current build. Hopefully I don't need to update them all because some devs are playing with the theme engine :P 14.44.46 # see if there's some behavior the old code is incompatible with 14.45.05 # Looks fantastic. The only thing I disliked was the background image, but that was simple enough to change. 14.45.37 # lebellium: How come it doesn't appear on the Rocker theme page? It works perfectly on Rocker. 14.45.37 # heh, it dumps core 14.45.54 # <_bilgus> huh when I applied it I got a segfault 14.46.03 # it segfaults in viewport_set_defaults() 14.46.04 # <_bilgus> on reboot it works though 14.46.12 # in checkwps 14.46.30 # a null pointer dereference 14.47.08 # <_bilgus> OH nice info 14.47.23 # <_bilgus> Airwave what is the issue you are having? 14.48.14 # _bilgus: You mean the theme issue with this build? https://build.rockbox.org/data/rockbox-agptekrocker.zip 14.48.25 # <_bilgus> yes 14.48.27 # Airwave: strange... I uploaded for Gogear because I actually have the Gogear and the Rocker didn't exist back to 2014 but as far as I know the themes filter is based on resolution so I would assume that it would appear on the Rocker page too. hum 14.48.57 # _bilgus: Let me get a screenshot of how it's supposed to look vs. how it looks on the new build, gimme a minute 14.49.36 # lebellium: it fiters out ones that don't work 14.50.07 # pfff you broke almost all my themes :( 14.50.08 # http://themes.rockbox.org/index.php?searchtheme&searchword=lebellium%20Samsung-like&searchtype=name 14.50.10 # there was never a "stable" rocker release 14.51.01 # oh I didn't think about that, makes sense 14.51.02 # Hmm according to https://www.rockbox.org/wiki/ScreenDump there's supposed to be a screendump function in debug, but I can't find it 14.52.34 # But I can describe the issue. There are lines between top bar elements, and most of the main screen has a black outline around it. 14.53.03 # <_bilgus> I think thats gone now 14.53.14 # the fact that it segfaults checkwps is a big red flag. 14.53.22 # _bilgus: Okay, do you have a build I should try? 14.53.44 # <_bilgus> is there more info on the null access in set_defaults? 14.54.04 # <_bilgus> the one that finishes here in a bit 14.54.41 # it's actually in viewport_set_fullscreen 14.55.29 # L287: screens[screen].init_viewport(vp); 14.56.33 # and 'screens' is nil 14.57.07 # <_bilgus> screens is nil O_o 14.57.31 # <_bilgus> oh it needs an ifdef 14.57.52 # screens _should_ be defined, in checkwps.c 14.59.51 # <_bilgus> it is 15.00.06 # <_bilgus> but it doesn't know about init_vp 15.09.42 *** Saving seen data "./dancer.seen" 15.11.11 # well this is helpful. i got a usb power meter for measuring current over usb 15.11.19 # now i can see if stuff is charging, etc 15.12.15 # ... wow 15.12.27 # this h120 has an ancient rockbox bootloader 15.12.36 # surprising. 15.12.45 # never thought i'd find a unit that had been modded previously 15.13.12 # just bought a iHP-120 for €20 :) 15.13.17 # they said it was red light when charging 15.13.21 # but 15.13.32 # i think the issue is they were using a 6V ac adapter! 15.13.42 # this is rated for 5V 15.13.47 # i'm guessing it was refusing to charge 15.14.27 # i'll let it charge awhile and see if it can run off battery 15.16.19 # Build Server message: Build round completed after 2295 seconds. 15.16.35 # Build Server message: Revision ada919f result: 62 errors 0 warnings 15.17.36 # <_bilgus> woo 15.17.53 # the errors are the reversi fix 15.18.20 # except e200v2 (lcd_framebuffer) 15.18.53 # <_bilgus> getting close FFS gotta be almost there 15.19.33 # <_bilgus> I think I just need a dummy init_viewports 15.20.42 # <_bilgus> also I'm not sure why I can't get these particualr errors in the builds here but maybe I'm just not doing the right ones 15.21.29 # the reversi bug is 'bg_pattern' instead of 'bgpattern' 15.22.16 # a typo 15.22.29 # and only on touch screens 15.22.44 # <_bilgus> ah 15.22.54 # <_bilgus> yeah I don't have any TS targets 15.23.06 # that should leave only the e200v2 failure. 15.28.03 # Build Server message: New build round started. Revision 04e7bac, 293 builds, 9 clients. 15.29.28 # checkwps no longer crashes, yay 15.29.41 # but valgrind does show a leak 15.33.49 # <_bilgus> oh? 15.34.12 # checkwps.c never free()s the skin_buffer it malloc()s 15.34.30 # pretty minor all in all. 15.35.44 # but back to the theme issue, I wonder if the theme (and others) was relying om some formerly-implicit behavior 15.39.52 # <_bilgus> 2914 now frees the buffer 15.40.17 # <_bilgus> it's quite possible there was a lot of that implicit fallback to the default fb going on 15.41.09 # well, I guess we neet to break a lot of eggs. 15.41.10 # <_bilgus> I have it well tamed in core but its always possibe I missed something or 348 somethings 15.42.15 # <_bilgus> wow I wondewr if those are the final size tallys 15.42.24 # <_bilgus> only 1k 15.42.39 # give or take, yeah 15.43.06 # <_bilgus> xduoox20 3k but still I was expecting way more 15.43.31 # but the x3ii was only 172, and it's nearly identical 15.44.07 # <_bilgus> No I'm perfectly fine with fixing anything new that pops up it goes towards a more stable system this way IMO 15.44.17 # there's still a little nondeterminism between our builders 15.44.21 # i'll test the iriver_flash from development builds 15.44.28 # on this new h120 15.44.33 # see 15.44.38 # if it works on the original target 15.44.40 # absolutely, we need to fix this stuff properly 15.44.52 # talking to me? 15.44.54 # oh no 15.45.09 # but 15.45.12 # <_bilgus> lol no but thats a good idea to check the original brea 15.45.20 # if i can't figure out the H300 erase procedure 15.45.29 # there's not much point to iriver_flash on it 15.45.30 # lol 15.46.00 # heh. just watched a bot try to break into the buildserver 15.46.15 # speachy: password logins disabled? 15.46.32 # usually the best option for SSH 15.46.36 # braewoods: the C&C port for the builders 15.46.40 # oh 15.47.00 # pretty hard to do a buffer overflow on native perl. :) 15.47.15 # speachy: still it seems pretty clear the H300 is failing to erase the flash 15.47.22 #