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

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

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

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

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

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,
participants (4)
-
Haavard Skinnemoen
-
Haavard Skinnemoen
-
Ladislav Michl
-
Tolunay Orkun