On 08/19/2014 08:50 PM, Mark Cave-Ayland wrote: > On 19/08/14 16:21, Jakub Jermar wrote: >> On 17.8.2014 18:16, Mark Cave-Ayland wrote: >>> Another issue I've found with my OpenBIOS tests is that HelenOS PPC >>> appears to be quite sluggish under the latest qemu-system-ppc. I've >>> attempted a few bisections but it's quite tricky to tie the regression >>> down to one particular commit. >>> >>> The slowness starts to appear in a minor form with the 1.6 timer rewrite >>> and seems to have become worse with newer QEMU releases. There have been >>> various changes to the OpenBIOS frequency/tb-frequency properties in >>> order to support OS X PPC in this timeframe so I'm wondering if somehow >>> HelenOS is exposing a bug in the qemu-system-ppc timer emulation? >>> >>> In order to reproduce, grab a QEMU 2.1 release tarball, compile and >>> install and then launch like this: >>> >>> qemu-system-ppc -cdrom HelenOS-0.5.0-ppc32.iso -m 512 -boot d >>> >>> As soon as the main kernel executes you can see the delay in writing >>> characters to the VGA console. >> >> I also noticed that as of QEMU 2.0, HelenOS/ppc32 under QEMU became >> quite slow. >> >> Now, I am not a ppc32 expert either, but I suspect that the problem is >> related to the way HelenOS programs the decrementer exception. It always >> does so using the instruction below: >> >> mtdec reg ; reg = 1000 >> >> So we always use constant 1000, regardless of what the real frequency >> property is. I guess this is a constant which used to work reasonably >> well under PearPC back then and has stayed ever since. *Martin*, correct >> me if I am wrong, please. Btw, was the actual frequency increased? That >> could explain why HelenOS/ppc32 became slower - with more exceptions >> you'd have bigger overhead. > > Ah possibly that could be it. The file history with the relevant changes > in QEMU for -M g3beige (the default) can found at > http://git.qemu.org/?p=qemu.git;a=history;f=hw/ppc/mac_oldworld.c;h=cd9bdbc53e92f423a329ecce7de1df9244a5eb0b;hb=0e4a77370594c91dd126f9872893ed473374cc72. > In particular you probably want to look at these commits: > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a1014f25ef54bbbdaf571873a1254f85d6dcf132 > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=536d8cda4adef3d202a800688ed5f63dae1f0f88 > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9d1c128341df7a303571f172d986291b4f3ed9ee > > > With the latest QEMU tree, all of the timebase frequency, clock > frequency and bus frequency are generated by QEMU and then passed to > OpenBIOS which creates the relevant device tree properties for the CPU > node: > > build@kentang:~/rel-qemu-git/bin$ ./qemu-system-ppc -nographic -prom-env > 'auto-boot?=false' > > >>> ============================================================= >>> OpenBIOS 1.1 [Jun 20 2014 22:58] >>> Configuration device id QEMU version 1 machine id 2 >>> CPUs: 1 >>> Memory: 128M >>> UUID: 00000000-0000-0000-0000-000000000000 >>> CPU type PowerPC,750 > milliseconds isn't unique. > Welcome to OpenBIOS v1.1 built on Jun 20 2014 22:58 > > 0 > cd /cpus/PowerPC,750 ok > 0 > .properties > name "PowerPC,750" > device_type "cpu" > cpu-version 80301 > d-cache-size 8000 > i-cache-size 8000 > d-cache-sets 80 > i-cache-sets 80 > d-cache-block-size 20 > i-cache-block-size 20 > tlb-sets 40 > tlb-size 80 > timebase-frequency fd4bc0 > clock-frequency fdad680 > bus-frequency 3ef1480 > state "running" > reg 00000000 > available 00004000 07c54000 > 07e10000 f80f0000 > 00000000 ffffffff > translations 00001000 00003000 00001000 00000000 > 07c58000 001b8000 07c58000 00000000 > fff00000 00100000 07f00000 00000000 > ok > > > I'm not exactly sure how these frequencies affect the decrementer, but > it's enough to break OS X if these frequencies (particularly timebase > and clock) are not correct.
The clock-frequency is most likely a frequency with which the decrementer is decremented. So in this case, it looks like it is decremented 266.000.000 times per second. In other words, the frequency is 266MHz. Indeed, setting the decrementer to the intended value of 266MHz / HZ, where HZ in HelenOS is 100, the system appears to boot much faster and is also somewhat more responsive. It still can be considered slow, because, AFAIR, we are using softfloats for drawing the GUI on ppc32. It seems to me like a good idea to get the value for the decrementer from the clock-frequency property. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
