Hi,
I would like to test my -rt kernels releases on the minnowboard. Though cyclictest always reports 2 to 4 ms spikes. It looks like that the original firmware is stealing those cycles. So my plan was to try out coreboot and see if my theory is correct or not.
Now, I am struggling with getting anything working. All my attempts to bake a working binary have been completely fruitless. Not a single char on the serial port. If I would at least get something on the serial port I could find my way through the maze.
I am confident that flashing the device is works correctly via my raspberry pi [2]. When I flash the original firmware, the device comes back to live again.
Unfortunately, the documentation on how to configure and build coreboot a bit outdated [1]. My google-foo didn't help either.
Could someone share his/her current config and also post the SHAs of coreboot? This would rule out that part. I am not sure if my binary blobs I extracted or downloaded are okay (fd, me, gbe, FSB).
Thanks, Daniel
[1] https://elinux.org/Minnowboard:MinnowMaxCoreboot [2] https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-zer...
Hello Daniel,
You need to properly build Coreboot, integrating BYT-I (as I recall minnow board) FSP, and the info about BYT-I FSP you can find here: https://github.com/IntelFsp/FSP
Zoran _______
On Wed, Mar 21, 2018 at 12:47 PM, Daniel Wagner wagi@monom.org wrote:
Hi,
I would like to test my -rt kernels releases on the minnowboard. Though cyclictest always reports 2 to 4 ms spikes. It looks like that the original firmware is stealing those cycles. So my plan was to try out coreboot and see if my theory is correct or not.
Now, I am struggling with getting anything working. All my attempts to bake a working binary have been completely fruitless. Not a single char on the serial port. If I would at least get something on the serial port I could find my way through the maze.
I am confident that flashing the device is works correctly via my raspberry pi [2]. When I flash the original firmware, the device comes back to live again.
Unfortunately, the documentation on how to configure and build coreboot a bit outdated [1]. My google-foo didn't help either.
Could someone share his/her current config and also post the SHAs of coreboot? This would rule out that part. I am not sure if my binary blobs I extracted or downloaded are okay (fd, me, gbe, FSB).
Thanks, Daniel
[1] https://elinux.org/Minnowboard:MinnowMaxCoreboot [2] https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-zer...
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/21/2018 12:47 PM, Daniel Wagner wrote:
Hi,
Hello Daniel, thank you for reading 3mdeb blog :)
I would like to test my -rt kernels releases on the minnowboard. Though cyclictest always reports 2 to 4 ms spikes. It looks like that the original firmware is stealing those cycles. So my plan was to try out coreboot and see if my theory is correct or not.
Now, I am struggling with getting anything working. All my attempts to bake a working binary have been completely fruitless. Not a single char on the serial port. If I would at least get something on the serial port I could find my way through the maze.
MinnowBoard is already integrated. What board are you using ? Is this MinnowBoard Turbot B ?
We were able successfully build coreboot for that platform. What is important is flashing only coreboot region without damaging TXE because that makes platform unbootable.
We even prepared Dockerized environment:
$ docker pull 3mdeb/coreboot-trainings-sdk $ git clone https://review.coreboot.org/coreboot $ docker run --rm -it -v $PWD/coreboot:/home/coreboot/coreboot -w \ /home/coreboot/coreboot 3mdeb/coreboot-trainings-sdk /bin/bash (docker)$ make menuconfig
# select Mainboard vendor (Intel) # select Mainboard model (Minnow Max)
(docker) $ make -j$(nproc) (docker) $ cd util/ifdtool && make
Use compiled ifdtool against oryginal firmware that you flashed to the board:
$ ./util/ifdtool/ifdtool -f layout MNW2MAX1.X64.0097.D01.1709211100.bin
This will give you layout file similar to: 00000000:00000fff fd 00400000:007fffff bios 00001000:003fffff me 00000000:00000fff gbe
Then copy build/coreboot.rom and layout file to your RPi and flash:
(rpi) $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32000 -l \ layout -i bios -w /tmp/coreboot.rom
Our container have default FSP from GitHub which is not the most recent one. Latest you can obtain only through Intel RDC portal.
Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
Hi Piotr,
On 03/21/2018 09:49 PM, Piotr Król wrote:
thank you for reading 3mdeb blog :)
Thanks for taking time to write your findings up. Very useful.
MinnowBoard is already integrated. What board are you using ? Is this MinnowBoard Turbot B ?
It is the Turbot but I don't remember if it is B or not. I need to check this this evening.
We were able successfully build coreboot for that platform. What is important is flashing only coreboot region without damaging TXE because that makes platform unbootable.
Is the TXE code also part of the rom? I wonder why it is not showing up in the ifdtool output.
We even prepared Dockerized environment:
I haven't done the docker yet. If all fails I'll try it.
$ docker pull 3mdeb/coreboot-trainings-sdk $ git clone https://review.coreboot.org/coreboot $ docker run --rm -it -v $PWD/coreboot:/home/coreboot/coreboot -w \ /home/coreboot/coreboot 3mdeb/coreboot-trainings-sdk /bin/bash (docker)$ make menuconfig
# select Mainboard vendor (Intel) # select Mainboard model (Minnow Max)
(docker) $ make -j$(nproc) (docker) $ cd util/ifdtool && make
Use compiled ifdtool against oryginal firmware that you flashed to the board:
$ ./util/ifdtool/ifdtool -f layout MNW2MAX1.X64.0097.D01.1709211100.bin
This will give you layout file similar to: 00000000:00000fff fd 00400000:007fffff bios 00001000:003fffff me 00000000:00000fff gbe
I got this as well. Zoran just told me offline that fd and gbe seems to overlap. He also told me that the layout should be fd, gbe, me and finally bios. Is the ifdtool output correct?
Then copy build/coreboot.rom and layout file to your RPi and flash:
(rpi) $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32000 -l \ layout -i bios -w /tmp/coreboot.rom
Our container have default FSP from GitHub which is not the most recent one. Latest you can obtain only through Intel RDC portal.
I suppose the one from GitHub is good enough though? I don't have an RDC portal account.
Thanks, Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 03/22/2018 10:27 AM, Daniel Wagner wrote:
Hi Piotr,
Hi Daniel,
(...)
Is the TXE code also part of the rom? I wonder why it is not showing up in the ifdtool output.
It shows under position of ME. ME for Bay Trail is called TXE.
(...)
This will give you layout file similar to: 00000000:00000fff fd 00400000:007fffff bios 00001000:003fffff me 00000000:00000fff gbe
I got this as well. Zoran just told me offline that fd and gbe seems to overlap. He also told me that the layout should be fd, gbe, me and finally bios. Is the ifdtool output correct?
I also wonder about that. IMO there can be 2 things - incorrect parsing of flash descriptor by ifdtool or incorrect values in flash descriptor. This may be because this firmware doesn't have GbE firmware. I wondered what will happen if we apply different permissions to fd and gbe.
If you look at addresses bios is at the end. At least this layout works. How to interpret overlapping regions I don't know.
Then copy build/coreboot.rom and layout file to your RPi and flash:
(rpi) $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32000 -l \ layout -i bios -w /tmp/coreboot.rom
Our container have default FSP from GitHub which is not the most recent one. Latest you can obtain only through Intel RDC portal.
I suppose the one from GitHub is good enough though? I don't have an RDC portal account.
Yes. But if you would like to complain to Intel for performance related stuff they will say "please use recent one" and then you can complain on correct one :)
Best Regards, - -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com
It shows under position of ME. ME for Bay Trail is called TXE.
I need to intervene here. TXE is a security engine, doing in HW MD5, sha256, sha1024 signatures, and more. It is used for locking and factory programming the device, also. This has nothing to do with ME.
ME is completely different animal, and it lives in CORE, I am not sure if such a thing/ME exists in ATOM families. I would say rather not.
TXE supposed to be slim TXE, around 1.5MB, which is dormant one. The full blown TXE is around 3MB in size, IIRC.
There were essays written here about ME, please, find them, and start reading them,
The CORE families have on the lowest flash address (first 4KB) fd (file descriptor), followed by GbE, then by ME, and lastly comes BIOS (base 3MB BIOS + integrated TXE, vBIOS or GOP - CSM setting wise, proper MCU). For latest CORE families the flash is 16MB in size. Usually last 2MB or 3MB of flash are empty. Where Coreboot should be written. Written, but not written in the manner that parts of the BIOS are overwritten (the latest BIOS region is PCH soft straps table (for CORE, IIRC), which in BYT case is integrated in SoC, anyway),
There are more to it, since I start forgetting this stuff, but as I read these messages I start recalling. :-)
Zoran _______
Hi Piotr,
This will give you layout file similar to: 00000000:00000fff fd 00400000:007fffff bios 00001000:003fffff me 00000000:00000fff gbe
I got this as well. Zoran just told me offline that fd and gbe seems to overlap. He also told me that the layout should be fd, gbe, me and finally bios. Is the ifdtool output correct?
I also wonder about that. IMO there can be 2 things - incorrect parsing of flash descriptor by ifdtool or incorrect values in flash descriptor. This may be because this firmware doesn't have GbE firmware. I wondered what will happen if we apply different permissions to fd and gbe.
If you look at addresses bios is at the end. At least this layout works. How to interpret overlapping regions I don't know.
With your tip to flash only the bios section I have some success. There is debug output now on the serial console. It will hang eventually but that might just be, that I use an too old FSP.
Then copy build/coreboot.rom and layout file to your RPi and flash:
(rpi) $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32000 -l \ layout -i bios -w /tmp/coreboot.rom
Our container have default FSP from GitHub which is not the most recent one. Latest you can obtain only through Intel RDC portal.
I suppose the one from GitHub is good enough though? I don't have an RDC portal account.
Yes. But if you would like to complain to Intel for performance related stuff they will say "please use recent one" and then you can complain on correct one :)
Pretty bad job by Intel I'd say. Especially if the boss of OTC is proclaiming that the MinnowBoard is blob free.
/me starts searching for working FSP.
Thanks, Daniel
/me starts searching for working FSP.
With the current (BayTrailFspGold004_3) FSP from github and the microcode from the 3rdparty dir (3rdparty/soc/intel/baytrail/microcode_blob.h) I get it finally booting a Linux system.
Thanks for all the tips. Daniel
-
Daniel Wagner -
Piotr Król -
Zoran Stojsavljevic