Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
1) Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.otter@gmail.com wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I’ve been using, which doesn’t seem to play nice with my coreboot build. I’ve been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you’re right that there should be output in that case as well.
Right now I’m not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren’t, then I’d love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven’t looked into the details of that just yet.
Gerald
On 11 Jun 2014, at 04:09, Sean McNeil seanmcneil3@gmail.com wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
- Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP.
- Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.otter@gmail.com wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote:
Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I’ve been using, which doesn’t seem to play nice with my coreboot build. I’ve been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you’re right that there should be output in that case as well.
Right now I’m not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren’t, then I’d love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven’t looked into the details of that just yet. Gerald
On 11 Jun 2014, at 04:09, Sean McNeil <seanmcneil3@gmail.com mailto:seanmcneil3@gmail.com> wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
- Properly configured FSP for BayleyBay with the bct program.
BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter@gmail.com mailto:gerald.otter@gmail.com> wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list:coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Thanks a lot Sean, I’ll try out the TXE when I have something booting.
It looks like it goes through every FSP phase now except the ReadyToBoot phase. I’ve added the log ( debug log level ), configuration and rom layout as attachments.
I’ve gone through the log myself, but can’t really find anything out of the ordinary. The 4digit hex display shows the code 0110, after which the board shuts down. This is probably set by the FSP during the FspNotify call. There doesn’t really seem to be any documentation on the error codes used by the FSP, which is a shame. Hopefully someone knows what I might have missed here. Getting really close now!
Gerald
On 11 Jun 2014, at 12:12, Sean McNeil seanmcneil3@gmail.com wrote:
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote:
Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I’ve been using, which doesn’t seem to play nice with my coreboot build. I’ve been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you’re right that there should be output in that case as well.
Right now I’m not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren’t, then I’d love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven’t looked into the details of that just yet.
Gerald
On 11 Jun 2014, at 04:09, Sean McNeil seanmcneil3@gmail.com wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
- Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP.
- Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.otter@gmail.com wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Just a small update if anyone runs into the same issue: after replacing the soc with B2 stepping it seems to work fine. With the B0 soc it worked fine when disabling that notification stage.
Gerald
On 11 Jun 2014, at 15:00, Gerald Otter gerald.otter@gmail.com wrote:
Thanks a lot Sean, I’ll try out the TXE when I have something booting.
It looks like it goes through every FSP phase now except the ReadyToBoot phase. I’ve added the log ( debug log level ), configuration and rom layout as attachments.
I’ve gone through the log myself, but can’t really find anything out of the ordinary. The 4digit hex display shows the code 0110, after which the board shuts down. This is probably set by the FSP during the FspNotify call. There doesn’t really seem to be any documentation on the error codes used by the FSP, which is a shame. Hopefully someone knows what I might have missed here. Getting really close now!
Gerald
<rom.layout> <coreboot.config> <coreboot-crb.log>
On 11 Jun 2014, at 12:12, Sean McNeil seanmcneil3@gmail.com wrote:
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote:
Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I’ve been using, which doesn’t seem to play nice with my coreboot build. I’ve been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you’re right that there should be output in that case as well.
Right now I’m not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren’t, then I’d love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven’t looked into the details of that just yet.
Gerald
On 11 Jun 2014, at 04:09, Sean McNeil seanmcneil3@gmail.com wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
- Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP.
- Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter gerald.otter@gmail.com wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I recall someone on the list got B0 stepping to work by using different microcode. B0 will boot with the newer microcode, but as you discovered it hangs in the final notification phase. Actually, it reboots then hangs when it calls fsp init again.
Sean
On 06/11/2014 10:08 PM, Gerald Otter wrote:
Just a small update if anyone runs into the same issue: after replacing the soc with B2 stepping it seems to work fine. With the B0 soc it worked fine when disabling that notification stage.
Gerald
On 11 Jun 2014, at 15:00, Gerald Otter <gerald.otter@gmail.com mailto:gerald.otter@gmail.com> wrote:
Thanks a lot Sean, I’ll try out the TXE when I have something booting.
It looks like it goes through every FSP phase now except the ReadyToBoot phase. I’ve added the log ( debug log level ), configuration and rom layout as attachments.
I’ve gone through the log myself, but can’t really find anything out of the ordinary. The 4digit hex display shows the code 0110, after which the board shuts down. This is probably set by the FSP during the FspNotify call. There doesn’t really seem to be any documentation on the error codes used by the FSP, which is a shame. Hopefully someone knows what I might have missed here. Getting really close now!
Gerald
<rom.layout> <coreboot.config> <coreboot-crb.log>
On 11 Jun 2014, at 12:12, Sean McNeil <seanmcneil3@gmail.com mailto:seanmcneil3@gmail.com> wrote:
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote:
Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I’ve been using, which doesn’t seem to play nice with my coreboot build. I’ve been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you’re right that there should be output in that case as well.
Right now I’m not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren’t, then I’d love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven’t looked into the details of that just yet. Gerald
On 11 Jun 2014, at 04:09, Sean McNeil <seanmcneil3@gmail.com mailto:seanmcneil3@gmail.com> wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
- Properly configured FSP for BayleyBay with the bct program.
BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter@gmail.com mailto:gerald.otter@gmail.com> wrote: > Hi all, > > I am trying to run coreboot + seabios payload on the bayley bay > crb with the recently committed FSP integration, but have had no > luck so far. > This crb uses the bay trail I (now atom e3800) soc from intel. > > Following the instructions from commit d75800c7f , I have built > a 2MB image and flashed it to the upper 2MB of the 8MB flash, > leaving the TXE / flash descriptor intact. > I have added the config from the build. The FSP I used is > BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash > descriptor and TXE from the 80.21 bios provided by intel, and > vga bios 36.2.2. > Fwiw, I have tried both the 32bit and 64bit releases of the > bios, even though the flash descriptor and TXE binary seem to be > exactly the same. > > The issue I’m running into is that I have no idea if anything is > running at all. > There is no output on the VGA/HDMI ports or uart. > > The legacy uart referred to in the source is working correctly > with the original intel bios, but does not produce any output > with the coreboot image. > I have tried the most common baud rates (115200, 19200, 9600 ) > and did some measurements with a scope in case I got the baud > rate wrong, but no cigar. > The uart I’m using is the PCU uart, as opposed to hsuart1/2 and > the superIO uart. This matches with the configuration in > coreboot when compared to the datasheet, so I’m assuming I got > this set up correctly. > Unfortunately, this is about all the information I have, so I > hope I am missing something obvious when building the image / > flashing it, etc. > > I have also used intel’s flash image tool (fitc) to build a > complete image, thinking that maybe the flash descriptor needed > to contain some specific information regarding the coreboot > image (size/checksums), but given the original instructions I > wasn’t surprised this didn’t work. > > Thanks in advance! > > > -- > coreboot mailing list: coreboot@coreboot.org > mailto:coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list:coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Sean,
Would you have an IBL reference to that BYT-I_SEC_DUAL_BOOT_PV_GOLD file? I have a look and couldn't find it.
Regards,
Mike.
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Sean McNeil Sent: 11 June 2014 11:12 To: Gerald Otter Cc: coreboot@coreboot.org Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote: Hi all,
indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ).
I just found out this had to do with the particular intel flash descriptor/txe I've been using, which doesn't seem to play nice with my coreboot build. I've been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you're right that there should be output in that case as well.
Right now I'm not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren't, then I'd love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven't looked into the details of that just yet.
Gerald
On 11 Jun 2014, at 04:09, Sean McNeil <seanmcneil3@gmail.commailto:seanmcneil3@gmail.com> wrote:
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so something should have shown.
Other things you can check:
1) Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git.
Cheers, Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
Gerald,
Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image.
Marc
On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter@gmail.commailto:gerald.otter@gmail.com> wrote:
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I'm running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I'm using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I'm assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel's flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn't surprised this didn't work.
Thanks in advance!
-- coreboot mailing list: coreboot@coreboot.orgmailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.orgmailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
That would be 543843.
Cheers, Sean
On 06/11/2014 08:09 PM, Mike Hibbett wrote:
Hi Sean,
Would you have an IBL reference to that BYT-I_SEC_DUAL_BOOT_PV_GOLD file? I have a look and couldn't find it.
Regards,
Mike.
*From:*coreboot [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *Sean McNeil *Sent:* 11 June 2014 11:12 *To:* Gerald Otter *Cc:* coreboot@coreboot.org *Subject:* Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
Hi Gerald,
You should either erase the TXE area or replace it with the correct one from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE within BIOS will not play nice with anything except the BIOS.
Cheers, Sean
On 06/11/2014 03:16 PM, Gerald Otter wrote:
Hi all, indeed, I think I misinterpreted the original issue, which is not solely due to the wrong/lack of microcode being loaded. I did not get any output on port 80 ( all zeros ). I just found out this had to do with the particular intel flash descriptor/txe I've been using, which doesn't seem to play nice with my coreboot build. I've been in contact with someone outside of the list who sent me a working image after my initial e-mail. I flashed the build with microcode over the top 2MB of his image, after which my build worked fine. I assumed it was the microcode, when it was actually (partly) due to the wrong txe/fd. When the wrong microcode is loaded, the 4digit display alternates between 0x66 and 0x07, so you're right that there should be output in that case as well. Right now I'm not really sure what the differences are between the working fd/txe I have, and the non-working fd/txe. If there is any particular version of the txe/fd that is working while others aren't, then I'd love to know. Another option is to erase the fd and txe and just start it in non-descriptor mode. There are apparently some downsides to that, but I haven't looked into the details of that just yet. Gerald On 11 Jun 2014, at 04:09, Sean McNeil <seanmcneil3@gmail.com <mailto:seanmcneil3@gmail.com>> wrote: Hi Marc, There is indeed a port80 4 digit hex display on that board, so Gerald should be getting something from that. Hi Gerald, If you had serial output from the BIOS, then I think you probably have the UART connected properly. I always use the microUSB connector, though, with a standard phone cable to get serial from those boards. It has an on-board usb to serial adapter. Coreboot usually sets baud rate to 115200, but it is configurable. Check your .config: CONFIG_CONSOLE_SERIAL=y CONFIG_TTYS0_BASE=0x3f8 CONFIG_CONSOLE_SERIAL_115200=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_LCS=3 CONFIG_POST_IO=y CONFIG_POST_DEVICE=y CONFIG_POST_DEVICE_NONE=y CONFIG_POST_IO_PORT=0x80 Regardless of these settings, FSP will send info to the port80 so something should have shown. Other things you can check: 1) Properly configured FSP for BayleyBay with the bct program. BayleyBay is a non-ECC RAM board and won't boot with ECC FSP. 2) Have the appropriate microcode for your stepping of CPU. B0 steppings are harder to get correct and the microcode is not in git. Cheers, Sean On 06/11/2014 03:04 AM, Marc Jones wrote: Gerald, Does the crb have a port80? You should get early postcodes from coreboot and the FSP. You are also correct that there might be something different in the descriptor.bin that isn't anticipated. You may want to use the coreboot util/ifdtool to get a look at the entire image. Marc On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter@gmail.com <mailto:gerald.otter@gmail.com>> wrote: Hi all, I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel. Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same. The issue I'm running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart. The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I'm using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I'm assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc. I have also used intel's flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn't surprised this didn't work. Thanks in advance! -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list:coreboot@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot
-
Gerald Otter -
Mike Hibbett -
Sean McNeil