On Mon, Mar 12, 2012 at 03:11:13AM +0100, Stefan Tauner wrote:
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
This one's trivial, as it's purely doc changes, so:
Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de>
But see the comments below please.
> ---
> Documentation/mysteries_intel.txt | 81 ++++++++++++++++++++++++++++++++++++-
> 1 files changed, 80 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/mysteries_intel.txt b/Documentation/mysteries_intel.txt
> index d6d3dfb..8a9a113 100644
> --- a/Documentation/mysteries_intel.txt
> +++ b/Documentation/mysteries_intel.txt
> @@ -15,4 +15,83 @@
> See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html
>
> = Unlocking the ME region =
> -TODO
> + If the ME region is locked by the FRAP register in descriptor mode, the host
> + software is not allowed to read or write any address inside that region. There
> + are different ways to unlock access:
> +
> + - a pin strap: Flash Descriptor Security Override Strap (as indicated by the
"a pin" -> "A pin"
> + Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is
> + probably not accessible to end users on consumer boards (every Intel doc i
^
I
> + have seen stresses that this is for debugging in manufacturing only and
> + should not be available for end users).
> + The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
> + the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL].
> +
> + - Intel Management Engine BIOS Extension (MEBx) Disable This option may be
^
Missing full stop.
> + available to end users on some boards usually accessible by hitting
> + ctrl+p after BIOS POST. Quote: "???Disabling??? the Intel ME does not really
> + disable it: it causes the Intel ME code to be halted at an early stage of
> + the Intel ME???s booting so that the system has no traffic originating from
> + the Intel ME on any of the buses." [MEBX]
Kill the strange "???" above?
> + The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
> + the HECI/MEI PCI device by setting them to 3 (Soft Temporary Disable)
> + [MODE_CTRL].
> +
> + - Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or
> + channel?) #0 disables the ME completely, which may give the host access to
> + the ME region.
> +
> + - HMRFPO (Host ME Region Flash Protection Override) Enable MEI command
> + This is the most interesting one because it allows to temporarily disable
> + the ME region protection by software. The ME indicates this in bits [19:16]
> + (Operation Mode) in the HFS register of the HECI/MEI PCI device by setting
> + them to 5 (SECOVER_MEI_MSG) [MODE_CTRL].
> +
> +== MEI/HECI ==
> + Communication between the host software and the different services provided by
> + the ME is done via a packet-based protocol that uses MMIO transfers to one or
> + more virtual PCI devices. Upon this layer there exist various services that can
> + be used to read out hardware management values (e.g. temperatures, fan speeds
> + etc.). The lower levels of that protocol are well documented:
> + The locations/offsets of the PCI MMIO registers are noted in the chipset
> + datasheets. The actually communication is documented in a whitepaper [DCMI] and
> + an outdated as well as a current Linux kernel implementation (currently in
> + staging/ exist [KERNEL]. There exists a patch that re-implements this in user
> + space (as part of flashrom).
> +
> +== Problems ==
> + The problem is that only very few higher level protocols are documented publicly,
> + especially the bunch of messages that contain the HMRFPO commands is probably
> + well protected and only documented in ME-specific docs and the BIOS writer's
> + guides. We are aware of a few leaked documents though that give us a few hints
> + about it, but nothing substantial regarding its implementation.
> +
> + The documents are somewhat contradicting each other in various points which
> + might be due to factual changes in process of time or due to the different
> + capabilities of the ME firmwares, example:
> +
> + Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI
> + ME Region, to prevent both writing at the same time, causing data corruption." [ME8]
> +
> + "FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if
> + used to update the ME Region." [SPS]
> +
> + When looking at the various ME firmware editions (and different chipsets), things
> + get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST
> + (EOP), others say that the ME region can be updated in the field or that some
> + vendor tools use it for updates. This needs to be investigated further before
> + drawing any conclusion.
> +
> +[MODE_CTRL] Client Platform Enabling Tour: Platform Software
> + Document Number: 439167, Revision 1.2, page 52
> +[MEBX] Intel?? Management Engine BIOS Extension (MEBX) User???s Guide
Kill/fix the "???" stuff.
> + Revision 1.2, Section 3.1 and 3.5
> +[DCMI] DCMI Host Interface Specification
> + Revision 1.0
> +[KERNEL] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=d…
> +[SPI_PROG] Ibex Peak SPI Programming Guide
> + Document Number: 403598, Revision 1.3, page 79
> +[ME8] Manufacturing with Intel?? Management Engine (ME) Firmware 8.X on Intel 7 Series
Ditto.
> + Revision 2.0, page 59
> +[SPS] Manufacturing with Intel?? Management Engine (ME) on Intel?? C600 Series Chipset 1 for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware
Ditto.
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
On Thu, Aug 11, 2011 at 05:59:42AM +0200, Stefan Tauner wrote:
> Chip features an optional permanent boot block write protection.
>
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
> Signed-off-by: David Borg <borg.db(a)gmail.com>
>
> ---
> diff of flashchips.c looks very odd, this is because i moved AT49F020 down.
> - rebased
> - voltages added
> - FEATURE_ADDR_FULL flag removed
> - printlock_at49f040 added (location dubios, but w39_idmode_readb
> implements what is needed already (and is static...)
> - AT49F020 does also feature a permanent lock (8 kB boot block), which uses
> the same detection method...
Rebased (again) and committed in r1522, thanks.
I changed 'struct flashchip *flash' to 'struct flashctx *flash' so that
it compiles.
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
Hi,
On Mon, Mar 26, 2012 at 12:58:40AM -0700, Cole Byre wrote:
> Hello. I used the Linux command sudo apt-get install flashrom to get
> flashrom on Linux mint..but when I run sudo flashrom, it tells me its
> version 0.9.4..which is outdated. What is the command to download the
> latest version of flashrom?
Depends on your distribution. If the version is outdated, the package
maintainers have to upgrade to a newer flashrom, and/or you have to upgrade
to a more recent version of your distribution.
Alternatively, you can also build flashrom manually from source code.
See http://flashrom.org/Downloads.
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
Add -I/usr/pkg/include to NetBSD/Dragon Fly build example CPPFLAGS.
This is needed to pick up libftdi.
Signed-off-by: Jonathan A. Kollasch <jakllsch(a)kollasch.net>