IRC logs for #openrisc Wednesday, 2012-10-24

ConXHello all! Is there a way to "watch" a special register value through adv_jtag_bridge?10:18
jeremybennettConX: I've not used the adv_tag_bridge, but I know the Igor Mohor debug unit provides hardware support for watching registers.10:37
jeremybennettadv_jtag_bridge is supposed to be an improved debug interface (not sure which debug unit it uses), so I would hope it provides that support as well.10:38
stekerndoes the watch feature work?10:44
stekernIIRC nathan yawn has some notes about patches for that to or1200 that never got applied10:45
stekernand more importantly, does it work on SPRs, as ConX asked for?10:45
jeremybennettstekern: Good point. IIRC it does work in Or1ksim :)11:06
ConXthank you guys I will try to contact Nathan!11:36
ConXanother question that I am sure you can answer is about SPR itself. I want to store a counter to a register that will not change during execution of my firmware. That's the reason I thought a "reserved for future use" SPR will do what I need. Am I right so far?11:39
jeremybennettConX: The risk you have is that in the future that SPR will be used. At that point your program will stop working. Why do you want to hold a value in a register specifically?11:50
ConXand not in RAM?11:51
ConXthat's a application specific constraint11:52
ConXcould I instruct gcc not to use an r# register instead?11:53
ConXthe code that will use that register will be written in assemlbly and I just don't want the C compiler to use it when it compiles the firmware11:55
LoneTechit's possible, but not necessarily reliable (declaring a global variable fixed to a register)11:56
ConXin the current version of or1k the first "reserved for future use" register group is 12 which means to access it I must run l.mfspr with what arguments?11:57
LoneTechthe group is a certain set of bits in the SPR address. most SPR addresses are simply unimplemented11:58
jeremybennettConX: I'm trying to think of an application specific constraint that requires a value to be held in a register, not in RAM. The reason it is not easy to do, is that people generally don't have it as a constraint.11:58
LoneTechjeremybennett: my first thought was extreme low latency interrupts, at which point you'd use fast contexts to get a separate GPR file.11:59
jeremybennettusually the constraints are that the program must meet certain performance requirements, or that you must access a particular memory location in a particular way (e.g. the "volatile" keyword).11:59
jeremybennettLoneTech: That is possible - has anyone ever implemented the context stuff?12:00
LoneTechmy scenario is all the less probable considering the OR1200's code fetch performance12:00
LoneTechI have, but it's not yet published (needs some arch changes and wanted to finish sample code, perhaps ecos based)12:01
LoneTechas is, the spec has conflicting information on how they should be implemented12:01
ConXjeremybennett: it's an implementation of a fault tolerant technique against soft errors which in case I use put that counter in RAM I will have a SPOF12:02
LoneTechwhoa. the parallella uses a zynq, that alone makes it a darn nicely priced board12:05
jeremybennettConX: Interesting - something unusual, so stretching the language support.12:06
jeremybennettLoneTech: Indeed so12:06
jeremybennettConX: In that case, I think you are right to consider the SPRs. I suggest you choose the next block. If your work proves successful, then you can make the case for the architecture to be updated to reserve this block for fault-tolerance implemenatations.12:07
jeremybennettLoneTech: It's a shame that Parallella isn't going to quite make it. I think they'll hit $500k by Saturday, but not $750k. I'm not sure what Kickstarter rules then allow them to do.12:08
ConXjeremybennett: as I am not very familiar with writing assembly, to do so a "l.mtspr r0, r3, SPR_CHCR" would work? (where SPR_CHCR is 0x6000)?12:10
LoneTechConX: once that register exists, yes12:10
ConXoups! so I have to implemented on hardware first?12:11
LoneTechor the simulator. like I said, undefined SPRs are absent, not simply unused12:11
LoneTechyou could as a proof of concept reuse a register not otherwise used, like the MACHI/MACLO registers if the MAC is implemented12:12
ConX:) Thank you guys! you made me understand what I have to do now12:13
LoneTechcome to think of it, I think or1ksim may actually implement the SPR space as a RAM, so they would exist there12:13
LoneTechjeremybennett: I think a Zynq board alone at the pricepoint would have sold. But it's a very short time frame now, and I guess they haven't decided to publish the interface RTL?12:15
jeremybennettLoneTech: I guess not.12:16
jeremybennettConX: I think LoneTech is probably right about Or1ksim. The SPR space is just a 64 kword array, so you should be able to just use the SPR.12:16
jeremybennett(that's from memory - I haven't looked at the code for a long time)12:17
LoneTechbtw, I think the easiest extension to the Epiphany architecture for wider use would be processor groups. say group 0 can access any processor, but other processors can only access their own group. Then map them in an MMU and you have a simple memory protection scheme for sharing large numbers of processors among users.12:19
ConXI am working with OR1200 on FPGA12:20
ConXso l.mfspr r0, r3, 0x6000 is a correct syntax to load the value of my SPR to register r3?12:22
ConXI meant "l.mfspr r3, r0, 0x6000"12:23
LoneTechyep, for instance (from orpsocv2/sw/tests/or1200/sim/or1200-except.S): l.mfspr r3,r0,SPR_EPCR_BASE     /* Get EPC */12:24
--- Log closed Wed Oct 24 17:26:33 2012
--- Log opened Wed Oct 24 17:26:50 2012
-!- Irssi: #openrisc: Total of 22 nicks [0 ops, 0 halfops, 0 voices, 22 normal]17:26
-!- Irssi: Join to #openrisc was synced in 22 secs17:27
-!- Netsplit *.net <-> *.split quits: heroux19:08
-!- Netsplit over, joins: heroux19:08

Generated by 2.15.2 by Marius Gedminas - find it at!