[U-Boot] at91 family status

[Reinhard Meyer]

Dear Claudio,
> 2010/11/8 Andreas Bießmann<andreas.devel at googlemail.com>:
>>
>> There where some major changes regarding arm relocation. Some boards currently fixed but a lot not.
>> Please see u-boot-atmel.git tree for a not yet submitted at91sam9 board called top9000. This could be a good starting point for you. AFAIR relocation on arm926ejs is working on that board so you may get your board fixed.
>>
>
> Thank you for point out this board I fix my board with this reference
> and also some generic api.
>
> For your convenience I upload the single patches here
> http://test.ninux.org/~claudyus/patch/uboot/
It is not very convenient to comment on patches that did not come per eMail :)
And others can not follow the discussion. However I will point out some
things I noticed when I looked at the patches there:

Generally:
We don't do #define SOMETHING 1 anymore when the define is for
#ifdef use only.
On occasion you have included at91sam9260.h instead of hardware.h.

 > 0001-at91-add-support-for-NetusG20.patch
 > 0002-AT91-re-work-netusg20-support-after-ARM-reloc.patch
 > 0007-AT91-totally-reworks-the-netusg20-board-on-the-top-o.patch

You should squash those together, so the final result can be seen,
instead of (for example) making config.mk appear (wrong anyway) and
disappear later again. If you want to split your board support into
two like top9000 currently is:
One initially to be based on the AT91 branch (one to be mainlined soon)
and one based on top of at91avr32rework (which is still moving fast,
and I cannot guarantee it being mainline very soon)

 > 0003-AT91-fix-compile-error-after-f5571dc9.patch
[at91sam9260_devices.c]

That include can not be necessary for your final board support!
Note that your board config.h must define which SoC to use first,
then include hardware.h to pull in the correct defines.

 > 0004-AT91-define-the-mmci-base-address-for-at91sam9-20.patch
[at91sam9260.h]

Line 71 already has:
#define ATMEL_BASE_MCI		0xfffa8000
If somewhere else MMCI is used that location must be fixed.
We are using the naming introduced in the data sheets.

 > 0005-AT91-replace-AT91_BASE_SPI-with-ATMEL_BASE_SPI0.patch
[atmel_dataflash_spi.c]

This is a separate patch for the rework of the *generic ATMEL*
drivers. It should mention in the subject that it fixes the
spi-dataflash driver. I can also squash that one into the
"ATMEL: fix related common atmel driver files patch". However
references to AT91 must be replaced by ATMEL throughout the
driver. See atmel_spi.c!
Maybe atmel_dataflash_spi.c can then be united with atmel_spi.c,
in a later fixup?

 > 0006-AT91-move-spi-generic-function-from-top9000-board-to.patch
[spi_cs* functions]

Those functions are not generic. They might be similar on most
at91sam9260/9g20/9xe boards but the use of GPIO pins
as SPI chip selects is truly board specific. Note that
top9000 defines 2x SPI with 4 chip selects each and therefore
allows pins to flicker that in other boards might be used for
different purposes. You can duplicate the functions but
zero out any chip selects that your board does not use.
On any account, those functions never belong into the ATMEL
generic SPI driver that is for *all* AVR32 and AT91 SoCs.

> This work is based on the top of atmel/at91avr32rework branch.

One note to that branch (partly mentioned above):
It sprang from the idea to cleanup the mess in the AT91 *.h
hierarchy and also to align the AVR32 and AT91 architectures
because they (due to the same IPs used) share several drivers.
Currently I am collecting "cleanup" patches there and to verify
the build(s) I am rebasing boards ports along the top of it.

Therefore it would help to have your board on the top as well.

I am (with low prio) working on the at91sam9260/9g20/9xe board.

Three boards working atop the reworks are a good base to mainline
the rework itself...

Best Regards,
Reinhard