[U-Boot-Users] Need the lists opinion on the "right" way to fix something (long)

Bruce_Leonard at selinc.com Bruce_Leonard at selinc.com
Thu Nov 1 23:56:49 CET 2007


Not long ago Grant put in a fix to .../common/cmd_fpga.c that was the 
right thing to do but introduced another problem.  What he did was 
essentially this:

-       #if CFG_FPGA_XILINX
+       #if (CONFIG_FPGA & CFG_FPGA_XILINX)

It's the right thing to do because the first always evaluated to true and 
(in Grant's opinion and mine) the real intent is to check CONFIG_FPGA and 
see if it's a Xilinx part.

However, it introduces the following problem.  CONFIG_FPGA is defined in 
the board specific config file and is usually going to be something like 
this:

#define CONFIG_FPGA             CFG_XILINX_SPARTAN3

Following CFG_XILINX_SPARTAN3 to .../include/xilinx.h you find:

#define CFG_XILINX_SPARTAN3     CFG_FPGA_XILINX | CFG_SPARTAN3

Now as to the problem:  .../common/cmd_fpga.c includes .../include/fpga.h 
but NOT .../include/xilinx.h.  This makes sense because 
.../common/cmd_fpga.c is a common file not a Xilinx specific file.  But, 
when the preprocessor hits Grant's fix it tries to substitute 
CFG_XILINX_SPARTAN3 for CONFIG_FPGA and can't because CFG_XILINX_SPARTAN3 
is defined in .../include/xilinx.h.  The simple solution is to include 
.../include/xilinx.h (which includes .../include/fpga.h) and life is 
happy.  The reason I don't like doing that is because 
.../common/cmd_fpga.c is a common file and I believe it would be a "bad" 
thing to put Xilinx specific stuff into a common file.

Of course the flip side of this is that the function fpga_loadbitsream() 
in .../common/cmd_fpga.c is already Xilinx specific.  IMHO, it shouldn't 
be there in the first place but I understand why it's there.  It's doing 
some pre-processing on the Xilinx BIT file prior to handing it to 
fpga_load(), which is a common high-level function that then starts 
drilling down to determine Altera vs. Xilinx, serial vs. parallel loading, 
etc.

Since I've only been working with u-boot/open source for about 9 months, 
I'm not really sure what the design philosophies are and what the 
acceptable and/or "righ" way of fixing this would be.  Any input or 
direction would be greatly appreciated.  Thanks.

Bruce




More information about the U-Boot mailing list