Customising RC4.1 for DNS-320L rev A? & DNS-320 rev B2

[Andrew G]

I have been trying to build and customise Alt-F RC4.1 for DNS-320L rev A? & DNS-320 rev B2.
This topic has been opened so I can ask questions, make suggestions, etc.
Still trying to understand how all the svn/buildroot/make/etc work.

First suggested change (only effects developers). New builds can be loaded for testing using a serial console to control u-boot and telling it to download the kernel and rootfs images from a TFTP server. But it seemed a pity that after the kernel booted it still copied an older sqimage from the nand. So I tried to change the actions during init to also download the new sqimage from the same TFTP server. Patches for /etc/init.d/rcS and mkfw.sh attached, also console boot log attached (contains u-boot commands used).

I changed mkfw.sh to:-
Check for tftpboot folder at two "standard" linux tftp server locations, and to not error if none found.
Copy all three image files.
Ensure image files are world readable (required by tftp daemon).

I changed rcS to:-
Check for required tftp parameters in command line tag in /proc/atags.
If all tftp parameters are found it uses them to create a temporary network connection, and do the tftp download, header first (to check sqimage size) then rest of file, in a similar way to the nand code.
Also added a few logger calls.
If anything fails it uses the image from nand as normal.
For non-testing use it just checks /proc/atags, finds nothing interesting and continues normally.

Also needs tftp applet to be enabled in busybox build, I managed to do this, but I think I used a wrong method, it did not produce any change to any svn managed file.

What is correct command to reconfigure the busybox config?

The command line fom u-boot seems to be ignored by the kernel, because it is built with CMDLINE_FORCE option. So /proc/cmdline just shows the kernel's compiled in default. Also attached dump of /proc/atags, I think the kernel also changed the tags (that is why there is a gap in the middle), but did not completely clear the buffer, so seems to have left the tag containing u-boot's command line in the end of the buffer. It works, but not nice to rely on a kernel oddity.

I would have tried to pass the tftp information from u-boot in a u-boot environment setting, but haven't got fw_printenv/fw_setenv utility to read them from linux.

How do you tell the make system to build this u-boot utility and include it in the root fs?

Hope you like this suggestion, I thought testing would be easier if changes to all three image files could be tested without nand flashing.

I purchased a DNS-320L rev A3 (seemed worth a couple of pounds extra for more ram) and fitted headphone socket to serial console..
Found another tiny difference, DNS-320 is all black, DNS-320L has silver band for switches/leds (blank band for DNS-320LW).

[João Cardoso]

On Monday, January 19, 2015 at 3:02:37 AM UTC, Andrew G wrote:

I have been trying to build and customise Alt-F RC4.1 for DNS-320L rev A? & DNS-320 rev B2.
This topic has been opened so I can ask questions, make suggestions, etc.
Still trying to understand how all the svn/buildroot/make/etc work.

First suggested change (only effects developers). New builds can be loaded for testing using a serial console to control u-boot and telling it to download the kernel and rootfs images from a TFTP server. But it seemed a pity that after the kernel booted it still copied an older sqimage from the nand. So I tried to change the actions during init to also download the new sqimage from the same TFTP server. Patches for /etc/init.d/rcS and mkfw.sh attached, also console boot log attached (contains u-boot commands used).

Yes, that is helpful.

I would simplify the code a bit, mainly for space saving reasons. For the same reason I have to see how much does busybox size increases due to the tftp additions. This is an issue for the 323, which has only 8MB of flash and where every byte counts. literally!

 

I changed mkfw.sh to:-
Check for tftpboot folder at two "standard" linux tftp server locations, and to not error if none found.
Copy all three image files.
Ensure image files are world readable (required by tftp daemon).

I changed rcS to:-
Check for required tftp parameters in command line tag in /proc/atags.
If all tftp parameters are found it uses them to create a temporary network connection, and do the tftp download, header first (to check sqimage size) then rest of file, in a similar way to the nand code.
Also added a few logger calls.
If anything fails it uses the image from nand as normal.
For non-testing use it just checks /proc/atags, finds nothing interesting and continues normally.

Also needs tftp applet to be enabled in busybox build, I managed to do this, but I think I used a wrong method, it did not produce any change to any svn managed file.

make  menuconfig # to configure the build, uses/writes to ./config

make linux26-menuconfig # to fine configure linux, uses/writes $KERNEL/.config

make busybox-menuconfig # to fine configure busybox, uses/writes $BLDDIR/build_arm/busybox-1.20.2/.config

make uclibc-menuconfig # to fine configure uclibc, uses/writes $UCLIBC/.config

Changes will go to the build directory, not under svn control, you have to copy then to local/<board> or use 'saveconfig'. When changing boards, sourcing 'exports'  for a different board, it will be checked if modification were made and 'exports' will refuse to make changes.

The ./config file controls where to retrieve the uclibc, kernel and busybox config files, as some are shared for the different boards while others specific to a particular board, ./local/<board>

What is correct command to reconfigure the busybox config?

The command line fom u-boot seems to be ignored by the kernel, because it is built with CMDLINE_FORCE option.

There was a time where a kernel patch was applied that allowed to append (prepend?) args to the default kernel command line, but for some reason I have dropped that. You can still see traces of that in /init (it needs to be cleaned up). It would be better to resurrect that (for all boards) instead of using atags.

On the 321/323 (orion SoC), I use kexec to load a new kernel/rootfs instead of using tftp, but for some reason I was not able to make kexec work on the 320/325 (kirkwood Soc) -- that is something I would like to see fixed.

 

So /proc/cmdline just shows the kernel's compiled in default. Also attached dump of /proc/atags, I think the kernel also changed the tags (that is why there is a gap in the middle), but did not completely clear the buffer, so seems to have left the tag containing u-boot's command line in the end of the buffer. It works, but not nice to rely on a kernel oddity.

yes, a grep says that

# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set

CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/ram0 init=/init"

# CONFIG_CMDLINE_FROM_BOOTLOADER is not set

# CONFIG_CMDLINE_EXTEND is not set

CONFIG_CMDLINE_FORCE=y

# CONFIG_MTD_CMDLINE_PARTS is not set

CONFIG_CMDLINE_EXTEND could be a possibility, if extra options could be appended (or prepended?).

 

I would have tried to pass the tftp information from u-boot in a u-boot environment setting, but haven't got fw_printenv/fw_setenv utility to read them from linux.

How do you tell the make system to build this u-boot utility and include it in the root fs?

probably enabling that package using 'make menuconfig'. But again flash space is at a premium for the 323.

Something that might get un-noticed is that the makefile calls the ./configfs script after building packages and before creating the rootfs.

 

Hope you like this suggestion, I thought testing would be easier if changes to all three image files could be tested without nand flashing.

yes, definetively! Thanks.

I purchased a DNS-320L rev A3 (seemed worth a couple of pounds extra for more ram) and fitted headphone socket to serial console..
Found another tiny difference, DNS-320 is all black, DNS-320L has silver band for switches/leds (blank band for DNS-320LW).

And hasn't the 320 a better case/disk-slots also? I find the 320L very "cheap" in this respect.

Also I *hate* the 320L thermal design -- bad design, in my opinion, as no place for natural/convection cooling takes place, as the fan opening is not located at box top. By comparison with the 323/325 with the same disks, the 320L fan turns on/off much more frequently, and the disks get hotter.

[João Cardoso]

I can't "reproduce" your atags.

I have a u-boot cmd script saved in the u-boot environment, so I only need to type 'run alt' each time:

altf=setenv bootargs console=ttyS0,115200 root=/dev/ram0 init=/init; setenv ipaddr 192.168.1.100; setenv serverip 192.168.1.1; tftp 0xa00000 uImage; tftp 0xf00000 urootfs; bootm 0xa00000 0xf00000

My atags don't show any sign of u-boot environment variables except 'bootargs':

[root@dns-320l]# hexdump -Cv /proc/atags 

00000000  05 00 00 00 01 00 41 54  00 00 00 00 00 00 00 00  |......AT........|

00000010  00 00 00 00 04 00 00 00  02 00 41 54 00 00 00 10  |..........AT....|

00000020  00 00 00 00 04 00 00 00  02 00 41 54 00 00 00 00  |..........AT....|

00000030  00 00 00 00 04 00 00 00  02 00 41 54 00 00 00 00  |..........AT....|

00000040  00 00 00 00 04 00 00 00  02 00 41 54 00 00 00 00  |..........AT....|

00000050  00 00 00 00 0e 00 00 00  09 00 41 54 63 6f 6e 73  |..........ATcons|

00000060  6f 6c 65 3d 74 74 79 53  30 2c 31 31 35 32 30 30  |ole=ttyS0,115200|

00000070  20 72 6f 6f 74 3d 2f 64  65 76 2f 72 61 6d 30 20  | root=/dev/ram0 |

00000080  69 6e 69 74 3d 2f 69 6e  69 74 00 30 04 00 00 00  |init=/init.0....|

00000090  05 00 42 54 40 00 f0 00  00 50 2c 00 0f 00 00 00  |..BT@....P,.....|

000000a0  03 04 00 41 0e 00 06 03  ab 21 ef 09 00 84 d7 17  |...A.....!......|

000000b0  a9 c2 51 10 00 50 43 00  02 02 00 00 00 00 00 00  |..Q..PC.........|

000000c0  00 00 00 00 00 00 00 00  00 00 00 00 dc 05 00 00  |................|

000000d0  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|

000000e0

Have you customized the kernel in any way? Or is that a u-boot trick?

[Andrew G]

On Tuesday, 20 January 2015 16:11:18 UTC, João Cardoso wrote:

I would simplify the code a bit, mainly for space saving reasons. For the same reason I have to see how much does busybox size increases due to the tftp additions. This is an issue for the 323, which has only 8MB of flash and where every byte counts. literally!

I think busybox increased by 4k (666,424 to 670,520 bytes), an alternative is to build and include the standard tftp package in the root fs for the desired boxes.
The tftp options are different from busybox's applet. I will try this way instead, probably bigger than the busybox applet, but should be okay for boxes with big nand chips.
 

make  menuconfig # to configure the build, uses/writes to ./config

make linux26-menuconfig # to fine configure linux, uses/writes $KERNEL/.config

make busybox-menuconfig # to fine configure busybox, uses/writes $BLDDIR/build_arm/busybox-1.20.2/.config

make uclibc-menuconfig # to fine configure uclibc, uses/writes $UCLIBC/.config

 

Changes will go to the build directory, not under svn control, you have to copy then to local/<board> or use 'saveconfig'. When changing boards, sourcing 'exports'  for a different board, it will be checked if modification were made and 'exports' will refuse to make changes.

The ./config file controls where to retrieve the uclibc, kernel and busybox config files, as some are shared for the different boards while others specific to a particular board, ./local/<board>

Thanks, I used  "make busybox-menuconfig", did not know about the copy/save config bit.

There was a time where a kernel patch was applied that allowed to append (prepend?) args to the default kernel command line, but for some reason I have dropped that. You can still see traces of that in /init (it needs to be cleaned up). It would be better to resurrect that (for all boards) instead of using atags.

On the 321/323 (orion SoC), I use kexec to load a new kernel/rootfs instead of using tftp, but for some reason I was not able to make kexec work on the 320/325 (kirkwood Soc) -- that is something I would like to see fixed.

I had thought about "extend", it would be nice for development. But for most boxes it would cause the kernel to get both its default cmdline and also the cmdline d-link programmed into u-boot, not sure what would happen.

Another method would be to load all three images using u-boot, but could not see how to tell the kernel what to do with the extra image.

And hasn't the 320 a better case/disk-slots also? I find the 320L very "cheap" in this respect.

Also I *hate* the 320L thermal design -- bad design, in my opinion, as no place for natural/convection cooling takes place, as the fan opening is not located at box top. By comparison with the 323/325 with the same disks, the 320L fan turns on/off much more frequently, and the disks get hotter.

 
I think you are thinking of DNS-320 rev A, the rev B case is identical to DNS-320L, except for colour of switch band (and colour of hdd handles). The DNS-320 rev B is also rather faster than the rev A. I bricked the only DNS-320 rev A I had, totally dead, not even serial console. For my boxes running d-link stock fw + ffp, I have tweaked the fan temperatures up by 5ºC, in summer the fans never stopped, just blowing more warm air in.

My atags don't show any sign of u-boot environment variables except 'bootargs':

I extended bootargs, u-boot commands were:-

setenv ipaddr 192.168.61.139;setenv netmask 255.255.255.0;setenv serverip 192.168.61.227
tftp 0xa00000 uImage;iminfo;tftp 0xf00000 urootfs;iminfo;setenv bootcmd bootm 0xa00000 0xf00000
setenv bootargs $(bootargs) tftpipaddr=$(ipaddr) tftpnetmask=$(netmask) tftpserverip=$(serverip) tftpremotename=tsqimage
boot

Your "setenv bootargs console=ttyS0,115200 root=/dev/ram0 init=/init", is probably irrelevant because of the CMDLINE_FORCE.

u-boot tricks:-

u-boot does not like multiple lines pasted into console, seems to have problems receiving more chars whilst still executing the previous lines, concatenating into one line lets it get all chars in before execution starts

When messing with u-boot commands, use "setenv bootcmd bootm 0xa00000 0xf00000" rather than actually booting, so have chance to enter more commands, eg. printenv, before actually typing "boot"

u-boot always executes all commands separated by semicolons, eg. with "cmd1; cmd2; cmd3" all will be executed even if earlier commands fail. But for "setenv a1 cmd1; setenv a2 cmd2; setenv a3 cmd3" and "run a1 a2 a3" the later commands will NOT be run if earlier command fails. So could prevent booting if tftp fails, or could setup alternative boot methods, eg. "setenv bt boot" and "run a1 a2 a3 bt; run b1 b2 b3 bt"; run c1 c2 c3 bt" would try methods "a" then "b" then "c".

[Andrew G]

On Tuesday, 20 January 2015 17:10:15 UTC, João Cardoso wrote:

I have a u-boot cmd script saved in the u-boot environment, so I only need to type 'run alt' each time:

altf=setenv bootargs console=ttyS0,115200 root=/dev/ram0 init=/init; setenv ipaddr 192.168.1.100; setenv serverip 192.168.1.1; tftp 0xa00000 uImage; tftp 0xf00000 urootfs; bootm 0xa00000 0xf00000

Alternative version of your altf that stops if either image download fails (left out your bootargs, exceeds u-boot 32 argument limit):-

setenv altf 'setenv a1 setenv ipaddr 192.168.1.100\; setenv serverip 192.168.1.1; setenv a2 tftp 0xa00000 uImage; setenv a3 tftp 0xf00000 urootfs; setenv bootcmd bootm 0xa00000 0xf00000; run a1 a2 a3 bootcmd'

note: needed quotes and escaped semicolon "\;"

When run on my box it fails and stops (wrong IP's for my network):-

Marvell>> run altf
Using egiga0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.100
Filename 'uImage'.
Load address: 0xa00000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Marvell>>

[Andrew G]

On Monday, 19 January 2015 03:02:37 UTC, Andrew G wrote:

The command line fom u-boot seems to be ignored by the kernel, because it is built with CMDLINE_FORCE option. So /proc/cmdline just shows the kernel's compiled in default. Also attached dump of /proc/atags, I think the kernel also changed the tags (that is why there is a gap in the middle), but did not completely clear the buffer, so seems to have left the tag containing u-boot's command line in the end of the buffer. It works, but not nice to rely on a kernel oddity.

 
Correction: I misinterpreted the "od" command output, what I thought was a gap (of zeros) in the middle of /proc/atags was actually repeats of previous line, should have included -v option for "od". With that now understood, it looks all the structure of all the atag data is valid and that the kernel has NOT changed anything.

/ # od -v -t x4 /proc/atags
0000000 00000005 54410001 00000000 00000000
0000020 00000000 00000004 54410002 10000000
0000040 00000000 00000004 54410002 00000000
0000060 00000000 00000004 54410002 00000000
0000100 00000000 00000004 54410002 00000000
0000120 00000000 0000002c 54410009 746f6f72
0000140 65642f3d 61722f76 6f63206d 6c6f736e
0000160 74743d65 2c305379 32353131 3a203030
0000200 42443a3a 58463838 3a313858 67696765
0000220 6e3a3061 20656e6f 70746674 64617069
0000240 313d7264 312e3239 362e3836 33312e31
0000260 66742039 656e7074 73616d74 35323d6b
0000300 35322e35 35322e35 20302e35 70746674
0000320 76726573 70697265 3239313d 3836312e
0000340 2e31362e 20373232 70746674 6f6d6572
0000360 616e6574 743d656d 6d697173 00656761
0000400 eaffffe5 00000004 54420005 00f00040
0000420 002d4000 0000000f 41000403 0306000e
0000440 09ef21ab 17d78400 e1a04005 00435000
0000460 00000202 00000000 00000000 00000000
0000500 00000000 000005dc 00000000 00000001
0000520 00000000 00000000
0000530
/ #

tags are 32bit word based, with format:-
<length> <tag type> [<tag data> ...]

So the data splits into 9 tags, the big one containing the command line.

ATAG_CORE
00000005 54410001 00000000 00000000 00000000
ATAG_MEM
00000004 54410002 10000000 00000000
ATAG_MEM
00000004 54410002 00000000 00000000
ATAG_MEM
00000004 54410002 00000000 00000000
ATAG_MEM
00000004 54410002 00000000 00000000
ATAG_CMDLINE
0000002c 54410009 746f6f72 65642f3d 61722f76 6f63206d 6c6f736e 74743d65
2c305379 32353131 3a203030 42443a3a 58463838 3a313858 67696765 6e3a3061
20656e6f 70746674 64617069 313d7264 312e3239 362e3836 33312e31 66742039
656e7074 73616d74 35323d6b 35322e35 35322e35 20302e35 70746674 76726573
70697265 3239313d 3836312e 2e31362e 20373232 70746674 6f6d6572 616e6574
743d656d 6d697173 00656761 eaffffe5
ATAG_INITRD2
00000004 54420005 00f00040 002d4000
ATAG_MV_UBOOT
0000000f 41000403 0306000e 09ef21ab 17d78400 e1a04005 00435000 00000202
00000000 00000000 00000000 00000000 000005dc 00000000 00000001
ATAG_NONE
00000000 00000000

[João Cardoso]

On Wednesday, January 21, 2015 at 8:06:29 PM UTC, Andrew G wrote:

On Monday, 19 January 2015 03:02:37 UTC, Andrew G wrote:

The command line fom u-boot seems to be ignored by the kernel, because it is built with CMDLINE_FORCE option. So /proc/cmdline just shows the kernel's compiled in default. Also attached dump of /proc/atags, I think the kernel also changed the tags (that is why there is a gap in the middle), but did not completely clear the buffer, so seems to have left the tag containing u-boot's command line in the end of the buffer. It works, but not nice to rely on a kernel oddity.

 
Correction: I misinterpreted the "od" command output, what I thought was a gap (of zeros) in the middle of /proc/atags was actually repeats of previous line, should have included -v option for "od". With that now understood, it looks all the structure of all the atag data is valid and that the kernel has NOT changed anything.

You can cross-compile dumpatags and run it in the box, which shows you each atag contents, './dumpatags /proc/atags': http://www.mesa.nl/~marcel/

Regarding the kernel command line, for some reason it is different for different boards:

jcard@flash:~/alt-f> grep CMDLINE local/pkgs/linux-3.10.32.config 

CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/ram0 init=/init"

# CONFIG_CMDLINE_FROM_BOOTLOADER is not set

CONFIG_CMDLINE_EXTEND=y # DNS-321/323

# CONFIG_CMDLINE_FORCE is not set

# CONFIG_MTD_CMDLINE_PARTS is not set

 

jcard@flash:~/alt-f> grep CMDLINE local/dns325/linux-3.10.32.config 

CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set

CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/ram0 init=/init"

# CONFIG_CMDLINE_FROM_BOOTLOADER is not set

# CONFIG_CMDLINE_EXTEND is not set

CONFIG_CMDLINE_FORCE=y # DNS-320/320L/325

# CONFIG_MTD_CMDLINE_PARTS is not set

Also, the 320/325 uses a device tree blob to describe the hardware, while the 320L (and the 321/323) uses traditional board setup code.

Using CMDLINE_EXTEND appends to the command line, so if some value is redefined it holds, ignoring the previous definition (or does it prepends? not sure now). That was used on the DNS-321/323 by rcE to set command line options to a kexeced kernel, then /init would proceed accordingly -- see near rcE end and /init.

So, I guess that setting CONFIG_CMDLINE_EXTEND also for the 320/325 will also work. I remember that there was some nasty interactions with this option and the dtb, so that might be the reason why extending is not enabled.

[Andrew G]

BUG: "libcurl" depends on "openssl"
I got the following error when I moved libcurl to from sqimage to rootfs and called curl from rcS
curl: can't load library 'libssl.so.1.0.0'
openssl was still in sqimage.

[Andrew G]

BUG: package dependency handling in "mkinitramfs.sh" for dns320/dns325 does not work properly, patch attached.
The problem is that packages that are in both fw_pkgs_deps and sq_pkgs_deps should be in the rootfs not the sqimage, as they are either in fw_pkgs or a package in fw_pkgs depends on them. So all entries common to both fw_pkgs_deps and sq_pkgs_deps should be removed from sq_pkgs_deps.

The effected packages are ntfs-3g and ncurses, which are moved to rootfs after patch applied.

Unfortunately this breaks the 3MB limit on rootfs copied. So some packages need to be moved from base_pkgs to base_pkgs2.
Needs check what packages actually used before /etc/init.d/rcS mounts sqimage.xz

Noticed this bug because my attempt to put libcurl in rootfs failed, because it is dependent of transmission in sqimage.

[João Cardoso]

I have created a ticket for this, which now has a tentative patch.

I have also implemented getting the sqimage from tftp, as you suggested, but in a simpler way. It's the developer responsibility to set it up right, so error handling is poor. Add to u-boot bootargs 'tftpargs=myip:tftpip[:netmask]'

Patch attached.

Thanks.

PS-I really prefer to use the bug tracking system and have a different forum topic for each different issue.

 

[Andrew G]

Sorry for delay, very busy with work.

On Saturday, 24 January 2015 18:12:51 UTC, João Cardoso wrote:

I have created a ticket for this, which now has a tentative patch.

 I did not create tickets because the problems did not occur on your released builds, but on the patched versions I am trying to build. But I thought you should know about them. I will create tickets in future if I believe your release is effected.
 

I have also implemented getting the sqimage from tftp, as you suggested, but in a simpler way. It's the developer responsibility to set it up right, so error handling is poor. Add to u-boot bootargs 'tftpargs=myip:tftpip[:netmask]'

Your line:-
        ifconfig eth0 up $myip $netmsk
causes error "ifconfig: SIOCSIFADDR: Invalid argument" when netmsk has a value, the word "netmask" is needed before its value. Suggest use parameter substitution with default value instead:-
        ifconfig eth0 up $myip netmask ${netmsk:-255.255.255.0}

To prevent enlarging busybox (with an applet that is only used by developers and even then only once during rcS) I tried other tftp clients. "curl" made rootfs much larger as included large libcurl and openssl packages. "tftp-hpa" is not in normal buildroot system, but tried hacking "tftpd-hpa" package to build it.

Then I thought, this is too much bother, is there any download method already built in to your released kernel and rootfs. So tried nfs instead of tftp and it works, with only a change to rcS script, no extra tools or busybox applets needed.

So installed nfs-server on my development machine and used it to export the tftpboot directory:-

# /etc/exports entry
/srv/tftpboot 192.168.61.0/24(ro,all_squash,subtree_check,sync)

Patch to rcS attached.

Works well, does hang for a few minutes if told to use wrong server ip. Script is few lines longer because need to mount/un-mount, but no increase to busybox size for the boxes with small nand chips.

I personally prefer the tftp download rather than nfs, but if you want to keep busybox small, then you might try this nfs method.

[João Cardoso]

On Tuesday, February 3, 2015 at 3:17:04 AM UTC, Andrew G wrote:

...

 

 

I have also implemented getting the sqimage from tftp, as you suggested, but in a simpler way. It's the developer responsibility to set it up right, so error handling is poor. Add to u-boot bootargs 'tftpargs=myip:tftpip[:netmask]'

Your line:-
        ifconfig eth0 up $myip $netmsk
causes error "ifconfig: SIOCSIFADDR: Invalid argument" when netmsk has a value, the word "netmask" is needed before its value. Suggest use parameter substitution with default value instead:-
        ifconfig eth0 up $myip netmask ${netmsk:-255.255.255.0}

Oops... just in time, fixed for the last RC4.1

 

To prevent enlarging busybox (with an applet that is only used by developers and even then only once during rcS)

The size increase is negligible, 2KB, so I will keep using tftp (get only, no put nor tftpd)

And I already had to compile a few base-firmware packages for space saving (in order to include the cifs.ko kernel module on it), so it fits and 32KB are still available for the DNS-323. uau, 32KB! :-)

 

I tried other tftp clients. "curl" made rootfs much larger as included large libcurl and openssl packages.

"tftp-hpa" is not in normal buildroot system, but tried hacking "tftpd-hpa" package to build it.

Then I thought, this is too much bother, is there any download method already built in to your released kernel and rootfs. So tried nfs instead of tftp and it works, with only a change to rcS script, no extra tools or busybox applets needed. 

So installed nfs-server on my development machine and used it to export the tftpboot directory:-

# /etc/exports entry
/srv/tftpboot 192.168.61.0/24(ro,all_squash,subtree_check,sync)

Patch to rcS attached.

Works well, does hang for a few minutes if told to use wrong server ip. Script is few lines longer because need to mount/un-mount, but no increase to busybox size for the boxes with small nand chips.

I personally prefer the tftp download rather than nfs, but if you want to keep busybox small,

Only up to a point. You might noticed that I have maintained the "--help" available for all commands, and that consumes a lot of memory. But as manual pages are not available online, and some busybox commands are different/missing from the usual ones, I think that that extra memory is well "wasted".

Thanks!