qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/77] ppc: Add "native" POWER8 platf


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/77] ppc: Add "native" POWER8 platform
Date: Mon, 7 Dec 2015 23:48:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0

On 12/07/2015 02:25 AM, Stewart Smith wrote:
> Cédric Le Goater <address@hidden> writes:
>> On 11/28/2015 08:59 AM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote:
>>>>
>>>> How does real hardware store petitboot? If it's flash, you could pass it
>>>> in using -pflash and thus model things even more closely and allow users
>>>> to just take the ROM image as is.
>>>
>>> It is a flash image, we could use an Open Power machine flash image "as-is"
>>> provided we taught qemu to extract skiboot (aka OPAL) from it.
>>
>> Couldn't we add an offset argument to load_image_targphys() or make that 
>> an extra routine ? If so, we could then load directly from an openpower 
>> pnor file. 
>>
>> I gave it a quick (and dirty) try and a powernv guest runs fine up to 
>> petitboot with just :
>>
>>      qemu-system-ppc64 -m 2G -M powernv -bios  
>> ~/work/open-power/images/palmetto.pnor -nographic -nodefaults -serial stdio
>>
>> The pnor file is compiled from github. The patch is below (without the dirty
>> cut and paste I did in loader.c). The offset for the PAYLOAD and BOOTKERNEL
>> partitions are hard coded but I guess we don't need to read the flash 
>> partition
>> table in qemu, not yet.
> 
> One downside to this is that if we don't fall back to being able to load
> skiboot.lid it becomes more annoying to boot a gcov enabled skiboot as
> typical PNOR layout only gives 1MB for skiboot, and gcov builds bloat
> that a *lot*.

I guess that what we can imagine having a bigger partition for skiboot 
in the case of gcov ?  This will require a custom pnor build. Might be 
too complex. Or we could use a -pflash option to load the pnor and an
optional -bios for skiboot if we want a custom one.

> We probably don't want NVRAM writes going back to a single system wide
> PNOR image too, so while using pnor file is great for simulating what
> hardware does, may not work as the solution for long term model.

we can use a memory backend to start with, which is also much simpler 
than having to handle the block backend like the cfi pflash is doing. 
a guest could use its own private pnor if a block backend is needed.

C. 




reply via email to

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