[humidify] HDF file utility

af123

af123

Administrator
Staff member
Here is where you can find a copy of the Humidify utility for manipulating HDF files. It's also available to run directly on a Humax via the package framework; just install the humidify package.
 
af123 said:
Here is where you can find a copy of the Humidify utility for manipulating HDF files. It's also available to run directly on a Humax via the package framework; just install the humidify package.

humidify-1.0.0.zip
Click to expand...

Any chance of the source code ?

I use 64-bit linux and sometimes binaries break, especially with new versions of the o/s.

I'll be upgrading from Mandriva 2010.2 to 2011.0 soon...
 
suarez said:
Does this utility allow me to produce my own customised firmware using my beta hdf?
Click to expand...

Yes. You can extract the root filesystem block from the beta firmware using humidify, unsquash that (using the Linux squashfs tools) and modify it to drop in whatever you want, squash it back up and then use humidify again to create a HDF that will load onto your box. You should only include the rootfs section in the final HDF and leave out the kernel/bootloader/other sections
 
Thanks for the reply. I thought so and I have been doing a bit of reading-up (starting with hacking thread)...

I just simply want to put your minirootfs together with the beta firmware and upload that to the box. What do I do? I am thinking, using humidify:

1. On your customised firmware and extract all parts.
2. On the beta firmware and extract all parts.
3. Put the new firmware together containing all beta firmware part except the linux kernel, instead using the one extracted from your customised firmware.

Is this the way to go?
 
suarez said:
Is this the way to go?
Click to expand...

Not quite. If you're already running the beta firmware then you already have the beta system ID, beta kernel and beta bootloader, and you don't want to touch them.

You just want to load a modified copy of the beta root filesystem.

So, extract just the root filesystem from the beta which is the section of type 1 and address 0000000 (use humidify <HDF file> with no other arguments to list the sections then extract the relevant section with 'humidify -S <section> -x <HDF file>')

Once you have the root filesystem extracted, then you need to use the Linux squashfs tools to extract the filesystem. You'll need to drop in the right scripts and binaries from my customised firmware into the right places and check that Humax haven't changed anything that would conflict.

Then squash up the filesystem again and create a new HDF with only that squashed root filesystem in it.
 
Ah, I think I get it now. If I build an hdf just with the squashed root filesystem in it, then it will only be that code that will change when I flash my box... leaving the other bits of code untouched..?

If Humax have updated the squashed root filesystem, then what I should do is to copy over your binaries and scripts, etc, into their modified root and pack it up and flash my box with this new root..?

Is there any chance of you detailing what changes (binaries and scripts) you've made to the linux system? (Was going to look on hummypkg.org.uk but that's not responding!)
 
Yes and Yes, that's right. Just load on an updated root, nothing else. The root (on the HDR although not the HD) also contains the humax commercial software. Leave the kernel etc. untouched with the custom update.
 
Just updated humidify to version 1.0.2.
  • Fix bug with single block file archiving;
  • Support second type of checksum (used for Fox HD hdf files).
 
Does humidify support compressed data blocks in hdf files?
(I'm getting all zeros as output for compressed data blocks)
 
matbl said:
Does humidify support compressed data blocks in hdf files?
(I'm getting all zeros as output for compressed data blocks)
Click to expand...

Yes it does. At least for the type of compression that's used for the HD[R] Fox T2 and Foxsat boxes.
 
Ok, thanks. Then it's no point for me to write my own util.
af123, if you have the time sometime I would be very grateful if you could look at why humidify produces all zeroes for certain blocks in the hdf-file I sent a link to.
 
When trying to extract the third part from the hdr_fox_t2 hdf, I get an error during extraction and large parts of the file is all 0xFF.
?

Code: 
$ humidify-1.0.2/humidify.exe -S3 -x hdr_fox_t2_upgrade_1.02.20.hdf 
Opening hdr_fox_t2_upgrade_1.02.20.hdf, 19129839 bytes.

  Blocks:     621
  Model:      4
  System ID:  80bc.7e00

Skipping file 1
Skipping file 2
x  3.hdfbin-3-1a00000.raw         
Checksum mismatch
  Calculated: fae4d4cdc333ddfea18272423cb87547737ea9342c2e762c55734a976ff3a7e6fae4d4cdc333ddfea18272423cb87547737ea9342c2e762c55734a976ff3a7e6
  Embedded:   8101eb4f70b4adfae246540132dcaaf24bf3972e98871cf3fd3d03ccdff2a5ed
(2097152 bytes)

Processed in: 0.20s
HDF Tool v1.0.2, by af123, 2011.
 
Do you get the same error if you extract all the files at once?
There are two different ways of calculating checksums that I've seen and one of them is cumulative using information from previous files as part of the algorithm.
 
humidify -x ../hdr_fox_t2_upgrade.hdf
HDF Tool v1.0.2, by af123, 2011.

Opening ../hdr_fox_t2_upgrade.hdf, 19129839 bytes.

Blocks: 621
Model: 4
System ID: 80bc.7e00

x 1.hdfbin-1-000000.raw (16175104 bytes)
x 2.hdfbin-1-1e00000.raw (1914254 bytes)
x 3.hdfbin-3-1a00000.raw
Checksum mismatch
Calculated: fae4d4cdc333ddfea18272423cb87547737ea9342c2e762c55734a976ff3a7e6 Calculated':5e444918da4840f343c87a8f2a412f2c6bfbdd4da524efee9c200139c759c53f
Embedded: 8101eb4f70b4adfae246540132dcaaf24bf3972e98871cf3fd3d03ccdff2a5ed
(2097152 bytes)
 
xyz321 said:
I see the same checksum error but the file was identical to the contents of the flash memory.
Click to expand...
Can you give some insight into the contents of the flash memory? I see something that looks like filenames but not much more that is usefull. A second stage bootloader and some compressed flash filesystem?
 
You must log in or register to reply here.
Back
Top