Postagens

Mostrando postagens de abril, 2018

Basics on ARM processor

Imagem
I am also teaching "Laboratory of Microprocessors" focusing ARM. I use  ARM Lab Manual  for the first experiences.  I have been asking students to install a tool chain in ubuntu to develop experiments in the simulator provided by arm-...-gdb. Last year, one team made everything as the docker image: https://github.com/EpicEric/gcc-arm.git In order to use it:  git clone https://github.com/EpicEric/gcc-arm.git See README.md  cd gcc-arm/ ./build_docker.sh emacs # any other editor that you prefer; perhaps, you will need sudo,and perhaps gedit suchs as:                sudo ./build_docker.sh gedit docker run --rm -ti -v "$PWD/src":/home/student/src epiceric/gcc-arm Note that your directory $PWD/src is attached to /home/student/src. In this docker image, we have 2 tool-chains: arm-elf and arm-none-eabi. In the first part of the course, we are using arm-elf. We will use arm-none-eabi to deal with the versatille board, emulated by qemu. The environment contai

Assignments - 1

Imagem
My Operating System course has, generally, 4 to 5 assignments corresponding to each chapter of the book: " Operating Systems Design and Implementation, Third Edition ", i.e., 1. Introduction, 2. Processes, 3. Input and Output, 4. Memory and 5. File Systems. For the first assignment, I ask students to implement a simple system call. Generally, I divide the class into 10 teams which are given 10 different tasks. General Instructions to the First Assignment A system call makes a software interrupt. All teams must install docker and Shibata's work, visualize the switch from user to kernel mode following:  http://linux-kernel-lab.blogspot.com.br/2018/04/arm-linux-kernel-on-docker-image-with.html http://linux-kernel-lab.blogspot.com.br/2018/04/first-run.html http://linux-kernel-lab.blogspot.com.br/2018/04/first-init.html http://linux-kernel-lab.blogspot.com.br/2018/04/rebuilding-new-docker-image.html http://linux-kernel-lab.blogspot.com.br/2018/04/creating-new-te

From user to kernel mode, step by step

Imagem
Now that we have a very silly system call (sys_hello_world), let us see how it is called, step by step, monitoring the processor mode. We may put breakpoint at sys_hello_world and run it step by step (using s or n). You must try it. The big problem is that gdb is looking to the kernel source code while init is running in user mode. We can not debug init using gdb. Thus, we will make a trick, that is, we will get an address of some instruction to be executed by init. Run the gdb till this instruction, disassembly running step by step utll find the svc instruction that makes the software interrupt. At this moment, we leave the user mode and go to the kernel mode. To get an address inside init, we do: student@a3974e81f3d7:~/src/initramfs/build/initramfs_root$ arm-linux-gnueabi-nm  init  in particular, hello_world: $ arm-linux-gnueabi-nm  init|grep hello_world  000105b4 T hello_world Now, as usual, in one terminal make qemu ... -s -S runs and in another Connect via gdb to qem

The system call "Hello World"

In our docker image, we have a system call that prints "Hello World"  from the kernel space. Its code is in: ~/Downloads/pcs3746-sistemas-operacionais/1/linux/sys_hello_world$ ls built-in.o  Makefile  modules.builtin  modules.order  sys_hello_world.c  sys_hello_world.o Modify it: change the string to print. That is your first modification in a kernel! Make init.c as in: ~/Downloads/pcs3746-sistemas-operacionais/1/initramfs$ more init.c #include "hello_world.h" int main() {    while (1) {       hello_world();    }    return 0; } This will make a lot of messages from the kernel in your terminal. When you run it through: ~/Downloads/pcs3746-sistemas-operacionais/1$ ./run.sh  the kernel and rootfs are remade.

2. run gdb

So far you must have two terminals on your docker container: One that shows the output of qemu ... -s -S One that is in a bash. See that you can give commands such as: ls, cd, etc.  You see something like this: $ docker exec -ti upbeat_khorana bash root@db40c62a2c8d:/# su student To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. student@db40c62a2c8d:/$ alias alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"' alias egrep='egrep --color=auto' alias fgrep='fgrep --color=auto' alias gdb='arm-none-eabi-gdb -ex '\''target remote:1234'\'' /home/student/src/linux/vmlinux' alias grep='grep --color=auto' alias l='ls -CF' alias la='ls

1. Open a new terminal to your docker container

You run the docker image as in: ~/Downloads/pcs3746-sistemas-operacionais/1$ ./run.sh In your ubuntu, do: docker ps, as in: ~/Downloads/pcs3746-sistemas-operacionais/1$ docker ps CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS               NAMES ded8427efd96        tiagoshibata/pcs3746   "/entrypoint.sh /def…"   5 hours ago         Up 5 hours                              focused_swartz You may see that we have the docker image tiagoshibata running on a docker container with ID ded8427efd96. It running for 5 hours and it has an image name blessed by docker: focused_swartz. Now, you may open another terminal and enter again in the docker container. Do: ~/Downloads/pcs3746-sistemas-operacionais/1$ docker exec -ti focused_swartz bash Note that you must insert the name given by "docker ps" and not necessarily focused_swartz. ~/Downloads/pcs3746-sistemas-operacionais/1$ docker exec -ti fo

Second run: qemu+gdb

In you ubuntu (not inside docker), you may see something like this: ~/Downloads/pcs3746-sistemas-operacionais/1/docker$ ls default_cmd1.sh  default_cmd1.sh~  default_cmd.sh*  default_cmd.sh.1*  Dockerfile  Dockerfile.1  entrypoint.sh*  initramfs/  linux/  src/ Open the Dockerfile. At the end you see: CMD ["/default_cmd.sh"] It means that after the docker will run default_cmd at last. Let us see this default_cmd: Basically it compiles what has to be compiled about the ARM linux kernel and boots it by qemu. The last line is: qemu-system-arm -M versatilepb -m 128M -nographic -kernel $BOOT/zImage -dtb $BOOT/dts/versatile-pb.dtb -initrd build/rootfs.gz -append "root=/dev/ram"  This last line makes qemu runs alone, with no gdb. To make it stops and waits for the gdb connection, you do add -s and -S at the end of the line to make a connection via socket at port 1234 and to Stop waiting for the connection: qemu-system-arm -M versatilepb -m 128M -nographic -ker

First init

Let us create the process init. It will print "hello world" as you would normally do, that is, init is a user process printing "hello world"  in user mode. Let us make our ARM Linux runs this init process: #include <stdio.h> int main () { while (1) { printf ( "Hello, World; from user!\n" ); } return 0 ; } Do something like this: Save what Shibata's team have done for future study: ~/Downloads/pcs3746-sistemas-operacionais/1/initramfs$ cp init.c init.c.1 edit init.c ~/Downloads/pcs3746-sistemas-operacionais/1/initramfs$ emacs init.c I like emacs to edit files, but you may choose vim, nano, etc. Make init.c contains the code above. Now, just do: ~/Downloads/pcs3746-sistemas-operacionais/1$ ./run.sh The Linux source code will be compiled if it has too, the init.c will be compiled and inserted into rootfs thanks to default_cmd.sh that will make everything automatically. That's it! You g

First Run!

In order to run the docker image, you will simply do: ~/Downloads/pcs3746-sistemas-operacionais/1$ ./run.sh You will see a lot of messages corresponding to the code in init.c. run.sh put the docker image to run as in: docker run -ti --rm -v "$PWD/linux":/home/student/src/linux -v "$PWD/initramfs":/home/student/src/initramfs tiagoshibata/pcs3746 The  -v "$PWD/linux":/home/student/src/linux  means: it attaches the $PWD/Linux that is in your machine to  /home/student/src/linux inside the docker container where $PWD means the working directory. In our case:  ~/Downloads/pcs3746-sistemas-operacionais/1 This attachment is really very important because it is how you communicate with the docker. It means that a docker image may write something in   /home/student/src/linux and you get it on  ~/Downloads/pcs3746-sistemas-operacionais/1/linux.  The same goes to the initramfs. This docker image raises ubuntu 16.4, makes the linux kernel, makes the rootfs

Arm Linux Kernel on docker image with qemu and tool chains - building

I am used to ask for 4 to 5 assignments in the Operating Systems course - PCS3746. Last year, it was four. My former student Tiago Shibata put the work of his team on: https://github.com/tiagoshibata/pcs3746-sistemas-operacionais He did not provide much documentation. I will do it. This links points to the source code necessary to build a docker image. A docker image is some kind of light virtual machine where you insert everything you need and nothing more. In a normal virtual machine, you would install ubuntu with X windows, Unity, and a lot of stuff that is not related to what we want: an ARM Linux kernel. Besides, a normal virtual machine, it emulates the hardware, I/O (clock, hard disk, etc.), BIOS, etc. while a docker image makes use of the Linux system calls. So, a docker image consumes much less resource than a real virtual machine. In order to run a docker image, you can: download the image and run it. download the image source, build and run it. As I will ask to m

Hello World!

My name is Jorge Kinoshita. I teach Operating Systems at "Escola Politecnica da Universidade de Sao Paulo". I am really grateful to be assigned to this discipline. I have been teaching it for well more than a decade. I have always thought that every student should put his hands on the source code of a particular kernel in order to grasp some concepts, similar to what happens when learning how to program. It is necessary a specific language as well as a specific kernel. Today it is easy to find source code kernels, but it was not so, some time ago. A veteran is Minix, the father of Linux. I used Minix for many years. Minix was developed by Tanenbaum and his students at Holland around 1980 decade. He used a compiler made by them. It is a micro kernel operating system; that means running just few code in kernel mode and lots of code in user mode when attending to system calls. Linus Torvalds was a student in Filland in 1991. For sure, Torvalds read a lot of Tanenbaum's b