qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for 4.2 v1 1/1] riscv/virt: Increase flash size


From: Alistair Francis
Subject: Re: [PATCH for 4.2 v1 1/1] riscv/virt: Increase flash size
Date: Thu, 7 Nov 2019 09:59:15 -0800

On Thu, Nov 7, 2019 at 10:01 AM Peter Maydell <address@hidden> wrote:
>
> On Thu, 7 Nov 2019 at 17:09, Palmer Dabbelt <address@hidden> wrote:
> >
> > On Wed, 06 Nov 2019 16:47:20 PST (-0800), Alistair Francis wrote:
> > > Coreboot developers have requested that they have at least 32MB of flash
> > > to load binaries. We currently have 32MB of flash, but it is split in
> > > two to allow loading two flash binaries. Let's increase the flash size
> > > from 32MB to 64MB to ensure we have a single region that is 32MB.
> > >
> > > No QEMU release has include flash in the RISC-V virt machine, so this
> > > isn't a breaking change.
> >
> > Even if we had, I wouldn't consider it a breaking change because it adds to
> > the memory map so existing programs will continue to run fine.
>
> I have a feeling you may find that some old command lines won't
> work any more because they specified a flash contents binary
> that was the old 32MB and now it needs to be padded out to 64MB.

Yes, that is correct. Everyone using -pflash will need to change the
size of their binaries. This was only just merged into QEMU master
though and hasn't been in a release so I don't think many people are
using it.

I only know of two users, one is me and someone from Coreboot who
requested the larger size. It doesn't seem like a problem users will
see.

Alistair

> But I haven't tested whether this theory is correct (it will
> depend on how the flash contents are specified -- --bios will
> be ok, as will loading contents directly as an ELF file or
> similar, specifying contents by a -drive option intended to be
> consumed by the pflash is the case which likely needs extra padding.)
>
> thanks
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]