[vmips] VMIPS

[Brian Gaeke]

On May 24, 2004, at 8:46 AM, vaneet at iitk.ac.in wrote:
> Thanks for your prompt reply. Even if I remove the fopen and fprintf
> functions, the printf alone gives the same problem when used. I think 
> the
> size of the rom file is large when I include libc.a and libidt.a files.
> That is why it is not proceeding.

It's possible... I don't know what libidt is for; maybe you could omit 
it?

> Is there a way to simulate fopen,fprintf functions like for printf
> functions, there is lib.c in which printf and other functions have been
> defined.

Yes; in fact the right thing to do is probably to implement them in 
terms of open, read() and write() calls. This is what the 
implementations of fopen and fprintf in your libc.a probably use. The 
trick is providing versions of open, read, and write that will work-- 
typically open, read, and write are expressed as system calls (using 
the MIPS syscall instruction). This is what I alluded to in my previous 
reply: if you want to make something like fopen() work, you will 
ultimately want to be able to simulate system calls.

> One more problem , when I increase the memsize(-o memsize=0x10000000
> ), it gives Error: Attempt to map two VMIPS components to the same 
> memory
> area.

When you start VMIPS you will see several diagnostic printouts intended 
to help debugging precisely this situation. For example:

  aluminum:~/vmips/sample_code/xmboot brg$ ./vmips16M boot.rom
  Big-Endian host processor detected.
  Mapping ROM image (boot.rom, 5120 words) to physical address 0x1fc00000
  Mapping RAM module (host=0x1008000, 16384KB) to physical address 0x0
  Mapping Halt device to physical address 0x01010024
  Mapping Clock device to physical address 0x01010000
  Connected IRQ7 to the Clock device
  Mapping SPIM console to physical address 0x02000000

This display tells you (among other things) that there are 
memory-mapped devices configured starting at physical addresses 
0x01010000 and 0x01010024. Unless you were to move them or disable 
them, you won't be able to configure more than about 16MB of memory, 
because RAM may not overlap memory-mapped devices.

It is easy to disable the halt device using the -o noclockdevice and -o 
nohaltdevice options. Moving them requires changing the CLOCK_ADDR and 
HALT_ADDR #defines in clockreg.h and haltreg.h respectively, and 
recompiling.

-Brian