[U-Boot] Kconfig menu layout
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
- k
On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala galak@kernel.crashing.org wrote:
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation.
- k
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala galak@kernel.crashing.org wrote:
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation.
Assuming boards/ is grouped by vendor today:
$ ls -1 board/ | wc -l 269
still seems like a long list.
- k
On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala galak@kernel.crashing.org wrote:
On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala galak@kernel.crashing.org wrote:
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation.
Assuming boards/ is grouped by vendor today:
$ ls -1 board/ | wc -l 269
still seems like a long list.
Everyone will know the vendor of their board. You could alphabetize and break the list into groups. I think there are some entries in board/ that should be combined and moved into vendor subdirs.
I believe Kconfig is flexible enough you could have two ways of selecting a board. By arch/cpu or by vendor.
- k
On Mon, Apr 20, 2009 at 8:06 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala galak@kernel.crashing.org wrote:
On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala galak@kernel.crashing.org wrote:
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation.
Assuming boards/ is grouped by vendor today:
$ ls -1 board/ | wc -l 269
still seems like a long list.
Everyone will know the vendor of their board. You could alphabetize and break the list into groups. I think there are some entries in board/ that should be combined and moved into vendor subdirs.
There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60.
Don't some of these ads board belong in the freescale dir? jonsmirl@terra:/home/apps/u-boot/board$ ls *ads* -d ads5121 adsvix fads mpc8260ads mpc8266ads mpc8540ads mpc8560ads mx1ads mx31ads
I believe Kconfig is flexible enough you could have two ways of selecting a board. By arch/cpu or by vendor.
- k
-- Jon Smirl jonsmirl@gmail.com
Jon Smirl wrote:
On Mon, Apr 20, 2009 at 8:06 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala galak@kernel.crashing.org wrote:
On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote:
On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala galak@kernel.crashing.org wrote:
In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings.
However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable?
I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation.
Assuming boards/ is grouped by vendor today:
$ ls -1 board/ | wc -l 269
still seems like a long list.
Everyone will know the vendor of their board. You could alphabetize and break the list into groups. I think there are some entries in board/ that should be combined and moved into vendor subdirs.
There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60.
Don't some of these ads board belong in the freescale dir? jonsmirl@terra:/home/apps/u-boot/board$ ls *ads* -d ads5121 adsvix fads mpc8260ads mpc8266ads mpc8540ads mpc8560ads mx1ads mx31ads
I suspect there are also quite a few boards that don't have a vendor attached to them or the vendor only has one or two boards in u-boot. I would create a "vendor" named "other" to lump the miscellaneous boards into.
$ ls -1 board/*/*.mk | wc -l 211
OK, that says that, of the 269 directories, 58 are vendor subdirectories and 211 are boards that should be stuffed into either an existing vendor subdirectory, a new vendor subdirectory, or "other".
(Interesting... vendors appear to have 202 boards, so we have almost as many vendor subdirectory boards as top level boards.) $ ls -1 board/*/*/*.mk | wc -l 202
Best regards, gvb
Dear Jon Smirl,
In message 9e4733910904201712x68658ddfk3c18298deb82bd9f@mail.gmail.com you wrote:
There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60.
There is many vendors which have just a single board; also, there are vendors who prefer to remain anonymous for some reason. Just adding an additional directory level for a single entry does not make much sense to me.
Best regards,
Wolfgang Denk
There is many vendors which have just a single board;
Like the ST nomadik8815 I maintain.
Just adding an additional directory level for a single entry does not make much sense to me.
So should we leave the nomadik as a single-entry vendor board or leave it as is? (more nomadik boards will be added over time, but none of them is in the queue nor will be in the foreseeable months)
/alessandro
So should we leave the nomadik as a single-entry vendor board or leave it as is?
Argh!
I mean: leave it alone in its own vendor-dir or move it up one level? I got the idea vendor dirs were preferred anyway (as suggested by JC), but Wolfgang's last message suggests the opposite.
Sorry for mistyping /alessandro
On Tue, Apr 21, 2009 at 10:27 AM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904201712x68658ddfk3c18298deb82bd9f@mail.gmail.com you wrote:
There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60.
There is many vendors which have just a single board; also, there are vendors who prefer to remain anonymous for some reason. Just adding an additional directory level for a single entry does not make much sense to me.
My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. This would also assign some responsibility to the vendor to maintain the subdirectory for their products.
Another choice is arch/cpu.
You can use the Kconfig search function Ctrl-F to jump right to a board name if you know it.
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@denx.de When the ax entered the forest, the trees said, "The handle is one of us!" -- Turkish proverb
Jon Smirl wrote:
My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is.
Companies and product lines get bought, names change...
IMHO, architecture (selected by kconfig, not ARCH=) and CPU family are a more robust and managable way of sorting the menu -- and would be familiar to those used to configuring Linux. We could still pull in a defconfig from the command line based on a board name alone (in addition to the search functionality you mention).
This would also assign some responsibility to the vendor to maintain the subdirectory for their products.
Assuming the vendor cares. :-)
-Scott
Dear Jon Smirl,
In message 9e4733910904210841n6c7f0db5s57eee23520dc10a@mail.gmail.com you wrote:
My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. This would also assign some responsibility to the vendor to maintain the subdirectory for their products.
No, this is NOT the case. See the examples I quoted, and this is just a few of them.
In my experience, I tend to search for board names first.
Best regards,
Wolfgang Denk
On Apr 21, 2009, at 3:02 PM, Wolfgang Denk wrote:
Dear Jon Smirl,
In message 9e4733910904210841n6c7f0db5s57eee23520dc10a@mail.gmail.com you wrote:
My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. This would also assign some responsibility to the vendor to maintain the subdirectory for their products.
No, this is NOT the case. See the examples I quoted, and this is just a few of them.
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
- k
Dear Kumar Gala,
In message 93A8F58D-8C13-4F72-AFF3-CF4FDF9A3CFA@kernel.crashing.org you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
Best regards,
Wolfgang Denk
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <93A8F58D-8C13-4F72-AFF3- CF4FDF9A3CFA@kernel.crashing.org> you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
I vote for the second one.
Now I'll ask what the location of "defconfig"s should be?
- k
On Tue, Apr 21, 2009 at 5:05 PM, Kumar Gala galak@kernel.crashing.org wrote:
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 93A8F58D-8C13-4F72-AFF3-CF4FDF9A3CFA@kernel.crashing.org you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too.
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
I vote for the second one.
Now I'll ask what the location of "defconfig"s should be?
- k
Dear Jon Smirl,
In message 9e4733910904211533s58df5764na715986b36824891@mail.gmail.com you wrote:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too.
Ctrl-F? In which exact envrionment does this work? With "make config"? "make menuconfig" ?
Best regards,
Wolfgang Denk
On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904211533s58df5764na715986b36824891@mail.gmail.com you wrote:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too.
Ctrl-F? In which exact envrionment does this work? With "make config"? "make menuconfig" ?
I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'
Jon Smirl wrote:
On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904211533s58df5764na715986b36824891@mail.gmail.com you wrote:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too.
Ctrl-F? In which exact envrionment does this work? With "make config"? "make menuconfig" ?
I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'
I don't want to ignite a flame war, but IMHO 'make menuconfig' is the one we should be optimizing towards.
What's the objection again to having the user set ARCH before running this, or at least to using ARCH as the first sort key?
regards, Ben
On Tue, Apr 21, 2009 at 07:22:31PM -0400, Jon Smirl wrote:
On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904211533s58df5764na715986b36824891@mail.gmail.com you wrote:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too.
Ctrl-F? In which exact envrionment does this work? With "make config"? "make menuconfig" ?
I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig'
Searching in 'make menuconfig' works with "/", like with every good unix tool.
rsc
Dear Kumar,
In message AEA791B2-2BC0-49F7-9152-ACF6CA5671DC@kernel.crashing.org you wrote:
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
I vote for the second one.
You misunderstant what I meant. I don't think of havon one or the other of these options, but of offering *both* of them, so the user can chose one of the ways, whatever suits best for his current situation.
Best regards,
Wolfgang Denk
On Apr 21, 2009, at 5:59 PM, Wolfgang Denk wrote:
Dear Kumar,
In message <AEA791B2-2BC0-49F7-9152- ACF6CA5671DC@kernel.crashing.org> you wrote:
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
I vote for the second one.
You misunderstant what I meant. I don't think of havon one or the other of these options, but of offering *both* of them, so the user can chose one of the ways, whatever suits best for his current situation.
Oh, I dont know if we can do that in Kconfig w/o duplicating the option which I think Kconfig would get unhappy about.
- k
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <93A8F58D-8C13-4F72-AFF3- CF4FDF9A3CFA@kernel.crashing.org> you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
Sam,
We are looking at moving u-boot to use Kconfig and was wondering if you could possible tell us if its possible to represent the same Kconfig 'config' options via two different menu schemes. We have a list of boards that will be 'config' options. We'd like to have it in one 'menu' that is just a long list of boards. The other would be a smaller subset that you "filter" based on selecting an Arch & Subarch.
is something like this possible?
- k
On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <93A8F58D-8C13-4F72-AFF3- CF4FDF9A3CFA@kernel.crashing.org> you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
Sam,
We are looking at moving u-boot to use Kconfig and was wondering if you could possible tell us if its possible to represent the same Kconfig 'config' options via two different menu schemes. We have a list of boards that will be 'config' options. We'd like to have it in one 'menu' that is just a long list of boards. The other would be a smaller subset that you "filter" based on selecting an Arch & Subarch.
Kconfig does not allow you to duplicate a config entry in two menus in a way that is usefull here. You want to use the same name, prompt and help text in both menus.
I think the solution is to have a filter part and a "list all boards" part. Then the filter part can be used to make the board list smaller.
Below is a quick mock-up of the idea. I used CPU + INTERFACE - reading the above I should have used Arch + SubArch but you get the idea.
If you decide to do something like this then hide most of this in a separate file and include it.
Sam
choice SHOW_CPU prompt "What CPU?" default SHOW_CPU_ALL
config SHOW_CPU_ALL bool "Show all cpus" select CPU_ARM select CPU_POWERPC select CPU_AVR32
config SHOW_CPU_ARM bool "Show only ARM" select CPU_ARM
config SHOW_CPU_POPWERPC bool "Show only PowerPC" select CPU_POWERPC
config SHOW_CPU_AVR32 bool "Show only AVR32" select CPU_AVR32
endchoice
config CPU_ARM bool config CPU_POWERPC bool config CPU_AVR32 bool
choice SHOW_INTERFACE_ALL tristate "Which interfaces?" default SHOW_INTERFACE_ALL
config SHOW_INTERFACE_ALL bool "All interfaces" select INTERFACE_NONE select INTERFACE_USB select INTERFACE_CAN
config SHOW_INTERFACE_NONE bool "No interfaces!?!?!" select INTERFACE_NONE
config SHOW_INTERFACE_USB bool "USB" select INTERFACE_USB
config SHOW_INTERFACE_CAN bool "CAN" select INTERFACE_CAN endchoice
config INTERFACE_NONE bool config INTERFACE_USB bool config INTERFACE_CAN bool
config ARM_BOARD_A1 bool "A1 - not-fancy ARM based board" depends on CPU_ARM depends on INTERFACE_NONE help This is the super fancy ARM based boards
config ARM_BOARD_A2 bool "A1 - USB ARM based board" depends on CPU_ARM depends on INTERFACE_USB help This is the super fancy ARM based boards
config ARM_BOARD_A3 bool "A1 - CAN+USB ARM based board" depends on CPU_ARM depends on INTERFACE_CAN || INTERFACE_USB help This is the super fancy ARM based boards
config PPC_BOARD_A1 bool "P1 - not-fancy PPC based board" depends on CPU_POWERPC depends on INTERFACE_NONE help This is the fancy PopwerPC based board
config PPC_BOARD_USB10 bool "USB - PopwerPC based USB hub" depends on CPU_POWERPC depends on INTERFACE_USB help The 20 port USB hub with monitoring facilities
config AVR32_CAN bool "CAN Monitor based on AVR32" depends on CPU_AVR32 depends on INTERFACE_CAN help CAN monitor for 10 CAN simultaneously channels
is something like this possible?
- k
On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <93A8F58D-8C13-4F72-AFF3- CF4FDF9A3CFA@kernel.crashing.org> you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
Sam,
We are looking at moving u-boot to use Kconfig and was wondering if you could possible tell us if its possible to represent the same Kconfig 'config' options via two different menu schemes. We have a list of boards that will be 'config' options. We'd like to have it in one 'menu' that is just a long list of boards. The other would be a smaller subset that you "filter" based on selecting an Arch & Subarch.
is something like this possible?
Hi Kumar.
Was my input useable or just pure rubbish?
Sam
On May 1, 2009, at 6:47 AM, Sam Ravnborg wrote:
On Wed, Apr 22, 2009 at 07:44:48AM -0500, Kumar Gala wrote:
On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <93A8F58D-8C13-4F72-AFF3- CF4FDF9A3CFA@kernel.crashing.org> you wrote:
In my experience, I tend to search for board names first.
So back to the root of my question, do we just have one really long list of board names?
I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring.
IMHO there should be several options:
- for those who look for a board name, we should support this,
probably wih an initial selection by the first letter (case insensitive) of the board name.
like this: => board name => M => MPC837XERDB
- alternatively, it should be possible to restrict the choice by
selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names.
like this: => Architecture => PPC => MPC83xx => MPC837XERDB
Sam,
We are looking at moving u-boot to use Kconfig and was wondering if you could possible tell us if its possible to represent the same Kconfig 'config' options via two different menu schemes. We have a list of boards that will be 'config' options. We'd like to have it in one 'menu' that is just a long list of boards. The other would be a smaller subset that you "filter" based on selecting an Arch & Subarch.
is something like this possible?
Hi Kumar.
Was my input useable or just pure rubbish?
Its usable.. one question I had was if you ever gave thought to having a 'config' type that was only for internal dependencies and didn't show up in the resulting .config.
- k
Dear Jon Smirl,
In message 9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com you wrote:
Everyone will know the vendor of their board. You could alphabetize
Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX?
Board names are much better, IMO.
Best regards,
Wolfgang Denk
On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com you wrote:
Everyone will know the vendor of their board. You could alphabetize
Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX?
Read the box when you take the board out.
Dear Jon Smirl,
In message 9e4733910904210833u79f3d4dfv2db744916246222e@mail.gmail.com you wrote:
On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk wd@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910904201706u58387d5fod231dd4b8ac88d74@mail.gmail.com
you wrote:
Everyone will know the vendor of their board. You could alphabetize
Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX?
Read the box when you take the board out.
That doesn't help you. The boards are manufactured by Logic PD resp. STX, but they are the official Freescale eval boards. You can buy them here or there, or through an unrelated distributor - so who is the "vendor"?
Or should the "ebvbeagle" board I buy from EBV go under "env" or under "ti" - or, hey, is "omap3" the vendor?
The "vendor" concept is helpful sometimes, but generally useful here.
Best regards,
Wolfgang Denk
participants (9)
-
Alessandro Rubini -
Ben Warren -
Jerry Van Baren -
Jon Smirl -
Kumar Gala -
Robert Schwebel -
Sam Ravnborg -
Scott Wood -
Wolfgang Denk