IRC logs for #openrisc Saturday, 2014-08-09

--- Log opened Sat Aug 09 00:00:56 2014
HeshamHi, is there a set of registers (other than GPRs) that I can use from exception handler. Instead of pushing/poping GPRs to/from the stack?09:38
stekernHesham: yes, if the implementation have support for shadow gprfs, you can use those09:47
stekernmor1kx has support for that, and so do or1ksim09:47
HeshamThese registers are different from fast context switch shadowed registers ?09:48
HeshamAlso, in which group can I access these registers? And are there any special instruction to load GPRs into these shadowed registers, or I would have to do it with l.mtfspr instructions ?09:51
stekernHesham: no, that's them09:58
stekernbut mor1kx doesn't have support for all the stuff that is covered in the fast context switch (yet), *but* it does have access to the shadowed gprs (if you configure it to have it)09:59
Heshamstekern: Ok, how can I access them? Are they defined in the OpenRISC architecture manual?09:59
stekernyes, and you can access them with mfspr/mtspr09:59
HeshamI only need some set of registers to hold the interrupt task context so that I can use other registers09:59
Heshaminterrupted* task10:00
stekernyes, that's exactly the reason I implemented them in mor1kx10:00
HeshamI mean the registers addresses, are they in the manual?10:00
HeshamGPRs mapped to SPR space ?10:01
stekernso, the shadowed are gpr32-10:02
HeshamGreat! Thanks stekern10:02
stekernblueCmd_: where did you keep your memtest program?10:11
stekernI get weird errors when I try to use >= 512MB on my sockit board10:11
stekernnvm, I found it11:15
Heshamstekern: I think I misunderstood how to use GPR0-GPR511. Are they read-only? Meaning that I can not right to them? Also, is any value change in a general purpose register is automatically mirrored to these mapped SPRs?12:22
stekernyou can write to them12:25
stekernand GPR0-GPR31 contains the actual values of GPR0-GPR3112:25
stekernyou shouldn't read/write the *current* register file with the mtspr/mfspr though12:26
stekernthe behaviour of that is undefined by the spec12:26
stekernnot from within the CPU that is, from the debug port you can12:27
stekernit's the same with npcr, you shouldn't read that neither from the cpu12:27
HeshamSo, what if I want to hold the interrupted stack context in these registers static (for later restore)? and touch any r1-r31 from exception context12:28
Heshamis that possible?12:28
HeshamI am doing the following:12:31
Hesham1- Upon entering exceptions, move r1-r31 to GPR1-GPR32.12:31
Hesham2- Switch to dedicated SW stack, allocate CPU Context frame, populate it with the interrupted task context (r1 from GPR1)12:31
Hesham3- Jump to user C handler.12:31
Hesham4- After return of the C handler, restore the context (from GPR0-GPR31?)12:31
HeshamThe thing is, when switching to the interrupt SW stack, I have to modify r1. Then after allocating a CPU Context frame, I want to save the original r1 value of the interrupted task, and not the new SW interrupt stack12:33
stekernwhy would you move r1-r31 to GPR1-GPR31, they are the same thing?12:34
HeshamThat's what I misunderstood, I thought I can use GPR1-GPRX freely to hold any general purpose value that I want.12:36
HeshamHow do you use GPR0-GPR31 from exception context?12:37
stekernno, you are misunderstanding the address space, GPR1-GPR31 == r1-r31 (in context 0, but since there's no support for other contexts in mor1kx, it's always context 0)12:37
stekerncontext 1 is GPR32-GPR6312:37
stekern*that* you can use freely as scratch regs12:37
HeshamAnd are they supported on or1ksim?12:38
stekern...but to be honest, I'm not sure you really need that in rtems?12:38
stekernyes, you can read and write to GPR32-GPR63 in or1ksim12:38
HeshamRestoring the context from scratch registers would be faster than accessing the stack, right?12:39
stekernbut you limit yourself to implementations that have support for the shadowed gprs12:41
HeshamAre not all implementations have at least context 1 shadowed gprs?12:42
stekernor1200 don't for instance12:42
stekernand, in mor1kx it's optional12:42
HeshamI see, so I will have to store the context to the stack as I did before.12:43
* blueCmd_ only reads hilights so you probably already found it14:42
blueCmd_yep, you did14:43
stekernyup, and I have some minor patches for it too ;)14:46
stekernlike, a define for MEM_START14:47
stekernbecause, I want to run it from mem14:47
stekernah, right, you only read highlights14:55
stekernblueCmd_: ^14:55
--- Log closed Sun Aug 10 00:00:58 2014

Generated by 2.15.2 by Marius Gedminas - find it at!