From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29354 invoked by alias); 27 Aug 2008 07:12:18 -0000 Received: (qmail 29336 invoked by uid 22791); 27 Aug 2008 07:12:17 -0000 X-Spam-Check-By: sourceware.org Received: from d5152C2DE.access.telenet.be (HELO lx-dmz.televic.com) (81.82.194.222) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Aug 2008 07:11:32 +0000 Received: (qmail 7687 invoked from network); 27 Aug 2008 07:11:22 -0000 Received: from nt-email.televic.com (10.0.0.9) by lx-dmz.televic.com with SMTP; 27 Aug 2008 07:11:22 -0000 Received: from [127.0.0.1] ([10.0.56.49]) by nt-email.TELEVIC.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 09:11:22 +0200 Message-ID: <48B4FE19.5020009@televic.com> Date: Wed, 27 Aug 2008 07:20:00 -0000 From: =?UTF-8?B?SsO8cmdlbiBMYW1icmVjaHQ=?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: =?UTF-8?B?TWFyYy1BbmRyw6kgQmVjaw==?= , Nuria.PazosEscudero@he-arc.ch CC: Frank Pagliughi , eCos Discuss References: <48B290B3.6080804@netlabs.org> <48B2A9B4.3050108@gmx.ch> In-Reply-To: <48B2A9B4.3050108@gmx.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Booting from Flash in a AT91M55800A based platform X-SW-Source: 2008-08/txt/msg00070.txt.bz2 Marc-André Beck wrote: > Hi, > > I'm a coworker of Nuria and am rather new to this project. So i reply > to this mail. > > Lambrecht Jürgen wrote: >> Frank Pagliughi wrote: >> > Pazos Escudero Nuria wrote: >> > >> > >Hi, >> > > >> > >I've ported eCos and RedBoot for a proprietary platform >> comprising the >> > >AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash >> modules. >> > >The RAM version works fine and I can communicate with the RedBoot >> > >console through the serial port, but I have not yet managed to make >> Can you access the flash from redboot? (fis init; fconfig -I; ..) > > No. while booting from RAM I only see the RAM. There's no FLASH part: > > RAM: 0x40000000-0x40080000, [0x4001f1e8-0x40034000] available > > > Trying to build the "Flash Tools" (CYGSEM_REDBOOT_FLASH_CONFIG) fails > with a linking error: > > .../libtarget.a(redboot_fconfig.o): In function `do_flash_config': > .../fconfig.c:322: undefined reference to `__flash_init' you need to add a flash driver. Redboot can not find a flash if the drivers are not compiled in... Of course "There's no FLASH part: " ... see at eb55. my /misc/redboot_rom.ecm looks so: cdl_configuration eCos { package CYGPKG_IO_FLASH current ; package CYGPKG_DEVS_FLASH_[platform-name] current; package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current; }; > > > As the flash (NAND) supports the JEDEC-standard, shouldn't it be > accessible from RedBoot with a generic driver? Spansion does not make NAND flashes, only NOR flashes. So you have a NOR flash. Yes, I know, the datasheet does not mention it, but then it is a NOR flash - if it would be a NAND flash, the datasheet would mention it. Or visit the spansion web-site... (datasheet via alldatasheet.com). Yes, a generic driver.. Redboot still needs a low-level driver, in this case the devs/flash/amd/am29xxxxx/. -> 'package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current;' Spansion has taken over the flashes from AMD. The datasheet also mentions that the S29AL016D is "Fully compatible with Am29LV160D and MBM29LV160E devices" In devs/flash/amd/am29xxxxx/ only the T and B are present (not the D), but your flash has an ID of 0x49, so I would give it a try with the AM29LV160-B flash. Still, I would check with the datasheet if it is completely the same. If you don't understand something from the files in devs/flash/amd/am29xxxxx/, just ask. Redboot also needs you to specify the root address. -> 'package CYGPKG_DEVS_FLASH_[platform-name] current;' > > > >> Are the flash things OK? You can use the arm/at91/eb55 port as >> starting point. You need also flash code in devs/flash/arm/eb55 and >> devs/flash/amd/am29xxxxx -> I just checked >> devs/flash/amd/am29xxxxx/current/include/flash_am29xxxxx_parts.inl, >> and there is no S29AL part in the list. >> Just add it. You can start from the CYGHWR_DEVS_FLASH_AMD_S29GL128N >> part, and check your datasheet for changes. >> (mark: the eb55 board uses an atmel flash of course, so the part used >> (' #define CYGHWR_DEVS_FLASH_ATMEL_AT49BV1604A ') is in >> devs\flash\atmel\at49xxxx\current\include\ flash_at49xxxx_parts.inl) >> >> You could also have problems because of the 3 flash chips. Start with >> using only 1. >> If you want to use the 3 flashes separately, I think you need then >> the flash_v2 drivers - check the mailing list for it. >> >> > the >> > >platform boot from the flash (after copying the ROM version of the >> > >ported RedBoot on the flash address pointed by the chip select 0). I >> > >don't know whether the problem comes from the platform porting or >> from >> > >the fact that eCos does not recognize the used flash chips from >> > >Spansion. Could you provide me any hint? >> > > >> > >Thanks in advance! >> > >Nuria >> > > >> > > >> > > >> > If you're programming the Flash chips with a JTAG, then the lack of >> > eCos >> > drivers doesn't matter at this stage. > > Yes, it was done using a JTAG. > >> > - Does the JTAG software claim that the "program and verify" worked >> > properly? > > Yes. > >> > - Are the Flash chips properly wired on the board? > > Yes. Verified and reverified. > >> > - Did you set up the "_InitMemory" table in "hal_platform_setup.h" >> for >> > the Flash chip(s). You need to set the base address, # wait states, >> > etc. > > I adapted them for the S29AL016D90TFI02: > > .long 0x100037B1 // NAND Flash, 2MB, 3 cycles after transfer, > 16-bit, 5 wait state > .long 0x200037B1 > .long 0x300037B1 > .long 0x40002121 // RAM > ... > > Still the Spansion S29AL016D is NAND-Flash with a bottom boot block. > So i am booting from NAND. Is this a from the datasheet: bottom boot has ID 0x49 > problem as the ATMEL AT91M55800A should be capable of code shadowing? google explained to me what "code shadowing" is. In ecos, this is called ROMRAM mode: you boot from ROM, but then copy all binary to RAM (done in assembly in hal_platform_setup.h). You do this because an external NOR flash is very slow to execute code from; but I only do it for the application, not for redboot: redboot is executed from flash and then loads the application (in my case). I would think your processor just needs RAM do be able to do code shadowing. Even in ROM mode, the flash access functions are mapped into RAM in ecos. > Regarding the boot block of the NAND: Shouldn't it be XIP (execution > in place) capable? Indeed. but you have a NOR flash, so don't worry: in general a NOR flash is bootable or XIP, a NAND not. > > >> > Plus the base address for each CS line must be different, even if the >> > CS >> > is disabled. >> Indeed. >> >> I have a 64MB S29GL512, and use 4 chip-selects for it. >> Here is my "_InitMemory" code: >> >> .long 0x1000352D //NCS0 flash-1 , 16MB, 2 cycles after >> transfer, 16-bit, 4 wait state >> .long 0x1100352D //NCS1 flash-2 , 16MB, 2 cycles after >> transfer, 16-bit, 4 wait state >> .long 0x1200352D //NCS2 flash-3 , 16MB, 2 cycles after >> transfer, 16-bit, 4 wait state >> .long 0x1300352D //NCS3 flash-4 , 16MB, 2 cycles after >> transfer, 16-bit, 4 wait state >> .long 0x06002121 //NCS4 IDT SRAM, 16MB, 0 cycles after >> transfer, 16-bit, 1 wait state >> >> Starting from the eb55 port, I first used addresses 0x0100, 0x0200, >> 0x0300 and 0x0400. But this did not work very well! I still don't >> know why. The addresses 0x1000, 0x1100, .. worked, so I stopped my >> effort there. >> >> > - You should be able to reset the CPU and single step through the >> first >> > few instructions, using the JTAG and/or gdb. Remember that the chip >> > starts with the first Flash (CS0) mapped to address zero. You can >> > single >> > step up to the point where the chip select registers are loaded and >> > make >> > sure that the values are being loaded properly. But note that you >> > can't >> > step over the remap command since the debugger messes with the >> > pipeline. >> > - One of the first things that the assembly startup does is set the >> > master clock (and maybe the PLL) running faster. If you set them >> > running >> > faster than the external board can support, the board may lock up. >> > >> > >> > Whatever you're using to load the RAM debug code onto the board is >> > initializing it properly (a JTAG initialization file?). Use that as a >> > starting point. The only thing it isn't doing is setting up the Flash >> > chip select registers in the EBI, so pay careful attention to that. >> > >> > Frank >> > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss