| 00:00:05 | braewoods | it does it every time when i try to let iriver_flash do its thing with the bootloader |
| 00:00:08 | braewoods | but |
| 00:00:12 | braewoods | nothing happens to the flash |
| 00:00:16 | braewoods | so |
| 00:00:27 | braewoods | 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 | braewoods | where would I put that? |
| 00:01:36 | _bilgus | in the makefile of whatever you are building |
| 00:01:45 | braewoods | 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 | braewoods | is rockbox.map the file? |
| 00:06:14 | _bilgus | yep |
| 00:06:24 | braewoods | 0x0000000032f80000 _pluginbuf = . |
| 00:06:29 | braewoods | this is the region it is in... |
| 00:06:38 | braewoods | 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 | braewoods | _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 | braewoods | 0x0000000032f800ee |
| 00:09:28 | braewoods | found it |
| 00:09:34 | braewoods | cfi_get_flash_info |
| 00:09:37 | braewoods | strange. |
| 00:09:55 | _bilgus | it clearly read an invalid address |
| 00:10:09 | braewoods | i'll see what happens |
| 00:10:27 | _bilgus | stick in some bounding |
| 00:10:47 | braewoods | bounding? |
| 00:10:52 | braewoods | right. |
| 00:11:00 | braewoods | 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 | braewoods | _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 | braewoods | cfi_get_flash_info is only ever called with a pointer to a stack allocation |
| 00:12:56 | braewoods | so hm |
| 00:13:17 | _bilgus | Idk where you'd get info on what err 7 is |
| 00:13:24 | braewoods | indeed |
| 00:13:56 | _bilgus | pointer to whos stack alloc? |
| 00:14:16 | _bilgus | your control? |
| 00:14:34 | braewoods | i don't know honestly. |
| 00:14:40 | _bilgus | also toochain updates?? |
| 00:14:42 | braewoods | just going by what i'm seeing here |
| 00:15:43 | braewoods | 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 | braewoods | 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 | braewoods | weird part is |
| 00:19:53 | braewoods | it makes it well past that function. if i add a return before the first cfi_erase_sector |
| 00:20:01 | braewoods | so... |
| 00:20:15 | braewoods | 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 | braewoods | it's reproduceable |
| 00:20:45 | braewoods | something is up |
| 00:20:55 | braewoods | anyway |
| 00:21:02 | braewoods | i'll give another try later |
| 00:21:03 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 00:21:04 | braewoods | i got an idea or 2 |
| 00:21:22 | braewoods | my idea is simple though |
| 00:21:38 | braewoods | i'll see if it works with the junker H120 I ordered |
| 00:21:40 | braewoods | when it arrives |
| 00:21:49 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 00:21:51 | braewoods | if it does there's something weird going on |
| 00:21:57 | braewoods | but if the toolchain works with H120... |
| 00:23:15 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 00:24:27 | braewoods | _bilgus: could Trap7 be delayed in triggering? |
| 00:24:34 | braewoods | is that why it gets as far as it does? |
| 00:33:24 | braewoods | hm. |
| 00:33:33 | braewoods | i found a manual on the coldfire cpu |
| 00:33:52 | braewoods | 27 is the index of the interrupt |
| 00:36:16 | braewoods | 0x28 or so? |
| 00:36:20 | braewoods | right |
| 00:36:25 | braewoods | 0x27 in base zero |
| 00:37:16 | braewoods | really generic error |
| 00:37:22 | braewoods | appears to be |
| 00:37:29 | braewoods | oh |
| 00:37:32 | braewoods | Trap #0–15 instructions |
| 00:40:20 | braewoods | real generic sounding |
| 00:40:25 | braewoods | 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 | braewoods | indeed. not sure. |
| 00:43:32 | braewoods | it starts before a successful erase |
| 00:43:39 | braewoods | or else i'd have bricked it |
| 00:50:06 | braewoods | but i'm suspecting some issue with the code |
| 00:50:16 | braewoods | i'll review the flash interactions |
| 00:59:18 | braewoods | i wonder |
| 00:59:36 | braewoods | the actual sample code from the vendor for these flash chips does a length routine to return to read mode |
| 00:59:47 | braewoods | maybe that's the problem |
| 00:59:59 | braewoods | the iriver_flash doesn't do it the same way |
| 01:00 |
| 01:00:31 | braewoods | maybe that worked by coincidence for the original H120 |
| 01:00:33 | braewoods | or so |
| 01:00:35 | braewoods | but not here |
| 01:00:40 | braewoods | hm |
| 01:00:47 | braewoods | well it's at least worth looking into |
| 01:01:00 | braewoods | 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 | braewoods | _bilgus: well i'll take a look when i'm feeling better |
| 01:05:07 | braewoods | i think i need to experiment with iriver_flash on the H100 series |
| 01:05:10 | braewoods | to get some ideas |
| 01:05:53 | braewoods | something isn't working right |
| 01:06:06 | braewoods | i don't want to modify the code further without knowing |
| 01:06:11 | braewoods | if the H100 code is still working |
| 01:06:26 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 01:06:26 | braewoods | so far i'd just done fixes that were equivalent |
| 01:06:32 | braewoods | to the original |
| 01:09:06 | | Quit advcomp2019__ (Ping timeout: 256 seconds) |
| 01:09:18 | *** | Saving seen data "./dancer.seen" |
| 01:37:27 | braewoods | _bilgus: i think i found something. |
| 01:37:47 | braewoods | the h300's flash chip has hardware bootblock protection... the same region the iriver_flash program tries to erase first. |
| 01:38:06 | braewoods | it doesn't appear to make it past there so |
| 01:38:19 | braewoods | maybe i need to figure out how to disable this |
| 02:00 |
| 02:07:15 | _bilgus | sounds like a pretty plausible cause |
| 02:09:47 | braewoods | the datasheet says the WP pin needs to be set high for the protection to be lifted |
| 02:10:13 | braewoods | so the question then is |
| 02:10:24 | braewoods | how do you set it? assuming it is even connected on the iriver. |
| 02:10:45 | braewoods | 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:00 |
| 03:09:22 | *** | No seen item changed, no save performed. |
| 04:00 |
| 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:00 |
| 05:09:26 | *** | Saving seen data "./dancer.seen" |
| 05:49:21 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:05:05 | pamaury | 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 | vvrng | hello! |
| 06:42:03 | edhelas | hello :) |
| 06:42:07 | vvrng | 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 | vvrng | but maybe I'm mistaken! |
| 06:42:39 | vvrng | maybe I'm not aware of the recent developments |
| 06:56:29 | speachy | pamaury: glad to hear it. :D Just.. peeling the onion. |
| 06:58:35 | speachy | 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 | wodz | vvrng: agptek rocker/benjie T6, AIGO: Eros Q / K (aka HIFI WALKER H2, AGPTek H3, and Surfans F20) |
| 06:58:54 | edhelas | 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 | speachy | (putting aside bugs introduced due to active development, they do work quite well for daily use) |
| 07:00 |
| 07:09:30 | *** | No seen item changed, no save performed. |
| 07:11:52 | vvrng | speachy, wodz: thanks, I'm future proofing for when my iPod dies |
| 07:16:37 | vvrng | 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 | fs-bluebot_ | 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 | fs-bluebot_ | Build Server message: Build round completed after 846 seconds. |
| 07:48:30 | fs-bluebot_ | Build Server message: Revision c5d7cd5 result: 1 errors 0 warnings |
| 07:48:31 | fs-bluebot_ | Build Server message: New build round started. Revision dd3ea52, 293 builds, 7 clients. |
| 08:00 |
| 08:00:14 | | Quit pamaury (Ping timeout: 260 seconds) |
| 08:01:50 | fs-bluebot_ | Build Server message: Build round completed after 800 seconds. |
| 08:01:51 | fs-bluebot_ | 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 | speachy | Airwave: I believe I've fixed the statusvar volume thingey. |
| 08:47:48 | speachy | Airwave: ... sorry about that. |
| 08:48:20 | speachy | Airwave: if you could grab the test build again, same URL as before. |
| 09:00 |
| 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 | fs-bluebot_ | 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 | fs-bluebot_ | 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 | fs-bluebot_ | Build Server message: Build round completed after 956 seconds. |
| 09:46:18 | fs-bluebot_ | Build Server message: Revision 845e5a4 result: All green |
| 09:46:36 | pamaury | 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 | pamaury | them anyway. I believe the gerrit task only does it for the ARC core. |
| 09:48:33 | braewoods | 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 | pamaury | 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 | pamaury | 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:00 |
| 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 | efqw | Does rb has "usb dac" support on hosted targets? |
| 10:08:04 | efqw | As in the device acts as a USB audio gadget, not connecting to an external dac over OTG |
| 10:09:26 | efqw | I'm trying to fix usb mass storage on the m3k. Currently it doesn't actually work. |
| 10:10:41 | efqw | 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 | speachy | efqw: the short answer is no |
| 10:16:28 | efqw | I suppose it's not a high priority |
| 10:16:51 | efqw | Mass storage is more important imo |
| 10:17:29 | efqw | 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 | speachy | efqw: on the targets that already have audio gadget support, it probably wouldn't be _that_ bad to hook it up. |
| 10:18:09 | efqw | Yeah this is assuming existing support, I just don't know how the i2s stuff would work |
| 10:20:33 | speachy | efqw: we'd presumably get the audio data into userspace and pump it back out via our pcm api. |
| 10:21:18 | efqw | Yeah I'll dig into the fiio player to find out how they handled that first |
| 10:21:20 | speachy | (Assuming the audio gadget stuff presents itself as a normal audio device to userspace) |
| 10:21:42 | speachy | I would assume the fiio stuff is a massive hack not shared by anything else |
| 10:21:52 | braewoods | 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 | speachy | 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 | braewoods | speachy: i see. |
| 10:23:25 | speachy | flash write protection in of itself wouldn't trigger an exception. |
| 10:23:27 | braewoods | 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 | braewoods | oh. |
| 10:23:34 | braewoods | i see. |
| 10:23:55 | efqw | 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 | speachy | 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 | braewoods | 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 | speachy | and doesn't the H300 have 32MB RAM? |
| 10:29:00 | braewoods | yes |
| 10:29:06 | speachy | that address in the exception is at ~31.5MB. |
| 10:29:14 | braewoods | indeed. |
| 10:29:14 | speachy | so it's legit. |
| 10:29:33 | braewoods | i figured that out and trace it to the address of a function in iriver_flash |
| 10:29:53 | braewoods | cfi_get_flash_info |
| 10:29:58 | braewoods | strange one |
| 10:30:07 | speachy | did youever trace that excepction number to an explanation? |
| 10:30:20 | braewoods | speachy: no. it's just the generic trap 7 interrupt. |
| 10:30:27 | braewoods | the manual doesn't specify really |
| 10:30:36 | braewoods | just listed as part of traps 0 to 15 |
| 10:31:00 | braewoods | anyway i have some ideas |
| 10:31:17 | speachy | is pInfo->name valid? |
| 10:31:24 | braewoods | it should be. |
| 10:31:39 | braewoods | it is called twice in the program flow |
| 10:31:54 | braewoods | both times by the same function |
| 10:32:12 | braewoods | with an argument that is a pointer to a local variable |
| 10:32:39 | braewoods | speachy: would there be a delay in it getting triggered? |
| 10:32:50 | braewoods | i noticed it only triggers after a certain point. |
| 10:32:58 | speachy | I mean, there's not a lot there in that function. |
| 10:32:59 | braewoods | but long after the function was called |
| 10:33:12 | braewoods | it seems to trigger right before the first erase attempt |
| 10:33:30 | braewoods | i'm considering omitting usage of that function since it is non-critical |
| 10:33:34 | braewoods | just to see what happens |
| 10:33:38 | braewoods | bad idea? |
| 10:34:12 | speachy | or sanity-check the output immediately after it, and don't call erase. |
| 10:34:45 | braewoods | output of what? the function? |
| 10:35:03 | braewoods | hm |
| 10:35:12 | speachy | yeah, make sure pInfo is sane. |
| 10:35:56 | braewoods | speachy: but the weird part is the function was called much earlier than the known failure point |
| 10:36:05 | braewoods | 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 | braewoods | including the plugin functions? |
| 10:39:30 | braewoods | or is that a problem with the linker? |
| 10:39:40 | braewoods | i noticed local functions are rarely made static |
| 10:41:54 | | Quit pamaury (Ping timeout: 272 seconds) |
| 10:42:38 | speachy | 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 | braewoods | _bilgus: well... here's the weird part... it doesn't trigger immediately. seems to trigger while attempting an erase. |
| 10:47:19 | braewoods | since it exits normally if i just return prior to erase attempt in the bootloader flash code. |
| 10:47:27 | braewoods | so is it even right? |
| 10:47:35 | braewoods | 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 | braewoods | _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 | braewoods | yes. |
| 10:51:13 | braewoods | it makes it to line 506 and that's the last known place before the interrupt. |
| 10:52:38 | braewoods | maybe i should add rb splash calls to see how far it reaches |
| 10:53:10 | braewoods | 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 | braewoods | that's expected |
| 10:55:32 | braewoods | the flash chips deal in 16 bit chunks |
| 10:55:45 | braewoods | 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 | braewoods | Oh. |
| 10:56:09 | braewoods | i checked the math and it should check out |
| 10:56:14 | braewoods | 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 | braewoods | ok. i'll stop the actual writes |
| 10:59:29 | braewoods | i'll gut these functions and see what happens |
| 11:00 |
| 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 | braewoods | just disabled the actual writes |
| 11:04:17 | braewoods | i'll see what happens |
| 11:07:57 | braewoods | nothing happened. ok. |
| 11:08:19 | braewoods | 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 | braewoods | _bilgus: yea. exitted normally. |
| 11:09:54 | braewoods | i disabled the guts of the |
| 11:10:07 | braewoods | erase / program routines |
| 11:10:13 | _bilgus | so now set a file to record the addresses and write it to disk |
| 11:12:30 | braewoods | _bilgus: how does rockbox do IO? |
| 11:12:36 | braewoods | 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 | speachy | 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 | speachy | yeah |
| 11:19:19 | _bilgus | probably static |
| 11:19:38 | speachy | 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 | speachy | 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 | speachy | 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 | speachy | the offsets of the elements are all fixed relative to each other |
| 11:32:04 | speachy | 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 | speachy | to go, you mean? |
| 11:42:18 | _bilgus | yep |
| 11:42:23 | speachy | 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 | speachy | I think we have a few other <2MB targets too |
| 11:43:54 | speachy | <= |
| 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 | speachy | we are stuck with SYSFONT or UIFONT though, because they're the only ones guaranteed to be there |
| 11:53:27 | speachy | (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 | speachy | yeah, trying to figure out if there's a way to glean that at build time. |
| 11:57:06 | fs-bluebot_ | Build Server message: New build round started. Revision 5d5f816, 293 builds, 9 clients. |
| 11:57:43 | speachy | the volume number displayed will now respect numdecimals so we won't get "-300" when it's really -30.0 |
| 11:58:04 | speachy | this is one of those things I'm surprised went this long |
| 11:58:08 | speachy | cd .. |
| 12:00 |
| 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 | speachy | UIFont can change at runtime, only SYSFONT_FIXED is guaranteed static. |
| 12:03:07 | speachy | (and thus can be used in a #define) |
| 12:03:58 | speachy | 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 | speachy | well, the main reason SYSFONT_FIXED is 16px on tehse things is to make the bootloader text readable |
| 12:10:41 | fs-bluebot_ | Build Server message: Build round completed after 815 seconds. |
| 12:10:45 | fs-bluebot_ | 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 | braewoods | _bilgus: ok. i did a dump log and there's nothing odd about the addresses that i can tell. |
| 12:16:00 | braewoods | 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 | braewoods | that i can tell |
| 12:16:38 | braewoods | moment |
| 12:18:00 | braewoods | wow. they can't handle 750KB file |
| 12:18:05 | braewoods | pastes are so limited |
| 12:19:13 | braewoods | braewoods.net/flash.log">https://braewoods.net/flash.log |
| 12:19:38 | braewoods | the first part is erasing then programming the early boot sector |
| 12:19:55 | braewoods | 0x10000000 is the start of IRAM |
| 12:20:03 | braewoods | and doesn't exceed iram size of 0xc00 |
| 12:20:05 | braewoods | and doesn't exceed iram size of 0xc000* |
| 12:20:16 | braewoods | rest is in the ROM address region |
| 12:20:37 | braewoods | and the flash accesses are all aligned, not surprising but still worth looking at. |
| 12:22:07 | braewoods | then it loops the erase sector function 16 times to erase the boot sectors |
| 12:22:19 | braewoods | then it starts to program it |
| 12:22:48 | braewoods | all i can say is it seems to be something related to the actual attempts to write or erase the flash |
| 12:23:05 | braewoods | only way to know is to enable it with my new logging and see where it goes |
| 12:30:58 | edhelas | The Rockbox JPG decoder doesn't support progressive JPEG? |
| 12:31:24 | gevaerts | Correct |
| 12:31:48 | edhelas | Is there a reason why? |
| 12:35:19 | * | gevaerts tries to do some research |
| 12:37:08 | gevaerts | https://www.rockbox.org/irc/log-20090514#08:46:06 |
| 12:38:45 | gevaerts | So yes, apparently :) |
| 12:38:52 | speachy | _bilgus: g#2908 is my hacky workaround. Make everything use 8px sysfont, except for the bootloaders. |
| 12:38:54 | fs-bluebot | Gerrit review #2908 at http://gerrit.rockbox.org/r/2908 : statusbar: Make statusbar set to SYSFONT_HEIGHT by Solomon Peachy |
| 12:39:47 | speachy | 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 | speachy | 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 | speachy | okeydokey. |
| 12:46:23 | braewoods | _bilgus: ok... same error, same function at the given address. |
| 12:46:36 | braewoods | only when flash stuff is actually enabled in the mutative operations |
| 12:46:41 | braewoods | nothing in the log. |
| 12:46:49 | braewoods | 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 | braewoods | hm. |
| 12:51:38 | braewoods | i wonder if the WP# is mapped to one of the GPIOs. |
| 12:51:57 | braewoods | that's the only thing RB can directly manipulate to put something high or low |
| 12:52:03 | braewoods | and it is a very simple pin |
| 12:52:22 | braewoods | gpio is the most likely place it would be |
| 12:55:40 | fs-bluebot | 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 | speachy | _bilgus: when you submit several together it only "reports" the last one in the series. |
| 13:00 |
| 13:03:47 | _bilgus | ah ok that makes sense |
| 13:05:05 | speachy | 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 | speachy | 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 | speachy | 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 | speachy | no reason to not use higher-res fonts in the BL |
| 13:11:04 | speachy | 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 | speachy | no (practical) limitations on these targets |
| 13:13:52 | speachy | the statusbar is skinnable but it's still fixed in height at compile-time |
| 13:14:21 | speachy | 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 | speachy | 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 | fs-bluebot | Build Server message: Build round completed after 1274 seconds. |
| 13:16:57 | fs-bluebot | Build Server message: Revision 40e98a2 result: 346 errors 42 warnings |
| 13:17:02 | speachy | ohdear |
| 13:17:30 | _bilgus | lol |
| 13:17:47 | speachy | 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 | braewoods | speachy: i'm considering the practicality of disassembling the stock firmware. any pointers? |
| 13:20:15 | braewoods | 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 | mendel_munkis | how much free space on tmp does rockboxdev assume? |
| 13:22:56 | speachy | mendel_munkis: "as much as is needed" |
| 13:23:03 | speachy | realistically it's a couple of GB. |
| 13:23:51 | speachy | 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 | speachy | 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 | speachy | most of the failures on my toolchain bump turned out to be the long tail of bootloaders |
| 13:26:48 | mendel_munkis | I was just surprised when running it always runs out of space. |
| 13:28:21 | mendel_munkis | 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 | mendel_munkis | I meantfor the toolchain buildscripts. |
| 13:29:10 | mendel_munkis | 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 | speachy | my approach was to blow it away and re-start |
| 13:31:11 | speachy | (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 | mendel_munkis | thanks |
| 13:34:18 | _bilgus | none of that xyrsz stuff unless you want 14 hr redo's |
| 13:38:42 | mendel_munkis | 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 | speachy | 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 | fs-bluebot | 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:00 |
| 14:04:06 | fs-bluebot | 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 | speachy | e00v2 is probably in the same red boat |
| 14:24:10 | Airwave | speachy: Sorry, I was away from the computer. Want me to try the test build? |
| 14:24:32 | speachy | Airwave: latest dev build should be good |
| 14:24:38 | fs-bluebot | Build Server message: Build round completed after 1232 seconds. |
| 14:24:40 | fs-bluebot | Build Server message: Revision 9b295ce result: 554 errors 0 warnings |
| 14:24:47 | Airwave | 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 | speachy | _bilgus: um... |
| 14:27:53 | _bilgus | lol |
| 14:29:21 | _bilgus | because its now current_viewport |
| 14:29:25 | Airwave | 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 | speachy | Airwave: in what way? |
| 14:30:05 | Airwave | 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 | speachy | Airwave: try this: https://download.rockbox.org/daily/agptekrocker/rockbox-agptekrocker-20201026.zip |
| 14:31:17 | speachy | _bilgus: It's the Rocker, and yes. |
| 14:32:18 | Airwave | speachy: Okay, installing. I'm not using the default theme by the way. |
| 14:33:20 | Airwave | speachy: Yeah it looks good with that one |
| 14:34:45 | Airwave | Was the top bar showing 10x volume supposed to be fixed in this one? |
| 14:38:01 | fs-bluebot | 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 | Airwave | _bilgus: Are you asking me? |
| 14:41:55 | _bilgus | yes |
| 14:42:06 | Airwave | 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 | speachy | _bilgus: reload |
| 14:43:12 | speachy | worst case I'll manually unwedge things. |
| 14:43:25 | _bilgus | i t worked |
| 14:43:26 | speachy | Airwave: I do notice that the theme claims "doesn't work with current build" |
| 14:43:45 | lebellium | Airwave: good choice of theme :) |
| 14:43:46 | _bilgus | but he was using it |
| 14:43:48 | Airwave | speachy: Yeah I noticed that too just now. I haven't experienced any issues with it though |
| 14:43:55 | speachy | that means checkwps fails |
| 14:43:59 | Airwave | lebellium: :-D |
| 14:44:07 | Airwave | lebellium: I honestly love it |
| 14:44:27 | braewoods | hm. |
| 14:44:31 | braewoods | i wonder... |
| 14:44:39 | braewoods | i'm going to compare the datasheets again |
| 14:44:40 | lebellium | 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 | braewoods | see if there's some behavior the old code is incompatible with |
| 14:45:05 | Airwave | Looks fantastic. The only thing I disliked was the background image, but that was simple enough to change. |
| 14:45:37 | Airwave | lebellium: How come it doesn't appear on the Rocker theme page? It works perfectly on Rocker. |
| 14:45:37 | speachy | heh, it dumps core |
| 14:45:54 | _bilgus | huh when I applied it I got a segfault |
| 14:46:03 | speachy | it segfaults in viewport_set_defaults() |
| 14:46:04 | _bilgus | on reboot it works though |
| 14:46:12 | speachy | in checkwps |
| 14:46:30 | speachy | 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 | Airwave | _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 | lebellium | 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 | Airwave | _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 | speachy | lebellium: it fiters out ones that don't work |
| 14:50:07 | lebellium | pfff you broke almost all my themes :( |
| 14:50:08 | lebellium | lebellium%20Samsung-like&searchtype=name">http://themes.rockbox.org/index.php?searchtheme&searchword=lebellium%20Samsung-like&searchtype=name |
| 14:50:10 | speachy | there was never a "stable" rocker release |
| 14:51:01 | lebellium | oh I didn't think about that, makes sense |
| 14:51:02 | Airwave | 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 | Airwave | 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 | speachy | the fact that it segfaults checkwps is a big red flag. |
| 14:53:22 | Airwave | _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 | speachy | it's actually in viewport_set_fullscreen |
| 14:55:29 | speachy | L287: screens[screen].init_viewport(vp); |
| 14:56:33 | speachy | 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 | speachy | screens _should_ be defined, in checkwps.c |
| 14:59:51 | _bilgus | it is |
| 15:00 |
| 15:00:06 | _bilgus | but it doesn't know about init_vp |
| 15:09:42 | *** | Saving seen data "./dancer.seen" |
| 15:11:11 | braewoods | well this is helpful. i got a usb power meter for measuring current over usb |
| 15:11:19 | braewoods | now i can see if stuff is charging, etc |
| 15:12:15 | braewoods | ... wow |
| 15:12:27 | braewoods | this h120 has an ancient rockbox bootloader |
| 15:12:36 | braewoods | surprising. |
| 15:12:45 | braewoods | never thought i'd find a unit that had been modded previously |
| 15:13:12 | lebellium | just bought a iHP-120 for €20 :) |
| 15:13:17 | braewoods | they said it was red light when charging |
| 15:13:21 | braewoods | but |
| 15:13:32 | braewoods | i think the issue is they were using a 6V ac adapter! |
| 15:13:42 | braewoods | this is rated for 5V |
| 15:13:47 | braewoods | i'm guessing it was refusing to charge |
| 15:14:27 | braewoods | i'll let it charge awhile and see if it can run off battery |
| 15:16:19 | fs-bluebot | Build Server message: Build round completed after 2295 seconds. |
| 15:16:35 | fs-bluebot | Build Server message: Revision ada919f result: 62 errors 0 warnings |
| 15:17:36 | _bilgus | woo |
| 15:17:53 | speachy | the errors are the reversi fix |
| 15:18:20 | speachy | 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 | speachy | the reversi bug is 'bg_pattern' instead of 'bgpattern' |
| 15:22:16 | speachy | a typo |
| 15:22:29 | speachy | 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 | speachy | that should leave only the e200v2 failure. |
| 15:28:03 | fs-bluebot | Build Server message: New build round started. Revision 04e7bac, 293 builds, 9 clients. |
| 15:29:28 | speachy | checkwps no longer crashes, yay |
| 15:29:41 | speachy | but valgrind does show a leak |
| 15:33:49 | _bilgus | oh? |
| 15:34:12 | speachy | checkwps.c never free()s the skin_buffer it malloc()s |
| 15:34:30 | speachy | pretty minor all in all. |
| 15:35:44 | speachy | 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 | speachy | 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 | speachy | give or take, yeah |
| 15:43:06 | _bilgus | xduoox20 3k but still I was expecting way more |
| 15:43:31 | speachy | 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 | speachy | there's still a little nondeterminism between our builders |
| 15:44:21 | braewoods | i'll test the iriver_flash from development builds |
| 15:44:28 | braewoods | on this new h120 |
| 15:44:33 | braewoods | see |
| 15:44:38 | braewoods | if it works on the original target |
| 15:44:40 | speachy | absolutely, we need to fix this stuff properly |
| 15:44:52 | braewoods | talking to me? |
| 15:44:54 | braewoods | oh no |
| 15:45:09 | braewoods | but |
| 15:45:12 | _bilgus | lol no but thats a good idea to check the original brea |
| 15:45:20 | braewoods | if i can't figure out the H300 erase procedure |
| 15:45:29 | braewoods | there's not much point to iriver_flash on it |
| 15:45:30 | braewoods | lol |
| 15:46:00 | speachy | heh. just watched a bot try to break into the buildserver |
| 15:46:15 | braewoods | speachy: password logins disabled? |
| 15:46:32 | braewoods | usually the best option for SSH |
| 15:46:36 | speachy | braewoods: the C&C port for the builders |
| 15:46:40 | braewoods | oh |
| 15:47:00 | speachy | pretty hard to do a buffer overflow on native perl. :) |
| 15:47:15 | braewoods | speachy: still it seems pretty clear the H300 is failing to erase the flash |
| 15:47:22 | braewoods | or else i'd have bricked it |
| 15:47:43 | braewoods | i think i need to investigate those routines. |
| 15:47:52 | braewoods | hm. |
| 15:47:56 | braewoods | what region is unused by the OF? |
| 15:48:13 | braewoods | this flash is pretty massive and the OF is only 2.7 MBs or so |
| 15:48:56 | braewoods | i mean iriver_flash is pretty critical to what i want to do |
| 15:49:05 | braewoods | if you can't flash from RB you can't replace the OF |
| 15:49:19 | fs-bluebot | Build Server message: Build round completed after 1277 seconds. |
| 15:49:23 | fs-bluebot | Build Server message: Revision 04e7bac result: 11 errors 0 warnings |
| 15:49:25 | speachy | braewoods: the actual server blocks about 150-200 unique IP addresses a day from breakins on the ssh ports alone. If I were to include bots hitting the www side, it would be much larger. |
| 15:49:32 | braewoods | ah |
| 15:50:00 | braewoods | it's possible something else is going on but the H300 flash chip does have a feature the H100 flash chip does not. |
| 15:50:04 | braewoods | the WP pin |
| 15:50:45 | braewoods | but it appears to only guard the bootblock |
| 15:51:20 | * | braewoods ponders. |
| 15:51:27 | speachy | that's not likely |
| 15:51:41 | speachy | I've never seen a WP/WE pin that doesn't cover everything |
| 15:51:55 | braewoods | I see. There's a separate WE pin. |
| 15:51:59 | speachy | but bootblocks might require a sort of doorbell/knock sequence to the command port |
| 15:52:04 | fs-bluebot | Build Server message: New build round started. Revision 299c237, 293 builds, 9 clients. |
| 15:52:07 | _bilgus | woot |
| 15:53:48 | braewoods | ok. |
| 15:53:50 | braewoods | this is the... |
| 15:53:57 | braewoods | datasheet's description of WP# |
| 15:54:00 | braewoods | "To protect the top/bottom boot block from Erase/Program operation when |
| 15:54:02 | braewoods | grounded. |
| 15:54:04 | braewoods | " |
| 15:54:10 | braewoods | so just specifically for that |
| 15:54:28 | speachy | huh, ok. |
| 15:54:33 | braewoods | which is the first 64K of the ROM |
| 15:54:40 | braewoods | for the one on the H300 |
| 15:54:50 | speachy | so it's presumably tied to a GPIO, but.. maybe not. |
| 15:55:03 | braewoods | there has to be a way around it or else the OF couldn't rewrite it |
| 15:55:17 | braewoods | assuming it is even connected |
| 15:55:26 | braewoods | the WP# defaults to high if unconnected |
| 15:55:34 | braewoods | which means, unprotected |
| 15:56:11 | braewoods | but i need to do some tests |
| 15:56:20 | braewoods | i'll test some of the high ROM that goes unused currently |
| 15:56:30 | braewoods | if that can be written then writes do work but... |
| 15:56:32 | _bilgus | so could you takeit apart put a probe on the wp pin the have the OF do an upgrade? |
| 15:56:53 | braewoods | _bilgus: how? the ROM chop is mounted BGA style. |
| 15:56:57 | braewoods | chip* |
| 15:57:08 | braewoods | meaning there's no easily accessible pins you can poke |
| 15:57:23 | _bilgus | oh well that would make it pretty difficult without a schematic |
| 15:57:32 | braewoods | indeed |
| 15:57:38 | braewoods | but if it is in use |
| 15:57:51 | braewoods | it is probably set by default to low |
| 15:57:59 | braewoods | which is 0, yes? |
| 15:58:01 | braewoods | in GPIO |
| 15:58:03 | braewoods | bits |
| 15:58:14 | braewoods | i'm not used to manipulating GPIO so i'm not sure |
| 15:58:25 | braewoods | there's always plan B |
| 15:58:45 | braewoods | try manipulating the undocumented GPIO pins to see if any of them do anything |
| 15:58:54 | braewoods | it's possible they were though unused due to no one pursuing this |
| 15:59:42 | speachy | braewoods: it's also possible the boot block is truly protected and not overwritten by the OF. |
| 16:00 |
| 16:00:31 | speachy | (then again, if our bootloader is written into that block... nevermind) |
| 16:05:03 | speachy | it could also be controlled indirectly, eg via a pin attached to the PMIC or something else |
| 16:08:05 | braewoods | speachy: yea, i just know GPIO is the best bet at the moment. |
| 16:08:06 | _bilgus | that theme still segfaults on first selection |
| 16:08:16 | _bilgus | time to track that down |
| 16:08:19 | braewoods | right now my new H120 is charging |
| 16:08:24 | braewoods | it's the junker unit i bought |
| 16:08:51 | braewoods | pulling .7 amps according to my meter |
| 16:10:03 | fs-bluebot | Build Server message: Build round completed after 1080 seconds. |
| 16:10:11 | fs-bluebot | Build Server message: Revision 299c237 result: 2 errors 0 warnings |
| 16:10:12 | fs-bluebot | Build Server message: New build round started. Revision 804a498, 293 builds, 8 clients. |
| 16:11:56 | speachy | I don't know WTF is oging on with the android builds. |
| 16:16:04 | braewoods | _bilgus: i mean the only way i can think is to remove the BGA chip, basically sacrificing an h300 permanently |
| 16:16:16 | braewoods | then seeing what the pads have continuity with |
| 16:16:35 | _bilgus | yep thats the unfortunate side of no info |
| 16:16:51 | braewoods | yea, there's no leaked schematics either |
| 16:17:02 | braewoods | so i think i'm better off trying some stuff. |
| 16:17:14 | braewoods | GPIO has 64 pins in the H300 |
| 16:17:24 | braewoods | i can try bruteforcing i guess |
| 16:17:37 | braewoods | i'd start with the pins no one has assigned to anything |
| 16:17:59 | braewoods | but first i plan to do some tests to see what behavior i observe |
| 16:18:07 | braewoods | i found there's a lot of unused ROM Space in the OF |
| 16:18:13 | braewoods | like a megabyte ish |
| 16:18:23 | braewoods | i should be able to erase part of that and do a test write |
| 16:18:33 | braewoods | with no harm to the OF |
| 16:18:46 | braewoods | it's all 0xFFFF patterns |
| 16:18:56 | braewoods | which is what the bits in this ROM default to when not programmed |
| 16:19:24 | braewoods | probably best to experiment with that part of the ROM |
| 16:19:55 | braewoods | i may have to use a different approach to support flashing here |
| 16:20:04 | braewoods | one option i've considered... |
| 16:20:31 | braewoods | considering the bootloader block RO and just be sure it has something we can leverage to boot from ROM that we can erase |
| 16:21:02 | braewoods | basically an idea is to have a bootloader for the bootloader so to speak |
| 16:21:11 | braewoods | chain that never gets erased |
| 16:21:32 | braewoods | not ideal but it is an option if i can erase part of high rom |
| 16:23:21 | _bilgus | speachy panic.c has a font dependent setting too |
| 16:25:29 | speachy | _bilgus: yeah.. but at least it scales based on the font/screen width |
| 16:26:21 | _bilgus | I think its the wrong one though missing half the info |
| 16:27:08 | speachy | hmm? |
| 16:28:45 | _bilgus | nope its not there |
| 16:29:04 | _bilgus | weird does something else do panics for Segmentation fault? |
| 16:29:47 | _bilgus | ah sig handler |
| 16:33:16 | fs-bluebot | Build Server message: Build round completed after 1384 seconds. |
| 16:33:17 | fs-bluebot | Build Server message: Revision 804a498 result: 4 errors 0 warnings |
| 16:33:56 | _bilgus | hmm now two more failed to complete? |
| 16:34:59 | speachy | they also use the android toolchain |
| 16:45:08 | | Quit pixelma (*.net *.split) |
| 16:45:08 | | Quit amiconn (*.net *.split) |
| 16:45:08 | | Quit ender| (*.net *.split) |
| 16:45:10 | | Quit atsampson (*.net *.split) |
| 16:45:10 | | Quit akaWolf (*.net *.split) |
| 16:45:10 | | Quit igitoor (*.net *.split) |
| 16:45:10 | | Quit Galois (*.net *.split) |
| 16:45:15 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 16:45:19 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 16:45:19 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 16:45:24 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 16:45:29 | | Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) |
| 16:45:41 | | Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) |
| 16:45:49 | | Quit igitoor (Changing host) |
| 16:45:50 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 16:47:21 | | Join Galois [0] (djao@efnet-math.org) |
| 16:58:23 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 17:00 |
| 17:07:09 | lebellium | "works with current build" |
| 17:07:11 | lebellium | thanks :) |
| 17:09:43 | *** | Saving seen data "./dancer.seen" |
| 17:12:50 | speachy | OK, I tink I've fixed a longstanding bug in the build client. ought to make us a bit more efficient. |
| 17:15:48 | braewoods | speachy: something interesting happened. |
| 17:15:49 | speachy | time to repeat the last build.. |
| 17:15:53 | fs-bluebot | Build Server message: New build round started. Revision 804a498, 293 builds, 9 clients. |
| 17:15:57 | braewoods | i produced a trap7 while doing something else. |
| 17:16:27 | braewoods | when i booted the h300 with usb attached, it entered usb bootloader. then i unplugged and replugged it quickly. |
| 17:16:34 | braewoods | during boot RB got a trap7 |
| 17:16:54 | braewoods | could it be the toolchain producing semi-flawed code? |
| 17:17:09 | braewoods | it would help if i knew what trap7 *was* |
| 17:17:36 | lebellium | _bilgus: the latest build doesn't fix FS #13249, it actually makes it worse. When I stop playback in my SBS mini-player, it freezes id3tags |
| 17:17:38 | fs-bluebot | http://www.rockbox.org/tracker/task/13249 SBS Info viewport not refreshing when used as a conditional (bugs, unconfirmed) |
| 17:18:24 | _bilgus | thjats is actually a good thing |
| 17:18:50 | _bilgus | well not overall |
| 17:18:52 | _bilgus | :p |
| 17:19:30 | _bilgus | right now I'm tracking down this crash on switch to that theme I'll start looking at that one next |
| 17:22:30 | speachy | no errors so far, good. |
| 17:23:33 | braewoods | interesting. |
| 17:23:42 | braewoods | the error pops up no matter what part of flash i try to erase |
| 17:23:47 | braewoods | i just tried on a safe region |
| 17:23:57 | braewoods | hm. |
| 17:33:08 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 17:36:18 | fs-bluebot | Build Server message: Build round completed after 1225 seconds. |
| 17:36:19 | fs-bluebot | Build Server message: Revision 804a498 result: All green |
| 17:37:10 | fs-bluebot | Build Server message: New build round started. Revision 804a498, 293 builds, 9 clients. |
| 17:37:25 | | Quit pamaury (Ping timeout: 264 seconds) |
| 17:44:10 | _bilgus | well I'll have to continue this later sd card in the rocker just went R/O |
| 17:56:29 | fs-bluebot | Build Server message: Build round completed after 1159 seconds. |
| 17:56:30 | fs-bluebot | Build Server message: Revision 804a498 result: All green |
| 17:57:51 | braewoods | speachy: apparently TRAP7 is one of the CF programmable trap interrupts... it's not predefined to anything. |
| 17:57:57 | braewoods | but then what is triggering it? |
| 17:58:03 | braewoods | would a debug build help? |
| 18:00 |
| 18:12:36 | speachy | maybe it's an unhandled exception, ending up in the default handler |
| 18:13:02 | braewoods | speachy: how would I find out if it is? |
| 18:13:28 | braewoods | hm. |
| 18:13:40 | braewoods | strange. |
| 18:13:45 | braewoods | i'm going to try something. |
| 18:14:43 | braewoods | speachy: i haven't done much with ASM so i feel like i'm running into a brick wall lol |
| 18:25:25 | | Quit JanC (Remote host closed the connection) |
| 18:25:48 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 18:41:26 | braewoods | strange |
| 18:47:59 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 18:48:00 | | Nick amiconn is now known as Guest90961 (jens@rockbox/developer/amiconn) |
| 18:48:00 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 18:48:04 | | Quit lebellium (Quit: Leaving) |
| 18:48:27 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 18:48:28 | | Nick pixelma is now known as Guest69839 (marianne@rockbox/staff/pixelma) |
| 18:48:28 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 18:48:57 | | Quit Guest69839 (Ping timeout: 260 seconds) |
| 18:48:57 | | Quit Guest90961 (Ping timeout: 260 seconds) |
| 19:00 |
| 19:03:01 | speachy | braewoods: this stuff is the lowest-level one can get, alas. |
| 19:03:14 | speachy | I'm not familiar with the vagracies of m68k/dragonball processors |
| 19:09:46 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:12:09 | | Join Huntereb [0] (~Huntereb@174.226.17.248) |
| 20:13:50 | | Quit bluebrother (Disconnected by services) |
| 20:13:54 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 20:14:10 | | Join fs-bluebot_ [0] (~fs-bluebo@55d47a77.access.ecotel.net) |
| 20:16:16 | | Quit fs-bluebot (Ping timeout: 246 seconds) |
| 20:35:07 | braewoods | hm. the junker unit mostly works after some preliminary repairs. |
| 20:35:20 | braewoods | but i need to resolder the navigation button to actually do anything with it |
| 20:50:04 | | Quit JanC (Remote host closed the connection) |
| 20:50:38 | braewoods | speachy: i found pay dirt. |
| 20:51:17 | braewoods | i dunno why but GCC is generating traps in the source code. |
| 20:51:37 | braewoods | it's the result of TRAP instructions being inserted. |
| 20:51:55 | braewoods | i just wanted to see what the generated ASM was |
| 20:52:05 | braewoods | gee, it's trap #7 |
| 20:52:11 | braewoods | the same turd that's been giving me grief! |
| 20:52:23 | braewoods | but why is GCC generating this? |
| 20:52:40 | braewoods | maybe we need to update how we build coldfire |
| 20:53:08 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 20:53:35 | speachy | I ran into something sorta like this when debugging the PP stuff, GCC was inserting an UND or something like that because it knew things were goign to go into the weeds. |
| 20:54:24 | speachy | wait, what's the first address of the flash sector? 0x0? |
| 20:54:28 | braewoods | 0x0 |
| 20:54:34 | braewoods | aka null |
| 20:54:46 | braewoods | what does GCC use trap 7 for? |
| 20:54:49 | speachy | it thinks you're deliberately doing a null pointer dereference. |
| 20:55:37 | braewoods | interesting. |
| 20:55:49 | speachy | add '-fno-delete-null-pointer-checks' and rebuild. |
| 20:56:02 | braewoods | speachy: i mentioned that we might need that before |
| 20:56:19 | braewoods | i only know about that because i remember it. it bit the linux kernel. |
| 20:56:24 | braewoods | when gcc 4.9 hit |
| 20:56:33 | braewoods | ok. i'll try it. |
| 20:56:52 | speachy | (the thing is, we generally _don't_ want to turn that on, but tehre are a few places where it does indeed matter. |
| 20:57:31 | braewoods | traps are gone |
| 20:57:55 | speachy | personally I would wrap the function with a #pragma that disables that option just for that function |
| 21:00 |
| 21:03:23 | braewoods | speachy: agreed |
| 21:03:31 | braewoods | i'll see what i can do. |
| 21:03:39 | braewoods | i'll need to patch this |
| 21:03:44 | braewoods | so traps are no longer generated |
| 21:06:39 | speachy | let's see if I got htis right |
| 21:08:35 | braewoods | speachy: i'll patch it |
| 21:08:39 | braewoods | you don't need to |
| 21:08:48 | speachy | g#2915 |
| 21:08:50 | fs-bluebot_ | Gerrit review #2915 at http://gerrit.rockbox.org/r/2915 : iriver_flash: we need -fno-delete-null-pointer-checks by Solomon Peachy |
| 21:09:15 | speachy | this version of gcc won't let us use pragmas the way we need, so.. the next best thing. |
| 21:09:27 | braewoods | ok, works for me. |
| 21:09:50 | *** | Saving seen data "./dancer.seen" |
| 21:09:53 | braewoods | speachy: i take it function attributes also don't work? |
| 21:12:43 | braewoods | hm |
| 21:12:44 | braewoods | anyway |
| 21:13:14 | speachy | can't seem to make the attribute stick. |
| 21:13:56 | braewoods | i'll give it a try |
| 21:14:28 | speachy | __attribute__((optimize("no-delete-null-pointer-checks"))) |
| 21:17:51 | braewoods | pragma appears to work if set globally for the file... |
| 21:17:55 | braewoods | let's see if i can narrow it down |
| 21:19:29 | speachy | doing it for the whole file is probably best, |
| 21:19:47 | speachy | I was trying to wrap the function but it's inlined so god only knows what's going on |
| 21:21:12 | speachy | so doing it at the top of the file is fine |
| 21:21:17 | speachy | #pragma GCC optimize "no-delete-null-pointer-checks" |
| 21:21:45 | braewoods | ok |
| 21:22:28 | braewoods | i'll be reviewing the logic used to update the flash chip |
| 21:22:37 | braewoods | now that this is finally cleared |
| 21:22:50 | braewoods | commit whatever solution you think best |
| 21:23:36 | braewoods | at least now we know it's an issue with GCC |
| 21:23:53 | braewoods | we can turn it off when it proves meddlesome |
| 21:28:09 | fs-bluebot_ | Build Server message: New build round started. Revision f62eee5, 293 builds, 9 clients. |
| 21:28:17 | speachy | ok, it's pushed. |
| 21:30:55 | speachy | braewoods: really good catch btw |
| 21:31:13 | braewoods | well, i decided to look at the generated ASM. |
| 21:31:17 | braewoods | since nothing else made sense. |
| 21:31:29 | braewoods | rockbox doesn't use the traps at all |
| 21:31:34 | braewoods | so why is it being triggered? |
| 21:31:40 | braewoods | it turns out they have to be explicitly triggered in code |
| 21:31:49 | braewoods | they're commonly used to implement system calls |
| 21:31:54 | braewoods | but rockbox has no system calls that i can tell |
| 21:33:22 | braewoods | speachy: as it turns out the crap i read about nearly 8 years ago when gcc 4.9 first landed in Frugalware... |
| 21:33:30 | braewoods | actually turned out to be relevant again |
| 21:45:12 | speachy | and the warning that kicks in to tell us about the places where it "helped" is not there in 4.9 |
| 21:46:36 | fs-bluebot_ | Build Server message: Build round completed after 1106 seconds. |
| 21:46:37 | fs-bluebot_ | Build Server message: Revision f62eee5 result: All green |
| 21:52:00 | braewoods | i can see why you're not too eager to change toolchains |
| 21:52:02 | braewoods | brrr |
| 21:52:22 | braewoods | i'm going to update cfi_read_id |
| 21:52:51 | speachy | and more to the point, do them all in lock-step so we don't have different quirks to deal with on different targets. |
| 21:58:30 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 22:00 |
| 22:02:19 | | Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:e418:9938:b2ef:1e26) |
| 22:05:06 | braewoods | https://gerrit.rockbox.org/#/c/rockbox/+/2916 |
| 22:05:10 | braewoods | speachy: ^ |
| 22:06:25 | | Quit MrZeus_ (Ping timeout: 272 seconds) |
| 22:08:22 | speachy | I suspect the reason for the argument is that this funcion was lifted from a more generic source |
| 22:08:37 | braewoods | yea it was |
| 22:08:40 | speachy | the argument is probably optimized away anyway. |
| 22:12:28 | braewoods | speachy: not necessarily. i could only see that if it was inlined. |
| 22:13:52 | speachy | can you clean up the whitespace in a future patch? |
| 22:21:50 | braewoods | sure. |
| 22:27:10 | braewoods | i think i need to look for trap 7s in the bootloader code too |
| 22:27:24 | braewoods | you know |
| 22:27:30 | braewoods | that should be an option. |
| 22:27:37 | braewoods | for us to leave the generated ASM files |
| 22:27:49 | braewoods | so we can review them for problematic code |
| 22:28:19 | braewoods | it's especially important for rockbox since so many of its targets are freestanding |
| 22:39:41 | braewoods | https://gerrit.rockbox.org/r/#/c/rockbox/+/2917/ |
| 22:39:51 | braewoods | speachy: i integrated that and redid the commit |
| 22:39:52 | braewoods | ^ |
| 22:47:00 | _bilgus | speachy is there an easy way to translate the PC address from the rocker into my code |
| 22:47:14 | _bilgus | ie how do I get the base address of the app? |
| 22:49:03 | braewoods | _bilgus: it uses ASLR? |
| 22:49:44 | _bilgus | I don't think I just don't know the offset |
| 22:50:00 | braewoods | i believe there's an ELF symbol for that problem |
| 22:52:55 | braewoods | i can't recall it though |
| 22:54:16 | _bilgus | I guess I could dereference a pointer in the map and subtract |
| 22:54:43 | braewoods | some people define an extern char |
| 22:54:57 | braewoods | to reference a symbol's address |
| 22:55:16 | braewoods | there's some special ones in ELF or how linux handles dynamic loading at least |
| 22:56:15 | braewoods | i spent a lot of time researching how LD works before |
| 22:56:19 | braewoods | pretty complex crap |
| 22:56:41 | braewoods | essentially all dynamic executables are run through a platform specific dynamic loader (DL) |
| 22:56:58 | braewoods | /lib/ld-linux.so.2 for 32 bit x86 |
| 22:56:59 | braewoods | etc |
| 22:57:58 | _bilgus | Yeah I've used it for checking stack ovfl on tiny uc too |
| 22:58:37 | | Quit atsampson (Ping timeout: 260 seconds) |
| 22:59:03 | braewoods | my reason was different |
| 22:59:21 | braewoods | i needed to research it to create an optimized system for detecting broken dynamic linkage |
| 22:59:41 | braewoods | though that was 100% desktop linux |
| 22:59:49 | braewoods | or what i call GNU linux since it uses glibc |
| 22:59:54 | braewoods | architecture is kinda irrelevant |
| 22:59:55 | braewoods | there |
| 23:00 |
| 23:02:02 | braewoods | i'll be reviewing the flash routines of iriver_flash later |
| 23:02:02 | _bilgus | uhoh when I ask the address from within RB it gives me the same one in the map |
| 23:02:05 | | Quit MrZeus__ (Read error: Connection reset by peer) |
| 23:02:06 | braewoods | tomorrow probably |
| 23:02:18 | _bilgus | curious |
| 23:03:06 | braewoods | _bilgus: i got another H100 remote in fair condition |
| 23:03:08 | braewoods | woohoo |
| 23:03:33 | | Join MrZeus__ [0] (~MrZeus@90.203.212.4) |
| 23:03:49 | _bilgus | well they should work |
| 23:04:07 | braewoods | i got a long list of stuff i want to do with the H300 |
| 23:04:16 | braewoods | but iriver_flash was the first one |
| 23:04:35 | braewoods | why implement experimental ROM/RAM image support if the flash program can't even update the bootloader? |
| 23:09:54 | *** | Saving seen data "./dancer.seen" |
| 23:28:48 | braewoods | that's a good sign |
| 23:28:51 | speachy | braewoods: objdump -D file.elf | grep -i trap |
| 23:29:02 | braewoods | ? |
| 23:29:35 | speachy | to find any other lurking traps |
| 23:30:05 | speachy | well, m68k-elf-objdump |
| 23:30:29 | speachy | does a full disasm |
| 23:31:17 | braewoods | i see |
| 23:31:19 | speachy | _bilgus: hmm, it's going to be relocated each time it's invoked; in theory anywhere. but /proc/<pid>/maps should help |
| 23:31:51 | _bilgus | ah indeed I was typing pmaps |
| 23:32:02 | braewoods | speachy: found something but it's in the rodata section |
| 23:32:20 | _bilgus | I've already moved on to making panic log f scroll the buffer |
| 23:32:20 | | Quit Huntereb (Read error: Connection reset by peer) |
| 23:32:36 | speachy | rodata? presumably not executable.. |
| 23:33:03 | speachy | (we _shouldn't_ be playing games like that. doesn't mean we aren't..) |
| 23:33:03 | braewoods | hm |
| 23:33:22 | speachy | oh, use -d not -D |
| 23:33:32 | speachy | the latter will disassemble all sections, the former only executable |
| 23:33:52 | braewoods | no traps |
| 23:33:54 | speachy | I rely on -D a lot for dumping raw binaries |
| 23:34:12 | speachy | (and trying to find executable code in random fw images) |
| 23:34:28 | braewoods | h120 is done |
| 23:34:31 | braewoods | no traps |
| 23:34:37 | speachy | all elfs? |
| 23:34:51 | braewoods | no |
| 23:34:55 | braewoods | i only checking bootloader |
| 23:35:11 | braewoods | the bootloader.elf |
| 23:35:17 | braewoods | for h120, h100, h300 i built |
| 23:35:23 | braewoods | no trap asm |
| 23:35:43 | speachy | for x in `find . -name '*.elf'` ; do m68k-elf-objdump -d $x |grep trap ; done |
| 23:35:55 | braewoods | there's only one .elf file when you build the bootloader |
| 23:35:58 | speachy | gotta lobe shell |
| 23:36:09 | braewoods | so be it |
| 23:36:16 | speachy | anyway. time to hit the sack, before pumpkin hour for a change |
| 23:36:19 | speachy | g'nite, y'all |
| 23:37:03 | braewoods | speachy: it's trapoolsa |
| 23:37:05 | braewoods | lol |
| 23:37:10 | braewoods | tons of 'em in the main firmware |
| 23:37:34 | braewoods | afaik these should be disabled since RB has no trap handlers |
| 23:37:44 | braewoods | or at least investigated why they are getting built |
| 23:39:44 | braewoods | i'd start by cleaning up the main firmware ones |
| 23:39:51 | braewoods | since those are always loaded |
| 23:40:39 | | Quit MrZeus__ (Ping timeout: 260 seconds) |
| 23:41:06 | braewoods | most of the traps are in skin code |
| 23:41:09 | * | braewoods boggles. |
| 23:55:23 | S|h|a|w|n | whatcha guys working on? |
| 23:55:29 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 23:57:45 | | Quit S|h|a|w|n (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).