On Thu, Dec 15, 2011 at 5:10 PM, Matthew Hicks <[email protected]> wrote: > On Thu, Dec 15, 2011 at 10:09 AM, Julius Baxter <[email protected]> > wrote: >> >> On Thu, Dec 15, 2011 at 3:57 PM, Matthew Hicks <[email protected]> >> wrote: >> > The method I used is just as synthesizable as the readmem tasks, plus >> > you >> > don't need to keep an external file. The method I used is also more >> > modular >> > and scalable than readmem. >> > >> > I agree that a better fix is to correct the OR32 boot code, but I also >> > like >> > initializing the memories to make RTL simulation closer to hardware >> > execution. >> > >> >> If you want to make the RTL simulation closer to what you experience >> with hardware, I would fill the RAMs with random values, not zeroes. >> > I agree. > >> >> Sometimes it's good to have X go everywhere, because it doesn't let >> you get away with not initialising things properly. In this case I >> think X is a good thing. >> > I agree here to, but when the software doesn't initialize things properly, > it is a pain to debug. The simulation doesn't just stop, it locks. > >> >> In what way is the Linux boot code not compatible with RTL simulation, >> ie where is it using registers before initialising them? > > > The caches and the register file are the main problems that I know of. The > TLBs may or may not be a problem. With the register file, specifically r0 > is the problem, the rest are initialized to 0.
In the reset vector currently in the kernel ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=arch/openrisc/kernel/head.S;hb=HEAD ) I see this: /* ---[ 0x100: RESET exception ]----------------------------------------- */ .org 0x100 /* Jump to .init code at _start which lives in the .head section * and will be discarded after boot. */ LOAD_SYMBOL_2_GPR(r4, _start) tophys (r3,r4) /* MMU disabled */ l.jr r3 l.nop Which does not appear to clear registers at reset. I recall a discussion about this a while back, about whether hardware should clear them at reset or not (in a synthesisable manner.) >From what I can see in the OpenRISC 1000 architecture manual from the section on GPRs: An implementation is not required to initialize GPRs to zero during the reset procedure. The reset exception handler is responsible for initializing GPRs to zero if that is necessary. The sections on the TLB match registers shows them as having 'X' at reset (therefore not initialised by RTL) and should be probably be initialised by software. The cache shouldn't be an issue - all implementations I've seen clear the thing before it's turned on. So I think the correct patch to be submitting would be one to the kernel port and not one for the processor RTL. Cheers, Julius _______________________________________________ Linux mailing list [email protected] http://lists.openrisc.net/listinfo/linux
