During "./MAKEALL avr32" at least my toolchain gives the following warnings for 
every board:

Configuring for atstk1002 board...
atmel_usart.c:21:2: warning: #warning Please update to use C structur SoC 
access !
cmd_bdinfo.c: In function 'do_bdinfo':
cmd_bdinfo.c:295: warning: format '%d' expects type 'int', but argument 2 has 
type 'long unsigned int'
   text    data     bss     dec     hex filename
  91587    7136  211712  310435   4bca3 ./u-boot
<same for all boards>
====
atmel_usart.c:

that is more or less a TODO warning, it should probably be removed or the
structure approach be implemented. And is it wise to directly pointer access 
hardware,
even if the AVR32 hardware allows that without cache problems?

====
cmd_bdinfo.c:

this is because
        printf ("baudrate    = %d bps\n", bd->bi_baudrate);
but
        AVR32 bd_t has unsigned long bi_baudrate
and there is no explicit case for avr32 architecture, so the code under
        /* ! PPC, which leaves MIPS */
is compiled and used!

The current architecture specific #if chain in cmd_bdinfo.c is as follows:

#ifndef CONFIG_ARM      /* PowerPC and other */
 #ifdef CONFIG_PPC
 #elif defined(CONFIG_NIOS2) /* Nios-II */
 #elif defined(CONFIG_MICROBLAZE) /* ! PPC, which leaves Microblaze */
 #elif defined(CONFIG_SPARC)    /* SPARC */
 #elif defined(CONFIG_M68K) /* M68K */
 #elif defined(CONFIG_BLACKFIN)
 #else /* ! PPC, which leaves MIPS */
>>AVR32 falls into here <<
 #endif  /* MIPS */
#else   /* ARM */
#endif /* CONFIG_ARM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX */

Would it not be better to include ARM in the #elif chain as well, and of course
add AVR32 in a similiar way:
#if defined(CONFIG_PPC)
#elif defined(CONFIG_NIOS2)
#elif defined(CONFIG_MICROBLAZE)
#elif defined(CONFIG_SPARC)
#elif defined(CONFIG_M68K)
#elif defined(CONFIG_BLACKFIN)
#elif defined(CONFIG_MIPS)
#elif defined(CONFIG_AVR32)
#elif defined(CONFIG_ARM)
#else
  #error "a case for this architecture does not exist"
#endif

I can rework that and submit a patch, but I cannot MAKEALL all the 
architectures.
However the changes should be straightforward and involve little risk breaking
something.

Reinhard

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to