WebSVN – HelenOS-doc – Diff – /prjdoc/trunk/tools/tools.tex

 \begin{description}
 \item [Chora] is a part of the Horde framework and can be used to comfortably
 browse Subversion repository from the web. We altered it a little bit to also
 show number of commits per developer on our homepage.
-\item [WHUPS] is another component of the Horde framework. It provides
+\item [Whups] is another component of the Horde framework. It provides
 feature request and bug tracking features. However, in the light of being rather
 closed group of people, we used this tool only seldomly. On the other hand,
 any possible beta tester of our operating system has had a chance to
 submit bug reports.
 \section{Virtual environments}
 After the build tools, simulators, emulators and virtualizers were the second focal point
 in our project. These invaluable programs really sped the code-compile-test cycle.
 In some cases, they were, and still are, the only option to actually run HelenOS on certain
 processor architectures, because real hardware was not available to us. Using virtual environment
-for developing our system provided us with deterministic environment on wich it is much easier to do
+for developing our system provided us with deterministic environment on which it is much easier to do
 troubleshooting. Moreover, part of the simulators featured integrated debugging facilities.
 Without them, a lot of bugs would remain unresolved or even go unnoticed.
 From one point of view, we have tested our system on eight different virtual environments:
 portable, compared to much faster virtualizers and emulators using dynamic translation
 of instructions. Lately, there have been some plans to develop or port dynamic translation
 to Bochs brewing in its developer community.
 The biggest virtue of Bochs is that it has traditionally supported SMP. For some time, Bochs
-has been our only environment on wich we could develop and test SMP code. Unfortunatelly,
+has been our only environment on which we could develop and test SMP code. Unfortunatelly,
 the quality of SMP support in Bochs was different from version to version. Because of SMP
 breakage in Bochs, we had to avoid some versions thereof. So far, Bochs versions 2.2.1 and 2.2.6
 have been best in this regard.
 Our project has not only used Bochs. We also helped to identify some SMP related problems
 Curiously, this simulator contained the biggest number of defects and inaccuracies
 that we have ever discovered in a simulator.  Fortunately, all of them have been
 eventually fixed.
 \subsection{PearPC}
-PearPC is the only emulator on wich we have run ppc32 port of HelenOS. It has
+PearPC is the only emulator on which we have run ppc32 port of HelenOS. It has
 no debugging features, but fortunatelly its sources are available under
 an open source license. This enabled {\OP} and {\MD} to alter its sources
 in a way that this modified version allowed some basic debugging.
 \subsection{QEMU}
 This emulator seemed to realistically emulate the {\tt hlt} instruction,
 which was nice for those of us who use notebooks as their development
 machine.
 \subsection{Simics}
-Simics simulator can be compared to a Swiss-army knife for operating system debugging.
+Virtutech's Simics simulator can be compared to a Swiss-army knife for operating system debugging.
 This proprietary piece of software was available to us under an academic license for free.
 Simics can be set to simulate many different configurations of many different machines.
 It has the most advanced debugging features we have ever seen. To highlight some, its
 memory access tracing ability has been really helpfull to us. During device driver
 during application processors start. Another bugs found were related to amd64 and mips32.
 As for amd64, Simics did not report general protection fault when {\tt EFER.NXE} was 0 and a non-executable
 page was found (\#4214). As for mips32, Simics misemulated {\tt MSUB} and {\tt MSUBU} instructions.
 \subsection{Ski}
+The ia64 port of HelenOS has been developed and debugged on the HP's IA-64 Ski simulator.
+Ski is just an Itanium processor simulator and as such does not simulate a real machine. In fact, there
+is no firmware and no configuration tables (e.g. memory map) present in Ski! On the other hand, the missing parts can be supplied externally\footnote{This
+is actually how Linux runs in this simulator.}. The simulator provides means of interaction with
+host system devices via Simulator SystemCalls (SSC). The simulator itself has graphical interface
+with pretty powerful, but not as good as those of Simics, debugging facilities.
+Ski is a proprietary program with no source code available. Its binaries are available
+for free under a non-free license. It comes packaged with insufficient documentation
+which makes the development pretty problematic. For instance, there is no public documentation
+of all the SSC's. All one can do is to look into Linux/ia64-Ski port, which was written by the
+same people as Ski, and use it as a refernce. We had to look into Linux once more when our kernel
+started to fail in some memory-intensive stress tests. In fact, the problem was that the tests
+hit the IA-32 legacy videoram area. We fixed the problem, in the light of absence of any memory map, by blacklisting
+this piece of memory to our frame allocator.
+The way HelenOS is booted on Ski is by simply loading its ELF image
+and jumping to it. The ELF header contains two fields describing where and how to load the program image into memory:
+VMA and LMA. VMA\footnote{Virtual Memory Address} is an address where the program's segment gets mapped in virtual memory.
+LMA\footnote{Load Memory Address} is the physical address where the segment is loaded in memory. {\JV} discovered
+that Ski confuses VMA and LMA. This, what we believe to be a bug in Ski, has not shown in Linux since Linux always has
+LMA equal to VMA. People from the Ski mailing list had tried to help us but our repeated problem report didn't
+make it far enough for the HP to fix or at least clarify the issue. Finally, we adopted a workaround implemented by {\JJ}
+that simply swaps LMA and the program entry point in the kernel ELF image.
 \subsection{VMware}
+VMware is the only virtualizer we have used in HelenOS development. It virtualizes the ia32 host machine.
+Since VMware version 5.5, we made use of its possibility to run the guest system (i.e. HelenOS) on multiple processors.
+VMware has no support for debugging but is very useful for compatibility and regression testing because
+it's closest to the real hardware. VMware, being a virtualizer, is also the fastest of all the virtual environments
+we have utilized.
 \section{Authoring tools}

Subversion Repositories HelenOS-doc

(root)/prjdoc/trunk/tools/tools.tex – Rev 32 → 33