Download
1 / 25
250 likes | 368 Vues
Linux on SOPC – Embedded System Implementation. Final presentation- Part A. Avi Urman, Kobi Maltinsky. Supervisor: Inna Rivkin. Table of Contents. Project Goals Hardware Petalinux Configuration Boot Up PS2 Keyboard TFT Screen Difficulties Part B. Project Goals.
E N D
Linux on SOPC – Embedded System Implementation Final presentation- Part A Avi Urman, KobiMaltinsky Supervisor: Inna Rivkin
Table of Contents • 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 Linux • Part B - Based on system from part A, create a Hardware Accelerator – Decode an encrypted file using software and hardware.
Project Goals- Continued • 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
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.
Configuring Kernel 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
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 0x50000000 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: 640x480 24 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.
int(*fb_set_par)(structfb_info *info) - Configure the video controller registers • static intxilinx_fb_setcolreg- Create pseudo color palette map • int (*fb_blank)(int blank, structfb_info *info) - Blank/unblankdisplay probe initializes the driver and registers the functions that control the hardware
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 /devnodes 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 theSerio layer that is a part of the input layer of linux. • The seriolayer 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 __initxps2_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 Accelartorto perform decoding. • Decoded file then sent to the sound controller to play sound on speakers.
Part B-Goals • 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.
