About this lab. Lab course Operating Systems. Study achievment. Goal Develop an own operating system... from the first code line on...

Transcription

1 About this lab Lab course Operating Systems Mario Haustein Chemnitz University of Technology The typical lab course Well defined problem statement Deterministic solutions Stable environment This lab course: Much detail work Poor effort to credit point relation Many possible solution Great insight into operating systems Goal Develop an own operating system from the first code line on... on bare metal 1 / 18 2 / 18 Study achievment Prerequisite Well-founded knowledge about achitecture and functionality of operating systems (at least foundation course operating systems) Basic knowledge in computer architecture (pipelining, caching, memory hierarchy,... ) Solid C programming (C++, C#, Java,... does not suffice) Basic knowledge in assembler programming Ability and willingness to read and comprehend extensive technical documentations Engagement Sufficient resistance to frustration (maybe) Voluntary participation generally possible Successful completion of the course: D-F: Praktikum D-AF: Systementwurfspraktikum Successful completion + student research paper (approx. 10 pages): 1 B-F (2007): F3.23 Praktikum Echtzeitprogrammierung B-F (2010): Praktikum ESS B-AF (2006): M20 Teamorientiertes Praktikum B-AF ( 2009): Teamorientiertes Praktikum Master: Seminar (as far as thematically suitable) 1 Detailed explanation of the solution of one problem complex defined by the supervisor. 3 / 18 4 / 18

2 Procedure Experimental environment The hardware System on a Chip Common Meeting: Discussing the problem definition ( 20 minutes) Contains processor core and periphery 2 weeks processing time for every complex task /O (subset) Extended to 3 weeks, if task proves too complex Processing of the tasks by oneself or by group (up to two team members) As required: consultation after one week Discussing the approach to a solution briefly Submission of the solution to the supervisor via electronic mail Afterwards publication of a sample solution 5 / 18 LCD LEDs Buzzer Reset-Button Memmory Power supply Processor May be used as basis for further problems Furthermore USART USB-Host USB-Target Ethernet Architecture: ARM nstruction set: ARMv4 Family: ARM9 Core: ARM920T Chip: AT91RM / 18 Experimental environment The rest We provide you a prepared development environment for Virtual Box2 Supervisor rights = You may do everything, even damage You have not to start from scratch... Toolchain for the target architecture ARM emulator Makefile + Linker-Script Bootloader You can alter it in any way You may adapt the environment to your needs There is no backup, unless you create one Login Normal user: user, Password: bsprakt Superuser: root, Password: bsprakt / 18 8 / 18

3 Software Setup USB-RS232-converter Operating System: Gentoo Linux Text editors: Vim, gvim, Emacs, bluefish Window managers: LXDE, i3, openbox, fluxbox, icewm Compiler-Toolchain + Debugger Serial line terminal: minicom, C-Kermit Revision Control System: Subversion, Git, Mercurial ARM emulator (QEMU) Hardware-Debugger (J-Link) Disassembler (htedit) Firefox, Thunderbird... RS232-adapter RS232-1 ETH /dev/ttyusb0 enp0s8 9 / / 18 Toolchain Makefile $ arm -none -eabi - gcc -g -Wall -Wextra -fno - hosted \ -fno -zero - initialized -in - bss -c \ -o Objekt-File C-File $... $ arm - none - eabi - as -- warn -o Objekt-File Assembler-File $... $ arm -none -eabi -ld -L/ usr /arm -none - eabi / lib -Tlink. lds \ -o image. img Objekt-Files \ arm -none -eabi - gcc -print - libgcc -file -name The provided makefile will save you from entering all commands Furthermore: make install = Copy boot image to the TFTP server make qemu = Starts QEMU make jlink = Starts the J-Link hardware debugger make gdb = Starts GDB $ arm -none -eabi - objcopy image. img - Obinary image. bin $ mkimage -A arm -O linux -T kernel -C none -a 0 x \ -e 0 x d image. bin boot. bin 11 / / 18

4 Booting GDB 1. Open a serial terminal ( baud, 8N1, no flow control) 2. After power on the bootloader (U-Boot) will start 3. P adress and boot data is obtained via DHCP 4. Loading boot.bin from the TFTP server to RAM. 5. Defalting the boot image to address 0x (see mkimage). 6. Branch to 0x (see mkimage). /var/lib/tftp/ on the workstation is the root directory of the TFTP server make install copies the boot image to this directory Frontend to the emulators Because the code cannot be executed at the host system, GDB must be connected to an appropriate target. ( gdb ) target remote : TCP-Port # Connecting 0 x in START () ( gdb ) layout asm # Show assembler code ( gdb ) layout src # Show source code ( gdb ) layout regs # Show / Hide register bank ( gdb ) fs cmd # Set focus to command line ( gdb ) info registers # Print register bank 13 / / 18 QEMU Emulates the target platform Caution: The behaviour of the emulator may differ slightly from the real platform. 1. Starting QEMU: $ qemu - system - arm -M portux920t - nographic - kernel \ image. img -s -S 2. Starting GDB: ( gdb ) target remote : Exiting QEMU: Ctrl + A X QEMU online help: Ctrl + A H J-Link Requires hardware modification = confer with me in advance Only as a last resort TFTP mechanism has to be avoided 1. Power cycle the board 2. nterrupt the bootloader within 3 seconds 3. Start the J-Link GDB server 4. Start GDB ( gdb ) target remote :2331 Remote debugging using : x in?? () ( gdb ) monitor speed adaptive ( gdb ) set remote memory - write - packet - size 1024 ( gdb ) set remote memory - write - packet - size fixed ( gdb ) load image. img 15 / / 18

5 Hints Follow-up Hints How it will continue? Wrong design descisions may prove problematic rapidly. = frustration Give precedence to holding on concepts instead of performance Avoid (supposed) optimizations Don t make assumptions about the compiler behaviour Stack organization, registers, calling conventions, return values,... Catch up on the specifics of the compiler to the architecture Reduce assembler code as far as essential (interrupt handler may be implemented in C completely) Don t assume that code which shows the right behaviour is correct as well Just now Accept or cancel definitely Next week (deciding now!) Lecture about the ARM architecture nformation about the hardware Discussion of the first problem statement Conclusion t may be hard t may be a lot of work t can be great fun Experience of success and a lot of insights are the harvest of the effort 17 / / 18