verbose log of unsupported mainboard Foxconn Q45M
Hi there, we have a value of 150 machines with foxconn's Q45M. Last year we had to configure the bios settings of each machine by hand, because we were not able to deploy our bios settings to this mainboard in our standard way (boot via pxe, load a dos with a bios flash tool and an image of an configured bios and flash this image to the mainboard). Today i tried your flashrom tool (v0.9.5.2-r1515) build in parted magic but with no luck. I attached a verbose log of flashrom to this e-mail. Keep up the good work! Sincere regards, Marc Mendler ------------------------------ Statistisches Landesamt Baden-Württemberg Ref. 14 (Dezentrale Systemtechnik) Böblinger Str. 68 70199 Stuttgart Tel.: 0711/641-2827 Fax : 0711/641-2440 E-Mail: poststelle@stala.bwl.de Internet: www.statistik-bw.de ------------------------------
On Thu, 20 Sep 2012 12:12:50 +0200 "Mendler, Marc (STL)" <Marc.Mendler@stala.bwl.de> wrote:
Hi there,
we have a value of 150 machines with foxconn's Q45M. Last year we had to configure the bios settings of each machine by hand, because we were not able to deploy our bios settings to this mainboard in our standard way (boot via pxe, load a dos with a bios flash tool and an image of an configured bios and flash this image to the mainboard). Today i tried your flashrom tool (v0.9.5.2-r1515) build in parted magic but with no luck. I attached a verbose log of flashrom to this e-mail.
Keep up the good work!
0x5C: 0x026f0020 FREG2: WARNING: Management Engine region (0x00020000-0x0026ffff) is locked.
Hello Marc, thanks for your report! The problem is the locked ME region as quoted above. We are working on unlocking it, but intel does not provide us any documentation so please do not expect a complete solution soon. I have added the board to our list of (un)supported boards (with an appropriate note) and will commit that later together with other small changes. Normally the BIOS settings are not stored in the flash chip (but in NVRAM), although there is nothing stopping firmware vendors doing so. Usually flashing tools do not care about preserving, changing or resetting NVRAM contents and they are reset by the firmware itself if it detects a version mismatch on the first boot after the flashing. If the configuration data is really stored in flash on this board, i think the probability that they are stored in the platform region are quite high.
0x64: 0x027f0270 FREG4: Platform Data region (0x00270000-0x0027ffff) is read-write.
If that is true and you are only interested in saving and deploying this part, then we can supply you some patches and instructions for doing so. Please note that it is also possible that there is something completely different stored in there or a mix of configuration and e.g. serial numbers etc. If you want to use/try other tools, make sure that they support so called "hardware sequencing" to access the flash chips, since this is a hardware requirement on intel boards with two flash chips and the "normal" access method called "software sequencing" would not be able to access the second chip (which could lead to severe problems of course). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On 20/09/12 14:05, Stefan Tauner wrote:
Normally the BIOS settings are not stored in the flash chip (but in NVRAM), although there is nothing stopping firmware vendors doing so. Usually flashing tools do not care about preserving, changing or resetting NVRAM contents and they are reset by the firmware itself if it detects a version mismatch on the first boot after the flashing.
Just FYI, UEFI variables are stored in the flash by UEFI firmware. Almost nothing is stored in the CMOS NVRAM on modern PCs.
If the configuration data is really stored in flash on this board, i think the probability that they are stored in the platform region are quite high.
0x64: 0x027f0270 FREG4: Platform Data region (0x00270000-0x0027ffff) is read-write.
That is a pure guess based on no evidence, AFAICT. It is quite easy to find the UEFI variables in the flash image, once it has been read out, as the variable names are there in ASCII for those variables that have been set to non-default values. Andrew
On Thu, 20 Sep 2012 14:40:04 +0100 Andrew Goodbody <ajg4tadpole@gmail.com> wrote:
On 20/09/12 14:05, Stefan Tauner wrote:
Normally the BIOS settings are not stored in the flash chip (but in NVRAM), although there is nothing stopping firmware vendors doing so. Usually flashing tools do not care about preserving, changing or resetting NVRAM contents and they are reset by the firmware itself if it detects a version mismatch on the first boot after the flashing.
Just FYI, UEFI variables are stored in the flash by UEFI firmware. Almost nothing is stored in the CMOS NVRAM on modern PCs.
If the configuration data is really stored in flash on this board, i think the probability that they are stored in the platform region are quite high.
0x64: 0x027f0270 FREG4: Platform Data region (0x00270000-0x0027ffff) is read-write.
That is a pure guess based on no evidence, AFAICT. It is quite easy to find the UEFI variables in the flash image, once it has been read out, as the variable names are there in ASCII for those variables that have been set to non-default values.
Right. And the Q45M seems to use UEFI. In that case the locked ME firmware remains the major obstacle, because we still don't know if the ME requires to be updated together with the BIOS region *in general*. In the case of the Q45M, the latest firmware update archive contains different binaries: (presumably) image of the whole flash space, images for each flash chip, and one image for the BIOS region only. The interesting bit is that the batch file included uses only the latter to write to the BIOS region. So i think it is safe to assume, that updating that region only is ok, which makes flashrom (including my layout patches) suitable for the job of reading the (updated, and configured) region out and deploying it on the other machines. Marc: you said you tried that before with your DOS-based setup. Which tool did you try? The DOS version of fpt.exe? What did not work exactly? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hello Stefan, Thursday, September 20, 2012, 10:50:39 PM, you wrote:
That is a pure guess based on no evidence, AFAICT. It is quite easy to find the UEFI variables in the flash image, once it has been read out, as the variable names are there in ASCII for those variables that have been set to non-default values.
ST> Right. And the Q45M seems to use UEFI. ST> In that case the locked ME firmware remains the major obstacle, because ST> we still don't know if the ME requires to be updated together with the ST> BIOS region *in general*. No, ME is very rarely (never?) updated together with the BIOS; usually it's either a separate update (using Intel's FWUpdLcl.exe and a specially-packaged ME image) or another elaborate step (e.g. MSI P67A-G43 ME7 to ME8 update involves an EFI module inside the BIOS). ST> In the case of the Q45M, the latest firmware update archive contains ST> different binaries: (presumably) image of the whole flash space, images ST> for each flash chip, and one image for the BIOS region only. ST> The interesting bit is that the batch file included uses only the latter ST> to write to the BIOS region. So i think it is safe to assume, that ST> updating that region only is ok, which makes flashrom (including my ST> layout patches) suitable for the job of reading the (updated, and ST> configured) region out and deploying it on the other machines. I think it makes sense to just update the BIOS region for the descriptor-based flashes; AFAIK that's what all other tools do. Another good feature would be to detect the NVAR partition and skip it when flashing. -- WBR, roxfan mailto:roxfan@skynet.be
On Fri, 21 Sep 2012 06:34:28 +0200 roxfan <roxfan@skynet.be> wrote:
Thursday, September 20, 2012, 10:50:39 PM, you wrote:
That is a pure guess based on no evidence, AFAICT. It is quite easy to find the UEFI variables in the flash image, once it has been read out, as the variable names are there in ASCII for those variables that have been set to non-default values.
ST> Right. And the Q45M seems to use UEFI. ST> In that case the locked ME firmware remains the major obstacle, because ST> we still don't know if the ME requires to be updated together with the ST> BIOS region *in general*.
No, ME is very rarely (never?) updated together with the BIOS; usually it's either a separate update (using Intel's FWUpdLcl.exe and a specially-packaged ME image) or another elaborate step (e.g. MSI P67A-G43 ME7 to ME8 update involves an EFI module inside the BIOS).
ST> In the case of the Q45M, the latest firmware update archive contains ST> different binaries: (presumably) image of the whole flash space, images ST> for each flash chip, and one image for the BIOS region only. ST> The interesting bit is that the batch file included uses only the latter ST> to write to the BIOS region. So i think it is safe to assume, that ST> updating that region only is ok, which makes flashrom (including my ST> layout patches) suitable for the job of reading the (updated, and ST> configured) region out and deploying it on the other machines.
I think it makes sense to just update the BIOS region for the descriptor-based flashes; AFAIK that's what all other tools do.
those elaborate schemes mentioned above are what worries me. flashrom is a very generic tool, that does not look at the image contents as much as possible. users have broken hardware in much less obscure situations (and in most of those they were to blame themselves). just ignoring the ME region completely without any safeguard is not an option. David proposed this before (and chromium uses it), but i don't deem this to be safe enough for upstream. we can not expect users to foresee the occasions where ignoring the ME would brick the hardware. you were talking about other tools, which? don't they care for the image contents at all (like flashrom) either and work on so many different machines? ;)
Another good feature would be to detect the NVAR partition and skip it when flashing.
not automatically, but in the long term we will need some elaborate mechanism to create layout information from a) images (and flash contents) b) programmers c) chips since there is so little work done ATM, i don't see a way to make substantial progress in the near future. one thing where you (roxfan) could play a major role is in developing bios_extract further into something that a flashing application can use together with libflashrom. the general workflow of that application would be something like: - get existing content with libflashrom - retrieve layout and other information from the hardware and the read content - take the new image and extract, check, modify it together with the information above to create the image and layout information we really want to flash - write and verify with libflashrom the 3. step is what i want to keep out of (lib)flashrom as much as possible. providing necessary information via an API is of course ok. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi, thanks for your fast reply! I tried the DOS version of fpt.exe. With it i was able to save the bios to an image file and restore it on another computer, but the configured settings are lost (bad checksum, load default values, etc.) On older machines/mainboards (without efi/uefi) i worked with a tool called uniflash (http://www.rainbow-software.org/uniflash/). It stores the cmos settings to a file and can restore these on other machines. So it's a perfekt tool for deploying cmos settings to a huge anmount of machines. I red in the manual of the Q45M, that it is possible to disable the intel management engine with a jumper setting on the board. Do you think this makes a difference to the actual problem? Kind regards / Mit freundlichen Grüßen Marc -----Ursprüngliche Nachricht----- Von: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Gesendet: Donnerstag, 20. September 2012 22:51 An: Mendler, Marc (STL) Cc: flashrom@flashrom.org Betreff: Re: [flashrom] verbose log of unsupported mainboard Foxconn Q45M On Thu, 20 Sep 2012 14:40:04 +0100 Andrew Goodbody <ajg4tadpole@gmail.com> wrote:
On 20/09/12 14:05, Stefan Tauner wrote:
Normally the BIOS settings are not stored in the flash chip (but in NVRAM), although there is nothing stopping firmware vendors doing so. Usually flashing tools do not care about preserving, changing or resetting NVRAM contents and they are reset by the firmware itself if it detects a version mismatch on the first boot after the flashing.
Just FYI, UEFI variables are stored in the flash by UEFI firmware. Almost nothing is stored in the CMOS NVRAM on modern PCs.
If the configuration data is really stored in flash on this board, i think the probability that they are stored in the platform region are quite high.
0x64: 0x027f0270 FREG4: Platform Data region (0x00270000-0x0027ffff) is read-write.
That is a pure guess based on no evidence, AFAICT. It is quite easy to find the UEFI variables in the flash image, once it has been read out, as the variable names are there in ASCII for those variables that have been set to non-default values.
Right. And the Q45M seems to use UEFI. In that case the locked ME firmware remains the major obstacle, because we still don't know if the ME requires to be updated together with the BIOS region *in general*. In the case of the Q45M, the latest firmware update archive contains different binaries: (presumably) image of the whole flash space, images for each flash chip, and one image for the BIOS region only. The interesting bit is that the batch file included uses only the latter to write to the BIOS region. So i think it is safe to assume, that updating that region only is ok, which makes flashrom (including my layout patches) suitable for the job of reading the (updated, and configured) region out and deploying it on the other machines. Marc: you said you tried that before with your DOS-based setup. Which tool did you try? The DOS version of fpt.exe? What did not work exactly? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Fri, 21 Sep 2012 10:22:03 +0200 "Mendler, Marc (STL)" <Marc.Mendler@stala.bwl.de> wrote:
thanks for your fast reply! I tried the DOS version of fpt.exe. With it i was able to save the bios to an image file and restore it on another computer, but the configured settings are lost (bad checksum, load default values, etc.) On older machines/mainboards (without efi/uefi) i worked with a tool called uniflash (http://www.rainbow-software.org/uniflash/). It stores the cmos settings to a file and can restore these on other machines. So it's a perfekt tool for deploying cmos settings to a huge anmount of machines.
the code to read out traditional "cmos" memory is pretty easy and short afaik, no need for a dos application (although uniflash is or at least was one of the better ones i have used in the past :)
I red in the manual of the Q45M, that it is possible to disable the intel management engine with a jumper setting on the board. Do you think this makes a difference to the actual problem?
there are two problems that i currently see: 1. flashrom plays safe whenever it notices read-protected regions on intel hardware and bails out. this can be dealt with with existing patches that just were not merged yet. i don't think that this would change anything regarding the second problem though and if you are happy with your dos-based solution there is no reason to not use fpt.exe. 2. the configuration of your board is either not stored (completely) in the bios region or it is somehow bound to the machine (or some other problem i don't grasp). neither of both would be solved by disabling the ME with the jumper i think. there is no harm to try it though. something else you could try is to deploy the platform region (which i was talking about in my first mail) too together with the bios region. maybe my guess in the first mail wasn't that wrong after all. i can't remember the right syntax for fpt to operate on the platfrom region, but IIRC it prints some useful usage information on -h or /? or something... be sure to backup the old content of the platform region! if that does not help either, i am out of ideas and someone would need to look at the actual bios code more closely. asking the vendor will probably not help, but i would nevertheless try it. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi,
neither of both would be solved by disabling the ME with the jumper i think. there is no harm to try it though.
something else you could try is to deploy the platform region (which i was talking about in my first mail) too together with the bios region. maybe my guess in the first mail wasn't that wrong after all.
I will try that next week. I'm back in the office on Thursday, so i will inform you about the results next Friday i guess ;-) Thank you and have a nice weekend! Kind regards/Mit freundlichen Grüßen Marc -----Ursprüngliche Nachricht----- Von: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Gesendet: Freitag, 21. September 2012 17:08 An: Mendler, Marc (STL) Cc: flashrom@flashrom.org Betreff: Re: [flashrom] verbose log of unsupported mainboard Foxconn Q45M On Fri, 21 Sep 2012 10:22:03 +0200 "Mendler, Marc (STL)" <Marc.Mendler@stala.bwl.de> wrote:
thanks for your fast reply! I tried the DOS version of fpt.exe. With it i was able to save the bios to an image file and restore it on another computer, but the configured settings are lost (bad checksum, load default values, etc.) On older machines/mainboards (without efi/uefi) i worked with a tool called uniflash (http://www.rainbow-software.org/uniflash/). It stores the cmos settings to a file and can restore these on other machines. So it's a perfekt tool for deploying cmos settings to a huge anmount of machines.
the code to read out traditional "cmos" memory is pretty easy and short afaik, no need for a dos application (although uniflash is or at least was one of the better ones i have used in the past :)
I red in the manual of the Q45M, that it is possible to disable the intel management engine with a jumper setting on the board. Do you think this makes a difference to the actual problem?
there are two problems that i currently see: 1. flashrom plays safe whenever it notices read-protected regions on intel hardware and bails out. this can be dealt with with existing patches that just were not merged yet. i don't think that this would change anything regarding the second problem though and if you are happy with your dos-based solution there is no reason to not use fpt.exe. 2. the configuration of your board is either not stored (completely) in the bios region or it is somehow bound to the machine (or some other problem i don't grasp). neither of both would be solved by disabling the ME with the jumper i think. there is no harm to try it though. something else you could try is to deploy the platform region (which i was talking about in my first mail) too together with the bios region. maybe my guess in the first mail wasn't that wrong after all. i can't remember the right syntax for fpt to operate on the platfrom region, but IIRC it prints some useful usage information on -h or /? or something... be sure to backup the old content of the platform region! if that does not help either, i am out of ideas and someone would need to look at the actual bios code more closely. asking the vendor will probably not help, but i would nevertheless try it. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi, thank you for your hint! With fpt.exe i was able to copy the whole bios with all settings to another machine. The correct syntax for dumping the bios is "fpt.exe -d filename.ext -bios". The only thing i don't like about this solution is, that you have to "flash" the whole bios (not only the "cmos" memory) on the target machine. This can be dangerous for mass deployment in case of a power failure or something like that... Is there a chance to read only the "cmos" when i know the correct register and adress ranges (with flashrom)? kind regards/Mit freundlichen Grüßen Marc -----Ursprüngliche Nachricht----- Von: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Gesendet: Freitag, 21. September 2012 17:08 An: Mendler, Marc (STL) Cc: flashrom@flashrom.org Betreff: Re: [flashrom] verbose log of unsupported mainboard Foxconn Q45M On Fri, 21 Sep 2012 10:22:03 +0200 "Mendler, Marc (STL)" <Marc.Mendler@stala.bwl.de> wrote:
thanks for your fast reply! I tried the DOS version of fpt.exe. With it i was able to save the bios to an image file and restore it on another computer, but the configured settings are lost (bad checksum, load default values, etc.) On older machines/mainboards (without efi/uefi) i worked with a tool called uniflash (http://www.rainbow-software.org/uniflash/). It stores the cmos settings to a file and can restore these on other machines. So it's a perfekt tool for deploying cmos settings to a huge anmount of machines.
the code to read out traditional "cmos" memory is pretty easy and short afaik, no need for a dos application (although uniflash is or at least was one of the better ones i have used in the past :)
I red in the manual of the Q45M, that it is possible to disable the intel management engine with a jumper setting on the board. Do you think this makes a difference to the actual problem?
there are two problems that i currently see: 1. flashrom plays safe whenever it notices read-protected regions on intel hardware and bails out. this can be dealt with with existing patches that just were not merged yet. i don't think that this would change anything regarding the second problem though and if you are happy with your dos-based solution there is no reason to not use fpt.exe. 2. the configuration of your board is either not stored (completely) in the bios region or it is somehow bound to the machine (or some other problem i don't grasp). neither of both would be solved by disabling the ME with the jumper i think. there is no harm to try it though. something else you could try is to deploy the platform region (which i was talking about in my first mail) too together with the bios region. maybe my guess in the first mail wasn't that wrong after all. i can't remember the right syntax for fpt to operate on the platfrom region, but IIRC it prints some useful usage information on -h or /? or something... be sure to backup the old content of the platform region! if that does not help either, i am out of ideas and someone would need to look at the actual bios code more closely. asking the vendor will probably not help, but i would nevertheless try it. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Mon, 1 Oct 2012 15:42:40 +0200 "Mendler, Marc (STL)" <Marc.Mendler@stala.bwl.de> wrote:
Hi,
thank you for your hint! With fpt.exe i was able to copy the whole bios with all settings to another machine. The correct syntax for dumping the bios is "fpt.exe -d filename.ext -bios".
how is that different to what you did before, described by you like this:
thanks for your fast reply! I tried the DOS version of fpt.exe. With it i was able to save the bios to an image file and restore it on another computer, but the configured settings are lost (bad checksum, load default values, etc.)
what did you do differently?
The only thing i don't like about this solution is, that you have to "flash" the whole bios (not only the "cmos" memory) on the target machine. This can be dangerous for mass deployment in case of a power failure or something like that... Is there a chance to read only the "cmos" when i know the correct register and adress ranges (with flashrom)?
flashrom operates on the flash memory only. if the data you need to copy is stored in it, then yes, flashrom can read and write user-specified address ranges (you need some patches though, this functionality is not in the released code yet, as mentioned previously). if you require real CMOS data too, then you would need to use a second tool and e.g. create a script that calls both. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
participants (4)
-
Andrew Goodbody -
Mendler, Marc (STL) -
roxfan -
Stefan Tauner