• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

FOXSAT-HDR locked up

L

lolo_UK2944

New Member
Hi,

I tried flashing a foxsat HDR with a custom kernel that I had built and I am now left with a bricked box !

I started off building the kernel that I downloaded from the HUMAX website to which I added the support for printk. I then compressed it into a file named "1.hdfbin-1-100000.raw" and packed it into an HDF file. The long term idea was to play around with the kernel and eventually adding support for a wifi dongle I have at home.

I then flashed the FOXSAT-HDR the usual way except that it never rebooted properly :-(. It now displays a blank but lit up screen at start-up and there seem to be no way for me to re-flash it with a known good firmware like Raydon's one (what I used to run). I can hear the hard drive powering-up.

My best guess is that the kernel I have built was either not compiled or not compressed properly, but it could be something else. I had not anticipated that an incorrect kernel would lock the box up.

As an attempt to reprogram it manually (and to satisfy my own curiosity), I have started to look at the JTAG port. I have been partly successfull with that, I can successfully detect the BCM7403 in the JTAG chain but I have not got enough information to read/write into the NAND Flash yet. I thought I would post now get people's thoughts before I go any further.

I would first be very interested in getting it up and running again so I would appreciate if someone has any suggestion. secondly, I would also like to understand the boot process as well as the flashing process used internally.
 
Do you know if your .hdf file was definitely set to load the kernel into the right location in flash? How did you build it?
 
From what I have read on various forums, the address used to copy into flash is the one contained in the name of the raw file. Given that the name of the raw file was correct, I believe the kernel should have been loaded in the right place.

One thing I have not paid too much attention to is the version of the gzip utility I have used to compress the kernel image. I am not sure whether this is important or not.

in terms of the kernel build, the plan was to start with small steps so I have used the kernel sources from the humax website, with the config file they supply* and the cross compilation tools they also supply.
* I simply turned on the kernel messages (printk) ON as mentioned earlier before I compiled it.
 
Have you actually tried to reflash with a known good .hdf ? If not then it is definitely worth a try before assuming you have bricked it. Power off at the back before plugging in your USB stick then while holding down the front power button switch it back on.
 
Yes I tried that and it does not seem to do anything. Nothing on the TV or the front panel display.
When flashing with the normal procedure, we are supposed to start from standby mode, I can not access that mode. The red Light at the front does not turn ON either.

Does the foxsat hdr rely on linux running to write into flash or is there a utility that is independant from the kernel and the fs ?
 
lolo_UK2944 said:
Yes I tried that and it does not seem to do anything. Nothing on the TV or the front panel display.
When flashing with the normal procedure, we are supposed to start from standby mode, I can not access that mode. The red Light at the front does not turn ON either.

Does the foxsat hdr rely on linux running to write into flash or is there a utility that is independant from the kernel and the fs ?
Click to expand...
No, it depends on the loader code which is in flash ROM also. I have an hdf somewhere with the loader on it that you can try but it will be tomorrow before I can dig it out. BTW, reflashing from full power off does work or I wouldn't have suggested it.
 
Last edited:
raydon said:
No, it depends on the loader code which is in flash ROM also. I have an hdf somewhere with the loader on it that you can try but it will be tomorrow before I can dig it out. BTW, reflashing from full power off does work or I wouldn't have suggested it.
Click to expand...

OK that's great thank you. I tried flashing it again from power off but with a second USB stick to rule that out and no luck.
 
Black Hole said:
It's easy to be wise after the event, but it's a shame you didn't post before you got as far as you did.
Click to expand...

You are absolutely right, that will teach me a lesson !
At least I hope at will at some point understand what I did wrong in the first place. I am not sure at all how I ended up not even having the loader code running...
 
lolo_UK2944 said:
From what I have read on various forums, the address used to copy into flash is the one contained in the name of the raw file. Given that the name of the raw file was correct, I believe the kernel should have been loaded in the right place.
Click to expand...
It depends on how you built the.hdf. Some tools will derive the addresses from the name of the input file but not all. How did you build it?
 
Here's the loader hdf as promised. If you succeed in flashing this then you should be able to flash a standard hdf immediately afterwards.
FYI: I always use the Windows version of af123's 'humidify'utility to build my hdf's with the following command:
humidify -c FOXSAT-HDR_upgrade.hdf 3768.0000 1.hdfbin-1-100000.raw 2.hdfbin-1-300000.raw 3.hdfbin-1-400000.raw 4.hdfbin-1-600000.raw 5.hdfbin-3-c00000.raw
For a kernel only hdf the command would be:
humidify -c FOXSAT-HDR_upgrade.hdf 3768.0000 1.hdfbin-1-100000.raw
For compressing the kernel I use gzip v1.3.12 with the command gzip -9c vmlinux > 1.hdfbin-1-100000.raw
 

Attachments

af123 said:
It depends on how you built the.hdf. Some tools will derive the addresses from the name of the input file but not all. How did you build it?
Click to expand...

The command line I have used to create the HDF is as follows :
# humidify-linux-i386 -c FOXSAT-HDR_upgrade.hdf 3768.0000 1.hdfbin-1-100000.raw
As you can see from the command line above I have used the Linux version. The version of humidify I used is 1.0.2, extract from the readme : "HDF Tool v1.0.2, by af123, 2011."
NOTE. Before I created the actual HDF file, I actually tried to unpack the raw files from Raydon's firmware revision 4.0.8 and repack them into an HDF with the command line above. I then did a diff and they were identical, so this is how I gained confidence I was using the tool properly.

To compress the kernel, I have used the following command :
# gzip -9c vmlinux > 1.hdfbin-1-100000.raw
The version of gzip I am using is 1.6.

Executing file on the compiled kernel gives me :
# file vmlinux
vmlinux: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, not stripped

I hope it looks sensible ...
 
lolo_UK2944 said:
I hope it looks sensible ...
Click to expand...
Yes, humidify will have set the load address correctly based on the file-name of the .raw file.
Can you post the output of 'humidify FOXSAT-HDR_upgrade.hdf'? That will show the addresses and sizes.
 
raydon said:
Here's the loader hdf as promised. If you succeed in flashing this then you should be able to flash a standard hdf immediately afterwards.
FYI: I always use the Windows version of af123's 'humidify'utility to build my hdf's with the following command:
humidify -c FOXSAT-HDR_upgrade.hdf 3768.0000 1.hdfbin-1-100000.raw 2.hdfbin-1-300000.raw 3.hdfbin-1-400000.raw 4.hdfbin-1-600000.raw 5.hdfbin-3-c00000.raw
For a kernel only hdf the command would be:
humidify -c FOXSAT-HDR_upgrade.hdf 3768.0000 1.hdfbin-1-100000.raw
For compressing the kernel I use gzip v1.3.12 with the command gzip -9c vmlinux > 1.hdfbin-1-100000.raw
Click to expand...

Thanks for the command lines above, what I used seems to be very similar, the version of gzip I used is different though.

I tried tonight to put the loader in and unfortunately I am not getting anything either. I tried the following without success, the front panel display backlight is ON but I have nothing being displayed.
  • Tried to flash the loader 7.54 with my usual 1GB stick.
  • Tried to flash the loader with 2 other sticks, a 1GB and a 2GB. One of them was formatted on a Windows system and has got a light. It normally flashes when being accessed and the light remains OFF.
  • I took the HUMAX cover off to ensure the from panel buttons and USB were not disconnected/damaged.
  • I tried the USB at the back just in case.
I am afraid none of the above seems to bring it back to life ...
Have you come across this problem before, not having anything displayed on the screen at all ?

Thanks for your help.
 
af123 said:
Yes, humidify will have set the load address correctly based on the file-name of the .raw file.
Can you post the output of 'humidify FOXSAT-HDR_upgrade.hdf'? That will show the addresses and sizes.
Click to expand...

Running humidify onto the file I generated yields :

HDF Tool v1.0.2, by af123, 2011.

Opening FOXSAT-HDR_upgrade.hdf, 1634059 bytes.

Blocks: 51
Model: 4
System ID: 3768.0000

File Offset Address Type Flags Size Uncompressed Size
---- ------ ------- ---- ----- ---- -----------------
1 0000014 0100000 1 0x80 1633395 1635938 (0.16%)
 
Hi,


Thanks all for your help so far.


I am still trying to get my HUMAX to talk somehow … no.. I have not given up yet. Although none of the things below have worked I thought I would let everybody know what I have done so far.
It may help someone or give someone some bright ideas.

JTAG.

I have converted a raspberry pi into a JTAG controller and I am using openocd. I had to fit a header on the PCB as the JTAG header is not fitted at manufacture by default.
The JTAG connector is fairly easy to locate and the pinout seems to be pretty standard. One thing to note is that the access to both TRST and SRST is given.

I can successfully scan the chain and I detect the BCM97403 as being the only device on the chain. I can’t go any further than that unfortunately. Any JTAG command I send to the processor does not seem to processed as expected.
The JTAG bus may possibly be locked at manufacture !
I could also see from a schematic based on the BCM97405 that this family of microcontrollers have a couple of pins to select between Boundary scan, JTAG or eJTAG. I have not managed to identify where those GPIOs are in the FOXSAT-HDR. I have been looking for pull-ups and pull-downs without success.

BBS.

This is another bus which could potentially allow me to re-program my flash. There is a header fitted which has 4 pins. It could be a RS232 or a BBS, I can’t ascertain either way. The pins on this header do not change levels at any time after power up or SRST release.
If it is BBS, I have no chance to be able to use it anyway as I do not have access to the Broadcom utility with BCM97403 support to do BBS.


RS232.

I scope probed other headers that are not fitted on the PCB to see if there was any RS232 coming out (just in case my CFE is running and transmitting) and I was unsuccessful so far.


Physical Flash.

It crossed my mind to take the FLASH chip off the board. Unfortunately it is probably going to write the box off :
The flash is an 8x8 BGA with a pitch of 1mm. I am confident I could take the device off with a specialist tool but I am never going to be able to connect it to a programmer given it is a BGA.
If I had a scrapped foxsat-HDR and as a last call, I would attempt to swap the flash but even this is risky !

Potentially Interesting findings :

USB.

The USB port at the front of my FOXSAT-HDR does not even get powered, the 5V does not come through.
I identified that there is a device that acts as a diode which is in charge of powering up the USB. This device has a couple of ENABLE pins which are not being driven at all by the processor on my box.
As a result, I know now that there is no way that I can restore the flash with a normal USB stick procedure.

Does anybody know what piece of code initialises the USB in the HUMAX. Because mine does not initialise, it may help me to find out where the software gets stuck (I hope I still have cfe running)

Ethernet lights

I noticed that the Ethernet lights at the back come on. On they do not seem to be one straight after power up. This may suggest they are turned on by some software.

Next steps…

  • I am planning to try to connect a USB to RS232 cable on the back USB to find out if by any chance the CFE will output any data on it. I read on some forums that the CFE would have drivers for FTDI cables.
  • I am also planning to try to connect to the ETHERNET as the CFE code may initialise and use the Ethernet.
I will keep you posted of my progress whether I make any or not. In the meantime I am still open to suggestions.
This is it for now, I hope it makes sense to someone.
 
Black Hole said:
How about just scanning eBay for a replacement? Not that I don't admire your efforts so far!
Click to expand...

Hi Black Hole,

Well ... as a matter of fact I have already ordered a replacement a few days ago which is going to be a Xtrend ET10000, but I figured I could still try to get that one back !
It is not uninteresting to try to fix it, quite a nice challenge in fact ;).

Not having schematics and just partial source code makes it a bit of a walk in the dark though.
 
You must log in or register to reply here.
Back
Top