coreboot March 2012

coreboot@coreboot.org

58 participants
718 discussions

Patch merged into coreboot/master: 1b0d000 Include arch/acpi.h instead of manually adding acpi_slp_type.
by gerrit＠coreboot.org 28 Mar '12

28 Mar '12

the following patch was just integrated into master: commit 1b0d000be7468923efade01d70aaed1e8b1ca0e3 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Fri Sep 23 10:24:49 2011 -0700 Include arch/acpi.h instead of manually adding acpi_slp_type. acpi_slp_type is defined in arch/acpi.h, so let's use that instead of manually spreading extern u8 acpi_slp_type throughout the code. Change-Id: Ia5eb420364c15ab5a764bc328bbd201ca9cb7837 Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Build-Tested: build bot (Jenkins) at Fri Mar 9 09:54:47 2012, giving +1 See http://review.coreboot.org/714 for details. -gerrit

1 0

Patch merged into coreboot/master: 7a95abb Add timestamp collecting to coreboot.
by gerrit＠coreboot.org 28 Mar '12

28 Mar '12

the following patch was just integrated into master: commit 7a95abbb000a9088f65e19a78e2468dea8e5b740 Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Wed Sep 21 16:12:39 2011 -0700 Add timestamp collecting to coreboot. This patch adds code to initialize the time stamp collection facility in coreboot. It adds a table in the CBMEM section, which provides the base timer reading value (all other readings are offsets of this one) and an array of timestamp id/timestamp value pairs. Just two values are being added now, this will have to be used more extensively and also integrated into payloads to provide more comprehensive boot process time measurements. Also, since the CBMEM area could already contain a section (from the previous run, before reset), when processing a section addition request we should check if a section already exists and return its address, if so. Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Build-Tested: build bot (Jenkins) at Fri Mar 9 09:24:17 2012, giving +1 See http://review.coreboot.org/713 for details. -gerrit

1 0

Patch merged into coreboot/master: 8254fd4 Add a config flag to enable time stamp collection
by gerrit＠coreboot.org 28 Mar '12

28 Mar '12

the following patch was just integrated into master: commit 8254fd40495371ad1475e03c92741366deed09f1 Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Wed Sep 21 14:46:43 2011 -0700 Add a config flag to enable time stamp collection Add a new flag, make it dependent on EARLY_CBMEM_INIT Change-Id: Idbebcaf298238f31a73e9eb4a9af7b03e857bc74 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Build-Tested: build bot (Jenkins) at Fri Mar 9 09:41:38 2012, giving +1 See http://review.coreboot.org/712 for details. -gerrit

1 0

Patch merged into coreboot/master: 710fe3b Initialize CBMEM early.
by gerrit＠coreboot.org 28 Mar '12

28 Mar '12

the following patch was just integrated into master: commit 710fe3bd556cc9de1e7067a4ca22e19b97475b1b Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Tue Sep 20 17:07:14 2011 -0700 Initialize CBMEM early. We want to be able to share data between different phases of firmware (rom stage/ram stage/payload). Coreboot CBMEM seems an appropriate location for this data, but normally it is not initialized until coreboot reaches the ram stage. This change initializes the CBMEM while still in rom stage in case CONFIG_EARLY_CBMEM_INIT is set. Note that there is a discrepancy in how coreboot determines the size of DRAM at rom and ram stages, get_top_of_ram() is used at rom stage and is not defined for all platforms. Those platforms will have to define this function should they enable the CONFIG_EARLY_CBMEM_INIT flag. Change-Id: I81691d45e28de59496fb227f2cca4e8c15ece717 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Build-Tested: build bot (Jenkins) at Fri Mar 9 06:53:47 2012, giving +1 See http://review.coreboot.org/711 for details. -gerrit

1 0

Patch merged into coreboot/master: 67cbf9d Introduce config option to initialize CBMEM early.
by gerrit＠coreboot.org 28 Mar '12

28 Mar '12

the following patch was just integrated into master: commit 67cbf9dd64a323f7bae11e2a78a495fdd70461a7 Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Tue Sep 20 16:46:46 2011 -0700 Introduce config option to initialize CBMEM early. We want to be able to communicate information between rom and ram stages of coreboot. This configuration option will be used to compile such ability in. Change-Id: I6736fdc264ecd0b63369b28462d7bb96e4c2b012 Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Build-Tested: build bot (Jenkins) at Fri Mar 9 07:09:00 2012, giving +1 See http://review.coreboot.org/710 for details. -gerrit

1 0

Re: [coreboot] Fwd: porting Coreboot to a new motherboard....
by Kyösti Mälkki 28 Mar '12

28 Mar '12

On Wed, 2012-03-28 at 17:22 +0430, ali hagigat wrote: > I just added 10 "nop" assembly command("no operation")! > 10 because the number of the Pentium III pipeline stages is 10. > Very simple and strange. After adding that, each time hardwaremain() > got executed and the code continued loading FILO. > Try to use original coreboot tree, with your raminit of course, but this time do not enable RAM cache for 0x0-CONFIG_RAMTOP range. That is typically the (variable) MTRR 0 setting close to the end of cache_as_ram.inc. KM

1 0

Re: [coreboot] Fwd: porting Coreboot to a new motherboard....
by Idwer Vollering 28 Mar '12

28 Mar '12

Op 28 maart 2012 14:52 heeft ali hagigat <hagigatali(a)gmail.com> het volgende geschreven: > --------- Forwarded message ---------- > From: ali hagigat <hagigatali(a)gmail.com> > Date: Wed, Mar 28, 2012 at 4:58 PM > Subject: Re: [coreboot] porting Coreboot to a new motherboard.... > To: Kyösti Mälkki <kyosti.malkki(a)gmail.com> > > > Dear Kyösti > > I just added 10 "nop" assembly command("no operation")! Please show your code in diff-formatting, because what you have shown isn't reallye readable: it does not show your additions in a clear way. Also I want to emphasize Stefan's answer ( http://www.coreboot.org/pipermail/coreboot/2012-February/068335.html ): "But generally, I suggest you rewrite this in C, so it's a lot more readable..." > 10 because the number of the Pentium III pipeline stages is 10. > Very simple and strange. After adding that, each time hardwaremain() > got executed and the code continued loading FILO. > > Now another strange thing (and a similar work i saw before when i was > working on hardwaremain()): > I add some "nop" like: > > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > to the start_linux() function of FILO ( in linux_load.c) and switch.S > as follows: > > static int start_linux(uint32_t kern_addr, struct linux_params *params) > { > struct segment_desc *linux_gdt; > struct context *ctx; > #ifdef VGA_CONSOLE > extern int cursor_x, cursor_y; > #endif > #ifdef PCMCIA_CF > uint32_t cf_bar; > int i; > #endif > > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx = init_context(phys_to_virt(STACK_LOC), 4096, 0); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > /* Linux expects GDT being in low memory */ > linux_gdt = phys_to_virt(GDT_LOC); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > memset(linux_gdt, 0, 13*sizeof(struct segment_desc)); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > /* Normal kernel code/data segments */ > linux_gdt[2] = gdt[FLAT_CODE]; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > linux_gdt[3] = gdt[FLAT_DATA]; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > /* 2.6 kernel uses 12 and 13, but head.S uses backward-compatible > * segments (2 and 3), so it SHOULD not be a problem. > * However, some distro kernels (eg. RH9) with backported threading > * patch use 12 and 13 also when booting... */ > linux_gdt[12] = gdt[FLAT_CODE]; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > linux_gdt[13] = gdt[FLAT_DATA]; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->gdt_base = GDT_LOC; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->gdt_limit = 14*8-1; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->cs = 0x10; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->ds = 0x18; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->es = 0x18; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->fs = 0x18; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->gs = 0x18; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx->ss = 0x18; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > /* Parameter location */ > ctx->esi = virt_to_phys(params); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > /* Entry point */ > ctx->eip = kern_addr; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > debug("eip=%#x\n", kern_addr); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > printf("Jumping to entry point...\n"); > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > > #ifdef VGA_CONSOLE > /* Update VGA cursor position. > * This must be here because the printf changes the value! */ > params->orig_x = cursor_x; > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > params->orig_y = cursor_y; > #endif > #ifdef PCMCIA_CF > cf_bar = phys_to_virt(pci_read32(PCI_ADDR(0, 0xa, 1), 0x10)); > for( i = 0x836 ; i < 0x840 ; i++){ > *(unsigned char *)(cf_bar+i) = 0; > } > #endif > /* Go... */ > asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); > ctx = switch_to(ctx); > > /* It's impossible but... */ > printf("Returned with eax=%#x\n", ctx->eax); > > return ctx->eax; > } > > > __switch_context: > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop > > /* Save everything in current stack */ > pushfl /* 56 */ > pushl %ds /* 52 */ > pushl %es /* 48 */ > pushl %fs /* 44 */ > pushl %gs /* 40 */ > pushal /* 8 */ > subl $8, %esp > movw %ss, (%esp) /* 0 */ > sgdt 2(%esp) /* 2 */ > > #if 0 > /* Swap %cs and %eip on the stack, so lret will work */ > movl 60(%esp), %eax > xchgl %eax, 64(%esp) > movl %eax, 60(%esp) > #endif > > /* At this point we don't know if we are on flat segment > * or relocated. So compute the address offset from %eip. > * Assuming CS.base==DS.base==SS.base. > */ > call 1f > 1: popl %ebx > subl $1b, %ebx > > /* Interrupts are not allowed... */ > cli > > /* Current context pointer is our stack pointer */ > movl %esp, %esi > > /* Normalize the ctx pointer */ > subl %ebx, %esi > > /* Swap it with new value */ > xchgl %esi, __context(%ebx) > > /* Adjust new ctx pointer for current address offset */ > addl %ebx, %esi > > /* Load new %ss and %esp to temporary */ > movzwl (%esi), %edx > movl 20(%esi), %eax > > /* Load new GDT */ > lgdt 2(%esi) > > /* Load new stack segment with new GDT */ > movl %edx, %ss > > /* Set new stack pointer, but we have to adjust it because > * pushal saves %esp value before pushal, and we want the value > * after pushal. > */ > leal -32(%eax), %esp > > /* Load the rest from new stack */ > popal > popl %gs > popl %fs > popl %es > popl %ds > popfl > > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop > > /* Finally, load new %cs and %eip */ > lret > > > The rest of the code(COREBOOT+FILO) is exactly the same. What happens > is that CPU executes the code till boot() function!! and stops! I can > not even see printf() output of autoboot_delay() function!! > > What is happening here? I changed two functions which are executed > after boot() , how "nop" commands are effecting boot() and > autoboot_delay()? > > > Can you explain it? > > Regards > > On Wed, Mar 28, 2012 at 4:14 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >> On Wed, 2012-03-28 at 13:51 +0430, ali hagigat wrote: >>> I remember when i ported my RAM initialization code, hardwaremain() >>> could not be run. The problem was not RAM, it was CPU! i chaned >>> c_start() a bit to solve the problem. >>> What do you mean by earlyprintk(), do you suggest to change linux >>> kernel to monitor it? >>> >>> Regards >>> >> >> A diff of that c_start() change, please. >> >> Thanks, >> KM >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Fwd: porting Coreboot to a new motherboard....
by ali hagigat 28 Mar '12

28 Mar '12

--------- Forwarded message ---------- From: ali hagigat <hagigatali(a)gmail.com> Date: Wed, Mar 28, 2012 at 4:58 PM Subject: Re: [coreboot] porting Coreboot to a new motherboard.... To: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Dear Kyösti I just added 10 "nop" assembly command("no operation")! 10 because the number of the Pentium III pipeline stages is 10. Very simple and strange. After adding that, each time hardwaremain() got executed and the code continued loading FILO. Now another strange thing (and a similar work i saw before when i was working on hardwaremain()): I add some "nop" like: asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); to the start_linux() function of FILO ( in linux_load.c) and switch.S as follows: static int start_linux(uint32_t kern_addr, struct linux_params *params) { struct segment_desc *linux_gdt; struct context *ctx; #ifdef VGA_CONSOLE extern int cursor_x, cursor_y; #endif #ifdef PCMCIA_CF uint32_t cf_bar; int i; #endif asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx = init_context(phys_to_virt(STACK_LOC), 4096, 0); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); /* Linux expects GDT being in low memory */ linux_gdt = phys_to_virt(GDT_LOC); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); memset(linux_gdt, 0, 13*sizeof(struct segment_desc)); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); /* Normal kernel code/data segments */ linux_gdt[2] = gdt[FLAT_CODE]; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); linux_gdt[3] = gdt[FLAT_DATA]; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); /* 2.6 kernel uses 12 and 13, but head.S uses backward-compatible * segments (2 and 3), so it SHOULD not be a problem. * However, some distro kernels (eg. RH9) with backported threading * patch use 12 and 13 also when booting... */ linux_gdt[12] = gdt[FLAT_CODE]; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); linux_gdt[13] = gdt[FLAT_DATA]; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->gdt_base = GDT_LOC; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->gdt_limit = 14*8-1; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->cs = 0x10; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->ds = 0x18; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->es = 0x18; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->fs = 0x18; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->gs = 0x18; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx->ss = 0x18; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); /* Parameter location */ ctx->esi = virt_to_phys(params); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); /* Entry point */ ctx->eip = kern_addr; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); debug("eip=%#x\n", kern_addr); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); printf("Jumping to entry point...\n"); asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); #ifdef VGA_CONSOLE /* Update VGA cursor position. * This must be here because the printf changes the value! */ params->orig_x = cursor_x; asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); params->orig_y = cursor_y; #endif #ifdef PCMCIA_CF cf_bar = phys_to_virt(pci_read32(PCI_ADDR(0, 0xa, 1), 0x10)); for( i = 0x836 ; i < 0x840 ; i++){ *(unsigned char *)(cf_bar+i) = 0; } #endif /* Go... */ asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop"); ctx = switch_to(ctx); /* It's impossible but... */ printf("Returned with eax=%#x\n", ctx->eax); return ctx->eax; } __switch_context: nop nop nop nop nop nop nop nop nop nop /* Save everything in current stack */ pushfl /* 56 */ pushl %ds /* 52 */ pushl %es /* 48 */ pushl %fs /* 44 */ pushl %gs /* 40 */ pushal /* 8 */ subl $8, %esp movw %ss, (%esp) /* 0 */ sgdt 2(%esp) /* 2 */ #if 0 /* Swap %cs and %eip on the stack, so lret will work */ movl 60(%esp), %eax xchgl %eax, 64(%esp) movl %eax, 60(%esp) #endif /* At this point we don't know if we are on flat segment * or relocated. So compute the address offset from %eip. * Assuming CS.base==DS.base==SS.base. */ call 1f 1: popl %ebx subl $1b, %ebx /* Interrupts are not allowed... */ cli /* Current context pointer is our stack pointer */ movl %esp, %esi /* Normalize the ctx pointer */ subl %ebx, %esi /* Swap it with new value */ xchgl %esi, __context(%ebx) /* Adjust new ctx pointer for current address offset */ addl %ebx, %esi /* Load new %ss and %esp to temporary */ movzwl (%esi), %edx movl 20(%esi), %eax /* Load new GDT */ lgdt 2(%esi) /* Load new stack segment with new GDT */ movl %edx, %ss /* Set new stack pointer, but we have to adjust it because * pushal saves %esp value before pushal, and we want the value * after pushal. */ leal -32(%eax), %esp /* Load the rest from new stack */ popal popl %gs popl %fs popl %es popl %ds popfl nop nop nop nop nop nop nop nop nop nop /* Finally, load new %cs and %eip */ lret The rest of the code(COREBOOT+FILO) is exactly the same. What happens is that CPU executes the code till boot() function!! and stops! I can not even see printf() output of autoboot_delay() function!! What is happening here? I changed two functions which are executed after boot() , how "nop" commands are effecting boot() and autoboot_delay()? Can you explain it? Regards On Wed, Mar 28, 2012 at 4:14 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Wed, 2012-03-28 at 13:51 +0430, ali hagigat wrote: >> I remember when i ported my RAM initialization code, hardwaremain() >> could not be run. The problem was not RAM, it was CPU! i chaned >> c_start() a bit to solve the problem. >> What do you mean by earlyprintk(), do you suggest to change linux >> kernel to monitor it? >> >> Regards >> > > A diff of that c_start() change, please. > > Thanks, > KM >

1 0

Re: [coreboot] porting Coreboot to a new motherboard....
by Kyösti Mälkki 28 Mar '12

28 Mar '12

On Wed, 2012-03-28 at 13:51 +0430, ali hagigat wrote: > I remember when i ported my RAM initialization code, hardwaremain() > could not be run. The problem was not RAM, it was CPU! i chaned > c_start() a bit to solve the problem. > What do you mean by earlyprintk(), do you suggest to change linux > kernel to monitor it? > > Regards > A diff of that c_start() change, please. Thanks, KM

1 0

Re: [coreboot] porting Coreboot to a new motherboard....
by ali hagigat 28 Mar '12

28 Mar '12

Thank you, Ron, for the reply. I have checked RAM by one assembly code i developed, the whole code has been written by myself(it is not Coreboot). I tested RAM , particularly the first 5 mega bytes by read/write cycles and "mov" instructions. I even had a serial port code in EPROM , i copied that to RAM and jumped to execute it and it was OK. Besides I checked RAM by ramcheck() function of Coreboot. I will test it finally by memtest(). But i am believing that the problem is some where else. I remember when i ported my RAM initialization code, hardwaremain() could not be run. The problem was not RAM, it was CPU! i chaned c_start() a bit to solve the problem. What do you mean by earlyprintk(), do you suggest to change linux kernel to monitor it? Regards

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
72
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2012