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@emk-elektronik.de:
Dear Claudio,
2010/11/8 Andreas Bießmannandreas.devel@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