Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

Hello,

On Sat, Jan 14, 2017 at 12:29:32PM +0800, Jia Liu wrote:
> Hi all,
> 
> On Sat, Jan 14, 2017 at 6:02 AM, Stafford Horne <shorne@gmail.com> wrote:
> > Hello,
> >
> > Sorry for the duplicate. There was an issue with my copy to qemu-devel
> > group.  Resent to everyone with proper cc to qemu-devel.
> >
> > Please ignore this one.
> >
> > -Stafford
> >
> > On Sat, Jan 14, 2017 at 06:57:20AM +0900, Stafford Horne wrote:
> >> I am working on testing instruction emulation patches for the linux
> >> kernel. During testing I found these 2 issues:
> >>
> >>  - sets DSX (delay slot exception) but never clears it
> >>  - EEAR for illegal insns should point to the bad exception (as per
> >>    openrisc spec) but its not
> >>
> >> This patch fixes these two issues by clearing the DSX flag when not in a
> >> delay slot and by setting EEAR to exception PC when handling illegal
> >> instruction exceptions.
> >>
> >> After this patch the openrisc kernel with latest patches boots great on
> >> qemu and instruction emulation works.
> >>
> >> Cc: qemu-trivial@nongnu.org
> >> Cc: openrisc@lists.librecores.org
> >> Signed-off-by: Stafford Horne <shorne@gmail.com>
> >> ---
> >>  target/openrisc/interrupt.c | 7 +++++++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/target/openrisc/interrupt.c b/target/openrisc/interrupt.c
> >> index 5fe3f11..e1b0142 100644
> >> --- a/target/openrisc/interrupt.c
> >> +++ b/target/openrisc/interrupt.c
> >> @@ -38,10 +38,17 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
> >>          env->flags &= ~D_FLAG;
> >>          env->sr |= SR_DSX;
> >>          env->epcr -= 4;
> >> +    } else {
> >> +        env->sr &= ~SR_DSX;
> >>      }
> >>      if (cs->exception_index == EXCP_SYSCALL) {
> >>          env->epcr += 4;
> >>      }
> >> +    /* When we have an illegal instruction the error effective address
> >> +       shall be set to the illegal instruction address.  */
> >> +    if (cs->exception_index == EXCP_ILLEGAL) {
> >> +        env->eear = env->pc;
> >> +    }
> >>
> >>      /* For machine-state changed between user-mode and supervisor mode,
> >>         we need flush TLB when we enter&exit EXCP.  */
> 
> Anyone wanna take the openrisc job in QEMU?
> Will you Stafford?
> I really don't have time working on it.

I don't mind watching the the mailing list and collecting patchs and
sending pull requests for openrisc.

But if anyone is more willing to take over the role I would not step in
their way.  I only have a few days experience with the qemu code base.
But I do think its very nice :)

I think I would need my key signed, do you know anyone in Japan?

> And, this is the lwa&swa support.
> It also make latest Linux boot.

Thanks, I know about these patches from Sebastian.  In my case I
explicity wanted to fix the illegal instruction handling logic as I am
testing the instruction emulation patch for lwa/swa which I am preparing
for the next kernel merge window.  (I am currently the Linux openrisc
maintainer)

I think the l.swa and l.lwa support should go in too. I have tested
those instructions on fpga and the or1ksim simulator.

-Stafford

> diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
> index 155913f..e6f6186 100644
> --- a/target-openrisc/cpu.c
> +++ b/target-openrisc/cpu.c
> @@ -55,6 +55,7 @@ static void openrisc_cpu_reset(CPUState *s)
>  
>      cpu->env.pc = 0x100;
>      cpu->env.sr = SR_FO | SR_SM;
> +    cpu->env.lock_addr = -1;
>      s->exception_index = -1;
>  
>      cpu->env.upr = UPR_UP | UPR_DMP | UPR_IMP | UPR_PICP | UPR_TTP;
> diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
> index aaf1535..d64c54f 100644
> --- a/target-openrisc/cpu.h
> +++ b/target-openrisc/cpu.h
> @@ -296,6 +296,9 @@ typedef struct CPUOpenRISCState {
>      uint32_t fpcsr;           /* Float register */
>      float_status fp_status;
>  
> +    target_ulong lock_addr;
> +    target_ulong lock_value;
> +
>      uint32_t flags;           /* cpu_flags, we only use it for exception
>                                   in solt so far.  */
>      uint32_t btaken;          /* the SR_F bit */
> diff --git a/target-openrisc/interrupt.c b/target-openrisc/interrupt.c
> index 5fe3f11..2c4f452 100644
> --- a/target-openrisc/interrupt.c
> +++ b/target-openrisc/interrupt.c
> @@ -55,6 +55,7 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
>      env->sr &= ~SR_TEE;
>      env->tlb->cpu_openrisc_map_address_data = &cpu_openrisc_get_phys_nommu;
>      env->tlb->cpu_openrisc_map_address_code = &cpu_openrisc_get_phys_nommu;
> +    env->lock_addr = -1;
>  
>      if (cs->exception_index > 0 && cs->exception_index < EXCP_NR) {
>          env->pc = (cs->exception_index << 8);
> diff --git a/target-openrisc/interrupt_helper.c b/target-openrisc/interrupt_helper.c
> index 116f9109..a1d3a9b 100644
> --- a/target-openrisc/interrupt_helper.c
> +++ b/target-openrisc/interrupt_helper.c
> @@ -34,6 +34,7 @@ void HELPER(rfe)(CPUOpenRISCState *env)
>      cpu->env.pc = cpu->env.epcr;
>      cpu->env.npc = cpu->env.epcr;
>      cpu->env.sr = cpu->env.esr;
> +    cpu->env.lock_addr = -1;
>  
>  #ifndef CONFIG_USER_ONLY
>      if (cpu->env.sr & SR_DME) {
> diff --git a/target-openrisc/mmu.c b/target-openrisc/mmu.c
> index 505dcdc..56b11d3 100644
> --- a/target-openrisc/mmu.c
> +++ b/target-openrisc/mmu.c
> @@ -174,6 +174,7 @@ static void cpu_openrisc_raise_mmu_exception(OpenRISCCPU *cpu,
>  
>      cs->exception_index = exception;
>      cpu->env.eear = address;
> +    cpu->env.lock_addr = -1;
>  }
>  
>  #ifndef CONFIG_USER_ONLY
> diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
> index 28c9446..1185a00 100644
> --- a/target-openrisc/translate.c
> +++ b/target-openrisc/translate.c
> @@ -61,6 +61,8 @@ static TCGv jmp_pc;            /* l.jr/l.jalr temp pc */
>  static TCGv cpu_npc;
>  static TCGv cpu_ppc;
>  static TCGv_i32 env_btaken;    /* bf/bnf , F flag taken */
> +static TCGv cpu_lock_addr;
> +static TCGv cpu_lock_value;
>  static TCGv_i32 fpcsr;
>  static TCGv machi, maclo;
>  static TCGv fpmaddhi, fpmaddlo;
> @@ -95,6 +97,12 @@ void openrisc_translate_init(void)
>      env_btaken = tcg_global_mem_new_i32(cpu_env,
>                                          offsetof(CPUOpenRISCState, btaken),
>                                          "btaken");
> +    cpu_lock_addr = tcg_global_mem_new(cpu_env,
> +                                       offsetof(CPUOpenRISCState, lock_addr),
> +                                       "lock_addr");
> +    cpu_lock_value = tcg_global_mem_new(cpu_env,
> +                                        offsetof(CPUOpenRISCState, lock_value),
> +                                        "lock_value");
>      fpcsr = tcg_global_mem_new_i32(cpu_env,
>                                     offsetof(CPUOpenRISCState, fpcsr),
>                                     "fpcsr");
> @@ -264,6 +272,44 @@ static void gen_jump(DisasContext *dc, uint32_t imm, uint32_t reg, uint32_t op0)
>      gen_sync_flags(dc);
>  }
>  
> +static void gen_lwa(DisasContext *dc, TCGv rd, TCGv ra, int32_t ofs)
> +{
> +    TCGv ea = tcg_temp_new();
> +
> +    tcg_gen_addi_tl(ea, ra, ofs);
> +    tcg_gen_qemu_ld_tl(rd, ea, dc->mem_idx, MO_TEUL);
> +    tcg_gen_mov_tl(cpu_lock_addr, ea);
> +    tcg_gen_mov_tl(cpu_lock_value, rd);
> +    tcg_temp_free(ea);
> +}
> +
> +static void gen_swa(DisasContext *dc, TCGv rb, TCGv ra, int32_t ofs)
> +{
> +    TCGv ea, val;
> +    TCGLabel *lab_fail, *lab_done;
> +
> +    ea = tcg_temp_new();
> +    tcg_gen_addi_tl(ea, ra, ofs);
> +
> +    lab_fail = gen_new_label();
> +    lab_done = gen_new_label();
> +    tcg_gen_brcond_tl(TCG_COND_NE, ea, cpu_lock_addr, lab_fail);
> +    tcg_temp_free(ea);
> +
> +    val = tcg_temp_new();
> +    tcg_gen_qemu_ld_tl(val, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> +    tcg_gen_brcond_tl(TCG_COND_NE, val, cpu_lock_value, lab_fail);
> +
> +    tcg_gen_qemu_st_tl(rb, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> +    tcg_gen_movi_i32(env_btaken, 0x1);
> +    tcg_gen_br(lab_done);
> +
> +    gen_set_label(lab_fail);
> +    tcg_gen_movi_i32(env_btaken, 0x0);
> +
> +    gen_set_label(lab_done);
> +    tcg_gen_movi_tl(cpu_lock_addr, -1);
> +}
>  
>  static void dec_calc(DisasContext *dc, uint32_t insn)
>  {
> @@ -858,6 +904,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
>          goto do_load;
>  #endif*/
>  
> +    case 0x1b: /* l.lwa */
> +        LOG_DIS("l.lwa r%d, r%d, %d\n", rd, ra, I16);
> +        gen_lwa(dc, cpu_R[rd], cpu_R[ra], I16);
> +        break;
> +
>      case 0x21:    /* l.lwz */
>          LOG_DIS("l.lwz r%d, r%d, %d\n", rd, ra, I16);
>          mop = MO_TEUL;
> @@ -1036,6 +1087,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
>          goto do_store;
>  #endif*/
>  
> +    case 0x33: /* l.swa */
> +        LOG_DIS("l.swa r%d, r%d, %d\n", ra, rb, I16);
> +        gen_swa(dc, cpu_R[rb], cpu_R[ra], sign_extend(tmp, 16));
> +        break;
> +
>      case 0x35:    /* l.sw */
>          LOG_DIS("l.sw %d, r%d, r%d, %d\n", I5, ra, rb, I11);
>          mop = MO_TEUL;

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

(+CC Rth)

I believe you also have some experience with openrisc.  Any thought on
the below?

On Sat, Jan 14, 2017 at 05:04:35PM +0900, Stafford Horne wrote:
> Hello,
> 
> On Sat, Jan 14, 2017 at 12:29:32PM +0800, Jia Liu wrote:
> > Hi all,
> > 
> > On Sat, Jan 14, 2017 at 6:02 AM, Stafford Horne <shorne@gmail.com> wrote:
> > > Hello,
> > >
> > > Sorry for the duplicate. There was an issue with my copy to qemu-devel
> > > group.  Resent to everyone with proper cc to qemu-devel.
> > >
> > > Please ignore this one.
> > >
> > > -Stafford
> > >
> > > On Sat, Jan 14, 2017 at 06:57:20AM +0900, Stafford Horne wrote:
> > >> I am working on testing instruction emulation patches for the linux
> > >> kernel. During testing I found these 2 issues:
> > >>
> > >>  - sets DSX (delay slot exception) but never clears it
> > >>  - EEAR for illegal insns should point to the bad exception (as per
> > >>    openrisc spec) but its not
> > >>
> > >> This patch fixes these two issues by clearing the DSX flag when not in a
> > >> delay slot and by setting EEAR to exception PC when handling illegal
> > >> instruction exceptions.
> > >>
> > >> After this patch the openrisc kernel with latest patches boots great on
> > >> qemu and instruction emulation works.
> > >>
> > >> Cc: qemu-trivial@nongnu.org
> > >> Cc: openrisc@lists.librecores.org
> > >> Signed-off-by: Stafford Horne <shorne@gmail.com>
> > >> ---
> > >>  target/openrisc/interrupt.c | 7 +++++++
> > >>  1 file changed, 7 insertions(+)
> > >>
> > >> diff --git a/target/openrisc/interrupt.c b/target/openrisc/interrupt.c
> > >> index 5fe3f11..e1b0142 100644
> > >> --- a/target/openrisc/interrupt.c
> > >> +++ b/target/openrisc/interrupt.c
> > >> @@ -38,10 +38,17 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
> > >>          env->flags &= ~D_FLAG;
> > >>          env->sr |= SR_DSX;
> > >>          env->epcr -= 4;
> > >> +    } else {
> > >> +        env->sr &= ~SR_DSX;
> > >>      }
> > >>      if (cs->exception_index == EXCP_SYSCALL) {
> > >>          env->epcr += 4;
> > >>      }
> > >> +    /* When we have an illegal instruction the error effective address
> > >> +       shall be set to the illegal instruction address.  */
> > >> +    if (cs->exception_index == EXCP_ILLEGAL) {
> > >> +        env->eear = env->pc;
> > >> +    }
> > >>
> > >>      /* For machine-state changed between user-mode and supervisor mode,
> > >>         we need flush TLB when we enter&exit EXCP.  */
> > 
> > Anyone wanna take the openrisc job in QEMU?
> > Will you Stafford?
> > I really don't have time working on it.
> 
> I don't mind watching the the mailing list and collecting patchs and
> sending pull requests for openrisc.
> 
> But if anyone is more willing to take over the role I would not step in
> their way.  I only have a few days experience with the qemu code base.
> But I do think its very nice :)
> 
> I think I would need my key signed, do you know anyone in Japan?
> 
> > And, this is the lwa&swa support.
> > It also make latest Linux boot.
> 
> Thanks, I know about these patches from Sebastian.  In my case I
> explicity wanted to fix the illegal instruction handling logic as I am
> testing the instruction emulation patch for lwa/swa which I am preparing
> for the next kernel merge window.  (I am currently the Linux openrisc
> maintainer)
> 
> I think the l.swa and l.lwa support should go in too. I have tested
> those instructions on fpga and the or1ksim simulator.
> 
> -Stafford
> 
> > diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
> > index 155913f..e6f6186 100644
> > --- a/target-openrisc/cpu.c
> > +++ b/target-openrisc/cpu.c
> > @@ -55,6 +55,7 @@ static void openrisc_cpu_reset(CPUState *s)
> >  
> >      cpu->env.pc = 0x100;
> >      cpu->env.sr = SR_FO | SR_SM;
> > +    cpu->env.lock_addr = -1;
> >      s->exception_index = -1;
> >  
> >      cpu->env.upr = UPR_UP | UPR_DMP | UPR_IMP | UPR_PICP | UPR_TTP;
> > diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
> > index aaf1535..d64c54f 100644
> > --- a/target-openrisc/cpu.h
> > +++ b/target-openrisc/cpu.h
> > @@ -296,6 +296,9 @@ typedef struct CPUOpenRISCState {
> >      uint32_t fpcsr;           /* Float register */
> >      float_status fp_status;
> >  
> > +    target_ulong lock_addr;
> > +    target_ulong lock_value;
> > +
> >      uint32_t flags;           /* cpu_flags, we only use it for exception
> >                                   in solt so far.  */
> >      uint32_t btaken;          /* the SR_F bit */
> > diff --git a/target-openrisc/interrupt.c b/target-openrisc/interrupt.c
> > index 5fe3f11..2c4f452 100644
> > --- a/target-openrisc/interrupt.c
> > +++ b/target-openrisc/interrupt.c
> > @@ -55,6 +55,7 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
> >      env->sr &= ~SR_TEE;
> >      env->tlb->cpu_openrisc_map_address_data = &cpu_openrisc_get_phys_nommu;
> >      env->tlb->cpu_openrisc_map_address_code = &cpu_openrisc_get_phys_nommu;
> > +    env->lock_addr = -1;
> >  
> >      if (cs->exception_index > 0 && cs->exception_index < EXCP_NR) {
> >          env->pc = (cs->exception_index << 8);
> > diff --git a/target-openrisc/interrupt_helper.c b/target-openrisc/interrupt_helper.c
> > index 116f9109..a1d3a9b 100644
> > --- a/target-openrisc/interrupt_helper.c
> > +++ b/target-openrisc/interrupt_helper.c
> > @@ -34,6 +34,7 @@ void HELPER(rfe)(CPUOpenRISCState *env)
> >      cpu->env.pc = cpu->env.epcr;
> >      cpu->env.npc = cpu->env.epcr;
> >      cpu->env.sr = cpu->env.esr;
> > +    cpu->env.lock_addr = -1;
> >  
> >  #ifndef CONFIG_USER_ONLY
> >      if (cpu->env.sr & SR_DME) {
> > diff --git a/target-openrisc/mmu.c b/target-openrisc/mmu.c
> > index 505dcdc..56b11d3 100644
> > --- a/target-openrisc/mmu.c
> > +++ b/target-openrisc/mmu.c
> > @@ -174,6 +174,7 @@ static void cpu_openrisc_raise_mmu_exception(OpenRISCCPU *cpu,
> >  
> >      cs->exception_index = exception;
> >      cpu->env.eear = address;
> > +    cpu->env.lock_addr = -1;
> >  }
> >  
> >  #ifndef CONFIG_USER_ONLY
> > diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
> > index 28c9446..1185a00 100644
> > --- a/target-openrisc/translate.c
> > +++ b/target-openrisc/translate.c
> > @@ -61,6 +61,8 @@ static TCGv jmp_pc;            /* l.jr/l.jalr temp pc */
> >  static TCGv cpu_npc;
> >  static TCGv cpu_ppc;
> >  static TCGv_i32 env_btaken;    /* bf/bnf , F flag taken */
> > +static TCGv cpu_lock_addr;
> > +static TCGv cpu_lock_value;
> >  static TCGv_i32 fpcsr;
> >  static TCGv machi, maclo;
> >  static TCGv fpmaddhi, fpmaddlo;
> > @@ -95,6 +97,12 @@ void openrisc_translate_init(void)
> >      env_btaken = tcg_global_mem_new_i32(cpu_env,
> >                                          offsetof(CPUOpenRISCState, btaken),
> >                                          "btaken");
> > +    cpu_lock_addr = tcg_global_mem_new(cpu_env,
> > +                                       offsetof(CPUOpenRISCState, lock_addr),
> > +                                       "lock_addr");
> > +    cpu_lock_value = tcg_global_mem_new(cpu_env,
> > +                                        offsetof(CPUOpenRISCState, lock_value),
> > +                                        "lock_value");
> >      fpcsr = tcg_global_mem_new_i32(cpu_env,
> >                                     offsetof(CPUOpenRISCState, fpcsr),
> >                                     "fpcsr");
> > @@ -264,6 +272,44 @@ static void gen_jump(DisasContext *dc, uint32_t imm, uint32_t reg, uint32_t op0)
> >      gen_sync_flags(dc);
> >  }
> >  
> > +static void gen_lwa(DisasContext *dc, TCGv rd, TCGv ra, int32_t ofs)
> > +{
> > +    TCGv ea = tcg_temp_new();
> > +
> > +    tcg_gen_addi_tl(ea, ra, ofs);
> > +    tcg_gen_qemu_ld_tl(rd, ea, dc->mem_idx, MO_TEUL);
> > +    tcg_gen_mov_tl(cpu_lock_addr, ea);
> > +    tcg_gen_mov_tl(cpu_lock_value, rd);
> > +    tcg_temp_free(ea);
> > +}
> > +
> > +static void gen_swa(DisasContext *dc, TCGv rb, TCGv ra, int32_t ofs)
> > +{
> > +    TCGv ea, val;
> > +    TCGLabel *lab_fail, *lab_done;
> > +
> > +    ea = tcg_temp_new();
> > +    tcg_gen_addi_tl(ea, ra, ofs);
> > +
> > +    lab_fail = gen_new_label();
> > +    lab_done = gen_new_label();
> > +    tcg_gen_brcond_tl(TCG_COND_NE, ea, cpu_lock_addr, lab_fail);
> > +    tcg_temp_free(ea);
> > +
> > +    val = tcg_temp_new();
> > +    tcg_gen_qemu_ld_tl(val, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> > +    tcg_gen_brcond_tl(TCG_COND_NE, val, cpu_lock_value, lab_fail);
> > +
> > +    tcg_gen_qemu_st_tl(rb, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> > +    tcg_gen_movi_i32(env_btaken, 0x1);
> > +    tcg_gen_br(lab_done);
> > +
> > +    gen_set_label(lab_fail);
> > +    tcg_gen_movi_i32(env_btaken, 0x0);
> > +
> > +    gen_set_label(lab_done);
> > +    tcg_gen_movi_tl(cpu_lock_addr, -1);
> > +}
> >  
> >  static void dec_calc(DisasContext *dc, uint32_t insn)
> >  {
> > @@ -858,6 +904,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
> >          goto do_load;
> >  #endif*/
> >  
> > +    case 0x1b: /* l.lwa */
> > +        LOG_DIS("l.lwa r%d, r%d, %d\n", rd, ra, I16);
> > +        gen_lwa(dc, cpu_R[rd], cpu_R[ra], I16);
> > +        break;
> > +
> >      case 0x21:    /* l.lwz */
> >          LOG_DIS("l.lwz r%d, r%d, %d\n", rd, ra, I16);
> >          mop = MO_TEUL;
> > @@ -1036,6 +1087,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
> >          goto do_store;
> >  #endif*/
> >  
> > +    case 0x33: /* l.swa */
> > +        LOG_DIS("l.swa r%d, r%d, %d\n", ra, rb, I16);
> > +        gen_swa(dc, cpu_R[rb], cpu_R[ra], sign_extend(tmp, 16));
> > +        break;
> > +
> >      case 0x35:    /* l.sw */
> >          LOG_DIS("l.sw %d, r%d, r%d, %d\n", I5, ra, rb, I11);
> >          mop = MO_TEUL;
> 

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 01/20/2017 08:39 AM, Stafford Horne wrote:
> (+CC Rth)
> 
> I believe you also have some experience with openrisc.  Any thought on
> the below?
> 
> On Sat, Jan 14, 2017 at 05:04:35PM +0900, Stafford Horne wrote:
>> Hello,
>>
>> On Sat, Jan 14, 2017 at 12:29:32PM +0800, Jia Liu wrote:
>>> Hi all,
>>>
>>> On Sat, Jan 14, 2017 at 6:02 AM, Stafford Horne <shorne@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Sorry for the duplicate. There was an issue with my copy to qemu-devel
>>>> group.  Resent to everyone with proper cc to qemu-devel.
>>>>
>>>> Please ignore this one.
>>>>
>>>> -Stafford
>>>>
>>>> On Sat, Jan 14, 2017 at 06:57:20AM +0900, Stafford Horne wrote:
>>>>> I am working on testing instruction emulation patches for the linux
>>>>> kernel. During testing I found these 2 issues:
>>>>>
>>>>>  - sets DSX (delay slot exception) but never clears it
>>>>>  - EEAR for illegal insns should point to the bad exception (as per
>>>>>    openrisc spec) but its not
>>>>>
>>>>> This patch fixes these two issues by clearing the DSX flag when not in a
>>>>> delay slot and by setting EEAR to exception PC when handling illegal
>>>>> instruction exceptions.
>>>>>
>>>>> After this patch the openrisc kernel with latest patches boots great on
>>>>> qemu and instruction emulation works.
>>>>>
>>>>> Cc: qemu-trivial@nongnu.org
>>>>> Cc: openrisc@lists.librecores.org
>>>>> Signed-off-by: Stafford Horne <shorne@gmail.com>
>>>>> ---
>>>>>  target/openrisc/interrupt.c | 7 +++++++
>>>>>  1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/target/openrisc/interrupt.c b/target/openrisc/interrupt.c
>>>>> index 5fe3f11..e1b0142 100644
>>>>> --- a/target/openrisc/interrupt.c
>>>>> +++ b/target/openrisc/interrupt.c
>>>>> @@ -38,10 +38,17 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
>>>>>          env->flags &= ~D_FLAG;
>>>>>          env->sr |= SR_DSX;
>>>>>          env->epcr -= 4;
>>>>> +    } else {
>>>>> +        env->sr &= ~SR_DSX;
>>>>>      }
>>>>>      if (cs->exception_index == EXCP_SYSCALL) {
>>>>>          env->epcr += 4;
>>>>>      }
>>>>> +    /* When we have an illegal instruction the error effective address
>>>>> +       shall be set to the illegal instruction address.  */
>>>>> +    if (cs->exception_index == EXCP_ILLEGAL) {
>>>>> +        env->eear = env->pc;
>>>>> +    }
>>>>>
>>>>>      /* For machine-state changed between user-mode and supervisor mode,
>>>>>         we need flush TLB when we enter&exit EXCP.  */

This patch seems sane, and I'm fine with it.  That said, I don't know what
"latest patches" means, and was not able to find a kernel version that works.

>>> +static void gen_swa(DisasContext *dc, TCGv rb, TCGv ra, int32_t ofs)
>>> +{
>>> +    TCGv ea, val;
>>> +    TCGLabel *lab_fail, *lab_done;
>>> +
>>> +    ea = tcg_temp_new();
>>> +    tcg_gen_addi_tl(ea, ra, ofs);
>>> +
>>> +    lab_fail = gen_new_label();
>>> +    lab_done = gen_new_label();
>>> +    tcg_gen_brcond_tl(TCG_COND_NE, ea, cpu_lock_addr, lab_fail);
>>> +    tcg_temp_free(ea);
>>> +
>>> +    val = tcg_temp_new();
>>> +    tcg_gen_qemu_ld_tl(val, cpu_lock_addr, dc->mem_idx, MO_TEUL);
>>> +    tcg_gen_brcond_tl(TCG_COND_NE, val, cpu_lock_value, lab_fail);
>>> +
>>> +    tcg_gen_qemu_st_tl(rb, cpu_lock_addr, dc->mem_idx, MO_TEUL);
>>> +    tcg_gen_movi_i32(env_btaken, 0x1);
>>> +    tcg_gen_br(lab_done);
>>> +
>>> +    gen_set_label(lab_fail);
>>> +    tcg_gen_movi_i32(env_btaken, 0x0);
>>> +
>>> +    gen_set_label(lab_done);
>>> +    tcg_gen_movi_tl(cpu_lock_addr, -1);
>>> +}

This one needs to be updated to work with the atomic operations now present in
TCG.  See target/alpha/translate.c, gen_store_conditional among the many examples.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Mon, Jan 23, 2017 at 10:08:47AM -0800, Richard Henderson wrote:
> On 01/20/2017 08:39 AM, Stafford Horne wrote:
> > (+CC Rth)
> > 
> > I believe you also have some experience with openrisc.  Any thought on
> > the below?
> > 
> > On Sat, Jan 14, 2017 at 05:04:35PM +0900, Stafford Horne wrote:
> >> Hello,
> >>
> >> On Sat, Jan 14, 2017 at 12:29:32PM +0800, Jia Liu wrote:
> >>> Hi all,
> >>>
> >>> On Sat, Jan 14, 2017 at 6:02 AM, Stafford Horne <shorne@gmail.com> wrote:
> >>>> Hello,
> >>>>
> >>>> Sorry for the duplicate. There was an issue with my copy to qemu-devel
> >>>> group.  Resent to everyone with proper cc to qemu-devel.
> >>>>
> >>>> Please ignore this one.
> >>>>
> >>>> -Stafford
> >>>>
> >>>> On Sat, Jan 14, 2017 at 06:57:20AM +0900, Stafford Horne wrote:
> >>>>> I am working on testing instruction emulation patches for the linux
> >>>>> kernel. During testing I found these 2 issues:
> >>>>>
> >>>>>  - sets DSX (delay slot exception) but never clears it
> >>>>>  - EEAR for illegal insns should point to the bad exception (as per
> >>>>>    openrisc spec) but its not
> >>>>>
> >>>>> This patch fixes these two issues by clearing the DSX flag when not in a
> >>>>> delay slot and by setting EEAR to exception PC when handling illegal
> >>>>> instruction exceptions.
> >>>>>
> >>>>> After this patch the openrisc kernel with latest patches boots great on
> >>>>> qemu and instruction emulation works.
> >>>>>
> >>>>> Cc: qemu-trivial@nongnu.org
> >>>>> Cc: openrisc@lists.librecores.org
> >>>>> Signed-off-by: Stafford Horne <shorne@gmail.com>
> >>>>> ---
> >>>>>  target/openrisc/interrupt.c | 7 +++++++
> >>>>>  1 file changed, 7 insertions(+)
> >>>>>
> >>>>> diff --git a/target/openrisc/interrupt.c b/target/openrisc/interrupt.c
> >>>>> index 5fe3f11..e1b0142 100644
> >>>>> --- a/target/openrisc/interrupt.c
> >>>>> +++ b/target/openrisc/interrupt.c
> >>>>> @@ -38,10 +38,17 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
> >>>>>          env->flags &= ~D_FLAG;
> >>>>>          env->sr |= SR_DSX;
> >>>>>          env->epcr -= 4;
> >>>>> +    } else {
> >>>>> +        env->sr &= ~SR_DSX;
> >>>>>      }
> >>>>>      if (cs->exception_index == EXCP_SYSCALL) {
> >>>>>          env->epcr += 4;
> >>>>>      }
> >>>>> +    /* When we have an illegal instruction the error effective address
> >>>>> +       shall be set to the illegal instruction address.  */
> >>>>> +    if (cs->exception_index == EXCP_ILLEGAL) {
> >>>>> +        env->eear = env->pc;
> >>>>> +    }
> >>>>>
> >>>>>      /* For machine-state changed between user-mode and supervisor mode,
> >>>>>         we need flush TLB when we enter&exit EXCP.  */
> 
> This patch seems sane, and I'm fine with it.  That said, I don't know what
> "latest patches" means, and was not able to find a kernel version that works.

Hi Richard,

By "latest patches", I mean the ones I posted to the lkml [1] earlier
this month and are now in linux-next.  These have actually been sitting
in the openrisc repo [2] for much longer than that though. The patches
that depend on l.swa and l.lwa (all of the atomic ones) depend on the
hardware (or emulator) being able to either:
 1. Support the l.swa/l.lwa instructions
 2. Support illegal instructions, used by emulation in patch 06/22 [3]

Qemu seems to have issues with both of these right now.  This patch will
help support illegal instructions properly.

If you are having problems booting, both mainline (4.10-rc5) and
linux-next (i.e. next-201701124) should be able to boot. i.e.

  export ARCH=openrisc
  make defconfig   # defconfig works fine on qemu

  # make any updates to CONFIG_CROSS_COMPILE needed
  make

  # start qemu
  qemu-system-or32  -cpu or1200 -M or32-sim -kernel $LINUX/vmlinux \
   -serial stdio -nographic -monitor none

I just ran those commands with linu-next and my qemu patches and the
kernel can boot, but note fails to find init due to config missing
initramfs, which I figure you know thats expected.

Let me know what you tried and what problem you are having.

> >>> +static void gen_swa(DisasContext *dc, TCGv rb, TCGv ra, int32_t ofs)
> >>> +{
> >>> +    TCGv ea, val;
> >>> +    TCGLabel *lab_fail, *lab_done;
> >>> +
> >>> +    ea = tcg_temp_new();
> >>> +    tcg_gen_addi_tl(ea, ra, ofs);
> >>> +
> >>> +    lab_fail = gen_new_label();
> >>> +    lab_done = gen_new_label();
> >>> +    tcg_gen_brcond_tl(TCG_COND_NE, ea, cpu_lock_addr, lab_fail);
> >>> +    tcg_temp_free(ea);
> >>> +
> >>> +    val = tcg_temp_new();
> >>> +    tcg_gen_qemu_ld_tl(val, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> >>> +    tcg_gen_brcond_tl(TCG_COND_NE, val, cpu_lock_value, lab_fail);
> >>> +
> >>> +    tcg_gen_qemu_st_tl(rb, cpu_lock_addr, dc->mem_idx, MO_TEUL);
> >>> +    tcg_gen_movi_i32(env_btaken, 0x1);
> >>> +    tcg_gen_br(lab_done);
> >>> +
> >>> +    gen_set_label(lab_fail);
> >>> +    tcg_gen_movi_i32(env_btaken, 0x0);
> >>> +
> >>> +    gen_set_label(lab_done);
> >>> +    tcg_gen_movi_tl(cpu_lock_addr, -1);
> >>> +}
> 
> This one needs to be updated to work with the atomic operations now present in
> TCG.  See target/alpha/translate.c, gen_store_conditional among the many examples.

I haven't looked into this patch.  I am thinking I can look at it when I
try to upstream the openrisc linux SMP patches which are sitting in the
openrisc/linux repo too.

Thanks for reviewing

-Stafford

[1] https://lkml.org/lkml/2017/1/14/263
[2] https://github.com/openrisc/linux
[3] https://lkml.org/lkml/2017/1/14/265

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 01/24/2017 02:26 AM, Stafford Horne wrote:
> If you are having problems booting, both mainline (4.10-rc5) and
> linux-next (i.e. next-201701124) should be able to boot. i.e.
> 
>   export ARCH=openrisc
>   make defconfig   # defconfig works fine on qemu
> 
>   # make any updates to CONFIG_CROSS_COMPILE needed
>   make
> 
>   # start qemu
>   qemu-system-or32  -cpu or1200 -M or32-sim -kernel $LINUX/vmlinux \
>    -serial stdio -nographic -monitor none
> 
> I just ran those commands with linu-next and my qemu patches and the
> kernel can boot, but note fails to find init due to config missing
> initramfs, which I figure you know thats expected.
> 
> Let me know what you tried and what problem you are having.

I've tried booting linux-next and mainline, both from yesterday.

According to the trace from qemu (-D z -d in_asm,exec), I execute

./or32-softmmu/qemu-system-or32 -cpu or1200 -M or32-sim \
    -kernel ~/work/linux/bld-or/vmlinux -append console=ttyS0 \
    -serial stdio -nographic -monitor none \
    -D z -d in_asm,exec,int,op_opt

...
Trace 0x7f501130a880 [0: c036c650] setup_cpuinfo
Trace 0x7f501130a990 [0: c036c65c] setup_cpuinfo
Trace 0x7f501130aaa0 [0: c0069774] panic
...
Trace 0x7f5011312b70 [0: 000001fc]
Trace 0x7f5011312b70 [0: 000001fc]

That last block repeats forever.

The qemu I'm using is

  git://github.com/rth7680/qemu.git tgt-or1k-2

which has your patch, l.lwa/swa, and a cleanup to the disassembly trace.

Looking at the kernel source I would hazard a guess that it's

>         cpu = of_find_compatible_node(NULL, NULL, "opencores,or1200-rtlsvn481");
>         if (!cpu)
>                 panic("No compatible CPU found in device tree...\n");

which suggests some large configuration error.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

On Tue, Jan 24, 2017 at 10:32:03AM -0800, Richard Henderson wrote:
> On 01/24/2017 02:26 AM, Stafford Horne wrote:
> > If you are having problems booting, both mainline (4.10-rc5) and
> > linux-next (i.e. next-201701124) should be able to boot. i.e.
> > 
> >   export ARCH=openrisc
> >   make defconfig   # defconfig works fine on qemu
> > 
> >   # make any updates to CONFIG_CROSS_COMPILE needed
> >   make
> > 
> >   # start qemu
> >   qemu-system-or32  -cpu or1200 -M or32-sim -kernel $LINUX/vmlinux \
> >    -serial stdio -nographic -monitor none
> > 
> > I just ran those commands with linu-next and my qemu patches and the
> > kernel can boot, but note fails to find init due to config missing
> > initramfs, which I figure you know thats expected.
> > 
> > Let me know what you tried and what problem you are having.
> 
> I've tried booting linux-next and mainline, both from yesterday.
> 
> According to the trace from qemu (-D z -d in_asm,exec), I execute
> 
> ./or32-softmmu/qemu-system-or32 -cpu or1200 -M or32-sim \
>     -kernel ~/work/linux/bld-or/vmlinux -append console=ttyS0 \
>     -serial stdio -nographic -monitor none \
>     -D z -d in_asm,exec,int,op_opt
> 
> ...
> Trace 0x7f501130a880 [0: c036c650] setup_cpuinfo
> Trace 0x7f501130a990 [0: c036c65c] setup_cpuinfo
> Trace 0x7f501130aaa0 [0: c0069774] panic
> ...
> Trace 0x7f5011312b70 [0: 000001fc]
> Trace 0x7f5011312b70 [0: 000001fc]
> 
> That last block repeats forever.
> 
> The qemu I'm using is
> 
>   git://github.com/rth7680/qemu.git tgt-or1k-2
> 
> which has your patch, l.lwa/swa, and a cleanup to the disassembly trace.
> 
> Looking at the kernel source I would hazard a guess that it's
> 
> >         cpu = of_find_compatible_node(NULL, NULL, "opencores,or1200-rtlsvn481");
> >         if (!cpu)
> >                 panic("No compatible CPU found in device tree...\n");
> 
> which suggests some large configuration error.

Hmm, I just tried your qemu branch and mine:

  git@github.com:stffrdhrn/qemu.git or1k-fix-sigill

Both of them were able to boot fine.

The opencores,or1200-rtlsvn481 cpu node is in the or1ksim device tree
definition.  Are you sure your kernel config has this in it?

  CONFIG_OPENRISC_BUILTIN_DTB="or1ksim"

Could you send your kernel config?

I have attached mine, just in case.  For next-20170124

-Stafford

[-- Attachment #2: config.or1k-next-20170124.gz --]
[-- Type: application/gzip, Size: 7343 bytes --]

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 01/25/2017 04:34 AM, Stafford Horne wrote:
> Hmm, I just tried your qemu branch and mine:
> 
>   git@github.com:stffrdhrn/qemu.git or1k-fix-sigill
> 
> Both of them were able to boot fine.
> 
> The opencores,or1200-rtlsvn481 cpu node is in the or1ksim device tree
> definition.  Are you sure your kernel config has this in it?
> 
>   CONFIG_OPENRISC_BUILTIN_DTB="or1ksim"
> 
> Could you send your kernel config?
> 
> I have attached mine, just in case.  For next-20170124

Curious.  The entire diff between our configs is just

--- ../or-config        2017-01-24 09:14:51.918059107 -0800
+++ .config     2017-01-25 09:18:14.153999754 -0800
@@ -18,7 +18,7 @@
 #
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
-CONFIG_CROSS_COMPILE="or1k-linux-musl-"
+CONFIG_CROSS_COMPILE="or1k-musl-linux-"
 # CONFIG_COMPILE_TEST is not set
 CONFIG_LOCALVERSION=""
 CONFIG_LOCALVERSION_AUTO=y

So you're saying you *do* get serial port output?

Perhaps you can just send me your kernel...


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Wed, Jan 25, 2017 at 09:27:29AM -0800, Richard Henderson wrote:
> On 01/25/2017 04:34 AM, Stafford Horne wrote:
> > Hmm, I just tried your qemu branch and mine:
> > 
> >   git@github.com:stffrdhrn/qemu.git or1k-fix-sigill
> > 
> > Both of them were able to boot fine.
> > 
> > The opencores,or1200-rtlsvn481 cpu node is in the or1ksim device tree
> > definition.  Are you sure your kernel config has this in it?
> > 
> >   CONFIG_OPENRISC_BUILTIN_DTB="or1ksim"
> > 
> > Could you send your kernel config?
> > 
> > I have attached mine, just in case.  For next-20170124
> 
> Curious.  The entire diff between our configs is just
> 
> --- ../or-config        2017-01-24 09:14:51.918059107 -0800
> +++ .config     2017-01-25 09:18:14.153999754 -0800
> @@ -18,7 +18,7 @@
>  #
>  CONFIG_BROKEN_ON_SMP=y
>  CONFIG_INIT_ENV_ARG_LIMIT=32
> -CONFIG_CROSS_COMPILE="or1k-linux-musl-"
> +CONFIG_CROSS_COMPILE="or1k-musl-linux-"
>  # CONFIG_COMPILE_TEST is not set
>  CONFIG_LOCALVERSION=""
>  CONFIG_LOCALVERSION_AUTO=y
> 
> So you're saying you *do* get serial port output?
> 
> Perhaps you can just send me your kernel...

I just sent you a mail with a link to my kernel for download.

One thing I noticed is you passed '-append console=ttyS0' I think that
does nothing on openrisc since as far as I know openrisc only gets boot
params from the device tree file. I tried with and without it and got no
differences.

Another thing, I am using a 'late' version of gcc built with musl cross [1]
, I dont think it would make a difference, but maybe?

$ or1k-musl-linux-as --version
GNU assembler (GNU Binutils) 2.26.20160125
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `or1k-linux-musl'.

$ or1k-musl-linux-gcc --version
or1k-musl-linux-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


[1] https://github.com/openrisc/musl-cross/tree/or1k

Boot sequence I am seeing, this comes out to stdout when running the
qemu command. The panic at the end is expected, if I add initrd it
goes away.

Compiled-in FDT at c03ad120
Linux version 4.10.0-rc5-next-20170124 (shorne@lianli.shorne-pla.net) (gcc version 5.4.0 (GCC) ) #406 Thu Jan 26 22:04:20 JST 2017
CPU: OpenRISC-0 (revision 0) @20 MHz
-- dcache disabled
-- icache disabled
-- dmmu:   64 entries, 1 way(s)
-- immu:   64 entries, 1 way(s)
-- additional features:
-- power management
-- timer
setup_memory: Memory: 0x0-0x2000000
Setting up paging and PTEs.
map_ram: Memory: 0x0-0x2000000
itlb_miss_handler c0002160
dtlb_miss_handler c0002000
OpenRISC Linux -- http://openrisc.io
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4080
Kernel command line: console=uart,mmio,0x90000000,115200
earlycon: uart0 at MMIO 0x90000000 (options '115200')
bootconsole [uart0] enabled
PID hash table entries: 128 (order: -4, 512 bytes)
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Sorting __ex_table...
Memory: 28672K/32768K available (2883K kernel code, 116K rwdata, 640K rodata, 128K init, 94K bss, 4096K reserved, 0K cma-reserved)
mem_init_done ...........................................
NR_IRQS:32 nr_irqs:32 0
clocksource: openrisc_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 95563022313 ns
40.00 BogoMIPS (lpj=200000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
NET: Registered protocol family 16
clocksource: Switched to clocksource openrisc_timer
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 256 (order: -2, 3072 bytes)
workingset: timestamp_bits=30 max_order=12 bucket_order=0
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
90000000.serial: ttyS0 at MMIO 0x90000000 (irq = 2, base_baud = 1250000) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [uart0] disabled
bootconsole [uart0] disabled
libphy: Fixed MDIO Bus: probed
NET: Registered protocol family 17
devtmpfs: mounted
Freeing unused kernel memory: 128K
This architecture does not have kernel memory protection.
Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 01/26/2017 05:12 AM, Stafford Horne wrote:
> I just sent you a mail with a link to my kernel for download.
>
> One thing I noticed is you passed '-append console=ttyS0' I think that
> does nothing on openrisc since as far as I know openrisc only gets boot
> params from the device tree file. I tried with and without it and got no
> differences.

That was just reflex, wondering where the output went.

> Another thing, I am using a 'late' version of gcc built with musl cross [1]
> , I dont think it would make a difference, but maybe?

I think that's likely the difference.  I can indeed boot your kernel.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Thu, Jan 26, 2017 at 09:26:55AM -0800, Richard Henderson wrote:
> On 01/26/2017 05:12 AM, Stafford Horne wrote:
> > I just sent you a mail with a link to my kernel for download.
> > 
> > One thing I noticed is you passed '-append console=ttyS0' I think that
> > does nothing on openrisc since as far as I know openrisc only gets boot
> > params from the device tree file. I tried with and without it and got no
> > differences.
> 
> That was just reflex, wondering where the output went.
> 
> > Another thing, I am using a 'late' version of gcc built with musl cross [1]
> > , I dont think it would make a difference, but maybe?
> 
> I think that's likely the difference.  I can indeed boot your kernel.

OK, you can try to build with the musl-cross link I sent you.

  https://github.com/openrisc/musl-cross/tree/or1k

Also, for the linux kernel crosstool project I am working on getting
their toolchain updated to support l.swa/l.lwa.   I have posted some
binaries here (but no libc needed for the kernel):

  http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/

The official ones are all here (below), but much too old to support openrisc
modern instructions.

  https://www.kernel.org/pub/tools/crosstool/

-Stafford

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Thu, Jan 26, 2017 at 09:26:55AM -0800, Richard Henderson wrote:
> On 01/26/2017 05:12 AM, Stafford Horne wrote:
> > I just sent you a mail with a link to my kernel for download.
> > 
> > One thing I noticed is you passed '-append console=ttyS0' I think that
> > does nothing on openrisc since as far as I know openrisc only gets boot
> > params from the device tree file. I tried with and without it and got no
> > differences.
> 
> That was just reflex, wondering where the output went.
> 
> > Another thing, I am using a 'late' version of gcc built with musl cross [1]
> > , I dont think it would make a difference, but maybe?
> 
> I think that's likely the difference.  I can indeed boot your kernel.

Hi Richard,

For kernel builds I have created toolchain binaries here:

  http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/

These should work.

If all is ok with the qemu patch I sent what is the next step to get them
incorporated.  Do you need any help from me?

... Actually I just checked your branch on github, it looks like you are
doing a few updates.  Let me know if you want me to review anything.

-Stafford

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 02/01/2017 02:04 AM, Stafford Horne wrote:
> On Thu, Jan 26, 2017 at 09:26:55AM -0800, Richard Henderson wrote:
>> On 01/26/2017 05:12 AM, Stafford Horne wrote:
>>> I just sent you a mail with a link to my kernel for download.
>>>
>>> One thing I noticed is you passed '-append console=ttyS0' I think that
>>> does nothing on openrisc since as far as I know openrisc only gets boot
>>> params from the device tree file. I tried with and without it and got no
>>> differences.
>>
>> That was just reflex, wondering where the output went.
>>
>>> Another thing, I am using a 'late' version of gcc built with musl cross [1]
>>> , I dont think it would make a difference, but maybe?
>>
>> I think that's likely the difference.  I can indeed boot your kernel.
> 
> Hi Richard,
> 
> For kernel builds I have created toolchain binaries here:
> 
>   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> 
> These should work.
> 
> If all is ok with the qemu patch I sent what is the next step to get them
> incorporated.  Do you need any help from me?
> 
> ... Actually I just checked your branch on github, it looks like you are
> doing a few updates.  Let me know if you want me to review anything.

Yes, I've been attempting to revive a patch set from 2013 that cleans up the
implementation, fixing a few other bugs in the process.

However, testing it properly has been tricky.  It appears as if I'm debugging
qemu and gcc simultaneously, while your gdb branch doesn't want to compile for
me.  So I've been limited to instruction traces from qemu, which is slow going.

If you'd like to do your own testing on my tgt-or1k-2 branch, that would be
appreciated.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Wed, Feb 01, 2017 at 10:15:54AM -0800, Richard Henderson wrote:
> On 02/01/2017 02:04 AM, Stafford Horne wrote:
> > On Thu, Jan 26, 2017 at 09:26:55AM -0800, Richard Henderson wrote:
> >> On 01/26/2017 05:12 AM, Stafford Horne wrote:
> >>> I just sent you a mail with a link to my kernel for download.
> >>>
> >>> One thing I noticed is you passed '-append console=ttyS0' I think that
> >>> does nothing on openrisc since as far as I know openrisc only gets boot
> >>> params from the device tree file. I tried with and without it and got no
> >>> differences.
> >>
> >> That was just reflex, wondering where the output went.
> >>
> >>> Another thing, I am using a 'late' version of gcc built with musl cross [1]
> >>> , I dont think it would make a difference, but maybe?
> >>
> >> I think that's likely the difference.  I can indeed boot your kernel.
> > 
> > Hi Richard,
> > 
> > For kernel builds I have created toolchain binaries here:
> > 
> >   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> > 
> > These should work.
> > 
> > If all is ok with the qemu patch I sent what is the next step to get them
> > incorporated.  Do you need any help from me?
> > 
> > ... Actually I just checked your branch on github, it looks like you are
> > doing a few updates.  Let me know if you want me to review anything.
> 
> Yes, I've been attempting to revive a patch set from 2013 that cleans up the
> implementation, fixing a few other bugs in the process.
> 
> However, testing it properly has been tricky.  It appears as if I'm debugging
> qemu and gcc simultaneously, while your gdb branch doesn't want to compile for
> me.  So I've been limited to instruction traces from qemu, which is slow going.

What issue are you having compiling gdb?

I compile gdb with these flags.

  ../binutils-gdb/configure --target=or1k-musl-linux \
    --prefix=$PREFIX \
    --disable-itcl \
    --disable-tk \
    --disable-tcl \
    --disable-winsup \
    --disable-gdbtk \
    --disable-libgui \
    --disable-rda \
    --disable-sid \
    --with-sysroot \
    --disable-newlib \
    --disable-libgloss \
    --disable-gas \
    --disable-ld \
    --disable-binutils \
    --disable-gprof \
    --with-system-zlib

Also, I uploaded my binaries just in case:

  http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/

My host gcc is "6.3.1 20161221", I used musl-cross and my gdb branch

  https://github.com/openrisc/musl-cross.git or1k

  git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream

> If you'd like to do your own testing on my tgt-or1k-2 branch, that would be
> appreciated.

I will have a look tomorrow if I can.

-Stafford

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Thu, Feb 02, 2017 at 11:34:55PM +0900, Stafford Horne wrote:
> On Wed, Feb 01, 2017 at 10:15:54AM -0800, Richard Henderson wrote:
> > On 02/01/2017 02:04 AM, Stafford Horne wrote:
> > > On Thu, Jan 26, 2017 at 09:26:55AM -0800, Richard Henderson wrote:
> > >> On 01/26/2017 05:12 AM, Stafford Horne wrote:
> > >>> I just sent you a mail with a link to my kernel for download.
> > >>>
> > >>> One thing I noticed is you passed '-append console=ttyS0' I think that
> > >>> does nothing on openrisc since as far as I know openrisc only gets boot
> > >>> params from the device tree file. I tried with and without it and got no
> > >>> differences.
> > >>
> > >> That was just reflex, wondering where the output went.
> > >>
> > >>> Another thing, I am using a 'late' version of gcc built with musl cross [1]
> > >>> , I dont think it would make a difference, but maybe?
> > >>
> > >> I think that's likely the difference.  I can indeed boot your kernel.
> > > 
> > > Hi Richard,
> > > 
> > > For kernel builds I have created toolchain binaries here:
> > > 
> > >   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> > > 
> > > These should work.
> > > 
> > > If all is ok with the qemu patch I sent what is the next step to get them
> > > incorporated.  Do you need any help from me?
> > > 
> > > ... Actually I just checked your branch on github, it looks like you are
> > > doing a few updates.  Let me know if you want me to review anything.
> > 
> > Yes, I've been attempting to revive a patch set from 2013 that cleans up the
> > implementation, fixing a few other bugs in the process.
> > 
> > However, testing it properly has been tricky.  It appears as if I'm debugging
> > qemu and gcc simultaneously, while your gdb branch doesn't want to compile for
> > me.  So I've been limited to instruction traces from qemu, which is slow going.
> 
> What issue are you having compiling gdb?
> 
> I compile gdb with these flags.
> 
>   ../binutils-gdb/configure --target=or1k-musl-linux \
>     --prefix=$PREFIX \
>     --disable-itcl \
>     --disable-tk \
>     --disable-tcl \
>     --disable-winsup \
>     --disable-gdbtk \
>     --disable-libgui \
>     --disable-rda \
>     --disable-sid \
>     --with-sysroot \
>     --disable-newlib \
>     --disable-libgloss \
>     --disable-gas \
>     --disable-ld \
>     --disable-binutils \
>     --disable-gprof \
>     --with-system-zlib
> 
> Also, I uploaded my binaries just in case:
> 
>   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> 
> My host gcc is "6.3.1 20161221", I used musl-cross and my gdb branch
> 
>   https://github.com/openrisc/musl-cross.git or1k
> 
>   git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream
> 
> > If you'd like to do your own testing on my tgt-or1k-2 branch, that would be
> > appreciated.
> 
> I will have a look tomorrow if I can.

I tried your tgt-or1k-2 branch with my latest kernel and have no issues.

What are you having issues with?  If you have some example code I could
have a look.

-Stafford

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 02/03/2017 07:14 AM, Stafford Horne wrote:
> I tried your tgt-or1k-2 branch with my latest kernel and have no issues.

Ok, excellent, thanks.  I'll send a pull for that branch then.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 02/01/2017 02:04 AM, Stafford Horne wrote:
> For kernel builds I have created toolchain binaries here:
>
>   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
>
> These should work.

This gdb crashes on the first "stepi" that I issue.  To reproduce,

$ cat z.c
int main() { return 0; }
$ or1k-musl-linux-gcc -g z.c
$ qemu-or32 -g 10001 ./a.out

// another window

$ or1k-musl-linux-gdb ./a.out
(gdb) target remote localhost:10001
// should see that the pc is at _start
(gdb) stepi
// crash

I won't be able to debug this myself until I can build my own gdb.


r~

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

On Mon, Feb 06, 2017 at 09:53:26PM -0800, Richard Henderson wrote:
> On 02/01/2017 02:04 AM, Stafford Horne wrote:
> > For kernel builds I have created toolchain binaries here:
> > 
> >   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> > 
> > These should work.
> 
> This gdb crashes on the first "stepi" that I issue.  To reproduce,
> 
> $ cat z.c
> int main() { return 0; }
> $ or1k-musl-linux-gcc -g z.c
> $ qemu-or32 -g 10001 ./a.out
> 
> // another window
> 
> $ or1k-musl-linux-gdb ./a.out
> (gdb) target remote localhost:10001
> // should see that the pc is at _start
> (gdb) stepi
> // crash
> 
> I won't be able to debug this myself until I can build my own gdb.

Hello,

The gdb branch I use is the following, it is tracking very close to
upsstream:

  git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream

I have sent this for review to the gdb list and currently waiting on
comments for version 4.  Most of the code is the same as in openrisc
github. However, I have just rebased and cleaned up for upstreaming.

Note, I can get basic programs running fine on your qemu branch using
linux-user i.e.

 $ cat main.c
   #include <stdio.h>

   int main() {
     printf("hello");
     return 0;
   }
 $ or1k-linux-musl-gcc -g -static main.c
 $ ./qemu/build/or32-linux-user/qemu-or32 ./a.out
   hello

However, when debugging I ran into a few errors.

  1. qemu aborts the program and sends SIGILL to gdb, this is caused by
     the openrisc loop in linux-user missing handlers for EXCP_INTERRUPT
     and EXCP_DEBUG, I patched that see below:
  2. After patching I got 1 step to work then gdb crashes with SIGSEGV
     Currently looking at it, Interestingly the code that is failing is

       in gdb/or1k-tdep.c: or1k_single_step_through_delay()
       cgen_lookup_insn() - returns NULL (shouldnt happen though)
       then NULL is dereferenced

     Interesting because it seems you wrote cgen_lookup_insn :)
     I am investigating more, but it seems like gdb issue.

Notes on the debugger:
  - The support for linux user processes is not implemented.  Eventually
    I think it will crash somewhere.  But it shouldnt crash where it is.
  - I tested the same program with the baremetal (newlib) toolchain
     * gdb native sim - OK can debug
     * or1ksim (via target remote) - Crashes same as QEMU

-Stafford


Patch for qemu issue mentioned in (1) above.

>From 777bd1c6641ea919799579dfbc99db4338db11bf Mon Sep 17 00:00:00 2001
From: Stafford Horne <shorne@gmail.com>
Date: Wed, 8 Feb 2017 22:20:01 +0900
Subject: [PATCH] linux-user: openrisc: Implement EXCP_INTERRUPT and EXCP_DEBUG

These were not implemented.  They are required escpecially if we
want to debug user processes in openrisc.

Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 linux-user/main.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index 94a636f..1c33378 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2468,6 +2468,7 @@ void cpu_loop(CPUOpenRISCState *env)
 {
     CPUState *cs = CPU(openrisc_env_get_cpu(env));
     int trapnr, gdbsig;
+    target_siginfo_t info;
     abi_long ret;
 
     for (;;) {
@@ -2542,6 +2543,23 @@ void cpu_loop(CPUOpenRISCState *env)
         case EXCP_ATOMIC:
             cpu_exec_step_atomic(cs);
             break;
+        case EXCP_INTERRUPT:
+            /* just indicate that signals should be handled asap */
+            break;
+        case EXCP_DEBUG:
+            {
+                int sig;
+
+                sig = gdb_handlesig(cs, TARGET_SIGTRAP);
+                if (sig)
+                  {
+                    info.si_signo = sig;
+                    info.si_errno = 0;
+                    info.si_code = TARGET_TRAP_BRKPT;
+                    queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info);
+                  }
+            }
+            break;
         default:
             EXCP_DUMP(env, "\nqemu: unhandled CPU exception %#x - aborting\n",
                      trapnr);
-- 
2.9.3

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

Hello,

On Wed, Feb 08, 2017 at 11:01:20PM +0900, Stafford Horne wrote:
> On Mon, Feb 06, 2017 at 09:53:26PM -0800, Richard Henderson wrote:
> > On 02/01/2017 02:04 AM, Stafford Horne wrote:
> > > For kernel builds I have created toolchain binaries here:
> > > 
> > >   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
> > > 
> > > These should work.
> > 
> > This gdb crashes on the first "stepi" that I issue.  To reproduce,
> > 
> > $ cat z.c
> > int main() { return 0; }
> > $ or1k-musl-linux-gcc -g z.c
> > $ qemu-or32 -g 10001 ./a.out
> > 
> > // another window
> > 
> > $ or1k-musl-linux-gdb ./a.out
> > (gdb) target remote localhost:10001
> > // should see that the pc is at _start
> > (gdb) stepi
> > // crash
> > 
> > I won't be able to debug this myself until I can build my own gdb.
> 
> Hello,
> 
> The gdb branch I use is the following, it is tracking very close to
> upsstream:
> 
>   git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream
> 
> I have sent this for review to the gdb list and currently waiting on
> comments for version 4.  Most of the code is the same as in openrisc
> github. However, I have just rebased and cleaned up for upstreaming.
> 
> Note, I can get basic programs running fine on your qemu branch using
> linux-user i.e.
> 
>  $ cat main.c
>    #include <stdio.h>
> 
>    int main() {
>      printf("hello");
>      return 0;
>    }
>  $ or1k-linux-musl-gcc -g -static main.c
>  $ ./qemu/build/or32-linux-user/qemu-or32 ./a.out
>    hello
> 
> However, when debugging I ran into a few errors.
> 
>   1. qemu aborts the program and sends SIGILL to gdb, this is caused by
>      the openrisc loop in linux-user missing handlers for EXCP_INTERRUPT
>      and EXCP_DEBUG, I patched that see below:
>   2. After patching I got 1 step to work then gdb crashes with SIGSEGV
>      Currently looking at it, Interestingly the code that is failing is
> 
>        in gdb/or1k-tdep.c: or1k_single_step_through_delay()
>        cgen_lookup_insn() - returns NULL (shouldnt happen though)
>        then NULL is dereferenced
> 
>      Interesting because it seems you wrote cgen_lookup_insn :)
>      I am investigating more, but it seems like gdb issue.

OK, I think I fixed this cgen_lookup_insn issue.

Now I can debug qemu user:

  $ ./qemu/build/or32-linux-user/qemu-or32 -g 10001 ./a.out
  $ or1k-linux-musl-gdb ./a.out \
    --eval-command='target remote localhost:10001'
   Remote debugging using localhost:10001
   0x000020e4 in _start ()
   (gdb) si
   0x000020e8 in _start ()
   (gdb)

A bug was added there by Nick Clifton last year when he did some memory
allocation cleanups in cgen_lookup_insn(). It seems not much code uses
this so perhaps it was not noticed.

Also, it looks like you didnt write it, you just imported the original
source?

I have now pushed the fix to my repo.  At the same time pushing to
gdb-patches list.

-Stafford

> Notes on the debugger:
>   - The support for linux user processes is not implemented.  Eventually
>     I think it will crash somewhere.  But it shouldnt crash where it is.
>   - I tested the same program with the baremetal (newlib) toolchain
>      * gdb native sim - OK can debug
>      * or1ksim (via target remote) - Crashes same as QEMU
> 

Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Richard Henderson]

On 02/08/2017 06:01 AM, Stafford Horne wrote:
> On Mon, Feb 06, 2017 at 09:53:26PM -0800, Richard Henderson wrote:
>> On 02/01/2017 02:04 AM, Stafford Horne wrote:
>>> For kernel builds I have created toolchain binaries here:
>>>
>>>   http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
>>>
>>> These should work.
>>
>> This gdb crashes on the first "stepi" that I issue.  To reproduce,
>>
>> $ cat z.c
>> int main() { return 0; }
>> $ or1k-musl-linux-gcc -g z.c
>> $ qemu-or32 -g 10001 ./a.out
>>
>> // another window
>>
>> $ or1k-musl-linux-gdb ./a.out
>> (gdb) target remote localhost:10001
>> // should see that the pc is at _start
>> (gdb) stepi
>> // crash
>>
>> I won't be able to debug this myself until I can build my own gdb.
>
> Hello,
>
> The gdb branch I use is the following, it is tracking very close to
> upsstream:
>
>   git@github.com:stffrdhrn/binutils-gdb.git or1k-upstream
>
> I have sent this for review to the gdb list and currently waiting on
> comments for version 4.  Most of the code is the same as in openrisc
> github. However, I have just rebased and cleaned up for upstreaming.

Thanks.  I can confirm that I have no problems building this branch.

> However, when debugging I ran into a few errors.
>
>   1. qemu aborts the program and sends SIGILL to gdb, this is caused by
>      the openrisc loop in linux-user missing handlers for EXCP_INTERRUPT
>      and EXCP_DEBUG, I patched that see below:

Yes, I fixed that on my or1k branch Monday.


r~

[Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers

[Stafford Horne]

I am working on testing instruction emulation patches for the linux
kernel. During testing I found these 2 issues:

 - sets DSX (delay slot exception) but never clears it
 - EEAR for illegal insns should point to the bad exception (as per
   openrisc spec) but its not

This patch fixes these two issues by clearing the DSX flag when not in a
delay slot and by setting EEAR to exception PC when handling illegal
instruction exceptions.

After this patch the openrisc kernel with latest patches boots great on
qemu and instruction emulation works.

Cc: qemu-trivial@nongnu.org
Cc: openrisc@lists.librecores.org
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 target/openrisc/interrupt.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/target/openrisc/interrupt.c b/target/openrisc/interrupt.c
index 5fe3f11..e1b0142 100644
--- a/target/openrisc/interrupt.c
+++ b/target/openrisc/interrupt.c
@@ -38,10 +38,17 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
         env->flags &= ~D_FLAG;
         env->sr |= SR_DSX;
         env->epcr -= 4;
+    } else {
+        env->sr &= ~SR_DSX;
     }
     if (cs->exception_index == EXCP_SYSCALL) {
         env->epcr += 4;
     }
+    /* When we have an illegal instruction the error effective address
+       shall be set to the illegal instruction address.  */
+    if (cs->exception_index == EXCP_ILLEGAL) {
+        env->eear = env->pc;
+    }
 
     /* For machine-state changed between user-mode and supervisor mode,
        we need flush TLB when we enter&exit EXCP.  */
-- 
2.9.3