On 10/02/2013 07:23 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-02 at 00:23 +1000, Alexey Kardashevskiy wrote:
>
>> SLOF is what is loaded from the very beginning, it configures PCI, cooks
>> the device tree and boots the guest system (directly or via yaboot/grub,
>> from disk, network or
On Wed, 2013-10-02 at 00:23 +1000, Alexey Kardashevskiy wrote:
> SLOF is what is loaded from the very beginning, it configures PCI, cooks
> the device tree and boots the guest system (directly or via yaboot/grub,
> from disk, network or ram). Normal firmware, as usual. It knows all the
> details a
On Tue, Oct 1, 2013 at 10:28 AM, Paolo Bonzini wrote:
> Il 01/10/2013 17:12, Peter Maydell ha scritto:
> >> > I just need some way to have different default firmware images for
> >> > different pc machine type versions. Requests to considering other
> >> > firmware loading needs (such as the two
Il 01/10/2013 17:12, Peter Maydell ha scritto:
>> > I just need some way to have different default firmware images for
>> > different pc machine type versions. Requests to considering other
>> > firmware loading needs (such as the two images needed for sPAPR) when
>> > doing this is reasonable. B
On 2 October 2013 00:05, Gerd Hoffmann wrote:
> I just need some way to have different default firmware images for
> different pc machine type versions. Requests to considering other
> firmware loading needs (such as the two images needed for sPAPR) when
> doing this is reasonable. Blaming me fo
On Di, 2013-10-01 at 22:00 +0900, Peter Maydell wrote:
> On 1 October 2013 21:16, Gerd Hoffmann wrote:
> > Hi,
> >
> >> -bios we're stuck with because it's a legacy
> >> option,
> >
> > What is legacy about it?
>
> The fact that we've had it since forever, it was introduced for
> a specific x86
Il 01/10/2013 15:00, Peter Maydell ha scritto:
> > Some don't. They just memcpy the firmware into guest ram instead.
>
> ...is that a good thing? What does the real hardware do? Should we
> be doing that instead? Isn't this awkward on reset?
They probably have a ROM (which should be the real "-m
On 10/01/2013 04:40 PM, Gerd Hoffmann wrote:
Hi,
SLOF is what is loaded from the very beginning, it configures PCI, cooks
the device tree and boots the guest system (directly or via yaboot/grub,
from disk, network or ram). Normal firmware, as usual. It knows all the
details about the machine
Hi,
> SLOF is what is loaded from the very beginning, it configures PCI, cooks
> the device tree and boots the guest system (directly or via yaboot/grub,
> from disk, network or ram). Normal firmware, as usual. It knows all the
> details about the machine so the guest system (linux) does not nee
On 10/01/2013 11:46 PM, Andreas Färber wrote:
> Am 01.10.2013 15:41, schrieb Gerd Hoffmann:
>> On Di, 2013-10-01 at 14:20 +0200, Andreas Färber wrote:
>>> Hi,
>>>
>>> Am 01.10.2013 14:16, schrieb Gerd Hoffmann:
> -bios we're stuck with because it's a legacy
> option,
What is legac
Am 01.10.2013 15:41, schrieb Gerd Hoffmann:
> On Di, 2013-10-01 at 14:20 +0200, Andreas Färber wrote:
>> Hi,
>>
>> Am 01.10.2013 14:16, schrieb Gerd Hoffmann:
-bios we're stuck with because it's a legacy
option,
>>>
>>> What is legacy about it?
>>>
>>> Well, the x86-centric name of course
On Di, 2013-10-01 at 14:20 +0200, Andreas Färber wrote:
> Hi,
>
> Am 01.10.2013 14:16, schrieb Gerd Hoffmann:
> >> -bios we're stuck with because it's a legacy
> >> option,
> >
> > What is legacy about it?
> >
> > Well, the x86-centric name of course. Thats why the machine option is
> > named '
> > --- a/hw/arm/highbank.c
> > +++ b/hw/arm/highbank.c
> > @@ -250,15 +250,15 @@ static void calxeda_init(QEMUMachineInitArgs *args,
> > enum cxmachines machine)
> > sysram = g_new(MemoryRegion, 1);
> > memory_region_init_ram(sysram, NULL, "highbank.sysram", 0x8000);
> > memory_
On 1 October 2013 21:16, Gerd Hoffmann wrote:
> Hi,
>
>> -bios we're stuck with because it's a legacy
>> option,
>
> What is legacy about it?
The fact that we've had it since forever, it was introduced for
a specific x86 use case and has since accreted behaviour
rather than being designed.
>>
Hi,
Am 01.10.2013 14:16, schrieb Gerd Hoffmann:
>> -bios we're stuck with because it's a legacy
>> option,
>
> What is legacy about it?
>
> Well, the x86-centric name of course. Thats why the machine option is
> named 'firmware' instead.
>
> It also doesn't use QemuOpts, which is fixed by this
Hi,
> -bios we're stuck with because it's a legacy
> option,
What is legacy about it?
Well, the x86-centric name of course. Thats why the machine option is
named 'firmware' instead.
It also doesn't use QemuOpts, which is fixed by this patch.
Anything else?
> >> Why is this a machine option
On 1 October 2013 20:22, Gerd Hoffmann wrote:
> On Di, 2013-10-01 at 19:55 +0900, Peter Maydell wrote:
>> No documentation or definition of what the semantics of
>> specifying a "firmware image" filename are?
>
> "-machine firmware=$file" has the same effect as "-bios $file", which is
> simliar to
On Di, 2013-10-01 at 19:55 +0900, Peter Maydell wrote:
> On 1 October 2013 18:39, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann
> > ---
> > hw/alpha/dp264.c| 2 +-
> > hw/arm/highbank.c | 8
> > hw/i386/pc.c| 6 --
> > hw/i386/pc_piix.c |
On 1 October 2013 18:39, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> hw/alpha/dp264.c| 2 +-
> hw/arm/highbank.c | 8
> hw/i386/pc.c| 6 --
> hw/i386/pc_piix.c | 3 ++-
> hw/i386/pc_q35.c| 3 ++-
> hw/i386/pc_sysfw.c
Signed-off-by: Gerd Hoffmann
---
hw/alpha/dp264.c| 2 +-
hw/arm/highbank.c | 8
hw/i386/pc.c| 6 --
hw/i386/pc_piix.c | 3 ++-
hw/i386/pc_q35.c| 3 ++-
hw/i386/pc_sysfw.c | 8 +---
hw/lm32/milkymist.c | 8
hw/mips/m
20 matches
Mail list logo
