[flashrom] Re: Asus Z87-A
Hi Sami, On Sat, Oct 15, 2022 at 7:44 PM Sami via flashrom wrote: > > Is there anything I can do anymore? See in-line messages. > // Sami > > flashrom --programmer internal --ifd -i bios --noverify-all -w Z87A.bin > flashrom v1.2 on Linux 5.10.0-18-amd64 (x86_64) > flashrom is free software, get the source code at https://flashrom.org > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > Found chipset "Intel Z87". > Enabling flash write... Warning: BIOS region SMM protection is enabled! > Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed. > New value is 0x2a. This means your mainboard's BIOS/UEFI firmware restricts write access to the flash chip. Enabling writes failed. > SPI Configuration is locked down. > FREG0: Flash Descriptor region (0x-0x0fff) is read-only. > FREG2: Management Engine region (0x1000-0x0017) is locked. > Not all flash regions are freely accessible by flashrom. This is most > likely > due to an active ME. Please see https://flashrom.org/ME for details. > At least some flash regions are read protected. You have to use a flash > layout and include only accessible regions. For write operations, you'll > additionally need the --noverify-all switch. See manpage for more > details. This means some part of the flash chip (the ME region) cannot be read. > OK. > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical > address 0xff80. > Reading ich descriptor... done. > Using region: "bios". > Reading old flash chip contents... done. > Erasing and writing flash chip... Transaction error! > spi_write_cmd failed during command execution at address 0x18 > Reading current flash chip contents... done. Looking for another erase > function. > spi_write_cmd failed during command execution at address 0x18 > Reading current flash chip contents... done. Looking for another erase > function. > spi_write_cmd failed during command execution at address 0x18 > Reading current flash chip contents... done. Looking for another erase > function. > Transaction error! > Can't read! Aborting. This is because the ME region is not readable. Why flashrom still tries to read it anyway is rather puzzling. > FAILED! > Uh oh. Erase/write failed. > Your flash chip is in an unknown state. This is because flashrom could not read the ME region, and could not check whether the flash chip contents have changed. However, we know that SMM BIOS write protection is enabled, which prevents flashrom from writing to the flash chip. So, flashrom couldn't have modified the flash chip contents. > Get help on IRC at chat.freenode.net (channel #flashrom) or > mail flashrom@flashrom.org with the subject "FAILED: "! > --- > DO NOT REBOOT OR POWEROFF! Based on the reasonings given earlier, it should be safe to reboot because flashrom couldn't have possibly changed the flash chip contents. > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Asus Z87-A
Is there anything I can do anymore? // Sami flashrom --programmer internal --ifd -i bios --noverify-all -w Z87A.bin flashrom v1.2 on Linux 5.10.0-18-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found chipset "Intel Z87". Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed. New value is 0x2a. SPI Configuration is locked down. FREG0: Flash Descriptor region (0x-0x0fff) is read-only. FREG2: Management Engine region (0x1000-0x0017) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address 0xff80. Reading ich descriptor... done. Using region: "bios". Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error! spi_write_cmd failed during command execution at address 0x18 Reading current flash chip contents... done. Looking for another erase function. spi_write_cmd failed during command execution at address 0x18 Reading current flash chip contents... done. Looking for another erase function. spi_write_cmd failed during command execution at address 0x18 Reading current flash chip contents... done. Looking for another erase function. Transaction error! Can't read! Aborting. FAILED! Uh oh. Erase/write failed. Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom@flashrom.org with the subject "FAILED: "! --- DO NOT REBOOT OR POWEROFF! ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] [PATCH] Add support for XMC XM25QH128A. Read/write tested.
Signed-off-by: Stijn Segers
---
flashchips.c | 49
include/flashchips.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/flashchips.c b/flashchips.c
index 47a37ee..e3fd368 100644
--- a/flashchips.c
+++ b/flashchips.c
@@ -19707,6 +19707,55 @@ const struct flashchip flashchips[] = {
.voltage= {1650, 1950},
},
+ {
+ .vendor = "XMC",
+ .name = "XM25QH128A",
+ .bustype= BUS_SPI,
+ .manufacture_id = ST_ID,
+ .model_id = XMC_XM25QH128A,
+ .total_size = 16384,
+ .page_size = 256,
+ .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI
| FEATURE_WRSR2,
+ .tested = TEST_OK_PREW,
+ .probe = probe_spi_rdid,
+ .probe_timing = TIMING_ZERO,
+ .block_erasers =
+ {
+ {
+ .eraseblocks = { {4 * 1024, 4096} },
+ .block_erase = spi_block_erase_20,
+ }, {
+ .eraseblocks = { {32 * 1024, 512} },
+ .block_erase = spi_block_erase_52,
+ }, {
+ .eraseblocks = { {64 * 1024, 256} },
+ .block_erase = spi_block_erase_d8,
+ }, {
+ .eraseblocks = { {16 * 1024 * 1024, 1} },
+ .block_erase = spi_block_erase_60,
+ }, {
+ .eraseblocks = { {16 * 1024 * 1024, 1} },
+ .block_erase = spi_block_erase_c7,
+ }
+ },
+ .printlock = spi_prettyprint_status_register_plain,
+ .unlock = spi_disable_blockprotect,
+ .write = spi_chip_write_256,
+ .read = spi_chip_read,
+ .voltage= {2700, 3600},
+ .reg_bits =
+ {
+ .srp= {STATUS1, 7, RW},
+ .srl= {STATUS2, 0, RW},
+ .bp = {{STATUS1, 2, RW}, {STATUS1, 3, RW},
{STATUS1, 4, RW}},
+ .tb = {STATUS1, 5, RW},
+ .sec= {STATUS1, 6, RW},
+ .cmp= {STATUS2, 6, RW},
+ },
+ .decode_range = decode_range_spi25,
+ },
+
+
{
.vendor = "XMC",
.name = "XM25QH128C",
diff --git a/include/flashchips.h b/include/flashchips.h
index 5df42dc..8317da7 100644
--- a/include/flashchips.h
+++ b/include/flashchips.h
@@ -818,6 +818,7 @@
#define ST_M45PE16 0x4015
#define XMC_XM25QH64C 0x4017
#define XMC_XM25QU64C 0x4117
+#define XMC_XM25QH128A 0x7018
#define XMC_XM25QH128C 0x4018
#define XMC_XM25QU128C 0x4118
#define XMC_XM25QH256C 0x4019
--
2.36.1
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: master state / potential release
Hi all, On 14.10.22 03:53, Anastasia Klimchuk wrote: > A quick answer first: > We are closer to the release, and the state of the master is better > than a half year ago. hmmm, I may not have made myself clear with my question. I didn't mean to ask for an overall state but wrt. stability (iow. absence of code flaws) in particular. And if/how we can trust that there are no or few enough flaws. > More details. > In general, the progress is visible here > https://ticket.coreboot.org/issues/353 Yes, this is the progress of tickets. But how to put this... I know the state as far as we measure it. What I'm concerned about is what we don't measure. Maybe this helps to understand the idea of the release process better: In the Development Guidelines[1] it says "Branching for a new release can happen at any point in time when a commit (branch point) on master seems to be in good shape and was reasonably tested after previous invasive changes." The last part tries to protect us from very new regressions / issues that nobody found (measured) yet. And this was written in a time when flashrom builds from the master branch were much more tested. We could tell people that it's safe to use the master branch (which it isn't anymore). And even the people who used releases implicitly tested a state of the code for us that was much closer to master. Also, what led to the long list in #353 was a development process that created issues faster than they were fixed. Many of the issues were only made visible by a re-review. Can we say that the ratio of creating and fixing issues is more balanced now? How can we trust that if we'd re-review again, we wouldn't end up with an even longer list? > > There is one issue that came up around May > https://ticket.coreboot.org/issues/390 . This one is new. It does not > prevent from using any functionality, and also if the user does not > specify `--progress` they won’t even notice. Can the latter be proved? I'd say yes, but it seems like more effort then re-writing the whole patch. I never fully reviewed the patch but in the few places I looked into I saw wrong calculations and overflows. And those run independently from the `--progress` switch. And please remember we are talking about C code. To say that it doesn't affect existing functionality would require a proof of defined behavior. Because if there is undefined behavior, flashrom could just crash. Also worth to remember: flashrom often runs with root privileges. So every coding mistake is a security issue unless we can prove that it isn't. > Lots of code improvements: for example we have way less global state > than it used to be 1/2yr ago, and we have more unit tests of all > types. > The former is in the category of "invasive changes" that I'd like to avoid before a release. I see a lot of refactorings in the name of less global state. IMO that's a nice long-term goal, but shouldn't stall the project. Just very recently, there was a patch train that unnecessarily introduced a lot of NULL pointers (I commented how to do it without and that we'd have to be careful otherwise). Things were merged (without being careful), reverted, fixed up (I warned about NULL pointers again), merged again (again without looking for NULL pointers left), fixed up again. How can we know now that it's settled? How to trust such a development process? (This case might actually be why I started to wonder how the measured progress relates to the actual progress on the master branch.) > > If you ask me to pick what’s very important to fix I would say > https://ticket.coreboot.org/issues/370 I remember several patches on > that, from different people. Potentially, the bug is [technically] > fixed, but we need to coordinate who is rebasing on the top of whom, > and complete the review. The story is much more complex. Every time somebody looks into it, more even older issues pop up. I'd say revert to the state of the last release, and then after a new release, fix remaining issues and only then add new things and the refactorings again. IMO this driver was patched to a dead end, or at least a state where the easiest way for- ward is to go a few steps back first. Last time Edward drew attention to it, I really tried to find a solution. But even comparing the state right after the problematic patch to the current state was too frus- trating: Due to all the refactorings I couldn't see (within reasonable time) what changed in terms of functionality. Maybe we should have a rule for this? "If there are any known issues within a file or area of the code, no refactoring must take place until they are fixed."? Nico [1] https://www.flashrom.org/Development_Guidelines#Release_branches_(e.g._1.0.x) ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
