Re: Testing hte CPU
Mike Rowehl <[email protected]> Tue, 12 Aug 2003 11:52:06 -0700
| Newsgroups | gmane.org.handasarabia.ofoq |
|---|---|
| Message-ID | <[email protected]> |
On 0, Jamil Khatib <[email protected]> wrote: > > Hi, > Since uClinux is working, can you inform us about the devices, memory map and > the size of the OS on flash or SRAM? > We have to remember that OR1K uses two external memories (Instruction and > Data) I think I have to dump the instructions only to the SRAM. > > I found SRAM and Flash controllers with the OpenRisc1K test application on > the XSV board. Do you think we can use them? > > Regards, > Jamil > > On 8/10/2003, "Mike Rowehl" <[email protected]> wrote: > > >On 0, Mohamed Eldesoky <[email protected]> wrote: > >> On Saturday 09 August 2003 9:50 am, Jamil Khatib wrote: > >> > Hi, > >> > I think in our case the lase approach is the best one. > >> > I am going to make a small proposal about a bridge between the PC and > on > >> > board SRAM. > >> > Please keep us informed about the memory controller status because I > may > >> > need it to design the bridge. > >> > > >> > I hope that we can get a small program that turns some leds on the board > to > >> > test the CPU. Anyone can do it? > >> > >> We need Linux installed first !! > >> Have you succeeded in building the uCLinux port ?? > >> > >> Second, AFAIK we need a device driver to handle the I/O. > >> As Unices (AFAIK) handle I/O as files too !! > >> Does anyone has better info ?? Mike ?? > >> > > > >I have uCLinux building and running on the or1k simulator, but I dont have > a > >board to try it out on. I think there are a number of devices supported > >already with the uCLinux port, but I haven't taken a look at which ones. I > >would think that uCLinux installed on the prototyping board would yield a > >working system without much hacking. > > > > Mike > > I don't have the full set of images in front of me, I'll give you the info I do have. I can look other stuff up if you need. Configuration of the simulator is done through the sim.cfg file, it's distributed with the uclinux for or1k uCLinux-2.0.x package.. I would assume setup to match their default or1k build target. Machine setup is: Memory areas: flash baseaddr = 0xf0000000 size = 0x00800000 ram baseaddr = 0x00000000 size = 0x00800000 sram baseaddr = 0x08000000 size = 0x00400000 Instruction Memory Management Unit enabled number of ITLB sets: 64 number of ITLB ways: 1 pagesize: 8192 Data Memory Management Unit enabled number of DTLB sets: 64 number of DTLB ways: 1 pagesize: 8192 Instruction Cache enabled number of IC sets: 256 number of IC ways: 1 IC block size (bytes): 16 Data Cache enabled number of DC sets: 256 number of DC ways: 1 DC block size (bytes): 16 CPU version: 0x1200 CPU revision: 0x0001 Memory Controller enabled base address of first MC register: 0x93000000 Power on configuration register: 0x00000008 Devices: 1 uart at 0x90000000, irq 2, 16550 style 1 network device at 0x92000000, irq 4 framebuffer at 0x97000000 keyboard at 0x94000000, irq 5 I don't have the images here, I'm not too sure about the size. The system is build as a core linux kernel, and then a package of files called an initrd. The initrd contains the root filesystem to be used when the system boots up. The simulator does not by default appear to simulate using flash for the filesystem, but I'm assuming it could be used to do so if I change the configuration appropriately. If the plan is to create a serial interface to load the SRAM with, the requirements should be simply loading a single file at a given address within RAM and then being able to load PC with a value from within the loaded address. The kernel/initrd are normally loaded as one unit with the build tools patching in the correct addressing fixups and sizes so the package can be dumped as a binary image and executed. Mike ------------------------------- OFOQ Mailing List Handasa Arabia Organization http://www.handasarabia.org Message number 68