RE: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint
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@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: Wednesday, January 12, 2005 11:55 AM To: Peter Asemann Cc: u-boot-users@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
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 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.
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
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.
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
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
participants (5)
-
Jon Loeliger -
Nghiem, Tien -
Peter Asemann -
Tolunay Orkun -
Wolfgang Denk