Re: MVME5110

[Andrew Johnson <anj@aps.anl.gov>]

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