23 Jun
2015
23 Jun
'15
1:20 p.m.
On Tue, Jun 23, 2015 at 12:38:22PM -0700, Fred Cisin wrote:
We have now had conflicting "definitive"
statements ranging from
"the software simply displays a message and refuses to run", to "the
software irreparably damages the device"
What is in
the NVRAM? And how did it get there in the first place?
Are you saying that it is impossible to reprogram the device with
some other firmware after you have tried the version Elnec have
which detects your clone?
Not necessarily incompetence, but probably penny pinching. Adding a
second firmware flash and the switch to toggle between primary and
secondary and another one to actually allow writing to the firmware
flash in the first place ... you can shave a bit off the BOM. Might
not matter much if you only ever make 5 devices, but over thousands
it adds up ...
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
But unless I misunderstood things, the software merely
does a check if
the hardware looks sane, and if not it displays a message saying that
this is the wrong hardware, and it refuses to continue running.
You do misunderstand
the situation. Elnec has publicly stated that it
checks for one of the illegal clones and subsequently erases the NVRAM. It's dead, pushing up daisies, it's run
down the curtain to the Choir
Invisible. IT'S BRICKED.
"C: 'E's not pinin'! 'E's passed on! This parrot is no more! He
has
ceased to be! 'E's expired and gone to meet 'is maker!
'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't
nailed 'im to the perch 'e'd be pushing up the daisies!
'Is metabolic processes are now 'istory! 'E's off the twig!
'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down
the curtain and joined the bleedin' choir invisibile!!
THIS IS AN EX-PARROT!!"
http://www.davidpbrown.co.uk/jokes/monty-python-parrot.html
Some modern devices have been so badly designed that it becomes
possible IN SOFTWARE to erase/rewrite code that is required to boot
the device, and which is required to be able to run code needed to
"repair"/rewrite that code. Thus "brick" the device.
(about a decade ago, we had a thread that included stacking
algorithms for using dead/unwanted commodity devices as construction
materials)
Surely any competent designer will provide a way to prevent/recover
from that situation! That could consist of a physical switch or
jumper that must be manually set before the system can writeover the
NVRAM.
OR there could be a second boot ROM in the machine that could be
jumpered into place to enable booting, perhaps to a limited recovery
mode, if/when the primary boot is damaged.
OR, in worst case, the NVRAM could be socketed, and a replacement
copy could be physically installed.
YES, the part(s) could be unsoldered, and replacement soldered in.
THAT does not seem like an acceptable recovery requirement.
Why are such incompetent designers still employed in the industry?