diff mbox

ARM: Add an L2 cache controller to KZM

Message ID 84r4e9j5ko.wl%peter.chubb@nicta.com.au
State New
Headers show

Commit Message

Peter Chubb Aug. 5, 2013, 1:21 a.m. UTC
Reads to unassigned memory now return non-zero (since patch
9b8c69243585).  This breaks guests runnong on i.MX31 that use the
cache controller --- they poll forever waiting for the L2CC cache
invalidate regsiter to be zero.

This patch adds in an L2 cache controller.  It's not quite right ---
it reuses the PL2x0 implementation that  is already in QEMU.  The
differences however are minor --- a different ID, a different initial
value for the aux control register (because Freescale have used
some of the reserved bits), and the pl2x0 implements registers that
are not present in the Freescale cache controller.

Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au>



--
Dr Peter Chubb				        peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au          Software Systems Research Group/NICTA

Comments

Peter Maydell Aug. 5, 2013, 9:18 a.m. UTC | #1
On 5 August 2013 02:21, Peter Chubb <peter.chubb@nicta.com.au> wrote:
> Reads to unassigned memory now return non-zero (since patch
> 9b8c69243585). This breaks guests runnong on i.MX31 that use the
> cache controller --- they poll forever waiting for the L2CC cache
> invalidate regsiter to be zero.

That commit claims it was just restoring the previous
behaviour, so it shouldn't break guests, surely?

-- PMM
Andreas Färber Aug. 5, 2013, 9:24 a.m. UTC | #2
Am 05.08.2013 11:18, schrieb Peter Maydell:
> On 5 August 2013 02:21, Peter Chubb <peter.chubb@nicta.com.au> wrote:
>> Reads to unassigned memory now return non-zero (since patch
>> 9b8c69243585). This breaks guests runnong on i.MX31 that use the
>> cache controller --- they poll forever waiting for the L2CC cache
>> invalidate regsiter to be zero.
> 
> That commit claims it was just restoring the previous
> behaviour, so it shouldn't break guests, surely?

See Jan's patches on the list. PReP was reported affected, too.

Peter Ch., if you know the exact differences, why don't you just derive
an imx-l2cc type (or so) derived from ARM's type, overriding the values
mentioned above? Sounds trivial to me.

Regards,
Andreas
Peter Chubb Aug. 5, 2013, 11:31 p.m. UTC | #3
>>>>> "Peter" == Peter Maydell <peter.maydell@linaro.org> writes:

Peter> On 5 August 2013 02:21, Peter Chubb <peter.chubb@nicta.com.au>
Peter> wrote:
>> Reads to unassigned memory now return non-zero (since patch
>> 9b8c69243585). This breaks guests runnong on i.MX31 that use the
>> cache controller --- they poll forever waiting for the L2CC cache
>> invalidate regsiter to be zero.

Peter> That commit claims it was just restoring the previous
Peter> behaviour, so it shouldn't break guests, surely?

The behaviour was introduced in 2008 in commit e18231a3 --- The KZM
port only went in last year and assumed the then-current behaviour.

Peter C
--
Dr Peter Chubb				        peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au          Software Systems Research Group/NICTA
peter@chubb.wattle.id.au Aug. 6, 2013, midnight UTC | #4
>>>>> "Andreas" == Andreas Färber <afaerber@suse.de> writes:

Andreas> Am 05.08.2013 11:18, schrieb Peter Maydell:
>> On 5 August 2013 02:21, Peter Chubb <peter.chubb@nicta.com.au>
>> wrote:
>>> Reads to unassigned memory now return non-zero (since patch
>>> 9b8c69243585). This breaks guests runnong on i.MX31 that use the
>>> cache controller --- they poll forever waiting for the L2CC cache
>>> invalidate regsiter to be zero.
>> 
Andreas> Peter Ch., if you know the exact differences, why don't you
Andreas> just derive an imx-l2cc type (or so) derived from ARM's type,
Andreas> overriding the values mentioned above? Sounds trivial to me.

Because I don't know how -- can you point me at some documentation?

Peter C
Andreas Färber Aug. 6, 2013, 8:27 a.m. UTC | #5
Am 06.08.2013 02:00, schrieb peter@chubb.wattle.id.au:
>>>>>> "Andreas" == Andreas Färber <afaerber@suse.de> writes:
> 
> Andreas> Am 05.08.2013 11:18, schrieb Peter Maydell:
>>> On 5 August 2013 02:21, Peter Chubb <peter.chubb@nicta.com.au>
>>> wrote:
>>>> Reads to unassigned memory now return non-zero (since patch
>>>> 9b8c69243585). This breaks guests runnong on i.MX31 that use the
>>>> cache controller --- they poll forever waiting for the L2CC cache
>>>> invalidate regsiter to be zero.
>>>
> Andreas> Peter Ch., if you know the exact differences, why don't you
> Andreas> just derive an imx-l2cc type (or so) derived from ARM's type,
> Andreas> overriding the values mentioned above? Sounds trivial to me.
> 
> Because I don't know how -- can you point me at some documentation?

There's no official how-to, but QOM is documented in include/qom/object.h.

May I simply point you to an example:
http://git.qemu.org/?p=qemu.git;a=commit;h=692a76d1c4a32573bf3cc19110c7fa6cc8c93f60

pl061 has Luminary and ARM IDs, with ARM in the base type and Luminary
overriding values. Another idea is to use an abstract base type and
several derived types if the differences are bigger.

Andreas
diff mbox

Patch

diff --git a/hw/arm/kzm.c b/hw/arm/kzm.c
index bd6c05c..018fc81 100644
--- a/hw/arm/kzm.c
+++ b/hw/arm/kzm.c
@@ -33,6 +33,7 @@ 
      * 0x1fffc000-0x1fffffff RAM                  EMULATED
      * 0x20000000-0x2fffffff Reserved             IGNORED
      * 0x30000000-0x7fffffff I.MX31 Internal Register Space
+     *   0x30000000-0x30000fff L2 Cache Controller PARTIALLY EMULATED
      *   0x43f00000 IO_AREA0
      *   0x43f90000 UART1                         EMULATED
      *   0x43f94000 UART2                         EMULATED
@@ -134,6 +135,15 @@  static void kzm_init(QEMUMachineInitArgs *args)
                        DEVICE_NATIVE_ENDIAN);
     }
 
+    /*
+     * The i.MX L2CC  is almost the same as the PL210
+     * except for a different ID (the implementor bits are different)
+     * and the `reserved' bits in the auxilliary control register
+     * are implemented.  The l2x0 qemu implementation is for a superset
+     * of the PL210.
+     */
+    sysbus_create_varargs("l2x0", 0x30000000, NULL);
+
     kzm_binfo.ram_size = ram_size;
     kzm_binfo.kernel_filename = kernel_filename;
     kzm_binfo.kernel_cmdline = kernel_cmdline;