coreboot May 2011

coreboot@coreboot.org

62 participants
161 discussions

amd sb800 wrapper compile warning fix
by She, Kerry 01 Jun '11

01 Jun '11

Hello, This patch fix a AMD sb800 wrapper compile warning: src/southbridge/amd/cimx_wrapper/sb800/late call clear_ioapic but not include the prototype declare header file. and remove some trivial blanks. Signed-off-by Kerry She <Kerry.she(a)amd.com> Regards, Kerry She < kerry.she(a)amd.com> Tel: 86-10-6280-1415 Mobile: 86 - 152 1018 2083

3 4

[commit] r6554 - trunk/src/cpu/intel/model_6ex
by repository service 31 May '11

31 May '11

Author: svens Date: Tue May 3 09:55:43 2011 New Revision: 6554 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6554 Log: Enable caching for ROM area in model_6ex/cache_as_ram.inc Signed-off-by: Sven Schnelle <svens(a)stackframe.org> Acked-by: Sven Schnelle <svens(a)stackframe.org> Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Modified: trunk/src/cpu/intel/model_6ex/cache_as_ram.inc ============================================================================== --- trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Tue May 3 09:55:30 2011 (r6553) +++ trunk/src/cpu/intel/model_6ex/cache_as_ram.inc Tue May 3 09:55:43 2011 (r6554) @@ -201,7 +201,17 @@ xorl %edx, %edx wrmsr movl $MTRRphysMask_MSR(0), %ecx - movl $(~(1024 * 1024 - 1) | MTRRphysMaskValid), %eax + movl $(~(CONFIG_RAMTOP - 1) | MTRRphysMaskValid), %eax + movl $0x0000000f, %edx // 36bit address space + wrmsr + + /* Enable caching and Speculative Reads for the last 4MB. */ + movl $MTRRphysBase_MSR(1), %ecx + movl $(0xffc00000 | MTRR_TYPE_WRPROT), %eax + xorl %edx, %edx + wrmsr + movl $MTRRphysMask_MSR(1), %ecx + movl $(~(4 * 1024 * 1024 - 1) | MTRRphysMaskValid), %eax movl $0x0000000f, %edx // 36bit address space wrmsr

6 21

APM and VESA
by cinap_lenrek＠gmx.de 31 May '11

31 May '11

Hi, working on a bootloader, we added apm initialization code to the bootloader so the kernel doesnt have to switch to realmode and can just do 32 protected mode calls. the bootloader does the following things in realmode before starting the kernel: 1) do apm installation check (INT 0x15, AX=0x5300) 2) do apm disconnect (INT 0x15, AX=0x5304) 3) do apm connect to 32bit protected mode interface (INT 0x15, AX=0x5303, BX=0) 4) save and pass the register contents after the connect call in some form to the kernel but doing this seems to disable VESA bios functionality on some machines (via epia and p3-sbc) (INT 0x10, AX=0x4F00 doesnt return any modes) i dont have the machines where this happens and i dont know the exact return conditions of the vbe calls yet, but i plan to debug this using our realmode emulator but it might take us some time... my question is are we on the right track? is it possible that doing these APM calls disables VBE? -- cinap

2 1

About grub.cfg――Building coreboot with grub2 payload
by Cui Lei 31 May '11

31 May '11

I am working hard at building coreboot with grub2 payload. Now I can build a grub2 payload as follow: 1: Download the lastest grub2 source code. 2: ./autogen.sh ./configure --with-platform=coreboot make 3: Use grub-mkimage to generate a "payload.elf", detail: ./grub-mkimage -d . -O i386-coreboot -o ../coreboot-v4/payload.elf --prefix='/boot/grub2' memdisk cpio -m ../memdisk.tar Accoding the coreboot website(http://www.coreboot.org/Talk:GRUB2), memdisk is a virtual disk in grub image and it is suggested that grub.cfg is contained in a memdisk image. So I made folders boot/grub2 in my work folder and add a new grub.cfg and some modules(such as memdisk.mod cpio.mod ...) into the boot/grub2, then tar boot/grub2 to memdisk.tar(according to the website tar can be used to build a memdisk image). *Problems:* 1: I don't know wether grub2 can found my grub.cfg ,if I set " --prefix='/boot/grub2' " ? On the coreboot website,a sample is --prefix='(ata0)/boot/grub2'. I think the ata0 is hard disk. but I use the memdisk image, what should I do ? 2: I want my grub.cfg in memdisk to load the grub.cfg from my hard disk. Because I have install the ubuntu11.04 on my hard disk, a grub.cfg file should be in the /boot/grub. So my grub.cfg just like this: search -f -s /boot/grub/grub.cfg configfile /boot/grub/grub.cfg Is this practicable? 3: I want the gurb can boot into the grub-shell, how to ? BRs, Rock.C

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 30 May '11

30 May '11

1 0

Problem returned regarding SVN (and then vanished)
by Gregg Levine 30 May '11

30 May '11

Hello! Group I returned from vacation, (which is where SVN worked) on the Friday. Today I went ahead and attempted the regular and routine update of SVN. Stefan is it possible, however unlikely that something where you are located happens to be blocking any US based IP address in the range 66.167.246.40? For example that's my current one. And if I asked my router to update itself, it would probably pick up one from the Covad services end within the same range. This is especially strange as the folks from Covad practically insist that they do not block the port range used by SVN for example. Or any of the others. Well it just updated. Strange. The first two times today it hung itself. Now it worked. Still can one of you where you are, Stefan, check the machine logs? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 2

Coreboot issues with ASRock E350m1
by Marshall Buschman 27 May '11

27 May '11

Hello: I was instructed to send mail to you by Carebear from #coreboot. I have some issues to report based on the "Golden Image" I received from him, which was created for the ASRock E350M1. After booting, my Linux kernel panics like this: http://www.lucidmachines.com/coreboot/panic-lm-patched-2.6.39.txt I should mention that this is a slightly modified (http://www.lucidmachines.com/coreboot/2.6.39-pci-do-fixups.txt) kernel, patched to enable PCI Quirks only for a specific PCI ID: the video card. This is done so that the radeon firmware blobs can be loaded, enabling KMS, while not delaying my boot for 800ms. I have not tested this specific thing on a vanilla kernel, but it does work perfectly on a normal BIOS. CareBear told me to enable ACPI (and try it with the vanilla kernel), and it no longer panics, but he did note the following quirks: [ 0.137098] Extended Config Space enabled on 0 nodes [ 0.178984] ACPI: (supports S0 S5) [ 0.289970] Unable to assume _OSC PCIe control. Disabling ASPM [ 0.310267] ACPI: PCI Interrupt Link INTA (IRQs 3 4 5 7 10 11 12 15) *0, disabled. This last error is repeated for INTB to INTH Other issues: * Network card is not recognized at all (works fine with stock BIOS) * Total system RAM is reported as 480 Megabytes, actual system ram is 4096mbytes. The image I have does not have serial output enabled - I am working on getting another image compiled for better debug output - unfortunately, my time tonight is extremely limited, as I begin traveling tomorrow. I will return on Tuesday, May 31st, and will be unable to return emails until then. I do look forward to working with all of you on this. Thank you! -Marshall Buschman

2 1

Build coreboot with grub/grub2 payload
by Cui Lei 26 May '11

26 May '11

Hello, all I found that grub could be used as a coreboot payload at coreboot website, but no more detail messages. Can anyone give me some advices? I alse found there were great resource at http://grub.enbug.org, but I can not open it, the other people around me can not open it either, maybe, its address had changed. Can anyone open it? BRs, Rock.C

3 2

Build coreboot with grub/grub2 payload
by 崔磊 26 May '11

26 May '11

2 1

Re: [coreboot] unifying `acpi_tables.c`
by shawn Bai 26 May '11

26 May '11

Hi,folks, I searched for 'acpi_tables.c' in directory 'mainboard', and 49 entries come.They are as follows, but not all listed here,just for your reference. coreboot\src\mainboard\advansus\a785e-i\acpi_tables.ccoreboot\src\mainboard\amd\bimini_fam10\acpi_tables.ccoreboot\src\mainboard\amd\dbm690t\acpi_tables.ccoreboot\src\mainboard\amd\inagua\acpi_tables.ccoreboot\src\mainboard\amd\mahogany\acpi_tables.ccoreboot\src\mainboard\amd\mahogany_fam10\acpi_tables.ccoreboot\src\mainboard\amd\persimmon\acpi_tables.ccoreboot\src\mainboard\amd\pistachio\acpi_tables.c I don't know ACPI and don't know the reason why there are so many files with the same name scattering in different subdirectories. For different mainboards, should the implementation in 'acpi_tables.c' be so different? Does it depend on ACPI spec or the mainboard details, or both? Maybe the answer is quite clear; I know little, so forgive me have this problem. I find the contents of some 'acpi_tables.c' among the 49 entries are the same，or just different with a conditional preprocessor macros,such as '#if CONFIG_BOARD_HAS_FADT == 1'. Definitely, the 49 files with the same name 'acpi_tables.c' can be combined into one or more files, but the number must be less than 49, and this can reduce the chance of errors. ---------------------------------------- > Message: 5 > Date: Thu, 19 May 2011 00:14:49 +0200 > From: Paul Menzel > To: coreboot(a)coreboot.org > Subject: [coreboot] unifying `acpi_tables.c` (was: [PATCH] workaround > for "An unexpected error (805262864) occurred at line 1768 of > d:\xpclient\base\boot\setup\arcdisp.c") > Message-ID: <1305756889.12722.49.camel@mattotaupa> > Content-Type: text/plain; charset="utf-8" > > Dear Scott and coreboot folks, > > > Am Mittwoch, den 18.05.2011, 01:40 -0500 schrieb Scott Duplichan: > > [?] > > looking at the change > > > Index: src/mainboard/amd/bimini_fam10/acpi_tables.c > > =================================================================== > > --- src/mainboard/amd/bimini_fam10/acpi_tables.c (revision 6599) > > +++ src/mainboard/amd/bimini_fam10/acpi_tables.c (working copy) > > @@ -127,6 +127,31 @@ > > acpi_write_rsdp(rsdp, rsdt, NULL); > > acpi_write_rsdt(rsdt); > > > > + /* DSDT */ > > + current = ( current + 0x07) & -0x08; > > + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); > > + dsdt = (acpi_header_t *)current; // it will used by fadt > > + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); > > + current += dsdt->length; > > + memcpy(dsdt, &AmlCode, dsdt->length); > > + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); > > + > > + /* FACS */ // it needs 64 bit alignment > > + current = ( current + 0x07) & -0x08; > > + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); > > + facs = (acpi_facs_t *) current; // it will be used by fadt > > + current += sizeof(acpi_facs_t); > > + acpi_create_facs(facs); > > + > > + /* FADT */ > > + current = ( current + 0x07) & -0x08; > > + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); > > + fadt = (acpi_fadt_t *) current; > > + current += sizeof(acpi_fadt_t); > > + > > + acpi_create_fadt(fadt, facs, dsdt); > > + acpi_add_table(rsdp, fadt); > > [?] > > the contents seems to very similar. Besides some comments even > identical. > > Can `acpi_tables.c` be shared between certain families or even all new > boards? > > If yes, maybe that could be put on a todo list. > > > Thanks, > > Paul > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 198 bytes > Desc: This is a digitally signed message part > URL: > > ------------------------------ > > Message: 6 > Date: Thu, 19 May 2011 00:21:35 +0200 > From: Peter Stuge > To: coreboot(a)coreboot.org > Subject: Re: [coreboot] unifying `acpi_tables.c` > Message-ID: <20110518222135.31713.qmail(a)stuge.se> > Content-Type: text/plain; charset="us-ascii" > > Paul Menzel wrote: > > Can `acpi_tables.c` be shared between certain families or even all > > new boards? > > > > If yes, maybe that could be put on a todo list. > > Yeah, I ranted about this a bit on IRC. Will take a look in Prague. > > > //Peter > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 190 bytes > Desc: not available > URL: > > ------------------------------ > > _______________________________________________ > coreboot mailing list > coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > End of coreboot Digest, Vol 75, Issue 55 > ****************************************

2 1

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 May 2011