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

[Blue Swirl]

On Sat, Jun 5, 2010 at 8:25 PM, Bob Breuer <address@hidden> wrote:
> Blue Swirl wrote:
>> 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.
>>
>
> With empty_slot SS-20 OBP accesses just 2 addresses for slot E:
>    0xEE0001000 - 8bit read (FCode)
>    0xEE0010000 - 32bit write (put DBRI into reset)
>
> Did a little digging, slot E starts at 0xEE0000000 (0xE << 32 | slot <<
> 28).  On my SS-20, the DBRI FCode is only 48 bytes which is then
> mirrored every 64 bytes within at least the first 8K, and the actual
> registers are at offset 64K with a reported length of 256 bytes.
>
> Besides hooking up DBRI (empty_slot or not), I would propose the
> following additions to the sun4m_hwdef structure so that the other
> missing pieces can then be hooked up to empty_slot.
>
> --- a/hw/sun4m.c
> +++ b/hw/sun4m.c
> @@ -98,6 +98,10 @@ struct sun4m_hwdef {
>     target_phys_addr_t serial_base, fd_base;
>     target_phys_addr_t afx_base, idreg_base, dma_base, esp_base, le_base;
>     target_phys_addr_t tcx_base, cs_base, apc_base, aux1_base, aux2_base;
> +    target_phys_addr_t dbri_base, sx_base;
> +    struct {
> +        target_phys_addr_t reg_base, vram_base;
> +    } vsimm[4];

OK by itself, but again: should we have a new machine with cg14 or
some switch to select TCX vs. cg14?

Maybe the recently proposed machine subtype patches could help here.

>     target_phys_addr_t ecc_base;
>     uint32_t ecc_version;
>     uint8_t nvram_machine_id;
>
> Also, looks like OpenBIOS would need some additional ranges added under
> obio and sbus.  From a SS-20:
> ok cd /obio
> ok .attributes
> ranges                   00000000  00000000  0000000f  f1000000  01000000
>                         00000001  00000000  00000000  90000000  04000000
>                         00000002  00000000  00000000  9c000000  04000000
>                         00000003  00000000  00000000  f0000000  04000000
>                         00000004  00000000  00000000  fc000000  04000000
> device_type              hierarchical
> name                     obio
> ok cd /iommu/sbus
> ok .attributes
> clock-frequency          017d7840
> scsi-initiator-id        00000007
> burst-sizes              00f8007f
> ranges                   00000000  00000000  0000000e  00000000  10000000
>                         00000001  00000000  0000000e  10000000  10000000
>                         00000002  00000000  0000000e  20000000  10000000
>                         00000003  00000000  0000000e  30000000  10000000
>                         0000000e  00000000  0000000e  e0000000  10000000
>                         0000000f  00000000  0000000e  f0000000  10000000
> address                  ffeec000
> reg                      0000000f  e0001000  00000020
> slot-address-bits        0000001c
> up-burst-sizes           0000003f
> device_type              hierarchical
> name                     sbus

Again, the question is how to pass cg14 vs. TCX info to OpenBIOS.