April 2013 - coreboot - mail.coreboot.org

Re: [coreboot] UDELAY_IO
by Aaron Durbin April 26, 2013

April 26, 2013

On Fri, Apr 26, 2013 at 2:29 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: > Question for the masses: does anyone actually use UDELAY_IO? If not, > can we get rid of it? I'll prepare the patch. With APICs, HPETs, TSCs, > etc I really don't see the need for such a thing. Same question for UDELAY_TIMER2.

1 0

UDELAY_IO
by Aaron Durbin April 26, 2013

April 26, 2013

Question for the masses: does anyone actually use UDELAY_IO? If not, can we get rid of it? I'll prepare the patch. With APICs, HPETs, TSCs, etc I really don't see the need for such a thing. -Aaron

1 0

Re: [coreboot] On loongson CPU or MIPS ARCH
by ron minnich April 26, 2013

April 26, 2013

Are there development systems for this CPU that we could buy to assist in the effort? Is there reference memory startup code? ron

1 0

Re: [coreboot] Boot flow flexibility changes
by ron minnich April 26, 2013

April 26, 2013

I will happily confirm you are a great mind :) ron

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin April 25, 2013

April 25, 2013

That sounds exactly the way my thoughts were proceeding. Please confirm you and I are both great minds. :) I hope so because my experience dictates otherwise. On Thu, Apr 25, 2013 at 11:28 PM, ron minnich <rminnich(a)gmail.com> wrote: > we have this notion of timer_init() or whatever we called it on arm. > On all platforms, timer_init could record the clock value when it's > called, and then timer_us could report the time relative to the > starting value of timer_init. > > And then our time would be a 'microseconds since coreboot started' and > would still, I think, easily fit in 32 bits. > > ron

1 0

Re: [coreboot] Boot flow flexibility changes
by ron minnich April 25, 2013

April 25, 2013

we have this notion of timer_init() or whatever we called it on arm. On all platforms, timer_init could record the clock value when it's called, and then timer_us could report the time relative to the starting value of timer_init. And then our time would be a 'microseconds since coreboot started' and would still, I think, easily fit in 32 bits. ron

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin April 25, 2013

April 25, 2013

On Thu, Apr 25, 2013 at 6:42 PM, David Hendricks <dhendrix(a)google.com> wrote: > On Thu, Apr 25, 2013 at 4:00 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> Am I doing the math right ... >> >> a 32-bit microsecond timer is about 20 minutes. If we ever take more >> than 20 seconds we need a new job. >> >> That was my logic. > > > Who says the timer has to start at zero? What about the reboot case? This is true, but I was thinking it would start at 0 and be valid for the duration of ramstage. -Aaron

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin April 25, 2013

April 25, 2013

On Thu, Apr 25, 2013 at 6:00 PM, ron minnich <rminnich(a)gmail.com> wrote: > Am I doing the math right ... > > a 32-bit microsecond timer is about 20 minutes. If we ever take more > than 20 seconds we need a new job. > > That was my logic. > You are doing your math correctly. However, not all platforms may have this perfect 1MHz clock. That means the microsecond resolution clock needs to be derived off of a faster ticking hardware clock. That's where we need to be more careful about polling intervals against the hardware source clock. Anyway, it's not impossible; tick rates just need to be worked out. -Aaron

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin April 25, 2013

April 25, 2013

On Thu, Apr 25, 2013 at 6:00 PM, ron minnich <rminnich(a)gmail.com> wrote: > Am I doing the math right ... > > a 32-bit microsecond timer is about 20 minutes. If we ever take more > than 20 seconds we need a new job. > > That was my logic. > You are doing your math correctly. However, not all platforms may have this perfect 1MHz clock. That means the microsecond resolution clock needs to be derived off of a faster ticking hardware clock. That's where we need to be more careful about polling intervals against the hardware source clock. Anyway, it's not impossible; tick rates just need to be worked out. -Aaron

1 0

Re: [coreboot] Boot flow flexibility changes
by David Hendricks April 25, 2013

April 25, 2013

On Thu, Apr 25, 2013 at 4:00 PM, ron minnich <rminnich(a)gmail.com> wrote: > Am I doing the math right ... > > a 32-bit microsecond timer is about 20 minutes. If we ever take more > than 20 seconds we need a new job. > > That was my logic. > Who says the timer has to start at zero? What about the reboot case? -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0