2011/12/15 Julius Baxter <[email protected]>: > 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 > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc
I fully agree. In FPGA we would probably get zeroed out registers on startup. But it's a bad practice on ASIC. Resetting the registers is one way, but it would also put extra load on the reset net. Therefore I would say this is something SW should take care of. We still could add a simulation-only parameter that zeroes out the memories, but there are always complications in deviating the implementation from the simulation model -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ Linux mailing list [email protected] http://lists.openrisc.net/listinfo/linux
