From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4523 invoked by alias); 9 Jun 2006 18:47:12 -0000 Received: (qmail 4471 invoked by uid 22791); 9 Jun 2006 18:47:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.systech.com (HELO mail.systech.com) (207.212.80.162) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Jun 2006 18:47:07 +0000 Received: by mail.systech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2006 11:43:59 -0700 Message-ID: <74C9525D67A5FF4791614FDB06593BB1028627@mail.systech.com> From: Jay Foster To: 'Gary Thomas' , Jay Foster Cc: "'ecos-discuss@ecos.sourceware.org'" Date: Fri, 09 Jun 2006 18:47:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Flash Driver Read/Write Alignment Question X-SW-Source: 2006-06/txt/msg00101.txt.bz2 I have not encountered an alignment issue (yet), as I haven't gotten that far. I am studying the source code (flash_am29xxxxx.inl). I still don't see how this is supposed to work. Effectively, I would have: typedef cyg_uint16 flash_data_t; // flash_io.h volatile flash_data_t *f_s1, *f_s2; f_s1 = (volatile flash_data_t *)0xAAA; // flash base address omitted f_s2 = (volatile flash_data_t *)0x555; *f_s1 = FLASH_Reset; *f_s1 = FLASH_Setup_Code1; *f_s2 = FLASH_Setup_Code2; Where does the 0x555 and 0xAAA get shifted left by 1? The value of f_s2 is odd. Dereferencing it will result in an unaligned transfer. Jay -----Original Message----- From: Gary Thomas [mailto:gary@mlbassoc.com] Sent: Friday, June 09, 2006 11:02 AM To: Jay Foster Cc: 'ecos-discuss@ecos.sourceware.org' Subject: Re: [ECOS] Flash Driver Read/Write Alignment Question On Fri, 2006-06-09 at 10:06 -0700, Jay Foster wrote: > I am puzzling over how the eCos flash drivers are supposed to work when > using 16-bit wide flash devices. I'm using an ARM architecture (ARM7TDMI, > ARM940T), and the AMD AM29LV160 flash device connected in the 16-bit wide > mode (CYGNUM_FLASH_WIDTH=16). > > Looking at the flash driver code, this defines the flash_data_t as a 16-bit > type. This results in all accesses to the flash device to be performed as > 16-bit reads/writes. > > The flash driver defines some special addresses (FLASH_Setup_Addr1, > FLASH_Setup_Addr2, etc.). At least one of these will be defined as an odd > address. This will result in an unaligned transfer, causing a DATA ABORT > exception. What am I missing here? They should not end up at odd addresses since they are cast to the FLASH element type. If this is 16 bit, Addr(0xA55) == 0x14AA, etc. If you're ending up with alignment issues, then you've configured your FLASH driver incorrectly (check the defines). There are lots of examples of 16 and 32 bit device setups, as well as some parallel and banked layouts. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss