[U-Boot-Users] [RFC] u-boot migration to kconfig

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

As per Wolfgang & my conversation on IRC this morning; here is the
proposed approach for migrating the mainline u-boot tree to use
kconfig:

First, some background:
By convention, u-boot uses two prefixes for configuration macros.  In
general, CFG_* macros are used to define board properties, and
CONFIG_* macros are for user configurable options.  However, if we
migrate to using Kconfig for managing the config macros, then all the
macros need to be prefixed with CONFIG_ (not CFG_).  As such, there
needs to be a mass rename of the CFG_ prefix to CONFIG_<something>_.

For lack of a better name, Wolfgang and I have settled on replacing
all instances of CFG_* with CONFIG_BSP_*.

So, here's the proposed migration approach...

Commit early in the next merge window (1.3.1?):
1. Perform mass rename of CFG_ macros to CONFIG_BSP_*
2. Perform mass split of COBJS makefile macros to prepare for
conditional compiling.
3. Add cpp/sed postprocessor to generate an autoconf.mk file from the
existing include/configs/*.h files (already posted a patch for this)
and include config files
4. Include autoconf.mk into the Makefiles to support conditional
compiling of .c files.
At this point there should be no difference in the u-boot binaries produced.

Commit in 1.3.2 merge window:
1. Import kconfig source into u-boot tree
2. Create giant Kconfig file containing all possible CONFIG_ macros.
Populate with macro types (bool, string, hex, etc) but don't include
any dependencies between values (yet)
3. Use kconfig to postprocess autoconf.mk for validation and generate autoconf.h
4. Modify mkconfig to allow a board port to specify a *_defconfig file
instead of a header file.  If a defconfig is provided, then
include/config.h will include autoconf.h instead of a config file from
include/configs.
At this point u-boot should still be producing identical binaries.
kconfig is in the u-boot build process, but menuconfig build targets
are not enabled.

In the 1.3.3 merge window:
1. Split/Reorganize the big Kconfig file into smaller logically
organized Kconfig files.  Each board port should define a top level
target and the target will select config options which are required
for the board port (CONFIG_BSP_*).  Organization of this will probably
require some thought.
2. Migrate board ports over to the new approach.
3. Enable menuconfig and oldconfig targets to allow u-boot config to
be manipulated by the user.
This step is probably going to be the riskiest and the most work.  It
will probably take a number of merge windows to get it all right
without causing instability.

Cheers,
g.





-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jon Loeliger]

So, like, the other day "Grant Likely" mumbled:
> As per Wolfgang & my conversation on IRC this morning; here is the
> proposed approach for migrating the mainline u-boot tree to use
> kconfig:

If desired, I will happily stage and moderate patches into
my u-boot-cfg.git tree here on jdl.com until they are ready
to go upstream some.

jdl

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Wolfgang Denk]

Dear Jon,

in message <E1IWEhk-0006l3-M3@jdl.com> you wrote:
> So, like, the other day "Grant Likely" mumbled:
> > As per Wolfgang & my conversation on IRC this morning; here is the
> > proposed approach for migrating the mainline u-boot tree to use
> > kconfig:
> 
> If desired, I will happily stage and moderate patches into
> my u-boot-cfg.git tree here on jdl.com until they are ready
> to go upstream some.

Thanks, but the idea was to use the u-boot-testing repo for this
purpose.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a group of N persons implements a COBOL compiler,  there  will  be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

    I'd like to be involved in the migration to Kconfig.
    How could it be possible?

Best regards

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> Hi,
>
>     I'd like to be involved in the migration to Kconfig.
>     How could it be possible?

We're working on it.  I'll be submitting patches for the -testing tree
this week which move in that direction.

However, it is a big, invasive job so don't expect anything overnight.

Cheers,
g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,
    I'm actually working on the drivers part, to create a new organization
like in the kernel tree
As follow
    drivers/
    drivers/ata 
    drivers/block
    drivers/bios_emulator
    drivers/char
    drivers/eeprom
    drivers/hwmon
    drivers/i2c
    drivers/ide
    drivers/input
    drivers/leds
    drivers/misc
    drivers/mtd
    drivers/mtd/nand
    drivers/mtd/nand_legacy
    drivers/net
    drivers/pci
    drivers/pcmcia
    drivers/serial
    drivers/scsi
    drivers/usb
    drivers/video

That could be interesting to integrate this idea


Le 22/09/07 17:41, ??Grant Likely?? <grant.likely@secretlab.ca> a ?crit?:

> On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>> Hi,
>> 
>>     I'd like to be involved in the migration to Kconfig.
>>     How could it be possible?
> 
> We're working on it.  I'll be submitting patches for the -testing tree
> this week which move in that direction.
> 
> However, it is a big, invasive job so don't expect anything overnight.
> 
> Cheers,
> g.
> 
> 

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Wolfgang Denk]

In message <C31B1B0B.3BBD%plagnioj@jcrosoft.com> you wrote:
>
>     I'm actually working on the drivers part, to create a new organization
> like in the kernel tree
...
> > We're working on it.  I'll be submitting patches for the -testing tree
> > this week which move in that direction.
> 
> > However, it is a big, invasive job so don't expect anything overnight.

I recommend to do one step after the other. Grant's  Kconfig  changes
are already scheduled, so you may want to wait until these are in the
tree.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

    That's why I've propose my help in my first e-mail if it's possible.
    And I agree with you about to do one step after an other.
    Even if I've nearly finished to migrate the drivers to a new
organization, I'm waiting until the Kconfig changes are in the tree.

Best regards.


Le 22/09/07 21:08, ??Wolfgang Denk?? <wd@denx.de> a ?crit?:

> In message <C31B1B0B.3BBD%plagnioj@jcrosoft.com> you wrote:
>> 
>>     I'm actually working on the drivers part, to create a new organization
>> like in the kernel tree
> ...
>>> We're working on it.  I'll be submitting patches for the -testing tree
>>> this week which move in that direction.
>> 
>>> However, it is a big, invasive job so don't expect anything overnight.
> 
> I recommend to do one step after the other. Grant's  Kconfig  changes
> are already scheduled, so you may want to wait until these are in the
> tree.
> 
> Best regards,
> 
> Wolfgang Denk

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> Hi,
>
>     That's why I've propose my help in my first e-mail if it's possible.
>     And I agree with you about to do one step after an other.
>     Even if I've nearly finished to migrate the drivers to a new
> organization, I'm waiting until the Kconfig changes are in the tree.
>
> Best regards.

Sorry, I misread your original question.  Yes, of course you can help
with the migration!  :-)  As I mentioned, I'm doing a first step of
modifying the build system to enable conditional compilation.  I'll
have those patches submitted to the ML in the next few days.

Both the common and drivers directories can be organized.  I recommend
waiting for the build patches to be merged into the -testing tree and
basing your changes on top of that.  Then you can post your changes to
the ML.  Hint: don't try to move all the files in a single patch.
Split the move up into smaller chunks.

Another task that needs to be done is to import the Kconfig source
code into u-boot and build it.  I haven't figured out when I'll be
able to take on that task yet.  This work can be done in parallel with
the build system changes.  It's not until we start actually *using*
kconfig that the changes will require coordination.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

    Two points : 

    1) If you're ok, I can work on kconfig itself.
    2) About the re-organization
       I'd like to create a tree like following
    arch/arm/
    arch/arm/board <- the boards
    arch/arm/boot <- where will be store the u-boot & u-boot.bin
    arch/arm/config <- defconfig
    arch/arm/commom <- arch specific common
    arch/arm/lib <- the lib_arm
    arch/i386/
    arch/i386/board
    arch/i386/boot <- where will be store the u-boot & u-boot.bin
    arch/i386/config <- defconfig
    arch/i386/commom <- arch specific common
    arch/i386/lib <- the lib_i386
    common
    lib <- lib_generic
    drivers
    
Best Regards

Le 23/09/07 0:32, ??Grant Likely?? <grant.likely@secretlab.ca> a ?crit?:

> On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>> Hi,
>> 
>>     That's why I've propose my help in my first e-mail if it's possible.
>>     And I agree with you about to do one step after an other.
>>     Even if I've nearly finished to migrate the drivers to a new
>> organization, I'm waiting until the Kconfig changes are in the tree.
>> 
>> Best regards.
> 
> Sorry, I misread your original question.  Yes, of course you can help
> with the migration!  :-)  As I mentioned, I'm doing a first step of
> modifying the build system to enable conditional compilation.  I'll
> have those patches submitted to the ML in the next few days.
> 
> Both the common and drivers directories can be organized.  I recommend
> waiting for the build patches to be merged into the -testing tree and
> basing your changes on top of that.  Then you can post your changes to
> the ML.  Hint: don't try to move all the files in a single patch.
> Split the move up into smaller chunks.
> 
> Another task that needs to be done is to import the Kconfig source
> code into u-boot and build it.  I haven't figured out when I'll be
> able to take on that task yet.  This work can be done in parallel with
> the build system changes.  It's not until we start actually *using*
> kconfig that the changes will require coordination.
> 
> Cheers,
> g.

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Wolfgang Denk]

In message <C31C78A0.3BD3%plagnioj@jcrosoft.com> you wrote:
> 
>     2) About the re-organization
>        I'd like to create a tree like following
>     arch/arm/
>     arch/arm/board <- the boards

What's wrong with board/ ?

>     arch/arm/boot <- where will be store the u-boot & u-boot.bin

I don't see a use for this. What's wroing with having these  files  in
the top level directory?

>     arch/arm/config <- defconfig

Please don't. Please add the default  config  files  into  the  board
directory. That's IMHO where they logically belong.

> Le 23/09/07 0:32, ??Grant Likely?? <grant.likely@secretlab.ca> a ?crit?:
> 
> > On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrot> e:
...
And please STOP to top post / full quote. Read
http://www.netmeister.org/news/learn2quote.html

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"You shouldn't make my toaster angry." - Household security explained
in "Johnny Quest"

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Le 23/09/07 23:37, ??Wolfgang Denk?? <wd@denx.de> a ?crit?:

> In message <C31C78A0.3BD3%plagnioj@jcrosoft.com> you wrote:
>> 
>>     2) About the re-organization
>>        I'd like to create a tree like following
>>     arch/arm/
>>     arch/arm/board <- the boards
> 
> What's wrong with board/ ?

The idea is to organize the board by cpu's arch like it's done in the kernel
tree.
Actually all boards are stored directly in "board" and the lib-'arch' in the
"srctree", to simplify the splitting in the kconfig menu.
And although regroup the common arch's code.

> 
>>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
> 
> I don't see a use for this. What's wroing with having these  files  in
> the top level directory?

The problem is when you work on multiple architecture & board.
But it's most cosmetic.

> 
>>     arch/arm/config/ <- defconfig
> 
> Please don't. Please add the default  config  files  into  the  board
> directory. That's IMHO where they logically belong.

It's not in the board directory, it's in the arch directory.

As example when you specify your architecture by ARCH=arm
And do a make help only the sh default configuration can be accessible and
show.

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Ulf Samuelsson]

s?n 2007-09-23 klockan 23:37 +0200 skrev Wolfgang Denk:
> In message <C31C78A0.3BD3%plagnioj@jcrosoft.com> you wrote:
> > 
> >     2) About the re-organization
> >        I'd like to create a tree like following
> >     arch/arm/
> >     arch/arm/board <- the boards
> 
> What's wrong with board/ ?
> 

You get a *lot* of boards in board/
Good for computers, not for humans.
Having arch/arm/board would add some minor convenioence,
but not much so.

It would be more useful to collect all boards
using one specific chip in a single directory.
arch/arm/<chip>/board.


> >     arch/arm/boot <- where will be store the u-boot & u-boot.bin
> 
> I don't see a use for this. What's wroing with having these  files  in
> the top level directory?

If you could build several boards in one tree, then
it makes sense to have it in a subdirectory,
but for once I agree with Wolfgang :-)

> 
> >     arch/arm/config <- defconfig
> 
> Please don't. Please add the default  config  files  into  the  board
> directory. That's IMHO where they logically belong.
> 
> > Le 23/09/07 0:32, ? Grant Likely ? <grant.likely@secretlab.ca> a ?crit :
> > 
> > > On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrot> e:
> ...
> And please STOP to top post / full quote. Read
> http://www.netmeister.org/news/learn2quote.html
> 
> Best regards,
> 
> Wolfgang Denk
> 
BR
Ulf Samuelsson

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Shinya Kuribayashi]

Ulf Samuelsson wrote:
> It would be more useful to collect all boards
> using one specific chip in a single directory.
> arch/arm/<chip>/board.

This is too tight, isn't it?
Strictly speaking, boards are not related to chips (at least for me).
So I'll vote +1 for Jean's.

>>>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
>> I don't see a use for this. What's wroing with having these  files  in
>> the top level directory?
> 
> If you could build several boards in one tree, then
> it makes sense to have it in a subdirectory,
> but for once I agree with Wolfgang :-)

I agree with Wolfgang, too.

Thanks,

    Shinya Kuribayashi

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

On 9/23/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>
> Hi,
>
>     Two points :
>
>     1) If you're ok, I can work on kconfig itself.
>     2) About the re-organization
>        I'd like to create a tree like following
>     arch/arm/
>     arch/arm/board <- the boards
>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
>     arch/arm/config <- defconfig
>     arch/arm/commom <- arch specific common
>     arch/arm/lib <- the lib_arm
>     arch/i386/
>     arch/i386/board
>     arch/i386/boot <- where will be store the u-boot & u-boot.bin
>     arch/i386/config <- defconfig
>     arch/i386/commom <- arch specific common
>     arch/i386/lib <- the lib_i386
>     common
>     lib <- lib_generic
>     drivers

If you want to take on reorganization of the source tree, cool.
However, keep the following things in mind:
- Maintaining stability is of utmost concern.  Bite off small chunks
at a time and post patches that do small, well defined things.
- Make sure that patches which move files don't make changes to those
files at the same time; it makes it easier to review the changes.
- Reorganization of the source tree is unrelated to the migration to
Kconfig.  You won't need to worry about the Kconfig layout while
moving files around.
- One word: 'MAKEALL'  :-)

It's probably best to start with the changes to drivers/ that you
mentioned in your earlier email.  It will be the least contentious of
the changes.  Changing the cpu/ and board/ layouts will require
considerably more consensus.

As for Kconfig, I would like to handle the task of generating the
initial set of Kconfig data files (which is a separate task from
importing the Kconfig source files).  I've got a plan in mind for
migrating to Kconfig without breaking existing board ports.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

On 9/23/07, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>
> Le 23/09/07 23:37, ?Wolfgang Denk? <wd@denx.de> a ?crit:
>
> > In message <C31C78A0.3BD3%plagnioj@jcrosoft.com> you wrote:
> >>
> >>     2) About the re-organization
> >>        I'd like to create a tree like following
> >>     arch/arm/
> >>     arch/arm/board <- the boards
> >
> > What's wrong with board/ ?
>
> The idea is to organize the board by cpu's arch like it's done in the kernel
> tree.
> Actually all boards are stored directly in "board" and the lib-'arch' in the
> "srctree", to simplify the splitting in the kconfig menu.
> And although regroup the common arch's code.

I disagree.  Kconfig layout has little effect on the directory
structure at this time.  Kconfig will be make to work with whatever
layout we agree on.  Personally, I also like the existing board/
structure, but I think it would make sense to divide more boards into
a board/<vendor>/<board> structure like the Freescale boards are
(purely for the logistical reason of finding the correct board port
directory)

>
> >
> >>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
> >
> > I don't see a use for this. What's wroing with having these  files  in
> > the top level directory?
>
> The problem is when you work on multiple architecture & board.
> But it's most cosmetic.

That is already solved with the $(obj) macro.  You can build outside
the source tree.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

On 9/23/07, Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> wrote:
> Ulf Samuelsson wrote:
> > It would be more useful to collect all boards
> > using one specific chip in a single directory.
> > arch/arm/<chip>/board.
>
> This is too tight, isn't it?
> Strictly speaking, boards are not related to chips (at least for me).
> So I'll vote +1 for Jean's.

Just to throw a wrench in the works, what about boards like the Xilinx
ML403 which can be *either* PowerPC or MicroBlaze.  :-)

I still think sticking with the existing board/ directory (but perhaps
organizing it better) makes the most sense.  Each board directory can
pull in whatever cpu/soc support it needs.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Shinya Kuribayashi]

Grant Likely wrote:
> On 9/23/07, Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> wrote:
>> Ulf Samuelsson wrote:
>>> It would be more useful to collect all boards
>>> using one specific chip in a single directory.
>>> arch/arm/<chip>/board.
>> This is too tight, isn't it?
>> Strictly speaking, boards are not related to chips (at least for me).
>> So I'll vote +1 for Jean's.
> 
> Just to throw a wrench in the works, what about boards like the Xilinx
> ML403 which can be *either* PowerPC or MicroBlaze.  :-)

I wanted to note doing <chip>/board is not much convinient
from the technical point of view. 

As ML403, NEC also has the platform board on which different
CPUs or different ARCHs are available.

> I still think sticking with the existing board/ directory (but perhaps
> organizing it better) makes the most sense.  Each board directory can
> pull in whatever cpu/soc support it needs.

So fully Agreed. I should have voted +1 for Wolfgang's.
Thanks for your clarification with a concrete example.


Thanks,

    Shinya Kuribayashi

P.S.
IMO even SOCs are not related to CPU ore CPU core.
From SoC point of view, CPU is just a piece of component.
But that's another story ;-)

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Ulf Samuelsson]

m?n 2007-09-24 klockan 12:31 +0900 skrev Shinya Kuribayashi:
> Ulf Samuelsson wrote:
> > It would be more useful to collect all boards
> > using one specific chip in a single directory.
> > arch/arm/<chip>/board.
> 
> This is too tight, isn't it?
> Strictly speaking, boards are not related to chips (at least for me).
> So I'll vote +1 for Jean's.

If you select which chip you are using first, then you
can use that to select which board from a limited amount
instead of having a zillion boards to select from.

This is the way the Linux kernel work.

> >>>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
> >> I don't see a use for this. What's wroing with having these  files  in
> >> the top level directory?
> > 
> > If you could build several boards in one tree, then
> > it makes sense to have it in a subdirectory,
> > but for once I agree with Wolfgang :-)
> 
> I agree with Wolfgang, too.
> 
> Thanks,
> 
>     Shinya Kuribayashi
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Ulf Samuelsson]

s?n 2007-09-23 klockan 23:12 -0600 skrev Grant Likely:
> On 9/23/07, Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> wrote:
> > Ulf Samuelsson wrote:
> > > It would be more useful to collect all boards
> > > using one specific chip in a single directory.
> > > arch/arm/<chip>/board.
> >
> > This is too tight, isn't it?
> > Strictly speaking, boards are not related to chips (at least for me).
> > So I'll vote +1 for Jean's.
> 
> Just to throw a wrench in the works, what about boards like the Xilinx
> ML403 which can be *either* PowerPC or MicroBlaze.  :-)
> 

There won't be many of those boards,and I am sure that
the community will find the right way to handle exceptions.


> I still think sticking with the existing board/ directory (but perhaps
> organizing it better) makes the most sense.  Each board directory can
> pull in whatever cpu/soc support it needs.
> 
> Cheers,
> g.
> 
BR
Ulf Samuelsson

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Ulf Samuelsson]

m?n 2007-09-24 klockan 14:52 +0900 skrev Shinya Kuribayashi:
> Grant Likely wrote:
> > On 9/23/07, Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> wrote:
> >> Ulf Samuelsson wrote:
> >>> It would be more useful to collect all boards
> >>> using one specific chip in a single directory.
> >>> arch/arm/<chip>/board.
> >> This is too tight, isn't it?
> >> Strictly speaking, boards are not related to chips (at least for me).
> >> So I'll vote +1 for Jean's.
> > 
> > Just to throw a wrench in the works, what about boards like the Xilinx
> > ML403 which can be *either* PowerPC or MicroBlaze.  :-)
> 
> I wanted to note doing <chip>/board is not much convinient
> from the technical point of view. 
> 
> As ML403, NEC also has the platform board on which different
> CPUs or different ARCHs are available.
> 
And you today maintain everything supporting this in
a single board directory? (not subdirectories within a directory)

There is nothing to stop you from doing
	arch/ppc/ML403
	arch/microblaze/ML403
	board/vendor/xilinx	- Common files


> > I still think sticking with the existing board/ directory (but perhaps
> > organizing it better) makes the most sense.  Each board directory can
> > pull in whatever cpu/soc support it needs.
> 
> So fully Agreed. I should have voted +1 for Wolfgang's.
> Thanks for your clarification with a concrete example.
> 
BR
Ulf Samuelsson

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Haavard Skinnemoen]

On Sun, 23 Sep 2007 22:58:57 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> - Make sure that patches which move files don't make changes to those
> files at the same time; it makes it easier to review the changes.

And please remember to specify the -M option to git-format-patch. It
will make the patches useless to non-git users, but they will be _so_
much easier to review...

Btw, if you use git-format-patch -M it is probably ok with minor
changes to the file (fixing up includes, comments, etc.) since those
are the only ones that will show up in the diff.

H?vard

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Wolfgang Denk]

In message <C31CAD02.3BD8%plagnioj@jcrosoft.com> you wrote:
> 
> >>     arch/arm/boot <- where will be store the u-boot & u-boot.bin
> > 
> > I don't see a use for this. What's wroing with having these  files  in
> > the top level directory?
> 
> The problem is when you work on multiple architecture & board.
> But it's most cosmetic.

What is your problem with such a setup? You do use "make O=..." then,
don't you?

> >>     arch/arm/config/ <- defconfig
> > 
> > Please don't. Please add the default  config  files  into  the  board
> > directory. That's IMHO where they logically belong.
> 
> It's not in the board directory, it's in the arch directory.
> 
> As example when you specify your architecture by ARCH=arm
> And do a make help only the sh default configuration can be accessible and
> show.

I would like to avoid having board  specific  information  scapttered
over several files *and* directories. So far, we know that everything
(except for a "few" #ifdef's ;-) is concentrated in board/<name>/ and
include/configs/<name>.h

This is a *very* useful setup, me thinks. [Actually  I'  rather  thae
the <name>.h config file in the board driectpory, too, but that would
make the Makefile (as it is currently) too complicated.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The best index to a person's character is a) how  he  treats  people
who can't do him any good and b) how he treats people who can't fight
back."                                            - Abigail Van Buren

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Wolfgang Denk]

In message <1190585597.7015.28.camel@elrond.atmel.sweden> you wrote:
>
> > What's wrong with board/ ?
> 
> You get a *lot* of boards in board/
> Good for computers, not for humans.

Depends on what you are doing. A "grep -r foo board" can be good for
humans, too, as it save me a lot of time and thinking where the hell
all the board files may be scattered around.

> > I don't see a use for this. What's wroing with having these  files  in
> > the top level directory?
> 
> If you could build several boards in one tree, then
> it makes sense to have it in a subdirectory,
> but for once I agree with Wolfgang :-)

You can build several boards in one source tree by simply using the
"make O=..." option.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Ulf Samuelsson]

m?n 2007-09-24 klockan 11:40 +0200 skrev Wolfgang Denk:
> In message <1190585597.7015.28.camel@elrond.atmel.sweden> you wrote:
> >
> > > What's wrong with board/ ?
> > 
> > You get a *lot* of boards in board/
> > Good for computers, not for humans.
> 
> Depends on what you are doing. A "grep -r foo board" can be good for
> humans, too, as it save me a lot of time and thinking where the hell
> all the board files may be scattered around.

grep -r arch/*/board ?

> > > I don't see a use for this. What's wroing with having these  files  in
> > > the top level directory?
> > 
> > If you could build several boards in one tree, then
> > it makes sense to have it in a subdirectory,
> > but for once I agree with Wolfgang :-)
> 
> You can build several boards in one source tree by simply using the
> "make O=..." option.

But you still only put one u-boot.bin in each directory structure.
Lets not argue when we agree!

> Best regards,
> 
> Wolfgang Denk
> 

BR
Ulf Samuelsson

[U-Boot-Users] [RFC] u-boot migration to kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

Le 24/09/07 11:37, ??Wolfgang Denk?? <wd@denx.de> a ?crit?:

> In message <C31CAD02.3BD8%plagnioj@jcrosoft.com> you wrote:

>>>>     arch/arm/config/ <- defconfig
>>> 
>>> Please don't. Please add the default  config  files  into  the  board
>>> directory. That's IMHO where they logically belong.
>> 
>> It's not in the board directory, it's in the arch directory.
>> 
>> As example when you specify your architecture by ARCH=arm
>> And do a make help only the sh default configuration can be accessible and
>> show.
> 
> I would like to avoid having board  specific  information  scapttered
> over several files *and* directories. So far, we know that everything
> (except for a "few" #ifdef's ;-) is concentrated in board/<name>/ and
> include/configs/<name>.h
> 
> This is a *very* useful setup, me thinks. [Actually  I'  rather  thae
> the <name>.h config file in the board driectpory, too, but that would
> make the Makefile (as it is currently) too complicated.
> 
> Best regards,
> 
> Wolfgang Denk

And the idea is not to have "specific information scapttered file *and*
directories" but to organize board by arch and regroup specific information
in a same tree.

I think that a proof of concept may be more representative than speech, I
propose you an example of reorganization that could be with my proposition.
So I put publish git repository where I can show you it even if its not
finished : http://uboot.jcrosoft.org/git

Best Regards.