world leader in high performance signal processing
Trace: » micromonitor

MicroMonitor

Generically speaking...

MicroMonitor (aka uMon) is a free embedded system boot platform centered around an extensible embedded flash file system called TFS. With TFS intrinsic to the monitor, all data access can be name based instead of address based. Data transfer protocols like XMODEM and TFTP (also in the monitor) can refer to filenames instead of address space. The whole boot-up strategy is driven by the content of one or more files that can be scripts or executable images. The file system is accessible at the command line and through an API available to the application. The API provides a flexible means of reading and writing files in flash, plus TFS provides power-safe runtime defragmentation as the flash fills up. Refer to this white paper for a usage example.

In the nutshell, uMon presents the embedded system to a user the same way DOS presented the PC to a user. Ok, don't run away, just yet, hear me out first!… While a comparison to DOS may seem archaic these days, if you think about a basic embedded platform its really a pretty nice startup. You immediately have a command line interface/shell, flash file system, network access (assuming the hardware supports that), text-based scripting, a programming API to eliminate the user's need to know much about the hardware (for the generic interfaces) and even an ASCII based file editor on board.

A network-accessible, MicroMonitor-based embedded system provides a firmware development project with immediate network boot (DHCP/BOOTP), file based maintainability, infield upgrade and in-system diagnostics. The boot flash footprint size typically ranges from 64K to 256K depending on the configuration.

Blackfin Specifics...

MicroMonitor is distributed as a tarball, and has a 350+ page user manual. Both are available at the Micromonitor Home Page or the Microcross Web Site. After untarring the code, the BF537 port is found under umon_ports/bf537. Always refer to the README and makefile in that space for the most up-to-date information. Here's a quick summary of the BF537 port…

The BF537 port of uMon can be built to run launched by other bootloaders or it can be built to run standalone. There is a procedure included in the BF537 port (refer to that port's makefile) that walks the user through the steps to install uMon over top of u-boot, resident in flash (mode-0 boot), or it can be installed using mode-7 (UART) boot. This mode-7 method is also useful for cases where the boot flash has been corrupted and hence needs to be re-installed. Once installed on the target, the user can jump over to umon_apps/demo directory (part of the tarball) and immediately install a demonstration application that gives examples for accessing the flash file system, retrieving environment variables, interacting with argc/argv command line args, and even how to get some recovery information (i.e. a stack trace) in the event of some unexpected exception. There are other demonstration apps that are peer to the umon_apps/demo directory, like an example usage of UIP-based webserver; a BASIC interpreter, etc… Once you get the hang of the demo application, it will be pretty clear what you can do out-of-the box with uMon.

The BF537 port has been used to boot standalone (os-less) applications as well as uCLinux, uC/OS-II and VDK based applications. The application gets installed into TFS's file system as a (stripped) elf file and TFS's loader knows about Blackfin's L1 space and will appropriately load text areas destined for L1 using Blacfin DMA. All the typical uMon-generic debugging capabilities are supported except that as of this writing (Aug 2008), uMon does not have a Blackfin disassembler.

For Example...

Lets assume you have uMon on the BF537 EZ-Kit eval board…
At bootup you see the following opening message:

                    MICRO MONITOR 1.15.16
                  Platform: ADDS-BF537-EVAL
                    CPU: BlackFin BF537
                Built: Aug 12 2008 @ 15:17:40
              Monitor RAM: 0x3f2e364-0x3f464e0
               Application RAM Base: 0x100000
                   MAC: 00:e0:22:fe:4c:c9
                     IP: 135.222.138.21
uMON>

To see the files currently stored in TFS, just type “tfs ls”…

uMON>tfs ls
 Name                        Size   Location   Flags  Info
 /cmdresptop.html             437  0x200602cc
 /index.html                  637  0x200604ec
 /page.html                   706  0x2006085c
 /umonheader.jpg            12431  0x20060b7c
 camera                    130004  0x201e12dc  E
 monrc                        530  0x2006005c  e
 uclinux.scr                  547  0x202020bc  e

Total: 8 items listed (145341 bytes).
uMON>

The above listing is from a system that is ready to boot uCLinux or a simple standalone application. There are a few files that are used by an application that has an HTTP server that directly accesses TFS's files. The executable application is called 'camera', and it is known to be an executable ELF file because its 'E' flag (4th collumn in the listing) is set.

Notice the 'monrc' file. Use “tfs cat monrc” to dump its content…

uMON>tfs cat monrc
set IPADD 135.222.138.21
set NETMASK 255.255.254.0
set GIPADD 135.222.138.1
set CAMERA_SRVRIP 135.222.138.206
uMON>

The monrc file (monitor run-control file) automatically runs at startup and simply sets up the environment used by both the monitor and the application. In the above case, IPADD, NETMASK & GIPADD are used to set up the network (for both monitor and application), and CAMERA_SRVRIP is a variable that will be used by the camera application to tell it what server to connect to.

Finally, once again referring to the output of “tfs ls” above, notice the uclinux.scr file. This is a script (similar to monrc), but it is used to launch uClinux using the images/linux-initramfs.gz ELF file…

uMON> tfs cat uclinux.scr
tftp SRVR_IP_ADDRESS get linux-initramfs.gz 0x3000000
heap -m 256
set CMDLINE $MALLOC
pm -s $CMDLINE "ip=$IPADD::$GIPADD:$NETMASK:BF537:eth0:on"
tfs -v ld 0x3000000,E
ether off
call $ENTRYPOINT $CMDLINE
uMON>

In this script, the image is downloaded from the TFTP server at IP address 'SRVR_IP_ADDRESS' and placed in RAM at 0x3000000 (see note below). A small block of memory is allocated off uMon's heap to create a command line based on the shell variables already established in the environment (IPADD, GIPADD & NETMASK). Then, the ELF formatted image located at 0x3000000 is loaded by TFS, the monitor's ethernet driver is turned off and control is turned over to the entrypoint of the just-loaded ELF image.

Note1: in this case the file 'linux-initramfs.gz' is too big to put in the eval board's flash, so we load it directly into RAM, and use TFS's ability to load elf right out of raw memory. Had the file been small enough (or the flash big enough), then the 0x3000000 could have been replaced with a filename (destined for TFS space). The point here is that it can work in several different ways.
Note2: the 'linux-initramfs.gz' file is ELF. The .gz suffix here is a bit misleading. It indicates that the section that makes up the initial ramfs is compressed, not that the entire file is compressed. So, the ELF file may contain symbols that can be removed by running 'bfin-elf-strip' on the file (this can sometimes be a significant reduction). Further, uMon allows the sections within the ELF file to be compressed; however, this requires some pre-processing of the file using a uMon-supplied tool called 'elf'. Running the command 'elf -z6 linux-initramfs.gz' will compress each of the sections within the ELF file, but still maintain the ELF structure. The result is a file further reduced in size, with the name linux-initramfs.gz.ezip. This file can be used by TFS also, it simply requires that TFS be told it is compressed by includeing the 'c' flag.

Either way, this script successfully loads the image and boots uClinux on the BF537 EZ-Kit.
The console output looks something like this…

                            _____________________________________
        a8888b.           / Welcome to the uClinux distribution \
       d888888b.         /       _     _                         \
       8P"YP"Y88        /       | |   |_|            __  __ (TM)  |
       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /       |
       8'    .88       \        | |   | |  _ \| | | | \  /        |
       8`._.' Y8.       \       | |__ | | | | | |_| | /  \        |
      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\       |
     dP   .    Y8b.       \   For embedded processors including   |
    d8:'  "  `::88b        \    the Analog Devices Blackfin      /
   d8"         'Y88b        \___________________________________/
  :8P    '      :888
   8a.   :     _a88P         For further information, check out:
 ._/"Yaa_:   .| 88P|            - http://blackfin.uclinux.org/
 \    YP"    `| 8P  `.          - http://docs.blackfin.uclinux.org/
 /     \.___.d|    .'           - http://www.uclinux.org/
 `--..__)8888P`._.'  jgs/a:f    - http://www.analog.com/blackfin

Have a lot of fun...


BusyBox v1.4.1 (2008-08-21 17:20:16 EDT) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

root:/> 

The following sites have more documentation and a tarball with the uMon source…
Have fun!

More information...

Also, check out uCon, a terminal emulator suited for embedded development…