I've got a project on a side burner that's basically using a proprietaryIt looks like it's a read-only filesystem, so dunno if there's any point getting that driver to work?
set-top-box (can provide details privately), the customer want's to change
some of the startup files contained on a certain partition of a
disk-on-module IDE device. This is in no way to do anything illegal, they simply want to use the box for something it wasn't intended for. They know it's possible because they've managed to configure it once booted, they just can't seem to store the changes.
I should point out that this very excercise is LEGAL at this point but would most likely not be LEGAL if the FTA goes ahead. Write to your minister about it.
Anyway... managed to dd a copy of the disk-on-module to play with and looks like the 2nd partition is ext2 but the first is not anything regular. Doing a strings on it revealed the string "The boot/system partition is not of type CROMDISK !" among other things (pointing to the manufacturer).
Anyway, cutting to the chase... I believe it's using something called a Compressed Block Device which acts like so:-
fwrite()-->ext2-->CBD-->ide_block_device-->physical_mediaFrom my understanding it's not cramfs, romfs or cromfs (2 out of 3 in thenormal kernel tree).
I found a patch for the 2.4.0 kernel below. There's some interesting reading fairly early on (starting line 35).
http://grumbeer.dyndns.org/ftp/linux/kernel/patches/misc/cbd-2.4.0-2.patch
I tried to patch it into the 2.4.22 source and lets just say it got beyond me as after fixing up the rejects it really wasn't going to build nicely.
Right now I'm seeing if I can build a 2.4.2 kernel I found from a SRC RPM on a RedHat 7.1 CD set with the hope that the patch will have more chance of building. The point of this excercise is to build as system that can modify this partition, hence I don't care what kernel it runs. Just thought I'd write this email whilst waiting for the build to finish.
The time spent on this so far is more than it's worth so my client is pursuing other avenues - I'm mainly doing this because I belive it may help some other clients that have a similar problem down the track and some stuff we've run up against in the past.
I'm prepared to give an EverythingLinux discount in return or something like that.
Seems like the mkimg program in there takes an existing filesystem and compresses it for reading by the CBD driver, so maybe you could get away with just writing something to decompress an image, based on what mkimg does to compress it.
Shouldn't the device manufacturer be providing source for it by the way?
Felix
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
