@all Seeing how busy Balaton is with everything else, is there anyone willing on payment basis to expand bboot to be able to make a flat PCI list from firmware's results, so peg2's os4 kernel will be fine with ?
I can't offer thousands, but at least some 300$ can (through in crypto). If anyone willing to do so, i can maybe give a little more , if there will be anyone willing to do so.
@kas1e Wow, that's more than all the donations I've got so far altogether... However thinking about it BBoot may not be the best place to do this because it only has access to OF client interface which is not suitable for editing the device tree beyond changing properties. The easiest and best place to fix this would be in the AmigaOS kernel but only privileged people who have access to the source can do that. Other than that it could be done in a Forth script before starting bboot but doing anything in Forth is a bit challenging. I was thinking about a design but it would be more work than what your offer could cover so maybe wait until it's fixed in kernel or I find it enough of a challenge to do it eventually. It probably can't be done in BBoot because of the above so save that money for something more useful. (Of course everything can be done so if somebody really wanted there could be a way to do it in BBoot but it would be very ugly and increased the size of BBoot too much so I'd keep it separate and let BBoot remain simple.)
@balaton Sure, fixing it in the kernel is correct thing to do technicaly, but this also have several problem: - i offer same in os4beta list to fix it in kernel, but so far no one take the task. - even if it will be fixed in kernel, its uknown if it ever be released, because os4 pretty fragle now, and if there will be any new version released also unknown. In best, it will takes few years more.
With bboot/forth it at least technicaly possible to do something so everyone can use it once it done, even if it may be not the best place.
So according to a recent thread about Radeon RX on X1000 the freezes with interrupts=yes seem to be a known problem thus people getting it with emulation and passed through cards likely got the same issue and not an emulation bug after all. Unless more data comes up I consider this to be fixed in the RX driver and not something we need to do anything about in QEMU then.
@all Just so you know, Hans trying to improve PCI scan code, so currently kernel do see RadeonHD both video and audio parts in the bridge, but still we didn't come to the point when it works, so testing in the process.
So according to a recent thread about Radeon RX on X1000 the freezes with interrupts=yes seem to be a known problem thus people getting it with emulation and passed through cards likely got the same issue and not an emulation bug after all. Unless more data comes up I consider this to be fixed in the RX driver and not something we need to do anything about in QEMU then.
Oh no. This happened to me on my X1000 with Update 2. It has a conflict with my R7 250. Disabling compositing and interrupts works around it but it's slow after that and not efficient.
I wasn't aware of any similar issues in the RX driver so I'll check that thread out.
I would consider this a software issue in the RX driver. Or graphics drivers as a whole. I wonder if the same issue occurs with Update 1 if that can work.
@Hypex Damn, I was in hope there are some information about pegasos2/bridges when find an answer from you there, but it's all unrelated, so please don't derail the thread, it's about real Pegasos2 and Radeon cards in :)
Together with that, BBoot already faster on system loading : because it did use *.zip package with all kickstart modules, which loads to the memory, then unpacked, and loads from. This gives on real Pegaoss2 +10 seconds to load up the whole system. Quite a lot.
Zip? Oh no. That's yukky PC thing. On Amiga we use LhA. Or second to that GZip which has native firmware support.
They did some tests on compressed Kickstarts a few years back. But the result wasn't worth it according to results. Still, I wanted to test it myself once I had my X1Boot loader working, since I can control it. And can use XZ for best compression. Takes ages to compress the best but unpacks real fast!
Also, after reading through the latest posts in thread, it looks like the bridge issue is worked around now. I don't have any real Pegasos hardware so cannot test on the real thing. I can only test under qemu like every one else.
Also, after reading through the latest posts in the thread, it looks like the bridge issue is worked around now.
You seem didn't read it still before answer… Or only first ones…
Bridge's issue didn't work around now. But if you didn't read the whole thread, then you mistakenly think it is.
To summarize, with pegasos2's kernel, we do have 2 issues :
1). BAR addresses are 64bit ones in the drivers, but pegasos2's kernel can handle 32bit ones only. So what BBOOT do there, is spoofs BARs as 32bit ones in the OpenFirmWare device tree. Lately, Hans also add the same to the pegasos2's kernel too. So that one deal with in both BBOOT and kernel. Until new kernel not released, those who want can use BBOOT with this fix.
2). Another issue, is that pegasos2's kernel don't do recursive PCI scanning. The scanning code is “dumb” and were done for fast port of os4 to pegasos2, so nothing like “future-proof” scanning code were created in kernel. This mean that with current kernel we do only see Bridge hardware itself, but no devices attached to it.
Now, Hans trying to add proper PCI scanning to the kernel for pegasos2, and so far, new kernel already see and bridge, and devices in it (radeonHD in our case), but, it seems still messed up on the controllers numbers, so it not works currently and Hans working on fixing this.
In other words, if you will re-read the whole thread, then, you will see that worked around only one issue with BARs, but the second issue, is not worked around not in BBOOT, not in the Kernel currently, and at this point of time we don't have working RadeonHD/RX on peg2 over bridge.
At least now PCI scanning code in the kernel on which Hans work do find card in the bridge, and(!) RadeonHD driver is at least tries to load it's up first time! Check this out:
RadeonHD (5): findRXCard called
RadeonHD (5): Card 0 (1): 0x1002, 0x5960, unknown, other driver, active
RadeonHD (5): Calling original FindCard()
RadeonHD (5): Found a graphics card
RadeonHD (5): Skipping
RadeonHD (5): Card 0 (1): 0x1002, 0x5960, unknown, other driver, active
RadeonHD (5): Calling original FindCard()
RadeonHD (5): Card 1 (0): 0x1002, 0x682B, Radeon HD Verde (Mob.), supported, inactive
RadeonHD (5): Found supported card
...
RadeonHD (5): initRXCard called
RadeonHD (5): Initializing card
...
RadeonHD (2): Obtaining ITimer interface
...
RadeonHD (2): Got ITimer interface
RadeonHD (2): Returning from LibOpen().
....
RadeonHD (0): RadeonHD.chip 5.20 (25.5.2023)
RadeonHD (6): <rxOpen>
....
RadeonHD (4): Have altivec.
RadeonHD (4): CPU cache line length: 32
.....
RadeonHD (4): PCI device is a graphics card.
RadeonHD (2): Identified the chipset as: VERDE
RadeonHD (2): Graphics card name is: Radeon HD Verde (Mob.)
....
And at the end, just that:
RadeonHD (4): Obtaining memory and I/O addresses and sizes
RadeonHD (4): Video RAM at: 0x00000000, size is 268435456 bytes
RadeonHD (0): ERROR: Video RAM base address was NULL
RadeonHD (6): <rxClose>
[HAL_DfltTrapHandler] *** Warning: Fatal exception in task 0x6FFAB240 (exec.task, etask = 0xEFFF4000)
And reboot. So far, it means:
1). pci scan code seems to be at least working and kernel are ok with. 2). RadeonHD driver is loaded up, and find a card (a correct card) in the bridge.
That surely some good progress, and i feel soon AmigaOS logo will show up on RadeonHD/RX card on peg2 first time!
No, it's just new changes in kernel only (Hans also added BAR fixes as well into the peg2's kernel). Anyway, tried with BBOOT as well: no differences. But the fact we do have driver loaded up seeing hardware make me think we very close.
Thanks for your improvements on Peg2 kernel, it won't solve my problem, but maybe it can be used for PC hardware with bridge and RadeonHD/RX under Qemu.
And of course it would be fantastic for real Pegasos 2 hardware if they could use newer Radeon cards including Warp3dNova/OpenGL ES. I wish them good luck.
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
