[flashrom] Re: RFC: removing 1 second verification delay
Hi Anastasia, list,
On Thu, Apr 25, 2024 at 10:26 AM Anastasia Klimchuk wrote:
>
> Angel, great to see you here again! Also, you provided very useful
> information.
>
> > Did you conside making it so that only SPI programmers / flash chips
> > skip the delay? The SPI bus' strict timing leaves no room for this
> > problem to occur, so it should be safe to skip this delay. And this
> > would keep non-SPI unaffected (which is most likely what needs this
> > extra delay).
>
> This sounds interesting.
> If we check for non-SPI chips, it only adds one more line to the patch
> (if I understand your idea correctly):
>
> if (flash->chip->bustype == BUS_NONSPI)
I haven't looked into the specifics at all, but that's the idea. It
would be good to test that the delay is still executed on non-SPI
flash chips. I think `BUS_NONSPI` actually encompasses multiple buses,
so a simple equality test might not work. I would try something like
this:
/*
* Work around chips which need some time to calm down.
* Not needed for SPI flash chips because of the bus' strict timing.
*/
if (flash->chip->bustype != BUS_SPI)
programmer_delay(flashctx, 1000*1000);
[The following is a textual representation of my thought processes;
it's not particularly necessary but I felt it could be interesting]
My idea is to maintain backwards compatibility while still enabling
new features and improvements. To do this, my very general approach is
to look for "cut-off points", i.e. some criteria to differentiate
between "preserve existing behaviour to avoid regressions" and "add
new features and/or make existing stuff better", seeking to maximise
the extent of the improvements (e.g. improving SPI support in general
instead of artificially restricting the improvements to a few
chips/programmers) while also trying to minimise the chance of
regressions (which can be fatal in the case of flashrom: some LPC/FWH
flash chips are TSOP32, externally reflashing them sounds very
not-fun). Analytically solving this is most likely impossible, but for
specific cases it's possible to find a reasonably acceptable ("good
enough") balance with the usual problem-solving tools: reason (e.g.
check against specifications, test things, etc.), intuition (useful as
a heuristic to get "directions" to explore further), and communication
(e.g. this very mailing list thread).
In this case (removing the delay in the verify path), my thoughts were
(not necessarily in order):
- I feel this delay was introduced for a good reason (even though I
have no idea what the reason is), so removing it will probably break
something.
- But do we have to remove the delay for *everything*, or can we
conditionally skip it in some circumstances? This isn't a strict
yes/no scenario.
- Looks like the messages proposing this change pretty much only talk
about flashing SPI chips, maybe this delay relates to the bus somehow.
Plus, the delay was introduced a long time ago.
- The SPI bus has very strict timing requirements (emulating SPI flash
isn't easy). However, Non-SPI flash chips don't have the same
requirements (older laptop ECs used SPI flash chips, but exposed the
flash contents to the chipset over LPC).
- It's likely this delay isn't needed for SPI because of all of this,
so let's consider skipping the delay for SPI. It's what most (but not
all) people use these flashrom for these days.
- Even if some non-SPI chips don't need the delay, it's much harder to
test this. Plus, keeping the delay in there for non-SPI won't hurt.
> On Thu, Apr 25, 2024 at 7:35 AM Angel Pons wrote:
> >
> > Hi Brian, list,
> >
> > Thanks for bringing this up on the mailing list.
> >
> > On Wed, Apr 24, 2024 at 9:16 PM Brian Norris
> > wrote:
> > >
> > > Background: https://review.coreboot.org/c/flashrom/+/80807
> > >
> > > A long time ago, in the pre-git times [1], flashrom added a 1 second
> > > delay to all verification, and claimed that some chips "need some time
> > > to calm down." The commit message claims it "fixes a few reports where
> > > verify directly after erase had unpleasant side effects like
> > > corrupting flash or at least getting incorrect verify results." It
> > > provides no details of what systems, chips, or programmers were
> > > involved.
> >
> > Back then, SPI flash chips weren't as ubiquitous as they currently
> > are. This workaround is most likely for Parallel/LPC/FWH flash chips,
> > which can actually be quite weird.
> >
> > > This delay remains in the --verify path today, and IMO, it's a big
> > > waste of time. If there are truly chips that are, say, deasserting the
> > > BUSY line before they're truly finished programming ... well, we
>
[flashrom] Re: RFC: removing 1 second verification delay
Hi Brian, list, Thanks for bringing this up on the mailing list. On Wed, Apr 24, 2024 at 9:16 PM Brian Norris wrote: > > Background: https://review.coreboot.org/c/flashrom/+/80807 > > A long time ago, in the pre-git times [1], flashrom added a 1 second > delay to all verification, and claimed that some chips "need some time > to calm down." The commit message claims it "fixes a few reports where > verify directly after erase had unpleasant side effects like > corrupting flash or at least getting incorrect verify results." It > provides no details of what systems, chips, or programmers were > involved. Back then, SPI flash chips weren't as ubiquitous as they currently are. This workaround is most likely for Parallel/LPC/FWH flash chips, which can actually be quite weird. > This delay remains in the --verify path today, and IMO, it's a big > waste of time. If there are truly chips that are, say, deasserting the > BUSY line before they're truly finished programming ... well, we > should track those chips down and add targeted quirk flags for them. > We shouldn't penalize all flashrom users in all cases for all time. I agree that this delay shouldn't be unconditional. > Personally, I highly doubt that this delay is still relevant today -- > there may have been a bug in some programmer that has since been > fixed; there may have been some malfunctioning system that is no > longer in use; ... or it's possible this is still hiding a real buggy > chip somewhere out there. If we don't know for sure whether this delay is no longer needed, I wouldn't risk re-introducing issues in flashrom. > I propose: we still remove the delay. There's plenty of description in > the above Gerrit link about why, and how we can handle regressions. > (For one, it's relatively simple to split up a --verify operation into > its constituent --write/sleep/--read operations, for debugging.) > > The request: > 1. Tests: I've tested a few Chromebooks, but imagine this had to have > been some more esoteric system. Extra testing is welcome. Do Chromebooks use non-SPI flash chips? They probably don't. > 2. Thoughts: does my proposal make sense? Am I missing something obvious? Did you conside making it so that only SPI programmers / flash chips skip the delay? The SPI bus' strict timing leaves no room for this problem to occur, so it should be safe to skip this delay. And this would keep non-SPI unaffected (which is most likely what needs this extra delay). > 3. Awareness: if nothing else, this email may serve to highlight in > case we land the above patch and later hear back that there are some > sketchy --verify reports from users. I agree that awareness is important, but bear in mind that external programmers for non-SPI flash chips are increasingly rare, so recovering from a brick can be quite convoluted (e.g. having to desolder a TSOP32 flash chip to reflash it somehow). > Thanks, > Brian > > [1] The svn->git commit in question: > > commit 8ab49e72af8465d4527de2ec37b22cd44f7a1169 > Date: Wed Aug 19 13:55:34 2009 + > Disallow erase/write for known bad chips so people won't try without > a clear understanding > ___ > 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] Re: master state / potential release
Hi Richard, Maybe it's not intentional, but your email sounds rather unpleasant and very confusing. What would you like to achieve? Also, out of curiosity, did you see https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/65BNRWRTKLTMS7EDOGCN2NJYIFX5QXBV/ before writing your reply? Maybe you missed it. Perhaps you'd want to read it: the first paragraph contains information that seems to contradict some of your claims. It could be that we're talking past each other. On Tue, Oct 18, 2022 at 2:50 PM Richard Hughes wrote: > > On Tue, 18 Oct 2022 at 14:22, Nico Huber wrote: > > Regressions can be much more severe though, and with the cur- > > rent development the story might look like: "sorry for the regression! > > you may have to acquire a hot-air soldering station now to fix your PC. > > I don't think that's true. The only people using flashrom at scale is > Google, Let's make sure we're on the same page, as misunderstandings have already costed the flashrom project way too much time and effort. Could you please explain what "at scale" means for you? > and they're quite certainly testing every flashrom version > with every firmware version with every hardware version before > deploying anything. Yes, Google most likely checks that flashrom works for *their* use-cases before deploying anything. > In the community the only people _really_ using > flashrom are the ones with SPI clips and screws already removed, if > we're being completely honest. Um, this is not true. There are people out there using flashrom on DOS to update their BIOS, and a significant number of users who come asking for help on IRC don't even know what a SPI clip is. Do you mean that these people are not _really_ using flashrom? Also... Doesn't fwupd use flashrom? Do all fwupd users have a SPI clip at hand, in case something goes wrong? It would be interesting to know how fwupd handles the possibility of device(s) no longer booting after a failed firmware update. > Normal people don't use flashrom in > production in any appreciable number. Hmmm, this seems to be another potential source of misunderstandings. What do you mean with "in production"? > > Because I've seen it burning out people (including > > myself) when one tries to clean up behind others, I argue against fixing > > bugs that other people introduced. > > But flashrom isn't your baby, it's not your responsibility. Advice > yes, being condescending no. Huh, why do you say so? Who do you think is responsible for flashrom, then? Whose responsibility is flashrom? > Richard. Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: master state / potential release
Hi all (again), We (Angel) just took the time to reorder the previous replies so that we can respond to them in-line. On Mon, Oct 17, 2022 at 11:34 AM Richard Hughes wrote: > > On Mon, 17 Oct 2022 at 12:24, Edward O'Callaghan wrote: > > > > On Mon, 17 Oct 2022 at 20:27, Richard Hughes wrote: > > > > > > Hi all, > > > > > > Perhaps a way forward would be to tag a rc release, ask distributors > > > to package and test it (e.g. pushing to Fedora Rawhide, but not Fedora > > > 36), and then push the actual official release a week or two later? > > > > > > Certainly aiming to do releases monthly is much healthier than doing > > > releases every few years. I think it's much more achievable to set the > > > expectation to the end user "sorry for the regression! it'll be fixed > > > in your distro in ~3 weeks, in the meantime use the previous release" > > > than trying to squash every bug and add all the features before > > > tagging a mythical beautiful bug-free "feature complete" release. We (Angel) agree that striving for a "feature complete" release is not good: in a way, it resembles maladaptive daydreaming. Having a faster-paced release cadence is a good idea, too. However, flashrom isn't the kind of project where regressions can be taken lightly, especially those which can render users' hardware unusable. It's important to not forget that flashrom's userbase is extremely wide, with users that just want to update their BIOS without having to install Windows, experienced coreboot developers, and anything in between and even out-of-bounds. Some people even use flashrom on DOS: if there's a bug that corrupts the flash chip contents, it may not be possible to get a different flashrom version without rebooting the system (in other words, they are doomed). > > > Richard. > > > > I very much like Richard's pragmatic approach here. > > > > It would be my view that we should re-evaluate branch critical bugs > > (sb600spi map issue + build system stuff are the two the most prominent in > > my mind at the moment) and just cut a release branch, stabilise that with > > some cherry-picks of any residue items. Forge forwards from that with a > > more regular cadence exactly how Richard suggests. If some critical issue > > comes up we can do a point release. Sounds good, thank you. Not sure which are the most pressing concerns, but definitely not everything currently listed in https://ticket.coreboot.org/issues/353 is required to make a release. Another option would be to make a new branch for the next (probably v1.3, but it could be something else like v1.2.1 too?) release: one could base the next release off the master branch with the potentially broken parts removed, or one could base it off the v1.2 branch and cherry-pick the most important changes from master. At first, we (Angel) were unsure which approach would be better, but the second approach sounds more appealing the more we think about it: it would allow us (the flashrom community) to calmly re-review (and possibly re-design) all the changes since the v1.2 release. It will be a *lot* of work, but it will allow us (the flashrom community) to address any concerns about review thoroughness (for lack of a better word) and settle them down once and for all. > > Kindest regards, > > Edward. > > If it helps, a monthly release seems to be the sweet spot for fwupd, > from a "writing release notes" and "getting fixes into users hands" > point of view. There's no point having a "no regressions" rule as this > is software, and even the most benign of changes can have some unknown > side effect -- it's much better to just make releases "cheap" and do > lots of them. In fwupd the main branch is always "releasable" so if we > have a high-priority fix or security issue we just merge, write > release notes, tag, push outside the usual release cadence. This is what coreboot strives for, too: coreboot's master branch is supposed to work at all times, and releases are just "glorified" commits from the master branch. The release cadence for coreboot is about 3 months (it used to be 6 months), which should also work for flashrom. However, flashrom's master branch isn't "releasable" at the moment even though it should be. > Richard Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: master state / potential release
Hi list, We (Angel) sense that this thread might potentially drift towards an unpleasant direction and we think the outcome wouldn't be forward-useful, i.e. it would make things worse. How are all of you doing? Is anyone feeling hurt? On Sat, Oct 15, 2022 at 11:53 AM Nico Huber wrote: > > 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. In order to make a release, stability (iow. absence of code flaws) is more important than having more features. So, we (Angel) would suggest prioritizing bug fixes over new features, at least to get the release done. Another option would be to branch off current master, radically deal with existing bugs (e.g. delete the problematic sb600spi code, revert the progress state patches) and use this branch for the flashrom v1.3 release. Then we can decide how to proceed for future releases without the pressure of not having done a release in a long time. > > 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. Do you have any examples of things that we do not measure? Hmmm, looks like they're explained below. > 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. In other words, it's best to submit new features and potentially breaking changes after a release. Otherwise, things in a release don't get tested properly. On the coreboot side, we had to make the 4.8.1 release because 4.8 was broken: a small patch got submitted just before the 4.8 release that broke loading several payloads, and people who tried the 4.8 release quickly noticed that it did not boot... > 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? We (Angel) found several patches with bugs after a re-review or a post-submit review in the past. Some of these bugs could have been oversights, but other bugs were too conspicuous to be accidental oversights. It felt as if those reviews (mainly those for CrOS flashrom upstreaming patches) were heavily expedited for some reason that we (Angel, and possibly the upstream flashrom community) don't know about. If anyone knows, we'd appreciate if they could help understand why things happened this way, especially if they can shed some light regarding what happened inside Google at that time. > > 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. We fully agree with Nico's view. We hadn't thought about the safety and security implications of such changes. Hmmm, maybe we should rewrite flashrom in at-least-Ada then? :D > > 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
[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] Re: Question on adding some WP documentation
Hi all, Having this documentation added to the flashrom Wiki sounds like a great idea. Thank you for the proposal! On Mon, Oct 10, 2022 at 12:11 PM Sergii Dmytruk wrote: > > Hi Anastasia, > > On Mon, Oct 10, 2022 at 01:36:38PM +1100, Anastasia Klimchuk wrote: > > I looked through the website, this section seems relevant: > > https://www.flashrom.org/Documentation#Using_flashrom ? > > Yes, I agree, It seems to be a suitable place, yes. The text can be moved elsewhere if need be in the future, anyway. > > The advantage of Documentation/ directory in the repository is that it > > allows other people (anyone who is interested) to review the text > > before adding. Because for Documentation/ you basically send a patch > > and everyone can review. End result gets submitted, and everyone is > > happy. > > Another option is to use Gerrit for the review, but then abandon the > change, convert to Wiki format and publish final result on the website. Reviewing Wiki changes on the mailing list is a reasonable option as well, especially if commenting inline. Top-posting is generally frowned upon on mailing lists (although having an introduction section before replying to specific parts is fine, see this very email). > Regards, > Sergii Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Old IRC channel
Hi Nils, On Sun, Oct 2, 2022 at 9:25 PM Nils Woeste wrote: > > Hi, I encountered an Issue with flashing a BIOS and the message says > "Get help on IRC at chat.freenode.net (channel #flashrom)" > > this points to an old server not monitored. The correct one (Libera.chat) > should also be included in the error message. They could help me there. Thanks for the notice. I personally took care of fixing this in https://review.coreboot.org/56031 a while ago. To make sure a similar problem won't happen again, flashrom executables now point to our wiki, which we can update as needed without having to wait for package maintainers. However, this was before the last release. > Version 1.2-5 We've backported my patches to the release branches (see Felix's comment), but I'm not sure if any package maintainers will update the packages. The next flashrom release is long overdue, primarily because the quality of the code in the master branch degraded too much to make a new release with. We're trying to bring the quality back again, but it takes time and effort... > Regards Nils Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Intel Kaby Lake Y w/ iHDCP2.2 Prem ERASE_FAILED
Hi, On Thu, Jul 21, 2022 at 2:23 AM J. Craft wrote: > > Let me know if there's anything else needed and what might be suggested in > this situation. *snip* > 0x84: 0x89ef09d0 PR0: Warning: 0x009d-0x009e is read-only. flashrom errors out because this region is read-only. I'm pretty sure that's the MRC cache region. You have to disable write-protect by either removing the "WP screw" or by disconnecting the internal battery, then you will be able to flash coreboot successfully. > Good, writing to the flash chip apparently didn't do anything. You can safely reboot. Best regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: [MT25QU256] Tested probe, read, write and erase through ft2232_spi programmer
Hi Charles, On Tue, Mar 8, 2022 at 2:13 PM Charles Parent wrote: > Hello, > > First thank you a lot for your amazing work on flashrom, I just discovered > this software and it saved me a lot of time lately ! > > I use it to flash a MT25QU256 through a FTDI4233H, and as software is > telling me that this chip is labelled as untested I would like to send you > the logs showing that it works indeed. > > Here are logs for both reading and writing / erasing. > > I also did varius tests, filling the EEPROM with arbitrary values and > reading back to see everything was working. > Thank you for your report. I'm going to mark the chip as tested, see https://review.coreboot.org/62664 for the change. > Please do not hesitate if you need more details ! > > Best regards, > > *Charles Parent* > > Software Engineer > > > > charles.par...@orolia2s.com > > > France, Sèvres > > 6, rue Troyon > > 92310 Sèvres > > ___ > 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] Re: atapromise
Hi, On Wed, Jan 26, 2022 at 10:06 AM Jd Lyons via flashrom wrote: > > What is the correct command to run flashrom for Promise ATA chipsets? > > Flashrom —programmer atapromise doesn’t work. The atapromise programmer isn't compiled in by default. I'm pretty sure it's because it cannot be used as a generic programmer (max flash chip size is limited by hardware), see this commit message: https://github.com/flashrom/flashrom/commit/c2644a3fc14088a2535c05edbd56c041b3a7370d If you want to use the atapromise programmer, you'll have to build flashrom from source with `make CONFIG_ATAPROMISE=yes`. > ___ > 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] Re: How to obtain a BIOS image from another computer use flashrom？
Hi, On Sun, Jan 23, 2022 at 9:49 AM Mike Banon wrote: > > Good day! The flashrom software has the "internal" mode - using which, > you may be able to access the BIOS chip directly from your OS, if your > hardware is supported. In example: > > sudo flashrom -p > internal:laptop=force_I_want_a_brick,amd_imc_force=yes -r > ./build/coreflop.rom Mike, can you please explain why you've suggested using such a dangerous command without even knowing which system it's going to be run on? The `force_I_want_a_brick` name is intentional, as flashrom can cause problems on certain laptops (most laptops from the last decade should be fine, though), c.f. https://www.flashrom.org/Laptops for a detailed explanation. And you've suggested using `amd_imc_force` even though it only applies to AMD southbridges using SPI. I know you're just trying to help, but I'm afraid that suggesting people to run dangerous commands on unknown hardware without mentioning the risks is not helpful. > I think this mode is available only on Linux (may have to boot with > "iomem=relaxed" kernel flag) - however, you may boot a Linux LiveUSB > on your target PC to use Linux without the installation in a live > mode. On x86, the internal programmer should also work on most BSDs and Darwin (macOS). It might even work on Solaris. On Linux, the `iomem=relaxed` kernel parameter can be used when a kernel module conflicts with the resources flashrom wants to use, but it reduces the system's security. On Intel systems, unloading the `lpc_ich` kernel module should allow using flashrom's internal programmer without having to boot with `iomem=relaxed`. > As for "how do I remotely obtain a BIOS image from another computer > using flashrom" - if this internal mode is available to you, and a > target PC is running Linux, you can remotely connect to this PC using > a SSH (or VPN + SSH), run the flashrom command to read a BIOS image > from a chip, and then - using scp - copy the obtained BIOS image to > your own PC > > > On Fri, Jan 21, 2022 at 3:26 AM zy <2018111...@bupt.cn> wrote: > > > > Hi， > >I'm a student from China and I've been learning flashrom，So I would like > > to know whether the flashrom can support extracting BIOS firmware images > > under Windows 7/10. > >If I don't have the Internet（Just LAN），how do I remotely obtain a BIOS > > image from another computer use flashrom？ > >Maybe my English not very well. Thank you very much. On Windows, flashrom's internal programmer is unusable. It requires libpci and raw memory access; libpci is not available on Windows as far as I know, and I think Windows restricts raw memory access from userspace code for security reasons. One could try to implement the required functionality in a driver, but one would also need to convince Microsoft to sign the driver. It could be done, but it's not easy. No one is working on this, as far as I know. > >Looking forward to your reply. > > > > > > ___ > > flashrom mailing list -- flashrom@flashrom.org > > To unsubscribe send an email to flashrom-le...@flashrom.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > ___ > 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] Re: Quanta Freedom Firmware project
Hi Billy,
On Tue, Dec 7, 2021 at 8:23 AM Billy Croan wrote:
>
> I've been tasked with updating bioses on some machines we have which have no
> manufacturer support. They were made by Quanta I think, as part of
> OpenCompute project. I have several boards that area all physically the
> same, but half of them have a different bios version, and we need them to all
> match.
>
> For testing, I took a node with the old bios version, F02_3A18, and a board
> with the new one, F02_3A20, and used -r to create a bios image.
>
> Then I used -w to write that same image back to the mobo and rebooted. No
> problem on either board...
Before writing, flashrom reads the current flash chip contents and
only rewrites the parts that have changed. I'm pretty sure flashrom
didn't write anything in your case, you can check if `Warning: Chip
content is identical to the requested image.` appears in the log.
> Then I copied the images to the opposite machine, and tried a -w, and that's
> when I saw:
> This means we have to add special support for your board, programmer or flash
> chip. Please report this on IRC at chat.freenode.net (channel #flashrom) or
> mail flashrom@flashrom.org, thanks!
Without the rest of the log, this message is meaningless. Could you
please provide a full log? You can add `-o logfile.txt` to your
flashrom command to generate a debug log file. This is the preferred
method because it ensures all flashrom output gets logged: it's common
to forget about stderr when using shell redirection.
> So, here I am.
>
> it may be worth mentioning that between the two machines, the CHIPNAME,
> referred to as such at
> https://wiki.archlinux.org/title/Flashing_BIOS_from_Linux is different.
> Here's what it shows:
>
> [root@GH-11 ~]# flashrom --programmer internal
> flashrom v1.0.1 on Linux 3.10.0-1160.49.1.el7.x86_64 (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 ICH10R".
> Enabling flash write... Warning: Setting Bios Control at 0xdc from 0x02 to
> 0x01 failed.
> New value is 0x03.
> OK.
> Found Macronix flash chip "MX25L3205(A)" (4096 kB, SPI) mapped at physical
> address 0xffc0.
> Found Macronix flash chip "MX25L3205D/MX25L3208D" (4096 kB, SPI) mapped at
> physical address 0xffc0.
> Found Macronix flash chip "MX25L3206E/MX25L3208E" (4096 kB, SPI) mapped at
> physical address 0xffc0.
> Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) mapped at physical
> address 0xffc0.
> Multiple flash chip definitions match the detected chip(s): "MX25L3205(A)",
> "MX25L3205D/MX25L3208D", "MX25L3206E/MX25L3208E", "MX25L3273E"
> Please specify which chip definition to use with the -c option.
> [root@GH-11 ~]#
>
> [root@GH-12 ~]# flashrom --programmer internal
> flashrom v1.0.1 on Linux 3.10.0-1160.49.1.el7.x86_64 (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 ICH10R".
> Enabling flash write... Warning: Setting Bios Control at 0xdc from 0x02 to
> 0x01 failed.
> New value is 0x03.
> OK.
> Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) mapped at physical address
> 0xffc0.
> No operations were specified.
> [root@GH-12 ~]#
>
> comparing dmidecode on the two machines only shows differences in serial
> numbers, and ram slots used. all other hardware matches, so I'm pretty sure
> they're the same hardware.
>
> Why might one show up with a different chipset for bios image?
These two flash chips are equivalent and interchangeable. They're not
100% equivalent, but they have lots of things in common. For example,
they have the same size, both use the SPI protocol ("speak the same
language") and many commands are supported by both chips (including
identification commands). Using equivalent parts from different
vendors is common practice in circuit board design, as it reduces the
risk of not being able to assemble circuit boards because some
component is unavailable.
This is nothing to worry about. To choose the correct flash chip
definition in the Macronix case, the most straightforward way is to
read the model numbers written on the flash chip itself. From your
pictures, I see it's next to a corner of the ICH10R southbridge (the
square Intel chip next to the SATA ports), in a white socket.
> Here's some info I've gathered on these boards.
> https://docs.google.com/document/d/1qp1qBXW0Y9k_Xlj1VZ-OYmF6gfm31G00tRRXYmoPaMM/edit?usp=sharing
> Th G Doc lists all three hardware types we have from Quanta. The boards I'm
> writing about in this message, for this firmware exercise are called 13-P in
> this document.
>
> I have yet to see any actual manual for this hardware. tarball attached has
> firmware as captured on both machines.
For context, this attachment is missing because this mailing list
[flashrom] Re: Truncating flash for oversized image
Hi Rob, On Sun, Oct 31, 2021 at 10:18 PM David Hendricks wrote: > > On Sun, Oct 31, 2021 at 10:10 AM Rob Shore wrote: >> >> Hello! >> >> I've just discovered Flashrom as a way to use a Dediprog SPI programmer with >> MacOS, which is awesome. I've got a bit of a strange question though: >> >> I've got a 1Mbit rom on a board, but the image I was given for it is for a >> 2Mbit part. The firmware itself in the raw image is < 1Mbit, but the file is >> still larger than my ROM. Flashrom won't run the flash saying "Error: Image >> size (262144 B) doesn't match the flash chip's size (131072 B)!", which is >> technically correct. Is there a way to force the flash, and just have the >> process end after the first 131072B, which would result in the data I need >> being on the ROM? >> >> Thanks, and looking forward to using this tool some more! > > Try one of these: > - Use a layout file to tell flashrom exactly where you intend to write: `echo > "0:01 fw" > layout.txt && flashrom -p dediprog -l layout.txt -i fw > --noverify-all -w ` > - Create a new file that is the appropriate size, for example using `dd > if= of= bs=1k count=128` I think the first approach won't work, as flashrom still wants the file size to be exactly that of the flash chip. In these cases, one needs to manually adjust the file. If the file is too small, add some padding before and/or after its contents. If the file is too large, extract a subsection of the desired size (see David's second approach). Because this depends on the firmware contents and use case, flashrom cannot do this automatically. > The size check is an intentional UI decision to help prevent writing an > incorrect file to the flash. A little bit of extra caution here is typically > much easier than recovering a bricked host. Indeed. Having to perform some extra steps before flashing is much better than having to recover a bricked system. > ___ > 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] Re: One build system to rule them all (Meson)
options on all platforms, but at least some testing to be done. Otherwise, we risk introducing lots of regressions which no one would then fix. > This email sounds more like "I don't > understand X, we have to rip it out for everyone". I guess you've done > your research and found out which distros shipping flashrom are using, > either the make-based version or the meson-based version. That might > help you make up your mind. It is very simple: the `-o` command-line option is unusable on the distributions which have switched to meson to build flashrom. > Richard > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Schematic: MSI X570-A PRO (MS-7C37) ?
Hi Clay, On Sun, Sep 27, 2020 at 8:23 PM Clay Daniels wrote: > > Looking for schematic for: > MSI X570-A PRO (MS-7C37) > > Ivan Ivanov pointed out a very nice detailed view which I could not find in > MSI marketing propaganda, and it looks like I will need to use a CH341A > external programmer. This means I need to know if the vcc to the chip is 3.3v > or 5v. I have no real clues without a schematic. Are these available? VCC for SPI flash chips is never 5V. It's usually either 3.3V or 1.8V, and the best way to know is to look at the chip itself. It's a WSON8 package located between the first PCIe x16 slot and the CPU heatsink mount bracket, next to a connector labelled JSPI1. This connector is NOT meant for in-system programming, but for plugging in another flash chip and disabling the onboard one. I think the chip in the picture is a Winbond. `W25Q*V*` chips run on 3.3V, whereas `W25Q*W*` chips are 1.8V parts. Note the `V` vs `W` difference. > See nice Russian NIX picture at: > https://www.nix.ru/autocatalog/motherboards_msi/MSI-X570-A-PRO-RTL-AM4-X570-2xPCI-E-HDMI-GbLAN-SATA-ATX-4DDR4_427748.html > > Clay > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Success Report - Intel Z370 on MSI Z370-A PRO motherboard
Hi list, On Wed, Sep 9, 2020 at 9:07 PM Clay Daniels wrote: > > Congrats, Aspen. I have a MSI X570-A PRO (MS-7C37) Motherboard and trying to > get flashrom v1.2 on FreeBSD 13.0-CURRENT to recognize my mb. Looking at the > supported hardware at https://www.flashrom.org/Supported_hardware I don't see > my mb NOR yours either. Give me a little more detail on how you made this > happen on a fairly recent MSI mb like ours. (On or off list). While both mainboards are new, they're night and day. The MSI Z370-A-PRO is an Intel platform, whereas the MSI X570-A PRO is an AMD platform. One of the main use-cases of flashrom is to rewrite the boot firmware (BIOS, UEFI, coreboot...), and flashrom is often used to flash coreboot onto things. What's more, coreboot and flashrom use the same review infrastructure [1], so it's easy for coreboot developers to contribute to flashrom. There's coreboot support for Intel Coffee Lake, but not for AMD Zen stuff; and flashrom support is in a similar situation. I know there's some patches that enable support floating around. However, I don't think anyone pushed anything for review (if so, I must have missed it). There might be something in the GitHub pull requests, but I haven't checked. Since the GitHub repo is a mirror, it's not possible to accept pull requests through it, and transferring the PRs to Gerrit isn't trivial because of the sign-off requirement [2]. Yes, that page also mentions using GitHub, but it then says that one should use Gerrit instead. Maybe I'll rewrite that part at some point. [1]: https://review.coreboot.org [2]: https://flashrom.org/Development_Guidelines#Sign-off_Procedure > Clay > > On Wed, Sep 9, 2020 at 2:52 AM aspen via flashrom > wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Hi, I succesfully flashed an official MSI BIOS (version 7B48v2C) onto my MSI >> Z370-A PRO motherboard (Intel Z370 chipset, Intel Core i7 8086k CPU) using >> flashrom 1.2. >> It scared me as first, then it showed the BIOS screen... then rebooted a few >> times, then it booted succesfully! >> >> -BEGIN PGP SIGNATURE- >> >> iHUEARYIAB0WIQT9GEgotw7oWiVcdotzKTKWiWXeVgUCX1gJdQAKCRBzKTKWiWXe >> VuRbAP9KNqpOELFGRFGO3yjHS1jX6dY73+1bJQdPEyhU4BQq1AEAgAZ36LLZs5kg >> MI4jDZnzxIgMeDNm+2XNCWxj7qWWPQY= >> =ioGw >> >> -END PGP SIGNATURE- >> ___ >> flashrom mailing list -- flashrom@flashrom.org >> To unsubscribe send an email to flashrom-le...@flashrom.org > ___ > 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] Re: Tried to flash but cannot commence flash with v1.2
Hi Stephen, On Tue, Aug 4, 2020 at 12:51 PM Stephen Wong wrote: > > Hello guys > > i have a laptop equipped with GIGADEVICE chip, attached the photo for > the ram chip I don't see any RAM chip in the picture. That GigaDevice chip is a flash chip, though. Looks like it's a 512 KiB (kibibytes) part. Another interesting thing I see is the big square chip to the right of the flash chip. Sure, I only see a small part of it, but it looks like it says "ITE". It's probably an EC (Embedded Controller). If it is an EC, then it's very likely that the flash chip is directly connected to it, which makes in-circuit reflashing harder: powering the flash chip often powers the EC as well, and the EC starts talking with the SPI flash. Having two or more active masters on a SPI bus almost always ends up badly (not working). > i can't seem to proceed with flashing the bios with flashrom version 1.2 > > i not sure if this chip being supported > > wondering if it's supported or i did something wrong? Logs, logs, logs... What would we do without them? :P You can append the `-o logfile.txt` command-line argument to your flashrom command to generate a log file. Then, you can paste it on paste.flashrom.org (or send it as an attachment, I don't really care) so that we can see what exactly went wrong. If you're using a Debian-based distribution and flashrom complains about -o not being supported in standalone mode, add `-VV` instead and copy the resulting output. If redirecting to a file, remember to also redirect stderr! > Thanks! > > Stephen > > ___ > 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] Re: (no subject)
Hi there, On Tue, Aug 4, 2020 at 12:49 PM Gjglesias wrote: > > Please add winbond w25Q32bva in next update This flash chip is already supported, but we call it "W25Q32.V" because it also covers, e.g., "W25Q32JV". If flashrom can't detect this chip, it might be due to an electrical problem. > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Regards, Angel ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: read & write W25Q128.W chip
Hi Thomas, On Thu, Jul 16, 2020 at 10:06 PM Thomas Nordbø Vasquez wrote: > > Hi, > i have just successfully been able to flash the W25Q128.W chip. > Bricked Motherboard: UP2 Squared (Link below) > https://upboard.org/upsquared/specifications/ It's always great when bricked things stop being bricked :) > Mainboard for flashing: Raspberry Pi 3B > OS: Raspbian Buster Lite. > Flashrom version: Linux 4.19.118v7+ (armv7l) > I am new to using flashrom, so email me back if i have given you the wrong > log file and you are in need of the right one. It's the correct log. The flashrom version string is empty, but it's a known problem. IIRC, this was because Debian packagers downloaded flashrom through github's "Download ZIP" button instead of using the signed release tarballs. So, flashrom doesn't know about its own version (it prints an empty string). Oh well. In any case, this chip has been marked as tested for a few years: https://review.coreboot.org/22790 > Best regards, > Thomas N. Vasquez > Technician at Mohn Technology AS / Norway > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Current state of meson
Hi Richard, Jonathan, and everyone else, On Tue, May 26, 2020 at 12:00 PM Richard Hughes wrote: > > On Tue, 26 May 2020 at 00:20, Angel Pons wrote: > > So, given that meson produces broken executables and nobody seems to > > be actively taking care of it > > Errr, I am taking care of it. Is it broken now? Well, as I stated previously, flashrom built with meson results in the `-o` option not working at all. When helping others via IRC, we recommend fetching flashrom logs using that option so that no messages get lost, so not being able to rely on it is rather inconvenient. I can see [1] that you have two changes on gerrit, one of which is currently not submittable due to merge conflicts and has not been touched in two months. As far as I can tell, that's it. Are there any future plans for meson, such as making Jenkins build-test it? Edward O'Callaghan is working on unit testing [2], and it would be great if Jenkins could actually run these tests alongside the usual build tests. There isn't a thing such as too much coverage, or is there? :-P Feel free to propose any ideas here in the mailing list, so that we can discuss them beforehand. Working on something big without having previously talked it through with the rest of the community is dangerous: one can end up wasting lots of time working on something that is then rejected, then emotions overflow and then everyone and everything ends up on fire... I've had that happen several times and it has always been extremely frustrating, so let's do it right this time, shall we? :-) On Tue, May 26, 2020 at 12:03 PM Richard Hughes wrote: > > On Tue, 26 May 2020 at 03:27, Jonathan A. Kollasch > wrote: > > Remove meson support. > > Removing meson support from flashrom would mean dropping the fwupd > plugin that uses libflashrom; we have to build flashrom from a > subproject as very often we're depending the very latest API > additions. I believe dropping meson support should only be a last-resort measure, so I brought up the topic on the mailing list to calmly and respectfully exchange ideas about it and work towards improvement. Let's be honest, we will never be able to make each and every being on this planet completely happy, but we can surely attempt to find a middle ground that is good enough for all of us, the flashrom community. > > Meson is no less broken than our home-grown Makefiles. > > Can you substantiate that? Please refer to the aforementioned bug about `-o` not being usable when building with meson. While the home-grown Makefiles may have bugs, they have survived the test of time and should be considered the official way to build flashrom, especially considering that Jenkins relies on them to build-test flashrom patches. If possible, I would consider turning meson into a wrapper around the Makefiles, to eliminate redundancy. However, as I do not know a thing about meson, I have no idea if such a thing is doable. As you seem to be more familiar with meson than I am, what are your thoughts on this idea? Is there a better way to handle that? > Richard. Best regards, Angel [1]: https://review.coreboot.org/q/owner:richard%2540hughsie.com [2]: https://review.coreboot.org/41622 ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Current state of meson
Dear flashrom community, Currently, flashrom has support for two different build systems: the traditional Makefile-based approach, and meson. The latter was introduced not too long ago [1] to be used by the fwupd project. However, as far as I am concerned, it is currently not used for build-testing on upstream, and is thus prone to breakage. As a result, both build systems need to be kept in sync manually, which is an additional maintenance burden. On top of that, it appears to be that no one has been working on addressing this problem upstream. In addition, looks like the Debian folks started using meson as well. Looks like binaries built using meson do not work correctly, e.g., the `-o` command-line option is unusable: $ flashrom -p dummy -o logfile.txt flashrom v1.2 on Linux 5.2.0-2-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Log file not supported in standalone mode. Aborting. Please run "flashrom --help" for usage info. This problem can also be reproduced when building with meson on Arch Linux, so it is not specific to Debian. Needless to say, binaries built with the Makefile are unaffected. So, given that meson produces broken executables and nobody seems to be actively taking care of it, what should we do with it? Is anyone interested in improving and maintaining the meson integration? All suggestions are welcome. Best regards, Angel [1]: https://review.coreboot.org/31248 ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Is this an Error? Problem flashng.
Hi Nikos, On Wed, May 20, 2020, 07:46 Nikos Mouzakitis wrote: > Hello this is my output when trying to flash.. > > Does Incomplete/failed Command Receive Device string plays a role on > the error of verification? > I cannot flash back the original bios contents at the moment on my board. > > flashrom v0.9.9-r1954 on Linux 4.15.0-88-generic (x86_64) > flashrom is free software, get the source code at https://flashrom.org > I would suggest using a more recent flashrom version like v1.2 just in case there are relevant bugfixes. Calibrating delay loop... OK. > Setting voltage to 1800 mV > So dediprog sets its voltage to 1.8V... Incomplete/failed Command Receive Device String! > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on dediprog. > ... but this chip is a 3.3V part! Just in case, double-check that the model on the chip matches what flashrom detected (the "." means any character, like W25Q64FV"). You can also turn on the board and measure the voltage between flash chip pins 8 (VCC) and 4 (GND). In any case, W25Q64.V is a 3.3V part, and W25Q64.W is a 1.8V part. Note the different "V" and "W" endings. Reading old flash chip contents... done. > Erasing and writing flash chip... Erase/write done. > Verifying flash... FAILED at 0x0010! Expected=0x5a, Found=0xff, failed > byte count from 0x-0x007f: 0x2ddb74 > Your flash chip is in an unknown state. > Please report this on IRC at chat.freenode.net (channel #flashrom) or > mail flashrom@flashrom.org, thanks! > ___ > 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] Re: Flashrom tool failed on the Intel Bakerville platform(CPU:SKY-D)
Hi Ocean
On Tue, Mar 24, 2020 at 2:41 AM Ocean Huang wrote:
>
> Hi Angel:
>
> "0xa1c8" seems is the "QS/PRQ" SKU, but it does not mark it as "QS/PRQ" SKU
> in the eds spec "568202-d-2100-eds-rev2-1-review.pdf", the detail you can see
> the below image.
>
>
> However, I think the device id 0xa1c8 whether QS/PRQ SKU or Super SKU will
> not affect for flashrom tool.
Right, looks like the Xeon D-2100 integrates a Lewisburg PCH inside.
That explains why I couldn't find that ID anywhere: there is no
publicly available datasheet for these Xeons.
> Anyway, thank you very much for the support.
>
> Thanks,
> Best Regards,
> Ocean
>
> On Mon, Mar 23, 2020 at 11:08 PM Angel Pons wrote:
>>
>> Hi Ocean,
>>
>> On Mon, Mar 23, 2020 at 2:00 PM Ocean Huang via flashrom
>> wrote:
>> >
>> > Hi David:
>> >
>> > For flashrom could update BIOS successfully on the Intel Bakerville
>> > platform(CPU:SKY-D), we need to add device id to chipset_enables table in
>> > the file of"chipset_enables.c", or it will cause below error:
>> > WARNING: No chipset found. Flash detection will most likely fail.
>> > No EEPROM/flash device found.
>> > Note: flashrom can never write if the flash chip isn't found automatically.
>> >
>> > So could you please help to add these three device ids to the
>> > chipset_enable table and upload to the Github?
>> > Attached the changed file.
>>
>> I see that you have added these three new device IDs:
>>
>> {0x8086, 0xa1c8, NT, "Intel", "C620 Series Chipset Supersku",
>> enable_flash_c620},
>> {0x8086, 0xa248, NT, "Intel", "C620 Series Chipset Supersku",
>> enable_flash_c620},
>> {0x8086, 0xa249, NT, "Intel", "C620 Series Chipset Supersku",
>> enable_flash_c620},
>>
>> I can confirm that the last two IDs are for Super SKUs, but "0xa1c8"
>> (the first one) seems to be a "QS/PRQ" SKU. Could you please confirm
>> it? I have created a change to add these IDs:
>>
>> https://review.coreboot.org/39780
>>
>> In addition, since flashrom can successfully update the BIOS on these
>> chipsets, knowing the Device IDs that have been tested would be much
>> appreciated. That way, we can mark the chipsets as tested.
>>
>> > Thanks,
>> > Best Regards,
>> > Ocean
>> >
>> > --
>> > Thanks,
>> > Best Regards,
>> > Ocean Huang
>> > BIOS Engineer
>> > Celestica(Shanghai) R Center, China
>> > email: hah...@celestica.com
>> > www.celestica.com
>> > ___
>> > flashrom mailing list -- flashrom@flashrom.org
>> > To unsubscribe send an email to flashrom-le...@flashrom.org
>>
>> Thanks in advance,
>>
>> Angel Pons
>
>
>
> --
> Thanks,
> Best Regards,
> Ocean Huang
> BIOS Engineer
> Celestica(Shanghai) R Center, China
> email: hah...@celestica.com
> www.celestica.com
Best regards,
Angel Pons
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Flashrom tool failed on the Intel Bakerville platform(CPU:SKY-D)
Hi Ocean,
On Mon, Mar 23, 2020 at 2:00 PM Ocean Huang via flashrom
wrote:
>
> Hi David:
>
> For flashrom could update BIOS successfully on the Intel Bakerville
> platform(CPU:SKY-D), we need to add device id to chipset_enables table in the
> file of"chipset_enables.c", or it will cause below error:
> WARNING: No chipset found. Flash detection will most likely fail.
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
>
> So could you please help to add these three device ids to the chipset_enable
> table and upload to the Github?
> Attached the changed file.
I see that you have added these three new device IDs:
{0x8086, 0xa1c8, NT, "Intel", "C620 Series Chipset Supersku",
enable_flash_c620},
{0x8086, 0xa248, NT, "Intel", "C620 Series Chipset Supersku",
enable_flash_c620},
{0x8086, 0xa249, NT, "Intel", "C620 Series Chipset Supersku",
enable_flash_c620},
I can confirm that the last two IDs are for Super SKUs, but "0xa1c8"
(the first one) seems to be a "QS/PRQ" SKU. Could you please confirm
it? I have created a change to add these IDs:
https://review.coreboot.org/39780
In addition, since flashrom can successfully update the BIOS on these
chipsets, knowing the Device IDs that have been tested would be much
appreciated. That way, we can mark the chipsets as tested.
> Thanks,
> Best Regards,
> Ocean
>
> --
> Thanks,
> Best Regards,
> Ocean Huang
> BIOS Engineer
> Celestica(Shanghai) R Center, China
> email: hah...@celestica.com
> www.celestica.com
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
Thanks in advance,
Angel Pons
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: 25x10cln1g erase and write failed!
Hi there, On Mon, Mar 23, 2020 at 2:01 PM The real bruno mars wrote: > > Hello all. It seems that I am having issues with my Arduino based flasher. I > installed Frser-duino on my Arduino UNO and tried flashing a winbond > 25x10cln1g. However I am running into errors. My log is here: > https://pastebin.com/eLJNu43T I would greatly appreciate any help. The Arduino-based programmers are more complicated to debug and use, primarily because the Arduino works at 5V while the flash chips run with at most 3.3V. In your case, the datasheet says so: https://www.winbond.com/resource-files/w25x10cl_revg%20021714.pdf Are you following any particular guide? To avoid damaging the flash chip, one should use a level shifter. The flashrom wiki page has some information: https://www.flashrom.org/Serprog/Arduino_flasher > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: flashrom log, Intel C236
Hi Mario, On Wed, Mar 4, 2020 at 6:41 AM Mario Piras via flashrom wrote: > > I was not able to use flashrom with Intel C236 motherboard Fujitsu D3417-B1, > as the following information was displayed, I'm also attaching log. > > Found chipset "Intel C236" with PCI ID 8086:a149. > This chipset is marked as untested. If you are using an up-to-date version > of flashrom *and* were (not) able to successfully update your firmware with > it, > then please email a report to flashrom@flashrom.org including a verbose (-V) > log. > Thank you! > Part of your log explains why it is not working: 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. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). In short, your firmware settings block read access to some parts of the flash chip. For some reason, the flashrom version does not appear in the log, so I have no idea if it's a recent version. I would suggest building from master and trying again. The message will be similar, but contains more useful information. Newer flashrom versions support the `--ifd` command line switch, which uses the Intel Flash Descriptor (think of it as a "partition table" for the firmware on Intel platforms) as a layout. Together with the `-i bios` switch, flashrom will only read the BIOS region, which should just work. > I'd purchase another C236 or C232 motherboard, would welcome suggestion which > one to try. > > Best regards > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Test went wrong on GD25Q32(B)
Hi Jakob & Bendik On Sat, Feb 29, 2020 at 11:35 PM Jakob Kok wrote: > > Dear Flashrom, > > We are two master students working on our thesis and in that regard we are > doing a security analysis on an embedded device. The embedded device has an > external flash memory, and it is of the GD25Q32(B) series. We are using a > Shikra as extracting device (ft2232h). On your website, it states that this > should be a tested and verified flash chip. However, we get this error > message in our experiment - and we would really appreciate if you looked into > this. > > flashrom -p ft2232_spi:type=232H -r spidump.bin > flashrom v1.2-2-g0f510a7 on Linux 5.2.0-kali2-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 Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on ft2232_spi. This means that flashrom was able to detect something, but failed to identify the flash chip. If the flash chip is still soldered onto the circuit board, it is extremely likely that the embedded device's SoC is getting powered through the programmer. Most designs do not have any isolation between the flash chip and the rest of the voltage rail, so powering the flash chip also powers the rest of the board. If the SoC receives enough power to turn on (even partially), it will attempt to access the SPI flash chip, and it will conflict with your programmer accesses. To overcome this issue, I personally recommend desoldering the flash chip. Since no other circuit may interfere, it is much easier to verify that reading works consistently, using flashrom's `-v` command line switch. In addition, this reduces the risk of killing the device, as no external power needs to be applied to the board. Connnecting the flash chip backwards may make it overheat, but I have never seen a flash chip die because of that. > === > This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE > The test status of this chip may have been updated in the latest development > version of flashrom. If you are running the latest development version, > please email a report to flashrom@flashrom.org if any of the above operations > work correctly for you with this flash chip. Please include the flashrom log > file for all operations you tested (see the man page for details), and mention > which mainboard or programmer you tested in the subject line. > Thanks for your help! > Read is not working on this chip. Aborting. This is a consequence of the flash chip not being detected. To avoid any issues, flashrom considers it to not be working, so that no potentially destructive accesses may occur. Once the flash chip is detected properly, this message should not appear. > Best regards, > Jakob Stenersen Kok & Bendik Aalmen Markussen > > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, and happy hacking! Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: "pcidev.c: Factor out pcidev_validate() into pure fn" broke PCI programmers
Hi, On Sat, Jan 18, 2020 at 7:31 PM Nico Huber wrote: > > Hi, > > On 14.01.20 17:10, Carl-Daniel Hailfinger wrote: > > commit e28d75ed7204d7fac2c0fac13978098530b0574e dropped some logic > > during refactoring. > > PCI-based programmers now fail to initialize IFF the desired PCI device > > not the last one enumerated by libpci. > > yup, I already commented on that change post-merge. Just waited for the > holidays to pass, no reaction after all so I pushed a revert: > https://review.coreboot.org/c/flashrom/+/38319 I noticed the revert today. I'm not sure what unit tests are good for without, for example, regression tests on hardware. > Nico > ___ > 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] Re: GitHub PRs
Hi everyone, On Sat, Nov 30, 2019, 14:15 Nico Huber wrote: > Hi all, > > the GitHub PR topic popped up from time to time on IRC in the past but > it seems we never discussed it here or came to any conclusion that led > to action. > > When we switched to Git, we wrote down three ways to send patches [1]: > > o Via our mailing list > > o Via gerrit on coreboot.org > > o Via pull request on flashrom's github mirror > If the repo on github is a mirror which tracks the "master repo" in coreboot, it does not make sense to use pull requests, as they would land on the mirror. I have never reviewed on the mailing list, so I don't know how tedious it is. In any case, it's easier to move mailing list patches to gerrit than pull requests. Now, roughly 2 years later, some PRs have been merged, but some, even > smaller ones, were left unanswered. We also never set a clear process > how to move things to Gerrit. > Agreed. Should we stop accepting pull requests, it would be good to document (or link to) the procedure to create a change on gerrit. While I still don't object to reviewing on Github, if somebody wants > to do so, it has some downsides: no global overview of pending patches, > no build testing before moving things to Gerrit, the overhead of moving > things, ofc (IMHO, reviewing on Github is also much harder, maybe I'm > just Gerrit spoiled). > IMHO, handling the merging of pull requests alone is cumbersome enough to outweigh the benefits of allowing pull requests. Especially the build-test integration makes it hard for me to come up > with a reasonable process. Hence, I suggest that we just stop accepting > PRs on GitHub and tell contributors to push to Gerrit directly. This > may be more work for the contributors and might even scare some away; > but I don't see any lack of contributions to this project rather a lack > of reviewer resources. So we should make reviewing as easy as possible, > IMO. > I completely agree. Nico > > [1] https://www.flashrom.org/Development_Guidelines#Sending_a_patch > ___ > flashrom mailing list -- flashrom@flashrom.org > To unsubscribe send an email to flashrom-le...@flashrom.org Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: SFDP with Winbond chip
Hi Bercik, Thanks for your report. On Thu, Aug 22, 2019 at 5:45 PM ro_beri wrote: > > Hi to all team members. > > chip: Winbond 25Q128BFVS0 > programmer: ch341a > device: Intel NUC5PPYH > os: Debian Stretch > kernel: 4.9.168-1+deb9u5 (2019-08-11) > That chip should be supported, but looks like SFDP probing is done first, so you get that message about an unsupported chip. Then probing for the "W25Q128.V" runs and finds your chip fine. In the end, you end up with two detected chip definitions: the SFDP definition, and the W25Q128.V definition. For now, you can tell flashrom to use the W25Q128.V definition adding the following command-line switch: -c "W25Q128.V" Nevertheless, this looks like a bug that was introduced in a recent change: https://review.coreboot.org/c/flashrom/+/33931 The SFDP-capable entry used to be at the end of flashchips.c, so as to be probed last. However, the sorting done in that change moved it upwards, before the Winbond entries. Hence the error. > Flashrom builded with procedure: > # apt install pciutils pciutils-dev libpci-dev zlib1g-dev libpci3 libftdi-dev > libusb-dev > # git clone https://github.com/flashrom/flashrom.git flashrom_git > # cd flashrom_git; make; cp flashrom ../ > > Some parts of build log: > # Replacing all version templates with v1.1-rc1-69-g188127e. > # Checking for a C compiler... found. > # Target arch is x86 > # Target OS is Linux > # Checking for libpci headers... found. > # Checking version of pci_get_dev... new version (including PCI domain > parameter). > # Checking if libpci is present and sufficient... yes. > # Checking for libusb-1.0 headers... found. > # Checking if libusb-1.0 is usable... yes. > # Checking for FTDI support... found. > # Checking for FT232H support in libftdi... found. > # Checking if Linux MTD headers are present... yes. > # Checking if Linux SPI headers are present... yes. > # Checking for utsname support... found. > # Checking for clock_gettime support... found. > > log from "flashrom -p ch341a_spi -VV" in attachment. > > Regards > Bercik Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Chip size
Hello, On Tue, May 7, 2019, 23:16 EvilGremlin wrote: > Hello! > > Can you change chip size verification? At least for SPI EEPROMs, that i > flash almost every day, chip size doesn't really matter. I find it > really annoying, that i cannot flash 32Mb image to 64Mb chip and there > is no option to force it. So i have to boot Windows or edit image just > for that. Almost any other software can do that just fine. > flashrom does not know where to place your image if it does not match your chip size. If you know, you can pad your image accordingly. So, can you add force key or warning message with (yes/no) option. > Default "yes", of course. > Adding a "force" optian does not make any sense if flashrom does not know where to flash the data on the chip. And forcing that by default would be even worse. Regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: probleme read flashrom
Hello On Fri, Mar 15, 2019, 16:27 sebch...@gmx.com flashrom v0.9.9-rc1-r1942 on Linux 4.4.0-142-generic (x86_64) > flashrom is free software, get the source code at https://flashrom.org This version is old, and may support less chips. Consider getting a newer version (e.g. from git). Regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Wont flash bios
Hello, Your reply did not reach the mailing list. Please use "Reply to all" so that your messages can reach more people than just me. On Tue, Mar 12, 2019, 09:06 Frei Bjerkestrand No I'm pretty sure the 1.8V is connected. Should I try to disassemble the > programmer and the 1.8V converter and assemble it again? > So you are using a 1.8V converter between the programmer and the chip? Regarding the original issue: If you can not change any bytes, I would suspect the flash chip is write-protected. Check its datasheet, it is likely pin 3 is somehow pulled low (write-protect pin is usually active when low). Regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Wont flash bios
Hello, On Sun, Mar 10, 2019, 22:36 Frei Bjerkestrand W25Q128.W Winbond Chip > If I recall correctly, this is a 1.8V part. Are you powering it with a higher voltage, by any chance? Regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Possible bug report (?)
Hello, On Tue, Feb 26, 2019, 09:38 Joe Sypniewski via flashrom < flashrom@flashrom.org wrote: > ./flashrom -p internal:ich_spi_forces=yes -V -N --ifd -i bios -w peppy/ > coreboot-peppy-seabios-latest.rom > ferr.txt 2>&1 > To write logs, you can use the -o/--output command line switch. Error accessing ICH RCRB, 0x4000 bytes at 0xfed1c000 > /dev/mem mmap failed: Operation not permitted > Your kernel restricts access to /dev/mem. Try using the following kernel parameter: iomem=relaxed Best regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Updating the e-flash on an ITE SuperIO chip
Hello, On Mon, Feb 11, 2019, 18:26 Richard Hughes On Mon, 11 Feb 2019 at 17:00, Angel Pons wrote: > > The it85spi driver is commented out in code, apparently because it > > relies on firmware-specific functions. AFAIK, there isn't much to read > > the internal flash on ECs, other than the ENE KB9012's via EDI. > > Okay, that was a very useful read, thanks. Different, but related of > course. > > > > Whilst I now have a datasheet, I > > For those chips? I'm interested in them: How did you obtain them? > > I've been working with an ODM for an un-named OEM, who supplied me the > datasheet for the IT89 without signing an NDA. I don't think I can > redistribute it without issues. > Oh, bummer. > I don't think much has been done for the internal flash on these ICs on > > flashrom. For instance, I didn't know the IT8987 had an internal flash. > > As I understand it, at least for the the hardware I have here, the > IT89 has both. The SPI "external" flash is only used to populate the > "internal" e-flash at manufacturing time and then after than it's > unused. I imagine you could reprogram the 128k external SPI chip using > the indirect mapping thing although at least for me it's a nice "get > out of jail" feature as the current firmware seems to look for the > A5A5A5A5 16 byte header on the e-flash to check if it's valid. Of > course, I could have misunderstood this all wildly. > I now recall reading something like that. I'm not sure about the header bit, though. On Mon, 11 Feb 2019 at 17:11, Carl-Daniel Hailfinger > wrote: > > IT87 handling was easy and straightforward because all they did > > (regarding flash) was translating LPC flash accesses to SPI flash > > accesses in passthrough mode and offering a separate SPI-centric > > programming interface for full access. > > I think IT89 is much like a IT87 -- some of the LDNs seem a bit > different (and there are more!) but it looks basically the same kind > of beast. > Well, the IT87 and IT86 series are usually Super IO chips, whereas the IT85 and IT89 chips are ECs, which seem to have a SuperIO-like part, with LDNs and such. Richard. > Best regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Updating the e-flash on an ITE SuperIO chip
Hello Richard, On Mon, Feb 11, 2019, 16:33 Richard Hughes > I've been looking at updating the EC for the IT8587 and IT8987 SuperIO > controllers from userspace. Hmm, I have the ITE IT8585 and IT8987 chips here. > I see that there are it87spi and ite85spi > modules in flashrom, but as I understand it they are using the ITE > chip to write the system firmware over SPI (e.g. the 4MiB BIOS) rather > than the 128KiB internal e-flash. The it85spi driver is commented out in code, apparently because it relies on firmware-specific functions. AFAIK, there isn't much to read the internal flash on ECs, other than the ENE KB9012's via EDI. > Whilst I now have a datasheet, I For those chips? I'm interested in them: How did you obtain them? > don't want to implement code that someone else has already done. If > anyone knows any pointers to any code or documentation I'd be very > grateful. Thanks. I don't think much has been done for the internal flash on these ICs on flashrom. For instance, I didn't know the IT8987 had an internal flash. > Richard Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Intel HM86 - Lenovo L440 failure
Hello, On Sun, Feb 3, 2019, 08:48 /dev/mem mmap failed: Operation not permitted > This means your kernel restricts accesses to /dev/mem. To overcome this, add `iomem=relaxed` to your kernel flags. Do note that you may not be able to read the whole flash chip contents. This is because newer Intel platforms lock read and/or write access to some parts of the flash chip based on what the IFD (Intel Firmware Descriptor, also known as Intel Flash Descriptor) specifies. flashrom has a parameter to access one region at a time, however. Best regards, Angel Pons > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Report of flashrom failure (Intel DQ67OW motherboard)
Hello Tom, On Fri, Dec 28, 2018 at 7:03 PM Tom Crane wrote: > > Dear Flashrom developers, > > Please find attached my failure report as suggested in flashrom O/P. The > PC has been updated with the latest BIOS (file SWQ6710H.86A.0070.BI.zip from > Intel) and I am running a built-today git version of flashrom. I can see a few things: > flashrom v0.9.9-r1955 on Linux 4.19.8 (x86_64) This is from git? It seems to be a rather old version. > 0x54: 0x FREG0: Warning: Flash Descriptor region > (0x-0x0fff) is read-only. > 0x58: 0x07ff0580 FREG1: BIOS region (0x0058-0x007f) is read-write. > 0x5C: 0x057f0003 FREG2: Warning: Management Engine region > (0x3000-0x0057) is locked. > 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff) is > read-write. Some regions are unreadable. Trying to read them results in an error, as expected. If you want to completely backup the chip, either disabling region protections or using an external programmer is needed. > > Thanks > > Tom Crane Best regards, Angel Pons ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
Re: [flashrom] Intel Z97 chipset
Hello, Is this a log to mark Z97 as tested? Since neither the flash descriptor nor protected ranges are blocking reads or writes, could you test read, write and erase as well, please? Best regards, Angel Pons Pons ___ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom
Re: [flashrom] Fwd: Intel QS77 chipet on MBA 2012
Hello, > 0x54: 0x FREG0: Flash Descriptor region (0x-0x0fff) is > read-write. > 0x58: 0x07ff0190 FREG1: BIOS region (0x0019-0x007f) is read-write. > 0x5C: 0x018f0001 FREG2: Management Engine region (0x1000-0x0018) is > read-write. I see you made all the flash regions read-write. This means region protections should not be a problem to use flashrom. > 0x74: 0x866f0190 PR0: Warning: 0x0019-0x0066 is read-only. > 0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ff is read-only. AFAIK, this means flashing internally a complete image may not work. However, if you only want to restore the EFI variables region, you should tell flashrom to only write to the EFI variables region (which I imagine is not write-protected) using a layout file. Since you know the rest of the firmware is working properly, it is safer to only change what is not working. Best regards, Angel Pons Pons ___ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom
Re: [flashrom] HP 8200
Hello Michael, What is your question about this log? Regards, Angel Pons Pons On Tue, Sep 18, 2018 at 9:14 AM, Michael Miller wrote: > [root@localhost ~]# flashrom -V --programmer internal > flashrom v1.0 on Linux 3.10.0-862.11.6.el7.x86_64 (x86_64) > flashrom is free software, get the source code at https://flashrom.org > > flashrom was built with libpci 3.5.1, GCC 4.8.5 20150623 (Red Hat 4.8.5-16), > little endian > Command line (3 args): flashrom -V --programmer internal > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > Initializing internal programmer > No coreboot table found. > Using Internal DMI decoder. > DMI string chassis-type: "Mini Tower" > DMI string system-manufacturer: "Hewlett-Packard" > DMI string system-product-name: "HP Compaq 8200 Elite SFF PC" > DMI string system-version: "Not Specified" > DMI string baseboard-manufacturer: "Hewlett-Packard" > DMI string baseboard-product-name: "1495" > DMI string baseboard-version: "Not Specified" > W836xx enter config mode worked or we were already in config mode. W836xx > leave config mode had no effect. > Active config mode, unknown reg 0x20 ID: 1c. > Found chipset "Intel Q67" with PCI ID 8086:1c4e. > This chipset is marked as untested. If you are using an up-to-date version > of flashrom *and* were (not) able to successfully update your firmware with > it, > then please email a report to flashrom@flashrom.org including a verbose (-V) > log. > Thank you! > Enabling flash write... Root Complex Register Block address = 0xfed1c000 > GCS = 0xc25: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) > Top Swap: not enabled > 0xfff8/0xffb8 FWH IDSEL: 0x0 > 0xfff0/0xffb0 FWH IDSEL: 0x0 > 0xffe8/0xffa8 FWH IDSEL: 0x1 > 0xffe0/0xffa0 FWH IDSEL: 0x1 > 0xffd8/0xff98 FWH IDSEL: 0x2 > 0xffd0/0xff90 FWH IDSEL: 0x2 > 0xffc8/0xff88 FWH IDSEL: 0x3 > 0xffc0/0xff80 FWH IDSEL: 0x3 > 0xff70/0xff30 FWH IDSEL: 0x4 > 0xff60/0xff20 FWH IDSEL: 0x5 > 0xff50/0xff10 FWH IDSEL: 0x6 > 0xff40/0xff00 FWH IDSEL: 0x7 > 0xfff8/0xffb8 FWH decode enabled > 0xfff0/0xffb0 FWH decode enabled > 0xffe8/0xffa8 FWH decode enabled > 0xffe0/0xffa0 FWH decode enabled > 0xffd8/0xff98 FWH decode enabled > 0xffd0/0xff90 FWH decode enabled > 0xffc8/0xff88 FWH decode enabled > 0xffc0/0xff80 FWH decode enabled > 0xff70/0xff30 FWH decode disabled > 0xff60/0xff20 FWH decode disabled > 0xff50/0xff10 FWH decode disabled > 0xff40/0xff00 FWH decode disabled > Maximum FWH chip size: 0x10 bytes > SPI Read Configuration: prefetching disabled, caching enabled, > BIOS_CNTL = 0x22: BIOS Lock Enable: enabled, BIOS Write Enable: disabled > Warning: BIOS region SMM protection is enabled! > Warning: Setting Bios Control at 0xdc from 0x22 to 0x01 failed. > New value is 0x22. > SPIBAR = 0x7fcb9274c000 + 0x3800 > 0x04: 0xe008 (HSFS) > HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 > Warning: SPI Configuration Lockdown activated. > Reading OPCODES... done > 0x06: 0x (HSFC) > HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 > 0x50: 0x1a1b (FRAP) > BMWAG 0x00, BMRAG 0x00, BRWA 0x1a, BRRA 0x1b > 0x54: 0x FREG0: Warning: Flash Descriptor region > (0x-0x0fff) is read-only. > 0x58: 0x07ff0510 FREG1: BIOS region (0x0051-0x007f) is read-write. > 0x5C: 0x050f0003 FREG2: Warning: Management Engine region > (0x3000-0x0050) is locked. > 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff) is > read-write. > 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. > 0x74: 0x87ff07f0 PR0: Warning: 0x007f-0x007f is read-only. > Writes have been disabled for safety reasons. You can enforce write > support with the ich_spi_force programmer option, but you will most likely > harm your hardware! If you force flashrom you will get no support if > something breaks. On a few mainboards it is possible to enable write > access by setting a jumper (see its documentation or the board itself). > 0x90: 0x84 (SSFS) > SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 > 0x91: 0xf94240 (SSFC) > SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=2, SME=0, SCF=1 > 0x94: 0x0006 (PREOP) > 0x96: 0x043b (OPTYPE) > 0x98: 0x05200302 (OPMENU) > 0x9c: 0x019f (OPMENU+4) > 0xA0: 0x (BBAR) > 0xC4: 0x00802005 (LVSCC) > LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 > 0xC8: 0x
Re: [flashrom] (no subject)
Hello, First of all, is your laptop a Dell Latitude D630? Specifying the model number may be ambiguous. With regard to reflashing the BIOS, may I ask how exactly would reflashing help? AFAIUI, rewriting the same code would make no difference, and there isn't a free replacement such as coreboot for this laptop. Best regards, Angel Pons Pons ___ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom
Re: [flashrom] flash bios on winbond W25X32
Hello LWS, I use a RPi for flashing chips too, and I connect pin 17 (3.3V source for the RPi) to three pins on DIP-8/SOIC-8 flash chip: - pin 3, to disable write protection - pin 7, to enable the chip - pin 8, to power the chip As I understand it, it should work. Best regards, Angel Pons ___ flashrom mailing list flashrom@flashrom.org https://mail.coreboot.org/mailman/listinfo/flashrom
