© Promwad Innovation Company
Application Notes | December 09, 2013
Use of NetBSD with Marvell Kirkwood Processors
This article provides an overview of NetBSD and highlights its differences from other operating systems of the family. It also briefly discusses the implementation and configuration of device drivers. The author studies an example of using this operating system, as an alternative to Linux, on the IP-Plug.
NetBSD is an operating system which represents the BSD family, along with OpenBSD and FreeBSD. Originally, BSD (an acronym of Berkeley Software Distribution) was a combination of patches and utilities for Bell Labs Unix, which evolved into an independent system. The source code had two licenses - Bell (because the company owned the larger part of the original source code) and BSD proper. After a while, the team of BSD developers broke up and the BSD project later received a new incarnation as 386BSD, an architecture i386 port. Eventually, the BSD family broke into three branches: NetBSD, OpenBSD and FreeBSD.
Each of the three systems is unique in its own way, but they all have a lot in common. The key feature of NetBSD is multi-platform support. The developers’ slogan was: “Of course, you can run NetBSD on this platform”. Developers have applied for registering 53 architectures, and the number of supported machines continues to grow.
Meanwhile, NetBSD remains just as safe and high-performing as its “family members”, OpenBSD and FreeBSD. NetBSD was first officially released in April 1993 and had the version number 0.8. Today’s latest version is 6.0.
We should especially mention the advantages of a BSD license. Unlike Linux GPL, a BSD license helps in every possibly way modify the source code, change file names and distribute the final product provided we mention the author’s name.
NetBSD source codes are accessible through an FTP server as tar archives or iso images. You can also receive any version of the system out of the cvs repository by referring to the release name tag. The source code tree includes a kernel code (sys directory), utilities (bin, usr.bin, sbin, usr, usr.sbin, gnu), a cross-compiler (tools), the build script build.sh, as well as relevant libraries and documentation.
System compilation involves the following stages:
Let us discuss the system assembly process using the example of the IP-Plug plug computer. This multi-functional mini-server was developed by Promwad engineers by the order of AK-Systems. It is designed for solving a wide range of tasks in IP networks and can perform the functions of a computer or a server. The IP-Plug is powered from a 220V network and has low power consumption, as well as a small size (which can be compared to the size of a mobile phone charger).

Figure 1. Multi-functional mini-server AK-System IP-Plug
This device is used for measuring computing network parameters, data storage and transmission, as well as routing. It can also be used as a Wi-Fi access point, a file server or a DLNA server. The range of tasks performed by the computer is extended through software modification.
Table 1. IP-Plug key features
The IP-Plug uses the Marvell 88F6282 processor, ARMv5TE Kirkwood architecture series. Its support has been added to the NetBSD distribution since July 2012 and represented by files in the directory sys/arch/evbarm/marvell:
The drivers of specified peripherals are located in the folder sys / dev / marvell and are compiled to conform to kernel configuration.
We can use the configuration of the Sheevaplug kernel as a basic configuration because its processor and peripherals are identical to those of the IP-Plug.
To work with different devices, the kernel uses HAL based on the abstractions uvm/pmap (virtual memory), bus_space and bus_dma. Many popular buses (ISA, PCI, PCI-E, etc.) are also abstracted, which increases driver code portability.
All devices in the system are represented as a hierarchical tree-like structure described in the ioconf.c file (generated out of kernel configuration). The root of the tree is a fake root device to which all other devices are connected. The first root child for our processor will be the mainbus which connects the ARM kernel and the peripherals (see Figure 1).
--------------------
mainbus0 at root # specifies the first abstract “mainbus”
cpu0 at mainbus0 # enables processor kernel
mvsoc0 at mainbus0 # and peripherals
--------------------

Figure 2. Configuration of the first NetBSD root child.
For example, the implementation of the Ethernet driver is represented by the files if_mvgbe.c, makphy.c and mii.c. Its configuration is shown as a tree in Figure 2:

Figure 3. Configuration of the Ethernet driver in NetBSD
and represented as follows:
--------------------
mvgbec0 at mvsoc0 offset 0x70000 # first interface controller
mvgbec1 at mvsoc0 offset 0x74000 # second interface controller
mvgbe0 at mvgbec0 port 0 irq 11 # PHY0
mvgbe1 at mvgbec1 port 1 irq 15 # PHY1
makphy0 at mii0 phy 0
makphy1 at mii1 phy 1
--------------------
Because each device has a universal interface, tree traversal is performed at kernel startup, while successively calling the functions attach / match to initialize each of them. This results in system configuration (this process is called autoconf).
After editing the configuration file and building the kernel, let us proceed to the next step.
By specifying the parameter distribution for the script build.sh, you can build a full-functional root file system with all system utilities. But if you specify the target release, all programs will be grouped into sets and packed in respective files (base, comp, etc, games, modules, etc.). Unpacking only two sets, base and etc, helps receive a minimal root file system. By placing the archive contents on NFS, you can configure the NetBSD kernel to connect it as rootfs. To do this, it is enough to add to the configuration:
--------------------
options NFS_BOOT_BOOTSTATIC
options NFS_BOOTSTATIC_MYIP=”\”192.168.10.10\””
options NFS_BOOTSTATIC_GWIP=”\”192.168.10.1\””
options NFS_BOOTSTATIC_MASK=”\”255.255.255.0\””
options NFS_BOOTSTATIC_SERVERADDR=”\”192.168.10.3.0\””
options NFS_BOOTSTATIC_SERVER=”\”:/export/rootfs\””
config netbsd root on mvgbe0 type nfs
--------------------
Now, the built kernel will automatically mount the specified resource as a root file system.
By changing the device in the config line you can start a rootfs connection from any of the supported devices. If the file system is not mounted for whatever reason, the kernel will ask you to select a new boot device and a file system type on it in interactive mode.
NetBSD allows for the possibility of mounting both ready-made packets and self-assembled packets. To install binary packets, you just have to run pkg_add specifying the packets name mask. The archives of packets and dependencies will be downloaded from the FTP server and unpacked. To receive information on the installed packets, you can use the pkg_info utility. To remove it, run pkg_delete.
When building packets from source codes, you need to download and unpack the pkgsrc archive that contains the bmake utility and make packet files sorted by the category. The list of all packets with a brief description can be generated by the command make readme.
Conclusion
High portability, sufficient ease of use, as well as the necessary software packet and an open source code packets and open source make NetBSD a very attractive operating system for use in embedded systems. As seen in the example, it takes quite superficial knowledge of the system architecture and minimum change in the code to run NetBSD on the IP-Plug. At the same time, the functionality and performance of the built operating system is not inferior to that of Linux, which is used by default.
-----
Author: Vladimir Trubilov, Programming Engineer at © Promwad Innovation Company
Each of the three systems is unique in its own way, but they all have a lot in common. The key feature of NetBSD is multi-platform support. The developers’ slogan was: “Of course, you can run NetBSD on this platform”. Developers have applied for registering 53 architectures, and the number of supported machines continues to grow.
Meanwhile, NetBSD remains just as safe and high-performing as its “family members”, OpenBSD and FreeBSD. NetBSD was first officially released in April 1993 and had the version number 0.8. Today’s latest version is 6.0.
We should especially mention the advantages of a BSD license. Unlike Linux GPL, a BSD license helps in every possibly way modify the source code, change file names and distribute the final product provided we mention the author’s name.
NetBSD source codes are accessible through an FTP server as tar archives or iso images. You can also receive any version of the system out of the cvs repository by referring to the release name tag. The source code tree includes a kernel code (sys directory), utilities (bin, usr.bin, sbin, usr, usr.sbin, gnu), a cross-compiler (tools), the build script build.sh, as well as relevant libraries and documentation.
System compilation involves the following stages:
- To build a tool chain for the target architecture, you should call the script build.sh with the parameter tools. The tools include as, binutils, gcc, m4, yacc, etc. You can see all supported architectures in the sys/arch directory.
- Building the kernel is based on the specified configuration.
- To build system utilities and create a root file system, you should call the script build.sh with the parameter distribution.
Let us discuss the system assembly process using the example of the IP-Plug plug computer. This multi-functional mini-server was developed by Promwad engineers by the order of AK-Systems. It is designed for solving a wide range of tasks in IP networks and can perform the functions of a computer or a server. The IP-Plug is powered from a 220V network and has low power consumption, as well as a small size (which can be compared to the size of a mobile phone charger).

Figure 1. Multi-functional mini-server AK-System IP-Plug
This device is used for measuring computing network parameters, data storage and transmission, as well as routing. It can also be used as a Wi-Fi access point, a file server or a DLNA server. The range of tasks performed by the computer is extended through software modification.
Table 1. IP-Plug key features
Microprocessor | 1 GHz Marvell Kirkwood 88F6283, ARM Compliant |
Memory | Up to 1024 MB 16 bit DDR2@800 MHz / Up to 4 GB NAND Flash |
Interfaces | |
Ethernet | 2x Gigabit Ethernet |
USB | 2xUSB 2.0 |
Wi-Fi/BT | Wi-Fi 802.11 b/g/n + BT 2.1 EDR (optional) |
Software | |
Operating system | Linux |
Basic features | |
Power | Input voltage: 100–240 V, 50/60 Hz; / Power consumption: 15 Watt, 5V@3.0A max |
Dimensions | 118 мм (L) x 76 mm (W) x 43 mm (H) |
Package size | 145 mm (L) х 125 mm (W) х 55 mm (H) |
Weight | 250 gram |
The IP-Plug uses the Marvell 88F6282 processor, ARMv5TE Kirkwood architecture series. Its support has been added to the NetBSD distribution since July 2012 and represented by files in the directory sys/arch/evbarm/marvell:
- marvell_start.S is low-level kernel initialization: MMU initialization, transfer of boot parameters to the high-level code;
- marvell_machdep.c contains the main initialization code of the ARM kernel, peripherals (including boot console), building a page table and kernel relocation;
- marvellreg.h and marvellvar.h are constant values for addresses and sizes of memory locations, into which the registers of peripherals needed for system boot are mapped.
The drivers of specified peripherals are located in the folder sys / dev / marvell and are compiled to conform to kernel configuration.
We can use the configuration of the Sheevaplug kernel as a basic configuration because its processor and peripherals are identical to those of the IP-Plug.
To work with different devices, the kernel uses HAL based on the abstractions uvm/pmap (virtual memory), bus_space and bus_dma. Many popular buses (ISA, PCI, PCI-E, etc.) are also abstracted, which increases driver code portability.
All devices in the system are represented as a hierarchical tree-like structure described in the ioconf.c file (generated out of kernel configuration). The root of the tree is a fake root device to which all other devices are connected. The first root child for our processor will be the mainbus which connects the ARM kernel and the peripherals (see Figure 1).
--------------------
mainbus0 at root # specifies the first abstract “mainbus”
cpu0 at mainbus0 # enables processor kernel
mvsoc0 at mainbus0 # and peripherals
--------------------

Figure 2. Configuration of the first NetBSD root child.
For example, the implementation of the Ethernet driver is represented by the files if_mvgbe.c, makphy.c and mii.c. Its configuration is shown as a tree in Figure 2:

Figure 3. Configuration of the Ethernet driver in NetBSD
and represented as follows:
--------------------
mvgbec0 at mvsoc0 offset 0x70000 # first interface controller
mvgbec1 at mvsoc0 offset 0x74000 # second interface controller
mvgbe0 at mvgbec0 port 0 irq 11 # PHY0
mvgbe1 at mvgbec1 port 1 irq 15 # PHY1
makphy0 at mii0 phy 0
makphy1 at mii1 phy 1
--------------------
Because each device has a universal interface, tree traversal is performed at kernel startup, while successively calling the functions attach / match to initialize each of them. This results in system configuration (this process is called autoconf).
After editing the configuration file and building the kernel, let us proceed to the next step.
By specifying the parameter distribution for the script build.sh, you can build a full-functional root file system with all system utilities. But if you specify the target release, all programs will be grouped into sets and packed in respective files (base, comp, etc, games, modules, etc.). Unpacking only two sets, base and etc, helps receive a minimal root file system. By placing the archive contents on NFS, you can configure the NetBSD kernel to connect it as rootfs. To do this, it is enough to add to the configuration:
--------------------
options NFS_BOOT_BOOTSTATIC
options NFS_BOOTSTATIC_MYIP=”\”192.168.10.10\””
options NFS_BOOTSTATIC_GWIP=”\”192.168.10.1\””
options NFS_BOOTSTATIC_MASK=”\”255.255.255.0\””
options NFS_BOOTSTATIC_SERVERADDR=”\”192.168.10.3.0\””
options NFS_BOOTSTATIC_SERVER=”\”:/export/rootfs\””
config netbsd root on mvgbe0 type nfs
--------------------
Now, the built kernel will automatically mount the specified resource as a root file system.
By changing the device in the config line you can start a rootfs connection from any of the supported devices. If the file system is not mounted for whatever reason, the kernel will ask you to select a new boot device and a file system type on it in interactive mode.
NetBSD allows for the possibility of mounting both ready-made packets and self-assembled packets. To install binary packets, you just have to run pkg_add specifying the packets name mask. The archives of packets and dependencies will be downloaded from the FTP server and unpacked. To receive information on the installed packets, you can use the pkg_info utility. To remove it, run pkg_delete.
When building packets from source codes, you need to download and unpack the pkgsrc archive that contains the bmake utility and make packet files sorted by the category. The list of all packets with a brief description can be generated by the command make readme.
Conclusion
High portability, sufficient ease of use, as well as the necessary software packet and an open source code packets and open source make NetBSD a very attractive operating system for use in embedded systems. As seen in the example, it takes quite superficial knowledge of the system architecture and minimum change in the code to run NetBSD on the IP-Plug. At the same time, the functionality and performance of the built operating system is not inferior to that of Linux, which is used by default.
-----
Author: Vladimir Trubilov, Programming Engineer at © Promwad Innovation Company
Thales Alenia Space in partnership for ISS-program
NanoRacks will pursue International Space Station opportunities in cooperation with...
Versum Materials opens R&D facility in Pennsylvania
Versum Materials, a materials supplier to the semiconductor industry, has officially opened its...
Qualcomm with 1'500 job cuts
Chipmaker Qualcomm Inc. is said to lay off 1'500 staff in California, the majority of which will have to leave the chipmaker’s San Diego headquarters.
What’s in your portable product?
We are all familiar with batteries these days; they are virtually ubiquitous in a myriad of...
Rheinmetall protects new naval port
The multiphase contract is a worth a double-digit euro million figure and includes the...
Stadium now part of TT Electronics
TT Electronics plc has completed its acquisition of Stadium Group plc, a supplier of design-led...
First Graphene signs MoU with SupremeSAT on miniature satellites
First Graphene has entered into a binding Memorandum of Understanding with...
Littelfuse PLEDs support replacing fluorescent lighting tubes with LED...
Littelfuse, Inc. introduced a series of PLEDs with an ultra-low holding current (just 21mA) that...
Passives: Demand continues to outstrip supply
Especially MLCC, tantalum and chip resistors are affected by this demand-supply discrepancy. The traditional slowdown in demand that is typical for January, has not occurred and consumption is now expected to be up for the global market...
Bittium secures purchase order from Finnish Defence Forces
Bittium Wireless has received a purchase order from the Finnish Defence Forces for products...
CACI withdraws offer to acquire CSRA
CACI International Inc has withdrawn its previously announced offer to acquire all...
ROHM: Apollo plant gets more production capacity
ROHM Semiconductor plans to construct a new building at its Apollo plant in Chikugo (Japan)...
Bosch plans smart factory for electronic components
Bosch is investing EUR 100 million in a new plant in Celaya (Mexico). The German manufacturer plans to build a new smart factory for electronic components in the central Mexican city by 2020.
RoodMicrotec: First quarter sales up 17%
RoodMicrotec reports a 17 percent year‐on‐year increase in sales revenue, due to a strong...
Infineon demonstrates secured authentication using FIDO2 on Microsoft...
Infineon Technologies AG is demonstrating its FIDO2 reference design. The design is...
MediaTek teams up with Microsoft
MediaTek are collaborating with Microsoft to deliver the first ever Azure Sphere chip, the MT3620...
Edwards Vacuum breaks ground on new innovation centre in Oregon
Edwards Vacuum, a manufacturer of vacuum and abatement solutions, has...
Mouser Electronics expands Mexico office
The new and expanded customer service centre in Guadalajara, Mexico, will serve...
Continental expands production with new facility in China
German technology company, Continental, has broken ground on its greenfield facility in Wuhu...
Molex & TTTech to develop industrial IoT solutions
Based on their shared vision of open, flexible and interoperable systems in the Industrial Internet...
Most Read
Load more news
Comments