Radeon R9 270X may or may not have a usable solution right now. I think it is workable from a "does it function" point of view as long as you disable interrupts. This as Joerg pointed out is likely no good longer term. I'm a little confused on replies from Hans. I have a suspicion from the explanation of how the interrupt handlers should return 1 or 0, the v5 drivers might not work and the earlier ones would.
To clarify, the pre-v5 RadeonHD.chip correctly returns 0 when it doesn't process an interrupt. This makes it able to share interrupts with other devices. The v5 RadeonHD.chip driver has the same bug as the RadeonRX.chip driver, and always returns 1 (which is supposed to mean "yes, I processed this interrupt").
If you still have to disable interrupts with he RadeonHD.chip v3 driver, then the problem is likely something else. The driver is doing what it's supposed to.
Quote:
As for the fan, maybe I was just "unlucky" that the card I found for cheap on fleabay was the 270X. I mean, I was lucky that it came up cheap when all the others were at least 2x the price or more, but maybe a 270 might not have had the fan issue. Or it could even be make and model specific I guess.
I've always tried to buy "silent" or "quiet" graphics card models that either have passive cooling, or have quiet fans. Cards not designed for quiet operation can sound like an aircraft taking off.
What does alpha support here mean? The SM501 does have a 2D engine which can do Windows ROPs including compositing so maybe the driver should use that but it doesn't and the defaults in graphics.library can't do software rendering in 32 bit mode only in packed 24 bit mode? I don't get all this but I don't know anthing about graphics.library especially the parts related to RTG but maybe this is helpful for somebody who understands all this. I still believe the sm502 driver is limited as even as a simple framebuffer supporting 32 bit mode could help. If that's possible for @m3x to do easily then it may worth trying unless it's impossible for some reason which I'm still not convinced about but it may be too much work to do.
The problem with compositing, is that the SM502 only supports the alpha channel being in a separate bitmap (or bitplane), whereas AmigaOS mostly uses ARGB32 bitmaps, with the alpha channel included in the chunky 32-bit pixel. Emulating compositing with ARGB32 using a separate alpha bitmap isn't easy, and would be very slow if the SM502 isn't able to extract an alpha channel from an ARGB32 bitmap and write it to a separate alpha bitmap.
The problem with compositing, is that the SM502 only supports the alpha channel being in a separate bitmap (or bitplane), whereas AmigaOS mostly uses ARGB32 bitmaps, with the alpha channel included in the chunky 32-bit pixel. Emulating compositing with ARGB32 using a separate alpha bitmap isn't easy, and would be very slow if the SM502 isn't able to extract an alpha channel from an ARGB32 bitmap and write it to a separate alpha bitmap.
Hans
I did not read all the SM502 docs but AFAIU the separate alpha bitmap is only used for compositing graphics output to a video input (as this chip was probably meant to be used in a set top box or similar) but in 32bit graphics mode without video layer it stores RGBA and just ignores the A part so you could store the alpha channel there and use it for software rendering, can't you?
Still trying to find out how to boot AmigaOS without pegasos2.rom
I've figured this out. Looks like it crashed on wrong assigned-addresses properties. It seems at least the sm502 driver needs both an assigned-addresses property and the card being programmed by the firmware with noth the BARs written with the values corresponding to the assigned-addresses AND also PCI config reg 0x3c set to the IRQ it should use (which is 9 for everything on pegasos2). After that it boots but I still have some things hard coded in QEMU for it so now I'll have to find out what else is needed and try to do all this from the boot loader so we don't need changes in QEMU as other guests don't need any of this so this should really be in AmigaOS that we can now patch up in the boot loader instead. This will take some time to to but I don't see a blocking issue now.
This may be different for other graphics drivers but it seems AmigaOS relies more on firmware setting things up than other guests do.
I did not read all the SM502 docs but AFAIU the separate alpha bitmap is only used for compositing graphics output to a video input (as this chip was probably meant to be used in a set top box or similar)
The SM501/2 has 5 layers (+ 2 CRT-only ones, which aren't used): - Hardware cursor (used by AmigaOS, but not very important) - Alpha layer (that's what would be required for AmigaOS alpha, but separate alpha bitmaps aren't supported by AmigaOS) - Video alpha layer (not required, or maybe only for video playback, or maybe even mixing external video input sources to the output, not sure) - Video layer (since it supports YUV422 it could be something like PIP/overlay in old gfx cards like the Voodoo ones, but I'm not sure) - Graphics layer (8/16/32 bit pixels, i.e. the standard pixels, but without alpha) Check for example this PDF
Quote:
but in 32bit graphics mode without video layer it stores RGBA and just ignores the A part so you could store the alpha channel there and use it for software rendering, can't you?
Software rendering is way too slow for compositing, and additionally to a standard A8R8G8B8 32 bit framebuffer it has to constantly copy the alpha parts to/from it's seperate alpha layer/bitmap making it even much slower. Unless there is some hardware support in the SM501/2 for extracting/adding the alpha layer from/to an A8R8G8B8 bitmap and moving it to/from it's separate alpha bitmap it's not usable at all.
Quote:
This may be different for other graphics drivers but it seems AmigaOS relies more on firmware setting things up than other guests do.
It does, and the reason is very simple: The firmwares (CFE on the X1000, U-Boot on anything else) were implemented, or at least vastly improved/adapted to AmigaOS, by the AmigaOS kernel developers. The firmware of all Amiga NG systems configure the hardware exactly the way the AmigaOS kernel, and AmigaOS hardware drivers, needs it, which severely reduces the platform specific code required in the different kernels and drivers. The only exception is the Pegasos2 with it's SmartFirmware.
@joerg But that Alpha layer and the hardware alpha blending that uses it are not used by the AmigaOS driver so it does not have to move any data there. It already does software compositing for 16 bit mode as the sm502 driver has no compositing support and I think it could just do the same with 32 bit too so there's no hadware limitation here just a driver limitation. How I know it's not used? QEMU does not emulate any of it and we still get picture in AmigaOS. What we had to add was some blitter ops that are used but that should work the same in 32 bit mode. It may be too slow on a real sam460ex with a 1GHz CPU but people use PCIe gfx cards there anyways and it could be usable with QEMU. But since @m3x did not react on any of this I think he's not interested to change this driver any more so we're stuck with what we have. To resolve the problem need to write a new driver but then target a better option such as virtio. So this is just to understand if there's a hadware limitation or a software one. I think there's no hardware problem just that driver was only made for 8 and 16 bit modes.
@MartinW I wasn't clear in the post above about my boot loader that what I've found about sm502 driver needing assigned addresses, BARs programmed and IRQ programmed via PCI config reg 0x3c of the card might also be relevant for passed through cards, althogh I don't know if the Radeon drivers need the same. But in any case check that when at the firmware prompt the card has these set up and if not these might need to be patched from the script converting BARs. In particular IRQ should be set to 9, if not then it may check the wrong IRQ or miss them that leads to a hang. I think the pegasos2.rom would set this for all PCI cards unconditionally but maybe worth a check. This may not even show up in info pci although that lists IRQ for some devices it does not show it for sm501 for example but I don't know why. So one has to check the PCI config reg 0x3c somehow. I don't know an easy way, maybe -trace enable="pci*" shows accesses to config regs and one can check there. Maybe it's not causing the IRQ issue with passed through cards but worths a try checking it anyway.
But that Alpha layer and the hardware alpha blending that uses it are not used by the AmigaOS driver so it does not have to move any data there
It doesn't have to for 15/16 bit modes (no alpha at all, or at most a 1 bit one), but it would have to for 32 bit ARGB modes. Supporting a 24 bit RGB mode (no alpha either) instead of 32 bit ARGB may be possible in the SM50x driver, but it would be slower than an ARGB 32 bit framebuffer driver using the QEmu vga-ati emulation. Unlike SM501/2 the ATI emulation is using a combined ARGB 32 bit alpha + RGB pixel mode, which is the standard format supported by AmigaOS, instead of separate alpha + RGB bitmaps.
Specifically, the part about addresses has been my suspicion all along because even after we have changed the "assigned-addresses" property in the firmware (and the reg property), this change is not reflected in either Qemu's info pci, or the firmware's "show-pci-full". To date I've just assumed that maybe the output of that command is only refreshed when a full probe is done by the firmware, which we wouldn't want to force / repeat as it would presumably override the values we've patched and we'd be back where we started. But the fact that Qemu doesn't seem to be aware of the updates we make is likely more problematic further down the line.
So, yes, I suspect you're correct about needing to program this info to the card, or at least commit it in some way (map-in ?) so that Qemu and the firmware both fully reflect the change(s).
I think the IRQs are already showing as 9 but I can check after work. If not, then I'd have to read up on that.
@balaton info pci shows everything except the IDE controller as having IRQ 9. the pin numbes are different. For some reason the IDE controller is on IRQ 14. The bochs display doesn't have an IRQ listed at all but I think that's disconnected?
I'm not really sure at the moment how I could confim the same from within Smart Firmware. I'll have a read. Ranger confirms the interrupts as the same as qemu with one exception. It shows the bochs display as IRQ 9 but with no pin (line in Ranger).
balaton wrote:@MartinW I don't know an easy way, maybe -trace enable="pci*" shows accesses to config regs and one can check there. Maybe it's not causing the IRQ issue with passed through cards but worths a try checking it anyway.
Im getting constant output of the following lines after using -trace for pci*. There is so many that i had to freeze qemu to use the monitor as the output disappeared as soon as i pressed enter.
(qemu) info qtree
bus: main-system-bus
type System
dev: ps2-mouse, id ""
gpio-out "" 1
dev: ps2-kbd, id ""
gpio-out "" 1
dev: mv64361-pcihost, id ""
index = 1 (0x1)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pci.1
type PCI
dev: rtl8139, id ""
mac = "52:54:00:12:34:56"
netdev = "net0"
addr = 03.0
romfile = "efi-rtl8139.rom"
romsize = 262144 (0x40000)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Ethernet controller, addr 00:03.0, pci id 10ec:8139 (sub 1af4:1100)
bar 0: i/o at 0x1200 [0x12ff]
bar 1: mem at 0xffffffffffffffff [0xfe]
bar 6: mem at 0xffffffffffffffff [0x3fffe]
dev: bochs-display, id ""
vgamem = 16777216 (16 MiB)
edid = true
xres = 1280 (0x500)
yres = 800 (0x320)
xmax = 0 (0x0)
ymax = 0 (0x0)
refresh_rate = 0 (0x0)
addr = 02.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Display controller, addr 00:02.0, pci id 1234:1111 (sub 1af4:1100)
bar 0: mem at 0xffffffffffffffff [0xfffffe]
bar 2: mem at 0xffffffffffffffff [0xffe]
dev: vfio-pci, id ""
host = "0000:0b:00.0"
vf-token = "00000000-0000-0000-0000-000000000000"
sysfsdev = "/sys/bus/pci/devices/0000:0b:00.0"
x-pre-copy-dirty-page-tracking = "on"
display = "off"
xres = 0 (0x0)
yres = 0 (0x0)
x-intx-mmap-timeout-ms = 1100 (0x44c)
x-vga = true
x-req = true
x-igd-opregion = false
enable-migration = "auto"
x-no-mmap = false
x-balloon-allowed = false
x-no-kvm-intx = false
x-no-kvm-msi = false
x-no-kvm-msix = false
x-no-geforce-quirks = false
x-no-kvm-ioeventfd = false
x-no-vfio-ioeventfd = false
x-pci-vendor-id = 4098 (0x1002)
x-pci-device-id = 26641 (0x6811)
x-pci-sub-vendor-id = 4294967295 (0xffffffff)
x-pci-sub-device-id = 4294967295 (0xffffffff)
x-igd-gms = 0 (0x0)
x-nv-gpudirect-clique = 255 (0xff)
x-msix-relocation = "off"
addr = 01.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = true
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class VGA controller, addr 00:01.0, pci id 1002:6811 (sub 1462:3050)
bar 0: mem at 0x80000000 [0x8fffffff]
bar 2: mem at 0x90000000 [0x9003ffff]
bar 4: i/o at 0x1100 [0x11ff]
bar 6: mem at 0xffffffffffffffff [0x1fffe]
dev: via-mc97, id ""
addr = 0c.6
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Class 0780, addr 00:0c.6, pci id 1106:3068 (sub 1af4:1100)
dev: via-ac97, id ""
audiodev = "none"
addr = 0c.5
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Audio controller, addr 00:0c.5, pci id 1106:3058 (sub 1af4:1100)
bar 0: i/o at 0x1300 [0x13ff]
bar 1: i/o at 0x1030 [0x1033]
bar 2: i/o at 0x1034 [0x1037]
dev: vt8231-pm, id ""
addr = 0c.4
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Bridge, addr 00:0c.4, pci id 1106:8235 (sub 1af4:1100)
bus: i2c
type i2c-bus
dev: smbus-eeprom, id ""
address = 87 (0x57)
dev: vt82c686b-usb-uhci, id ""
bandwidth = 1280 (0x500)
maxframes = 128 (0x80)
addr = 0c.3
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class USB controller, addr 00:0c.3, pci id 1106:3038 (sub 1af4:1100)
bar 4: i/o at 0x1060 [0x107f]
bus: usb-bus.1
type usb-bus
dev: vt82c686b-usb-uhci, id ""
bandwidth = 1280 (0x500)
maxframes = 128 (0x80)
addr = 0c.2
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class USB controller, addr 00:0c.2, pci id 1106:3038 (sub 1af4:1100)
bar 4: i/o at 0x1040 [0x105f]
bus: usb-bus.0
type usb-bus
dev: via-ide, id ""
gpio-in "" 2
gpio-out "isa-irq" 2
addr = 0c.1
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class IDE controller, addr 00:0c.1, pci id 1106:0571 (sub 1af4:1100)
bar 0: i/o at 0x1000 [0x1007]
bar 1: i/o at 0x100c [0x100f]
bar 2: i/o at 0x1010 [0x1017]
bar 3: i/o at 0x101c [0x101f]
bar 4: i/o at 0x1020 [0x102f]
bus: ide.1
type IDE
dev: ide-cd, id ""
drive = "ide1-cd0"
backend_defaults = "auto"
logical_block_size = 512 (512 B)
physical_block_size = 512 (512 B)
min_io_size = 0 (0 B)
opt_io_size = 0 (0 B)
discard_granularity = 512 (512 B)
write-cache = "auto"
share-rw = false
account-invalid = "auto"
account-failed = "auto"
rerror = "auto"
werror = "auto"
ver = "2.5+"
wwn = 0 (0x0)
serial = "QM00003"
model = ""
unit = 0 (0x0)
bus: ide.0
type IDE
dev: ide-hd, id ""
drive = "ide0-hd1"
backend_defaults = "auto"
logical_block_size = 512 (512 B)
physical_block_size = 512 (512 B)
min_io_size = 0 (0 B)
opt_io_size = 0 (0 B)
discard_granularity = 512 (512 B)
write-cache = "auto"
share-rw = false
account-invalid = "auto"
account-failed = "auto"
rerror = "auto"
werror = "auto"
ver = "2.5+"
wwn = 0 (0x0)
serial = "QM00002"
model = ""
cyls = 4063 (0xfdf)
heads = 16 (0x10)
secs = 63 (0x3f)
lcyls = 0 (0x0)
lheads = 0 (0x0)
lsecs = 0 (0x0)
bios-chs-trans = "lba"
rotation_rate = 0 (0x0)
unit = 1 (0x1)
dev: ide-hd, id ""
drive = "ide0-hd0"
backend_defaults = "auto"
logical_block_size = 512 (512 B)
physical_block_size = 512 (512 B)
min_io_size = 0 (0 B)
opt_io_size = 0 (0 B)
discard_granularity = 512 (512 B)
write-cache = "auto"
share-rw = false
account-invalid = "auto"
account-failed = "auto"
rerror = "auto"
werror = "auto"
ver = "2.5+"
wwn = 0 (0x0)
serial = "QM00001"
model = ""
cyls = 4161 (0x1041)
heads = 16 (0x10)
secs = 63 (0x3f)
lcyls = 0 (0x0)
lheads = 0 (0x0)
lsecs = 0 (0x0)
bios-chs-trans = "lba"
rotation_rate = 0 (0x0)
unit = 0 (0x0)
dev: vt8231-isa, id ""
gpio-in "pirq" 4
gpio-out "" 1
addr = 0c.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = true
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class ISA bridge, addr 00:0c.0, pci id 1106:8231 (sub 1af4:1100)
bus: isa.0
type ISA
dev: i8042, id ""
gpio-in "ps2-mouse-input-irq" 1
gpio-in "ps2-kbd-input-irq" 1
gpio-out "" 2
gpio-out "a20" 1
extended-state = true
kbd-throttle = false
kbd-irq = 1 (0x1)
mouse-irq = 12 (0xc)
dev: isa-fdc, id ""
iobase = 1008 (0x3f0)
irq = 6 (0x6)
dma = 2 (0x2)
fdtypeA = "auto"
fdtypeB = "auto"
fallback = "288"
bus: floppy-bus.0
type floppy-bus
dev: floppy, id ""
unit = 0 (0x0)
drive = "floppy0"
backend_defaults = "auto"
logical_block_size = 512 (512 B)
physical_block_size = 512 (512 B)
min_io_size = 0 (0 B)
opt_io_size = 0 (0 B)
discard_granularity = 4294967295 (4 GiB)
write-cache = "auto"
share-rw = false
account-invalid = "auto"
account-failed = "auto"
drive-type = "288"
dev: isa-serial, id ""
index = 0 (0x0)
iobase = 760 (0x2f8)
irq = 4 (0x4)
dev: isa-parallel, id ""
index = 0 (0x0)
iobase = 888 (0x378)
irq = 7 (0x7)
chardev = "parallel0"
dev: vt8231-superio, id ""
dev: mc146818rtc, id ""
gpio-out "" 1
base_year = 0 (0x0)
iobase = 112 (0x70)
irq = 8 (0x8)
lost_tick_policy = "discard"
dev: i8257, id ""
base = 192 (0xc0)
page-base = 136 (0x88)
pageh-base = -1 (0xffffffffffffffff)
dshift = 1 (0x1)
dev: i8257, id ""
base = 0 (0x0)
page-base = 128 (0x80)
pageh-base = -1 (0xffffffffffffffff)
dshift = 0 (0x0)
dev: isa-pit, id ""
gpio-in "" 1
gpio-out "" 1
iobase = 64 (0x40)
dev: isa-i8259, id ""
gpio-in "" 8
gpio-out "" 1
iobase = 160 (0xa0)
elcr_addr = 1233 (0x4d1)
elcr_mask = 222 (0xde)
master = false
dev: isa-i8259, id ""
gpio-in "" 8
gpio-out "" 1
iobase = 32 (0x20)
elcr_addr = 1232 (0x4d0)
elcr_mask = 248 (0xf8)
master = true
dev: mv64361-pcibridge, id ""
addr = 00.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Host bridge, addr 00:00.0, pci id 11ab:6460 (sub 1af4:1100)
dev: mv64361-pcihost, id ""
index = 0 (0x0)
x-config-reg-migration-enabled = true
bypass-iommu = false
bus: pci.0
type PCI
dev: mv64361-pcibridge, id ""
addr = 00.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class Host bridge, addr 00:00.0, pci id 11ab:6460 (sub 1af4:1100)
dev: mv64361, id ""
gpio-in "gpp" 32
gpio-out "sysbus-irq" 1
mmio ffffffffffffffff/0000000000010000
This starts as soon as the workbench appears - which is also when Amidock loads - and you can see/feel the slowness as stdio fills up with the messages.
Are the 2 host bridges meant to have the same details? "Bus 0, device 0, function 0:" etc
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device 11ab:6460
PCI subsystem 1af4:1100
id ""
Bus 0, device 1, function 0:
VGA controller: PCI device 1002:6811
PCI subsystem 1462:3050
IRQ 9, pin A
BAR0: 64 bit prefetchable memory at 0x80000000 [0x8fffffff].
BAR2: 64 bit memory at 0x90000000 [0x9003ffff].
BAR4: I/O at 0x1100 [0x11ff].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
id ""
Bus 0, device 2, function 0:
Display controller: PCI device 1234:1111
PCI subsystem 1af4:1100
BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x00fffffe].
BAR2: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
id ""
Bus 0, device 3, function 0:
Ethernet controller: PCI device 10ec:8139
PCI subsystem 1af4:1100
IRQ 9, pin A
BAR0: I/O at 0x1200 [0x12ff].
BAR1: 32 bit memory at 0xffffffffffffffff [0x000000fe].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
id ""
Bus 0, device 12, function 0:
ISA bridge: PCI device 1106:8231
PCI subsystem 1af4:1100
id ""
Bus 0, device 12, function 1:
IDE controller: PCI device 1106:0571
PCI subsystem 1af4:1100
IRQ 14, pin A
BAR0: I/O at 0x1000 [0x1007].
BAR1: I/O at 0x100c [0x100f].
BAR2: I/O at 0x1010 [0x1017].
BAR3: I/O at 0x101c [0x101f].
BAR4: I/O at 0x1020 [0x102f].
id ""
Bus 0, device 12, function 2:
USB controller: PCI device 1106:3038
PCI subsystem 1af4:1100
IRQ 9, pin D
BAR4: I/O at 0x1040 [0x105f].
id ""
Bus 0, device 12, function 3:
USB controller: PCI device 1106:3038
PCI subsystem 1af4:1100
IRQ 9, pin D
BAR4: I/O at 0x1060 [0x107f].
id ""
Bus 0, device 12, function 4:
Bridge: PCI device 1106:8235
PCI subsystem 1af4:1100
id ""
Bus 0, device 12, function 5:
Audio controller: PCI device 1106:3058
PCI subsystem 1af4:1100
IRQ 9, pin C
BAR0: I/O at 0x1300 [0x13ff].
BAR1: I/O at 0x1030 [0x1033].
BAR2: I/O at 0x1034 [0x1037].
id ""
Bus 0, device 12, function 6:
Class 1920: PCI device 1106:3068
PCI subsystem 1af4:1100
IRQ 9, pin C
id ""
Bus 0, device 0, function 0:
Host bridge: PCI device 11ab:6460
PCI subsystem 1af4:1100
id ""
(qemu)
Introducing BBoot, the boot loader I proposed before and was werking on. This should be useful for multiple use cases. The main goal is to be able to boot AmigaOS without needing pegasos2.rom but it should also help with other problems such as debugging PCI pass through as it will try to fix BARs or at least provide detailed info on how the firmware and card sees them. More info on the project page at: https://osdn.net/projects/qmiga/wiki/SubprojectBBoot and supposed to be available under File releases there but since OSDN seems to be dying since recently I've also uploaded it here: http://zero.eik.bme.hu/~balaton/amiga/bboot/
The README in the package should give some idea on how to use it. One important details that -initrd option needs QEMU compiled from git master so if you're using older version it will not work. (There's a generic loader that may be used instead but I have no idea how to use it but ir's documented in the QEMU docs if somebody really wants to find out.)
@derfs There's also info qom-tree which should help identifying what device /machine/peripheral-anon/device[0] may refer to and maybe you should try to give bboot a try and post the log that should show how BARs are set up or if it could fix them.
Is there a reliable way to detect when the OS is running under emulation rather than real hardware? I'm considering enabling GART in the driver when it's used under emulation, because all modern hardware has memory coherence.
Or, is the Marvell Discovery II chipset's cache already coherent?
Is there a reliable way to detect when the OS is running under emulation rather than real hardware? I'm considering enabling GART in the driver when it's used under emulation, because all modern hardware has memory coherence.
There are probably easier ways, but for example the Vendor string of the emulated HDs (HD_SCSICmd, SCSI Inquery) includes "QEmu".
Quote:
Or, is the Marvell Discovery II chipset's cache already coherent?
Should be, since that was the reason for using the Marvell in the Pegasos2 instead of the Articia-S in the Pegasos1.
Introducing BBoot, the boot loader I proposed before and was werking on. This should be useful for multiple use cases. The main goal is to be able to boot AmigaOS without needing pegasos2.rom but it should also help with other problems such as debugging PCI pass through as it will try to fix BARs or at least provide detailed info on how the firmware and card sees them.
Very good work and in this short time.
I have already made a few tests to start AmigaOs4.1 with BBoot and Qemu which unfortunately fails.
How did I proceed:
I took the Kickstart folder of my AmigaOs4.1 installation and packed it as "Kickstart.zip". After reading your readme I put the whole thing into Qemu.
For some reason AmigaOs4.1 does not boot because the modules cannot be found or loaded, but they are in the archive Kickstart.zip. Qemu was built from the git master sources from https://scm.osdn.net/gitroot/qmiga/qemu.git
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
