[U-Boot-Users] [GIT PULL] AVR32 relocation

[U-Boot-Users] [GIT PULL] AVR32 relocation

[Haavard Skinnemoen]

Hi Wolfgang,

Please pull from the 'for-upstream' branch of

	git://www.atmel.no/~hskinnemoen/u-boot/avr32 for-upstream

to receive the following updates:

Haavard Skinnemoen (6):
      AVR32: Split start_u_boot into board_init_f and board_init_r
      AVR32: Use avr32-linux- cross-compilation prefix by default
      AVR32: Build position-independent u-boot
      AVR32: Clean up memory-map.h for at32ap7000
      AVR32: Resource management rewrite
      AVR32: Relocate u-boot to SDRAM

 Makefile                                       |    2 +-
 avr32_config.mk                                |    2 +-
 board/atmel/atstk1000/atstk1000.c              |   13 +
 board/atmel/atstk1000/flash.c                  |    2 +-
 board/atmel/atstk1000/u-boot.lds               |   21 +-
 cpu/at32ap/Makefile                            |    2 +-
 cpu/at32ap/at32ap7000/Makefile                 |    2 +-
 cpu/at32ap/at32ap7000/devices.c                |  448 ------------------------
 cpu/at32ap/at32ap7000/gpio.c                   |   77 ++++
 cpu/at32ap/at32ap7000/hebi.c                   |   38 --
 cpu/at32ap/cpu.c                               |   64 +++-
 cpu/at32ap/device.c                            |  126 -------
 cpu/at32ap/entry.S                             |    3 +-
 cpu/at32ap/exception.c                         |    7 +-
 cpu/at32ap/hsdramc.c                           |   43 +--
 cpu/at32ap/hsdramc1.h                          |    8 +-
 cpu/at32ap/hsmc3.h                             |    8 +-
 cpu/at32ap/interrupts.c                        |   14 +-
 cpu/at32ap/pio.c                               |   90 ++----
 cpu/at32ap/pio2.h                              |    8 +-
 cpu/at32ap/pm.c                                |  127 +-------
 cpu/at32ap/sm.h                                |    8 +-
 cpu/at32ap/start.S                             |  113 +++++--
 drivers/atmel_usart.c                          |   48 ++-
 drivers/atmel_usart.h                          |    8 +-
 include/asm-avr32/arch-at32ap7000/clk.h        |   58 +++
 include/asm-avr32/arch-at32ap7000/gpio.h       |  210 +++++++++++
 include/asm-avr32/arch-at32ap7000/hmatrix2.h   |    8 +-
 include/asm-avr32/arch-at32ap7000/memory-map.h |   81 +++--
 include/asm-avr32/arch-at32ap7000/platform.h   |  146 --------
 include/asm-avr32/global_data.h                |    3 +-
 include/configs/atstk1002.h                    |   17 +-
 lib_avr32/avr32_linux.c                        |    4 +-
 lib_avr32/board.c                              |  139 +++++++-
 34 files changed, 796 insertions(+), 1152 deletions(-)
 delete mode 100644 cpu/at32ap/at32ap7000/devices.c
 create mode 100644 cpu/at32ap/at32ap7000/gpio.c
 delete mode 100644 cpu/at32ap/at32ap7000/hebi.c
 delete mode 100644 cpu/at32ap/device.c
 create mode 100644 include/asm-avr32/arch-at32ap7000/clk.h
 create mode 100644 include/asm-avr32/arch-at32ap7000/gpio.h
 delete mode 100644 include/asm-avr32/arch-at32ap7000/platform.h

After this, the avr32 port will relocate itself to the end of DRAM like
the ppc port does. Attached is a combined diff with all the changes,
for your reference (too big to include inline.)

Quite a large number of files were touched. This is mostly early init
code which assumed the .data and .bss sections were available.

Now, I would like to use the cfi driver with the AT49BV6416 chip on
atstk1000 instead of the custom driver, but unfortunately, it doesn't
work. I'll have a closer look at it later (I think it's a combination
of the geometry reversal issue and a special non-intel unlocking
algorithm.)

Thanks,

Haavard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avr32-relocation.patch.gz
Type: application/x-gzip
Size: 15345 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061120/bd944077/attachment.bin 

[U-Boot-Users] [GIT PULL] AVR32 relocation

[Tolunay Orkun]

Haavard Skinnemoen wrote:

> Now, I would like to use the cfi driver with the AT49BV6416 chip on
> atstk1000 instead of the custom driver, but unfortunately, it doesn't
> work. I'll have a closer look at it later (I think it's a combination
> of the geometry reversal issue and a special non-intel unlocking
> algorithm.)

Try the latest cfi driver from git. My patch to address geometry 
reversal for AMD style flash was applied today.

Tolunay

[U-Boot-Users] [GIT PULL] AVR32 relocation

[Haavard Skinnemoen]

On 11/20/06, Tolunay Orkun <listmember@orkun.us> wrote:
>
> Haavard Skinnemoen wrote:
>
> > Now, I would like to use the cfi driver with the AT49BV6416 chip on
> > atstk1000 instead of the custom driver, but unfortunately, it doesn't
> > work. I'll have a closer look at it later (I think it's a combination
> > of the geometry reversal issue and a special non-intel unlocking
> > algorithm.)
>
> Try the latest cfi driver from git. My patch to address geometry
> reversal for AMD style flash was applied today.

Thanks, but I already tried the latest patch I could find in my inbox.
After I added a special case for AT49BV6416, it got the geometry
right, but it still needs to learn how to "soft unlock" sectors before
erasing/programming.

We could of course just unlock the whole thing at initialization time,
like Linux does. AMD-style chips aren't supposed to be locked after
reset.

Haavard

[U-Boot-Users] [GIT PULL] AVR32 relocation

[Tolunay Orkun]

Haavard Skinnemoen wrote:
> On 11/20/06, Tolunay Orkun <listmember@orkun.us> wrote:
>   
>> Haavard Skinnemoen wrote:
>>
>>     
>>> Now, I would like to use the cfi driver with the AT49BV6416 chip on
>>> atstk1000 instead of the custom driver, but unfortunately, it doesn't
>>> work. I'll have a closer look at it later (I think it's a combination
>>> of the geometry reversal issue and a special non-intel unlocking
>>> algorithm.)
>>>       
>> Try the latest cfi driver from git. My patch to address geometry
>> reversal for AMD style flash was applied today.
>>     
>
> Thanks, but I already tried the latest patch I could find in my inbox.
> After I added a special case for AT49BV6416, it got the geometry
> right, but it still needs to learn how to "soft unlock" sectors before
> erasing/programming.
>   

I did check the data sheet of AT49BV6416. 
http://www.atmel.com/dyn/resources/prod_documents/doc3451.pdf

It's a total mess. It is not just "soft unlock" that is needed. Via CFI, 
it claims compatibility with AMD Standard command set but 2nd cycle is 
written to address AAA instead of 2AA. I do not know if 2AA works for 
this device as the address to use in second cycle as well.

It also claims CFI version 1.0 in Primary Extended Vendor Specific 
Table, but table layout is different from AMD standard. It is using a 
different byte for top/bottom flag and in a different value setup there.

I think to use this chip with CFI driver, you will have to identify this 
device using jedec manufacturer and possibility jedec device id and 
implement correct command sequences for this device if manufacturer id 
and device id match this device. However, even JEDEC identification 
sequence might fail since the second cycle address is to AAA instead of 
2AA. Major incompatibilities....

FYI, compare that with the following AMD style chips:

http://www.st.com/stonline/books/pdf/docs/9195.pdf
http://www.spansion.com/datasheets/s29gl-m_00_b6_e.pdf
http://www.mcu-memory.com/datasheet/macronix/MX29LV640T-B-1.0.pdf

> We could of course just unlock the whole thing at initialization time,
> like Linux does. AMD-style chips aren't supposed to be locked after
> reset.
>   
Intel Legacy unlock does that (no individual sector unlock).  CFI driver 
relocks all those sectors that was supposed to be locked when using 
Intel legacy unlock sequence. I personally think individually locking 
and unlocking is a better way.

Best regards,
Tolunay

[U-Boot-Users] [GIT PULL] AVR32 relocation

[Ladislav Michl]

On Mon, Nov 20, 2006 at 07:07:12PM +0100, Haavard Skinnemoen wrote:
> Thanks, but I already tried the latest patch I could find in my inbox.
> After I added a special case for AT49BV6416, it got the geometry
> right, but it still needs to learn how to "soft unlock" sectors before
> erasing/programming.
> 
> We could of course just unlock the whole thing at initialization time,
> like Linux does. AMD-style chips aren't supposed to be locked after
> reset.

Current CFI driver works with AT49BV6416 after unlocking all sectors at
initialization time. So... To create acceptable patch someone should
decide which approach is correct (unlock before erase/program or unlock
all on init)

Best regards,
	ladis

diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c
index 5579a1e..a71c1f5 100644
--- a/drivers/cfi_flash.c
+++ b/drivers/cfi_flash.c
@@ -330,13 +330,25 @@ ulong flash_read_long (flash_info_t * info, flash_sect_t sect, uint offset)
 	return retval;
 }
 
+int flash_atmel_softlock (flash_info_t * info, long sector, int prot)
+{
+	int retcode = 0;
+
+	flash_write_cmd (info, 0, AMD_ADDR_START, 0xaa);
+	if (prot)
+		flash_write_cmd (info, sector, 0, 0x55);
+	else
+		flash_write_cmd (info, sector, 0, 0x70);
+
+	return retcode;
+}
 
 /*-----------------------------------------------------------------------
  */
 unsigned long flash_init (void)
 {
 	unsigned long size = 0;
-	int i;
+	int i, j;
 
 #ifdef CFG_FLASH_PROTECTION
 	char *s = getenv("unlock");
@@ -394,8 +406,11 @@ unsigned long flash_init (void)
 			}
 		}
 #endif /* CFG_FLASH_PROTECTION */
-	}
+	/* Unlock all sectors at reset */
+	for (j = 0; j < flash_info[i].sector_count; j++)
+		flash_atmel_softlock (&flash_info[i], j, 0);
 
+	}
 	/* Monitor protection ON by default */
 #if (CFG_MONITOR_BASE >= CFG_FLASH_BASE)
 	flash_protect (FLAG_PROTECT_SET,