coreboot November 2004

coreboot@coreboot.org

31 participants
183 discussions

Status Report 2004-11-02
by Stefan Reinauer 02 Nov '04

02 Nov '04

Hi, after some more changes like the removed 64k limit for linuxbios rom images here a new status report about the current image builds. NOTE: Many boards are broken at the moment. If anyone here can supply fixes, please do so. The situation is almost fatal given that the changes to do are mostly time consuming but not really complex. As a generic goal we should work on reducing the impact of such changes by adapting the structure. Example: Having a per board fallback mechanism seems overkill.. The only difference among all boards seem to be the included files from the north bridge and southbridge directories. These could easily be autogenerated from the config tool. The less files one port has, the easier it is to adapt to new changes. Long term this raises code quality and the number of new ports. Stefan

2 1

option tables
by Stefan Reinauer 02 Nov '04

02 Nov '04

Hi, what's the right method of disabling build with an option table? Setting HAVE_OPTION_TABLE to 0 fails in src/include/pc80/mc146818rtc.h It's possible to change both HAVE_OPTIONS_TABLE and USE_OPTION_TABLE, but the logic is a bit weird. Stefan

2 1

RE: Status Report 2004-11-02
by YhLu 02 Nov '04

02 Nov '04

I have fixed my parts. Regards YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Tuesday, November 02, 2004 4:14 AM To: linuxbios(a)clustermatic.org Subject: Status Report 2004-11-02 Hi, after some more changes like the removed 64k limit for linuxbios rom images here a new status report about the current image builds. NOTE: Many boards are broken at the moment. If anyone here can supply fixes, please do so. The situation is almost fatal given that the changes to do are mostly time consuming but not really complex. As a generic goal we should work on reducing the impact of such changes by adapting the structure. Example: Having a per board fallback mechanism seems overkill.. The only difference among all boards seem to be the included files from the north bridge and southbridge directories. These could easily be autogenerated from the config tool. The less files one port has, the easier it is to adapt to new changes. Long term this raises code quality and the number of new ports. Stefan

1 0

testing and researching
by Jakob Praher 02 Nov '04

02 Nov '04

hi all, I'd like to do some embedded systems and cluster research and would like to use linuxbios as the building block. Has anybody tried to use linuxbios as the bios in a vm like bochs or vmware, so that one can "play" with linuxbios in software only? Additionally I'd like to know, whether you prefere the LinuxBiosKernel (I mean that there is no "real" linux kernel in the bios) over the LinuxKernel in Bios approach. If you are using LinuxBiosKernel are you using a standard ATA flash disk, or are there better ways to boot the LinuxKernel..... I'd also apprechiate a good and cheap hardware configuration, that works with linuxbios, especially: * in todays boards: is the flash bios big enough for the LinuxBiosKernel * if not, which flash chips would you prefer? * what board would you choose for clustering testing purposes (it should have state of the art peripheral stuff and modern chipsets, etc). thanks in advance -- Jakob

3 2

Re: Merge/Cleanup status
by ebiederman＠lnxi.com 02 Nov '04

02 Nov '04

"Yinghai Lu" <yhlu(a)tyan.com> writes: > Eric, > > What the reasons that you set MTRRs for one CPU two times.? > amd_setup_mtrrs of amd_mtrr.c call x86_setup_mtrrs... This is just the fixed mtrrs. The code should be refined further, but this code properly sets the RD_MEM and WR_MEM bits in the fixed mtrrs. Given how the code is currently factored this was the easiest way to code it cleanly. I expect to revisit this when looking at overlapping mtrr support. Eric

1 0

Re: Merge/Cleanup status
by ebiederman＠lnxi.com 01 Nov '04

01 Nov '04

"Yinghai Lu" <yhlu(a)tyan.com> writes: > 1. Using ROMCC to do propresser will help the size reduction? Not directly. But it does cleanup the header files and increase the exposure to romcc. There are a small handful of things this make more maintainable. > 2. what is usage for MOVNTI? It is for GDB.... Look at ramtest.c. movnti is a non-teporal move (bypasses the cache). In some cases it can noticeably increase store performance. Last I measured in the cases it mattered it increased store performance by 3X. > 3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram? Correct. Either an exception must be taken or a call to gdb_stub_breakpoint() needs to be made. At that point LinuxBIOS will stop and wait for the debugger. Assuming CONFIG_GDB_STUB is compiled in. For details on the gdb side, read up on the gdb remote serial protocol. I'm not really a fan, I am still more productive with printf debugging. But implement ion exception handling support is a general win. And the support was easy to add. > 4. You will use llshell for crt0.s or auto.c debug? That is the idea. Again I added it because it is available. It would not be hard to call out to it with an appropriate asm directive. If people find llshell useful. > 5. Current romcc only take constant parameters for non inline function? It > that right? There is something weird going on that affects the generated code, so things don't work as smoothly as they should. That said in theory function can be non-inline. > 6. Anyone has tried to compile LinuxBIOS under Suse 9.1? what's the > recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not > compile Etherboot properly. I am always using RH9 to do the work. And just > found I can not compile LB for S2885, (size>65536), but I can do it in Suse > 9.1 pro. The goal is to have LinuxBIOS compiling as many places as possible. As for recommendations we can call out specific revisions of the tool chain that are known good but I won't call out distros. Size wise I know gcc-3.4 is about 2% better than gcc-3.3. Interesting. On the purely size issue you can bump ROM_IMAGE_SIZE a little and see if it the build works. As for etherboot I don't know what your compile failure is. So I don't know how to diagnose that. Eric

2 3

RE: FILO fixups
by YhLu 01 Nov '04

01 Nov '04

I mean cluster nodes. You will go there unplug the CF. (You may need to spend sometime to figure out which one). Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Monday, November 01, 2004 12:39 PM To: YhLu Cc: Ronald G. Minnich; LinuxBIOS Subject: RE: FILO fixups On Mon, 2004-11-01 at 13:30, YhLu wrote: > >From the very beginning, how to initialize the CF flash, do it manually? > > Or if the CF FS crashed, how do you roll it back? > How does the CF in your PDA get inited ? How do you recover your PDA when it crashed? Connect to the internet ? How about your vacuum ? your refigurator, your microwave ? Ollie

3 2

RE: FILO fixups
by YhLu 01 Nov '04

01 Nov '04

I guess FILO will be in Etherboot from 5.2.6. I think we may add several lines in README to make users to enable linuxbios support. It should be 1. Changes in arch/i386/Config. Comment out PCIBOS Enable LinuxBIOS line. Enable X86-64 line 2. make bin/tg3.zelf or make bin/tg3--filo.zelf Regards YH -----Original Message----- From: Dave Aubin [mailto:daubin@actuality-systems.com] Sent: Monday, November 01, 2004 12:53 PM To: Li-Ta Lo Cc: Ronald G. Minnich; YhLu; LinuxBIOS Subject: RE: FILO fixups Filo does need a home and it can run outside of etherboot So I would concede that is ok to have a home for it. Although...sniff I do like it in etherboot;) -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Monday, November 01, 2004 3:46 PM To: Dave Aubin Cc: Ronald G. Minnich; YhLu; LinuxBIOS Subject: RE: FILO fixups On Mon, 2004-11-01 at 13:21, Dave Aubin wrote: > Hi, > > I'll voice my desire to have etherboot with filo. > I love the fact that I can first try to boot remotely And then if not > use filo. For this reason alone I am A fan of the mechanism. Try > remote first then if fail Use local storage. If we can, can we please > put the Etherboot flavor in utils that has both network & filo > support? > First of all, we didn't say we don't want choice. Actually we want more, including the choice of not having some choices. The problems of FILO/Etherboot are: 1. Some people have hard time building Etherboot. 2. Some people don't want the feature provided by Etherboot, they are satisfied by FILO itself. 3. FILO (as FILO itself) does not have an official host. If we want to continue maintain FILO to serve people in 1. and 2., we have to put it somewhere. If you want FILO as FILO+Etherboot, why don't you get it from etherboot project? Ollie

1 0

RE: FILO fixups
by YhLu 01 Nov '04

01 Nov '04

The reason for put filo in etherboot. 1. It can let boot from HD or net according to CMOS setting. 2. Etherboot can produce zelf. We may got more space to put other stuff such as USB support... 3. Etherboot structure and support... I may check if filo.zlef only include FILO ..., even it is not, we still can make it clean. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Monday, November 01, 2004 10:49 AM To: YhLu Cc: Ronald G. Minnich; LinuxBIOS Subject: RE: FILO fixups On Fri, 2004-10-29 at 16:47, YhLu wrote: > You can get filo only under Etherboot. > > make bin/filo.zelf > > or > > make bin/tg3--filo.zelf > > Also I added something into the filo in Etherboot. > Does it contain anything about Etherboot ? I just want FILO !!! Ollie

4 3

RE: FILO fixups
by YhLu 01 Nov '04

01 Nov '04

>From the very beginning, how to initialize the CF flash, do it manually? Or if the CF FS crashed, how do you roll it back? Regards Yinghai Lu -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Monday, November 01, 2004 12:05 PM To: YhLu Cc: Ronald G. Minnich; LinuxBIOS Subject: RE: FILO fixups On Mon, 2004-11-01 at 12:00, YhLu wrote: > The reason for put filo in etherboot. > 1. It can let boot from HD or net according to CMOS setting. > 2. Etherboot can produce zelf. We may got more space to put other stuff such > as USB support... > 3. Etherboot structure and support... > > I may check if filo.zlef only include FILO ..., even it is not, we still can > make it clean. > You have the same blind spot as Eric. For many people, boot over net is irrelevant. Why do they need to live with the overhead of network protocol stack and driver if all they want to to boot form some mass storage device ? Ollie

4 3

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 November 2004