Lantronix EDS2100 Linux SDK - User Guide - Page 29

Con the Boot Loader for JFFS2 as Root Partition - user manual

Page 29 highlights

4 Supported File Systems Configure the Boot Loader for JFFS2 as Root Partition To tell µClinux kernel to look for a JFFS2 root file system, the kernel command line (kcl) has to be set accordingly. To validate this, boot the target into dBUG and issue the following command: dBUG> show watchdog: on ... kcl: rootfstype=romfs If kcl is not set to "noinitrd rw rootfstype=jffs2 root=/dev/mtdblock5" it can be fixed by issuing the command dBUG> set kcl noinitrd rw rootfstype=jffs2 root=/dev/mtdblock5 and the target will try to mount its root file system from the JFFS2 partition. NFS µClinux comes with support for mounting directories from a remote computer via NFS. This can be very useful in many scenarios:  To speed up development: mount the development directory on the target from the host to eliminate time consuming manual transfer of the compiled files via ftp or scp.  To save data permanently (e.g. for logging or backing up data to a server) Be aware that most sample profiles provided by Lantronix do not include support for NFS to save precious RAM. Depending on the chosen profile, you might have to activate the relevant configuration switches in the Linux kernel:  CONFIG_NFS_FS  CONFIG_NFS_V3  CONFIG_NFS_COMMON  CONFIG_IP_PNP_DHCP (optional)  CONFIG_IP_PNP_BOOTP (optional) NFS as root File System - The Option for Development Mounting the whole root file system via NFS can be a great time saver. Without it, a typical development cycle would look like this: 1. Make a minor change to an application. 2. Create a new firmware image. 3. Flash it to the device (MatchPort AR, XPort Pro, or EDS1100 / 2100). 4. Reboot. 5. Validate the changes. Consequently the developer would waste productive time with tedious tasks. Thus, we recommend using the NFS as a root file system during development and debugging. This allows the developer to try out the changes on the device as soon as they are compiled. If none of the core components (kernel and BusyBox) were modified, the target does not even have to be rebooted. Linux Software Developers Kit (SDK) User Guide 29

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76

4 Supported File Systems
Linux Software Developers Kit (SDK) User Guide
29
Configure the Boot Loader for JFFS2 as Root Partition
To tell µClinux kernel to look for a JFFS2 root file system, the kernel command line (kcl) has to be
set accordingly. To validate this, boot the target into dBUG and issue the following command:
dBUG> show
watchdog: on
...
kcl: rootfstype=romfs
If kcl is not set to “noinitrd rw rootfstype=jffs2 root=/dev/mtdblock5” it can be fixed by issuing the
command
dBUG> set kcl noinitrd rw rootfstype=jffs2 root=/dev/mtdblock5
and the target will try to mount its root file system from the JFFS2 partition.
NFS
µClinux comes with support for mounting directories from a remote computer via NFS. This can
be very useful in many scenarios:
To speed up development: mount the development directory on the target from the host to
eliminate time consuming manual transfer of the compiled files via ftp or scp.
To save data permanently (e.g. for logging or backing up data to a server)
Be aware that most sample profiles provided by Lantronix do not include support for NFS to save
precious RAM. Depending on the chosen profile, you might have to activate the relevant
configuration switches in the Linux kernel:
CONFIG_NFS_FS
CONFIG_NFS_V3
CONFIG_NFS_COMMON
CONFIG_IP_PNP_DHCP (optional)
CONFIG_IP_PNP_BOOTP (optional)
NFS as root File System – The Option for Development
Mounting the whole root file system via NFS can be a great time saver. Without it, a typical
development cycle would look like this:
1.
Make a minor change to an application.
2.
Create a new firmware image.
3.
Flash it to the device (MatchPort AR, XPort Pro, or EDS1100 / 2100).
4.
Reboot.
5.
Validate the changes.
Consequently the developer would waste productive time with tedious tasks. Thus, we
recommend using the NFS as a root file system during development and debugging. This allows
the developer to try out the changes on the device as soon as they are compiled. If none of the
core components (kernel and BusyBox) were modified, the target does not even have to be
rebooted.