Flash Access on Shuttle XH170V failed

[Michael Fuckner]

Hi,

I added PCI ID for my chipset, but I can't access/ read FLash chip. Any 
idea how to proceed?

Regards,
  Michael!


[root@revo flashrom]# diff chipset_enable.c.bak chipset_enable.c
1783a1784
          {0x8086, 0xa144, NT,  "Intel",
"Sunrise Point-H",
   enable_flash_pch9},
-------------------------------------------------------

[root@revo flashrom]# ./flashrom -V -p internal
flashrom v0.9.9-r1954 on Linux 4.9.13-201.fc25.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

flashrom was built with libpci 3.5.4, GCC 6.3.1 20161221 (Red Hat 
6.3.1-1), little endian
Command line (3 args): ./flashrom -V -p internal
Calibrating delay loop... OS timer resolution is 1 usecs, 2789M loops 
per second, 10 myus = 10 us, 100 myus = 104 us, 1000 myus = 1014 us, 
10000 myus = 10007 us, 4 myus = 4 us, OK.
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "Shuttle Inc."
DMI string system-product-name: "XH170"
DMI string system-version: "V1.0"
DMI string baseboard-manufacturer: "Shuttle Inc."
DMI string baseboard-product-name: "FH170"
DMI string baseboard-version: "1.0"
Found ITE Super I/O, ID 0x8772 on port 0x2e
Found chipset "Intel Sunrise Point-H" with PCI ID 8086:a144.
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(a)flashrom.org including a verbose 
(-V) log.
Thank you!
Enabling flash write... Root Complex Register Block address = 0x0
Error accessing ICH RCRB, 0x4000 bytes at 0x0000000000000000
/dev/mem mmap failed: Resource temporarily unavailable
FAILED!
FATAL ERROR!
Error: Programmer initialization failed.

[Nico Huber]

Hi Michael,

On 21.03.2017 20:48, Michael Fuckner wrote:
  Hi,
 
 I added PCI ID for my chipset, but I can't access/ read FLash chip. Any
 idea how to proceed?
if you compare the datasheets, you'll see that it's incompatible with
the 9series PCH.

I'm currently working on upstream support for the Sunrise Point PCH [1].
It's not working yet on my system. But if you want to try it out / help
me debugging remaining issues, here's how you can fetch the code:

  $ git clone https://review.coreboot.org/flashrom
  $ cd flashrom
  $ git fetch https://review.coreboot.org/flashrom
refs/changes/40/18940/1 && git checkout FETCH_HEAD

You'd still have to set your chipset to NT instead of BAD in
chipset_enable.c.

Nico

PS. You can also try the chromiumos fork of flashrom (can't give you
    build instructions though).

[1] Tip of my branch: https://review.coreboot.org/#/c/18940/

  
 Regards,
  Michael!
 
 
 [root@revo flashrom]# diff chipset_enable.c.bak chipset_enable.c
 1783a1784
          {0x8086, 0xa144, NT,  "Intel",
"Sunrise Point-H",
 enable_flash_pch9},
 -------------------------------------------------------
 
 [root@revo flashrom]# ./flashrom -V -p internal
 flashrom v0.9.9-r1954 on Linux 4.9.13-201.fc25.x86_64 (x86_64)
 flashrom is free software, get the source code at https://flashrom.org
 
 flashrom was built with libpci 3.5.4, GCC 6.3.1 20161221 (Red Hat
 6.3.1-1), little endian
 Command line (3 args): ./flashrom -V -p internal
 Calibrating delay loop... OS timer resolution is 1 usecs, 2789M loops
 per second, 10 myus = 10 us, 100 myus = 104 us, 1000 myus = 1014 us,
 10000 myus = 10007 us, 4 myus = 4 us, OK.
 Initializing internal programmer
 No coreboot table found.
 Using Internal DMI decoder.
 DMI string chassis-type: "Desktop"
 DMI string system-manufacturer: "Shuttle Inc."
 DMI string system-product-name: "XH170"
 DMI string system-version: "V1.0"
 DMI string baseboard-manufacturer: "Shuttle Inc."
 DMI string baseboard-product-name: "FH170"
 DMI string baseboard-version: "1.0"
 Found ITE Super I/O, ID 0x8772 on port 0x2e
 Found chipset "Intel Sunrise Point-H" with PCI ID 8086:a144.
 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(a)flashrom.org including a verbose
 (-V) log.
 Thank you!
 Enabling flash write... Root Complex Register Block address = 0x0
 Error accessing ICH RCRB, 0x4000 bytes at 0x0000000000000000
 /dev/mem mmap failed: Resource temporarily unavailable
 FAILED!
 FATAL ERROR!
 Error: Programmer initialization failed.
 
 _______________________________________________
 flashrom mailing list
 flashrom(a)flashrom.org
 https://www.flashrom.org/mailman/listinfo/flashrom

[Michael Fuckner]

Hi,

just tried it- this Board uses a Winbond 25Q64FV (64Mbit) and after 
reading there is an 8MB file, but it is empty. Anything else I should try?

molli123@revo:~/beta/flashrom > xxd flash.bin | head -n 5
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Regards,
  Michael!

On 3/22/2017 1:08 PM, Nico Huber wrote:
  Hi Michael,

 On 21.03.2017 20:48, Michael Fuckner wrote:
  Hi,

 I added PCI ID for my chipset, but I can't access/ read FLash chip. Any
 idea how to proceed?
 if you compare the datasheets, you'll see that it's incompatible with
 the 9series PCH.

 I'm currently working on upstream support for the Sunrise Point PCH [1].
 It's not working yet on my system. But if you want to try it out / help
 me debugging remaining issues, here's how you can fetch the code:

   $ git clone https://review.coreboot.org/flashrom
   $ cd flashrom
   $ git fetch https://review.coreboot.org/flashrom
 refs/changes/40/18940/1 && git checkout FETCH_HEAD

 You'd still have to set your chipset to NT instead of BAD in
 chipset_enable.c.

 Nico

 PS. You can also try the chromiumos fork of flashrom (can't give you
     build instructions though).

 [1] Tip of my branch: https://review.coreboot.org/#/c/18940/

 
 Regards,
  Michael!


 [root@revo flashrom]# diff chipset_enable.c.bak chipset_enable.c
 1783a1784
          {0x8086, 0xa144, NT,  "Intel",
"Sunrise Point-H",
 enable_flash_pch9},
 -------------------------------------------------------

 [root@revo flashrom]# ./flashrom -V -p internal
 flashrom v0.9.9-r1954 on Linux 4.9.13-201.fc25.x86_64 (x86_64)
 flashrom is free software, get the source code at https://flashrom.org

 flashrom was built with libpci 3.5.4, GCC 6.3.1 20161221 (Red Hat
 6.3.1-1), little endian
 Command line (3 args): ./flashrom -V -p internal
 Calibrating delay loop... OS timer resolution is 1 usecs, 2789M loops
 per second, 10 myus = 10 us, 100 myus = 104 us, 1000 myus = 1014 us,
 10000 myus = 10007 us, 4 myus = 4 us, OK.
 Initializing internal programmer
 No coreboot table found.
 Using Internal DMI decoder.
 DMI string chassis-type: "Desktop"
 DMI string system-manufacturer: "Shuttle Inc."
 DMI string system-product-name: "XH170"
 DMI string system-version: "V1.0"
 DMI string baseboard-manufacturer: "Shuttle Inc."
 DMI string baseboard-product-name: "FH170"
 DMI string baseboard-version: "1.0"
 Found ITE Super I/O, ID 0x8772 on port 0x2e
 Found chipset "Intel Sunrise Point-H" with PCI ID 8086:a144.
 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(a)flashrom.org including a verbose
 (-V) log.
 Thank you!
 Enabling flash write... Root Complex Register Block address = 0x0
 Error accessing ICH RCRB, 0x4000 bytes at 0x0000000000000000
 /dev/mem mmap failed: Resource temporarily unavailable
 FAILED!
 FATAL ERROR!
 Error: Programmer initialization failed.

 _______________________________________________
 flashrom mailing list
 flashrom(a)flashrom.org
 https://www.flashrom.org/mailman/listinfo/flashrom

[Nico Huber]

On 22.03.2017 16:13, Michael Fuckner wrote:
  Hi,
 
 just tried it- this Board uses a Winbond 25Q64FV (64Mbit) and after
 reading there is an 8MB file, but it is empty. Anything else I should try?
Same here, thanks for the log though :) Your flash controller seems
pretty unlocked. That feeds my suspicion that it's not the controller's
state that is causing trouble. I guess, I have to go back to the data-
sheet.

Btw, flashrom has an option `-o logfile` that makes it easier to catch
the output (e.g. you never miss the stderr messages).

Regards,
Nico

  
 molli123@revo:~/beta/flashrom > xxd flash.bin | head -n 5
 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 
 Regards,
  Michael!
 
 On 3/22/2017 1:08 PM, Nico Huber wrote:
  Hi Michael,

 On 21.03.2017 20:48, Michael Fuckner wrote:
  Hi,

 I added PCI ID for my chipset, but I can't access/ read FLash chip. Any
 idea how to proceed?
 if you compare the datasheets, you'll see that it's incompatible with
 the 9series PCH.

 I'm currently working on upstream support for the Sunrise Point PCH [1].
 It's not working yet on my system. But if you want to try it out / help
 me debugging remaining issues, here's how you can fetch the code:

   $ git clone https://review.coreboot.org/flashrom
   $ cd flashrom
   $ git fetch https://review.coreboot.org/flashrom
 refs/changes/40/18940/1 && git checkout FETCH_HEAD

 You'd still have to set your chipset to NT instead of BAD in
 chipset_enable.c.

 Nico

 PS. You can also try the chromiumos fork of flashrom (can't give you
     build instructions though).

 [1] Tip of my branch: https://review.coreboot.org/#/c/18940/

 
 Regards,
  Michael!


 [root@revo flashrom]# diff chipset_enable.c.bak chipset_enable.c
 1783a1784
          {0x8086, 0xa144, NT,  "Intel",
"Sunrise Point-H",
 enable_flash_pch9},
 -------------------------------------------------------

 [root@revo flashrom]# ./flashrom -V -p internal
 flashrom v0.9.9-r1954 on Linux 4.9.13-201.fc25.x86_64 (x86_64)
 flashrom is free software, get the source code at https://flashrom.org

 flashrom was built with libpci 3.5.4, GCC 6.3.1 20161221 (Red Hat
 6.3.1-1), little endian
 Command line (3 args): ./flashrom -V -p internal
 Calibrating delay loop... OS timer resolution is 1 usecs, 2789M loops
 per second, 10 myus = 10 us, 100 myus = 104 us, 1000 myus = 1014 us,
 10000 myus = 10007 us, 4 myus = 4 us, OK.
 Initializing internal programmer
 No coreboot table found.
 Using Internal DMI decoder.
 DMI string chassis-type: "Desktop"
 DMI string system-manufacturer: "Shuttle Inc."
 DMI string system-product-name: "XH170"
 DMI string system-version: "V1.0"
 DMI string baseboard-manufacturer: "Shuttle Inc."
 DMI string baseboard-product-name: "FH170"
 DMI string baseboard-version: "1.0"
 Found ITE Super I/O, ID 0x8772 on port 0x2e
 Found chipset "Intel Sunrise Point-H" with PCI ID 8086:a144.
 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(a)flashrom.org including a verbose
 (-V) log.
 Thank you!
 Enabling flash write... Root Complex Register Block address = 0x0
 Error accessing ICH RCRB, 0x4000 bytes at 0x0000000000000000
 /dev/mem mmap failed: Resource temporarily unavailable
 FAILED!
 FATAL ERROR!
 Error: Programmer initialization failed.

 _______________________________________________
 flashrom mailing list
 flashrom(a)flashrom.org
 https://www.flashrom.org/mailman/listinfo/flashrom

[Nico Huber]

Hi Michael,

On 22.03.2017 16:43, Nico Huber wrote:
  On 22.03.2017 16:13, Michael Fuckner wrote:
  Hi,

 just tried it- this Board uses a Winbond 25Q64FV (64Mbit) and after
 reading there is an 8MB file, but it is empty. Anything else I should try?
 
 Same here, thanks for the log though :) Your flash controller seems
 pretty unlocked. That feeds my suspicion that it's not the controller's
 state that is causing trouble. I guess, I have to go back to the data-
 sheet.
found some nits and one serious bit ==> it might work now :)

Here's my latest work:

git fetch https://review.coreboot.org/flashrom refs/changes/59/18959/1
&& git checkout FETCH_HEAD

One warning though: My platform is currently write protected so I
couldn't test erase/write yet. It might work, but it might also destroy
your flash contents.

Nico

[Michael Fuckner]

Hi,

I got a file, 8MB in size and it contains data. md5sum is not identical 
to original file and binwalk looks different on the beginning. The 
original file starts with 0x258988, so this is the area for ME and 
Ethernet Config?

Regards,
  Michael!



On 3/23/2017 5:39 PM, Nico Huber wrote:
  Hi Michael,

 On 22.03.2017 16:43, Nico Huber wrote:
  On 22.03.2017 16:13, Michael Fuckner wrote:
  Hi,

 just tried it- this Board uses a Winbond 25Q64FV (64Mbit) and after
 reading there is an 8MB file, but it is empty. Anything else I should try?
 Same here, thanks for the log though :) Your flash controller seems
 pretty unlocked. That feeds my suspicion that it's not the controller's
 state that is causing trouble. I guess, I have to go back to the data-
 sheet.
 found some nits and one serious bit ==> it might work now :)

 Here's my latest work:

 git fetch https://review.coreboot.org/flashrom refs/changes/59/18959/1
 && git checkout FETCH_HEAD

 One warning though: My platform is currently write protected so I
 couldn't test erase/write yet. It might work, but it might also destroy
 your flash contents.

 Nico

[Nico Huber]

On 23.03.2017 20:26, Michael Fuckner wrote:
  Hi,
 
 I got a file, 8MB in size and it contains data. md5sum is not identical
 to original file and binwalk looks different on the beginning.
Not sure, what an "original" file would be. The flash contains data that
is specific to your device like serial numbers, the MAC address etc.
Also, at least two of the firmwares in your flash are self-modifying
(ME, UEFI).

  The original file starts with 0x258988, so this is the
area for ME and
 Ethernet Config?
What is 0x258988 supposed to mean? an offset? I doubt that binwalk can
give any thorough report of the flash image though.

Let's have a look at your log:

  === Region Section ===
 FLREG0   0x00000000
 FLREG1   0x07ff0200
 FLREG2   0x005a0000
 FLREG3   0x5a000000
 FLREG4   0x00000000
 
 --- Details ---
 Region 0 (Descr.) 0x00000000 - 0x00000fff
 Region 1 (BIOS  ) 0x00200000 - 0x007fffff
 Region 2 (ME    ) 0x00000000 - 0x0005afff
 Region 3 (GbE   ) 0x00000000 - 0x01a00fff
 Region 4 (Platf.) 0x00000000 - 0x00000fff
This is part of the Firmware Descriptor, the first part of any modern
Intel flash image. Beside many other things it contains this partition
table. It looks very odd, with overlapping regions. I haven't looked
into changes in the descriptor for Skylake yet, maybe it's not decoded
correctly.

However if you want to verify your image you can try to decode the read
descriptor:

  $ make -Cutil/ich_descriptors_tool/
  $ util/ich_descriptors_tool/ich_descriptors_tool -f flash.bin

It should give you the same output that you can find in your log.

Thanks again for testing and your log, it's nice to see things working!
;)

Nico

[Michael Fuckner]

Hi,

I had to use flashrom and my raspi to reflash my bios chip after it got 
corrupted. Now I compare the original Firmware (XH170V00.200) I flashed 
into the Chip with the file I read (flash.bin).

I found the MAC Address in the File read (at 0x1000), so of course, the 
flash.bin is different from the original.

The descriptors look somewhat different from the information found in 
the log- here it is not overlapping

--- Details ---
Region 0 (Descr.) 0x00000000 - 0x00000fff
Region 1 (BIOS  ) 0x00200000 - 0x007fffff
Region 2 (ME    ) 0x00003000 - 0x001fffff
Region 3 (GbE   ) 0x00001000 - 0x00002fff
Region 4 (Platf.) is unused.

Should I upload you flash.bin somewhere?

Regards,
  Michael!


On 3/23/2017 10:36 PM, Nico Huber wrote:
  On 23.03.2017 20:26, Michael Fuckner wrote:
  Hi,

 I got a file, 8MB in size and it contains data. md5sum is not identical
 to original file and binwalk looks different on the beginning.
 Not sure, what an "original" file would be. The flash contains data that
 is specific to your device like serial numbers, the MAC address etc.
 Also, at least two of the firmwares in your flash are self-modifying
 (ME, UEFI).

  The original file starts with 0x258988, so this
is the area for ME and
 Ethernet Config?
 What is 0x258988 supposed to mean? an offset? I doubt that binwalk can
 give any thorough report of the flash image though.

 Let's have a look at your log:

  === Region Section ===
 FLREG0   0x00000000
 FLREG1   0x07ff0200
 FLREG2   0x005a0000
 FLREG3   0x5a000000
 FLREG4   0x00000000

 --- Details ---
 Region 0 (Descr.) 0x00000000 - 0x00000fff
 Region 1 (BIOS  ) 0x00200000 - 0x007fffff
 Region 2 (ME    ) 0x00000000 - 0x0005afff
 Region 3 (GbE   ) 0x00000000 - 0x01a00fff
 Region 4 (Platf.) 0x00000000 - 0x00000fff
 This is part of the Firmware Descriptor, the first part of any modern
 Intel flash image. Beside many other things it contains this partition
 table. It looks very odd, with overlapping regions. I haven't looked
 into changes in the descriptor for Skylake yet, maybe it's not decoded
 correctly.

 However if you want to verify your image you can try to decode the read
 descriptor:

   $ make -Cutil/ich_descriptors_tool/
   $ util/ich_descriptors_tool/ich_descriptors_tool -f flash.bin

 It should give you the same output that you can find in your log.

 Thanks again for testing and your log, it's nice to see things working!
 ;)

 Nico

[Nico Huber]

Hi Michael,

On 24.03.2017 15:14, Michael Fuckner wrote:
  Hi,
 
 I had to use flashrom and my raspi to reflash my bios chip after it got
 corrupted. Now I compare the original Firmware (XH170V00.200) I flashed
 into the Chip with the file I read (flash.bin).
 
 I found the MAC Address in the File read (at 0x1000), so of course, the
 flash.bin is different from the original.
 
 The descriptors look somewhat different from the information found in
 the log- here it is not overlapping
 
 --- Details ---
 Region 0 (Descr.) 0x00000000 - 0x00000fff
 Region 1 (BIOS  ) 0x00200000 - 0x007fffff
 Region 2 (ME    ) 0x00003000 - 0x001fffff
 Region 3 (GbE   ) 0x00001000 - 0x00002fff
 Region 4 (Platf.) is unused.
this looks sane. Another sign, that the reading was successful. I still
have to investigate, why flashrom reported this wrong. Both BIOS and ME
usually "log" data, so (per boot) changes in these regions are expected.

What I usually do to verify a flash read besides checking the descriptor
is looking at the last line (16B) of a hexdump. It usually starts with a
jump instruction, possibly prepended by no-ops. Mine starts with `90 90
e9`.

  
 Should I upload you flash.bin somewhere?
No, thanks.

Nico