I checked all interrupts on pegasos2 board OF via serial link.
Interrupts seems to be ok on OF, not at least all addressed to same irq, what was claimed elsewhere. ok, there is Silicon image card on same as ide, but it is not OF problem and it may changed if moved other slot. Anyway my idea to adjust irq's on OF with forth-script is obsolete. There is not much to adjust.
Here is dump cleared a bit from real peg2 board, if you want to check. Actually comments very welcome. I can post whole dump, if needed. OF settings on boot. Forgot to get firewire though.
Two buses
/pci@80000000 /pci@8C000000
isa@C is behind /pci@80000000
First devices, buses, then devices with irq and explanation.
I didnt get clear picture from readme, wich of these bboot fix. If Im read correctly from here and there, BARs and edge/level is fixed. Look behind bridges may or may not work, not possible to test as I dont have pci-pcie riser for example.
Four known broblems. Below more or less correct.
- Kernel doesnt see behind bridges - 64bit BARS are alien to kernel, needs to be trunkated to 32bit - interupts are set to level, should be (falling) edge - All devices mapped to interrupt 0x09 on OS side.
Of these BBoot fixes edge/level interrupts and 64bit BARs, it does not do others as those would need changing the device tree which is not really possible through the OF Client Interface so these would need fixed kernel or patching from OF before BBoot runs.
Quote:
Interrupts to set edge affects stability more than all mapped same irq. PCI standard says level, period. That was obvious on A1 uboot, where set them level made it pretty unstable and freezing was problem.
The difference between edge and level triggering is that edge only signals the CPU once when the interrupt happens (on the rising edge of the interrupt line) and if the OS does not notice the interrupt will be lost which can lead to hangs. This could work if the OS keeps track of interrupts and counts how many of them happened and then handles all but in my understanding AmigaOS does not do that and while it handles an interrupt it can miss another of the same interrupt. With level triggering the interrupt is raised as long as there is a device holding the interrupt high so the OS will get another interrupt after handling one if there's another device still needing attention. This is clearly the behaviour that AmigaOS expects but it forgets to set the interrupt controller accordingly. This wasn't a problem on AmigaOne where the firmware set it and isn't a problem on Pegasos for Linux or MorphOS which set it for themselves. Fixed AmigaOS kernel will likely also do that but for the now available kernels BBoot can change the setting in the interrupt controller for this. This is done here, you can check VT8231 manual for the register meanings. Quote:
If all irqs are mapped to same address, it leads irq thunder. Kernel needs to make more work to take care about situation, at some level at least. No catastrophe, some performance hit probably. Some drivers cant share irq. This leads instability
In theory yes, with level trigger and same IRQ it should work but as you say there may be issues with some drivers sharing interrupts so in practice it may cause problems. I remember Hans mentioning somewhere on this forum that one of his drivers had problems with interrupt sharing which had to be fixed but that is also likely unreleased so this may still be a problem. Work around is to disable interrupts for graphics card in the monitor file tooltype but that may lead to lower performance. Another way to try to fix it is to map graphics card to other interrupt than other devices. Quote:
Suspected by me and probably others rtl8139 and usb2.0 at least.
For the rtl8139 the author of that has debugged it on the German os4welt forum (you can look it up there) and posted updated drivers but it wasn't clear if the problem was related to interrupt sharing, more likely some difference between emulated and real card but it wasn't a bug in emulation as that still confirms to the data sheet of the chip. Quote:
I scanned via serial terminal both buses /pci@80000000 and /pci@8C000000 and _all_ devices behind them inside OF and at first look I got picture that IRQs are just fine there.
What do you consider fine? The mapping is valid but a difference between AmigaOne and Pegasos is that AmigaOne maps devices to 4 interrupts so it's less likely to get shared interrupts while Pegasos maps all devices to IRQ9 so if there's a problem with sharing you'll likely get that. Quote:
If so, irq mapping scheme on OS is not OF fault.
The OS could change interrupt mapping if it prefers not to share interrupts but AmigaOS doesn't do that and relies on the firmware entirely to set up PCI then it just reads the device tree and uses whatever it finds there. Some drivers init some devices but maybe partially and still rely on firmware to init the card. It's not like Linux where the drivers usually set up the card the way they need it and not rely on firmware to leave them in a working state. (AmigaOS comes from an environment where the firmware was also controlled by the OS developers so they could rely on it while Linux comes from PC where it had to handle all different BIOS varieties plus the level of testing and number of developers are also different so it's understandable why Linux does it better.) Quote:
They are addressed to same irq elsewhere.
Where? Quote:
My peg2 2b2 has newest OF delivered with board, newer than publicly available 050404. Could dump current OF out and downgrade it to 050404, but without very good argument I dont do it, because swapping firmwares forth and back can brick whole machine.
I don't think you should downgrade firmware. There's a bit newer firmware version somewhere on MorphOS stroage, link posted somewhere on morph.zone but it does not fix any known problems with QEMU and I always tested with 050404 so that's what I recommended. Quote:
I scanned OF devices because planned to set IRQs inside OF by forth script launched inside bboot.fth but as for my findings it is unneccessary. IRQs are messed elsewhere, it seems.
AmigaOS does not change interrupt configuration. When turning the machine on PCI devices are unconfigured and something needs to do it. The firmware walks the PCI buses and assings BARs and interrupts then puts this info in the device tree where AmigaOS reads from. So on PegasosII it's only the firmware that decides how interrupts are mapped. QEMU without pegasos2.rom emulates the same so you should get consistent results with or without firmware. For testing you could try patching QEMU to assign different interrupts then try if it makes a difference if that's easier than doing it on real machine. You should also consult this documentation on how PCI is handled in OpenFirmware and what needs to be changed. The forth script to map interrupts differently should write the card's config register to set the interrupt then update the device tree to match. Quote:
As a side note, bboot on real peg2 works bit different to amigaboot.of as next.
When OS is installed, first small FFS partition is made. There resides amigaboot.of. Next partition wich usually is SFS02 has OS. After installation both has boot priority 0. Amigaboot.of is happy with that, it boots to OS. Bboot cant understand difference between that and tries to find OS from first partition with highest boot pri (it seems) and boots from first partition. Result is boot picture without booting to OS. Fixed that setting first partition boot pri to -3. After that boots to OS.
Unless amigaboot.of somehow passes the boot partition to the kernel I don't see how can that be different but I did not see amigaboot.of add any additional options so I don't see why you get different results. Are you sure your kickstart zip is the same as the Kickstart dir on your boot partition that amigaboot.of reads?
This is clearly the behaviour that AmigaOS expects but it forgets to set the interrupt controller accordingly.
It's not something that was "forgotten" to implement, it's just one of the major differences between the AmigaOne and Pegasos2 versions of AmigaOS 4.x: Both U-Boot and the AmigaOS 4.x kernels for the AmigaOne were implemented by the same developers, and the AmigaOne versions of AmigaOS just didn't reimplement the same code in the kernel again as it can depend on the AmigaOne U-Boot having set up everything "correctly" already (the way the AmigaOS 4.x kernel needs it). On the Pegasos2 it's different, it's SmartFirmware was implemented by other developers, the AmigaOS developers had no control over it and the AmigaOS kernel would have to fix everything the firmware does "wrong" (in a way the AmigaOS kernel doesn't support). But that never was done, except in some recent, not yet publicly available Pegasos2 kernels maybe.
It's not just the AmigaOne, the firmware of all other systems, except for classic Amigas ("firmware" = AmigaOS 3.1) and the Pegasos2, was implemented by the same developers as well: Sam440, Sam460, X1000, X5000, A1222+. (X1000 CFE, all others U-Boot.) On all systems the AmigaOS 4.x kernel depends on the firmware having set up all hardware the way the AmigaOS 4.x kernel needs it, only on the Pegasos2, and partially on classic Amigas (with ZorroIII->PCI bridges), that's not the case and causes problems, some of which you have fixed in your bboot for the Pegasos2.
Quote:
Unless amigaboot.of somehow passes the boot partition to the kernel I don't see how can that be different but I did not see amigaboot.of add any additional options so I don't see why you get different results.
AmigaOS uses priority sorted lists in a lot of parts, incl. the boot order. If more than one entry have the same priority in such a list the one which was added first is usually used, and if AmigaBoot.(ub|of) and BBoot use different methods for adding entries, insert entries with the same priority before or after an already existing one, that can explain the difference.
I would say that on time there was little possibilities co-operation between Genesi and Hyperion :) I presume that Genesi owns Pegasos platform OF. Allso Amiga port came years later when pegasos2 was discontinued.
@Mlehto My guess (I don't know anything about this, just guessing) is that the PegasosII port was done based on AmigaOne XE and X1000 after realising that PegasosII is quite similar to AmigaOne XE but they forgot the parts done by U-Boot on AmigaOne (and probably CFE on X1000) and then ran out of resources to fix problems found during testing so gave up and released what they had. This was probably not used much until QEMU came along with pegasos2 emulation which helped to find and fix those problems. I've only picked PegasosII to emulate as it had documentation available and can run both AmigaOS and MorphOS so this was fortunate. Unfortunate is that the fixed PegasosII version is still unreleased but hopefully they will release it eventually. I then realised that AmigaOne is very similar to PegasosII so added emulation of that where AmigaOS has less bugs but only helps those who have that version. In QEMU the emulation is almost the same except the north bridge so only bugs there can lead to different results between amigaone and pegasos2 on QEMU otherwise these should run the same. The AmgiaOS side is also almost the same too except amigaboot (not used with BBoot), kernel and some drivers. I know at least two bugs were fixed in pegasos2 kernel, one related to IRQ handling which is also fixed by BBoot and one graphics issue seen with SDL1 apps that only happens with AltiVec so using -cpu g3 with pegasos2 can avoid that. (Using g3 CPU might also be faster for graphics because the AltiVec optimised routines don't run well on QEMU but this wasn't tested too much.) Updated PegasosII kernel might also handle PCI better so it can use newer graphics cards on real machine but on QEMU BBoot handles at least the 64bit BARs which may be enough.
@flash I think you could do that from Forth in the firmware. You just have to write the registers like BBoot does which can be done from Forth (actually anything can be done from Forth, it's a full programming language albeit a bit awkward). (But it's simpler to use BBoot because it also fixes 64bit BARs and boots faster.)
Hi Zoltan, what prevents to fix level triggering interrupts from AmigaOS? It's safe to use BBoot in a multi boot environment? On my Peg2 I have OS4+MOS+Debian and It's not clear for me it BBoot interfere with multi startup script.
I think that you are correct about how Peg2 port had published. It is unfinished as it is now. And has been pretty long. It is frustrating to usew system, wich can freeze without reason. I anyway dropped usb2 card away.
My goal to dig pins/line failed. I made wrong assumption that I allready have them.
Ie VGA ATI Radeon 0x1 (1) includes only PIN, not LINE.
There is no method to get them via of. At least I dont find that method. If I try to give OF command methods, it doesnt return anything.
Any combination these 3c H " config-b@" 3c H " config-w@" 3c H " config-l@" fails and it is meaningless to use monkey typoing more :)
Just should be intresting to know, are they really 0x09 all by OF or is it going south later.
One exception there is. IDE is on PIN A on OF side and PIN is None on Amiga side. Now I dont go back to OF command line any more but if I remember correctly, it is on PCI side, not ISA, as None could be fine to ISA-device I think. Speculation, not important probably.
Other things.
With amigaboot.of it doesnt care about first partition boot priority at all. I put it over system partition and it just happily boot to os.
Bboot reacts correctly, same boot priority on two bootable partitions, it picks first and boots from there.
On clean install first partition includes only amigaboot.of so it has no reason to take care of it, other hand.
As for bboot on real pegasos2. No final conclusion. It seems to make system ”jerky”. Some ”new process” is grimming quite often. Some times drag&drop icons leads no operation, sometimes it works.
It can be that when now things are more correct by bboot, some other parts on OS dont like them. TImings, drivers? Dont know.
I dont have idea how to test that any deeply. If you have ideas, I can test...
There is anyway very intresting things under qemu and it will get better and easier over time. Im sure about that. Thank you of bring it to Amiga scene :)
Should not interfere as linux and MOS writes VIA irq registers correctly them self i presume (or at least hope :D…). So whatever bboot does for these are overwritten by OS later on boot.
Pretty easy to test.
Correct kicklayout names/ kicklayout filenames so that names are case sensivitelly same on kiklayout file and filenames. I found only smartfilesystem incorrect.
Check that first partition boot pri is under system partition(s).
ZIP Kickstart . as Kickstart.zip so that Kickstart drawer is incuded.
Drop Kickstartr.zip, bboot and bboot.fth to first partition.
Rename at least temporarily amigaboot.of to amiga.of for example. Then you get easily to OF prompt.
Boot hd:0 bboot.fth.
Writed down here because it was little hassle to put all info together wich where how.
Ie VGA ATI Radeon 0x1 (1) includes only PIN, not LINE.
Pin and line are different. I think Pin shows which of the 4 PCI interrupt lines are used from ABCD (AGP port only have A and B connected, the PegasosII schematics are public and linked from my page in my signature, go to development on top left then pegasos2 emulation). These go into the VIA chip where they can be routed to ISA interrupts by two registers. On PegasosII the firmware sets these to route all 4 PCI interrupts to ISA IRQ 9 (as well as other internal functions of the VIA chip such as USB and others which are routable by their own registers). This is what is then put in the Line PCI config register which shows which ISA interrupt it uses. Or something like that, it's documented in the VT8231 data sheet and some PCI documentation which I recommend to read.
Quote:
There is no method to get them via of. At least I dont find that method. If I try to give OF command methods, it doesnt return anything.
Any combination these 3c H " config-b@" 3c H " config-w@" 3c H " config-l@" fails and it is meaningless to use monkey typoing more :)
Yeah, find some documentation like the Open Firmware PCI binding that I've referred to as Forth isn't something that you can figure out without docs. I think you have to open the PCI device before you can do config-b@ and config-w! otherwise it does not know which device to address but it should work. It may even need something like 'open to my-self' but find docs. Some old Sun OpenFirmware docs may be clearer, there was another thread somewhere on this forum with some links.
Quote:
Just should be intresting to know, are they really 0x09 all by OF or is it going south later.
BBoot can help you with that too. When PCI config is enabled (the default unless you changed in /options/bboot variable) then you should see some debug output for PCI devices. Look in the comment in BBoot sources for docs on what they mean but these list both what's in the device tree and what's in the config registers of the device.
Quote:
One exception there is. IDE is on PIN A on OF side and PIN is None on Amiga side. Now I dont go back to OF command line any more but if I remember correctly, it is on PCI side, not ISA, as None could be fine to ISA-device I think. Speculation, not important probably.
IDE has a legacy mode and even in PCI mode its IRQ is routable separately and stays on ISA interrupts normally. What AmigaOS lists as Pin/line may not be the same as OpenFirmware says because I think AmigaOS uses virtual interrupt numbers that are real IRQ+16 or something like that.
Quote:
With amigaboot.of it doesnt care about first partition boot priority at all. I put it over system partition and it just happily boot to os.
Bboot reacts correctly, same boot priority on two bootable partitions, it picks first and boots from there.
But boot partition is picked by AmigaOS kernel and not amigaboot or BBoot. The only list created by BBoot is the list of kickstart modules and that should be the same as with amigaboot as it depends on the Kicklayout so unless there's something to sort in there I don't see what BBoot could do differently or what amigaboot can do to change boot partition order. You may achieve the same by changing order in Kicklayout then.
Quote:
On clean install first partition includes only amigaboot.of so it has no reason to take care of it, other hand.
I think the reason for having a boot partition is because the firmware can only read FFS partitions and Sys may be SFS so you need the files that the firmware has to read (i.e. amigaboot.of) on FFS then amigaboot.of can read SFS so it can load modules from Sys partition.
Quote:
As for bboot on real pegasos2. No final conclusion. It seems to make system ”jerky”. Some ”new process” is grimming quite often. Some times drag&drop icons leads no operation, sometimes it works.
It can be that when now things are more correct by bboot, some other parts on OS dont like them. TImings, drivers? Dont know.
Hard to tell. Is this reproducibly because of BBoot or maybe it's just generally unstable for some other reason.
Quote:
I dont have idea how to test that any deeply. If you have ideas, I can test...
You could comment out the lines from BBoot that sets the IRQ trigger registers and see if that changes anything. For this you would need to recompile BBoot but if you have Linux and it has a PPC cross compiler that should be easy. Otherwise if you don't want to recompile you could try finding that part and binary patch the device ID it checks in bboot so it skips it. In BBoot 0.8 I think it's this part:
as that's the only part where 0x82311106 appears so maybe just change the 82 in the first line to 88 or something so it won't find the device. I hope you can find the file offset yourself and can use a hex editor. I don't want to make this configurable or do a test version just for this.
Quote:
There is anyway very intresting things under qemu and it will get better and easier over time. Im sure about that. Thank you of bring it to Amiga scene :)
It will get better if some people work on it. As you said time is the limiting factor so if I'm the only one who does it it will take a long time. But QEMU is open source and contributions are welcome. If somebody is interested they could look at for example optimising dcbz or the AltiVec instruction that runs slower in the memory copy routine used for Read/WritePixels or there are a lot of other things that could be done too such as recording support for via-ac97 or whatever else somebody is interested in and can do.
Should be intresting to set IRQs allso via bboot :D.
Can't do that because BBoot cannot change the device tree and it has to match because the device tree is what the OS reads to know which interrupt to use. You can fix up both device config regs and device tree in the firmware from Forth but BBoot uses the OpenFirmware Client Interface which only has functions to read the device tree but not writing it. So either change it in firmware or teach OS to change it itself (but you can't do that because AmigaOS is closed source so you can't change it).
Quote:
My bet is that one cant forth them as there is no way to see them either.
Look for the thread where MartinW patched the 64 bit BARs from Forth, that has also links to docs on how to do it. It may be in the long thread about QEMU or in some other thread about pegasos2 and newer graphics cards, I don't remember but I do remember this was discussed before and it's possible to do this from Forth.
Hi Zoltan, what prevents to fix level triggering interrupts from AmigaOS?
Mainly that you can't modify the kernel because it's closed source. You can try to patch it from an executable run from startup-sequence if it allows you to poke PCI device registers from outside the kernel (as AmigaOS does not have memory protection it may but it does use the MMU to protect some areas).
Quote:
It's safe to use BBoot in a multi boot environment? On my Peg2 I have OS4+MOS+Debian and It's not clear for me it BBoot interfere with multi startup script.
You just replace the AmigaOS boot entry to use BBoot so it should not affect any other entries. BBoot does not provide a menu or replace anything else than amigaboot.of so it should not interfere with anything else. All you need is to put bboot, bboot.fth and Kickstart.zip where you have amigaboot.of then change the boot entry to load bboot.fth instead of amigaboot.of. I tried to explain it in the BBoot README so I suggest to read that.
I think AmigaOS uses virtual interrupt numbers that are real IRQ+16 or something like that.
Yes, because the first 16 (0-15) are the legacy interrupts of classic Amigas. PCI interrupt numbers in AmigaOS usually start at 16 (= PCI interrupt number 0).
Quote:
You can try to patch it from an executable run from startup-sequence if it allows you to poke PCI device registers from outside the kernel (as AmigaOS does not have memory protection it may but it does use the MMU to protect some areas).
99% of AmigaOS is running in user mode, but there is nothing in it which prevents you to run your own code in supervisor mode either if required, like direct MMU changes, access to some SPRs, or maybe MMU restricted hardware accesses. Check for example https://wiki.amigaos.net/amiga/autodocs/exec.doc.txt
APTR oldSysStack = IExec->SuperState();
// your code running in supervisor mode
IExec->UserState(oldSysStack);
News feed
OS4 Feedback forum
OS4Depot Feedback 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
