| --- Log opened Sat Aug 09 00:00:56 2014 | ||
| Hesham | Hi, 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 |
|---|---|---|
| stekern | Hesham: yes, if the implementation have support for shadow gprfs, you can use those | 09:47 |
| stekern | mor1kx has support for that, and so do or1ksim | 09:47 |
| Hesham | These registers are different from fast context switch shadowed registers ? | 09:48 |
| Hesham | Also, 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 |
| stekern | Hesham: no, that's them | 09:58 |
| stekern | but 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 |
| Hesham | stekern: Ok, how can I access them? Are they defined in the OpenRISC architecture manual? | 09:59 |
| stekern | yes, and you can access them with mfspr/mtspr | 09:59 |
| Hesham | I only need some set of registers to hold the interrupt task context so that I can use other registers | 09:59 |
| Hesham | interrupted* task | 10:00 |
| stekern | yes, that's exactly the reason I implemented them in mor1kx | 10:00 |
| Hesham | I mean the registers addresses, are they in the manual? | 10:00 |
| stekern | yes | 10:00 |
| Hesham | GPRs mapped to SPR space ? | 10:01 |
| Hesham | GPR0-GPR511? | 10:01 |
| stekern | right | 10:01 |
| stekern | so, the shadowed are gpr32- | 10:02 |
| Hesham | Great! Thanks stekern | 10:02 |
| stekern | blueCmd_: where did you keep your memtest program? | 10:11 |
| stekern | I get weird errors when I try to use >= 512MB on my sockit board | 10:11 |
| stekern | nvm, I found it | 11:15 |
| Hesham | stekern: 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 |
| stekern | you can write to them | 12:25 |
| stekern | and GPR0-GPR31 contains the actual values of GPR0-GPR31 | 12:25 |
| stekern | you shouldn't read/write the *current* register file with the mtspr/mfspr though | 12:26 |
| stekern | the behaviour of that is undefined by the spec | 12:26 |
| stekern | not from within the CPU that is, from the debug port you can | 12:27 |
| stekern | it's the same with npcr, you shouldn't read that neither from the cpu | 12:27 |
| Hesham | So, what if I want to hold the interrupted stack context in these registers static (for later restore)? and touch any r1-r31 from exception context | 12:28 |
| Hesham | is that possible? | 12:28 |
| Hesham | I am doing the following: | 12:31 |
| Hesham | 1- Upon entering exceptions, move r1-r31 to GPR1-GPR32. | 12:31 |
| Hesham | 2- Switch to dedicated SW stack, allocate CPU Context frame, populate it with the interrupted task context (r1 from GPR1) | 12:31 |
| Hesham | 3- Jump to user C handler. | 12:31 |
| Hesham | 4- After return of the C handler, restore the context (from GPR0-GPR31?) | 12:31 |
| Hesham | The 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 stack | 12:33 |
| stekern | why would you move r1-r31 to GPR1-GPR31, they are the same thing? | 12:34 |
| Hesham | That's what I misunderstood, I thought I can use GPR1-GPRX freely to hold any general purpose value that I want. | 12:36 |
| Hesham | How do you use GPR0-GPR31 from exception context? | 12:37 |
| stekern | no, 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 |
| stekern | context 1 is GPR32-GPR63 | 12:37 |
| stekern | *that* you can use freely as scratch regs | 12:37 |
| Hesham | And are they supported on or1ksim? | 12:38 |
| stekern | ...but to be honest, I'm not sure you really need that in rtems? | 12:38 |
| stekern | yes, you can read and write to GPR32-GPR63 in or1ksim | 12:38 |
| Hesham | Restoring the context from scratch registers would be faster than accessing the stack, right? | 12:39 |
| stekern | probably | 12:40 |
| stekern | but you limit yourself to implementations that have support for the shadowed gprs | 12:41 |
| Hesham | Are not all implementations have at least context 1 shadowed gprs? | 12:42 |
| stekern | no | 12:42 |
| stekern | or1200 don't for instance | 12:42 |
| stekern | and, in mor1kx it's optional | 12:42 |
| Hesham | I see, so I will have to store the context to the stack as I did before. | 12:43 |
| blueCmd_ | stekern: https://github.com/bluecmd/mexiko/blob/master/src/bootrom/mem_stress.S | 14:42 |
| * blueCmd_ only reads hilights so you probably already found it | 14:42 | |
| blueCmd_ | yep, you did | 14:43 |
| stekern | yup, and I have some minor patches for it too ;) | 14:46 |
| stekern | like, a define for MEM_START | 14:47 |
| stekern | because, I want to run it from mem | 14:47 |
| stekern | ah, right, you only read highlights | 14:55 |
| stekern | blueCmd_: ^ | 14:55 |
| --- Log closed Sun Aug 10 00:00:58 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!