coreboot October 2005

coreboot@coreboot.org

34 participants
58 discussions

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

Great, create LinuxBIOS v3 for CAR only? YH -----Original Message----- From: Ronald G Minnich [mailto:rminnich@lanl.gov] Sent: Thursday, October 27, 2005 2:24 PM To: Lu, Yinghai Cc: Li-Ta Lo; LinuxBIOS Subject: Re: [LinuxBIOS] Config file dependencies Lu, Yinghai wrote: > You want CAR only or make them coexist? my opinion is, that in the long term, we want CAR only. For every target in which CAR can be turned on, it should be turned on and always left on. If you have CAR, you should use it always. ron

2 1

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

Please look at arch/i386/include/arch/io.h Romcc need some built-in function, that can not be use gcc and cache_as_ram. So you can substitute, __ROMCC__ with __PRE_SDRAM__, it is just a symbol.... YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, October 27, 2005 2:38 PM To: Lu, Yinghai Cc: LinuxBIOS Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 14:11 -0700, Lu, Yinghai wrote: > You want CAR only or make them coexist? > Why does #define __PRE_SDRAM__ makes them non-coexist? > YH > > -----Original Message----- > From: Li-Ta Lo [mailto:ollie@lanl.gov] > Sent: Thursday, October 27, 2005 2:01 PM > To: Lu, Yinghai > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Config file dependencies > > On Thu, 2005-10-27 at 13:49 -0700, Lu, Yinghai wrote: > > __ASSEMBLY__ already be used. > > > > __PRE_SDRAM__ maybe good, but if we define USE_DCACHE = 1, > > __ROMCC__is equal to __PRE_SDRAM___ it mean code will be compiled by > gcc > > instead of romcc. > > > > If we #define __PRE_SDRAM__ then we can change > > #if !defined( __ROMCC__ ) && defined( __GNUC__) > #include <device/device.h> > > to > #if !defined(__PRE_SDRAM__) > #include <device/device.h> > > Actually we should move most of the romcc_io.h into pre_dram.h > > > > YH > > > > -----Original Message----- > > From: linuxbios-bounces(a)openbios.org > > [mailto:linuxbios-bounces@openbios.org] On Behalf Of Li-Ta Lo > > Sent: Thursday, October 27, 2005 1:30 PM > > To: Lu, Yinghai > > Cc: LinuxBIOS > > Subject: RE: [LinuxBIOS] Config file dependencies > > > > On Thu, 2005-10-27 at 14:21 -0600, Li-Ta Lo wrote: > > > On Thu, 2005-10-27 at 11:11 -0700, Lu, Yinghai wrote: > > > > If CONFIG_USE_INIT == 0, the cache_as_ram_auto.c will be compiled > to > > > > auto.inc. ---> part of crt0.s---> part of linuxbios_rom > > > > > > > > If CONFIG_USE_INIF == 1, the cache_as_ram_auto.c will be compiled > to > > > > auto.o and be linked with memcpy.o....and auto.o and memcpy.o ---> > > > > init.o > > > > And init.o ---> part of linuxbios_rom... > > > > > > > > > > Is there any reason we need two different ways to do it? If both of > > them > > > are as good, can we drop one and support just the other? > > > > > > BTW, after reading your patch, I found there is very little > difference > > > > > between auto.c and cache_as_ram_auto.c. Most of the differences are > in > > > the included files, can we merge auto.c and cache_as_ram_auto.c? > > > > > > > Talking about merging auto.c and cache_as_ram_auto.c, you are using > > #define __ROMCC__ to choose different definitions of device_t. I don't > > thing it is the right way to do it. Instead, we should use another > > macro for this (__ASSEMBLY__ or __PRE_SDRAM__)? > > > > -- > > Li-Ta Lo <ollie(a)lanl.gov> > > Los Alamos National Lab > > > > -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab

1 0

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

You want CAR only or make them coexist? YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, October 27, 2005 2:01 PM To: Lu, Yinghai Cc: LinuxBIOS Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 13:49 -0700, Lu, Yinghai wrote: > __ASSEMBLY__ already be used. > > __PRE_SDRAM__ maybe good, but if we define USE_DCACHE = 1, > __ROMCC__is equal to __PRE_SDRAM___ it mean code will be compiled by gcc > instead of romcc. > If we #define __PRE_SDRAM__ then we can change #if !defined( __ROMCC__ ) && defined( __GNUC__) #include <device/device.h> to #if !defined(__PRE_SDRAM__) #include <device/device.h> Actually we should move most of the romcc_io.h into pre_dram.h > YH > > -----Original Message----- > From: linuxbios-bounces(a)openbios.org > [mailto:linuxbios-bounces@openbios.org] On Behalf Of Li-Ta Lo > Sent: Thursday, October 27, 2005 1:30 PM > To: Lu, Yinghai > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Config file dependencies > > On Thu, 2005-10-27 at 14:21 -0600, Li-Ta Lo wrote: > > On Thu, 2005-10-27 at 11:11 -0700, Lu, Yinghai wrote: > > > If CONFIG_USE_INIT == 0, the cache_as_ram_auto.c will be compiled to > > > auto.inc. ---> part of crt0.s---> part of linuxbios_rom > > > > > > If CONFIG_USE_INIF == 1, the cache_as_ram_auto.c will be compiled to > > > auto.o and be linked with memcpy.o....and auto.o and memcpy.o ---> > > > init.o > > > And init.o ---> part of linuxbios_rom... > > > > > > > Is there any reason we need two different ways to do it? If both of > them > > are as good, can we drop one and support just the other? > > > > BTW, after reading your patch, I found there is very little difference > > > between auto.c and cache_as_ram_auto.c. Most of the differences are in > > the included files, can we merge auto.c and cache_as_ram_auto.c? > > > > Talking about merging auto.c and cache_as_ram_auto.c, you are using > #define __ROMCC__ to choose different definitions of device_t. I don't > thing it is the right way to do it. Instead, we should use another > macro for this (__ASSEMBLY__ or __PRE_SDRAM__)? > > -- > Li-Ta Lo <ollie(a)lanl.gov> > Los Alamos National Lab > > -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab

3 2

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

CONFIG_USE_INIT 1. car as ram is messed up with inline assembly, So We can check up the auto.inc that gcc produced to verify if the inline assembly is well with other lines from C. 2. ...., the same, except We rename some section name. Why only cache_as_ram_auto.c 1. then will be section name conflicts to create crt0.s (CONFIG_USE_INIT==0) or init.o (CONFIG_USE_INIT==1) 2. with ROMCC, you can not put these info in reg, it may need 4K bytes. Also for support new CPU or sync different CPU freq to common freq, I need to separate HT freq optimization with coherent_ht and ht_chain. So need to store all link info for optimization later....... YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, October 27, 2005 1:56 PM To: Lu, Yinghai Cc: Stefan Reinauer; LinuxBIOS; Greg Watson Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 13:45 -0700, Lu, Yinghai wrote: > No > 1. CONFIG_USE_INIT==0 is very useful for debug. Why?? > 2. CONFIG_USE_INIT==1 is something ppc car using... > AFIAK, the way you are using USE_INIT is totally different from what Greg is doing on PPC. I am not an expert on this issue but I believe the only common thing in these two is the same macro name. Greg, can you have some comment on this? > Auto.c and cache_as_ram_auto.c is very different > 1. cache_as_ram_auto include failover.c Why do you do that? Why don't you have cache_as_ram_failover.c too? > 2. later cache_as_ram_auto will have struct sys_info sysinfox, and it > will include every info include dimm.....and we don't need to keep read > smbus and pci conf space for.... > Any reason it has to be in cache_as_ram_auto only? >

1 0

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

__ASSEMBLY__ already be used. __PRE_SDRAM__ maybe good, but if we define USE_DCACHE = 1, __ROMCC__is equal to __PRE_SDRAM___ it mean code will be compiled by gcc instead of romcc. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Li-Ta Lo Sent: Thursday, October 27, 2005 1:30 PM To: Lu, Yinghai Cc: LinuxBIOS Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 14:21 -0600, Li-Ta Lo wrote: > On Thu, 2005-10-27 at 11:11 -0700, Lu, Yinghai wrote: > > If CONFIG_USE_INIT == 0, the cache_as_ram_auto.c will be compiled to > > auto.inc. ---> part of crt0.s---> part of linuxbios_rom > > > > If CONFIG_USE_INIF == 1, the cache_as_ram_auto.c will be compiled to > > auto.o and be linked with memcpy.o....and auto.o and memcpy.o ---> > > init.o > > And init.o ---> part of linuxbios_rom... > > > > Is there any reason we need two different ways to do it? If both of them > are as good, can we drop one and support just the other? > > BTW, after reading your patch, I found there is very little difference > between auto.c and cache_as_ram_auto.c. Most of the differences are in > the included files, can we merge auto.c and cache_as_ram_auto.c? > Talking about merging auto.c and cache_as_ram_auto.c, you are using #define __ROMCC__ to choose different definitions of device_t. I don't thing it is the right way to do it. Instead, we should use another macro for this (__ASSEMBLY__ or __PRE_SDRAM__)? -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

2 1

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai 27 Oct '05

27 Oct '05

If CONFIG_USE_INIT == 0, the cache_as_ram_auto.c will be compiled to auto.inc. ---> part of crt0.s---> part of linuxbios_rom If CONFIG_USE_INIF == 1, the cache_as_ram_auto.c will be compiled to auto.o and be linked with memcpy.o....and auto.o and memcpy.o ---> init.o And init.o ---> part of linuxbios_rom... YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Li-Ta Lo Sent: Thursday, October 27, 2005 10:31 AM To: Stefan Reinauer Cc: LinuxBIOS Subject: Re: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 09:26 +0200, Stefan Reinauer wrote: > Hi, > > > @@ -130,10 +130,10 @@ > > ## > > ## enable CACHE_AS_RAM specifics > > ## > > -default USE_DCACHE_RAM=1 > > +default USE_DCACHE_RAM=0 > > default DCACHE_RAM_BASE=0xcf000 > > default DCACHE_RAM_SIZE=0x1000 > > -default CONFIG_USE_INIT=1 > > +default CONFIG_USE_INIT=0 > > > The config files have a number of dependencies like the above. > USE_DCACHE_RAM needs CONFIG_USE_INIT otherwise it won't work. > That's something I try to figure out. If DCACHE_RAM needs USE_INIT, why we still have #if CONFIG_USE_INIT == 0 #include "lib/memcpy.c" #endif in the src/mainboard/tyan/s2895/cache_as_ram_auto.c ? > Should we put this dependency in another place? Keeping such > things in mind should be part of the LinuxBIOS configuration, > not the LinuxBIOS (mainboard) developer.. > > Stefan > > -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

2 2

[LinuxBIOS] Config file dependencies
by Stefan Reinauer 27 Oct '05

27 Oct '05

Hi, > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 The config files have a number of dependencies like the above. USE_DCACHE_RAM needs CONFIG_USE_INIT otherwise it won't work. Should we put this dependency in another place? Keeping such things in mind should be part of the LinuxBIOS configuration, not the LinuxBIOS (mainboard) developer.. Stefan

3 2

RE: [LinuxBIOS] lnxi-merge complete
by Lu, Yinghai 26 Oct '05

26 Oct '05

Don't block me, I never broke the code. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Stefan Reinauer Sent: Wednesday, October 26, 2005 8:15 AM To: Jason Schildt Cc: linuxbios(a)openbios.org Subject: Re: [LinuxBIOS] lnxi-merge complete * Jason Schildt <jschildt(a)lnxi.com> [051026 00:14]: > All, > > The LNXI mega patch merge is complete. Note that lnxi-patch-14 and 16 > were not committed. #14 was ommitted because it was no longer relevant > due to the apic_id lifting. #16 was ommitted because it wasn't all that > important and it needs to be regenerated before we commit. I will make > necessary comments on Issue Tracker next. > Thanks for being patient. > Regards, I don't think this can be considered complete. All builds are broken at the moment except the arima hdama. There needs to be more to it than just code reviews. If nothing else helps I will block commits that break any compiling target. Stefan -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

5 7

[LinuxBIOS] lnxi-merge complete
by Jason Schildt 26 Oct '05

26 Oct '05

All, The LNXI mega patch merge is complete. Note that lnxi-patch-14 and 16 were not committed. #14 was ommitted because it was no longer relevant due to the apic_id lifting. #16 was ommitted because it wasn't all that important and it needs to be regenerated before we commit. I will make necessary comments on Issue Tracker next. Thanks for being patient. Regards, --jason-- -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx

7 11

RE: [LinuxBIOS] lnxi-merge complete
by Lu, Yinghai 26 Oct '05

26 Oct '05

I don't think two trees are needed, that will create more work. I mean every committer must not break the current code at least it can compile through before the commit can be made. Just need he to spend 5 more minutes to double check it. YH -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wednesday, October 26, 2005 10:47 AM To: Eric W. Biederman Cc: Lu, Yinghai; Jason Schildt; linuxbios(a)openbios.org Subject: Re: [LinuxBIOS] lnxi-merge complete * Eric W. Biederman <ebiederman(a)lnxi.com> [051026 19:35]: > > Bad idea? > > Nope. I don't think so. Richard's objection that a checkin will take a couple of minutes more is true though. This might become annoying. Sounds like we really might want a development tree and a stable tree and have a 2 step process for merging into stable. But then again I see it coming that noone will really use the stable tree as it is the least common denominator > I think abuild.sh will need some improvements so it can build all of the > boards, and this won't replace code reviews. Or fixing the build process might help. Image sizes are really sensitive and get adjusted from time to time. This looks wrong to me. The image size is something that I might want to decide when everything built correctly and I compose the final image. Then abuild might check and tell "minimum image size: 512k" or whatever but not just fail. As for the code reviews you are completely right. Code quality is nothing that can be ensured by a bunch of automated tools. But it can't be guaranteed by code reviews either, since even by careful looking I can't guess if a certain piece of code will actually compile unless it is reaaally nasty stuff. We all agree that the LNXI merge is a good thing, but it is causing us a little headache now and then. Nothing to worry, nor to argue about - but still something that needs a little fixup. Do you have a time frame for getting things into shape, or shall anyone else try to fix up their own builds? (I'd prefer the first ;)) Stefan

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 October 2005