From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ulf Samuelsson <ulf@atmel.com>
Date: Sun, 11 Feb 2007 17:43:38 +0100
Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
References: <mailman.12584.1171099992.16820.u-boot-users@lists.sourceforge.net>
	<47403.127.0.0.1.1171139473.squirrel@localhost>
Message-ID: <007601c74dfc$13ee7340$01c4af0a@Glamdring>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

>>>
>>> But we agree that this *is* specific to a certain class of processors
>>> of the ARM family, right?
>>
>> No. You can add dataflash to any processor with an SPI
>> interface or even if you do not have an SPI interface you
>> can access the device using standard I/O pins.
>>
>> At the moment, inside U-Boot it is only used by AT91 processors
>> but that is really not the same thing.
>>
>
>
> Hello, i'm afraid to be wrong, but at45.c is used also by Blackfin version
> of uboot at blackfin.uclinux.org  to allow booting off Atmel Dataflash
> some of Blackfin boards. So at45.c is not a processor specific.
>

The at45.c contains the at45 commands and the spi driver.
For all other chips the spi driver seems to be
in the cpu/xxx directories.
That is why my patch merges the duplicated at45.c's
into a single file, but the splits the file into two parts,
one containing the at45 commands in driver/at45.c and
one containing the spi driver for the at91rm9200 in
cpu/arm920t/at91rm9200.

Any duplication causes by this is against code which is not
yet present in the current source tree, but only against code
Haavard wants to write.

Duplication of a few subroutines is not uncommon in U-boot
Looking through the Power PC directories and the NIOS/NIOS2
you easily find subroutines beeing duplicated?between different
architectures.

I do not see any "cpu/<vendor>" directories in U-Boot
and to split up the spi driver into multiple files just
because a few of the routines are duplicated will
make maintenance harder, and will muddle the reponsibility.

I do not understand who will be responsible for maintaining
the spi support for at91 chips if it is rewritten.

At least Wolfgang, which multiple times has said he wants
to have a single Makefile to edit should appreciate this.

Please realize that, while I am providing the patches, I am just taking what
the Atmel AT91 groups is delivering to the end customers.
The AT91 group is fed up with zero response
and has basically given up on trying to get patches approved.

I am in no way able to support fully testing significant modifications of 
these
patches and I belive that if this is done, there will be noone
accepting responsibility for that these patches actually
generate U-Boot binaries's which will actually work.

>From what I have seen, the patches from the AT91 group fit closely into the 
current
way U-Boot is designed, and they should be reviewed by people that
actually study the patches so that an unbiased opinion is given.


Best regards, Ivan
>
>


Best Regards
Ulf Samuelsson