Re: [PATCH v3 00/16] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support

[Bin Meng]

Hi Leif,

On Tue, Sep 8, 2020 at 1:27 AM Leif Lindholm <leif@nuviainc.com> wrote:
>
> On Mon, Sep 07, 2020 at 18:24:06 +0800, Bin Meng wrote:
> > Hi Leif,
> >
> >
> > On Sun, Sep 6, 2020 at 9:08 AM Leif Lindholm <leif@nuviainc.com> wrote:
> > >
> > > On Tue, Sep 01, 2020 at 09:38:55 +0800, Bin Meng wrote:
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > This adds support for Microchip PolarFire SoC Icicle Kit board.
> > > > The Icicle Kit board integrates a PolarFire SoC, with one SiFive's
> > > > E51 plus four U54 cores and many on-chip peripherals and an FPGA.
> > > >
> > > > For more details about Microchip PolarFire SoC, please see:
> > > > https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga
> > > >
> > > > The Icicle Kit board information can be found here:
> > > > https://www.microsemi.com/existing-parts/parts/152514
> > > >
> > > > Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
> > > > The RISC-V CPU and HART codes has been updated to set the core's
> > > > reset vector based on a configurable property from machine codes.
> > > >
> > > > The following perepherals are created as an unimplemented device:
> > > >
> > > > - Bus Error Uint 0/1/2/3/4
> > > > - L2 cache controller
> > > > - SYSREG
> > > > - MPUCFG
> > > > - IOSCBCFG
> > > > - GPIO
> > > >
> > > > The following perepherals are emulated:
> > > > - SiFive CLINT
> > > > - SiFive PLIC
> > > > - PolarFire SoC Multi-Mode UART
> > > > - SiFive PDMA
> > > > - Cadence eMMC/SDHCI controller
> > > > - Cadence Gigabit Ethernet MAC
> > > >
> > > > The BIOS image used by this machine is hss.bin, aka Hart Software
> > > > Services, which can be built from:
> > > > https://github.com/polarfire-soc/hart-software-services
> > > >
> > > > To launch this machine:
> > > > $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
> > > >     -bios path/to/hss.bin -sd path/to/sdcard.img \
> > > >     -nic tap,ifname=tap,script=no,model=cadence_gem \
> > > >     -display none -serial stdio \
> > > >     -chardev socket,id=serial1,path=serial1.sock,server,wait \
> > > >     -serial chardev:serial1
> > >
> > > I finally got around to building the sd image from
> > > https://github.com/polarfire-soc/polarfire-soc-buildroot-sdk,
> > > and I can successfully boot to prompt using that, and the (hacked)
> > > hss.bin I verified previously - also with this v3.
> > >
> >
> > Good to know!
> >
> > > However, unless I add the "-nic user,model=cadence_gem \" shown in
> > > https://wiki.qemu.org/Documentation/Platforms/RISCV#Microchip_PolarFire_SoC_Icicle_Kit
> > > but not here, I do not have functioning networking. (It is not obvious
> > > to me why this is needed.)
> > >
> >
> > Sorry I don't understand what the issue is?
>
> The instructions in this cover letter does not contain the line
>   "-nic user,model=cadence_gem \"
>
> The instruction in the wiki does.
> The instruction in the wiki works, the instruction in the cover letter
> does not.

Ah, OK. So please follow the Wiki docs.

>
> It is not clear to me why both lines are needed.
>
> > > > The memory is set to 1 GiB by default to match the hardware.
> > >
> > > Which hardware is this?
> > > https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit lists
> > > 2GiB.
> >
> > It's this same board. But I believe the crowdsupply webpage has the
> > wrong information. The board I got only has 1GB memory.
>
> The diagram on https://www.microsemi.com/existing-parts/parts/152514
> also says 2GB. Do you have any channel to Microchip to clarify this?

I suspect future version boards might ship 2GB memory. Right now as
you can see from both U-Boot and Linux device tree files, it's only
1GB.

>
> > > > A sanity check on ram size is performed in the machine init routine
> > > > to prompt user to increase the RAM size to > 1 GiB when less than
> > > > 1 GiB ram is detected.
> > >
> > > There is currently no visible effect in firmware from setting memory size 
> > > to >
> > > 1GiB (hss says 1GB, u-boot says 1GB, Linux sees 1GB).
> > > Are there any plans to address this in future versions?
> >
> > HSS is using hardcoded 1GB memory size and that's why in QEMU the
> > minimum required memory size is 1GB. Setting less than 1GB size blocks
> > HSS to load the 2nd stage bootloader U-Boot into the memory. Both
> > U-Boot and Linux DTS files set the memory size to 1GB, so that's why
> > both of them see only 1GB. Setting memory >1G does not affect U-Boot
> > and Linux though. You can however manually edit the U-Boot and Linux
> > DTS files to have a large RAM size to match QEMU -m option.
>
> Understood, thanks.

Regards,
Bin