Re: [PATCH] hw/riscv: microchip_pfsoc: IOSCBCTRL memmap entry

[Ivan Griffin]

Yes, it could be.

But the "Physical Address" column, in my mind, should be the 0x37020000 address.  At least when I check other peripherals, their physical address values in the register map HTML corresponds to the source code.

Cheers,

Ivan.

---

From: Bin Meng <bmeng.cn@gmail.com>
Sent: Monday 19 October 2020 09:38
To: Ivan Griffin <ivan.griffin@emdalo.com>
Cc: Alistair Francis <alistair23@gmail.com>; QEMU Trivial <qemu-trivial@nongnu.org>; open list:RISC-V <qemu-riscv@nongnu.org>; qemu-devel@nongnu.org Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] hw/riscv: microchip_pfsoc: IOSCBCTRL memmap entry

 

Hi Ivan,

On Mon, Oct 19, 2020 at 4:17 PM Ivan Griffin <ivan.griffin@emdalo.com> wrote:
>
> Hi Bin,
>
> Well spotted with the register map. I grepped it for 0x37020000 and didn't find it, but it seems the address (incorrectly) is 0x07020000 in the documentation.
>

I believe the documented offset 0x07020000 is the offset into the
IOSCB block, not the final one that is mapped into the system memory.

Regards,
Bin

> ________________________________
> From: Bin Meng <bmeng.cn@gmail.com>
> Sent: Monday 19 October 2020 03:05
> To: Ivan Griffin <ivan.griffin@emdalo.com>
> Cc: Alistair Francis <alistair23@gmail.com>; QEMU Trivial <qemu-trivial@nongnu.org>; Bin Meng <bin.meng@windriver.com>; open list:RISC-V <qemu-riscv@nongnu.org>; qemu-devel@nongnu.org Developers <qemu-devel@nongnu.org>
> Subject: Re: [PATCH] hw/riscv: microchip_pfsoc: IOSCBCTRL memmap entry
>
> Hi Ivan,
>
> On Sat, Oct 17, 2020 at 12:31 AM Ivan Griffin <ivan.griffin@emdalo.com> wrote:
> >
> > I don't know why it isn't documented in that PDF (or in the register map), but if you check https://github.com/polarfire-soc/polarfire-soc-bare-metal-library/blob/master/src/platform/drivers/mss_sys_services/mss_sys_services.h you'll see the following
> >
> > ```
> > typedef struct
> > {
> >     volatile uint32_t SOFT_RESET;
> >     volatile uint32_t VDETECTOR;
> >     volatile uint32_t TVS_CONTROL;
> >     volatile uint32_t TVS_TEMP_A;
> >     volatile uint32_t TVS_TEMP_B;
> >     volatile uint32_t TVS_TEMP_C;
> >     volatile uint32_t TVS_VOLT_A;
> >     volatile uint32_t TVS_VOLT_B;
> >     volatile uint32_t TVS_VOLT_C;
> >     volatile uint32_t TVS_OUTPUT0;
> >     volatile uint32_t TVS_OUTPUT1;
> >     volatile uint32_t TVS_TRIGGER;
> >     volatile uint32_t TRIM_VDET1P05;
> >     volatile uint32_t TRIM_VDET1P8;
> >     volatile uint32_t TRIM_VDET2P5;
> >     volatile uint32_t TRIM_TVS;
> >     volatile uint32_t TRIM_GDET1P05;
> >     volatile uint32_t RESERVED0;
> >     volatile uint32_t RESERVED1;
> >     volatile uint32_t RESERVED2;
> >     volatile uint32_t SERVICES_CR;
> >     volatile uint32_t SERVICES_SR;
> >     volatile uint32_t USER_DETECTOR_SR;
> >     volatile uint32_t USER_DETECTOR_CR;
> >     volatile uint32_t MSS_SPI_CR;
> >
> > } SCBCTRL_TypeDef;
> >
> > #define MSS_SCBCTRL                    ((SCBCTRL_TypeDef*) (0x37020000UL))
> >
> > /*2kB bytes long mailbox.*/
> > #define MSS_SCBMAILBOX                 ((uint32_t*) (0x37020800UL))
> > ```
> >
> > And in https://github.com/polarfire-soc/polarfire-soc-bare-metal-library/blob/master/src/platform/drivers/mss_sys_services/mss_sys_services.c you'll see MSS_SCB and MSS_SCBMAILBOX used in many places to interact with the FPGA system controller to perform various services.
>
> It's actually documented, but not in the PDF file. I also spent some
> time locating the doc when I do the DDR controller modeling work.
>
> See Register Map/PF_SoC_RegMap_V1_1/MPFS250T/pfsoc_control_scb.htm in
> https://www.microsemi.com/document-portal/doc_download/1244581-polarfire-soc-register-map