Re: [Qemu-ppc] Booting AIX on qemu-system-ppc, kernel not started successfully

[Alexander Graf]

On 02/23/2012 09:22 AM, Liang Guo wrote:
> On Thu, Feb 23, 2012 at 4:03 PM, Alexander Graf<address@hidden>  wrote:
> > On 23.02.2012, at 09:01, Liang Guo wrote:
> >
> > > On Thu, Feb 23, 2012 at 3:35 PM, Alexander Graf<address@hidden>  wrote:
> > > > On 23.02.2012, at 08:32, Liang Guo wrote:
> > > >
> > > > > On Thu, Feb 23, 2012 at 3:14 PM, Alexander Graf<address@hidden>  wrote:
> > > > > > On 23.02.2012, at 08:13, Liang Guo wrote:
> > > > > >
> > > > > > > On Thu, Feb 23, 2012 at 2:26 PM, Alexander Graf<address@hidden>  wrote:
> > > > > > > > It looks like the disassembler in gdb is configured for something odd, yeah. 
> > > > > > > > POWER1 maybe.
> > > > > > > >
> > > > > > > > Try to run "log in_asm,cpu,int" on the qemu monitor right at the AIX entry 
> > > > > > > > point. The disassembly log should be in /tmp/qemu.log then.
> > > > > > > >
> > > > > > > > Alternatively, you can of course try to use a gdb that works ;).
> > > > > > > >
> > > > > > > > Alex
> > > > > > > Too more information generated with log in_asm,cpu,int. the qemu.log is
> > > > > > > attached, hope it is useful. but the asm code is buggy too.
> > > > > > Hrm, I don't see the CPU states and interrupt information in here. Mind to post 
> > > > > > the complete log somewhere? At http://paste.debian.net for example :)
> > > > > >
> > > > > >
> > > > > > Alex
> > > > > it is too large, more than 1G, the log may interruppted, for my /tmp
> > > > > is full, I'll generated it asap
> > > > > and upload it to somewhere
> > > > Well, we're only interested in the first few hundred lines. After that it's 
> > > > stuck in an endless loop and just prints out its cpu state needlessly. Just cut 
> > > > it off after a few iterations of:
> > > >
> > > >   0x000000000000004c:  blt+    0x40
> > > >
> > > >
> > > > Alex
> > > This is the log between 0x3c with several loop between  0x40 and 0x48
> > > http://paste.debian.net/157274/,
> > >
> > > the most part of the log is between 0x2c and 0x38, it is about 1.6G
> > I was actually rather thinking of doing the log from AIX entry point until the 
> > part where you cut it off at the end.
> >
> > So here, r16 is 0, but the code isn't expecting it to be 0. Try to find out why 
> > r16 is 0 and you will know why the loop doesn't end ;)
> >
> >
> > Alex
> This is the log between 0x22e28 and 0x2c, hope it will be useful

Ugh. Now you did exactly what you shouldn't do. You posted a >300kb file 
on a mailing list :(. That's why I pointed you to pastebin earlier.... 
Please don't post such a large attachment to mailing lists.

With the following patch to current upstream SLOF (on github) you can 
check for missing device tree entries:

diff --git a/slof/fs/client.fs b/slof/fs/client.fs
index 7ffd506..610a4c1 100644
--- a/slof/fs/client.fs
+++ b/slof/fs/client.fs
@@ -13,7 +13,7 @@

 \ Client interface.

-0 VALUE debug-client-interface?
+1 VALUE debug-client-interface?

 \ First, the machinery.

@@ -125,7 +125,11 @@ ALSO client-voc DEFINITIONS
 ;

 : getprop ( phandle zstr buf len -- len' )
->r>r zcount rot get-property
+>r>r zcount
+   debug-client-interface? IF
+      ." ci: getprop " 2dup type cr
+   THEN
+  rot get-property
   0= IF r>  swap dup r>  min swap>r move r>
   ELSE r>  r>  2drop -1 THEN ;



It's not complete though, Thomas has a more complete version in his queue.

With this, we were able to identify a few shortcomings in the QEMU code, 
most notably:

diff --git a/hw/spapr.c b/hw/spapr.c
index dffb6a2..8b49576 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -315,9 +315,13 @@ static void *spapr_create_fdt_skel(const char 
*cpu_model,
         _FDT((fdt_property_string(fdt, "device_type", "cpu")));

         _FDT((fdt_property_cell(fdt, "cpu-version", env->spr[SPR_PVR])));
-        _FDT((fdt_property_cell(fdt, "dcache-block-size",
+        _FDT((fdt_property_cell(fdt, "d-cache-block-size",
                                 env->dcache_line_size)));
-        _FDT((fdt_property_cell(fdt, "icache-block-size",
+        _FDT((fdt_property_cell(fdt, "d-cache-size",
+                                env->dcache_line_size)));
+        _FDT((fdt_property_cell(fdt, "i-cache-block-size",
+                                env->icache_line_size)));
+        _FDT((fdt_property_cell(fdt, "i-cache-size",
                                 env->icache_line_size)));
         _FDT((fdt_property_cell(fdt, "timebase-frequency", tbfreq)));
         _FDT((fdt_property_cell(fdt, "clock-frequency", cpufreq)));
diff --git a/hw/spapr_rtas.c b/hw/spapr_rtas.c
index c0723b3..c02962b 100644
--- a/hw/spapr_rtas.c
+++ b/hw/spapr_rtas.c
@@ -187,6 +187,14 @@ static void rtas_start_cpu(sPAPREnvironment *spapr,
     rtas_st(rets, 0, -3);
 }

+static void rtas_freeze_time_base(sPAPREnvironment *spapr,
+                                  uint32_t token, uint32_t nargs,
+                                  target_ulong args,
+                                  uint32_t nret, target_ulong rets)
+{
+    rtas_st(rets, 0, 0);
+}
+
 static struct rtas_call {
     const char *name;
     spapr_rtas_fn fn;
@@ -297,6 +305,7 @@ static void core_rtas_register_types(void)
     spapr_rtas_register("query-cpu-stopped-state",
                         rtas_query_cpu_stopped_state);
     spapr_rtas_register("start-cpu", rtas_start_cpu);
+    spapr_rtas_register("freeze-time-base", rtas_freeze_time_base);
 }

 type_init(core_rtas_register_types)


However, AIX still doesn't boot. It does however get past the point 
where you saw it failing, looping at address 00000000003b32b0 for me 
now. I'm out of time to look at this though, so good luck with it!


Alex