olofk | I need a component that parses an or1k ELF file and gives me the memory contents. Where should I look? | 00:39 |
---|---|---|
olofk | I could use objdump or objcopy (never learn which is which tool), but I would prefer to have it as a library function | 00:40 |
olofk | I tried to rip it out from or1ksim too, but it was more integrated in the code than I had hoped for | 00:40 |
olofk | _franck_: A GDB question, in the current version, GDB refuses to read SPRs that aren't defined in the GDB code. Will the XML stuff fix that? | 00:52 |
blueCmd | olofk: it's probably objcopy -O binary input.elf output.bin you want to emulate then | 01:23 |
olofk | Yeah, I figured that out by looking at some makefile. I'll probably do a first version that calls it directly | 01:24 |
blueCmd | sorry, don't know any libraries but you might want to look at objcopy - it shouldn't be that hard to parse the ELF header and find the correct section I would think. | 01:24 |
blueCmd | olofk: sounds like a good idea | 01:24 |
olofk | The GNU toolchain seems to be notoriously bad at providing libraries for their tools | 01:25 |
blueCmd | hm perhaps bfd contains what you're after. all binutils share things via "binary file descriptor"-thing. it seems that there is a thing called libbfd | 01:26 |
olofk | Hmm.. that could be worth a look | 01:26 |
olofk | Hey, it's Christmas eve here now. Merry christmas to everyone in the GMT+[1:] timezones who celebrate christmas eve | 01:29 |
olofk | All you others will have to wait | 01:29 |
blueCmd | olofk: indeed, merry xmas to you too! | 01:36 |
* blueCmd chuckled at the 1: | 01:36 | |
olofk | Oh well. Time for bed. orpsocv3's elf loader will have to wait another day | 01:46 |
_franck_ | olofk: for new SPR, on GDB side, you won't change anything. | 10:23 |
_franck_ | but you would have to recompile your GDB server (because the XML file doesn't know the new SPR address) | 10:24 |
_franck_ | I'm thinking of adding a TCL command to openocd to add SPR register definition at run time | 10:25 |
_franck_ | for now, the XML is generated dynamicaly from the openocd register list. So adding a register a run time will do the trick | 10:26 |
olofk | What's the syntax for adding a register? Still a bit green on the openocd side | 11:23 |
_franck_ | well for now, on the current openocd version there is no such a feature | 11:31 |
olofk | ah.. | 11:34 |
olofk | I noticed the problem when I tried to add support for the version registers in the new arch spec | 11:35 |
_franck_ | however, you can use openocd "readspr" command from the telnet console | 11:42 |
_franck_ | see or1k.c | 11:43 |
olofk | Hmm.. IIRC correctly, readspr refused to read registers that weren't defined. Is that changed? | 11:44 |
_franck_ | don't know never used or looked at the code | 11:44 |
_franck_ | a quick look at the code let me think if it's not in the reglist it read it from the hardware | 11:45 |
olofk | I have to investigate that again | 11:45 |
olofk | Stupid C question... what's the best way to call an external program? I want to call or1k-elf-objcopy to convert a elf to a bin | 13:35 |
jeremybennett | olofk: How do you mean - from within another program? | 13:43 |
jeremybennett | You can use the system(3) call. But it sounds more like you should be linking in the BFD library and using the API directly. | 13:44 |
olofk | jeremybennett: Yes, using the API directly would be better in the long run, but I'm doing a quick and dirty fix now so that I can do a proper release | 13:53 |
olofk | It would actually be nice in a way to avoid using both BFD and objcopy directly, since that would be the only dependency on the toolchain | 13:54 |
jeremybennett | OK - use the system(3) call. If you want to convert between file formats, you are going to have to use something that knows about the file formats, so you are stuck with the tool chain one way or another! | 13:55 |
olofk | Yes, the alternative would be to include a static copy of something, but that has it's own set of problems | 13:56 |
olofk | jeremybennett: Are you planning to go the dvclub thing? It seemed to be right up your alley | 13:56 |
jeremybennett | Yes we are heavily involved with both Wilson Snyder and Atmel. | 14:02 |
jeremybennett | I hope it will encourage more people to pay for commercial Verilator support. | 14:02 |
olofk | Indeed | 14:02 |
jeremybennett | You may have noticed my name on one or two recent Verilator patches. It has been my main piece of work this year. | 14:03 |
olofk | Ahh.. I knew that you were interested in verilator, but I didn't know you were an actibe contributor | 14:03 |
olofk | I'm thinking of taking a trip over there. Looks like a good place to meet some interesting people. I saw that people from TVS will be there too. I remember you talked about them during my orpsoc presentation | 14:05 |
olofk | It turns out to be completely impossible to google for TVS. :) | 14:07 |
olofk | Is this the right TVS? http://testandverification.com/ | 14:09 |
olofk | I had to search for "tvs -tv -television -televisions" to find relevant results :) | 14:09 |
jeremybennett | that's them | 14:09 |
olofk | Oh well. Time for christmas lunch with the family. Apparently that's more important than ORPSoC ;) | 14:11 |
jeremybennett | happy christmas | 14:12 |
olofk | Same to you. Make sure to include checksums on all your christmas gifts to avoid packet loss | 14:14 |
jeremybennett | :) | 14:28 |
stekern | heh, good one | 14:33 |
stekern | merry christmas all | 14:34 |
olofk | alright! orpsocv3 got an ELF loader for the RTL simulators now | 22:32 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!