GEOSATpro Strange idea -- Feature on boot

[rv1pop]

Might be difficult to do with no buttons...... Some way to lock a "factory reboot" into memory that would cause a boot from USB which would restore the latest working firmware (.abs file) from a usb stick.

Might be possible to have the boot sequence check the usb for the boot file and if that USB stick is not there continue, but if it was --- ie, HardRestore.abs --- grab that file to boot and then let you update from another usb or from the satellite. Have only that file on the well marked USB or you might pop-a-rot-zee -- your brain!:rant:

 

[Conky]

somebody suggested that in another thread but it was never addressed. The Viewsat Ultra has a feature like that

 

[toucan-man]

I like it, is there a downside?

 

[SatelliteAV]

Unfortunately, this suggestion is not possible to implement. The USB is not active until the boot sequence is complete. One of the downsides of a SoC approach to hardware design.

 

[Scott Greczkowski]

Can the bootloader do some kind of checksum to make sure the data file is good and if not wipe it out to prevent the bricking issue?

 

[rv1pop]

Probably a challenge in implementing... My thought is a file that would just get everything back to a stable platform - maybe with instructions on how to recover to your last saved working list. We all save them don't we?

My first thought was for a hard coded reset, but with no buttons, not to easy to do. But now days they can write and hard code a boot sequence that looks for addresses = like a USB port. as well as the starting address for firmware.

I got an OLD ham radio that had a hard reset built in - it was one of the first computerized radios. The fellow that gave it to me had done the hard reset, but he did not have ANY copies of the software for it, so I had a boot screen. I found a ham who had software on a floppy - from a VIC-20. Fortunately I got my C-64 working and got it downloaded - then I gave it away.... Now I wish I had not. It was a 220 rig.

slow to post so edit: I suppose enabling and reading USB does take extra loading sequence time.... but just thinking. I guess USB only has 4 lines or so, which makes it harder to code a start up. I can think of parts of how we used to code branching, and we did it with 8 k or less memory. But I do not want to admit I was around that LONG AGO!

 

[SatelliteAV]

Can the bootloader do some kind of checksum to make sure the data file is good and if not wipe it out to prevent the bricking issue?

The issue is not a corrupted firmware file, but rather corrupted user file. What you are proposing would erase all user data and return the STB to a default factory default database. This could be possible, but is it acceptable to erase user data anytime the STB decides that there is an error in the file?

Yes, a few users have required a serial firmware reload to restore operation, but in comparison to the number of microHDs in operation, the error happens very rarely.

We are looking at other options...

 

[Scott Greczkowski]

The issue is not a corrupted firmware file, but rather corrupted user file. What you are proposing would erase all user data and return the STB to a default factory default database. This could be possible, but is it acceptable to erase user data anytime the STB decides that there is an error in the file?

I don't know I am torn on that one. Just not everyone is up to hot wiring their box to get it running again. So for those I say yes, but for those who are comfortable opening the box, buying a cable and clearing the bad data themselves then I say no. (Call me Mr. Indecisive)

 

[rv1pop]

BRIAN!!!! YES!! If you do save the user file regularly, then if all you have to do is roll back to the previous working one you have, then you might have a day or 2 worth of changes to redo, not everything, and not take a week or more for guys like me to get it going again. If the user file has a date in the name, as I think you said it did, then having a USB stick in place to save changes --- would not only give you a back-up but a file that would show what went wrong! And the file is small enough, it should not lessen your recording space.

 

[rv1pop]

And, rethinking, if the only time it disabled / deleted the user file is after it rebooted two or three times - counting loops is easy - then it is a reasonable rescue.

 

[SatelliteAV]

And, rethinking, if the only time it disabled / deleted the user file is after it rebooted two or three times - counting loops is easy - then it is a reasonable rescue.

The SoC is pre-programmed for a specific boot sequence and it is not capable of counting reboot attempts. If it failed to reboot a sequence could be enabled to delete the user data as the final step. Next attempt at a boot would then find only a default database with no user data.

To me, this is a very extreme proposal for a issue that rarely happens. I see a very real possibility of having more upset users who have their user data deleted (without option of recovery) than the few users who have had to restore via a serial connection. At least with the serial recovery the user has an option to save and recover their user data.

 

[primestar31]

Why not just include the serial recovery cable with every receiver? After all, they only cost a couple dollars from China, which probably means they are really only pennies to produce.

Even if the receiver price had to go up a few dollars for this, it might be worth it as the simplest solution of all. Of course, that supposes that Brian doesn't have a more elegant solution he's thought of already.

I really do NOT like the idea of some sort of automated boot solution that has a chance of wiping out my receiver. I think that has far to much chance of causing issues in yet another way.

 

[SatelliteAV]

As I suggested in another thread, there is no need to include an item that 99.9% of users will never need or use. The average FTA viewer will never need the USB/TTL serial cable. An advanced hobbyist might wish to directly load data files or recover a receiver, but this has already shown to be a rare occurrence. Hacker boxes had included a serial cable because it was originally the only way that the end user could enable theft of service and generate more STB sales for the reseller.

Like the Amateur radio hobbyists, we also might want to do something that the casual user may not have desire or interest or ability. If an advanced microHD user ever needs a serial cable, they are available from wallyhts web cart for $15. I applaud and endorse his initiative and solution. Would love to see other 3rd party exploration and development on the microHD platform!

 

[tekjunkie02]

user ever needs a serial cable, they are available from wallyhts web cart for $15. I applaud and endorse his initiative and solution. Would love to see other 3rd party exploration and development on the microHD platform!

Is the firmware and programming Open Source? Is the source code available? How about a schematic for the system, and Datasheet(s) for the chipset?

How about moving/extending that socket on the circuit board out to the back panel so that the user doesn't need to expose the entire system board, maybe put it behind an access panel so that it's not exposed without some deliberate action by the user?

I'm fine with it as is, but just throwing out thoughts for you.

 

[SatelliteAV]

Not open source and development and SDK are secured by confidentiality agreements. There are some limited ALI datasheets publicly available.

The location of the TTL connection should not be an issue for an advanced user or anyone competent with computer hardware. If a user is uncomfortable with recovering a unit, they can simply pay postage and our RMA repair department will recover it under warranty. Removing two screws and lifting the case cover will not void the unit warranty and will not expose the user to any dangerous voltages or radiation. If a user wishes to add an external case connection, it is easily accomplished, but for what reason?

Let's put this into perspective. Several thousand microHDs have been sold and less than 8 receivers have been returned due to no boot or cycling boot (the reports on this forum that may or may not be included in these returns). A total of 11 microHD returns for all problems combined. This percentage is lower than any STB that we have ever distributed during the past 10+ years. Where other brands and distributors issues are kept hushed and privately requested to be returned for repair, we openly address the few issues and have provided a self-fix for those hobbyists that are interested in recovering their own receiver.

We continue to work on developing a simplified recovery solution that does not natively exist on any STi, M-star, Novatek, ALI or any other current STB SoC.

 

[digiblur]

Always an after thought and maybe the chipset didn't offer an pin to short, but it would have been cool if it was like your typical home router. Take a paper clip to the reset button and boom, factory default on a boot looped unit.

 

[chaskuchar]

i don't think supplying the extra cable with a microhd is a good idea. it would create more problems that it solved. i like to try all options when i get a new piece of gear. that includes trying all options... and getting into trouble. charlie

 

[mucketbucket]

I can't speak for anyone else but I would much rather the mhd restore default settings on boot failure than me have to install a ttl cable and try to fix it myself or have to send it back for repairs. If I could save my user file to usb as I go and restore it after the boot resets to default settings.

 

[ihenry]

Speaking from first hand experience, I second mucketbucket's suggestion.

Cheers, iHenry

 

[Bongu]

I recall my Viewsat has an option to boot from USB and reload from USB if things were to go really wrong with the receiver. If I recall correctly, you had to hold a front panel button down while cycling power to enable this mode. Lacking a front panel button on the MHD kind of makes this type of option really hard to set up. The chipset needs some way to receive an interrupt to enable a mode like this and the only input on the MHD is via IR remote control and not available until the firmware is fully booted. This is not a flaw in my opinion. The ttl cable is probably the most elegant solution to this rare problem.

Sent from my Timex Sinclair using SatelliteGuys