This page contains information about the projects.
For students who only have access to machines with processors that are not compatible with the Intel x86 processor, including Mac M1 machines, see below for information about how to use university resources to access a development environment.
guest123
to log in.
If you are interested in accessing files from both your host machine and the Linux virtual machine in VirtualBox, check out the following links for information on how to set up shared folders.
This is recommended only for students who do not have access to an Intel x86 compatible machine. One such case is students who own Mac/Silicon's, and who do not have access to an Intel-compatible machine. (If you have a Mac/Silicon, it may be more convenient to install the development environment natively on your machine instead of using the university-provided environment. See below for step-by-step instructions to install the development environment on MacOS.)
Access to a pre-configured virtual development environment can be done through VMware Horizon Client. A description of how to install the Horizon Client and access the development environment can be found here (Links to an external site.). The guide also contains information of how to share files and other functionalities.
csce410
and the same
password as the one listed above for for the virtual box image.
Note that these virtual machines are not persistent! If a user logs out, or disconnects for more than a day, the virtual machine will be destroyed and recreated. This means that you lose all your files stored on the virtual machine. Files can be transferred between a user's computer and the box as long as they are using the VMware Horizon Client (as opposed to the web client). Alternatively, users can download/upload files to any cloud storage (e.g. Google Drive, Github). This is a great incentive to use GitHub!!
We have good news for Mac/Silicon users! If you don't want to use the University provided development environment (which is -- admittedly -- a pain to use) see below for information about how to set up the development environment natively on your Mac.
Kudos to Caleb Norton, a student in a previous semester, who found and described the following procedure to set up the development environment on Silicon Macs:
We have tested out the steps described below. If you're following along and something doesn't work, post a new reply and we can investigate.
https://brew.sh/
) Follow the directions to set up your macOS Xcode tools as well, if needed.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"Step 2: install nasm, qemu, and bochs
brew install nasm qemu bochsStep 3: add i386 toolchain formulae
brew tap nativeos/i386-elf-toolchainStep 4. install i386-elf-binutils and i386-elf-gcc
brew install i386-elf-binutils i386-elf-gcc
Note that some of these steps take quite a while. You may want to grab a coffee...
Now you should be able to type make
to generate the binary for the kernel.
Type make clean
to delete all binaries and object files.
The provided shell script copykernel.sh
copies the kernel binary onto an image of a bootable floppy drive (anybody remembers floppy drives?). For this, the script first mounts the image as a floppy, then copies the binary onto the floppy, and then unmounts the image again. Now you tell bochs to boot off the floppy, which contains the bootloader and the kernel binary.
The script copykernel.sh provided with the MP source code has been developed for Linux and does not work on MacOS!
If you use the native development environment on a Mac, use the following script instead (again, kudos to Caleb Norton!):
mkdir ./floppy hdiutil attach dev_kernel_grub.img -mountpoint ./floppy cp kernel.elf ./floppy sleep 1 hdiutil detach ./floppy rmdir ./floppy
On the Mac you will need to configure bochs to open a bochs console. You do this by adding a line to the bochsrc.bxrc configuration file as described here:
#display_library: wx # other choices: win32 sdl wx carbon amigaos beos macintosh nogui rfb term svga # ADD THE FOLLOWING LINE FOR MAXOS: display_library: sdl2
Executing bochs on MacOS is slightly cumbersome.
You start bochs in the same fashion as on Linux:
bochs -f bochsrc.bxrc
Once you have started bocks, you will to type "6" for the emulation to start. The execution of bochs then seems to hang; you need to type "c" for "continue".
Now you should see the console of a booting x86 machine!
We will be testing the kernels by using them to boot a virtual machine. The preferable environment for this is Bochs. You are free to use other virtual-machine environments. We prefer Bochs because it is light-weight (albeit maybe slow) and because it emulates the hardware very accurately.
Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS. Bochs can be compiled to emulate many different x86 CPUs, from early 386 to the most recent x86-64 Intel and AMD processors, even those not in the market yet.
Additional information about how to use Bochs in this project, and how to set it
up to support debugging using gdb
, can be found in the
following documents:
gdb
can be found in document
The Bochs Environment.
gdb
is Integrating Bochs
Environment with GDB
gdb
is
this one.
Note that, since there are several slightly different ways to integrate gdb with Bochs, the TA and instructor won't be able to be helpful in debugging your installation. If you plan to add debugging support, you will be on your own.
The use of a version control system like github is beneficial in many ways. For example, the history of your git actions is a documentation of your development process. As you work on an MP and develop code, you commit new versions of files. If you diligently do that, with meaningful explanations in your commit messages, this naturally documents the development of your code. Commit frequently! Introducing lots of code and lots of changes in a single git action is not, in general, a good software practice. Working with github has other benefits. For example, if the project submission system on Canvas is not working, you won’t need to sweat about proving that you finished the project within the deadline: the git history will prove that you had concluded it. Finally, a good github commit record will be helpful in the unlikely case that you need to prove that you developed your code without violating the Aggie Honor Code.
make: Nothing to be
done for 'all'
, do a make clean
, followed by
make
.
.img
file makes it available as a
drive. If you copy/modify files in this drive, you are updating the
corresponding .img
file.
Think of the parallel as a floppy drive. The .img
is
the floppy disk. Inserting the floppy disk into the drive is performed
by mounting the image (.img
file). Now you can
make changes to the drive. (This changes the contents of the
.img
file) When you are done making changes, you remove
the floppy disk by unmounting the image (.img
file)
-fno-asynchronous-unwind-tables
option in the makefile. Check out documentation for details.
Other students have had success by changing the linking command in the makefile, from
ld -m elf_i386 ...to
ld -m i386linux ...
mount: mount point /mnt/floppy does not exists cp: cannot create a regular file '/mnt/floppy/': Not a directory umount: /mnt/floppy: mountpoint not found
mkdir /mnt/floppyThen run
kopykernel.sh
int mask[] = {128, 64, 32, 16, 8, 4, 2, 1};Error:
cont_frame_pool.o: In function `__static_initialization_and_destruction_0': /usr/include/c++/4.8/iostream:74: undefined reference to `__ZNSt8ios_base4InitC1Ev' /usr/include/c++/4.8/iostream:74: undefined reference to `___dso_handle' /usr/include/c++/4.8/iostream:74: undefined reference to `__ZNSt8ios_base4InitD1Ev' /usr/include/c++/4.8/iostream:74: undefined reference to `___cxa_atexit'A: You are probably including
iostream
in your code. This
makes for some exciting linking. Remember that we are on an island!
Filesystem type is fat, using whole disk /kernel.bin Error 15: File not found
(gdb) b main() Function "main()" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b kernel.C:35 No symbol table is loaded. Use the "file" command. Make breakpoint pending on future shared library load? (y or [n])I have modified the makefile and compiled it again to generate the
kernel.elf
file.
Is there anything I am missing here???
gdb kernel.elfThen once you are in gdb, you can connect to the port and whatnot. Alternatively, after starting gdb and before targeting the remote port, you can type the command:
file kernel.elfThis has the same effect as sending the filename as a parameter when starting gdb.
sudo ./copykernel
I get an error:
is not a directory/mnt/floppy sleep : invalid time interval '1s\r' Try sleep -- help for more information : not mountedfloppyWhat does that mean?
printf()
and my program does not link!
printf()
. This function is part of a library that we don't have access to. Use Console::puts
and Console::puti
instead.
assert()
does not work!
a
and b
are different, but
assert(a=b);does not throw an assertion error.
a=b
does not compare a and b! Instead, it assigns the value of b
to a
. This always succeeds. Instead, use the statement
assert(a==b);
port_e9_hack: enabled=1
0xe9
:
Machine::outportb(0xe9, 'H'); Machine::outportb(0xe9, 'e'); Machine::outportb(0xe9, 'l'); Machine::outportb(0xe9, 'l'); Machine::outportb(0xe9, 'o'); Machine::outportb(0xe9, '\n');
$ bochs -f bochsrc.bxrc > myoutput.txt
http://bochs.sourceforge.net/doc/docbook/user/bochsrc.html