Headlines |
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
-
libfaac.lha - development/library/audio
Apr 22, 2024
-
libfaad.lha - development/library/audio
Apr 22, 2024
-
image2pdf.lha - utility/text/convert
Apr 22, 2024
-
libharfbuzz.lha - development/library/graphics
Apr 20, 2024
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home 
|
@kas1e
The kernel was already using RTAS for accessing PCI configuration registers.
Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton Quote: I could help with that but I only work for free on open source projects that I can then also use myself. But if I won't get the result and you're payed to do that and not me I'll let you figure that out (or you can hire me for consulting if needed). Thanks for your help so far. This would have been better left unsaid, though. It reminds me of another person who refused to give any assistance because I'm "working on the wrong OS." I would have helped him out if he asked... BTW, kas1e offered a small bounty to get this fixed. That's all the "reward" that's available monetarily. If this were on a commercial basis, then I wouldn't be here. Quote: Sorry for that but I believe in free software. I don't mind if others don't but then the rules of commercial software should be applied for those projects which means you get what you pay for. I appreciate free software, but I certainly don't demand it. I'm also sick and tired of the passive-aggressive bullying & harassment that comes from open-source advocates. It is entirely reasonable to want to be paid for your work so that you can practise your craft full-time. And yes, that includes the craft of writing software. As a solo developer I don't have big budgets, I don't have a "day job," or a trust fund, or anything else to keep my family fed and sheltered. If I can't earn enough to support my family from writing software, then I simply won't have the time to write any more code. Sorry for the rant, but I'm sick of this kind of attitude. Hans p.s., To be clear, I don't expect any help from you (although what you've given is appreciated). Just lighten up on the attitude, please.
Edited by Hans on 2024/4/27 3:57:14
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: Yesterday 12:59
#3
|
Home away from home
|
@kas1e
Try the other way round: 16 config-l@
I have very little experience with OpenFirmWare, and remember the syntax being unusual, and error messages being very cryptic. That's because it's based on the Forth scripting language, which is stack based. It takes some getting used to.
I did manage to piece together a script for fixing up the previous PCI issues (i.e., making a 64-bit PCI device look like a 32-bit one), and the syntax looked something like this:
s" /pci/display@2" find-device
Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton
Ah, okay. So if kas1e cd'd to the graphics card, then maybe config-l@ 16 would read BAR0 (BAR0's offset is 16, or 0x10).
AFAICT, with RTAS you need to pass the full PCI card address: PCI domain, bus, device, function. And, of course, the register you want to access. I've tried that, and it works for all cards except the one behind the PCI-to-PCI bridge.
Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton
Thanks for helping despite the lack of interest.
I find the OpenFirmware documentation to be rather difficult to understand. Theoretically, section 2.1.4 explains how to address a particular card's config registers. However, it glosses over the "PCI domain." How do we address a particular PCI domain? How do we even know how many PCI domains there are? It seems to be related to how many PCI root controllers there are.
Then there's this annoying statement:
"Note: the decoding mechanism (e.g., the address bit selected) from the Device Number is system dependent. Fur-
thermore, the implementation of the Open Firmware
config-xx words can "hide" this detail. However, it is
recommended that an Open Firmware implementation choose a numbering which is meaningful to the user."
So, we don't know in what format to pass the config-* parameters...
I have also been unable to find a specification for the RTAS feature. There are vague references to it in some documents, but no link to a specification.
Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton Thanks. I'll have a look at the docs. Quote: Did you try if you can access the card behind the bridge with config-l@ config-w@ and so on from the SmartFirmware prompt? I don't have physical access to a Pegasos-II, so this is something for kas1e to try. He might need a bit more guidance on how to use it... Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton Where did you get this from (bboot/brd_pegasos2):
static int bases_for_bus(prom_handle ph)
{
int i, n = prom_getprop(ph, "ranges", cells, sizeof(cells));
if (n <= 0) {
puts("Cannot get ranges");
return 0;
}
n /= sizeof(cells[0]);
for (i = 0; i < n; i += 6) {
switch (PHYS_HI_TYPE(cells[i])) {
case 1:
iobase = cells[i + 3];
iolen = cells[i + 5];
break;
case 2:
membase = cells[i + 3];
memlen = cells[i + 5];
break;
}
}
if (!iobase || !iolen || !membase || !memlen) {
puts("Cannot get ranges");
return 0;
}
printf("/pci@%x: io %x/%x mem %x/%x\n", membase, iobase, iolen, membase, memlen);
memavail = membase;
unsigned long pci_cfgbase;
if (membase == 0x80000000) {
ioresavail = IORES_START; /* reserved for south bridge functions */
ioavail = IORES_TOP;
pci_cfgbase = MV64361_BASE + 0xc78;
} else if (membase == 0xc0000000) {
ioresavail = iolen; /* no reserved space on this bus */
ioavail = IORES_START;
pci_cfgbase = MV64361_BASE + 0xcf8;
} else {
puts("Unknown PCI bus");
return 0;
}
pci_set_addr(pci_cfgbase, pci_cfgbase + 4);
return 1;
}
Then in pci.c:
void pci_set_addr(unsigned long conf_addr, unsigned long data_addr)
{
pci_conf_addr = conf_addr;
pci_data_addr = data_addr;
}
u8 pci_read_config8(pcidev_t device, u16 reg)
{
write32_le(pci_conf_addr, device | reg | (1UL << 31));
return read8(pci_data_addr);
}
u16 pci_read_config16(pcidev_t device, u16 reg)
{
write32_le(pci_conf_addr, device | reg | (1UL << 31));
return read16_le(pci_data_addr);
}
u32 pci_read_config32(pcidev_t device, u16 reg)
{
write32_le(pci_conf_addr, device | reg | (1UL << 31));
return read32_le(pci_data_addr);
}
...
This code performs direct register writes instead of using OpenFirmware calls or RTAS. Hans
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Home away from home
|
@balaton
I took a quick look at the BBoot source-code. Is it accessing PCI configuration registers via register accesses instead of using OpenFirmware's function calls for that?
If so, is there documentation on how it's done?
The major problem blocking the use of RadeonHD/RX cards on the Pegasos-2, is that attempting to access its PCI configuration registers fails. Reads return either 0, or 0xFFFFFFFF, and writes fail. This is using RTAS calls.
From kas1e's tests, it looks like Linux may also be unable to access the configuration registers.
The Pegasos-II firmware was clearly able to access the device's config registers at some point, or the device wouldn't be listed in the device tree.
If there's documentation on how to read the PCI configuration registers of any device directly (i.e., without RTAS), then we may have a chance to get it working.
Hans
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
|
Home away from home
|
@sailor
[qote]I am sorry Hans, it was joke. It only means, that for me was not enough to read your article, and I had to make some examples and experiments before I understood it completely. Nothing other needed. Thanks.[/quote]
Ah, okay. Suggestions for improvements are still welcome.
Hans
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
|
Home away from home
|
@sailor Quote: Answer is inside this nice Hans's Taborizing guide - see paragraph 2. But unfortunatelly, this guide is too short, is not written for blondes, who did c-coding 25 years before. How could I make it more accessible to "blones, who did C-coding 25 years before?" Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@balaton Quote: I've uploaded BBoot 0.7 (see https://qmiga.codeberg.page/) that might fix this even on real pegasos2 or when using passed through GPU on Linux host. Please test and let me know of any problems found. I've tested this with the original Pegasos2 kernel, and my lockup problems are gone. Nicely done! Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/12 13:14
#12
|
Home away from home
|
@balaton Quote: So check those ELCR bits too and maybe that should be used to fix this instead of the LTIM bit, although now both should work in QEMU. The ELCR offsets are 0x4d0, and 0x4d1. The OS is *NOT* writing to them. I've already experimented with it, and enabling level triggered interrupts for PCI interrupts solves the problem where interrupts suddenly stop coming in. Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/12 10:30
#13
|
Home away from home
|
@joerg
Yes, that surprises me too. I don't see how a shared interrupt line can work 100% properly unless it's level triggered. When it's edge triggered then there's always that narrow window where an interrupt can go missing.
This is going to need a kernel update to fix...
Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@all I can now confirm that the OS puts both PICs in edge triggered mode (as does the firmware). Here are the initialization register writes from AmigaOS:
pic_ioport_write master 1 addr 0x0 val 0x11
pic_ioport_write master 1 addr 0x1 val 0x0
pic_ioport_write master 1 addr 0x1 val 0x4
pic_ioport_write master 1 addr 0x1 val 0x1
pic_ioport_write master 0 addr 0x0 val 0x11
pic_ioport_write master 0 addr 0x1 val 0x8
pic_ioport_write master 0 addr 0x1 val 0x2
pic_ioport_write master 0 addr 0x1 val 0x1
The problem is that the first write to each PIC's command register is 0x11. Bit 3 is zero, which puts the PIC in edge triggered mode. Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@balaton Quote: That sounds wrong if you want it to retrigger interrupts that were not yet serviced. I think edge mode will only trigger the interrupt once when the device signals it but does not keep the state, but I could be wrong about that. I agree. I've captured another log, and it's very clear that it fails when the Virtio GPU interrupt is triggered when IRQ 9's bit is still high from another device. The interrupt gets missed, because the PIC is in edge mode, and there's no edge to trigger it. I'll have a look at how the firmware and OS set up the PIC. Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@balaton Quote: I've asked this before but did you try if the problem also reproduces with -bios pegasos2.rom or using -machine sam460ex that does not use ISA PIC? ... Yes, you've asked this multiple times. However, I'm currently only set up to use BBoot on Pegasos2, so there's a high switching cost. You already posted some info about what the pegasos2.rom is doing with the PIC, here. Quote: Your conclusion is probably right but just to correct the above. There are actually two 8259 PICs in a PC AT (XT had only one) and each can handle 8 interrupt inputs. The master PIC's output is connected to the CPU, the 2nd (slave) PIC's output is connected to INT2 (bit 2, value 4) of the master PIC also called the cascade interrupt that signals there's an interrupt on the slave PIC. Masking out INT2 on master will disable all interrupts >=8. IRQ9 is bit 1, value 2 on the slave so it's not the same bit on both PICs. IRQ1 on master is used by the keyboard. I just realized that I was reading the master and slave round the wrong way. The master PIC is the one with "master 1" (in the logs), and I've been treating "master 0" as the master PIC. @Georg Quote: Another idea: maybe the OS assumes (and possibly did something to make sure) that interrupts don't nest (get called during another interrupt.), or maybe at least don't nest if it's the same interrupt (number). And this for whatever reason is ignored by Qemu.
Can anyone test on real hw if OS prevents nesting interrupts (maybe just if interrupt number is the same). AmigaOS disables interrupts while processing interrupts. So, an interrupt cannot interrupt an existing interrupt handler (what a mouthful...). If an interrupt comes in during that time, then it should be triggered as soon as the existing interrupt handling is done, and interrupts are enabled again. Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/11 10:11
#17
|
Home away from home
|
Final notes for the day. The PIC is programmed in edge-triggered mode, and somehow ends up in a state where bit 2 of last_irr is set, but bit 2 of irr is 0.
Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@Georg
I've already got a way to log various events.
@all
I've been reading up on the PIC, and it looks like something is indeed going wrong with it.
The 8259 has a master and slave, and the slave is mapped through to one of the interrupt lines on the master (IRR = 2, so IRQ 1). The PCI interrupts appear to be routed to the slave (IRR = 2 as well, which is IRQ 9).
So, when a PCI interrupt occurs, then bit 2 should be set on both the master and the slave. However, after something has gone wrong, the master's IRR is 128 instead, which signals IRQ 7 alone. So, IRQ 1 no longer gets set, and no more interrupts get through.
The next question is: is this an emulation error? Or a PIC programming error from the AmigaOS side? I don't understand the PIC well enough yet to decipher the QEMU PIC logging.
Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@Georg Quote: Is everything completely frozen or are other things (not using/affected directly or indirectly by gfx) still running in the system? Like if you create a (high pri) task that every second kprintfs something to debug output. Good question. The rest of the OS is still running, so things like timer interrupts still work. So, the problem really is that external interrupts stop making it through to the interrupt handler(s). Here's a new log showing where it goes wrong:
pic_update_irq master 0 imr 45 irr 2 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
ppc_deliver_interrupt
powerpc_excp_74xx
pic_update_irq master 1 imr 249 irr 5 padd 0
=> Interrupt handling starts
- Not a VirtioGPU interrupt (in emulator)
virtio_pci_notify: 65535
virtio_pci_notify: 65535
virtio_pci_notify: 65535
<= Interrupt handling ends (in emulator)
virtio_pci_notify: 65535
virtio_pci_notify: 65535
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
ppc_deliver_interrupt
powerpc_excp_74xx
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
ppc_deliver_interrupt
powerpc_excp_74xx
The "virtio_pci_notify" log entries are the VirtioGPU triggering an interrupt. So, the failure starts with the VirtioGPU triggering an interrupt while AmigaOS is processing a previous interrupt. The OS has interrupts disabled at this point. It looks like the interrupts are triggered once the OS enables interrupts again, but the PIC's Interrupt Request Register (IRR) has a different value. I'll have to look at the PIC's documentation again. It wasn't clear to me how the IRR register is supposed to behave. Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@balaton Quote: Does this patch help at all with this issue? Sadly, no. Thanks for trying, anyway. It doesn't help that the ISR is cleared by reading. So, trying to monitor that register from the driver when not running the interrupt handler is guaranteed to cause interrupts to be missed. This is going to take even more digging... Hans
|
|
|
|
|
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
