| Message ID | b4a7f8e59ba8f6eaa03e7fe24690df7b39b17e8d.1537379317.git.noring@nocrew.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | target/mips: Support R5900 GCC programs in user mode | expand |
Hi Fredrik, On 9/15/18 11:50 AM, Fredrik Noring wrote: > The primary purpose of this change is to support programs compiled by > GCC for the R5900 target and thereby run R5900 Linux distributions, for > example Gentoo. In particular, this avoids issues with cross compilation. > > This change has been tested with Gentoo compiled for R5900, including > native compilation of several packages under QEMU. > > Signed-off-by: Fredrik Noring <noring@nocrew.org> > --- > target/mips/translate_init.inc.c | 47 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c > index b3320b9dc7..71fd83de06 100644 > --- a/target/mips/translate_init.inc.c > +++ b/target/mips/translate_init.inc.c > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > .insn_flags = CPU_MIPS32R5 | ASE_MSA, > .mmu_type = MMU_TYPE_R4000, > }, > + { > + .name = "R5900", What bothers me here is you are not modeling "The" unique R5900, but a cpu which implements the R5900 architecture. From the "TX7901 User’s Manual (Rev. 6.30T – Nov, 2001)": The TX7901 MIPS RISC microcontroller is a highly integrated solution based on Toshiba’s dual-issue super-scalar pipeline Processor Core, the C790 (henceforth referred to as “the C790”). C790 High-performance MIPS CPU Core on which the TX7901 is based. So the correct core name is "C790". > + .CP0_PRid = 0x00003800, "The implementation number of the C790 processor is 0x38". OK (note again the correct name: "C790"). > + /* No L2 cache, icache size 32k, dcache size 32k, uncached coherency. */ > + .CP0_Config0 = (0x3 << 9) | (0x3 << 6) | (0x2 << CP0C0_K0), From the DS: The C790 core has the following features: - Large on-chip caches • Instruction cache: 32KB, 2-way set associative • Data cache: 32KB, 2-way set-associative (with write-back protocol) 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for 'Cacheable, write-back, write allocate'? > + .CP0_Status_rw_bitmask = 0xF4C79C1F, Correct. > +#ifdef CONFIG_USER_ONLY > + /* > + * R5900 hardware traps to the Linux kernel for IEEE 754-1985 and LL/SC > + * emulation. For user only, QEMU is the kernel, so we emulate the traps > + * by simply emulating the instructions directly. > + * > + * Note: Config1 is only used internally, the R5900 has only Config0. > + */ > + .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU), Richard Henderson suggested to use ...: .CP0_Config1 = CP0C1_FP_USER_ONLY | (47 << CP0C1_MMU), > + .CP0_LLAddr_rw_bitmask = 0xFFFFFFFF, > + .CP0_LLAddr_shift = 4, ... and Maciej said "No LL/SC in the R5900, so the LLAddr settings can go"; but you previously explained "kernel traps FPU instructions to emulate them". That was clearer to me than "For user only, QEMU is the kernel", but it is understandable. > + .CP1_fcr0 = (0x38 << FCR0_PRID) | (0x0 << FCR0_REV), OK. > + .CP1_fcr31 = 0, > + .CP1_fcr31_rw_bitmask = 0x0183FFFF, OK. > +#else > + /* > + * The R5900 COP1 FPU implements single-precision floating-point > + * operations but is not entirely IEEE 754-1985 compatible. In > + * particular, > + * > + * - NaN (not a number) and plus/minus infinities are not supported; > + * - exception mechanisms are not fully supported; > + * - denormalized numbers are not supported; > + * - rounding towards nearest and plus/minus infinities are not supported; > + * - computed results usually differs in the least significant bit; > + * - saturating instructions can differ more than the least significant bit. > + * > + * Since only rounding towards zero is supported, the two least > + * significant bits of FCR31 are hardwired to 01. > + * > + * FPU emulation is disabled here until it is implemented. > + * > + * Note: Config1 is only used internally, the R5900 has only Config0. > + */ > + .CP0_Config1 = (47 << CP0C1_MMU), 48 entry TLB, OK. > +#endif /* !CONFIG_USER_ONLY */ > + .SEGBITS = 32, OK. > + .PABITS = 32, 20 bits PFN + 12 bits offset = 32 (Maciej, can you verify please?). > + .insn_flags = CPU_R5900, I'd rather use: .insn_flags = CPU_MIPS3 | INSN_R5900, But that's OK. > + .mmu_type = MMU_TYPE_R4000, "The C790 processor provides a memory management unit (MMU) [...] as the one implemented in R4000" OK. > + }, > { > /* A generic CPU supporting MIPS32 Release 6 ISA. > FIXME: Support IEEE 754-2008 FP. > Regards, Phil.
> On 9/15/18 11:50 AM, Fredrik Noring wrote: [...] >> + { >> + .name = "R5900", > > What bothers me here is you are not modeling "The" unique R5900, but a > cpu which implements the R5900 architecture. > > From the "TX7901 User’s Manual (Rev. 6.30T – Nov, 2001)": > > The TX7901 MIPS RISC microcontroller is a highly integrated solution > based on Toshiba’s dual-issue super-scalar pipeline Processor Core, > the C790 (henceforth referred to as “the C790”). > > C790 High-performance MIPS CPU Core on which the TX7901 is based. > > So the correct core name is "C790". FYI, if the qemu-system mode is ever implemented, the TMPR7901 is the SoC that uses the C790 core: https://www.toshiba.co.jp/about/press/2001_09/pr2701.htm "The core of the new reduced instruction set computer (RISC) microprocessor, the TX79 family, was developed by ArTile Microsystems, Inc., a fully-owned subsidiary of Toshiba America Electronic Components, Inc. The core of the processor is based on know-how cultivated in the joint-development with Sony Computer Entertainment Inc. of EmotionEngine(R), the processor used in PlayStation(R)2. " Also: https://www.design-reuse.com/news/405/artile-thinks-entertainment-soc.html "ArTile Microsystems has announced the first in a family of MIPS-based high-performance systems-on-chip (SOCs). The TMPR7901B incorporates a multimedia-enhanced RISC processor core with instruction and data cache memories, PCI and Ethernet interfaces, timers, and memory controllers in a single device. [...] The 790X family starts with the C790, a 128-bit MIPS-compatible RISC processor core with multiply-accumulate and bit-manipulation instruction enhancements. On the TMPR7901B device, the core comes with dual 32-kbyte, 2-way set-associative caches for instruction and data on chip and a 1Gbyte SDRAM memory controller with DMA access for high-speed external memory access. The device also has a dual 10/100 Mbps Ethernet MAC, two separate PCI controllers (33 MHz and 66 MHz), and three 24-bit timer-counters. The presence of the PCI bus bridges on-chip solves a system bottleneck that has compromised the performance of other, two-chip solutions. A dual UART and a 16-line interrupt controller complete the TMPR7901's bundle." TX7901 User’s Manual: https://www.datasheetarchive.com/TMPR7901-datasheet.html
Hi Philippe, > > diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c > > index b3320b9dc7..71fd83de06 100644 > > --- a/target/mips/translate_init.inc.c > > +++ b/target/mips/translate_init.inc.c > > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > > .insn_flags = CPU_MIPS32R5 | ASE_MSA, > > .mmu_type = MMU_TYPE_R4000, > > }, > > + { > > + .name = "R5900", > > What bothers me here is you are not modeling "The" unique R5900, but a > cpu which implements the R5900 architecture. There was only one R5900 implementation. > >From the "TX7901 User’s Manual (Rev. 6.30T – Nov, 2001)": > > The TX7901 MIPS RISC microcontroller is a highly integrated solution > based on Toshiba’s dual-issue super-scalar pipeline Processor Core, > the C790 (henceforth referred to as “the C790”). > > C790 High-performance MIPS CPU Core on which the TX7901 is based. > > So the correct core name is "C790". The C790 is a follow-up to the R5900. The R5900 has an FPU that is not compliant to the IEEE 754 standard for floating-point arithmetic. It doesn't implement exceptions, infinities, NaNs or denormals. It doesn't implement the the double format either, but that is really tangential, because the same was the case with the IDT R4650, which had a standard IEEE 754 FPU, but no double format either. Finally it has some anomalies in the FP instruction set; not all opcode encodings are standard. No documentation has been made publicly available for the R5900; my understanding is it was only released under NDA as a part of the PS2 SDK. However I have been told that the only software-visible difference (except for graphic coprocessors) between the R5900 and the C790 is the FPU, which in the latter processor is a standard IEEE 754 implementation. So the document named is the best public reference for the R5900. Also any emulation of the C790 will have to use a separate template. > > + .CP0_PRid = 0x00003800, > > "The implementation number of the C790 processor is 0x38". I'll leave the answer to what the values of PRId are for the R5900 vs the C790 to Fredrik or Jürgen. I suspect that the difference is in the Rev field only. > >From the DS: > > The C790 core has the following features: > - Large on-chip caches > • Instruction cache: 32KB, 2-way set associative > • Data cache: 32KB, 2-way set-associative (with write-back protocol) > > 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for > 'Cacheable, write-back, write allocate'? No other MIPS emulation does what you suggest, which is why I refrained from commenting on the K0 field and commented on the ICE/DCE bits only. See: /* Have config1, uncached coherency */ #define MIPS_CONFIG0 \ ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) elsewhere in this file. > > + .PABITS = 32, > > 20 bits PFN + 12 bits offset = 32 (Maciej, can you verify please?). That's what I wrote previously. NB the offset being 12-bit is only the minimum, depending on the PageMask register and used for 4kiB pages only. But it is a useful simplification. Maciej
Cc'ing Laurent for the linux-user FPU emulation part. On 9/15/18 11:50 AM, Fredrik Noring wrote: > The primary purpose of this change is to support programs compiled by > GCC for the R5900 target and thereby run R5900 Linux distributions, for > example Gentoo. In particular, this avoids issues with cross compilation. > > This change has been tested with Gentoo compiled for R5900, including > native compilation of several packages under QEMU. > > Signed-off-by: Fredrik Noring <noring@nocrew.org> > --- > target/mips/translate_init.inc.c | 47 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c > index b3320b9dc7..71fd83de06 100644 > --- a/target/mips/translate_init.inc.c > +++ b/target/mips/translate_init.inc.c > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > .insn_flags = CPU_MIPS32R5 | ASE_MSA, > .mmu_type = MMU_TYPE_R4000, > }, > + { > + .name = "R5900", > + .CP0_PRid = 0x00003800, > + /* No L2 cache, icache size 32k, dcache size 32k, uncached coherency. */ > + .CP0_Config0 = (0x3 << 9) | (0x3 << 6) | (0x2 << CP0C0_K0), > + .CP0_Status_rw_bitmask = 0xF4C79C1F, > +#ifdef CONFIG_USER_ONLY > + /* > + * R5900 hardware traps to the Linux kernel for IEEE 754-1985 and LL/SC > + * emulation. For user only, QEMU is the kernel, so we emulate the traps > + * by simply emulating the instructions directly. > + * > + * Note: Config1 is only used internally, the R5900 has only Config0. > + */ > + .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU), > + .CP0_LLAddr_rw_bitmask = 0xFFFFFFFF, > + .CP0_LLAddr_shift = 4, > + .CP1_fcr0 = (0x38 << FCR0_PRID) | (0x0 << FCR0_REV), > + .CP1_fcr31 = 0, > + .CP1_fcr31_rw_bitmask = 0x0183FFFF, > +#else > + /* > + * The R5900 COP1 FPU implements single-precision floating-point > + * operations but is not entirely IEEE 754-1985 compatible. In > + * particular, > + * > + * - NaN (not a number) and plus/minus infinities are not supported; > + * - exception mechanisms are not fully supported; > + * - denormalized numbers are not supported; > + * - rounding towards nearest and plus/minus infinities are not supported; > + * - computed results usually differs in the least significant bit; > + * - saturating instructions can differ more than the least significant bit. > + * > + * Since only rounding towards zero is supported, the two least > + * significant bits of FCR31 are hardwired to 01. > + * > + * FPU emulation is disabled here until it is implemented. > + * > + * Note: Config1 is only used internally, the R5900 has only Config0. > + */ > + .CP0_Config1 = (47 << CP0C1_MMU), > +#endif /* !CONFIG_USER_ONLY */ > + .SEGBITS = 32, > + .PABITS = 32, > + .insn_flags = CPU_R5900, > + .mmu_type = MMU_TYPE_R4000, > + }, > { > /* A generic CPU supporting MIPS32 Release 6 ISA. > FIXME: Support IEEE 754-2008 FP. >
Hi Maciej, Fredrik. On 9/21/18 1:51 AM, Maciej W. Rozycki wrote: > Hi Philippe, > >>> diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c >>> index b3320b9dc7..71fd83de06 100644 >>> --- a/target/mips/translate_init.inc.c >>> +++ b/target/mips/translate_init.inc.c >>> @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = >>> .insn_flags = CPU_MIPS32R5 | ASE_MSA, >>> .mmu_type = MMU_TYPE_R4000, >>> }, >>> + { >>> + .name = "R5900", >> >> What bothers me here is you are not modeling "The" unique R5900, but a >> cpu which implements the R5900 architecture. > > There was only one R5900 implementation. > >> >From the "TX7901 User’s Manual (Rev. 6.30T – Nov, 2001)": >> >> The TX7901 MIPS RISC microcontroller is a highly integrated solution >> based on Toshiba’s dual-issue super-scalar pipeline Processor Core, >> the C790 (henceforth referred to as “the C790”). >> >> C790 High-performance MIPS CPU Core on which the TX7901 is based. >> >> So the correct core name is "C790". > > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > compliant to the IEEE 754 standard for floating-point arithmetic. It > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > implement the the double format either, but that is really tangential, > because the same was the case with the IDT R4650, which had a standard > IEEE 754 FPU, but no double format either. Finally it has some anomalies > in the FP instruction set; not all opcode encodings are standard. > > No documentation has been made publicly available for the R5900; my > understanding is it was only released under NDA as a part of the PS2 SDK. > However I have been told that the only software-visible difference (except > for graphic coprocessors) between the R5900 and the C790 is the FPU, which > in the latter processor is a standard IEEE 754 implementation. > > So the document named is the best public reference for the R5900. Also > any emulation of the C790 will have to use a separate template. OK. > >>> + .CP0_PRid = 0x00003800, >> >> "The implementation number of the C790 processor is 0x38". > > I'll leave the answer to what the values of PRId are for the R5900 vs the > C790 to Fredrik or Jürgen. I suspect that the difference is in the Rev > field only. Yes, I think so. Fredrik: maybe you can simply name the C790 in the comment pointing to the DS documentation. >> >From the DS: >> >> The C790 core has the following features: >> - Large on-chip caches >> • Instruction cache: 32KB, 2-way set associative >> • Data cache: 32KB, 2-way set-associative (with write-back protocol) >> >> 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for >> 'Cacheable, write-back, write allocate'? > > No other MIPS emulation does what you suggest, which is why I refrained > from commenting on the K0 field and commented on the ICE/DCE bits only. > See: > > /* Have config1, uncached coherency */ > #define MIPS_CONFIG0 \ > ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) > > elsewhere in this file. Yes, this was just out of curiosity. >>> + .PABITS = 32, >> >> 20 bits PFN + 12 bits offset = 32 (Maciej, can you verify please?). > > That's what I wrote previously. > > NB the offset being 12-bit is only the minimum, depending on the PageMask > register and used for 4kiB pages only. But it is a useful simplification. OK. Fredrik, except the linux-user part for kernel FPU emulation that I don't feel confident to review, the rest of this patch looks OK to me: Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Regards, Phil.
On Mon, 24 Sep 2018, Philippe Mathieu-Daudé wrote: > >> >From the DS: > >> > >> The C790 core has the following features: > >> - Large on-chip caches > >> • Instruction cache: 32KB, 2-way set associative > >> • Data cache: 32KB, 2-way set-associative (with write-back protocol) > >> > >> 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for > >> 'Cacheable, write-back, write allocate'? > > > > No other MIPS emulation does what you suggest, which is why I refrained > > from commenting on the K0 field and commented on the ICE/DCE bits only. > > See: > > > > /* Have config1, uncached coherency */ > > #define MIPS_CONFIG0 \ > > ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) > > > > elsewhere in this file. > > Yes, this was just out of curiosity. Also the value of this field at reset is undefined for this CPU (as is architecturally, though some implementations might work otherwise), so 0x2 is as good as any. For the user emulation mode we could consider choosing what the kernel would use, however that would only matter if we had the cache properly emulated. Maciej
On 9/25/18 10:25 AM, Maciej W. Rozycki wrote: > On Mon, 24 Sep 2018, Philippe Mathieu-Daudé wrote: >>>> >From the DS: >>>> >>>> The C790 core has the following features: >>>> - Large on-chip caches >>>> • Instruction cache: 32KB, 2-way set associative >>>> • Data cache: 32KB, 2-way set-associative (with write-back protocol) >>>> >>>> 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for >>>> 'Cacheable, write-back, write allocate'? >>> >>> No other MIPS emulation does what you suggest, which is why I refrained >>> from commenting on the K0 field and commented on the ICE/DCE bits only. >>> See: >>> >>> /* Have config1, uncached coherency */ >>> #define MIPS_CONFIG0 \ >>> ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) >>> >>> elsewhere in this file. >> >> Yes, this was just out of curiosity. Maciej, FYI I now remembered the thread that triggered this curiosity: http://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg03796.html > Also the value of this field at reset is undefined for this CPU (as is > architecturally, though some implementations might work otherwise), so 0x2 > is as good as any. For the user emulation mode we could consider choosing > what the kernel would use, however that would only matter if we had the > cache properly emulated.
On Tue, 25 Sep 2018, Philippe Mathieu-Daudé wrote: > >>>> >From the DS: > >>>> > >>>> The C790 core has the following features: > >>>> - Large on-chip caches > >>>> • Instruction cache: 32KB, 2-way set associative > >>>> • Data cache: 32KB, 2-way set-associative (with write-back protocol) > >>>> > >>>> 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for > >>>> 'Cacheable, write-back, write allocate'? > >>> > >>> No other MIPS emulation does what you suggest, which is why I refrained > >>> from commenting on the K0 field and commented on the ICE/DCE bits only. > >>> See: > >>> > >>> /* Have config1, uncached coherency */ > >>> #define MIPS_CONFIG0 \ > >>> ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) > >>> > >>> elsewhere in this file. > >> > >> Yes, this was just out of curiosity. > > Maciej, FYI I now remembered the thread that triggered this curiosity: > > http://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg03796.html Thanks for the pointer; I'm not subscribed to the QEMU mailing list these days anymore. For the record, you can achieve the same effect by using the TLB and the cache mode of the page(s) mapped, possibly with a wired entry, rather than with the physical kernel segments (KSEG0/KSEG1/XKPHYS). There's also SPRAM that uses the cache interface in some implementations (MTI 4K and M4K cores if memory serves; possibly other ones as well), that you may want to model in QEMU one day too. Maciej
Hello Maciej, > Gesendet: Freitag, 21. September 2018 um 01:51 Uhr > Von: "Maciej W. Rozycki" <macro@linux-mips.org> > An: "Philippe Mathieu-Daudé" <f4bug@amsat.org> > Cc: "Fredrik Noring" <noring@nocrew.org>, "Richard Henderson" <richard.henderson@linaro.org>, "Aleksandar Markovic" <amarkovic@wavecomp.com>, "Aurelien Jarno" <aurelien@aurel32.net>, "Petar Jovanovic" <pjovanovic@wavecomp.com>, "Peter Maydell" <peter.maydell@linaro.org>, "Jürgen Urban" <JuergenUrban@gmx.de>, qemu-devel@nongnu.org > Betreff: Re: [PATCH v5 6/8] target/mips: Define the R5900 CPU > > Hi Philippe, > > > > diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c > > > index b3320b9dc7..71fd83de06 100644 > > > --- a/target/mips/translate_init.inc.c > > > +++ b/target/mips/translate_init.inc.c > > > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > > > .insn_flags = CPU_MIPS32R5 | ASE_MSA, > > > .mmu_type = MMU_TYPE_R4000, > > > }, > > > + { > > > + .name = "R5900", > > > > What bothers me here is you are not modeling "The" unique R5900, but a > > cpu which implements the R5900 architecture. > > There was only one R5900 implementation. > > > >From the "TX7901 User’s Manual (Rev. 6.30T – Nov, 2001)": > > > > The TX7901 MIPS RISC microcontroller is a highly integrated solution > > based on Toshiba’s dual-issue super-scalar pipeline Processor Core, > > the C790 (henceforth referred to as “the C790”). > > > > C790 High-performance MIPS CPU Core on which the TX7901 is based. > > > > So the correct core name is "C790". > > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > compliant to the IEEE 754 standard for floating-point arithmetic. It > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > implement the the double format either, but that is really tangential, > because the same was the case with the IDT R4650, which had a standard > IEEE 754 FPU, but no double format either. Finally it has some anomalies > in the FP instruction set; not all opcode encodings are standard. > > No documentation has been made publicly available for the R5900; my > understanding is it was only released under NDA as a part of the PS2 SDK. > However I have been told that the only software-visible difference (except > for graphic coprocessors) between the R5900 and the C790 is the FPU, which > in the latter processor is a standard IEEE 754 implementation. The documentation is not under NDA. The only problem is the copyright of the documentation, but there was some official statement from Sarah Ewen (Sony) which makes me believe that the following website is legal, but I can't find the statement in the webarchive. https://hwdocs.webs.com/ps2 The documentation was part of the Linux Toolkit: https://en.wikipedia.org/wiki/Linux_for_PlayStation_2 The kit has 2 DVDs. One DVD contains Linux and source code. The run time environment (=boot loader), VCL and the documentation are on the other disc. Sometimes it is possible to buy it on ebay. It is legal to buy it, you don't need a NDA. The original website is down, but there is a backup: http://ps2linux.no-ip.info/playstation2-linux.com/faq.html#Availability__When_Where_and_how_much There was also the question to release the documents for free. http://ps2linux.no-ip.info/playstation2-linux.com/forum/message23e0.html?msg_id=51027 Later there was a response that all files form playstation2-linux.com would be released for free when enough money would be paid. I assume this would have included the hardware documents as there was also no problem with releasing the VCL for free. The problem was not the copyright, but Sony needs to pay their employes for packing the stuff. > So the document named is the best public reference for the R5900. Also > any emulation of the C790 will have to use a separate template. > > > > + .CP0_PRid = 0x00003800, > > > > "The implementation number of the C790 processor is 0x38". > > I'll leave the answer to what the values of PRId are for the R5900 vs the > C790 to Fredrik or Jürgen. I suspect that the difference is in the Rev > field only. According to the documentation tx79architecture.pdf the C790 has 0x3800. According to the documentation coreum_e.pdf the R5900 has 0x2Exx. xx depends on the revision. I thought that I have seen several revisions, but in my log files I found only 0x2e31. Best regards Jürgen Urban > > >From the DS: > > > > The C790 core has the following features: > > - Large on-chip caches > > • Instruction cache: 32KB, 2-way set associative > > • Data cache: 32KB, 2-way set-associative (with write-back protocol) > > > > 0x2 << CP0C0_K0 is 'Uncached', why you selected this and not 0x3 for > > 'Cacheable, write-back, write allocate'? > > No other MIPS emulation does what you suggest, which is why I refrained > from commenting on the K0 field and commented on the ICE/DCE bits only. > See: > > /* Have config1, uncached coherency */ > #define MIPS_CONFIG0 \ > ((1U << CP0C0_M) | (0x2 << CP0C0_K0)) > > elsewhere in this file. > > > > + .PABITS = 32, > > > > 20 bits PFN + 12 bits offset = 32 (Maciej, can you verify please?). > > That's what I wrote previously. > > NB the offset being 12-bit is only the minimum, depending on the PageMask > register and used for 4kiB pages only. But it is a useful simplification. > > Maciej >
Hi Jürgen, Maciej, > The original website is down, but there is a backup: > http://ps2linux.no-ip.info/playstation2-linux.com/faq.html#Availability__When_Where_and_how_much > > There was also the question to release the documents for free. > http://ps2linux.no-ip.info/playstation2-linux.com/forum/message23e0.html?msg_id=51027 Thanks, Jürgen! > > > > + .CP0_PRid = 0x00003800, > > > > > > "The implementation number of the C790 processor is 0x38". > > > > I'll leave the answer to what the values of PRId are for the R5900 vs the > > C790 to Fredrik or Jürgen. I suspect that the difference is in the Rev > > field only. > > According to the documentation tx79architecture.pdf the C790 has 0x3800. > According to the documentation coreum_e.pdf the R5900 has 0x2Exx. > xx depends on the revision. I thought that I have seen several revisions, > but in my log files I found only 0x2e31. I have verified with hardware that model SCPH-77004 is 0x2e42 whereas an older model such as SCPH-50004 is 0x2e31. Someone has made a substantial table of models at http://www.ps2-home.com/forum/app.php/page/ps2ident-database where the columns "EE implementation" and "EE revision" correspond to PRId. Fredrik
Thank you for your reviews, Philippe, > Fredrik: maybe you can simply name the C790 in the comment pointing to > the DS documentation. Sure, I will do that for v6! I am also adding some of Maciej's notes on the differences between the C790 and the R5900, along with PRId 0X2E00 as noted by Jürgen: { /* * The Toshiba TX System RISC TX79 Core Architecture manual * * http://www.lukasz.dk/files/tx79architecture.pdf * * describes the C790 processor which is a follow-up to the R5900. * There are a few notable differences in that the R5900 FPU * * - is not fully IEEE 754-1985 compliant, * - does not implement double format, and * - its machine code is nonstandard. */ .name = "R5900", .CP0_PRid = 0x00002E00, > Fredrik, except the linux-user part for kernel FPU emulation that I > don't feel confident to review, the rest of this patch looks OK to me: > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Would you rather have an acked-by as a less formal "looks good to me" tag? I anticipate significant changes to the notes and commit messages in v6, so all previous tags ought to be reset for that reason, I think. Fredrik
On Thu, Sep 27, 2018 at 7:11 PM Fredrik Noring <noring@nocrew.org> wrote: > > Thank you for your reviews, Philippe, > > > Fredrik: maybe you can simply name the C790 in the comment pointing to > > the DS documentation. > > Sure, I will do that for v6! I am also adding some of Maciej's notes on the > differences between the C790 and the R5900, along with PRId 0X2E00 as noted > by Jürgen: > > { > /* > * The Toshiba TX System RISC TX79 Core Architecture manual > * > * http://www.lukasz.dk/files/tx79architecture.pdf > * > * describes the C790 processor which is a follow-up to the R5900. > * There are a few notable differences in that the R5900 FPU > * > * - is not fully IEEE 754-1985 compliant, > * - does not implement double format, and > * - its machine code is nonstandard. > */ > .name = "R5900", > .CP0_PRid = 0x00002E00, > > > Fredrik, except the linux-user part for kernel FPU emulation that I > > don't feel confident to review, the rest of this patch looks OK to me: > > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> > > Would you rather have an acked-by as a less formal "looks good to me" tag? QEMU 'Acked-by' means "I'm the maintainer for this area and I haven't actually reviewed this but I don't object to it" as I learned here :) https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02186.html > I anticipate significant changes to the notes and commit messages in v6, > so all previous tags ought to be reset for that reason, I think. Just reset, I'm happy to review this series. Regards, Phil.
Hi Maciej, > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > compliant to the IEEE 754 standard for floating-point arithmetic. It > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > implement the the double format either, but that is really tangential, > because the same was the case with the IDT R4650, which had a standard > IEEE 754 FPU, but no double format either. Finally it has some anomalies > in the FP instruction set; not all opcode encodings are standard. Do you know where one might find a list of the nonstandard FP instructions? The command % grep 'FP_.*EE' binutils/opcodes/mips-opc.c gives a list of candidates, I suppose? Fredrik
Hi Fredrik, > > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > > compliant to the IEEE 754 standard for floating-point arithmetic. It > > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > > implement the the double format either, but that is really tangential, > > because the same was the case with the IDT R4650, which had a standard > > IEEE 754 FPU, but no double format either. Finally it has some anomalies > > in the FP instruction set; not all opcode encodings are standard. > > Do you know where one might find a list of the nonstandard FP instructions? > > The command > > % grep 'FP_.*EE' binutils/opcodes/mips-opc.c > > gives a list of candidates, I suppose? Yeah, those that have EE in `membership' are extra and those that have EE in `exclusions' are missing. See also: <https://sourceware.org/ml/binutils/2012-11/msg00360.html>. Maciej
diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c index b3320b9dc7..71fd83de06 100644 --- a/target/mips/translate_init.inc.c +++ b/target/mips/translate_init.inc.c @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = .insn_flags = CPU_MIPS32R5 | ASE_MSA, .mmu_type = MMU_TYPE_R4000, }, + { + .name = "R5900", + .CP0_PRid = 0x00003800, + /* No L2 cache, icache size 32k, dcache size 32k, uncached coherency. */ + .CP0_Config0 = (0x3 << 9) | (0x3 << 6) | (0x2 << CP0C0_K0), + .CP0_Status_rw_bitmask = 0xF4C79C1F, +#ifdef CONFIG_USER_ONLY + /* + * R5900 hardware traps to the Linux kernel for IEEE 754-1985 and LL/SC + * emulation. For user only, QEMU is the kernel, so we emulate the traps + * by simply emulating the instructions directly. + * + * Note: Config1 is only used internally, the R5900 has only Config0. + */ + .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU), + .CP0_LLAddr_rw_bitmask = 0xFFFFFFFF, + .CP0_LLAddr_shift = 4, + .CP1_fcr0 = (0x38 << FCR0_PRID) | (0x0 << FCR0_REV), + .CP1_fcr31 = 0, + .CP1_fcr31_rw_bitmask = 0x0183FFFF, +#else + /* + * The R5900 COP1 FPU implements single-precision floating-point + * operations but is not entirely IEEE 754-1985 compatible. In + * particular, + * + * - NaN (not a number) and plus/minus infinities are not supported; + * - exception mechanisms are not fully supported; + * - denormalized numbers are not supported; + * - rounding towards nearest and plus/minus infinities are not supported; + * - computed results usually differs in the least significant bit; + * - saturating instructions can differ more than the least significant bit. + * + * Since only rounding towards zero is supported, the two least + * significant bits of FCR31 are hardwired to 01. + * + * FPU emulation is disabled here until it is implemented. + * + * Note: Config1 is only used internally, the R5900 has only Config0. + */ + .CP0_Config1 = (47 << CP0C1_MMU), +#endif /* !CONFIG_USER_ONLY */ + .SEGBITS = 32, + .PABITS = 32, + .insn_flags = CPU_R5900, + .mmu_type = MMU_TYPE_R4000, + }, { /* A generic CPU supporting MIPS32 Release 6 ISA. FIXME: Support IEEE 754-2008 FP.
The primary purpose of this change is to support programs compiled by GCC for the R5900 target and thereby run R5900 Linux distributions, for example Gentoo. In particular, this avoids issues with cross compilation. This change has been tested with Gentoo compiled for R5900, including native compilation of several packages under QEMU. Signed-off-by: Fredrik Noring <noring@nocrew.org> --- target/mips/translate_init.inc.c | 47 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)