Loke_ | Hello | 12:56 |
---|---|---|
Loke_ | Has anyone here been working with the development version of the newlib toolchain? | 12:58 |
juliusb | Loke_: I've been using it, sure | 13:28 |
Loke_ | I'm having a problem compiling with it | 13:29 |
Loke_ | I have the following error: | 13:29 |
Loke_ | crt0.S:256: Error: unrecognized keyword/register name `l.sw 0x78(r1),r32' | 13:30 |
Loke_ | crt0.S:291: Error: unrecognized keyword/register name `l.lwz r32,0x78(r1)' | 13:30 |
Loke_ | I don't understand why the stable version would accept that r32 register, but the development won't | 13:31 |
Loke_ | If I just comment that two lines, then the problem I get is the loader saying that it cannot represent the or32 machine | 13:32 |
Loke_ | Do you have any clue as why that error? | 13:32 |
LoneTech | both sound like the toolchain is confused about what architecture it's working on (first as then ld) | 13:36 |
LoneTech | rather odd to error out on only two lines though | 13:36 |
LoneTech | perhaps someone renamed r1 to sp instead of making it an alias? | 13:37 |
LoneTech | hang on.. where's r32 from? we only have 32 registers so end at r31. silly of me not to think of it | 13:37 |
Loke_ | yeah, that was my first thought, but I didn't write that file | 13:38 |
Loke_ | it came with the orksim | 13:38 |
LoneTech | not in the version I have. which repo did that crt0.S come from? | 13:42 |
Loke_ | i got it from here: http://opencores.org/ocsvn/openrisc/openrisc/trunk | 13:44 |
Loke_ | here is the file in question: http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2/sw/drivers/or1200/crt0.S | 13:45 |
LoneTech | ah, the orpsocv2 framework | 13:49 |
Loke_ | yes, sorry | 13:49 |
LoneTech | looks like someone simply did an off by one in creating the routine to save context for ISRs | 13:50 |
LoneTech | those two lines should not exist | 13:51 |
LoneTech | the old as simply wrapped around and used r0, which is a bug | 13:51 |
juliusb | oh yes I think that r32 error is mine :-/ | 13:52 |
LoneTech | looks like it | 13:52 |
juliusb | from a while ago, though | 13:52 |
juliusb | I've since learned OR1K only has 32 GPRs, not 33 | 13:52 |
juliusb | :) | 13:52 |
Loke_ | why would the stable version not complain? | 13:52 |
LoneTech | Loke_: because it does something along the lines of sscanf("r%d", ®no); regno&=0x1f; | 13:53 |
Loke_ | uh | 13:53 |
Loke_ | ok, so I delete them, but still get the other error :S | 13:54 |
LoneTech | quite possibly in very separate places (assembly parsing and machine code generation) | 13:54 |
LoneTech | the other error may be interesting | 13:54 |
LoneTech | juliusb: care to check in the crt0.S fix? | 13:54 |
Loke_ | probably is what you said, the toolchain being confused about the architecture... The problem is I'm still more confused :S | 13:55 |
juliusb | LoneTech: sure I'll get a chance later today | 14:51 |
_franck_ | LoneTech: could you show me again what you did in openocd (debug_entry function) to make it work (something like writing to NPC to get a pipeline flush) ? | 14:51 |
LoneTech | _franck_: it's incomplete (in that it probably is problematic at branches) but it's at http://donkey.vernier.se/~yann/openrisc-public/openocd-breakpoint-workaround.diff | 15:22 |
LoneTech | (the comments are out of date too) | 15:22 |
_franck_ | ok thanks, last time I wanted to test it, you had already removed it | 15:23 |
LoneTech | I don't think so (at least not intentionally), but the donkey container was down a while | 15:25 |
_franck_ | ah ok, must have looked at that momen.... | 15:26 |
_franck_ | *moment | 15:26 |
LoneTech | sorry | 15:26 |
_franck_ | I don't know if we should do something in the RTL about breakpoint on delay slot instruction or we should handle this in gdb | 15:29 |
_franck_ | like here: https://github.com/openrisc/or1k-src/blob/or1k/gdb/mips-tdep.c#L7157 | 15:29 |
LoneTech | my first thought would have been to follow the mips example, but we should compare complexity and duplication of effort | 15:32 |
_franck_ | I would have vote for mips way too | 15:33 |
LoneTech | yay, finally managed to run a usb program on the msp430. Just had to rewrite half the programmer. | 16:03 |
_franck_ | :) | 16:04 |
LoneTech | (goal for the moment is yet another open source jtag adapter, but more planned) | 16:06 |
LoneTech | one of the hurdles is that it seems any software from TI is broken. For instance, the bootloader everybody seemed to use doesn't work at all on my board - no clue why. | 16:08 |
stekern | isn't TI phasing out msp430 in favor of arm? | 16:27 |
stekern | at least on some rf-chips I think they are | 16:27 |
LoneTech | perhaps they are, but that sounds a bit sad to me | 16:31 |
LoneTech | the RF stuff tends to be Chipcon's radio blocks, though.. some of those with msp430 were launched fairly recently | 16:35 |
LoneTech | if anything, I'd expect them to promote the CC430 over the CC1110 | 16:38 |
LoneTech | CC2538 is a Cortex M3 device though. I guess we'll have little clues until they do EOL announcements | 16:39 |
LoneTech | so they went ARM on the ZigBee model (2530 to 2538) and MSP430 on the sub-GHz proprietary (111[10] to cc430). they have not yet replaced 8051 for the 2.5GHz proprietary (cc2510/2511). per their selection guide Q4 2012 | 16:44 |
blueCmd | regarding the Loke_-issue of r32 - it didn't complain about the TI_STACK thing in the linux kernel either, nice to uncover bugs like that :P | 16:47 |
stekern | LoneTech: ok, my knowledge is basically some heads-up at work that some chip we are using is going to switch from msp430 to cortex, but that was not zigbee | 17:04 |
stekern | more likely sub-ghz | 17:04 |
LoneTech | I see | 17:04 |
LoneTech | this chip was selected for usb, low cost (including small quantities), small size, and usb bootloader preprogrammed | 17:05 |
stekern | not involved in those projects though, I'm stuck with f2811 (among others similiar) | 17:06 |
stekern | they are a bit odd with their 16-bit chars | 17:06 |
stekern | makes porting software more interesting ;) | 17:07 |
LoneTech | not terribly surprising from a dsp | 17:07 |
LoneTech | yes, people do forget the difference between char, octet and byte | 17:07 |
LoneTech | once answered a question on that at SO.. http://stackoverflow.com/questions/6149740/size-of-byte-clarification/6149927#6149927 | 17:11 |
-!- Netsplit *.net <-> *.split quits: simoncook | 19:31 | |
-!- Netsplit over, joins: simoncook | 19:31 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!