Thursday, December 17, 2009
Recent progress
Currently working with some of the people over at the xtreamer forums. Some have been looking at the Ellion sources and if we can get to the point that the Hello World is displaying on the Ellion, then it may result in more people looking and helping to understand the Realtek chip (although the xtreamer uses the 1073, but there should be many common things between that and the 1282). Feel free to join the discussion.
Sunday, November 29, 2009
Update and minor discovery
I haven't been posting much to my blog, but what I've been doing is studying the Ellion source and trying to understand the structure.
I have managed to create the traditional "hello world" and have it appear on the TV. That may not seem significant, but for me that's a major step forward since it means I have all of the steps identified for initializing the ScreenPlay. However, most of the steps for painting the rectangle, loading the font and writing the Hello World text on screen still rely on the internal structures of the DvdPlayer program.
In the process, I've had to stop/restart multiple times. Each time that the program stops, whatever was displayed on the TV stays there. If you try to run the program again, it fails to allocate graphical memory because the memory is already allocated. I've been using "stopall" to free up the memory.
What I didn't realize was that stopall was NOT the program responsible for freeing up the memory. It's RootApp, which is called without any command line arguments by the stopall program.
Well, the code for RootApp reinitialize can now be incorporated into my starting Hello World program to auto reinitialize each time :) Like I said, minor discovery, but I felt it was worth sharing anyway.
I have managed to create the traditional "hello world" and have it appear on the TV. That may not seem significant, but for me that's a major step forward since it means I have all of the steps identified for initializing the ScreenPlay. However, most of the steps for painting the rectangle, loading the font and writing the Hello World text on screen still rely on the internal structures of the DvdPlayer program.
In the process, I've had to stop/restart multiple times. Each time that the program stops, whatever was displayed on the TV stays there. If you try to run the program again, it fails to allocate graphical memory because the memory is already allocated. I've been using "stopall" to free up the memory.
What I didn't realize was that stopall was NOT the program responsible for freeing up the memory. It's RootApp, which is called without any command line arguments by the stopall program.
Well, the code for RootApp reinitialize can now be incorporated into my starting Hello World program to auto reinitialize each time :) Like I said, minor discovery, but I felt it was worth sharing anyway.
Friday, November 6, 2009
More about Ellion Firmware on Iomega ScreenPlay Pro HD
Ok, here's the code for the remotes:
RemoteControl.cpp
And then a minor adjustment in RemoteControl.h. I added:
So how did I find out the IOMEGA_CUSTOMER_CODE value? In the ir_control.cpp program, there's a couple of places where IRCodeTranslate(key) is called. All I had to do was put a printf("code: %x\n", key); before it, then run the ./DvdPlayer and press a few remote buttons. It is the last 4 characters (LO WORD) that are returned. At least, for that particular remote protocol it is. That's a fairly common remote protocol, but they did have one other listed (which I left commented in the above code).
So what's so exciting about the Ellion vs the Iomega in terms of functionality? There are several features that the Ellion had implemented that were wish list items on the Iomega.
1) Screensaver
2) USB shows label on NTFS drives
3) Ability to shut off the preview
4) Returns to where you left off. If you exit to the main menu and then reselect the HDD drive, you'll be in the same directory as when you left.
5) Continue movie after stop.
6) Timeshifting (doesn't yet work, may require a dedicated partition on the hard drive)
7) Network browsing / favorites (appears to be able to store username/password, can access root of hard drive).
8) NDAS friendly
9) Favorites folder
10) Auto Chapter during recording
11) Can record to USB
12) Can edit recorded video
13) Good file copy / management
14) Quick display of wifi integrity by pressing display button twice
In addition, there is also DTV tuning and channel scan/set. These are not useful on the Iomega, at least not until somebody figures out what hardware is needed to hook up to the iomega to get it working. There's definitely an area in the bottom of the drive reserved for it, so it's just a matter of determining what tuner module needs to be added.
Now, it's not a pretty interface. Some of the words are very hard to see (for instance, white on yellow) but that kind of thing is easy to change (just edit the Resources in the resource folder). Mapping buttons on the remote to other key commands should be easy. I'm eyeing the instant replay and commercial skip commands.
Also worth mentioning... when I was playing a movie and pressed Home, the menu translucently overlaid the video, which continued to play in the background. That's good, because it means it will be possible to do that in a future replacement media player. So there is a lot we can learn from studying this firmware.
RemoteControl.cpp
#include <Platform_Lib/RemoteControl/RemoteControl.h>
ENUM_REMOTE_PROTOCOL getIRProtocol(void) {
// return IR_PROCOTOL_C03;
return IR_PROCOTOL_NEC;
};
char IRCodeTranslate(int code) {
if((code & 0x0000ffff) != IOMEGA_CUSTOMER_CODE)
return -1;
switch((code & 0x00ff0000)>>16) {
//for the complete list of available commands, see Include/Platform_Lib/Graphics/user_cmd.h
case 18: return CMD_POWER;
case 27: return CMD_DISPLAY;
case 72: return CMD_SETUP;
case 21: return CMD_PSCAN;
case 22: return CMD_MENU;
case 12: return CMD_GUIDE;
case 1: return CMD_UP;
case 9: return CMD_DOWN;
case 25: return CMD_LEFT;
case 17: return CMD_RIGHT;
case 23: return CMD_SELECT;
case 31: return CMD_RETURN;
case 8: return CMD_DELETE;
case 24: return CMD_ZERO;
case 65: return CMD_ONE;
case 77: return CMD_TWO;
case 69: return CMD_THREE;
case 66: return CMD_FOUR;
case 78: return CMD_FIVE;
case 70: return CMD_SIX;
case 67: return CMD_SEVEN;
case 79: return CMD_EIGHT;
case 71: return CMD_NINE;
case 4: return CMD_STOP;
case 14: return CMD_NEXT;
case 15: return CMD_PREV;
case 20: return CMD_FFWD;
case 28: return CMD_FRWD;
case 11: return CMD_SEARCH;
case 3: return CMD_REPEAT;
case 2: return CMD_AB_REPEAT;
case 75: return CMD_STITLE;
case 73: return CMD_AUDIO;
case 74: return CMD_ANGLE;
case 16: return CMD_ZOOM;
case 13: return CMD_VOL_UP;
case 19: return CMD_VOL_DOWN;
case 29: return CMD_FORCE_RECORD;
case 26: return CMD_SOURCE;
// return CMD_EJECT;
// return CMD_GCODE;
// return CMD_SCHEDULE;
// return CMD_DISC_UTILITY;
// return CMD_HDD;
// return CMD_DVD;
// return CMD_USB;
// return CMD_DVCONTROL;
// return CMD_FILE_COPY;
// return CMD_INSTANT_REPLAY;
// return CMD_CMSKIP; // commercial skip
// return CMD_RECORD_PLAY;
// return CMD_PLAY;
// return CMD_PAUSE;
// return CMD_SFWD;
// return CMD_MUTE;
// return CMD_ZOOM_IN;
// return CMD_ZOOM_OUT;
// return CMD_QUALITY;
// return CMD_NET; // ellion specific
default:
return -1;
}
}
And then a minor adjustment in RemoteControl.h. I added:
#define IOMEGA_CUSTOMER_CODE 0x3F40
So how did I find out the IOMEGA_CUSTOMER_CODE value? In the ir_control.cpp program, there's a couple of places where IRCodeTranslate(key) is called. All I had to do was put a printf("code: %x\n", key); before it, then run the ./DvdPlayer and press a few remote buttons. It is the last 4 characters (LO WORD) that are returned. At least, for that particular remote protocol it is. That's a fairly common remote protocol, but they did have one other listed (which I left commented in the above code).
So what's so exciting about the Ellion vs the Iomega in terms of functionality? There are several features that the Ellion had implemented that were wish list items on the Iomega.
1) Screensaver
2) USB shows label on NTFS drives
3) Ability to shut off the preview
4) Returns to where you left off. If you exit to the main menu and then reselect the HDD drive, you'll be in the same directory as when you left.
5) Continue movie after stop.
6) Timeshifting (doesn't yet work, may require a dedicated partition on the hard drive)
7) Network browsing / favorites (appears to be able to store username/password, can access root of hard drive).
8) NDAS friendly
9) Favorites folder
10) Auto Chapter during recording
11) Can record to USB
12) Can edit recorded video
13) Good file copy / management
14) Quick display of wifi integrity by pressing display button twice
In addition, there is also DTV tuning and channel scan/set. These are not useful on the Iomega, at least not until somebody figures out what hardware is needed to hook up to the iomega to get it working. There's definitely an area in the bottom of the drive reserved for it, so it's just a matter of determining what tuner module needs to be added.
Now, it's not a pretty interface. Some of the words are very hard to see (for instance, white on yellow) but that kind of thing is easy to change (just edit the Resources in the resource folder). Mapping buttons on the remote to other key commands should be easy. I'm eyeing the instant replay and commercial skip commands.
Also worth mentioning... when I was playing a movie and pressed Home, the menu translucently overlaid the video, which continued to play in the background. That's good, because it means it will be possible to do that in a future replacement media player. So there is a lot we can learn from studying this firmware.
Wednesday, November 4, 2009
That's not my menu...!
Tonight, I found that in the Ellion Open source, UnitTest/Grandma_DG_StateMachine was the source code for the DvdPlayer. It was everything necessary, but referenced a few things that weren't quite right. For one, it tried to get to the Utility and Platform_Lib as if they were right there. So I put in a symbolic link to put them there. Second was that it was trying to reference the mp3info.h in the mp3info directory when it was really in the mp3info/Include directory. So I copied to to the mp3info directory (yeah, I should have used a hard link instead, doh!)
Last piece was that it was trying to get to a Tools/MConfig, which wasn't there. So I found a Tools/MConfig in the conceptronic sources and put it there. It all compiled (and I mean compiled, not linked a bunch of already compiled .o files :D )
I copied it and the resource directory out on the ScreenPlay. Like in previous attempts, it came up in Pal mode. Unlike in previous attempts, it was now reading the keyboard. So I exited the program and this time brought it up by typing ./DvdPlayer -f NTSC which forced it to NTSC mode.
It worked.
The remote control didn't work, but I could control everything from the keyboard through telnet. I was able to complete the configuration screen, then browse to both the USB and Main hard drives. Naturally, the menu is based on the same principles that the Iomega SPP is, where it just lists filenames and shows a preview. But I was able to browse to specific movies and launch them.
Since there is a file called ir_control.cpp in the directory, I'm positive I'll be able to get the remote control working...
But not tonight. It'll have to wait a couple of nights before I can get back to it.
Update: Too excited to sleep tonight. RemoteControl.cpp and RemoteControl.h in the Platform_Lib were the ones responsible. In RemoteControl.h, it defines the manufacturer's code for the Ellion, which they had two. So I stuck in a printf in the ir_control.cpp to find out what remote code was for the Iomega, and found out mine was 0x3f40. Stuck that in, now it should process the codes...except that the codes are all different. Luckily, prior work has paid off now: http://screenplayprohd.wikia.com/wiki/Remote the bottom half JP1 OBC codes are listed. So it is just a matter of changing the RemoteControl.cpp switch statement to use the Iomega codes intead of the Ellion ones. :)
Last piece was that it was trying to get to a Tools/MConfig, which wasn't there. So I found a Tools/MConfig in the conceptronic sources and put it there. It all compiled (and I mean compiled, not linked a bunch of already compiled .o files :D )
I copied it and the resource directory out on the ScreenPlay. Like in previous attempts, it came up in Pal mode. Unlike in previous attempts, it was now reading the keyboard. So I exited the program and this time brought it up by typing ./DvdPlayer -f NTSC which forced it to NTSC mode.
It worked.
The remote control didn't work, but I could control everything from the keyboard through telnet. I was able to complete the configuration screen, then browse to both the USB and Main hard drives. Naturally, the menu is based on the same principles that the Iomega SPP is, where it just lists filenames and shows a preview. But I was able to browse to specific movies and launch them.
Since there is a file called ir_control.cpp in the directory, I'm positive I'll be able to get the remote control working...
But not tonight. It'll have to wait a couple of nights before I can get back to it.
Update: Too excited to sleep tonight. RemoteControl.cpp and RemoteControl.h in the Platform_Lib were the ones responsible. In RemoteControl.h, it defines the manufacturer's code for the Ellion, which they had two. So I stuck in a printf in the ir_control.cpp to find out what remote code was for the Iomega, and found out mine was 0x3f40. Stuck that in, now it should process the codes...except that the codes are all different. Luckily, prior work has paid off now: http://screenplayprohd.wikia.com/wiki/Remote the bottom half JP1 OBC codes are listed. So it is just a matter of changing the RemoteControl.cpp switch statement to use the Iomega codes intead of the Ellion ones. :)
Tuesday, November 3, 2009
smbpasswd
Inspired from a forum post on the wiki, I decided to try to get smbpasswd going.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
Sunday, November 1, 2009
Temporary diversion -- VSFTP and BFTPD
Super has been waiting for some help from me regarding VSFTP and BFTPD. I thought those were already in IomTools, but apparently the functions were not yet there. So I've helped with what I can and hopefully we'll see the new version soon.
Along the process, I discovered that VSFTP could not use the anonymous upload for the root directory. You have to create a directory on the media partition to do anonymous uploads. I had discovered this when I originally documented it on the wiki, but had forgotten and had to "rediscover" it. So I put it on the wiki this time.
Along the process, I discovered that VSFTP could not use the anonymous upload for the root directory. You have to create a directory on the media partition to do anonymous uploads. I had discovered this when I originally documented it on the wiki, but had forgotten and had to "rediscover" it. So I put it on the wiki this time.
Monday, October 26, 2009
Start of compiling
Really late right now so I'll do a quick synopsis: The source for 1.00.011 APP is missing some pieces. I'm downloading the 2.00.004 sources now to see if the missing pieces are there instead. But then I started playing around with the Ellion sources.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
Saturday, October 24, 2009
Organization, and yet another toolchain (conceptronic / media giant)
Organization. I have two external 1 TB drives with ISOs and I've moved all of my stuff off of the screenplay so I can experiment with it. In the process, I decided to switch back to EXT3 for the screenplay. The screenplayprohd.wikia.com wiki details how to do that in filesystem. Anyway, after reformatting the drive, I then organized all of the videos on the other two drives under one directory called Alphabetical, and then subdirectories from there ABC, DEF, GHI, JKL, and so on with VWXYZ all in the same. So both external drives had that. Underneath each of those directories, I put another directory for each movie / group of movies. For instance, all of the Star Wars ISOs are under Alphabetical/STU/Star Wars.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
cd Alphabetical
rm -r *
mkdir ABC
mkdir DEF
mkdir GHI
mkdir JKL
mkdir MNO
mkdir PQR
mkdir STU
mkdir VWXYZ
ln -s /tmp/usbmounts/sda1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sda1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sda1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sda1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sda1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sda1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sda1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sda1/Alphabetical/VWXYZ/* VWXYZ &
ln -s /tmp/usbmounts/sdb1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sdb1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sdb1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sdb1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sdb1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sdb1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sdb1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sdb1/Alphabetical/VWXYZ/* VWXYZ &
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
Wednesday, October 21, 2009
Controlling the dvdplayer from an external program
Well, I figured out a couple of things today, my day off...
First, the RootApp. I figured out that it is required in order for the Power Off button to work. Otherwise, the unit does not shut down properly. This becomes critical with the second discovery...
In a prior post, Fun with the Player I detailed that you have telnet control over the screenplay if you launch the DvdPlayer program after executing a stopall. You can then send keypresses to remote control the screenplay. This trick was stopped in R1.8 firmware, although it still works if you kill -9 the RootApp process. The real trick is to get it to allow you to connect to some kind of key queue that you can fill up after the screenplay is booted.
For the ScreenPlay Pro, the /usr/local/etc has an rcS file that launches the DvdPlayer portion in conjunction with the RootApp. So, using a suggestion from jamoba posted to the emtec group back in february, I modified my rcS as follows:
if [ -f $DEFAULT_AP_DIR/DvdPlayer ] && [ -x $DEFAULT_AP_DIR/DvdPlayer ]; then
cd $DEFAULT_AP_DIR
if [ -f $DEFAULT_AP_DIR/RootApp ] && [ -x $DEFAULT_AP_DIR/RootApp ]; then
echo Running dvdplayer with RootApp
touch /tmp/command_sender.txt
tail -f /tmp/command_sender.txt | RootApp DvdPlayer -l on -o /var/log/dvdplayer/user_input&
else
echo Running dvdplayer
./DvdPlayer -l on -o /var/log/dvdplayer/user_input&
fi
else
/usr/local/etc/dvdplayer/script/run_tail
fi
sleep 10
cat /tmp_orig/startscript >> /tmp/command_sender.txt
So basically, I have a series of keypresses in the startscript file that it sends 10 seconds after launching the program, which is just about right. I can have the startscript read something like:
XX
(There's a single space before XX and a single space after)
To have it automatically go into the ScreenPlay drive and press down twice and select the folder or media at that location.
Now, if I wanted to send more keystrokes outside of the startscript, I can simply add to the /tmp/command_sender.txt by commands like "echo O >> command_sender.txt" to have it automatically shut down the screenplay. I can do this in a telnet prompt AFTER the screenplay has booted. Theoretically, I could write an http webpage that displays all of my movies, say in thumbnail mode, and if I select one, it could send the necessary prompts to the screenplay to automatically select and play the movie. It could even send the necessary prompts to launch the movie from a DVD menu. Or shut off the screenplay from a remote location.
There is a condition in which it won't run the script. This script will run each time the screenplay is powered on, but does not work if the screenplay is brought back from standby mode. If you shut off the screenplay with the remote, then any scheduled recordings you have will automatically boot up the screenplay. The screenplay is in Standby mode.
If you shut it down by holding down the power button on the front of the console, then it shuts off the power and you will miss any scheduled recordings. It is not in standby mode.
When you power up from standby mode, the "Iomega" logo does not appear during the boot process. That is one way you can identify that you are in standby mode. It also isn't going to run the rcS script, and thus won't run the startscript text file either.
Something else I discovered: If you telnet in, go into standby mode, then turn the screenplay back on, your telnet session will still be running. This is a symptom of it coming out of standby mode. All processes are still running. Thought it was interesting.
First, the RootApp. I figured out that it is required in order for the Power Off button to work. Otherwise, the unit does not shut down properly. This becomes critical with the second discovery...
In a prior post, Fun with the Player I detailed that you have telnet control over the screenplay if you launch the DvdPlayer program after executing a stopall. You can then send keypresses to remote control the screenplay. This trick was stopped in R1.8 firmware, although it still works if you kill -9 the RootApp process. The real trick is to get it to allow you to connect to some kind of key queue that you can fill up after the screenplay is booted.
For the ScreenPlay Pro, the /usr/local/etc has an rcS file that launches the DvdPlayer portion in conjunction with the RootApp. So, using a suggestion from jamoba posted to the emtec group back in february, I modified my rcS as follows:
if [ -f $DEFAULT_AP_DIR/DvdPlayer ] && [ -x $DEFAULT_AP_DIR/DvdPlayer ]; then
cd $DEFAULT_AP_DIR
if [ -f $DEFAULT_AP_DIR/RootApp ] && [ -x $DEFAULT_AP_DIR/RootApp ]; then
echo Running dvdplayer with RootApp
touch /tmp/command_sender.txt
tail -f /tmp/command_sender.txt | RootApp DvdPlayer -l on -o /var/log/dvdplayer/user_input&
else
echo Running dvdplayer
./DvdPlayer -l on -o /var/log/dvdplayer/user_input&
fi
else
/usr/local/etc/dvdplayer/script/run_tail
fi
sleep 10
cat /tmp_orig/startscript >> /tmp/command_sender.txt
So basically, I have a series of keypresses in the startscript file that it sends 10 seconds after launching the program, which is just about right. I can have the startscript read something like:
XX
(There's a single space before XX and a single space after)
To have it automatically go into the ScreenPlay drive and press down twice and select the folder or media at that location.
Now, if I wanted to send more keystrokes outside of the startscript, I can simply add to the /tmp/command_sender.txt by commands like "echo O >> command_sender.txt" to have it automatically shut down the screenplay. I can do this in a telnet prompt AFTER the screenplay has booted. Theoretically, I could write an http webpage that displays all of my movies, say in thumbnail mode, and if I select one, it could send the necessary prompts to the screenplay to automatically select and play the movie. It could even send the necessary prompts to launch the movie from a DVD menu. Or shut off the screenplay from a remote location.
There is a condition in which it won't run the script. This script will run each time the screenplay is powered on, but does not work if the screenplay is brought back from standby mode. If you shut off the screenplay with the remote, then any scheduled recordings you have will automatically boot up the screenplay. The screenplay is in Standby mode.
If you shut it down by holding down the power button on the front of the console, then it shuts off the power and you will miss any scheduled recordings. It is not in standby mode.
When you power up from standby mode, the "Iomega" logo does not appear during the boot process. That is one way you can identify that you are in standby mode. It also isn't going to run the rcS script, and thus won't run the startscript text file either.
Something else I discovered: If you telnet in, go into standby mode, then turn the screenplay back on, your telnet session will still be running. This is a symptom of it coming out of standby mode. All processes are still running. Thought it was interesting.
Thursday, September 24, 2009
Interface Update
I updated the wiki with new skins and a template for creating new skins.
http://screenplayprohd.wikia.com/wiki/Skins
The purpose of this blog is to explain how I did things, so here goes...
I created a grid.bmp file. It's actually in the template.zip if you want to see it. I used a special code to help identify the 100 / 200 / 300 / 400 / 500 / 600 point lines. The X in the grid boxes help to identify more specific points. By putting the grid into the background (giving it the name IMAGE_GUIDE_BG.bmp for instance) I was able to figure out the exact location of all of the other boxes on the screen. Then it was a matter of reconstructing that in layers through GIMP.
Playing around with the colors, I found that 0,0,0 was transparent on some of the images. I tried to take advantage of that fact, but quickly found out that most of the time you WANT the images to overwrite what was on the background before.
The Iomega Toys skin came from Superberny. It was similar to what I had been planning with a Disney theme. I decided to focus strictly on Mickey and found many resources on the web for getting Mickey pictures. I ended up having to modify most of them in one way or another. Mickey looks too fat on the TV. But I left it because, after all, TV does make you look too fat, right?
All kidding aside, I spent a lot of time trying to do the Mickey skin and toward the end got a little sloppy because I just wanted to get it done. There's a lot of graphics to replace if you want to match the whole theme.
I mentioned it many times on the interface page, but I'll say it again. You HAVE to save each and every bitmap out as R5G6B5 format or it will lock up the screenplay.
Kudos to SuperBerny for the initial work identifying the files to replace.
http://screenplayprohd.wikia.com/wiki/Skins
The purpose of this blog is to explain how I did things, so here goes...
I created a grid.bmp file. It's actually in the template.zip if you want to see it. I used a special code to help identify the 100 / 200 / 300 / 400 / 500 / 600 point lines. The X in the grid boxes help to identify more specific points. By putting the grid into the background (giving it the name IMAGE_GUIDE_BG.bmp for instance) I was able to figure out the exact location of all of the other boxes on the screen. Then it was a matter of reconstructing that in layers through GIMP.
Playing around with the colors, I found that 0,0,0 was transparent on some of the images. I tried to take advantage of that fact, but quickly found out that most of the time you WANT the images to overwrite what was on the background before.
The Iomega Toys skin came from Superberny. It was similar to what I had been planning with a Disney theme. I decided to focus strictly on Mickey and found many resources on the web for getting Mickey pictures. I ended up having to modify most of them in one way or another. Mickey looks too fat on the TV. But I left it because, after all, TV does make you look too fat, right?
All kidding aside, I spent a lot of time trying to do the Mickey skin and toward the end got a little sloppy because I just wanted to get it done. There's a lot of graphics to replace if you want to match the whole theme.
I mentioned it many times on the interface page, but I'll say it again. You HAVE to save each and every bitmap out as R5G6B5 format or it will lock up the screenplay.
Kudos to SuperBerny for the initial work identifying the files to replace.
Sunday, August 23, 2009
Changing the theme
Credit where credit is due: the rtd1261.wikidot.com site contained the information about what format the graphics had to be saved in. And Superberny put together a package for IomTools that contained most of the graphic files necessary, which made it easier to identify.
So what I did was go through all of the BMP files on the drive and identify the purpose and where they appeared on the screenplay. This is to make it easier for other people to do custom themes by changing the graphics.
I documented it on the wiki:
http://screenplayprohd.wikia.com/wiki/Modifying_the_Interface
That will make it easier for people to change what has to be changed to match whatever theme. Now I need to figure out how I'm going to identify the locations that each of the overlays appear. But it's really late at night / really early in the morning, so I'm done for today.
So what I did was go through all of the BMP files on the drive and identify the purpose and where they appeared on the screenplay. This is to make it easier for other people to do custom themes by changing the graphics.
I documented it on the wiki:
http://screenplayprohd.wikia.com/wiki/Modifying_the_Interface
That will make it easier for people to change what has to be changed to match whatever theme. Now I need to figure out how I'm going to identify the locations that each of the overlays appear. But it's really late at night / really early in the morning, so I'm done for today.
Tuesday, August 11, 2009
Other hacks
I picked up a Canon SX10 IS camera to replace my outdated Canon PowerShot S30. I had hacked the Powershot S30, so I figured there might be something for the SX10. And there was: http://chdk.wikia.com contains a wealth of information for supplementing the existing firmware. I'm already using many of the features, including taking snapshots of lightning, displaying the battery power in %, the temperature of the lens, ccd, and battery compartments, the time displayed on the OSD, and the best thing: Removal of the hot/dead pixels. I had one set near the middle and it was very obvious in all of my pictures. I didn't want to return the camera for "possibly" getting a fix, and the firmware fixed it right up. If you have a canon camera, it's definitely worth checking into that hack. I'd love to say I had something to do with it, but all I've done is applied other people's work at this point.
Today, my laundry machine had some problems. I have a GE Harmony washer. Luckily, with a lot of research and a little bit of luck, I was able to determine a "test" mode for the washer. Push power on, then hold down on help and press start/stop. Then you can test out specific things like spin, fill cold, fill hot, drain, agitate, etc, overriding what the washer would normally do. There's another one that is similar, something like back and home at the same time. But it will actually make your washer reset. I had to use it once when my washer reported a problem while I was reassembling it. Oh, and common knowledge, but if you put a magnet near the front left side of the lid, there is a reed switch that triggers so that the laundry machine thinks that the lid is down. That way you can watch what is going on inside.
Trying to catch up with everything after my vacation, so hopefully I will be able to get back to the Screenplay soon.
Today, my laundry machine had some problems. I have a GE Harmony washer. Luckily, with a lot of research and a little bit of luck, I was able to determine a "test" mode for the washer. Push power on, then hold down on help and press start/stop. Then you can test out specific things like spin, fill cold, fill hot, drain, agitate, etc, overriding what the washer would normally do. There's another one that is similar, something like back and home at the same time. But it will actually make your washer reset. I had to use it once when my washer reported a problem while I was reassembling it. Oh, and common knowledge, but if you put a magnet near the front left side of the lid, there is a reed switch that triggers so that the laundry machine thinks that the lid is down. That way you can watch what is going on inside.
Trying to catch up with everything after my vacation, so hopefully I will be able to get back to the Screenplay soon.
Friday, June 12, 2009
New Buildroot / Toolchain
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.
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, 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.
Wednesday, February 18, 2009
PROFTP
Just a quick note that I didn't mention. In that recently posted toolchain, I have the PROFTPD file compiled. It does run, and even starts up the way it is supposed to. I haven't taken the time to figure out all of the configuration requirements. But here are some:
1) addgroup nogroup
2) adduser ftp
3) move proftpd.conf file to /etc directory
4) make directory /home/ftp
5) make directory /var/ftp (this might not be right. I'm doing this from memory. And I was equipped with fuzzy memory. Oh, wait, that's fuzzy logic. Nevermind. There was some directory here that needed to be created).
6) Copy the S50proftpd file to the /etc directory, switch to the etc directory and type ./S50proftpd start to get it started, stop to stop it, restart to stop and start it again.
There's more required, but I didn't get to it. I'll probably try again another day. Just ran out of time before I got it totally working. If you run syslogd you can capture more information about the error messages it runs into.
1) addgroup nogroup
2) adduser ftp
3) move proftpd.conf file to /etc directory
4) make directory /home/ftp
5) make directory /var/ftp (this might not be right. I'm doing this from memory. And I was equipped with fuzzy memory. Oh, wait, that's fuzzy logic. Nevermind. There was some directory here that needed to be created).
6) Copy the S50proftpd file to the /etc directory, switch to the etc directory and type ./S50proftpd start to get it started, stop to stop it, restart to stop and start it again.
There's more required, but I didn't get to it. I'll probably try again another day. Just ran out of time before I got it totally working. If you run syslogd you can capture more information about the error messages it runs into.
Saturday, February 14, 2009
G++ toolchain fixed
I finally found the headers I needed for g++. They were in the buildroot, but were not being copied to the root for inclusion in the toolchain. I had tried copying them before, but I must have copied the wrong ones. Tried again and this time it worked. So here's the new uclibc 2.6.12.6 toolchain for mipsel.
http://www.box.net/shared/cmtngtrfjn
One note on the g++ -- you need to make the libraries available before you can run anything you compile. Those libraries are in the usr/lib of the ext2. Create a symbolic link of that called /usr/lib and you won't have to copy it. Of course, if you want to distribute any g++ compiled program, you'll need to include that library as well or nobody else will be able to run it. You can probably link it in to the executable somehow.
edit: To get the compiled c++ programs to work, I had to copy libgcc_s.so.1 and libstdc++.so.6.0.9 to the /usr/lib directory, and also do the symbolic links of libgcc_s.so to libgcc_s.so.1 and libstdc++.so and libstdc++.so.6 to libstdc++.so.6.0.9.
I also got a chance to try out some stuff with an ext3 formatted hddmedia partition. And it was way worth it.
I used symbolic links to hook up folders from my USB drives. As a result, all of the information available on those drives appears under my main ScreenPlay Pro drive when I'm browsing. So I don't have to exit to the menu and go to the USB directory. And its allowed me to create simple categories for finding the movies by placing those categories at the root level.
This is something that I think would work really well as a web page, so I'm going to try to create something like that to make it easy to do symbolic links. And while I'm at it, I might as well make it intelligent enough to allow downloading those files and, in the case of a VIDEO_TS directory, automatically create a tarball of the entire directory for download when you click on it.
http://www.box.net/shared/cmtngtrfjn
One note on the g++ -- you need to make the libraries available before you can run anything you compile. Those libraries are in the usr/lib of the ext2. Create a symbolic link of that called /usr/lib and you won't have to copy it. Of course, if you want to distribute any g++ compiled program, you'll need to include that library as well or nobody else will be able to run it. You can probably link it in to the executable somehow.
edit: To get the compiled c++ programs to work, I had to copy libgcc_s.so.1 and libstdc++.so.6.0.9 to the /usr/lib directory, and also do the symbolic links of libgcc_s.so to libgcc_s.so.1 and libstdc++.so and libstdc++.so.6 to libstdc++.so.6.0.9.
I also got a chance to try out some stuff with an ext3 formatted hddmedia partition. And it was way worth it.
I used symbolic links to hook up folders from my USB drives. As a result, all of the information available on those drives appears under my main ScreenPlay Pro drive when I'm browsing. So I don't have to exit to the menu and go to the USB directory. And its allowed me to create simple categories for finding the movies by placing those categories at the root level.
This is something that I think would work really well as a web page, so I'm going to try to create something like that to make it easy to do symbolic links. And while I'm at it, I might as well make it intelligent enough to allow downloading those files and, in the case of a VIDEO_TS directory, automatically create a tarball of the entire directory for download when you click on it.
Saturday, February 7, 2009
Fixing the Norton Internet Security problem, and an improved toolchain
At the request of cybermomo, I rebuilt the toolchain with g++ support. All non-windows binutils were already included. So I threw in a bunch of other utilities while I was at it. I haven't yet made this available.
I decided to tackle the issue of the Norton Internet Security problem. For those not familiar with the problems it has with the screenplay (of which neither side wants to fix): The ScreenPlay uses an older kernel driver. The NIS 2009 version of the program makes some change to the NTFS partition on the screenplay EVEN IF YOU EXCLUDE THE DRIVE and makes it so that the kernel driver can't read it anymore. So then when you boot the screenplay pro hd, it just sits there flashing at you.
The easiest way to solve this is to move over to the newer NTFS-3G driver, which will solve a bunch of other problems with the NTFS driver too. So I included that as well. Unfortunately, the buildroot needed several adjustments before I could finally include the driver. It required wchar support, so I had to rebuild the uClibc libraries with that. I had to adjust it to use the latest stable version of NTFS-3G. Then it was just a matter of figuring out how to install it into the existing screenplay. That's where I ran into trouble.
Apparently the NTFS-3G is requiring a fuse.ko module. I believe that's only going to be possible if I rebuild the kernel. I'm not sure if there's any other way around it. However, I'm just not familiar with the kernel modules and how to create them. So I'm somewhat stuck there.
I also tried reformatting the drive with the 8 partitions to see if it would mount the 6th partition under the livepause as it tries to do when you start dvdplayer. Unfortunately, it did not. I would format the partition as ext3, and it would turn around and do a mkudffs on it, and then try to mount it and fail. At least, the output appearing was similar to when you run a mkudffs.
So not very much success this time. I'm in process of reformatting my NTFS partition as EXT3 to do some other experiments.
I decided to tackle the issue of the Norton Internet Security problem. For those not familiar with the problems it has with the screenplay (of which neither side wants to fix): The ScreenPlay uses an older kernel driver. The NIS 2009 version of the program makes some change to the NTFS partition on the screenplay EVEN IF YOU EXCLUDE THE DRIVE and makes it so that the kernel driver can't read it anymore. So then when you boot the screenplay pro hd, it just sits there flashing at you.
The easiest way to solve this is to move over to the newer NTFS-3G driver, which will solve a bunch of other problems with the NTFS driver too. So I included that as well. Unfortunately, the buildroot needed several adjustments before I could finally include the driver. It required wchar support, so I had to rebuild the uClibc libraries with that. I had to adjust it to use the latest stable version of NTFS-3G. Then it was just a matter of figuring out how to install it into the existing screenplay. That's where I ran into trouble.
Apparently the NTFS-3G is requiring a fuse.ko module. I believe that's only going to be possible if I rebuild the kernel. I'm not sure if there's any other way around it. However, I'm just not familiar with the kernel modules and how to create them. So I'm somewhat stuck there.
I also tried reformatting the drive with the 8 partitions to see if it would mount the 6th partition under the livepause as it tries to do when you start dvdplayer. Unfortunately, it did not. I would format the partition as ext3, and it would turn around and do a mkudffs on it, and then try to mount it and fail. At least, the output appearing was similar to when you run a mkudffs.
So not very much success this time. I'm in process of reformatting my NTFS partition as EXT3 to do some other experiments.
Wednesday, January 28, 2009
The seagate problem
I've posted about it in the wiki already, so if you want to see that information, it's at http://screenplayprohd.wikia.com/wiki/Detecting_drive_identity
But my blog is for documenting how I did it.
I started out as I do with many of my ventures by going to google. In looking up how to read the disk drive serial number, I came across the linux IOCTL command, which is for direct device communication. May come in handy in the future. In trying to find a working example of how to use it, I found somebody opening the /proc/something else (I don't recall what it was) and I started thinking that maybe there was something for the drive.
So I looked in proc and found ide, found ide0 inside of it, and several files inside of that.
cat them all out and I could see tons of hexadecimal. So my first thought was to convert the hexadecimal to character format. I went to my favorite hex editor "HxD" (freeware, works really nice) and manually entered the codes. Sure enough, I saw the "SD15" code appear and then the drive model number.
Great, but I can't explain that process to non-programmers very easily. So I figured I'd see if there was some way to do it on the command line. Got as far as awk and decided it would be easier to do this in a simple C program. That would enable me to use my toolchain that I spent so long trying to build.
So the program is simple enough. It uses the built in ability of C to convert a hex string to decimal using strtol command, which is then echoed out as a character.
In other news...I think I've made some progress deciphering the memory dump I took of the machine. I was able to reconstruct a view of the screen that was on the TV at the time I took the screenshot. Don't have time to tell about it now, but details will come.
But my blog is for documenting how I did it.
I started out as I do with many of my ventures by going to google. In looking up how to read the disk drive serial number, I came across the linux IOCTL command, which is for direct device communication. May come in handy in the future. In trying to find a working example of how to use it, I found somebody opening the /proc/something else (I don't recall what it was) and I started thinking that maybe there was something for the drive.
So I looked in proc and found ide, found ide0 inside of it, and several files inside of that.
cat them all out and I could see tons of hexadecimal. So my first thought was to convert the hexadecimal to character format. I went to my favorite hex editor "HxD" (freeware, works really nice) and manually entered the codes. Sure enough, I saw the "SD15" code appear and then the drive model number.
Great, but I can't explain that process to non-programmers very easily. So I figured I'd see if there was some way to do it on the command line. Got as far as awk and decided it would be easier to do this in a simple C program. That would enable me to use my toolchain that I spent so long trying to build.
So the program is simple enough. It uses the built in ability of C to convert a hex string to decimal using strtol command, which is then echoed out as a character.
In other news...I think I've made some progress deciphering the memory dump I took of the machine. I was able to reconstruct a view of the screen that was on the TV at the time I took the screenshot. Don't have time to tell about it now, but details will come.
Monday, January 19, 2009
ScreenPlay Pro HD and "Yet anOther Dummy CTCS"
The instructions are on the Wikidot site: http://rtd1261.wikidot.com/tweaking-the-official-firmware
The only change I needed to make was that after extracting and copying the files, the /usr/local/bin/ctorrent and /usr/local/bin/dctcs files needed to be chmod to become executable. And to make sure that I created the TORRENT and DOWNLOAD directories in the right place /usr/local/etc/hdd/volumes/HDD1/TORRENT and /usr/local/etc/hdd/volumes/HDD1/DOWNLOAD. After that, the torrent web page worked just fine. Sure, it would be nice to be able to enter those from the screenplay, but even to be able to tell the screenplay which torrents to download via a web browser and then come back later to find them already present on the screenplay...well, it's convenient. I'm not a big fan of torrents, but I think if you do like them, it is a worthwhile thing to setup.
The only change I needed to make was that after extracting and copying the files, the /usr/local/bin/ctorrent and /usr/local/bin/dctcs files needed to be chmod to become executable. And to make sure that I created the TORRENT and DOWNLOAD directories in the right place /usr/local/etc/hdd/volumes/HDD1/TORRENT and /usr/local/etc/hdd/volumes/HDD1/DOWNLOAD. After that, the torrent web page worked just fine. Sure, it would be nice to be able to enter those from the screenplay, but even to be able to tell the screenplay which torrents to download via a web browser and then come back later to find them already present on the screenplay...well, it's convenient. I'm not a big fan of torrents, but I think if you do like them, it is a worthwhile thing to setup.
Tuesday, January 13, 2009
Fun with the player
Tried a few things tonight. I plugged in a keyboard into the player to see if it supported one right out of the box. Unfortunately, it does not. So I'd have to get a keyboard driver loaded on it.
I also played around with the DvdPlayer part of the OS.
it is located in /usr/local/bin. I believe it automatically starts from the rcS located in the /usr/local directory, although I haven't experimented with that to see if it was the case.
You can stop the current one by typing stopall. It will terminate the RootApp and the DvdPlayer.
So I tried putting in a DvdPlayer from an Emtec player. Copied both the DvdPlayer and the Resource directory. Unfortunately, it wasn't able to boot it. In fact, it even stopped responding to telnet, so I had to use my System Recovery CD to mount the directory and put things back. Oh well.
Now, something really fun to do is to do the stopall, and then start up the DvdPlayer again. You do it by typing, from the /usr/local/bin directory:
./DvdPlayer -l on -o /var/log/dvdplayer/user_input
Now it will launch the Dvdplayer and dump the stdout and stderr to your telnet session. And the information it reports back is very useful...
for instance, it starts off:
Livepause not stop correctly last time
"umount /usr/local/etc/hdd/livepause" failed. The partition "may" not be mounted.
-->There is further mention of the livepause later on. it is possible that with 6 partitions, this drive might support livepause. Continuing with the log:
trying to change type of multiple extents
info, udhcpc (v0.9.9-pre) started
CMD: mkdir -p /tmp/netb/smb
In my system...
CMD: mkdir -p /tmp/smb
In my system...
CMD: ifconfig > /tmp/netb/samba_my_ip
In my system...
GrandMa Revision: 131384
(User Input)Pipe Created.
(Internal Event)Pipe Created.
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: AbstractAP::Init, startMode=0
command: rm /tmp/hddmedia
In my system...
command: ln -s /usr/local/etc/hdd/volumes/HDD1 /tmp/hddmedia
In my system...
pli initialization...
free [0] address 0x42000000, size = -16777216 to Cache
free [1] address 0x43800000, size = -2097152 to Cache
free [2] address 0x43a00000, size = -1638400 to Cache
In my system...
In my system...
[udf check done]
In my system...
Video DebugMem Physical Address = 0xa9ea00
MEMCache Hit [0]! size = 16777216, address = 0x42000000
tandy: lba 14,ariid=
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: ARI_EE_VIDEO_ASPECTRATIO=2
tandy: ARI_EE_VIDEO_BRIGHT=25
tandy: ARI_EE_VIDEO_CONTRAST=35
tandy: ARI_EE_VIDEO_TVSYSTEM=5
tandy: ARI_EE_VIDEO_TVSTANDARD=0
tandy: etho enable, static=0
[HDMI]: Set AVMute
[HDMI] setHDMIPscan(456) HDMIPscan = 1
tandy bright=32
tandy contrast=32
MIN_TILE_HEIGHT 32
pli_allocGraphic 2097152 bytes, Old priority = 0
pli 1st allocated virt addr = 47000000, phy addr = 3000000 , end addr = 47120000
MIN_TILE_HEIGHT 32
pli 1st allocated virt addr = 470d8000, phy addr = 30d8000 , end addr = 471f8000
MIN_TILE_HEIGHT 32
pli_allocGraphic 884736 bytes, Old priority = 0
pli 1st allocated virt addr = 47200000, phy addr = 3200000 , end addr = 47320000
MIN_TILE_HEIGHT 32
pli_allocGraphic 442368 bytes, Old priority = 0
pli 1st allocated virt addr = 47300000, phy addr = 3300000 , end addr = 47390000
MIN_TILE_HEIGHT 32
pli 1st allocated virt addr = 471b0000, phy addr = 31b0000 , end addr = 47210000
MIN_TILE_HEIGHT 32
pli_allocGraphic 196608 bytes, Old priority = 0
pli 1st allocated virt addr = 47380000, phy addr = 3380000 , end addr = 473c0000
MIN_TILE_HEIGHT 32
pli_allocGraphic 147456 bytes, Old priority = 0
pli 1st allocated virt addr = 473c0000, phy addr = 33c0000 , end addr = 473f0000
[HDMI] setHDMIAudioVideoFormat(230) HDMI EDID table isn't ready !!!
MIN_TILE_HEIGHT 32
pli_allocGraphic 262144 bytes, Old priority = 0
pli 1st allocated virt addr = 47400000, phy addr = 3400000 , end addr = 47440000
-->I think this might be telling me the address of the graphic buffers. The EDID is a documented structure that the HDMI TV reports.
IN : /tmp/ramfs/usb/livepause
IN : /tmp/ramfs/usb/rec
tandy: abstractap: start to activate the gudie ap
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: AbstractAp, GetInitialFlag 1
IN : /tmp/net
Create /tmp/net Ok!!!
In my system...
In my system...
In my system...
wait wlan0!!0
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
GetDeviceUp 0 flag : 0x1043
SetupClass::GetInstance()->GetNetEth0DHCPEnable() = 1
In my system...
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
In my system...
0 usb block device found
No Recording Partition Available !!!!!!
No Timeshift Partition Available !!!!!!
-->More mention of the livepause (timeshift) system... very intriguing. Would it do livepause if it had the partition available? I wonder...
DNS IP : 127. 0. 0. 1
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
In my system...
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
Click eth0 DHCP IP and DNS
In my system...
In my system...
DNS IP : 127. 0. 0. 1
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
[HDMI] HDMI_thread(40) start !!!!0529 PVR
[HDMI]: Disable HDCP
[HDMI] setHDCPEnabled(1854) HDCPEnabled = 0
[HDMI]: Set AVMute
[HDMI] Hotplug Change !!! -1 -> 1
[HDMI] init_HDMI_EDID_data !!!
[HDMI] setHDMIPscan(456) HDMIPscan = 100
[HDMI] setHDMIPscan(456) HDMIPscan = 1
[HDMI]: HDCP_Authenticate HDCPOper_state=0xtandy: discovery: bind fail
Running non-bridged mode...
debug, Sending discover...
debug, Sending select for 192.168.42.5...
info, Lease of 192.168.42.5 obtained, lease time -1
1
[HDMI]: HDCP_Authenticate HDCPOper_state=0x2
[HDMI]: Start HDCP Authentication. t=1231876062593
tandy: AbstractAP::Init 1
IP : 192. 168. 42. 5
ioctl error: No such device
In my system...
wait wlan0!!1
tandy: eth0 alive, start eth0 discovery daemon
lock success
I locked the file
I locked the file
release success
tandy: guideap,CMD_USB_UPDATED, don't care
Key processed.
[HDMI]: Tx Reads EDID from Rx.
[HDMI] setDVIMonitor(1865) DVIMonitor = 0
0x00 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0x6a 0x4e 0x94 0x02 0x01 0x00 0x00 0x00
0x00 0x0f 0x01 0x03 0x80 0x40 0x24 0x00 0x0a 0x92 0x03 0xa2 0x56 0x48 0x99 0x25
0x14 0x4a 0x4d 0x21 0x08 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x1d 0x80 0x18 0x71 0x1c 0x16 0x20 0x58 0x2c
0x25 0x00 0xf4 0x19 0x11 0x00 0x00 0x9e 0x01 0x1d 0x00 0x72 0x51 0xd0 0x1e 0x20
0x6e 0x28 0x55 0x00 0xf4 0x19 0x11 0x00 0x00 0x1e 0x00 0x00 0x00 0xfc 0x00 0x5a
0x4f 0x52 0x41 0x4e 0x20 0x48 0x44 0x4d 0x49 0x20 0x54 0x56 0x00 0x00 0x00 0xfd
0x00 0x3b 0x3d 0x0f 0x3c 0x0c 0x00 0x0a 0x20 0x20 0x20 0x20 0x20 0x20 0x01 0x22
0x02 0x03 0x18 0x71 0x45 0x07 0x02 0x03 0x04 0x05 0x26 0x09 0x07 0x07 0x15 0x07
0x50 0x66 0x03 0x0c 0x00 0x10 0x00 0x80 0x8c 0x0a 0xa0 0x14 0x51 0xf0 0x16 0x00
0x26 0x7c 0x43 0x00 0xf4 0x19 0x11 0x00 0x00 0x98 0x8c 0x0a 0xd0 0x8a 0x20 0xe0
0x2d 0x10 0x10 0x3e 0x96 0x00 0x90 0x2d 0x11 0x00 0x00 0x18 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x37
HDMI_EDID.tag = 2
HDMI_EDID.revision = 3
HDMI_EDID.offset = 24
HDMI_EDID.bUnderScan = 0
HDMI_EDID.bBasicAudio = 1
HDMI_EDID.YCBCR444 = 1
HDMI_EDID.YCBCR422 = 1
HDMI_EDID.native_format_number = 1
data_block_collection_length = 0x14, VideoTagCode(ptr) = 0x01
HDMI_EDID.VDB_length = 0x05
HDMI_EDID.VDB[0] = 0x07
HDMI_EDID.VDB[1] = 0x02
HDMI_EDID.VDB[2] = 0x03
HDMI_EDID.VDB[3] = 0x04
HDMI_EDID.VDB[4] = 0x05
data_block_collection_length = 0xe, AudioTagCode(ptr) = 0x01
HDMI_EDID.ADB_length = 0x02
(HDMI_EDID.ADB + 0)->coding_type = 0x01
(HDMI_EDID.ADB + 0)->channel_count = 0x01
(HDMI_EDID.ADB + 0)->sample_freq_all = 0x07
(HDMI_EDID.ADB + 0)->sample_size_all = 0x07
(HDMI_EDID.ADB + 0)->max_bit_rate_divided_by_8KHz = 0x00
(HDMI_EDID.ADB + 1)->coding_type = 0x02
(HDMI_EDID.ADB + 1)->channel_count = 0x05
(HDMI_EDID.ADB + 1)->sample_freq_all = 0x07
(HDMI_EDID.ADB + 1)->sample_size_all = 0x00
(HDMI_EDID.ADB + 1)->max_bit_rate_divided_by_8KHz = 0x50
[HDMI]: Pass ADB data to audio firmware.................
[HDMI]: Copy HDMI AUDIO data to physical addr(uncacheable addr)
[HDMI]: ADB[0] = 0x26
[HDMI]: ADB[1] = 0x9
[HDMI]: ADB[2] = 0x7
[HDMI]: ADB[3] = 0x7
data_block_collection_length = 0x7, SpeakerAllocationTagCode(ptr) = 0x00
data_block_collection_length = 0x7, VendorSpecificTagCode(ptr) = 0x01
HDMI_EDID.VSDB_length = 0x06
HDMI_EDID.VSDB[0] = 0x03
HDMI_EDID.VSDB[1] = 0x0c
HDMI_EDID.VSDB[2] = 0x00
HDMI_EDID.VSDB[3] = 0x10
HDMI_EDID.VSDB[4] = 0x00
HDMI_EDID.VSDB[5] = 0x80
data_block_collection_length = 0x0, ReservedTagCode(ptr) = 0x00
data_block_collection_length = 0x0, Reserved_6TagCode(ptr) = 0x00
data_block_collection_length = 0x0, VESA_DTC_DataTagCode(ptr) = 0x00
data_block_collection_length = 0x0, UseExtendedTagCode(ptr) = 0x00
HDMI_EDID.native_format_number = 0x01
HDMI_EDID.native_format[0] = 0x8c
HDMI_EDID.native_format[1] = 0x0a
HDMI_EDID.native_format[2] = 0xa0
HDMI_EDID.native_format[3] = 0x14
HDMI_EDID.native_format[4] = 0x51
HDMI_EDID.native_format[5] = 0xf0
HDMI_EDID.native_format[6] = 0x16
HDMI_EDID.native_format[7] = 0x00
HDMI_EDID.native_format[8] = 0x26
HDMI_EDID.native_format[9] = 0x7c
HDMI_EDID.native_format[10] = 0x43
HDMI_EDID.native_format[11] = 0x00
HDMI_EDID.native_format[12] = 0xf4
HDMI_EDID.native_format[13] = 0x19
HDMI_EDID.native_format[14] = 0x11
HDMI_EDID.native_format[15] = 0x00
HDMI_EDID.native_format[deleting routers
adding dns 192.168.42.127
16] = 0x00
HDMI_EDID.native_format[17] = 0x98
[HDMI] HDMI_GetCurrentVid(1037) HDMI_Video_List_Index 19
[HDMI] HDMI_GetCurrentVid(1038) HDMI_Video_Info_Index 11
[HDMI] HDMI_GetCurrentVid(1039) HDMI_EDID_VDB_Index 4
[HDMI] i 19 - HDMI_Video_List[i] 5
[HDMI] HDMI_GetNextVideoListIndex 20
[HDMI] HDMI_thread(135) call setHDMIAudioVideoFormat()
[HDMI] HDMI_GetCurrentVid(1037) HDMI_Video_List_Index 19
[HDMI] HDMI_GetCurrentVid(1038) HDMI_Video_Info_Index 11
[HDMI] HDMI_GetCurrentVid(1039) HDMI_EDID_VDB_Index 4
[HDMI] setHDMIPscan(456) HDMIPscan = 2
[HDMI] set setHDMIPSCANFlag = 1
[HDMI] VID = 0x5 1080i 60Hz
[HDMI] VIDEO type = 0x08
[HDMI] VIDEO HDMI_Sd_Hd = 0xa8
[HDMI] VIDEO Vid = 0x05
[HDMI] VIDEO RGB_or_YCbCr = 0x00
[HDMI] VIDEO PixelRepeat = 0x00
[HDMI] check EDID structure !!!!
[HDMI] HDMI_AudioCurrentIndex = 0
[HDMI] AUDIO use Input_I2S !!!!
[HDMI]: Turn on HDMI................... 1 s_freq=3 c_cnt=2 t=1231876063066
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
[HDMI]: Clear AVMute
[HDMI]: Turn on HDMI AUDIO
[HDMI]: Clear HDMI Audio Mute(Turn on AUDIO)
[HDMI]: Send_AudioMute() Ok, argp.hdmi_mute=0
[HDMI]: HDMISwitchTVSystem SP t=1231876063377
[HDMI] AUDIO HDMI_AudioInMode = 0x01
[HDMI] AUDIO HDMI_LocalInfo.coding_type = 0x01
[HDMI] AUDIO HDMI_LocalInfo.channel_count = 0x01
[HDMI] AUDIO HDMI_LocalInfo.sample_freq = 0x03
[HDMI] AUDIO HDMI_LocalInfo.sample_size = 0x03
[HDMI] AUDIO HDMI_LocalInfo.max_bit_rate_divided_by_8KHz = 0x00
[HDMI]: HDCP_Authenticate HDCPOper_state=0x3
[HDMI]: HDCP_Authenticate HDCPOper_state=0x4
[HDMI]: HDCP_Authenticate HDCPOper_state=0x5
[HDMI]: HDCP_Authenticate HDCPOper_state=0x6
[HDMI]: HDCP_Authenticate HDCPOper_state=0x9
[HDMI]: HDCP_Authenticate HDCPOper_state=0x7
[HDMI]: HDMI HDCP Authenticated t=1231876063378
wait wlan0!!2
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!3
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!4
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!5
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!6
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
lock success
I locked the file
I locked the file
release success
wait wlan0!!7
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!8
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!9
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!10
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!11
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
lock success
I locked the file
I locked the file
release success
wait wlan0!!12
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
o
tandy: GuideAP: CMD_POWER
[VIN] VIN_RPC_TVD_TOAGENT_VBI_CTRL, hr != S_OK !!!!!!!!!!!!
[AIN] AIN_RPC_TOAGENT_CREATE_0 send successful
wait wlan0!!13
start ao rpc config
start ao rpc config spdif
[AIN] InitializeInputStatus 1 1 0
[VE] RPC_EN_TOAGENT_ENC_INIT, format: 1, source: 0, hr = S_OK
Input Pin not connected while pause
[AE] RPC_TOAGENT_CREATE, hr = S_OK, agentID: 48
************** connect
[AIN] RPC_CONNECT to AO, 32 0 5 0
[AIN] RPC_CONNECT, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, numOfReadPtr: 1, listSize: 4
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, input pin, listSize: 4, header: 7ff9c618
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AIN] RPC_CONNECT to AE, 48 0 5 2
[AIN] RPC_CONNECT, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, numOfReadPtr: 2, listSize: 4
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc460, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc4e0, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, out pin, listSize: 1
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AE] msg ring buf m_pMsgRingLower: 4bd40000, m_pMsgRingUpper: 4bd48000
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc560, hr = S_OK
[VE] RPC_EN_TOAGENT_SETTF, 1 1, hr = S_OK
[VE] RPC_EN_TOAGENT_SETNR, 3 3, hr = S_OK
[VE] RPC_EN_TOAGENT_SETENCODEFORMAT, 1, hr = S_OK
[VE] RPC_EN_TOAGENT_SETRESOLUTION, hres: 720, SIF: 0, hr = S_OK
[VE] RPC_EN_TOAGENT_SETBITRATE, hr = S_OK
[VE] RPC_EN_TOAGENT_SETGOPSTRUCTURE, M: 3, N: 12, hr = S_OK
[VE] RPC_EN_TOAGENT_CONFIGVOBU, 1, hr = S_OK
[VIN] VIN_RPC_TVD_TOAGENT_TVD_CONFIGURE, hr = S_OK
[VE] RPC_EN_TOAGENT_SETTF, 0 0, hr = S_OK
[VE] RPC_EN_TOAGENT_SETNR, 0 0, hr = S_OK
[AIN] AIN_RPC_TOAGENT_TSD_CONFIG: 0......
[AIN] AIN_RPC_TOAGENT_TSD_CONFIG, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_PAUSE
[AE] AUDIO_RPC_TOAGENT_PAUSE, hr = S_OK
[VE] RPC_TOAGENT_PAUSE....
[VE] RPC_TOAGENT_PAUSE, hr = S_OK
*** aout pause
[AIN] ADC0_Config: 1 15 0 0, 48000 16
[AIN] ADC0_Config, hr = S_OK
[AIN] ADC1_Config: 1 15 0 0, 48000 16
[AIN] ADC1_Config, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_RUN...
[AE] AUDIO_RPC_TOAGENT_RUN, hr = S_OK
[VE] RPC_TOAGENT_RUN....
MEMCache Hit [2]! size = 1638400, address = 0x43a00000
[VE] RPC_TOAGENT_RUN, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_RUN
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
[AIN] AUDIO_RPC_TOAGENT_RUN, hr = S_OK
[AIN] AIN_RPC_TOAGENT_MUTE: 1......
[AIN] AIN_RPC_TOAGENT_MUTE, hr = S_OK
[VIN] VIN_RPC_TVD_TOAGENT_TVD_CONFIGURE, hr = S_OK
[AIN] AIN_RPC_TOAGENT_SWITCH_FOCUS: 0......
[AIN] AIN_RPC_TOAGENT_SWITCH_FOCUS, hr = S_OK
Key processed.
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
-->Somewhere around here, I told it to shut down (not using standby or the power button...read on to see how)
[VE] status: (3, 1, 0, 0, 3)
[VE] notify FE_RECORD_NOSIGNAL
[AE] AUDIO_RPC_TOAGENT_PAUSE
[AE] AUDIO_RPC_TOAGENT_PAUSE, hr = S_OK
[VE] RPC_TOAGENT_PAUSE....
[VE] RPC_TOAGENT_PAUSE, hr = S_OK
state force paused
[AE] AUDIO_RPC_TOAGENT_STOP
[AE] AUDIO_RPC_TOAGENT_STOP, hr = S_OK
AUDIO_RPC_ToSystem_HDMI_Setting_0_svc(546) prio_process = 0
[HDMI]: AUDIO parameters are the same, no need to setup again.
wait wlan0!!14
free [2] address 0x43a00000, size = -1638400 to Cache
[VE] RPC_TOAGENT_STOP, hr = S_OK
state force stoped
[AIN] AUDIO_RPC_TOAGENT_STOP
[AIN] AUDIO_RPC_TOAGENT_STOP, hr = S_OK
MediaLoaderThread stopped
!!!!!!!!!!!!!!!!!!! CMD_TERMINATE received
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
Free Graphic 0x47000000
Free Graphic 0x473c0000
Free Graphic 0x47300000
Free Graphic 0x47380000
error in pli_freeContinuousMemory()...
error in pli_freeContinuousMemory()...
In my system...
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
free [0] address 0x42000000, size = -16777216 to Cache
wait wlan0!!15
Entering Suspend Mode ..
SYSTEM STANDBY MODElock success
I locked the file
I locked the file
release success
Schedule is off.
Delete Network
In my system...
Something else I found was that I could control the DvdPlayer from my keyboard in this mode. These are the keys that did something that I could determine. I know there are some missing because the DVD Player wouldn't allow certain operations at that time. For instance, I can't seem to find a video with multiple angles, but I'm sure one of these keystrokes is the angle button. Update: Post on emtec reveals that e is the angle button.
a - audio button
b - takes you into the recording setup screen
c - delete schedule when in recording, otherwise doesn't appear to do anything
e - angle (reported by other users, not verified)
f - reverse play <<
j - reverse zoom (starts at max zoom and goes back to 1)
l - slow play reverse
m - mute on/off
n - skip to next title (not chapter)
o - Shut down quickly
p - skip to prior title (not chapter)
q - go back 10 SECONDS
r - start recording / switch to av
s - subtitle toggle
v - volume -
z - normal zoom
A - left
B - 30 Second Skip
C - Command Line interpreter, engineering mode, see below
D - right
E - Delete
F - Fast forward >>
G - Asks for GCode. Not sure what the GCode is. Tried a VCR+ code given the context, but the code I tried only crashed the player.
H - report some kind of status
L - slow play forward
M - Menu
N - Next chapter
O - shut down normally
P - Prior chapter
Q - Stop
S - Play
T- AV input screen
V - volume +
W - up
X - down
Z - Step / pause
- - goto
= - repeat a/b
+ - repeat button
# - go to USB screen
$ - go to SPP directory when on another source
& - graphical file copy, looks nice. Much better than the cut/copy/paste concept you can do from the remote.
( - start performance logging
) - stop performance logging
~ - memory allocation status
0-9 - same as entering 0-9. Jumps to title. I did not know you could jump to a specific title that way on this player, so something new.
[ - source button
] - In the menu, will go to the last source accessed.
{ - home button
, - return button
/ - go to setup menu
\ - switch tv system
: - switch tv system (not sure how it is different from \)
ESC - Go to setup menu
Spacebar - Select (this is what the play button on the remote maps to)
In engineering mode, you can type HELP and get this:
Engineering Mode Command List:
port: read or write value to specified address
setdebug: set audio/video debug flag
setbri : set Video In Brightness value (00~ff)
setcont : set Video In Contrast value (00~ff)
setsatu : set Video In Saturation value (00~ff)
sethue : set Video In Hue value (00~ff)
setscal : set the coefficients of VIN Scaling (0x10
00~0xFFFF)
setcolorm
: set VO hardware's Color Adjustment transformation matrix
copyfree: enable copy-free
netperf : Enable network performance meter. Use on or o
ff to tern on/off this feature
netperf nodecode, means streaming only withou
t decode.
setyc: set YC separation parameters [6 parameters]
| save: save setting
| load: load setting
| default: use factory default setting
| show: show current setting
shell: Unix Shell to execute unix command
kill: kill the program immediately (to generate coredump)
quit: quit from command line interpreter
So I'm thinking if I can grab the stdin of the DvdPlayer process, I could have another program control it. It could start the recording, for instance. Or it could automatically navigate, play certain files. In fact, some of the information coming back during DvdPlayer execution relates to the video/music/picture it is currently working on. And I would love to be able to map the 30 second skip command to a remote button...
I also played around with the DvdPlayer part of the OS.
it is located in /usr/local/bin. I believe it automatically starts from the rcS located in the /usr/local directory, although I haven't experimented with that to see if it was the case.
You can stop the current one by typing stopall. It will terminate the RootApp and the DvdPlayer.
So I tried putting in a DvdPlayer from an Emtec player. Copied both the DvdPlayer and the Resource directory. Unfortunately, it wasn't able to boot it. In fact, it even stopped responding to telnet, so I had to use my System Recovery CD to mount the directory and put things back. Oh well.
Now, something really fun to do is to do the stopall, and then start up the DvdPlayer again. You do it by typing, from the /usr/local/bin directory:
./DvdPlayer -l on -o /var/log/dvdplayer/user_input
Now it will launch the Dvdplayer and dump the stdout and stderr to your telnet session. And the information it reports back is very useful...
for instance, it starts off:
Livepause not stop correctly last time
"umount /usr/local/etc/hdd/livepause" failed. The partition "may" not be mounted.
-->There is further mention of the livepause later on. it is possible that with 6 partitions, this drive might support livepause. Continuing with the log:
trying to change type of multiple extents
info, udhcpc (v0.9.9-pre) started
CMD: mkdir -p /tmp/netb/smb
In my system...
CMD: mkdir -p /tmp/smb
In my system...
CMD: ifconfig > /tmp/netb/samba_my_ip
In my system...
GrandMa Revision: 131384
(User Input)Pipe Created.
(Internal Event)Pipe Created.
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: AbstractAP::Init, startMode=0
command: rm /tmp/hddmedia
In my system...
command: ln -s /usr/local/etc/hdd/volumes/HDD1 /tmp/hddmedia
In my system...
pli initialization...
free [0] address 0x42000000, size = -16777216 to Cache
free [1] address 0x43800000, size = -2097152 to Cache
free [2] address 0x43a00000, size = -1638400 to Cache
In my system...
In my system...
[udf check done]
In my system...
Video DebugMem Physical Address = 0xa9ea00
MEMCache Hit [0]! size = 16777216, address = 0x42000000
tandy: lba 14,ariid=
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: ARI_EE_VIDEO_ASPECTRATIO=2
tandy: ARI_EE_VIDEO_BRIGHT=25
tandy: ARI_EE_VIDEO_CONTRAST=35
tandy: ARI_EE_VIDEO_TVSYSTEM=5
tandy: ARI_EE_VIDEO_TVSTANDARD=0
tandy: etho enable, static=0
[HDMI]: Set AVMute
[HDMI] setHDMIPscan(456) HDMIPscan = 1
tandy bright=32
tandy contrast=32
MIN_TILE_HEIGHT 32
pli_allocGraphic 2097152 bytes, Old priority = 0
pli 1st allocated virt addr = 47000000, phy addr = 3000000 , end addr = 47120000
MIN_TILE_HEIGHT 32
pli 1st allocated virt addr = 470d8000, phy addr = 30d8000 , end addr = 471f8000
MIN_TILE_HEIGHT 32
pli_allocGraphic 884736 bytes, Old priority = 0
pli 1st allocated virt addr = 47200000, phy addr = 3200000 , end addr = 47320000
MIN_TILE_HEIGHT 32
pli_allocGraphic 442368 bytes, Old priority = 0
pli 1st allocated virt addr = 47300000, phy addr = 3300000 , end addr = 47390000
MIN_TILE_HEIGHT 32
pli 1st allocated virt addr = 471b0000, phy addr = 31b0000 , end addr = 47210000
MIN_TILE_HEIGHT 32
pli_allocGraphic 196608 bytes, Old priority = 0
pli 1st allocated virt addr = 47380000, phy addr = 3380000 , end addr = 473c0000
MIN_TILE_HEIGHT 32
pli_allocGraphic 147456 bytes, Old priority = 0
pli 1st allocated virt addr = 473c0000, phy addr = 33c0000 , end addr = 473f0000
[HDMI] setHDMIAudioVideoFormat(230) HDMI EDID table isn't ready !!!
MIN_TILE_HEIGHT 32
pli_allocGraphic 262144 bytes, Old priority = 0
pli 1st allocated virt addr = 47400000, phy addr = 3400000 , end addr = 47440000
-->I think this might be telling me the address of the graphic buffers. The EDID is a documented structure that the HDMI TV reports.
IN : /tmp/ramfs/usb/livepause
IN : /tmp/ramfs/usb/rec
tandy: abstractap: start to activate the gudie ap
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
tandy: AbstractAp, GetInitialFlag 1
IN : /tmp/net
Create /tmp/net Ok!!!
In my system...
In my system...
In my system...
wait wlan0!!0
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
GetDeviceUp 0 flag : 0x1043
SetupClass::GetInstance()->GetNetEth0DHCPEnable() = 1
In my system...
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
In my system...
0 usb block device found
No Recording Partition Available !!!!!!
No Timeshift Partition Available !!!!!!
-->More mention of the livepause (timeshift) system... very intriguing. Would it do livepause if it had the partition available? I wonder...
DNS IP : 127. 0. 0. 1
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
In my system...
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
Click eth0 DHCP IP and DNS
In my system...
In my system...
DNS IP : 127. 0. 0. 1
/bin/echo nameserver 127.0.0.1 >> /etc/resolv.conf
[HDMI] HDMI_thread(40) start !!!!0529 PVR
[HDMI]: Disable HDCP
[HDMI] setHDCPEnabled(1854) HDCPEnabled = 0
[HDMI]: Set AVMute
[HDMI] Hotplug Change !!! -1 -> 1
[HDMI] init_HDMI_EDID_data !!!
[HDMI] setHDMIPscan(456) HDMIPscan = 100
[HDMI] setHDMIPscan(456) HDMIPscan = 1
[HDMI]: HDCP_Authenticate HDCPOper_state=0xtandy: discovery: bind fail
Running non-bridged mode...
debug, Sending discover...
debug, Sending select for 192.168.42.5...
info, Lease of 192.168.42.5 obtained, lease time -1
1
[HDMI]: HDCP_Authenticate HDCPOper_state=0x2
[HDMI]: Start HDCP Authentication. t=1231876062593
tandy: AbstractAP::Init 1
IP : 192. 168. 42. 5
ioctl error: No such device
In my system...
wait wlan0!!1
tandy: eth0 alive, start eth0 discovery daemon
lock success
I locked the file
I locked the file
release success
tandy: guideap,CMD_USB_UPDATED, don't care
Key processed.
[HDMI]: Tx Reads EDID from Rx.
[HDMI] setDVIMonitor(1865) DVIMonitor = 0
0x00 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0x6a 0x4e 0x94 0x02 0x01 0x00 0x00 0x00
0x00 0x0f 0x01 0x03 0x80 0x40 0x24 0x00 0x0a 0x92 0x03 0xa2 0x56 0x48 0x99 0x25
0x14 0x4a 0x4d 0x21 0x08 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x1d 0x80 0x18 0x71 0x1c 0x16 0x20 0x58 0x2c
0x25 0x00 0xf4 0x19 0x11 0x00 0x00 0x9e 0x01 0x1d 0x00 0x72 0x51 0xd0 0x1e 0x20
0x6e 0x28 0x55 0x00 0xf4 0x19 0x11 0x00 0x00 0x1e 0x00 0x00 0x00 0xfc 0x00 0x5a
0x4f 0x52 0x41 0x4e 0x20 0x48 0x44 0x4d 0x49 0x20 0x54 0x56 0x00 0x00 0x00 0xfd
0x00 0x3b 0x3d 0x0f 0x3c 0x0c 0x00 0x0a 0x20 0x20 0x20 0x20 0x20 0x20 0x01 0x22
0x02 0x03 0x18 0x71 0x45 0x07 0x02 0x03 0x04 0x05 0x26 0x09 0x07 0x07 0x15 0x07
0x50 0x66 0x03 0x0c 0x00 0x10 0x00 0x80 0x8c 0x0a 0xa0 0x14 0x51 0xf0 0x16 0x00
0x26 0x7c 0x43 0x00 0xf4 0x19 0x11 0x00 0x00 0x98 0x8c 0x0a 0xd0 0x8a 0x20 0xe0
0x2d 0x10 0x10 0x3e 0x96 0x00 0x90 0x2d 0x11 0x00 0x00 0x18 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x37
HDMI_EDID.tag = 2
HDMI_EDID.revision = 3
HDMI_EDID.offset = 24
HDMI_EDID.bUnderScan = 0
HDMI_EDID.bBasicAudio = 1
HDMI_EDID.YCBCR444 = 1
HDMI_EDID.YCBCR422 = 1
HDMI_EDID.native_format_number = 1
data_block_collection_length = 0x14, VideoTagCode(ptr) = 0x01
HDMI_EDID.VDB_length = 0x05
HDMI_EDID.VDB[0] = 0x07
HDMI_EDID.VDB[1] = 0x02
HDMI_EDID.VDB[2] = 0x03
HDMI_EDID.VDB[3] = 0x04
HDMI_EDID.VDB[4] = 0x05
data_block_collection_length = 0xe, AudioTagCode(ptr) = 0x01
HDMI_EDID.ADB_length = 0x02
(HDMI_EDID.ADB + 0)->coding_type = 0x01
(HDMI_EDID.ADB + 0)->channel_count = 0x01
(HDMI_EDID.ADB + 0)->sample_freq_all = 0x07
(HDMI_EDID.ADB + 0)->sample_size_all = 0x07
(HDMI_EDID.ADB + 0)->max_bit_rate_divided_by_8KHz = 0x00
(HDMI_EDID.ADB + 1)->coding_type = 0x02
(HDMI_EDID.ADB + 1)->channel_count = 0x05
(HDMI_EDID.ADB + 1)->sample_freq_all = 0x07
(HDMI_EDID.ADB + 1)->sample_size_all = 0x00
(HDMI_EDID.ADB + 1)->max_bit_rate_divided_by_8KHz = 0x50
[HDMI]: Pass ADB data to audio firmware.................
[HDMI]: Copy HDMI AUDIO data to physical addr(uncacheable addr)
[HDMI]: ADB[0] = 0x26
[HDMI]: ADB[1] = 0x9
[HDMI]: ADB[2] = 0x7
[HDMI]: ADB[3] = 0x7
data_block_collection_length = 0x7, SpeakerAllocationTagCode(ptr) = 0x00
data_block_collection_length = 0x7, VendorSpecificTagCode(ptr) = 0x01
HDMI_EDID.VSDB_length = 0x06
HDMI_EDID.VSDB[0] = 0x03
HDMI_EDID.VSDB[1] = 0x0c
HDMI_EDID.VSDB[2] = 0x00
HDMI_EDID.VSDB[3] = 0x10
HDMI_EDID.VSDB[4] = 0x00
HDMI_EDID.VSDB[5] = 0x80
data_block_collection_length = 0x0, ReservedTagCode(ptr) = 0x00
data_block_collection_length = 0x0, Reserved_6TagCode(ptr) = 0x00
data_block_collection_length = 0x0, VESA_DTC_DataTagCode(ptr) = 0x00
data_block_collection_length = 0x0, UseExtendedTagCode(ptr) = 0x00
HDMI_EDID.native_format_number = 0x01
HDMI_EDID.native_format[0] = 0x8c
HDMI_EDID.native_format[1] = 0x0a
HDMI_EDID.native_format[2] = 0xa0
HDMI_EDID.native_format[3] = 0x14
HDMI_EDID.native_format[4] = 0x51
HDMI_EDID.native_format[5] = 0xf0
HDMI_EDID.native_format[6] = 0x16
HDMI_EDID.native_format[7] = 0x00
HDMI_EDID.native_format[8] = 0x26
HDMI_EDID.native_format[9] = 0x7c
HDMI_EDID.native_format[10] = 0x43
HDMI_EDID.native_format[11] = 0x00
HDMI_EDID.native_format[12] = 0xf4
HDMI_EDID.native_format[13] = 0x19
HDMI_EDID.native_format[14] = 0x11
HDMI_EDID.native_format[15] = 0x00
HDMI_EDID.native_format[deleting routers
adding dns 192.168.42.127
16] = 0x00
HDMI_EDID.native_format[17] = 0x98
[HDMI] HDMI_GetCurrentVid(1037) HDMI_Video_List_Index 19
[HDMI] HDMI_GetCurrentVid(1038) HDMI_Video_Info_Index 11
[HDMI] HDMI_GetCurrentVid(1039) HDMI_EDID_VDB_Index 4
[HDMI] i 19 - HDMI_Video_List[i] 5
[HDMI] HDMI_GetNextVideoListIndex 20
[HDMI] HDMI_thread(135) call setHDMIAudioVideoFormat()
[HDMI] HDMI_GetCurrentVid(1037) HDMI_Video_List_Index 19
[HDMI] HDMI_GetCurrentVid(1038) HDMI_Video_Info_Index 11
[HDMI] HDMI_GetCurrentVid(1039) HDMI_EDID_VDB_Index 4
[HDMI] setHDMIPscan(456) HDMIPscan = 2
[HDMI] set setHDMIPSCANFlag = 1
[HDMI] VID = 0x5 1080i 60Hz
[HDMI] VIDEO type = 0x08
[HDMI] VIDEO HDMI_Sd_Hd = 0xa8
[HDMI] VIDEO Vid = 0x05
[HDMI] VIDEO RGB_or_YCbCr = 0x00
[HDMI] VIDEO PixelRepeat = 0x00
[HDMI] check EDID structure !!!!
[HDMI] HDMI_AudioCurrentIndex = 0
[HDMI] AUDIO use Input_I2S !!!!
[HDMI]: Turn on HDMI................... 1 s_freq=3 c_cnt=2 t=1231876063066
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
[HDMI]: Clear AVMute
[HDMI]: Turn on HDMI AUDIO
[HDMI]: Clear HDMI Audio Mute(Turn on AUDIO)
[HDMI]: Send_AudioMute() Ok, argp.hdmi_mute=0
[HDMI]: HDMISwitchTVSystem SP t=1231876063377
[HDMI] AUDIO HDMI_AudioInMode = 0x01
[HDMI] AUDIO HDMI_LocalInfo.coding_type = 0x01
[HDMI] AUDIO HDMI_LocalInfo.channel_count = 0x01
[HDMI] AUDIO HDMI_LocalInfo.sample_freq = 0x03
[HDMI] AUDIO HDMI_LocalInfo.sample_size = 0x03
[HDMI] AUDIO HDMI_LocalInfo.max_bit_rate_divided_by_8KHz = 0x00
[HDMI]: HDCP_Authenticate HDCPOper_state=0x3
[HDMI]: HDCP_Authenticate HDCPOper_state=0x4
[HDMI]: HDCP_Authenticate HDCPOper_state=0x5
[HDMI]: HDCP_Authenticate HDCPOper_state=0x6
[HDMI]: HDCP_Authenticate HDCPOper_state=0x9
[HDMI]: HDCP_Authenticate HDCPOper_state=0x7
[HDMI]: HDMI HDCP Authenticated t=1231876063378
wait wlan0!!2
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!3
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!4
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!5
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!6
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
lock success
I locked the file
I locked the file
release success
wait wlan0!!7
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!8
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!9
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!10
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
wait wlan0!!11
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
lock success
I locked the file
I locked the file
release success
wait wlan0!!12
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
o
tandy: GuideAP: CMD_POWER
[VIN] VIN_RPC_TVD_TOAGENT_VBI_CTRL, hr != S_OK !!!!!!!!!!!!
[AIN] AIN_RPC_TOAGENT_CREATE_0 send successful
wait wlan0!!13
start ao rpc config
start ao rpc config spdif
[AIN] InitializeInputStatus 1 1 0
[VE] RPC_EN_TOAGENT_ENC_INIT, format: 1, source: 0, hr = S_OK
Input Pin not connected while pause
[AE] RPC_TOAGENT_CREATE, hr = S_OK, agentID: 48
************** connect
[AIN] RPC_CONNECT to AO, 32 0 5 0
[AIN] RPC_CONNECT, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, numOfReadPtr: 1, listSize: 4
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, input pin, listSize: 4, header: 7ff9c618
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AIN] RPC_CONNECT to AE, 48 0 5 2
[AIN] RPC_CONNECT, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, numOfReadPtr: 2, listSize: 4
[AIN] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc460, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc4e0, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, out pin, listSize: 1
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[AE] msg ring buf m_pMsgRingLower: 4bd40000, m_pMsgRingUpper: 4bd48000
[AE] AUDIO_RPC_TOAGENT_INITRINGBUFFERHEADER, hr = S_OK
[VE] RPC_TOAGENT_INITRINGBUFFER, header: dc560, hr = S_OK
[VE] RPC_EN_TOAGENT_SETTF, 1 1, hr = S_OK
[VE] RPC_EN_TOAGENT_SETNR, 3 3, hr = S_OK
[VE] RPC_EN_TOAGENT_SETENCODEFORMAT, 1, hr = S_OK
[VE] RPC_EN_TOAGENT_SETRESOLUTION, hres: 720, SIF: 0, hr = S_OK
[VE] RPC_EN_TOAGENT_SETBITRATE, hr = S_OK
[VE] RPC_EN_TOAGENT_SETGOPSTRUCTURE, M: 3, N: 12, hr = S_OK
[VE] RPC_EN_TOAGENT_CONFIGVOBU, 1, hr = S_OK
[VIN] VIN_RPC_TVD_TOAGENT_TVD_CONFIGURE, hr = S_OK
[VE] RPC_EN_TOAGENT_SETTF, 0 0, hr = S_OK
[VE] RPC_EN_TOAGENT_SETNR, 0 0, hr = S_OK
[AIN] AIN_RPC_TOAGENT_TSD_CONFIG: 0......
[AIN] AIN_RPC_TOAGENT_TSD_CONFIG, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_PAUSE
[AE] AUDIO_RPC_TOAGENT_PAUSE, hr = S_OK
[VE] RPC_TOAGENT_PAUSE....
[VE] RPC_TOAGENT_PAUSE, hr = S_OK
*** aout pause
[AIN] ADC0_Config: 1 15 0 0, 48000 16
[AIN] ADC0_Config, hr = S_OK
[AIN] ADC1_Config: 1 15 0 0, 48000 16
[AIN] ADC1_Config, hr = S_OK
[AE] AUDIO_RPC_TOAGENT_RUN...
[AE] AUDIO_RPC_TOAGENT_RUN, hr = S_OK
[VE] RPC_TOAGENT_RUN....
MEMCache Hit [2]! size = 1638400, address = 0x43a00000
[VE] RPC_TOAGENT_RUN, hr = S_OK
[AIN] AUDIO_RPC_TOAGENT_RUN
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
[AIN] AUDIO_RPC_TOAGENT_RUN, hr = S_OK
[AIN] AIN_RPC_TOAGENT_MUTE: 1......
[AIN] AIN_RPC_TOAGENT_MUTE, hr = S_OK
[VIN] VIN_RPC_TVD_TOAGENT_TVD_CONFIGURE, hr = S_OK
[AIN] AIN_RPC_TOAGENT_SWITCH_FOCUS: 0......
[AIN] AIN_RPC_TOAGENT_SWITCH_FOCUS, hr = S_OK
Key processed.
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
-->Somewhere around here, I told it to shut down (not using standby or the power button...read on to see how)
[VE] status: (3, 1, 0, 0, 3)
[VE] notify FE_RECORD_NOSIGNAL
[AE] AUDIO_RPC_TOAGENT_PAUSE
[AE] AUDIO_RPC_TOAGENT_PAUSE, hr = S_OK
[VE] RPC_TOAGENT_PAUSE....
[VE] RPC_TOAGENT_PAUSE, hr = S_OK
state force paused
[AE] AUDIO_RPC_TOAGENT_STOP
[AE] AUDIO_RPC_TOAGENT_STOP, hr = S_OK
AUDIO_RPC_ToSystem_HDMI_Setting_0_svc(546) prio_process = 0
[HDMI]: AUDIO parameters are the same, no need to setup again.
wait wlan0!!14
free [2] address 0x43a00000, size = -1638400 to Cache
[VE] RPC_TOAGENT_STOP, hr = S_OK
state force stoped
[AIN] AUDIO_RPC_TOAGENT_STOP
[AIN] AUDIO_RPC_TOAGENT_STOP, hr = S_OK
MediaLoaderThread stopped
!!!!!!!!!!!!!!!!!!! CMD_TERMINATE received
lock success
I locked the file
I locked the file
release success
lock success
I locked the file
I locked the file
release success
Free Graphic 0x47000000
Free Graphic 0x473c0000
Free Graphic 0x47300000
Free Graphic 0x47380000
error in pli_freeContinuousMemory()...
error in pli_freeContinuousMemory()...
In my system...
MediaServer.cpp , 431 bind local IP fail 0 !!error = Address already in use
free [0] address 0x42000000, size = -16777216 to Cache
wait wlan0!!15
Entering Suspend Mode ..
SYSTEM STANDBY MODElock success
I locked the file
I locked the file
release success
Schedule is off.
Delete Network
In my system...
Something else I found was that I could control the DvdPlayer from my keyboard in this mode. These are the keys that did something that I could determine. I know there are some missing because the DVD Player wouldn't allow certain operations at that time. For instance, I can't seem to find a video with multiple angles, but I'm sure one of these keystrokes is the angle button. Update: Post on emtec reveals that e is the angle button.
a - audio button
b - takes you into the recording setup screen
c - delete schedule when in recording, otherwise doesn't appear to do anything
e - angle (reported by other users, not verified)
f - reverse play <<
j - reverse zoom (starts at max zoom and goes back to 1)
l - slow play reverse
m - mute on/off
n - skip to next title (not chapter)
o - Shut down quickly
p - skip to prior title (not chapter)
q - go back 10 SECONDS
r - start recording / switch to av
s - subtitle toggle
v - volume -
z - normal zoom
A - left
B - 30 Second Skip
C - Command Line interpreter, engineering mode, see below
D - right
E - Delete
F - Fast forward >>
G - Asks for GCode. Not sure what the GCode is. Tried a VCR+ code given the context, but the code I tried only crashed the player.
H - report some kind of status
L - slow play forward
M - Menu
N - Next chapter
O - shut down normally
P - Prior chapter
Q - Stop
S - Play
T- AV input screen
V - volume +
W - up
X - down
Z - Step / pause
- - goto
= - repeat a/b
+ - repeat button
# - go to USB screen
$ - go to SPP directory when on another source
& - graphical file copy, looks nice. Much better than the cut/copy/paste concept you can do from the remote.
( - start performance logging
) - stop performance logging
~ - memory allocation status
0-9 - same as entering 0-9. Jumps to title. I did not know you could jump to a specific title that way on this player, so something new.
[ - source button
] - In the menu, will go to the last source accessed.
{ - home button
, - return button
/ - go to setup menu
\ - switch tv system
: - switch tv system (not sure how it is different from \)
ESC - Go to setup menu
Spacebar - Select (this is what the play button on the remote maps to)
In engineering mode, you can type HELP and get this:
Engineering Mode Command List:
port: read or write value to specified address
setdebug: set audio/video debug flag
setbri
setcont
setsatu
sethue
setscal
00~0xFFFF)
setcolorm
: set VO hardware's Color Adjustment transformation matrix
copyfree: enable copy-free
netperf
ff to tern on/off this feature
netperf nodecode, means streaming only withou
t decode.
setyc: set YC separation parameters [6 parameters]
| save: save setting
| load: load setting
| default: use factory default setting
| show: show current setting
shell: Unix Shell to execute unix command
kill: kill the program immediately (to generate coredump)
quit: quit from command line interpreter
So I'm thinking if I can grab the stdin of the DvdPlayer process, I could have another program control it. It could start the recording, for instance. Or it could automatically navigate, play certain files. In fact, some of the information coming back during DvdPlayer execution relates to the video/music/picture it is currently working on. And I would love to be able to map the 30 second skip command to a remote button...
Wednesday, January 7, 2009
Getting buildroot to work
Ok, I've already talked about compiling a binary on the device using the toolchain I found. Unfortunately, it works less often than I expected due to the difference in libraries and linux system.
So a better option would be to build my own so I can specify exactly which linux kernel to use, and which uclibc to use.
Well, this has not been an easy process. I originally started documenting all of the steps, but there have been so many steps trying to get it to work that I've lost track.
Step 1. Get the Ubuntu 8.04 ISO.
Step 2. Get vmware player. This will allow you to play a virtual machine on your machine. It's a way to host another operating system without losing what you have on yours.
Step 3. Get vmx builder. This is a way to build the virtual machines. You'll need to set up one that has a CD Rom that points to the Ubuntu ISO, and a hard drive with at least 20 GB.
Step 4. Launch the ubuntu VMX. This will start the virtual machine and launch the Ubuntu install. After you have completed the linux install, you'll be ready to start the real task.
Step 5. Once into linux, open a terminal screen. At the prompt type:
sudo apt-get install xxxxx
where xxxxx is replaced with the following packages:
gcc
libssl-dev
libncurses-dev
bison
flex
texinfo
zlib1g-dev
gettext
autoconf
patch
subversion
wget
That will install those individual packages. You can combine those onto one line separated with a space to save time. I've put them on individual lines so you can see each package required.
Then type:
sudo dpkg-reconfigure dash
and when prompted, select No. This was at the recommendation of another website that said dash would interfere.
That's all for the prerequisites.
now type
svn co svn://uclibc.org/trunk/buildroot
That will pull down the buildroot source. Now you need to configure it. Type:
make menuconfig
and after a moment, you will get the configuration. Change the configuration target so that it will do (first option) MIPSEL, (second option) MIPS32. You can also enable Large File support (I suspect Iomega forgot to do that one) and the generic development too.
Now exit. Then type
make
Bye bye. It'll take a while. When you get back, you'll find that you've just compiled a root file system for the wrong version of the Linux kernel, and the wrong version of the uClibc. Hold on, that doesn't mean get mad at me for not telling you the additional configuration options. You have to do it first the way it is currently checked into SVN. It is possible it won't work. If it doesn't work, solve the problems before continuing on. That'll make it easier to solve the problems you will run into when selecting the right kernel and uclibc.
Ok, if you want the older version of the linux file system that matches the one on the SPP, then go to the ~/buildroot/package/linux directory and modify the Config.in file in it to include the correct version of linux.
Now build, selecting the new version of linux. It'll download and decompress it, but then fail because it doesn't know how to build the Kbuild file. You'll need to pull the Kbuilds from the other linux directory. The Kbuild file appears to tell the buildroot utility what include files are needed. Well, the other linux directory includes files in the Kbuilds that aren't in the older version of linux, so after you copy then you'll have to modify those Kbuild files to remove those references.
Except there's another complication. The newer version of linux includes unifdef which is needed in the build. So you need to pull that one from the other version of linux as well.
Then you may find .h files in different places, which can be resolved by putting in symbolic links from their regular place.
And then there's trying to find the right package selection. I selected the build environment and blew everything up.
uClibc version is there, but you have to select the option for showing obsolete packages. Oh, and be sure to do a make clean when switching between linux and uclibc versions.
Yeah, see, it was getting so complicated I couldn't keep it down to a few simple steps.
Maybe somebody who understands buildroot will find an easier way. But I think from here, the best thing for me to do is to provide the .tar of my buildroot directory (so you can pull down your own packages as needed, and solve the problems with them as you try to compile them).
And for those who are satisfied with a 2.6.12.6 version of linux + 0.9.28 uClibc toolchain + gcc and tools in an .ext2 file that can be chrooted to, I can provide the ext2 file.
All I have to do at this point is find a place to host the files. box isn't going to do it because the ext2 is 75 Mb and the tar file is over 1 gb, although I think I can get the size down on that by removing some of the easy-to-add packages and let them download.
Stay tuned if you're interested in either of these files. In fact, leave me a comment letting me know you're interested, as I probably won't try to find a host until I know somebody wants this.
So a better option would be to build my own so I can specify exactly which linux kernel to use, and which uclibc to use.
Well, this has not been an easy process. I originally started documenting all of the steps, but there have been so many steps trying to get it to work that I've lost track.
Step 1. Get the Ubuntu 8.04 ISO.
Step 2. Get vmware player. This will allow you to play a virtual machine on your machine. It's a way to host another operating system without losing what you have on yours.
Step 3. Get vmx builder. This is a way to build the virtual machines. You'll need to set up one that has a CD Rom that points to the Ubuntu ISO, and a hard drive with at least 20 GB.
Step 4. Launch the ubuntu VMX. This will start the virtual machine and launch the Ubuntu install. After you have completed the linux install, you'll be ready to start the real task.
Step 5. Once into linux, open a terminal screen. At the prompt type:
sudo apt-get install xxxxx
where xxxxx is replaced with the following packages:
gcc
libssl-dev
libncurses-dev
bison
flex
texinfo
zlib1g-dev
gettext
autoconf
patch
subversion
wget
That will install those individual packages. You can combine those onto one line separated with a space to save time. I've put them on individual lines so you can see each package required.
Then type:
sudo dpkg-reconfigure dash
and when prompted, select No. This was at the recommendation of another website that said dash would interfere.
That's all for the prerequisites.
now type
svn co svn://uclibc.org/trunk/buildroot
That will pull down the buildroot source. Now you need to configure it. Type:
make menuconfig
and after a moment, you will get the configuration. Change the configuration target so that it will do (first option) MIPSEL, (second option) MIPS32. You can also enable Large File support (I suspect Iomega forgot to do that one) and the generic development too.
Now exit. Then type
make
Bye bye. It'll take a while. When you get back, you'll find that you've just compiled a root file system for the wrong version of the Linux kernel, and the wrong version of the uClibc. Hold on, that doesn't mean get mad at me for not telling you the additional configuration options. You have to do it first the way it is currently checked into SVN. It is possible it won't work. If it doesn't work, solve the problems before continuing on. That'll make it easier to solve the problems you will run into when selecting the right kernel and uclibc.
Ok, if you want the older version of the linux file system that matches the one on the SPP, then go to the ~/buildroot/package/linux directory and modify the Config.in file in it to include the correct version of linux.
Now build, selecting the new version of linux. It'll download and decompress it, but then fail because it doesn't know how to build the Kbuild file. You'll need to pull the Kbuilds from the other linux directory. The Kbuild file appears to tell the buildroot utility what include files are needed. Well, the other linux directory includes files in the Kbuilds that aren't in the older version of linux, so after you copy then you'll have to modify those Kbuild files to remove those references.
Except there's another complication. The newer version of linux includes unifdef which is needed in the build. So you need to pull that one from the other version of linux as well.
Then you may find .h files in different places, which can be resolved by putting in symbolic links from their regular place.
And then there's trying to find the right package selection. I selected the build environment and blew everything up.
uClibc version is there, but you have to select the option for showing obsolete packages. Oh, and be sure to do a make clean when switching between linux and uclibc versions.
Yeah, see, it was getting so complicated I couldn't keep it down to a few simple steps.
Maybe somebody who understands buildroot will find an easier way. But I think from here, the best thing for me to do is to provide the .tar of my buildroot directory (so you can pull down your own packages as needed, and solve the problems with them as you try to compile them).
And for those who are satisfied with a 2.6.12.6 version of linux + 0.9.28 uClibc toolchain + gcc and tools in an .ext2 file that can be chrooted to, I can provide the ext2 file.
All I have to do at this point is find a place to host the files. box isn't going to do it because the ext2 is 75 Mb and the tar file is over 1 gb, although I think I can get the size down on that by removing some of the easy-to-add packages and let them download.
Stay tuned if you're interested in either of these files. In fact, leave me a comment letting me know you're interested, as I probably won't try to find a host until I know somebody wants this.
Friday, January 2, 2009
Solving the NTFS problem
On the way home tonight, my friend and I started talking about the facts that we knew and started speculating as to what is really happening. We had eliminated the operating system as the issue by testing it out on both XP and another Vista machine. We came up with a few experiments to run to eliminate the possibility of it being a hardware issue. On the computer that was causing the problem, we mounted it using a live linux CD, then unmounted and confirmed that it was still working. That eliminated the hardware.
With those eliminated, we figured it had to be related to software. Since we were seeing this on a sony machine and a dell machine, it eliminated sony and dell software (what's on one would not likely be on the other). That made 3rd party software suspect. Found that a common program was Norton Internet Security 2009. Tried disabling it, but it still caused the problem. Uninstalled and... it worked! Installed Norton Internet Security 2007 and it continued to work, so it was specific to the 2009 version.
We're speculating that Norton is marking the drive, much like it does when you use Ghost (also by the same company). It could be marking it to trap boot sector viruses, or marking it as a monitored drive. Whatever the reason, it is apparently compatible with Vista, XP, and Gentoo Linux, but not compatible with the NTFS driver on the ScreenPlay Pro.
Response to comments:
Sabi -- per your request:
/ # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 ro 0 0
none /dev devfs rw 0 0
none /proc proc rw,nodiratime 0 0
devpts /dev/pts devpts rw 0 0
none /sys sysfs rw 0 0
none /tmp ramfs rw 0 0
/dev/ide/host0/bus0/target0/lun0/part2 /usr/local/etc/dvdplayer ext3 rw 0 0
/dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_mult
iplier=1 0 0
/dev/rd/0 /mnt/rd vfat rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iochar
set=iso8859-1 0 0
/ # uname -a
Linux Iomega 2.6.12.6-VENUS #29 Wed Sep 10 22:00:48 CST 2008 mips unknown
With those eliminated, we figured it had to be related to software. Since we were seeing this on a sony machine and a dell machine, it eliminated sony and dell software (what's on one would not likely be on the other). That made 3rd party software suspect. Found that a common program was Norton Internet Security 2009. Tried disabling it, but it still caused the problem. Uninstalled and... it worked! Installed Norton Internet Security 2007 and it continued to work, so it was specific to the 2009 version.
We're speculating that Norton is marking the drive, much like it does when you use Ghost (also by the same company). It could be marking it to trap boot sector viruses, or marking it as a monitored drive. Whatever the reason, it is apparently compatible with Vista, XP, and Gentoo Linux, but not compatible with the NTFS driver on the ScreenPlay Pro.
Response to comments:
Sabi -- per your request:
/ # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 ro 0 0
none /dev devfs rw 0 0
none /proc proc rw,nodiratime 0 0
devpts /dev/pts devpts rw 0 0
none /sys sysfs rw 0 0
none /tmp ramfs rw 0 0
/dev/ide/host0/bus0/target0/lun0/part2 /usr/local/etc/dvdplayer ext3 rw 0 0
/dev/ide/host0/bus0/target0/lun0/part4 /usr/local/etc/dvdplayer/hdd/volumes/HDD1
ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_mult
iplier=1 0 0
/dev/rd/0 /mnt/rd vfat rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iochar
set=iso8859-1 0 0
/ # uname -a
Linux Iomega 2.6.12.6-VENUS #29 Wed Sep 10 22:00:48 CST 2008 mips unknown
Thursday, January 1, 2009
Change of mind
Ok, so after exploring some new avenues on the SPP and trying to figure out where my discoveries really belong, I decided the wikidot wiki really wasn't the place for it. So I created a new wiki and I'm logging all of the information I'm discovering there.
http://screenplayprohd.wikia.com
I've added my 2 GB fix to it this morning. It was the luck of a draw, really. I was exploring the wikidot and noticed that on a German page (Peter's) where they discussed the FTP hack, they also had the samba hack. So I pulled that one down, extracted it (WinRar again) and found an smbd binary in it. Tried plugging it directly in place of the one on the drive (located at /usr/local/etc/dvdplayer/samba/bin) but that didn't fix the problem. In fact, it stopped the drive from recognizing any smb requests. I removed it from the inetd.conf file (in the /etc directory) and manually started it myself, specifying the location of the configuration file.
It worked. So I added it back into the inetd.conf file and added the samba configuration file as a parameter to the drive. Tried it again, and it worked. Cool thing is, it ended up transferring the file about twice as fast.
Some other things I've done:
1. With a second screenplay on the network, was able to confirm that they can see each other, that they both have different names (iomega-d7xxxxxx), and both have different divx codes.
2. Was able to format the media partition on the drive as ext3 (used the system rescue cd, fdisk to drop the partition and recreate it at an ext3 partition, then formatted it, which took a long time).
3. Trying to help out a friend -- his drive stops booting whenever he plugs the screenplay pro hd into Vista, even if he doesn't access the drive and just unplugs it. So I formatted mine as ext3, plugged it into his computer and it continued to work afterwards.
That means formatting it for fat32 would probably also take care of the problem, but then you've got a silly 4 gb limit. Reformatted it for NTFS, plugged it into his computer again and it stopped working.
At that point, I used the system rescue CD, disabled the mount (found in /etc/rcS1) and then booted it. Yes, it booted, but the drive was obviously inaccessible. Nonetheless, I was able to get into it via telnet and try to mount it manually. Got a segmentation fault, the drive had been "corrupted." The built in windows scandisk utilities did not fix it.
Vista has added some additional things into the drive which are supposed to be backwards compatible. Tried mounting it with system rescue cd and the ntfs-3g driver and it worked fine. So the problem is the screenplay pro hd ntfs driver. It is not compatible with the Vista changes.
4. Took apart the drive to see its innards. Nothing spectacular to look at, as most of the secrets are under the heat sink. The heat sink covers the main processor and I wasn't about to try to remove it. The shielding was really annoying to get off too.
5. Mapped out all of the remote codes. Tried sending it some of the unmapped remote codes, but didn't find any hidden menus / service menus. I logged all of that on the wiki. Did find that the requirement to point directly at the device comes from the lack of a good IR light on the remote itself. When I used my JP-1 remote, I could bounce the signal off of walls and picture frames and it would still pick it up. So the main unit has a good IR receiver. I think there may be a way to send a keycode to the player using the network. I'm going to explore that someday too.
6. I discovered that the uclibc libraries that ship with the device (0.9.28) are not binary compatible with those found on the toolchain I discovered earlier. So while it is still possible to run programs when you've done a chroot to do the compile, most of those won't work once you exit the chroot shell. So I will need to figure out a way to get a precompiled 0.9.28 toolchain. I think Peter may have the answer.
Response to comments:
Dominik -- haven't looked into the auto mount for the usb drives. It's easy enough to switch them to read/write, but I suspect you're asking how to get them to mount as r/w to begin with. The approach I'd take to figure it out would be to telnet in with the drive just barely powered up and the USB drive attached to it. If it is already mounted, then there may be a startup script on the drive somewhere that does it and it should easy to modify. If it isn't mounted until you select the USB option in the menu, then the main DvdPlayer is responsible for mounting it and it will be much more difficult to change without doing it through telnet every time. I'll take a look at it later and see.
-- followup: after I posted, I recalled that there was a "hotplug" binary that detects the new USB devices. Looking at the binary, I see the mount command being done as -o ro (read only) inside the binary. So you can wait for Iomega to publish their modifications to the hotplug program (yeah, right) or you can use a tool like WinHex to modify that binary so that the devices will be mounted read/write. Just look for the text "mount" in the hotplug file and, you'll find it. Make sure you don't insert new or delete extra characters, or you'll kill the binary. /sbin is where the hotplug file is found.
http://screenplayprohd.wikia.com
I've added my 2 GB fix to it this morning. It was the luck of a draw, really. I was exploring the wikidot and noticed that on a German page (Peter's) where they discussed the FTP hack, they also had the samba hack. So I pulled that one down, extracted it (WinRar again) and found an smbd binary in it. Tried plugging it directly in place of the one on the drive (located at /usr/local/etc/dvdplayer/samba/bin) but that didn't fix the problem. In fact, it stopped the drive from recognizing any smb requests. I removed it from the inetd.conf file (in the /etc directory) and manually started it myself, specifying the location of the configuration file.
It worked. So I added it back into the inetd.conf file and added the samba configuration file as a parameter to the drive. Tried it again, and it worked. Cool thing is, it ended up transferring the file about twice as fast.
Some other things I've done:
1. With a second screenplay on the network, was able to confirm that they can see each other, that they both have different names (iomega-d7xxxxxx), and both have different divx codes.
2. Was able to format the media partition on the drive as ext3 (used the system rescue cd, fdisk to drop the partition and recreate it at an ext3 partition, then formatted it, which took a long time).
3. Trying to help out a friend -- his drive stops booting whenever he plugs the screenplay pro hd into Vista, even if he doesn't access the drive and just unplugs it. So I formatted mine as ext3, plugged it into his computer and it continued to work afterwards.
That means formatting it for fat32 would probably also take care of the problem, but then you've got a silly 4 gb limit. Reformatted it for NTFS, plugged it into his computer again and it stopped working.
At that point, I used the system rescue CD, disabled the mount (found in /etc/rcS1) and then booted it. Yes, it booted, but the drive was obviously inaccessible. Nonetheless, I was able to get into it via telnet and try to mount it manually. Got a segmentation fault, the drive had been "corrupted." The built in windows scandisk utilities did not fix it.
Vista has added some additional things into the drive which are supposed to be backwards compatible. Tried mounting it with system rescue cd and the ntfs-3g driver and it worked fine. So the problem is the screenplay pro hd ntfs driver. It is not compatible with the Vista changes.
4. Took apart the drive to see its innards. Nothing spectacular to look at, as most of the secrets are under the heat sink. The heat sink covers the main processor and I wasn't about to try to remove it. The shielding was really annoying to get off too.
5. Mapped out all of the remote codes. Tried sending it some of the unmapped remote codes, but didn't find any hidden menus / service menus. I logged all of that on the wiki. Did find that the requirement to point directly at the device comes from the lack of a good IR light on the remote itself. When I used my JP-1 remote, I could bounce the signal off of walls and picture frames and it would still pick it up. So the main unit has a good IR receiver. I think there may be a way to send a keycode to the player using the network. I'm going to explore that someday too.
6. I discovered that the uclibc libraries that ship with the device (0.9.28) are not binary compatible with those found on the toolchain I discovered earlier. So while it is still possible to run programs when you've done a chroot to do the compile, most of those won't work once you exit the chroot shell. So I will need to figure out a way to get a precompiled 0.9.28 toolchain. I think Peter may have the answer.
Response to comments:
Dominik -- haven't looked into the auto mount for the usb drives. It's easy enough to switch them to read/write, but I suspect you're asking how to get them to mount as r/w to begin with. The approach I'd take to figure it out would be to telnet in with the drive just barely powered up and the USB drive attached to it. If it is already mounted, then there may be a startup script on the drive somewhere that does it and it should easy to modify. If it isn't mounted until you select the USB option in the menu, then the main DvdPlayer is responsible for mounting it and it will be much more difficult to change without doing it through telnet every time. I'll take a look at it later and see.
-- followup: after I posted, I recalled that there was a "hotplug" binary that detects the new USB devices. Looking at the binary, I see the mount command being done as -o ro (read only) inside the binary. So you can wait for Iomega to publish their modifications to the hotplug program (yeah, right) or you can use a tool like WinHex to modify that binary so that the devices will be mounted read/write. Just look for the text "mount" in the hotplug file and, you'll find it. Make sure you don't insert new or delete extra characters, or you'll kill the binary. /sbin is where the hotplug file is found.
Subscribe to:
Posts (Atom)