Re: [coreboot] Future coreboot phases?
On Sat, Jan 09, 2010 at 11:31:08PM -0800, ron minnich wrote: > great idea, we need it. I think it ought to be a .tex file. But this > is a good start, needs to be in svn > > ron Thanks everyone for the feedback. I'll repost a new edition with some of the updates I've gotten. If anyone has any further comments, please let me know. My preference would be to put the info a wiki page, because I think it may be a little easier to keep up to date that way. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
On January 11, 2010 at 1:52 PM Patrick Georgi wrote: > Am 11.01.2010 14:42, schrieb Peter Stuge: > > I don't think svn or wiki matters. .tex is nice because you can > > easily make .pdf and print. Ron has inspired me to use Lyx. :) > > > markdown can be transformed to tex for those that want it (and thus to > pdf), but it's still editable with a simple text editor (unlike lyx > files, or tex files of reasonable complexity). Lyx for windows is > basically non-existant, for example. > > I think it's more important to save it than to have the right > > format. I think a wiki page would be fine. > > > Right, and as said, one or the other please. > So wiki it is? > My vote is for wiki... Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Am 11.01.2010 14:42, schrieb Peter Stuge: > I don't think svn or wiki matters. .tex is nice because you can > easily make .pdf and print. Ron has inspired me to use Lyx. :) > markdown can be transformed to tex for those that want it (and thus to pdf), but it's still editable with a simple text editor (unlike lyx files, or tex files of reasonable complexity). Lyx for windows is basically non-existant, for example. > I think it's more important to save it than to have the right > format. I think a wiki page would be fine. > Right, and as said, one or the other please. So wiki it is? Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Rudolf Marek wrote: > The DQS values are stored in chipset S3 "NVRAM" during first boot, > and used later when resume to fill them in. It could be done via > simple backup of all mem cntrl regs but it is not done so. I think this is a brilliant idea for improvement - it would also reduce the resume time ever so slightly. Either a structure for the chipset-specific registers that are needed, filled and saved at first boot and reused on resume - or a super simple blob copy of all registers. (If there's enough space?) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Patrick Georgi wrote: > >> great idea, we need it. I think it ought to be a .tex file. But > >> this is a good start, needs to be in svn > >> > > yes and a wiki page please?? > > One or the other please, otherwise we have two out-of-sync documents. > And .tex? why not markdown or something like that? I don't think svn or wiki matters. .tex is nice because you can easily make .pdf and print. Ron has inspired me to use Lyx. :) MediaWiki can also generate .pdf. I think it's more important to save it than to have the right format. I think a wiki page would be fine. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Am 11.01.2010 13:41, schrieb j...@settoplinux.org: >> great idea, we need it. I think it ought to be a .tex file. But this >> is a good start, needs to be in svn >> > yes and a wiki page please?? > One or the other please, otherwise we have two out-of-sync documents. And .tex? why not markdown or something like that? Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
On January 10, 2010 at 7:31 AM ron minnich wrote: > great idea, we need it. I think it ought to be a .tex file. But this > is a good start, needs to be in svn > yes and a wiki page please?? Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
How is S3 resume handled? I describe the AMD64 port. There is a function which you can get sleepstate from a chipset. If you are resuming, most of the boot code flow is same. However there are following expecptions: 1) the coreboot RAM stage area is backuped to a cbmem store. It is done because we don't have relocable ram stage. 2) The memory is taken out of the selfrefresh instead of "init command", so most of the memory setup is same. The DQS values are stored in chipset S3 "NVRAM" during first boot, and used later when resume to fill them in. It could be done via simple backup of all mem cntrl regs but it is not done so. 3) The boot continues normally until the build of the memory tables. No tables are build but the wakeup vector is taken from ACPI tables and with a realmode trampoline (currently partly overwriting first 1K of mem) the CPU is taken to the realmode OS wakup entrypoint. Thats it. Maybe it is more clear now. Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
On Saturday 09 January 2010 23:31:03 Kevin O'Connor wrote: > This is just a starting point for discussion. There's a good chance > I've gotten some things wrong. The idea is to document where things > are heading instead of how exactly they are today. Great Idea, and nicely summed up. Please try to get it somewhere into the repro, that information could often be quite useful. > Thoughts? > -Kevin Regards, Harald -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Am 09.01.2010 23:31, schrieb Kevin O'Connor: > This is just a starting point for discussion. There's a good chance > I've gotten some things wrong. The idea is to document where things > are heading instead of how exactly they are today. > Thank you! > * Full rom mapping and fallback/normal switch can be board specific, > but most of the other code is standard. > Any romstage selection should be generic in source (it can compile to board specific object code). The proliferation of all those similar-but-not-quite copies of the switch in the board directories wasn't one of the better aspects of coreboot-v2. The current "selection" code for tinybootblock is in src/arch/i386/init/bootblock.c At some point I'd like to see multiple selection code files there with a Kconfig option to select the desired one. Before we can actually do a selection, we need a way to fill an image with mupltiple variants. That's mostly a build system issue, but one I'd like to get ridhg > Open questions: > > At what point do the non-BP cpus get shutdown? What phases will use > multiple processors? > CPU code (or northbridge code in some instances, I think) handles that for itself. AMD can (or must?) use multiple CPUs for RAM init, all others put non-BP cpus to sleep as soon as possible (somewhere inside cpu or northbridge code). > How is S3 resume handled? > Rudolf was working on resume related issues recently. A clear set of rules how caches have to work in all stages should help him, too... Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
great idea, we need it. I think it ought to be a .tex file. But this is a good start, needs to be in svn ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Dear Kevin, Am Samstag, den 09.01.2010, 17:31 -0500 schrieb Kevin O'Connor: […] > This is just a starting point for discussion. There's a good chance > I've gotten some things wrong. The idea is to document where things > are heading instead of how exactly they are today. > > Thoughts? […] your effort is a great idea. Could you put it into the Wiki or into the repository right away, so that people can adapt it and merging comments together does not have to be done? I think Ron also started a TeX document somewhere. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Future coreboot phases?
Hi, There are a bunch of changes under way in coreboot-v2. Because of these changes and because of the many differences in operation between boards already in v2, it can be somewhat difficult to figure out what a board should be doing. I think some documentation on where functionality in coreboot should be located would be helpful for developers. I put together some notes (see below) on what I've gathered from my understanding of the code and from various emails. This is just a starting point for discussion. There's a good chance I've gotten some things wrong. The idea is to document where things are heading instead of how exactly they are today. Thoughts? -Kevin There are four major phases to coreboot execution: bootblock, romstage, coreboot_ram, and payload. bootblock: The purpose of the bootblock is to enable full access to flash and to detect and enable fallback booting in necessary. It also does basic CPU initialization (clears caches and enables 32bit mode). The objective is to make this code as small and isolated as possible so that one can deploy new "normal" images without needing to reflash the bootblock (or the "fallback" image). Basic attributes: * Located at end of 32bit ram so that it runs when CPU first starts executing (at 0xfff0). * Code runs XIP in rom. * Debugging is generally accomplished via 0x80 ioport (post codes) * Code is a mixture of assembler and romcc compiled C code. The code will not attempt to access any RAM memory. * Full rom mapping and fallback/normal switch can be board specific, but most of the other code is standard. * Last step is to jump into "romstage". For the handoff, %eax will contain the BIST code, the cpu will be in 32bit flat mode, caches will be disabled, and no stale data will be in the cache. romstage: The purpose of the romstage is to enable RAM. Basic attributes: * Code runs XIP in rom. The code location is determined at compile time and is fixed (the code is not PIC and can not be relocated without recompiling). * The system will generally enable CAR. This will result in CPU caches being enabled, variable MTRR for the XIP romstage region being enabled, and all other variable MTRRs cleared. * Code uses gcc (CAR) or romcc (non-CAR) compiled C code. In general, care must be taken to limit memory usage so that storage overflows don't occur. (As an exception, the last step of decompressing and launching "coreboot_ram" occurs after memory is initialized and it uses regular memory and regular gcc compiled code.) * Early debugging is enabled - debugging is generally accomplished either via a serial port or via an EHCI debug port. * Code will enable memory and basic northbridge/cpu/memory controller settings. * Last step is to decompress and run "coreboot_ram". For the handoff, caching will be enabled, memory from 0 - CONFIG_RAMTOP will be fully mapped and cached, and the entire flash chip will be cached. If CAR was enabled it is completely torn down. There will be no stale data in cache. Additional information may be passed from romstage to coreboot_ram - the information and mechanism is board specific. coreboot_ram: The purpose of coreboot_ram is to enable system devices and do motherboard specific hardware initialization. It also sets up the coreboot table and various other legacy BIOS tables (eg, ACPI, PIR, mptable, smbios). The goal is to perform the motherboard specific initialization so that the payload can be mostly board independent. Basic attributes: * Runs from RAM. It is generally stored compressed in the rom. This code is standard gcc compiled C code - no special tricks for memory are needed. * Does PCI enumeration and PCI config space initialization. * If legacy VGA is enabled, the corresponding PCI config settings are enabled and 0xa-0xc is unmapped and made uncached. * Builds legacy BIOS tables. * May emulate vga roms. * Last step is to decompress and run the "payload". For the handoff, all MTRRs are initialized, caching is enabled, and the entire flash chip is cached. There will be no stale data in cache. No specific information is passed during payload execution, but the payload may locate the coreboot table and other BIOS tables at standard locations. payload: The purpose of the payload is to load and run the operating system (or occasionally to be the operating system). It will also initialize generic hardware that typical operating systems expect to be initialized before execution. Basic attributes: * Stored in flash. Generally stored compressed. * may use CBFS. * Generally needs to be aware of hardware still "spinning up". Open questions: At what point do the non-BP cpus get shutdown? What phases will use multiple processors? How is S3 resume handled? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
