On Fri, 16 Mar 2012 16:44:29 +0000, Peter Maydell <peter.maydell at linaro.org> wrote: > On 14 March 2012 00:49, Rusty Russell <rusty at rustcorp.com.au> wrote: > > On Tue, 13 Mar 2012 08:47:52 +0000, Peter Maydell <peter.maydell at linaro.org> wrote: > >> Are you going to want to encode "this is how this cp15 register > >> is reset" in your tables at some point? Or "r/o for user mode > >> but r/w for kernel" or other complicated permissions? > > > > I think reset values deserve a separate table, since it's not an obvious > > fit here. > > Hmm. Isn't that going to make it hard to say "this register is > present on both CPU Foo and CPU Bar", since the details of what > 'this register' means will be spread across an MRC line, an MCR > line and an entry in a separate reset value table? Hmm, true. We could split the table using elf sections, so the code could be organized like so (silly example, since l2ctlr doesn't need init, but you get the idea): CP15_WRITE(CRn(10), CRm(0), Op1(DF), Op2(DF), is32, ignore_write); CP15_READ(CRn(10), CRm(0), Op1(DF), Op2(DF), is32, read_l2ctlr); CP15_INIT(l2ctlr, init_l2crlr) If we're going to emulate different cpus, we need a key, too, so we'll probably want to build the table at runtime. I think we can keep this in our pockets for now, however. My immediate concern is reducing and defining the scope of those FIXME wildcards in emulation... Thanks, Rusty. -- How could I marry someone with more hair than me? http://baldalex.org
