Hello Everyone,
We are designing a mainboard powered by an EP80579 and I came across coreboot.
I've seen corebot v2 supports the Truxton EP80579 Development kit. However I cannot get any relevant information about Truxton.
Is this the "official" intel development kit (EP80579TRXDK) or something else? I wanted to order the exact board coreboot supports and use this as a reference design.
Could the people in charge of maintaining the EP80579 modules get back to me with this information?
The initial stage would be to have Windows/Linux running on our board followed by VxWorks. Anyone around here as already used coreboot to "boot" a Vxworks system?
Thank you!
Arnaud Maye Embedded Systems Manager. www.4dsp.com
* ** *
On Thu, Apr 16, 2009 at 2:40 AM, Arnaud Maye arnaud.maye@4dsp.com wrote:
We are designing a mainboard powered by an EP80579 and I came across coreboot.
I've seen corebot v2 supports the Truxton EP80579 Development kit. However I cannot get any relevant information about Truxton.
Is this the "official" intel development kit (EP80579TRXDK) or something else? I wanted to order the exact board coreboot supports and use this as a reference design.
Truxton is the mainboard in the official Intel EP80579 development kit.
--Ed
Hello Ed,
We have received the truxton board a few days ago.
I have compiled coreboot-v2 as well as FILO and created the rom image. I've placed the image in the flash using flashrom, everything there went smoothly.
I tried to launch the system but the system does not boot. Is coreboot on truxton supposed to output something to the G550 PCIe gfx card shipped along with the truxton mainboard or not? The default AMI bios is able to do that obviously.
The board state after a reboot is
1) No active VGA output 2) The two seven segments displays on the main board is display 80
I am still waiting my UART dongle so I cannot say if anything goes out from the com ports.
Is it a normal behavior Ed or my coreboot image is simply not working?
In advance, thank you for your pointers.
With my best regards,
Arnaud
Ed Swierk wrote:
On Thu, Apr 16, 2009 at 2:40 AM, Arnaud Maye arnaud.maye@4dsp.com wrote:
We are designing a mainboard powered by an EP80579 and I came across coreboot.
I've seen corebot v2 supports the Truxton EP80579 Development kit. However I cannot get any relevant information about Truxton.
Is this the "official" intel development kit (EP80579TRXDK) or something else? I wanted to order the exact board coreboot supports and use this as a reference design.
Truxton is the mainboard in the official Intel EP80579 development kit.
--Ed
* *
Hello Again,
I've just received my UART dongle and I could see that indeed something has been sent over UART.
The first error seen was about the fact only ECC DIMMs are allowed, in the devkit they provide non-ecc memory. Is it normal coreboot only supports ECC DIMMs?
I've then plugged some nice kingston DIMM with ecc and what I get then is an exception :
Unexpected Exception: 13 @ 10:00002f08 - Halting Code: 4096 eflags: 00010282 eax: 002163b6 ebx: 0000c000 ecx: 0000227e edx: fffffffe edi: 0000eb02 esi: 0000f444 ebp: 0000bebc esp: 0000bebc
As soon I get this exception, the 7 segments display : FF
I guess if this is the first thing I get, coreboot has a problem not the payload, right?
Could you tell me which coreboot version from the 1.3 tree you have been using when you validated the port?
Thank you.
Arnaud
Arnaud Maye wrote:
Hello Ed,
We have received the truxton board a few days ago.
I have compiled coreboot-v2 as well as FILO and created the rom image. I've placed the image in the flash using flashrom, everything there went smoothly.
I tried to launch the system but the system does not boot. Is coreboot on truxton supposed to output something to the G550 PCIe gfx card shipped along with the truxton mainboard or not? The default AMI bios is able to do that obviously.
The board state after a reboot is
- No active VGA output
- The two seven segments displays on the main board is display 80
I am still waiting my UART dongle so I cannot say if anything goes out from the com ports.
Is it a normal behavior Ed or my coreboot image is simply not working?
In advance, thank you for your pointers.
With my best regards,
Arnaud
Ed Swierk wrote:
On Thu, Apr 16, 2009 at 2:40 AM, Arnaud Maye arnaud.maye@4dsp.com wrote:
We are designing a mainboard powered by an EP80579 and I came across coreboot.
I've seen corebot v2 supports the Truxton EP80579 Development kit. However I cannot get any relevant information about Truxton.
Is this the "official" intel development kit (EP80579TRXDK) or something else? I wanted to order the exact board coreboot supports and use this as a reference design.
Truxton is the mainboard in the official Intel EP80579 development kit.
--Ed
* *
On Tue, Jun 16, 2009 at 7:24 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've just received my UART dongle and I could see that indeed something has been sent over UART.
The first error seen was about the fact only ECC DIMMs are allowed, in the devkit they provide non-ecc memory. Is it normal coreboot only supports ECC DIMMs?
No, but I never got around to implementing support for non-ECC DIMMs in the EP80579 raminit code. It shouldn't be too hard--I think you just need to note whether the DIMMs are ECC, and refrain from enabling ECC mode if they are. (You may want to keep ECC disabled anyway during debugging; until the DRAM is stable, ECC only makes the error behavior more complicated.)
I've then plugged some nice kingston DIMM with ecc and what I get then is an exception :
Unexpected Exception: 13 @ 10:00002f08 - Halting Code: 4096 eflags: 00010282 eax: 002163b6 ebx: 0000c000 ecx: 0000227e edx: fffffffe edi: 0000eb02 esi: 0000f444 ebp: 0000bebc esp: 0000bebc
As soon I get this exception, the 7 segments display : FF
I guess if this is the first thing I get, coreboot has a problem not the payload, right?
Could you tell me which coreboot version from the 1.3 tree you have been using when you validated the port?
I did the work somewhere around revision 3650 of the coreboot-v2 tree. However, I tested only a very limited number of DIMMs, and only at 667 speed, so I'm not surprised a random one doesn't work. Unfortunately there's no substitute for spending some quality time with the datasheet, beating the raminit settings into submission.
--Ed
Hello Again ED and others.
I've been able to go further but still a few strange things I am seeing. This is the last part of my log :
TC Init PNP: 004e.4 init PNP: 004e.5 init PCI: 00:1f.2 init SATA init SATA Enabled PCI: 00:1f.4 init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Intel device 10650 CPU: family 06, model 15, stepping 00 Enabling cache
Setting fixed MTRRs(0-88) Type: UC
After this either it hang or jump back to "Uncompressing coreboot to RAM" and then hang. It can as well loop "Uncompressing coreboot to RAM".
Could it still be related to wrong timing value set on the memory controller? I doubt about this because I have tried a lot of different DIMMs as well but the result same. Memory can be ECC or not, not much differences.
I've tried both FSB (400 and 533MHz) and both SKU ( 600 and 1200MHz (forced to 1060 as well).
What I can say as well is that depending where the PCIe GFX card is connected the boot process is very unstable. I know the build does not even use GFX output. Connecting the GFX card on the x16 PCIe slot is the more stable vector. By more stable I mean no strange unhandled exceptions.
I was trying to find in the sources where the hardware watchdog timer is enabled or disabled. Am not sure if this is something you have been taking care about during your dev or not, did you enable and set a value in the WDT or not.
Could you let as well which SKU you have been using, the 600 or 1200 and which BSEL/VSEL jumper selection you have on your board.
I would say that this is not related to the memory controller, especially because several FSB speeds, processor speed and memory speed does not make much difference.
The ep80579 raminit source file does write a "magic" value to the BUS0, DEV8 and FN 0 to the register 0xCC. Higher the DDR frequency is, higher the "magic" value is. I could not find anywhere in the EP80579 datasheet what is this "magic" peripheral.
A last thing is a bit before in the log is the following :
Initializing devices... Root Device init PCI: 00:00.0 init PCI: 00:00.1 init PCI: 00:01.0 init PCI: 00:1d.0 init PCI: 00:1d.7 init PCI: 00:1f.0 init set power on after power fail RTC Init
The power did not fail, the voltage did not even drop, I've been measuring this with an oscilloscope in here. Is it expected?
Probably a lot of people around here might answer these questions, if so, feel free to do so!
With my best regards,
Arnaud
Ed Swierk wrote:
On Tue, Jun 16, 2009 at 7:24 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've just received my UART dongle and I could see that indeed something has been sent over UART.
The first error seen was about the fact only ECC DIMMs are allowed, in the devkit they provide non-ecc memory. Is it normal coreboot only supports ECC DIMMs?
No, but I never got around to implementing support for non-ECC DIMMs in the EP80579 raminit code. It shouldn't be too hard--I think you just need to note whether the DIMMs are ECC, and refrain from enabling ECC mode if they are. (You may want to keep ECC disabled anyway during debugging; until the DRAM is stable, ECC only makes the error behavior more complicated.)
I've then plugged some nice kingston DIMM with ecc and what I get then is an exception :
Unexpected Exception: 13 @ 10:00002f08 - Halting Code: 4096 eflags: 00010282 eax: 002163b6 ebx: 0000c000 ecx: 0000227e edx: fffffffe edi: 0000eb02 esi: 0000f444 ebp: 0000bebc esp: 0000bebc
As soon I get this exception, the 7 segments display : FF
I guess if this is the first thing I get, coreboot has a problem not the payload, right?
Could you tell me which coreboot version from the 1.3 tree you have been using when you validated the port?
I did the work somewhere around revision 3650 of the coreboot-v2 tree. However, I tested only a very limited number of DIMMs, and only at 667 speed, so I'm not surprised a random one doesn't work. Unfortunately there's no substitute for spending some quality time with the datasheet, beating the raminit settings into submission.
--Ed
* *
I'm no expert on this board.
TC Init PNP: 004e.4 init PNP: 004e.5 init PCI: 00:1f.2 init SATA init SATA Enabled PCI: 00:1f.4 init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Intel device 10650 CPU: family 06, model 15, stepping 00 Enabling cache
Setting fixed MTRRs(0-88) Type: UC
After this either it hang or jump back to "Uncompressing coreboot to RAM" and then hang. It can as well loop "Uncompressing coreboot to RAM".
Could it still be related to wrong timing value set on the memory controller? I doubt about this because I have tried a lot of different DIMMs as well but the result same. Memory can be ECC or not, not much differences.
I don't think so. This is a long time after RAM gets set up.
I've tried both FSB (400 and 533MHz) and both SKU ( 600 and 1200MHz (forced to 1060 as well).
What I can say as well is that depending where the PCIe GFX card is connected the boot process is very unstable. I know the build does not even use GFX output. Connecting the GFX card on the x16 PCIe slot is the more stable vector. By more stable I mean no strange unhandled exceptions.
I think more information here could be helpful.
I was trying to find in the sources where the hardware watchdog timer is enabled or disabled. Am not sure if this is something you have been taking care about during your dev or not, did you enable and set a value in the WDT or not.
To see if the problem is the WDT, set the log level lower (less output) and see if it reboots at a different place. It will boot much faster with less output.
A last thing is a bit before in the log is the following :
...
set power on after power fail RTC Init
The power did not fail, the voltage did not even drop, I've been measuring this with an oscilloscope in here. Is it expected?
I think this line means that it's setting the option, so that when there is a power failure it will power back on. It doesn't mean that there's been a power failure.
Thanks, Myles
Hello Gents,
So I've been able to confirm that the WDT is not related to this issue as indeed, changing the debug level to something smaller does not change anything to my problem.
I've narrowed down the problem to the mtrr.c file in src/cpu/x86/mtrr/ in the function set_fixed_mtrrs().
The first time disable_cache() is called, the CPU gets "lost". It either hang or jump back to some code to hang a bit after.
Am not 100% sure but I would say that as soon we disable the cache, the processor is "forced" to execute from RAM and not from the cache itself, having this strange behavior here can still mean the memory controller settings are not correct, right?
Anyone of you encountered this issue? I have searched for a bit on google, but not much I could find about this besides unanswered posts.
Any help would be greatly appreciated.
Arnaud
Myles Watson wrote:
I'm no expert on this board.
TC Init PNP: 004e.4 init PNP: 004e.5 init PCI: 00:1f.2 init SATA init SATA Enabled PCI: 00:1f.4 init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Intel device 10650 CPU: family 06, model 15, stepping 00 Enabling cache
Setting fixed MTRRs(0-88) Type: UC
After this either it hang or jump back to "Uncompressing coreboot to RAM" and then hang. It can as well loop "Uncompressing coreboot to RAM".
Could it still be related to wrong timing value set on the memory controller? I doubt about this because I have tried a lot of different DIMMs as well but the result same. Memory can be ECC or not, not much differences.
I don't think so. This is a long time after RAM gets set up.
I've tried both FSB (400 and 533MHz) and both SKU ( 600 and 1200MHz (forced to 1060 as well).
What I can say as well is that depending where the PCIe GFX card is connected the boot process is very unstable. I know the build does not even use GFX output. Connecting the GFX card on the x16 PCIe slot is the more stable vector. By more stable I mean no strange unhandled exceptions.
I think more information here could be helpful.
I was trying to find in the sources where the hardware watchdog timer is enabled or disabled. Am not sure if this is something you have been taking care about during your dev or not, did you enable and set a value in the WDT or not.
To see if the problem is the WDT, set the log level lower (less output) and see if it reboots at a different place. It will boot much faster with less output.
A last thing is a bit before in the log is the following :
...
set power on after power fail RTC Init
The power did not fail, the voltage did not even drop, I've been measuring this with an oscilloscope in here. Is it expected?
I think this line means that it's setting the option, so that when there is a power failure it will power back on. It doesn't mean that there's been a power failure.
Thanks, Myles
* *
On Mon, Jun 22, 2009 at 5:06 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've narrowed down the problem to the mtrr.c file in src/cpu/x86/mtrr/ in the function set_fixed_mtrrs().
The first time disable_cache() is called, the CPU gets "lost". It either hang or jump back to some code to hang a bit after.
Am not 100% sure but I would say that as soon we disable the cache, the processor is "forced" to execute from RAM and not from the cache itself, having this strange behavior here can still mean the memory controller settings are not correct, right?
That does seems like symptom of memory controller misconfiguration.
I'd recommend you proceed by disabling ECC (comment out the "Set the ECC mode" line in raminit_ep80579.c) and enabling the ram_fill() and ram_verify() steps in auto.c. Adjust the parameters to fill and verify the entire memory range. This is a very simple test that should pass reliably before you try anything fancy like booting a payload.
--Ed
Good afternoon gents,
The ECC enable code has been fixed. It does enable the ECC when the DIMM has ECC.
I did enable the RAM check and indeed this showed miserable results. I've been trying to figure out the correct settings but so far they are not there! Trying a few BSEL/VSEL jumper settings with a couple of different DIMM we have here showed some decent results, the value I read back starts to look as the value I send.
I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of difference around the ODT register and such. So there is still some hope.
I will keep you guys updated as soon it is moving forward.
One thing I cannot figure out so far, is what the peripheral 0.8.0 is. This seems to be an non existing peripheral, this is the assumption I make so far. It is not documented in the EP80579 documentation. I am referring to raminit_ep80579.c function spd_set_drt_attributes().
val = (magic[index]); print_debug("magic = "); print_debug_hex32(val); print_debug("\r\n"); pci_write_config32(PCI_DEV(0, 0x08, 0), 0xcc, val);
So what is this magic value about and what the devnbr8 on bus0 is are the thing I would love to hear from you guys. It is clear that the magic value is different for given DDR memory frequency.
Thank you,
Arnaud
Ed Swierk wrote:
On Mon, Jun 22, 2009 at 5:06 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've narrowed down the problem to the mtrr.c file in src/cpu/x86/mtrr/ in the function set_fixed_mtrrs().
The first time disable_cache() is called, the CPU gets "lost". It either hang or jump back to some code to hang a bit after.
Am not 100% sure but I would say that as soon we disable the cache, the processor is "forced" to execute from RAM and not from the cache itself, having this strange behavior here can still mean the memory controller settings are not correct, right?
That does seems like symptom of memory controller misconfiguration.
I'd recommend you proceed by disabling ECC (comment out the "Set the ECC mode" line in raminit_ep80579.c) and enabling the ram_fill() and ram_verify() steps in auto.c. Adjust the parameters to fill and verify the entire memory range. This is a very simple test that should pass reliably before you try anything fancy like booting a payload.
--Ed
* *
On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of difference around the ODT register and such. So there is still some hope.
Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start.
Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave.
--Ed
On Wed, 24 Jun 2009 07:29:02 -0700, Ed Swierk eswierk@aristanetworks.com wrote:
On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of
difference
around the ODT register and such. So there is still some hope.
Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start.
Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave.
FYI, RCOMP (resistive compensation) is part of the Buffer Strength calculation. I far as I know there are no public docs explaining RCOMP but (hint:-)) there may possibly be patents that explain it.
Hey Gents,
So the 2T timings did the trick, phoooow!
This is fair enough. Actually, our final hardware is not having any DIMMs but the chipsets themselves mounted on the board. So anyway all the timings will need to be found again.
This is enough to allow me going forward with the dev until we get our protos!
As a side note, Intel and their "protection by obscurity". I am fighting for a bit more than one week to obtain an "orange cover" document from Intel :
*RS - Intel(R) EP80579 Integrated Processor Product Line BIOS/Firmware Writer's Guide
*They have asked us to sign a CNDA and now we are waiting to receive a RSNDA to maybe get this document.
I will be laughing if this document does not provide any key information finally.
We will see!
Thanks for all your support guys, I(we)'ve got it working even if the performance will not be as good as in 1T mode.
Arnaud
Joseph Smith wrote:
On Wed, 24 Jun 2009 07:29:02 -0700, Ed Swierk eswierk@aristanetworks.com wrote:
On Wed, Jun 24, 2009 at 6:36 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
I've tried a reverse engineer approach. Plug a DIMM into the system and launch Linux with the legacy BIOS. lspci -xxx then shows me the IMCH BAR and implicitly the settings doctored by the legacy BIOS. The first try I've done was to try the r-e DRT0/DRT1 in the coreboot RAM init code. Not much differences so far. But anyway I've seen quite a lot of
difference
around the ODT register and such. So there is still some hope.
Have you tried 2T timing? This causes the memory controller to wait an extra cycle before sending a command. The delay can compensate for slight misconfiguration of other signal timing settings so it's a good place to start.
Also try different RCOMP values. I have no idea what RCOMP is but I remember having to tweak it to get the memory to behave.
FYI, RCOMP (resistive compensation) is part of the Buffer Strength calculation. I far as I know there are no public docs explaining RCOMP but (hint:-)) there may possibly be patents that explain it.
* *
On Thu, 25 Jun 2009 13:45:21 +0200, Arnaud Maye arnaud.maye@4dsp.com wrote:
Hey Gents,
So the 2T timings did the trick, phoooow!
This is fair enough. Actually, our final hardware is not having any DIMMs but the chipsets themselves mounted on the board. So anyway all the timings will need to be found again.
This is enough to allow me going forward with the dev until we get our protos!
As a side note, Intel and their "protection by obscurity". I am fighting for a bit more than one week to obtain an "orange cover" document from Intel :
*RS - Intel(R) EP80579 Integrated Processor Product Line BIOS/Firmware Writer's Guide
*They have asked us to sign a CNDA and now we are waiting to receive a RSNDA to maybe get this document.
I will be laughing if this document does not provide any key information finally.
We will see!
Thanks for all your support guys, I(we)'ve got it working even if the performance will not be as good as in 1T mode.
Good to hear Arnaud. Have fun with Intel.... From everything I have heard it's like beating your head against a brick wall to get anything out of them. Even then they they just give you enough info to skim bye....
Arnaud Maye wrote:
Anyone around here as already used coreboot to "boot" a Vxworks system?
I don't know.
Do you know a lot about the boot process of VxWorks? Or do you have good contacts with WindRiver which we can ask?
The ideal for coreboot would be if VxWorks can be started using a self-contained 32-bit ELF file. That's what we use for payload.
It can be a bootloader, or it can even be the kernel itself.
Please let us know if you find out more info.
Of course you can always use SeaBIOS to boot the old-fashioned way.
//Peter
Peter Stuge wrote:
Arnaud Maye wrote:
Anyone around here as already used coreboot to "boot" a Vxworks system?
I don't know.
Do you know a lot about the boot process of VxWorks? Or do you have good contacts with WindRiver which we can ask?
The ideal for coreboot would be if VxWorks can be started using a self-contained 32-bit ELF file. That's what we use for payload.
It can be a bootloader, or it can even be the kernel itself.
Please let us know if you find out more info.
Vxworks, LynxOS kernel are meant to be boot from ELF images. These systems are usually tiny. A lot of these system do not even have a hard disk.
So it sounds promising, great!
I will keep you guys updated as soon we go forward on this project.
Best Regards,
Arnaud
Of course you can always use SeaBIOS to boot the old-fashioned way.
//Peter
* *
-
Arnaud Maye -
Ed Swierk -
Joseph Smith -
Myles Watson -
Peter Stuge