Dear Claudio, > 2010/11/8 Andreas Bießmann<[email protected]>: >> >> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
