coreboot April 2013

coreboot@coreboot.org

42 participants
125 discussions

Re: [coreboot] Boot flow flexibility changes
by ron minnich 26 Apr '13

26 Apr '13

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. ron

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin 25 Apr '13

25 Apr '13

On Thu, Apr 25, 2013 at 3:45 PM, Marc Jones <marcj303(a)gmail.com> wrote: > The timer scheduler for hardware init scares me a bit... but I'd like > to see an implementation. It's similar to the boot state callbacks. There is a free running timer. One can say run this in 10milliseconds. In 10 milliseconds (or after) the callback will be called. The timer callbacks would be evaluated between boot state transitions. Stand by on the implementation. Fwiw, the free running timer is the hard part because we aren't talking about an interrupt but a polling method. Therefore we need to somehow ensure the longest period between polls is not sufficiently long (1/2 the global timer period) to not detect a roll over. > > On Thu, Apr 25, 2013 at 11:59 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: >> On Thu, Apr 25, 2013 at 12:52 PM, ron minnich <rminnich(a)gmail.com> wrote: >>> we really need the timer scheduler on newer platforms. >>> >>> Some of the platforms are so old they may not be testable. >>> >>> My plan is to provide timer_us for all platforms I can test, and then >>> have only the new platforms use timer queue interface. I think we can >>> manage this with proper configuration of makefiles. >> >> >> OK. Let me look into it more then. I can probably have something next >> week some time once I tease out the weird implementations of the >> current udelay() functions. The only thing we'll have to get a handle >> on is roll over in whatever hardware is providing a the free running >> timer. >> >> -Aaron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > http://se-eng.com

1 0

Re: [coreboot] Boot flow flexibility changes
by ron minnich 25 Apr '13

25 Apr '13

In my view, udelay becomes a src/lib/ function, i.e. generic, and it calls timer_us to know when it's done. u32 udelay(int us){ now = timer_us(); end = now + us; while (timer_us() < end) ; return timer_us(); // might as well, we know the time. }

1 0

Re: [coreboot] Boot flow flexibility changes
by Marc Jones 25 Apr '13

25 Apr '13

The timer scheduler for hardware init scares me a bit... but I'd like to see an implementation. On Thu, Apr 25, 2013 at 11:59 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Thu, Apr 25, 2013 at 12:52 PM, ron minnich <rminnich(a)gmail.com> wrote: >> we really need the timer scheduler on newer platforms. >> >> Some of the platforms are so old they may not be testable. >> >> My plan is to provide timer_us for all platforms I can test, and then >> have only the new platforms use timer queue interface. I think we can >> manage this with proper configuration of makefiles. > > > OK. Let me look into it more then. I can probably have something next > week some time once I tease out the weird implementations of the > current udelay() functions. The only thing we'll have to get a handle > on is roll over in whatever hardware is providing a the free running > timer. > > -Aaron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com

1 0

Re: [coreboot] Boot flow flexibility changes
by Aaron Durbin 25 Apr '13

25 Apr '13

On Thu, Apr 25, 2013 at 12:52 PM, ron minnich <rminnich(a)gmail.com> wrote: > we really need the timer scheduler on newer platforms. > > Some of the platforms are so old they may not be testable. > > My plan is to provide timer_us for all platforms I can test, and then > have only the new platforms use timer queue interface. I think we can > manage this with proper configuration of makefiles. OK. Let me look into it more then. I can probably have something next week some time once I tease out the weird implementations of the current udelay() functions. The only thing we'll have to get a handle on is roll over in whatever hardware is providing a the free running timer. -Aaron

1 0

Re: [coreboot] Boot flow flexibility changes
by ron minnich 25 Apr '13

25 Apr '13

we really need the timer scheduler on newer platforms. Some of the platforms are so old they may not be testable. My plan is to provide timer_us for all platforms I can test, and then have only the new platforms use timer queue interface. I think we can manage this with proper configuration of makefiles. ron

1 0

[RFH] Test on hardware with GCC 4.7.3
by Paul Menzel 25 Apr '13

25 Apr '13

Dear coreboot folks, could you please test building coreboot for your hardware with GCC 4.7.3 and report back your results [1]? Make sure to save your build with GCC 4.7.2 for comparison beforehand as `make crossgcc` will delete `build/`. $ cd your/coreboot/git/clone $ git fetch http://review.coreboot.org/coreboot refs/changes/12/3112/6 && git cherry-pick FETCH_HEAD $ make crossgcc # builds i386-elf and armv7a-eabi toolchains $ make $ sudo flashrom … Thanks, Paul [1] http://review.coreboot.org/#/c/3112/

3 4

Boot flow flexibility changes
by Aaron Durbin 25 Apr '13

25 Apr '13

Hi Folks, I just wanted to point out to people that I posted changes to make the boot flow more flexible: http://review.coreboot.org/3131 http://review.coreboot.org/3132 http://review.coreboot.org/3133 http://review.coreboot.org/3134 http://review.coreboot.org/3135 http://review.coreboot.org/3136 http://review.coreboot.org/3137 http://review.coreboot.org/3138 http://review.coreboot.org/3139 The reason for these changes stems from dependency requirements on newer machines that don't closely follow the device tree and pci device ordering. However, there are other benefits such as dynamically deciding to perform something at a given time during the boot sequence as well as not introducing board-specific calls throughout the common code. The patches provide usage examples by some of the core pieces of code. There is something else I've been thinking about and working on is the ability to schedule work based on time. Ron had introduced a microsecond global timer. There is also a desire on my part to utilize this concept so that the boot flow isn't busy waiting on something that takes a long time. I have the timer scheduler written, but it requires global time source. On x86 this is quite complicated in that there appears to be quite a few (> 3?) implementations of the udelay() function. The timer scheduler would integrate into the boot state machine above by running the timers between states. Additionally, the concept of blocking state entry when timers are queued. That concept would provide a sequence point for not proceeding further than necessary until all work is drained. I wanted to get people's thoughts on these concepts. I think I can push off the introduction of the timer scheduler by just delaying work using the boot state machine. However, I'm not sure what other people's needs are. Thanks. -Aaron

1 0

Looking for Linux messages (`dmesg`) and coreboot log of AMD Persimmon for comparison with ASRock E350M1
by Paul Menzel 24 Apr '13

24 Apr '13

Dear coreboot folks, I am planning on working on the ASRock E350M1 a bit. As it is similar to the AMD Persimmon board, it would be awesome to have the Persimmon logs for comparison. Could you please attach them to your reply with a note what GNU/Linux distribution you use and what Linux version. Thanks, Paul

2 2

Re: [coreboot] AsRock E350M1 report: VGA BIOS extraction from vendor BIOS fails
by Marc Jones 23 Apr '13

23 Apr '13

You may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/useracceptance?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON Marc

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2013