coreboot September 2010

coreboot@coreboot.org

58 participants
324 discussions

[PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Juhana Helovuo 19 Sep '10

19 Sep '10

On Sat, 2010-09-18 at 00:14 +0200, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > In the mean time i checked RAM with memtest86+ v4.0 provided with > Ubuntu 10.04, and it is not working at all, 0kb RAM detected with > coreboot+seabios. > On tyan bios all the RAM is detected properly (no errors on tests > too). > > I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. Hello, My guess from your memtest86+ printouts is the following: With Tyan BIOS, memtest86+ uses BIOS call "e820" to find out the available RAM. With Coreboot + SeaBIOS, memtes86+ detects that there are Coreboot tables in memory ("LxBIOS"), but for some reason thinks that the table reports 0k memory. This may be because your memtest86+ version does not support Coreboot "high tables", and therefore detects the presence of Coreboot, but cannot read the contents of the table. Coreboot does not implement the e820 interface, but SeaBIOS should have it available. However, when memtest86+ detects that Coreboot is present, it ignores the e820 interface and tries to read the Coreboot tables. I have made a patch for memtest86+ v4.10, which adds better support for Coreboot and also multiboot tables. The patch is not my original work, but a combination of two patches, so the credit belongs to the original authors. Application instructions: * Download memtest86+ v 4.10 sources .tar.gz and untar * Apply patch, e.g. patch -p1 < ../coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch * Manually rename two files: % mv linuxbios.c coreboot.c % mv linuxbios_tables.h coreboot_tables.h * Build memtest86+ using "make" The build process creates two versions of the memtest86+ binary. "memtest" is multiboot-compatible ELF executable and "memtest.bin" is bootable image like a Linux kernel image. Choosing between these two depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a bootloader. My success with memtest86+ has been rather limited, but maybe this works for you. Best regards, Juhana Helovuo

2 1

[PATCH] fix 'AMD Fam10 code breaks with gcc 4.5.0'
by Scott 17 Sep '10

17 Sep '10

Hello, The subversion comment for -r 5571 states: The AMD Fam10 code breaks with coreboot 4.5.0. Potentially caused by reordering. Going back to 4.4.4 which is known working on Fam10 until gcc or the Fam10 code is fixed. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> I encountered the same problem and debugged it. The AP code that disables cache as ram before the final halt has to be all inline. Function calls require a valid stack, and the stack is kept in the very cache as ram that the code is disabling. I found with gcc 450, the code for rdmsr, disable_cache, and enable_cache and not getting inlined as intended. Function calls are generated, and the first one after the AP clears msr 268 fails. The solution is to force these functions to generate inline code by adding __attribute__((always_inline)) to their declarations: Index: src/include/cpu/x86/msr.h =================================================================== --- src/include/cpu/x86/msr.h (revision 5763) +++ src/include/cpu/x86/msr.h (working copy) @@ -29,7 +29,7 @@ msr_t msr; } msrinit_t; -static inline msr_t rdmsr(unsigned index) +static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index) { msr_t result; __asm__ __volatile__ ( @@ -40,7 +40,7 @@ return result; } -static inline void wrmsr(unsigned index, msr_t msr) +static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t msr) { __asm__ __volatile__ ( "wrmsr" Index: src/include/cpu/x86/cache.h =================================================================== --- src/include/cpu/x86/cache.h (revision 5763) +++ src/include/cpu/x86/cache.h (working copy) @@ -74,7 +74,7 @@ asm volatile("invd" ::: "memory"); } -static inline void enable_cache(void) +static inline __attribute__((always_inline)) void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); @@ -82,7 +82,7 @@ write_cr0(cr0); } -static inline void disable_cache(void) +static inline __attribute__((always_inline)) void disable_cache(void) { /* Disable and write back the cache */ unsigned long cr0; Thanks, Scott

9 12

Re: [coreboot] RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Peter Stuge 17 Sep '10

17 Sep '10

STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > PCI: 40:00.0 [1022/7450] bus ops > PCI: 40:00.0 [1022/7450] enabled Bus 40? > PCI: 41: 133MHz PCI-X > PCI: 42: 100MHz PCI-X And 41 and 42. > PCI: 80:00.0 [10de/005e] ops > PCI: 80:00.0 [10de/005e] enabled And 80? It's far between them.. Maybe things should work anyway, but still. > [ 1.565157] powernow-k8: Found 2 AMD Opteron(tm) Processor 256 processors (2 cpu cores) (version 2.20.00) > [ 1.574860] ACPI Warning for \_PR_.CPU0._PSS: Return Package has no elements (empty) (20090903/nspredef-433) > [ 1.584865] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. > [ 1.584868] [Firmware Bug]: powernow-k8: Try again with latest BIOS. Another problem.. Linux doesn't like our ACPI for powersaving, but this should really only mean that powersaving is disabled, so should not cause any problem with booting. //Peter

2 1

[commit] r5818 - trunk/src/include/cpu/x86
by repository service 17 Sep '10

17 Sep '10

Author: mjones Date: Fri Sep 17 23:38:40 2010 New Revision: 5818 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5818 Log: AMD Fam10 code breaks with gcc 4.5.0. Root cause: After function STOP_CAR_AND_CPU disables cache as ram, the cache as ram stack can no longer be used. Called functions must be inlined to avoid stack usage. Also, the compiler must keep local variables register based and not allocated them from the stack. With gcc 4.5.0, some functions declared as inline are not being inlined. This patch forces these functions to always be inlined by adding the qualifier __attribute__((always_inline)) to their declaration. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/include/cpu/x86/cache.h trunk/src/include/cpu/x86/msr.h Modified: trunk/src/include/cpu/x86/cache.h ============================================================================== --- trunk/src/include/cpu/x86/cache.h Fri Sep 17 02:13:52 2010 (r5817) +++ trunk/src/include/cpu/x86/cache.h Fri Sep 17 23:38:40 2010 (r5818) @@ -74,7 +74,17 @@ asm volatile("invd" ::: "memory"); } -static inline void enable_cache(void) +/* The following functions require the always_inline due to AMD + * function STOP_CAR_AND_CPU that disables cache as + * ram, the cache as ram stack can no longer be used. Called + * functions must be inlined to avoid stack usage. Also, the + * compiler must keep local variables register based and not + * allocated them from the stack. With gcc 4.5.0, some functions + * declared as inline are not being inlined. This patch forces + * these functions to always be inlined by adding the qualifier + * __attribute__((always_inline)) to their declaration. + */ +static inline __attribute__((always_inline)) void enable_cache(void) { unsigned long cr0; cr0 = read_cr0(); @@ -82,7 +92,7 @@ write_cr0(cr0); } -static inline void disable_cache(void) +static inline __attribute__((always_inline)) void disable_cache(void) { /* Disable and write back the cache */ unsigned long cr0; Modified: trunk/src/include/cpu/x86/msr.h ============================================================================== --- trunk/src/include/cpu/x86/msr.h Fri Sep 17 02:13:52 2010 (r5817) +++ trunk/src/include/cpu/x86/msr.h Fri Sep 17 23:38:40 2010 (r5818) @@ -29,7 +29,17 @@ msr_t msr; } msrinit_t; -static inline msr_t rdmsr(unsigned index) +/* The following functions require the always_inline due to AMD + * function STOP_CAR_AND_CPU that disables cache as + * ram, the cache as ram stack can no longer be used. Called + * functions must be inlined to avoid stack usage. Also, the + * compiler must keep local variables register based and not + * allocated them from the stack. With gcc 4.5.0, some functions + * declared as inline are not being inlined. This patch forces + * these functions to always be inlined by adding the qualifier + * __attribute__((always_inline)) to their declaration. + */ +static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index) { msr_t result; __asm__ __volatile__ ( @@ -40,7 +50,7 @@ return result; } -static inline void wrmsr(unsigned index, msr_t msr) +static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t msr) { __asm__ __volatile__ ( "wrmsr"

1 0

Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Myles Watson 17 Sep '10

17 Sep '10

> > GRUB_CMDLIN_LINUX_DEFAULT="verbose" in /etc/default/grub and "sudo > update-> grub" > I will do it, with original VGA bios and prebuild seabios too. Since there's no built-in video card on the s2895, there shouldn't be a VGA BIOS for the board. I was thinking of the s2892. My s2895 boots fine, so when you get a log & send it to the list, we should be able to figure out what's going wrong pretty easily. Thanks, Myles

2 1

Porting coreboot to Unknown Sis620/5595 Motherboard
by Hernan Freschi 17 Sep '10

17 Sep '10

Hello, I'd like to port coreboot to a motherboard I have. I dont have either brand or model (it's a generic OEM board). I'm not sure what info is needed so I have uploaded: lspci -xxxvvvnnn http://pastebin.org/876731 superiotool -deV http://pastebin.org/876714 I'd like to know if it's possible and what are the steps to get started. Thanks, Hernan

3 4

Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Corey Osgood 17 Sep '10

17 Sep '10

On Thu, Sep 16, 2010 at 1:18 PM, STEMMELIN, FREDERIC (FREDERIC)** CTR ** <frederic.stemmelin(a)alcatel-lucent.com> wrote: > The computer is booting, and then crashing on Ubuntu logo (10.04 64bits version), so far so nice. In your /etc/default/grub, comment out this line: GRUB_CMDLIN_LINUX_DEFAULT="quiet splash" and replace it with GRUB_CMDLIN_LINUX_DEFAULT="verbose" Then do "sudo update-grub" to update the config files. That should let you see exactly *where* it's failing. -Corey

2 1

Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Scott Duplichan 17 Sep '10

17 Sep '10

]Now i have a 3 questions for you: ]The build seabios (bios.bin.elf) is about 1MB in size..., The seabios web page has links to prebuilt binaries. You could start off using one of these known-good seabios binaries to eliminate unknowns. ]I didnt put VGA bios so far into the coreboot.rom. If you see the F12 message on the connected monitor, then a suitable video bios has been found and used. By the way, I have this exact board sitting on the shelf. If I can dig up a suitable power supply, I might give it a try. Thanks, Scott

2 1

Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Myles Watson 17 Sep '10

17 Sep '10

> Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build a > 64bits version of the coreboot bios, as i intend to run a 64bits OS ? Coreboot is 32 bit, but it will work fine with a 64-bit OS. > I build the seabios with Ubuntu gcc 64bits version, it is compatible, can > i mix it, with the coreboot.rom build with i386-elf coreboot toolchain ? > The build seabios (bios.bin.elf) is about 1MB in size, how it is possible > to put it into a smaller 512KB chip inside coreboot.rom ? Most of it is empty space. When the ELF gets unpacked, it doesn't take that much space. > I didnt put VGA bios so far into the coreboot.rom. Have you tried using a separate graphics card? That would narrow down the problem. I would try adding the VGA BIOS, though. > In my opinion, it would be a good idea to mention, somewhere in the build > howto, that there is a integrated toolchain in coreboot, and may be also > mention not to forget to delete the .xcompile file after the toolchain was > built. I thought if you did a 'make clean' it deleted the .xcompile file. > What are your advice for the next steps ? I would add a Video card or put the VGA BIOS into coreboot.rom. Whichever one you find easier. Thanks, Myles

2 1

Re: [coreboot] First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Peter Stuge 17 Sep '10

17 Sep '10

Hi Frederic, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > this was my first try to build a coreboot bios ever, for my tyan > s2895 mobo. Cool! Remember that coreboot is not a BIOS, all the BIOS stuff is in SeaBIOS, the coreboot payload. coreboot just does the early hardware initialization. :) > The computer is booting, and then crashing on Ubuntu logo (10.04 > 64bits version), so far so nice. This is pretty good progress for the very first try! :) > I downloaded latest available verszion of payload seabios, with > command "git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios". .. > The make command has build the file => out/bios.bin.elf 1048716 bytes This is wrong. The SeaBIOS payload file should only be a few hundred kb. There is a problem with the build of SeaBIOS. > Now i downloaded latest coreboot files, with a > "svn co svn://coreboot.org/coreboot/trunk coreboot" > But, on first "make", i run into troubles: .. > Then i find out (in some mailing list archive) that there is a > integrated compiling toolchain in the coreboot files, under > "coreboot/util/crossgcc". We have discovered that the toolchains shipped in many distributions can not correctly build coreboot. So the script that makes a "reference" toolchain was created. > I burned the coreboot.rom into the RD1 chip, and restared the > computer. I then saw briefly a message about pressing F12 for some > configuration. This message is from SeaBIOS. When you see the message, coreboot has already finished. > After some other quick messages, which i coulnd read, i saw Ubuntu > starting and then crashing on the graphical logo. Too bad. :( Hopefully we can identify the reason for this. > Now i have a 3 questions for you: > > Is the coreboot.rom 32bits only and is there any advantage to build > a 64bits version of the coreboot bios, as i intend to run a 64bits OS ? coreboot.rom has both 16-bit and 32-bit code, but no 64-bit code. I don't believe it is common (at least not yet) to boot directly in 64-bit mode. Rather all operating systems will handle the switch into 64-bit mode themselves. > I build the seabios with Ubuntu gcc 64bits version, it is > compatible, can i mix it, with the coreboot.rom build with i386-elf > coreboot toolchain ? In theory yes, you can build coreboot with one toolchain, and the payload with another, that's not a problem, but it of course requires that both toolchains actually build correct binaries. :) Because of the abnormally large size of your SeaBIOS binary I think it is possible that the Ubuntu toolchain also can not build SeaBIOS correctly. I would definately try to build SeaBIOS with the i386-elf toolchain and see if the results are any different. > The build seabios (bios.bin.elf) is about 1MB in size, how it is > possible to put it into a smaller 512KB chip inside coreboot.rom ? bios.bin.elf should be much smaller. > I didnt put VGA bios so far into the coreboot.rom. Do you have a discrete graphics card in your system? I think you do, otherwise how could the graphics card have been initialized? > In my opinion, it would be a good idea to mention, somewhere in the > build howto, that there is a integrated toolchain in coreboot, and > may be also mention not to forget to delete the .xcompile file > after the toolchain was built. I think this is a good point. > What are your advice for the next steps ? Make sure that coreboot and SeaBIOS are built with maximum debug loglevel and connect a second PC to the serial port of your Tyan board. You will get quite verbose output, which you can study to follow what coreboot and SeaBIOS are doing, and you can also send the output to this mailing list to have more eyes try to find if there is a problem somewhere. > Put VGA bios into coreboot.rom, change Ubuntu default start to > non-graphical one ? I think the problems are way before Ubuntu, so the first step should be coreboot+SeaBIOS debug output, but sure, setting also the Ubuntu console to the serial port is a good idea; that way all messages from starting the system can be collected in one place. //Peter

2 1

← Newer
1
...
15
16
17
18
19
20
21
...
33
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 September 2010