EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <2004>  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <2004>  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: MVME5110
From: Andrew Johnson <[email protected]>
To: Dirk Zimoch <[email protected]>
Cc: TECHTALK <[email protected]>
Date: Wed, 14 Apr 2004 13:29:29 -0500
Dirk Zimoch wrote:
I have 512 MB. I use the default bootrom.bin as it comes with the BSP. (Why does the boot loader try to map any VME space? It's just supposed to load vxWorks from the network?)

The boot loader is just another vxWorks application, which uses much of the same startup as the regular vxWorks bootfile, so it's going to do the same stuff for hardware initialization that the regular vxWorks does.

I use the PPC's BAT registers to map in the A32 space, which is much faster than creating PTEs but it does limit you to only 1GB because there are only 4 DBAT registers with a maximum mapping size of 256MB. Of course if you have more RAM than you need for A32 space then it might make more sense to swap the two and use PTEs for A32 and BATs for RAM, but if you try that be aware there may be complications in doing so.

What exactly are you talking about? I don't know much about VME mapping (not more than how to use sysBusToLocalAdrs() :-) )

For the CPU to be able to generate cycles on the VMEbus, the OS has to program the MMU to convert the virtual CPU address into a physical address to put out on the bus (there are actually several kinds of address and address translation going on between the CPU and the VMEbus, but I'll ignore those for now as they don't change this description). The MMU is programmed by setting up as series of tables in memory that tell it how to do that conversion (Page Table Entries, or PTEs). Each PTE provides the mecessary information for a 4KB chunk of virtual memory space, so you can see that Gigabyte-sized chunks of memory space are going to need lots of PTEs.

In virtual-memory OSs like Linux, Unix and Windows these PTEs get manipulated all the time to switch between different processes, but in vxWorks there's only one set of PTEs which are created at OS startup time, and they are almost always set up so the physical address generated is the same as the virtual address. The information in the sysPhysMemDesc[] array in sysLib.c is used to create these.

The PowerPC CPU family has an alternative way of programming the MMU which doesn't involve PTEs; there are a set of registers called BATs (Block Address Translation registers) which allow you to specify areas of virtual memory up to 256MB per BAT, and give the physical address and cache parameters for that address range. The PowerPC CPUs we use here have 4 DBATs and 4 IBATs - DBATs are for data access, IBATs for instruction access. It would be pretty unusual (and slow) to execute CPU instructions from VMEbus memory, so we ignore the IBATs here at APS since we're using the DBATs for VMEbus A32 memory.

FYI, the 68K family provides something similar called a Transparent Translation Register, which don't have the size limitations of the PoerPC's BAT registers.

Hopefully that will make my paragraph above more comprehensible.


If you have much more RAM than you need, you could also turn off the vxWorks auto-memory sizing and just don't use it all, which will speed up the PTE creation time.

Why that? Are PTEs also used for local memory?

Yes, and for I/O locations as well - for the CPU to be able to access an area of physical memory space after the MMU has been enabled, there must be either a PTE or a BAT to convert the CPU's virtual address into the physical address that goes out to the memory.

sysLib.c says:

* Normally, the user specifies the amount of physical memory with the
* macro LOCAL_MEM_SIZE in config.h.  BSPs that support run-time
* memory sizing do so only if the macro LOCAL_MEM_AUTOSIZE is defined.
* If not defined, then LOCAL_MEM_SIZE is assumed to be, and must be, the
* true size of physical memory.

So, how to 'don't use it all' ?

Undefine LOCAL_MEM_AUTOSIZE and set LOCAL_MEM_SIZE to the amount of RAM you want to be able to use. The rest of the RAM won't be accessible, but if you don't need it and you want a faster startup why bother having PTEs created for it?

You may be able to do this for your bootroms and allow the final vxWorks to use all the RAM - that would reduce the startup time without reducing the RAM you have available.

BTW, this line
#define VME_A32_MSTR_SIZE 0x08000000
says that you're only mapping in 128MB of VME A32 space, so ~20% of your slow startup time is because of the A32 space and ~80% is because of the 512MB of RAM you have. [128/(128+512)]

HTH,

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro

References:
RE: MVME5110 Mark Rivers
Re: MVME5110 Dirk Zimoch
Re: MVME5110 Andrew Johnson
Re: MVME5110 Dirk Zimoch
Navigate by Date:
Prev: Re: MVME5110 Dirk Zimoch
Next: Re: MVME5110 Craig Walther
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <2004>  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: MVME5110 Dirk Zimoch
Next: Base R3.13.10 now available Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <2004>  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·