From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ulf Samuelsson <ulf@atmel.com>
Date: Fri, 9 Feb 2007 23:18:50 +0100
Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
References: <20070209193909.C448835265F@atlas.denx.de>
Message-ID: <010801c74c98$716c2040$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

link: www.avrfreaks.net
----- Original Message ----- 
From: "Wolfgang Denk" <wd@denx.de>
To: "Haavard Skinnemoen" <hskinnemoen@atmel.com>
Cc: "Ulf Samuelsson" <ulf@atmel.com>; <u-boot-users@lists.sourceforge.net>
Sent: Friday, February 09, 2007 8:39 PM
Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK


> In message <20070209164520.68b3980c@dhcp-252-105.norway.atmel.com> you 
> wrote:
>>
>> I suggest we try to create a patch series doing the following:
>>   1. Eliminate any differences between the two at45.c drivers
>>   2. Consolidate the two drivers into drivers/at45.c
>>   3. Do a codingstyle cleanup of drivers/at45.c
>>   4. Split out the SPI part into a separate driver
>>   5. Make everything portable. This includes getting rid of all the
>>      AT91FOO prefixing.
>>   <insert additional cleanup steps here>
>>
>> Wolfgang, does this sound like a good plan to you?
>
> Yes, it does.
>
> The only thimg I'm not really happy with (whithout having any  better
> suggestion)  is  to  move this into drivers - drivers is intended for
> general, CPU and board independent  code,  where  this  is  obviously
> specific to a certain class of processors.
>
> Best regards,
>




I think at45.c is CPU independent, but spi.c is closely tied to Atmel 
processors.
spi.c consist of:

SpiInit    - Clearly CPU dependent due to pin mux.
                Only reason that sam926x chips can use a common file
                is the #ifdefs...

SpiEnable    - Configure the chip select.
                   - Not generic only useable w Atmel SPI
SpiDisable,SpiEnable: both these start PDC (DMA) transfers.
SpiWrite:    - Initializes the PDC (DMA) for the SPI macro.
                     It sometimes reads the dataflash as a side effect.

---------------
at45.c contains commands which are specific to the at45 series of dataflash.
In order to access the functionality of the at45 chips you have to send
commands over the SPI.

Typically you prepare a descriptor which then calls the SPI driver.
Low level commands are
* send command
* get status
* wait until ready

High level commands are:
* Continous read
* Program flash from internal at45 SRAM buffer
* Transfer from SDRAM to internal SRAM buffer
* Write data to internal at45 SRAM buffer
* Page Erase
* Block Erase
* Read internal at45 SRAM buffer to SDRAM
* Partial Page Write
* Page Write
* Read Dataflash
* Probe Dataflash
You could conceivably use a different SPI flash, I.E. AT26xxx,
and this family of chips would require another driver


---------------
drivers/dataflash.c



This file initializes the SPI and probes the SPI bus for precense of 
dataflash chips.
It determines which type of dataflash chip, and stores this info
in a table allowing printing out this later.

The dataflash is divided into several partitions which
can be independently protected.
A table defines the partition sizes

The AT91F_DataflashSelect function will map a physical address to a chip 
select
using a mapping table.
When fed an address, the function will scan this table until a match is 
found.

You can check if an address is inside the dataflash memory map.
You can check if a memory block is completely inisde the dataflash.

You can check if a memory area is protected,
and you can protect and unprotect the memory area.

The read routine will do error checks, assert the chip select
and then read the dataflash using access routines in at45.c

The write routine will do similar things for writing dataflash

At the end there is an error routine.

Everything Wolfgang dislikes about dataflash (memory mapping)
is either in the memory commands in the common directory
or in the dataflash.c file.

The sam926x patches will need to update the dataflash.c
because most boards will either support one chip select or two
chipselects and this information needs to be there for new boards.

It will not change any of the access routines used to implement memory 
mapping.
That is why I think the sam926x patches can be applied
even though people now question the implementation.

=====================================================

While the functions in at45.c are called AT91xxx they really do not
depend on any specific SPI H/W and it can thus be used
with any chip which implements the SPI API defined
by cpu/arm920t/at91rm9200/spi.c

If you let it remain in the board directories as is, then
you duplicate this for each board.

I think a good place for any driver stuff which is useable
both by at91 and ap7xxx chips could be an
board/atmel/drivers directory.
An alternative would be a cpu/atmel/drivers directory.

I do not think it belongs inside the drivers directory.
By putting spi.c in drivers you have to be really careful not to compile
this for chips which does not have this SPI macro.

The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.

I still would like to have the complete sam926x patch set
implemented before we start to "play" with it

Best Regards
Ulf Samuelsson