index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>LynxLine</title>
    <link>https://lynxline.com/</link>
    <description>Recent content on LynxLine</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 03 Mar 2024 11:21:28 +0100</lastBuildDate>
    <atom:link href="https://lynxline.com/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Services</title>
      <link>https://lynxline.com/services/</link>
      <pubDate>Fri, 08 Mar 2024 10:10:11 +0100</pubDate>
      <guid>https://lynxline.com/services/</guid>
      <description>Introducing LynxLine. Our team specializes in creating secure and efficient solutions for businesses and organizations. With a focus on cutting-edge technology and unparalleled expertise, we are dedicated to providing top-notch services to protect your sensitive data and communications.&#xA;Smart contracts audit Our industry-leading veteran smart contract auditors, ensures that your Ethereum application is ready for launch and built to protect users.&#xA;Software development Our expertise lies in designing and developing software for networking and desktop applications, high-availability servers, and optimizing application performance.</description>
    </item>
    <item>
      <title>Contact</title>
      <link>https://lynxline.com/contact/</link>
      <pubDate>Wed, 06 Mar 2024 21:50:35 +0100</pubDate>
      <guid>https://lynxline.com/contact/</guid>
      <description>BM-2cWzqxBQpnKuu8QhLjep1YsRdhCL9mLeTc</description>
    </item>
    <item>
      <title>Init</title>
      <link>https://lynxline.com/posts/first_post/</link>
      <pubDate>Sun, 03 Mar 2024 11:21:28 +0100</pubDate>
      <guid>https://lynxline.com/posts/first_post/</guid>
      <description>init</description>
    </item>
    <item>
      <title>Labs: Porting Inferno OS to Raspberry Pi</title>
      <link>https://lynxline.com/posts/labs-portintg-inferno-os-to-raspberry-pi/</link>
      <pubDate>Sun, 02 Mar 2014 10:14:13 +0200</pubDate>
      <guid>https://lynxline.com/posts/labs-portintg-inferno-os-to-raspberry-pi/</guid>
      <description>It is a small and exciting project just for fun as “Porting Inferno OS to Raspberry Pi”. Of course to run it there as native, not hosted. It was always declared that this OS is very simple for porting to new platforms, so let’s just research this and reach new distilled experiences of system programming. Also this OS is very small, simple and easy to tweak for research purposes.</description>
    </item>
    <item>
      <title>Lab 26, floating point</title>
      <link>https://lynxline.com/posts/lab-26-floating-point/</link>
      <pubDate>Sat, 01 Mar 2014 10:06:09 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-26-floating-point/</guid>
      <description>In Lab 19 we found a problem that kernel raises exception “Undefined instruction” and stops working. It happens on running JIT arm codes produced by Dis. Now it is time to have little review. In Lab 19 I just added sources used in 9pi for handling floating point exceptions but commented real call fpemu() – so the call fpiarm() only shifting PC to bypass the place of wrong instructions.&#xA;By looking at /libinterp/comp-arm.</description>
    </item>
    <item>
      <title>Lab 25, network, part 2</title>
      <link>https://lynxline.com/posts/lab-25-network-part-2/</link>
      <pubDate>Sun, 23 Feb 2014 12:23:17 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-25-network-part-2/</guid>
      <description>After the Lab 24 when we prepared the layout I took serious study of the ways to implement the ethernet driver. And I found that there is actual convergence of 2 ways of implementation that I saw in previous lab. Comparing to implementation of ethernet driver in C (ether.c, smsc.c) it is enough to have code worked up to call of kernelproxy() which just bypass control to etherusb.c – send a “bind” command into the control file and bypass as arguments usb end point files for input and output data streams.</description>
    </item>
    <item>
      <title>Lab 24, network, part 1</title>
      <link>https://lynxline.com/posts/lab-24-network-part-1/</link>
      <pubDate>Sun, 09 Feb 2014 09:15:24 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-24-network-part-1/</guid>
      <description>This lab will be short; we will add all network modules needed for network layout and make a roadmap how to make the Raspberry Pi ethernet driver. First have a look at other ports and inferno and find what is needed to compile with network support.&#xA;dev section needs: + ip ip ipv6 ipaux iproute arp netlog ptclbsum iprouter plan9 nullmedium pktmedium netaux + ether netif netaux add ip section +ip + il + tcp + udp + ipifc + icmp + icmp6 mod section needs: + crypt + ipints Then we will add etherusb.</description>
    </item>
    <item>
      <title>Lab 23, hard disk or SD card</title>
      <link>https://lynxline.com/posts/lab-23-hard-disk-or-sd-card/</link>
      <pubDate>Thu, 02 Jan 2014 09:01:28 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-23-hard-disk-or-sd-card/</guid>
      <description>Before this Lab, the only way to bypass information to our Raspberry Pi machine, was the TFTP which downloads kernel from development machine (used Mac). Because kernel also includes root filesystem, we can embed some files there to have minimal read-only filesystem which allows to run dis files and do some testing, like experimenting with USB support, etc.&#xA;Sure, there were no way to do something and keep results on storage as there is no one.</description>
    </item>
    <item>
      <title>Lab 22, Usb keyboard</title>
      <link>https://lynxline.com/posts/lab-22-usb-keyboard/</link>
      <pubDate>Thu, 26 Dec 2013 09:52:13 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-22-usb-keyboard/</guid>
      <description>In previous lab we approached very close to get working Usb devices. In this lab we will try to get Usb keyboard working:&#xA;First some preparations: as we need automatic drivers loading, we overwrite existing Usb codes in Inferno repository with our files affecting appl/cmd/usb and appl/lib/usb. Our Usbd which we have written as standalone limbo file, we will split into header usb.m, library with API, usb.b and functionality related to hubs and ports logic and driver loading we leave in usbd.</description>
    </item>
    <item>
      <title>Lab 21, porting usbd, fixed in allocb, see usb in actions</title>
      <link>https://lynxline.com/posts/lab-21-porting-usbd-fixed-in-allocb-see-usb-in-actions/</link>
      <pubDate>Sun, 15 Dec 2013 12:02:49 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-21-porting-usbd-fixed-in-allocb-see-usb-in-actions/</guid>
      <description>From previous lab 20 we got /dev/usb connected in our system, but what to do with it? Different systems handling usb in different ways, but Inferno and Plan9 has /dev/usb just as communication filesystem which should managed not by kernel but user-space process usbd which by communication with the file server manages the connectivity and start appropriate drivers for connected usb devices.&#xA;My first attempt was to have a look at original Inferno OS used to see possibilities to just reuse it.</description>
    </item>
    <item>
      <title>Lab 20, devusb, usbdwc and firq, first step to usb</title>
      <link>https://lynxline.com/posts/lab-20-devusb-usbdwc-and-firq-first-step-to-usb/</link>
      <pubDate>Mon, 09 Dec 2013 12:02:49 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-20-devusb-usbdwc-and-firq-first-step-to-usb/</guid>
      <description>To have our Inferno to communicate with external world we need to have the USB supported as most important parts including ethernet controller and keyboard are behind the USB subsystem. I had a look what parts the Inferno already had for usb support and what was implemented in 9pi. So I decided just to compile-in the Plan9 usb support as devusb.c and usbdwc.c from 9pi. Fortunately due to sharing almost same API of syscalls, the devusb is compiled perfectly and usbdwc needed just two fixes.</description>
    </item>
    <item>
      <title>Lab 19, keyboard through serial, fixes to get Ls</title>
      <link>https://lynxline.com/posts/lab-19-keyboard-through-serial-fixes-to-get-ls/</link>
      <pubDate>Sun, 01 Dec 2013 14:27:34 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-19-keyboard-through-serial-fixes-to-get-ls/</guid>
      <description>In previous Lab I got a screen working, but still no way to send commands into Raspberry computer. My guess that for time being it just simple enough to make the keyboard input coming from serial cable, so then I can play with Sh on raspberry and do some simple experiments onboard until I will have the Usb subsystem working and it recognize keyboard connected to RPi.&#xA;To work with input from Pl011 we should have it in non-blocking way.</description>
    </item>
    <item>
      <title>Lab 18, we have a screen!</title>
      <link>https://lynxline.com/posts/lab-18-we-have-a-screen/</link>
      <pubDate>Mon, 18 Nov 2013 09:13:37 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-18-we-have-a-screen/</guid>
      <description>Before the Lab the development was going in total darkness…, um I meant using serial ftdi usb cable. But time comes to have a light!, no, a screen. Amazingly it wasn’t so complicated. Yes, we just used codes from 9pi project (thanks to Richard Miller). Our expected result is:&#xA;To achieve we need first to expand our “rpi” configuration and add draw and screen to dev section, tk draw memlayer memdraw into the lib section and draw and tk to mod:</description>
    </item>
    <item>
      <title>Lab 17, mmu init</title>
      <link>https://lynxline.com/posts/lab-17-mmu-init/</link>
      <pubDate>Fri, 15 Nov 2013 09:13:29 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-17-mmu-init/</guid>
      <description>What is fun about Inferno OS that our CPU may not have MMU support and still we are able to port Inferno to such architecture. That’s because Inferno OS implements Dis virtual machine and all users processes are actually Dis byte-codes interpreters on JIT compiled. So address space is virtual by software layer and it is very good for portability of the system.&#xA;Anyway, still it is good to have the MMU initialized (may be needed later to work with framebuffer) and it looks simple enough to do.</description>
    </item>
    <item>
      <title>Lab 16, Adding clocks, timers, converging to 9pi codes</title>
      <link>https://lynxline.com/posts/lab-16/</link>
      <pubDate>Wed, 17 Jul 2013 09:08:00 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-16/</guid>
      <description>We are starting new season of the labs. Season 2 will be named as “Close to hardware”. And we start from important point to have clocks and timers working. But first we made a decision to make our codes close to 9pi source codes, especially assembler parts. But we found it little complicated as UReg struct on Plan 9 have r14 and link as union while Inferno has them separate. We can not change Ureg in arm/include as we would break another ports.</description>
    </item>
    <item>
      <title>Lab 15, Eve, Hello World from Limbo!</title>
      <link>https://lynxline.com/posts/lab-15-eve-hello-world-from-limbo/</link>
      <pubDate>Wed, 17 Apr 2013 10:18:04 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-15-eve-hello-world-from-limbo/</guid>
      <description>It is our 15-th Lab and it is the time came to make birth of the process Eve, run Dis virtual machine and our first Limbo program!&#xA;First create file archrpi.c where we all R-Pi platform specific code. We need to implement kprocchild() call:&#xA;1static void 2linkproc(void) 3{ 4&#x9;spllo(); 5&#x9;if (waserror()) 6&#x9;print(&amp;#34;error() underflow: %r\n&amp;#34;); 7&#x9;else (*up-&amp;gt;kpfun)(up-&amp;gt;arg); 8&#x9;pexit(&amp;#34;end proc&amp;#34;, 1); 9} 10 11void 12kprocchild(Proc *p, void (*func)(void*), void *arg) 13{ 14&#x9;p-&amp;gt;sched.</description>
    </item>
    <item>
      <title>Lab 14, interrupts, part 3</title>
      <link>https://lynxline.com/posts/lab-14-interrupts-part-3/</link>
      <pubDate>Tue, 16 Apr 2013 10:18:04 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-14-interrupts-part-3/</guid>
      <description>Now we can study the C part of handling interrupts. But before we start remember that we need to install stack pointers to appropriate modes:&#xA;1void 2trapinit(void) 3{ 4&#x9;Vpage0 *vpage0; 5&#x9;/* set up the exception vectors */ 6&#x9;vpage0 = (Vpage0*)HVECTORS; 7&#x9;memmove(vpage0-&amp;gt;vectors, vectors, sizeof(vpage0-&amp;gt;vectors)); 8&#x9;memmove(vpage0-&amp;gt;vtable, vtable, sizeof(vpage0-&amp;gt;vtable)); 9 10&#x9;setr13(PsrMfiq, m-&amp;gt;fiqstack+nelem(m-&amp;gt;fiqstack)); 11&#x9;setr13(PsrMirq, m-&amp;gt;irqstack+nelem(m-&amp;gt;irqstack)); 12&#x9;setr13(PsrMabt, m-&amp;gt;abtstack+nelem(m-&amp;gt;abtstack)); 13&#x9;setr13(PsrMund, m-&amp;gt;undstack+nelem(m-&amp;gt;undstack)); 14} 1TEXT setr13(SB), $-4 2&#x9;MOVW&#x9;4(FP), R1 3&#x9;MOVW&#x9;CPSR, R2 4&#x9;BIC&#x9;$PsrMask, R2, R3 5&#x9;ORR&#x9;R0, R3 6&#x9;MOVW&#x9;R3, CPSR&#x9;/* switch to new mode */ 7&#x9;MOVW&#x9;SP, R0&#x9;/* return old sp */ 8&#x9;MOVW&#x9;R1, SP&#x9;/* install new one */ 9&#x9;MOVW&#x9;R2, CPSR&#x9;/* switch back to old mode */ 10&#x9;RET Have a look at *trap(Ureg ).</description>
    </item>
    <item>
      <title>Lab 13, interrupts, part 2</title>
      <link>https://lynxline.com/posts/lab-13-interrupts-part2/</link>
      <pubDate>Sun, 14 Apr 2013 12:45:00 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-13-interrupts-part2/</guid>
      <description>Time to write a code to process interrupts. All interrupts that happens in system use the vector of interrupts (8 of them) which is located at 0xffff0000 (high memory case). This vector contains addresses that CPU should pass execution to.&#xA;1. +00 Reset 2. +04 Undefined 3. +08 SWI 4. +0C Prefetch abort 5. +10 Data abort 6. +14 Reserved 7. +18 IRQ 8. +1C FIQ In main() we have to call function called trapinit() to do all initializations of interrupts handling.</description>
    </item>
    <item>
      <title>Lab 12, interrupts, part 1</title>
      <link>https://lynxline.com/posts/lab-12-interrupts-part-1/</link>
      <pubDate>Sat, 13 Apr 2013 12:03:37 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-12-interrupts-part-1/</guid>
      <description>Time to create content of io.h with references to control registers, irq nums etc:&#xA;1#define IOBASE&#x9;0x20000000&#x9;/* base of io regs */ 2#define INTREGS&#x9;(IOBASE+0x00B200) 3#define POWERREGS&#x9;(IOBASE+0x100000) 4#define PL011REGS&#x9;(IOBASE+0x201000) 5 6#define UART_PL01x_FR_TXFF&#x9;0x20 7 8typedef struct Intregs Intregs; 9 10/* interrupt control registers */ 11struct Intregs { 12&#x9;u32int ARMpending; 13&#x9;u32int GPUpending[2]; 14&#x9;u32int FIQctl; 15&#x9;u32int GPUenable[2]; 16&#x9;u32int ARMenable; 17&#x9;u32int GPUdisable[2]; 18&#x9;u32int ARMdisable; 19}; 20 21enum { 22&#x9;IRQtimer0&#x9;= 0, 23&#x9;IRQtimer1&#x9;= 1, 24&#x9;IRQtimer2&#x9;= 2, 25&#x9;IRQtimer3&#x9;= 3, 26&#x9;IRQclock&#x9;= IRQtimer3, 27&#x9;IRQdma0&#x9;= 16, 28#define IRQDMA(chan)&#x9;(IRQdma0+(chan)) 29&#x9;IRQaux&#x9;= 29, 30&#x9;IRQmmc&#x9;= 62, 31&#x9;IRQbasic&#x9;= 64, 32&#x9;IRQtimerArm&#x9;= IRQbasic + 0, 33&#x9;DmaD2M&#x9;= 0,&#x9;/* device to memory */ 34&#x9;DmaM2D&#x9;= 1,&#x9;/* memory to device */ 35&#x9;DmaM2M&#x9;= 2,&#x9;/* memory to memory */ 36&#x9;DmaChanEmmc&#x9;= 4,&#x9;/* can only use 2-5, 11-12 */ 37&#x9;DmaDevEmmc&#x9;= 11 38}; Then in Mach struct we need to add stacks – they will be used as short memory blocks for stack:</description>
    </item>
    <item>
      <title>Lab 11, _div, testing print</title>
      <link>https://lynxline.com/posts/lab-11-_div-testing-print/</link>
      <pubDate>Sat, 13 Apr 2013 11:27:58 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-11-_div-testing-print/</guid>
      <description>Interesting point we missed in lab10. Those are stubs that we have in main(): _div, _divu, _mod, _modu&#xA;Amazingly, I do not know what it is :),&#xA;Plan9/Inferno people, can you give a help regarding purpose of these references and way how they affect? (I will update the lab as I get more info about this)&#xA;It is clear that without them fixed you can not have print() call working and other stuff in the kernel.</description>
    </item>
    <item>
      <title>Lab 10, Bss, memory pools, malloc</title>
      <link>https://lynxline.com/posts/lab-10-bss-menpools-malloc/</link>
      <pubDate>Sat, 16 Feb 2013 09:45:03 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-10-bss-menpools-malloc/</guid>
      <description>Time to have a look at initial memory initializations. First we need to initialize BSS (more details: http://en.wikipedia.org/wiki/.bss), statically-allocated variables. We do it in next way:&#xA;1memset(edata, 0, end-edata); From Plan9 manual: “The loaded image has several symbols inserted by the loader: etext is the address of the end of the text segment; bdata is the address of the beginning of the data segment; edata is the address of the end of the data segment; and end is the address of the end of the bss segment, and of the program.</description>
    </item>
    <item>
      <title>Lab 9, coding assembler part</title>
      <link>https://lynxline.com/posts/lab-9-coding-assembler-part/</link>
      <pubDate>Sun, 27 Jan 2013 21:59:03 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-9-coding-assembler-part/</guid>
      <description>Time to have assembler part of Inferno kernel to be implemented. Let’s start with routines that allows to make labels and later jump to them, they are used in kernel sources to have scheduler to switch control and do context switching between processes. The Label structure in dat.h:&#xA;1struct Label { 2&#x9;ulong sp; 3&#x9;ulong pc; 4}; Simple idea to remember the PC(program counter) and SP(stack pointer), to init the structure and use later, we should have two functions implemented:</description>
    </item>
    <item>
      <title>Lab 8, memory model</title>
      <link>https://lynxline.com/posts/lab-8-memory-model/</link>
      <pubDate>Thu, 24 Jan 2013 20:18:59 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-8-memory-model/</guid>
      <description>Now time to have a look at memory model. The BCM2835 gives next picture:&#xA;Actually when U-Boot pass the control, we have memory model equal to just physical addresses (middle column), so we just do not do anything we can perfectly sit with memory model equal with physical.&#xA;So then, our kernel is loaded at 0x8000, which is 32KB, and we are going to use the low 0-0x8000 memory part for kernel structures and kernel stack (which is not expected to be too much)</description>
    </item>
    <item>
      <title>Lab 7, linking, planning next</title>
      <link>https://lynxline.com/posts/lab-7-linking-more-initialization/</link>
      <pubDate>Mon, 17 Dec 2012 21:07:59 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-7-linking-more-initialization/</guid>
      <description>As we have the kernel almost compiled now it is time to check what is missing to have it linked. By checking header files and adding stubs into main.c we will get linked with very small changes as:&#xA;Changes to main.c:&#xA;1#include &amp;#34;u.h&amp;#34; 2#include &amp;#34;../port/lib.h&amp;#34; 3#include &amp;#34;dat.h&amp;#34; 4#include &amp;#34;mem.h&amp;#34; 5 6Conf conf; 7Mach *m = (Mach*)MACHADDR; 8Proc *up = 0; 9 10#include &amp;#34;../port/uart.h&amp;#34; 11PhysUart* physuart[1]; 12 13int waserror(void) { return 0; } 14int splhi(void) { return 0; } 15void splx(int) { return; } 16int spllo(void) { return 0; } 17void splxpc(int) { return; } 18int islo(void) { return 0; } 19int setlabel(Label*) { return 0; } 20void gotolabel(Label*) { return; } 21ulong getcallerpc(void*) { return 0; } 22int segflush(void*, ulong) { return 0; } 23void idlehands(void) { return; } 24void kprocchild(Proc *p, void (*func)(void*), void *arg) { return; } 25ulong _tas(ulong*) { return 0; } 26ulong _div(ulong*) { return 0; } 27ulong _divu(ulong*) { return 0; } 28ulong _mod(ulong*) { return 0; } 29ulong _modu(ulong*) { return 0; } 30 31void setpanic(void) { return; } 32void dumpstack(void) { return; } 33void exit(int) { return; } 34void reboot(void) { return; } 35void halt(void) { return; } 36 37Timer* addclock0link(void (*)(void), int) { return 0; } 38void clockcheck(void) { return; } 39 40void fpinit(void) {} 41void FPsave(void*) {} 42void FPrestore(void*) {} Changes to fns.</description>
    </item>
    <item>
      <title>Lab 6, Compile something</title>
      <link>https://lynxline.com/posts/lab-6-compile-something/</link>
      <pubDate>Tue, 11 Dec 2012 22:05:20 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-6-compile-something/</guid>
      <description>Now it is lab 6 and it is time to compile “something” – kernel of inferno, but we are going to compile without worrying that it would not work (even would not link). We just need inferno kernel which can be compiled okay for R-Pi using a lot of stabs.&#xA;Files/Folders structure:&#xA;inferno-os/ |-os/ | |-rpi/ | | |-rpi | | |-mkfile | | |-load.s | | |-main.c mkfile:&#xA;1&amp;lt;../../mkconfig 2 3CONF=rpi 4CONFLIST=rpi 5loadaddr=0x00008000 6 7SYSTARG=$OSTARG 8OBJTYPE=arm 9INSTALLDIR=$ROOT/Inferno/$OBJTYPE/bin 10 11&amp;lt;$ROOT/mkfiles/mkfile-$SYSTARG-$OBJTYPE 12 13&amp;lt;| $SHELLNAME .</description>
    </item>
    <item>
      <title>Lab 5, Hello World</title>
      <link>https://lynxline.com/posts/lab-5-hello-world/</link>
      <pubDate>Tue, 27 Nov 2012 22:05:20 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-5-hello-world/</guid>
      <description>This lab will be short but it is going to summarize all material provided in previous labs. Our target to develop simple “barebone” program which can be loaded and executed by U-Boot. It should only print “Hello world!” to our serial console.&#xA;First, let’s find out how we can print something. BCM2835 manual describes that the chip has different features as Mini-UART and PL011 UART.&#xA;Instead of writing own driver for UART routines let’s better check how U-Boot performs.</description>
    </item>
    <item>
      <title>Lab 4, Loading kernel</title>
      <link>https://lynxline.com/posts/lab-4-loading-kernel/</link>
      <pubDate>Sun, 18 Nov 2012 21:27:34 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-4-loading-kernel/</guid>
      <description>Time to study the way how we place our kernel into the memory on R-Pi. U-Boot have usually convention to place loaded binaries at 0x8000 (32KB) and just pass control there. So, let’s compile trivial program and study generated binary to understand the way how we can operate with it.&#xA;In Lab 1 we found a way of making ARM executables. Check what actually the file is:&#xA;$ file test test: Plan 9 executable, ARM 7-something By checking Plan 9 a.</description>
    </item>
    <item>
      <title>Lab 3, R-Pi Booting process</title>
      <link>https://lynxline.com/posts/lab-3-r-pi-booting-process/</link>
      <pubDate>Fri, 16 Nov 2012 21:18:43 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-3-r-pi-booting-process/</guid>
      <description>Now time to study the boot process on Raspberry Pi. Good source to study: R-Pi Boot process&#xA;Stage 1 boot is in the on-chip ROM. Loads stage2 in the L2 cache! Stage 2 is bootcode.bin. Enables SDRAM and loads stage3 Stage 3 is loader.bin. Knows about elf format and load start.elf start.elf loads kernel.img (also start.elf is the main gpu code). It reads config.txt, cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at 0x100 &amp;amp; kernel @ 0x8000 Else if disable_commandline_tags is set load kernel @ 0x0 Else if load kernel @ 0x8000 and put ATAGS at 0x100 kernel.</description>
    </item>
    <item>
      <title>Lab 2, Hardware</title>
      <link>https://lynxline.com/posts/lab-2-hardware/</link>
      <pubDate>Fri, 16 Nov 2012 21:18:42 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-2-hardware/</guid>
      <description>We need to have possibility of booting kernel on Raspbery Pi. Because we will not have display driver soon, we need another approach – have serial port connected to get all output from booter and then from our kernel. We bought small FTDI 3.3V chip to have connected it to GPIO pins on one side and to USB port of my Mac on another side. Also need to install FTDIUSBSerialDriver_v2_2_18 for Mac.</description>
    </item>
    <item>
      <title>Lab 1, Compiler</title>
      <link>https://lynxline.com/posts/lab-1-compiler/</link>
      <pubDate>Fri, 16 Nov 2012 21:18:41 +0200</pubDate>
      <guid>https://lynxline.com/posts/lab-1-compiler/</guid>
      <description>Let’s start with tools that we need to just build the OS for ARM. First clone official inferno os repository from google code repository:&#xA;1# hg clone https://code.google.com/p/inferno-os/ What we need to move further? We need the ARM cross compiler, linker, etc. For this, let’s just compile inferno targeting mac as host (we are on mac now, so we will get hosted inferno for mac as result):&#xA;1# cd inferno-os/ 2# INF_ROOT=`pwd` perl -i -pe &amp;#39;s/^ROOT=.</description>
    </item>
  </channel>
</rss>