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...@gmail.com> Sent: Monday 19 October 2020 09:38 To: Ivan Griffin <ivan.grif...@emdalo.com> Cc: Alistair Francis <alistai...@gmail.com>; QEMU Trivial <qemu-triv...@nongnu.org>; open list:RISC-V <qemu-ri...@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.grif...@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...@gmail.com> > Sent: Monday 19 October 2020 03:05 > To: Ivan Griffin <ivan.grif...@emdalo.com> > Cc: Alistair Francis <alistai...@gmail.com>; QEMU Trivial > <qemu-triv...@nongnu.org>; Bin Meng <bin.m...@windriver.com>; open > list:RISC-V <qemu-ri...@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.grif...@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
