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
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
