@smarkusg
So to make it short, bboot is not need it with original (no our new) firmware and all works without with update3's kernel, right ? You can boots from RadeonHD with no probs ?

(i just need that to understand if we can get rid of bboot now and it's fixes for tests).

@sailor
Quote:

You have time for : i ordered Promise TX4 pci2sata card, as well as 3112 and 31114, as well as few Geforce modesl (one agp and one PCIe), so want to make it all works too and to have more real live test cases.

@smarkusg
Quote:

The switch to Balaton's video driver happens only if you use rv100, yes, but that probably out of firmware question and it all the same with original firmware too (at least as far as i can tell).

@smarkusg

Quote:

But that probably expected, because sm501/voodoo3 is not real cards on your setup, so how can you passthrough with them ? That the same with original and with new firmware, right ? But yes, i will check with putting any non ATI/AMD card to, just to see if there correct fallback, or if firmware can handle anything else too.

I may try to find some PCI/e and AGP versions of some Nvidia/Voodoo cards, those probably will be good to test.

Quote:

I use RadeonRX driver 2.23 on real peg2 which should fit someday in enhancer (if it will ever happens), and i also use beta kernel with peg2 fixes for test, so can use it without BBOOT, but that shouldn't matter, because if the same setup works for you with original firmware on qemu, and simple changing on new firmware cause it to not work, then it mean something changes, and that not related to your components.

Quote:

Nope, it didn't change anything for cards, just simple initialization behind bridge and POST running.

Quote:

Not for now, but will do. What version of RadeonHD you use ?


Quote:


So, RadeonRX cars is booting with both original firmware and new one ? Or only with new one ? Can you try plz to boot RadeonRX without BBOOT on this Update3 (and be sure, that Kickstart.zip contain kernel 54.57 in)

Quote:

But you tested it now with UP3 update, right ? It works both with original and our firmware ?


Anyway, what i want to say mainly now is that if you have update3 installed, and you surely have kernel 54.57 and BBOOT "only" fix 64/32 address issues, you can try to not use BBOOT and it should works without. Try it plz if you can.

Thanks for tests !


@Mlehto

Quote:

What i found is : The card which i run POST init on the firmware, will be the one taken as the primary by AmigaOS4.

So, i implemented it like this (at least for now): added "primary-vga" environment, which default value is "vga0", meaning the first video card found during PCI scan. The first one usually a PCI one (not AGP one) in the pci probing. So if you have 2 video cards in peg2 , then "vga0" mean pci one, and "vga1" an agp one. If card running alone, then "vga0" will handle any card it find be it agp or pci/pcie.

The good thing is that we don't need removing cards or disconnecting cables, I tested right now with both video cards connected to monitor at the same time : RadeonRX connected via HDMI cable, and Radeon9250 connected via VGA cable to same monitor at the same time, and simple set to "vga0", make firmware outputs to RadeonRX and amigaos4 boots to RadeonRX as the main one, and simple set to "vga1" make Radeon9250 in AGP output on firmware, and amigaos4 take this one as the primary to boot from.

@smarkusg
Quote:

That good!

Quote:

So, that without bboot or with bboot ?
And with what kernel version ?

Exactly the same config with all same settings, with same bboot usage/or_not_usage, but with original firmware boots up fine ?


This "ERROR: Could not get the video RAM resource range" looks like you trying without bboot and with some older kernel than the one from update3 ?

@All (smarkusg mostly)
I found now, that update3 which we release not long ago, have kernel 54.57 for pegasos2. And in this version there were fix by Hans:

- Fixed 64-bit PCI BAR handling for Pegasos II, so that 64-bit PCI
devices can be used on the Pegasos II (provided they're within
32-bit address space)

So, if bboot only fix that, maybe you can test in your spare time without bboot with update3's 54.57 kernel your passthrough setup to RadeonHD, so we will know if there needs to fix it in firmware at all anymore or that in the past ? Just the less hacks in new firmware the better, of course.

From my side i at least can say that i can boot without bboot with 54.71 version, which have not only this 64/32bit workaround, but also few other ones, but will be good to know if 54.57 at least fix "just" what bboot fix.

@Mlehto
Quote:

Yes, "setenv primary-vga" sounds good for me too. Just how to set argument to.. Probably need few arguments, like for example "auto" - to set first probed (probably always will be one in agp slot). Or maybe, "agp" / "pci" , but that too dumb imho.. Better way probably some cryptic thing like:



So we set pci-bus number, device number and function (so to point to exact display, and not to audio or something). But that mean you should know on what bus, etc,etc.

Maybe doing like that: if more than 1 card found, and then one of them are "agp" , then agp one is default. In other cases, primary-vga can be set to default "agp" and to "pci" arg ?



Quote:
I check lspci -vvv output from Linux on pegasos2 , and it also show that everything on the irq9, but only legacy ide on irq 14, see:



It possible to change it in firmware: at least in datasheets to marvel and via there is no limitation in this regards, but then , probably all the OSes we have will fail after and will need changes in kernels.

Why it was chosen to have all on irq9 : dunno for now..

@smarkusg
Wow, that cool :)

I noticed that your boot time a bit slower than my: i have just 10 seconds once i hit "enter" on my qemu line, till the working console (that via ati-vga,model=rv100,romfile=share\vgabios-ati.bin,guest_hwcursor=on) , while on your setup it takes 40 (!) seconds.

Then at first i realize that even simple bootstrap init take 10 seconds on your setup (which point out that you use some slow hardware for emulation, at least CPU wise) and then, at second, i realize that you use 2 video devices at the same time : rage128 and rv100, so it mean double x86 POST emualtion too. Through on faster hardware it shouldn't be problem, will be not 10, but 12 seconds, but still.

To have it all working with balaton's ati-driver, and without needs to switch and without needs to have 2 video cards you can just do:




Also, will be interesting to know how RadeonHD passthrough will works, basically all the passthrough tests are interesting, as they kind of "almost real hardware just not the motherboard/cpu itself". But i assume right now it will works only with bboot, because i didn't do for now those 64/32bar fixes in firmware which bboot did (but will do, of course).

Also, peg2 kernel do "flat pci scanning", and while it ok on QEMU (as it put all as flat list) , and passthrough works, on real pegasos2 kernel it will not find card behind the bridge with current firmware state, and while Hans do fixes in the kernel about, it's now totally unknown if new kernel will be ever released => which in turn mean, i need to made in firmware a specific workaround which if detect os4 booting, will made a flat list of pci device too. Or something of that sort .. In other words, it probably possible to cheat kernel from firmware now and no needs to wait for new kernel !


And btw, after you note NVME, maybe it worth also add some simple driver for some popular NVME cards, if there any PCI to NVME, so to be able to boot from it too.. But there also PCIe NVME cards of course, so they can be used via bridges too.. Just need to choose ones for which we may have drivers in os4 already.

@smarkusg
Check pm plz, report all findings there if you have time for

@All

Tested in bridge those cards (and they all works and made an output on monitor with new firmware):

- Radeon 9250 (AGP)
- Radeon X1950 XT (PCIE)
- Radeon RX 460 Polaris (PCIE)
- Radeon R9 M360 VERDE (PCIE)

Also, added AMD/ATI ids (~100kb table) so banner at top will show correctly the card name. It may sounds too much, but that really the only correct way to output proper names instead of device id only : there is no standard for real where all the info placed in all (old and new) amd roms. ATIBIOS one thing, older bioses another, VBE oem/production info is not enough, etc, etc. Of course added fallback, that if there is not proper ids found , it print device id and "OEM" production name, but that not as good as full id.

While firmware by itself already 900kb of size, the good thing that it gziped into the ROM and unpacked by bootstrap on run, so , it still fits to the 524kb of size and some place still left, which probably worth to use for another siliconimage or promise pci2sata driver and for remain fixes and flash read/write support (which will be the last thing to add before i will crash and burn my peg2:) ).

So plz, anyone who have find back in days in original firmware some quirks, or things which need to improve/fix, plz, write about. Thanks !

@All

And now RadeonHD/RX works over bridge in the pegasos2 firmware too !





Now, question of logical decision about : If i have 2 video cards at the same time in pegasos2 (radeon9250 in AGP, and RadeonHD in PCI), which one should be taken as the main output by default ?

And how to do better this "selection" without needs to open a case, and remove one of the cards ? Environment variable like "setenv primary-vga" or something ? Because autodetection to "which card cable is connected to monitor" surely too much hassle with writing full blown driver which make no sense for firmware at least.

I can of course do something like "the first one detects, the one which will be used in output", but then, you loose ability to switch output between. Any suggestions ?

Thanks!

@LiveForIt
No, i say exactly what i say.. In short: one of the SSDs can't be detected by the amigaos4's sii3512ide.device in the IRQ/DMA path, but only in PIO, while other SSDs detects in the IRC/DMA path fine.

So question is if anyone else noticed any day on any amiga hardware that sii3512ide.device may not detect some of the disks by any of the reassons.

@joerg
By "3rd" disk i mean that one which originally connected to pegasos2's IDE port through IDE2SATA adapter and it works fine with peg2ide.device.

But, when i connect this "3rd" ssd, to the SIi card (not as 3rd one of course, but instead of any other 2 disk which were connected before), then it fail to detects by sii3512ide.device.

I dig in a bit more into this, and find out that it's exactly IRQ/DMA path which made this disk be not detected by sii3512ide.device. If i patch the device to not use irq/dma, that it detects and kind of works (but slow, of course).

But then, wtf ? Why it can act like this ? Why it didn't detect device by IRQ/DMA path, while when it on IDE port (via IDE2SATA adapter), then peg2ide.device detect it pretty fine, with all DMA/IRQ enabled and co.

But 2 other SSDs, detects by IRQ/DMA path pretty good and no problems. Question is : Wtf ? Those just 3 SSD of same kind. More of it, why pio may works, while irq/dma not ? Can i do anything about from the firmware side ? Maybe it should be "set" to some state or dunno, maybe there some quirks i know nothing about which should be used ? Or sii3512ide.device have some hacks in ?

I do not know, maybe firmware of this card need to be updated ?

@All

Find out today, that my sii3512ide while can detect on os4 fine 2 disks, can't detect 3rd disk (the one i use usually in ide2sata port of pegasos2 to boot from), with output like:



I.e. peg2ide.device can detect that drive fine (i boot from it all in all). Then, my experimental driver for firmware also can detect the disk fine on very the same sii3512 card, but os4's sii3512ide device acts like that.

Question is : did anyone noticed on any amiga hardware that some ssd/hdds finds fine, while others are not in those Sii pci-sata cards ?

Thanks!

@flash
Quote:

Everything hell until you didn't dig in :)


Quote:

Nope, it just make no sense to update repo only to show to others few ppls what were changed and where. Working locally is much faster. But once i will have something ready, i will put it to repo of course, so it will be for everyone.


Quote:

Why not, but i do all on cross compiler: fast, easy, no specific bugs to os4 version of make/cmake/diffs/rg/grep/bash/pythong/etc.

Quote:

That the harder question, because i do test it on my own peg2 G4, so it should works of course on everything else, especially in sense that i currently only replace SmartFirmware, while bootsrap is original bPlan's one.

That need to be safe-tested after something ready.


@All
Borrowed from UBOOT driver for sii3512, adapted to smartfirmware, and now i can boot, see the drives attached to it and BOOT FROM ! YEAHOO !!

Last hardcore things is to made bridge working now, so i will see firmware on radeonhd/rx, and then it kind of it, cleanup, etc,etc.

Just for some nerd fancy checking if anyone in interest, that the one of the working session i have now with attaching to the PCI USB Nec based card usb CD-ROM, a USB Stick and a Mouse. Also, Si512 with attached 1 SSD, then one stick attached to the VIA's port (so uhci) , and one hdd attached to ide2sata atapter and a keyboard connected to the Via's usb port too. And all whole mess works and output from firmware initialisation are:



You also can see there that PCI USB Nec card have Ehci + Ohci support, so, firmware checks if there Ehci devices attached, if yes, enumerate, if not , checked by Ohci and only then give up.

"show-devs" is even more fancy

@smarkusg
Answered :)

@all
Was another 2 hardworking days : imroved UHCI, so USB booting works from pure VIA's ports of pegasos2 + does not matter on what port you attach keyboard/mouse it works in any now.

Then played with 2 new PCI USB cards : one is NEC based, another one is VIA based. The NEC one have ability to work as EHCI, and as companion OHCI, and VIA one same can work as EHCI and as companion an UHCI.

So, starting from NEC one, and default SmartFirmware's OHCI was very dumb, and detect nothing properly, so starting writing new one, and meet with all sort of possible usb issues about everything, until realized that i better take the proved to works one from latest UBoot and integrate it to smartfirmware. Then while OHCI start to works, i can detect sticks attached to it , but it still acts a bit strage, need to do some more debugging.

Also while was at it , borrowed from Uboot more harder EHCI driver, so now SmartFirmware have all 3 : OHCI, UHCI and EHCI. While really necessary is the UHCI one (as pegasos's VIA's usb is UHCI) , still have OHCI and EHCI can find it use by some one.

Next stage : PCI SATA. Once i will be able to boot from, it will means no more needs of anything connected to IDE ports anymore, even through IDE2SATA adapters..

@All
Good progress: USB issues gone , it was one of the VT config registers.

Also added UDMA for ATA (be it pure IDE , or sata disk via IDE2SATA adapter) together with LBA48 (originaly it was just 28) + batching for PIO if UDMA not supported on some drive, which in result mean that: originally my kickstart modules loads up for 21s (i just have debug version of modules, both radeonrx/hd ones, kernel , etc). Now, if UDMA driver detected : 3s (!). IF UDMA not detected, fallback to PIO, but improved one, which instead of 21s gives 8s, which is good too.

Also added SFS2 support of all flavors : original firmware simple list only morphos SFS version, in my one now any SFS/SFS2 can be listed/booted from. Together with that added read/listing/booting from FAT16/32 with VFAT, NTFS (!) , Linuxes (LNX, EXT2/3) and improve FFS to have support of latest ones.

Some bits were fixed in original smartfirmware like "ls" on relative block-device (before you can't "ls disk@0,0" when you in /pci@80000000/ide@c,1 for example). And fixed when you CD to any device , and do "cd non_present_anything" instead of fallback to the root it keep stays on same place.


Everything done of course on REAL pegasos2, where i upload just SmartFirmware over IKARUS (so original BPlan's bootstrap still in use).


Now, what i else want to do is:

- USB booting from massstorage
- CD-USB booting
- Booting from SATA PCI directly
- Booting from USB stick from PCI USB card directly.
- Make the GFX card in PCI bridges be visibly in firmware and usable.
- Improve a bit network support (to have sane ping return, not like now, and to not died on network after one network operation as it was with original)

Once that done, clean the debug, and first release with proper scripts so one can use it on original peg2 via uploading only SF part via Ikarus, or one can use full rom which will be done by script which will take original pegasos2.rom, extract bootstrap from and build a ready rom for you, so to play with QEMU.

Then, it will time to somehow think how better to prepare reflashing work (at first with original bootstrap) , so to have basics works. Because flash on pegasos is TSOP32, which you can't easyly solder-resolder many times, so this need to be thinks of how to do it all correctly ..

But if anyone want to play with it right now , i can put it now too, just ask.

fixed.

@Balaton
Deal with this stick, was some small issue about wrong order initialisation. As for releasing anything: sure, but it firstly should work at all :) Currently i only deal with smartfirmware itself, to be able to boots correctly with original bootstrap , and it still acts in one or another way which need to deal with. Once it will works, i can simple release just a smartfirmware part with a python script which build a new rom from original (extracting bootstrap, combine with our smartfirmware, and create new rom). This way ppls already can use it, while i will worry about bootstrap replacement, which, IMHO, will be harder part.

Currently fighting with another strange issue : when i run original firmware, then soft reset, then i can run my own fine too till workbench boot (both uses same bootstrap from bplan). If i run my firmware after cold boot : Then once i run amigaboot.of it stops/hangs after returning to its own code. No next OF call, and no exception so far. And this can be anything : CPU/cache/MSR/exception/vector state, stack/runtime convention, timer/interrupt state, or some device/platform state original firmware leaves initialized (but only after graphics boot!). And to note that bootstrap is the same bPlan's one..

Edit: issue was about missing fp exception vector together with missing msr's fp bit set, causing silent hang in allocator. Fixed this one and now need to understand how properly hands off usb stack to OS..

@all
Were able to add UHCI support to original OF, so now my firmware can detect usb keyabord, and can detect usb-sticks, and put them to OF as scsi/block devices, and so i can list files on them, etc.

So far all sounds good, if not one moment : i have 3 usb sticks. 2 of them , detects fine, no problem:

Phison Electronics Corp. 16gb (13FE:4300)
Kingston 256gb (0951:1666)


But one which is JetFlash 8GB (8564:1000), while surely works fine and detects fine on windows or on same pegasos2 just via amigaos4, simple fail for me to detects from within firmware: UHCI controller executes the very first address-0 SETUP packet, but the device never gives a valid USB response, so enumeration cannot even read the descriptor. Does not matter what i tried. I compared from amigaos4's usbinfo/ranger the differences: nothing which can explain it. I compare with lspci -vvv from linux : nothing can explain it. In the datasheet on VIA's VT8231 i see nothing about USB quirks or whatever ..

Maybe anyone have any clue or experience with to where a look at ?

The difference is only that i have this stick formatted FFS, and others two (working) are Fat32 and NTFS, but that just about FS, which is not matter until enumeration take place..

@balaton
Quote:

On real pegasos2 if you have attached both usb-keyboard and ps/2 keyboard, the usb-keyboard is one which smartfirmware take as the input, and ps/2 is unusable and didn't work.

Quote:

With -device usb-kbd , while i can see with both my and original firmware that i do have:



But then who can say what keyboard works now when i type, ps/2 or usb one from smartfirmware in qemu?:) that why i were in hope to disable ps/2 to see if it will works.

But that anyway not so matter now, because issue was that keyboard was hardcoded to isa, so now i add "set it to isa only after there wasn't usb one found" , to act like original firmware, and then it works.

Now fighting with usb-mass sticks, because simple os4_stick.img, formatted in fat16 works for qemu now (i just go scsi route), but have issues with real sticks on real pegasos2.

Maybe i need to do passthrough for this exactly usb-sticks, so to try real ones on qemu where it all more easy to debug.

@balaton
Did you aware if pegasos2 emulation support disabling ps2 keyboard/mouse ? I need to test usb keyboard, but for that i need to disable ps2 one : on real pegasos2 when both ps/2 one and usb one connected, the ps/2 one is disables and usb one is the working, but that happens inside of OF, and for mimic that i firstly need to be sure that uhci usb keyboard start working at all.