[K42-discussion] Porting K42 to Power5

[Michal Ostrowski]

As Amos pointed out to me, you actually need to be using the code-base
that he's working on which has a re-done boot program that should deal
with this.  So if you don't want to waste time, you can wait for that.

If you're feeling lucky (or your head is able to withstand multiple
self-inflicted bashings against the nearest brick wall) you can try
debugging this.

One trick you can use is to put in statements to set r14 to indicate how
much progress you've made  e.g.:


volatile uval64 r14 asm("r14");

....
r14 = __LINE__;
....


Chances are though that you're dying in the assembly code between the
boot program and the K42 C++ entry point.  In which case you'd have to
pull this trick in the asm code.

When your kernel crashes, the firmware crash dump should show you the
value of r14 in the register dump.

Another trick is to try to hard-code H_PUT_TERM_CHAR hcalls, which will
results in characters being printed to the console to track your
progress.  (Doing this inside the assembly code is actually easier than
in the C code.)

-- 
Michal Ostrowski <mostrows at watson.ibm.com>



On Mon, 2006-01-30 at 11:36 -0500, Livio Soares wrote:
>   Howdy folks,
> 
> 
>   We  (University of  Toronto) are  beginning  efforts to  port K42  to our  new
> machine,  an  OpenPower with  4  Power5  processors.  So  far  we  have made  no
> progress, and  are trying  to understand some  of the  early issues we  run into
> during  the boot-up  process.   Hopefully,  someone over  there  (IBM) has  more
> experience or access to documentation to provide some insight for us.
> 
>   Currently,  we  have tried  to  boot  up K42  code  as-is,  and  ran into  the
> following:
> 
> ////////////************************************************///////////////////
> 
> Cannot adjust timebase, no rtas token
> BSS will be cleared after closing OpenFirmware.
>      From       To           Mapping Description
> [00000000 00003000] C000000000000000 exception vector
> [01FFC000 02000000] C000000001FFC000 bootInfo
> [02000000 05000000] C000000002000000 kernel image
> [05F00000 06000000]         unmapped OF dev tree
> [07720000 07734000] C000000007720000 boot stack
> [07734000 08000000]         unmapped rtas
> [08000000 10000000]         unmapped page table
> [10000000 10001000]         unmapped segment table
> 
> About to jump to K42...
>     asr:              0000000010000001
>     sdr1:             0000000000000000
>     msr:              A000000000001030
>     iar:              C00000000216E0BC
>     TOC address:      C000000002EB0450
>     stack pointer:    C000000007733F00
>     bootInfo address: C000000001FFC000
>     rtas base:        0000000007734000
>     rtas entry:       00000000077343A4
>     availCPUs:        0000000000000055
>     masterCPU:        0000000000000000
>     serial port:      0000000000000000
>     CPU version:      000000000000003A
>     onSim:            0000000000000000
>     onHV:             0000000000000001
>     platform:         0000000000000101
> before launching to kernel
> DEFAULT CATCH!, exception-handler=fff00700 
> at   %SRR0: 0000000000000480   %SRR1: 8000000000081000 
> Call History
> ------------
> throw  - c3903c 
> abort  - c44ce8 
> getphndl  - c7e640 
> ~getprop  - c7eb84 
> catch  - c38fe8 
> cicall  - c7e468 
> cientry  - c39aa4 
> _syscatch  - c4d768 
> _syscatch  - c4d768 
> invalid pointer - 0 
> invalid pointer - 0 
> invalid pointer - 0 
> invalid pointer - 0 
> invalid pointer - 0 
> invalid pointer - 0 
> invalid pointer - 0 
> 
> Client's Fix Pt Regs:
>  00 00000000018bfcb0 c000000007733f00 c000000002eb0450 c000000001ffc000
>  04 0000000000000000 0000000000000000 c00000000216e0bc a000000000001030
>  08 0000000000000000 0000000010000001 0000000000000000 00000000018bfc60
>  0c 0000000001ffc000 0000000000000000 0000000000000000 0000000000000000
>  10 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  14 0000000000c00000 0000000000000008 0000000000000000 0000000000000000
>  18 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  1c 0000000000000010 0000000001ffc000 000000000071f3b8 00000000018bfc60
> Special Regs:
>     %IV: 00000700     %CR: 20000004    %XER: 20000000  %DSISR: 00000000 
>   %SRR0: 0000000000000480   %SRR1: 8000000000081000 
>     %LR: 0000000000702d14    %CTR: 0000000000c39a48 
>    %DAR: 0000000000000000 
> Virtual PID = 0 
> PFW: Unable to send error log!
>  ok
> 0 > 
> 
> ////////////************************************************///////////////////
> 
>   As far  as I  can understand it  from instrumenting  the code, and  using some
> scratch registers for tags, we get to the launch() procedure in
> os/boot/arch/powerpc/asm_utils.S,   and   reach    the   'rfid'   (return   from
> interrupt). The PC is set to start() in kinit.C correctly. 
> 
>   However, we get an 'Instruction Segment Interrupt'. At this point int the boot
> up  there is  no  handler for  instruction  segment exceptions,  so some  random
> instruction is executed at 0x480 (value of SRR0), and the 'Program Interrupt' is
> raised at 0x700.  Apparently, open-firmware has a default  exception handler for
> it and spits all the registers out (see above). 
> 
>   So, as far  as I can see, there  is a problem with the setup  of K42's initial
> page-tables. The first  instruction from start() fails to be  fetched and we get
> the instruction segment  interrupt. I tried installing an  exception handler for
> 'instruction segment'  interrupt and  have verified that  SRR0 is, in  fact, the
> address of the first instruction of start():kinit.C.
> 
>   I have compared Linux's boot up code  from the Power5 and K42's, and they seem
> very  similar.  Both  are  using  H_ENTER  hypervisor  call  to  establish  page
> mappings. 
> 
>   I'm a little lost to where the problem could be... Any ideas? 
> 
>   Thanks a lot! 
> 
> 			Livio
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion