qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: option-rom (was cg14)


From: Blue Swirl
Subject: [Qemu-devel] Re: option-rom (was cg14)
Date: Fri, 4 Jun 2010 19:28:53 +0000

On Fri, Jun 4, 2010 at 5:40 PM, Artyom Tarasenko
<address@hidden> wrote:
>>>> 2010/5/27 Bob Breuer <address@hidden>:
>>>> +    /* DBRI (audio) */
>>>> +    cpu_register_physical_memory_offset(0xEE0001000ULL, 0x10000, bad_mem, 
>>>> 0xE0001000);
>>>
>>> Please add a new DBRI device ;-).
>>
>> Or maybe just a field in hwdef + empty_slot? :-)
>
> Or actually don't bother at all. What is expected at 0xee0001000 is
> not the DBRI device, but its FCode driver.
> I wrote a stub, but don't see that it helps to boot except one has a
> nice device name (
>
> Probing /obio at 2,0  cgfourteen
> Probing /address@hidden,e0000000/address@hidden,e0001000 at f,0  espdma esp 
> sd st
> ledma le SUNW,bpp
> Probing /address@hidden,e0000000/address@hidden,e0001000 at e,0  
> qemu,device-stub
> Probing /address@hidden,e0000000/address@hidden,e0001000 at 0,0  Nothing there
>
>  ) and switching off slot "e" probing is not necessary.
>
>
> What would be nice is a generic '-option-rom' switch which would take
> a rom address and rom file or contents
> as params. Or do we have something like this? I mean for qemu-system-sparc.

Maybe SysBusDeviceInfo should have something similar to PCI .romfile
field, or we should rather have a SBusDeviceInfo. That way ROM
handling would be automatic.



reply via email to

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