OPENCORES.ORG

On Tuesday 13 September 2005 19:15, György 'nog' Jeney wrote:

Do you run it with cache turned on ? If so just a wild guess and for the fun
of it maybe try it with cache off. I've seen a problem like this once before
and it was related to cache...

regards,
p.

* Balint Cristian (cristian.balint@o...) wrote:
> On Tuesday 13 September 2005 19:15, György 'nog' Jeney wrote:
> 
> Hmm ...
> 
> This release stop at  "Calibrating Delay loop ..." for me.
> 
> I builded with:
> ---------------------------------<>
> export CC='gcc32'
> ../configure --prefix=/usr --target=or32-uclinux --enable-impl=default --enable-ethphy
> ---------------------------------<>
> 
> Used gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)
> 
> 
> Can advice please to find out why ?
> 
> 
> More Older or1ksim boot this kernel and pass.
> 
> 
> 
> > Hi,
> > 
> > After more than nearly 9 months, we are heading toward the next stable release
> > of the simulator.  Alot of work has gone into cleaning up the core of the
> > simulator, which provided the groundwork for various optimisations and more
> > acurate overall simulation.  Regrettably, the cleanups also forced some changes
> > to the structure of the config file, details are given below.
> > 
> > I have extensively tested this release of or1ksim.  The only issue that I know
> > of is the one that Stephan reported with gdb a couple of days ago, so please
> > try out this release candidate and report any bugs and/or compile failures.  I'm
> > especially interested in results from non-linux builds (Cygwin, solaris, etc.).
> > 
> > Resulting from a typo, the 0.2.0rc1 release may be grabbed from cvs useing the
> > stable_0_2_0 tag.  It may also be downloaded as a source tarball from:
> > http://www.opencores.org/projects.cgi/web/or1k/or1ksim-0.2.0rc1.tar.gz
> > 
> > To compile this release, one needs to have a working set of the automake and
> > autoconf packages.  Consult your distribution documents for installing these
> > packages.
> > 
> > The most noticable change is an hughe speedup of simulation speed.  Compared to
> > the previous stable release (0.1.0), a 90% speed up may be observed: [1]
> > 
> > 0.1.0:
> > real    3m16.244s
> > user    3m1.440s
> > sys     0m4.040s
> > 
> > 0.2.0rc1:
> > real    0m20.837s
> > user    0m20.710s
> > sys     0m0.130s
> > 
> > Config. file changes
> > ~~~~~~~~~~~~~~~~~~~~
> > 
> > The general config. file structure has changed somewhat.  Instead of haveing
> > multiple device instances defined in one section, each section becomes one
> > device instance.  Previously, to define some memory:
> > 
> > section memory
> >   nmemories = 2
> >   device 0
> >     <instance 0 parameters>
> >   enddevice
> >   device 1
> >     <instance 1 parameters>
> >   enddevice
> > end
> > 
> > Now becomes:
> > 
> > section memory
> >   <instance 0 parameters>
> > end
> > section memory
> >   <instance 0 parameters>
> > end
> > 
> > The same goes for all other peripherals (uart/dma/ethernet/gpio/vga).  The
> > peripherals that, in the past, could not be instanciated multiple times (memory
> > controller/ata/frame buffer/ps2kbd), may now be instanciated multiple times,
> > based on the above scheme.  Since the memory controller (mc) may be instanciated
> > multiple times, each instance needs to have a unique identifier.  For this
> > purpose, the `index' parameter has been added to the mc section that takes a
> > positive integer as its parameter.  If the index parameter is not specified, the
> > default of 0 is used.  The mc with the index of `0' will be treated as the
> > default mc, being consulted in the case of overlapping memory areas.  It is now
> > also possible to connect a given memory instance to any one of the mcs that have
> > been instanciated.  The `mc' parameter, that takes as its parameter the index of
> > the mc that the memory is to be connected to, has been provided for this
> > purpose.
> > 
> > An `enabled' parameter has been added to the ata/vga/gpio/ethernet/uart
> > peripherals to facilitate a fast enableing/disableing mechanism.  In the case of
> > the `enabled' parameter being assigned a value of 0 (`enabled = 0'), the entire
> > section is ignored.
> > 
> > The `spr_log' and `spr_log_fn' parameters have been removed from the `sim'
> > section in favour of the new `+spr' debug channel, that may be specified on the
> > simulator command line with the `-d' option.
> > 
> > nog.
> > 
> > [1] The benchmarks where performed on a PIII 1GHz system, with the test binary
> > being the or32 port of the linux-2.4 kernel in its default configuration, except
> > the instruction cache was disabled.  The simulator was compiled with the
> > `--enable-ethphy' option.
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/openrisc
> > 
> > 
> 
> -- 
> Balint Cristian
> area network engineer
> .............................................................................
> RCS & RDS  Oradea
> Tel.: +40359.400.400
> Fax: +40359.400.444
> http://www.rcs-rds.ro
>         suport@r...
> ....................................................................................
> Privileged/Confidential Information may be contained in this message. 
> If you are not in the addresses indicated in this message (or responsible
> for delivery of the message to such person), you may not copy or deliver
> this message to anyone. In such a case, you should destroy this 
> message and kindly notify the sender by reply e-mail. 
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc