The script gives only the first option, the rest do nothing when selected, and it is indicated that the WP is on for each, so it follows the WP is still on and preventing those options from being executed. I’m perplexed what the screw at the bottom of the chromebook covered with a silver sticker was for after all if it was not the WP screw. What did I remove?
it also links to a page that tells you to boot with the internal battery disconnected in order to temporarily disable WP. I don’t know how this isn’t clear.
as explained in the script instructions
a screw that has nothing to do with firmware WP
This is where I got the idea, I’m literate and your instructions are not THAT well written (much of it is good, please understand). Internal flashing is not possible if you have to OPEN the case of the chromebook with a screw driver, removing several screws, to remove the battery to turn off WP. Internal flashing, means not having to physically disassemble the device and alter any component contained therein to flash new firmware. While I didn’t have to desolder a chip and replace it, or use a chip programmer clip on the component, it’s still not flashing done exclusively through the devices software without modification of the hardware (see 1vyrain for haswell).
Not nothing. Perhaps other chromebook models allow you to remove the battery without opening the computer case but this one requires just that, and after removing eleven screws placed on the bottom of this cenobite torture box to boot!
you are inventing a definition for internal flashing which is contrary to that used by the community at large. Internal flashing means flashing on the device itself, while powered on, without the use of another device (eg, flashrom -p internal). The fact that you may have to open the device, remove a screw, solder a jumper, etc has no bearing on it at all. External flashing means using an external device for reprogramming (SuzyQ, RPI, ch341a, etc). The definitions are quite clear and unambiguous.
you’re being pedantic, of course you have to remove multiple screws in order to access the battery to disconnect it. The screws themselves, nor any on the mainboard, have no bearing on the firmware WP for that model (or any which have the battery sense line tied to firmware WP).
I welcome any additions/corrections/clarifications to the documentation on my site.
Keep in mind the above, as you were the one who felt the need to make a wide sweeping claim that all ChromeOS devices could be internally flashed, despite this being somewhat of a non sequitur and possibly inaccurate.
I have provided you enough context clues, and explicitly stated other pieces of information which should make it apparent that I am attempting to flash the UEFI firmware ROM to this device, it’s not clear what would help you further in diagnosing the information I lacked to complete the flashing of the UEFI firmware rom to this chromebook, even if we accepted the incorrect sentiment and attitude you ascribed to me: that I didn’t think internal flashing was available
but what’s worse is that it is literally the opposite of what I wrote
Now it’s clear you didn’t seem to think so at the time but consider the following
No, I’m not. See the coreboot official docs quoted and linked below.
Updating the firmware is possible using the internal method, where the updates happen from a running system, or using the external method, where the system is in a shut down state and an external programmer is attached to write into the flash IC.
https://doc.coreboot.org/tutorial/flashing_firmware/index.html
So per their definition presented here, it is “a” running system, not “the” system being updated necessarily. So that’s one thing, but this implies further that another system is not explicitly precluded, or “forbidden”, from internally flashing another distinct device under this definition.
And in fact, you can find many bios, uefi, and firmware modding communities who will corroborate that flashing a device’s firmware from another device is internal flashing, and regardless of whether the flashed device is on or off, as it is contextual.
For example, see openwrt router firmware flashing, which in some cases require a separate device hosting a tftp server to be connected to a powered off router, which before entering a fully powered “on” state, sends a bootp packet to retrieve the rom to flash the device over RJ45 ethernet.
Your definition doesn’t appear compatible with the definition provided by the coreboot docs, nor similar communities like the openwrt/ddwrt community and their way of employing terms for internal flashing and firmware flashing.
Internal flashing means flashing on the device itself, while powered on, without the use of another device (eg,
flashrom -p internal).
This definition explicitly places the condition that internal flashing requires the device being flashed is powered on, then further places a second condition: without the use of a second device. Neither of which is contained in the coreboot doc definition.
Worth noting, Power states like S0 S1 S2 S3 S4 S5 seem to be glossed over in this “powered on” requirement of your definition as well, and adds to the arbitrariness and nitpicky vibe of the inclusion of this requirement in your derivation, but it perhaps there is something of value to it which I am not aware.
Regardless of the powered on state being a legitimate criteria, at the very least, using the web UI firmware flashing tool or ssh server hosted on the router to push firmware updates to routers from your computer, as in the aforementioned case with DD-WRT/OpenWRT still requires a second device to internally flash them.
This is not some peculiarity of embedded linux firmware flashing, not that that should matter as arm and intel routers and modems running linux and firmware for those architectures are not specially distinct outside of not necessarily running on devices with built in monitors or ports for monitors, but if we further set aside the aforementioned embedded linux devices, and focus on laptops, tablets, desktops, rack mounted servers and rack mounted switches, there are also cases of internal flashing which match the definition I’ve presented from the coreboot docs here and cannot match your definition.
Supermicro desktop mobos and rack mounted servers can be internally flashed with coreboot over IMPI and BMC using another computer.
Android and iPad tablets can be internally flashed firmware via another device.
Thinkpads, Dell laptops, and apple macbooks can be internally flashed with coreboot using a PXE server.
All of these can be done without ever having to open up a device’s casing, unscrew anything, or even remove it’s battery (and in many cases these batteries do not require anything more than a simple pushing of a button or sliding of one to eject/remove) and in fact I have yet to come across anything which can be “internally flashed” which required disassembly of any sort, except devices which can only be flashed internally once flashed externally and devices which used specific pin shorting (which meets one of coreboot’s criteria for the definition of external flashing but not the other because it doesn’t require an external programmer attached to write into the flash IC), but inevitably had already developed ways of internally flashing without opening the device in anyway.
Ultimately your definition appears “made up” according to your standards, as it is not the definition of coreboot’s presented in the doc here, and not the definition used by any similar coreboot and firmware communities. To your credit it is in fact your definition though, and I surmise it is bore out of your experiences working to establish and maintain the mrchromebox project and has merits from wisdom attained in doing so.
Fortunately, I happen to be of the opinion that language is highly contextual and based in inter-subjective consensus, and that false consensus (plural) based in miscommunications are ubiquitous and more often unrealized than not in any given community.
Better to be patient in communicating with others and proactive in ascertaining the way a community uses terminology, than declare your definition(s) the correct one, regardless of the realities which were foregone in such a declaration. Meet them where their language is as best as you are able, while still conveying what is integral and critical, faithfully. Those who are worthwhile will reciprocate.
JFC, I can’t even.
AMPTON/NOSPIKE can be internally flashed after disabling firmware WP (which for them means disconnecting the battery or disabling via a suzyQ cable), a step whose method(s) are completely separate from the flashing.
1 Like
Okay fair. I opened up the chromebook, disconnected the battery and managed to flash the UEFI firmware, but the script still shows the WP being on for option 1 despite the option functioning and the WP display reading “disabled”. Attempted to use flashrom to take a full dump, but the intel me is still WP as well. Any chance you know how to flip the HAP bit?
per the script docs, the menu items will show WP next to them if WP is required to be disabled in order to perform them. The WP text is colored red when enabled and green when disabled. the text in the header indicates WP status in case the colors are not clear (ie, different terminal theme)
the ME not be readable or writable has nothing to do with firmware WP - read/write access to the different flash regions (on intel devices) is controlled by the soft straps set in the IFD (intel flash descriptor, the first 4kb of the flash chip). By default, the IFD is readable only, the ME is not readable (or writable), and the bios is readable (and write is controlled by the flash protection registers / WP).
This is why on intel devices the script only reads/writes the bios region (or sub-regions thereof).
coreboot’s ifdtool can do this on supported platforms (as the HAP bit is in the IFD region), but you can only write the IFD using an external programmer (unless the IFD has previously been unlocked, using ifdtool, and written using an external programmer)
1 Like
Thank you for sharing your insights.
1 Like