Comment by fsflover

5 years ago

This thread is just wrong. You can modify the blobs if you need to: https://forums.puri.sm/t/does-respects-your-freedom-certific....

5 comments

fsflover

Reply
marcan_42  5 years ago

The Librem article I linked in my thread clearly states:

https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

> The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing.

The post you link to is full of wishy-washy fluff, but does not answer the direct question that the user posed in the OP, about the DDR timing code flash being writable.

  • fsflover  5 years ago

    I don't see any "wishy-washy fluff". It states quite clearly:

    we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.

    In other words, you can modify the firmware on the Wi-Fi card or modem.

    Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.

    Edit:

    > can’t be modified without the user knowing

    > without the user knowing

    Did you actually read what you quoted?

    • marcan_42  5 years ago

      > Methods to flash the firmware on the Librem 5 are outside of my area of expertise.

      That's CSO code for "I have no idea what I'm talking about, but I'm just giving you a canned response about our principles with no technical details and hoping you don't pry further and prove me wrong".

      He never explicitly addressed the RAM blob. If he knew it was flashable he would've outright said it to answer the question. But he did not.

      > Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.

      Incorrect. The code is loaded in the DDR PHY. It then runs continuously. It is required for normal operation. This is because LPDDR requires continuous runtime re-training at its higher performance modes. What only runs on boot is the (dumb as hell) code they wrote to run on the Cortex-M4 as a workaround, because the FSF's ridiculous requirements forbid you not just from running proprietary code on the main CPU, but from touching proprietary code on the main CPU.

      So Purism built code that runs on cpu A to run code they built that runs on cpu B to load a blob from external read-only memory C into cpu D, just so they could claim cpu A never got digital cooties from touching the blob.

      Please appreciate the stupidity of this entire ordeal.

      cpu B code: https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_l...

      > read only

      Means it can't be modified without the user knowing, and it also can't be modified with the user knowing.

      Unless the Librem 5 literally has a DIP switch for "enable flashing RAM code", read only means read only, period. It means the write protect pin is tied to protected, or a set-only protect bit in the SPI flash config was flipped.

      2 replies →