Hi Mark,
First, Linux rarely uses the real time clock - use the 'hwclock' tool to query it repeatedly and compare that against your stop watch to figure out if RTC is involved.
If it isn't: Linux keeps its own system clock which is only once synchronized against RTC. I don't know off-hand what Linux uses to determine time progression, but I know that it believes whatever is in the ACPI about cpu frequency scaling. Maybe some values are off, and the CPU is clocked lower in some modes than Linux thinks it is, or moving to higher CPU clocks has no effect (I think I saw that on one board due to insufficient ACPI data). To my knowledge, the linux system clock can be fed from different sources - so it's also possible that with AMI, ACPI (or similar tables) enable a different set of clock sources than coreboot, showing different behaviour. The kernel's log messages should tell you.
Patrick
Mark C. Mason via coreboot coreboot@coreboot.org schrieb am Tue Nov 04 2014 at 01:21:49:
We are working with both vanilla Coreboot and Sage's BSP version of Coreboot, and we stumbled upon the fact that the system clock is running 20-30% slow.
This does not occur when booting from the original AMI BIOS. We are running both CentOS 6.4 and Ubuntu 14.04 versions of Linux.
To reproduce, run "sleep 10" and time it with a stopwatch. Our timings indicate about 12.2 seconds when booting from either vanilla or Sage BSP Coreboot.
I've searched the Coreboot mailing list archives (and google), but I don't see anything.
Does anyone know anything about this? I'll start looking at the code, but any help will be greatly appreciated.
Best regards,
Mark Mason Engineering Design Team
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot