Linux on SOPC – Embedded
System Implementation
Final presentation- Part A
Avi Urman, Kobi Maltinsky
Supervisor: Inna Rivkin
•
•
•
•
•
•
•
•
•
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
Linux
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.
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
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.
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.
Kernel
init_xilinxfb_init
register_platform
_driver
probe
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
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
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.
Time Table for project B
PART A
DEMO