Running gllin and restoring from mtdblock backups

La Monte Henry Piggy Yarroll piggy at netronome.com
Tue Sep 11 14:58:31 CEST 2007


I find that I can not run the GPS daemon gllin with newer kernels, such 
as 
http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/uImage-2.6.22.5-moko11-r2-fic-gta01.bin 
downloaded on 29 August 2007.

root at fic-gta01:~/DM2$ ./gllin
-sh: ./gllin: not found
root at fic-gta01:~/DM2$ ls -l
-rw-r--r--    1 root     root         3030 Sep  3 02:30 NVRAM1.DAT
-rw-r--r--    1 root     root         3030 Sep  3 02:30 NVRAM2.DAT
-rwxr-xr-x    1 root     root      1548564 Sep  3 02:30 gllin
-rwxr-xr-x    1 root     root           76 Sep  3 02:30 stop_gps
root at fic-gta01:~/DM2$  

I suspect the problem is that the 2.6 kernels do not support this 2.4.0 
executable format:

tsqali >> file gllin
gllin: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 
2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
tsqali >>


SO, I'm attempting to do a restore from the backup I did of the original 
image following page:
http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo1973#Initial_backup

My first attempt was to use dfu_util:

tsqali >> sudo dfu-util -a 3 -R -D mtdblock2

This fails with an error message about the write continuing past the end 
of the device--not all that surprising now that I think about it.

So I fall back to scp'ing the kernel image over to the neo1973 and using dd:

tsqali >> scp mtdblock2 root at 192.168.0.202:
root at 192.168.0.202's password:
mtdblock2                                    100% 2064KB 412.8KB/s   
00:05   
tsqali >> ssh root at 192.168.0.202
root at 192.168.0.202's password:
root at fic-gta01:~$ dd if=mtdblock2 of=/dev/mtdblock2
4128+0 records in
4128+0 records out
root at fic-gta01:~$ reboot
-sh: reboot: Input/output error

At this point, it appears that every command which is not part of the 
shell gives me an I/O error. I need to remove the battery to turn the 
phone off. I would expect this if I were changing the RFS, but why does 
this happen replacing the kernel? Is the kernel being actively paged 
from NAND?

Happily, I can restore the newer kernel with dfu-util, but this puts me 
back where I started.

So my two questions:

1) Any other suggestions on running gllin?

2) What is the right way to restore the device from mtdblock backups?




More information about the device-owners mailing list