Final presentation- Part A Avi Urman, Kobi Maltinsky Supervisor: Inna Rivkin Linux on SOPC – Embedded System Implementation

Project Goals Hardware Petalinux Configuration Boot Up PS2 Keyboard TFT Screen Difficulties Part B

Project Goals Part A - Implement an interactive standalone embedded system running Linux. Interaction with user through PS/2 keyboard LCD Screen as standard output of the system Ethernet UART Boot system from flash Part B - Based on system from part A, create a Hardware Accelerator – Decode an encrypted file using software and hardware. Linux

Our goal was to add Keyboard and Screen functionalities – Hardware components. Write/update PS2 and TFT drivers Configure kernel correctly to support them and get a system running. *System already had UART and Ethernet support Project Goals- Continued

Who’s on board ?

Hardware Architecture

Hardware configuration Hardware configuration was done using EDK. Adding all necessary controllers I/O Address mapping Interrupt priorities FPGA Pin assignment Linux related configuration : stdin,stdout, memory, FLASH etc.

PetaLinux A special Linux distribution for embedded systems Kernel sources and a set of linking and debugging tools. Cross compilation- binaries generation for a target different than where the compiler is running. All software components(Kernel and Application) were compiled into a single ELF file that was downloaded onto the memory on boot up. Configuration is done through GUI- Enables to add and remove kernel functionality based on underling Hardware.(more on this later) Information on Hardware is passed to kernel using DTS- a textual description of systems Hardware.

Several functionalties should be configured for our system : Set where the kernel should be allocated in memory, this had to match the DDR address specified in hardware design. Match micrblaze features: MMU support, FPU, etc. Add Xilinx frame buffer support and set it as default output Add “support for console on virtual terminal” and “Enable character translation in console” Add Frame buffer Console support and Map the console to the primary display device. Activate Xilinx XPS PS/2 Controller support Configuring Kernel

Booting Up A single “ACE” file was created containing Hardware and Software. The file was place in Compact Flash, and read by FPGA through JTAG on power up. After Hardware design is downloaded, FPGA copies kernel to the DDR memory through MDM interface while loading the kernel file to memory, we had to prevent the processor executing random code and keep it in a known state, thus a simple C program was created,which waits a few seconds (until the compact flash finished copying the kernel) and the jumps to 0x where the kernel resides in memory.

TFT XPS Thin Film Transistor (TFT) controller is a hardware display controller IP capable of displaying true color (24 bit) color depth. 640x480 pixels at 60HZ refresh rate TFT Video memory is stored in main memory - 2MB required. Linux Frame buffer driver updates video memory

Frame Buffer Driver The Linux frame buffer is special layer dedicated to handling graphic displays. It provides a general abstraction and specifies a programming interface that allows applications and higher kernel layers to be written in a platform-independent Manner. The kernel's frame buffer interface thus allows applications to be independent of the vagaries of the underlying graphics hardware. Applications run unchanged over diverse types of video hardware if they and the display Drivers conform to the frame buffer interface.

TFT Driver The interface to the frame buffer has two control registers. The first tells the LCD interface where in memory the frame buffer is.The second allows the LCD to be turned on or off as well as rotated 180 degrees. The hardware only handles a single mode: 640x bit true color. Each pixel gets a word (32 bits) of memory. Within each word, the 8 most significant bits are ignored, the next 8 bits are the red level, the next 8 bits are the green level and the 8 least significant bits are the blue level. Each row of the LCD uses 1024words, but only the first 640 pixels are displayed with the other 384words being ignored. There are 480 rows.

probe initializes the driver and registers the functions that control the hardware int (*fb_set_par)(struct fb_info *info) - Configure the video controller registers static int xilinx_fb_setcolreg - Create pseudo color palette map int (*fb_blank)(int blank, struct fb_info *info) - Blank/unblank display Kernel init_xilinxfb_init register_platform _driver probe

PS2 controller PS/2 is a specification for mouse and keyboards interface. It was added to the design as a mean to fully interact with user on a standalone system without connection to the host PC. Xilinx's “xps_ps2_v1.01a” was used,It supports two devices on the same controller, each one of them with its own interrupt signal.

Input layer architecture kernel's input subsystem was created to unify scattered drivers that handle diverse classes of data-input devices such as keyboards, mice, trackballs etc. Uniform handling of functionally similar input devices even when they are physically different. For example, all mice, such as PS/2, USB or Bluetooth, are treated alike. An easy event interface for dispatching input reports to user applications. Our driver does not have to create and manage /dev nodes and related access methods. Instead, it can simply invoke input APIs to send mouse movements, key presses, or touch events upstream to user land.

PS/2 ports uses the the Serio layer that is a part of the input layer of linux. The serio layer offers library routines to access legacy input hardware such as i8042-compatible keyboard controllers and the serial port. To communicate with hardware serviced by serio, for example, to send a command to a PS/2 mouse, register prescribed callback routines with serio using serio_register_driver(). To add a new driver as part of serio, register open()/close()/start()/stop()/write() entry points using serio_register_port ().

PS2 Driver The PS2 driver registers itself to the Serio layer by providing the driver functions and calling serio_register_port(), this function is called in the probe function which itself is being called by the __init xps2_init on module load. The driver contains the following functions : xps2_recv() - attempts to receive a byte from the PS/2 port. sxps2_write() - sends a byte out through the PS/2 port. sxps2_open() - called when a port is opened by the higher layer sxps2_close() - frees the interrupt. xps2_of_probe - probe method for the PS/2 device. This function probes the PS/2 device in the device tree. It initializes the driver data structure and the hardware xps2_of_remove - unbinds the driver from the PS/2 device. This function is called if a device is physically removed from the system

Difficulties An area that is unfamiliar to us. It was hard to find real professional and/or formal information on embedded Linux. Difficult to debug -Many components in the system hardware/software, hard to identify the root cause of problems. Configuration process was difficult, hundreds of different options for kernel, it was hard to find and configure what we really needed.

Part B Add an Hardware Accelerator block that will perform decoding algorithm Software on the host computer encrypts a sound file And sends it to our system through Ethernet. The file is passed to the Hardware Accelartor to perform decoding. Decoded file then sent to the sound controller to play sound on speakers.

Part B- System Architecture

Write a software encoder that will run on host CPU, encode a sound file. Write a software based decoder that will run on our system, show that it’s not fast enough to perform decoding in real time. Write a hardware decoder in VHDL/Verilog and integrate into existing system. Show that decoding works well with hardware offload engine, and the sound file plays ok. Part B-Goals

Time Table for project B

PART A DEMO