help! (remotebooting rtems)

Sun Aug 18 17:51:02 UTC 2002

"ÖÐÊ¿" wrote:
> 
> Hi,I am a newbie in RTEMS and
> want to download the file hello.bt
> to the target(pc386).but When I
> use netboot(following the netboot
> document-installation), it does not
> fully work.
> Can you describe the process
> in detail or give me some suggestions?
> (especially how to make the boot image)
> 
> Some information on the target computer's
> screen is below:
>   BOOTP: Sending request (Press ESC to abort):ok
>   Local IP: 192.0.2.51
>   Server IP: 192.0.2.149(lzs)
>   Loading /root/boot/bootImage-client
> then the target computer stops.
> 
> Thanks a lot in advance!
> 
>      Bert
>               doclzs at fm365.com

Hi,

Since your netboot rom is requesting the bootimage, and it doesnt get
bootimage (because after this either rtems's hello.bt should execute or
rtems should give an error had the image been loaded) the fault would be
in configuration of the tftpserver.

Below is an extract from a documentation i wrote for my lab dealing with
server setup for remotebooting rtems.

note the file im keeping .bt image is in /tftboot/lts/vmlinuz.ne2000 ,
(its actually rtems image.)

and all .bt images made as default by rtems makefile should work and are
netbootable. 
to crosscheck, if an image is correct or not u can use command
file hello.bt

anyway, check your server configuration using following ->

Extract Begin: 
***remotebooting the 486pc inside robot for rtems control code transfer
****

3. Server Setup
---------------
	This step involves
	1) BOOTP server configuration  (Bert, you may skip this...)
	2) TFTP server configuration
	3) keeping the image at the correct location 
	   ( ie. /tftpboot/lts/vmlinuz.ne2000 on the server)

I observe that Redhat has stopped giving BOOTP Daemon after version
5.2. and everyone is migrating to DHCP Daemon.

We still use the BOOTP from version 5.2 for 2 reasons:
	     1. Netboot asks for BOOTP (which dhcp could cater to also)
	     2. But BootPd is very simple to configure

3.1)  Bootp server configuration:
----------------------------------
hence we install Booptd rpm from the Redhat 5.2 distribution.

the file /etc/bootptab should be as follows:
#---------------------------------------------
.ltsp:\
  :ht=ethernet:\
c  :ds=144.16.101.208:\
  :gw=144.16.101.208:\
  :lg=144.16.101.208:\
  :sm=255.255.255.0:\
  :hn:\
  :hd=/tftpboot/lts:\
  :rp=/tftpboot/lts/ltsroot:
#
mission:t=.ltsp:ha=008048A81631:bf=vmlinuz.ne2000:ip=144.16.101.203:
#---------------------------------------------

Details of what these fields mean could be seen in man pages of
bootpd. 
For now its sufficient to say that the Remote Booted Machine
would be called Mission, with IP 144.16.101.203.
"ha" is THE hardware address of the network card currently being used.
If the card changes, this field "Needs To Be Changed".

3.2) TFTP Server Configuration
-------------------------------
This is the tricky part when the Server is Redhat 7.2.

First we see how i did it in RedHat 6.2

  For RedHat 6.2
---------------
	Simply uncomment the 2 lines in /etc/inetd.conf which begin with 
	# bootp...
	# tftp...
by removing the # marks.

Install the tftp-server RPM which came with RedHat 6.2

  For RedHat 7.2
--------------------
After version 7.0, Redhat uses 'xinetd superserver' instead of 'inetd
superserver.'

But the tftp-server which comes with redhat 7.2 does not work properly
(at-least for our walking machine it DID NOT WORK, and it took 2
full days to get tftpserver working which was got from etherboot later)

Hence the following steps are needed to set the server in RedHat 7.2

i)  Install the tftp-server RPM which came with RedHat 7.2

ii) The file named "tftp" in /etc/xinetd.d/ should contain:
#------------------------------------------------------------
# description: The tftp server serves files using the trivial file
transfer \
#	protocol.  The tftp protocol is often used to boot d \
#	workstations, download configuration files to network-aware printers,
\
#	and to start the installation process for some operating systems.
service tftp
{
	disable	= no
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
inetd	server			= /usr/sbin/in.tftpd
#	server_args		= 
	only_from		= 144.16.101.203	
}
 #---------------------------------------------

 It is evident that we are allowing only Mission to tftp the files from
 server. (security, as tftp is a common hacker's tool)

 Now we have configured the xinetd properly. *But we need to get a good
 and working tftpserver. this is done as follows*

 iii) Download Ethetboot source-code from etherboot.sourceforge.net
 and after untaring the source , we cd to "contrib/tftp" directory in
 the source.
 Here we run: 
 make
 make install

 this compiles and the then copies the tftpserver in /usr/sbin

 Now we have configured the boopt server and tftp server.
 Only few more things remain.

 3.3) Setting the Hosts* files
 ----------------------------
 This step is common to both Redhat 6.2 and 7.2

 The /etc/hosts file should contain a line:
 144.16.101.203  mission.me.iitb.ac.in           mission 

 The /etc/hosts.allow file should "at-least" contain the lines:
#--------------------------------------------------------
# hosts.allow	This file describes the names of the hosts which are
NET#		allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#
bootpd:    0.0.0.0
in.tftpd:  144.16.101.
portmap:   144.16.101.
ALL: 144.16.101.
#--------------------------------------------------------------

the /etc/hosts.deny file should contain
#-----------------------------------------
# hosts.deny	This file describes the names of the hosts which are
#		*not* allowed to use the local I services, as decided
#		by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
ALL: 192.168.
ALL: ALL
#--------------------------------------

Here we have allowed all connections from the Mechanical dept. and
denied all connection from Hostels and everywhere else.

4. Boot Images
----------------------
The boot image to be tranferred might be 
a) A QNX boot Image
b) A Linux Kernel Boot Image 
c) An RTEMS image with the control program (The current Robot control
program is based on this, and above 2 are just for       sake of
information useless things)

For debugging i find RTEMS most effective, fast and hassle free.
Two boot images of RTEMS are placed in /tftpboot/lts (and
shall also be there in the cd-rom) which are most useful for debugging
the hardware without adding harddisk to 486 etc.

The file README in the /tftpboot/lts shall always contain the up-to-date
description of these images and any new ones.

<snip>

regards
Vivek 

========================================================================
Vivek Vaid
                                  |
Research Assitant                 |     M. Tech. Student
Robotics Lab                      |     Control & Instrumentation
Dept. of Mechanical Engineering   |     Dept. of Electrical Engineering
                                  |
Indian Institute of Technology, Bombay
Powai, Mumbai, 400076
_______________________________________________________________________
-------------- next part --------------

		  WALKING MACHINE REMOTE-BOOT HOW-TO
	      =========================================
Vivek Vaid <vaid at me.iitb.ac.in>
Robotics Lab
IIT Bombay  						 Jan. 20, 2002
----------------------------------------------------------------------

This document illustrates the tips, experiences and tricks of Remote
Booting the Walking Machine's on-board controller PC (486).

---------------------------------------------------------------------

			       Contents
			       --------
1. Hardware Architecture
   1.1 Overall View
   1.2 Overall Operation
   1.3 486-PC on the Robot   
2. Firmware 
3. Server Setup
   3.1  Bootp server
   3.2	Tftp server (Redhat 6.2 and 7.2)
   3.3  hosts* files	  
4. Boot Images

---------------------------------------------------------------

1. Hardware Architecture
==========================

1.1 Overall View
----------------

	PC(486)========peer2peer-cable==========PC(server)

The 486-PC on the robot is connected to the Server (main PC) via a
Peer-to-peer cable. 

The use of peer-to-peer cable eliminates the need of the Hub, and
makes a direct, fast and secure link between the 2 PCs. 

Alternatively the 486-PC could be directly connected to department's
network via a hub or switch and the Server could be connected to
dept. network. (This approach connects the robot to the dept. net. So
the server program could be run from anywhere outside the robotics-lab
too. A potential security threat. And if there is clash on the
dept. net. it would affect our robot too)

1.2 Overall Operation
---------------------

1) The 486 sends a BOOTP broadcast request on the network 
2) The server sees that the "Hardware-Address" of the network
   card requesting for boot is the same as it has been configured to
   respond to. So the server allocates the 486-PC an IP address. 
		    (currently: 144.16.101.203; mission.me.iitb.ac.in). 
3) Now the 486 requests for tftp download of the image file of the
   operating system. This image might (or shall) contain the Low-Level 
   controller program too.
		   (currently this file has to be named as:
		   /tftpboot/lts/vmlinuz.ne2000 on the server)
4) After the image is transferred, the operating system starts and
   takes the control of the system.

In steps 1-3 above, requests etc. are all made by the boot-rom on
Network-Card on the 486.

1.3 486-PC on the Robot
-----------------------
The 486 PC on the Walking Machine has only ISA slots.
Hence the Ethernet network-card which goes in it is ISA only.

Currently the card being used is: Readylink 
				  (NE2000 compatible)
The IO Port of this card is =  0x280
	       		IRQ = 11
It is IMPORTANT that the IO Port of any network card, used in this PC be 0x280
or set to that value.
The reason for this is that all the motor control-io cards in this pc have
addresses: 200, 220, 240, 300, 320, 340
The irq does not matter as it is not being used the the control
hardware/software.

2. Firmware
-----------

The Boot-Rom firmware is a free-ware code Netboot.
(available at http://netboot.sourceforge.net/)  - OpenSource

The Boot-Rom chip (EPROM CHIP) currently is a 16KB eprom (IC Number:
M27c256)
"Any 16KB eprom" could be made in the boot-rom needed by us as follows:

	 1. Download and Install Netboot (NO Compilation is needed)
	 2. read the docs of netboot and run the script
	 3. The script will ask what kind of network card we have and
	 its IO port number and IRQ number
	 (current values are NE2000, 0x280 & 11)
	 4. The script shall finall generate a ".bin" file. 
	 5. The ".bin" file is the binary file which is burned in the
	 chip using the EPROM programmer of the lab.

When this chip is placed in the network-card with the above IO port
and IRQ, and the card is put in PC, on Power On, the card should make
BOOTP requests.
This could be First Diagnostic Step about the Network Card, and PC. 
Even without any network connection, the PC's screen should show:
" BOOTP: Sending request (press ESC to abort):...."

If it finds the BootP server, it will immediately download the image
and the above message wont be seen.

 There are other and newer Open-Source programs (firmware) like
 EtherBoot, which are better in the sense that they find the IO port
 and IRQ of the card themselves.
However, I was found the Ether-boot didnot recognize the QNX image
 correctly and netboot did. Hence we use netboot.
Both the firmwares are very popular and can recognize the image of
almost any os. 

3. Server Setup
---------------

	This is long step. It involves
	1) BOOTP server configuration
	2) TFTP server configuration
	3) keeping the image at the correct location 
	   ( ie. /tftpboot/lts/vmlinuz.ne2000 on the server)