- Radeon HD 77xx-79xx series graphics card (excluding the Radeon HD 7790)
- Radeon R7 240D/240/250/250E/250X/265
- Radeon R9 270/270X/280/280X
From aeon/amigakit's wiki:
Support for "R520" (X1300-X1950 series)
Support for "R700" (HD4000 series)
Support for "Evergreen" (HD5000 series)
Support for "Northern Islands" (HD6000 series)
Support for "Southern Islands" (selected HD7000, R7, R9 series)
@all We a bit stuck with, maybe anyone have a clue where to look next.
Our problems currently are: - Reading the graphics card's BAR registers always returns 0, even after we've written new value to them
- Possibly related, reading from the card's secondary function (i.e,. the audio sub-device) configuration register returns 0xFFFFFFFFF, including for its vendor/device ID.
To clarify, the Pegasos II's firmware clearly managed to read the configuration registers properly, because the card appears in the PCI device tree. However, attempting to access the card's PCI configuration registers fails when the OS tries to do it (using OpenFirmware's PCI configuration access API). Clearly something went wrong between the firmware's PCI device scan, and the OS starting up...
@Hans Is this with QEMU or on real machine with a bridge? If on QEMU is it using pegasos2.rom or with bboot? Can you boot Linux and check what that sees from the device? The lspci command has some options to dump the config regs so you can check with that what it sees. If this is through a bridge you may need to do something differently to access the other bus behind the bridge otherwise you may try to read device on the host bus not the bridge's bus so you'd get non-existing device that would return 0xff when you read it (which may be interpreted as 0 for BARs, I'm not sure). Maybe check some docs on how to handle PCI buses behind a bridge and check if the AmigaOS kernel does that correctly.
Sorry, this is with a real machine. After the success with getting a RadeonRX working with QEMU + passthrough, kas1e wanted to see if we could get it working on a real Pegasos II.
We've kind of hit a brick wall. The OS & driver need to be able to access the PCI configuration registers, but they're not responding...
Quote:
If this is through a bridge you may need to do something differently to access the other bus behind the bridge otherwise you may try to read device on the host bus not the bridge's bus so you'd get non-existing device that would return 0xff when you read it (which may be interpreted as 0 for BARs, I'm not sure). Maybe check some docs on how to handle PCI buses behind a bridge and check if the AmigaOS kernel does that correctly.
The OS is using OpenFirmware's own callback function to access configuration registers. You tell it which domain, bus, & device you want to access, and it does it for you. That function is working with all other devices, but not with the graphics card behind the PCI to PCIe bridge. It reads zeros from the GPU's configuration registers, and 0xFFFFFFFF from the card's audio sub-device.
@everyone Can anybody help us with an idea of how to access properly the PCI configuration registers ? Or should be something done to make them accessible at all ? That what currently block Hans from progress in making working RadeonHD/RX cards via bridge on real pegasos2.
If the OS is using OpenFirmware's callback function to access those registers, maybe this one isn't working properly, and we need to cookie up our one ? But then how to access this properly ?
@All Does anyone know what the best PPC Linux which still support pegasos2 up-to-date , so we can see if bridge and some older HD cards supported by Linux are works on at all (so we can see what they do). Is Debian 8.2 is the last/best one to play with ?
At least on morphos, while it being said it should work, i tried some old X1950, and it didn't work, but produce some mess on screen instead. So we want to check how Linux handle it all, so maybe it will help us in right direction.
Can anybody help us with an idea of how to access properly the PCI configuration registers ? Or should be something done to make them accessible at all ? That what currently block Hans from progress in making working RadeonHD/RX cards via bridge on real pegasos2.
Unfortunatelly manual of Pegasos Smart Firmware is very short. Only usable information I found is: "SmartFirmware is an implementation of the OpenFirmware IEEE standard 1275-1994 plus errata changes" And here is OpenFirmware Manual. Maybe we can use some config-x writes...
kas1e wrote:@All Does anyone know what the best PPC Linux which still support pegasos2 up-to-date , so we can see if bridge and some older HD cards supported by Linux are works on at all (so we can see what they do). Is Debian 8.2 is the last/best one to play with?
Yes, the last distro supporting Pegasos 2 is Debian 8. Or Ubuntu 16.04
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
@Sailor Are you aware if OF can boot from ext2fs ? Seems that not ? At least, by simple "ls hd:5" in OF it show nothing and when i tried to "boot hd:5 boot/vmlinuz root=/dev/sda6" as noted at the end of installation process i have "no such file/abort", while if i boot into morphos and mount this partition, i can see there are directory boot and vmlinuz in.
I then tried to copy manually under morphos whole "boot" directory from ext2fs to my "BOOT" (ffs) partition, and then: "boot hd:0 boot/vmlinuz root=/dev/sda6" and while kernel loads, i do have on serial words:
Quote:
Linux/PPC 3.16.0
arch: exit
Have fun!
It then simple stuck forever on the "returning from prom_init" when about to change screenmode and init video card or something (i am on radeon9250 for now).
So i think something still wrong with my installation, but i were under impression that ext2fs should be readable under OF ? Or maybe for OF issue is that i made my ext2df of 30 GB of size and it fails to init and should be small one ?
At moment didn't find any normal doc in google where will be explained how to install debian on peg2 together with os4/morphos on it , where to put kernels, and why installation procedure didn't handle all this .. Maybe you aware of some tips and tricks about ?
Probably the way i copy manually "boot" directory from ext2ds to my BOOT(ffs) partition is the way to go, but maybe some bits need to be changed somewhere in fstab or so to make it all works after manual changes.. Installation process is surely ends succefully (as i have all those words "done, you can remove CD and reboot, etc). Just they by some reassons says that i should boot vmlinuz from hd:5 , but this one surely didn't visibly from OF.
I have triboot peg2 os4/mos/debian 8 I remember linux and mos kernel for bootstrap are suited on os4 partition. Every time a new mos version came out I have to coy new kernel on os4 boot partition. The same should be done for linux in case of kernel updates.
@flash What you call “os4 partition”, is not os4 partition, but an FFS partition which OF can read and boot from : this is casual FFS partition and used for both OS4 and MOS bootimages, and can be used for Linux kernels too of course, but, the problem which I ask Sailor for is different:
I read that OF can read/boot from ext2fs: but for me, it is not. I can't list files and boot from ext2fs partition of 30 GB size. Maybe it should be a smaller one to make it be accessible from OF, dunno. At least Linux installer at the end of the installation says that I should be able to boot from this partition, but OF can't see it (while partition surely working and created). I tried simple move that whole boot directory from ext2fs to this my "boot-ffs" partition which OF can read and boot from, but then, as i wrote in previous post it just stuck on some point.
@smarkusg Nope, still the same with adding "video=uvesafb:1920x1080-32,console=tty0".
My question still valid : why installer keep saying that i can boot from hd:5, which is my ext2fs partition, but OF can't see it at all (so how it can boot then).
Your hd:0 is ext2 right ? So you can do "ls hd:0" in OF ? If so, how much of size your ext2 boot parition are ?
My output (when i manually copy boot directory from my /dev/sda6 to my boot-ffs parition so OF can boot from), and with out added options are :
Quote:
zImage starting: loaded at 0x00400000 (sp: 0x00762fa0) Allocating 0x8a1ec0 bytes for kernel ... OF version = 'Pegasos2,1.2' Trying to claim from 0x400000 to 0x76edfc (0x36edfc) got 400000 gunzipping (0x01800000 <- 0x0040c000:0x00761c62)...done 0x743000 bytes
Linux/PowerPC load: root=/dev/sda6 video=uvesafb:640x480-32, console=tt Finalizing device tree... using OF tree (promptr=01003bc4) OF stdout device is: /failsafe Preparing to boot Linux version 3.16.0-6-powerpc (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.56-1+deb8u1 (2018-05-08) Detected machine type: 00000500 command line: root=/dev/sda6 video=uvesafb:640x480-32, console=tt memory layout at init: memory_limit : 00000000 (16 MB aligned) alloc_bottom : 020a6000 alloc_top : 30000000 alloc_top_hi : 40000000 rmo_top : 30000000 ram_top : 40000000 instantiating rtas at 0x0fbfd000... done Fixing up missing ISA range on Pegasos... Fixing up IDE interrupt on Pegasos... Fixing up IDE class-code on Pegasos... copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x020a7000 -> 0x020a77c3 Device tree struct 0x020a8000 -> 0x020cb000 Calling quiesce... returning from prom_init
Linux/PPC 3.16.0
arch: exit
Have fun!
And the same nothing. And i didn't see anything about initrd initialization there.. While it surely placed in the same boot-ffs parition where linux kernel are .. so seems i need to change manually something else so initrd will be keept as well.
But the kernel loads for you, so you set it right. root is missing, which is the partition where you have the system. - Maybe you have the wrong partition, not the right one.
In the log you have "console=tt" I pasted it wrong or did you pass it like that?
edit:
unless initrd can't load .... then on kernel and initrd you have on FFS partition yes ? my boot/ext2 partition has 100MB
what possibility you have make a small partition ext2 and copy the kernel and initrd there and see if it boots up
Yes it seems that initrd can't load by some reasons, because and in your log, and in the log when i boot from CD, initrd surely attached and loads up.
I tried to create a small 100mb EXT2 partition (via CD's installer), and i still can't "list dh:8" it from OF. If you go to OF, can you do "list" on your small ext2 100mb partition to see content in ?
SmartFirmware:
cpu0: PowerPC,74x7 CPUClock 1533 Mhz BUSClock 133 Mhz (Version 0x8002,0x0102)
no/bad nvramrc - performing default startup script
channel 0 unit 0 : ata | QEMU HARDDISK | 2.5+
ATA device not present or not responding
channel 1 unit 0 : atapi | QEMU DVD-ROM | 2.5+
ATA device not present or not responding
Welcome to SmartFirmware(tm) for bplan Pegasos2 version 1.2 (20040810112413)
SmartFirmware(tm) Copyright 1996-2001 by CodeGen, Inc.
All Rights Reserved.
Pegasos BIOS Extensions Copyright 2001-2004 by bplan GmbH.
All Rights Reserved.
entering main read/eval loop...
ok ls hd:0
.
..
lost+found
config-3.16.0-6-powerpc
vmlinux-3.16.0-6-powerpc
initrd.img
vmlinuz
cuImage.amigaone.img-3.16.0-4-book3s-amigaone-smp+
System.map-3.16.0-4-book3s-amigaone-smp+
build_uboot_image.sh
vmlinuz.old
cuImage.amigaone.elf-3.16.0-4-book3s-amigaone-smp+
boot.img.amigaone-3.16.0-4-book3s-amigaone-smp+
config-3.16.0-4-book3s-amigaone-smp+
vmlinuz-3.16.0-6-powerpc
initrd.img-3.16.0-4-book3s-amigaone-smp+
vmlinux
cuImage.amigaone-3.16.0-4-book3s-amigaone-smp+
initrd.img-3.16.0-6-powerpc
vmlinux-3.16.0-4-book3s-amigaone-smp+
System.map-3.16.0-6-powerpc
vmlinuz-3.16.0-4-book3s-amigaone-smp+
ok
Maybe if you have some free disk install on it from scratch. As you wrote you only need it for the test so it's a shame if you make yourself something with the actial partitions ma Pegasos I don't remember if Pegasos required a boot partition as the first one, but I guess it shouldn't matter to list it with "ls"
@smarkusg Yeah, you definitely can list content in ! But, hd:0 is your first partition, so maybe that matter ? (my one is the 6,7 and 8st ones for linux, not the first one). And what is interesting is that when i install linux, it says before installing starts "your boot partition should be the first one in order to boot, want to make it as first one, or keep it as it ?" . So i keep it as it, as my first one is my boot FFS partition, which had os4 and morphos boot imgs, and which i can't delete.
Maybe OF of pegasos2 can access to ext2fs only when it in hd:0 ? But then wtf :)
And your boot partition is surely EXT2 ? Can you plz also do that:
cd ide ls
?
ps, see how my list of partitions looks like (only different that on video i tried now for #6 is ext3fs for root partition, before all tests were with ext2):
And you can see on 0:14 that error about "your boot is not located on the first partition of the disk", but then, my boot is the first one, I use it for os4 and mos. And why i can't list content of ext2 partitions from OF and you can is quite strange.
Edited by kas1e on 2024/4/20 11:54:49 Edited by kas1e on 2024/4/20 12:14:19 Edited by kas1e on 2024/4/20 12:15:57
@kas1e I think PegasosII SmartFirmware may have a limit on how many blocks it can read so the boot partition should be at the beginning of the disk (maybe below some cylinder/block limit). Maybe it does not need to be hd:0 but if it's at the end of a large disk that's outside the limit. Try to put it fully within the first 2GB or so. It probably tries hd:0 by default that's why it says it should be first otherwise you'd need to type boot hd:1 ... or set some env var. Also pegasos2 kernels contain an initrd so you may either need such kernel or some boot loader to load both kernel and initrd. So maybe you need to boot cuimage or boot img which have embedded initrd instead of vmlinuz that may be just the kernel. I have some docs on what Linux distros I could boot on emulated machines here: https://www.qemu.org/docs/master/system/ppc/amigang.html I think for pegasos2 Debian 8.11 was the latest that supported it but maybe there some unofficial later versions.
Edited by balaton on 2024/4/20 13:12:48 Edited by balaton on 2024/4/20 13:18:54