Hello and welcome to this training on Linux Board Port overview. This is for Sitara AM-Class devices AM33x, AM43x, and AM5x. This training is going to discuss all the major steps used to port the processor's SDK Linux from a TI EVM to a custom board.
Here is the presentation overview. What is a Linux board port? Next, we will look at the Linux board port process when migrating from a TI EVM to a custom board. We'll continue on looking at Linux board port process resources available from TI. And then finally, we'll wrap the presentation up with a conclusion.
So here's a disclaimer. This presentation covers Sitara catalog embedded processors in an overview fashion. As you notice, the beginning of the presentation covered three different processors. While the topics presented generally apply to all the processors, there will be areas that are different between the processors.
During the port process, there will be elements that are very specific to the AM3x or AM4x or AM5x processors. Therefore, please review the processor TRM-- technical reference manual-- data sheet, and TI processors Linux SDK for specific information and examples on the port process.
This section is called What is a Linux Board Port. This is a fair question to ask. Another question that is asked is where do you begin? Discussed in this section are answers to these questions about where do you start, as well as the metaphor used that explains the areas of work done by TI with the Linux SDK and how the custom board developer leverages this starting point.
Here's the section overview for What is a Linux Board Port. The key point of this section is to show that porting a custom board is expected, and there is a method that can be filed to expedite a port. The TI EVMs are the starting point that board developers can use to create their port.
First, we'll look at the typical perception of porting an OS to a custom board. Next, we'll look at finding an abstraction for board porting. Then we will produce something called the base port concept. This will lead into the TI Processor SDK Linux board port abstraction. And then we'll look at implementing a board port for Linux.
All right, so let's look at some board port questions that you might have. When looking at porting an OS to a custom board, there is always the perception that, as a developer, you are starting from scratch. This may be typically based on experience of previous ports. There is not any set way to do porting, and so most take the belief that they have to do everything.
So the first question you ask is, where do I start? And as you think about it, several questions start to pop in your mind. Based on previous port experiences, you might be thinking of an OS abstraction layer, or OSAL, an area that usually has all the defined functions you need to fill out to port the OS.
Other questions might be such as architecture support. Do I have to define all that myself? How do I build the code? Do I have to make the make files, or are they provided as part of the port kit? What about basic processor initialization code? Is this something that you have to do, or is it something that's provided?
Then questions such as interrupt setup. Is that something you have to do? Processor privilege modes-- how are they defines? And then finally, driver support. Is there a template? Do I have to create templates? How do I port the actual drivers to the board itself? This driver support is typically called binding peripherals to a board. Something we'll see later for Linux's is this is what a DTS file helps you do.
So now, let's discuss finding an abstraction for board porting. Porting to a new platform is not a new concept. Ever since the Unix epoch, platform porting has been a requirement. Languages and operating systems have been required to be portable for years.
Because moving platforms is a mandatory requirement, softwares evolve to define and use a harder abstraction to make a port easier to accomplish. Sometimes, these harder abstractions can be developed into multiple layers. Each abstraction layer can act as a refinement, so that only changing one layer of an abstraction is all that is needed to move onto the new platform.
Looking at an application as having layers, it's abstraction layer can be written to be portable across hardware. Applications based on the C programming language are set up for porting if they use the attribute standard 1003.1.
Everybody has pretty much seen this, and it's better known as the POSIX API standard. This layered application is drawn in the picture here. The application is written to an API standard that abstracts access to hardware functions provided by the OS.
To summarize, applications can be written to an abstraction layer, such as the POSIX API, which in turn can abstract the operating system on the platform. The later approach demonstrates how several abstraction layers can be combined to define a platform abstraction.
Linux application hardware abstraction. If we're looking at how the Linux kernel possibly uses an abstraction of reporting, let's look at what a Linux application uses to access hardware, and why this allows applications to be portable.
Everything is defined as a file in Linux. The Linux application interface uses these very basic API calls of open, read, write, close, [INAUDIBLE], for its file I/O abstraction. This is a very basic representation. The POSIX API standard has quite a bit more APIs. This file I/O abstraction is used across all Linux platforms, which allows applications to be portable.
As mentioned previously, a harder abstraction can be layered. For example, most of the peripheral drivers in Linux are layered. Here's an example of how a file written to the user's home directory is abstracted to a hardware device. One note here that on a TI EVM running Linux, the default user is route.
The code snippet shows the basic open, write, and close for a file. While this code is compiled and run from the user's home directory, the full path is shown to highlight the file I/O obstruction path to the SD card. The user's home directory is in the root file system, which is shown it right to be mounted on mmcblk0ps, which looking at the dev directory shows us a second partition on mmc0.
For this particular EVM, the user is pretty much aware that they are writing to the second partition on AOMC0 that is configured as an EXT4 file system. The code itself does not care so long as the path requested in the fopen call exists on the system. So in summary, this example is showing the directory path is abstracted to the mounted root file system, which is abstracted to a particular device.
Most of the peripherals in Linux system have similar device instructions to some Linux grown representations, such as sockets for networking or video for Linux for video capture. Again, this is a very basic representation, but one that hopefully describes the file IO aspect of Linux.
Now let's talk about an OS abstraction layer, or OSAL layer, as they're sometimes called. As with application porting, abstractions are used to accelerate porting in OS to a new platform. Some operating systems provide a hardware abstraction layer, or HAL, and this is also known as an OS or operating system abstraction layer, or OSAL. These terms are typically used by people who are used to porting [INAUDIBLE].
Specifically, this layer is a set of APIs that the OS expects for communicating with device drivers, memory, and initialization of the processor specific to the platform it is running on. Expanding the previous slide of the application stack, this diagram shows the abstraction layers that the application will use to get all the way down to a device driver.
The application goes through the library abstraction, which then goes through the OS abstraction, which then goes through the HAL abstraction to finally access the device driver. Linux, though, does not have a published HAL that could be used for porting. So a question you might be asking is, how does Linux, then, put on a new platform?
Now we're going to discuss the TI processor's Linux board port abstraction. In short, this is the abstraction that TI provides for custom board port developers. This is where all the basic processor initialisation questions are answered.
Starting with the processors selected for the custom board, the Linux SDK has already been demonstrated that Linux is running on the processor. This resolves questions from earlier, such as processor initialisation setup. Later on in this presentation, this will be referred to as architecture support.
What makes the SoC differentiating is the peripherals that are included in it. The Linux SDK provides full entitlement to these interfaces. This means that all the device drivers of the SoC have already been ported to Linux. Later on in this presentation, this will be referred to as the SoC portion of support.
So to answer the previous question of how Linux is ported to a new platform, it requires a one-time architecture support and the porting of all the SoC's device drivers. The architecture port is done by ARM for TI processors, and TI does the device driver development for the SoC.
So the key point here is that the port of the architecture has been done. The porting of the SoC has been done. What is left to port? And that is the actual board.
Here, the base port concept is introduced. A base port is a porting of Linux to a processor architecture. This is what is provided by the Processor SDK Linux package. The base port is a combination of the code developed for the processor core, the code developed for the SOC drivers, and then finally, this is all combined on a TI EVM.
To achieve the full SoC entitlement, the base port is developed on a TI EVM. This becomes what is called the known good, which is the EVM out-of-box experience that is provided by the TI processor's Linux SDK. This is the recommended starting point for a custom board developer.
Let's review the board port abstraction. The architecture portion, which is the actual processor itself and the code that supports, the SoC portion, which is all the device drivers for the SoC portion of the chip, and now the third portion of the board port abstraction is the board itself. These are the three elements of the board port abstraction.
One caveat of the base port in EVM process is that it is impossible to make a cost-effective EVM for every possible SoC peripheral or hardware combination. The TI EVMs will target a superset of use cases, such as the industrial development kit shown here.
So with the porting story at this point, the base port proves that both the architecture and SoC layers can be realized on a board. Now the question is how to make this work on a custom board.
So to summarize this key point of this slide, the board port abstraction of architecture, SoC and board will be used in follow-on board port material. The architecture and SoC work has been done by TI. The binding to a board is done by the custom board developer. Again, the base port concept is a combination of architecture, SoC, and the actual board.
Now that we've discussed what a base port is, let's actually look at what implementing a board port is actually like. So the first definition we want to provide is that a board port is equal to a base port plus or minus some custom board peripherals and kernel requirements.
So here's a high-level example of taking a known good, which is the TI EVM out-of-box, and then trying to use it on a custom board. Our example custom board is shown here in the block diagram on the right. So this is the task in a nutshell, implementing the block diagram on the right with the TI SDK.
The starting point is the ARCH SoC abstraction that we've been defining in this presentation for the selected processor that is provided with the TI processor's Linux SDK. The custom block diagram shown is not using the full SoC entitlement, but rather a possible solution for an application that uses only a subset of the SoC. Here, only certain peripherals need to be allocated to realize a new product.
From the block diagram, the port is accomplished by only enabling the peripherals that are required for the new board. Later in the presentation, it will be shown the steps that are necessary to enable or disable a peripheral on the board and the steps and tools provided to accomplish the task. To summarize this slide, a board port is equal to a base port plus or minus some peripherals and kernel requirements.
All right, so here we are at the section conclusion to What is a Linux Board Port? In this section, we discussed the following topics. The first thing we discussed was the typical perception of porting an OS to a board. And the first big question, usually, that people ask is, where do I begin?
Next, we discussed finding an abstraction for board porting. Through the years, people have tryed to find abstraction layers to help them with boarding efforts between [INAUDIBLE] platforms.
The next thing we discussed was the TI Processor SDK Linux board port abstraction, which introduces the architecture code and the SoC code, and how that is done for you by TI.
Next was introducing the base port concept. This is the realization of the architecture code running and the SoC driver code running, all running on a TI EVM. Again, driving home that point that all ports are based on architecture, SoC, and finally, platform.
And the last thing we looked at was implementing a Linux board port on a custom board. This was like taking a look at that custom block diagram and seeing how the architecture, SoC, and board port all work together to make a custom board application.
Thanks for watching this training. For more information, refer to the links below. If you have any questions, please go to the E2E community forums at e2e.ti.com.

Description

April 12, 2018

This training provides an overview of the Linux board porting process for Sitara AM-class devices: AM335x, AM437x, and AM57x. It addresses the typical perception of porting an OS to a custom board, finding an abstraction for board porting, understanding the base port concept and TI Processor SDK Linux board port abstraction, as well as how to implement a Linux board port.