qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: RFC: emulation of system flash


From: Антон Кочков
Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash
Date: Thu, 10 Mar 2011 23:08:51 +0300

As I'm working on bootrom loading support for omap/arm platform, I'm
have suggestion about something more universal than -bios (and even
-flash) option. Because Flash can be NOR, can be NAND, but on-chip
memory is not flash memory. So may be something like -rom option?

Best regards,
Anton Kochkov.




On Thu, Mar 10, 2011 at 22:50, Jordan Justen <address@hidden> wrote:
> On Thu, Mar 10, 2011 at 11:12, Gleb Natapov <address@hidden> wrote:
>> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
>>> Yes, this definitely could add firmware upgrade issues, but I thought
>>> this could be the responsibility of the firmware itself.  For example,
>>> OVMF could have an outside of VM tool to merge new releases, or it
>>> could have an inside of VM firmware update process.
>> Why require another tool if can do without? I don't see any advantages
>> in storing firmware code and its non-volatile storage in the same image,
>> but I do see disadvantages.
>
> I agree.  The implications of a firmware image getting out of sync
> with qemu were a bit of a concern to me.  But, having both -bios +
> -flash just below -bios was starting to seem a bit complicated.
>
> And, I guess as a firmware developer, I thought it might be
> interesting to consider enabling a firmware update process within the
> VM. :)
>
> How about?
> 1) Pure rom:
> -bios bios.bin
> 2) Rom + flash below rom:
> -bios bios.bin,flash=flash.bin
> 3) Pure flash:
> -bios flash=flash.bin
>
> Or, with a separate new -flash option:
> 1) Pure rom:
> -bios bios.bin
> or no -bios or -flash parameters
> 2) Rom + flash below rom:
> -bios bios.bin -flash flash.bin
> 3) Pure flash:
> -flash flash.bin
>
>> It is not even about performance (which will be very bad for 1MB). KVM
>> can't run code from MMIO region, so the part that contains firmware
>> has to be memory.
>
> Hmm.  That's good to know. :)
>
> So, perhaps this feature should build upon the other feature you and
> Jan are discussing.  When will it become available?
>
> Thanks,
>
> -Jordan
>
>



reply via email to

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