[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: Quanta Freedom Firmware project
You've said these Quanta boards are a part of the OpenCompute project. That means, instead of looking for a proprietary BIOS workaround, these OCP boards - to match the OCP certification - should be ported to open source firmware (most likely, coreboot BIOS), considering the new requirements of OCP project regarding the firmware. Please take a look at https://www.opencompute.org/wiki/Open_System_Firmware/Checklist , document v1.1 from October 2020, and forward this info to your supervisor. вт, 7 дек. 2021 г. в 11:23, Billy Croan : > > 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... > > 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! > > 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? > > 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. > > So. What might I try to gain confidence that I can freely reboot these > machines again without them being bricked? > > When I tried flashing the originally captured firmware back on it, I got the > same error message as I got when I tried transplanting the firmwares. > > I did make sure that flashing the original firmware of each node back to them > didn't brick them first. And I did make sure the firmware files were the > same size to the byte on both of them. But it feels like the flash storage > is tainted now on GH-11 because it gets transaction errors now. > > Is there something I need to do to initialize the bios flashing chipset to > work properly? > > Here's lspci output: > 00:00.0 Host bridge [0600]: Intel Corporation 5500 I/O Hub to ESI Port > [8086:3403] (rev 22) > Subsystem: QUANTA Computer Inc Device [152d:8983] > Flags: fast devsel > Capabilities: [60] MSI: Enable- Count=1/2 Maskable+ 64bit- > Capabilities: [90] Express Root Port (Slot-), MSI 00 > Capabilities: [e0] Power
