coreboot April 2013

coreboot@coreboot.org

42 participants
125 discussions

Re: [coreboot] monotonic timer patches
by Aaron Durbin 30 Apr '13

30 Apr '13

On Tue, Apr 30, 2013 at 9:50 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > Hi All, > > As noted in the thread titled 'Boot flow flexibility changes' I have > uploaded the initial pass for monotonic timers. It just provides the > API with 3 implementations. > > remote: http://review.coreboot.org/3152 > remote: http://review.coreboot.org/3153 > remote: http://review.coreboot.org/3154 > remote: http://review.coreboot.org/3155 > remote: http://review.coreboot.org/3156 > > As for the ARM board. I didn't change anything in there at the moment. > However, my thinking is the following: > > 1. move src/include/time.h to the samsung cpu directory. > 2. provide a time_monotonic_get() implementation most likely in mct.c? > > I'm not as familiar with that code base. That was just what I was > thinking. However, I do think it is appropriate to move time.h out of > the src/include because that provides an API specific to a CPU. I'd > like to make the monotonic timer API the generic one. I just uploaded the timer queue code as well: remote: http://review.coreboot.org/3158 remote: http://review.coreboot.org/3159 -Aaron

1 0

monotonic timer patches
by Aaron Durbin 30 Apr '13

30 Apr '13

Hi All, As noted in the thread titled 'Boot flow flexibility changes' I have uploaded the initial pass for monotonic timers. It just provides the API with 3 implementations. remote: http://review.coreboot.org/3152 remote: http://review.coreboot.org/3153 remote: http://review.coreboot.org/3154 remote: http://review.coreboot.org/3155 remote: http://review.coreboot.org/3156 As for the ARM board. I didn't change anything in there at the moment. However, my thinking is the following: 1. move src/include/time.h to the samsung cpu directory. 2. provide a time_monotonic_get() implementation most likely in mct.c? I'm not as familiar with that code base. That was just what I was thinking. However, I do think it is appropriate to move time.h out of the src/include because that provides an API specific to a CPU. I'd like to make the monotonic timer API the generic one. -Aaron

1 0

Re: [coreboot] On loongson CPU or MIPS ARCH
by li guang 30 Apr '13

30 Apr '13

在 2013-04-29一的 20:38 -0700，ron minnich写道： > On Mon, Apr 29, 2013 at 7:37 PM, li guang <lig.fnst(a)cn.fujitsu.com> wrote: > > > Thanks! > > follow your pointing, I know execution flow, > > I want to know why coreboot force to boot a payload? > > can't we skip this payload(by changing hardwaremain())? > > or can we write a simple pseudo payload? > > what would your pseudo payload do? to simply load kernel image. because we have to have a payload, but, we have done hardware init work, so what we can do for payload? load kernel image. > > But first, let's start getting the directories set up. > > Could you put together a simple CL to create > src/cpu/loongson, with a Kconfig in it, and a src/arch/mips, with a > config in it? If you want, you can follow the path we took with ARM, > where we started out with an empty tree and then filled it in. > > you could start with this example: > http://review.coreboot.org/#/c/1939/ Thanks, I visited it. BTW, I did not register for coreboot gerrit.

1 0

Re: [coreboot] On loongson CPU or MIPS ARCH
by li guang 30 Apr '13

30 Apr '13

在 2013-04-29一的 12:40 -0700，David Hendricks写道： > On Mon, Apr 29, 2013 at 1:56 AM, li guang <lig.fnst(a)cn.fujitsu.com> > wrote: [...] > > A very simplified overview of each stage: > - bootblock is the very first instructions executed by the CPU. It > does very basic CPU setup. It has also been used to detect if the > previous boot succeeded and, if not, select a fallback (or "failover") > firmware to boot. > - romstage usually consists of code which runs before RAM is ready to > use, for example to initialize the DRAM controller interface. > - ramstage consists of everything else. > > > Overall we try to avoid assembly after the bootblock stage. For > romstage, we use a technique called "cache-as-RAM" to exploit the > processor cache (or embedded SRAM, if available) as a temporary > location to set up a stack and run C code. > > > If you're interested in following the code flow for ARMv7, the Snow > mainboard is the current example. Here are the files you should look > at in order of usage: > 1. src/arch/armv7/bootblock.inc: Assembly code which sets ARM chip in > service mode, puts non-bootstrap CPU cores to sleep, initializes > stack. > > > 2. src/arch/armv7/bootblock_simple.c: Generic ARM cache setup, calls > mainboard-specific routines, jumps to romstage > > > 3. src/mainboard/google/snow/bootblock.c: Determine if we are resuming > and can jump to resume vector. > > > > 4. src/mainboard/google/snow/romstage.c: Set up PMIC, clocks, and RAM, > jump to ramstage. x86 platforms will also copy ramstage code into DRAM > at this point for the next stage, but the Exynos5250 CPU on the Snow > mainboard has a large enough embedded SRAM which we continue to use > for ramstage on this platform. > > > 5. src/mainboard/google/snow/ramstage.c: Set up MMU, framebuffer, > exception handler, etc, and load payload. Thanks! follow your pointing, I know execution flow, I want to know why coreboot force to boot a payload? can't we skip this payload(by changing hardwaremain())? or can we write a simple pseudo payload? > > > > > > > > > As I do not know the Loongson/MIPS architecture, I have no > idea if the > > coreboot “framework” is suitable or not for it. From > coreboot’s > > perspective it would be nice if you could spend the time > trying to do a > > Loongson/MIPS port. I also cannot remember if that has been > tried in the > > past. > > > > > seems there's no conflict with coreboot's framework. > > > I tend to agree. The real question is whether it might be useful for > future MIPS-based laptops. I suspect coreboot is overkill for current > MIPS-based products. However, we may see more complex systems where > the Loongson is only a small part of the system as a whole, and where > you may need flexibility to customize for different products with > shared components. > > > ARM is similar in that regard. Fundamentally, ARMv7 setup is very easy > and could be done in a few hundred lines of assembly code. However, > each CPU implementation (ie Exynos5250) includes dozens of peripherals > and each product requires customization. So in that case it's useful > to have a framework which is flexible enough to account for > differences in CPU implementation, mainboard components, and overall > product design. > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] UDELAY_IO
by Stefan Reinauer 30 Apr '13

30 Apr '13

* Aaron Durbin <adurbin(a)chromium.org> [130430 04:27]: > My only comment is that it would be nice to have the notion that there > is some sort of free running timer on all the boards. It can simplify > some of the code as well as what is exposed through CONFIG_*, etc. If > reality dictates that this isn't possible then that's just the way it > is. > > -Aaron Agreed, we do want free running timers and this might be a great opportunity to straighten up the code and get rid of all the parallel implementations of timers that we don't need and want. Stefan

1 0

Re: [coreboot] UDELAY_IO
by Stefan Reinauer 30 Apr '13

30 Apr '13

* Aaron Durbin <adurbin(a)chromium.org> [130426 21:29]: > 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. UDELAY_IO is the default on all systems that do not explicitly select a different timer. Right now only the following CPUs use UDELAY_LAPIC: ./src/cpu/intel/model_206ax/Kconfig: select UDELAY_LAPIC ./src/cpu/intel/model_6ex/Kconfig: select UDELAY_LAPIC ./src/cpu/intel/haswell/Kconfig: select UDELAY_LAPIC ./src/cpu/intel/model_106cx/Kconfig: select UDELAY_LAPIC ./src/cpu/intel/model_6fx/Kconfig: select UDELAY_LAPIC ./src/cpu/amd/model_10xxx/Kconfig: select UDELAY_LAPIC ./src/cpu/amd/model_fxx/Kconfig: select UDELAY_LAPIC ./src/cpu/amd/agesa/Kconfig: select UDELAY_LAPIC These mainboards manually select UDELAY_LAPIC (and shouldn't, but instead have the CPU select it for them): ./src/mainboard/getac/p470/Kconfig: select UDELAY_LAPIC ./src/mainboard/asus/f2a85-m/Kconfig: select UDELAY_LAPIC ./src/mainboard/iwave/iWRainbowG6/Kconfig: select UDELAY_LAPIC ./src/mainboard/amd/parmer/Kconfig: select UDELAY_LAPIC ./src/mainboard/amd/south_station/Kconfig: select UDELAY_LAPIC ./src/mainboard/amd/thatcher/Kconfig: select UDELAY_LAPIC ./src/mainboard/amd/union_station/Kconfig: select UDELAY_LAPIC Generally, there are a few boards / CPUs that might explicitly need UDELAY_IO. 8 boards are using UDELAY_IO: bifferos_bifferboard/config.build:CONFIG_UDELAY_IO=y digitallogic_adl855pc/config.build:CONFIG_UDELAY_IO=y digitallogic_msm586seg/config.build:CONFIG_UDELAY_IO=y emulation_qemu-x86/config.build:CONFIG_UDELAY_IO=y iei_juki-511p/config.build:CONFIG_UDELAY_IO=y lanner_em8510/config.build:CONFIG_UDELAY_IO=y roda_rk9/config.build:CONFIG_UDELAY_IO=y technologic_ts5300/config.build:CONFIG_UDELAY_IO=y - At least the Roda RK9 looks wrong, possibly others too. - The Geode GX1 has TSC so IEI Juki-511P could be switched over. - The Bifferboard might need CONFIG_UDELAY_IO. But if it is the only one, and it has been obsoleted by Bifferos, maybe we should drop the board from coreboot's top of tree and refer people to check out an older git version to run coreboot on this board. - MSM586SEG and TS5300 are AMD SC520 and should probably be retired, too. Not a single board is using CONFIG_UDELAY_TIMER2, so we should wipe that code and reduce the number of different timer sources. 79 boards use CONFIG_UDELAY_TSC. 104 boards are using CONFIG_UDELAY_LAPIC. Comments? Stefan

3 2

Re: [coreboot] On loongson CPU or MIPS ARCH
by li guang 30 Apr '13

30 Apr '13

在 2013-04-29一的 19:05 -0700，ron minnich写道： > let's take this one step at a time. > > First off, we're going to need to work out names. Since loongson > requires patches, does that mean it is more or less than a base mips? It has a little new instructions against mips for optimization, like MULT.G, DIV.G, MADD.G(float multi-then-add). > > So, what do we use as names? I think we can use mips directly, because loongson internally use it. > > Let's start with the arch/ and cpu/ > src/arch/? mips? Is it a true mips? > > src/cpu/loongson/? what name here? I think src/cpu/loongson is right, and src/arch/mips is also right. (maybe just like via :-))

1 0

coreboot mailing list now gerrit-free
by Stefan Reinauer 30 Apr '13

30 Apr '13

Dear coreboot community, it has been quite a while since we switched our version control system to git + gerrit, and the incredible amount of emails has alienated one or another person on this list, unfortunately. But help is finally here: We switched all gerrit based email traffic over to a new mailing list: coreboot-gerrit(a)coreboot.org. To prevent everybody's inbox to break down due to not working filters, we decided to _not_ automatically subscribe everybody to the new mailing list. Please do subscribe yourself, if you are interested in all the commit messages and code reviews flying by. In order to subscribe to the new list, please visit: http://www.coreboot.org/mailman/listinfo/coreboot-gerrit Regards, coreboot admin team

5 11

Re: [coreboot] On loongson CPU or MIPS ARCH
by li guang 30 Apr '13

30 Apr '13

在 2013-04-29一的 13:27 -0700，ron minnich写道： > OK, some of us just went through this exercise for armv7a and we've > decided we're going to help you get this done. Great! Thanks! > > So, the first step is to get a working toolchain via crossgcc. And the > first step in that, we found, is to pick the "name" of the CPU. For > x86, it was x86 :-) > > For our current arm, it was armv7a-eabi. > > It needs to be the architecture name known to gcc for this particular > architecture and CPU. So what is that for the Loongson? for me, it's mips-elf, and maybe you can get more recent patches for gcc from loongson's official website. > > Once that is done, I'll help you with the next steps. It's not hard, > now that we know how it's done. > my raw simple plan: 1. startup code 2. north-bridge(bonito) init code 3. south-bridge(vt82c686b) init code 4. kernel image loading code now, there's an issue: payload, seems coreboot doesn't want to do much further things like load a kernel image, payload will do much more, but, here what payload is suitable for me? if it's pmon, that's maybe a joke, because I just want to kick away pmon, but it comes back again. or, it's grub2 as Vladimir said? don't know, let me see.

2 1

Re: [coreboot] On loongson CPU or MIPS ARCH
by li guang 30 Apr '13

30 Apr '13

在 2013-04-29一的 12:40 -0700，David Hendricks写道： > On Mon, Apr 29, 2013 at 1:56 AM, li guang <lig.fnst(a)cn.fujitsu.com> > wrote: > Hi, Paul > > 在 2013-04-29一的 10:47 +0200，Paul Menzel写道： > > Am Montag, den 29.04.2013, 10:19 +0200 schrieb Paul Menzel: > > > Am Sonntag, den 28.04.2013, 20:21 -0700 schrieb ron > minnich: > > > > On Sun, Apr 28, 2013 at 7:24 PM, Vladimir > 'φ-coder/phcoder' Serbinenko > > > > <phcoder(a)gmail.com> wrote: > > > > > > > > > Could we have a sane discussion about why it's not > suitable for this or > > > > > that scenario and what would need to be fixed? Not > just quasi-fanatical > > > > > "I don't want it". > > > > > > > > I guess I missed the part where not wanting something > was considered insane. > > > > > > […] > > > > > > Could you all please read what Vladimir actually wrote and > not put > > > something in his mouth! > > > > > > »You need something as GRUB for it since the chip is too > small > > > to hold a kernel anyway.« > > > > > > The »something« makes a difference. > > > > > > He just informed Guang, that he needs a payload, which > Guang did not > > > consider yet. As Vladimir already knows coreboot due to > his X201s work > > > and dealt with Loongson I find it very nice of him to > share his opinion. > > > > Guang, from all of the respondents I probably are the most > inexperienced > > one, so my answers might be incorrect. One of the strong > points of > > coreboot is its PCI initialization framework, the ability to > configure > > it with Kconfig and the ability to customize it > > > Loongson platform be designed mostly like a PC, it also > control PCI > devices. > > > From what Vladimir mentions, the Yeeloong netbook implementation seems > very simple. Do you intend to add support for more complicated > platform? As Ron pointed out, coreboot's framework provides a lot of > flexibility which might be useful if you intend to support more > Loongson (or other MIPS) based systems. > Yes, I will try to add support of them one by one if it's possible. > > In any case, adding a new architecture to coreboot is an educational > exercise and I highly encourage it if you have the time ;-) > > > > because of the payload > > concept, where coreboot only initializes only the minimum of > the > > hardware and a payload, like SeaBIOS, FILO and GRUB, can > take over. > > > I'm not quite clear about code flow between bootblock and > payload > for now, so, is there some document about it? > or can you give some hints for code flow? > Thanks! > > > A very simplified overview of each stage: > - bootblock is the very first instructions executed by the CPU. It > does very basic CPU setup. It has also been used to detect if the > previous boot succeeded and, if not, select a fallback (or "failover") > firmware to boot. > - romstage usually consists of code which runs before RAM is ready to > use, for example to initialize the DRAM controller interface. > - ramstage consists of everything else. > > > Overall we try to avoid assembly after the bootblock stage. For > romstage, we use a technique called "cache-as-RAM" to exploit the > processor cache (or embedded SRAM, if available) as a temporary > location to set up a stack and run C code. > > > If you're interested in following the code flow for ARMv7, the Snow > mainboard is the current example. Here are the files you should look > at in order of usage: > 1. src/arch/armv7/bootblock.inc: Assembly code which sets ARM chip in > service mode, puts non-bootstrap CPU cores to sleep, initializes > stack. > > > 2. src/arch/armv7/bootblock_simple.c: Generic ARM cache setup, calls > mainboard-specific routines, jumps to romstage > > > 3. src/mainboard/google/snow/bootblock.c: Determine if we are resuming > and can jump to resume vector. > > > > 4. src/mainboard/google/snow/romstage.c: Set up PMIC, clocks, and RAM, > jump to ramstage. x86 platforms will also copy ramstage code into DRAM > at this point for the next stage, but the Exynos5250 CPU on the Snow > mainboard has a large enough embedded SRAM which we continue to use > for ramstage on this platform. > > > 5. src/mainboard/google/snow/ramstage.c: Set up MMU, framebuffer, > exception handler, etc, and load payload. > > > > > > > > > As I do not know the Loongson/MIPS architecture, I have no > idea if the > > coreboot “framework” is suitable or not for it. From > coreboot’s > > perspective it would be nice if you could spend the time > trying to do a > > Loongson/MIPS port. I also cannot remember if that has been > tried in the > > past. > > > > > seems there's no conflict with coreboot's framework. > > > I tend to agree. The real question is whether it might be useful for > future MIPS-based laptops. I suspect coreboot is overkill for current > MIPS-based products. However, we may see more complex systems where > the Loongson is only a small part of the system as a whole, and where > you may need flexibility to customize for different products with > shared components. > > > ARM is similar in that regard. Fundamentally, ARMv7 setup is very easy > and could be done in a few hundred lines of assembly code. However, > each CPU implementation (ie Exynos5250) includes dozens of peripherals > and each product requires customization. So in that case it's useful > to have a framework which is flexible enough to account for > differences in CPU implementation, mainboard components, and overall > product design. > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

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