How to keep networking functionality when booting from ramdisk on EVMDM365 ?

Hi Jinh,

You can set static or dhcp ip address : 
ip=dhcp
or
ip=192.168.2.111:192.168.2.33:192.168.2.1:255.255.255.0:::off

for nfs:
setenv bootargs 'console=ttyS0,115200n8 noinitrd ip=192.168.2.111:192.168.2.33:192.168.2.1:255.255.255.0:::off root=/dev/nfs rw nfsroot=192.168.2.33:/home//workdir/filesystems mem=60M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=0 davinci_capture.device_type=1'

Marko.

Hi Marko, this is waht we have been running and tried on the ramdisk:

1)When running from NFS server my uboot environment looks like this and my app transmits UDP broadcast at 50Hz on vsync int:

DM365 EVM :>printenv

bootdelay=4

baudrate=115200

bootfile="uImage"

ethaddr=00:0e:99:02:ca:73

bootcmd=tftp;bootm

rootpath=/home/gvi/workdir/filesys

serverip=196.1.6.108

ipaddr=196.1.6.105

nfshost=196.1.6.108

bootargs=console=ttyS0,115200n8 noinitrd rw ip=196.1.6.105 root=/dev/nfs nfsroot=196.1.6.108:/home/gvi/workdir/filesys,nolock mem=76M video=davincifb:vid0=720x576x16,2500K@0,0:vid1=720x576x16,2500K@0,0:osd0=720x576x16,2025K@0,0:osd1=360x200x16,2025K@300,300 dm365_imp.oper_mode=0 davinci_capture.device_type=4 davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal

stdin=serial

stdout=serial

stderr=serial

ver=U-Boot 1.3.4 (May 22 2009 - 11:25:39)

Environment size: 647/262140 bytes

2) The app also works fine when we do the guide's story to make it autorun.

3)When we want to run from ramdisk over tftp from server, we cahnge the boot environment with the following:

setenv bootcmd 'tftp 0x82000000 ramdisk.gz; tftp 0x80700000 uImage; bootm 0x80700000'

setenv serverip 196.1.6.108

setenv ipaddr 196.1.6.105

setenv nfshost 196.1.6.108

setenv rootpath /home/gvi/workdir/filesys

setenv bootargs console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x82000000,10M ip=off mem=76M video=davincifb:vid0=720x576x16,2500K@0,0:vid1=720x576x16,2500K@0,0:osd0=720x576x16,2025K@0,0:osd1=360x200x16,2025K@300,300 dm365_imp.oper_mode=0 davinci_capture.device_type=4 davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal

Here my app does not want to transmit the UDP's and sendto( ) returns an error.  Teh we changed the bootargs to the following to have an IP:

setenv bootargs console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x82000000,10M ip=196.1.6.105 mem=76M video=davincifb:vid0=720x576x16,2500K@0,0:vid1=720x576x16,2500K@0,0:osd0=720x576x16,2025K@0,0:osd1=360x200x16,2025K@300,300 dm365_imp.oper_mode=0 davinci_capture.device_type=4 davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal

When booting into this environment, the message from the kernel says: "Sending DHCP and RARP requests..... timed-out!" "IP-Config: Reopening network devices...." and starts again with Sending DHCP. When we changes the bootargs to ip=dhcp it does the same but without the RARP: "Sending DHCP requests....."

The ramdisk was created from the PSP demo.  We are suspecting something in the filesystem that configures the networking to be wrong and am looking at making our own filesystem to ramdisk.  Would that solve our problem or can you see something wrong in our booting or bootargs?

Thanks, Jinh T.

Thanks Marko, it works now!

Can you explain why or where I can go read why?  What does it do with all the addresses its fed?

 Your help is much appreciated!

Thanks, Jinh T. (going home now and will continue tomorrow)

Hi Jinh,

You can read about that in Linux \Documentation\nfsroot.txt

Copy/past from there:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

  This parameter tells the kernel how to configure IP addresses of devices
  and also how to set up the IP routing table. It was originally called
  `nfsaddrs', but now the boot-time IP configuration works independently of
  NFS, so it was renamed to `ip' and the old name remained as an alias for
  compatibility reasons.

  If this parameter is missing from the kernel command line, all fields are
  assumed to be empty, and the defaults mentioned below apply. In general
  this means that the kernel tries to configure everything using
  autoconfiguration.

  The <autoconf> parameter can appear alone as the value to the `ip'
  parameter (without all the ':' characters before) in which case auto-
  configuration is used.

  <client-ip> IP address of the client.

    Default:  Determined using autoconfiguration.

  <server-ip> IP address of the NFS server. If RARP is used to determine
  the client address and this parameter is NOT empty only
  replies from the specified server are accepted.

  Only required for for NFS root. That is autoconfiguration
  will not be triggered if it is missing and NFS root is not
  in operation.

  Default: Determined using autoconfiguration.
           The address of the autoconfiguration server is used.

  <gw-ip> IP address of a gateway if the server is on a different subnet.

  Default: Determined using autoconfiguration.

  <netmask> Netmask for local network interface. If unspecified
  the netmask is derived from the client IP address assuming
  classful addressing.

  Default:  Determined using autoconfiguration.

  <hostname> Name of the client. May be supplied by autoconfiguration,
    but its absence will not trigger autoconfiguration.

    Default: Client IP address is used in ASCII notation.

  <device> Name of network device to use.

  Default: If the host only has one device, it is used.
    Otherwise the device is determined using
    autoconfiguration. This is done by sending
    autoconfiguration requests out of all devices,
    and using the device that received the first reply.

  <autoconf> Method to use for autoconfiguration. In the case of options
                which specify multiple autoconfiguration protocols,
  requests are sent using all protocols, and the first one
  to reply is used.

  Only autoconfiguration protocols that have been compiled
  into the kernel will be used, regardless of the value of
  this option.

                  off or none: don't use autoconfiguration (default)
    on or any:   use any protocol available in the kernel
    dhcp:        use DHCP
    bootp:       use BOOTP
    rarp:        use RARP
    both:        use both BOOTP and RARP but not DHCP
                 (old option kept for backwards compatibility)

                Default: any

Hi Marko,

when I boot the board like this, what do I have to do to still be able to do a SSH login ?

I am now busy with the SD card things and need to get the device name of the sd card.  Is there a way to see it through ubuntu and my card reader interface or is it best to plug it into the board and read it this way?  If so, how do I read the SD card's device name in linux on commandline?  This is why I need to have a session with the board.

Thanks, Jinh T.

Hi Jinh,

Console on ttyS0 should work.
You can also use telnet from PC.
Just type in console :  telnet -> open -> boardipaddress -> yourlogin.
You can see plugged device with dmesg command, probably it's mmcblk0.

Marko.

Hi Marko,

I confirmed that I can get in with telnet when booting from nfs server but when autobooting from ramdisk via tftp on server I get response"telnet: Unable to connect to remote host: Connection refused".  Is there anything wrong in the filesystem it is running from then on booting from ramdisk?  Or should I add/change anything in bootargs to enable remote connection?

Thanks, Jinh T.

Hi Marko,

I checked the following: I disabled the autorun when booting from ramdisk over tftp and get to a login on my uboot terminal.  Login as root I can then manually load modules and run my app which does its UDP transmissions.  Trying then to establish a telnet from a different terminal connects but doesn't frovide any functionality, I can basically exit with its ^] and again out of the telnet back to the host terminal.  What process is skipped on doing the autorun that enables remote sessions?

Thanks, Jinh T.

Hi Jinh,

To connect with telnet, program telnetd must be running on the board.
It's usaully in /usr/sbin/telnetd.
If you can use serial  console, then type command "top"  to see all running processes.
You should see telned running.
Or maybe there is some error in initialisation scripts, and telnetd is not started.
Then check  init.d initialisation scripts.

Regards, Marko.

Hi Marko,

we were trying to overwrite some of the demo filesystem folders with ones from our development filesystem in workdir.  When we disable calling the autorun from rc.local, we can get in telnet and see inetd and telnetd running from top.  Copying too much from our huge filesystem breaks it eventually and trying to find the correct script by trial and error could possibly take a while.  We copied ssh and ssl from /etc as well as rc.d from our filesys to the demo/baserd filesys.  My feeling is to start from scratch and get it working from the server via nfs on a minimal filesys and to use that then for the ramdisk.  For development it would be good to have ssh cpability but eventually when it is a product it is not necessary as long as it can transmit UDP for my simulator and receive UDP for my product it will be fine.  We will try a couple of things now but let us know if you have suggestions what to check in the minimalistic filesystem to get ssh going. 

Thanks, Jinh T.

Hi Jinh,

I started with original filesystems from DVSDK 3.10 :
http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r37/images/dm365-evm/
http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel_Releases
or from PSP if you are using DVSDK 2. Those work for me.

First look at /etc/inittab, initialisation starts there, then follow the scripts.
Initialisation goes to rc(x).d folder which is set by initd default runlevel. Then check scripts in that runlevel folder (e.g /etc/rc5.d or /etc/rc.d/rc5.d),
then in /etc/init.d/rcS.

Regards,
Marko.

Thanks Marko.  This is very valuable info!  I was looking for this stuff since Friday when a colleague was helping me and he hase SUSE experience and the contractor with my now works with Slackware and RTLinux but none has embedded linux experience and all the stuff I get after googling around is quite broad and sometimes too vague to make sense in my embedded application.  Too much said anyway to try hide my incompetance but I will not let these penguins get the better of me.  We are busy with a Beyond Compare exercise to merge the demo filesys from PSP in DVSDK2 as we want to stay there for now and get the product finished.  There might be dragons hiding in 3.11 - do you know what kernel is used in 3.1 as I had some proposals to go over when I was having problems with video drivers toget my app working?   If it is still mvl 5 I might do it sooner than later if it is worth it.

Thanks, Jinh T.

Hi Jinh,

DVSDK 2.10.01.18 uses Linux kernel version 2.6.18, compiled with MontaVista5 tools,
DVSDK 3.10.00.19 uses kernel 2.6.32. ,  compiled with CodeSourcery 2009q1.

Regards,
Marko.

Hallo Marko,

our comparison tool does not like all the symblic lnks so that task went to a bit of a dead-end.  We had a quick look at the scripts but couldn't see why the ssh daemon doesn't get loaded.  We are now going to make a filesystem from scratch....we probably have to do it at least once in a lifetime and now is as good as ever so here we go!  If you have any tips please share with us else I'll certainly be posting on the forum for help.  As mentioned previously, we decided to stick with the DVSDK2 and mvl5 for now.  I see elsewhere some threads about filesystems but few on the one we're looking at for dm365 but the stuff for OMAP will probably be useful.  Is Busybox now the "standard" for utilities for starting a filesystem?

Thanks, Jinh T.

Hi Jinh,
Sorry, i have never created filesystem from a scratch, i 've always started from a demo fs.
http://processors.wiki.ti.com/index.php/Creating_a_Root_File_System_for_Linux_on_OMAP35x
http://focus.ti.com/lit/an/spraah2a/spraah2a.pdf

Regards,
Marko.

Hi Marko,

before going all out building a small filesystem from basics I tried to start with the demo filesystem from PSP and looked at the rc scripts and tried to modify but was not able to get the ssh going.  I in fact have something broken now so I will have to go a couple of steps back to get my capture device working - some fd get lost somewhere.....  Will try again on Monday.  It might have been the way I copied the scripts using the symblic links that doesn't work when I copied it over.  I used cp -sp but am not sure if it worked properly.

Thanks, Jinh T.

After my previous attempts from top down to copy stuff into the demo filesystem broke more things than got it working, I started with the demo filesystem again and worked from the bottom up this time.  First copied all files I thought was necessary for ssh.  Then tried to start it manually and sorted out missing libraries, provelege separation and shadow passwords, the sshd was running.  I then copied the scripts into rc.d and now have a filesystem than supports my ssh conection.  size increased from 5.6MB to 9.2MB.

Thanks all for your help on this issue.  Now its over to doing the SD card exercise...... Jinh T.