If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.
You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

MG35Development

Page history last edited by Vasile 14 years, 11 months ago

Development status

The firmware is a puzzle with a lot of pieces which can be updated separately, so we decided to give each one of the its own page. An index of the firmware parts, with links to their pages, is on the Development status page. If you want to know who is working on what, see the Development team page.

John, who was the only developer for some time, abandoned the project in September, 2008, at firmware 1.5.2.0-a8. Leon tried to rebuild it and summarized his attempts in the status-r1056 page (1056 is the SVN revision of the files, see next section). As of Februay, 2009, Andrei took over and reported that using r1072 he can build a bootable image that can play files. Extended functionality like ftp server is not yet fixed.

The mg35tools project

We have a public project hosted at Sourceforge. Sourceforge provides us a SVN repository, which can be easily accessed with your browser or with a SVN client. Please check the repository structure to understand the layout. Building the parts is easy due to an integrated makefile. Each tool can be built independently, or you can build all of them in a single shot.

ARM uClinux development

For those who are new to embedded programming, a good starting point is here. Good general information on where and why uClinux is different to normal Linux can be found here. Some more articles about embedded programming are here.

Because MG35 is an embedded system with limited resources, development is done on normal PCs using cross-compilers. The recommended OS is Linux, but you can also 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.

Installing development tools on Linux

You can do this on a real Linux machine, or in a virtual machine on your Windows computer. To install the tools, perform the following steps:

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 20030314".

2. Run the downloaded file as user "root". For Nuke, the default root password is... "root".

3. To work with the repository, install the following packages with your package manager:

svn
libc6-dbg
libc6-dev
gcc
flex
patch
yacc/bison
libtool
automake
binutils
cvs
make
g++
libstdc++
gawk
cabextract
ctags

That's all, now you can go to create your first Hello, World! application for the MG35.

Installing development tools on Windows/Cygwin

1. Download and install Cygwin. Make sure you install the following packages, which are NOT installed by default:

automake 1.9
binutils
cvs
gcc-core
make

The default installation path is C:\Cygwin. In the next steps we will use this location, but if you choose a different one, just use your path in the examples below.

2. Download the Windows arm-elf cross compiler. Save the resulted arm-elf-gcc.zip file to c:\Cygwin.

3. Open a console (Start/Cygwin, or run C:\Cygwin\cygwin.bat). You will find yourself in an emulated Linux environment, ready to start building.

4. Unpack the zip file

cd /
unzip arm-elf-gcc.zip

5. The documentation asks us to make executable the new installed .exe's (but to be honest, it worked OK for me even without this step... YMMV).

chmod +x /usr/local/bin/*.exe
chmod +x /usr/local/lib/gcc-lib/arm-elf/2.95.3/*.exe
chmod +x /usr/local/arm-elf/bin/*.exe

chmod +x /usr/local/arm-elf/bin/ld
chmod +x /usr/local/arm-elf/bin/elf2flt

GCC 3.4.3, uClibc 0.9.26

In addition to the above compilers, you can use the gcc-3.4.3 toolchain, available from ipodlinux.org. The gcc-3.4.3 series should *NOT* be used for kernel compilation.

Hello, World!

Now it's the time to do something useful with our new tool. Let's create a file named webhello.c, preferably on your home directory. Here is what you have to cpy and paste into it:

#include <stdio.h>

int main()
{
/* Open the HTML stuff */
printf("Content-type: text/htmln" /* Necessary to specify the type */
"n" /* This blank line is critical! */
"<html>n"
"<body>n");

/* Do the hello thing... */
printf("Hello, World!
n");

/* Close the HTML stuff */
printf("</body>n</html>n");

return 0;
}

Or if you are lazy like me, just download it from ...here... and unzip it.

Next, try to compile it:

arm-elf-gcc -o webhello.cgi -Wl,-elf2flt webhello.c

Check the result using the "ls" command. You should get 2 new files:

webhello.cgi.elf.bflt
webhello.cgi.gdb

The first one is our beloved executable, and the second is a file containig debug information. Rename the executable:

mv webhello.cgi.elf.bflt webhello.cgi

Now copy it using FTP to your MG35, for example in /phase2 directory. If you have an internal hard drive, you can also use USB interface to copy it to the hdd.

Now make it executable and run it. The result should look like:

BusyBox v1.2.0 (2006.08.28-07:47+0000) Built-in shell (lash)
Enter 'help' for a list of built-in commands.

/ # chmod +x /phase2/webhello.cgi
/ # /phase2/webhello.cgi
Content-type: text/html
<html>
<body>
Hello, World!
</body>
</html>
/ #

Congratulations! You just created your first MG35 executable. If the execution result doesn't tell you too much, don't despair: it's a CGI program, ready to be executed by the MG35's web server.

Kernel development

Kernel development has its own dedicated page.

In order to speed the development by avoiding time-consuming reflashing, the serial loader has a feature to allow you to download and boot the kernel. Read the section on bootloader console for general information and then try -

 download serial kernel
 boot kernel

The kernel should be uncompressed. Note that the code you download doesn't have to be a kernel - anything placed at 0x1008000 will be executed.

The cramfs is still mounted from ROM.

Good luck! Please report positive and negative results.

Downloading via TFTP

First you need to configure your bootloader: my tftp server is 192.168.2.23 and my Kernel filename is linux.bin

Leave the other file names alone unless you know what you are doing.

  Welcome to JASPER boot loader

  boot> config net
  Protocol    : (0) None (1) Static IP (2) BOOTP (3) DHCP : (1)
  MAC Address : (00:02:a8:xx:xx:xx)
  IP Address  : (192.168.2.167)
  Netmask     : (255.255.255.0)
  Gateway     : (192.168.2.1)
  DNS         : (192.168.2.1)
  Server      : (192.168.2.23)

  boot> config file
  boot loader filename : (loader.bin)
  ROM filesystem filename : (romfs.ok)
  Kernel filename : (linux.bin)
  Image filename : (romfs.new)

Next compile a new kernel and copy linux.bin to your tftpserver. The kernel should be uncompressed . Tell the bootloader to load a new kernel and boot it:

  boot> net up
  DM9000 open
  Networking is enabled
  
  boot> net arp 192.168.2.23
  192.168.2.23      00:xx:xx:xx:xx:xx
  
  boot> download net kernel
  Connecting...
  ARP for 1, 192.168.2.23
  Receiving : ..............
  Received 1223152 (0x12a9f0) bytes at address 01008000
  
  boot> boot kernel
  01008000Linux version 2.4.17-uc0 (root@xx.xx) (gcc version 2.95.3 20010315 (release) (ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from 6
  Processor: ARM pt110 revision 0

Also the network driver (from source) doesn't work...

Application development

(Note: this section will be changed after releasing a firmware including unionfs) Updates?

To ease the application development and testing, we can replace some of the built-in applications with replacement ones, kept on the local harddrive or on the network. To get this, a few modifications were made in our alpha releases:

all the applications from / and /bin were moved to /sbin/rbin (for replacement bin) and symlinks were created in their original locations. This way, the original functionality is preserved.
we modified /etc/sashrc. Before calling dvdplayer, we try to locate a phase1 script in specific locations on the harddisk (/cdrom/RECYCLER, /cdrom/Recycled and /cdrom/zz_devel), and execute it if it's found. The main purpose phase1 is to copy some files/scripts to /phase2 ramdisk. A secondary purpose for this script is to set the dvddir variable, so that we can later execute a modified dvdplayer instead of the original one.
also in /etc/sashrc, after executing dvdplayer and starting the telnet and ftp daemons, we try to execute /phase2/phase2 script which was saved there in phase1. A possible use phase2 is to create a ramfs, populate it with symlinks or executables and mount it over /bin. This way, we can replace the majority of the binaries without reflashing the MG35.

If something went wrong in your phase1/phase2 scripts and the device doesn't boot, connect the MG35 to the PC via USB cable and rename or change the scripts. Alternatively, you can remove the harddrive, connect it in your PC and then do the renaming or editing of the scripts.

Here is an example. The structure on my first partition on the harddrive is as follows:

  [music]
  [zz_devel]
      phase1
      phase2
      [tools]
         bigbox  - this is a busybox that includes many tools 
         rw      - this is a script to remount the /cdrom as RW
         ....

This is phase1 script:

#!/bin/lash
# this is the first step in the startup, executed while /cdrom is mounted readonly
# it cannot umount /cdrom, since it is in use
# Instead, it will copy the phase2 script in ramdisk, to be executed later
# phase2 can unmount /cdrom, or better just remount it as read-write

/bin/mount -t proc proc /proc       # some utilities don't work properly without a mounted /proc
cp $PHASE_DIR/phase2 /phase2/phase2 # copy the phase2 script to ramdiskASX
                                    # this is needed to be able to unmount and remount /cdrom
export PATH=$PHASE_DIR/$PHASE_DIR:$PATH
export dvddir=/bin                  # the path to dvdplayer
/bin/umount /proc                   # restore the original state

This is phase2:

#!/bin/lash
sleep 6                            # give dvdplayer some time to mount /proc; 6 sec it's minimum
mount /cdrom -o remount,rw         # remount /cdrom as RW

####### create and mount a custom /bin
/bin/cp -a /bin /phase2            # copy the original symlinks and tools from /bin to ramdisk

# add some new symlinks
export BIGBOX=/cdrom/zz_devel/tools/bigbox      # bigbox should be specifically called
ln -s $BIGBOX /phase2/bin/find    # create symlinks to our needed tools in bigbox
ln -s $BIGBOX /phase2/bin/reboot
ln -s $BIGBOX /phase2/bin/chroot
ln -s $BIGBOX /phase2/bin/date

# now replace some original symlinks, just as an example
rm /bin/phase2/echo
ln -s $BIGBOX /phase2/bin/echo

# /phase2/bin is now ready, now mount it and enjoy the "writeable" /bin
/phase2/bin/mount -o bind /phase2/bin /bin

Testing the cramfs without flashing it

[Courtesy of Andrei] I developed a way of testing new firmware without flashing it. The idea is to put test cramfs at 0x1A80000 and exclude area 0x1A80000-0x01E7FFFF (4Mb) from kernel-addressable space. THe needed sources are in SVN at projects/cramfstst.

1. Use compile.sh to compile a kernel that utilizes only 10Mb of RAM, has debug output enabled and expects cramfs image at 0x1A80000. Can be done once.

2. Start MG35, download the modified kernel and your test cramfs (see the bootloader commands if you need help about these steps), then move the test cramfs in its final location and boot the kernel:

boot> net up
boot> download net kernel
Received 1196584 (0x124228) bytes at address 01008000
boot> download net romfs
Received 3059712 (0x2eb000) bytes at address 01400000
boot> memcpy 0x1A80000 0x1400000 3059712
Copy completed
boot> boot kernel

Important lines in the kernel boot log:

....

Memory: 10MB = 10MB total

....

Blkmem 1 disk images:

0: 1A80000-4A7FFFF [VIRTUAL 1A80000-4A7FFFF] (RO)

Modifying a .upgrade firmware file

Disclaimer: creating a new firmware is not for anyone! Any small mistake (it can be something as insignificant as a small typo) can create a firmware image which will brick your MG35. So if you're not 100% sure about what we're talking about here and you don't have the means and knowledge to debrick your MG35, don't go furher! Even if the above conditions are met, please be advised that you are on your own! We can give no warranties that everything will work as expected.

It is possible to create a new upgrade from scratch, but this process is generally handled by some script (e.g. a makefile) in order to avoid costly mistakes. But for small changes one uses an existing firmware as a base, alters it and then creates a new .upgrade file.

BYO firmware builder

There is a set of scripts available for simplifying the process of creating consistent firmware builds. After you have created your skin and/or tested your applications, you can use the BYOFirmware package to build an upgrade file.

Manual procedure

For small changes, BYO Firmware builder is an overkill, and you can use the manual approcach outlined below.

Split the original .upgrade file

The .upgrade file format is now fully documented, and we have the MG35Tool program which makes splitting very easy. The result are a few files. We are most interested in the cramfs image (default name is cramfs.img), but one can also change the kernel (linux.gz). It is NOT recommended to mess with the bootloader (boot.img), if it is present in your base.

Edit the cramFS contents

Now that you have the cramfs image, you should use cramfsck to extract all the files from an image (-x option) to a working directory. [Note: You can also mount the read-only cramfs image in a subdirectory for copying or examining the files. But you will not be able to alter them]

You can now change things in you work directory. Examples of things you can do:

change the graphics of the MG35. This requires you to create new graphics file in your img subdirectory and then patch the dvdplayer.bin with the new palette. EmuMannen worked hard and provided us a howto about this subject. Thanks again!
change the fonts used for movie subtitles
alter the startup scripts
add new busybox applets and symlinks for them

Once you are happy with your changes, use mkcramfs to make a new cramFS image from your work directory.