SVN repository

We have a public source repository hosted at Sourceforge.net. Any user can read the repository. If you need write access, please write me an email at mg35 at sysoft dot ro.

Here is the structure for the mg35tools project:

firmware

+--busybox-1.2.0

+--libexif-0.6.13

+--microwindows

+--minimod

+--nbtscan

+--samba-2.0.7

+--uClinux-2.4

+--udhcpc

+--wireless_tools-26

+--mathopd

+--pure-ftpd

+--mgnv

+--themes

+--scripts (sashrc, phase1, phase2, ...)

+--utilities (peek, poke, dumptop, mg35config??)

+--www (static web content)

+----img

+----cgi (screendump, screenraw, flashid, version)

host_tools

+--mg35tool

+--mg35palpatch

+--package (gadgetmind's packaging script)

ARM uClinux development

Good general information on where and why uClinux is different to normal Linux can be found here.

Because MG-350HD is an embedded system with limited resources, development is done on normal PCs using cross-compilers. The recommended OS is Linux, but you may be able to develop on a Windows machine, using Cygwin.

A Linux 2.6 Kernel version can be found here.

An arm2html bFLT disassembler is here.

The installation procedure described below is based on the howto found here.

Should you want to begin with a 2.4 kernel (the MG-350HD uses a 2.4 kernel), the sigma designs port of uClinux is available. You'll have to use make menuconfig to configure it, since it's missing some unnecessary subdirectories, and the make config method doesn't handle it.

Installing development tools on Linux

You can do this on a real Linux machine, or in a virtual machine on your Windows computer. VMware server and coLinux are good candidates. A Linux instance running under Parallels Desktop on Mac OS X works fine as well.

1. Download the arm-elf-tools. If you want some more info about arm-elf-tools, just go here. The compiler you need is version "arm-elf gcc version 2.95.3 20010315" but the version dated 20030314 seems to work just fine.

2. Run the downloaded file as user "root". For Nuke, the default root password is... "root". This will unpack the arm-elf-tools archive and install the contents in /usr/local -- components will go into /usr/local/arm-elf, /usr/local/bin, and /usr/local/lib/gcc-lib/arm-elf. Components in /usr/local/bin are prefixed with arm-elf-

MG-350HD kernel status

There hasn't been released MG-350HD kernel source anywhere but Al Tech have released GPL source code for MG-35 but it's currently not clear how well it matches what was used for the MG-35. It's here.

The next best source of a "close" kernel is here.

Building the Sigma Designs port of the uClinux kernel

Note: the usefulness of this hasn't been determined yet, but more information is better than none, right? If it's a blind alley, at least we can say so clearly.

1. Download and unpack the sigma designs kernel port linked above
2. Copy the config-bootflash file to .config
3. run make menuconfig, and make the following changes:
   1. System Type -> SDRAM Base Address (to be verified from a console boot message)
   2. System Type -> SDRAM Size (verify as above)
   3. System Type -> Flash Base Address (verify)
   4. System Type -> Flash Size (verify)
   5. ATA/IDE/MFM/RLL Support -> IDE, ATA, and ATAPI Block devices -> turn on IDE/ATA-2 disk support
   6. Block Devices -> FLASH type set to AMD
   7. File Systems -> turn on Second Extended fs support (see notes below)
   8. USB Support -> turn on USB support (compiled in or module)
4. If you turned on ext2 support, you'll have to copy in the following files/directories from the vanilla uClinux distribution. Download the 2.4.17-uc0 version, since it's what the Sigma Designs port is based on, and will result in much less fiddling around (see section below on getting older versions from CVS):
   1. fs/ext2 (entire directory)
   2. include/linux/ext2_fs_i.h
5. run make dep; make; make modules
6. You now have a uClinux-2.4.17-sigma kernel

Getting vanilla uClinux-2.4.17-uc0 from CVS

This is based on the instructions at http://cvs.uclinux.org/cvs_anon.html

1. "Log in" to the CVS server anonymously:

   • cvs -d:pserver:anonymous@cvs.uclinux.org:/var/cvs login

     (just press enter when prompted for a password)

2. Check out the appropriate revision from the archive:

   • cvs -z3 -d:pserver:anonymous@cvs.uclinux.org:/var/cvs co -P -r uClinux-2.4.17-uc0 uClinux-2.4.x

There you go! What one might do with this is debatable at present.

Splitting a .upgrade file

See MG35Tool this section on the .upgrade file tool.

The .upgrade file format is fully documented here, and the details are handled by MG35Tool.

As an example, assuming your firmware upgrade file is called MG350HD_firmware.upgrade:

$ mg35tool split -t MG350HD MG350HD_firmware.upgrade

Firmware version is 1.1.3

[BOOT] 

Checksum = 0xE5674106

Offset in Flash = 0x46000000

Length = 0x00017330

Checksum matches, generating boot.img output

[ROFS] 

CheckSum = 0x3E9E0735

Offset in Flash = 0x46020000

Length = 0x007CA789

Offset to Cramfs = 0x460F1789

This will generate 3 files: boot.img, cramfs.img, and linux.gz

If you are splitting an official firmware file, it's most likely that it contains a boot image as well as a compressed linux kernel and a cramfs. When you rejoin your new image file, it's safest to leave the boot image out of it unless you really know what you're doing. The MG350HD will happily reflash itself with a firmware image that doesn't include new boot code, and there's much less risk of bricking the device this way.

Editing the cramFS contents

cramFS images are manipulated by the Linux cramfstools package. The two tools that are required are cramfsck for extracting the files from an image, and mkcramfs for taking a directory of files and making a new cramFS image.

The most important thing is not to use a cramfs tool from a package built under a 2.6 kernel. Instead, you must use versions of cramfsck and mkcramfs that were built under Linux kernel 2.4.x. Here is a copy of the statically compiled tools for your sake.

Extracting the contents of a cramfs.img file

Using the above-linked tools, and assuming you have split your original firmware using mg35tool as described above:

$ cramfsck -x cramfs cramfs.img

You can add the -v flag to see the names of the files as they're extracted.

$ cramfsck -v -x cramfs cramfs.img

d 0755 276 521:245 cramfs

d 0755 60 521:245 cramfs/CVS

f 0644 20 521:245 cramfs/CVS/Entries

f 0644 37 521:245 cramfs/CVS/Repository

f 0644 10 521:245 cramfs/CVS/Root

d 0755 728 521:245 cramfs/bin

[...]

Creating a new cramfs.img file

Using the above-linked statically linked tools, and assuming you've used the same file/directory names described above:

$ mkcramfs cramfs mycramfs.img

lots of verbosity here

You can then use the file mycramfs.img in a new .upgrade file.

Putting a .upgrade file back together

Use the above-linked mg35tool.

Note: .upgrade files without boot sections work very well on the MG-350HD and are highly recommended!

To recreate an upgrade firmware image without the boot section (assuming the standard filenames from an mg35tool split operation):

$ mg35tool join -t MG350HD -k linux.gz -c cramfs.img my_new_firmware.upgrade

[ROFS]

CheckSum = 0x3E9E0735

Offset in Flash = 0x46020000

Length = 0x007CA789

Offset to Cramfs = 0x460F1789

join operation successful.

Application development

Notes on size

Because the MG-350HD has a limited amount of flash available to store its firmware image, any .upgrade file that you create must be less than 8MB (8192 KB, 8,388,608 bytes) if it includes the boot code (which isn't considered safe to do unless you really, really like risking the operational status of the device, or if you really, really know what you're doing).

For this reason, if you are creating a .upgrade file without the boot code, it should be less than (8MB - (sizeof boot.img)), plus a small margin for safety to allow for future expansion of the flash boot image. The boot code size from the official 1.1.3_beta1 firmware is 95,024 bytes.

This suggests that a .upgrade file should be less than 8,293,584 bytes less, say, 10k for future expansion of the boot firmware; giving a suggested maximum .upgrade file size of 8,283,344 bytes.

Creating a .upgrade file larger than this should result in the MG-350HD complaining about upgrade file size when you try to install that firmware; but there's no indication on the GUI (it seems to just hang). It probably complains on whatever is stdout for curacao instead. At least it doesn't install the too-large firmware, as that would satisfactorily brick the unit.

Assuming that we can't change the size of the linux kernel (yet), the only place left to save space is in the cramfs image. Looking at the top users of space there, we see:

If one weren't fussed about keeping NDAS functionality, it should be ok to delete the ndas_core module from the cramfs image. The altech.ttf file is a truetype font used in the gui -- it's so large because it has both English and Korean fonts encoded in it. If you have a purely English system, it is possible to substitute a pure-English font, which is much smaller. So far, both Arial and Bitstream Vera Sans Mono have been tested, at quite a space saving, and appear to perform pretty well. There do seem to be some minor niggles, in that underscores (for example) don't appear -- however, this isn't a major concern at present.

The other way to give more space is, of course, to use any storage device attached to the unit; once hooks are in place to start up, say, telnetd locally, it would be possible to execute binaries from non-Flash storage.

busybox

BusyBox 1.2.2 seems to compile and run. The source can be found here.

You need to apply this patch to compile telnetd.

Patches for other busybox applets:

• rmmod.patch (adds the __NR_delete_module syscall number)

To configure the build of busybox for an ARM processor, you have two options:

1. using busybox's supplied make menuconfig, turn on cross-compilation and define the prefix for the cross compiler as /usr/local/bin/arm-elf- (note the trailing hyphen '-'). Note that doing things this way also allows you to configure the applets that get built, and perhaps generate far more confusion for yourself than you were really ready for. If you're at all uncertain, use the other option.
2. If you just want to build a separate telnetd and lash, you can download this .config file and place it under your busybox build tree

To build busybox (configured either way above), use the command line:

$ CROSS_CFLAGS=-Wl,-elf2flt EXTRA_CFLAGS=-DBB_NOMMU make

This will give you a version of busybox in your build tree. Copy it into the bin subdirectory of your source for your cramfs filesystem, but call it nbusybox instead of overwriting the original busybox binary. This will prevent clobbering existing functionality by mistake. Then, create symlinks to your new nbusybox binary:

$ cp busybox ~/your_new_cramfs_source_path/bin/nbusybox
$ cd ~/your_new_cramfs_source_path/bin/
$ ln -sf nbusybox telnetd
$ ln -sf nbusybox lash

If you have, for whatever reason, built a lot of busybox applets and you want to add them to your personal upgrade image without clobbering the existing stuff:

• apply install.patch for applets/install.sh
• run make install in the busybox build tree, which will create a subtree called _install, with the busybox binary called nbusybox and all symlinks pointing to that (instead of to busybox)
• create a tarball of your busybox build:
  • $ ( cd _install && tar cf ../my_bb.tar * )
• extract the contents of the tarball over your original extracted cramfs tree, but without overwriting anything that already exists (note the 'k' option which stands for "keep-old-files" -- aka don't clobber existing files)
  • $ cat my_bb.tar | ( cd /path/to/cramfs && tar xkf - )

The next step to activate telnetd is to modify /etc/inittab to add your telnetd invocation script:

::sysinit:/etc/init.d/rcS 
::sysinit:/etc/init.d/S40telnetd

rcS is the script that invokes the main mediaplayer (curacao). Add your script (e.g S40telnetd) right after rcS. The content of S40telnetd is something like this:

#!/bin/sh

# pause to allow curacao to start up and for the system to settle
/bin/sleep 10

# run our telnetd binary and tell it to spawn our shell
/bin/telnetd -l /bin/lash &

The final step is to create your new .upgrade file and update your MG-350HD. Use the instructions above.

Sntpdate

Since MG-350HD doesn't have RTC, date and time becomes always Jan-1-1970 and 00:00:00 at start up. This is problem when you copy files onto the internal HDD. If your MG-350HD can connect internet or you have NTP server in your LAN, you can initialize date and time by sntpdate.

Compiling sntpdate is fairly easy. Just use this Makefile and type make. Finally you will have sntpdate.

Installing sntpdate is similar to telnetd. An invokation script needs adding in /etc/inittab and sntpdate can be started like this.

Like telnetd, create a upgrade file and update your MG-350HD.

This page has been viewed times.