Universidade De´Evora

Total Page:16

File Type:pdf, Size:1020Kb

Universidade De´Evora Universidade de Evora´ Escola de Ciencias^ e Tecnologia Mestrado em Engenharia Inform´atica Disserta¸c~ao Simulador para Arquitectura MIPS32 David Jo~aoDomingues Rodrigues Maia Orientador Miguel Jos´eSim~oesBar~ao Mar¸code 2013 Mestrado em Engenharia Inform´atica Disserta¸c~ao Simulador para Arquitectura MIPS32 David Jo~aoDomingues Rodrigues Maia Orientador Miguel Jos´eSim~oesBar~ao Quero dedicar este modesto trabalho aos meus tr^esav´os,que j´apartiram para um lugar melhor. A Jos´eJo~aoPedro da Con- cei¸c~aoBelezas, uma vez que nasceu com ele a minha vontade de estudar engenharia e a Jos´eda Costa Maia e Ant´onioAugusto Nu- nes Domingues que sempre foram uma ins- pira¸c~aoem tempos dif´ıceis. Sum´ario A virtualiza¸c~aode sistemas ´ecada vez mais utilizada no mundo inform´atico. O seu em- prego acarreta in´umerasvantagens, sendo que, em alguns casos, permite atingir melhor desempenho relativamente a uma m´aquinanativa. Esta tese prop~oeum modelo de implementa¸c~aode um simulador da arquitectura MIPS32 utilizando a linguagem de programa¸c~aoC, sendo as aplica¸c~oesde teste desenvolvidas uti- lizando a linguagem assembly MIPS. E´ objectivo recriar os primeiros passos no processo de virtualiza¸c~aode sistemas, assim como possibilitar a instala¸c~aode um minissistema operativo, baseado na fam´ılialinux, no simulador. Para tal, ser´anecess´arioreproduzir o comportamento de v´arios dispositivos f´ısicos, tais como o disco r´ıgido, interface de rede, TLB, cache, rato, teclado e monitor. Embora estes sejam dispositivos desej´aveis, apenas o processador e a mem´oriaRAM s~aocomponentes fulcrais ao funcionamento do simulador. De forma a respeitar os requisitos m´ınimosda arquitectura ser~aoimplementados todos os mecanismos necess´arios, nomeadamente, coprocessadores, modos de opera¸c~ao,registos gen´ericose registos do coprocessador central, unidade de gest~aode mem´oria,mecanismo de tradu¸c~aode endere¸cos,sistema de excep¸c~oese sistema de interrup¸c~oes. i Simulator for the MIPS32 Architecture Abstract Virtualization systems are increasingly used in the computer world. Their use brings numerous advantages and, in some cases, allows to achieve better performance compared to a native machine. This thesis proposes an implementation model of a simulator for MIPS32 architecture using the C programming language and the test applications developed using the MIPS assembly language. The aim is to recreate the first steps in the process of virtualization systems, as well as to enable the installation of a Linux-based mini operating system in the simulator. This will need to reproduce the behavior of several physical devices such as hard disk, network interface, memory management unit including a translation lookaside buffer (TLB), cache, mouse, keyboard, monitor. Although these devices are desirable, only the processor and main memory RAM are key components to the operation of the simulator. In order to meet the minimum requirements of the architecture, all the necessary me- chanisms will be implemented including coprocessors, operating modes, generic registers and records of the central coprocessor, memory management unit, address translation mechanism and the exception and interruption systems. iii Pref´acio Este documento cont´ema disserta¸c~aointitulada \Simulador para a Arquitectura MIPS32", entregue em Outubro de 2012 no ^ambito do Mestrado em Engenharia Inform´aticado autor David Jo~aoDomingues Rodrigues Maia1, na Universidade de Evora,´ em Portugal. O autor ´eLicenciado em Engenharia Inform´atica,tamb´empela Universidade de Evora.´ Actualmente ´eadministrador de sistemas de informa¸c~aona empresa Deloitte, BPAS - AMS, em Portugal. O orientador deste trabalho ´eo Professor Doutor Miguel Jos´eSim~oesBar~ao2, Professor auxiliar no Departamento de Inform´aticada Universidade de Evora.´ [email protected] [email protected] v Agradecimentos Com o desenvolvimento do trabalho final de Mestrado culmina uma importante fase na vida de qualquer estudante. Desta forma, gostaria de dedicar umas palavras de apre¸co a um conjunto de pessoas, que directa ou indirectamente, ajudaram no desenvolvimento do presente trabalho. Aos meus pais e irm~ao,um grande agradecimento pelo amor incondicional, assim como pelo enorme esfor¸coe sacr´ıficosfeitos ao longo desta fase, sem os quais nada disto seria poss´ıvel. Muito obrigado Pai, M~aee Jo~ao! Quero agradecer ao meu orientador, Professor Miguel Bar~ao,pelo incessante apoio, com- preens~aoe claramente pela disponibilidade demonstrada ao longo do desenvolvimento de todo o trabalho. Muito obrigado professor Miguel Bar~ao! Gostaria de agradecer especialmente `aminha namorada Renata Carmona, pelo constante apoio e dedica¸c~aono desenvolvimento da disserta¸c~ao,sem o qual n~aoteria sido poss´ıvel a entrega a tempo. Um muito obrigado e um beijo especial! Aos meus colegas e amigos, Daniel Quina, Alexandre Cabo, Laura Sim~oes, Nelson Dias e Hugo Teodoro, gostaria de agradecer pelo incentivo, conselhos e pela troca de ideias, muito importantes na resolu¸c~aode problemas, assim como pelo suporte no desenvolvi- mento pr´atico.Obrigado a todos! vii Nota¸c~aoe s´ımbolos jj Concatena¸c~aode bits numa palavra de 32 bits. xy..z Selec¸c~aodos bits desde y at´ez da palavra de 32 bits X. 0bn Valor da constante n em base 2. (Bin´ario) 0xn Valor da constante n em base 16. (Hexadecimal) OR Opera¸c~aoL´ogicaOR AND Opera¸c~aoL´ogicaAND XOR Opera¸c~aoL´ogicaXOR NOR Opera¸c~aoL´ogicaNOR USEG Espa¸code mem´oriavirtual mapeada destinado ao modo de opera¸c~ao user. KSEG0 Espa¸code mem´oriavirtual n~aomapeada com utiliza¸c~aode cache destinado ao modo de opera¸c~ao kernel. Este segmento aponta para os primeiros 512 Bytes na mem´oriaRAM. KSEG1 Espa¸code mem´oriavirtual n~aomapeada sem utiliza¸c~aode cache destinado ao modo de opera¸c~ao kernel. KSSEG Espa¸code mem´oriavirtual mapeado destinado ao modo de opera¸c~ao superuser e kernel. KSEG3 Espa¸code mem´oriavirtual mapeada destinado ao modo de opera¸c~ao kernel. CP0..3 Coprocessador 0 ... 3 SEL Vari´avel utilizada pelo processador para identificar o sub registo associado ao registo interno do CP0. ix Acr´onimos ALU Arithmetic Logic Unit CISC Complex Instruction Set Computer CPU Central Processing Unit ELF Executable Linkable Format FMT Fixed Map Translation FPU Floating Point Unit GPR General Purpose Register GPT Global Page Table IF Instruction Fetch IPC Inter Process Communication ISA Instruction Set Architecture LSB Least Significant Byte MEM Memory MIPS Microprocessor without Interlocked Pipeline Stages MMU Memory Management Unit MSB Most Significant Byte xi xii PC Program Counter PFN Physical Frame Number PRA Privileged Resource Architecture PTB Page Table Base PTE Page Table Entry PTL Page Table Limit RAM Random Access Memory RISC Reduced Instruction Set Computer ROM Read Only Memory RD Read Registers TLB Translation Lookaside Buffer VPN Virtual Page Number VMM Virtual Machine Monitor WB Write Back Conte´udo Sum´ario i Abstract iii Pref´acio v Agradecimentos vii Nota¸c~aoe s´ımbolos ix Acr´onimos xii 1 Introdu¸c~ao1 1.1 Enquadramento e Motiva¸c~ao.........................1 1.2 Objectivos....................................3 2 Estado da Arte e Conceitos Envolvidos5 2.1 Virtualiza¸c~aode Sistemas...........................5 2.2 T´ecnicasde tradu¸c~aoe compila¸c~aode instru¸c~oes.............. 13 2.3 Comunica¸c~aoentre processos (IPC)...................... 16 2.3.1 Named e Unnamed Pipes....................... 16 2.4 Executable and Linkable Format (ELF)................... 18 2.4.1 Organiza¸c~aode ficheiros ELF..................... 18 xiii xiv CONTEUDO´ 2.4.2 Interpreta¸c~aode ficheiros ELF.................... 22 3 Sistema Proposto 25 3.1 Apresenta¸c~ao.................................. 25 3.1.1 O que se pretende........................... 26 3.1.2 Metodologias.............................. 28 3.2 Arquitectura.................................. 30 3.2.1 M´odulosdo Sistema.......................... 31 3.2.2 Plataforma de desenvolvimento.................... 33 4 M´odulos 35 4.1 Processador................................... 36 4.1.1 Modos de Execu¸c~ao.......................... 39 4.1.2 Endianness............................... 42 4.1.3 Interpreta¸c~aode c´odigom´aquina................... 45 4.1.4 Pipelines................................ 52 4.1.5 Coprocessadores............................ 57 4.1.6 Registos Gen´ericos........................... 57 4.1.7 Registos do Coprocessador Central.................. 59 4.1.8 Mecanismo de Excep¸c~oes....................... 72 4.2 Unidade de Gest~aode Mem´oria(MMU)................... 92 4.2.1 Mem´oriaVirtual............................ 92 4.2.2 Pagina¸c~ao................................ 95 4.2.3 Simula¸c~aoem Software........................ 100 4.3 Mecanismo de Tradu¸c~aode Endere¸cos(TLB)................ 104 4.3.1 Interface de comunica¸c~aoMMU/TLB................ 105 4.3.2 Instru¸c~oesde controlo MMU/TLB.................. 109 4.3.3 TLB Flush vs ASID's......................... 110 4.3.4 Excep¸c~oesda TLB........................... 112 4.3.5 Simula¸c~aoem Software........................ 116 4.4 Mem´oriasRAM e ROM............................ 121 4.4.1 Simula¸c~aoem Software........................ 123 CONTEUDO´ xv 4.5 Simulador UE.................................. 127 4.5.1 Carregamento e arranque do sistema................. 127 4.5.2 Execu¸c~ao................................ 133 4.5.3 T´ermino de Execu¸c~ao......................... 134 5 Utiliza¸c~aodo Sistema 137 5.1 Interface e funcionamento........................... 138 5.2 Demonstra¸c~oes................................
Recommended publications
  • Authentication Services in Mobile Ad-Hoc Networks
    Authentication Services in Mobile Ad-hoc Networks LOgiciels-Réseaux Willy Jiménez 08013 -LOR Hakima Chaouchi Maryline Laurent-Maknavicius _______________________________________________________________________________ Authentication Services in Mobile Ad-hoc Networks ABSTRACT The deployment of wireless ad hoc networks is useful for people when they desire to communicate even if they are not connected to any infrastructure, with the purpose of playing games, sharing internet connection, or exchange files. In some ad hoc scenarios, they might know each other, so they can establish trusted relationships. However, if the number or users and mobility increase then it is more complicated to trust all users and a security mechanism is required. Few researches has been done in this field to find security solutions for MANETs deployments; one of them proposes a framework where the traditional AAA services are distributed inside the network with the idea of allowing secure exchange of services that could be chargeable. Based on this framework, we evaluate technical solutions, focusing mainly on the Authentication service; in order to have real implementations. One possibility is using virtualization technology to offer a de-centralized authentication service. Another solution is the development of a secure version of a routing protocol that uses a de-centralized authentication service as a previous requirement to allow any node to join the ad hoc routing domain. Willy Jiménez Hakima Chaouchi Maryline Laurent-Maknavicius Etudiant Maître de Conférences
    [Show full text]
  • Virtualization Technologies Overview Course: CS 490 by Mendel
    Virtualization technologies overview Course: CS 490 by Mendel Rosenblum Name Can boot USB GUI Live 3D Snaps Live an OS on mem acceleration hot of migration another ory runnin disk alloc g partition ation system as guest Bochs partially partially Yes No Container s Cooperati Yes[1] Yes No No ve Linux (supporte d through X11 over networkin g) Denali DOSBox Partial (the Yes No No host OS can provide DOSBox services with USB devices) DOSEMU No No No FreeVPS GXemul No No Hercules Hyper-V iCore Yes Yes No Yes No Virtual Accounts Imperas Yes Yes Yes Yes OVP (Eclipse) Tools Integrity Yes No Yes Yes No Yes (HP-UX Virtual (Integrity guests only, Machines Virtual Linux and Machine Windows 2K3 Manager in near future) (add-on) Jail No Yes partially Yes No No No KVM Yes [3] Yes Yes [4] Yes Supported Yes [5] with VMGL [6] Linux- VServer LynxSec ure Mac-on- Yes Yes No No Linux Mac-on- No No Mac OpenVZ Yes Yes Yes Yes No Yes (using Xvnc and/or XDMCP) Oracle Yes Yes Yes Yes Yes VM (manage d by Oracle VM Manager) OVPsim Yes Yes Yes Yes (Eclipse) Padded Yes Yes Yes Cell for x86 (Green Hills Software) Padded Yes Yes Yes No Cell for PowerPC (Green Hills Software) Parallels Yes, if Boot Yes Yes Yes DirectX 9 Desktop Camp is and for Mac installed OpenGL 2.0 Parallels No Yes Yes No partially Workstati on PearPC POWER Yes Yes No Yes No Yes (on Hypervis POWER 6- or (PHYP) based systems, requires PowerVM Enterprise Licensing) QEMU Yes Yes Yes [4] Some code Yes done [7]; Also supported with VMGL [6] QEMU w/ Yes Yes Yes Some code Yes kqemu done [7]; Also module supported
    [Show full text]
  • Comparison of Platform Virtual Machines - Wikipedia
    Comparison of platform virtual machines - Wikipedia... http://en.wikipedia.org/wiki/Comparison_of_platform... Comparison of platform virtual machines From Wikipedia, the free encyclopedia The table below compares basic information about platform virtual machine (VM) packages. Contents 1 General Information 2 More details 3 Features 4 Other emulators 5 See also 6 References 7 External links General Information Name Creator Host CPU Guest CPU Bochs Kevin Lawton any x86, AMD64 CHARON-AXP Stromasys x86 (64 bit) DEC Alphaserver CHARON-VAX Stromasys x86, IA-64 VAX x86, x86-64, SPARC (portable: Contai ners (al so 'Zones') Sun Microsystems (Same as host) not tied to hardware) Dan Aloni helped by other Cooperati ve Li nux x86[1] (Same as parent) developers (1) Denal i University of Washington x86 x86 Peter Veenstra and Sjoerd with DOSBox any x86 community help DOSEMU Community Project x86, AMD64 x86 1 of 15 10/26/2009 12:50 PM Comparison of platform virtual machines - Wikipedia... http://en.wikipedia.org/wiki/Comparison_of_platform... FreeVPS PSoft (http://www.FreeVPS.com) x86, AMD64 compatible ARM, MIPS, M88K GXemul Anders Gavare any PowerPC, SuperH Written by Roger Bowler, Hercul es currently maintained by Jay any z/Architecture Maynard x64 + hardware-assisted Hyper-V Microsoft virtualization (Intel VT or x64,x86 AMD-V) OR1K, MIPS32, ARC600/ARC700, A (can use all OVP OVP Imperas [1] [2] Imperas OVP Tool s x86 (http://www.imperas.com) (http://www.ovpworld compliant models, u can write own to pu OVP APIs) i Core Vi rtual Accounts iCore Software
    [Show full text]
  • Foreign Library Interface by Daniel Adler Dia Applications That Can Run on a Multitude of Plat- Forms
    30 CONTRIBUTED RESEARCH ARTICLES Foreign Library Interface by Daniel Adler dia applications that can run on a multitude of plat- forms. Abstract We present an improved Foreign Function Interface (FFI) for R to call arbitary na- tive functions without the need for C wrapper Foreign function interfaces code. Further we discuss a dynamic linkage framework for binding standard C libraries to FFIs provide the backbone of a language to inter- R across platforms using a universal type infor- face with foreign code. Depending on the design of mation format. The package rdyncall comprises this service, it can largely unburden developers from the framework and an initial repository of cross- writing additional wrapper code. In this section, we platform bindings for standard libraries such as compare the built-in R FFI with that provided by (legacy and modern) OpenGL, the family of SDL rdyncall. We use a simple example that sketches the libraries and Expat. The package enables system- different work flow paths for making an R binding to level programming using the R language; sam- a function from a foreign C library. ple applications are given in the article. We out- line the underlying automation tool-chain that extracts cross-platform bindings from C headers, FFI of base R making the repository extendable and open for Suppose that we wish to invoke the C function sqrt library developers. of the Standard C Math library. The function is de- clared as follows in C: Introduction double sqrt(double x); We present an improved Foreign Function Interface The .C function from the base R FFI offers a call (FFI) for R that significantly reduces the amount of gate to C code with very strict conversion rules, and C wrapper code needed to interface with C.
    [Show full text]
  • Download (4MB)
    Establishing trusted Machine-to-Machine communications in the Internet of Things through the use of behavioural tests Thesis submitted in accordance with the requirements of the University of Liverpool for the degree of Doctor in Philosophy by Valerio Selis April 2018 \Be less curious about people and more curious about ideas." Marie Curie Abstract Today, the Internet of Things (IoT) is one of the most important emerging technolo- gies. Applicable to several fields, it has the potential to strongly influence people's lives. \Things" are mostly embedded machines, and Machine-to-Machine (M2M) communica- tions are used to exchange information. The main aspect of this type of communication is that a \thing" needs a mechanism to uniquely identify other \things" without human intervention. For this purpose, trust plays a key role. Trust can be incorporated in the smartness of \things" by using mobile \agents". From the study of the IoT ecosystem, a new threat against M2M communications has been identified. This relates to the opportunity for an attacker to employ several forged IoT-embedded machines that can be used to launch attacks. Two \things-aware" detection mechanisms have been proposed and evaluated in this work for incorporation into IoT mobile trust agents. These new mechanisms are based on observing specific thing-related behaviour obtained by using a characterisation algorithm. The first mechanism uses a range of behaviours obtained from real embedded ma- chines, such as threshold values, to detect whether a target machine is forged. This detection mechanism is called machine emulation detection algorithm (MEDA). MEDA takes around 3 minutes to achieve a detection accuracy of 79.21%, with 44.55% of real embedded machines labelled as belonging to forged embedded machines.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Netbsdのクロスビルドのしくみと インストール済みlive Imageの作成
    OSC 2012 北海道 たまには謎マシン抜きの話をしてみよう NetBSDのクロスビルドのしくみと インストール済みLive Imageの作成 Izumi Tsutsui [email protected] NetBSDの特徴 特定の機種に依存しない設計 各種ソースが Android や MINIX に流用されたり ものすごい数の機種への移植 55~58機種くらい(?)を一応いまだにサポート クロスコンパイル開発環境 NetBSDを使っていなくてもNetBSD開発が可能 クロスコンパイルとは 「セルフコンパイル」 バイナリを作るマシン=バイナリを実行するマシン ⇒バイナリを作ったマシンでそのまま実行 「クロスコンパイル」 バイナリを作るマシン≠バイナリを実行するマシン ⇒作ったバイナリを実行するマシンに転送して実行 クロスコンパイル用語 「ターゲット」 ⇒バイナリを実行するマシン 「ホスト」 ⇒バイナリを作成するマシン 「ツールチェイン」 ⇒コンパイラ、アセンブラなどの クロスビルドバイナリ作成用プログラム一式 NetBSDとクロス開発環境 NetBSD 1.6 (2002年) から公式にサポート OS標準の配布物だけで全部をクロスで作成可能 ・カーネル ・ユーザーランドバイナリ ・man ページ ・リリース用配布バイナリ一式 tar.gz ・インストール用フロッピーイメージ ・インストール用CD ISOイメージ (3.0以降) ・インストール済み Live イメージ (6.0以降) クロスビルド実行コマンド “build.sh” スクリプト 面倒な設定不要なクロスビルド実行スクリプト “build.sh -U -m i386 tools” →i386用ツールチェインバイナリ一式作成 “build.sh -U -m i386 release” →i386 リリース用バイナリ一式作成 “build.sh -U -m i386 live-image” →i386 インストール済み Live イメージ作成 なぜクロスビルドなのか(1) にわとり卵問題 「バイナリを実行するマシンでバイナリを作る」には 「バイナリを実行できる環境」が必要 ⇒まだOSすら動いてないマシンはどうするの? OS以前にハードから自作した場合は?? 当然 ターゲット≠ホスト のクロス開発が必須 なぜクロスビルドなのか(2) 遅マシン対策 ・移植バブル期のターゲット⇒現役引退ハード多数 ・お世辞にも速いとは言えない ・PCのほうがよっぽど速い ・NetBSD/news68k カーネルコンパイル時間(当時) ・NWS-1750D(MC68030/25MHz): 3時間20分 ・自作PC (AMD K6-2/350MHz): 5分 ……苦労してでも5分で作れる環境用意しますよね なぜクロスビルドなのか(3) 全自動ビルド化 ・セルフビルド時代でもリリース作成は自動化済み ・NetBSD/news68k のリリース作成に1週間とか ⇒速いマシンでやれば全機種毎日テスト可能? ・ツールチェイン作成~ビルド~リリース一式作成 を全自動で実行して結果チェック releng.NetBSD.org http://releng.NetBSD.org/ デイリービルド結果サマリー Summary of daily snapshot builds ある日のNetBSD -current 59 successful builds, 1 failed builds さらなる自動化 デイリービルドの弊害 ・「ビルド至上主義」問題 ・とりあえずエラーを消すやっつけ修正する人が発生 ・「ビルドできたけど壊れてて動かない」という問題
    [Show full text]
  • Raspberrypiでnetbsdを使ってみる
    セキュリティキャンプ2016 SecCamp2016 ドキュメント file:///usr/local/Github/NetBSD/Guide/_build/singleh... RaspberryPIでNetBSDを使ってみる 特徴 NetBSDをRaspberryPIで利用するために、ディスクイメージを用意しました。 Xが動いて、ご家庭のテレビでmikutterが動きます。 うまく動いたら、動いた記念写真をツイートだ! fossil(http://www.fossil-scm.org/)も入れてあります。家庭内Webサーバとかチケットシステムとかwikiサーバになるんでないかい。 準備するもの RaspberryPI本体 HDMI入力のあるテレビ/ディスプレイ USBキーボード USBマウス 有線ネットワーク 起動ディスクの作成 ディスクイメージのダウンロード earmv6hf # ftp http://cdn.netbsd.org/pub/NetBSD/misc/jun/raspberry-pi/ 2016-07-29-earmv6hf/2016-07-29-netbsd-raspi-earmv6hf.img.gz 2GB以上のSDカードを準備します。 ダウンロードしたディスクイメージを、SDカード上で展開します。 disklabel sd0 ..... 必ずインストールするSDカードか確認してください。 gunzip < 2016-07-29-netbsd-raspi-earmv6hf.img.gz.gz|dd of=/dev/rsd0d bs=1m Cubieboard2,BananaPI用イメージ Cubieboard2,BananaPI用のイメージが、 http://cdn.netbsd.org/pub/NetBSD/misc/jun/allwinner/ 以下にあります。 同じ手 順で起動できます。 ODROID-C1用イメージ ODROID-C1用のイメージが、 http://cdn.netbsd.org/pub/NetBSD/misc/jun/odroid_c1/ 以下にあります。 同じ手順で起動で きます。 RaspberryPIの起動 1. HDMIケーブル/USBキーボード/USBマウス/有線ネットワークをRPIにさします。 2. 電源を入れてRPIを起動します。 3. 少し待つと、HDMIからNetBSDの起動メッセージが表示されます。 4. メモリカードの容量にあわせたサイズまでルートパーティションを自動調整します。(現在、RPI2では自動調整プログラムの起動が失 敗します) 5. 容量調整後に再起動します。再起動した後は、起動プロセスが最後まで進み、ログインできる状態になります。 6. 起動しない場合、まず基板上のLEDを確認してください。 赤いランプのみ点灯している場合 OSを正しく読み込めていません。 少なくともMSDOS領域に各種ファームウェアファイルが見えていることを確認する。 SDカードの接触不良の可能性があるので、SDカードを挿しなおしてみる。 ファームウェアが古いため起動しない 緑のランプも点灯している場合 OSは起動しているのに画面をHDMIに表示できていません。 HDMIケーブルを差した状態で電源ケーブルを抜き差しして、HDMIディスプレイに何か表示するか確認する。 HDMIケーブル自体の接触不良。ケーブルを何度か差し直してください。 電源アダプタ容量には、少なくとも800mA程度の容量を持つアダプタを使ってみてください。スマートフォン用のアダプタなら まず大丈夫です。起動途中で画面が一瞬消えたり、負荷をかけるといきなり再起動したりする場合は、電源やUSBケーブルを気
    [Show full text]
  • Simsoc: a Systemc TLM Integrated ISS for Full System Simulation
    SimSoC: A SystemC TLM integrated ISS for full system simulation Claude Helmstetter Vania Joloboff INRIA INRIA LIAMA, 95 Zhongguancun East Road LIAMA, 95 Zhongguancun East Road Haidian District, 100080, Beijing, CHINA Haidian District, 100080, Beijing, CHINA Email: [email protected] Email: [email protected] Abstract—The development of embedded systems requires the devel- ISS technology uses a form of dynamic translation, using an inter- opment of increasingly complex software and hardware platforms. Full mediate representation and pre-generated code using specialization, system simulation makes it possible to run the exact binary embedded a technique already used within virtual machines. software including the operating system on a totally simulated hardware platform. Whereas most simulation environments do not support full The hardware models are standard SystemC TLM abstractions system simulation, or do not use any hardware modeling techniques, or and the simulator uses the standard SystemC kernel. Therefore, have combined different types of technology, SimSoC is developing a the simulation host can be any commodity commercial off-the-shelf full system simulation architecture with an integrated approach relying computer and yet provide reasonable simulation performance. only upon SystemC hardware modeling and transaction-level modeling abstractions (TLM) for communications. To simulate processors at The rest of the paper is organized as follows. Section II describes reasonably high speed, SimSoC integrates instruction set simulators related work in the area of full system simulation, instruction set (ISS) as SystemC modules with TLM interfaces to the other platform simulation and SystemC TLM. Section III explains the overall components. The ISS’s use a variant approach of dynamic translation structure of the simulator, the integration between SystemC, TLM to run binary code.
    [Show full text]
  • Fudging with Firmware
    Fudging with Firmware Firmware reverse-engineering tactics 23C3 27-30 December 2006 Berlin, Germany The (s)talker “Who is this guy anyway” khorben I work for n.runs AG I code for Open Source projects (mostly my own) and ÜberWall of course :) 27-30 December 2006 Fudging with Firmware 2 khorben What's the plan? “Where you need slightly larger glasses” I.How does it look? II.First peek under the hood III.Identification IV.Is there more to it? V.Have some fun 27-30 December 2006 Fudging with Firmware 3 khorben Before we start “Someone tell him it's already started” ● Focusing on firmwares likely to host an Operating System ● Assumes you know how to obtain some: – Read your hardware documentation – Look for undocumented features – Check web sites extensively – Use your imagination... 27-30 December 2006 Fudging with Firmware 4 khorben I. How does it look? “I'm looking better than good, I'm looking nice” ● Unpacking – Presentation – Compression – Bootloaders – Extraction ● Storing – Filesystems 27-30 December 2006 Fudging with Firmware 5 khorben Presentation ● Data may just be encoded in a trivial way ● ASCII versus EBCDIC – Don't take anything for granted! ● ASCII-armored data transfers: – UUENCODE – Base64 – Intel HEX... ● History (or hype) decides 27-30 December 2006 Fudging with Firmware 6 khorben XXENCODE Principles ● Groups of 3 bytes (trailing zeros) ● Split groups into four 6-bit numbers ● Apply the following translation table: 0 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123 | | | | | | | +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
    [Show full text]
  • IJITE Vol.2 Issue-12, (December 2014) ISSN: 2321-1776 Impact Factor- 3.570 a RESEARCH SURVEY on VIRTUAL MACHINES for EFFICIENT COMPUTING in OPERATING SYSTEMS
    IJITE Vol.2 Issue-12, (December 2014) ISSN: 2321-1776 Impact Factor- 3.570 A RESEARCH SURVEY ON VIRTUAL MACHINES FOR EFFICIENT COMPUTING IN OPERATING SYSTEMS Y. Subba Reddy1,V Venkata Ramana2,G. Rama Subba Reddy3,Dr. Pandurangan Ravi4 1, 2, 3 Associate Professors, Department of CSE, CBIT, Proddatur, Y.S.R, A.P, (India) 4 Principal, CBIT, Proddatur, Y.S.R, A.P, (India) ABSTRACT Studies to virtualization old back to 1970’s, while researches targeted on multiplexing solutions in the mainframe. Nevertheless, because of the fall of components value and as well the passing of modern multi-tasking program, virtualization researches fall to its value. Recently, the revitalization of virtualization technological innovation has customized Enterprises’ IT technique from ―one program one machine‖ to multiplexing applications/services into one device that is defined as Virtualization 1.0. Service, merging is an affiliate level on-going pattern and is actuated by higher protection and reliability that virtualization offered.This literary work study talks about the styles of growth of exclusive device, such as genuine virtualization, para- virtualization, and binary interpretation, pre-virtualization and hardware-assisted virtualization. Within the latter part, we often analyze the security and efficiency sides and difficulties introduced by a virtual machine monitor (VMM). Keywords : VMM, OS, Vitualization I. INTRODUCTION The source of virtualization technological innovation old back to 19 70's [1], during which the Exclusive device Observe (VMM) came into being as a thin program system-abstraction part between components and program. VMM allowed dividing a components system into one or a lot of virtual machines during which unlimited in function methods (OS) might run on great of it as if it absolutely was running on great of local components.
    [Show full text]
  • Testen Von Datensicherheit in Vernetzten Und Automatisierten Fahrzeugen Durch Virtuelle Steuergeräte
    Testen von Datensicherheit in vernetzten und automatisierten Fahrzeugen durch virtuelle Steuergeräte Zur Erlangung des akademischen Grades eines DOKTOR-INGENIEURS (Dr.-Ing.) von der KIT-Fakultät für Elektrotechnik und Informationstechnik, des Karlsruher Instituts für Technologie (KIT) genehmigte DISSERTATION von M. Sc. Andreas Florian Lauber geb. in Filderstadt Tag der mündlichen Prüfung: 04.05.2020 Hauptreferent: Prof. Dr.-Ing. Eric Sax Korreferent: Prof. Dr. rer. nat. Sabine Glesner Kurzfassung In der Automobilindustrie sind in den vergangenen Jahren die zwei Trends Automatisierung und Vernetzung entstanden. Diese Trends sorgen für eine steigende Anzahl an Funktionen im Fahrzeug. Neben einer Erhöhung des Komforts nehmen jedoch auch die Risiken durch den unerlaubten Zugriff von außen zu. Das IT-Manipulationen bei Fahrzeugen keine Ausnahme bilden, zeigen bereits erste Beispiele. Besonders durch die langen Lebenszyklen in der Automobilindustrie und der Tatsache, dass 44 % aller Angriffe auf IT-Systeme durch bekannte Schwachstellen geschehen, müssen Fahrzeuge bereits in der Entwicklung abgesichert werden. Bezogen auf die funktionale Sicherheit (engl. Safety) existieren in der Auto- mobilentwicklung bereits eine Vielzahl an Testprozessen und -methoden. Eine Übertragbarkeit dieser auf die Datensicherheit (engl. Security) ist jedoch nicht gegeben, wodurch neue Methoden am Entstehen sind. Daher wird eine Testme- thode mittels virtuellen Steuergeräten vorstellt. Hierfür wird aufgezeigt, welche Beobachtungspunkte und Überwachungsfunktionen für die Tests der Daten- sicherheit gegeben sein müssen, wie sich daraus eine Testmethodik ableiten lässt und wie diese Testmethodik anschließend in die Automobilentwicklung eingebunden werden kann. Für die Testmethodik wurden die Bereiche Speicher-, Numerische-, Systema- tische-, Funktionale- und Anwendungsfehler identifiziert. Der Fokus wird da- bei auf die ersten beiden Fehlerarten gelegt und daraus Kriterien für einen Test der Datensicherheit abgeleitet.
    [Show full text]