[Linux-Xtensa] booting linux in ISS with LX3 core

Low Swee Leong at Low Kwang Hao sleong.low at mimos.my
Mon Jul 19 03:06:18 PDT 2010


Hi
We are building a wimax client device , it is not a router device , so we did not use openWrt .

We just managed to get pass the first jump to remap address , since our reset handler is at 0x3fff0500, we use your latest init_mmu file and change the virtual address of the remap code to 0x60000000 instead of 0x40000000 , and it jump to remap address successfully.

I think it is better for us to put the reset back to 0xfe000000 to avoid further problem..

-----Original Message-----
From: Piet Delaney [mailto:pdelaney at tensilica.com]
Sent: Friday, 16 July, 2010 6:22 PM
To: Low Swee Leong @ Low Kwang Hao
Cc: Piet Delaney; Lam Yat Seng; Marc Gauthier; Piet Delaney; Stephen Chou; linux-xtensa at linux-xtensa.org
Subject: Re: [Linux-Xtensa] booting linux in ISS with LX3 core

Low Swee Leong @ Low Kwang Hao wrote:

I posted the change to the 2.6.29-smp git repo and will very likley post
another, hopefully cleaner, version later today where the XCHAD_*_VMADDR
constants are renamed by the user instead of redefining them like I do
now in asm/core.h.

The code that's currently checked in was running the Linux Test Program (LTP)
for almost an hour without any issues. Hopefully you a progressing on you
port.

BTW, for your project, do you happen to be interested in the router market?
I'm curious in knowing the interest our developers have in the OpenWrt Buildroot
environment as it appears to be further ahead in a number or areas then the code
it was derived from from UcLibc folks; like support for glibc and the more
recent uClibc 0.9.32 which supports Native Posix Threads.

You haven't told us much about what you designing your chip to be used for;
Just curious.

-piet


> Hi
>
> Thanks for all the reply ,
> So far we have tested in Dini board, our SRAM physical address started 0x0 to 0x04000000, which is about 64Mb ,
> We have changed the ResetVector to location 0x3fff0500, thats our IRAM , where the board will start from and also the Alternate Static Vector Group Base Address
> We did not use ROM which resides in 0xfe000000, as it is still under test .
>
> We modify the linker script as well as the mmu initialization code , see attached.
>
> But when we are stepping through the code , seems like we get into Double Exception Vector (0x000023c0), my understanding is that once we go over this
>         wdtlb   a3, a7                  // setup mapping...
>         witlb   a3, a7                  // ...
>         isync                           // ...
>
> the virtual to physical mapping is defined , so we should able to step through correctly , or is there something i have miss ?
>
> Thanks
>
>
> (xt-gdb)
> _SetupMMU ()
>     at /home/sllow/Download/git/linux/arch/xtensa/include/asm/initialize_mmu.h:228
> 228             movi    a4, 0x4600004c
> (xt-gdb)
> _SetupMMU ()
>     at /home/sllow/Download/git/linux/arch/xtensa/include/asm/initialize_mmu.h:229
> 229             jx      a4
> (xt-gdb)
> ?? ()
>     at /home/sllow/Download/git/linux/arch/xtensa/include/asm/initialize_mmu.h:181
> 181     0:      j       2f              // a0 = pc; NOTE: we get here AGAIN in Step 2b after remapping to 0X46000000
> (xt-gdb)
> 0x000023c3 in ?? ()
> (xt-gdb) x /10 0X46000000
> 0x46000000:     Cannot access memory at address 0x46000000
> (xt-gdb)
>
>
>
> [sllow at localhost build-ori]$ xtensa_maccore5-linux-nm Image.elf
> 00000044 a Offset
> 3fff0540 t RomBootParam
> 3fff053c t RomInitAddr
> 46000000 T _RemappedResetVector
> 46000044 t _RemappedSetupMMU
> 3fff0500 T _ResetVector
> 3fff0544 t _SetupMMU
> 00130270 B __bss_end
> 0012fc68 B __bss_start
> 3fff0608 T _bootparam
> d012fc68 D _image_end
> d0001000 D _image_start
> 3fff05fa T reset
> 0012fc70 B spill_location_0
> 0012fe70 B spill_location_1
> 00130070 B spill_location_2
>
>
>
> -----Original Message-----
> From: Piet Delaney [mailto:pdelaney at tensilica.com]
> Sent: Thursday, 8 July, 2010 6:05 PM
> To: Lam Yat Seng
> Cc: Piet Delaney; Low Swee Leong @ Low Kwang Hao; Marc Gauthier; Piet Delaney; Steve Chou; linux-xtensa at linux-xtensa.org
> Subject: Re: [Linux-Xtensa] booting linux in ISS with LX3 core
>
> Lam Yat Seng wrote:
>
> Hi Steven:
>
>> Hi Piet, Marc,
>>
>> My name is Steven I am a colleague of Low working also on the kernel
>> porting.  Thanks for the previous reply below and we are now trying
>> directly with the DINI board.\
>
> I mentioned your working with the DINI board to our of our hardware superstars and he thought we might be able to work closer with you if we had RTL for the ethernet NIC.
>
>
>> As for Piet's previous reply below:
>>
>> "I'll fire off a DC_B_233L. BUILDROOT for it and try that next. Since
>> your using xt-gdb on printk() I take it your already familiar with the
>> tricks of placing breakpoints in V3 MMU code (Documented in
>> linux//Documentation/xtensa/gdbmacros)."
>>
>> There seems to be useful macros there for debugging the MMU V3, but
>> what I saw are a few .gdb and xt-gdbinit file attached, what are the
>> instructions to load and invoke these macros with xt-gdb?  (sorry for
>> the silly question as I am also not too familiar with gdb here except
>> for the basic ones..)
>
> I use the .xt-gdbinit macro to load the breakpoints after the MMU has been re-mapped. I also use the .xt-gdbinit macro to load the .gdb files in that directory.
>
> I've been tweaking .xt-gdbinit macro, even today while debugging.
> There are a number of things that get tricky, like making sure you set breakpoints after the MMU has re-mapped and setting breakpoints in vectors.S after the have been setup. New additions include enabling verify after loading the image.
>
> You might try just doing this process by hand the first time. If you single step (stepi) from the beginning you will end up in the code that re-mapped the MMU. I wrote this so you can even single step thru this code while it's re-mapping, thus being sure never to lose control. At the end of the remapping the code will return bootstrap.S at reset: which is where I have a breakpoint as I recall to set the breakpoints in the kernel.
>
> As a 1st step just try single stepping from the starting point in bootstrap.S that should immediately take you to _SetupMMU which includes arch/xtensa/include/asm/initialize_mmu.h. I wrote this so code so you can continue single stepping thru it. The symbols of the code are defined to both the originally mapped addresses as well as the new linux-style mapped addresses. So as you switch mapping the code will appear in the ddd/xt-gdb window to step as if nothing significant happen. At the end of this #included code you end up back in bootstrap.S at reset: which is a point where it's safe to set the kernel breakpoints.
>
> I'll try to give it a spin again in the near future and make sure nothing has broken. When I last use the V3_MMU it was working great for both uni-processor and SMP bit-streams and kernels.
>
> Hope that helps and you don't mind my Cc: the linux-xtensa mailing list as we started this discussion. I think this kinda of material could be valuable to others in the future.
>
> A few more pointers. Debugging the kernel can be a bit tedious, especially the machine specific stuff. I find it more comfortable to configure the kernel for debugging, compiling it -O0, so that the stack back-traces are complete and variables (locals, formals, and globals) are simply what gdb says they are. If you start xt-gdb with ddd you can see the value of all variables my simply placing the cursor on top the the variable in the code. I usually start xt-gdb with ddd like this:
>
>         exec ddd -debugger xt-gdb -n
>
> We have tried to make it easy for new comers by making the back-traces pass thru exceptions and even the registers at the time of the exception being displayed by gdb correctly. Attached in 'HugeStack' is an example backtrace that I crash in this evening while preparing code to go upstream. As you can see it's crossing exceptions quite a few times. You just click on on the ddd "up" and 'down' buttons and ddd takes you to the code and you just mouse over the code and it pops up the variable values. Just as easy as debugging a normal user space C program in computers 101.
>
> There's a bug or something in ddd which makes it best to start xt-gdb with the -n option and doing the "source .xt-gdbinit" by hand when ddd opens up the command window. If you forget the -n option xt-gdb will automatically source the .xt-gdbinit file.
> The problem is that if you change the .xt-gdbinit file and start ddd again it continues to use the previous versions. I suppose it's considered to be the default sessions and can likely be disabled somehow.
>
> Good luck and keep us posted on your progress. When your starting a new area of work is usually better to ask a lot of questions until you get familiar with the environment.
>
> Here a bit more on gdb macros. In the .xt-gdbinit example you have you will see:
>
> 140 if $debug_reset
> 141     break *&_ResetVector
> 142     set var $_ResetVector = $bpnum
> 143
> 144 #   NOTE: you can't enable this breakpoint while
> 145 #         single stepping in the MMU-V3 remapping
> 146 #         code and mapped to 0x46000000.
> 147 #
> 148     break reset
> 149     set var $reset = $bpnum
> 150     commands $reset
>
> Here $debug_reset is enabling putting a breakpoint in to set the breakpoints at reset. The variable $reset is the breakpoint number of the breakpoint at 'reset'. When it hits the breakpoint it executes the gdb commands starting at 'commands'
> up to the matching 'end'. Today I just tried placing the commands in a separate gdb definition and just invoking 'set_breakpoints'
> macro in the command. Ex:
>
>         commands $reset
>             set_breakpoints
>         end
>
> I've attached it, but keep in mind I'm still messing with it and it not setting breakpoints right yet; it's just an example of using the 'commands' gdb cmd to run the 'set_breakpoints' user-defined function upon hitting a breakpoint at 'reset:' after the MMU has been re-mapped.
>
> -piet
>
>> Thanks in advance,
>> steven
>>
>>
>>
>>
>> -----Original Message-----
>> From: Piet Delaney [mailto:pdelaney at tensilica.com]
>> Sent: Saturday, June 26, 2010 11:37 AM
>> To: Low Swee Leong @ Low Kwang Hao
>> Cc: Marc Gauthier; Piet Delaney; linux-xtensa at linux-xtensa.org; Piet
>> Delaney; Lam Yat Seng
>> Subject: Re: [Linux-Xtensa] booting linux in ISS with LX3 core
>>
>> Low Swee Leong @ Low Kwang Hao wrote:
>>
>> Hi Low Swee:
>>
>>  > In our core configuration , we have the following :
>>  >
>>  >
>>  >
>>  > Memory Protection/MMU       MMU with TLBs and autorefill
>>  >
>>  >   Entries/Way (Inst)     4
>>  >
>>  >   Entries/Way (Data)   4
>>  >
>>  >   System RAM start address / size     0x0 / 128M
>>  >
>>  >   System ROM start address / size     0xfe000000 / 32M
>>  >
>>  >
>>  >
>>  > I would assume MMU is being configured in our core ?
>>
>> I suppose your using the new V3 MMU as said LX2 worked fine but your
>> having problems with vprintk() in with an ISS simulation.
>>
>>  >
>>  >
>>  >
>>  > We are currently using
>>  >
>>  >  DN9000K10PCIE8T from dini group
>>
>> We have a DN9002K10PCU, sexy board, but we haven't tried running linux
>> on it.
>>
>>
>>
>>  >
>>  > I have tried to use the kernel source from  >
>> http://git.linux-xtensa.org/cgi-bin/git.cgi?p=kernel/xtensa-2.6.29-smp
>> .git;a=summary,
>>  >
>>  > Use the configuration as attached , and build the kernel and run in
>> ISS,  > it  has pass through set_cpu_possible but seems to get stuck at vprintk.
>>
>> I tried running my HiFi-2 config which I had a buildroot for and tried
>> it with ISS and got well past the first kernel printk() calls.
>>
>> Clearly say xt-gdb 'next' over line 563:
>>
>>   557 asmlinkage int printk(const char *fmt, ...)
>>   558 {
>>   559         va_list args;
>>   560         int r;
>>   561
>>   562         va_start(args, fmt);
>>   563         r = vprintk(fmt, args);
>>   564         va_end(args);
>>   565
>>   566         return r;
>>   567 }
>>
>> setup_arch() took a while but succeeded.
>> In fact I got up to network initialization and filesystem initialization:
>> ----------------------------------------------------------------------
>> ---------------
>> (gdb) next
>> net_namespace: 520 bytes
>> ^CNET: Registered protocol family 16
>> bio: create slab <bio-0> at 0
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP
>> established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind
>> hash table entries: 4096 (order: 2, 16384 bytes)
>> TCP: Hash tables configured (established 4096 bind 4096) TCP reno
>> registered
>> NET: Registered protocol family 1
>> SIMDISK: major: 240
>> Can't open x: 2
>> Can't open x: 2
>> msgmni has been set to 248
>> io scheduler noop registered (default) Reading in symbols for
>> fs/sysfs/dir.c...done.
>>
>> Program received signal SIGINT, Interrupt.
>> 0xd00bf96f in sysfs_link_sibling (sd=0xd78ab2a0) at fs/sysfs/dir.c:54
>> (gdb) bt
>> Reading in symbols for lib/kobject.c...done.
>> Reading in symbols for drivers/base/core.c...done.
>> Reading in symbols for drivers/char/pty.c...done.
>> #0  0xd00bf96f in sysfs_link_sibling (sd=0xd78ab2a0) at
>> fs/sysfs/dir.c:54
>> #1  0xd00c00c0 in __sysfs_add_one (acxt=0xd781b8dc, sd=0xd78ab2a0) at
>> fs/sysfs/dir.c:431
>> #2  0xd00c0135 in sysfs_add_one (acxt=0xd781b8dc, sd=0xd78ab2a0) at
>> fs/sysfs/dir.c:460
>> #3  0xd00c04d2 in create_dir (kobj=0xd78aaf44, parent_sd=0xd7811450,
>> name=0xd78a5450 "ttyp1", p_sd=0xd781b938) at fs/sysfs/dir.c:656
>> #4  0xd00c0586 in sysfs_create_dir (kobj=0xd78aaf44) at
>> fs/sysfs/dir.c:689
>> #5  0xd00fe30a in create_dir (kobj=0xd78aaf44) at lib/kobject.c:51
>> #6  0xd00fe6ce in kobject_add_internal (kobj=0xd78aaf44) at
>> lib/kobject.c:187
>> #7  0xd00fe890 in kobject_add_varg (kobj=0xd78aaf44,
>> parent=0xd782b008,
>> fmt=0xd01ed0d8 "%s", vargs={__va_stk = 0xd781ba90, __va_reg =
>> 0xd781ba60, __va_ndx = 0xc}) at lib/kobject.c:307
>> #8  0xd00fe905 in kobject_add (kobj=0xd78aaf44, parent=0xd782b008,
>> fmt=0xd01ed0d8 "%s") at lib/kobject.c:352
>> #9  0xd0126ee6 in device_add (dev=0xd78aaf00) at
>> drivers/base/core.c:885 #10 0xd0127119 in device_register
>> (dev=0xd78aaf00) at
>> drivers/base/core.c:991
>> #11 0xd0127530 in device_create_vargs (class=0xd7810500, parent=0x0,
>> devt=0x300001, drvdata=0x0, fmt=0xd781bc04 "ttyp1", args={__va_stk =
>> 0xd781bbe0, __va_reg = 0xd781bbc0, __va_ndx = 0x14}) at
>> drivers/base/core.c:1352
>> #12 0xd01275c9 in device_create (class=0xd7810500, parent=0x0,
>> devt=0x300001, drvdata=0x0, fmt=0xd781bc04 "ttyp1") at
>> drivers/base/core.c:1393
>> #13 0xd010fa48 in tty_register_device (driver=0xd78429c0, index=0x1,
>> device=0x0) at drivers/char/tty_io.c:2850
>> #14 0xd010fd56 in tty_register_driver (driver=0xd78429c0) at
>> drivers/char/tty_io.c:2995
>> #15 0xd0262189 in legacy_pty_init () at drivers/char/pty.c:419
>> #16 0xd026241e in pty_init () at drivers/char/pty.c:762
>> #17 0xd00012b2 in do_one_initcall (fn=0xd0262418 <pty_init>) at
>> init/main.c:709
>> #18 0xd025ab30 in do_initcalls () at init/main.c:749
>> #19 0xd025ab66 in do_basic_setup () at init/main.c:769 #20 0xd025abf1
>> in kernel_init (unused=0x0) at init/main.c:861
>> #21 0xd0002acd in kernel_thread () at arch/xtensa/kernel/entry.S:2136
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>> (gdb) c
>> Software Watchdog Timer: 0.07 initialized. soft_noboot=0
>> soft_margin=60 sec (nowayout= 1) TCP cubic registered
>> NET: Registered protocol family 17
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> ISS serial driver 0.1
>> IP-Config: No network devices available.
>> Looking up port of RPC 100003/2 on 192.168.168.1
>> rpcbind: server 192.168.168.1 not responding, timed out
>> Root-NFS: Unable to get nfsd port number from server, using default
>> Looking up port of RPC 100005/1 on 192.168.168.1
>> rpcbind: server 192.168.168.1 not responding, timed out
>> Root-NFS: Unable to get mountd port number from server, using default
>> Root-NFS: Server returned error -5 while mounting
>> /opt/montavista/pro/devkit/xtensa/linux_be/target
>> VFS: Unable to mount root fs via NFS, trying floppy.
>> List of all partitions:
>> No filesystem could mount root, tried:
>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>> unknown-block(2,0)
>> ( ISS simcall ) *WARNING* Unexpected request code -1
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0xd00083e3 in iss_panic_event (this=0xd0243798, event=0x0,
>> ptr=0xd026d018) at arch/xtensa/platforms/iss/setup.c:100
>> (gdb)
>> ----------------------------------------------------------------------
>> ------------------------------
>>
>>
>> Mark:
>>
>> You mentioned tricks/adjustments:
>> ----------------------------------------------------------------------
>> --------  > We don't run on ISS as regularly, however it should work.
>> You have to  > follow the extra instructions in that wiki for
>> configuring the kernel  > for use with ISS, including using the
>> iss_defconfig instead of other  > default kernel configs, as well as
>> other adjustments.  Presumably you've  > done all this?
>> ----------------------------------------------------------------------
>> -------
>> Is this what you were referring to:
>> ...............................................................................
>> in addition to setting up the initramfs filesystem, do the following.
>> Under Bus Options, deselect PCI support. Under Platform Options,
>> deselect Default bootloader kernel arguments.
>> ....................................................................................................................................................................................
>> I got thru PCI the hard way, and will try deselect Default bootloader
>> kernel arguments next time.
>>
>> BTW, how do we get to the internet with ISS? Would be nice to document
>> up to mounting NFS root file-system and all.
>> Perhaps eventually documenting how to run SMP linux in simulation with
>> XTSC so kernel.org guys can maintain it.
>>
>>
>>
>> Low Swee: (continued):
>>
>> So I assume the problem is likely specific to your config or the new
>> V3 MMU code, which I've heavily tested on the LX200 FPGA board but
>> it's never been tried with ISS AFAIK.
>>
>> I've just build xtensa-tools for a V3 MMU version of DC_B_232L,
>> calling it DC_B_233L. (Marc: is the 'B' kosher? 'C' better?)
>>
>> I'll fire off a DC_B_233L. BUILDROOT for it and try that next. Since
>> your using xt-gdb on printk() I take it your already familiar with the
>> tricks of placing breakpoints in V3 MMU code (Documented in
>> linux//Documentation/xtensa/gdbmacros).
>>
>> -piet
>>
>>
>>  >
>>  >
>>  >
>>  > Please advice ..
>>  >
>>  >
>>  >
>>  > Thanks lot .
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > (xt-gdb) bt
>>  >
>>  > #0  0xd0103390 in printk ()
>>  >
>>  > #1  0xd015c3d4 in start_kernel ()
>>  >
>>  > #2  0xd015c004 in _startup () at
>>  > /home/sllow/Download/git/linux/arch/xtensa/kernel/head.S:289
>>  >
>>  > (xt-gdb) stepi
>>  >
>>  > 0xd0103393 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd0103396 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd0103399 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd010339b in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd010339e in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033a0 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033a2 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033a4 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033a6 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033a8 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033aa in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033ac in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033ae in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd01033b1 in printk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd54 in vprintk ()
>>  >
>>  > (xt-gdb) stepi
>>  >
>>  > 0xd000bd57 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd5a in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd5d in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd5f in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd62 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd65 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd67 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd6a in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd6d in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd70 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd73 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd76 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bd78 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdc5 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdc8 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdcb in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdcd in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdcf in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdd2 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdd4 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdd7 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bdda in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bddc in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bddf in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000bde1 in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  > 0xd000be0f in vprintk ()
>>  >
>>  > (xt-gdb)
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > *From:* Marc Gauthier [mailto:marc at tensilica.com]  > *Sent:*
>> Thursday, 24 June, 2010 11:55 PM  > *To:* Low Swee Leong @ Low Kwang
>> Hao; Piet Delaney  > *Cc:* linux-xtensa at linux-xtensa.org; Piet Delaney
>>> *Subject:* RE: [Linux-Xtensa] booting linux in ISS with LX3 core  >
>>>  >  > Hi Low Swee,  >  >  >  > I think the latest overlay installer
>> will work with either overlay.
>>  > Though we are moving to the one in src/xtensa-config-overlay.tar.gz
>> as  > the standard one.  One issue is that open source tools progress
>>> independently of Xtensa Tools releases.  If you've successfully  >
>> installed the overlay, that means the overlay installer recognized the
>>> overlay you gave it, so you should be okay.
>>  >
>>  >
>>  >
>>  > We run the kernel regularly on the LX60 and LX200 boards.  Which
>> FPGA  > board are you using?  Does your custom LX3 core have an MMU?
>>  >
>>  >
>>  >
>>  > We don't run on ISS as regularly, however it should work.  You have
>> to  > follow the extra instructions in that wiki for configuring the
>> kernel  > for use with ISS, including using the iss_defconfig instead
>> of other  > default kernel configs, as well as other adjustments.
>> Presumably you've  > done all this?
>>  >
>>  >
>>  >
>>  > Since you're running in xt-gdb, you could Ctrl-C after a while and
>> see  > what the (simulated) processor is doing.  Is it in the idle
>> loop?  You  > might have to use "symbol vmlinux" to switch to the
>> actual image's  > kernel symbols, to see that.
>>  >
>>  >
>>  >
>>  > HTH,
>>  >
>>  > -Marc
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>> ----------------------------------------------------------------------
>> --
>>  >
>>  >     *From:* linux-xtensa-bounces at linux-xtensa.org
>>  >     [mailto:linux-xtensa-bounces at linux-xtensa.org] *On Behalf Of *Low
>>  >     Swee Leong @ Low Kwang Hao
>>  >     *Sent:* Thursday, June 24, 2010 06:15
>>  >     *To:* Piet Delaney
>>  >     *Cc:* linux-xtensa at linux-xtensa.org; Piet Delaney
>>  >     *Subject:* RE: [Linux-Xtensa] booting linux in ISS with LX3 core
>>  >
>>  >     Thanks, i will try that ,
>>  >
>>  >
>>  >
>>  >     I have tried it on FPGA board , but it has the same result , so i
>>  >     have used ISS to do the testing .
>>  >
>>  >     I have tested the linux build in LX2 before and it works well.
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     1 question i have is that there seems to have 2  overlay file in the
>>  >     core
>>  >
>>  >     ./MAC_core5_lx3/xtensa-elf/src/linux/misc/linux-overlay.tar.gz
>>  >
>>  >     ./MAC_core5_lx3/src/xtensa-config-overlay.tar.gz
>>  >
>>  >
>>  >
>>  >     In the OSKIT  guide it stated
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     Building a Linux environment for a specific Tensilica processor
>>  >     configuration requires the Xtensa Linux Overlay.
>>  >
>>  >     This overlay is a compressed tar file located
>>  >     in<xtensa_root>/xtensa-elf/src/linux/misc/linux-overlay.tar.gz ,
>>  >     where <xtensa_root> is the location of the configured Tensilica core
>>  >     package
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     But in the Build root instruction, seems to indicate that i need to
>>  >     use xtensa-config-overlay
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     ./buildroot/target/xtensa/xt-buildroot-overlay-install -t
>>  >     blinkcore-config-overlay.tar.gz   -b ./buildroot -k ./linux -c
>>  >     superzip -l "ChipCorp SuperZIP Blink Accelerator Core"
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     May i know which is the correct one to use ?
>>  >
>>  >
>>  >
>>  >     Thanks
>>  >
>>  >
>>  >
>>  >     *From:* Piet Delaney [mailto:piet.delaney at gmail.com]
>>  >     *Sent:* Thursday, 24 June, 2010 6:47 PM
>>  >     *To:* Low Swee Leong @ Low Kwang Hao
>>  >     *Cc:* linux-xtensa at linux-xtensa.org; piet.delaney at Tensilica.com
>>  >     *Subject:* Re: [Linux-Xtensa] booting linux in ISS with LX3 core
>>  >
>>  >
>>  >
>>  >     Low Swee Leong @ Low Kwang Hao wrote:
>>  >
>>  >     Hi
>>  >
>>  >
>>  >
>>  >     Our company are currently using a custom LX3 core , i have download
>>  >     the image from linux-xtensa-20080711.tar.gz
>>  >
>>  >     And follow the instruction in
>>  >
>>  >     http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions
>>  >
>>  >     Morning Low:
>>  >
>>  >     Most folks are using the 2.6.29-SMP git repo:
>>  >
>>  >
>>  >
>> http://git.linux-xtensa.org/cgi-bin/git.cgi?p=kernel/xtensa-2.6.29-smp
>> .git;a=summary
>>  >
>>  >     I haven't tried running it with ISS as we mostly use a FPGA or an
>>  >     LX2 chip.
>>  >     I'll try running the 2.6.29-SMP code with ISS as soon as possible
>>  >     and make
>>  >     sure it's not broken.
>>  >
>>  >     -piet
>>  >
>>  >
>>  >
>>  >
>>  >     but when i try to run in ISS, it just stuck , as shown below , am i
>>  >     missing something ? anyone can shed some light on how to
>>  >     troubleshoot this issue ?
>>  >
>>  >
>>  >
>>  >     Thanks
>>  >
>>  >
>>  >
>>  >     [sllow at localhost tmpX]$ xt-gdb Image.elf
>>  >
>>  >     GNU gdb 6.8 Xtensa Tools 8.0.0
>>  >
>>  >     Copyright (C) 2008 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) run
>>  >
>>  >     Starting program: /mnt/hgfs/tmpX/Image.elf
>>  >
>>  >     Starting the ISS simulator.
>>  >
>>  >     Switching to remote protocol
>>  >
>>  >     Remote debugging using localhost:63087
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     Disclaimer added by *CodeTwo Exchange Rules 2007*
>>  >     www.codetwo.com <http://www.codetwo.com> <http://www.codetwo.com>
>>  >
>>  >
>>  >
>>  >     ------------------------------------------------------------------
>>  >     -
>>  >     -
>>  >     DISCLAIMER:
>>  >
>>  >     This e-mail (including any attachments) is for the addressee(s)
>>  >     only and may contain confidential information. If you are not the
>>  >     intended recipient, please note that any dealing, review,
>>  >     distribution, printing, copying or use of this e-mail is strictly
>>  >     prohibited. If you have received this email in error, please notify
>>  >     the sender immediately and delete the original message.
>>  >     MIMOS Berhad is a research and development institution under
>>  >     the purview of the Malaysian Ministry of Science, Technology and
>>  >     Innovation. Opinions, conclusions and other information in this e-
>>  >     mail that do not relate to the official business of MIMOS Berhad
>>  >     and/or its subsidiaries shall be understood as neither given nor
>>  >     endorsed by MIMOS Berhad and/or its subsidiaries and neither
>>  >     MIMOS Berhad nor its subsidiaries accepts responsibility for the
>>  >     same. All liability arising from or in connection with computer
>>  >     viruses and/or corrupted e-mails is excluded to the fullest extent
>>  >     permitted by law.
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>> ----------------------------------------------------------------------
>> --
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     _______________________________________________
>>  >
>>  >     linux-xtensa mailing list
>>  >
>>  >     linux-xtensa at linux-xtensa.org <mailto:linux-xtensa at linux-xtensa.org>
>>  >
>>  >     http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >     ------------------------------------------------------------------
>>  >     -
>>  >     -
>>  >     DISCLAIMER:
>>  >
>>  >     This e-mail (including any attachments) is for the addressee(s)
>>  >     only and may contain confidential information. If you are not the
>>  >     intended recipient, please note that any dealing, review,
>>  >     distribution, printing, copying or use of this e-mail is strictly
>>  >     prohibited. If you have received this email in error, please notify
>>  >     the sender immediately and delete the original message.
>>  >     MIMOS Berhad is a research and development institution under
>>  >     the purview of the Malaysian Ministry of Science, Technology and
>>  >     Innovation. Opinions, conclusions and other information in this e-
>>  >     mail that do not relate to the official business of MIMOS Berhad
>>  >     and/or its subsidiaries shall be understood as neither given nor
>>  >     endorsed by MIMOS Berhad and/or its subsidiaries and neither
>>  >     MIMOS Berhad nor its subsidiaries accepts responsibility for the
>>  >     same. All liability arising from or in connection with computer
>>  >     viruses and/or corrupted e-mails is excluded to the fullest extent
>>  >     permitted by law.
>>  >
>>  >
>>  > ------------------------------------------------------------------
>>  > -
>>  > -
>>  > DISCLAIMER:
>>  >
>>  > This e-mail (including any attachments) is for the addressee(s)  >
>> only and may contain confidential information. If you are not the  >
>> intended recipient, please note that any dealing, review,  >
>> distribution, printing, copying or use of this e-mail is strictly  >
>> prohibited. If you have received this email in error, please notify  >
>> the sender immediately and delete the original message.
>>  > MIMOS Berhad is a research and development institution under  > the
>> purview of the Malaysian Ministry of Science, Technology and  >
>> Innovation. Opinions, conclusions and other information in this e-  >
>> mail that do not relate to the official business of MIMOS Berhad  >
>> and/or its subsidiaries shall be understood as neither given nor  >
>> endorsed by MIMOS Berhad and/or its subsidiaries and neither  > MIMOS
>> Berhad nor its subsidiaries accepts responsibility for the  > same.
>> All liability arising from or in connection with computer  > viruses
>> and/or corrupted e-mails is excluded to the fullest extent  >
>> permitted by law.
>>  >
>>  >
>>
>>
>> -----------------------------------------------
>> A strategic agency under MOSTI
>> www.mimos.my <http://www.mimos.my>
>> -----------------------------------------------
>>
>>
>> ------------------------------------------------------------------
>> -
>> -
>> DISCLAIMER:
>>
>> This e-mail (including any attachments) is for the addressee(s) only
>> and may contain confidential information. If you are not the intended
>> recipient, please note that any dealing, review, distribution,
>> printing, copying or use of this e-mail is strictly prohibited. If you
>> have received this email in error, please notify the sender
>> immediately and delete the original message.
>> MIMOS Berhad is a research and development institution under the
>> purview of the Malaysian Ministry of Science, Technology and
>> Innovation. Opinions, conclusions and other information in this e-
>> mail that do not relate to the official business of MIMOS Berhad
>> and/or its subsidiaries shall be understood as neither given nor
>> endorsed by MIMOS Berhad and/or its subsidiaries and neither MIMOS
>> Berhad nor its subsidiaries accepts responsibility for the same. All
>> liability arising from or in connection with computer viruses and/or
>> corrupted e-mails is excluded to the fullest extent permitted by law.
>>
>>
>
> -----------------------------------------------
>  A strategic agency under MOSTI
>  www.mimos.my
> -----------------------------------------------
>
>
> ------------------------------------------------------------------
> -
> -
> DISCLAIMER:
>
> This e-mail (including any attachments) is for the addressee(s)
> only and may contain confidential information. If you are not the
> intended recipient, please note that any dealing, review,
> distribution, printing, copying or use of this e-mail is strictly
> prohibited. If you have received this email in error, please notify
> the sender  immediately and delete the original message.
> MIMOS Berhad is a research and development institution under
> the purview of the Malaysian Ministry of Science, Technology and
> Innovation. Opinions, conclusions and other information in this e-
> mail that do not relate to the official business of MIMOS Berhad
> and/or its subsidiaries shall be understood as neither given nor
> endorsed by MIMOS Berhad and/or its subsidiaries and neither
> MIMOS Berhad nor its subsidiaries accepts responsibility for the
> same. All liability arising from or in connection with computer
> viruses and/or corrupted e-mails is excluded to the fullest extent
> permitted by law.
>


------------------------------------------------------------------
-
-
DISCLAIMER: 

This e-mail (including any attachments) is for the addressee(s) 
only and may contain confidential information. If you are not the 
intended recipient, please note that any dealing, review, 
distribution, printing, copying or use of this e-mail is strictly 
prohibited. If you have received this email in error, please notify 
the sender  immediately and delete the original message. 
MIMOS Berhad is a research and development institution under 
the purview of the Malaysian Ministry of Science, Technology and 
Innovation. Opinions, conclusions and other information in this e-
mail that do not relate to the official business of MIMOS Berhad 
and/or its subsidiaries shall be understood as neither given nor 
endorsed by MIMOS Berhad and/or its subsidiaries and neither 
MIMOS Berhad nor its subsidiaries accepts responsibility for the 
same. All liability arising from or in connection with computer 
viruses and/or corrupted e-mails is excluded to the fullest extent 
permitted by law.




More information about the linux-xtensa mailing list