On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
Hello to community,
I finally, after 3 days of additional very hard struggle, found out why I have (while I am in the last stage of building CBFS) nonsense while building APL-I Coreboot coreboot.rom?!
Please, read carefully this announcement.
For last three days I came to hard stop because of this failure:
Just quick look into the final failure (all passed, but last stage - IFD failed):
Compile IFDTOOL HOSTCC util/ifdfake/ifdfake DD Adding Intel Firmware Descriptor IFDTOOL Unlocking Management EngineFile build/coreboot.pre is 8388608 bytes No Flash Descriptor found in this image *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target 'add_intel_firmware' failed* *make: *** [add_intel_firmware] Error 1* [user@localhost coreboot]$
At first, I suspect that culprit my .config file, but I have checked it several times (maybe > dozen), and I could NOT find any problem with it (except minor doubts).
Then I switched to inspect -southbridge- setup, but these is none, since (simplified explanation/view) APL-I is SoC.
The next phase was to inspect *src/southbridge/intel/common/firmware/Makefile.inc* , but there (although my make scripting is rusty) I could NOT find any problem...
Finally, somewhere around 2:00 AM I noticed/determined the root cause of the problem: the util/ifdtool/ifdtool.c, line: if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: APL-I_ FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool).
Looks like this [VERY IMPORTANT] Announcement is about you, confusing two very different concepts. FSP is a binary program run by coreboot and has nothing in common with the Intel Firmware Descriptor. It's called *.fd for some reason I don't know, but I'm pretty sure it's another binary. The Firmware Descriptor describes some flash parameters and soft straps. It's just data, no program. You only need it as an OEM to build a full ROM image for a new system. If you have a system that already runs another firmware, you can just keep the existing descriptor in place.
Nico
On Wed, Feb 22, 2017 at 9:56 AM, Nico Huber nico.huber@secunet.com wrote:
On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
Hello to community,
I finally, after 3 days of additional very hard struggle, found out why I have (while I am in the last stage of building CBFS) nonsense while building APL-I Coreboot coreboot.rom?!
Please, read carefully this announcement.
For last three days I came to hard stop because of this failure:
Just quick look into the final failure (all passed, but last stage - IFD failed):
Compile IFDTOOL HOSTCC util/ifdfake/ifdfake DD Adding Intel Firmware Descriptor IFDTOOL Unlocking Management EngineFile build/coreboot.pre is 8388608 bytes No Flash Descriptor found in this image *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target 'add_intel_firmware' failed* *make: *** [add_intel_firmware] Error 1* [user@localhost coreboot]$
At first, I suspect that culprit my .config file, but I have checked it several times (maybe > dozen), and I could NOT find any problem with it (except minor doubts).
Then I switched to inspect -southbridge- setup, but these is none, since (simplified explanation/view) APL-I is SoC.
The next phase was to inspect *src/southbridge/intel/common/firmware/Makefile.inc* , but there (although my make scripting is rusty) I could NOT find any problem...
Finally, somewhere around 2:00 AM I noticed/determined the root cause of the problem: the util/ifdtool/ifdtool.c, line: if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: APL-I_ FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool).
Looks like this [VERY IMPORTANT] Announcement is about you, confusing two very different concepts. FSP is a binary program run by coreboot and has nothing in common with the Intel Firmware Descriptor. It's called *.fd for some reason I don't know, but I'm pretty sure it's another binary. The Firmware Descriptor describes some flash parameters and soft straps. It's just data, no program. You only need it as an OEM to build a full ROM image for a new system. If you have a system that already runs another firmware, you can just keep the existing descriptor in place.
I missed that bit. Yes, the .fd is just the extension FSP decided to use for their blob.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
I can admit my errors:
This is what I have:
user@localhost FspBin]$ pwd /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin [user@localhost FspBin]$ ls -al total 672 drwxr-xr-x. 2 user user 4096 Feb 11 12:19 . drwxr-xr-x. 6 user user 4096 Feb 11 12:19 .. -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf *-rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd* [user@localhost FspBin]$
I use one in *RED*.
Need the clarification. Please, do it for me.
Zoran
On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber nico.huber@secunet.com wrote:
On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
Hello to community,
I finally, after 3 days of additional very hard struggle, found out why I have (while I am in the last stage of building CBFS) nonsense while building APL-I Coreboot coreboot.rom?!
Please, read carefully this announcement.
For last three days I came to hard stop because of this failure:
Just quick look into the final failure (all passed, but last stage - IFD failed):
Compile IFDTOOL HOSTCC util/ifdfake/ifdfake DD Adding Intel Firmware Descriptor IFDTOOL Unlocking Management EngineFile build/coreboot.pre is 8388608 bytes No Flash Descriptor found in this image *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
target
'add_intel_firmware' failed* *make: *** [add_intel_firmware] Error 1* [user@localhost coreboot]$
At first, I suspect that culprit my .config file, but I have checked it several times (maybe > dozen), and I could NOT find any problem with it (except minor doubts).
Then I switched to inspect -southbridge- setup, but these is none, since (simplified explanation/view) APL-I is SoC.
The next phase was to inspect *src/southbridge/intel/common/firmware/Makefile.inc* , but there
(although
my make scripting is rusty) I could NOT find any problem...
Finally, somewhere around 2:00 AM I noticed/determined the root cause of the problem: the util/ifdtool/ifdtool.c, line: if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: APL-I_ FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool).
Looks like this [VERY IMPORTANT] Announcement is about you, confusing two very different concepts. FSP is a binary program run by coreboot and has nothing in common with the Intel Firmware Descriptor. It's called *.fd for some reason I don't know, but I'm pretty sure it's another binary. The Firmware Descriptor describes some flash parameters and soft straps. It's just data, no program. You only need it as an OEM to build a full ROM image for a new system. If you have a system that already runs another firmware, you can just keep the existing descriptor in place.
Nico
-
Aaron Durbin -
Nico Huber -
Zoran Stojsavljevic