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.
