[U-Boot-Users] Preparing a KEV7a400 patch
I've successfully ported u-boot to the Sharp KEV7A400 board. It can program flash, boot from the network, and it runs from flash.
Before I submit a patch, I believe there are a couple of outstanding issues that you, Wolfgang, want resolved.
1) Dependency on Perl
Are you OK with an initial patch that checks for the presence of a Perl interpreter? Since this is the only board using the mkocnfigx script, such a method will be backward compatible. I agree that a shell script of the Perl script must be written.
2) #undef arm
It looks like the arm macro may be defined by the compiler. The GCC info pages suggest that this macro may be defined unless -ansi is passed to the compiler.
There are a few of ways to resolve this problem. I could change the structure that is broken by the #define. I could leave the #undef intact. I could find a way to remove the #define by passing an switch to the compiler. My preference, of course, is to leave the #undef intact.
3) Trailing whitespace
You found some lines in a previous patch to have trailing whitespace. What do you use to detect this?
Dear Marc,
in message 20030806191635.GA2601@buici.com you wrote:
I've successfully ported u-boot to the Sharp KEV7A400 board. It can program flash, boot from the network, and it runs from flash.
Before I submit a patch, I believe there are a couple of outstanding issues that you, Wolfgang, want resolved.
Dependency on Perl
Are you OK with an initial patch that checks for the presence of a Perl interpreter? Since this is the only board using the mkocnfigx script, such a method will be backward compatible. I agree that a shell script of the Perl script must be written.
Can you please split your patch in two separate parts: one with the support for the new Sharp KEV7A400 board, and another one to use your Perl script?
Did you address the issues I raised with this script last time you showed it to me?
#undef arm
It looks like the arm macro may be defined by the compiler. The GCC info pages suggest that this macro may be defined unless -ansi is passed to the compiler.
There are a few of ways to resolve this problem. I could change the structure that is broken by the #define. I could leave the #undef intact. I could find a way to remove the #define by passing an switch to the compiler. My preference, of course, is to leave the #undef intact.
I will (again) reject a patch which includes such a #undef; please fix the reason for the problem, not the symptoms.
Trailing whitespace
You found some lines in a previous patch to have trailing whitespace. What do you use to detect this?
For example vi -- :g/[\t ][\t ]*$/p
Best regards,
Wolfgang Denk
On Thu, Aug 07, 2003 at 12:22:19AM +0200, Wolfgang Denk wrote:
Dear Marc,
in message 20030806191635.GA2601@buici.com you wrote:
I've successfully ported u-boot to the Sharp KEV7A400 board. It can program flash, boot from the network, and it runs from flash.
Before I submit a patch, I believe there are a couple of outstanding issues that you, Wolfgang, want resolved.
Dependency on Perl
Are you OK with an initial patch that checks for the presence of a Perl interpreter? Since this is the only board using the mkocnfigx script, such a method will be backward compatible. I agree that a shell script of the Perl script must be written.
Can you please split your patch in two separate parts: one with the support for the new Sharp KEV7A400 board, and another one to use your Perl script?
That's an interesting request. There isn't really a way to separate them this way since the configuration control script is used to divide the LHA7A400 implementation of the ARM920 from the Samsung implementation.
Did you address the issues I raised with this script last time you showed it to me?
I've rewritten the generation script using text tools. It is attached. It uses the preprocessor to generate the list of #defines, so I think that it better matches your expectations.
Cheers.
In message 20030806223427.GA7826@buici.com you wrote:
Can you please split your patch in two separate parts: one with the support for the new Sharp KEV7A400 board, and another one to use your Perl script?
That's an interesting request. There isn't really a way to separate them this way since the configuration control script is used to divide the LHA7A400 implementation of the ARM920 from the Samsung implementation.
Please try it.
I definitely want to keep these two issues separated.
Most probably I will merge the KEV7A400 board support quickly, but spend some time playing with the configuration control script before I add it.
Did you address the issues I raised with this script last time you showed it to me?
I've rewritten the generation script using text tools. It is attached. It uses the preprocessor to generate the list of #defines, so I think that it better matches your expectations.
Ummm... and what do you need perl for?
# Copyright (c) 2003 # Marc Singer elf@buici.com
Please include a GPL header.
# The macro CPP may refer to 'gcc -E'. This definition is not # compatible with this use of the preprocessor because the input file # is a header and not a source file. Should there be a dependency on # a target-specific macro, another method must be found.
Please explain this comment, I don't understand it.
CPP=cpp [ -z "$GREP" ] && GREP=grep [ -z "$SED" ] && SED=sed [ -z "$SORT" ] && SORT=sort
Any specific reason for not using something like this:
: ${GREP:=grep} ${SED:=sed} ${SORT:=sort}
?
$CPP -Iinclude -dM include/config.h\ | $GREP -E "define[ \t]+CONFIG_[^ \t]*[ \t]+1$"\ | $SED -e "s/.*(CONFIG_[^ \t]*).*/\1=y/"\ | $SORT\
$CONFIG
I don't think this command does what you think it does.
You are running the _native_ CPP, which on a x86 host will set things like __i386__ and i386, which may enable or disable ramdom stuff in the U-Boot config files.
A patch based on this code as is will be rejected.
Best regards,
Wolfgang Denk
On Thu, Aug 07, 2003 at 01:30:44AM +0200, Wolfgang Denk wrote:
In message 20030806223427.GA7826@buici.com you wrote:
Can you please split your patch in two separate parts: one with the support for the new Sharp KEV7A400 board, and another one to use your Perl script?
That's an interesting request. There isn't really a way to separate them this way since the configuration control script is used to divide the LHA7A400 implementation of the ARM920 from the Samsung implementation.
Please try it.
My target won't compile without it. I can separate it, but MAKEALL will fail.
Most probably I will merge the KEV7A400 board support quickly, but spend some time playing with the configuration control script before I add it.
How about the other way around. I'll send you the configuration script portion. It's very small.
Ummm... and what do you need perl for?
Don't any more.
# Copyright (c) 2003 # Marc Singer elf@buici.com
Please include a GPL header.
Sure.
Note that mkconfig doesn't.
# The macro CPP may refer to 'gcc -E'. This definition is not # compatible with this use of the preprocessor because the input file # is a header and not a source file. Should there be a dependency on # a target-specific macro, another method must be found.
Please explain this comment, I don't understand it.
Found another way. It's removed.
CPP=cpp [ -z "$GREP" ] && GREP=grep [ -z "$SED" ] && SED=sed [ -z "$SORT" ] && SORT=sort
Any specific reason for not using something like this:
: ${GREP:=grep} ${SED:=sed} ${SORT:=sort}
Hand't thought of it. Changed.
I'm attaching a patch with just the configuration patches. I found another method of invoking cpp that ought to meet your expectations.
Cheers.
In message 20030807004716.GA20846@buici.com you wrote:
--pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Thu, Aug 07, 2003 at 01:30:44AM +0200, Wolfgang Denk wrote:
In message 20030806223427.GA7826@buici.com you wrote:
Can you please split your patch in two separate parts: one with the support for the new Sharp KEV7A400 board, and another one to use your Perl script?
That's an interesting request. There isn't really a way to separate them this way since the configuration control script is used to divide the LHA7A400 implementation of the ARM920 from the Samsung implementation.
Please try it.
My target won't compile without it. I can separate it, but MAKEALL will fail.
That's what I meant when I wrote to separate things: make your code work without this extension like all the other boards.
How about the other way around. I'll send you the configuration script portion. It's very small.
I don't see what good it does. For all boards I tried it just generates an empty "configx.mk" file (well,tnot exactly empty, but two blank lines and a comment).
I'm attaching a patch with just the configuration patches. I found
Please submit the next patches against more recent sources.
another method of invoking cpp that ought to meet your expectations.
This will - for example - run these commands:
+ echo '#include "include/config.h"' | + ppc_8xx-gcc -E -Iinclude -dM - | + grep -E 'define[ \t]+CONFIG_[^ \t]*[ \t]+1$' | + sed -e 's/.*(CONFIG_[^ \t]*).*/\1=y/' | + sort
I remember you wanted to avoid using $(CC) -E ?
Best regards,
Wolfgang Denk
On Thu, Aug 07, 2003 at 02:51:42PM +0200, Wolfgang Denk wrote:
I don't see what good it does. For all boards I tried it just generates an empty "configx.mk" file (well,tnot exactly empty, but two blank lines and a comment).
The ppc preprocessor behaves a bit differently from the other's I've used. Change the line
grep -E 'define[ \t]+CONFIG_[^ \t]*[ \t]+1$' |
to
grep -E 'define[ \t]+CONFIG_[^ \t]*[ \t]+1[ \t]*$' |
I wrote a Perl script to test this. It configures every target and then builds the configx.mk file. I'm attaching the script in case you want to use it.
I noticed that a couple of targets fail because of missing headers in the board specific directories.
I remember you wanted to avoid using $(CC) -E ?
I found no other reliable way to access the target-specific preprocessor. You made it clear that you want to use the cross-compiler's preprocessor, so this a method to do that.
As for submitting patches against more recent source, I'd be happy to do so. The sourceforge CVS server doesn't want to let me login as anonymous. I'll use a more recent snapshot if you have one.
Cheers.
participants (2)
-
Marc Singer -
Wolfgang Denk