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-b...@emk-elektronik.de>: > Dear Claudio, >> >> 2010/11/8 Andreas Bießmann<andreas.de...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot