Hello,
I'm trying to use OFW for the Pegasos2 emulation in QEMU that I'm working on but at the same time I'm trying to make this generic with the promise that it could later be used for other machines emulated by QEMU as well (such as 40p and Macs and maybe even sparc machines but for those compiling the OBP sources may be better as these two seem to have diverged too much, so this is only for PPC now and mainly focusing on Pegasos2 at first). Starting from Artyom's prep/qemu port I've got something starting but it's not working yet and I have several questions and need some advice on how to continue.
My current work in progress code is here:
https://github.com/zbalaton/openfirmware/tree/master/cpu/ppc/qemu
that can be tested with the currently off-tree pegasos2 emulation from:
https://osdn.net/projects/qmiga/scm/git/qemu/tree/pegasos2/
(this is QEMU with WIP pegasos2 patch) only needed to compile with configure --target-list=ppc-softmmu to get qemu-system-ppc with pegasos2 machine, then it can be tested with:
qemu-system-ppc -M pegasos2 -m 512 -bios qofwppc.rom -serial stdio
where qofwppc.rom is what's built from the above OFW fork. More info on the Pegasos2 emulation can be found here:
https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2
To keep it generic and easy to adapt in the future to other machines I'm trying to do what SLOF does and use a flattened DTB to pass initial parameters from QEMU to OFW and start from there instead of detecting hardware as it would be done on a real machine. (Since this is only for QEMU emulated machines, a lot of low level hardware init and testing that OFW would normally do on real hadrware can be skipped as those are not needed for a virtual machine.) I've attempted to port SLOF's fdt parsing, which is in fdt.fth. It's able to create the initial device tree but may have some problems so it needs to be reviewed by someone who knows OFW.
The rest is mostly a cut down version of cpu/ppc/prep/qemu with as much machine specific parts removed as I could. The idea I've tried was to put machine specifics in a drop-in (so a generic rom could be built for similar machines that would load the appropriate driver based on the device tree it got from QEMU or it would be easy to build different roms for different machines with common parts still being the same). I only have one such driver now: the pegasos2.bth implements that drop-in but some code I could not put in there as those do not seem to work in fc file so those are now in pegasos2.fth. Ideally these should also be in the machine specific driver but I'm not sure that's possible. If not then maybe the above idea can't work and we'll need separate rom image for each machine but maybe there are some Forth tricks I'm not aware of to make this work.
Currently this gets to an OFW prompt but detecting pci devices does not work yet. With the default (for pegasos2) cirrus vga a /pci/vga device node is created but I think it stops during that and does not detect any more pci devices. With -vga std (that's the normal QEMU Bochs compatible VGA) it freezes during init-ing the card and with my experimental -vga none -device ati-vga (that's also upstream in QEMU now) an unnamed node is created so something is wrong with PCI probing at the moment. Could it be because not properly doing memory scrub&release? The the prep/qemu rom has some code for this and SLOF fdt code also has some parts to handle that but I did not understand how this should work so I've disabled these but it could be this causes problems with memory management later?
Once this can be made working and would get PCI devices detected next question is if it would be possible to emulate the board's original firmware that the OSes running on it expect. It's an OpenFirmware implementation (SmartFirmware) but properties may be slightly different so it may be necessary to change some properties to match that but I'm not sure what's the best way to do that.
Lastly once Pegasos2 works I may be interested in trying to make this work with the emulated Mac machines in QEMU as well but it seems drivers for that would be needed as those are not included in the OFW sources so it may be a bigger task so for now I focus on Pegasos2 but keeping it open for future enhancement.
I think I need more understanding on how OFW works and if the above is possible at all or how to debug it further so I hope someone here can provide some insight or answer my questions to get me over these hurdles. (I've already read http://wiki.laptop.org/go/Forth_Lessons which was a great introduction also discussing OFW implementation details but that still left me with a lot of pieces missing so I'd need some more help.)
Thank you, BALATON Zoltan
On Fri, Aug 23, 2019 at 1:55 AM BALATON Zoltan balaton@eik.bme.hu wrote:
Hello,
I'm trying to use OFW for the Pegasos2 emulation in QEMU that I'm working on but at the same time I'm trying to make this generic with the promise that it could later be used for other machines emulated by QEMU as well (such as 40p and Macs and maybe even sparc machines but for those compiling the OBP sources may be better as these two seem to have diverged too much, so this is only for PPC now and mainly focusing on Pegasos2 at first). Starting from Artyom's prep/qemu port I've got something starting but it's not working yet and I have several questions and need some advice on how to continue.
My current work in progress code is here:
https://github.com/zbalaton/openfirmware/tree/master/cpu/ppc/qemu
that can be tested with the currently off-tree pegasos2 emulation from:
https://osdn.net/projects/qmiga/scm/git/qemu/tree/pegasos2/
(this is QEMU with WIP pegasos2 patch) only needed to compile with configure --target-list=ppc-softmmu to get qemu-system-ppc with pegasos2 machine, then it can be tested with:
qemu-system-ppc -M pegasos2 -m 512 -bios qofwppc.rom -serial stdio
where qofwppc.rom is what's built from the above OFW fork. More info on the Pegasos2 emulation can be found here:
https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2
To keep it generic and easy to adapt in the future to other machines I'm trying to do what SLOF does and use a flattened DTB to pass initial parameters from QEMU to OFW and start from there instead of detecting hardware as it would be done on a real machine. (Since this is only for QEMU emulated machines, a lot of low level hardware init and testing that OFW would normally do on real hadrware can be skipped as those are not needed for a virtual machine.) I've attempted to port SLOF's fdt parsing, which is in fdt.fth. It's able to create the initial device tree but may have some problems so it needs to be reviewed by someone who knows OFW.
The rest is mostly a cut down version of cpu/ppc/prep/qemu with as much machine specific parts removed as I could. The idea I've tried was to put machine specifics in a drop-in (so a generic rom could be built for similar machines that would load the appropriate driver based on the device tree it got from QEMU or it would be easy to build different roms for different machines with common parts still being the same). I only have one such driver now: the pegasos2.bth implements that drop-in but some code I could not put in there as those do not seem to work in fc file so those are now in pegasos2.fth. Ideally these should also be in the machine specific driver but I'm not sure that's possible. If not then maybe the above idea can't work and we'll need separate rom image for each machine but maybe there are some Forth tricks I'm not aware of to make this work.
Currently this gets to an OFW prompt but detecting pci devices does not work yet. With the default (for pegasos2) cirrus vga a /pci/vga device node is created but I think it stops during that and does not detect any more pci devices. With -vga std (that's the normal QEMU Bochs compatible VGA) it freezes during init-ing the card
You can use the serial to debug the vga. To initialize the vga card you can use
select /vga
if the above hangs, you can turn on debugging of the specific words: dev /vga debug init ( or open or whatever word you want to debug and after that) select /vga
I think the simplest /vga driver is Bochs VGA (bga.fth), since it knows that device is virtual, it doesn't set up clock generator etc.
and with my experimental -vga none -device ati-vga (that's also upstream in QEMU now) an unnamed node is created so something is wrong with PCI probing at the moment. Could it be because not properly doing memory scrub&release?
For some reason (copyright I guess) the ATI drives were never released. You may try extracting the drop-in from the physical ROM if it was built as a drop-in. Otherwise creating an unnamed node is a good sign: your PCI enumerating code is somewhat working
The the prep/qemu rom has some code for this and SLOF fdt code also has some parts to handle that but I did not understand how this should work so I've disabled these but it could be this causes problems with memory management later?
Once this can be made working and would get PCI devices detected next question is if it would be possible to emulate the board's original firmware that the OSes running on it expect. It's an OpenFirmware implementation (SmartFirmware) but properties may be slightly different so it may be necessary to change some properties to match that but I'm not sure what's the best way to do that.
Lastly once Pegasos2 works I may be interested in trying to make this work with the emulated Mac machines in QEMU as well but it seems drivers for that would be needed as those are not included in the OFW sources so it may be a bigger task so for now I focus on Pegasos2 but keeping it open for future enhancement.
I think I need more understanding on how OFW works and if the above is possible at all or how to debug it further so I hope someone here can provide some insight or answer my questions to get me over these hurdles. (I've already read http://wiki.laptop.org/go/Forth_Lessons which was a great introduction also discussing OFW implementation details but that still left me with a lot of pieces missing so I'd need some more help.)
Thank you, BALATON Zoltan _______________________________________________ openfirmware mailing list -- openfirmware@openfirmware.info To unsubscribe send an email to openfirmware-leave@openfirmware.info
On Tue, 17 Sep 2019, Artyom Tarasenko wrote:
On Fri, Aug 23, 2019 at 1:55 AM BALATON Zoltan balaton@eik.bme.hu wrote:
Currently this gets to an OFW prompt but detecting pci devices does not work yet. With the default (for pegasos2) cirrus vga a /pci/vga device node is created but I think it stops during that and does not detect any more pci devices. With -vga std (that's the normal QEMU Bochs compatible VGA) it freezes during init-ing the card
You can use the serial to debug the vga. To initialize the vga card you can use
select /vga
if the above hangs, you can turn on debugging of the specific words: dev /vga debug init ( or open or whatever word you want to debug and after that) select /vga
I think the simplest /vga driver is Bochs VGA (bga.fth), since it knows that device is virtual, it doesn't set up clock generator etc.
and with my experimental -vga none -device ati-vga (that's also upstream in QEMU now) an unnamed node is created so something is wrong with PCI probing at the moment. Could it be because not properly doing memory scrub&release?
For some reason (copyright I guess) the ATI drives were never released. You may try extracting the drop-in from the physical ROM if it was built as a drop-in. Otherwise creating an unnamed node is a good sign: your PCI enumerating code is somewhat working
Thanks for the suggestion I'll try to get more debugging output to find where it hangs when I'll have time (not now). The bochs driver should also work with the QEMU ati-vga emulation because it also supports Bochs VBE (that's how it works with OpenBIOS) but I'm not sure what driver OFW tries to use for it. Should also work as generic VGA so no specific ati driver shuold be needed to get some picture. (OSes I may want to boot have their own drivers so from OFW only basic support is enough,)
I thought the problem may not be related to VGA though but maybe because not correctly initialising memory. The memory detect code for other machines runs scrub&release and the slof fdt also has call to release which I've currently disabled because I don't know how it should work. Therefore memory may not be correctly initialised and this may be needed for pci detection to work?
Regards, BALATON Zoltan
On Tue, Sep 17, 2019 at 4:19 PM BALATON Zoltan balaton@eik.bme.hu wrote:
On Tue, 17 Sep 2019, Artyom Tarasenko wrote:
On Fri, Aug 23, 2019 at 1:55 AM BALATON Zoltan balaton@eik.bme.hu wrote:
Currently this gets to an OFW prompt but detecting pci devices does not work yet. With the default (for pegasos2) cirrus vga a /pci/vga device node is created but I think it stops during that and does not detect any more pci devices. With -vga std (that's the normal QEMU Bochs compatible VGA) it freezes during init-ing the card
You can use the serial to debug the vga. To initialize the vga card you can use
select /vga
if the above hangs, you can turn on debugging of the specific words: dev /vga debug init ( or open or whatever word you want to debug and after that) select /vga
I think the simplest /vga driver is Bochs VGA (bga.fth), since it knows that device is virtual, it doesn't set up clock generator etc.
and with my experimental -vga none -device ati-vga (that's also upstream in QEMU now) an unnamed node is created so something is wrong with PCI probing at the moment. Could it be because not properly doing memory scrub&release?
For some reason (copyright I guess) the ATI drives were never released. You may try extracting the drop-in from the physical ROM if it was built as a drop-in. Otherwise creating an unnamed node is a good sign: your PCI enumerating code is somewhat working
Thanks for the suggestion I'll try to get more debugging output to find where it hangs when I'll have time (not now). The bochs driver should also work with the QEMU ati-vga emulation because it also supports Bochs VBE (that's how it works with OpenBIOS) but I'm not sure what driver OFW tries to use for it. Should also work as generic VGA so no specific ati driver shuold be needed to get some picture. (OSes I may want to boot have their own drivers so from OFW only basic support is enough,)
If in your rom.bth you have something like " ${BP}/dev/video/build/cirrus.fc" " pci1013,b8" $add-dropin " ${BP}/dev/video/build/bga.fc" " class030000" $add-dropin " ${BP}/ofw/termemu/cp881-16.obf" " font" $add-dropin
the bga drop-in should be used as a fallback option for all the VGA devices. On the other hand if you have " ${BP}/dev/video/build/bga.fc" " pci1234,1111" $add-dropin the bga drop-in would be only loaded for the specific card.
I thought the problem may not be related to VGA though but maybe because not correctly initialising memory.
Btw, you can test a pci vga card with any pci machine, including 40p and x86.
The memory detect code for other machines runs scrub&release and the slof fdt also has call to release which I've currently disabled because I don't know how it should work. Therefore memory may not be correctly initialised and this may be needed for pci detection to work?
Are you testing it with QEMU or on a real hardware? Under QEMU it should also work without scrubbing, and for the simplicity of the initial tests you can hard code the amount of RAM similarly as it's done for 40p model.
On Tue, 17 Sep 2019, Artyom Tarasenko wrote:
If in your rom.bth you have something like " ${BP}/dev/video/build/cirrus.fc" " pci1013,b8" $add-dropin " ${BP}/dev/video/build/bga.fc" " class030000" $add-dropin " ${BP}/ofw/termemu/cp881-16.obf" " font" $add-dropin
the bga drop-in should be used as a fallback option for all the VGA devices. On the other hand if you have " ${BP}/dev/video/build/bga.fc" " pci1234,1111" $add-dropin the bga drop-in would be only loaded for the specific card.
I have:
" ${BP}/dev/video/build/cirrus.fc" " pci1013,b8" $add-dropin " ${BP}/dev/video/build/bga.fc" " pci1234,1111" $add-dropin " ${BP}/dev/video/build/video.fc" " class030000" $add-dropin
So I think it should use generic VGA for ati-vga. Maybe I should try with bga.fc as well but tried all of cirrus, stdvga and ati-vga (so all three drivers above) and none of these really work so there may be a problem somewhere else not related to VGA but VGA seems to be the first PCI card detected so that's where I see the problem.
I thought the problem may not be related to VGA though but maybe because not correctly initialising memory.
Btw, you can test a pci vga card with any pci machine, including 40p and x86.
But those don't provide the necessary FDT blob so won't work with my patched OFW. Currently only pegasos2 would work.
The memory detect code for other machines runs scrub&release and the slof fdt also has call to release which I've currently disabled because I don't know how it should work. Therefore memory may not be correctly initialised and this may be needed for pci detection to work?
Are you testing it with QEMU or on a real hardware? Under QEMU it should also work without scrubbing, and for the simplicity of the initial tests you can hard code the amount of RAM similarly as it's done for 40p model.
I only test with QEMU and this is meant to only work with QEMU. Also the point of passing memory size via FDT is to avoid hard coding it. It prints the correct size and sets the reg property of the /memory node but I'm not sure memory is properly set up for OpenFirmware's own memory management. If by scrubbing you mean set to 0 that's probably not needed for QEMU but what does release do? I think that part may still be needed and currently I don't do that because I don't know how to correctly use that word.
Regards, BALATON Zoltan
openfirmware@openfirmware.info