Re: [Qemu-devel] [Qemu-arm] [PATCH 6/7] hw/misc/mps2_scc: Implement MPS2 Serial Communication Controller

[Peter Maydell]

On 11 July 2017 at 13:53, Philippe Mathieu-Daudé <address@hidden> wrote:
> I Peter,
>
> On 07/11/2017 08:17 AM, Peter Maydell wrote:
>>
>> Implement a model of the Serial Communication Controller (SCC) found
>> in MPS2 FPGA images.
>>
>> The primary purpose of this device is to communicate with the
>> Motherboard Configuration Controller (MCC) which is located on
>> the MPS board itself, outside the FPGA image. This is used
>> for programming the MPS clock generators. The SCC also has
>> some basic ID registers and an output for the board LEDs.
>>
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>>   hw/misc/Makefile.objs           |   1 +
>>   include/hw/misc/mps2-scc.h      |  43 ++++++
>>   hw/misc/mps2-scc.c              | 310
>> ++++++++++++++++++++++++++++++++++++++++
>
>
> Hmm I understand hw/ssi is for Synchronous Serial Interface, this interface
> doesn't belong there?

No, it's not an SSI bus -- that's a standardized clocked
point-to-point serial interface. This is just a fairly
ad-hoc communication channel.

>> +++ b/include/hw/misc/mps2-scc.h
>> @@ -0,0 +1,43 @@
>> +/*
>> + * ARM CMSDK APB timer emulation
>
>
> ARM MPS2 SCC emulation

Oops; fixed.

>> +static uint64_t mps2_scc_read(void *opaque, hwaddr offset, unsigned size)
>> +{
>> +    MPS2SCC *s = MPS2_SCC(opaque);
>> +    uint64_t r;
>> +
>> +    switch (offset) {
>> +    case A_CFG0:
>> +        r = s->cfg0;
>> +        break;
>> +    case A_CFG1:
>> +        r = s->cfg1;
>> +        break;
>> +    case A_CFG3:
>> +        /* These are user-settable DIP switches on the board. We don't
>> +         * model that, so just return zeroes.
>> +         */
>
>
> Shouldn't be hard to have a property (thinking about having multiple boards
> and using those switches to have some board unique ID, not switches one
> might toggle at runtime).

No, on the board these are wired up to user-toggled switches.
Board ID information is in the ID/AID/CFG4 registers, which we have
properties for.


>> +    case A_CFG1:
>> +        /* CFG1 bits [7:0] control the board LEDs. We don't currently
>> have
>> +         * a mechanism for displaying this graphically, so use a trace
>> event.
>> +         */
>
>
> Well MIPS Jazz uses hw/display/jazz_led.c which is kinda nice :)
>
> Now than there is interest in simulating IoT boards and so, we might think
> about a generic LED display.

Yeah, if we do this at all we should have generic support (and
ideally you might want to see both the LED output and the
LCD screen output at the same time). This tracepoint is a
low-effort placeholder because I don't want to get into trying
to define and implement a generic LED-and-switches kind of UI.

> Reviewed-by: Philippe Mathieu-Daudé <address@hidden>

thanks
-- PMM