wigout
11-19-2010, 01:47 AM
I'm not sure what happened to the original post, but I think there's nothing wrong with discussing someone's firmware modifications, so here goes.
Earlier today usli posted a link to a firmware for the pbo which he'd modified. He added on some web remote control stuff and prepared alot opt accessory files. All good, but he was presenting it as a "shareware" model (the firmware was set to reboot after fifteen minutes until you had the right key), which would bring all the issues of doing any of these mods for-profit.... which would would seem to be troublesome in a context such as this forum.
Anyway, I mentioned that he'd moved the DvdPlayer from it's native location and symlinked it to a copy on the /usr/local/etc partition. He sent me a pm about it and I responded to him, but it seems like a good point to discuss so here's our exchange:
[quote=wigout]Usil-
1. Remote control in a web browser. I just learned about Infosite today but a simple run on PBO doesn't work and the interface is not customized for iphone and other handhelds. I am sure it can be fixed but I didn't bother. My approach is totally different but sorry it doesn't work as an addon.
.....
ps. The reason to move DvdPlayer is nothing but to improve performance and it doesn't have to. And I don't get your point in your post. Corruption of any one of the many important files can lead to booting
issues, so why picked on DvdPlayer, right?
How did you differently implement the remote control interface?
If you must move a startup critical file to the the /usr/local/etc the best practice is to also make the same files available in the original underlying image-- that is, if you have moved the DvdPlayer or (.DvdPlayer as you've renamed it) to the /usr/local/etc/dvdplayer directory, you'd want to make sure that the squashfs1.img ALSO had the .DvdPlayer in the /usr/local/etc/dvdplayer
That way if the /dev/mtdblock/2 gets corrupted, the player will still be able to start. This is the same approach the players take- in fact the usr.local.tar / dev/mtdblock/2 usually starts with the same content as the /usr/local/etc/ as packaged in the root-filesystem image.
Anyway, what I meant for an overlay is something like this:
on ubuntu or wherever, make an ext3 disk image, (http://www.patriotmemory.com/forums/showthread.php?t=4611) about 25 mb.
put all the files you'd like in there.
give out that image file plus an install script.
For simplicity's sake, assume that the install script and your modified image file will be on the root of your usb drive.
the install script moves the /usr/local/etc/rcS to /usr/local/etc/rcS2
and creates a /usr/local/etc/rcS file
that does something like:
#Waiting for usb to mount...
n=1
while [ ! -d /tmp/usbmounts/sbd1 ] ; do
sleep 3
[ $n -gt 30 ] && break
let n+=1
done
#bind rss scripts directory:
mkdir /usr/local/etc/usil-mod
mount -o bind /tmp/usbmounts/sbd1/usil-mod.img /usr/local/etc/usil-mod
if [ ! -f /usr/local/etc/usli-mod/startup-script ]
then /usr/local/etc/rcS2
else /usr/local/etc/usli-mod/startup-script
exit
This waits for the usb to mount, then mounts your usli-mod.img file (if it can be found). Then, if the startup-script can be found it gets executed, including all sorts of mount -o bind stuff to let all your modified files be put in their proper places. If the startup script can't be found (that is, if something went wrong, if the usb can't be found, etc) well everything continues as it was, executing the original /usr/local/etc/rcS (now /usr/local/etc/rcS2) in its place.
-wigout
Earlier today usli posted a link to a firmware for the pbo which he'd modified. He added on some web remote control stuff and prepared alot opt accessory files. All good, but he was presenting it as a "shareware" model (the firmware was set to reboot after fifteen minutes until you had the right key), which would bring all the issues of doing any of these mods for-profit.... which would would seem to be troublesome in a context such as this forum.
Anyway, I mentioned that he'd moved the DvdPlayer from it's native location and symlinked it to a copy on the /usr/local/etc partition. He sent me a pm about it and I responded to him, but it seems like a good point to discuss so here's our exchange:
[quote=wigout]Usil-
1. Remote control in a web browser. I just learned about Infosite today but a simple run on PBO doesn't work and the interface is not customized for iphone and other handhelds. I am sure it can be fixed but I didn't bother. My approach is totally different but sorry it doesn't work as an addon.
.....
ps. The reason to move DvdPlayer is nothing but to improve performance and it doesn't have to. And I don't get your point in your post. Corruption of any one of the many important files can lead to booting
issues, so why picked on DvdPlayer, right?
How did you differently implement the remote control interface?
If you must move a startup critical file to the the /usr/local/etc the best practice is to also make the same files available in the original underlying image-- that is, if you have moved the DvdPlayer or (.DvdPlayer as you've renamed it) to the /usr/local/etc/dvdplayer directory, you'd want to make sure that the squashfs1.img ALSO had the .DvdPlayer in the /usr/local/etc/dvdplayer
That way if the /dev/mtdblock/2 gets corrupted, the player will still be able to start. This is the same approach the players take- in fact the usr.local.tar / dev/mtdblock/2 usually starts with the same content as the /usr/local/etc/ as packaged in the root-filesystem image.
Anyway, what I meant for an overlay is something like this:
on ubuntu or wherever, make an ext3 disk image, (http://www.patriotmemory.com/forums/showthread.php?t=4611) about 25 mb.
put all the files you'd like in there.
give out that image file plus an install script.
For simplicity's sake, assume that the install script and your modified image file will be on the root of your usb drive.
the install script moves the /usr/local/etc/rcS to /usr/local/etc/rcS2
and creates a /usr/local/etc/rcS file
that does something like:
#Waiting for usb to mount...
n=1
while [ ! -d /tmp/usbmounts/sbd1 ] ; do
sleep 3
[ $n -gt 30 ] && break
let n+=1
done
#bind rss scripts directory:
mkdir /usr/local/etc/usil-mod
mount -o bind /tmp/usbmounts/sbd1/usil-mod.img /usr/local/etc/usil-mod
if [ ! -f /usr/local/etc/usli-mod/startup-script ]
then /usr/local/etc/rcS2
else /usr/local/etc/usli-mod/startup-script
exit
This waits for the usb to mount, then mounts your usli-mod.img file (if it can be found). Then, if the startup-script can be found it gets executed, including all sorts of mount -o bind stuff to let all your modified files be put in their proper places. If the startup script can't be found (that is, if something went wrong, if the usb can't be found, etc) well everything continues as it was, executing the original /usr/local/etc/rcS (now /usr/local/etc/rcS2) in its place.
-wigout