About: How to update a bootloader program on a flash chip using Linux MTD ABI. Detailed description of MTD character device ABI calls.
Preface
A lot of embedded systems are configured to bootstrap from non-volatile flash memory containing a bootloader program like U-Boot. Using a flash memory here lets developers to re-install bootloader program several times (by re-programming a flash) using:
Figure 1. Abatron BDI2000 BDM / JTAG debugger connection.
It works quite well until the board is shipped to production, after that any changes (mostly, bug-fixes) are hardly possible, for a number of reasons:
-
the board is usually a part of a complex solution, where physical access to JTAG/serial console ports is a difficulty;
-
special equipment and on-site technical assistance is necessary;
-
normal OS operation is interrupted.
The proposal is to re-program a flash directly from Linux, where web interface-based updating could be very convenient option.
The article describes how to implement flash chip access from a Linux application.
Read more »
About: How to port a package from RPM-based system (like Red Hat Enterprise Linux / Fedora) to the ELDK (Embedded Linux Development Kit).
Preface
The Embedded Linux Development Kit (ELDK) includes a number of pre-built target tools and libraries necessary to provide some functionality on the target system. In most cases users need more packages for their systems ELDK maintainers don’t provide. There are two possible solutions here:
-
Compile and install manually. It’s OK if you need something small like tinyproxy, but it could be a problem for packages requiring special post-installation procedure or including >100 files to be installed (biggest problem is further removal/updating). Finally, if we don’t use package managing system ELDK provides then it makes no sense to use ELDK at all – can simply take cross-compiler and build the system by hand.
-
Build target package for ELDK. Means following a specific building procedure. Can be performed on existing ELDK installation without changing of installed components unless special dependencies management required.
Lab: Porting TCL package to ELDK
As an example, I’m going to show how to port TCL package to ELDK, step by step.
Read more »
About: Peripheral DMA transfer implementation in Linux driver from a scratch on example of PPC4xx Embedded Core.
Transfer evaluation
DMA transfer implementation usually derives from transfer characteristics. That’s why first thing to do is to evaluate the transfer itself.
Step 1. Define transfer characteristics.
-
Direction – CPU-sourced or peripheral-sourced (or both). Technically, there’s no big difference in transfer implementation depending on its direction: in CPU-sourced transfer you put data to the buffer and then perform DMA operation, in peripheral-sourced – perform DMA operation and then take data from the buffer.
-
Packet size (min and max) – data portion size.
-
Average rate = min ( potential writer rate, potential reader rate)
-
Direction: CPU-sourced. Data writer is a user application (via write()/writev() syscall) or kernel, data reader is a peripheral. Writer rate should be limited to fit in with reader rate, for example, by blocking writer inside write() syscall while no buffer space available; reader limits transfer rate by controlling DMA request line i.e. signaling when it’s ready to receive a data.
-
Direction: peripheral-sourced. Data writer a peripheral, data reader is a user application (via read()/readv() syscall) or kernel. Writer rate usually can’t be limited without data dropping (peripheral internal buffer is usually very small).
-
Latency (max) – maximum time data transfer takes.
-
Buffer memory available – how much memory driver can use for buffer space according to requirements.
-
Synchronization (sync/async) – sync: writer process is suspended during active DMA transfer performing; async: writer process is allowed to write during active DMA transfer performing (data is collected by the driver internally, new transfer starts asynchronously to the writer). It makes sense to use synchronous model only for CPU-sourced transfers
-
Usage – is the transfer a permanent part of embedded system operation or just a loadable feature.
Read more »
