[U-Boot] at91 family status

[Claudio]

Dear Reinhard
thank you for your review. I know that post the patches on an
webserver isn't the common path but this time this was really a wip
work...

2010/11/9 Reinhard Meyer <u-boot at emk-elektronik.de>:
> 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.

Inside the board config.h, before the include of hardware.h, I have
the appropriate #define AT91SAM9G20 but build fails anyway due to
undefined ATMEL_PIO_PORTS.


>
>> 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.
>

So the following should be converted:
$ grep -inr 'ATMEL_BASE_MMCI' *
arch/avr32/include/asm/arch-at32ap700x/hardware.h:78:#define
ATMEL_BASE_MMCI				0xFFF02400
drivers/mmc/atmel_mci.h:241:	readl((void *)ATMEL_BASE_MMCI + MMCI_##reg)
drivers/mmc/atmel_mci.h:243:	writel((value), (void *)ATMEL_BASE_MMCI +
MMCI_##reg)


>> 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

feel free to do so if is convenient for you

>> 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

That not true, I found that those 8 chip select are defined in
**exactly** the same way inside at91sm9g20 datasheet.
Finally I don't understand WHY those function are used to
enable/disable CS when this function should be managed in hw...
What do you suggest?
I should replicate this code or keep a shared file for
at91sam9260/9g20/9xe boards and leave avr32 in a separate file?

Best Regards