On Sun, Nov 1, 2020 at 8:51 AM Bin Meng <[email protected]> wrote:
>
> Hi Alistair,
>
> On Mon, Nov 2, 2020 at 12:46 AM Alistair Francis <[email protected]> wrote:
> >
> > On Sun, Nov 1, 2020 at 8:42 AM Bin Meng <[email protected]> wrote:
> > >
> > > From: Bin Meng <[email protected]>
> > >
> > > When system memory is larger than 1 GiB (high memory), PolarFire SoC
> > > maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is
> > > aliased to the same 1 GiB low memory with different cache attributes.
> > >
> > > At present QEMU maps the system memory contiguously from 0x8000_0000.
> > > This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is
> > > the alias to the high memory, and even physical memory is only 1 GiB,
> > > the HSS codes still tries to probe the high memory alias address.
> > > It seems there is no issue on the real hardware, so we will have to
> > > take that into the consideration in our emulation. Due to this, we
> > > we increase the default system memory size to 2047 MiB (the largest
> > > ram size allowed when running on a 32-bit host) so that user gets
> > > notified an error when less than 2047 MiB is specified.
> >
> > Is this better than just not supporting 32-bit hosts? Or could we make
>
> I am not sure if we have a general rule about discontinuing 32-bit
> hosts support, i.e.: deprecating 32-bit hosts at some time?
>
> > this number even lower (as low as possible that still works with HSS)?
> >
>
> Sure I will figure this out and set this number to meet the minium
> requirement of HSS.

Thanks, that's probably the best bet for both 32 and 64-bit hosts then.

Alistair

>
> Regards,
> Bin

Reply via email to