[U-Boot-Users] Configuration System
Folks,
At the risk of opening a hot topic (again), I would like to bring up the subject of using the Linux Kernel 2.5/2.6 kconfig configuration mechanism.
I know that this topic has been discussed in the past, and that there are some in favor and some opposed to the idea. I also know that it won't be a clean-n-easy transition if motion in that direction is started.
I have implemented build systems based on linux 2.5's kconfig and believe that U-Boot would benefit from using such a system as well. I understand that there are some on the list that "don't want to fix working code" as well. :-)
I am curious to know if others feel that this would be a good direction for U-Boot, or if this is just a Bad Idea that should be dropped immediately.
If there are others (Schurig? Schwebel?) that would like to see this sort of configuration mechanism, and would like to work on the side with me until we have something that is clearly demonstrable to others (Hi Wolfgang! :-)), please let me know. I think it will take a bit of effort to get to a point where a critical mass of infrastructure is in place before the benefits of the mechanism will be seen.
Tread softly, jdl
Dear Jon,
in message 1083273421.24127.170.camel@baz.sps.mot.com you wrote:
At the risk of opening a hot topic (again), I would like to bring up the subject of using the Linux Kernel 2.5/2.6 kconfig configuration mechanism.
What exactly do you want to make configurable? And how? At the moment, configuration is done in a couple of places, like Makefiles, config.mk files included by Makefiles, {architecture,processor,board} dependend header and source files, and linker scripts.
Which of these are you going to address?
If we just take the include/config/<board>.h files, they contain a lot of user configurable stuff (CONFIG_??? options), BSP specific stuff (CFG_??? options), and private definitons added by the specific board maintainer.
Which of these are you going to address?
I know that this topic has been discussed in the past, and that there are some in favor and some opposed to the idea. I also know that it won't be a clean-n-easy transition if motion in that direction is started.
I think I have made myself clear what I think about this: i find the ide very interesting, but I can see no way how to implement it without making the code much harder to understand and to maintain. But I may be wrong. Please go on if you think you can provide patches that show how this can be done for all existing architectures, processors and boards, without negative impact. be
system as well. I understand that there are some on the list that "don't want to fix working code" as well. :-)
This is not the case. If there is an obvious improvement, it will be added. Of course there are different points of view: code maintainer, regular developer and board maintainer, occasional user, etc.
One thing should be clear: there are certain things that require a really intimate knowledge of the innards of the processor, and the code. You must not expect that any configuration tool could enable an uninformed user to - for example - port U-Boot to new hardware. THIS CANNOT BE DONE.
If there are others (Schurig? Schwebel?) that would like to see this sort of configuration mechanism, and would like to work on the side with me until we have something that is clearly demonstrable to others (Hi Wolfgang! :-)), please
I'd rather see that development happen in the public.
let me know. I think it will take a bit of effort to get to a point where a critical mass of infrastructure is in place before the benefits of the mechanism will be seen.
I am really curious to see what you have in mind.
Best regards,
Wolfgang Denk
Hi Jon, Hi Wolfgang,
First of all, I would welcome such a project.
On Fri, Apr 30, 2004 at 12:14:19AM +0200, Wolfgang Denk wrote:
What exactly do you want to make configurable? And how? At the moment, configuration is done in a couple of places, like Makefiles, config.mk files included by Makefiles, {architecture,processor,board} dependend header and source files, and linker scripts.
Well, the idea of CFG vs. CONFIG variables does IMHO point into the right direction. There are several things which could be changed by a user (which needs to be a poweruser anyway, you cannot compare somebody who works on bootloaders with occaional kernel compiling guys):
- baudrate - bootdelay - bootargs - bootcmd - cpu speed - flash layout - etc.
I think I have made myself clear what I think about this: i find the ide very interesting, but I can see no way how to implement it without making the code much harder to understand and to maintain.
Hmm, what about this concept: first we leave everything as it is and add the KConfig infrastructure. It can easily be done, I have done it in the past and we can simply copy the stuff from PTXdist (which also uses KConfig). The only thing that needs to be changed is the variable prefix which is fixed to CONFIG_. Maybe UBOOT_. When this is done we could let it generate another config.h file (invent a name here...) which will be included by the BSPs which use the new mechanism. Everything will stay as it is for the other boards and we can make some proof of concept implementations for further review of the idea.
But I may be wrong. Please go on if you think you can provide patches that show how this can be done for all existing architectures, processors and boards, without negative impact.
... which would not be necessary going that way.
One thing should be clear: there are certain things that require a really intimate knowledge of the innards of the processor, and the code. You must not expect that any configuration tool could enable an uninformed user to - for example - port U-Boot to new hardware. THIS CANNOT BE DONE.
Sure. But on the other hand there are several things which are more "configuration" than "porting". These parts should be clearly separated.
I'd rather see that development happen in the public.
We can make a patch, post it on the list (I can offer my old u-boot-config web page as a temporary home) and review it that way.
Robert
On Fri, Apr 30, 2004 at 07:31:31AM +0200, Robert Schwebel wrote:
Hmm, what about this concept: first we leave everything as it is and add the KConfig infrastructure. It can easily be done, I have done it in the past and we can simply copy the stuff from PTXdist (which also uses KConfig). The only thing that needs to be changed is the variable prefix which is fixed to CONFIG_. Maybe UBOOT_. When this is done we could let it generate another config.h file (invent a name here...) which will be included by the BSPs which use the new mechanism. Everything will stay as it is for the other boards and we can make some proof of concept implementations for further review of the idea.
If you during this process could come up with a generic way to select architecture/board changes to Kconfig could be backported to the kernel.
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. For U-boot I think it would be relevant to start out with a konw good config for one board, shift to another baord, and continue from there. Knowing that this would anyway invalidate 1/3 of the options.
With respect to selecting architecture it must be pretty genial, otherwise the current scheme is preferable.
Sam
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 <some_file> .config ; make oldconfig".
What exactly is the problem you are complaining about?
For U-boot I think it would be relevant to start out with a konw good config for one board, shift to another baord, and continue from there. Knowing that this would anyway invalidate 1/3 of the options.
With respect to selecting architecture it must be pretty genial, otherwise the current scheme is preferable.
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. * 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)
Best regards,
Wolfgang Denk
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 <some_file> .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
In message 20040430160019.GA2417@mars.ravnborg.org you wrote:
- 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.
We are not discussing Linux here. But I agree that the LInux config files is not what I'm dreaming of.
Best regards,
Wolfgang Denk
On Fri, 2004-04-30 at 10:39, Wolfgang Denk wrote:
With respect to selecting architecture it must be pretty genial, otherwise the current scheme is preferable.
I confess, I am not sure what constitutes "genial" here.
From the high-level perspective, my current notion is to
roughly ask three basic questions at the onset:
- What CPU Architecture is being targeted? (ARM, MIPS, PPC, Xscale, etc)
- Given the CPU Architecture is now known, which processor is being selected? This might involve an intermediate step in which a "family" of processors might be selected to help narrow the selection. For example, maybe it is OK to just offer the 7 XSCALE processors directly (ixdp425, xm250, etc), while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc selection for family in order to get to a specific cpu such as the mpc8540.
- What board is being targeted? (ADS, CDS, IceCube, etc) Basically anything in u-boot/boards that is appropriate for the given target CPU Arch or specific CPU.
I think that one of the key factors where a new configuration system could win, in general, is in "enforcing bad combinations". One component that would get encoded into the config files would be, for example, the knowledge of what CPUs are supported on which boards.
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.
Could I ask you to clarify this point a bit, please? I'd like to understand what your concern here is. In particular, I think that there is a bit more of a "cross product of features" available and that some degree of horizontal slicing rather than vertical slicing of the options might be needed. In that way, it is not so much tied to a particular board.
Thinking out loud still.
Thanks, jdl
In message 1083341111.5420.15.camel@gleep.sps.mot.com you wrote:
I confess, I am not sure what constitutes "genial" here. From the high-level perspective, my current notion is to roughly ask three basic questions at the onset:
- What CPU Architecture is being targeted? (ARM, MIPS, PPC, Xscale, etc) - Given the CPU Architecture is now known, which processor is being selected? This might involve an intermediate step in which a "family" of processors might be selected to help narrow the selection. For example, maybe it is OK to just offer the 7 XSCALE processors directly (ixdp425, xm250, etc), while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc selection for family in order to get to a specific cpu such as the mpc8540. - What board is being targeted? (ADS, CDS, IceCube, etc) Basically anything in u-boot/boards that is appropriate for the given target CPU Arch or specific CPU.
Isn't that 300% redundand already?
Why do I need to select an architecture and a processor when I know I have an IceCube board which will never be ARM and never be fit with a MPC860 processor?
At this stage, all you need to select is the board type.
I think that one of the key factors where a new configuration system could win, in general, is in "enforcing bad combinations".
"enforcing bad combinations"??? You must be joking.
One component that would get encoded into the config files would be, for example, the knowledge of what CPUs are supported on which boards.
Which improvement would that give? Right now you select a target config name, like "TQM860L". Nobody needs to know more.
- 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.
Could I ask you to clarify this point a bit, please? I'd like to understand what your concern here is. In particular, I think that there is a bit more of a "cross product of features" available and that some degree of horizontal slicing rather than vertical slicing of the options might be needed. In that way, it is not so much tied to a particular board.
I'm thinking about how I spend my time. For me, working with U-Boot involves several tasks:
(1) porting new architectures/processors/boards; we do this for a living so it must be possible to do this in a very efficient way - at least not more complicated or with more overhead than we have now.
(2) adding customizations, add-on's, new features; again, this must be easily possible with minimal overhead.
(3) adding contributed code for other developers; I do this in my free time, so it must be especially easy do to.
(4) making sure the whole system is as clean and stable as possible; again I do this in my free time, and this is a very limited and precious resource
At the moment, you can add basic support for a new board within half an hour if you know the code as we do and if you manage to find a reasonable similar board as model. OK, to get it ready for release will usually take a few more days, but that's it.
I definitely don't want to have to add 25 new files with meta- or config data just to get my job done.
From your 3-questions approach to system configuration above I got
goose bumps all over my neck - this is something I will not accept.
Best regards,
Wolfgang Denk
On Fri, 2004-04-30 at 11:31, Wolfgang Denk wrote:
- What CPU Architecture is being targeted? - Given the CPU Architecture is now known, which processor is being selected? - What board is being targeted?
Isn't that 300% redundand already?
I don't think so, but I'm willing to be wrong.
Why do I need to select an architecture and a processor when I know I have an IceCube board which will never be ARM and never be fit with a MPC860 processor?
So, we could ask arguably ask the questions in a slightly better order, and derive valid CPU choices given a board. It's the fact that there can be more than one CPU choice that motivates me here.
At this stage, all you need to select is the board type.
But that is not good enough to be uniquely identifying yet. And I think this is an existing issue with some of the configurations in the current scheme where you have to provide CPU information as well as the board. In particular, I'm thinking of the examples as described in the top-level README:
For the Cogent platform, you need to specify the cpu type as well; e.g. "make cogent_mpc8xx_config". And also configure the cogent directory according to the instructions in cogent/README.
I had a perfect example of such a situation today. I have 4 CPUs in the PPC family that I am working with currently. I also have two different boards. Until today, there was a known supported mapping that looked like this:
BOARD CPU | B1 B2 -----+--------- C1 | x C2 | x C3 | x C4 | x
If you were using Board B1, then you could have been using a CPU C1 or a C2. If you were using a CPU C4, you must have been on a B2 board.
This morning, I was asked to make new U-Boot release for a C4 on an B1 board. I knew that the code in cpu/cpu.c would handle this properly as it was properly configured to handle the different CPU CONFIG_'s already. All I needed to was to pick Board B2 and CPU C4.
I think that one of the key factors where a new configuration system could win, in general, is in "enforcing bad combinations".
"enforcing bad combinations"??? You must be joking.
I think I misspoke myself here. My real point was that it can be used to disallow bad combinations by explicitly capturing supported configurations. Maybe I am being naive here, but I've implemented such knowledge for other systems that were as complex as U-Boot seems to be (to me).
Which improvement would that give? Right now you select a target config name, like "TQM860L". Nobody needs to know more.
I'm merely trying to establish a few comfiguration options along the way, and prevent huge choice lists. The person doing the configuring doesn't want a flat list of 172 boards from which to make a selection. In general, there are established config symbols such as CONFIG_ARCH_ARM, or CONFIG_MPC85xx that give an indication of specific families or architectures that are used throughout the code base already. A hierarchical method of selecting provides both a scalable selection method and a means to introduce those symbols along the way. It gives structure and guidance for future additions as well.
I'm thinking about how I spend my time. For me, working with U-Boot involves several tasks:
(1) porting new architectures/processors/boards; we do this for a living so it must be possible to do this in a very efficient way - at least not more complicated or with more overhead than we have now.
Agreed. I fully understand the difference between porting and just config'ing up a new image to be built. The same set of "well defined default configration parameters" can be had for each and every one of the existing board/CPU combinations that someone (we all) want to support.
(2) adding customizations, add-on's, new features; again, this must be easily possible with minimal overhead.
Again, agreed. I think that there is great value in having a way to leverage features and knowledge from _other_ ports as well. Off the top of my head, configuring a PCI sub-system might be a good example here. Suppose that most platforms have one PCI bus. And my platform has a second PCI bus. I can make the notion of a second PCI bus dependent on my particular board symbol in the configuration files. Later, a new system that also supports two PCI buses becomes available. All they have to do to "add support for the second PCI bus" is to make the config parts enabled based on "my original board or their new board". They leverage the existing config immediately. Maybe, they can even use the common code in the PCI subsystem; but that would depend on deeper board issues.
(3) adding contributed code for other developers; I do this in my free time, so it must be especially easy do to.
(4) making sure the whole system is as clean and stable as possible; again I do this in my free time, and this is a very limited and precious resource
Understood.
I definitely don't want to have to add 25 new files with meta- or config data just to get my job done.
I don't think it will take that at all. Maybe a couple 2 or 3?
From your 3-questions approach to system configuration above I got
goose bumps all over my neck - this is something I will not accept.
I appreciate your feedback.
Thanks, jdl
In message 1083363889.5691.363.camel@gleep.sps.mot.com you wrote:
So, we could ask arguably ask the questions in a slightly better order, and derive valid CPU choices given a board. It's the fact that there can be more than one CPU choice that motivates me here.
No. Once you selected a _board_configuration_, ALL these parameters are fix. If some boards come with several types of precessor, there will be several board configurations. For example, check the list of existent TQM8xxL or TQM82xx board configurations.
At this stage, all you need to select is the board type.
But that is not good enough to be uniquely identifying yet.
Yes, it is. A board configuration defines the whole configuration of a board. Everything. No other parameters are needed.
And I think this is an existing issue with some of the configurations in the current scheme where you have to provide CPU information as well as the board. In particular, I'm thinking of the examples as described in the top-level README:
For the Cogent platform, you need to specify the cpu type as well; e.g. "make cogent_mpc8xx_config". And also configure the cogent directory according to the instructions in cogent/README.
Here the board configuration name is "cogent_mpc8xx" - and it selects ALL required parameters. No other questions are necessary.
I had a perfect example of such a situation today. I have 4 CPUs in the PPC family that I am working with currently. I also have two different boards. Until today, there was a known supported mapping that looked like this:
BOARD CPU | B1 B2 -----+--------- C1 | x C2 | x C3 | x C4 | xIf you were using Board B1, then you could have been using a CPU C1 or a C2. If you were using a CPU C4, you must have been on a B2 board.
This morning, I was asked to make new U-Boot release for a C4 on an B1 board. I knew that the code in cpu/cpu.c would handle this properly as it was properly configured to handle the different CPU CONFIG_'s already. All I needed to was to pick Board B2 and CPU C4.
So you created a new board configuration. That's all.
And not to forget: your situation is one case in maybe a hundred or so. It is not any significant percentage of situations you will encounter when porting U-Boot.
"enforcing bad combinations"??? You must be joking.
I think I misspoke myself here. My real point was that it
A Freudian slip?
can be used to disallow bad combinations by explicitly capturing supported configurations. Maybe I am being naive
Ummm... With the current system, no "bad combinations" are possible right from the beginning. So where is the improvement?
Which improvement would that give? Right now you select a target config name, like "TQM860L". Nobody needs to know more.
I'm merely trying to establish a few comfiguration options along the way, and prevent huge choice lists. The person doing the configuring doesn't want a flat list of 172 boards from which to make a selection. In general, there are established
This is your opinion. Our customers _do_ want it this way. They say: all I want to know is the name of the configuration to chose. If I have a TQM823L module I care a shit which processor this is, I just want a running system.
config symbols such as CONFIG_ARCH_ARM, or CONFIG_MPC85xx that give an indication of specific families or architectures that are used throughout the code base already. A hierarchical method of selecting provides both a scalable selection method and a means to introduce those symbols along the way. It gives structure and guidance for future additions as well.
I wish it were that way. I think it ain't so.
Agreed. I fully understand the difference between porting and just config'ing up a new image to be built. The same set of "well defined default configration parameters" can be had for each and every one of the existing board/CPU combinations that someone (we all) want to support.
But there is no such set of default configuration parameters which applies to more than one board. Just look at the selection of supported commands - search how many board configurations use the same set of commands.
a good example here. Suppose that most platforms have one PCI bus.
Wrong. Most platforms have no PCI at all. And no USB, nor PCMCIA, nor CompactFlash, nor NAND flash. Butt some do ;-)
And my platform has a second PCI bus. I can make the notion of a second PCI bus dependent on my particular board symbol in the configuration files. Later, a new system that also supports two PCI buses becomes available. All they have to do to "add support for the second PCI bus" is to make the config parts enabled based
Thsi is a dream. First, they have to study the hardware. Than they have to understand the implications on the software. Then they have to analyze the existing code. And in 99% of all cases they will find that their board with 2 PCI busses is sufficiently different from yours that they cannot reuse the code without changing it.
on "my original board or their new board". They leverage the existing config immediately. Maybe, they can even use the common code in the PCI subsystem; but that would depend on deeper board issues.
Your system is standing on the head. First you got to get the code right. wIthout doing this all attempts to configure something will fail.
I definitely don't want to have to add 25 new files with meta- or config data just to get my job done.
I don't think it will take that at all. Maybe a couple 2 or 3?
Ummm... is you add only 3 files, you will have at least one monster of a config file which nobody will be able to understand nor maintain.
Best regards,
Wolfgang Denk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 30 April 2004 07:19 pm, Wolfgang Denk wrote:
I definitely don't want to have to add 25 new files with meta- or config data just to get my job done.
I don't think it will take that at all. Maybe a couple 2 or 3?
Ummm... is you add only 3 files, you will have at least one monster of a config file which nobody will be able to understand nor maintain.
First, let me say I don't find the configurator that we are talking about all the helpful to my work, but I think I might have a solution that will reduce the maintainability. So what I was thinking about was using the maintainers file along with a configurator script in the tools directory. The configurator would be all the smarts. It would read the MAINTAINERS file, which has the bits in a well-defined structure, and generate the views with some type of filtering. So you could say "Show me all boards supporting CPU xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of the configurator is "make <configuration>"
Here are the pros and cons I see to this:
PROS: * The only new files are specificaly for the configurator and only need be modified to fix the configurator. * Only the people interested in the system need to know about it. * Automatically updated with each supported board. * Minimal added work for Wolfgang. * It can be extracted from the tree and maintained on the side until Wolfgang has the time to review and appove it. * No one other then the interested parties has to do anything other than add their board to the MAINTAINERS list to work in u-boot. * It does not preclude the make <configuration> well known system. * Many others I am sure :)
CONS: * More files in the u-boot tree. * The configurator itself becomes somewhat complex. * Many others I am sure :)
Jon, Wolfgang what are your thoughts on a system like this?
Thanks Brian
Dear Brian,
in message 200405030705.57724.waite@skycomputers.com you wrote:
First, let me say I don't find the configurator that we are talking about all the helpful to my work, but I think I might have a solution that will reduce the maintainability. So what I was thinking about was using the maintainers
Ummm... Do you really mean what I'm reading here?
If it's not helpful, and reduces maintainability, then what is it good for at all?
file along with a configurator script in the tools directory. The configurator would be all the smarts. It would read the MAINTAINERS file, which has the bits in a well-defined structure, and generate the views with some type of filtering. So you could say "Show me all boards supporting CPU xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of the configurator is "make <configuration>"
What should this be good for?
Normally, the user has a board on his desk, which is labeled as "foo", and all he needs to know is that the board name "foo" will be supported by either "make foo_config; make all" or simply by "MAKEALL foo".
If you are looking for similar boards while porting to some custom hardware, just scanning the CPU types does not help at all. You will need a lot of other parameters like memory map, RAM and flash chip types, bus width, flash sector layout, where to put the environment, which commands shall be supported, etc. etc.
PROS:
- The only new files are specificaly for the configurator and only need be
modified to fix the configurator.
- Only the people interested in the system need to know about it.
- Automatically updated with each supported board.
Assuming somebody adds the relevant entries to the MAINTAINERS file. This is nothing you can rely on.
- Minimal added work for Wolfgang.
- It can be extracted from the tree and maintained on the side until Wolfgang
has the time to review and appove it.
- No one other then the interested parties has to do anything other than add
their board to the MAINTAINERS list to work in u-boot.
- It does not preclude the make <configuration> well known system.
- Many others I am sure :)
CONS:
- More files in the u-boot tree.
Not a real problem.
- The configurator itself becomes somewhat complex.
- Many others I am sure :)
One other: I see zero advantage.
Jon, Wolfgang what are your thoughts on a system like this?
Either I don't understand at all what you have in mind, or we have very, very different goals -- "reducing maintainability" is most definitely not on my wish list ;-)
Best regards,
Wolfgang Denk
On Fri, Apr 30, 2004 at 11:05:11AM -0500, Jon Loeliger wrote:
On Fri, 2004-04-30 at 10:39, Wolfgang Denk wrote:
With respect to selecting architecture it must be pretty genial, otherwise the current scheme is preferable.
I confess, I am not sure what constitutes "genial" here.
From the high-level perspective, my current notion is to
roughly ask three basic questions at the onset:
- What CPU Architecture is being targeted? (ARM, MIPS, PPC, Xscale, etc) - Given the CPU Architecture is now known, which processor is being selected? This might involve an intermediate step in which a "family" of processors might be selected to help narrow the selection. For example, maybe it is OK to just offer the 7 XSCALE processors directly (ixdp425, xm250, etc), while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc selection for family in order to get to a specific cpu such as the mpc8540. - What board is being targeted? (ADS, CDS, IceCube, etc) Basically anything in u-boot/boards that is appropriate for the given target CPU Arch or specific CPU.
It is better not asking less obvious questions. So when I know I have board XXX why should I then select CPU and CPU family. On the other hand knowing that I want an ARM, then I expect to see a list of available boards. Did I only select ARM9, again a even smaller set of boards.
Maybe this was what you had in mind already - my point is that it should be intuitive and simple. Simple from both a usage and implementation point of view.
But I see all this as something that can come later, the better approach is to start out small and incremental add more.
Sam
Hello!
I'd really like an overview what I would need to port U-Boot to the Motorola MVME5500.
I'd greatly appreciate any kind of help for a newbie anyone on this list could muster.
This is a student's project - I must tell upfront, that I cannot "hire a guru" as stated in the README, and I'm still hard-pressed for time.
The interesting features for the boot-loader port are the Motorla 7455 CPU and the Marvell GT64260B system controller.
I've seen in the source, that there's support for an evaluation board featuring this controller - EVB64260. The CPU seems to be supported as well by the 74xx_7xx, as far as I can see.
So there's some kind of support for the CPU, the controller, the integrated serial lines (controller) and ethernet (controller). Basically all in this revolves around the system controller from Marvell.
I need a decent boot-loader that can boot Linux from flash (a capability that seems to be lacking from MotLoad, AFAIK), and I'm willing to port it, if I can reasonably do so, and I'm willing to give back all changes.
But I do need some starting points of how to know which code to adapt, how to rewire the existing code, which data to supply to make it correspond to my setup.
Thanks in advance, Oliver Korpilla
In message Pine.LNX.4.58.0405031301060.654@corpster2 you wrote:
I'd really like an overview what I would need to port U-Boot to the Motorola MVME5500.
See section "U-Boot Porting Guide" in the README.
I've seen in the source, that there's support for an evaluation board featuring this controller - EVB64260. The CPU seems to be supported as well by the 74xx_7xx, as far as I can see.
Correct.
But I do need some starting points of how to know which code to adapt, how to rewire the existing code, which data to supply to make it correspond to my setup.
Well, even if you cannot implement the function no_more_time() the rest of the "U-Boot Porting Guide" still applies. Follow it step by step.
BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)
Maybe we should start a "black list" of companies who don't give their patches back to the public source tree.
Best regards,
Wolfgang Denk
At 12:45 PM 5/2/2004 +0200, Wolfgang Denk wrote:
In message Pine.LNX.4.58.0405031301060.654@corpster2 you wrote:
I'd really like an overview what I would need to port U-Boot to the Motorola MVME5500.
See section "U-Boot Porting Guide" in the README.
I've seen in the source, that there's support for an evaluation board featuring this controller - EVB64260. The CPU seems to be supported as well by the 74xx_7xx, as far as I can see.
Correct.
But I do need some starting points of how to know which code to adapt, how to rewire the existing code, which data to supply to make it correspond to my setup.
Well, even if you cannot implement the function no_more_time() the rest of the "U-Boot Porting Guide" still applies. Follow it step by step.
BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)
Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as we used the onboard MOTload software instead. Since MOTLoad worked just fine for us (once we figured it out) we didn't do the U-Boot port.
Sorry.
Maybe we should start a "black list" of companies who don't give their patches back to the public source tree.
Well, everything that we list on our Web site is freely available. You just have to do the same amount of hunting (and integration!) that MCC did.
I'm not fond of black-listing myself. Isn't that what big companies do??
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Remember that Beethoven wrote his first symphony in C ...
********************************************************** Mike McCullough MCC Systems, Inc. President and CEO 9 Cheshire Court Londonderry, NH 03053
mike@mccengineering.com Tel: 603-537-9593 Fax: 831-309-3472
********************************************************** Embedded Training Development Tools Embedded Consulting Custom Support Programs **********************************************************
Mike McCullough wrote:
BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)
Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as we used the onboard MOTload software instead. Since MOTLoad worked just fine for us (once we figured it out) we didn't do the U-Boot port.
MotLoad actually netboots fine, but AFAIK it doesn't boot from flash (a capability I already have gladly exploited with the MVME2100 and the PPCbug). While it seems that a lot of setups often seem to be perfectly ok with a netboot (which seems to be very popular with VxWorks as well), for my setup a flash boot setup would really be the better choice - especially since on the MVME5500 flash is an abundant resource: 32-40MB are more than enough for a really nice root filesystem, don't you think? (I've not even ran out of the 4MB on the MVME2100 by now - thanks, uClibc and BusyBox!!!)
Maybe we should start a "black list" of companies who don't give their patches back to the public source tree.
Well, everything that we list on our Web site is freely available. You just have to do the same amount of hunting (and integration!) that MCC did.
I'm not fond of black-listing myself. Isn't that what big companies do??
Well, as long as the Linux vendors either hide their Linux kernels, or release only trimmed down versions of them (and no patchset), I guess the bootloader is not the worst problem - ok, ok, of course to people on this list this is actually an issue at heart!! But with all the closed mailing lists, and proprietary patchsets for customers only, open-source projects seem to be pretty much to be on the exploited side of the deal to me. :(
This is of course a general comment, and not about your special SDK vendor, which I have no experience with yet!
Thanks, and with kind regards, Oliver Korpilla
In message 5.1.0.14.2.20040502213935.0129c038@pop3.ttlc.net you wrote:
Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as we used the onboard MOTload software instead. Since MOTLoad worked just fine for us (once we figured it out) we didn't do the U-Boot port.
You're right. I didn't read the page carefully enough. Sorry for the confusion.
Best regards,
Wolfgang Denk
participants (8)
-
Brian Waite -
Jon Loeliger -
Mike McCullough -
Oliver Korpilla -
Oliver Korpilla -
Robert Schwebel -
Sam Ravnborg -
Wolfgang Denk