On Sat, Jun 5, 2010 at 8:25 PM, Bob Breuer <breu...@mc.net> wrote:
> Blue Swirl wrote:
>> On Fri, Jun 4, 2010 at 5:40 PM, Artyom Tarasenko
>> <atar4q...@googlemail.com> wrote:
>>
>>>>>> 2010/5/27 Bob Breuer <breu...@mc.net>:
>>>>>> + /* 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 /io...@f,e0000000/s...@f,e0001000 at f,0 espdma esp sd st
>>> ledma le SUNW,bpp
>>> Probing /io...@f,e0000000/s...@f,e0001000 at e,0 qemu,device-stub
>>> Probing /io...@f,e0000000/s...@f,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.
