**** BEGIN LOGGING AT Sat Aug 22 02:59:57 2009
Aug 22 16:01:08 <mankash> hi
Aug 22 16:01:15 <mankash> anybody familiar with xtextaddr
Aug 22 19:04:56 <davidc__> anybody hacked on GDB much?
Aug 22 19:10:10 <robbe-> #define hacked
Aug 22 19:34:33 <davidc__> eh; trying to track down an incompatibility between GDB + openocd's mips support
Aug 22 19:40:59 <davidc__> seems gdb sign-extends all mips addresses internally; but the memory map its getting from openocd does not have those addresses sign-extended
Aug 22 19:41:17 <davidc__> so gdb fails on any examine / load / etc bit with the MSB set
Aug 22 19:50:51 <robbe-> I'm afraid I can't help with that. I've just been using openocd with this ARM µC
Aug 22 19:51:31 <robbe-> And it's working for me so didn't have to hack things like that (yet ... *crosses fingers*)
Aug 22 19:55:50 <davidc__> robbe-: I've fixed it in testing [manually patching addresses at runtime using GDB on GDB] manually sign-extending the bits
Aug 22 19:56:01 <davidc__> and that seems to work so I can actually flash images
Aug 22 19:57:39 <robbe-> nasty :D
Aug 22 19:59:58 <davidc__> yeah; and this thing has a fucked internal memory layout. its got stuff mapped multiple places; and the default linker scripts throw stuff that goes into the same physical memory into the various different mappings
Aug 22 20:00:29 <davidc__> so when you do a load() with gdb openocd tries to do general purpose writes to flash.
Aug 22 20:00:32 * davidc__ stabs microchip
Aug 22 20:00:52 <robbe-> lol
Aug 22 20:01:03 <robbe-> but, I know, it's not actually funno
Aug 22 20:01:06 <robbe-> funny
Aug 22 20:01:13 <davidc__> its getting to be funny :P
Aug 22 20:05:18 <davidc__> well; at least I know the path to success now; either patch GDB or openocd such that it generates valid memory segments
Aug 22 20:05:59 <davidc__> [likely gonna have to be openocd, since gdb won't take a memory segment that has the high bit set, so I need to split a segment]
Aug 22 20:06:27 <robbe-> Why doesn't GDB accept those?
Aug 22 20:06:44 <davidc__> robbe-: because GDB sign extends everything to 64bits on the mips arch
Aug 22 20:07:07 <robbe-> How did you ./configure GDB?
Aug 22 20:07:09 <davidc__> so say I have a memory segment from 0x00000000 to 0xbd000000 [just unused space with a couple of SFRs laying about]
Aug 22 20:07:14 <davidc__> --target=mipsel
Aug 22 20:07:33 <robbe-> Maybe there are other options? Just guessing here :)
Aug 22 20:07:50 <davidc__> I don't think so :( I've been reading over the code; seems to do that sign extend on the entire arch
Aug 22 20:08:45 <davidc__> anyhow; if I just naively sign extend that segment; I get 0x0000000000000000 to 0xffffffffbd000000 , which is sorta huge
Aug 22 20:15:17 <robbe-> I just ./configure --target=mips32
Aug 22 20:15:37 <robbe-> wait nvm
Aug 22 20:15:37 <robbe-> :p
Aug 22 20:16:43 <davidc__> well; its worth giving that a shot; I'll try mips32el [since my target is little endian]
Aug 22 20:22:46 * robbe- retries with --disable-werror ..
Aug 22 20:22:47 <robbe-> :)
Aug 22 20:26:18 <davidc__> no luck with the mips32 build variant. I think I'm just gonna hack the target memory layout read routines in GDB to hack it into working
Aug 22 20:26:32 <robbe-> This GDB was configured as "--host=i686-pc-linux-gnu --target=mips32".
Aug 22 20:26:35 <robbe-> ah, darn
Aug 22 20:26:38 <robbe-> too late :)
Aug 22 20:26:52 <davidc__> an ugly hack; but if it gets me the ability to load code; I'm happy
Aug 22 20:27:06 <robbe-> ;)
Aug 22 20:27:17 <davidc__> [it works great if I hand-fixup the addresses while gdb'ing gdb, and use a non-fucked linker script]
Aug 22 20:28:41 <robbe-> I recently figured out the ins and outs of gnu ld linker scripts.
Aug 22 20:29:07 <robbe-> I think you always want those customized for your µC
Aug 22 21:11:15 <mankash> anybody familiar with xtextaddr
Aug 22 21:17:00 <davidc__> mankash: please give context.
Aug 22 21:19:00 <mankash> I am using redboot and when I execute a program like hello program I get this error
Aug 22 21:19:20 <mankash> I am using gdb, when I type continue and program gives an error Program received signal SIGBUS, Bus error
Aug 22 21:19:32 <mankash> Cannot access memory at address 0xfc0ffc01
Aug 22 21:21:22 <mankash> davidc_: any idea?
Aug 22 21:41:39 <robbe-> bus error generally means that you are trying to read memory from locations the memory manager doesn't like you to
Aug 22 21:41:54 <robbe-> it's like a segfault, but on hardware level
Aug 22 21:46:52 <davidc__> mankash: can also mean you're doing an unaligned hardware read
Aug 22 21:47:02 <davidc__> [or write]
Aug 22 21:51:03 <davidc__> mankash: what architecture are you using?
Aug 22 22:34:44 <davidc__> sweet; finally; it all works. hallelujah. Now; to make the linker script actually meaningful....
Aug 22 22:44:05 <mankash> davidc_: I am  using xscale ( arm)
Aug 22 22:45:43 <davidc__> what kind of read are you trying to do to: 0xfc0ffc01
Aug 22 22:46:02 <davidc__> if its anything other than a byte read; you're going to get an unaligned read issue, which is a bus error
Aug 22 22:47:56 <mankash> do you have experience in embedded system
Aug 22 23:06:55 <mankash> davidc_:  how to fix ?
Aug 22 23:53:59 <davidc__> mankash: depends on your code. Hook up a debugger; figure out where you're crashing, then figure out why.
**** ENDING LOGGING AT Sun Aug 23 02:59:56 2009