pussuw commented on PR #5985: URL: https://github.com/apache/incubator-nuttx/pull/5985#issuecomment-1089176386
> > > but all arch call the chip specific setintstack macro setup the interrupt stack. It work very well, do you have any problem with it? > > > > > > I'm not sure what this "setintstack" macro does, can you provide and example of what you mean ? > > Here is an example: https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/cxd56xx/chip.h#L52-L69 > > > For RISC-V, riscv_exception_common.S defines 1 interrupt stack per CPU: ` .skip (((CONFIG_ARCH_INTERRUPTSTACK * IRQ_NSTACKS) + 8) & ~15)` > > And every exception its location is calculated again: > > ``` > > #if CONFIG_ARCH_INTERRUPTSTACK > 15 > > /* Load mhartid (cpuid) */ > > > > csrr s0, mhartid > > > > /* Switch to interrupt stack */ > > #if IRQ_NSTACKS > 1 > > li t0, (CONFIG_ARCH_INTERRUPTSTACK & ~15) > > mul t0, s0, t0 > > la s0, g_intstacktop > > sub sp, s0, t0 > > #else > > la sp, g_intstacktop > > #endif > > > > #endif > > ``` > > > > > > > > > > > > > > > > > > > > > > > > My idea was to pre-calculate the location of the IRQ stack per hart and use the riscv_percpu.c structure and [m/s]scratch register for this. However, for it to work, you need to call riscv_percpu_add_hart to register the hart there. Only MPFS does this now. > > My question was, is it OK to force registering for other RISC-V targets too or should I do the wrapper. > > Basically, you can provide setintstack to do what you describe above. I see, I wanted to store access to the interrupt stack directly to the scratch register, but for this someone would have to set the scratch register. With flat mode the macro should work, with S-mode reading mhartid fails, so I don't see a way to calculate the index for g_cpu_intstack_top. But maybe I can make uintptr_t riscv_irqstack(void) into an asm macro instead. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
