This post hosts a few blurbs about issues I ran into when developing for Embedded Linux and did not find decent documentation on google. It will update as I plow through more stuff.

Getting the telnet server (telnetd) to accept connections when using DENX SELF

By default, if you try to connect to the server, you’ll get an error claiming “all network ports in use”. This is not so much of a SELF configuration thing, rather how the kernel is set up by default. Assuming you ran MAKEDEV (see my installation post) when installing the ELDK, you’ll have a few /dev/ttyp devices. As I understand, telnetd attaches to these pseudo ttys to send/receive data from a user (one each). However, the kernel is not set up by default to install the driver for PTY devices.
The solution is to run menuconfig (or xconfig) and include the Legacy PTY device support in the kernel (under Device Drivers -> Character Devices). After you’ve deployed your kernel, telnet should be able to connect. Make sure to create a user with a shell for telnet, otherwise you won’t be able to log in.

Setting up the FTP server for upload support when using DENX SELF

The SELF image has wu-ftpd set up, but it does not allow uploading files by default. Doing this is rather simple – simply modify /etc/ftpaccess as follows:

  • Change the “no” just right of chmod, delete, overwrite to “yes”
  • Add “upload / * yes” with no quotation marks just below this list

Some images segfault before main

This one had me scratching my head for a few hours. I wanted to deploy dropbear on the target so I downloaded the latest source and compiled it. I then went ahead to deploy dropbear and dropbearkey only to see that dropbear shows a segmentation fault before main. At first I thought it was some shared library issue, but setting the LD debug flag did not print out anything – it was crashing before pulling in any objects.
I thought perhaps the kernel was not configured properly for ELF files but it was. I then rebuilt binutils (so that I will have the latest and greatest) and ran readelf on my Ubuntu station on both dropbear and dropbearkey – it showed everything was great. However, I then cross-compiled readelf and tried running it on the target’s dropbear and dropbearkey – it showed the dropbear ELF was corrupt (bad section header offsets).

After more investigation i saw an offset of 1 byte when reading the section headers – but only on the target. Looking manually at the hex dump for the dropbear image on my PC showed it was perfect. I then looked at the sizes of the images – dropbear on the target was 3 bytes smaller than dropbear on my PC, even though they’re the same file…

To make a long story short – it turns out that FileZilla (my FTP client) did some CR/LF manipulation when sending the file to the target. Setting the transfer mode from “Auto” to “Binary” did the trick. D’oh!

Using Eclipse to debug the kernel with Abatron BDI3000

The Abatron BDI3000 supports a GDB frontend (bdiGDB) so we can pretty easily set up Eclipse to debug the kernel. I used an external plugin for this – the Zylin embedded CDT (download/installation instructions here). Once that’s installed, we create a Debug configuration (Run -> Debug Configurations) under Zylin Embedded Debug (Native). In the Main tab we set the C/C++ application to the applicable vmlinux (there is no need to set a project) and in the Debugger tab we leave everything default and browse to set GDB debugger to the appropriate GDB (for example, ppc_8xx-gdb). Finally, in the Commands tab we set Initialize commands to “target remote {bdi-ip}:2001″ and Run commands to “c”.
To actually perform debugging, I attach the GDB only after Linux has initialized the MMU (I chose to break at __start_here). To do this, I telnet to the BDI and perform:

reset  
bi {__start_here offset, taken from the System.map file, e.g. bi 0xc00021e0}  
go

The target should stop at __start_here. At this point I can set breakpoints to debug the kernel boot process and start debugging in Eclipse. To debug again, terminate the GDB process by clicking the red button or Ctrl+F2 and re-enter the BDI commands above. There is no need to do the clear/set breakpoint dance with Eclipse – it will remember your breakpoint settings and reapply them every time you connect. The BDI does not do this, however, so you need to always re-perform bi.

Debugging U-Boot (after relocation) in Eclipse

This is quite similar to debugging the Linux kernel in eclipse, so follow the above paragraph with the following differences.

  • You need to obtain the address to which U-Boot relocates to in RAM. This can either be done the DENX way or by adding a printf to board_init_f, printing out the last argument, addr, to relocate_code
  • You’ll also need the address of board_init_r, which is called immediately after relocation to RAM. Just find it in u-boot.map and add its value to the relocation address you obtained in the first step. This will give you the absolute RAM address at which board_init_r resides after relocation
  • In the Main tab, instead of vmlinux you’ll need to point to the u-boot file in your U-Boot root directory
  • In the Commands tab, set ‘Initialize’ to:
    • target remote {bdi-ip}:2001
    • symbol-file
    • add-symbol-file {u-boot-dir}/u-boot {u-boot-ram-relocation-address}
  • In the BDI telnet session, follow the same thing as Linux debugging only break on board_init_r’s absolute RAM address

The rest should behave just like Linux debugging – reset in BDI, set the breakpoint, go; target will stop, attach via Eclipse.

Applying a patch from GMail

Many mailing lists have a host of patches, embedded inline posted messages. When subscribing to these lists with a GMail account, you may find yourself wanting to apply one such patch. The problem is that GMail’s web interfaces will manipulate the hell out of the received messages (whitespaces and line wraps mostly) – this will at best break checkpatch and at worst break compilation.

To create a working patch, I simply click on the little blue drop down icon on the upper-right corner of the message holding the patch and select “Show original”. You can safely copy/paste this into a text file and apply.