* Aaron Durbin adurbin@chromium.org [130509 00:02]:
Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin:
The reason udelay was put in northbridge was for SMM if I am not mistaken. How similar are the implementations?
Of `udelay.c`? Besides the register differences it is the same. Sandy Bridge (and Haswell) define `fsb` to 100 MHz, where i945 and i5000 use 400 MHz and divide it by four later on.
i945 and i5000 don't have a constant TSC but need to take the FSB frequency into regard. Not sure about Mobile 4 series. Sandybridge/Ivybridge/Haswell have a fixed frequency TSC.
As no code has been written yet, I do not know. But judging from the three `udelay.c` files I looked at, they should be.
The delay_tsc.c could be used as the basis for all of these implementations. I was confusing myself thinking each of these cpus had the implementation. Not the northbridge. Apparently the gm45 and i945 serve as the basis for all the memory controller for most of those cpus.
So the current intel northbridge chipsets with a delay implementation are: src/northbridge/intel/gm45 src/northbridge/intel/i945 src/northbridge/intel/sandybridge
The gm45 and i945 use the Intel Core architecture with the quad pumped FSB. Uses msrs 0x198 and MSR_FSB_FREQ. Note that the gm45 has a ns100delay() function for raminit. The gm45 uses delay.c for romstage as well as SMM while i945 just uses udelay.c for SMM.
The code originally went in on i945 and the reason was that certain delay operations were required to not create any front side bus traffic (interesting, huh?) or random corruption could happen. Of course it is almost impossible to get to that information, and even telling you the mere fact might force me into killing you.
Whether this was an issue with any other chipset / CPU after the i945 generation? I don't know. I am happy that haswell was cleaned up to not have that mess. Sandybridge/Ivybridge should/could probably be cleaned up as well.
Sandybridge's udelay for romstage and smm can be converted like haswell. As for having a seemingly-duplicate copy of a file for determining tsc freq doesn't bother me all that much. It's small and self contained.
Sometimes components seem very similar. Duplicating code because it happens to be similar hardware (but maybe not, in ways you will never actually know) is not the worst thing that can happen. And if it allows a clean API, we should not worry much. This is not the IOCC or contest for the shortest program, but a matter of how to create a maintainable code base that covers nearly 300 mainboards with a fast paced development team that moves on to the next set of boards every couple of months.
Stefan
-
Stefan Reinauer