[RANT] EX-PARROT (Was:False Beeprog. AGAIN.
Alexander Schreiber
als at thangorodrim.ch
Tue Jun 23 15:20:11 CDT 2015
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"
>
> >>>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.
> >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?
>
> >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?
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
More information about the cctalk
mailing list