[U-Boot-Users] [GIT-PULL][Blackfin] Please pull http://www.denx.de/git/u-boot-blackfin.git

[Wolfgang Denk]

In message <27d85ee10703101025l126aede9r955ae2341ba0049 at mail.gmail.com> you wrote:
>
> I guess I'm using the out-of-date toolchain. What arm toolchain are you using?

We use ELDk 4.1, of course.

> /home/aubrey/upstream-uboot/usr/local/arm/3.4.1/bin/../lib/gcc/arm-linux/3.4.1/specs

Yes, GCC-3.4.x is known to have caused issues in many cases before.
Try to avoid it.

> relocation truncated to fit: R_ARM_PLT32 __div0

Seems your toolchain is broken, i. e. GCC cannot find it's own
library routines.

> Well, MAKEALL blackfin has no building problem. I still don't
> understand why blackfin Makefile can make arm building fails. They are
> different architecture, they were supposed to not impact each other.
> If that's true, Can I report a u-boot bug?

You break the feature of using the O=... option on the  make  command
line, or use the "BUILD_DIR" environment variable. Using this feature
means  that  all  files  generated  during  this build are put into a
different directory, so your current source directory tree  will  not
contain any new, generated files.

> As my latest commit and git push, I think copyright and coding style
> issues should be fixed. Please let me know if there still has any
> problems. Thanks a lot.

Argh... I really don't have the time to check and clean up your code.
You are supposed to do that.

You still have coding style issues at least in the following files:

Trailing white space: cpu/bf533/flush.S, cpu/bf533/init_sdram.S,
cpu/bf533/init_sdram_bootrom_initblock.S, cpu/bf533/start.S,
cpu/bf533/traps.c

Indentation not by TABs: include/configs/bf533-stamp.h


A few more comments:

* I object to adding "rm -f $(obj)board/bf*/u-boot.lds" to the top
  level Makefile. You don't know who might be using a board name of
  "bf*".

* cpu/bf533/cache.S: please leave labels unindented, i. e. undo things
  like this:

  	-1:
	+       1:

* cpu/bf533/cache.S: please fix indentation of comments, i. e. undo
  things like this:

	-       /* Clear the IMC bit , All valid bits in the instruction
	-        * cache are set to the invalid state
	-        */
	-       BITCLR(R7,IMC_P);
	+/*
	+ * Clear the IMC bit , All valid bits in the instruction
	+ * cache are set to the invalid state
	+ */
	+       BITCLR(R7, IMC_P);

* Don't remove comments that might be useful, like here:

	-       SSYNC;          /* SSYNC required before writing to IMEM_CONTROL. */
	+       SSYNC;

* cpu/bf533/serial.c - Please undo your changes to the *  declaration
  of  DECLARE_GLOBAL_DATA_PTR.  Leave  it  at file global scope as it
  was, or you will run into problems with more recent  tolchains.  In
  general, don't change things without need!

* cpu/bf533/serial.c - we recently discussed to  introduce  a  sync()
  macro definition - please use this generic name instead of directly
  calling things like __builtin_bfin_ssync()

* include/asm-blackfin/io.h - Why do  you  delete  the  (to  me  good
  looking)  definition  of  sync()  and  replace  it  with  an  empty
  (broken?) one?

* include/asm-blackfin/page.h - it seems you delete the definition of
  BUG() but continue  to use it in PAGE_BUG() ?

* include/asm-blackfin/u-boot.h - here you change only  white  space,
  and  your  don't  make  it  better  - instead, you break formatting
  (indentation  of  comment  on  bi_baudrate).  Please  don't  change
  existing files in such a way.

* lib_blackfin/board.c - don't define things like pr_debug(); please
  use the existing debug() macro instead.,

Please note that above list of files are usually only  examples  -  I
mention  problems  only  when I run into them the first time; many of
them are actually present in several files.  Please  check  all  your
code.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why is an average signature file longer than an average Perl script??