Re: [Qemu-devel] [PATCH 36/38] target-unicore32: Use mul*2 for do_mult

[guanxuetao]

 Cc: Guan Xuetao g...@mprc.pku.edu.cn
 Signed-off-by: Richard Henderson r...@twiddle.net

Acked-by: Guan Xuetao g...@mprc.pku.edu.cn

 ---
  target-unicore32/translate.c | 83
 ++--
  1 file changed, 11 insertions(+), 72 deletions(-)

 diff --git a/target-unicore32/translate.c b/target-unicore32/translate.c
 index f4498bc..d5039e2 100644
 --- a/target-unicore32/translate.c
 +++ b/target-unicore32/translate.c
 @@ -267,37 +267,6 @@ static void gen_exception(int excp)
  dead_tmp(tmp);
  }

 -/* FIXME: Most targets have native widening multiplication.
 -   It would be good to use that instead of a full wide multiply.  */
 -/* 32x32-64 multiply.  Marks inputs as dead.  */
 -static TCGv_i64 gen_mulu_i64_i32(TCGv a, TCGv b)
 -{
 -TCGv_i64 tmp1 = tcg_temp_new_i64();
 -TCGv_i64 tmp2 = tcg_temp_new_i64();
 -
 -tcg_gen_extu_i32_i64(tmp1, a);
 -dead_tmp(a);
 -tcg_gen_extu_i32_i64(tmp2, b);
 -dead_tmp(b);
 -tcg_gen_mul_i64(tmp1, tmp1, tmp2);
 -tcg_temp_free_i64(tmp2);
 -return tmp1;
 -}
 -
 -static TCGv_i64 gen_muls_i64_i32(TCGv a, TCGv b)
 -{
 -TCGv_i64 tmp1 = tcg_temp_new_i64();
 -TCGv_i64 tmp2 = tcg_temp_new_i64();
 -
 -tcg_gen_ext_i32_i64(tmp1, a);
 -dead_tmp(a);
 -tcg_gen_ext_i32_i64(tmp2, b);
 -dead_tmp(b);
 -tcg_gen_mul_i64(tmp1, tmp1, tmp2);
 -tcg_temp_free_i64(tmp2);
 -return tmp1;
 -}
 -
  #define gen_set_CF(var) tcg_gen_st_i32(var, cpu_env,
 offsetof(CPUUniCore32State, CF))

  /* Set CF to the top bit of var.  */
 @@ -1219,38 +1188,6 @@ static void disas_coproc_insn(CPUUniCore32State
 *env, DisasContext *s,
  }
  }

 -
 -/* Store a 64-bit value to a register pair.  Clobbers val.  */
 -static void gen_storeq_reg(DisasContext *s, int rlow, int rhigh, TCGv_i64
 val)
 -{
 -TCGv tmp;
 -tmp = new_tmp();
 -tcg_gen_trunc_i64_i32(tmp, val);
 -store_reg(s, rlow, tmp);
 -tmp = new_tmp();
 -tcg_gen_shri_i64(val, val, 32);
 -tcg_gen_trunc_i64_i32(tmp, val);
 -store_reg(s, rhigh, tmp);
 -}
 -
 -/* load and add a 64-bit value from a register pair.  */
 -static void gen_addq(DisasContext *s, TCGv_i64 val, int rlow, int rhigh)
 -{
 -TCGv_i64 tmp;
 -TCGv tmpl;
 -TCGv tmph;
 -
 -/* Load 64-bit value rd:rn.  */
 -tmpl = load_reg(s, rlow);
 -tmph = load_reg(s, rhigh);
 -tmp = tcg_temp_new_i64();
 -tcg_gen_concat_i32_i64(tmp, tmpl, tmph);
 -dead_tmp(tmpl);
 -dead_tmp(tmph);
 -tcg_gen_add_i64(val, val, tmp);
 -tcg_temp_free_i64(tmp);
 -}
 -
  /* data processing instructions */
  static void do_datap(CPUUniCore32State *env, DisasContext *s, uint32_t
 insn)
  {
 @@ -1445,24 +1382,26 @@ static void do_datap(CPUUniCore32State *env,
 DisasContext *s, uint32_t insn)
  /* multiply */
  static void do_mult(CPUUniCore32State *env, DisasContext *s, uint32_t
 insn)
  {
 -TCGv tmp;
 -TCGv tmp2;
 -TCGv_i64 tmp64;
 +TCGv tmp, tmp2, tmp3, tmp4;

  if (UCOP_SET(27)) {
  /* 64 bit mul */
  tmp = load_reg(s, UCOP_REG_M);
  tmp2 = load_reg(s, UCOP_REG_N);
  if (UCOP_SET(26)) {
 -tmp64 = gen_muls_i64_i32(tmp, tmp2);
 +tcg_gen_muls2_i32(tmp, tmp2, tmp, tmp2);
  } else {
 -tmp64 = gen_mulu_i64_i32(tmp, tmp2);
 +tcg_gen_mulu2_i32(tmp, tmp2, tmp, tmp2);
  }
  if (UCOP_SET(25)) { /* mult accumulate */
 -gen_addq(s, tmp64, UCOP_REG_LO, UCOP_REG_HI);
 -}
 -gen_storeq_reg(s, UCOP_REG_LO, UCOP_REG_HI, tmp64);
 -tcg_temp_free_i64(tmp64);
 +tmp3 = load_reg(s, UCOP_REG_LO);
 +tmp4 = load_reg(s, UCOP_REG_HI);
 +tcg_gen_add2_i32(tmp, tmp2, tmp, tmp2, tmp3, tmp4);
 +dead_tmp(tmp3);
 +dead_tmp(tmp4);
 +}
 +store_reg(s, UCOP_REG_LO, tmp);
 +store_reg(s, UCOP_REG_HI, tmp2);
  } else {
  /* 32 bit mul */
  tmp = load_reg(s, UCOP_REG_M);
 --
 1.8.1.2

Re: [Qemu-devel] 绛�澶�: [PATCH qom-cpu for-1.4] targe t-unicore32: Rename CPU subtypes

[guanxuetao]

 As indicated above, this patch has a bug, sorry. I will send a v2.
 Forking in linux-user will be broken (cpu_copy()), everything else
 should work though, no?

 Can you please test qemu.git master and confirm that it is not broken
 without this patch?

 I do not have any unicore32 image for testing. I therefore tested
 ./unicore32-softmmu/qemu-system-unicore32 -cpu ? (which did not seem
 implemented) and ./unicore32-softmmu/qemu-system-unicore32 without
 parameters, which ran into a kernel_filename assertion IIRC.
 Can you upload a test image and static linux-user binaries somewhere? Or
 provide me with instructions how to build a toolchain and kernel?

Sorry for replying so late. Since it's chinese spring festival, I can't
access my linux server recently.
My suggestion is that you can apply your patches on unicore32 to qemu.git
freely, and when I rebase my repo on qemu.git, I will review and adjust my
codes.

Happy Chinese New Year!
Xuetao


 Thanks,
 Andreas

 P.S. FYI a hw/uc32/ directory has been created in the meantime. If you
 still wish to move your puv3 files out of hw/, please feel invited to
 send a patch.

 --
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N眉rnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imend枚rffer; HRB 16746 AG N眉rnberg

Re: [Qemu-devel] 绛�澶�: [RFC 19/19] target-unicore32: Refactor deb ug output macros

[guanxuetao]

 Am 29.01.2013 10:23, schrieb Guan Xuetao:
 -���浠跺��浠�-
 ���浠朵�#65533;: Andreas F盲rber [mailto:afaer...@suse.de]
 堕�#65533;: Sunday, January 27, 2013 21:32
 ��朵欢浜#65533;: qemu-devel@nongnu.org
 �#65533;: Andreas F盲rber; Guan Xuetao (maintainer:UniCore32)
 涓婚��: [RFC 19/19] target-unicore32: Refactor debug output macros

 Make debug output compile-testable even if disabled.

 Signed-off-by: Andreas F盲rber afaer...@suse.de

 The patch could work, but I don't think it's a good idea.

 Yes, I agree. The plan for v2 is to use static inline functions and to
 keep using #ifdef rather than #if.

 Perhaps tracetools can be better.

 Tracepoints are not as flexible as they require a fixed set of up to
 6(?) arguments. But yes, if you were to replace these macros in
 unicore32 code with specific tracepoints that would solve the issue at
 hand as well and would even allow to enable/disable them at runtime.
Tracepoints, or tracetools? As tracetools, it's unneccessary to have fixed
6 arguments.
In my recent development on unicore64, all debug information is output by
tracetools, and it's very convenient. I hope to reform unicore32 by this
means.


 CC'ing some more people on this new input. Maybe there would be a common
 subset of tracepoints? Anthony mentioned LOG_EXCP and LOG_DIS; would not
 only the names but also the arguments be generalizable?
I haven't learned about tracepoints and LOG_*. I will put it on my TODO list.

Thanks,
Xuetao


 Regards,
 Andreas

 --
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N眉rnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imend枚rffer; HRB 16746 AG N眉rnberg

Re: [Qemu-devel] [RFC qom-cpu 14/15] target-unicore32: Introduce QOM realizefn for UniCore32CPU

[guanxuetao]

 Introduce a realizefn and set realized = true in uc32_cpu_init().

 Signed-off-by: Andreas F盲rber afaer...@suse.de

LGTM.

Acked-by: Guan Xuetao g...@mprc.pku.edu.cn

 ---
  target-unicore32/cpu.c|   15 +++
  target-unicore32/helper.c |2 +-
  2 Dateien ge盲ndert, 16 Zeilen hinzugef眉gt(+), 1 Zeile entfernt(-)

 diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
 index 884c101..22330ad 100644
 --- a/target-unicore32/cpu.c
 +++ b/target-unicore32/cpu.c
 @@ -61,6 +61,13 @@ static const UniCore32CPUInfo uc32_cpus[] = {
  { .name = any,.instance_init = uc32_any_cpu_initfn },
  };

 +static void uc32_cpu_realizefn(DeviceState *dev, Error **errp)
 +{
 +UniCore32CPU *cpu = UNICORE32_CPU(dev);
 +
 +qemu_init_vcpu(cpu-env);
 +}
 +
  static void uc32_cpu_initfn(Object *obj)
  {
  UniCore32CPU *cpu = UNICORE32_CPU(obj);
 @@ -80,6 +87,13 @@ static void uc32_cpu_initfn(Object *obj)
  tlb_flush(env, 1);
  }

 +static void uc32_cpu_class_init(ObjectClass *oc, void *data)
 +{
 +DeviceClass *dc = DEVICE_CLASS(oc);
 +
 +dc-realize = uc32_cpu_realizefn;
 +}
 +
  static void uc32_register_cpu_type(const UniCore32CPUInfo *info)
  {
  TypeInfo type_info = {
 @@ -98,6 +112,7 @@ static const TypeInfo uc32_cpu_type_info = {
  .instance_init = uc32_cpu_initfn,
  .abstract = true,
  .class_size = sizeof(UniCore32CPUClass),
 +.class_init = uc32_cpu_class_init,
  };

  static void uc32_cpu_register_types(void)
 diff --git a/target-unicore32/helper.c b/target-unicore32/helper.c
 index 5359538..347d842 100644
 --- a/target-unicore32/helper.c
 +++ b/target-unicore32/helper.c
 @@ -42,7 +42,7 @@ CPUUniCore32State *uc32_cpu_init(const char *cpu_model)
  uc32_translate_init();
  }

 -qemu_init_vcpu(env);
 +object_property_set_bool(OBJECT(cpu), true, realized, NULL);
  return env;
  }

 --
 1.7.10.4

Re: [Qemu-devel] [PATCH 3/5] target-unicore32: avoid using cpu_single_env

[guanxuetao]

 Pass around CPUState instead of using global cpu_single_env.

 Signed-off-by: Blue Swirl blauwir...@gmail.com

Acked-by: Guan Xuetao g...@mprc.pku.edu.cn

 ---
  target-unicore32/softmmu.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/target-unicore32/softmmu.c b/target-unicore32/softmmu.c
 index 9c2c54c..fc27100 100644
 --- a/target-unicore32/softmmu.c
 +++ b/target-unicore32/softmmu.c
 @@ -31,7 +31,7 @@


  /* Map CPU modes onto saved register banks.  */
 -static inline int bank_number(int mode)
 +static inline int bank_number(CPUUniCore32State *env, int mode)
  {
  switch (mode) {
  case ASR_MODE_USER:
 @@ -46,7 +46,7 @@ static inline int bank_number(int mode)
  case ASR_MODE_INTR:
  return 4;
  }
 -cpu_abort(cpu_single_env, Bad mode %x\n, mode);
 +cpu_abort(env, Bad mode %x\n, mode);
  return -1;
  }

 @@ -60,12 +60,12 @@ void switch_mode(CPUUniCore32State *env, int mode)
  return;
  }

 -i = bank_number(old_mode);
 +i = bank_number(env, old_mode);
  env-banked_r29[i] = env-regs[29];
  env-banked_r30[i] = env-regs[30];
  env-banked_bsr[i] = env-bsr;

 -i = bank_number(mode);
 +i = bank_number(env, mode);
  env-regs[29] = env-banked_r29[i];
  env-regs[30] = env-banked_r30[i];
  env-bsr = env-banked_bsr[i];
 --
 1.7.2.5

Re: [Qemu-devel] [PATCH 1/5] disas: avoid using cpu_single_env

[guanxuetao]

 Pass around CPUState instead of using global cpu_single_env.

 Signed-off-by: Blue Swirl blauwir...@gmail.com

For unicore32 part:

Acked-by: Guan Xuetao g...@mprc.pku.edu.cn

 ---
  disas.c   |  149
 ++---
  disas.h   |3 +-
  qemu-log.h|6 +-
  target-alpha/translate.c  |2 +-
  target-arm/translate.c|2 +-
  target-cris/translate.c   |2 +-
  target-i386/translate.c   |2 +-
  target-lm32/translate.c   |2 +-
  target-m68k/translate.c   |2 +-
  target-microblaze/translate.c |2 +-
  target-mips/translate.c   |2 +-
  target-openrisc/translate.c   |2 +-
  target-ppc/translate.c|2 +-
  target-s390x/translate.c  |2 +-
  target-sh4/translate.c|2 +-
  target-sparc/translate.c  |2 +-
  target-unicore32/translate.c  |2 +-
  17 files changed, 100 insertions(+), 86 deletions(-)

 diff --git a/disas.c b/disas.c
 index b801c8f..6da1dd0 100644
 --- a/disas.c
 +++ b/disas.c
 @@ -7,6 +7,11 @@
  #include cpu.h
  #include disas.h

 +typedef struct CPUDebug {
 +struct disassemble_info info;
 +CPUArchState *env;
 +} CPUDebug;
 +
  /* Filled in by elfload.c.  Simplistic, but will do for now. */
  struct syminfo *syminfos = NULL;

 @@ -32,7 +37,9 @@ target_read_memory (bfd_vma memaddr,
  int length,
  struct disassemble_info *info)
  {
 -cpu_memory_rw_debug(cpu_single_env, memaddr, myaddr, length, 0);
 +CPUDebug *s = container_of(info, CPUDebug, info);
 +
 +cpu_memory_rw_debug(s-env, memaddr, myaddr, length, 0);
  return 0;
  }

 @@ -158,32 +165,35 @@ print_insn_thumb1(bfd_vma pc, disassemble_info
 *info)
  ppc  - nonzero means little endian
  other targets - unused
   */
 -void target_disas(FILE *out, target_ulong code, target_ulong size, int
 flags)
 +void target_disas(FILE *out, CPUArchState *env, target_ulong code,
 +  target_ulong size, int flags)
  {
  target_ulong pc;
  int count;
 -struct disassemble_info disasm_info;
 +CPUDebug s;
  int (*print_insn)(bfd_vma pc, disassemble_info *info);

 -INIT_DISASSEMBLE_INFO(disasm_info, out, fprintf);
 +INIT_DISASSEMBLE_INFO(s.info, out, fprintf);

 -disasm_info.read_memory_func = target_read_memory;
 -disasm_info.buffer_vma = code;
 -disasm_info.buffer_length = size;
 -disasm_info.print_address_func = generic_print_target_address;
 +s.env = env;
 +s.info.read_memory_func = target_read_memory;
 +s.info.buffer_vma = code;
 +s.info.buffer_length = size;
 +s.info.print_address_func = generic_print_target_address;

  #ifdef TARGET_WORDS_BIGENDIAN
 -disasm_info.endian = BFD_ENDIAN_BIG;
 +s.info.endian = BFD_ENDIAN_BIG;
  #else
 -disasm_info.endian = BFD_ENDIAN_LITTLE;
 +s.info.endian = BFD_ENDIAN_LITTLE;
  #endif
  #if defined(TARGET_I386)
 -if (flags == 2)
 -disasm_info.mach = bfd_mach_x86_64;
 -else if (flags == 1)
 -disasm_info.mach = bfd_mach_i386_i8086;
 -else
 -disasm_info.mach = bfd_mach_i386_i386;
 +if (flags == 2) {
 +s.info.mach = bfd_mach_x86_64;
 +} else if (flags == 1) {
 +s.info.mach = bfd_mach_i386_i8086;
 +} else {
 +s.info.mach = bfd_mach_i386_i386;
 +}
  print_insn = print_insn_i386;
  #elif defined(TARGET_ARM)
  if (flags  1) {
 @@ -193,27 +203,28 @@ void target_disas(FILE *out, target_ulong code,
 target_ulong size, int flags)
  }
  if (flags  2) {
  #ifdef TARGET_WORDS_BIGENDIAN
 -disasm_info.endian = BFD_ENDIAN_LITTLE;
 +s.info.endian = BFD_ENDIAN_LITTLE;
  #else
 -disasm_info.endian = BFD_ENDIAN_BIG;
 +s.info.endian = BFD_ENDIAN_BIG;
  #endif
  }
  #elif defined(TARGET_SPARC)
  print_insn = print_insn_sparc;
  #ifdef TARGET_SPARC64
 -disasm_info.mach = bfd_mach_sparc_v9b;
 +s.info.mach = bfd_mach_sparc_v9b;
  #endif
  #elif defined(TARGET_PPC)
 -if (flags  16)
 -disasm_info.endian = BFD_ENDIAN_LITTLE;
 +if (flags  16) {
 +s.info.endian = BFD_ENDIAN_LITTLE;
 +}
  if (flags  0x) {
  /* If we have a precise definitions of the instructions set, use
 it */
 -disasm_info.mach = flags  0x;
 +s.info.mach = flags  0x;
  } else {
  #ifdef TARGET_PPC64
 -disasm_info.mach = bfd_mach_ppc64;
 +s.info.mach = bfd_mach_ppc64;
  #else
 -disasm_info.mach = bfd_mach_ppc;
 +s.info.mach = bfd_mach_ppc;
  #endif
  }
  print_insn = print_insn_ppc;
 @@ -226,27 +237,27 @@ void target_disas(FILE *out, target_ulong code,
 target_ulong size, int flags)
  print_insn = print_insn_little_mips;
  #endif
  #elif defined(TARGET_SH4)
 -disasm_info.mach = bfd_mach_sh4;
 +s.info.mach = bfd_mach_sh4;
  print_insn = print_insn_sh;
  #elif defined(TARGET_ALPHA)
 -

Re: [Qemu-devel] [PATCH 15/21] target-unicore32: switch to AREG0 free mode

[guanxuetao]

 Add an explicit CPUState parameter instead of relying on AREG0
 and switch to AREG0 free mode.

 Signed-off-by: Blue Swirl blauwir...@gmail.com

Thanks,

Tested-by: Guan Xuetao g...@mprc.pku.edu.cn

 ---
  configure  |2 +-
  target-unicore32/Makefile.objs |2 -
  target-unicore32/helper.h  |   26 
  target-unicore32/op_helper.c   |   65
 +++
  target-unicore32/translate.c   |   38 +++---
  5 files changed, 58 insertions(+), 75 deletions(-)

 diff --git a/configure b/configure
 index 350b47c..4fd3b7f 100755
 --- a/configure
 +++ b/configure
 @@ -3829,7 +3829,7 @@ symlink $source_path/Makefile.target
 $target_dir/Makefile


  case $target_arch2 in
 -  alpha | i386 | lm32 | m68k | or32 | s390x | sparc* | x86_64 | xtensa* |
 ppc*)
 +  alpha | i386 | lm32 | m68k | or32 | s390x | sparc* | unicore32 | x86_64
 | xtensa* | ppc*)
  echo CONFIG_TCG_PASS_AREG0=y  $config_target_mak
;;
  esac
 diff --git a/target-unicore32/Makefile.objs
 b/target-unicore32/Makefile.objs
 index 777f01f..8e143da 100644
 --- a/target-unicore32/Makefile.objs
 +++ b/target-unicore32/Makefile.objs
 @@ -2,5 +2,3 @@ obj-y += translate.o op_helper.o helper.o cpu.o
  obj-y += ucf64_helper.o

  obj-$(CONFIG_SOFTMMU) += machine.o softmmu.o
 -
 -$(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS)
 diff --git a/target-unicore32/helper.h b/target-unicore32/helper.h
 index 305318a..a4b8149 100644
 --- a/target-unicore32/helper.h
 +++ b/target-unicore32/helper.h
 @@ -17,26 +17,26 @@ DEF_HELPER_1(cp1_putc, void, i32)
  DEF_HELPER_1(clz, i32, i32)
  DEF_HELPER_1(clo, i32, i32)

 -DEF_HELPER_1(exception, void, i32)
 +DEF_HELPER_2(exception, void, env, i32)

 -DEF_HELPER_2(asr_write, void, i32, i32)
 -DEF_HELPER_0(asr_read, i32)
 +DEF_HELPER_3(asr_write, void, env, i32, i32)
 +DEF_HELPER_1(asr_read, i32, env)

 -DEF_HELPER_1(get_user_reg, i32, i32)
 -DEF_HELPER_2(set_user_reg, void, i32, i32)
 +DEF_HELPER_2(get_user_reg, i32, env, i32)
 +DEF_HELPER_3(set_user_reg, void, env, i32, i32)

 -DEF_HELPER_2(add_cc, i32, i32, i32)
 -DEF_HELPER_2(adc_cc, i32, i32, i32)
 -DEF_HELPER_2(sub_cc, i32, i32, i32)
 -DEF_HELPER_2(sbc_cc, i32, i32, i32)
 +DEF_HELPER_3(add_cc, i32, env, i32, i32)
 +DEF_HELPER_3(adc_cc, i32, env, i32, i32)
 +DEF_HELPER_3(sub_cc, i32, env, i32, i32)
 +DEF_HELPER_3(sbc_cc, i32, env, i32, i32)

  DEF_HELPER_2(shl, i32, i32, i32)
  DEF_HELPER_2(shr, i32, i32, i32)
  DEF_HELPER_2(sar, i32, i32, i32)
 -DEF_HELPER_2(shl_cc, i32, i32, i32)
 -DEF_HELPER_2(shr_cc, i32, i32, i32)
 -DEF_HELPER_2(sar_cc, i32, i32, i32)
 -DEF_HELPER_2(ror_cc, i32, i32, i32)
 +DEF_HELPER_3(shl_cc, i32, env, i32, i32)
 +DEF_HELPER_3(shr_cc, i32, env, i32, i32)
 +DEF_HELPER_3(sar_cc, i32, env, i32, i32)
 +DEF_HELPER_3(ror_cc, i32, env, i32, i32)

  DEF_HELPER_1(ucf64_get_fpscr, i32, env)
  DEF_HELPER_2(ucf64_set_fpscr, void, env, i32)
 diff --git a/target-unicore32/op_helper.c b/target-unicore32/op_helper.c
 index c63789d..f474d1b 100644
 --- a/target-unicore32/op_helper.c
 +++ b/target-unicore32/op_helper.c
 @@ -9,19 +9,18 @@
   * later version. See the COPYING file in the top-level directory.
   */
  #include cpu.h
 -#include dyngen-exec.h
  #include helper.h

  #define SIGNBIT (uint32_t)0x8000
  #define SIGNBIT64 ((uint64_t)1  63)

 -void HELPER(exception)(uint32_t excp)
 +void HELPER(exception)(CPUUniCore32State *env, uint32_t excp)
  {
  env-exception_index = excp;
  cpu_loop_exit(env);
  }

 -static target_ulong asr_read(void)
 +static target_ulong asr_read(CPUUniCore32State *env)
  {
  int ZF;
  ZF = (env-ZF == 0);
 @@ -29,24 +28,18 @@ static target_ulong asr_read(void)
  (env-CF  29) | ((env-VF  0x8000)  3);
  }

 -target_ulong cpu_asr_read(CPUUniCore32State *env1)
 +target_ulong cpu_asr_read(CPUUniCore32State *env)
  {
 -CPUUniCore32State *saved_env;
 -target_ulong ret;
 -
 -saved_env = env;
 -env = env1;
 -ret = asr_read();
 -env = saved_env;
 -return ret;
 +return asr_read(env);
  }

 -target_ulong HELPER(asr_read)(void)
 +target_ulong HELPER(asr_read)(CPUUniCore32State *env)
  {
 -return asr_read();
 +return asr_read(env);
  }

 -static void asr_write(target_ulong val, target_ulong mask)
 +static void asr_write(CPUUniCore32State *env, target_ulong val,
 +  target_ulong mask)
  {
  if (mask  ASR_NZCV) {
  env-ZF = (~val)  ASR_Z;
 @@ -62,23 +55,19 @@ static void asr_write(target_ulong val, target_ulong
 mask)
  env-uncached_asr = (env-uncached_asr  ~mask) | (val  mask);
  }

 -void cpu_asr_write(CPUUniCore32State *env1, target_ulong val,
 target_ulong mask)
 +void cpu_asr_write(CPUUniCore32State *env, target_ulong val, target_ulong
 mask)
  {
 -CPUUniCore32State *saved_env;
 -
 -saved_env = env;
 -env = env1;
 -asr_write(val, mask);
 -env = saved_env;
 +asr_write(env, val, mask);
  }

 -void HELPER(asr_write)(target_ulong val, 

Re: [Qemu-devel] [PATCH 00/19] unicore32: Add unicore32-softmmu support

[guanxuetao]

 This still breaks build. Please fix, something like ret = 0 when the
 variable is declared should be enough.
 /src/qemu/hw/puv3_gpio.c: In function 'puv3_gpio_read':
 /src/qemu/hw/puv3_gpio.c:48:5: error: 'ret' may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
 /src/qemu/hw/puv3_pm.c: In function 'puv3_pm_read':
 /src/qemu/hw/puv3_pm.c:74:5: error: 'ret' may be used uninitialized in
 this function [-Werror=maybe-uninitialized]
 /src/qemu/hw/puv3_dma.c: In function 'puv3_dma_read':
 /src/qemu/hw/puv3_dma.c:44:5: error: 'ret' may be used uninitialized
 in this function [-Werror=maybe-uninitialized]

 I won't apply the patches until this is fixed.

My mistake.  I'm sorry for that.

Thanks  Regard,
Guan Xuetao

Re: [Qemu-devel] [RESEND PULL REQUEST] UniCore32 PUV3 machine support

[guanxuetao]

 On Wed, Aug 1, 2012 at 3:13 AM,  g...@mprc.pku.edu.cn wrote:
 are available in the git repository at:

   git://github.com/gxt/QEMU.git unicore32

 I'm still getting these errors, please fix:
   CClibhw32/hw/puv3_gpio.o
 /src/qemu/hw/puv3_gpio.c: In function 'puv3_gpio_read':
 /src/qemu/hw/puv3_gpio.c:48:5: error: 'ret' may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
 cc1: all warnings being treated as errors
 make[1]: *** [hw/puv3_gpio.o] Error 1
   CClibhw32/hw/puv3_pm.o
 /src/qemu/hw/puv3_pm.c: In function 'puv3_pm_read':
 /src/qemu/hw/puv3_pm.c:74:5: error: 'ret' may be used uninitialized in
 this function [-Werror=maybe-uninitialized]
 cc1: all warnings being treated as errors
 make[1]: *** [hw/puv3_pm.o] Error 1
   CClibhw32/hw/puv3_dma.o
 /src/qemu/hw/puv3_dma.c: In function 'puv3_dma_read':
 /src/qemu/hw/puv3_dma.c:44:5: error: 'ret' may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
 cc1: all warnings being treated as errors


Thanks Blue.
I can't get these errors in my server. Perhaps gcc versions are different,
and my gcc is 4.4.3. Maybe, new gcc check each branch of switch statement?
I will correct these errors, and resend the patch series.
Besides, because openrisc32 had been merged into qemu, I need adjust the
value of QEMU_ARCH_UNICORE32. Is 0x4000 proper? Or it has to be 16384?

Thanks  Regards,
Guan Xuetao

Re: [Qemu-devel] [PATCHv3 1/3] unicore32: Split UniCore-F64 instruction helpers from helper.c

[guanxuetao]

 On Wed, Aug 1, 2012 at 3:07 AM,  g...@mprc.pku.edu.cn wrote:
 From: Guan Xuetao g...@mprc.pku.edu.cn

 This patch just splits ucf64 instruction simulation helpers from
 helper.c.
 Also, two checkpatch warnings are solved.

 v1-v2: adjust copyright information for new ucf64_helper.c

 The patches don't apply, do they depend on the pull?


These patches depend on the patches of unicore32-softmmu.
I'm sorry for not saying it explicitly.

Thanks  Regards,
Guan Xuetao

Re: [Qemu-devel] [PATCHv2] unicore32-softmmu: Add a minimal curses screen support

[guanxuetao]

 Am 01.08.2012 05:09, schrieb g...@mprc.pku.edu.cn:

 Why is a TCG helper missing with curses directly? Shouldn't that use
 QEMU's console infrastructure and leave it to the user whether to use
 curses as a backend at runtime?

 What is the problem you are trying to solve? If you just need scrolling
 support you can already use -curses, -nographic and friends...

 Regards,
 Andreas


What we need is an output screen. The kernel (and busybox) outputs every
char to cp1, and curses is used to just print it on the screen.
This approach can generate the result as similar as the real debugging
situations when we use fpga boards and debug boards to debug linux kernel.
We need -curses to enable curses support, but we have no serial port
support at present, so -nographic doesn't work.

Thanks  Regards

Guan Xuetao

Re: [Qemu-devel] [PATCHv4 07/14] unicore32-softmmu: Add puv3 soc/board support

[guanxuetao]

 2012/7/13 Guan Xuetao g...@mprc.pku.edu.cn:
 This patch only add puv3 soc/board support, which introduces puv3
 machine description, and specifies console type.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  default-configs/unicore32-softmmu.mak |1 +
  hw/puv3.c |   93
 +
  hw/puv3.h |   49 +
  hw/unicore32/Makefile.objs|5 ++
  4 files changed, 148 insertions(+), 0 deletions(-)
  create mode 100644 hw/puv3.c
  create mode 100644 hw/puv3.h

 diff --git a/default-configs/unicore32-softmmu.mak
 b/default-configs/unicore32-softmmu.mak
 index 5f04fe3..726a338 100644
 --- a/default-configs/unicore32-softmmu.mak
 +++ b/default-configs/unicore32-softmmu.mak
 @@ -1 +1,2 @@
  # Default configuration for unicore32-softmmu
 +CONFIG_PUV3=y
 diff --git a/hw/puv3.c b/hw/puv3.c
 new file mode 100644
 index 000..0dc129d
 --- /dev/null
 +++ b/hw/puv3.c


 +static QEMUMachine puv3_machine = {
 +.name = puv3,
 +.desc = PKUnity Version-3 based on UniCore32,
 +.init = puv3_init,
 +.use_scsi = 0,
 Since there is only one machine type for unicore32 architecture,
 is_default field should be set  to 1, so that find_default_machine()
 returns with non-null value.

Thanks for pointing it out. I'll add a patch on this one.

Regards,
Guan Xuetao


 +};
 +
 +static void puv3_machine_init(void)
 +{
 +qemu_register_machine(puv3_machine);
 +}
 +
 +machine_init(puv3_machine_init)

 --
 Best Regards,

 Dunrong Huang

Re: [Qemu-devel] [PATCHv3 07/14] unicore32-softmmu: Add puv3 soc/board support

[guanxuetao]

 On Wed, Jun 20, 2012 at 1:56 AM, Guan Xuetao g...@mprc.pku.edu.cn wrote:
 On Mon, 2012-06-18 at 20:02 +, Blue Swirl wrote:
 [snip]
  diff --git a/hw/puv3.h b/hw/puv3.h
  new file mode 100644
  index 000..bcfc978
  --- /dev/null
  +++ b/hw/puv3.h
  @@ -0,0 +1,49 @@
  +/*
  + * Misc PKUnity SoC declarations
  + *
  + * Copyright (C) 2010-2012 Guan Xuetao
  + *
  + * This program is free software; you can redistribute it and/or
 modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation, or any later version.
  + * See the COPYING file in the top-level directory.
  + */
  +#ifndef __PUV3_H__

 Use of leading underscores is reserved to Posix, please use for
 example HW_PUV3_H.
 Ok, I will change it.
 Perhaps I'm wrong, but IMHO, leading underscores are used pervasively
 for headers protection and low-level definitions.

 It's unfortunately common, but as mentioned in HACKING file, those are
 reserved to C and POSIX use. For example Linux kernel can disregard
 this, because it doesn't use libc and GCC does not exercise the right
 to use the reserved prefixes. I guess some people copy this style to
 applications where it's no longer correct.

I see. Thanks for your explanation.

Guan Xuetao

Re: [Qemu-devel] [PATCHv3 12/14] unicore32-softmmu: Add puv3 dma support

[guanxuetao]

 On Wed, Jun 20, 2012 at 2:10 AM, Guan Xuetao g...@mprc.pku.edu.cn wrote:
 On Mon, 2012-06-18 at 19:59 +, Blue Swirl wrote:
 [snip]

 hw_error() also aborts, it would be nice to avoid that. However, the
 situation is somewhat different from the instruction case, since only
 privileged guest code (kernel) can write to hardware. The kernel can
 also for example power off the machine.

 It's the same problem as cpu_abort. Warning information is enough here.
 Is there a global and simple way to do it, g_warning()?

 The users will probably not be very interested about any debugging
 messages. In cases like this, two common ways are to use trace points
 or debugging printf macros.

I see. I will re-consider all cpu_abort and hw_error calls.

Thanks  Regards.

Guan Xuetao

Re: [Qemu-devel] [PATCHv3 02/14] unicore32-softmmu: Add coprocessor 0(sysctrl) and 1(ocd) instruction support

[guanxuetao]

[snip]
  +unrecognized:
  + �� ��cpu_abort(env, Wrong register (%d) or wrong operation (%d) in
 cp0_set!\n,
  + �� �� �� �� �� ��creg, cop);

 The call to cpu_abort() would mean that the guest is able to terminate
 QEMU at will, which is not OK. What does real HW do?
 In my opinion, I just want to terminate qemu when any unhandled or
 unknown operations happen.

 This can make the emulator vulnerable in the security sense. Probably
 Unicore CPUs are not used now in an environment where the guest can
 not be trusted (like cloud computing), but who knows the future?
Is it proper to print such information to monitor? by using monitor_printf().

[snip]


 The printout should be enabled only for DEBUG_UC32.
 Here, I just want to print a char in the text console.
 I tried printw and addch under curses environment, but their color
 schemes had some problems in my server, and I must call scrollok() at
 every new-line. (scrl() didn't work) So, I left printf here to output a
 character from ocd_console in kernel, and it works.

 It breaks the abstraction layer. CPUs very rarely have any direct
 instructions for high level I/O (like console output), instead I/O is
 handled via devices which are accessible via MMIO (or I/O ports for
 x86).

 For debugging, anything can be possible, but that's why I suggested
 using DEBUG_UC32.

I've found my errors. I'm going to use waddch() here. Please see my next
version.

Thanks  Regards,
Guan Xuetao

Re: [Qemu-devel] [PATCHv3 02/14] unicore32-softmmu: Add coprocessor 0(sysctrl) and 1(ocd) instruction support

[guanxuetao]

  Does this pass scripts/checkpatch.pl? These should become
  if (cop != 0) {
  goto unrecognized;
  }
 Thanks for pointing it out, and sorry for that.
 I will correct it in next version.

   You can run scripts/checkpatch.pl before you submit the patch.

 Regards,
 chenwj


Thanks, I will check  my patches.

Guan Xuetao

Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu

[guanxuetao]

 Am 28.05.2012 11:43, schrieb guanxue...@mprc.pku.edu.cn:
 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  target-unicore32/cpu.c |   17 +
  target-unicore32/cpu.h |2 +-
  2 files changed, 14 insertions(+), 5 deletions(-)

 diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
 index de63f58..62c0a22 100644
 --- a/target-unicore32/cpu.c
 +++ b/target-unicore32/cpu.c
 @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj)
  UniCore32CPU *cpu = UNICORE32_CPU(obj);
  CPUUniCore32State *env = cpu-env;

 -env-cp0.c0_cpuid = 0x40010863;
 +env-cp0.c0_cpuid = UC32_CPUID_UCV2;

 Please don't revert this change. I'll send you the patch to drop the
 CPUID #defines instead.

 But, the kernel need this CPUID to check whether it is a unicore32
 processor, and if check fail, the kernel will halt.

 I'm not discussing about a guest kernel but about your source change
 above: The UC32_CPUID_UC32 #define should go away, i.e. please ack
 (today, if we want it in 1.1) and prepend my patch, and if the value is
 wrong here it should be changed *here* and not in UC32_CPUID_UCV2.

 If you're introducing new uses of UC32_CPUID_UCV2 elsewhere (e.g., for
 register behavior) then that is a design fault and needs to be fixed.
 Compare the copro series for target-arm, which gets rid of the
 CPUID-based switches there.

 Andreas
Ok, I see.
Thanks for your explanation.
I will rebase my repo on qom-cpu-unicore32-v1.2 branch.

Guan Xuetao

Re: [Qemu-devel] [PATCH 8/9] unicore32-softmmu: add config and makefile support

[guanxuetao]

 Am 28.05.2012 12:08, schrieb guanxue...@mprc.pku.edu.cn:
 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 This patch adds configure and makefile support for unicore32-softmmu.
 All puv3-soc devices are put into hw/pkunity directory, so this dir
 will be added when unicore32-softmmu is selected.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  Makefile.target   |5 +
  arch_init.c   |2 ++
  arch_init.h   |1 +
  configure |4 
  default-configs/unicore32-softmmu.mak |4 
  5 files changed, 16 insertions(+), 0 deletions(-)
  create mode 100644 default-configs/unicore32-softmmu.mak

 diff --git a/Makefile.target b/Makefile.target
 index 1582904..2f850d3 100644
 --- a/Makefile.target
 +++ b/Makefile.target
 @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o
  obj-xtensa-y += core-dc233c.o
  obj-xtensa-y += core-fsf.o

 +obj-unicore32-y += uc32_softmmu.o
 +obj-unicore32-y += pkunity/puv3.o
 +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o
 pkunity/puv3_gpio.o
 +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o
 [snip]

 You need to put the Makefile/configure changes into the patches that
 introduce the files please, otherwise they cannot be checked for
 compiler warnings/errors.

 I think the patch series is considered as a whole, and only
 compiling/building one device sim-code doesn't make sense. In fact, when
 unicore32-softmmu not enabled, the device sim-code isn't going to be
 compiled at all.

 Well, we expect each patch in a series to build warning-free for
 bisectability (even if applied in one PULL), and only compiling things
 in the final patch does not help. The series should be ordered so that
 we can either manually enable it with --target-list=unicore32-softmmu
 until it finally gets enabled by default, or like the openrisc target
 enables itself by default with some stubs and refines itself over the
 next patches.

 The other aspect is to make it easy for humans to review your patches
 before they can get applied, and personally I find it easier to review
 small patches. But opinions are divided on that. The criteria for
 acceptance is not just whether your kernel works in the end [*], my
 concern is more about how its design aligns with upstream trends like
 QOM awareness.
I see.
Thanks.


 Another thing: It is advisable to place SoC devices (as opposed to the
 machine) into Makefile.objs (hw-unicore32-y) so that they get compiled
 into libhw32 rather than into the target's directory. That avoids
 duplicates when a second endianness or a 64-bit version is introduced.
 (Yes, some existing targets violate that principle. I am working towards
 fixing it.)
Thanks. That's exactly what I want to know.


 Andreas

 [*] It would be helpful if you could share linux-user and softmmu
 binaries on the Wiki for us to avoid regressions.
 http://wiki.qemu.org/Testing

I'm wandering who maintains Testing, then I could handin unicore32 testcase.

Thanks  Regards,
Guan Xuetao

Re: [Qemu-devel] [PATCH 7/9] unicore32-softmmu: add puv3 soc support

[guanxuetao]

 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 This patch only add minimal necessary system-control modules simulation
 for successfully kernel booting and busybox running.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  hw/pkunity/puv3.c  |  130 +
  hw/pkunity/puv3.h  |   49 
  hw/pkunity/puv3_dma.c  |  109 ++
  hw/pkunity/puv3_gpio.c |  141
 
  hw/pkunity/puv3_intc.c |  135
 ++
  hw/pkunity/puv3_ost.c  |  151
 
  hw/pkunity/puv3_pm.c   |  148
 +++
  7 files changed, 863 insertions(+), 0 deletions(-)
  create mode 100644 hw/pkunity/puv3.c
  create mode 100644 hw/pkunity/puv3.h
  create mode 100644 hw/pkunity/puv3_dma.c
  create mode 100644 hw/pkunity/puv3_gpio.c
  create mode 100644 hw/pkunity/puv3_intc.c
  create mode 100644 hw/pkunity/puv3_ost.c
  create mode 100644 hw/pkunity/puv3_pm.c

 Added a subdirectory without adapting configure and possibly Makefiles
 will break out-of-tree builds. Can't you just name the files
 puv3_something.[ch] as done for other SoCs?

 Andreas

Every time, when I 'ls' the source tree of qemu or qemu/hw, it will
generate a terrible and over-one-screen output. So, I think a new
subdirectory makes it more clear (well-organized) and effective.

Guan Xuetao

Re: [Qemu-devel] [PATCH 8/9] unicore32-softmmu: add config and makefile support

[guanxuetao]

 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 This patch adds configure and makefile support for unicore32-softmmu.
 All puv3-soc devices are put into hw/pkunity directory, so this dir
 will be added when unicore32-softmmu is selected.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  Makefile.target   |5 +
  arch_init.c   |2 ++
  arch_init.h   |1 +
  configure |4 
  default-configs/unicore32-softmmu.mak |4 
  5 files changed, 16 insertions(+), 0 deletions(-)
  create mode 100644 default-configs/unicore32-softmmu.mak

 diff --git a/Makefile.target b/Makefile.target
 index 1582904..2f850d3 100644
 --- a/Makefile.target
 +++ b/Makefile.target
 @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o
  obj-xtensa-y += core-dc233c.o
  obj-xtensa-y += core-fsf.o

 +obj-unicore32-y += uc32_softmmu.o
 +obj-unicore32-y += pkunity/puv3.o
 +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o
 pkunity/puv3_gpio.o
 +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o
 [snip]

 You need to put the Makefile/configure changes into the patches that
 introduce the files please, otherwise they cannot be checked for
 compiler warnings/errors.

 Andreas
I think the patch series is considered as a whole, and only
compiling/building one device sim-code doesn't make sense. In fact, when
unicore32-softmmu not enabled, the device sim-code isn't going to be
compiled at all.

Guan Xuetao

Re: [Qemu-devel] [PATCH 6/9] unicore32-softmmu: add generic cpu state save/load functions

[guanxuetao]

 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 This patch adds generic cpu state save/load functions for UniCore32 ISA.
 All architecture related registers are saved or loaded, and no
 optimization.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  target-unicore32/machine.c |   99
 
  1 files changed, 99 insertions(+), 0 deletions(-)
  create mode 100644 target-unicore32/machine.c

 diff --git a/target-unicore32/machine.c b/target-unicore32/machine.c
 new file mode 100644
 index 000..e8c52cd
 --- /dev/null
 +++ b/target-unicore32/machine.c
 @@ -0,0 +1,99 @@
 +/*
 + * Generic machine functions for UniCore32 ISA
 + *
 + * Copyright (C) 2010-2012 Guan Xuetao
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation, or any later version.
 + * See the COPYING file in the top-level directory.
 + */
 +#include hw/hw.h
 +
 +void cpu_save(QEMUFile *f, void *opaque)
 +{
 +int i;
 +CPUUniCore32State *env = (CPUUniCore32State *)opaque;
 +
 +for (i = 0; i  32; i++) {
 +qemu_put_be32(f, env-regs[i]);
 +}
 +qemu_put_be32(f, cpu_asr_read(env));
 +qemu_put_be32(f, env-bsr);
 [snip]

 Please use VMState instead.

 Andreas

Thanks, I will try it.

Guan Xuetao

Re: [Qemu-devel] [PATCH 6/9] unicore32-softmmu: add generic cpu state save/load functions

[guanxuetao]

 Hi Guan,

 +void cpu_save(QEMUFile *f, void *opaque)
 +{
 +int i;
 +CPUUniCore32State *env = (CPUUniCore32State *)opaque;
 +
 +for (i = 0; i  32; i++) {
 +qemu_put_be32(f, env-regs[i]);
 +}
 +qemu_put_be32(f, cpu_asr_read(env));
 +qemu_put_be32(f, env-bsr);
 +for (i = 0; i  6; i++) {
 +qemu_put_be32(f, env-banked_bsr[i]);
 +qemu_put_be32(f, env-banked_r29[i]);
 +qemu_put_be32(f, env-banked_r30[i]);
 +}
 +
 +qemu_put_be32(f, env-cp0.c0_cpuid);
 +qemu_put_be32(f, env-cp0.c0_cachetype);
 +qemu_put_be32(f, env-cp0.c1_sys);
 +qemu_put_be32(f, env-cp0.c2_base);
 +qemu_put_be32(f, env-cp0.c3_faultstatus);
 +qemu_put_be32(f, env-cp0.c4_faultaddr);
 +qemu_put_be32(f, env-cp0.c5_cacheop);
 +qemu_put_be32(f, env-cp0.c6_tlbop);
 +
 +qemu_put_be32(f, env-features);
 +
 +if (env-features  UC32_HWCAP_UCF64) {
 +for (i = 0;  i  16; i++) {
 +CPU_DoubleU u;
 +u.d = env-ucf64.regs[i];
 +qemu_put_be32(f, u.l.upper);
 +qemu_put_be32(f, u.l.lower);
 +}
 +for (i = 0; i  32; i++) {
 +qemu_put_be32(f, env-ucf64.xregs[i]);
 +}
 +}
 +}

   Do you think use VMState rather then QEMUFile is a good idea?
 I saw OpenRISC target got this kind of feedback before [1].

 Regards,
 chenwj

 [1] http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02457.html

Yes, the similar problems occured in both openrisc and unicore32.
Thanks for your guidence.

Guan Xuetao

Re: [Qemu-devel] [PATCH 7/9] unicore32-softmmu: add puv3 soc support

[guanxuetao]

 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 This patch only add minimal necessary system-control modules simulation
 for successfully kernel booting and busybox running.

 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  hw/pkunity/puv3.c  |  130 +
  hw/pkunity/puv3.h  |   49 
  hw/pkunity/puv3_dma.c  |  109 ++
  hw/pkunity/puv3_gpio.c |  141
 
  hw/pkunity/puv3_intc.c |  135
 ++
  hw/pkunity/puv3_ost.c  |  151
 
  hw/pkunity/puv3_pm.c   |  148
 +++
  7 files changed, 863 insertions(+), 0 deletions(-)
  create mode 100644 hw/pkunity/puv3.c
  create mode 100644 hw/pkunity/puv3.h
  create mode 100644 hw/pkunity/puv3_dma.c
  create mode 100644 hw/pkunity/puv3_gpio.c
  create mode 100644 hw/pkunity/puv3_intc.c
  create mode 100644 hw/pkunity/puv3_ost.c
  create mode 100644 hw/pkunity/puv3_pm.c

 Added a subdirectory without adapting configure and possibly Makefiles
 will break out-of-tree builds. Can't you just name the files
 puv3_something.[ch] as done for other SoCs?

 Andreas

Every time, when I 'ls' the source tree of qemu or qemu/hw, it will
generate a terrible and over-one-screen output. So, I think a new
subdirectory makes it more clear (well-organized) and effective.

Guan Xuetao

Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu

[guanxuetao]

 Am 25.05.2012 13:29, schrieb Guan Xuetao:
 Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
 ---
  target-unicore32/cpu.c |   17 +
  target-unicore32/cpu.h |2 +-
  2 files changed, 14 insertions(+), 5 deletions(-)

 diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
 index de63f58..62c0a22 100644
 --- a/target-unicore32/cpu.c
 +++ b/target-unicore32/cpu.c
 @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj)
  UniCore32CPU *cpu = UNICORE32_CPU(obj);
  CPUUniCore32State *env = cpu-env;

 -env-cp0.c0_cpuid = 0x40010863;
 +env-cp0.c0_cpuid = UC32_CPUID_UCV2;

 Please don't revert this change. I'll send you the patch to drop the
 CPUID #defines instead.

But, the kernel need this CPUID to check whether it is a unicore32
processor, and if check fail, the kernel will halt.

Guan Xuetao