* [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers @ 2017-01-13 22:00 ` Stafford Horne 0 siblings, 0 replies; 21+ messages in thread From: Stafford Horne @ 2017-01-13 22:00 UTC (permalink / raw) To: Jia Liu, qemu-devel; +Cc: Stafford Horne, qemu-trivial, openrisc 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [OpenRISC] [PATCH] target-openrisc: Fix exception handling status registers @ 2017-01-13 22:00 ` Stafford Horne 0 siblings, 0 replies; 21+ messages in thread From: Stafford Horne @ 2017-01-13 22:00 UTC (permalink / raw) To: openrisc 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 at nongnu.org Cc: openrisc at 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [OpenRISC] [PATCH] target-openrisc: Fix exception handling status registers @ 2017-01-13 21:57 Stafford Horne 2017-01-13 22:02 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-13 21:57 UTC (permalink / raw) To: openrisc 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 at nongnu.org Cc: openrisc at 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [OpenRISC] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-13 21:57 Stafford Horne @ 2017-01-13 22:02 ` Stafford Horne 2017-01-14 4:29 ` Jia Liu 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-13 22:02 UTC (permalink / raw) To: openrisc 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 at nongnu.org > Cc: openrisc at 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 > ^ permalink raw reply [flat|nested] 21+ messages in thread
* [OpenRISC] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-13 22:02 ` Stafford Horne @ 2017-01-14 4:29 ` Jia Liu 2017-01-14 8:04 ` [Qemu-devel] " Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Jia Liu @ 2017-01-14 4:29 UTC (permalink / raw) To: openrisc 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 at nongnu.org >> Cc: openrisc at 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. And, this is the lwa&swa support. It also make latest Linux boot. >> -- >> 2.9.3 >> Regards, Jia -------------- next part -------------- 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; ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-14 4:29 ` Jia Liu @ 2017-01-14 8:04 ` Stafford Horne 2017-01-20 16:39 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-14 8:04 UTC (permalink / raw) To: Jia Liu, qemu-devel; +Cc: openrisc 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; ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-14 8:04 ` [Qemu-devel] " Stafford Horne @ 2017-01-20 16:39 ` Stafford Horne 2017-01-23 18:08 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-20 16:39 UTC (permalink / raw) To: Jia Liu, qemu-devel, rth; +Cc: openrisc (+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; > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-20 16:39 ` Stafford Horne @ 2017-01-23 18:08 ` Richard Henderson 2017-01-24 10:26 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Richard Henderson @ 2017-01-23 18:08 UTC (permalink / raw) To: Stafford Horne, Jia Liu, qemu-devel; +Cc: openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-23 18:08 ` Richard Henderson @ 2017-01-24 10:26 ` Stafford Horne 2017-01-24 18:32 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-24 10:26 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-24 10:26 ` Stafford Horne @ 2017-01-24 18:32 ` Richard Henderson 2017-01-25 12:34 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Richard Henderson @ 2017-01-24 18:32 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-24 18:32 ` Richard Henderson @ 2017-01-25 12:34 ` Stafford Horne 2017-01-25 17:27 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-25 12:34 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-25 12:34 ` Stafford Horne @ 2017-01-25 17:27 ` Richard Henderson 2017-01-26 13:12 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Richard Henderson @ 2017-01-25 17:27 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-25 17:27 ` Richard Henderson @ 2017-01-26 13:12 ` Stafford Horne 2017-01-26 17:26 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-01-26 13:12 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-26 13:12 ` Stafford Horne @ 2017-01-26 17:26 ` Richard Henderson 2017-01-26 22:01 ` Stafford Horne 2017-02-01 10:04 ` Stafford Horne 0 siblings, 2 replies; 21+ messages in thread From: Richard Henderson @ 2017-01-26 17:26 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-26 17:26 ` Richard Henderson @ 2017-01-26 22:01 ` Stafford Horne 2017-02-01 10:04 ` Stafford Horne 1 sibling, 0 replies; 21+ messages in thread From: Stafford Horne @ 2017-01-26 22:01 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-01-26 17:26 ` Richard Henderson 2017-01-26 22:01 ` Stafford Horne @ 2017-02-01 10:04 ` Stafford Horne 2017-02-01 18:15 ` Richard Henderson 2017-02-07 5:53 ` Richard Henderson 1 sibling, 2 replies; 21+ messages in thread From: Stafford Horne @ 2017-02-01 10:04 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-01 10:04 ` Stafford Horne @ 2017-02-01 18:15 ` Richard Henderson 2017-02-02 14:34 ` Stafford Horne 2017-02-07 5:53 ` Richard Henderson 1 sibling, 1 reply; 21+ messages in thread From: Richard Henderson @ 2017-02-01 18:15 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-01 18:15 ` Richard Henderson @ 2017-02-02 14:34 ` Stafford Horne 2017-02-03 15:14 ` Stafford Horne 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-02-02 14:34 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-02 14:34 ` Stafford Horne @ 2017-02-03 15:14 ` Stafford Horne 2017-02-07 2:36 ` Richard Henderson 0 siblings, 1 reply; 21+ messages in thread From: Stafford Horne @ 2017-02-03 15:14 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-03 15:14 ` Stafford Horne @ 2017-02-07 2:36 ` Richard Henderson 0 siblings, 0 replies; 21+ messages in thread From: Richard Henderson @ 2017-02-07 2:36 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-01 10:04 ` Stafford Horne 2017-02-01 18:15 ` Richard Henderson @ 2017-02-07 5:53 ` Richard Henderson 2017-02-08 14:01 ` Stafford Horne 1 sibling, 1 reply; 21+ messages in thread From: Richard Henderson @ 2017-02-07 5:53 UTC (permalink / raw) To: Stafford Horne; +Cc: Jia Liu, qemu-devel, openrisc 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-07 5:53 ` Richard Henderson @ 2017-02-08 14:01 ` Stafford Horne 2017-02-08 16:38 ` Stafford Horne 2017-02-08 20:38 ` Richard Henderson 0 siblings, 2 replies; 21+ messages in thread From: Stafford Horne @ 2017-02-08 14:01 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-08 14:01 ` Stafford Horne @ 2017-02-08 16:38 ` Stafford Horne 2017-02-08 20:38 ` Richard Henderson 1 sibling, 0 replies; 21+ messages in thread From: Stafford Horne @ 2017-02-08 16:38 UTC (permalink / raw) To: Richard Henderson; +Cc: Jia Liu, qemu-devel, openrisc 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 > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers 2017-02-08 14:01 ` Stafford Horne 2017-02-08 16:38 ` Stafford Horne @ 2017-02-08 20:38 ` Richard Henderson 1 sibling, 0 replies; 21+ messages in thread From: Richard Henderson @ 2017-02-08 20:38 UTC (permalink / raw) To: Stafford Horne; +Cc: openrisc, Jia Liu, qemu-devel 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~ ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-02-08 20:39 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-13 22:00 [Qemu-devel] [PATCH] target-openrisc: Fix exception handling status registers Stafford Horne 2017-01-13 22:00 ` [OpenRISC] " Stafford Horne -- strict thread matches above, loose matches on Subject: below -- 2017-01-13 21:57 Stafford Horne 2017-01-13 22:02 ` Stafford Horne 2017-01-14 4:29 ` Jia Liu 2017-01-14 8:04 ` [Qemu-devel] " Stafford Horne 2017-01-20 16:39 ` Stafford Horne 2017-01-23 18:08 ` Richard Henderson 2017-01-24 10:26 ` Stafford Horne 2017-01-24 18:32 ` Richard Henderson 2017-01-25 12:34 ` Stafford Horne 2017-01-25 17:27 ` Richard Henderson 2017-01-26 13:12 ` Stafford Horne 2017-01-26 17:26 ` Richard Henderson 2017-01-26 22:01 ` Stafford Horne 2017-02-01 10:04 ` Stafford Horne 2017-02-01 18:15 ` Richard Henderson 2017-02-02 14:34 ` Stafford Horne 2017-02-03 15:14 ` Stafford Horne 2017-02-07 2:36 ` Richard Henderson 2017-02-07 5:53 ` Richard Henderson 2017-02-08 14:01 ` Stafford Horne 2017-02-08 16:38 ` Stafford Horne 2017-02-08 20:38 ` Richard Henderson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.