On many platforms, a ROM mode RedBoot image resides in the first flash sectors, working as the board's primary boot monitor. On these platforms, it is also normal to reserve a similar amount of flash for a secondary RAM mode image, which is used when updating the primary ROM mode image.

On other platforms, a ROMRAM mode RedBoot image is used as the primary boot monitor. On these platforms there is not normally reserved space for a RAM mode RedBoot image, since the ROMRAM mode RedBoot is capable of updating the primary boot monitor image.

Most platforms also contain a FIS directory (keeping track of available flash space) and a RedBoot config block (containing RedBoot board configuration data).

To see the amount of reserved flash memory, run the fis list command:

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0x00000000  0x00000000  0x00020000  0x00000000
RedBoot[RAM]      0x00020000  0x06020000  0x00020000  0x060213C0
RedBoot config    0x0007F000  0x0007F000  0x00001000  0x00000000
FIS directory     0x00070000  0x00070000  0x0000F000  0x00000000

To save flash resources, use a ROMRAM mode RedBoot, or if using a ROM mode RedBoot, avoid reserving space for the RedBoot[RAM] image (this is done by changing the RedBoot configuration) and download the RAM mode RedBoot whenever it is needed. If the RedBoot image takes up a fraction of an extra flash block, it may be possible to reduce the image size enough to free this block by removing some features.

RedBoot reserves RAM space for its run-time data, and such things as CPU exception/interrupt tables. It normally does so at the bottom of the memory map. It may also reserve space at the top of the memory map for configurable RedBoot features such as the net stack and zlib decompression support.

To see the actual amount of reserved space, issue the version command, which prints the RedBoot banner, including the RAM usage:

RedBoot> version

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 13:31:57, May 17 2002

Platform: FooBar (SH 7615)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.

RAM: 0x06000000-0x06080000, 0x06012498-0x06061000 available
FLASH: 0x00000000 - 0x00080000, 8 blocks of 0x00010000 bytes each.

To simplify operations that temporarily need data in free memory, the limits of free RAM are also available as aliases (aligned to the nearest kilo-byte limit). These are named FREEMEMLO and FREEMEMHI, and can be used in commands like any user defined alias:

RedBoot> load -r -b %{FREEMEMLO} file
Raw file loaded 0x06012800-0x06013e53, assumed entry at 0x06012800

RedBoot> x -b %{FREEMEMHI}
06061000: 86 F5 EB D8 3D 11 51 F2  96 F4 B2 DC 76 76 8F 77  |….=.Q…..vv.w|
06061010: E6 55 DD DB F3 75 5D 15  E0 F3 FC D9 C8 73 1D DA  |.U…u]…...s..|

To reduce RedBoot's RAM resource usage, use a ROM mode RedBoot. The RedBoot features that use most RAM are the net stack, the flash support and the gunzip support. These, and other features, can be disabled to reduce the RAM footprint, but obviously at the cost of lost functionality.

Each node in a networked system needs to have a unique address. Since the network support in RedBoot is based on TCP/IP, this address is an IP (Internet Protocol) address. There are two ways for a system to “know” its IP address. First, it can be stored locally on the platform. This is known as having a static IP address. Second, the system can use the network itself to discover its IP address. This is known as a dynamic IP address. RedBoot supports this dynamic IP address mode by use of either the BOOTP protocol, or a subset of the DHCP protocol. In this case, RedBoot will ask the network (actually some generic server on the network) for the IP address to use.

	Note
	Currently, RedBoot only supports BOOTP and a very simple form of DHCP which is limited to additional data items, not lease-based address allocation. If you wish to use this subset of DHCP, then ensure you the configuration option CYGSEM_REDBOOT_NETWORKING_DHCP is enabled in RedBoot's configuration.

If you are intending to use RedBoot for network debugging, and are also intending to use BOOTP or DHCP in the loaded application, then you should not also use BOOTP/DHCP with RedBoot. Otherwise the DHCP server is likely to give both RedBoot's and the application's network stacks the same IP address which will result in problems.

The choice of IP address type is made via the fconfig command. Once a selection is made, it will be stored in flash memory. RedBoot only queries the flash configuration information at reset, so any changes will require restarting the platform.

Here is an example of the RedBoot fconfig command, showing network addressing:

RedBoot> fconfig -l
Run script at boot: false
Use BOOTP for network configuration: false
Local IP address: 192.168.1.29
Default server IP address: 192.168.1.101
DNS server IP address: 192.168.1.1
GDB connection port: 9000
Network debug at boot time: false  

In this case, the board has been configured with a static IP address listed as the Local IP address. The default server IP address specifies which network node to communicate with for TFTP service. This address can be overridden directly in the TFTP commands.

The DNS server IP address option controls where RedBoot should make DNS lookups. A setting of 0.0.0.0 will disable DNS lookups. The DNS server IP address can also be set at runtime.

If the selection for Use BOOTP for network configuration had been true, these IP addresses would be determined at boot time, via the BOOTP protocol. The final number which needs to be configured, regardless of IP address selection mode, is the GDB connection port. RedBoot allows for incoming commands on either the available serial ports or via the network. This port number is the TCP port that RedBoot will use to accept incoming connections.

These connections can be used for GDB sessions, but they can also be used for generic RedBoot commands. In particular, it is possible to communicate with RedBoot via the telnet protocol. For example, on Linux®:

% telnet redboot_board 9000
Connected to redboot_board
Escape character is ’^]‚.
RedBoot>  

RedBoot may require three different classes of service from a network host:

Depending on the host system, these services may or may not be available or enabled by default.

In particular, on most Linux distributions, none of these services will be configured out of the box. As the method for configuring and enabling these services varies widely between Linux distributions and even between versions of the same distribution, the reader is advised to refer to the system documentation of your chosen Linux distribution and version for more details.

The Windows Desktop operating system does not provide these services. Instead these services are included with Windows Server. Please refer to your system administrator, or Microsoft TechNet, for details on how to configure these services on your Windows Server. Alternatively, if you do not have access to a Windows Server or Linux or do not wish to use either, you can use freely available MaraDNS, currently available from http://www.maradns.org/, to provide a DNS server and the Open TFTP Server, currently available from https://sourceforge.net/projects/tftp-server/, to provide a TFTP service on your Windows Desktop.

--------------- /etc/dhcpd.conf -----------------------------
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option domain-name-servers 198.41.0.4, 128.9.0.107;
option domain-name “bogus.com”;
allow bootp;
shared-network BOGUS {
  subnet 192.168.1.0 netmask 255.255.255.0
    {
       option routers 192.168.1.101;
       range 192.168.1.1 192.168.1.254;
    }
}
host mbx {
   hardware ethernet 08:00:3E:28:79:B8;
   fixed-address 192.168.1.20;
   filename “/tftpboot/192.168.1.21/zImage”;
   default-lease-time -1;
   server-name “srvr.bugus.com”;
   server-identifier 192.168.1.101;
   option host-name “mbx”;
} 

# service dhcpd start

--------------- /etc/named.conf -----------------------------
// generated by named-bootconf.pl

options {
  directory "/var/named";
  /*
   * If there is a firewall between you and nameservers you want
   * to talk to, you might need to uncomment the query-source
   * directive below.  Previous versions of BIND always asked
   * questions using port 53, but BIND 8.1 uses an unprivileged
   * port by default.
   */
  // query-source address * port 53;


  forward first;
  forwarders {
    212.242.40.3;
    212.242.40.51;
  };
};

//
// a caching only nameserver config
//
// Uncomment the following for Red Hat Linux 7.2 or above:
// controls {
//         inet 127.0.0.1 allow { localhost; } keys { rndckey; };
// };
// include "/etc/rndc.key";
zone "." IN {
  type hint;
  file "named.ca";
};

zone "localhost" IN {
  type master;
  file "localhost.zone";
  allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
  type master;
  file "named.local";
  allow-update { none; };
};

# service named start

# chkconfig named on

# systemctl start named

# systemctl enable named

Once your network setup has been configured, perform simple verification tests as follows: