From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam Ravnborg Date: Fri, 30 Apr 2004 18:00:19 +0200 Subject: [U-Boot-Users] Configuration System In-Reply-To: <20040430153959.89D70C1356@atlas.denx.de> References: <20040430150734.GB2216@mars.ravnborg.org> <20040430153959.89D70C1356@atlas.denx.de> Message-ID: <20040430160019.GA2417@mars.ravnborg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Apr 30, 2004 at 05:39:54PM +0200, Wolfgang Denk wrote: > In message <20040430150734.GB2216@mars.ravnborg.org> you wrote: > > > > In the Linux kernel today we lack a good way to select individual boards, > > the only mechanishm is the _defconfig hack where a default config > > file is selected, scrapping all options previously used. > > But this is an excellent way to get a known to work standard > coinfiguration for a certain board. If you modify it, you can always > save your customized config file to any place you likeand resume from > there by simply "cp .config ; make oldconfig". > > What exactly is the problem you are complaining about? Just as simple as keeping a few generic options (add -g, debug spinlocks, enable premept) but changing boards from rpxcllf to rpxlite. And at the same time have a good textual description availbale for the board which I am going to select. "This is a variant of the XXX board, with additional 2 Megs of Falsh, and the Ethernet port moved from FCC1 to FCC2." This is becoming off-topic so lets stop that until something is ready for u-boot. Then we can take it in the right context. > For me, the following topics are important: > > * clearness and readability of the resulting code / config files; > this includes having all relevant information for one board > concentrated in very few well known files. I will not say current .config in the kernel are 'readable' as such, it's just a bunch of defines seperated by a few headlines. > * effort needed to add a port to a new architecture, processor, > and/or board > * continued reliable support of all existing boards > * build speed (I have to routinely run MAKEALL for _all_ boards, and > this takes much too much time already) Sam