[U-Boot-Users] [RFC] u-boot migration to kconfig
Hi,
I'd like to be involved in the migration to Kconfig. How could it be possible?
Best regards
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.
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.
In message C31B1B0B.3BBD%plagnioj@jcrosoft.com you wrote:
I'm actually working on the drivers part, to create a new organizationlike 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
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 organizationlike 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
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 neworganization, 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.
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 neworganization, 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.
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
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 boardsWhat'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.binI 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/ <- defconfigPlease 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.
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 boardsWhat'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.binI 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.
In message C31CAD02.3BD8%plagnioj@jcrosoft.com you wrote:
arch/arm/boot <- where will be store the u-boot & u-boot.binI 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/ <- defconfigPlease 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
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/ <- defconfigPlease 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.
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 boardsWhat'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.binI 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 <- defconfigPlease 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
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.binI 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
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 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 ;-)
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
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
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.binI 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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
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.
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
participants (6)
-
Grant Likely -
Haavard Skinnemoen -
Jean-Christophe PLAGNIOL-VILLARD -
Shinya Kuribayashi -
Ulf Samuelsson -
Wolfgang Denk