Skip to contentSkip to conversation

A Shared flash.c

U-Boot-Users Stephen Williams 2 participants 4 messages Mar 5, 2004 1 message not in the archive

lore
Share & tools
lore

Stephen Williams

author
#1 lore raw
In reply to a message not in the archive
Quoted 9 lines · Stephen Williams

The JSE board (PPC405GPr) I'm working on has an 8-bit flash that is attached to the local bus, and I find that the flash.c from board/walnut405 is almost identical. (I just needed to add a case for a different chip vendor.) Would it make sense to move more of its contents to common/flash.c? For example, the flash_printinfo function seems like a candidate.

Would patches to that effect be accepted?

Well gee, it seems like flash_print_info in particular should
go into the cmd_flash.c file, *inside* the (CONFIG_COMMANDS & CFG_CMD_FLASH) section. The flinfo command is the only place it is used. There are a few other functions like that, but print_flash_info is the most glaring example.

Signature · 4 lines
Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
#2 lore raw
Quoted 6 lines · In message <[email protected]> you wrote:

Well gee, it seems like flash_print_info in particular should
go into the cmd_flash.c file, *inside* the (CONFIG_COMMANDS & CFG_CMD_FLASH) section. The flinfo command is the only place it is used. There are a few other functions like that, but print_flash_info is the most glaring example.

Please have a look over the rim. There are other flash drivers which are just different.

Wolfgang Denk

Signature · 6 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_
author
#3 lore raw
Quoted 11 lines · Wolfgang Denk wd-at-denx.de |u-boot-users|
Quoted 5 lines · In message <[email protected]> you wrote:

Well gee, it seems like flash_print_info in particular should
go into the cmd_flash.c file, *inside* the (CONFIG_COMMANDS & CFG_CMD_FLASH) section. The flinfo command is the only place it is used. There are a few other functions like that, but print_flash_info is the most glaring example.

Please have a look over the rim. There are other flash drivers which are just different.

OK, that's true about the flash.c file as a whole, but the print_flash_info functions are all board independent, as far as I can see. Just different levels of completeness. There are other similar functions that only peruse the flash_info structures and so are completely board independent, and I was merely thinking in terms of unifying some common code.

Again, I see your point WRT flash.c as a whole, but wouldn't it be useful to for example make flash_print_info common?

Granted that's a lot of board files implementing the same print_flash_info, so maybe surround a common version with CFG_FLASH_COMMON_PRINT and use that for the few that are staring me in the face.

Signature · 4 lines
Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
#4 lore raw
Quoted 4 lines · In message <[email protected]> you wrote:

OK, that's true about the flash.c file as a whole, but the print_flash_info functions are all board independent, as far as I can see. Just different levels of completeness. There

This has nothing to do with completeness, but with optimization of memory footprint. The reason why most boards use their own special version of flash.c is so that it gives minimum memory footprint by just supporting the poosible variants of this specific board. It is just a waste of memory when you for example include support for Intel chips when you know for sure that the board will always see only AMD chips.

Quoted 3 lines

are other similar functions that only peruse the flash_info structures and so are completely board independent, and I was merely thinking in terms of unifying some common code.

This has been suggested before, and the rules have been defined, too:

Such a modification is welcome, if and only if:

- it works on ALL existing boards at least as good as the current code
- it does NOT increase the memory footprint for any board

Quoted 2 lines

Again, I see your point WRT flash.c as a whole, but wouldn't it be useful to for example make flash_print_info common?

I think it would break U-Boot for a couple of boards that live in small memory like a 128 kB EPROM.

Best regards,

Wolfgang Denk

Signature · 3 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
How much net work could a network work, if a network could net work?