[U-Boot-Users] [GIT PULL] AVR32 relocation
Haavard Skinnemoen
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
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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
U-Boot-Users mailing list
U-Boot...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Haavard Skinnemoen
>
> 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
Tolunay Orkun
> On 11/20/06, Tolunay Orkun <listm...@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
Ladislav Michl
> 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,
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash