IRC logs for #openrisc Monday, 2013-02-18

Loke_Hello12:56
Loke_Has anyone here been working with the development version of the newlib toolchain?12:58
juliusbLoke_: I've been using it, sure13:28
Loke_I'm having a problem compiling with it13: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't13:31
Loke_If I just comment that two lines, then the problem I get is the loader saying that it cannot represent the or32 machine13:32
Loke_Do you have any clue as why that error?13:32
LoneTechboth sound like the toolchain is confused about what architecture it's working on (first as then ld)13:36
LoneTechrather odd to error out on only two lines though13:36
LoneTechperhaps someone renamed r1 to sp instead of making it an alias?13:37
LoneTechhang on.. where's r32 from? we only have 32 registers so end at r31. silly of me not to think of it13:37
Loke_yeah, that was my first thought, but I didn't write that file13:38
Loke_it came with the orksim13:38
LoneTechnot 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/trunk13:44
Loke_here is the file in question: http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2/sw/drivers/or1200/crt0.S13:45
LoneTechah, the orpsocv2 framework13:49
Loke_yes, sorry13:49
LoneTechlooks like someone simply did an off by one in creating the routine to save context for ISRs13:50
LoneTechthose two lines should not exist13:51
LoneTechthe old as simply wrapped around and used r0, which is a bug13:51
juliusboh yes I think that r32 error is mine :-/13:52
LoneTechlooks like it13:52
juliusbfrom a while ago, though13:52
juliusbI've since learned OR1K only has 32 GPRs, not 3313:52
juliusb:)13:52
Loke_why would the stable version not complain?13:52
LoneTechLoke_: because it does something along the lines of sscanf("r%d", &regno); regno&=0x1f;13:53
Loke_uh13:53
Loke_ok, so I delete them, but still get the other error :S13:54
LoneTechquite possibly in very separate places (assembly parsing and machine code generation)13:54
LoneTechthe other error may be interesting13:54
LoneTechjuliusb: 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 :S13:55
juliusbLoneTech: sure I'll get a chance later today14: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.diff15: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 it15:23
LoneTechI don't think so (at least not intentionally), but the donkey container was down a while15:25
_franck_ah ok, must have looked at that momen....15:26
_franck_*moment15:26
LoneTechsorry15: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 gdb15:29
_franck_like here: https://github.com/openrisc/or1k-src/blob/or1k/gdb/mips-tdep.c#L715715:29
LoneTechmy first thought would have been to follow the mips example, but we should compare complexity and duplication of effort15:32
_franck_I would have vote for mips way too15:33
LoneTechyay, 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
LoneTechone 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
stekernisn't TI phasing out msp430 in favor of arm?16:27
stekernat least on some rf-chips I think they are16:27
LoneTechperhaps they are, but that sounds a bit sad to me16:31
LoneTechthe RF stuff tends to be Chipcon's radio blocks, though.. some of those with msp430 were launched fairly recently16:35
LoneTechif anything, I'd expect them to promote the CC430 over the CC111016:38
LoneTechCC2538 is a Cortex M3 device though. I guess we'll have little clues until they do EOL announcements16:39
LoneTechso 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 201216:44
blueCmdregarding 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 :P16:47
stekernLoneTech: 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 zigbee17:04
stekernmore likely sub-ghz17:04
LoneTechI see17:04
LoneTechthis chip was selected for usb, low cost (including small quantities), small size, and usb bootloader preprogrammed17:05
stekernnot involved in those projects though, I'm stuck with f2811 (among others similiar)17:06
stekernthey are a bit odd with their 16-bit chars17:06
stekernmakes porting software more interesting ;)17:07
LoneTechnot terribly surprising from a dsp17:07
LoneTechyes, people do forget the difference between char, octet and byte17:07
LoneTechonce answered a question on that at SO.. http://stackoverflow.com/questions/6149740/size-of-byte-clarification/6149927#614992717:11
-!- Netsplit *.net <-> *.split quits: simoncook19:31
-!- Netsplit over, joins: simoncook19:31

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!