* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
[not found] <c88e466f0702050752t16c18251gcddf40a7ec95469@mail.gmail.com>
@ 2007-02-07 23:17 ` Ulf Samuelsson
2007-02-08 6:06 ` Stefan Roese
0 siblings, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-07 23:17 UTC (permalink / raw)
To: u-boot
> Hej,
>
> Has anyone used the at91_nand driver on the AT91SAM9260EK?
>
> I get bad erase blocks on every block that contaions data (written to
> nand flash with SAM-BA). Seems like the read_oob (read out of bounds
> area) function is returning data from the in bounds area.
>
> U-boot configs the nand flash to use hw ecc (syndrome) whereas the
> at91_nand seems to be setup to use soft ecc.
>
According to recent conversations on U-Boot mailing list
U-boot can do a raw copy of a flash file system, but nothing more.
(Correct me if I have misunderstood)
This means that if there are faulty pages in the NAND flash, you are dead.
U-Boot needs to be able to map out JFFS2 or YAFFS(2) to be useful here.
I.E. NAND flash is not functional as a boot memory yet.
If I understand correctly, you can read a JFFS2 fs in U-Boot
With the SAM9260, you can boot from an external dataflash card,
containing Linux and a small file system.
When this has booted, I think you can create a JFFS2 file system on the
NAND flash. This should contain the Linux image as well.
U-Boot should then after reset, be able to read the linux from
the JFFS2 file system and then boot.
I do not know if U-boot can fit into the NAND flash
and I have not tested anything of above, but I think it should work.
The programming time of the system
will of course be significant, since you have to test the NAND flash
for bad sectors..
> If anyone has been down this path before, I would appreciate any
> pointers or assistance you can provide.
>
> Michel
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
>
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-07 23:17 ` [U-Boot-Users] AT91 NAND om AT91SAM9260EK Ulf Samuelsson
@ 2007-02-08 6:06 ` Stefan Roese
2007-02-08 8:34 ` Michel Benoit
0 siblings, 1 reply; 42+ messages in thread
From: Stefan Roese @ 2007-02-08 6:06 UTC (permalink / raw)
To: u-boot
On Thursday 08 February 2007 00:17, Ulf Samuelsson wrote:
> > Has anyone used the at91_nand driver on the AT91SAM9260EK?
> >
> > I get bad erase blocks on every block that contaions data (written to
> > nand flash with SAM-BA). Seems like the read_oob (read out of bounds
> > area) function is returning data from the in bounds area.
> >
> > U-boot configs the nand flash to use hw ecc (syndrome) whereas the
> > at91_nand seems to be setup to use soft ecc.
>
> According to recent conversations on U-Boot mailing list
> U-boot can do a raw copy of a flash file system, but nothing more.
> (Correct me if I have misunderstood)
Yes. But this copy is bad block aware.
> This means that if there are faulty pages in the NAND flash, you are dead.
No. Bad blocks are handled correctly.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
=====================================================================
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 6:06 ` Stefan Roese
@ 2007-02-08 8:34 ` Michel Benoit
2007-02-08 19:25 ` Ulf Samuelsson
2007-02-10 1:53 ` Ken Watson
0 siblings, 2 replies; 42+ messages in thread
From: Michel Benoit @ 2007-02-08 8:34 UTC (permalink / raw)
To: u-boot
Good morning!
What version of the AT91SAM9260EK u-boot code are you referring to?
I am using u-boot-1.1.5_atmel_1.2 from the Atmel ftp site.
Is there a more recent version available? Are there any plans to add
the at91sam9260ek support to the main branch of u-boot (latest version
1.2).
In looking through the 1.1.5 Atmel u-boot code I see that nand_bbt.c
is used to map out bad blocks marked by the manufacturer. I can write
my code to nand from external SAM-BA tool and boot without any
problems. Has anyone tried booting from JFFS2 nand within u-boot?
The problem that I was having with the NAND flash on my AT91SAM9260EK
board is related to the fact that the hw ECC controller in the 9260
uses the first four bytes of out of bounds space after each page to
store an error correction/verification number. The Samsung flash on
my board uses the first byte of oob space in the first two pages of a
block to mark that it is bad. If the byte is not FF then the mfg has
marked the block as bad and it should never be used. When linux mtd
starts up it looks for mfg bad blocks and removes them from the
available list of nand blocks. Thus any page which contains data is
excluded. Looking around at other nand flash devices I found that
some use both offsets 0 and 5 in the oob space to mark bad blocks. We
plan to use such a nand flash on our custom board. I hope that Atmel
will do the same on future revisions of its AT91SAM9260EK board.
My work around for now is to ignore mfg bad blocks and hope that they
get caught by the ECC verification code. Mfg bad block info has
already been overwritten on my flash chip by the ECC data. Does
anyone know if the Atmel SAMBA tool does any bad block verification
when programming nand flash? It seems to be writing the 4 byte ECC
code in the oob space. Is it also marking mfg bad blocks? If so, at
which offset into the oob space?
Michel
On 2/8/07, Stefan Roese <sr@denx.de> wrote:
> On Thursday 08 February 2007 00:17, Ulf Samuelsson wrote:
> > > Has anyone used the at91_nand driver on the AT91SAM9260EK?
> > >
> > > I get bad erase blocks on every block that contaions data (written to
> > > nand flash with SAM-BA). Seems like the read_oob (read out of bounds
> > > area) function is returning data from the in bounds area.
> > >
> > > U-boot configs the nand flash to use hw ecc (syndrome) whereas the
> > > at91_nand seems to be setup to use soft ecc.
> >
> > According to recent conversations on U-Boot mailing list
> > U-boot can do a raw copy of a flash file system, but nothing more.
> > (Correct me if I have misunderstood)
>
> Yes. But this copy is bad block aware.
>
> > This means that if there are faulty pages in the NAND flash, you are dead.
>
> No. Bad blocks are handled correctly.
>
> Best regards,
> Stefan
>
> =====================================================================
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> =====================================================================
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 8:34 ` Michel Benoit
@ 2007-02-08 19:25 ` Ulf Samuelsson
2007-02-08 20:58 ` Haavard Skinnemoen
2007-02-10 1:53 ` Ken Watson
1 sibling, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-08 19:25 UTC (permalink / raw)
To: u-boot
Michel Benoit skrev:
> Good morning!
>
> What version of the AT91SAM9260EK u-boot code are you referring to?
>
> I am using u-boot-1.1.5_atmel_1.2 from the Atmel ftp site.
> Is there a more recent version available? Are there any plans to add
> the at91sam9260ek support to the main branch of u-boot (latest version
> 1.2).
>
The Atmel U-Boot for the AT91SAM9260/1/3 chips uses a common
driver for dataflash. This is located in the "drivers/at45.c"
If the Atmel U-boot patches are installed, it will break the
"board/at91rm9200dk" and "board/cmc_pu2" since it duplicates
the functionality.
Additional boards coming from Atmel will use the same dataflash driver.
The "board/at91rm9200dk/at45.c" functionality is split
into a CPU dependent part located in "cpu/arm926ejs/at91sam926x/spi.c"
and the "board/at45.c" file.
I tried to start the process of merging with mainstream U-boot
by sending in a patch which split the at45.c located in
board/at91rm9200dk into
* drivers/at45.c
* cpu/arm920t/at91rm9200/spi.c
but I have no feedback.
Peter Pearse which will be responsible for maintaining the ARM part
is not up to speed yet, and noone else seems to be interested.
There has been a discussion about how dataflash should be supported
but the things people do not like are not in this file, they
are in the "board/dataflash.c" file so I have no clue
why nothing is happening.
--
Best Regards,
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
links: www.avrfreaks.net; www.at91.com; avr32linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070208/fe413913/attachment.vcf
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 19:25 ` Ulf Samuelsson
@ 2007-02-08 20:58 ` Haavard Skinnemoen
2007-02-08 22:20 ` Ulf Samuelsson
0 siblings, 1 reply; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-08 20:58 UTC (permalink / raw)
To: u-boot
On 2/8/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> Additional boards coming from Atmel will use the same dataflash driver.
Hopefully including any AVR32 boards featuring DataFlash.
> The "board/at91rm9200dk/at45.c" functionality is split
> into a CPU dependent part located in "cpu/arm926ejs/at91sam926x/spi.c"
> and the "board/at45.c" file.
>
> I tried to start the process of merging with mainstream U-boot
> by sending in a patch which split the at45.c located in
> board/at91rm9200dk into
> * drivers/at45.c
> * cpu/arm920t/at91rm9200/spi.c
Any chance the SPI driver could move into drivers/ as well? The
at32ap7000 has pretty much the same SPI hardware built in, and IMO
there shouldn't really be anything chip-specific about it apart from
pin configuration, register base address and interrupt line (if it
even uses that.)
I'm willing to review the driver if you send it inline as a single
patch, and perhaps help you clean it up as well, if needed. Please Cc
hskinnemoen at atmel.com so I receive it in my mail client at work.
> There has been a discussion about how dataflash should be supported
> but the things people do not like are not in this file, they
> are in the "board/dataflash.c" file so I have no clue
> why nothing is happening.
It could have something to do with the tarball submission format not
being particularly reviewer-friendly...
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 20:58 ` Haavard Skinnemoen
@ 2007-02-08 22:20 ` Ulf Samuelsson
2007-02-09 15:45 ` Haavard Skinnemoen
0 siblings, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-08 22:20 UTC (permalink / raw)
To: u-boot
Haavard Skinnemoen skrev:
> On 2/8/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> Additional boards coming from Atmel will use the same dataflash driver.
>
> Hopefully including any AVR32 boards featuring DataFlash.
>
>> The "board/at91rm9200dk/at45.c" functionality is split
>> into a CPU dependent part located in "cpu/arm926ejs/at91sam926x/spi.c"
>> and the "board/at45.c" file.
>>
>> I tried to start the process of merging with mainstream U-boot
>> by sending in a patch which split the at45.c located in
>> board/at91rm9200dk into
>> * drivers/at45.c
>> * cpu/arm920t/at91rm9200/spi.c
>
> Any chance the SPI driver could move into drivers/ as well? The
> at32ap7000 has pretty much the same SPI hardware built in, and IMO
> there shouldn't really be anything chip-specific about it apart from
> pin configuration, register base address and interrupt line (if it
> even uses that.)
>
> I'm willing to review the driver if you send it inline as a single
> patch, and perhaps help you clean it up as well, if needed. Please Cc
> hskinnemoen at atmel.com so I receive it in my mail client at work.
>
>> There has been a discussion about how dataflash should be supported
>> but the things people do not like are not in this file, they
>> are in the "board/dataflash.c" file so I have no clue
>> why nothing is happening.
>
> It could have something to do with the tarball submission format not
> being particularly reviewer-friendly...
>
> Haavard
Here is it again, was not sent as a tarball, but as an attachement.
This was a patchset of three patches, the remaining
two patches just removes
"board/at91rm9200dk/at45.c" and
"board/cmc_pu2/at45.c"
They are not used any longer.
I do think that it is better to submit the AT91SAM9 patches
first and only then create a common driver.
-------------------------------------------------------------
DESCRIPTION
The at45.c dataflash driver is currently duplicated in
* board/at91rm9200dk
* board/cmc_pu2
This patch splits the at45 dataflash driver into a
* cpu-dependent part located in cpu/arm920t/at91rm9200
* cpu-independent part located in drivers/at45.c
making AT45 Dataflash available to all boards with an
appropriate SPI driver.
All new AT91 boards use this driver, so if/when patches
for these boards are accepted into mainline, having
a common driver will reduce the size of the U-boot source
and make the board support more maintainable.
The "drivers/at45.c" is compiled for all boards
but contain a configuration test:
#ifdef CONFIG_HAS_DATAFLASH
...
#endif
around the code, so if this is not set, the at45
driver will not add code to the system.
------
The current at45.c contains both the cpu specific
spi access routines and a higher layer
dataflash access routine which calls the lower layer
spi routines to read/write dataflash.
To make the at45 independent on the CPU, the
spi layer has been removed from the driver
and placed in the cpu/arm920t/at91rm9200/spi.c.
CPU specific "includes" are moved inside the
CONFIG_HAS_DATAFLASH test
Makefile changes
at45.o has been removed from the Makefiles in
* "board/at91rm9200dk"
* "board/cmc_pu2"
at45.o has been added to the "drivers" Makefile.
spi.o has been added to "cpu/arm920t/at91rm9200/Makefile"
-------------------------------------------------------------
CHANGELOG:
Author: Ulf Samuelsson <ulf <at> atmel.com>
Date: Thu Feb 1 21:18:53 CET 2007
Make at45 driver available to all boards.
Move SPI low level part to cpu/arm920t/at91rm9200
-------------------------------------------------------------
No new configuration options
-------------------------------------------------------------
Patch:
Attached in plaintext
Consists of three parts.
1. Split and move
2. Removal of at45.c from board/at91rm9200dk
3. Removal of at45.c from board/cmc_pu2
-------------------------------------------------------------
Patch generated by
diff -purN \
u-boot-2007-02-01-0rig \
u-boot-2007-02-01 > \
u-boot-2007-02-01-at45_split.1_3.patch
from the parent directory
-------------------------------------------------------------
Tested on PPC and ARM
diff -purN u-boot-2007-02-01-0rig/board/at91rm9200dk/Makefile
u-boot-2007-02-01/board/at91rm9200dk/Makefile
--- u-boot-2007-02-01-0rig/board/at91rm9200dk/Makefile 2007-02-01
20:18:38.000000000 +0100
+++ u-boot-2007-02-01/board/at91rm9200dk/Makefile 2007-02-01
20:43:49.000000000 +0100
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).a
-COBJS := at91rm9200dk.o at45.o flash.o
+COBJS := at91rm9200dk.o flash.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff -purN u-boot-2007-02-01-0rig/board/cmc_pu2/Makefile
u-boot-2007-02-01/board/cmc_pu2/Makefile
--- u-boot-2007-02-01-0rig/board/cmc_pu2/Makefile 2007-02-01
20:23:23.000000000 +0100
+++ u-boot-2007-02-01/board/cmc_pu2/Makefile 2007-02-01
20:44:27.000000000 +0100
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).a
-COBJS := cmc_pu2.o at45.o flash.o load_sernum_ethaddr.o
+COBJS := cmc_pu2.o flash.o load_sernum_ethaddr.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff -purN u-boot-2007-02-01-0rig/cpu/arm920t/at91rm9200/Makefile
u-boot-2007-02-01/cpu/arm920t/at91rm9200/Makefile
--- u-boot-2007-02-01-0rig/cpu/arm920t/at91rm9200/Makefile 2007-02-01
20:18:49.000000000 +0100
+++ u-boot-2007-02-01/cpu/arm920t/at91rm9200/Makefile 2007-02-01
20:42:50.000000000 +0100
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(SOC).a
COBJS = bcm5221.o dm9161.o ether.o i2c.o interrupts.o \
- lxt972.o serial.o usb_ohci.o
+ lxt972.o serial.o spi.o usb_ohci.o
SOBJS = lowlevel_init.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff -purN u-boot-2007-02-01-0rig/cpu/arm920t/at91rm9200/spi.c
u-boot-2007-02-01/cpu/arm920t/at91rm9200/spi.c
--- u-boot-2007-02-01-0rig/cpu/arm920t/at91rm9200/spi.c 1970-01-01
01:00:00.000000000 +0100
+++ u-boot-2007-02-01/cpu/arm920t/at91rm9200/spi.c 2007-02-01
20:27:37.000000000 +0100
@@ -0,0 +1,136 @@
+/* Driver for ATMEL SPI support
+ * Author : Hamid Ikdoumi (Atmel)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include <config.h>
+
+#ifdef CONFIG_HAS_DATAFLASH
+#include <common.h>
+#include <asm/hardware.h>
+#include <dataflash.h>
+
+#define AT91C_SPI_CLK 10000000 /* Max Value = 10MHz to be
compliant to
+the Continuous Array Read function */
+
+/* AC Characteristics */
+/* DLYBS = tCSS = 250ns min and DLYBCT = tCSH = 250ns */
+#define DATAFLASH_TCSS (0xC << 16)
+#define DATAFLASH_TCHS (0x1 << 24)
+
+#define AT91C_TIMEOUT_WRDY 200000
+#define AT91C_SPI_PCS0_SERIAL_DATAFLASH 0xE /* Chip Select 0
: NPCS0 %1110 */
+#define AT91C_SPI_PCS3_DATAFLASH_CARD 0x7 /* Chip Select 3 :
NPCS3 %0111 */
+
+void AT91F_SpiInit(void) {
+
+/*-------------------------------------------------------------------*/
+/* SPI DataFlash Init */
+/*-------------------------------------------------------------------*/
+ /* Configure PIOs */
+ AT91C_BASE_PIOA->PIO_ASR = AT91C_PA3_NPCS0 | AT91C_PA4_NPCS1 |
AT91C_PA1_MOSI | AT91C_PA5_NPCS2 |
+ AT91C_PA6_NPCS3 | AT91C_PA0_MISO | AT91C_PA2_SPCK;
+ AT91C_BASE_PIOA->PIO_PDR = AT91C_PA3_NPCS0 | AT91C_PA4_NPCS1 |
AT91C_PA1_MOSI | AT91C_PA5_NPCS2 |
+ AT91C_PA6_NPCS3 | AT91C_PA0_MISO | AT91C_PA2_SPCK;
+ /* Enable CLock */
+ AT91C_BASE_PMC->PMC_PCER = 1 << AT91C_ID_SPI;
+
+ /* Reset the SPI */
+ AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SWRST;
+
+ /* Configure SPI in Master Mode with No CS selected !!! */
+ AT91C_BASE_SPI->SPI_MR = AT91C_SPI_MSTR | AT91C_SPI_MODFDIS |
AT91C_SPI_PCS;
+
+ /* Configure CS0 and CS3 */
+ *(AT91C_SPI_CSR + 0) = AT91C_SPI_CPOL | (AT91C_SPI_DLYBS &
DATAFLASH_TCSS) | (AT91C_SPI_DLYBCT &
+ DATAFLASH_TCHS) | ((AT91C_MASTER_CLOCK / (2*AT91C_SPI_CLK)) << 8);
+
+ *(AT91C_SPI_CSR + 3) = AT91C_SPI_CPOL | (AT91C_SPI_DLYBS &
DATAFLASH_TCSS) | (AT91C_SPI_DLYBCT &
+ DATAFLASH_TCHS) | ((AT91C_MASTER_CLOCK / (2*AT91C_SPI_CLK)) << 8);
+
+}
+
+void AT91F_SpiEnable(int cs) {
+ switch(cs) {
+ case 0: /* Configure SPI CS0 for Serial DataFlash AT45DBxx */
+ AT91C_BASE_SPI->SPI_MR &= 0xFFF0FFFF;
+ AT91C_BASE_SPI->SPI_MR |=
((AT91C_SPI_PCS0_SERIAL_DATAFLASH<<16) & AT91C_SPI_PCS);
+ break;
+ case 3: /* Configure SPI CS3 for Serial DataFlash Card */
+ /* Set up PIO SDC_TYPE to switch on DataFlash Card and not
MMC/SDCard */
+ AT91C_BASE_PIOB->PIO_PER = AT91C_PIO_PB7; /* Set in PIO mode */
+ AT91C_BASE_PIOB->PIO_OER = AT91C_PIO_PB7; /* Configure in
output */
+ /* Clear Output */
+ AT91C_BASE_PIOB->PIO_CODR = AT91C_PIO_PB7;
+ /* Configure PCS */
+ AT91C_BASE_SPI->SPI_MR &= 0xFFF0FFFF;
+ AT91C_BASE_SPI->SPI_MR |= ((AT91C_SPI_PCS3_DATAFLASH_CARD<<16)
& AT91C_SPI_PCS);
+ break;
+ }
+
+ /* SPI_Enable */
+ AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN;
+}
+
+/*----------------------------------------------------------------------------*/
+/* \fn AT91F_SpiWrite */
+/* \brief Set the PDC registers for a transfert */
+/*----------------------------------------------------------------------------*/
+unsigned int AT91F_SpiWrite ( AT91PS_DataflashDesc pDesc )
+{
+ unsigned int timeout;
+
+ pDesc->state = BUSY;
+
+ AT91C_BASE_SPI->SPI_PTCR = AT91C_PDC_TXTDIS + AT91C_PDC_RXTDIS;
+
+ /* Initialize the Transmit and Receive Pointer */
+ AT91C_BASE_SPI->SPI_RPR = (unsigned int)pDesc->rx_cmd_pt ;
+ AT91C_BASE_SPI->SPI_TPR = (unsigned int)pDesc->tx_cmd_pt ;
+
+ /* Intialize the Transmit and Receive Counters */
+ AT91C_BASE_SPI->SPI_RCR = pDesc->rx_cmd_size;
+ AT91C_BASE_SPI->SPI_TCR = pDesc->tx_cmd_size;
+
+ if ( pDesc->tx_data_size != 0 ) {
+ /* Initialize the Next Transmit and Next Receive Pointer */
+ AT91C_BASE_SPI->SPI_RNPR = (unsigned int)pDesc->rx_data_pt ;
+ AT91C_BASE_SPI->SPI_TNPR = (unsigned int)pDesc->tx_data_pt ;
+
+ /* Intialize the Next Transmit and Next Receive Counters */
+ AT91C_BASE_SPI->SPI_RNCR = pDesc->rx_data_size ;
+ AT91C_BASE_SPI->SPI_TNCR = pDesc->tx_data_size ;
+ }
+
+ /* arm simple, non interrupt dependent timer */
+ reset_timer_masked();
+ timeout = 0;
+
+ AT91C_BASE_SPI->SPI_PTCR = AT91C_PDC_TXTEN + AT91C_PDC_RXTEN;
+ while(!(AT91C_BASE_SPI->SPI_SR & AT91C_SPI_RXBUFF) && ((timeout =
get_timer_masked() ) < CFG_SPI_WRITE_TOUT));
+ AT91C_BASE_SPI->SPI_PTCR = AT91C_PDC_TXTDIS + AT91C_PDC_RXTDIS;
+ pDesc->state = IDLE;
+
+ if (timeout >= CFG_SPI_WRITE_TOUT){
+ printf("Error Timeout\n\r");
+ return DATAFLASH_ERROR;
+ }
+
+ return DATAFLASH_OK;
+}
+#endif
diff -purN u-boot-2007-02-01-0rig/drivers/at45.c
u-boot-2007-02-01/drivers/at45.c
--- u-boot-2007-02-01-0rig/drivers/at45.c 1970-01-01
01:00:00.000000000 +0100
+++ u-boot-2007-02-01/drivers/at45.c 2007-02-01 20:34:34.000000000 +0100
@@ -0,0 +1,515 @@
+/* Driver for ATMEL DataFlash support
+ * Author : Hamid Ikdoumi (Atmel)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include <config.h>
+#include <common.h>
+
+#ifdef CONFIG_HAS_DATAFLASH
+#include <asm/hardware.h>
+#include <dataflash.h>
+
+
+#define AT91C_TIMEOUT_WRDY 200000
+
+
+/*----------------------------------------------------------------------*/
+/* \fn AT91F_DataFlashSendCommand */
+/* \brief Generic function to send a command to the dataflash */
+/*----------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashSendCommand(
+ AT91PS_DataFlash pDataFlash,
+ unsigned char OpCode,
+ unsigned int CmdSize,
+ unsigned int DataflashAddress)
+{
+ unsigned int adr;
+
+ if ( (pDataFlash->pDataFlashDesc->state) != IDLE)
+ return DATAFLASH_BUSY;
+
+ /* process the address to obtain page address and byte address */
+ adr = ((DataflashAddress / (pDataFlash->pDevice->pages_size)) <<
pDataFlash->pDevice->page_offset) + (DataflashAddress %
(pDataFlash->pDevice->pages_size));
+
+ /* fill the command buffer */
+ pDataFlash->pDataFlashDesc->command[0] = OpCode;
+ if (pDataFlash->pDevice->pages_number >= 16384) {
+ pDataFlash->pDataFlashDesc->command[1] = (unsigned char)((adr &
0x0F000000) >> 24);
+ pDataFlash->pDataFlashDesc->command[2] = (unsigned char)((adr &
0x00FF0000) >> 16);
+ pDataFlash->pDataFlashDesc->command[3] = (unsigned char)((adr &
0x0000FF00) >> 8);
+ pDataFlash->pDataFlashDesc->command[4] = (unsigned char)(adr &
0x000000FF);
+ } else {
+ pDataFlash->pDataFlashDesc->command[1] = (unsigned char)((adr &
0x00FF0000) >> 16);
+ pDataFlash->pDataFlashDesc->command[2] = (unsigned char)((adr &
0x0000FF00) >> 8);
+ pDataFlash->pDataFlashDesc->command[3] = (unsigned char)(adr &
0x000000FF) ;
+ pDataFlash->pDataFlashDesc->command[4] = 0;
+ }
+ pDataFlash->pDataFlashDesc->command[5] = 0;
+ pDataFlash->pDataFlashDesc->command[6] = 0;
+ pDataFlash->pDataFlashDesc->command[7] = 0;
+
+ /* Initialize the SpiData structure for the spi write fuction */
+ pDataFlash->pDataFlashDesc->tx_cmd_pt =
pDataFlash->pDataFlashDesc->command ;
+ pDataFlash->pDataFlashDesc->tx_cmd_size = CmdSize ;
+ pDataFlash->pDataFlashDesc->rx_cmd_pt =
pDataFlash->pDataFlashDesc->command ;
+ pDataFlash->pDataFlashDesc->rx_cmd_size = CmdSize ;
+
+ /* send the command and read the data */
+ return AT91F_SpiWrite (pDataFlash->pDataFlashDesc);
+}
+
+
+/*----------------------------------------------------------------------*/
+/* \fn AT91F_DataFlashGetStatus */
+/* \brief Read the status register of the dataflash */
+/*----------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashGetStatus(AT91PS_DataflashDesc pDesc)
+{
+ AT91S_DataFlashStatus status;
+
+ /* if a transfert is in progress ==> return 0 */
+ if( (pDesc->state) != IDLE)
+ return DATAFLASH_BUSY;
+
+ /* first send the read status command (D7H) */
+ pDesc->command[0] = DB_STATUS;
+ pDesc->command[1] = 0;
+
+ pDesc->DataFlash_state = GET_STATUS;
+ pDesc->tx_data_size = 0 ; /* Transmit the command and
receive response */
+ pDesc->tx_cmd_pt = pDesc->command ;
+ pDesc->rx_cmd_pt = pDesc->command ;
+ pDesc->rx_cmd_size = 2 ;
+ pDesc->tx_cmd_size = 2 ;
+ status = AT91F_SpiWrite (pDesc);
+
+ pDesc->DataFlash_state = *( (unsigned char *) (pDesc->rx_cmd_pt) +1);
+
+ return status;
+}
+
+
+/*----------------------------------------------------------------------*/
+/* \fn AT91F_DataFlashWaitReady */
+/* \brief wait for dataflash ready (bit7 of the status register == 1) */
+/*----------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashWaitReady(AT91PS_DataflashDesc
pDataFlashDesc, unsigned int timeout)
+{
+ pDataFlashDesc->DataFlash_state = IDLE;
+
+ do {
+ AT91F_DataFlashGetStatus(pDataFlashDesc);
+ timeout--;
+ } while( ((pDataFlashDesc->DataFlash_state & 0x80) != 0x80) &&
(timeout > 0) );
+
+ if((pDataFlashDesc->DataFlash_state & 0x80) != 0x80)
+ return DATAFLASH_ERROR;
+
+ return DATAFLASH_OK;
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_DataFlashContinuousRead */
+/* Object : Continuous stream Read */
+/* Input Parameters : DataFlash Service */
+/* : <src> = dataflash address */
+/* : <*dataBuffer> = data buffer pointer */
+/* : <sizeToRead> = data buffer size */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashContinuousRead (
+ AT91PS_DataFlash pDataFlash,
+ int src,
+ unsigned char *dataBuffer,
+ int sizeToRead )
+{
+ AT91S_DataFlashStatus status;
+ /* Test the size to read in the device */
+ if ( (src + sizeToRead) > (pDataFlash->pDevice->pages_size *
(pDataFlash->pDevice->pages_number)))
+ return DATAFLASH_MEMORY_OVERFLOW;
+
+ pDataFlash->pDataFlashDesc->rx_data_pt = dataBuffer;
+ pDataFlash->pDataFlashDesc->rx_data_size = sizeToRead;
+ pDataFlash->pDataFlashDesc->tx_data_pt = dataBuffer;
+ pDataFlash->pDataFlashDesc->tx_data_size = sizeToRead;
+
+ status = AT91F_DataFlashSendCommand (pDataFlash,
DB_CONTINUOUS_ARRAY_READ, 8, src);
+ /* Send the command to the dataflash */
+ return(status);
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_DataFlashPagePgmBuf */
+/* Object : Main memory page program through buffer 1 or
buffer 2 */
+/* Input Parameters : DataFlash Service */
+/* : <*src> = Source buffer */
+/* : <dest> = dataflash destination address
*/
+/* : <SizeToWrite> = data buffer size */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashPagePgmBuf(
+ AT91PS_DataFlash pDataFlash,
+ unsigned char *src,
+ unsigned int dest,
+ unsigned int SizeToWrite)
+{
+ int cmdsize;
+ pDataFlash->pDataFlashDesc->tx_data_pt = src ;
+ pDataFlash->pDataFlashDesc->tx_data_size = SizeToWrite ;
+ pDataFlash->pDataFlashDesc->rx_data_pt = src;
+ pDataFlash->pDataFlashDesc->rx_data_size = SizeToWrite;
+
+ cmdsize = 4;
+ /* Send the command to the dataflash */
+ if (pDataFlash->pDevice->pages_number >= 16384)
+ cmdsize = 5;
+ return(AT91F_DataFlashSendCommand (pDataFlash, DB_PAGE_PGM_BUF1,
cmdsize, dest));
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_MainMemoryToBufferTransfert */
+/* Object : Read a page in the SRAM Buffer 1 or 2
*/
+/* Input Parameters : DataFlash Service */
+/* : Page concerned */
+/* : */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_MainMemoryToBufferTransfert(
+ AT91PS_DataFlash pDataFlash,
+ unsigned char BufferCommand,
+ unsigned int page)
+{
+ int cmdsize;
+ /* Test if the buffer command is legal */
+ if ((BufferCommand != DB_PAGE_2_BUF1_TRF) && (BufferCommand !=
DB_PAGE_2_BUF2_TRF))
+ return DATAFLASH_BAD_COMMAND;
+
+ /* no data to transmit or receive */
+ pDataFlash->pDataFlashDesc->tx_data_size = 0;
+ cmdsize = 4;
+ if (pDataFlash->pDevice->pages_number >= 16384)
+ cmdsize = 5;
+ return(AT91F_DataFlashSendCommand (pDataFlash, BufferCommand,
cmdsize, page*pDataFlash->pDevice->pages_size));
+}
+
+
+/*-----------------------------------------------------------------------------
*/
+/* Function Name : AT91F_DataFlashWriteBuffer */
+/* Object : Write data to the internal sram buffer 1 or
2 */
+/* Input Parameters : DataFlash Service */
+/* : <BufferCommand> = command to write buffer1 or buffer2 */
+/* : <*dataBuffer> = data buffer to write */
+/* : <bufferAddress> = address in the internal
buffer */
+/* : <SizeToWrite> = data buffer size */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashWriteBuffer (
+ AT91PS_DataFlash pDataFlash,
+ unsigned char BufferCommand,
+ unsigned char *dataBuffer,
+ unsigned int bufferAddress,
+ int SizeToWrite )
+{
+ int cmdsize;
+ /* Test if the buffer command is legal */
+ if ((BufferCommand != DB_BUF1_WRITE) && (BufferCommand !=
DB_BUF2_WRITE))
+ return DATAFLASH_BAD_COMMAND;
+
+ /* buffer address must be lower than page size */
+ if (bufferAddress > pDataFlash->pDevice->pages_size)
+ return DATAFLASH_BAD_ADDRESS;
+
+ if ( (pDataFlash->pDataFlashDesc->state) != IDLE)
+ return DATAFLASH_BUSY;
+
+ /* Send first Write Command */
+ pDataFlash->pDataFlashDesc->command[0] = BufferCommand;
+ pDataFlash->pDataFlashDesc->command[1] = 0;
+ if (pDataFlash->pDevice->pages_number >= 16384) {
+ pDataFlash->pDataFlashDesc->command[2] = 0;
+ pDataFlash->pDataFlashDesc->command[3] = (unsigned
char)(((unsigned int)(bufferAddress & pDataFlash->pDevice->byte_mask))
>> 8) ;
+ pDataFlash->pDataFlashDesc->command[4] = (unsigned
char)((unsigned int)bufferAddress & 0x00FF) ;
+ cmdsize = 5;
+ } else {
+ pDataFlash->pDataFlashDesc->command[2] = (unsigned
char)(((unsigned int)(bufferAddress & pDataFlash->pDevice->byte_mask))
>> 8) ;
+ pDataFlash->pDataFlashDesc->command[3] = (unsigned
char)((unsigned int)bufferAddress & 0x00FF) ;
+ pDataFlash->pDataFlashDesc->command[4] = 0;
+ cmdsize = 4;
+ }
+
+ pDataFlash->pDataFlashDesc->tx_cmd_pt =
pDataFlash->pDataFlashDesc->command ;
+ pDataFlash->pDataFlashDesc->tx_cmd_size = cmdsize ;
+ pDataFlash->pDataFlashDesc->rx_cmd_pt =
pDataFlash->pDataFlashDesc->command ;
+ pDataFlash->pDataFlashDesc->rx_cmd_size = cmdsize ;
+
+ pDataFlash->pDataFlashDesc->rx_data_pt = dataBuffer ;
+ pDataFlash->pDataFlashDesc->tx_data_pt = dataBuffer ;
+ pDataFlash->pDataFlashDesc->rx_data_size = SizeToWrite ;
+ pDataFlash->pDataFlashDesc->tx_data_size = SizeToWrite ;
+
+ return AT91F_SpiWrite(pDataFlash->pDataFlashDesc);
+}
+
+/*------------------------------------------------------------------------------*/
+/* Function Name :
AT91F_PageErase */
+/* Object : Erase a page */
+/* Input Parameters : DataFlash Service */
+/* : Page concerned */
+/* : */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_PageErase(
+ AT91PS_DataFlash pDataFlash,
+ unsigned int page)
+{
+ int cmdsize;
+ /* Test if the buffer command is legal */
+ /* no data to transmit or receive */
+ pDataFlash->pDataFlashDesc->tx_data_size = 0;
+
+ cmdsize = 4;
+ if (pDataFlash->pDevice->pages_number >= 16384)
+ cmdsize = 5;
+ return(AT91F_DataFlashSendCommand (pDataFlash, DB_PAGE_ERASE,
cmdsize, page*pDataFlash->pDevice->pages_size));
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name :
AT91F_BlockErase */
+/* Object : Erase a Block */
+/* Input Parameters : DataFlash Service */
+/* : Page concerned */
+/* : */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_BlockErase(
+ AT91PS_DataFlash pDataFlash,
+ unsigned int block)
+{
+ int cmdsize;
+ /* Test if the buffer command is legal */
+ /* no data to transmit or receive */
+ pDataFlash->pDataFlashDesc->tx_data_size = 0;
+ cmdsize = 4;
+ if (pDataFlash->pDevice->pages_number >= 16384)
+ cmdsize = 5;
+ return(AT91F_DataFlashSendCommand (pDataFlash,
DB_BLOCK_ERASE,cmdsize, block*8*pDataFlash->pDevice->pages_size));
+}
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_WriteBufferToMain */
+/* Object : Write buffer to the main memory */
+/* Input Parameters : DataFlash Service */
+/* : <BufferCommand> = command to send to buffer1 or buffer2 */
+/* : <dest> = main memory address */
+/* Return value : State of the dataflash */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_WriteBufferToMain (
+ AT91PS_DataFlash pDataFlash,
+ unsigned char BufferCommand,
+ unsigned int dest )
+{
+ int cmdsize;
+ /* Test if the buffer command is correct */
+ if ((BufferCommand != DB_BUF1_PAGE_PGM) &&
+ (BufferCommand != DB_BUF1_PAGE_ERASE_PGM) &&
+ (BufferCommand != DB_BUF2_PAGE_PGM) &&
+ (BufferCommand != DB_BUF2_PAGE_ERASE_PGM) )
+ return DATAFLASH_BAD_COMMAND;
+
+ /* no data to transmit or receive */
+ pDataFlash->pDataFlashDesc->tx_data_size = 0;
+
+ cmdsize = 4;
+ if (pDataFlash->pDevice->pages_number >= 16384)
+ cmdsize = 5;
+ /* Send the command to the dataflash */
+ return(AT91F_DataFlashSendCommand (pDataFlash, BufferCommand,
cmdsize, dest));
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_PartialPageWrite */
+/* Object : Erase partielly a page */
+/* Input Parameters : <page> = page number */
+/* : <AdrInpage> = adr to begin the fading */
+/* : <length> = Number of bytes to erase */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_PartialPageWrite (
+ AT91PS_DataFlash pDataFlash,
+ unsigned char *src,
+ unsigned int dest,
+ unsigned int size)
+{
+ unsigned int page;
+ unsigned int AdrInPage;
+
+ page = dest / (pDataFlash->pDevice->pages_size);
+ AdrInPage = dest % (pDataFlash->pDevice->pages_size);
+
+ /* Read the contents of the page in the Sram Buffer */
+ AT91F_MainMemoryToBufferTransfert(pDataFlash, DB_PAGE_2_BUF1_TRF,
page);
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+ /*Update the SRAM buffer */
+ AT91F_DataFlashWriteBuffer(pDataFlash, DB_BUF1_WRITE, src,
AdrInPage, size);
+
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+
+ /* Erase page if a 128 Mbits device */
+ if (pDataFlash->pDevice->pages_number >= 16384) {
+ AT91F_PageErase(pDataFlash, page);
+ /* Rewrite the modified Sram Buffer in the main memory */
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+ }
+
+ /* Rewrite the modified Sram Buffer in the main memory */
+ return(AT91F_WriteBufferToMain(pDataFlash, DB_BUF1_PAGE_ERASE_PGM,
(page*pDataFlash->pDevice->pages_size)));
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_DataFlashWrite */
+/* Object : */
+/* Input Parameters : <*src> = Source buffer */
+/* : <dest> = dataflash adress */
+/* : <size> = data buffer size */
+/*------------------------------------------------------------------------------*/
+AT91S_DataFlashStatus AT91F_DataFlashWrite(
+ AT91PS_DataFlash pDataFlash,
+ unsigned char *src,
+ int dest,
+ int size )
+{
+ unsigned int length;
+ unsigned int page;
+ unsigned int status;
+
+ AT91F_SpiEnable(pDataFlash->pDevice->cs);
+
+ if ( (dest + size) > (pDataFlash->pDevice->pages_size *
(pDataFlash->pDevice->pages_number)))
+ return DATAFLASH_MEMORY_OVERFLOW;
+
+ /* If destination does not fit a page start address */
+ if ((dest % ((unsigned int)(pDataFlash->pDevice->pages_size))) !=
0 ) {
+ length = pDataFlash->pDevice->pages_size - (dest % ((unsigned
int)(pDataFlash->pDevice->pages_size)));
+
+ if (size < length)
+ length = size;
+
+ if(!AT91F_PartialPageWrite(pDataFlash,src, dest, length))
+ return DATAFLASH_ERROR;
+
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+
+ /* Update size, source and destination pointers */
+ size -= length;
+ dest += length;
+ src += length;
+ }
+
+ while (( size - pDataFlash->pDevice->pages_size ) >= 0 ) {
+ /* program dataflash page */
+ page = (unsigned int)dest / (pDataFlash->pDevice->pages_size);
+
+ status = AT91F_DataFlashWriteBuffer(pDataFlash, DB_BUF1_WRITE,
src, 0, pDataFlash->pDevice->pages_size);
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+
+ status = AT91F_PageErase(pDataFlash, page);
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+ if (!status)
+ return DATAFLASH_ERROR;
+
+ status = AT91F_WriteBufferToMain (pDataFlash, DB_BUF1_PAGE_PGM,
dest);
+ if(!status)
+ return DATAFLASH_ERROR;
+
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+
+ /* Update size, source and destination pointers */
+ size -= pDataFlash->pDevice->pages_size ;
+ dest += pDataFlash->pDevice->pages_size ;
+ src += pDataFlash->pDevice->pages_size ;
+ }
+
+ /* If still some bytes to read */
+ if ( size > 0 ) {
+ /* program dataflash page */
+ if(!AT91F_PartialPageWrite(pDataFlash, src, dest, size) )
+ return DATAFLASH_ERROR;
+
+ AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY);
+ }
+ return DATAFLASH_OK;
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_DataFlashRead */
+/* Object : Read a block in dataflash */
+/* Input Parameters : */
+/* Return value : */
+/*------------------------------------------------------------------------------*/
+int AT91F_DataFlashRead(
+ AT91PS_DataFlash pDataFlash,
+ unsigned long addr,
+ unsigned long size,
+ char *buffer)
+{
+ unsigned long SizeToRead;
+
+ AT91F_SpiEnable(pDataFlash->pDevice->cs);
+
+ if(AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY) != DATAFLASH_OK)
+ return -1;
+
+ while (size) {
+ SizeToRead = (size < 0x8000)? size:0x8000;
+
+ if (AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
AT91C_TIMEOUT_WRDY) != DATAFLASH_OK)
+ return -1;
+
+ if (AT91F_DataFlashContinuousRead (pDataFlash, addr, (uchar
*)buffer, SizeToRead) != DATAFLASH_OK)
+ return -1;
+
+ size -= SizeToRead;
+ addr += SizeToRead;
+ buffer += SizeToRead;
+ }
+
+ return DATAFLASH_OK;
+}
+
+
+/*------------------------------------------------------------------------------*/
+/* Function Name : AT91F_DataflashProbe */
+/* Object : */
+/* Input Parameters : */
+/* Return value : Dataflash status register */
+/*------------------------------------------------------------------------------*/
+int AT91F_DataflashProbe(int cs, AT91PS_DataflashDesc pDesc)
+{
+ AT91F_SpiEnable(cs);
+ AT91F_DataFlashGetStatus(pDesc);
+ return((pDesc->command[1] == 0xFF)? 0: pDesc->command[1] & 0x3C);
+}
+
+#endif
diff -purN u-boot-2007-02-01-0rig/drivers/Makefile
u-boot-2007-02-01/drivers/Makefile
--- u-boot-2007-02-01-0rig/drivers/Makefile 2007-02-01
20:18:50.000000000 +0100
+++ u-boot-2007-02-01/drivers/Makefile 2007-02-01 20:28:50.000000000
+0100
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)libdrivers.a
-COBJS = 3c589.o 5701rls.o ali512x.o atmel_usart.o \
+COBJS = 3c589.o 5701rls.o ali512x.o at45.o atmel_usart.o \
bcm570x.o bcm570x_autoneg.o cfb_console.o cfi_flash.o \
cs8900.o ct69000.o dataflash.o dc2114x.o dm9000x.o \
e1000.o eepro100.o \
--
Best Regards,
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
links: www.avrfreaks.net; www.at91.com; avr32linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070208/cc3a1ad4/attachment.vcf
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 22:20 ` Ulf Samuelsson
@ 2007-02-09 15:45 ` Haavard Skinnemoen
2007-02-09 19:11 ` Ulf Samuelsson
2007-02-09 19:39 ` Wolfgang Denk
0 siblings, 2 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-09 15:45 UTC (permalink / raw)
To: u-boot
On Thu, 08 Feb 2007 23:20:55 +0100
Ulf Samuelsson <ulf@atmel.com> wrote:
> Here is it again, was not sent as a tarball, but as an attachement.
> This was a patchset of three patches, the remaining
> two patches just removes
> "board/at91rm9200dk/at45.c" and
> "board/cmc_pu2/at45.c"
> They are not used any longer.
Thanks. When I replied last time, I thought for some reason that this
was a new driver even though I knew perfectly well it isn't. Anyway, I
guess it makes the review process slightly different...
I think the best way forward is probably to first get rid of the
duplication by moving everything as-is into drivers. That way, there's
only a single driver to clean up, not two.
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?
Step #1 is easy:
$ diff -up board/cmc_pu2/at45.c board/at91rm9200dk/at45.c
--- board/cmc_pu2/at45.c 2006-08-30 21:53:30.000000000 +0200
+++ board/at91rm9200dk/at45.c 2006-08-30 21:53:30.000000000 +0200
@@ -593,7 +593,7 @@ int AT91F_DataFlashRead(
if (AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc, AT91C_TIMEOUT_WRDY) != DATAFLASH_OK)
return -1;
- if (AT91F_DataFlashContinuousRead (pDataFlash, addr, buffer, SizeToRead) != DATAFLASH_OK)
+ if (AT91F_DataFlashContinuousRead (pDataFlash, addr, (uchar *)buffer, SizeToRead) != DATAFLASH_OK)
return -1;
size -= SizeToRead;
We'll just have to decide whether or not to keep the cast. buffer is a
char * anyway, so I don't think it makes any difference at all.
Step #2 will probably generate an oversize patch unless we do it as a
git patch, which will basically just boil down to a rename and a
deletion (where the deletion will be the biggest part, but still under
40KB I hope.)
Step #3 is where the fun begins...
I have a prototype board with DataFlash for ATSTK1000, so I can start
testing on AVR32 around step #5. Before that, I'd appreciate some help
testing the individual patches (I can do build testing on ARM though.)
> I do think that it is better to submit the AT91SAM9 patches
> first and only then create a common driver.
If the AT91SAM9 patches include another at45.c driver, I disagree.
Better consolidate first and add new stuff on top of that. But the
driver should be usable for new boards after step #2, so you probably
don't have to wait very long before you can start submitting the SAM
stuff.
Btw, Wolfgang: I'd really appreciate if you could pull the avr32 update
from last november (which I rebased and resent last week):
git://www.atmel.no/~hskinnemoen/u-boot/avr32.git for-wolfgang
It will be a lot easier to support avr32 with a single, unified at45
driver if those changes are in mainline. They simplify much of the
portmux- clock- and I/O management code, thus making it easier to see
what it takes to make the at45 and spi drivers portable across ARM and
AVR32.
Besides, you were the one who specifically asked me to add relocation
support, which is what the update is really all about...
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 15:45 ` Haavard Skinnemoen
@ 2007-02-09 19:11 ` Ulf Samuelsson
2007-02-09 19:54 ` Haavard Skinnemoen
2007-02-09 19:39 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-09 19:11 UTC (permalink / raw)
To: u-boot
>> Here is it again, was not sent as a tarball, but as an attachement.
>> This was a patchset of three patches, the remaining
>> two patches just removes
>> "board/at91rm9200dk/at45.c" and
>> "board/cmc_pu2/at45.c"
>> They are not used any longer.
>
> Thanks. When I replied last time, I thought for some reason that this
> was a new driver even though I knew perfectly well it isn't. Anyway, I
> guess it makes the review process slightly different...
>
> I think the best way forward is probably to first get rid of the
> duplication by moving everything as-is into drivers. That way, there's
> only a single driver to clean up, not two.
>
> 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>
My priority is to have AT91SAM9x support inside U-Boot ASAP.
This approach creates all kinds of unneccessary critical paths
which will delay this
I would like to see the following atpproach.
1) at45_split is applied splitting into
cpu independent part and cpu dependent part.
the drivers/at45.c is siglty modified to handle
at91rm9200dk and cmc_pu2 boards as well
as the at91sam926xek boards
2) cpu/arm926ejs/at91sam926x AT91SAM9 support
This has an spi.c which is different from
3) board patches applied
board/at91sam9260ek
board/at91sam9261ek
board/at91sam9263ek
board/at91rm9200ek
board/at91rm9200df
drivers/dataflash.c update to support linux-2.6 instead of linux-2.4
After that is in place, then it is time for your proposal.
1) Do a codingstyle cleanup of drivers/at45.c
2) Make everything portable.
This includes getting rid of all the AT91FOO prefixing.
If we follow your approach, then the at91sam926x
SPI support has first to be inserted into at45.c and retested
only to be split up at a later stage.
>
> Wolfgang, does this sound like a good plan to you?
>
> Step #1 is easy:
>
> $ diff -up board/cmc_pu2/at45.c board/at91rm9200dk/at45.c
> --- board/cmc_pu2/at45.c 2006-08-30 21:53:30.000000000 +0200
> +++ board/at91rm9200dk/at45.c 2006-08-30 21:53:30.000000000 +0200
> @@ -593,7 +593,7 @@ int AT91F_DataFlashRead(
> if (AT91F_DataFlashWaitReady(pDataFlash->pDataFlashDesc,
> AT91C_TIMEOUT_WRDY) != DATAFLASH_OK)
> return -1;
>
> - if (AT91F_DataFlashContinuousRead (pDataFlash, addr,
> buffer, SizeToRead) != DATAFLASH_OK)
> + if (AT91F_DataFlashContinuousRead (pDataFlash, addr,
> (uchar *)buffer, SizeToRead) != DATAFLASH_OK)
> return -1;
>
> size -= SizeToRead;
>
> We'll just have to decide whether or not to keep the cast. buffer is a
> char * anyway, so I don't think it makes any difference at all.
>
> Step #2 will probably generate an oversize patch unless we do it as a
> git patch, which will basically just boil down to a rename and a
> deletion (where the deletion will be the biggest part, but still under
> 40KB I hope.)
>
> Step #3 is where the fun begins...
>
> I have a prototype board with DataFlash for ATSTK1000, so I can start
> testing on AVR32 around step #5. Before that, I'd appreciate some help
> testing the individual patches (I can do build testing on ARM though.)
>
I do not see anyone from the AT91 team participating in this effort
right now, and that is why I think we should apply
*tested* code to establish a base which is useful to at91sam9 users.
>> I do think that it is better to submit the AT91SAM9 patches
>> first and only then create a common driver.
>
> If the AT91SAM9 patches include another at45.c driver, I disagree.
The at91sam9 patchset has a board/at45.c and it is this that
is available in in the "at45_split" patch.
If at91_split is applied there will be no modification of this file
when the at91sam9 patchset is submitted.
> Better consolidate first and add new stuff on top of that. But the
> driver should be usable for new boards after step #2, so you probably
> don't have to wait very long before you can start submitting the SAM
> stuff.
the spi.c is very small and msot of the code relies on the pin multiplexing
of the part.
This is why I think it may make little sense to have a common driver.
>
> Btw, Wolfgang: I'd really appreciate if you could pull the avr32 update
> from last november (which I rebased and resent last week):
>
> git://www.atmel.no/~hskinnemoen/u-boot/avr32.git for-wolfgang
>
> It will be a lot easier to support avr32 with a single, unified at45
> driver if those changes are in mainline. They simplify much of the
> portmux- clock- and I/O management code, thus making it easier to see
> what it takes to make the at45 and spi drivers portable across ARM and
> AVR32.
>
> Besides, you were the one who specifically asked me to add relocation
> support, which is what the update is really all about...
>
> Haavard
>
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 15:45 ` Haavard Skinnemoen
2007-02-09 19:11 ` Ulf Samuelsson
@ 2007-02-09 19:39 ` Wolfgang Denk
2007-02-09 22:18 ` Ulf Samuelsson
1 sibling, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2007-02-09 19:39 UTC (permalink / raw)
To: u-boot
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,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 19:11 ` Ulf Samuelsson
@ 2007-02-09 19:54 ` Haavard Skinnemoen
0 siblings, 0 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-09 19:54 UTC (permalink / raw)
To: u-boot
On 2/9/07, Ulf Samuelsson <ulf@atmel.com> 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>
>
> My priority is to have AT91SAM9x support inside U-Boot ASAP.
> This approach creates all kinds of unneccessary critical paths
> which will delay this
Hmm...at first I thought you disagreed with the whole approach, but I
think what you _really_ disagree with is the ordering of step 3 and 4.
I have no problem with doing these steps the other way around.
> I would like to see the following atpproach.
>
> 1) at45_split is applied splitting into
> cpu independent part and cpu dependent part.
> the drivers/at45.c is siglty modified to handle
> at91rm9200dk and cmc_pu2 boards as well
> as the at91sam926xek boards
The problem with your patchset is that it first creates a _third_
identical driver before removing the other two. I think it would be
cleaner to consolidate the existing two first, and it's not even a big
deal -- if it still builds after the move, it works because the code
will be the same.
After we then split out the spi part, you can apply your at91sam926
stuff on top of that. This will hopefully be a very small patch.
Btw, why is at45.c going to be modified? It already supports both
at91rm9200dk and cmc_pu2. The differences are minimal and purely
cosmetic.
> 2) cpu/arm926ejs/at91sam926x AT91SAM9 support
> This has an spi.c which is different from
Different from what? AFAIK the hardware is the same as on AT91RM9200
and AT32AP7000 modulo a couple of extra features which probably aren't
useful to u-boot.
If you're talking about the port muxing, I think it's _really_
overkill to add a new driver for each mux configuration. Maybe it
would be better not to split it spi vs. dataflash, but rather
"chip-dependent stuff like port muxing" vs. "chip-independent driver
code"?
> 3) board patches applied
> board/at91sam9260ek
> board/at91sam9261ek
> board/at91sam9263ek
> board/at91rm9200ek
> board/at91rm9200df
> drivers/dataflash.c update to support linux-2.6 instead of linux-2.4
>
> After that is in place, then it is time for your proposal.
Fine. If it will give us more at91 testers, I'm all for it.
> 1) Do a codingstyle cleanup of drivers/at45.c
> 2) Make everything portable.
> This includes getting rid of all the AT91FOO prefixing.
>
> If we follow your approach, then the at91sam926x
> SPI support has first to be inserted into at45.c and retested
> only to be split up at a later stage.
We can do the spi split before the code cleanup if that helps. But I
can't help but think that a per-chip spi driver is mighty strange...
> I do not see anyone from the AT91 team participating in this effort
> right now, and that is why I think we should apply
> *tested* code to establish a base which is useful to at91sam9 users.
Good point. But code that can't be changed because it's been tested
once and for all is going to suck in the long term.
> >> I do think that it is better to submit the AT91SAM9 patches
> >> first and only then create a common driver.
> >
> > If the AT91SAM9 patches include another at45.c driver, I disagree.
>
> The at91sam9 patchset has a board/at45.c and it is this that
> is available in in the "at45_split" patch.
What's the difference between this driver and the existing two?
> If at91_split is applied there will be no modification of this file
> when the at91sam9 patchset is submitted.
That's good.
> > Better consolidate first and add new stuff on top of that. But the
> > driver should be usable for new boards after step #2, so you probably
> > don't have to wait very long before you can start submitting the SAM
> > stuff.
>
> the spi.c is very small and msot of the code relies on the pin multiplexing
> of the part.
> This is why I think it may make little sense to have a common driver.
This is why I think it isn't the spi stuff that ought to get split out
-- it's the pin multiplexing stuff. Maybe it makes sense to split out
the spi stuff as well, if it could have other uses beyond dataflash.
In fact, the STK1000 has an LCD panel which is powered on using SPI,
so a generic spi driver would be nice if we're going to support boot
logo on this board later.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 19:39 ` Wolfgang Denk
@ 2007-02-09 22:18 ` Ulf Samuelsson
2007-02-09 22:58 ` Haavard Skinnemoen
2007-02-10 1:15 ` Wolfgang Denk
0 siblings, 2 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-09 22:18 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 22:18 ` Ulf Samuelsson
@ 2007-02-09 22:58 ` Haavard Skinnemoen
2007-02-09 23:20 ` Ulf Samuelsson
2007-02-10 7:23 ` Stefan Roese
2007-02-10 1:15 ` Wolfgang Denk
1 sibling, 2 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-09 22:58 UTC (permalink / raw)
To: u-boot
On 2/9/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > 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.
It's somewhat cpu- and board-independent. at32 and at91 are based on
two different architectures, so they don't have any directories in
common apart from the ones common to everyone.
We could perhaps create a drivers/atmel subdirectory or, as Ulf
suggests, boards/atmel/drivers or cpu/atmel/drivers.
> 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...
Hmm...how about moving the cpu-dependent bits into inline functions
somewhere under asm/arch? For example
static inline void portmux_enable_spi(unsigned int id)
{
/* do chip-dependent PIO stuff here */
}
asm/arch is chip-specific so there shouldn't be any need for #ifdefs there.
> 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
Yeah, that's why the AT91 prefixing should be dropped. But that's for
much later.
Btw, looks like there's another SPI API in u-boot as well. Probably a
good idea to convert the at91/atmel spi stuff over to implementing
that one. No point in having several APIs doing the same thing, and
the other API uses the much more sensible function name spi_xfer for
doing SPI transfers, as opposed to AT91F_SpiWrite which is totally
misleading since it's being used for reading as well.
> If you let it remain in the board directories as is, then
> you duplicate this for each board.
I don't think anyone wants that. Although you're the one suggesting we
add a _third_ identical driver ;-)
> 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.
Are any other drivers organized this way?
> I do not think it belongs inside the drivers directory.
I'm sorry but I fail to see why not. There are several other
platform-specific drivers in there. And I don't really see the big
advantage of spreading drivers around all over the place...
> 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.
Yeah, but if it's protected by an easy-to-understand #ifdef that
shouldn't be a problem. Although I don't think we should call it spi.c
then. It should be atmel_spi.c or something.
> The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.
Or do it in a chip-specific header file.
> I still would like to have the complete sam926x patch set
> implemented before we start to "play" with it
Yeah, but I still think some preparatory patches are a good thing in
order to make things easier later on.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 22:58 ` Haavard Skinnemoen
@ 2007-02-09 23:20 ` Ulf Samuelsson
2007-02-09 23:42 ` Haavard Skinnemoen
2007-02-10 1:18 ` Wolfgang Denk
2007-02-10 7:23 ` Stefan Roese
1 sibling, 2 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-09 23:20 UTC (permalink / raw)
To: u-boot
>> I still would like to have the complete sam926x patch set
>> implemented before we start to "play" with it
>
> Yeah, but I still think some preparatory patches are a good thing in
> order to make things easier later on.
I only see two things as a result of those prepatory patches.
1) Bugs
2) Delays in availability
I am not questioning anything you want to do, just the timing.
If we follow your recommendation you will have a bunch
of untested board patches in the mainstream u-boot,
for the sam926x.
I do not have the time to thoroughly test any changes
you do (I dont even have an at91sam9263 board).
If we go my way, then we should be able to have *tested* sam926x
support inside U-boot very soon, and while this results
in duplication of a small part of the spi code on the source level
(no addition to the binary) I believe that
the benefit to the community of at91sam926x users
of having native support in U-Boot outweighs this duplication a lot.
The number of users far outweisghs the number of implementers
and I think that we need to look at it from their point of view.
We are not introducing any new interfaces here,
just using the existing interfaces.
This means that it will not be harder to do any modifications
*after* the sam926x patches are applied.
It will be easier since you have better overview.
The only alternative I can see is that you take over
the responsibility for both AVR32 and AT91 U-boot
and test all modifications on all boards before submission
- Still with availability of working solution as the highest priority.
>
> Haavard
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 23:20 ` Ulf Samuelsson
@ 2007-02-09 23:42 ` Haavard Skinnemoen
2007-02-10 0:10 ` Ulf Samuelsson
2007-02-10 1:18 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-09 23:42 UTC (permalink / raw)
To: u-boot
On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> The number of users far outweisghs the number of implementers
> and I think that we need to look at it from their point of view.
Would help a lot to have some of those users help with testing though.
> We are not introducing any new interfaces here,
> just using the existing interfaces.
> This means that it will not be harder to do any modifications
> *after* the sam926x patches are applied.
> It will be easier since you have better overview.
Whatever. Please let me know when you're ready to continue.
> The only alternative I can see is that you take over
> the responsibility for both AVR32 and AT91 U-boot
> and test all modifications on all boards before submission
> - Still with availability of working solution as the highest priority.
I don't think that's going to happen. Besides, having the same person
implement and test the code usually doesn't work very well anyway, so
if we're going to do this we need people willing to test
probably-working-but-still-experimental stuff.
I'm of course not saying that I can't be bothered to test my
modifications before submitting, but relying on me to implement _and_
test everything on all configurations is just insane.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 23:42 ` Haavard Skinnemoen
@ 2007-02-10 0:10 ` Ulf Samuelsson
0 siblings, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-10 0:10 UTC (permalink / raw)
To: u-boot
> On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> The number of users far outweisghs the number of implementers
>> and I think that we need to look at it from their point of view.
>
> Would help a lot to have some of those users help with testing though.
>
>> We are not introducing any new interfaces here,
>> just using the existing interfaces.
>> This means that it will not be harder to do any modifications
>> *after* the sam926x patches are applied.
>> It will be easier since you have better overview.
>
> Whatever. Please let me know when you're ready to continue.
>
I am ready to continue as soon as at45_split is applied.
It is a real simple patch, it divides one more or less duplicated file into
two files.
If I try to apply any sam926x patches without that,
then It will crash the at91rm9200dk and cmc_pu2 board support.
Once this patch is applied, I can submit the at91sam926x patches
and if/when they are accepted, then we have accomplished the most
important goal to Atmel customers,
which is that *tested* sam926x support is available from the primary
U-Boot location and that you can build both at91 and avr32
from the same source code.
I consider all other activities secondary.
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 22:18 ` Ulf Samuelsson
2007-02-09 22:58 ` Haavard Skinnemoen
@ 2007-02-10 1:15 ` Wolfgang Denk
2007-02-10 7:32 ` Stefan Roese
2007-02-10 9:29 ` Ulf Samuelsson
1 sibling, 2 replies; 42+ messages in thread
From: Wolfgang Denk @ 2007-02-10 1:15 UTC (permalink / raw)
To: u-boot
In message <010801c74c98$716c2040$01c4af0a@Glamdring> you wrote:
>
> > 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.
...
> I think at45.c is CPU independent, but spi.c is closely tied to Atmel
...
> at45.c contains commands which are specific to the at45 series of dataflash.
Sounds contradictory ;-)
But I agree with the latter statement: at45.c is specific to the at45
series of dataflash, which in turn is specific to a certain class of
processors. You probably cannot find this on PowerPC, MIPS, NIOS, ...
systems.
That's why I wonder if this should not be located somewhere under
cpu/...
> While the functions in at45.c are called AT91xxx they really do not
Then that naming should be fixed...
> 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
But we agree that this *is* specific to a certain class of processors
of the ARM family, right?
> If you let it remain in the board directories as is, then
> you duplicate this for each board.
This is not what I want, nor what I suggested.
> 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.
No. Not board/... if you are talking about chip specific features.
> An alternative would be a cpu/atmel/drivers directory.
or cpu/atmel/ (without the /drivers part), like we do for other
processors.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The perversity of nature is nowhere better demonstrated by the fact
that, when exposed to the same atmosphere, bread becomes hard while
crackers become soft.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 23:20 ` Ulf Samuelsson
2007-02-09 23:42 ` Haavard Skinnemoen
@ 2007-02-10 1:18 ` Wolfgang Denk
2007-02-10 9:05 ` Ulf Samuelsson
1 sibling, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2007-02-10 1:18 UTC (permalink / raw)
To: u-boot
In message <012b01c74ca1$8ee35fe0$01c4af0a@Glamdring> you wrote:
>
> If we go my way, then we should be able to have *tested* sam926x
> support inside U-boot very soon, and while this results
> in duplication of a small part of the spi code on the source level
> (no addition to the binary) I believe that
> the benefit to the community of at91sam926x users
> of having native support in U-Boot outweighs this duplication a lot.
And once it's in, who guarantees to clean it up later? And when?
> We are not introducing any new interfaces here,
But we're adding to the mess of duplicated code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Spock, did you see the looks on their faces?"
"Yes, Captain, a sort of vacant contentment."
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-08 8:34 ` Michel Benoit
2007-02-08 19:25 ` Ulf Samuelsson
@ 2007-02-10 1:53 ` Ken Watson
1 sibling, 0 replies; 42+ messages in thread
From: Ken Watson @ 2007-02-10 1:53 UTC (permalink / raw)
To: u-boot
Hello,
I'm currently working with the at91sam9260ek board. I've rebased the atmel
code for this board up to the 1.2 release of u-boot. In addition, I've made
modifications to the NAND flash driver to support hardware ECC with
Syndrome. To support this feature, I had to enable the use of "bad block
tables". When u-boot first starts ( I had to start u-boot using the
dataflash), it checks for the existence of the bad block table, and if not
found, scans through all of the erase blocks to create the table. Once this
is done, you can use SAM-BA or the u-boot from dataflash to install U-Boot
to the NAND flash. At this point it is safe to overwrite the bad block
markers in the OOB area, as they are maintained by the bad block table.
This "bad block table" has the added benefit of a faster boot time, as it
doesn't have to scan the entire NAND flash when booting.
Ken Watson
kenw at sixnetio.com
> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-
> bounces at lists.sourceforge.net] On Behalf Of Michel Benoit
> Sent: Thursday, February 08, 2007 3:34 AM
> To: Stefan Roese
> Cc: Ulf Samuelsson; u-boot-users at lists.sourceforge.net; ARM Linux Mailing
> List
> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
>
> Good morning!
>
> What version of the AT91SAM9260EK u-boot code are you referring to?
>
> I am using u-boot-1.1.5_atmel_1.2 from the Atmel ftp site.
> Is there a more recent version available? Are there any plans to add
> the at91sam9260ek support to the main branch of u-boot (latest version
> 1.2).
>
> In looking through the 1.1.5 Atmel u-boot code I see that nand_bbt.c
> is used to map out bad blocks marked by the manufacturer. I can write
> my code to nand from external SAM-BA tool and boot without any
> problems. Has anyone tried booting from JFFS2 nand within u-boot?
>
> The problem that I was having with the NAND flash on my AT91SAM9260EK
> board is related to the fact that the hw ECC controller in the 9260
> uses the first four bytes of out of bounds space after each page to
> store an error correction/verification number. The Samsung flash on
> my board uses the first byte of oob space in the first two pages of a
> block to mark that it is bad. If the byte is not FF then the mfg has
> marked the block as bad and it should never be used. When linux mtd
> starts up it looks for mfg bad blocks and removes them from the
> available list of nand blocks. Thus any page which contains data is
> excluded. Looking around at other nand flash devices I found that
> some use both offsets 0 and 5 in the oob space to mark bad blocks. We
> plan to use such a nand flash on our custom board. I hope that Atmel
> will do the same on future revisions of its AT91SAM9260EK board.
>
> My work around for now is to ignore mfg bad blocks and hope that they
> get caught by the ECC verification code. Mfg bad block info has
> already been overwritten on my flash chip by the ECC data. Does
> anyone know if the Atmel SAMBA tool does any bad block verification
> when programming nand flash? It seems to be writing the 4 byte ECC
> code in the oob space. Is it also marking mfg bad blocks? If so, at
> which offset into the oob space?
>
>
> Michel
>
>
> On 2/8/07, Stefan Roese <sr@denx.de> wrote:
> > On Thursday 08 February 2007 00:17, Ulf Samuelsson wrote:
> > > > Has anyone used the at91_nand driver on the AT91SAM9260EK?
> > > >
> > > > I get bad erase blocks on every block that contaions data (written
> to
> > > > nand flash with SAM-BA). Seems like the read_oob (read out of
> bounds
> > > > area) function is returning data from the in bounds area.
> > > >
> > > > U-boot configs the nand flash to use hw ecc (syndrome) whereas the
> > > > at91_nand seems to be setup to use soft ecc.
> > >
> > > According to recent conversations on U-Boot mailing list
> > > U-boot can do a raw copy of a flash file system, but nothing more.
> > > (Correct me if I have misunderstood)
> >
> > Yes. But this copy is bad block aware.
> >
> > > This means that if there are faulty pages in the NAND flash, you are
> dead.
> >
> > No. Bad blocks are handled correctly.
> >
> > Best regards,
> > Stefan
> >
> > =====================================================================
> > DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> > Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> > =====================================================================
> >
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-09 22:58 ` Haavard Skinnemoen
2007-02-09 23:20 ` Ulf Samuelsson
@ 2007-02-10 7:23 ` Stefan Roese
1 sibling, 0 replies; 42+ messages in thread
From: Stefan Roese @ 2007-02-10 7:23 UTC (permalink / raw)
To: u-boot
On Friday 09 February 2007 23:58, Haavard Skinnemoen wrote:
> On 2/9/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > > 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.
>
> It's somewhat cpu- and board-independent. at32 and at91 are based on
> two different architectures, so they don't have any directories in
> common apart from the ones common to everyone.
>
> We could perhaps create a drivers/atmel subdirectory or, as Ulf
> suggests, boards/atmel/drivers or cpu/atmel/drivers.
My preferred location would be "drivers/atmel" too.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
=====================================================================
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-10 1:15 ` Wolfgang Denk
@ 2007-02-10 7:32 ` Stefan Roese
2007-02-10 9:29 ` Ulf Samuelsson
1 sibling, 0 replies; 42+ messages in thread
From: Stefan Roese @ 2007-02-10 7:32 UTC (permalink / raw)
To: u-boot
On Saturday 10 February 2007 02:15, Wolfgang Denk wrote:
> > 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.
>
> No. Not board/... if you are talking about chip specific features.
>
> > An alternative would be a cpu/atmel/drivers directory.
>
> or cpu/atmel/ (without the /drivers part), like we do for other
> processors.
I really prefer to "collect" the drivers in the "drivers" directory (or a
subdirectory). We already do this (Freescale Quicc Engine "drivers/qe"), and
we have something like "drivers/netarm_eth.c".
So especially for driver that can be used by more than one cpu platform, I
suggest to put them into the drivers directory (or subdirectory) and _not_
create another directory instead.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
=====================================================================
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-10 1:18 ` Wolfgang Denk
@ 2007-02-10 9:05 ` Ulf Samuelsson
0 siblings, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-10 9:05 UTC (permalink / raw)
To: u-boot
> In message <012b01c74ca1$8ee35fe0$01c4af0a@Glamdring> you wrote:
>>
>> If we go my way, then we should be able to have *tested* sam926x
>> support inside U-boot very soon, and while this results
>> in duplication of a small part of the spi code on the source level
>> (no addition to the binary) I believe that
>> the benefit to the community of at91sam926x users
>> of having native support in U-Boot outweighs this duplication a lot.
>
> And once it's in, who guarantees to clean it up later? And when?
>
>> We are not introducing any new interfaces here,
>
> But we're adding to the mess of duplicated code.
>
No, that is wrong.
today at45.c is in itself a duplication.
board/at91rm9200dk/at45.c
and
board/cmc_pu2/at45.c
are duplicates (except for a bug which is not fixed in cmc_pu2)
Customers which build their own board
add additional at45.c's in their board directory.
After the patch you have a single at45.c which is common
for all at91rm9200 boards and a single spi.c which is common
for all at91rm9200 boards and an spi.c which is common for
all at91sam926x boards.
spi.c is CPU specific and the only reason you can have a single
file for the sam926x (three chips supported by that the file) contains
ifdefs
to select which chip.
Duplication is therefore reduced by the patch.
I am sure that you realize this if you get into the details.
> Best regards,
>
> Wolfgang Denk
>
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-10 1:15 ` Wolfgang Denk
2007-02-10 7:32 ` Stefan Roese
@ 2007-02-10 9:29 ` Ulf Samuelsson
1 sibling, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-10 9:29 UTC (permalink / raw)
To: u-boot
> In message <010801c74c98$716c2040$01c4af0a@Glamdring> you wrote:
>>
>> > 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.
> ...
>> I think at45.c is CPU independent, but spi.c is closely tied to Atmel
> ...
>> at45.c contains commands which are specific to the at45 series of
>> dataflash.
>
> Sounds contradictory ;-)
>
> But I agree with the latter statement: at45.c is specific to the at45
> series of dataflash, which in turn is specific to a certain class of
> processors. You probably cannot find this on PowerPC, MIPS, NIOS, ...
> systems.
No it is not specific to any class processors.
You can add at45 dataflash to any processor.
>
> That's why I wonder if this should not be located somewhere under
> cpu/...
>
>> While the functions in at45.c are called AT91xxx they really do not
>
> Then that naming should be fixed...
>
>> 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
>
> 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.
I do believe that it is the guy who wants to use if for more than
AT91 processors that shoudl clean it up.
Please realize that I am not adding code, I am just rearranging code
in a way which will be an improvement of U-Boot.
Are you really against improvements of U-Boot because you want more
improvement
and rather have a worse U-boot because the improvement is not large
enough???
>
>> If you let it remain in the board directories as is, then
>> you duplicate this for each board.
>
> This is not what I want, nor what I suggested.
>
>> 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.
>
> No. Not board/... if you are talking about chip specific features.
>
>> An alternative would be a cpu/atmel/drivers directory.
>
> or cpu/atmel/ (without the /drivers part), like we do for other
> processors.
I do not see any such directories.
I only see cpu/<cpu type> directories.
I believe the proper way to proceed is to merge the tested patches
from the Atmel AT91 group which applies cleanly to the
the current tree (with the exception of at45_split and a small
issue on the NAND flash)
We need to split the current at45.c in the board directory
into spi.c and the remainder of at45.c in order not to break
current code.
I would like to suggest we proceed in the following way:
I modify the patch to generate:
cpu/arm920t/at91rm9200dk/spi.c
cpu/atmel/at45.c
and the neccessary hooks in Makefiles/configurations?
Once that is included, I will submit the at91sam926x patch(es)
One of the sam926x patches will then generate
cpu/arm926ejs/at91sam926x/spi.c
Haavard can then, after the sam926x patch set
has applied merge (if it is really desired) the spi.c
with the AVR32 version and put it in cpu/atmel/spi.c
.
He can the "clean up" cpu/atmel/at45.c" making naming conventions
more generic and move it to drivers/at45.c when that is completed.
Agreed?
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-12 19:37 ` Haavard Skinnemoen
@ 2007-02-12 20:05 ` Ulf Samuelsson
0 siblings, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-12 20:05 UTC (permalink / raw)
To: u-boot
> On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> > On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> >> >> It really does not make sense to test his patches only
>> >> >> on boards which does not use the dataflash.
>> >> >
>> >> > If that's all he has, then he has no other choice.
>> >>
>> >> He has always the choice of realizing that he maybe should
>> >> leave this possible improvement to someone capable of testing it
>> >> and concentrate on stuff which he can test.
>> >
>> > Yeah, that's a nice attitude. "Go away, we don't want your patches."
>> > Without even looking at them?
>>
>> I dont want patches that stops U-boot from functioning, that is correct.
>> If someone creates a patch which will improve functionality,
>> tries it out on a reasonable number of targets and then it
>> later turns out that there are some problems in corner cases,
>> I will not call for a public hanging.
>
> I do agree with this -- all changes should be tested by _someone_.
> However, I don't think we should categorically reject all patches that
> haven't been tested by the author. If someone sees something which
> looks wrong, or an opportunity for optimization, not having the board
> in question shouldn't stop him from submitting a patch IMO. The board
> maintainer (or cpu/arch/subsystem maintainer, depending on the code in
> question) may test it himself, or send it to someone else for testing.
>
> I disagree with your requirement that the author and the tester
> _always_ has to be the same person. Having done thorough testing,
> benchmarking, etc. and providing lots of nice numbers will of course
> increase the chances of acceptance, but none of it is an absolute
> requirement IMO.
>
I do not require that the author and the tester is the same person,
If someone wants to fix something, it is perfectly OK
that someone else tests the patch.
What I have seen of the dataflash interface discussion, there is no plan
to test the dataflash, the goal was to get rid of the dataflash
from the memory commands, write something which
appeared to replace the dataflash command, ensure it compiled
and submit that.
And since the current interface is undesirable, those patches
would get a fast acceptance
This plan leaves dataflash users to sort out the mess and with the current
time to get patches approved, at91 support would be broken for
a long time.
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR link: www.avrfreaks.net
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-12 18:40 ` Ulf Samuelsson
2007-02-12 19:36 ` Stefan Roese
@ 2007-02-12 19:37 ` Haavard Skinnemoen
2007-02-12 20:05 ` Ulf Samuelsson
1 sibling, 1 reply; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-12 19:37 UTC (permalink / raw)
To: u-boot
On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> >> >> It really does not make sense to test his patches only
> >> >> on boards which does not use the dataflash.
> >> >
> >> > If that's all he has, then he has no other choice.
> >>
> >> He has always the choice of realizing that he maybe should
> >> leave this possible improvement to someone capable of testing it
> >> and concentrate on stuff which he can test.
> >
> > Yeah, that's a nice attitude. "Go away, we don't want your patches."
> > Without even looking at them?
>
> I dont want patches that stops U-boot from functioning, that is correct.
> If someone creates a patch which will improve functionality,
> tries it out on a reasonable number of targets and then it
> later turns out that there are some problems in corner cases,
> I will not call for a public hanging.
I do agree with this -- all changes should be tested by _someone_.
However, I don't think we should categorically reject all patches that
haven't been tested by the author. If someone sees something which
looks wrong, or an opportunity for optimization, not having the board
in question shouldn't stop him from submitting a patch IMO. The board
maintainer (or cpu/arch/subsystem maintainer, depending on the code in
question) may test it himself, or send it to someone else for testing.
I disagree with your requirement that the author and the tester
_always_ has to be the same person. Having done thorough testing,
benchmarking, etc. and providing lots of nice numbers will of course
increase the chances of acceptance, but none of it is an absolute
requirement IMO.
> > Btw, I can't help but feel that you're using me as an example here,
> > since I _did_ at one point suggest that one particular patch would
> > only need compile-testing. If you are, please stop it because you're
> > misrepresenting what I said.
>
> No, I was thinking of the guys that wants to change the complete
> support for dataflash with no intention to test it on any
> board with dataflash
Ok, I don't know who you're talking about, then. Sorry for taking it
personal ;-)
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-12 18:40 ` Ulf Samuelsson
@ 2007-02-12 19:36 ` Stefan Roese
2007-02-12 19:37 ` Haavard Skinnemoen
1 sibling, 0 replies; 42+ messages in thread
From: Stefan Roese @ 2007-02-12 19:36 UTC (permalink / raw)
To: u-boot
On Monday 12 February 2007 19:40, Ulf Samuelsson wrote:
> > Yeah, that's a nice attitude. "Go away, we don't want your patches."
> > Without even looking at them?
>
> I dont want patches that stops U-boot from functioning, that is correct.
> If someone creates a patch which will improve functionality,
> tries it out on a reasonable number of targets and then it
> later turns out that there are some problems in corner cases,
> I will not call for a public hanging.
Sometimes you have to make some changes without being able to really test them
on real hardware. That's definitely nothing we like to do, but sometimes
there is no other way. Or we would keep "status quo" and I think we all agree
that we want to keep this project moving, even with more pace than in the
last months.
> > Btw, I can't help but feel that you're using me as an example here,
> > since I _did_ at one point suggest that one particular patch would
> > only need compile-testing. If you are, please stop it because you're
> > misrepresenting what I said.
>
> No, I was thinking of the guys that wants to change the complete
> support for dataflash with no intention to test it on any
> board with dataflash
That sounds a little like he (Grant) really wanted to _break_ dataflash
support intentionally. His idea was to clean up some ugly places and replace
them with something more readable and maintainable (Grant, please jump in if
I misinterpret you here). If he is unable to test the results (compile clean
is of course mandatory) then other have to "jump in" here. IIRC, he
volunteered to clean up possible bugs too.
So please don't discourage people who want to improve this project. Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
=====================================================================
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-12 15:18 ` Haavard Skinnemoen
@ 2007-02-12 18:40 ` Ulf Samuelsson
2007-02-12 19:36 ` Stefan Roese
2007-02-12 19:37 ` Haavard Skinnemoen
0 siblings, 2 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-12 18:40 UTC (permalink / raw)
To: u-boot
> On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> >> It really does not make sense to test his patches only
>> >> on boards which does not use the dataflash.
>> >
>> > If that's all he has, then he has no other choice.
>>
>> He has always the choice of realizing that he maybe should
>> leave this possible improvement to someone capable of testing it
>> and concentrate on stuff which he can test.
>
> Yeah, that's a nice attitude. "Go away, we don't want your patches."
> Without even looking at them?
I dont want patches that stops U-boot from functioning, that is correct.
If someone creates a patch which will improve functionality,
tries it out on a reasonable number of targets and then it
later turns out that there are some problems in corner cases,
I will not call for a public hanging.
> Btw, I can't help but feel that you're using me as an example here,
> since I _did_ at one point suggest that one particular patch would
> only need compile-testing. If you are, please stop it because you're
> misrepresenting what I said.
No, I was thinking of the guys that wants to change the complete
support for dataflash with no intention to test it on any
board with dataflash
>
> Haavard
>
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR link: www.avrfreaks.net
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-12 0:26 ` Ulf Samuelsson
@ 2007-02-12 15:18 ` Haavard Skinnemoen
2007-02-12 18:40 ` Ulf Samuelsson
0 siblings, 1 reply; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-12 15:18 UTC (permalink / raw)
To: u-boot
On 2/12/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> >> It really does not make sense to test his patches only
> >> on boards which does not use the dataflash.
> >
> > If that's all he has, then he has no other choice.
>
> He has always the choice of realizing that he maybe should
> leave this possible improvement to someone capable of testing it
> and concentrate on stuff which he can test.
Yeah, that's a nice attitude. "Go away, we don't want your patches."
Without even looking at them?
Btw, I can't help but feel that you're using me as an example here,
since I _did_ at one point suggest that one particular patch would
only need compile-testing. If you are, please stop it because you're
misrepresenting what I said.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 23:45 ` Wolfgang Denk
@ 2007-02-12 0:26 ` Ulf Samuelsson
2007-02-12 15:18 ` Haavard Skinnemoen
0 siblings, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-12 0:26 UTC (permalink / raw)
To: u-boot
> Dear Ulf,
>
> in message <00f201c74e25$71fdbf80$01c4af0a@Glamdring> you wrote:
>>
>> A contributor has no business changing a board file
>> if he cannot reasonably verify that this will not break a board.
>
> You are right in principle, but live is not always black and white.
>
>> > I cannot help this, and we will definitely not wait to see an ACK for
>> > each and every board that is listed in the U-Boot tree.
>>
>> No, but as mentioned above, different parts of U-Boot should require
>> the submitter to focus on different subsets of boards.
>
> It ain't that easy. Take for example this stupid ". = .;" addition to
> the linker scripts that was needed to make some versions of the
> toolchain happy - of course I add this to ALL boards without being
> able to test even half of them.
I think that is something which I could live with.
(This can be verified by building the board using MAKEALL)
Going in and writing a new UART driver and replacing the old one is not
something I could live with if they do not test this.
>
> And as mentioned before: if I have a global change to make, and I
> cannot get response from board / architecture maintainers in
> reasonable time, that change will be made globally, even if it breaks
> their boards. It's IMHO better to have a board clearly broken than
> having all boards in N different patch states.
Global changes needs to go ahead, but I already point that out.
>
>> The proposed dataflash patches in our other heated discussion
>> for instance should only be accepted once proven that it actually
>> works with dataflash memory chips.
>> The proposer seemed to be happy if the stuff compiled...
>> Since that mainly affects Atmel boards, he should make
>> sure to get Atmel boards or sign up testers for it,
>> and have it tested before even thinking about submit patches.
>
> I disagree with you. You cannot expect any maintainer or custodian or
> other person volunteering to contribute to U-Boot code (or any other
> free software project) to "get Atmel boards or sign up testers for
> it". There are board maintainers, and it is their task to help
> testing things. And yes, this includes that they will sometimes have
> to help sorting out problems created by other people. That's how it
> has been, and will remain, even if Atmel was shipping test systems
> for free.
I expect anyone that significantly modifies anything to ensure that
the submitted patch is tested on *something*.
I expect that the fact that things compiles is not considered a measure of
success
for significant code changes.
From this follows that anything which is specific to an Atmel target
and not used anywhere else cannot be tested on anything but an Atmel target.
Your changes above does not change code.
>
> Or do you intend to get a cmc_pu2 board or sign up testers for it to
> check your patches? No, it will be me who has to run the tests, right?
No, I know that this is a weak point of the argument, and that
is why I would like to avoid changing significantly the contents of the
patch.
The only change I see I do, is the bugfix in form of a type cast.
The current at45.c only exercises the internal resources
of the at91rm9200, so this fix should be enough to exercise
on any at9rm9200 board. There are board specific things
like which chip select to use etc, but all these parts are part
of other files, and not part of at45.c.
I really just change where the code is located in the source tree.
I have tested building cmc_pu2 to ensure that is not a problem.
Have also tested the patch so that non-Atmel arm targets and non-Arm targets
can build (Power PC target).
>
>> It really does not make sense to test his patches only
>> on boards which does not use the dataflash.
>
> If that's all he has, then he has no other choice.
He has always the choice of realizing that he maybe should
leave this possible improvement to someone capable of testing it
and concentrate on stuff which he can test.
>
> Best regards,
>
> Wolfgang Denk
>
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 21:39 ` Ulf Samuelsson
@ 2007-02-11 23:45 ` Wolfgang Denk
2007-02-12 0:26 ` Ulf Samuelsson
0 siblings, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2007-02-11 23:45 UTC (permalink / raw)
To: u-boot
Dear Ulf,
in message <00f201c74e25$71fdbf80$01c4af0a@Glamdring> you wrote:
>
> A contributor has no business changing a board file
> if he cannot reasonably verify that this will not break a board.
You are right in principle, but live is not always black and white.
> > I cannot help this, and we will definitely not wait to see an ACK for
> > each and every board that is listed in the U-Boot tree.
>
> No, but as mentioned above, different parts of U-Boot should require
> the submitter to focus on different subsets of boards.
It ain't that easy. Take for example this stupid ". = .;" addition to
the linker scripts that was needed to make some versions of the
toolchain happy - of course I add this to ALL boards without being
able to test even half of them.
And as mentioned before: if I have a global change to make, and I
cannot get response from board / architecture maintainers in
reasonable time, that change will be made globally, even if it breaks
their boards. It's IMHO better to have a board clearly broken than
having all boards in N different patch states.
> The proposed dataflash patches in our other heated discussion
> for instance should only be accepted once proven that it actually
> works with dataflash memory chips.
> The proposer seemed to be happy if the stuff compiled...
> Since that mainly affects Atmel boards, he should make
> sure to get Atmel boards or sign up testers for it,
> and have it tested before even thinking about submit patches.
I disagree with you. You cannot expect any maintainer or custodian or
other person volunteering to contribute to U-Boot code (or any other
free software project) to "get Atmel boards or sign up testers for
it". There are board maintainers, and it is their task to help
testing things. And yes, this includes that they will sometimes have
to help sorting out problems created by other people. That's how it
has been, and will remain, even if Atmel was shipping test systems
for free.
Or do you intend to get a cmc_pu2 board or sign up testers for it to
check your patches? No, it will be me who has to run the tests, right?
> It really does not make sense to test his patches only
> on boards which does not use the dataflash.
If that's all he has, then he has no other choice.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If the code and the comments disagree, then both are probably
wrong." - Norm Schryer
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 18:04 ` Haavard Skinnemoen
2007-02-11 19:42 ` Ulf Samuelsson
@ 2007-02-11 21:54 ` Ulf Samuelsson
1 sibling, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 21:54 UTC (permalink / raw)
To: u-boot
For people that has not looked into what the three submitted patches do:
They create the same end result as if you had done the following:
1) Fix a bug in "board/cmc_pu2/at45.c" making it a true duplicate
of ."board/at91rm9200dk/at45.c" (currently they differ in one line)
2) Move "board/at91rm9200dk/at45.c" to "drivers/at45.c"
3) Remove "board/cmc_pu2/at45.c".
4) Remove references to at45.c in the "board/xxx/Makefile"'s.
5) Ensure that the "drivers/Makefile" build "drivers/at45.c"
6) Move those parts of at45 which refer to at91rm9200 H/W
to "cpu/arm920t/at91rm9200/spi.c"
7) Ensure "cpu/arm920t/at91rm9200/Makefile" builds the spi.c
The end result is that there is no duplication left in U-boot of
either the at45.c nor the spi.c contents.
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 21:10 ` Wolfgang Denk
@ 2007-02-11 21:39 ` Ulf Samuelsson
2007-02-11 23:45 ` Wolfgang Denk
0 siblings, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 21:39 UTC (permalink / raw)
To: u-boot
> I promise that we will provide the infrastructure (git repos) for the
> custodians as fast as possible. As far as I can see, at the moment
> this affects only ARM boards, so please run this throught he ARM
> custodian then (Peter Pearse). If it's acceptable to him, and nobody
> else complains, I will accept this, too.
>
OK, acceptable
>> > 2) That people make sure that they do not destroy the U-boot
>> > support for at91 by providing untested patches.
>>
>> Well, I do agree that submitting totally untested patches is
>> unacceptable unless they are clearly marked as such. On the other
>> hand, it's also totally unreasonable to demand that people submitting
>> patches test them on boards they don't have.
>
> It's unreasonable, and impossible.
If you are working on, let's say, "common" files, then
you affect all boards, and then you should test on a reasonable subset.
If you enter and do significant modification on a file in the
board area, then I think things changes.
A contributor has no business changing a board file
if he cannot reasonably verify that this will not break a board.
The same for files in the cpu/xxx directories.
You should not be changing those without testing on boards using that CPU.
If someone spends time to thoroughly test boards and has this included
in the mainstream, then anyone changing this code should be
aware that breaking this code has a price to end users.
Splitting a driver for a peripheral into several files just because
a few subroutined can be shared has a price
to the maintainer, since this will reduce the overview of the code.
A few kB of duplication is not a high price to pay for working
U-Boot and easier maintenance.
If I look at the PowerPC/NIOS code, this is exactly how it is done.
Duplications in several areas.
>
> We have a pretty big selection of boards in our lab, but nevertheless
> I've never been able to test any change on all architectures and
> boards. And nobody else will ever do that.
>
>> If someone submits a patch that's not fully tested, we'll just have to
>> test it before it enters mainline. It's really that simple.
>
> And actually in some cases we will simply have to push it into
> mainline - in the past, there has often been very little of even zero
> feedback for patches or test branches. Some people simply don't wake
> up before their board does not compile any more in the standard tree.
> I cannot help this, and we will definitely not wait to see an ACK for
> each and every board that is listed in the U-Boot tree.
No, but as mentioned above, different parts of U-Boot should require
the submitter to focus on different subsets of boards.
The proposed dataflash patches in our other heated discussion
for instance should only be accepted once proven that it actually
works with dataflash memory chips.
The proposer seemed to be happy if the stuff compiled...
Since that mainly affects Atmel boards, he should make
sure to get Atmel boards or sign up testers for it,
and have it tested before even thinking about submit patches.
It really does not make sense to test his patches only?
on boards which does not use the dataflash.
>
>
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 20:23 ` Haavard Skinnemoen
2007-02-11 20:29 ` Ulf Samuelsson
@ 2007-02-11 21:10 ` Wolfgang Denk
2007-02-11 21:39 ` Ulf Samuelsson
1 sibling, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2007-02-11 21:10 UTC (permalink / raw)
To: u-boot
In message <1defaf580702111223v525ad814n763b80a28b7c16c8@mail.gmail.com> you wrote:
>
> > 1) that I can apply the complete patchset for the at91sam926x and have that
> > accepted before people start this activity
>
> That's up to Wolfgang I guess. I've already said that I can wait for
> the at91sam926x support to go in before I start modifying the at45
> driver.
Ulf has made it pretty clear that he thinks that I am just a show
stopper for all his efforts, and that I don't have a clue what he's
talking about. It seems I cannot help that, so I keep my mouth shut
here.
I promise that we will provide the infrastructure (git repos) for the
custodians as fast as possible. As far as I can see, at the moment
this affects only ARM boards, so please run this throught he ARM
custodian then (Peter Pearse). If it's acceptable to him, and nobody
else complains, I will accept this, too.
> > 2) That people make sure that they do not destroy the U-boot
> > support for at91 by providing untested patches.
>
> Well, I do agree that submitting totally untested patches is
> unacceptable unless they are clearly marked as such. On the other
> hand, it's also totally unreasonable to demand that people submitting
> patches test them on boards they don't have.
It's unreasonable, and impossible.
We have a pretty big selection of boards in our lab, but nevertheless
I've never been able to test any change on all architectures and
boards. And nobody else will ever do that.
> If someone submits a patch that's not fully tested, we'll just have to
> test it before it enters mainline. It's really that simple.
And actually in some cases we will simply have to push it into
mainline - in the past, there has often been very little of even zero
feedback for patches or test branches. Some people simply don't wake
up before their board does not compile any more in the standard tree.
I cannot help this, and we will definitely not wait to see an ACK for
each and every board that is listed in the U-Boot tree.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conceptual integrity in turn dictates that the design must proceed
from one mind, or from a very small number of agreeing resonant
minds. - Frederick Brooks Jr., "The Mythical Man Month"
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 20:29 ` Ulf Samuelsson
@ 2007-02-11 20:54 ` Haavard Skinnemoen
0 siblings, 0 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-11 20:54 UTC (permalink / raw)
To: u-boot
On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> >> Requesting me to modify the *contents* of a duplicated file because
> >> I want to have a single file I consider as an unreasonable request.
> >
> > I agree, but I don't recall anyone ever suggesting that (except that
> > my initial proposal did schedule some changes before the at91sam926x
> > board patches, but I also said that I was perfectly fine with doing
> > them later.)
> >
>
> No, Wolfgang implied that I could not move/split a file
> unless I promised to "clean" it up.
Oh, yes, I do recall that. But he did say "later", and that's what I'm
offering to do.
> I think we have basic agreement and we now should await
> the U-Boot maintainers reaction.
Agreed
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 20:23 ` Haavard Skinnemoen
@ 2007-02-11 20:29 ` Ulf Samuelsson
2007-02-11 20:54 ` Haavard Skinnemoen
2007-02-11 21:10 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 20:29 UTC (permalink / raw)
To: u-boot
> On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> Requesting me to modify the *contents* of a duplicated file because
>> I want to have a single file I consider as an unreasonable request.
>
> I agree, but I don't recall anyone ever suggesting that (except that
> my initial proposal did schedule some changes before the at91sam926x
> board patches, but I also said that I was perfectly fine with doing
> them later.)
>
No, Wolfgang implied that I could not move/split a file
unless I promised to "clean" it up.
I think we have basic agreement and we now should await
the U-Boot maintainers reaction.
/Ulf
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 19:42 ` Ulf Samuelsson
@ 2007-02-11 20:23 ` Haavard Skinnemoen
2007-02-11 20:29 ` Ulf Samuelsson
2007-02-11 21:10 ` Wolfgang Denk
0 siblings, 2 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-11 20:23 UTC (permalink / raw)
To: u-boot
On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> Requesting me to modify the *contents* of a duplicated file because
> I want to have a single file I consider as an unreasonable request.
I agree, but I don't recall anyone ever suggesting that (except that
my initial proposal did schedule some changes before the at91sam926x
board patches, but I also said that I was perfectly fine with doing
them later.)
> > Of course, Atmel needs to do testing as well, and it will probably
> > make sense to offer special "Atmel blessed" versions of u-boot which
> > have been tested thoroughly on all supported configurations for the
> > customers that need this. But we can't say that nobody is allowed to
> > make any changes to the official driver because it has been tested and
> > we don't want to do it again.
>
> No, but I am only asking for two things:
>
> 1) that I can apply the complete patchset for the at91sam926x and have that
> accepted before people start this activity
That's up to Wolfgang I guess. I've already said that I can wait for
the at91sam926x support to go in before I start modifying the at45
driver.
> 2) That people make sure that they do not destroy the U-boot
> support for at91 by providing untested patches.
Well, I do agree that submitting totally untested patches is
unacceptable unless they are clearly marked as such. On the other
hand, it's also totally unreasonable to demand that people submitting
patches test them on boards they don't have.
If someone submits a patch that's not fully tested, we'll just have to
test it before it enters mainline. It's really that simple.
> > I don't know what you're getting at here, but yes, in order to review
> > a patch, you _do_ need to study it and give an unbiased opinion. But
> > it works the other way around too -- if you want review, you _have_ to
> > be willing to make changes based on that review.
>
> Yes, I am prepared to put the spi part and the at45 support
> parts of at45.c in any suggested directory.
> That is a reasonable thing to ask for.
>
> To ask me to modify the *contents* of at45.c
> just because I want to remove duplication is out of line, IMHO.
> I dont say it is a bad thing, just that it should be done
> after the patchset is applied, and then by a group willing to maintain
> and test the code.
>
> If I am not allowed to remove the duplication, then there is no possibility
> to have a common at45.c and I will be forced to modify the
> drivers/at45.c in the at91sam926x patchset to be located
>
> board/at91sam9260ek/at45.c
> board/at91sam9261ek/at45.c
> board/at91sam9260ek/at45.c
>
> so we will have 5 at45.c instead of 1.
> I doubt that patch is going to be accepted.
You keep repeating this as if anyone actually disagreed with you that
we want a single unified at45 driver. Or that we should only start
changing it _after_ it's been consolidated.
And yes, I happen to be part of a group willing to maintain and test
the code. Not on every single board out there, but if we can manage to
find a tester for at least one RM board and one SAM board, I think
we'll be pretty well covered.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 18:04 ` Haavard Skinnemoen
@ 2007-02-11 19:42 ` Ulf Samuelsson
2007-02-11 20:23 ` Haavard Skinnemoen
2007-02-11 21:54 ` Ulf Samuelsson
1 sibling, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 19:42 UTC (permalink / raw)
To: u-boot
> On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> 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.
>
> Ok, I think there's some misunderstanding going on here. I didn't mean
> to say that the spi driver _must_ be made common for all chips _now_.
> Please disregard my suggestions about a common spi driver for now.
> Let's get this stuff moving.
>
>> I do not understand who will be responsible for maintaining
>> the spi support for at91 chips if it is rewritten.
>
> I'm responsible for the atmel_spi driver in the Linux kernel which is
> on its way into mainstream hopefully any day now (it's been accepted
> by the SPI maintainer.) This driver supports AT91RM9200, AT91SAM926x
> and AT32AP7000, so I don't see why I can't be responsible for the
> u-boot driver as well if nobody else are going to step up.
>
> But let's do it your way for now and move the SPI parts of the
> dataflash driver to the CPU directory. We can always change it later,
> when support for all boards are in place and it becomes clearer which
> parts are shareable and which parts are not.
>
This is exactly how I want to proceed.
There are a number of patches that needs to be sent
in order to have at91sam926x support.
I would like to submit them, have everything working.
There are changes which I consider reasonable to request.
There are also changes which I consider unreasonable to request.
Requesting me to modify the *contents* of a duplicated file because
I want to have a single file I consider as an unreasonable request.
>> 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.
>
> Hmm...that sounds somehow familiar :-P
>
> Hopefully, the new custodian model will improve this.
>
>> 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.
>
> U-boot is a community effort. We depend on an active community to test
> non-trivial changes. Michel has already volunteered, that's exactly
> what we need.
Yes and we need to have people preparing to test
* SAM9261
* SAM9263
* AT91RM9200DK
* AT91RM9200EK
* AT91RM9200DF
* CMC_PU2
as well.
>
> We can't depend _only_ on the AT91 group to make sure that dataflash
> will work on all boards using it, nor can we depend _only_ on the
> AVR32 group. As far as I know, none of us are testing any of this on
> Blackfin, for example.
>
The blackfin support is not in the main tree as far as I could tell.
It is available on a proprietary home page.
> Of course, Atmel needs to do testing as well, and it will probably
> make sense to offer special "Atmel blessed" versions of u-boot which
> have been tested thoroughly on all supported configurations for the
> customers that need this. But we can't say that nobody is allowed to
> make any changes to the official driver because it has been tested and
> we don't want to do it again.
No, but I am only asking for two things:
1) that I can apply the complete patchset for the at91sam926x and have that
accepted before people start this activity
2) That people make sure that they do not destroy the U-boot
support for at91 by providing untested patches.
> Any changes Atmel does based on such testing should of course be
> submitted for inclusion upstream. But for this to work, we do need a
> timely response from the upstream maintainers.
>
>> >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.
>
> I don't know what you're getting at here, but yes, in order to review
> a patch, you _do_ need to study it and give an unbiased opinion. But
> it works the other way around too -- if you want review, you _have_ to
> be willing to make changes based on that review.
Yes, I am prepared to put the spi part and the at45 support
parts of at45.c in any suggested directory.
That is a reasonable thing to ask for.
To ask me to modify the *contents* of at45.c
just because I want to remove duplication is out of line, IMHO.
I dont say it is a bad thing, just that it should be done
after the patchset is applied, and then by a group willing to maintain
and test the code.
If I am not allowed to remove the duplication, then there is no possibility
to have a common at45.c and I will be forced to modify the
drivers/at45.c in the at91sam926x patchset to be located
board/at91sam9260ek/at45.c
board/at91sam9261ek/at45.c
board/at91sam9260ek/at45.c
so we will have 5 at45.c instead of 1.
I doubt that patch is going to be accepted.
>
> Haavard
>
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 16:43 ` Ulf Samuelsson
@ 2007-02-11 18:04 ` Haavard Skinnemoen
2007-02-11 19:42 ` Ulf Samuelsson
2007-02-11 21:54 ` Ulf Samuelsson
0 siblings, 2 replies; 42+ messages in thread
From: Haavard Skinnemoen @ 2007-02-11 18:04 UTC (permalink / raw)
To: u-boot
On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> 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.
Ok, I think there's some misunderstanding going on here. I didn't mean
to say that the spi driver _must_ be made common for all chips _now_.
Please disregard my suggestions about a common spi driver for now.
Let's get this stuff moving.
> I do not understand who will be responsible for maintaining
> the spi support for at91 chips if it is rewritten.
I'm responsible for the atmel_spi driver in the Linux kernel which is
on its way into mainstream hopefully any day now (it's been accepted
by the SPI maintainer.) This driver supports AT91RM9200, AT91SAM926x
and AT32AP7000, so I don't see why I can't be responsible for the
u-boot driver as well if nobody else are going to step up.
But let's do it your way for now and move the SPI parts of the
dataflash driver to the CPU directory. We can always change it later,
when support for all boards are in place and it becomes clearer which
parts are shareable and which parts are not.
> 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.
Hmm...that sounds somehow familiar :-P
Hopefully, the new custodian model will improve this.
> 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.
U-boot is a community effort. We depend on an active community to test
non-trivial changes. Michel has already volunteered, that's exactly
what we need.
We can't depend _only_ on the AT91 group to make sure that dataflash
will work on all boards using it, nor can we depend _only_ on the
AVR32 group. As far as I know, none of us are testing any of this on
Blackfin, for example.
Of course, Atmel needs to do testing as well, and it will probably
make sense to offer special "Atmel blessed" versions of u-boot which
have been tested thoroughly on all supported configurations for the
customers that need this. But we can't say that nobody is allowed to
make any changes to the official driver because it has been tested and
we don't want to do it again.
Any changes Atmel does based on such testing should of course be
submitted for inclusion upstream. But for this to work, we do need a
timely response from the upstream maintainers.
> >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.
I don't know what you're getting at here, but yes, in order to review
a patch, you _do_ need to study it and give an unbiased opinion. But
it works the other way around too -- if you want review, you _have_ to
be willing to make changes based on that review.
Haavard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-10 20:31 ` Ivan Kuten
@ 2007-02-11 16:43 ` Ulf Samuelsson
2007-02-11 18:04 ` Haavard Skinnemoen
0 siblings, 1 reply; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 16:43 UTC (permalink / raw)
To: u-boot
>>>
>>> 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
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
2007-02-11 11:49 Michel Benoit
@ 2007-02-11 16:20 ` Ulf Samuelsson
0 siblings, 0 replies; 42+ messages in thread
From: Ulf Samuelsson @ 2007-02-11 16:20 UTC (permalink / raw)
To: u-boot
link: www.avrfreaks.net
----- Original Message -----
From: "Michel Benoit" <murpme@gmail.com>
To: <u-boot-users@lists.sourceforge.net>
Sent: Sunday, February 11, 2007 12:49 PM
Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
> Hello.
>
> As a current user of Atmel's AT91SAM9260, I encourage the effort to
> get at91sam926x
> inserted into the main u-boot branch. I'm willing help test u-boot on
> the at91sam9260ek board.
>
> Michel
I expect that we should have it merged somewhere late this century
since even after 50-100 emails there is no agreement how to
take two almost identical files and merge into one and then split
the single file into a cpu dependent and a cpu independent file.
Best Regards
Ulf Samuelsson
> On 2/10/07, u-boot-users-request at lists.sourceforge.net
> <u-boot-users-request@lists.sourceforge.net> wrote:
>> Send U-Boot-Users mailing list submissions to
>> u-boot-users at lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>> or, via email, send a message with subject or body 'help' to
>> u-boot-users-request at lists.sourceforge.net
>>
>> You can reach the person managing the list at
>> u-boot-users-owner at lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of U-Boot-Users digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: BDI2000 config for MPC8360rev2 with DDR2 memory?
>> (Medve Emilian-EMMEDVE1)
>> 2. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
>> 3. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
>> 4. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
>> 5. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
>> 6. 1 digital camera manufacturer. (Goldberg Rachel)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 9 Feb 2007 15:22:55 -0700
>> From: "Medve Emilian-EMMEDVE1" <Emilian.Medve@freescale.com>
>> Subject: Re: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2
>> memory?
>> To: <u-boot-users@lists.sourceforge.net>
>> Message-ID:
>>
>> <598D5675D34BE349929AF5EDE9B03E27C181C6@az33exm24.fsl.freescale.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Steve,
>>
>>
>> You could get the configuration files from Abatron
>> (ftp://83.125.32.26/bdigdb/config/powerpc/mpc83xx/). That should be
>> enough to just flash the board.
>>
>>
>> Cheers,
>> Emil.
>>
>>
>> This e-mail, and any associated attachments have been classified as:
>> ====================================================================
>> [x] Public
>> [ ] Freescale Semiconductor Internal Use Only
>> [ ] Freescale Semiconductor Confidential Proprietary
>>
>>
>> -----Original Message-----
>> From: u-boot-users-bounces at lists.sourceforge.net
>> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Steven
>> Hein
>> Sent: Friday, February 09, 2007 4:06 PM
>> To: u-boot-users at lists.sourceforge.net
>> Subject: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory?
>>
>> Hi all--
>>
>> I just received a new custom board with an MPC8360r2 with 128MB DDR2
>> memory on the board. My 8360EMDS board has a rev 1.2 part with DDR,
>> so I know I need a different set of init registers in my BDI2000 config.
>> If anyone has a similar config and could send me a BDI2000 config file
>> for it, that would be AWESOME! In the mean time, I'm trying to
>> flash u-boot directly into my flash part using the BDI2000 and let it
>> initialize my memory for me. But this is all fairly uncharted
>> territory for me, so a BDI config would be helpful.
>>
>> Thanks!
>> Steve
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software
>> Silicon Graphics, Inc.
>> 1168 Industrial Blvd. Phone: (715) 726-8410
>> Chippewa Falls, WI 54729 Fax: (715) 726-6715
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> ------------------------------------------------------------------------
>> -
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 9 Feb 2007 23:58:16 +0100
>> From: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
>> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
>> To: "Ulf Samuelsson" <ulf@atmel.com>
>> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
>> Haavard Skinnemoen <hskinnemoen@atmel.com>
>> Message-ID:
>> <1defaf580702091458p564ba747qc235ebe3601df497@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2/9/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> > > 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.
>>
>> It's somewhat cpu- and board-independent. at32 and at91 are based on
>> two different architectures, so they don't have any directories in
>> common apart from the ones common to everyone.
>>
>> We could perhaps create a drivers/atmel subdirectory or, as Ulf
>> suggests, boards/atmel/drivers or cpu/atmel/drivers.
>>
>> > 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...
>>
>> Hmm...how about moving the cpu-dependent bits into inline functions
>> somewhere under asm/arch? For example
>>
>> static inline void portmux_enable_spi(unsigned int id)
>> {
>> /* do chip-dependent PIO stuff here */
>> }
>>
>> asm/arch is chip-specific so there shouldn't be any need for #ifdefs
>> there.
>>
>> > 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
>>
>> Yeah, that's why the AT91 prefixing should be dropped. But that's for
>> much later.
>>
>> Btw, looks like there's another SPI API in u-boot as well. Probably a
>> good idea to convert the at91/atmel spi stuff over to implementing
>> that one. No point in having several APIs doing the same thing, and
>> the other API uses the much more sensible function name spi_xfer for
>> doing SPI transfers, as opposed to AT91F_SpiWrite which is totally
>> misleading since it's being used for reading as well.
>>
>> > If you let it remain in the board directories as is, then
>> > you duplicate this for each board.
>>
>> I don't think anyone wants that. Although you're the one suggesting we
>> add a _third_ identical driver ;-)
>>
>> > 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.
>>
>> Are any other drivers organized this way?
>>
>> > I do not think it belongs inside the drivers directory.
>>
>> I'm sorry but I fail to see why not. There are several other
>> platform-specific drivers in there. And I don't really see the big
>> advantage of spreading drivers around all over the place...
>>
>> > 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.
>>
>> Yeah, but if it's protected by an easy-to-understand #ifdef that
>> shouldn't be a problem. Although I don't think we should call it spi.c
>> then. It should be atmel_spi.c or something.
>>
>> > The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.
>>
>> Or do it in a chip-specific header file.
>>
>> > I still would like to have the complete sam926x patch set
>> > implemented before we start to "play" with it
>>
>> Yeah, but I still think some preparatory patches are a good thing in
>> order to make things easier later on.
>>
>> Haavard
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 10 Feb 2007 00:20:21 +0100
>> From: "Ulf Samuelsson" <ulf@atmel.com>
>> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
>> To: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
>> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
>> Haavard Skinnemoen <hskinnemoen@atmel.com>
>> Message-ID: <012b01c74ca1$8ee35fe0$01c4af0a@Glamdring>
>> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>> reply-type=response
>>
>>
>> >> I still would like to have the complete sam926x patch set
>> >> implemented before we start to "play" with it
>> >
>> > Yeah, but I still think some preparatory patches are a good thing in
>> > order to make things easier later on.
>>
>> I only see two things as a result of those prepatory patches.
>>
>> 1) Bugs
>> 2) Delays in availability
>>
>> I am not questioning anything you want to do, just the timing.
>> If we follow your recommendation you will have a bunch
>> of untested board patches in the mainstream u-boot,
>> for the sam926x.
>>
>> I do not have the time to thoroughly test any changes
>> you do (I dont even have an at91sam9263 board).
>>
>> If we go my way, then we should be able to have *tested* sam926x
>> support inside U-boot very soon, and while this results
>> in duplication of a small part of the spi code on the source level
>> (no addition to the binary) I believe that
>> the benefit to the community of at91sam926x users
>> of having native support in U-Boot outweighs this duplication a lot.
>>
>> The number of users far outweisghs the number of implementers
>> and I think that we need to look at it from their point of view.
>>
>> We are not introducing any new interfaces here,
>> just using the existing interfaces.
>> This means that it will not be harder to do any modifications
>> *after* the sam926x patches are applied.
>> It will be easier since you have better overview.
>>
>> The only alternative I can see is that you take over
>> the responsibility for both AVR32 and AT91 U-boot
>> and test all modifications on all boards before submission
>> - Still with availability of working solution as the highest priority.
>>
>>
>> >
>> > Haavard
>>
>>
>> Best Regards
>> Ulf Samuelsson
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 10 Feb 2007 00:42:27 +0100
>> From: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
>> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
>> To: "Ulf Samuelsson" <ulf@atmel.com>
>> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
>> Haavard Skinnemoen <hskinnemoen@atmel.com>
>> Message-ID:
>> <1defaf580702091542m19034fddu9e1d3eb4fccf0d64@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> > The number of users far outweisghs the number of implementers
>> > and I think that we need to look at it from their point of view.
>>
>> Would help a lot to have some of those users help with testing though.
>>
>> > We are not introducing any new interfaces here,
>> > just using the existing interfaces.
>> > This means that it will not be harder to do any modifications
>> > *after* the sam926x patches are applied.
>> > It will be easier since you have better overview.
>>
>> Whatever. Please let me know when you're ready to continue.
>>
>> > The only alternative I can see is that you take over
>> > the responsibility for both AVR32 and AT91 U-boot
>> > and test all modifications on all boards before submission
>> > - Still with availability of working solution as the highest priority.
>>
>> I don't think that's going to happen. Besides, having the same person
>> implement and test the code usually doesn't work very well anyway, so
>> if we're going to do this we need people willing to test
>> probably-working-but-still-experimental stuff.
>>
>> I'm of course not saying that I can't be bothered to test my
>> modifications before submitting, but relying on me to implement _and_
>> test everything on all configurations is just insane.
>>
>> Haavard
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sat, 10 Feb 2007 01:10:55 +0100
>> From: "Ulf Samuelsson" <ulf@atmel.com>
>> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
>> To: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
>> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
>> Haavard Skinnemoen <hskinnemoen@atmel.com>
>> Message-ID: <014701c74ca8$920caf30$01c4af0a@Glamdring>
>> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>> reply-type=original
>>
>> > On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> >> The number of users far outweisghs the number of implementers
>> >> and I think that we need to look at it from their point of view.
>> >
>> > Would help a lot to have some of those users help with testing though.
>> >
>> >> We are not introducing any new interfaces here,
>> >> just using the existing interfaces.
>> >> This means that it will not be harder to do any modifications
>> >> *after* the sam926x patches are applied.
>> >> It will be easier since you have better overview.
>> >
>> > Whatever. Please let me know when you're ready to continue.
>> >
>>
>> I am ready to continue as soon as at45_split is applied.
>> It is a real simple patch, it divides one more or less duplicated file
>> into
>> two files.
>>
>> If I try to apply any sam926x patches without that,
>> then It will crash the at91rm9200dk and cmc_pu2 board support.
>>
>> Once this patch is applied, I can submit the at91sam926x patches
>> and if/when they are accepted, then we have accomplished the most
>> important goal to Atmel customers,
>> which is that *tested* sam926x support is available from the primary
>> U-Boot location and that you can build both at91 and avr32
>> from the same source code.
>>
>> I consider all other activities secondary.
>>
>> Best Regards
>> Ulf Samuelsson ulf at atmel.com
>> Atmel Nordic AB
>> Mail: Box 2033, 174 02 Sundbyberg, Sweden
>> Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
>> Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
>> GSM +46 (706) 22 44 57
>>
>> Technical support when I am not available:
>> AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
>> AT90 AVR Applications Group: mailto:avr at atmel.com
>> AT91 ARM Applications Group: mailto:at91support at atmel.com
>> FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Sat, 10 Feb 2007 02:27:15 +0200
>> From: Goldberg Rachel <krihl@canpub.fr>
>> Subject: [U-Boot-Users] 1 digital camera manufacturer.
>> To: u-boot-users at lists.sourceforge.net
>> Message-ID: <45CD1163.1090109@canpub.fr>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> An HTML attachment was scrubbed...
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: logbook.gif
>> Type: image/gif
>> Size: 13741 bytes
>> Desc: not available
>>
>> ------------------------------
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>
>> ------------------------------
>>
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
>>
>> End of U-Boot-Users Digest, Vol 9, Issue 22
>> *******************************************
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
@ 2007-02-11 11:49 Michel Benoit
2007-02-11 16:20 ` Ulf Samuelsson
0 siblings, 1 reply; 42+ messages in thread
From: Michel Benoit @ 2007-02-11 11:49 UTC (permalink / raw)
To: u-boot
Hello.
As a current user of Atmel's AT91SAM9260, I encourage the effort to
get at91sam926x
inserted into the main u-boot branch. I'm willing help test u-boot on
the at91sam9260ek board.
Michel
On 2/10/07, u-boot-users-request at lists.sourceforge.net
<u-boot-users-request@lists.sourceforge.net> wrote:
> Send U-Boot-Users mailing list submissions to
> u-boot-users at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> or, via email, send a message with subject or body 'help' to
> u-boot-users-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> u-boot-users-owner at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of U-Boot-Users digest..."
>
>
> Today's Topics:
>
> 1. Re: BDI2000 config for MPC8360rev2 with DDR2 memory?
> (Medve Emilian-EMMEDVE1)
> 2. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
> 3. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
> 4. Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
> 5. Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
> 6. 1 digital camera manufacturer. (Goldberg Rachel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 9 Feb 2007 15:22:55 -0700
> From: "Medve Emilian-EMMEDVE1" <Emilian.Medve@freescale.com>
> Subject: Re: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2
> memory?
> To: <u-boot-users@lists.sourceforge.net>
> Message-ID:
> <598D5675D34BE349929AF5EDE9B03E27C181C6@az33exm24.fsl.freescale.net>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Steve,
>
>
> You could get the configuration files from Abatron
> (ftp://83.125.32.26/bdigdb/config/powerpc/mpc83xx/). That should be
> enough to just flash the board.
>
>
> Cheers,
> Emil.
>
>
> This e-mail, and any associated attachments have been classified as:
> ====================================================================
> [x] Public
> [ ] Freescale Semiconductor Internal Use Only
> [ ] Freescale Semiconductor Confidential Proprietary
>
>
> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Steven
> Hein
> Sent: Friday, February 09, 2007 4:06 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory?
>
> Hi all--
>
> I just received a new custom board with an MPC8360r2 with 128MB DDR2
> memory on the board. My 8360EMDS board has a rev 1.2 part with DDR,
> so I know I need a different set of init registers in my BDI2000 config.
> If anyone has a similar config and could send me a BDI2000 config file
> for it, that would be AWESOME! In the mean time, I'm trying to
> flash u-boot directly into my flash part using the BDI2000 and let it
> initialize my memory for me. But this is all fairly uncharted
> territory for me, so a BDI config would be helpful.
>
> Thanks!
> Steve
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software
> Silicon Graphics, Inc.
> 1168 Industrial Blvd. Phone: (715) 726-8410
> Chippewa Falls, WI 54729 Fax: (715) 726-6715
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> ------------------------------------------------------------------------
> -
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 9 Feb 2007 23:58:16 +0100
> From: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
> To: "Ulf Samuelsson" <ulf@atmel.com>
> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
> Haavard Skinnemoen <hskinnemoen@atmel.com>
> Message-ID:
> <1defaf580702091458p564ba747qc235ebe3601df497@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/9/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > > 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.
>
> It's somewhat cpu- and board-independent. at32 and at91 are based on
> two different architectures, so they don't have any directories in
> common apart from the ones common to everyone.
>
> We could perhaps create a drivers/atmel subdirectory or, as Ulf
> suggests, boards/atmel/drivers or cpu/atmel/drivers.
>
> > 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...
>
> Hmm...how about moving the cpu-dependent bits into inline functions
> somewhere under asm/arch? For example
>
> static inline void portmux_enable_spi(unsigned int id)
> {
> /* do chip-dependent PIO stuff here */
> }
>
> asm/arch is chip-specific so there shouldn't be any need for #ifdefs there.
>
> > 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
>
> Yeah, that's why the AT91 prefixing should be dropped. But that's for
> much later.
>
> Btw, looks like there's another SPI API in u-boot as well. Probably a
> good idea to convert the at91/atmel spi stuff over to implementing
> that one. No point in having several APIs doing the same thing, and
> the other API uses the much more sensible function name spi_xfer for
> doing SPI transfers, as opposed to AT91F_SpiWrite which is totally
> misleading since it's being used for reading as well.
>
> > If you let it remain in the board directories as is, then
> > you duplicate this for each board.
>
> I don't think anyone wants that. Although you're the one suggesting we
> add a _third_ identical driver ;-)
>
> > 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.
>
> Are any other drivers organized this way?
>
> > I do not think it belongs inside the drivers directory.
>
> I'm sorry but I fail to see why not. There are several other
> platform-specific drivers in there. And I don't really see the big
> advantage of spreading drivers around all over the place...
>
> > 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.
>
> Yeah, but if it's protected by an easy-to-understand #ifdef that
> shouldn't be a problem. Although I don't think we should call it spi.c
> then. It should be atmel_spi.c or something.
>
> > The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.
>
> Or do it in a chip-specific header file.
>
> > I still would like to have the complete sam926x patch set
> > implemented before we start to "play" with it
>
> Yeah, but I still think some preparatory patches are a good thing in
> order to make things easier later on.
>
> Haavard
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 10 Feb 2007 00:20:21 +0100
> From: "Ulf Samuelsson" <ulf@atmel.com>
> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
> To: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
> Haavard Skinnemoen <hskinnemoen@atmel.com>
> Message-ID: <012b01c74ca1$8ee35fe0$01c4af0a@Glamdring>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=response
>
>
> >> I still would like to have the complete sam926x patch set
> >> implemented before we start to "play" with it
> >
> > Yeah, but I still think some preparatory patches are a good thing in
> > order to make things easier later on.
>
> I only see two things as a result of those prepatory patches.
>
> 1) Bugs
> 2) Delays in availability
>
> I am not questioning anything you want to do, just the timing.
> If we follow your recommendation you will have a bunch
> of untested board patches in the mainstream u-boot,
> for the sam926x.
>
> I do not have the time to thoroughly test any changes
> you do (I dont even have an at91sam9263 board).
>
> If we go my way, then we should be able to have *tested* sam926x
> support inside U-boot very soon, and while this results
> in duplication of a small part of the spi code on the source level
> (no addition to the binary) I believe that
> the benefit to the community of at91sam926x users
> of having native support in U-Boot outweighs this duplication a lot.
>
> The number of users far outweisghs the number of implementers
> and I think that we need to look at it from their point of view.
>
> We are not introducing any new interfaces here,
> just using the existing interfaces.
> This means that it will not be harder to do any modifications
> *after* the sam926x patches are applied.
> It will be easier since you have better overview.
>
> The only alternative I can see is that you take over
> the responsibility for both AVR32 and AT91 U-boot
> and test all modifications on all boards before submission
> - Still with availability of working solution as the highest priority.
>
>
> >
> > Haavard
>
>
> Best Regards
> Ulf Samuelsson
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 10 Feb 2007 00:42:27 +0100
> From: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
> To: "Ulf Samuelsson" <ulf@atmel.com>
> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
> Haavard Skinnemoen <hskinnemoen@atmel.com>
> Message-ID:
> <1defaf580702091542m19034fddu9e1d3eb4fccf0d64@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > The number of users far outweisghs the number of implementers
> > and I think that we need to look at it from their point of view.
>
> Would help a lot to have some of those users help with testing though.
>
> > We are not introducing any new interfaces here,
> > just using the existing interfaces.
> > This means that it will not be harder to do any modifications
> > *after* the sam926x patches are applied.
> > It will be easier since you have better overview.
>
> Whatever. Please let me know when you're ready to continue.
>
> > The only alternative I can see is that you take over
> > the responsibility for both AVR32 and AT91 U-boot
> > and test all modifications on all boards before submission
> > - Still with availability of working solution as the highest priority.
>
> I don't think that's going to happen. Besides, having the same person
> implement and test the code usually doesn't work very well anyway, so
> if we're going to do this we need people willing to test
> probably-working-but-still-experimental stuff.
>
> I'm of course not saying that I can't be bothered to test my
> modifications before submitting, but relying on me to implement _and_
> test everything on all configurations is just insane.
>
> Haavard
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 10 Feb 2007 01:10:55 +0100
> From: "Ulf Samuelsson" <ulf@atmel.com>
> Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
> To: "Haavard Skinnemoen" <hskinnemoen@gmail.com>
> Cc: u-boot-users at lists.sourceforge.net, Wolfgang Denk <wd@denx.de>,
> Haavard Skinnemoen <hskinnemoen@atmel.com>
> Message-ID: <014701c74ca8$920caf30$01c4af0a@Glamdring>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> > On 2/10/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> >> The number of users far outweisghs the number of implementers
> >> and I think that we need to look at it from their point of view.
> >
> > Would help a lot to have some of those users help with testing though.
> >
> >> We are not introducing any new interfaces here,
> >> just using the existing interfaces.
> >> This means that it will not be harder to do any modifications
> >> *after* the sam926x patches are applied.
> >> It will be easier since you have better overview.
> >
> > Whatever. Please let me know when you're ready to continue.
> >
>
> I am ready to continue as soon as at45_split is applied.
> It is a real simple patch, it divides one more or less duplicated file into
> two files.
>
> If I try to apply any sam926x patches without that,
> then It will crash the at91rm9200dk and cmc_pu2 board support.
>
> Once this patch is applied, I can submit the at91sam926x patches
> and if/when they are accepted, then we have accomplished the most
> important goal to Atmel customers,
> which is that *tested* sam926x support is available from the primary
> U-Boot location and that you can build both at91 and avr32
> from the same source code.
>
> I consider all other activities secondary.
>
> Best Regards
> Ulf Samuelsson ulf at atmel.com
> Atmel Nordic AB
> Mail: Box 2033, 174 02 Sundbyberg, Sweden
> Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
> Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
> GSM +46 (706) 22 44 57
>
> Technical support when I am not available:
> AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
> AT90 AVR Applications Group: mailto:avr at atmel.com
> AT91 ARM Applications Group: mailto:at91support at atmel.com
> FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 10 Feb 2007 02:27:15 +0200
> From: Goldberg Rachel <krihl@canpub.fr>
> Subject: [U-Boot-Users] 1 digital camera manufacturer.
> To: u-boot-users at lists.sourceforge.net
> Message-ID: <45CD1163.1090109@canpub.fr>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: logbook.gif
> Type: image/gif
> Size: 13741 bytes
> Desc: not available
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> ------------------------------
>
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
> End of U-Boot-Users Digest, Vol 9, Issue 22
> *******************************************
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
[not found] <mailman.12584.1171099992.16820.u-boot-users@lists.sourceforge.net>
@ 2007-02-10 20:31 ` Ivan Kuten
2007-02-11 16:43 ` Ulf Samuelsson
0 siblings, 1 reply; 42+ messages in thread
From: Ivan Kuten @ 2007-02-10 20:31 UTC (permalink / raw)
To: u-boot
>>
>> 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.
Best regards, Ivan
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot-Users] AT91 NAND om AT91SAM9260EK
[not found] <mailman.5069.1170973304.16820.u-boot-users@lists.sourceforge.net>
@ 2007-02-08 22:57 ` Ivan Kuten
0 siblings, 0 replies; 42+ messages in thread
From: Ivan Kuten @ 2007-02-08 22:57 UTC (permalink / raw)
To: u-boot
>
> I tried to start the process of merging with mainstream U-boot
> by sending in a patch which split the at45.c located in
> board/at91rm9200dk into
> * drivers/at45.c
> * cpu/arm920t/at91rm9200/spi.c
> but I have no feedback.
>
> Peter Pearse which will be responsible for maintaining the ARM part
> is not up to speed yet, and noone else seems to be interested.
>
> There has been a discussion about how dataflash should be supported
> but the things people do not like are not in this file, they
> are in the "board/dataflash.c" file so I have no clue
> why nothing is happening.
>
Hi Ulf,
It's a good decision to move board/at91rm9200dk/at45.c into drivers/at45.c
cause our custom RM9200 board uses at45.c too.
We have dataflash only setup without NOR.
Also may be as suggestion to make AT91C_SPI_PCS3_DATAFLASH_CARD
#ifdefed because some boards such as ours may not use CS3 at all.
Best regards, Ivan
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2007-02-12 20:05 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <c88e466f0702050752t16c18251gcddf40a7ec95469@mail.gmail.com>
2007-02-07 23:17 ` [U-Boot-Users] AT91 NAND om AT91SAM9260EK Ulf Samuelsson
2007-02-08 6:06 ` Stefan Roese
2007-02-08 8:34 ` Michel Benoit
2007-02-08 19:25 ` Ulf Samuelsson
2007-02-08 20:58 ` Haavard Skinnemoen
2007-02-08 22:20 ` Ulf Samuelsson
2007-02-09 15:45 ` Haavard Skinnemoen
2007-02-09 19:11 ` Ulf Samuelsson
2007-02-09 19:54 ` Haavard Skinnemoen
2007-02-09 19:39 ` Wolfgang Denk
2007-02-09 22:18 ` Ulf Samuelsson
2007-02-09 22:58 ` Haavard Skinnemoen
2007-02-09 23:20 ` Ulf Samuelsson
2007-02-09 23:42 ` Haavard Skinnemoen
2007-02-10 0:10 ` Ulf Samuelsson
2007-02-10 1:18 ` Wolfgang Denk
2007-02-10 9:05 ` Ulf Samuelsson
2007-02-10 7:23 ` Stefan Roese
2007-02-10 1:15 ` Wolfgang Denk
2007-02-10 7:32 ` Stefan Roese
2007-02-10 9:29 ` Ulf Samuelsson
2007-02-10 1:53 ` Ken Watson
[not found] <mailman.5069.1170973304.16820.u-boot-users@lists.sourceforge.net>
2007-02-08 22:57 ` Ivan Kuten
[not found] <mailman.12584.1171099992.16820.u-boot-users@lists.sourceforge.net>
2007-02-10 20:31 ` Ivan Kuten
2007-02-11 16:43 ` Ulf Samuelsson
2007-02-11 18:04 ` Haavard Skinnemoen
2007-02-11 19:42 ` Ulf Samuelsson
2007-02-11 20:23 ` Haavard Skinnemoen
2007-02-11 20:29 ` Ulf Samuelsson
2007-02-11 20:54 ` Haavard Skinnemoen
2007-02-11 21:10 ` Wolfgang Denk
2007-02-11 21:39 ` Ulf Samuelsson
2007-02-11 23:45 ` Wolfgang Denk
2007-02-12 0:26 ` Ulf Samuelsson
2007-02-12 15:18 ` Haavard Skinnemoen
2007-02-12 18:40 ` Ulf Samuelsson
2007-02-12 19:36 ` Stefan Roese
2007-02-12 19:37 ` Haavard Skinnemoen
2007-02-12 20:05 ` Ulf Samuelsson
2007-02-11 21:54 ` Ulf Samuelsson
2007-02-11 11:49 Michel Benoit
2007-02-11 16:20 ` Ulf Samuelsson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.