|
Message
From: Chris Hescott<hesc0002@u...>
Date: Thu Sep 9 03:30:33 CEST 2004
Subject: [openrisc] HELP? Simulating uClinux on OR1200 RTL in Verilog
Greetings,I'm trying to get uClinux to run on the RTL code of the or1200. I'm using the latest CVS checkout (gotten using the ATS) of uClinux and a fairly recent release of the or1200. However, as far as I can tell, the memory mappings are very different between uClinux's default ordering and that used by the RTL (written for the XESS).
I've found older versions of board.h and orp.ld in the sw/support directory for the or1200 distribution, however it appears that there has been significant changes to uClinux and consequently these files will not be able to replace the asm-or32/board.h and arch/or32/board/rom.ld.
Are there any default configuration files that I can use to get uClinux to compile so that it will easily run on the or1200 RTL using a verilog simulator? If not, is there any updated documentation for getting uClinux properly ported to this environment. I've seen several reports of uClinux running on or1200 synthesized onto FPGA's however I haven't seen anyone simulate it using a verilog simulator or steps to get uClinux working on the FPGA.
So far I'm having problems due to the apparent lack of a Memory Controller in the or1200 RTL. Also, it appears that the MC_INIT flag in uClinux does not disable the memory controller code completely when set to 0. The old version of board.h had a flag MC_ENABLED which appeared to disable the memory controller in the uClinux code. However it appears to have been removed.
Also, I've tried the following for the Memory section in rom.ld but I still get write to non-writable memory errors when I try to simulate
MEMORY { romvec : ORIGIN = 0x04000000, LENGTH = 0x2000 flash : ORIGIN = 0x04002000, LENGTH = 0x00200000 - 0x2000 eflash : ORIGIN = 0x04200000, LENGTH = 0 ramvec : ORIGIN = 0x00000000, LENGTH = 0x00002000 ram : ORIGIN = 0x00002000, LENGTH = 0x00200000 - 0x2000 eram : ORIGIN = 0x00200000, LENGTH = 0 }
The following is the output from the or32-uclinux-sim that I'm using for testing (before I actually run it on the RTL model):
Section: .romvec, vaddr: 0x04000000, paddr: 0x04000000, offset: 0x00002000, size: 0x00000c14 Section: .text, vaddr: 0x04002000, paddr: 0x04002000, offset: 0x00004000, size: 0x000686a8 Section: .rodata, vaddr: 0x0406a6a8, paddr: 0x0406a6a8, offset: 0x0006c6a8, size: 0x0000625b Section: .initrd, vaddr: 0x04070908, paddr: 0x04070908, offset: 0x00072908, size: 0x00035c00 Section: .data, vaddr: 0x00002000, paddr: 0x040a6508, offset: 0x000aa000, size: 0x00007424 Section: .ramvec, vaddr: 0x00000000, paddr: 0x040ad92c, offset: 0x000b2000, size: 0x00000c14 Resetting 1 UART(s). UART0 at 0x90000000 uses 0 Resetting Tick Timer. Resetting Power Management. Resetting PIC. Resetting memory controller. Starting at 0x00000000 WARNING: memory write to 0x90000000, non-write memory area (value 0x00000700). WARNING: memory write to 0x90000000, non-write memory area (value 0x00000000). WARNING: memory write to 0x90000000, non-write memory area (value 0x00000003). WARNING: memory write to 0x90000000, non-write memory area (value 0x00000080). WARNING: memory write to 0x90000000, non-write memory area (value 0x00000000). WARNING: memory write to 0x90000000, non-write memory area (value 0x05000000). WARNING: memory write to 0x90000000, non-write memory area (value 0x00000000). WARNING: memory write to 0x00002000, non-write memory area (value 0x00000000).
And here is the relevant section from the sim.cfg file (Note: the code won't run without the Memory controller enabled)
section memory /*random_seed = 12345 type = random*/ pattern = 0x00 type = unknown /* Fastest */
nmemories = 3 device 0 name = "RAM" ce = 1 baseaddr = 0x00000000 size = 0x00200000 delayr = 1 delayw = 5 enddevice
device 1 name = "FLASH" ce = 0 baseaddr = 0x04000000
size = 0x00200000
delayr = 1
delayw = -1
enddevice
device 2
name = "ICM"
ce = 2
baseaddr = 0x00800000
size = 0x00004000
delayr = 1
delayw = 1
enddevice
end
I'd greatly appreciate any advice or tips about this.
--Chris
|
 |