| Message ID | cover.1615345138.git.balaton@eik.bme.hu |
|---|---|
| Headers | show |
| Series | Pegasos2 emulation | expand |
On Wed, 10 Mar 2021, BALATON Zoltan wrote: > Hello, I've started posting this series well in advance to get it into 6.0 and yet it seems like it may be missing it due to organisational issues (no real complaints were found with patches but Philippe seems to like more review that does not seem to happen as nobody is interested). Looks like David is waiting for an ack from Philippe but will be away next week so if this is not resolved now it may be too late on Monday. To avoid that: David, could you please send an ack before you leave for the last two patches so it could get committed via some other tree while you're away? Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via your tree before the freeze? That would give you some more days to review and it could always be reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it in again which would be another long delay. I don't think this will get more reviews unless it's in master and people can start using and testing it better. Thank you, BALATON Zoltan > This is adding a new PPC board called pegasos2. More info on it can be > found at: > > https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 > > Currently it needs a firmware ROM image that I cannot include due to > original copyright holder (bPlan) did not release it under a free > licence but I have plans to write a replacement in the future. With > the original board firmware it can boot MorphOS now as: > > qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device ati-vga,romfile="" -serial stdio > > then enter "boot cd boot.img" at the firmware "ok" prompt as described > in the MorphOS.readme. To boot Linux use same command line with e.g. > -cdrom debian-8.11.0-powerpc-netinst.iso then enter > "boot cd install/pegasos" > > The last patch adds the actual board code after previous patches > adding VT8231 and MV64361 system controller chip emulation. > > Regards, > BALATON Zoltan > > v7: Fix errp usage in patch 2 > > v6: Rebased on master, updated commit message about migration change > > v5: Changes for review comments from David and Philippe > > V4: Rename pegasos2_reset to pegasos2_cpu_reset > Add new files to MAINTAINERS > > BALATON Zoltan (7): > vt82c686: Implement control of serial port io ranges via config regs > vt82c686: QOM-ify superio related functionality > vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO > vt82c686: Introduce abstract TYPE_VIA_ISA and base vt82c686b_isa on it > vt82c686: Add emulation of VT8231 south bridge > hw/pci-host: Add emulation of Marvell MV64361 PPC system controller > hw/ppc: Add emulation of Genesi/bPlan Pegasos II > > Philippe Mathieu-Daudé (1): > hw/isa/Kconfig: Add missing dependency VIA VT82C686 -> APM > > MAINTAINERS | 10 + > default-configs/devices/ppc-softmmu.mak | 2 + > hw/isa/Kconfig | 1 + > hw/isa/vt82c686.c | 517 +++++++++++-- > hw/pci-host/Kconfig | 4 + > hw/pci-host/meson.build | 2 + > hw/pci-host/mv64361.c | 966 ++++++++++++++++++++++++ > hw/pci-host/mv643xx.h | 918 ++++++++++++++++++++++ > hw/pci-host/trace-events | 6 + > hw/ppc/Kconfig | 9 + > hw/ppc/meson.build | 2 + > hw/ppc/pegasos2.c | 144 ++++ > include/hw/isa/vt82c686.h | 2 +- > include/hw/pci-host/mv64361.h | 8 + > include/hw/pci/pci_ids.h | 4 +- > 15 files changed, 2512 insertions(+), 83 deletions(-) > create mode 100644 hw/pci-host/mv64361.c > create mode 100644 hw/pci-host/mv643xx.h > create mode 100644 hw/ppc/pegasos2.c > create mode 100644 include/hw/pci-host/mv64361.h > >
On Sat, 13 Mar 2021, BALATON Zoltan wrote: > On Wed, 10 Mar 2021, BALATON Zoltan wrote: >> Hello, > > I've started posting this series well in advance to get it into 6.0 and yet > it seems like it may be missing it due to organisational issues (no real > complaints were found with patches but Philippe seems to like more review > that does not seem to happen as nobody is interested). Looks like David is > waiting for an ack from Philippe but will be away next week so if this is not > resolved now it may be too late on Monday. To avoid that: > > David, could you please send an ack before you leave for the last two patches > so it could get committed via some other tree while you're away? > > Philippe, if you can't ack the vt82c686 patches now are you OK with taking > the whole series via your tree before the freeze? That would give you some > more days to review and it could always be reverted during the freeze but if > it's not merged now I'll have to wait until the summer to get it in again > which would be another long delay. I don't think this will get more reviews > unless it's in master and people can start using and testing it better. Hello, Since David seems to be away for this week before seeing my mail asking for an ack from him, now this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe acked it so I think that can count as an implicit ack and it could always be reverted before the releease.) Philippe, do you have anything against this to get merged now? If not please send a pull or ack it so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the freeze. This series was on the list since January and the remaining parts you did not take are here since February 22nd and the version after your first review since two weeks so it would be nice to sort this out and not block it any further without a good reason. Regards, BALATON Zoltan >> This is adding a new PPC board called pegasos2. More info on it can be >> found at: >> >> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 >> >> Currently it needs a firmware ROM image that I cannot include due to >> original copyright holder (bPlan) did not release it under a free >> licence but I have plans to write a replacement in the future. With >> the original board firmware it can boot MorphOS now as: >> >> qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device ati-vga,romfile="" >> -serial stdio >> >> then enter "boot cd boot.img" at the firmware "ok" prompt as described >> in the MorphOS.readme. To boot Linux use same command line with e.g. >> -cdrom debian-8.11.0-powerpc-netinst.iso then enter >> "boot cd install/pegasos" >> >> The last patch adds the actual board code after previous patches >> adding VT8231 and MV64361 system controller chip emulation. >> >> Regards, >> BALATON Zoltan >> >> v7: Fix errp usage in patch 2 >> >> v6: Rebased on master, updated commit message about migration change >> >> v5: Changes for review comments from David and Philippe >> >> V4: Rename pegasos2_reset to pegasos2_cpu_reset >> Add new files to MAINTAINERS >> >> BALATON Zoltan (7): >> vt82c686: Implement control of serial port io ranges via config regs >> vt82c686: QOM-ify superio related functionality >> vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO >> vt82c686: Introduce abstract TYPE_VIA_ISA and base vt82c686b_isa on it >> vt82c686: Add emulation of VT8231 south bridge >> hw/pci-host: Add emulation of Marvell MV64361 PPC system controller >> hw/ppc: Add emulation of Genesi/bPlan Pegasos II >> >> Philippe Mathieu-Daudé (1): >> hw/isa/Kconfig: Add missing dependency VIA VT82C686 -> APM >> >> MAINTAINERS | 10 + >> default-configs/devices/ppc-softmmu.mak | 2 + >> hw/isa/Kconfig | 1 + >> hw/isa/vt82c686.c | 517 +++++++++++-- >> hw/pci-host/Kconfig | 4 + >> hw/pci-host/meson.build | 2 + >> hw/pci-host/mv64361.c | 966 ++++++++++++++++++++++++ >> hw/pci-host/mv643xx.h | 918 ++++++++++++++++++++++ >> hw/pci-host/trace-events | 6 + >> hw/ppc/Kconfig | 9 + >> hw/ppc/meson.build | 2 + >> hw/ppc/pegasos2.c | 144 ++++ >> include/hw/isa/vt82c686.h | 2 +- >> include/hw/pci-host/mv64361.h | 8 + >> include/hw/pci/pci_ids.h | 4 +- >> 15 files changed, 2512 insertions(+), 83 deletions(-) >> create mode 100644 hw/pci-host/mv64361.c >> create mode 100644 hw/pci-host/mv643xx.h >> create mode 100644 hw/ppc/pegasos2.c >> create mode 100644 include/hw/pci-host/mv64361.h >> >
Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : > On Sat, 13 Mar 2021, BALATON Zoltan wrote: >> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>> Hello, >> >> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >> be missing it due to organisational issues (no real complaints were found with patches but >> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >> like David is waiting for an ack from Philippe but will be away next week so if this is not >> resolved now it may be too late on Monday. To avoid that: >> >> David, could you please send an ack before you leave for the last two patches so it could get >> committed via some other tree while you're away? >> >> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >> your tree before the freeze? That would give you some more days to review and it could always be >> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >> in again which would be another long delay. I don't think this will get more reviews unless it's >> in master and people can start using and testing it better. > > Hello, > > Since David seems to be away for this week before seeing my mail asking for an ack from him, now > this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe > acked it so I think that can count as an implicit ack and it could always be reverted before the > releease.) > > Philippe, do you have anything against this to get merged now? If not please send a pull or ack it > so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the > freeze. This series was on the list since January and the remaining parts you did not take are here > since February 22nd and the version after your first review since two weeks so it would be nice to > sort this out and not block it any further without a good reason. Pegasos looks like a New World PowerMac, so perhaps Mark can help? Thanks, Laurent
On 3/16/21 10:01 AM, Laurent Vivier wrote: > Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>> Hello, >>> >>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>> be missing it due to organisational issues (no real complaints were found with patches but >>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>> resolved now it may be too late on Monday. To avoid that: >>> >>> David, could you please send an ack before you leave for the last two patches so it could get >>> committed via some other tree while you're away? >>> >>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>> your tree before the freeze? That would give you some more days to review and it could always be >>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >>> in again which would be another long delay. I don't think this will get more reviews unless it's >>> in master and people can start using and testing it better. >> >> Hello, >> >> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe >> acked it so I think that can count as an implicit ack and it could always be reverted before the >> releease.) >> >> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >> freeze. This series was on the list since January and the remaining parts you did not take are here >> since February 22nd and the version after your first review since two weeks so it would be nice to >> sort this out and not block it any further without a good reason. > > Pegasos looks like a New World PowerMac, so perhaps Mark can help? The PPC part is mostly reviewed. The problem is the first patch: "vt82c686: Implement control of serial port io ranges via config regs". I don't understand it. Zoltan said Paolo isn't acking it because he doesn't mind. I prefer to be cautious and think than Paolo is rather too busy. Laurent, Peter, can you have a look at it? Thanks, Phil.
Le 16/03/2021 à 12:49, Philippe Mathieu-Daudé a écrit : > On 3/16/21 10:01 AM, Laurent Vivier wrote: >> Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >>> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>>> Hello, >>>> >>>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>>> be missing it due to organisational issues (no real complaints were found with patches but >>>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>>> resolved now it may be too late on Monday. To avoid that: >>>> >>>> David, could you please send an ack before you leave for the last two patches so it could get >>>> committed via some other tree while you're away? >>>> >>>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>>> your tree before the freeze? That would give you some more days to review and it could always be >>>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >>>> in again which would be another long delay. I don't think this will get more reviews unless it's >>>> in master and people can start using and testing it better. >>> >>> Hello, >>> >>> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >>> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe >>> acked it so I think that can count as an implicit ack and it could always be reverted before the >>> releease.) >>> >>> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >>> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >>> freeze. This series was on the list since January and the remaining parts you did not take are here >>> since February 22nd and the version after your first review since two weeks so it would be nice to >>> sort this out and not block it any further without a good reason. >> >> Pegasos looks like a New World PowerMac, so perhaps Mark can help? > > The PPC part is mostly reviewed. The problem is the first patch: > "vt82c686: Implement control of serial port io ranges via config regs". vt82c686.c is a Fuloong 2E file, why Fuloong 2E maintainers are not involved in the review? Thanks, Laurent
On Tue, 16 Mar 2021, Laurent Vivier wrote: > Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>> Hello, >>> >>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>> be missing it due to organisational issues (no real complaints were found with patches but >>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>> resolved now it may be too late on Monday. To avoid that: >>> >>> David, could you please send an ack before you leave for the last two patches so it could get >>> committed via some other tree while you're away? >>> >>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>> your tree before the freeze? That would give you some more days to review and it could always be >>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >>> in again which would be another long delay. I don't think this will get more reviews unless it's >>> in master and people can start using and testing it better. >> >> Hello, >> >> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe >> acked it so I think that can count as an implicit ack and it could always be reverted before the >> releease.) >> >> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >> freeze. This series was on the list since January and the remaining parts you did not take are here >> since February 22nd and the version after your first review since two weeks so it would be nice to >> sort this out and not block it any further without a good reason. > > Pegasos looks like a New World PowerMac, so perhaps Mark can help? The pegasos2 is more like a MIPS machine or a PC with a PPC than a PowerMac at the hardware level even if it implements similar specs like PowerMacs so not sure how much knowledge about Macs would help here. Besides we had a disagreement with Mark about what level of perfectness is needed for new QEMU devices so he stayed away from these. That said if anyone has a comment feel free to share, it probably has missed 6.0 now anyway. But I'll try to do everything needed to squeeze it in if that's still possible. Regards, BALATON Zoltan
On Tue, 16 Mar 2021, Laurent Vivier wrote: > Le 16/03/2021 à 12:49, Philippe Mathieu-Daudé a écrit : >> On 3/16/21 10:01 AM, Laurent Vivier wrote: >>> Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >>>> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>>>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>>>> Hello, >>>>> >>>>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>>>> be missing it due to organisational issues (no real complaints were found with patches but >>>>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>>>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>>>> resolved now it may be too late on Monday. To avoid that: >>>>> >>>>> David, could you please send an ack before you leave for the last two patches so it could get >>>>> committed via some other tree while you're away? >>>>> >>>>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>>>> your tree before the freeze? That would give you some more days to review and it could always be >>>>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >>>>> in again which would be another long delay. I don't think this will get more reviews unless it's >>>>> in master and people can start using and testing it better. >>>> >>>> Hello, >>>> >>>> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >>>> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe >>>> acked it so I think that can count as an implicit ack and it could always be reverted before the >>>> releease.) >>>> >>>> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >>>> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >>>> freeze. This series was on the list since January and the remaining parts you did not take are here >>>> since February 22nd and the version after your first review since two weeks so it would be nice to >>>> sort this out and not block it any further without a good reason. >>> >>> Pegasos looks like a New World PowerMac, so perhaps Mark can help? >> >> The PPC part is mostly reviewed. The problem is the first patch: >> "vt82c686: Implement control of serial port io ranges via config regs". > > vt82c686.c is a Fuloong 2E file, why Fuloong 2E maintainers are not involved in the review? Philippe is MIPS maintainer and he was involved and reviewed most patches. Huacai did not respond much and Jiaxun's email adress is constantly stripped by the list so whenrver I add him it will be lost the next time. He seems to be more interested in Fuloong 3 anyway so did not respond much either. All in all I think there's just not enough interest in these machines/devices so my stance is that if it does not break anything just take it now and then we'll have enough time for further review, fixing or reverting during the freeze. Whereas if this is kept pushing back then nothing will happen with them for the next 2-3 months then we'll be back to here and miss the next release as well. Regards, BALATON Zoltan
Le 16/03/2021 à 13:24, BALATON Zoltan a écrit : > On Tue, 16 Mar 2021, Laurent Vivier wrote: >> Le 16/03/2021 à 12:49, Philippe Mathieu-Daudé a écrit : >>> On 3/16/21 10:01 AM, Laurent Vivier wrote: >>>> Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >>>>> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>>>>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>>>>> Hello, >>>>>> >>>>>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>>>>> be missing it due to organisational issues (no real complaints were found with patches but >>>>>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>>>>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>>>>> resolved now it may be too late on Monday. To avoid that: >>>>>> >>>>>> David, could you please send an ack before you leave for the last two patches so it could get >>>>>> committed via some other tree while you're away? >>>>>> >>>>>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>>>>> your tree before the freeze? That would give you some more days to review and it could always be >>>>>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to >>>>>> get it >>>>>> in again which would be another long delay. I don't think this will get more reviews unless it's >>>>>> in master and people can start using and testing it better. >>>>> >>>>> Hello, >>>>> >>>>> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >>>>> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if >>>>> Philippe >>>>> acked it so I think that can count as an implicit ack and it could always be reverted before the >>>>> releease.) >>>>> >>>>> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >>>>> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >>>>> freeze. This series was on the list since January and the remaining parts you did not take are >>>>> here >>>>> since February 22nd and the version after your first review since two weeks so it would be nice to >>>>> sort this out and not block it any further without a good reason. >>>> >>>> Pegasos looks like a New World PowerMac, so perhaps Mark can help? >>> >>> The PPC part is mostly reviewed. The problem is the first patch: >>> "vt82c686: Implement control of serial port io ranges via config regs". >> >> vt82c686.c is a Fuloong 2E file, why Fuloong 2E maintainers are not involved in the review? > > Philippe is MIPS maintainer and he was involved and reviewed most patches. Huacai did not respond > much and Jiaxun's email adress is constantly stripped by the list so whenrver I add him it will be > lost the next time. He seems to be more interested in Fuloong 3 anyway so did not respond much either. > > All in all I think there's just not enough interest in these machines/devices so my stance is that > if it does not break anything just take it now and then we'll have enough time for further review, > fixing or reverting during the freeze. Whereas if this is kept pushing back then nothing will happen > with them for the next 2-3 months then we'll be back to here and miss the next release as well. The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 machine, does it? If the problem is only with the first patch perhaps you can remove it to have it merged and come back later with a cleaner implementation (it is presented to be a hack)? I think PATCH 6 can already be merged, and PATCH 2 can be done outside of the series as a pre-requisite. Then it will be easier to manage a series only adding devices for your new machine. Thanks, Laurent
On Tue, 16 Mar 2021, Laurent Vivier wrote: > Le 16/03/2021 à 13:24, BALATON Zoltan a écrit : >> On Tue, 16 Mar 2021, Laurent Vivier wrote: >>> Le 16/03/2021 à 12:49, Philippe Mathieu-Daudé a écrit : >>>> On 3/16/21 10:01 AM, Laurent Vivier wrote: >>>>> Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >>>>>> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>>>>>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>>>>>> Hello, >>>>>>> >>>>>>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>>>>>> be missing it due to organisational issues (no real complaints were found with patches but >>>>>>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>>>>>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>>>>>> resolved now it may be too late on Monday. To avoid that: >>>>>>> >>>>>>> David, could you please send an ack before you leave for the last two patches so it could get >>>>>>> committed via some other tree while you're away? >>>>>>> >>>>>>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>>>>>> your tree before the freeze? That would give you some more days to review and it could always be >>>>>>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to >>>>>>> get it >>>>>>> in again which would be another long delay. I don't think this will get more reviews unless it's >>>>>>> in master and people can start using and testing it better. >>>>>> >>>>>> Hello, >>>>>> >>>>>> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >>>>>> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if >>>>>> Philippe >>>>>> acked it so I think that can count as an implicit ack and it could always be reverted before the >>>>>> releease.) >>>>>> >>>>>> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >>>>>> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >>>>>> freeze. This series was on the list since January and the remaining parts you did not take are >>>>>> here >>>>>> since February 22nd and the version after your first review since two weeks so it would be nice to >>>>>> sort this out and not block it any further without a good reason. >>>>> >>>>> Pegasos looks like a New World PowerMac, so perhaps Mark can help? >>>> >>>> The PPC part is mostly reviewed. The problem is the first patch: >>>> "vt82c686: Implement control of serial port io ranges via config regs". >>> >>> vt82c686.c is a Fuloong 2E file, why Fuloong 2E maintainers are not involved in the review? >> >> Philippe is MIPS maintainer and he was involved and reviewed most patches. Huacai did not respond >> much and Jiaxun's email adress is constantly stripped by the list so whenrver I add him it will be >> lost the next time. He seems to be more interested in Fuloong 3 anyway so did not respond much either. >> >> All in all I think there's just not enough interest in these machines/devices so my stance is that >> if it does not break anything just take it now and then we'll have enough time for further review, >> fixing or reverting during the freeze. Whereas if this is kept pushing back then nothing will happen >> with them for the next 2-3 months then we'll be back to here and miss the next release as well. > > The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 machine, does it? It is needed (as well as all other patches in the series). Patch 1 is needed for getting serial output which is the only way to communicate with the Pegasos2 firmware so it's really hard to boot anything without it. > If the problem is only with the first patch perhaps you can remove it to have it merged and come > back later with a cleaner implementation (it is presented to be a hack)? I'll try to explain it again in another message but there's no cleaner solution available without much more work than I want to take up. To do it a more cleaner way ISA emulation would need to be QOM'ified that I won't do. This solution is a hack in that it pokes the isa-serial device from a superclass but there's no easier and cleaner way to do it so this should be good enough for now and it has the lowest chance to break anything else. > I think PATCH 6 can already be merged, and PATCH 2 can be done outside of the series as a pre-requisite. > > Then it will be easier to manage a series only adding devices for your new machine. It's all or nothing I'm afraid as all these pathces are needed for pegasos2 to work so taking only a few of them won't let users use it in 6.0. Regards, BALATON Zoltan
On Tue, 16 Mar 2021, Philippe Mathieu-Daudé wrote: > On 3/16/21 10:01 AM, Laurent Vivier wrote: >> Le 15/03/2021 à 13:33, BALATON Zoltan a écrit : >>> On Sat, 13 Mar 2021, BALATON Zoltan wrote: >>>> On Wed, 10 Mar 2021, BALATON Zoltan wrote: >>>>> Hello, >>>> >>>> I've started posting this series well in advance to get it into 6.0 and yet it seems like it may >>>> be missing it due to organisational issues (no real complaints were found with patches but >>>> Philippe seems to like more review that does not seem to happen as nobody is interested). Looks >>>> like David is waiting for an ack from Philippe but will be away next week so if this is not >>>> resolved now it may be too late on Monday. To avoid that: >>>> >>>> David, could you please send an ack before you leave for the last two patches so it could get >>>> committed via some other tree while you're away? >>>> >>>> Philippe, if you can't ack the vt82c686 patches now are you OK with taking the whole series via >>>> your tree before the freeze? That would give you some more days to review and it could always be >>>> reverted during the freeze but if it's not merged now I'll have to wait until the summer to get it >>>> in again which would be another long delay. I don't think this will get more reviews unless it's >>>> in master and people can start using and testing it better. >>> >>> Hello, >>> >>> Since David seems to be away for this week before seeing my mail asking for an ack from him, now >>> this can only get in by Philippe or Peter. (David said before he'd be OK with the series if Philippe >>> acked it so I think that can count as an implicit ack and it could always be reverted before the >>> releease.) >>> >>> Philippe, do you have anything against this to get merged now? If not please send a pull or ack it >>> so it has a chance to be in 6.0 or tell if you still intend to do anything about it before the >>> freeze. This series was on the list since January and the remaining parts you did not take are here >>> since February 22nd and the version after your first review since two weeks so it would be nice to >>> sort this out and not block it any further without a good reason. >> >> Pegasos looks like a New World PowerMac, so perhaps Mark can help? > > The PPC part is mostly reviewed. The problem is the first patch: > "vt82c686: Implement control of serial port io ranges via config regs". > > I don't understand it. Zoltan said Paolo isn't acking it because > he doesn't mind. I prefer to be cautious and think than Paolo is > rather too busy. Can you just send a pull request then and Paolo could nack it or comment on that. If he does not, then this should be OK as it does not touch anything else than vt82c686 so it also should not break anything else. Basically what the patch does is have a via-superio class that inherits from TYPE_ISA_SUPERIO that creates the ISA devices, among others isa-serial ports. Then the device grabs the memory regions for these serial devices to be able to change their state and address on config register writes. It only does that for serial devices not for parallel and floppy because those have more than one memory region and would not be easy to handle so those are not configurable but left at their default address. We need configurability for serial port because on pegasos2 there's only one serial port and it's set to a non-standard address by the firmware. Fuloong2e used to put these at default address and the firmware did not touch it, we now more properly emulate the chip and allow changing the address which the firmware leaves at the default but on pegasos that would not work. The resulting model is not so bad as we only access memory region owned by child device (via-superio sets memory region of isa-serial that's created by its superclass isa superio and this is only needed because there's no other interface and one cannot be easily added without possibly breaking something due to other ISA devices that have multiple memory regions). So I think this is the simplest and least invasive solution that shoul be enough for now until ISA device emulation is QOM'ified which is a task I don't want to take up as it's way more work I'd put in and has a possibility to break stuff I don't have a way or time to test so unless somebody does that there's no other easy way to solve this problem. Regards, BALATON Zoltan
Another arrempt to explain patch 1. This is the via-superio class that's a
subclass of ISA superio:
https://github.com/patchew-project/qemu/blob/ca5d88d2fee0016f939e91ae8b32c18e682064fa/hw/isa/vt82c686.c#L255
#define TYPE_VIA_SUPERIO "via-superio"
OBJECT_DECLARE_SIMPLE_TYPE(ViaSuperIOState, VIA_SUPERIO)
struct ViaSuperIOState {
ISASuperIODevice superio;
uint8_t regs[0x100];
const MemoryRegionOps *io_ops;
MemoryRegion io;
MemoryRegion *serial_io[SUPERIO_MAX_SERIAL_PORTS];
};
[...]
static void via_superio_realize(DeviceState *d, Error **errp)
{
ViaSuperIOState *s = VIA_SUPERIO(d);
ISASuperIOClass *ic = ISA_SUPERIO_GET_CLASS(s);
Error *local_err = NULL;
int i;
assert(s->io_ops);
ic->parent_realize(d, &local_err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
/* Grab io regions of serial devices so we can control them */
for (i = 0; i < ic->serial.count; i++) {
ISADevice *sd = s->superio.serial[i];
MemoryRegion *io = isa_address_space_io(sd);
MemoryRegion *mr = find_subregion(sd, io, sd->ioport_id);
if (!mr) {
error_setg(errp, "Could not get io region for serial %d", i);
return;
}
s->serial_io[i] = mr;
}
memory_region_init_io(&s->io, OBJECT(d), s->io_ops, s, "via-superio", 2);
memory_region_set_enabled(&s->io, false);
/* The floppy also uses 0x3f0 and 0x3f1 but this seems to work anyway */
memory_region_add_subregion(isa_address_space_io(ISA_DEVICE(s)), 0x3f0,
&s->io);
}
In realize we grab pointers to the MemoryRegions of the isa-serial devices
created by the ISA superio class. This is ISA superio:
https://github.com/patchew-project/qemu/blob/ca5d88d2fee0016f939e91ae8b32c18e682064fa/include/hw/isa/superio.h#L23
#define SUPERIO_MAX_SERIAL_PORTS 4
struct ISASuperIODevice {
/*< private >*/
ISADevice parent_obj;
/*< public >*/
ISADevice *parallel[MAX_PARALLEL_PORTS];
ISADevice *serial[SUPERIO_MAX_SERIAL_PORTS];
ISADevice *floppy;
ISADevice *kbc;
ISADevice *ide;
};
The serial members we access are even public so this should be OK (other
models to that too) but we need to get their MemoryRegion as we need to
configure that based on VIA superio registers. ISADevice is defined in:
https://github.com/patchew-project/qemu/blob/patchew/cover.1615345138.git.balaton%40eik.bme.hu/include/hw/isa/isa.h
but it does not store a reference to its memory regions:
struct ISADevice {
/*< private >*/
DeviceState parent_obj;
/*< public >*/
int8_t isairq[2]; /* -1 = unassigned */
int nirqs;
int ioport_id;
};
only an ioport_id which is the address of its first io region so we have
to get the actual MemoryRegion based on that. This works for isa-serial
that has a single mem region but would not for parallel or FDC that have
multiple regions. Those are created with isa_register_portio_list() I
think but we don't care about parallel and FDC only about serial.
This may be possible to clean up but that would need changes to ISA
emulation that I don't want to change so the patch tries to achieve what's
needed without changing how ISA devices are emulated currently. I think
the solution proposed in patch 1 is relatively clean and by not changing
anything than vt82c686 it avoids any possible breakage to other machines
using ISA devices so unless there's a reason not to accept it this should
solve the problem and allow pegasos2 firmware to boot.
Regards,
BALATON Zoltan
On 16/03/2021 13:06, BALATON Zoltan wrote: >> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 machine, does it? > > It is needed (as well as all other patches in the series). Patch 1 is needed for > getting serial output which is the only way to communicate with the Pegasos2 firmware > so it's really hard to boot anything without it. Just having a quick look at patch 1: presumably the issue here is that the Pegasos 2 firmware moves the serial ports to a different address on startup. If you know what that address is, then why not simply change the serial port base address(es) on the SuperIO device from the default? ATB, Mark.
On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: > On 16/03/2021 13:06, BALATON Zoltan wrote: >>> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 machine, >>> does it? >> >> It is needed (as well as all other patches in the series). Patch 1 is >> needed for getting serial output which is the only way to communicate with >> the Pegasos2 firmware so it's really hard to boot anything without it. > > Just having a quick look at patch 1: presumably the issue here is that the > Pegasos 2 firmware moves the serial ports to a different address on startup. > If you know what that address is, then why not simply change the serial port > base address(es) on the SuperIO device from the default? I had that as first version but other guests may expect the serial at the default address or set it up differently and we can emulate the device more fully this way that works with all guests which is also more like the device works. So putting it at a default address would be a step back. I can attempt that if this approach cannot be used but so far nobody said so. Regards, BALATON Zoltan
On 16/03/2021 17:25, BALATON Zoltan wrote: > On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: >> On 16/03/2021 13:06, BALATON Zoltan wrote: >>>> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 machine, does it? >>> >>> It is needed (as well as all other patches in the series). Patch 1 is needed for >>> getting serial output which is the only way to communicate with the Pegasos2 >>> firmware so it's really hard to boot anything without it. >> >> Just having a quick look at patch 1: presumably the issue here is that the Pegasos >> 2 firmware moves the serial ports to a different address on startup. If you know >> what that address is, then why not simply change the serial port base address(es) >> on the SuperIO device from the default? > > I had that as first version but other guests may expect the serial at the default > address or set it up differently and we can emulate the device more fully this way > that works with all guests which is also more like the device works. So putting it at > a default address would be a step back. I can attempt that if this approach cannot be > used but so far nobody said so. That would certainly be my first choice, as swapping out the memory regions within the ISA bus without its knowledge is likely to cause problems (I can see ioport_id being incorrect for one). Do the guest OSs actually use this feature at all? I don't think I've ever seen such registers being used within QEMU, OSs tend to simply relocate the IO space base address using the BAR if required. If Linux/MorphOS work with a fixed address then that's good enough for now: the code should look something like this: dev = qdev_new(TYPE_SUPER_IO); serial_dev = object_resolve_path_component(OBJECT(dev), "serial0")); qdev_prop_set_uint32(dev, "iobase", 0x1234); qdev_realise_and_unref(dev, &error_fatal); ATB, Mark.
On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: > On 16/03/2021 17:25, BALATON Zoltan wrote: >> On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: >>> On 16/03/2021 13:06, BALATON Zoltan wrote: >>>>> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 >>>>> machine, does it? >>>> >>>> It is needed (as well as all other patches in the series). Patch 1 is >>>> needed for getting serial output which is the only way to communicate >>>> with the Pegasos2 firmware so it's really hard to boot anything without >>>> it. >>> >>> Just having a quick look at patch 1: presumably the issue here is that the >>> Pegasos 2 firmware moves the serial ports to a different address on >>> startup. If you know what that address is, then why not simply change the >>> serial port base address(es) on the SuperIO device from the default? >> >> I had that as first version but other guests may expect the serial at the >> default address or set it up differently and we can emulate the device more >> fully this way that works with all guests which is also more like the >> device works. So putting it at a default address would be a step back. I >> can attempt that if this approach cannot be used but so far nobody said so. > > That would certainly be my first choice, as swapping out the memory regions > within the ISA bus without its knowledge is likely to cause problems (I can > see ioport_id being incorrect for one). Did you check what's that used for? Unlikely to cause any problems other than displaying initial value of port address instead of current address in device ID but that could be argued about if an ID should change or stay the same as initially. Easily fixable either way. > Do the guest OSs actually use this feature at all? I don't think I've ever > seen such registers being used within QEMU, OSs tend to simply relocate the > IO space base address using the BAR if required. The ISA devices don't have io BAR, they are relocatable _within_ ISA IO space by the config registers of the VIA superio chip. But the two guests that currently boot (MorphOS and Linux) don't seems to change default set by the firmware so we can go with the firmware defaults which is less correct than actually emulating what the chip does but whatever. (AmigaOS may also boot but has no gfx driver so can't really check at the moment.) > If Linux/MorphOS work with a fixed address then that's good enough for now: > the code should look something like this: > > dev = qdev_new(TYPE_SUPER_IO); > serial_dev = object_resolve_path_component(OBJECT(dev), "serial0")); > qdev_prop_set_uint32(dev, "iobase", 0x1234); > qdev_realise_and_unref(dev, &error_fatal); I've sent a v8 dropping patch 1 and setting a default but using the callback ISA superio has for this for that which is a bit cleaner IMO. Could this turned into a pull request by somebody now? Regards, BALATON Zoltan
On Tue, 16 Mar 2021, BALATON Zoltan wrote: > On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: >> On 16/03/2021 17:25, BALATON Zoltan wrote: >>> On Tue, 16 Mar 2021, Mark Cave-Ayland wrote: >>>> On 16/03/2021 13:06, BALATON Zoltan wrote: >>>>>> The PATCH 1 doesn't seem to be needed to have a working Pegasos 2 >>>>>> machine, does it? >>>>> >>>>> It is needed (as well as all other patches in the series). Patch 1 is >>>>> needed for getting serial output which is the only way to communicate >>>>> with the Pegasos2 firmware so it's really hard to boot anything without >>>>> it. >>>> >>>> Just having a quick look at patch 1: presumably the issue here is that >>>> the Pegasos 2 firmware moves the serial ports to a different address on >>>> startup. If you know what that address is, then why not simply change the >>>> serial port base address(es) on the SuperIO device from the default? >>> >>> I had that as first version but other guests may expect the serial at the >>> default address or set it up differently and we can emulate the device >>> more fully this way that works with all guests which is also more like the >>> device works. So putting it at a default address would be a step back. I >>> can attempt that if this approach cannot be used but so far nobody said >>> so. >> >> That would certainly be my first choice, as swapping out the memory regions >> within the ISA bus without its knowledge is likely to cause problems (I can >> see ioport_id being incorrect for one). > > Did you check what's that used for? Unlikely to cause any problems other than > displaying initial value of port address instead of current address in device > ID but that could be argued about if an ID should change or stay the same as > initially. Easily fixable either way. > >> Do the guest OSs actually use this feature at all? I don't think I've ever >> seen such registers being used within QEMU, OSs tend to simply relocate the >> IO space base address using the BAR if required. > > The ISA devices don't have io BAR, they are relocatable _within_ ISA IO space > by the config registers of the VIA superio chip. But the two guests that > currently boot (MorphOS and Linux) don't seems to change default set by the > firmware so we can go with the firmware defaults which is less correct than > actually emulating what the chip does but whatever. (AmigaOS may also boot > but has no gfx driver so can't really check at the moment.) > >> If Linux/MorphOS work with a fixed address then that's good enough for now: >> the code should look something like this: >> >> dev = qdev_new(TYPE_SUPER_IO); >> serial_dev = object_resolve_path_component(OBJECT(dev), "serial0")); >> qdev_prop_set_uint32(dev, "iobase", 0x1234); >> qdev_realise_and_unref(dev, &error_fatal); > > I've sent a v8 dropping patch 1 and setting a default but using the callback And v9 replacing patch 5 with latest that applies on master that has changed while I was sending the previous version... > ISA superio has for this for that which is a bit cleaner IMO. > > Could this turned into a pull request by somebody now? > > Regards, > BALATON Zoltan > >
Hello, This is adding a new PPC board called pegasos2. More info on it can be found at: https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 Currently it needs a firmware ROM image that I cannot include due to original copyright holder (bPlan) did not release it under a free licence but I have plans to write a replacement in the future. With the original board firmware it can boot MorphOS now as: qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device ati-vga,romfile="" -serial stdio then enter "boot cd boot.img" at the firmware "ok" prompt as described in the MorphOS.readme. To boot Linux use same command line with e.g. -cdrom debian-8.11.0-powerpc-netinst.iso then enter "boot cd install/pegasos" The last patch adds the actual board code after previous patches adding VT8231 and MV64361 system controller chip emulation. Regards, BALATON Zoltan v7: Fix errp usage in patch 2 v6: Rebased on master, updated commit message about migration change v5: Changes for review comments from David and Philippe V4: Rename pegasos2_reset to pegasos2_cpu_reset Add new files to MAINTAINERS BALATON Zoltan (7): vt82c686: Implement control of serial port io ranges via config regs vt82c686: QOM-ify superio related functionality vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO vt82c686: Introduce abstract TYPE_VIA_ISA and base vt82c686b_isa on it vt82c686: Add emulation of VT8231 south bridge hw/pci-host: Add emulation of Marvell MV64361 PPC system controller hw/ppc: Add emulation of Genesi/bPlan Pegasos II Philippe Mathieu-Daudé (1): hw/isa/Kconfig: Add missing dependency VIA VT82C686 -> APM MAINTAINERS | 10 + default-configs/devices/ppc-softmmu.mak | 2 + hw/isa/Kconfig | 1 + hw/isa/vt82c686.c | 517 +++++++++++-- hw/pci-host/Kconfig | 4 + hw/pci-host/meson.build | 2 + hw/pci-host/mv64361.c | 966 ++++++++++++++++++++++++ hw/pci-host/mv643xx.h | 918 ++++++++++++++++++++++ hw/pci-host/trace-events | 6 + hw/ppc/Kconfig | 9 + hw/ppc/meson.build | 2 + hw/ppc/pegasos2.c | 144 ++++ include/hw/isa/vt82c686.h | 2 +- include/hw/pci-host/mv64361.h | 8 + include/hw/pci/pci_ids.h | 4 +- 15 files changed, 2512 insertions(+), 83 deletions(-) create mode 100644 hw/pci-host/mv64361.c create mode 100644 hw/pci-host/mv643xx.h create mode 100644 hw/ppc/pegasos2.c create mode 100644 include/hw/pci-host/mv64361.h