1. Forum
  2. FidoNet
  3. sci.electronics.design

  • "No update" FLASH

    From Don Y@3:633/10 to All on Tuesday, September 15, 2026 08:27:51
    My design executes entirely out of RAM, fetching the binary at IPL
    (so the "boot rom" has fixed/unevolving responsibilities -- get it
    right first time)

    I am strongly tempted to *prohibit* updates to it after deployment
    as that just seems like another opportunity for feeping creaturism
    and the potential for bricking devices (though, for the life of me,
    I can't see how FLASH updates should *ever* be capable of that
    sort of outcome, if designed properly!)

    Are there any reasons I might *want* to leave that door open?

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From john larkin@3:633/10 to All on Tuesday, September 15, 2026 12:00:15
    On Tue, 15 Sep 2026 08:27:51 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

    My design executes entirely out of RAM, fetching the binary at IPL
    (so the "boot rom" has fixed/unevolving responsibilities -- get it
    right first time)

    I am strongly tempted to *prohibit* updates to it after deployment
    as that just seems like another opportunity for feeping creaturism
    and the potential for bricking devices (though, for the life of me,
    I can't see how FLASH updates should *ever* be capable of that
    sort of outcome, if designed properly!)

    Are there any reasons I might *want* to leave that door open?

    What CPU?

    We use the RP2040 in a new product line, with a giant flash for the
    programs (dual CPUs) and for the FPGA config.

    The Pi cpu has wonderful provisions for field code upgrades. It can't
    be bricked. So we can fix bugs or add features safely and easily, by
    email.


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)