I have used the linux 2.6.12.6-VENUS code published by iomega https://iomega-eu-en.custhelp.com/cgi-bin/iomega_eu_en.cfg/php/enduser/std_adp.php?p_faqid=21578 and the uClibc from the raidsonic http://www.raidsonic.de/de/data/driver/firmware/IB-MP3010HW/Sources_RaidSonic.rar which is also an RTD player like the SPP.
Using these two sources has enabled me to make library files that are closer to what is on the Iomega device. Without Iomega's version of the uClibc, it'll take more work to get it to be exact.
These instructions are what is necessary to set up a complete cross compiling environment and using the buildroot to make your own toolchain. You can use the toolchain on the iomega device, or just use the buildroot to build whatever files you need.
All of the links to the new stuff will be at the bottom of this post. For those who want to try to recreate and maybe fix anything I did wrong, here's a set by step.
Prerequisites:
VMWare Player (I'm using version 2.5). It's free, but requires registration to download from http://vmware.com/products/player/
VMX Builder (free, google it. It is used to make the configuration files for vmware)
Ubuntu 8.04.1 (free, google it)
step 1, installing Ubuntu
Setup new virtual machine using VMX Builder.
Set at least a 20 GB hard drive, CD Player pointing to the Ubuntu 8.04.1 ISO, ethernet (amdlance, NAT)
and a reasonable amount of memory (1 Gig works well). Make sure target platform is Player 2.x, guest is Linux, and OS is Ubuntu.
Boot the virtual machine
Select to install Ubuntu.
Ubuntu will boot and if you don't see the Install screen within a few minutes, you probably didn't give it enough memory.
Login name: developer
Login password: root
Wait...twiddle thumbs...power nap
After reboot, click on the CD-ROM button to "take the CD out of the drive".
It will finally boot to the login screen. Login with your username and password you selected.
Select System>Preferences>Screen Resolution. You're going to need to increase it to at least 1024 x 768 to even make it useable.
This virtual Machine will take about 2 1/2 GB on your drive at this point.
step 2, Preparing the machine for development. Much of this comes from the gumstix wiki.
Select Applications>Accessories>Terminal
Confirm that you can connect to the network. ping your gateway, and ping www.google.com. Fix any network problems before continuing.
You should be able to run the update.
sudo apt-get update
(you will need to provide your password)
sudo apt-get install build-essential libncurses-dev bison flex texinfo zlib1g-dev gettext autoconf subversion wget samba git git-core
sudo dpkg-reconfigure dash
select no. This will uninstall dash.
now to get the buildroot source:
git clone git://opensphd.git.sourceforge.net/gitroot/opensphd/opensphd opensphd
(note: Edited 12/12/2009. On 8/25/2009, sourceforge modified the git repository capabilities which required an adjustment to the above git command. If it wasn't working for you before now, try again. It just needed an opensphd added to the end of it)
At this point, you will probably want to set up a share so you can easily transfer files from Windows to Ubuntu through a virtual network.
chmod 777 opensphd
sudo vi /etc/samba/smb.conf
You are now using vi. Search the web to find instructions on how to use vi, because you'll use it often.
Find the section called Share Definitions and add this
[opensphd]
comment = opensphd
path = /home/developer/opensphd
read only = no
guest ok = no
Now save that file.
sudo /etc/init.d/samba restart
sudo smbpasswd -a developer
and enter root for the password.
Now you can find out what your IP is using ifconfig and then browse that from the network. The netbios name will be something like developer-deskt if you used the user name as instructed above. Now you can start > run > \\192.168.6.133 (or whatever IP address was identified in ifconfig) and you should see the directory.
Now, back to Ubuntu. Switch to the buildroot directory.
cd ~/opensphd/buildroot
and make the config
make menuconfig
If this is your first time using the buildroot, then just select exit and save. Otherwise, feel free to select the additional packages you need.
now type:
make
and wait...a long time. It's going to take a few hours. It downloads each package needed and compiles it. The final result will be in the /opensphd/buildroot/binaries/uclibc/ and there will be a rootfs.mipsel.ext2 file, your toolchain.
Once you've built the toolchain, you can copy it to your screenplay drive and mount it and chroot to it. gcc works, but g++ stopped working on this version for some reason, so I didn't include it in the default menuconfig.
I would suggest doing development in the buildroot cross development environment. If it's one of the packages already included in the buildroot, then just go back into menuconfig and add it. Then make again and presto, it'll be in your toolchain file. It'll also be in one of the working directories on ubuntu, (project_build_mipsel/uclibc/root or something like that).
You should also be able to use the staging directory and do your own cross compiling. I'll detail that another day.
The uClibc had a few minor changes, which I added as a patch in the toolchain/uclibc directory. I also removed all of the .o and .a files from it, since it interferes with a good compile. Do not remove the .so files though. They are required for the build.
The Linux is also slightly modified. the mconf.c file had a reference to LC_ALL, which is normally defined in the locale.h (bits/locale.h) file. But that file isn't a part of the iomega published files, so I subsituted the actual value in. mconf.c is not a main part of the linux system anyway (I believe it's used for the menuconfig). I also removed all of the CVS/SVN and excess files to reduce the size from 150 MB down to 50 MB.
Oh yes, if you didn't notice, I have placed all of this on sourceforge as the opensphd (Open ScreenPlay Pro HD). Feel free to send me any patch files to improve the buildroot.
edit 4/26/2010: I have updated the files today. I figured out that the headers it was downloading were responsible from some of the problems. When I compared it with the conceptronic tools, I found that I could just use the unsanitized headers. This can easily be undone by deleting the linux-libc-headers-2.6.12.0.tar.bz2 file in the buildroot/dl directory. I also encountered the "mipsel-linux-objcopy missing" error discussed in the comments when I enabled initramfs. I was able to determine this was from the Makefile in the linux code that Iomega provided. it was not using the variables from Makefile so it would only find them if the staging_dir happened to be in your path. So I fixed that. The last thing I ran into was after g++ started compiling it then couldn't link on the device (worked fine from the PC staging directory but not on the ScreenPlay) because it was missing crt1.o and others. So I modified the scripts to copy those .o files as well when building the ext2 file.
Friday, June 12, 2009
Friday, May 29, 2009
Getting VSFTP working
In addition to getting SSH working that I just posted about, I also got VSFTP working.
The reason I chose VSFTP was because it was claimed that it was the fastest, or amongst the fastest of the FTP programs. I was not doing it for the ability to use SSL. The setup I describe here is NOT secure, as passwords are transmitted in clear text and susceptible to man-in-the-middle attacks. If you are interested in security, look at SSH. Also, look at the options for VSFTP. I didn't try SSL, so I don't know if it works. But you are welcome to try if security is more important than speed.
Speaking of speed, the fastest connection I was able to get out of it with a wifi was 1.3 MB/sec. Over wired it was 4.1 MB/sec down and 3.0 MB/sec up. So about the same speed as samba for transferring files over the same connection, maybe a little faster, but it was much faster than the BFTP found at RTD1261 wikidot, which clocked at around 500 MB/sec over wifi. Additionally, there is no 2 GB limit problem with VSFTP. I used FileZilla for my FTP transfer tests.
Setup is a little more complicated.
First, download the files: http://www.box.net/shared/68250x4psu
Again, I created the binaries from the new buildroot that I was able to create from the GPLed iomega source. I have a feeling this is what prevented my earlier efforts from working.
Once again, unzip the file into the root directory of the screenplay, preserving the directory structure. If you have previously run IomTools and had to do something like that before, then all you have to do is reboot the machine as the script will automatically run. If not, you will need to run the I10SetupVSFTP.sh script yourself.
When the script is finished, you will need to set up a new user.
The default user, ftp, is anonymous access and will provide read only access to the root of the ScreenPlay. This will automatically be set up for you. If you do not want to provide read only access to anonymous users, you will need to edit the /etc/vsftp/vsftp.conf file.
If you want write access to the drive, You will need to setup an account. You cannot use root unless you change root's home dir. I wouldn't suggest doing that. For this example, I'm going to use the user named ftpuser.
adduser -h /tmp/hddmedia -s /bin/nologon -H ftpuser
you will be prompted for a password. If you want the FTP account password protected (a good idea) then enter the password. If not, just press enter and have no password.
Now you will need to edit the /etc/passwd file to change the default group for the new user. vi /etc/passwd and you'll find a line that looks something like this:
ftpuser:$1$mUZ/dW81$bLAtC7pGOSvh3cnbdmHfm0:1003:1003:Linux user,,,:/tmp/hddmedia:/bin/nologon
That second number, right before "Linux user", is the group number. Change it to 0. yes, that will give that FTP user root privileges. The way I've set up the script, the HDD directory gets changed so that only the root group has access to write to it. The FTP login goes to the HDD directory and is chroot protected so that the screenplay media is the only set of directories the user has access to. I would set the group ownership, but the busybox that comes with the screenplay doesn't have that built in. So the paranoid will need to wait until I publish the new buildroot, or use the old buildroot, it might work. And then you can change the group ownership of the HDD directory.
Anyway, that's it. Enjoy.
Hopefully the way I've done SSH and VSFTP should make it easy to add into IomTools, if SuperBerny so desires. I've also given him the necessary code for manipulating the password, so he can add the feature to IomTools to set the root password and create users.
Edit: After playing around with it for a few days, what I'm experiencing on my local box is a lockup during file transfer. Not very consistent, sometimes it locks up after transferring several GB, but usually locks up after 1-2 GB has been transferred, at least downloading. I'm not sure if this is related to the 1.8 firmware, or the VSFTP program. I had lockups prior to VSFTP, so I'd appreciate feedback from others as to if they are seeing lockups on other firmware versions, or no lockups at all.
Edit 2: I have just updated the VSFTP program by compiling it with v4.2.4 of the GCC compiler. It seems to have solved the lockup problem. I was not only able to upload > 6 GB multiple times, and download > 6 GB, I was also able to upload multiple files simultaneously, which the prior compile was leaving dead processes after trying to do. VSFTP works really well now. I am using firmware R1.8. One note: The R1.0 firmware mounts the HDD with no executable permissions, and as a result, you cannot run the script off of the hard drive. So I would recommend either upgrading to R1.8, or running the script by typing sh < I10SetupVSFTP.sh to execute the script.
The reason I chose VSFTP was because it was claimed that it was the fastest, or amongst the fastest of the FTP programs. I was not doing it for the ability to use SSL. The setup I describe here is NOT secure, as passwords are transmitted in clear text and susceptible to man-in-the-middle attacks. If you are interested in security, look at SSH. Also, look at the options for VSFTP. I didn't try SSL, so I don't know if it works. But you are welcome to try if security is more important than speed.
Speaking of speed, the fastest connection I was able to get out of it with a wifi was 1.3 MB/sec. Over wired it was 4.1 MB/sec down and 3.0 MB/sec up. So about the same speed as samba for transferring files over the same connection, maybe a little faster, but it was much faster than the BFTP found at RTD1261 wikidot, which clocked at around 500 MB/sec over wifi. Additionally, there is no 2 GB limit problem with VSFTP. I used FileZilla for my FTP transfer tests.
Setup is a little more complicated.
First, download the files: http://www.box.net/shared/68250x4psu
Again, I created the binaries from the new buildroot that I was able to create from the GPLed iomega source. I have a feeling this is what prevented my earlier efforts from working.
Once again, unzip the file into the root directory of the screenplay, preserving the directory structure. If you have previously run IomTools and had to do something like that before, then all you have to do is reboot the machine as the script will automatically run. If not, you will need to run the I10SetupVSFTP.sh script yourself.
When the script is finished, you will need to set up a new user.
The default user, ftp, is anonymous access and will provide read only access to the root of the ScreenPlay. This will automatically be set up for you. If you do not want to provide read only access to anonymous users, you will need to edit the /etc/vsftp/vsftp.conf file.
If you want write access to the drive, You will need to setup an account. You cannot use root unless you change root's home dir. I wouldn't suggest doing that. For this example, I'm going to use the user named ftpuser.
adduser -h /tmp/hddmedia -s /bin/nologon -H ftpuser
you will be prompted for a password. If you want the FTP account password protected (a good idea) then enter the password. If not, just press enter and have no password.
Now you will need to edit the /etc/passwd file to change the default group for the new user. vi /etc/passwd and you'll find a line that looks something like this:
ftpuser:$1$mUZ/dW81$bLAtC7pGOSvh3cnbdmHfm0:1003:1003:Linux user,,,:/tmp/hddmedia:/bin/nologon
That second number, right before "Linux user", is the group number. Change it to 0. yes, that will give that FTP user root privileges. The way I've set up the script, the HDD directory gets changed so that only the root group has access to write to it. The FTP login goes to the HDD directory and is chroot protected so that the screenplay media is the only set of directories the user has access to. I would set the group ownership, but the busybox that comes with the screenplay doesn't have that built in. So the paranoid will need to wait until I publish the new buildroot, or use the old buildroot, it might work. And then you can change the group ownership of the HDD directory.
Anyway, that's it. Enjoy.
Hopefully the way I've done SSH and VSFTP should make it easy to add into IomTools, if SuperBerny so desires. I've also given him the necessary code for manipulating the password, so he can add the feature to IomTools to set the root password and create users.
Edit: After playing around with it for a few days, what I'm experiencing on my local box is a lockup during file transfer. Not very consistent, sometimes it locks up after transferring several GB, but usually locks up after 1-2 GB has been transferred, at least downloading. I'm not sure if this is related to the 1.8 firmware, or the VSFTP program. I had lockups prior to VSFTP, so I'd appreciate feedback from others as to if they are seeing lockups on other firmware versions, or no lockups at all.
Edit 2: I have just updated the VSFTP program by compiling it with v4.2.4 of the GCC compiler. It seems to have solved the lockup problem. I was not only able to upload > 6 GB multiple times, and download > 6 GB, I was also able to upload multiple files simultaneously, which the prior compile was leaving dead processes after trying to do. VSFTP works really well now. I am using firmware R1.8. One note: The R1.0 firmware mounts the HDD with no executable permissions, and as a result, you cannot run the script off of the hard drive. So I would recommend either upgrading to R1.8, or running the script by typing sh < I10SetupVSFTP.sh to execute the script.
Getting SSH working
I finally got the Iomega GPL source to compile and link in a way that didn't lock up when I did a chroot :) The uClibc binary library is a very close match to the uClibc library on the SPP. Not perfect yet, I'm getting there. But as close as it is now, I've been able to get some things working that weren't working before.
SSH, for one.
Now, a warning. The SSH is for encrypted transmission. I believe this encryption process slows down the throughput rate of the Screenplay. When doing scp to transfer a file, the fastest I got was about 300 KB/s going over wifi. That's not very good. The FTP found at rtd1261.wikidot.com runs at about 500 KB/s over the same connection. Nonetheless, there are a variety of options in SSH and maybe somebody more knowledgable about SSH than me can figure out how to fine tune this and make it faster for the SPP.
So, if you want to install SSH anyway you start by downloading the binaries I created:
http://www.box.net/shared/o4e84c03ag
Unzip the file into the root of the screenplay, preserving the directories. Now, if you have previously used the IomTools and had to unzip the Setup files, then all you need to do is turn off and turn on the screenplay again and that I10SetupSSH.sh script will automatically run. Otherwise, you will need to run the script yourself.
Now, if you haven't already set the root password, then I have to ask if you are really that serious about security... Anyway, if you haven't, then telnet into the device and set the root password. You should then be able to use ssh to do all further communications.
How did I create the binaries? SSH was an option in the buildroot, so all I did to create the files was to turn on the option and rebuild. Then it was just a matter of copying the libraries and executables one at a time until I had determined which ones were needed to get it started.
SSH does not appear to have the 2 GB limit problem like the FTP from rtd1261.
SSH, for one.
Now, a warning. The SSH is for encrypted transmission. I believe this encryption process slows down the throughput rate of the Screenplay. When doing scp to transfer a file, the fastest I got was about 300 KB/s going over wifi. That's not very good. The FTP found at rtd1261.wikidot.com runs at about 500 KB/s over the same connection. Nonetheless, there are a variety of options in SSH and maybe somebody more knowledgable about SSH than me can figure out how to fine tune this and make it faster for the SPP.
So, if you want to install SSH anyway you start by downloading the binaries I created:
http://www.box.net/shared/o4e84c03ag
Unzip the file into the root of the screenplay, preserving the directories. Now, if you have previously used the IomTools and had to unzip the Setup files, then all you need to do is turn off and turn on the screenplay again and that I10SetupSSH.sh script will automatically run. Otherwise, you will need to run the script yourself.
Now, if you haven't already set the root password, then I have to ask if you are really that serious about security... Anyway, if you haven't, then telnet into the device and set the root password. You should then be able to use ssh to do all further communications.
How did I create the binaries? SSH was an option in the buildroot, so all I did to create the files was to turn on the option and rebuild. Then it was just a matter of copying the libraries and executables one at a time until I had determined which ones were needed to get it started.
SSH does not appear to have the 2 GB limit problem like the FTP from rtd1261.
Thursday, May 14, 2009
1.8 firmware differences
For those not already aware, iomega has released its 1.8 firmware available on the support download page.
Doing a quick comparison of the 1.8 firmware vs the 1.0 firmware files:
New Files:
ufsd.ko - Paragon NTFS driver (possibly fixes the Norton problem)
ntfsmount - another NTFS driver from ntfsprogs
DejaVuSans.ttf - font
DroidSansFallback.ttf - font
Grotesk Pro Regular.otf - font
snmpd and some directories with many snmp related files.
Removed Files:
arial.ttf
cwheib.ttf
cwyen.ttf
gkai00mp.ttf
Changed files:
inetd.conf - commented out telnet and www. Added in iodiscovery, and a commented out snmp with a note saying snmpd moved to rcS1.
rcS1 - now installs ufsd.ko and mounts the media partition using that. The "8th" partition (not on any SPP drives I've seen) is being mounted using ntfsmount.
rcS1.4partition - same changes as rcS1
services - added iodiscovery, port 6553 udp and tcp.
smb.conf - Comments removed, making it more difficult for people not familiar with the smb.conf file to change it. Max opened files upped from 1000 to 10000. Max connections upped to 4. Max smbd processed upped to 4. Log size increased to 1000. passdb backend changed to smbpasswd instead of tdbsam. oplocks changed to yes.
removed:
write cache size = 0
max mux = 10
min protocol = NT1
stat cache = no
strict sync = yes
sync always = yes
added:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2048 SO_RCVBUF=2048
read raw=yes
write raw=yes
max xmit=65535
dead time=15
getwd cache=yes
lpq cache=30
read prediction=yes
client NTLMv2 auth=yes
.str files: renamed Shared key (WEP) to WEP Key. Added ShiftJIS and Cyrillic strings. In those where the aspect was listed as 16:09, it was changed to 16:9. Many russian translations changed.
Binaries that changed:
DvdPlayer - Main player menu program
wpa_cli - WPA command line interface to wpa_supplicant
wpa_supplicant - WPA authentication provider
IO_Discovery - Daemon for responding to Discovery calls from the PC
IO_Discovery1 - Same, although slightly different binary.
nmbd - Part of Samba, Responds to NetBios over IP requests
smbd - Part of Samba, responds to file sharing requests
initrd.bin - Initial ram disk boot
install_ide_pvrbox_pc_v2 - Screenplay program that executes after copying firmware to do the install.
The following files are significant in the fact that they did NOT change.
busybox - no new linux commands
All files in the kernel/usb directory - meaning no new wifi devices supported
video_firmware.bin - meaning no new codecs or changes to existing ones.
hotplug - meaning the attaching of external USB drives will still be mounted using the kernel NTFS driver for those NTFS drives. So if those drives have been "modified" by Norton antivirus products, those would effectively stop the screenplay from booting still. Edit: Not true, see comment.
Doing a quick comparison of the 1.8 firmware vs the 1.0 firmware files:
New Files:
ufsd.ko - Paragon NTFS driver (possibly fixes the Norton problem)
ntfsmount - another NTFS driver from ntfsprogs
DejaVuSans.ttf - font
DroidSansFallback.ttf - font
Grotesk Pro Regular.otf - font
snmpd and some directories with many snmp related files.
Removed Files:
arial.ttf
cwheib.ttf
cwyen.ttf
gkai00mp.ttf
Changed files:
inetd.conf - commented out telnet and www. Added in iodiscovery, and a commented out snmp with a note saying snmpd moved to rcS1.
rcS1 - now installs ufsd.ko and mounts the media partition using that. The "8th" partition (not on any SPP drives I've seen) is being mounted using ntfsmount.
rcS1.4partition - same changes as rcS1
services - added iodiscovery, port 6553 udp and tcp.
smb.conf - Comments removed, making it more difficult for people not familiar with the smb.conf file to change it. Max opened files upped from 1000 to 10000. Max connections upped to 4. Max smbd processed upped to 4. Log size increased to 1000. passdb backend changed to smbpasswd instead of tdbsam. oplocks changed to yes.
removed:
write cache size = 0
max mux = 10
min protocol = NT1
stat cache = no
strict sync = yes
sync always = yes
added:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2048 SO_RCVBUF=2048
read raw=yes
write raw=yes
max xmit=65535
dead time=15
getwd cache=yes
lpq cache=30
read prediction=yes
client NTLMv2 auth=yes
.str files: renamed Shared key (WEP) to WEP Key. Added ShiftJIS and Cyrillic strings. In those where the aspect was listed as 16:09, it was changed to 16:9. Many russian translations changed.
Binaries that changed:
DvdPlayer - Main player menu program
wpa_cli - WPA command line interface to wpa_supplicant
wpa_supplicant - WPA authentication provider
IO_Discovery - Daemon for responding to Discovery calls from the PC
IO_Discovery1 - Same, although slightly different binary.
nmbd - Part of Samba, Responds to NetBios over IP requests
smbd - Part of Samba, responds to file sharing requests
initrd.bin - Initial ram disk boot
install_ide_pvrbox_pc_v2 - Screenplay program that executes after copying firmware to do the install.
The following files are significant in the fact that they did NOT change.
busybox - no new linux commands
All files in the kernel/usb directory - meaning no new wifi devices supported
video_firmware.bin - meaning no new codecs or changes to existing ones.
hotplug - meaning the attaching of external USB drives will still be mounted using the kernel NTFS driver for those NTFS drives. So if those drives have been "modified" by Norton antivirus products, those would effectively stop the screenplay from booting still. Edit: Not true, see comment.
Tuesday, April 28, 2009
I'm still here
Just a quick update. I know I haven't posted anything recently. I've been really busy with work. It's been eating up all of my personal time. What I was working on before that onslaught of endless and challenging work assignments was merging the code published by Iomega and the code published by some other RTD 1262 players into the buildroot I had constructed. I was able to rebuild it, and executables that weren't working before started working. However, it could no longer chroot successfully due to some problem with the uclibc main library. So I did some comparisons and I've been recompiling with different options to get the working and nonworking libraries closer to the same code. When I get there, I'll publish the results. I think this will give me everything I need to build the kernel modules.
Thursday, February 26, 2009
Examining the 8 files.
One of the 8 files extracted during the last blog entry is called "install_ide_pvrbox_pc_v2"
Well, this file has the familiar 3 letter word at the beginning... ELF!
Hmm, sounds like something that will install the PVR utilities... So I thought about it for a second, realized I had nothing on my SPP to lose right now anyway, so I went ahead and ran it.
PVR BOX from PC install v2 0......Aug 28 2008 19:05:32
It goes through a script and ultimately fails at the end. What it was trying to set up and run (which failed because I was logged into a drive that had mounted partitions) was the basic partitions that the screenplay starts with. So this is probably used for the initial setup to do everything required to set up the drive for the firmware installation. In fact, looking at the file in HxD, I see a bunch of interesting text. One seems to suggest that it can set up a FAT partition. So there may be some way to tell it to add PVR yet...
But this was also interesting: "tar -xjvf /mnt/hdc/ext3.img -C /mnt/hdc.ext3"
That is just a reference to the tarball in the install.img file. But that proves that his program is the one responsible for the update once you turn on the player after you've installed a firmware.
Video_firmware.bin is another one of the files in that set of 8. And I believe it is probably the microcode that gets flashed into the RTD 1262 chip itself. My basis for that belief is that if you look at the file using HxD in 16 bytes per row, you will find a graphical representation of the numbers 0-9, and then references to the decoders, MPEG-2, MPEG4, GOP, JPeg, YUV/RGB888/RGB565 -- these are all terms associated with encoders and decoders. My guess is that this will be the file we'll have to change to add H.264.
The GetUSBDev.dll, GetUSBDev.dat, and DeviceInfo.dll are probably just associated with hooking up to the ScreenPlay from the PC and transferring the information on. Arial.ttf, a font, is found on the screenplay itself, so it may just be there for when the installer wants to write some letters to the screen, such as "do not turn off".
That's all for now.
Well, this file has the familiar 3 letter word at the beginning... ELF!
Hmm, sounds like something that will install the PVR utilities... So I thought about it for a second, realized I had nothing on my SPP to lose right now anyway, so I went ahead and ran it.
PVR BOX from PC install v2 0......Aug 28 2008 19:05:32
It goes through a script and ultimately fails at the end. What it was trying to set up and run (which failed because I was logged into a drive that had mounted partitions) was the basic partitions that the screenplay starts with. So this is probably used for the initial setup to do everything required to set up the drive for the firmware installation. In fact, looking at the file in HxD, I see a bunch of interesting text. One seems to suggest that it can set up a FAT partition. So there may be some way to tell it to add PVR yet...
But this was also interesting: "tar -xjvf /mnt/hdc/ext3.img -C /mnt/hdc.ext3"
That is just a reference to the tarball in the install.img file. But that proves that his program is the one responsible for the update once you turn on the player after you've installed a firmware.
Video_firmware.bin is another one of the files in that set of 8. And I believe it is probably the microcode that gets flashed into the RTD 1262 chip itself. My basis for that belief is that if you look at the file using HxD in 16 bytes per row, you will find a graphical representation of the numbers 0-9, and then references to the decoders, MPEG-2, MPEG4, GOP, JPeg, YUV/RGB888/RGB565 -- these are all terms associated with encoders and decoders. My guess is that this will be the file we'll have to change to add H.264.
The GetUSBDev.dll, GetUSBDev.dat, and DeviceInfo.dll are probably just associated with hooking up to the ScreenPlay from the PC and transferring the information on. Arial.ttf, a font, is found on the screenplay itself, so it may just be there for when the installer wants to write some letters to the screen, such as "do not turn off".
That's all for now.
Cracking the upgrade.bin file
I needed to detail what I found out about the upgrade.bin file and how. If you want to know the format, just jump to the end of this post. I'm going to detail how I figured out the format.
For hacking this, HxD is one of the best programs in the world. And free, too!!
I set it to view 16 bytes at a time, both ascii and hex. Programmers like alignment on powers of two, and this is a very common one.
Right away, I see filenames near the beginning. And appearing in a fixed pattern too. The pattern repeats itself every 0x40 (64) bytes. It appears to start at 0x20, so there's some sort of header we'll have to decipher before that. But lets finish with the file structure.
Obviously the filename starts at offset 0x8 in that file structure. All of them are 24 bytes or less, and everything else is zeroes. So that remainder could be reserved for longer filename, but we don't know that for sure. The first part would have to identify where in the upgrade.bin it is, and how long it is. So looking at the easiest one: ChangeNote.txt. This is the easiest because it is searchable text. So we look through the file and find the text at the end of the file. Going back from the end, we find that the text likely starts at position 0x024a2ff8 in the file. Looking at the bytes before the filename we have f8 2f 4a 02 f9 08 00 00. At this point, it's pretty obvious to me. That's a simple lo-byte/hi-byte storage of the position first as a dword (32 bit), and if we apply that same thing to the second dword it's 0x000008f9, or 2297 bytes. That appears to be the length of the file.
So now to look at the header bytes. Based on the format of the file size and location, let's look at this as a group of dwords.
There a dword for 8. There's 8 files. Probably the number of files.
Nothing else seems familiar.
Looking at the differences in hex between the R1 and R1.1 upgrade.bin files, I see a change in offset 0x08-0x0b and another one at 0x10. Nothing else in that header changes. So those could easily be two different checksums. So I use HxD to highlight from 0x220 to the end of the file and calculate the checksums. Nothing matches. Hmmm. The checksum might include the file names and sizes. So I highlight from 0x20 to the end of the file and select to calculate the checksums. Checksum-32 FB4B0c59, it's a match with the 3rd dword! Doublecheck with R1.1 and it's a match! Ok, that solves part of the problem. Now, what about this one byte change at 0x10...
I change it in HxD and start DataInstaller.... The firmware package version number changed. So there we have it! Appears to be one word long that represents the number to the right of the decimal. Playing with the word at 0x0c, that appears to change the version to the left of the decimal.
Change the first dword and try to run. It says "Upgrade.bin not firmware update package, please check it then try again!" Ok, so this is a magic number for identifying the file. Tried it with the second dword. Same thing. Tried it with the other unknowns dwords. No change. Hmmm, well that's all I can research for now. So this is the structure as I've decoded it so far. I've written a small C program to extract out the individual files.
struct Header {
dword magic1 = 0x075bcd15
dword magic2 = 0x00002710
dword checksum
dword majorversion
dword minorversion
dword unknown1 = 0x00080001
dword unknown2 = 0x00000003
dword NumberOfFiles
}
struct FileList[8]
{
dword offset
dword FileSize
char FileName[24]
char Unknown[32] // this may be part of the filename, but none of the upgrades use it yet so it's not guaranteed.
}
Checksum is calculated by adding all of the bytes together, tracking up to 32 bits (ignoring overflow).
Super has indicated in the comments of "fun with player" that inside the upgrade.bin file is a tarball of the first partition. This is actually embedded in the "install.img" file that comes out of the upgrade.bin. You can find the start of the tarball by looking for it's magic number "BZh9" which is at position 0x0854216 of the upgrade.bin file for R1 firmware, or 0x0674cc6 in the install.img file.
Here's the source code & executable for extracting out the 8 files in the upgrade.bin file. http://www.box.net/shared/3dn0szidjs
Whatever directory your current directory is when you run the executable is where the extracted files will end up. You specify the location of the upgrade.bin file on the command line.
For example:
split c:\upgrade.bin
Edit: Something else I figured I'd mention. When you run the firmware installer, it extracts those 8 files to c:\documents and settings\yourlogin\Local Settings\Temp\DATA and so there is another easy way to get that. When it's done or you click cancel, it automatically delete those files.
For hacking this, HxD is one of the best programs in the world. And free, too!!
I set it to view 16 bytes at a time, both ascii and hex. Programmers like alignment on powers of two, and this is a very common one.
Right away, I see filenames near the beginning. And appearing in a fixed pattern too. The pattern repeats itself every 0x40 (64) bytes. It appears to start at 0x20, so there's some sort of header we'll have to decipher before that. But lets finish with the file structure.
Obviously the filename starts at offset 0x8 in that file structure. All of them are 24 bytes or less, and everything else is zeroes. So that remainder could be reserved for longer filename, but we don't know that for sure. The first part would have to identify where in the upgrade.bin it is, and how long it is. So looking at the easiest one: ChangeNote.txt. This is the easiest because it is searchable text. So we look through the file and find the text at the end of the file. Going back from the end, we find that the text likely starts at position 0x024a2ff8 in the file. Looking at the bytes before the filename we have f8 2f 4a 02 f9 08 00 00. At this point, it's pretty obvious to me. That's a simple lo-byte/hi-byte storage of the position first as a dword (32 bit), and if we apply that same thing to the second dword it's 0x000008f9, or 2297 bytes. That appears to be the length of the file.
So now to look at the header bytes. Based on the format of the file size and location, let's look at this as a group of dwords.
There a dword for 8. There's 8 files. Probably the number of files.
Nothing else seems familiar.
Looking at the differences in hex between the R1 and R1.1 upgrade.bin files, I see a change in offset 0x08-0x0b and another one at 0x10. Nothing else in that header changes. So those could easily be two different checksums. So I use HxD to highlight from 0x220 to the end of the file and calculate the checksums. Nothing matches. Hmmm. The checksum might include the file names and sizes. So I highlight from 0x20 to the end of the file and select to calculate the checksums. Checksum-32 FB4B0c59, it's a match with the 3rd dword! Doublecheck with R1.1 and it's a match! Ok, that solves part of the problem. Now, what about this one byte change at 0x10...
I change it in HxD and start DataInstaller.... The firmware package version number changed. So there we have it! Appears to be one word long that represents the number to the right of the decimal. Playing with the word at 0x0c, that appears to change the version to the left of the decimal.
Change the first dword and try to run. It says "Upgrade.bin not firmware update package, please check it then try again!" Ok, so this is a magic number for identifying the file. Tried it with the second dword. Same thing. Tried it with the other unknowns dwords. No change. Hmmm, well that's all I can research for now. So this is the structure as I've decoded it so far. I've written a small C program to extract out the individual files.
struct Header {
dword magic1 = 0x075bcd15
dword magic2 = 0x00002710
dword checksum
dword majorversion
dword minorversion
dword unknown1 = 0x00080001
dword unknown2 = 0x00000003
dword NumberOfFiles
}
struct FileList[8]
{
dword offset
dword FileSize
char FileName[24]
char Unknown[32] // this may be part of the filename, but none of the upgrades use it yet so it's not guaranteed.
}
Checksum is calculated by adding all of the bytes together, tracking up to 32 bits (ignoring overflow).
Super has indicated in the comments of "fun with player" that inside the upgrade.bin file is a tarball of the first partition. This is actually embedded in the "install.img" file that comes out of the upgrade.bin. You can find the start of the tarball by looking for it's magic number "BZh9" which is at position 0x0854216 of the upgrade.bin file for R1 firmware, or 0x0674cc6 in the install.img file.
Here's the source code & executable for extracting out the 8 files in the upgrade.bin file. http://www.box.net/shared/3dn0szidjs
Whatever directory your current directory is when you run the executable is where the extracted files will end up. You specify the location of the upgrade.bin file on the command line.
For example:
split c:\upgrade.bin
Edit: Something else I figured I'd mention. When you run the firmware installer, it extracts those 8 files to c:\documents and settings\yourlogin\Local Settings\Temp\DATA and so there is another easy way to get that. When it's done or you click cancel, it automatically delete those files.
Subscribe to:
Posts (Atom)