On 2011-03-11 20:09, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
Hello,
On 11 March 2011 20:09, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
> wrote:
>> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>>> At least it's an in-band interface, which is the better choice as we
>>> currently only have a PIIX3 southbridge for x86, predatin
On Thu, Mar 10, 2011 at 16:27, Carl-Daniel Hailfinger
wrote:
> Auf 11.03.2011 01:19, Jan Kiszka schrieb:
>> At least it's an in-band interface, which is the better choice as we
>> currently only have a PIIX3 southbridge for x86, predating even FWHs.
>>
>
> Right, that pretty much kills the option
On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 23:58, Jordan Justen schrieb:
>> Would the firmware
>> be able to depend on having control of the device at OS runtime? This
>> would be needed for UEFI non-volatile variables to make sure they can
>> always be written.
Auf 10.03.2011 23:58, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
> wrote:
>
>> Right, the constant size argument is definitely a point we need to talk
>> about.
>>
>> We could sidestep the issue by always using a 16 MByte flash device
>> which gets filled fro
On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger
wrote:
> Right, the constant size argument is definitely a point we need to talk
> about.
>
> We could sidestep the issue by always using a 16 MByte flash device
> which gets filled from the top with the firmware image, but I'm not sure
> if th
Auf 10.03.2011 23:14, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
> wrote:
>
>> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>>
>>> I thought this might be a case where deviation from real hardware
>>> emulation could better serve the VM's needs.
>>>
On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 19:43, Jordan Justen schrieb:
>> I thought this might be a case where deviation from real hardware
>> emulation could better serve the VM's needs.
>>
>
> If we have to write the code anyway, and if it can work just fine
On Thu, 10 Mar 2011 22:46:34 +0100
Carl-Daniel Hailfinger wrote:
> Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> > I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
> >
>
> If you're thinking beyond x86, most flash is probably using SPI nowadays
> because the reduced PCB f
On Thu, Mar 10, 2011 at 13:41, Carl-Daniel Hailfinger
wrote:
> Auf 10.03.2011 12:48, Gleb Natapov schrieb:
>> Yes we can make memory slot that will be treated as memory on read and
>> IO on write, but first relying on that will prevent using flash interface
>> on older kernels and second it is not
Auf 10.03.2011 19:43, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote:
>
>> On 03/10/2011 06:51 AM, Jordan Justen wrote:
>>
>>> http://wiki.qemu.org/Features/System_Flash
>>>
>>>
>> - make the programming interface the same as an existing device
>>
> Ho
Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> BTW, the programming granularity is not bytes but chips with common CFI.
> But that's still tricky if you want to run code from the same chip while
> updating parts of it. The easiest workaround would be handling the
> overlay regions as ROM all the time.
Auf 10.03.2011 12:48, Gleb Natapov schrieb:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue com
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 11:23, Anthony Liguori wrote:
> If you implement a CSM for Tiano Core, then you won't need to use any
> special parameters because we can just use OVMF by default ;-)
Sorry, but I can't do this. This is unlikely to change anytime soon.
But, if someone seeks to put forth
On 03/10/2011 01:03 PM, Jordan Justen wrote:
On Thu, Mar 10, 2011 at 03:46, Jan Kiszka wrote:
On 2011-03-10 12:27, Jan Kiszka wrote:
On 2011-03-10 10:47, Gleb Natapov wrote:
My suggestion is to extend
-bios option like this:
-bios bios.bin,flash=flash.bin,flash_base=addr
flash.bin will be m
16 matches
Mail list logo
