On 10/17/2012 2:05 PM, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/12 13:32, Troy Kisky wrote:
On 10/11/2012 4:15 PM, Tom Rini wrote:
On Fri, Oct 12, 2012 at 12:27:09AM +0200, stefano babic wrote:
[snip]
One reason to move into the board directory is that there was a
decision to move rules related to only one arch or SOC where
they belong to, that is in the corresponding arch/ or board/
directory.
I'll admit that maybe my make-fu is off, but that idea doesn't
work, at least for SPL. So I'd really like someone to make that
work first.
2. Easy to clean the temporary generated file. The main
Makefile deletes files with .pcfgtmp extension.
3. The file referred to by boards.cfg actually exists before
the build starts.
This is true, but I do not understand which is the advantage. A
lot of files are generated, also .c or .S files. If it exists
or not, it does not matter.
Consistency was my point here. Every other file in boards.cfg
exists prior to build.
4. The temporary file can be placed in an out-of-tree
directory for make -O builds
Using the file extension to determine whether to use the
preprocessor is also what gcc uses to preprocess ".S" files
while skipping this for ".s" files.
I believe that at least other mx6 boards will quickly change
to using the preprocessor as well to add support for
solo/duallite, so total line count should eventually be less
with changes to the main makefile.
Ok, but if this true, the rule should be moved to the mx6
directory, and should not be valid for other i.MX that do not
need it.
Introducing slight differences to the image generation rules per
family generation when we could just have one rule that works
fine for all generations is one worry I have about the notion of
moving things out of a top level Makefile and putting them
elsewhere.
Having said that, I really have no problem going your route,
I just don't prefer it. Let me know.
Let's wait to know Tom's opinion.
How about this, if we convert the existing cfg files to '@'
comments and use the LDSCRIPT style preprocessor rule instead of
another one? I assume there's improvements that could be done to
the mx5 ones if we preprocessed them. Or no? I'm looking for
opinions here myself still..
I had previously converted all existing cfg files to /* */
comments. That style of comment seems common for LDSCRIPTs as well.
'@''s actually give me an error.
arm-eabi-ld:u-boot.lds:1: ignoring invalid character `@' in
expression
Right, but in u-boot.lds.S it gets preprocessed away, at least I swear
I changed and tested that. My thinking being it was a smaller diff
delta.
Good point. Is there some magic parameter to pass to gcc to strip @. My
current
command line is expanded to
arm-eabi-gcc -E -x c board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfg -g -Os
-fno-common -ffixed-r8 -msoft-float -D__KERNEL__
-DCONFIG_SYS_TEXT_BASE=0x17800000
-I/home/tkisky/u-boot-imx6/include -fno-builtin -ffreestanding -nostdinc
-isystem
/home/tkisky/myandroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include
-pipe
-DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux
-march=armv7-a
-o board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfgtmp
Alternatively, I could send a small patch to mkimage to ignore @ lines
along with the currently
ignored # lines.
I grepped all lds files in u-boot, but could not find one that used @ as
a comment indicator.
I don't know what/where u-boot.lds.S is.
But my final point being I don't think we should start
introducing artificial differences here just because older boards may
not use it. That doing that leads to bit rot.
I do believe mx5 files can benefit from preprocessing. I can see
the advantage of converting everything now. I also like flexibility
of not forcing every cfg file to change now. So, I am setting on
the fence. If I have to take a position, I'd fall on the side of
the smaller patch set of a gradual conversion, just because I like
smaller patches.
I'm on the other side only because "later" sometimes never happens.
Doing it as a series of smaller patches, now might be fine too...
- --
Tom
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
