[U-Boot-Users] Re: Problem with the cfi flash driver with a x8/x16 flash confi guredinx8 mode.

[U-Boot-Users] Re: Problem with the cfi flash driver with a x8/x16 flash confi guredinx8 mode.

[Bastos Fernandez Alexandre]

Txema,

> >
> >I think your topic is very similar to this recent one:
> >
> >http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/19970
> >
> >
> OK, I've checked it.
>
> >and previous similar patches have been submited and are still
> >pending (but it seems they are coming, read the whole thread)
> >
> >
> But not the patch that Wolfgang proposed, isn'it?
>

Wolfgang proposes shifting the commands as a solution. This is
the way it's done in some patches already submitted, (mine as
an example ;-D ) ...

http://sourceforge.net/mailarchive/message.php?msg_id=12799051

> I think the patch that Wolfgang proposed could be like that. I've tested
> it with a S29GL128N x8/x16 in x8 mode. It works fine. But I have no idea
> what would happen in  x16 mode or others modes. I haven't the hardware
> to check it.

I think this may work for x16 but would break support for x32, x64
as portwidth can be ...
FLASH_CFI_8BIT          0x01
FLASH_CFI_16BIT         0x02
FLASH_CFI_32BIT         0x04
FLASH_CFI_64BIT         0x08

but AMD_ADDR_* for x16, x32 and x64 is the same


>
> --- ../tmp/u-boot/drivers/cfi_flash.c   2006-01-12 12:22:08.000000000
+0100
> +++ drivers/cfi_flash.c 2006-01-12 17:21:19.000000000 +0100
> @@ -107,9 +107,10 @@
>
>  #define AMD_STATUS_TOGGLE              0x40
>  #define AMD_STATUS_ERROR               0x20
> -#define AMD_ADDR_ERASE_START           0x555
> -#define AMD_ADDR_START                 0x555
> -#define AMD_ADDR_ACK                   0x2AA
> +
> +#define AMD_ADDR_ERASE_START           (0xAAA >> (info->portwidth-1))
> +#define AMD_ADDR_START                 (0xAAA >> (info->portwidth-1))
> +#define AMD_ADDR_ACK                   (0x555 >> (info->portwidth-1))
>
>  #define FLASH_OFFSET_CFI               0x55
>  #define FLASH_OFFSET_CFI_RESP          0x10
>


Also, take a look a this pathc for buffer write support:

http://sourceforge.net/mailarchive/message.php?msg_id=12797909


Best regards,

Alex BASTOS

[U-Boot-Users] Re: Problem with the cfi flash driver with ax8/x16 flash configuredinx8 mode.

[Txema Lopez]

Bastos Fernandez Alexandre wrote:

Hi Alex,

>Txema,
>
>  
>
>>>I think your topic is very similar to this recent one:
>>>
>>>http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/19970
>>>
>>>
>>>      
>>>
>>OK, I've checked it.
>>
>>    
>>
>>>and previous similar patches have been submited and are still
>>>pending (but it seems they are coming, read the whole thread)
>>>
>>>
>>>      
>>>
>>But not the patch that Wolfgang proposed, isn'it?
>>
>>    
>>
>
>Wolfgang proposes shifting the commands as a solution. This is
>the way it's done in some patches already submitted, (mine as
>an example ;-D ) ...
>
>http://sourceforge.net/mailarchive/message.php?msg_id=12799051
>  
>
What "shifting the commands" means ? I though the problem was with the 
addresses.

>  
>
>>I think the patch that Wolfgang proposed could be like that. I've tested
>>it with a S29GL128N x8/x16 in x8 mode. It works fine. But I have no idea
>>what would happen in  x16 mode or others modes. I haven't the hardware
>>to check it.
>>    
>>
>
>I think this may work for x16 but would break support for x32, x64
>as portwidth can be ...
>FLASH_CFI_8BIT          0x01
>FLASH_CFI_16BIT         0x02
>FLASH_CFI_32BIT         0x04
>FLASH_CFI_64BIT         0x08
>
>but AMD_ADDR_* for x16, x32 and x64 is the same
>  
>
I see. Anyway, why not define ?

#define AMD_ADDR_ERASE_START   ((info->portwidth == FLASH_CFI_8BIT) ? 
0xAAA : 0x555)
#define AMD_ADDR_START                ((info->portwidth == 
FLASH_CFI_8BIT) ? 0xAAA : 0x555)
#define AMD_ADDR_ACK                    ((info->portwidth == 
FLASH_CFI_8BIT) ? 0x555 : 0x2AA)

I think is cleaner to change one define than the code. What do you think?

>
>  
>
>>--- ../tmp/u-boot/drivers/cfi_flash.c   2006-01-12 12:22:08.000000000
>>    
>>
>+0100
>  
>
>>+++ drivers/cfi_flash.c 2006-01-12 17:21:19.000000000 +0100
>>@@ -107,9 +107,10 @@
>>
>> #define AMD_STATUS_TOGGLE              0x40
>> #define AMD_STATUS_ERROR               0x20
>>-#define AMD_ADDR_ERASE_START           0x555
>>-#define AMD_ADDR_START                 0x555
>>-#define AMD_ADDR_ACK                   0x2AA
>>+
>>+#define AMD_ADDR_ERASE_START           (0xAAA >> (info->portwidth-1))
>>+#define AMD_ADDR_START                 (0xAAA >> (info->portwidth-1))
>>+#define AMD_ADDR_ACK                   (0x555 >> (info->portwidth-1))
>>
>> #define FLASH_OFFSET_CFI               0x55
>> #define FLASH_OFFSET_CFI_RESP          0x10
>>
>>    
>>
>
>
>Also, take a look a this pathc for buffer write support:
>
>http://sourceforge.net/mailarchive/message.php?msg_id=12797909
>  
>
Ok, I'll test it in my board.

>
>Best regards,
>
>Alex BASTOS
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>  
>
Best Regard,
Txema
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 427 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060113/8d9b12f8/attachment.vcf 

[U-Boot-Users] Re: Problem with the cfi flash driver with ax8/x16 flash configuredinx8 mode.

[Alex BASTOS]

> What "shifting the commands" means ? I though the problem was with the
> addresses.

Sorry, mis-speaking. Shifting the addresses, I mean. ;)


>
> #define AMD_ADDR_ERASE_START   ((info->portwidth == FLASH_CFI_8BIT) ?
> 0xAAA : 0x555)
> #define AMD_ADDR_START                ((info->portwidth ==
> FLASH_CFI_8BIT) ? 0xAAA : 0x555)
> #define AMD_ADDR_ACK                    ((info->portwidth ==
> FLASH_CFI_8BIT) ? 0x555 : 0x2AA)
>
> I think is cleaner to change one define than the code. What do you think?
>

For me it's OK. I have no preference about how to do it.
I think, at the end, it will be Wolfgang or Tolunay Orkun
who will choose.

Best regards,

Alex

[U-Boot-Users] Re: Problem with the cfi flash driver with ax8/x16 flash configuredinx8 mode.

[Tolunay Orkun]

Alex BASTOS wrote:
> 
> I think, at the end, it will be Wolfgang or Tolunay Orkun
> who will choose.

Not me. It is Wolfgang that decides what is acceptable. I might have 
argued my position a bit more passionately in the past as well regarding 
some changes but I do not have any such decision making capability here.

I have interest in this peace of code because we use it and I have 
submitted some patches and studied the code probably a little more 
closely than others.

I am all for someone picking up all the pending patches and merging in. 
I wish I could do this but I really do not have time at this time. I 
guess this is true for most of us nowadays.

I am looking at "cfi_testing" branch proposal from Wolfgang as a medium 
to incorporate all the pending patches and resolve the merge conflicts 
between various patches before we can sync back to the mainline.

Since a lot of people are now dependent on these patches (as evidenced 
by frequency of questions regarding cfi_flash.c driver on the list) 
there is a lot of good to come if we merge these "somewhere" and after a 
testing period of say 1 month if everyone is happy (and especially 
Wolfgang) we can merge back to mainline hopefully before next release of 
U-Boot.

Wolfgang what do you think?

Best regards,
Tolunay

[U-Boot-Users] Re: Problem with the cfi flash driver with ax8/x16 flash configuredinx8 mode.

[Wolfgang Denk]

In message <43C82289.3060608@orkun.us> you wrote:
> 
> Since a lot of people are now dependent on these patches (as evidenced 
> by frequency of questions regarding cfi_flash.c driver on the list) 
> there is a lot of good to come if we merge these "somewhere" and after a 
> testing period of say 1 month if everyone is happy (and especially 
> Wolfgang) we can merge back to mainline hopefully before next release of 
> U-Boot.
> 
> Wolfgang what do you think?

I'd be *happy* if someone who has a clue just went ahead  and  merged
all  the existing patches into soe working version - ideally in a git
repo where I can  pull  from  (to  create  the  cfi-testing  branch);
alternatively a "summary patch" is welcome, too.

I promise to spend a little more time for U-Boot  once  we  get  this
d*** ELDK 4.0 released.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The world is coming to an end -- save your buffers!

[U-Boot-Users] Re: Problem with the cfi flash driver with a x8/x16 flash confi guredinx8 mode.

[Wolfgang Denk]

In message <51DB8827D393D411BB69003048003F4601B1C284@tvesntr> you wrote:
> 
> I think this may work for x16 but would break support for x32, x64
> as portwidth can be ...
...

Not used. Version from Txema Lopez  <tlopez@aotek.es>  from  16.  01.
2006 applied instead. Closed. Thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If A equals success, then the formula is A = X + Y + Z. X is work.  Y
is play. Z is keep your mouth shut.                 - Albert Einstein