coreboot May 2006

coreboot@coreboot.org

50 participants
101 discussions

Re: [LinuxBIOS] s2881 build broken
by Lu, Yinghai 04 May '06

04 May '06

That should be double skip length problem..., remove one +4 in copy_and_run.c could make it work. YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Stefan Reinauer Sent: Wednesday, May 03, 2006 4:12 PM To: Ward Vandewege Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] s2881 build broken * Ward Vandewege <ward(a)gnu.org> [060504 00:39]: > Hi all, > > It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and > 2290 are also bad. 2287 is ok. > > Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS' > line. This is gcc 3.4. > > Suggestions? Yes, I suggest I owe you a beer next time we meet and you try 2291. Yinghai Lu has sent a patch that is more complete but also more intrusive, which will go in later I guess. Until then this should work fine. This one is a good reason for automated testing on hardware.. 8) Stefan -- coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. Tel.: +49 761 7668825 * Fax: +49 761 7664613 Email: info(a)coresystems.de * http://www.coresystems.de/ -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

3 2

Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS description
by Lu, Yinghai 04 May '06

04 May '06

1. So the kernel need to know Hypertransport HT scan. 2. Also we need to move silicon bug fix code to kernel driver..., or cache_as_ram stage code... YH -----Original Message----- From: Ronald G Minnich [mailto:rminnich@lanl.gov] Sent: Wednesday, May 03, 2006 9:14 AM To: Lu, Yinghai Cc: Richard Smith; LinuxBIOS Subject: Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS description Lu, Yinghai wrote: > You don't need linuxbios_ram part to scan pci and allocate resource for > PCI devices? Or let kernel to do these allocation? I want to find out how to let the kernel do it. It's almost capable. This was our goal, 6 years ago; maybe the kernel is ready. ron

3 3

Re: [LinuxBIOS] [FEATURE] payload compression
by Lu, Yinghai 03 May '06

03 May '06

Just want to keep it consistent with util/nrv2b/nrv2b.c YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, May 03, 2006 3:44 PM To: Lu, Yinghai Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] [FEATURE] payload compression * Lu, Yinghai <yinghai.lu(a)amd.com> [060503 20:40]: > Please check the attached zrom fix up. > 1. copy_and_run.c double skip length > 2. merge zrom_stream.c into rom_stream.c > 3. ram position check to skip 0xa0000, and 0xf0000... I suggest you drop the following from the patch: +#if ENDIAN == 0 && BITSIZE == 8 +#define GETBIT(bb, src, ilen) GETBIT_8(bb, src, ilen) +#endif +#if ENDIAN == 0 && BITSIZE == 16 +#define GETBIT(bb, src, ilen) GETBIT_LE16(bb, src, ilen) +#endif +#if ENDIAN == 0 && BITSIZE == 32 +#define GETBIT(bb, src, ilen) GETBIT_LE32(bb, src, ilen) +#endif The algorithm does not work with anything than 32bit and little endian anyways as it is written down. Stefan -- coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. Tel.: +49 761 7668825 * Fax: +49 761 7664613 Email: info(a)coresystems.de * http://www.coresystems.de/

1 0

Re: [LinuxBIOS] [Etherboot-discuss] Re: [FEATURE] payload compression
by Lu, Yinghai 03 May '06

03 May '06

In arch/i386/core/Etherboot.prefix.lds _veratim_end is 16 byte align, So _verbatim_size is 16 byte align. And in arch/i386/prefix/elf/prefix.S, phdr2_p_filesz is set to _verbatim_size... But final tg3.elf size is not 16 byte align... So I have to use "dd s=16 conv=sync " to make the image more big several bytes to 16 byte align... YH

1 0

Re: [LinuxBIOS] [FEATURE] payload compression
by Lu, Yinghai 03 May '06

03 May '06

The Etherboot 5.4 later has different size in elf prefix... to real file size. So we need to align rom_end to 16 bytes or use dd to make payload to 16 bytes align before nrv2b payload.nrv2b... Which one is good? YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, May 03, 2006 2:17 PM To: Lu, Yinghai Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] [FEATURE] payload compression * Lu, Yinghai <yinghai.lu(a)amd.com> [060503 20:40]: > Please check the attached zrom fix up. > 1. copy_and_run.c double skip length > 2. merge zrom_stream.c into rom_stream.c > 3. ram position check to skip 0xa0000, and 0xf0000... Makes perfect sense! -- coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. Tel.: +49 761 7668825 * Fax: +49 761 7664613 Email: info(a)coresystems.de * http://www.coresystems.de/

3 2

Re: [LinuxBIOS] [FEATURE] payload compression
by Lu, Yinghai 03 May '06

03 May '06

Please check the attached zrom fix up. 1. copy_and_run.c double skip length 2. merge zrom_stream.c into rom_stream.c 3. ram position check to skip 0xa0000, and 0xf0000... YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of yhlu Sent: Saturday, April 29, 2006 3:12 PM To: Stefan Reinauer Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] [FEATURE] payload compression Good. lib/unrv2b.c and CAR could include it.... YH On 4/29/06, Stefan Reinauer <stepan(a)coresystems.de> wrote: > * yhlu <yinghailu(a)gmail.com> [060429 23:41]: > > the copy_and_run already have the same function that from nrv2b.c, So > > we share the function... > > Yes. I actually took it from copy_and_run.c. > > Should we put it to lib/unrv2b.c or similar and reference it in both > places? > > I would assume that we have to compile it twice in any case, as the one > time it is running in CAR/romcc context and the other time we're in > "late gcc" context. > > Stefan > > -- > coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 * Fax: +49 761 7664613 > Email: info(a)coresystems.de * http://www.coresystems.de/ > -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

2 2

[LinuxBIOS] Error in FSF high priority list LinuxBIOS description
by Richard Smith 03 May '06

03 May '06

After reading an article describing the High-priority list for the FSF I checked out our listing. And found the following. """ The way to solve the problem is to run a free BIOS. And our community has developed free BIOSes--for instance, LinuxBIOS, which is a modified version of the kernel, Linux. However, """ Seems to me this is not really true. LinuxBIOS is _vastly_ different than the Linux Kernel. We ripped some PCI code, printk code and a few other bits but I can't see us being a "modified version of the kernel..." We can load a kernel and our ultimate goal is to use a kernel as a super-bootloader but not to be a kernel. Anyone else think it needs changing? -- Richard A. Smith

6 11

Re: [LinuxBIOS] Error in FSF high priority listLinuxBIOS description
by Lu, Yinghai 03 May '06

03 May '06

Good to hear that! 32 bit kernel? What is size for kernel and initrd? YH

1 0

Re: [LinuxBIOS] Error in FSF high priority listLinuxBIOS description
by Clay Jones 03 May '06

03 May '06

Or you can go the opposite direction. I have been using an sst49lf016c 2MB flash in a motherboard with an AMD8111 as the southbridge. Then I used the kboot project to build a kernel and initrd that fits and can kexec from ide, usb, or network. Clay Jones senior software engineer | c.jones(a)f5.com | www.f5.com P. 509 343 3500 | F. 509 343 3501 | D. 509 343 3519 F5 Networks | 1322 North Whitman Lane | Liberty Lake, Washington 99019 The Leader in Application Traffic Management Ensuring secure and optimized application delivery for global enterprises -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ronald G Minnich Sent: Wednesday, May 03, 2006 11:41 AM To: Arc Riley Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] Error in FSF high priority listLinuxBIOS description Arc Riley wrote: > On Wed, May 03, 2006 at 09:45:28AM -0600, Ronald G Minnich wrote: > >>sadly, linux got big and flash got small. > > > Linux can still be compiled down to under a meg, especially if many of > the post-boot things are compiled as modules. > yeah, but it needs to be under (512-32)K. Plus, you need to stuff an initrd in there for basic utilities. That's been harder. ron -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS description
by Lu, Yinghai 03 May '06

03 May '06

You don't need linuxbios_ram part to scan pci and allocate resource for PCI devices? Or let kernel to do these allocation? YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ronald G Minnich Sent: Wednesday, May 03, 2006 8:45 AM To: Richard Smith Cc: LinuxBIOS Subject: Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS description Richard Smith wrote: > Anyone else think it needs changing? The original goal of linuxbios was that linux would be the bios. sadly, linux got big and flash got small. That said, on OLPC, we're going to try again. In fact I'm gearing up to try putting some gcc code into linux and loading linux direct from romcc-based code. I think it might work. Who knows what's true :-) ron -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

2 1

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 2006