[Linux-Xtensa] Running linux in xtensa simulator (Follow the source Luke. xt-gdb is your friend :)

Piet Delaney pdelaney at tensilica.com
Fri Dec 9 13:43:18 PST 2011


Mahavir Prasad wrote:
> Hi Piet,
>
> I have attached the .config file that was used to build linux. I think 
> our kernel versions are different. I had checked out linux with the 
> following command:
>
> git clone 
> git+ssh://rakesh@git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git 
> linux
>
> Could you please try out the version that I am using?

*Hi Mahavir:

This is the same kernel that I'm using.  I didn't see anything in your 
kernel .config that should effect the early startup of the MMU code.

_I'll try to get your Xtrensa Tools and Overlay from your office here in 
the States._
*
*In the simulation it looks like once the kernel jumps to the 1st 
re-mapped context at 0X4000,0000
that the PC isn't changing as it should. It appears to have put 
0x4000004c into ar4, and
then jumped to that location. After that  you (Mahavir) stepped twice 
with 'next' (_would have preferred
using 'step'_)  the PC is still at 0x4000004c; that seems wrong.

I just stepped with 'next' thru the MMU initialization code and I'm not 
getting stuck
at the point of executing in the 1st re-mapping at 0X4000,0000:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*[pdelaney at pdelaney_fc9 linux-2.6.29-smp.xcc]$ *./doit*
Current configuration:  XTCONFIG:DC_D_233L_Avnt60, 
root:MYROOT:/fac/vol6/software/pdelaney/Work/cottonwood_1, 
USEWHAT:ybuild, XTSYSTEM: Jtag
System, xtsysok:.
Current configuration:  XTCONFIG:DC_D_233L_Avnt60, 
root:MYROOT:/fac/vol6/software/pdelaney/Work/cottonwood_1, 
USEWHAT:ybuild, XTSYSTEM: Jtag
System, xtsysok:.
Current buildroot config is dc233c, root 
/export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot
Current buildroot config is dc233c, root 
/export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot
Current configuration:  XTCONFIG:DC_D_233L_Avnt60, 
root:MYROOT:/fac/vol6/software/pdelaney/Work/cottonwood_1, 
USEWHAT:ybuild, XTSYSTEM: Jtag
System, xtsysok:.
Current buildroot config is dc233c, root 
/export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot
ddd -debugger xt-gdb
GNU gdb (GDB) 7.1 Xtensa Tools 9.0.3-development
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=xtensa-elf".
(xt-gdb)* source .xt-gdbinit*
"Using MMU, assumne V2 MMU Mappings
""add-symbol-file vmlinux 0xd0003000
"add symbol table from file "vmlinux" at
        .text_addr = 0xd0003000
"target sim --memlimit=128
"Connected to the simulator.
Breakpoint 1 at 0xfe000104: file arch/xtensa/boot/boot-elf/bootstrap.S, 
line 93.
"Starting Simulation
"Breakpoint 2 at 0xfe000000: file arch/xtensa/boot/boot-elf/bootstrap.S, 
line 44.
Breakpoint 3 at 0xd0003003: file arch/xtensa/kernel/head.S, line 66.
Breakpoint 4 at 0xd000303a: file arch/xtensa/kernel/head.S, line 190.
".xt-gdbinit: Done
"(xt-gdb)* break _SetupMMU *
Breakpoint 5 at 0xfe000043: file 
/export2/DC_C_233L/src/linux-2.6.29-smp.xcc/arch/xtensa/include/asm/initialize_mmu.h, 
line 87.
(xt-gdb) run
Starting program: 
/export2/DC_C_233L/src/linux-2.6.29-smp.xcc/arch/xtensa/boot/Image.elf
Starting the ISS simulator.
Switching to remote protocol
Remote debugging using localhost:58376

Breakpoint 5, _SetupMMU () at 
/export2/DC_C_233L/src/linux-2.6.29-smp.xcc/arch/xtensa/include/asm/initialize_mmu.h:89
89              wsr     a3, ATOMCTL
(xt-gdb) *n*
178             movi    a1, 0           // Set $sp to NULL to minimize 
gdb confusion trying to walk up the stack
(xt-gdb)* <CR>*
180             _call0  1f              // get PC in a PIC manner (don't 
rely on literal constants)
(xt-gdb) *<CR>*
186     1:      movi    a2, 0x10000000
(xt-gdb)
187             movi    a3, 0x18000000
(xt-gdb)
188             add     a2, a2, a0      // a2 = 0x10000000 + original_pc
(xt-gdb)
189             bltu    a2, a3, 1f      // is PC >= 0xF0000000, or PC < 
0x08000000 ?
(xt-gdb)
200             movi    a2, 0x40000006  // 512MB region at vaddr 
0x40000000, way 6
(xt-gdb)
201             idtlb   a2              // kick it out...
(xt-gdb)
202             iitlb   a2
(xt-gdb)
203             isync
(xt-gdb)
211             srli    a3, a0, 27              // get 128MB area 
containing PC ...
(xt-gdb)
212             slli    a3, a3, 27              // ...
(xt-gdb)
213             addi    a3, a3, CA_BYPASS       // bypass-cache access 
R/W Executable
(xt-gdb)
214             addi    a7, a2, -1              // 128MB region at vaddr 
0x40000000, way 5
(xt-gdb)
215             wdtlb   a3, a7                  // setup mapping...
(xt-gdb)
216             witlb   a3, a7                  // ...
(xt-gdb)
217             isync                           // ...
(xt-gdb)
226             slli    a4, a0, 5       // clear upper 5 bits of PC (get 
128MB relative offset)
(xt-gdb)
227             srli    a4, a4, 5       // ...
(xt-gdb)
228             addi    a5, a2, -6      // a5 = 0x40000000
(xt-gdb)
229             add     a4, a4, a5      // address of above "j 2f" in 
128MB page at vaddr 0x40000000
(xt-gdb)
*230             jx      a4              // Note: jumps to 0x46000043; 
xt-gdb switches to remapped text section  *      *[Last instruction seen 
in your (Mahavir's) gdb log]*
(xt-gdb)
*181     0:      j       2f              // a0 = pc; NOTE: we get here 
AGAIN in Step 2b after remapping to 0X46000000 * *[You don't seem to get 
to this instruction being executed]*
(xt-gdb)
*240     2:      movi    a4, 
0x20000000                                                                                
**[You don't  seem to get to this instruction being executed]*
(xt-gdb)
241             add     a5, a2, a4      // start at 0x60000000 (+6 for 
way 6)
(xt-gdb)
242     3:      idtlb   a5              // invalidate entry...
(xt-gdb)
243             iitlb   a5
(xt-gdb)
244             add     a5, a5, a4
(xt-gdb)
245             bne     a5, a2, 3b      // loop until we get to 0x40000000
(xt-gdb) where
#0  ?? () at 
/export2/DC_C_233L/src/linux-2.6.29-smp.xcc/arch/xtensa/include/asm/initialize_mmu.h:245
(xt-gdb) *
**----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-piet
  *

>
>
>     I'd get curious. For starters I'd do a <control-C> and see what
>     it's doing. If you use the
>     .xt-gdbinit script it will put breakpoints in some early startup
>     points. If you don't get to
>     the 1st breakpoint that plants the other breakpoints you make have
>     to single step
>     from the very 1st instruction and walk thru the MMU
>     initialization. This code does
>     some harry stuff but I went to extreme effort to make it possible
>     to single step
>     completely thru the code and the debugger clearly showing you the
>     code your
>     executing.
>
>     If you aren't getting to the 1st breakpoint, "set_breakpoints",
>     I'd put a breakpoint
>     at the reset vector before doing the  "run" command. Look at your
>     log and compare
>     it to mine, if you use the same .xt-gbinit script the log should
>     be identical.
>
>     Relax, it's time to dive in and look closely at what's happening.
>     It's a journey and time to be curious.  ;-)
>      
>
>
> I have attached log file  (linux_bootup_on_iss_log01.txt) of my steps. 
> Curiously, the first time when I say "run" breakpoint is not hit. 
> However, if I do ^C twice and say "run" again, then breakpoint is hit. 
> This is a consistent behavior whenever I start xt-gdb.
>
> Last few lines from the log:
>
> (xt-gdb) n
> _SetupMMU () at 
> /home/mahavir/Desktop/lahaina/git_checkout/lah_build/linux/arch/xtensa/include/asm/initialize_mmu.h:230
> 230        jx    a4        // Note: jumps to 0x46000043; xt-gdb 
> switches to remapped text section
> (xt-gdb) n
> 0x4000004c in ?? ()
> (xt-gdb) n
> Cannot find bounds of current function
>
>  
>
>     Let us know if there is anything we can do to help in cutting the
>     Turbo License.
>     If your not getting to the two breakpoints at the begining of
>     kernel startup I'd
>     focus on that problem for now._ Even without Turbo you should get
>     to these
>     breakpoints easily within a minute; seconds as I recall.
>     _
>
>
> Yes, the second time when the breakpoint is hit is within 10-20 
> seconds. I will check with Rakesh again regarding the Turbo license. 
> The last we heard from him he said:
> >>What are the steps to cut a Turbo License from XPG account? I can 
> login into the Nethra’s XPG account.
> So, if you  have steps for the same, could you please mail it to him?
>
> Thanks and Regards,
> Mahavir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-xtensa.org/pipermail/linux-xtensa/attachments/20111209/af1123db/attachment.html


More information about the linux-xtensa mailing list