[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Peter Asemann]

Im writing my own flash.c for "my" custom board in the moment.
That's why I'm trying to understand what the flash.c does.
I thought I got it when I encountered the following problem examining 
board/fads/flash.c

All functions in there seem to be written to handle 4x8bit flash banks.
As indication for that are - in my opinion - the QUAD_ID macro in line 
41+ and the fact that 0xAAAAAAAA, 0x55555555 and 0x90909090 and not 
0x00AA00AA, 0x00550055 and 0x00900090 are written in the auto select 
command sequence, beginning in line 227 (u-boot 1.1.2).
But they do write to the addresses which are typical - my fine flash 
datasheet says - for word-mode flash access.
So the data written seems not to fit the addresses written to.

I'd be very happy if someone could give me a hint what I missed or what 
I got wrong or why it must be that way though.

Peter Asemann

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Wolfgang Denk]

In message <41E537A8.8050006@web.de> you wrote:
> Im writing my own flash.c for "my" custom board in the moment.
> That's why I'm trying to understand what the flash.c does.
> I thought I got it when I encountered the following problem examining 
> board/fads/flash.c

There must ne some strange fascination about the FADS port. I  really
wonder  why  everybody  is  picking  one  of the most complicated and
poroblematic ports...

Pleas ehave a loot at least at some other drivers, too.

> All functions in there seem to be written to handle 4x8bit flash banks.

SO look for other flash drivers, or maybe even for  the  generic  CFI
driver.

> I'd be very happy if someone could give me a hint what I missed or what 
> I got wrong or why it must be that way though.

Forget what the FADS is doing. Think about what is  needed  for  your
own hardware, and implement this.

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 high cost of living hasn't affected its popularity.

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Peter Asemann]

> There must ne some strange fascination about the FADS port. I  really
> wonder  why  everybody  is  picking  one  of the most complicated and
> poroblematic ports...

I have an idea / a strong suggestion:
Maybe it's that this port seems to "fit" so many different CPUs and 
configurations that every Newbie thinks that he/she could easily copy 
the "right" parts of the code from there; while trying to do so, Mr. or 
Mrs. Newbie get lost in the super-enhanced or just wildly grown and 
tricky FADS code.

> Pleas ehave a loot at least at some other drivers, too.

I had and will have.

> Forget what the FADS is doing. Think about what is  needed  for  your
> own hardware, and implement this.

I'll do as I lack other options. I think it's recommended to develop the 
port for "my" hardware based upon 1.1.2? I started when 1.1.1 was the 
latest version.

Thanks a lot and best regards,

Peter Asemann

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Wolfgang Denk]

In message <41E55CA9.6080108@web.de> you wrote:
> 
> I'll do as I lack other options. I think it's recommended to develop the 
> port for "my" hardware based upon 1.1.2? I started when 1.1.1 was the 
> latest version.

No, it's recommended to use the _current_ version, i. e. top of  tree
in CVS.

Viele Gr??e,

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 ignorance is bliss, why aren't there more happy people?

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Nghiem, Tien]

Hi,

You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification.

Tien 

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Denk
Sent: Wednesday, January 12, 2005 11:55 AM
To: Peter Asemann
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] .../board/fads/flash.c confuses me - give me
a hint 


In message <41E537A8.8050006@web.de> you wrote:
> Im writing my own flash.c for "my" custom board in the moment.
> That's why I'm trying to understand what the flash.c does.
> I thought I got it when I encountered the following problem examining 
> board/fads/flash.c

There must ne some strange fascination about the FADS port. I  really
wonder  why  everybody  is  picking  one  of the most complicated and
poroblematic ports...

Pleas ehave a loot at least at some other drivers, too.

> All functions in there seem to be written to handle 4x8bit flash banks.

SO look for other flash drivers, or maybe even for  the  generic  CFI
driver.

> I'd be very happy if someone could give me a hint what I missed or what 
> I got wrong or why it must be that way though.

Forget what the FADS is doing. Think about what is  needed  for  your
own hardware, and implement this.

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 high cost of living hasn't affected its popularity.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Peter Asemann]

Nghiem, Tien wrote:

> Hi,
> 
> You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification.

Ahh... thanks for the hint. But anyway... the u-boot readme says an own 
flash.c was a minimum requirement for a port. If the generic driver 
works, why do people write customs flash.c's at all? All modern flash 
chips seem to support CFI anyway. Is there an example for a port that 
"only" uses the cfi_flash.c so I can take a look on it?

Best regards,

Peter Asemann

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Tolunay Orkun]

Peter Asemann wrote:
> Nghiem, Tien wrote:
> 
>> Hi,
>>
>> You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. 
>> it's generic and working. I have used it with these boards: 
>> IceCube(MPC5200) and EP8260 without modification.
> 
> 
> Ahh... thanks for the hint. But anyway... the u-boot readme says an own 
> flash.c was a minimum requirement for a port. If the generic driver 
> works, why do people write customs flash.c's at all? All modern flash 
> chips seem to support CFI anyway. Is there an example for a port that 
> "only" uses the cfi_flash.c so I can take a look on it?

I'll jump in. Initially, each board had its own flash.c. cfi_flash.c 
came later and some board maintainers switched to it and others did not 
update their implementation for some reason. If your board can be 
supported by cfi_flash.c and works well, it is probably not a good idea 
to develop a custom flash driver.

Also, some hardware may have mapped their flash in a way that is not 
compatible with cfi_flash.c or there may be other board specific issues 
so a custom flash.c might be preferable. For example we use cfi_flash.c 
on csb272 and csb472 boards. On csb272 it works well. On csb472 after 
"cp" command the flash is left in command mode and I have to issue a 
"protect on" or "protect off" command to put it to read mode again (we 
use physical sector protection). One of these days, I'll debug the 
problem (or hopefully another user of csb472 will do) but it was 
determined by manager that this is not a critical issue for us and I 
better spend my time on more pressing matters.

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Wolfgang Denk]

In message <41E590B4.6080700@orkun.us> you wrote:
>
> I'll jump in. Initially, each board had its own flash.c. cfi_flash.c 
> came later and some board maintainers switched to it and others did not 
> update their implementation for some reason. If your board can be 

One of the reasons is code size and efficiency. For example:

-> MAKEALL OXC
Configuring for OXC board...
   text    data     bss     dec     hex filename
 126100    8040   35988  170128   29890 u-boot
-> ppc_8xx-size board/oxc/flash.o
   text    data     bss     dec     hex filename
   2256      84       0    2340     924 board/oxc/flash.o
-> MAKEALL uc100
Configuring for uc100 board...
   text    data     bss     dec     hex filename
 164164   10260  218452  392876   5feac u-boot
-> ppc_8xx-size drivers/cfi_flash.o
   text    data     bss     dec     hex filename
   6040     116       0    6156    180c drivers/cfi_flash.o

As you can see, the CFI flash driver is nearly 3 times as  big  as  a
customized flash driver.

In some cases there is ample space and this doesn't matter, in  other
cases things are different.

> supported by cfi_flash.c and works well, it is probably not a good idea 
> to develop a custom flash driver.

I disagree if you give this as general advice. You have to  know  the
requirements  of  the project, and understand what you're doing. Only
then you can give intelligent advice.


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 project was large enough and management communication poor enough
to prompt many members of the team to see themselves  as  contestants
making  brownie  points,  rather  than as builders making programming
products. Each suboptimized  his  piece  to  meet  his  targets;  few
stopped to think about the total effect on the customer.
                              - Fred Brooks, "The Mythical Man Month"

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Tolunay Orkun]

Wolfgang Denk wrote:

>>supported by cfi_flash.c and works well, it is probably not a good idea 
>>to develop a custom flash driver.
>>    
>>
>
>I disagree if you give this as general advice. You have to  know  the
>requirements  of  the project, and understand what you're doing. Only
>then you can give intelligent advice.
>  
>

Wolfgang, you made a good point regarding code size. I agree, there are 
always good reasons not to go with one size fits all approach.

As you see, I said "probably" instead of talking absolute terms. Also, I 
mentioned "if it works well". If the code does not fit in the space, it 
does not work at all.

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Jon Loeliger]

On Wed, 2005-01-12 at 13:34, Peter Asemann wrote:
> Nghiem, Tien wrote:
> 
> > Hi,
> > 
> > You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification.
> 
> Ahh... thanks for the hint. But anyway... the u-boot readme says an own 
> flash.c was a minimum requirement for a port. If the generic driver 
> works, why do people write customs flash.c's at all? All modern flash 
> chips seem to support CFI anyway. Is there an example for a port that 
> "only" uses the cfi_flash.c so I can take a look on it?
> 
> Best regards,
> 
> Peter Asemann

Peter,

The MPC85xx ADS and CDS boards are all currently using
the CFI driver.  They were originally coded using a
part-specific flash.c, but they have since been converted
to the generic CFI driver.

Thanks,
jdl

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Wolfgang Denk]

In message <41E57BAA.3010906@web.de> you wrote:
> 
> Ahh... thanks for the hint. But anyway... the u-boot readme says an own 
> flash.c was a minimum requirement for a port. If the generic driver 
> works, why do people write customs flash.c's at all? All modern flash 

Code size.

> chips seem to support CFI anyway. Is there an example for a port that 

Argh.. I really wish that was the case. It ain't so.

> "only" uses the cfi_flash.c so I can take a look on it?

Sure, many. For example:

	bash$ cd include/configs
	bash$ grep -l CFI_ *
	Adder.h
	ISPAN.h
	MPC8540ADS.h
	MPC8541CDS.h
	MPC8555CDS.h
	MPC8560ADS.h
	SBC8540.h
	SBC8560.h
	SX1.h
	TQM5200.h
	Total5200.h
	ZPC1900.h
	assabet.h
	csb272.h
	csb472.h
	dbau1x00.h
	eXalion.h
	gcplus.h
	omap1510inn.h
	ppmc8260.h
	quantum.h
	sbc8560.h
	uc100.h



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
"You ain't experienced..." "Well, nor are you." "That's true. But the
point is ... the point is ... the point is we've been not experienced
for a lot longer than you. We've got  a  lot  of  experience  of  not
having any experience."           - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Nghiem, Tien]

I can return your question: why does the CFI exist?. Have a look at the u-boot-1.1.2/board/ppm8260/strataflash.c that is an example for a port that "only" uses the cfi_flash.c.

Good luck

Tien
-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Peter
Asemann
Sent: Wednesday, January 12, 2005 2:34 PM
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] .../board/fads/flash.c confuses me - give me
a hint


Nghiem, Tien wrote:

> Hi,
> 
> You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification.

Ahh... thanks for the hint. But anyway... the u-boot readme says an own 
flash.c was a minimum requirement for a port. If the generic driver 
works, why do people write customs flash.c's at all? All modern flash 
chips seem to support CFI anyway. Is there an example for a port that 
"only" uses the cfi_flash.c so I can take a look on it?

Best regards,

Peter Asemann


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint

[Peter Pearse]

Hi 

I am not convinced drivers/cfi.flash.c performs correctly on the 
VersatilePB board - I am currently working on a patch.....

I believe:: 

static int flash_full_status_check (flash_info_t * info, flash_sect_t
sector,
				    ulong tout, char *prompt)
{
	int retcode;

	retcode = flash_status_check (info, sector, tout, prompt);
	switch (info->vendor) {
	case CFI_CMDSET_INTEL_EXTENDED:
	case CFI_CMDSET_INTEL_STANDARD:
		if ((retcode != ERR_OK)
		    && !flash_isequal (info, sector, 0,
FLASH_STATUS_DONE)) {

                **

			retcode = ERR_INVAL;

should be

static int flash_full_status_check (flash_info_t * info, flash_sect_t
sector,
				    ulong tout, char *prompt)
{
	int retcode;

	retcode = flash_status_check (info, sector, tout, prompt);
	switch (info->vendor) {
	case CFI_CMDSET_INTEL_EXTENDED:
	case CFI_CMDSET_INTEL_STANDARD:
		if ((retcode != ERR_OK)
		    || !flash_isequal (info, sector, 0,
FLASH_STATUS_DONE)) {

                **

			retcode = ERR_INVAL;

But perhaps only on VersatilePB.

Regards

Peter