Coreboot v3 - Revision history

Stepan: /* How coreboot starts after Reset */

2011-03-05T01:33:26Z

‎How coreboot starts after Reset

MJones at 23:59, 27 October 2008

2008-10-27T23:59:15Z

MJones at 23:58, 27 October 2008

2008-10-27T23:58:44Z

Stuge: Add link to Image:Newboot.pdf that I just uploaded

2008-03-13T12:17:13Z

Add link to Image:Newboot.pdf that I just uploaded

Uwe: Move license to the bottom.

2008-02-26T18:29:10Z

Move license to the bottom.

Whiterocker at 18:26, 26 February 2008

2008-02-26T18:26:43Z

Whiterocker: Fill in first-pass "how to add new board support" with text provided by cdh

2008-02-26T17:18:37Z

Fill in first-pass "how to add new board support" with text provided by cdh

Phs: Fix small grammatical error.

2008-02-16T21:43:58Z

Fix small grammatical error.

Stepan at 15:10, 15 January 2008

2008-01-15T15:10:09Z

Stepan: LinuxBIOSv3 moved to Coreboot v3

2008-01-13T11:33:45Z

LinuxBIOSv3 moved to Coreboot v3

@@ Line 40: / Line 40: @@
 As there was no change even if we run current processors like P3, these newer CPUs also feels like they where start at 0xF0000:0xFFF0 after a reset. But they do not. The base of the code segment register is 0xFFFF0000 after reset, so the CPU generates a physical address of 0xFFFFFFF0 to the chipset. And the chipset is responsible to forward this area to the boot ROM. Its confusing: The CPU "thinks" it runs code at 0xF000:0xFFF0 but instead it uses code at 0xFFFFFFF0. The developers must have been tanked up when they realised this design into silicon.
-On some chipsets there is an additional pitfall: The so called A20 gate. It was introduced to support full compatibility for the 80286 CPU with their predecessor 8086. When the old CPU accesses space "behind" the 0xFFFFF (=1MiB) limit, they wrap around to 0x00000. On 80286 and newer processors accesses above 0xFFFFF natively do not wrap around. The external A20 gate forces this wrap also on newer CPUs. On older CPUs its open after reset, so the CPU cannot generate addresses with A20 set.
+On some chipsets there is an additional pitfall: The A20 gate. It was introduced to support full compatibility for the 80286 CPU with their predecessor 8086. When the old CPU accesses space "behind" the 0xFFFFF (=1MiB) limit, they wrap around to 0x00000. On 80286 and newer processors accesses above 0xFFFFF natively do not wrap around. The external A20 gate forces this wrap also on newer CPUs. On older CPUs its open after reset, so the CPU cannot generate addresses with A20 set.
 [[Image:gatea20.png]]
@@ Line 257: / Line 257: @@
 ## activate CAR (CPU dependend)
 # At the end, its time to jump into the stage0_1 code at label stage1_main(). From now on, there is no more need for any special physical layout
 == coreboot V3 in Stages and Phases ==

@@ Line 266: / Line 266: @@
 Cache_As_RAM (CAR) setup. See How_coreboot_starts_after_Reset and How it works at runtime above.
 With CAR setup we can use C code.
 === Stage 1 ===

@@ Line 257: / Line 257: @@
 ## activate CAR (CPU dependend)
 # At the end, its time to jump into the stage0_1 code at label stage1_main(). From now on, there is no more need for any special physical layout
 {{Cc-by-2.5}}

← Older revision		Revision as of 12:17, 13 March 2008
Line 1:		Line 1:
−	To obtain the v3 sources, refer to [[Download coreboot]]. Further v3 documentation is provided in the <code>coreboot-v3/doc</code> subdirectory.	+	To obtain the v3 sources, refer to [[Download coreboot]]. Further v3 documentation is provided in the <code>coreboot-v3/doc</code> subdirectory. The design/newboot.lyx document describes the v3 structure and is a good read. [[Media:Newboot.pdf\|A PDF version]] is available here on the wiki, but may not always be completely up to date.

	== How to add a new board support ==		== How to add a new board support ==

@@ Line 1: / Line 1: @@
 To obtain the v3 sources, refer to [[Download coreboot]].  Further v3 documentation is provided in the <code>coreboot-v3/doc</code> subdirectory.
@@ Line 261: / Line 257: @@
 ## activate CAR (CPU dependend)
 # At the end, its time to jump into the stage0_1 code at label stage1_main(). From now on, there is no more need for any special physical layout

@@ Line 2: / Line 2: @@
 {{Cc-by-2.5}}
 == How to add a new board support ==
@@ Line 9: / Line 11: @@
 # add mainboard model to <code>mainboard/$vendor/Kconfig</code>,
 # create <code>mainboard/$vendor/$model/Kconfig</code> and <code>mainboard/$vendor/$model/Makefile</code> by copying from a similar model and modifying accordingly,
-# perform same copy/modify procedure for <code>mainboard/$vendor/$model/initram.c</code> and <code>mainboard/$vendor/$model/stage1.c</code>,
+# perform same copy/modify procedure for <code>mainboard/$vendor/$model/initram.c</code>, <code>mainboard/$vendor/$model/stage1.c</code>, and <code>mainboard/$vendor/$model/cmos.layout</code>,
 # create mainboard-specific files <code>mainboard/$vendor/$model/dts</code> and (possibly) <code>mainboard/$vendor/$model/irq_tables.c</code>, populate with board-specific data.
@@ Line 15: / Line 17: @@
 == How to add a new SuperIO device ==
-TBD
+TODO.  Please refer to documentation in the source tree.
 == How to add a new northbridge ==
-TBD
+TODO.  Please refer to documentation in the source tree.
 == How to add a new southbridge ==
-TBD
+TODO.  Please refer to documentation in the source tree.
 == How to add a new architecture support (CPU) ==

@@ Line 32: / Line 32: @@
 Whenever an x86 CPU wakes up after reset, it does it in Real Mode. This mode is limited to 1MiB address space and 64k offsets and the reset vector of the original 8086/88 was located at 0xFFFF0.
-As there was no change even if we run current processors like P3, these newer CPUs also feels like they where start at 0xF0000:0xFFF0 after a reset. But they do not. The base of the code segment register is 0xFFFF0000 after reset, so the CPU generates a physical address of 0xFFFFFFF0 to the chipset. And the chipset is responsible to forward this area to the boot ROM. Its confusing: The CPU "thinks" it runs code at 0xF000:0xFFF0 but instead it uses code at 0xFFFFFFF0. The developers must be tanked up when they realised this design into silicon.
+As there was no change even if we run current processors like P3, these newer CPUs also feels like they where start at 0xF0000:0xFFF0 after a reset. But they do not. The base of the code segment register is 0xFFFF0000 after reset, so the CPU generates a physical address of 0xFFFFFFF0 to the chipset. And the chipset is responsible to forward this area to the boot ROM. Its confusing: The CPU "thinks" it runs code at 0xF000:0xFFF0 but instead it uses code at 0xFFFFFFF0. The developers must have been tanked up when they realised this design into silicon.
 On some chipsets there is an additional pitfall: The so called A20 gate. It was introduced to support full compatibility for the 80286 CPU with their predecessor 8086. When the old CPU accesses space "behind" the 0xFFFFF (=1MiB) limit, they wrap around to 0x00000. On 80286 and newer processors accesses above 0xFFFFF natively do not wrap around. The external A20 gate forces this wrap also on newer CPUs. On older CPUs its open after reset, so the CPU cannot generate addresses with A20 set.

@@ Line 19: / Line 19: @@
 '''Implementation specification for the CAR code'''
-* What's to be provided to the rest of LinuxBIOSv3
+* What's to be provided to the rest of coreboot v3
 TBD
-* Exported labels to the rest of LinuxBIOSv3
+* Exported labels to the rest of coreboot v3
 TBD
 * Example implementations
@@ Line 28: / Line 28: @@
 ** what else is possible?
-== How LinuxBIOS starts after Reset ==
+== How coreboot starts after Reset ==
 Whenever an x86 CPU wakes up after reset, it does it in Real Mode. This mode is limited to 1MiB address space and 64k offsets and the reset vector of the original 8086/88 was located at 0xFFFF0.
@@ Line 89: / Line 89: @@
 [[Image:blocklayout.png]]
-These four fixed addresses are defined in the LinuxBIOSv3 menu when the expert mode is enabled. This menu is only important for developers, as they must define the addresses and sizes of this four areas to fit platform's requirements.
+These four fixed addresses are defined in the coreboot v3 menu when the expert mode is enabled. This menu is only important for developers, as they must define the addresses and sizes of this four areas to fit platform's requirements.
 The linker script to achive this layout looks like this:
@@ Line 156: / Line 156: @@
 After linking the whole code we could check the result with:
-  [jbe@jupiter]~/LinuxBIOSv3 > objdump -h build/stage0.o
+  [jbe@jupiter]~/coreboot-v3> objdump -h build/stage0.o
   build/stage0.o:     file format elf32-i386
@@ Line 189: / Line 189: @@
 We can check the result with objdump:
-  [jbe@jupiter]~/LinuxBIOSv3 > objdump -mi8086 -d -j .stage0_reset build/stage0.o
+  [jbe@jupiter]~/coreboot-v3> objdump -mi8086 -d -j .stage0_reset build/stage0.o
   build/stage0.o:     file format elf32-i386
@@ Line 222: / Line 222: @@
 We can also check the result with objdump:
-  [jbe@jupiter]~/LinuxBIOSv3 > objdump -mi8086 -d -j .stage0_real_mode build/stage0.o
+  [jbe@jupiter]~/coreboot-v3> objdump -mi8086 -d -j .stage0_real_mode build/stage0.o
   build/stage0.o:     file format elf32-i386