[U-Boot] What is the expected meaning of CONFIG_SYS_NO_FLASH

[U-Boot] What is the expected meaning of CONFIG_SYS_NO_FLASH

[Chris Packham]

Hi,

There is a bit of confusion at $dayjob about when CONFIG_SYS_NO_FLASH
is used. Initially we thought that this meant I have no parallel NOR
flash. So a board with only SPI flash would have CONFIG_SYS_NO_FLASH=1
and CONFIG_SPI_FLASH=1.

Is this understanding correct? I'd like to be able to add a blurb to
README about how CONFIG_SYS_NO_FLASH should be used. Based on what I
can tell from the code there seems to be a requirement that if
!defined(CONFIG_SYS_NO_FLASH) something must implement flash_init(),
flash_write(), etc as defined in include/flash.h. This could be a
driver like cfi_flash.c or a board specific implementation.

Thanks,
Chris

[U-Boot] What is the expected meaning of CONFIG_SYS_NO_FLASH

[Stefan Roese]

Hi Chris,

On 10.06.2015 02:02, Chris Packham wrote:
> There is a bit of confusion at $dayjob about when CONFIG_SYS_NO_FLASH
> is used. Initially we thought that this meant I have no parallel NOR
> flash. So a board with only SPI flash would have CONFIG_SYS_NO_FLASH=1
> and CONFIG_SPI_FLASH=1.
>
> Is this understanding correct?

Yes. CONFIG_SYS_NO_FLASH dates back to a time when only parallel NOR 
flash (like CFI NOR) was available. And it definitely is now confusing 
at least. Perhaps it would be good to rename it to 
CONFIG_SYS_NO_PARALLEL_FLASH now.

> I'd like to be able to add a blurb to
> README about how CONFIG_SYS_NO_FLASH should be used.

Thanks, that would be helpful.

> Based on what I
> can tell from the code there seems to be a requirement that if
> !defined(CONFIG_SYS_NO_FLASH) something must implement flash_init(),
> flash_write(), etc as defined in include/flash.h. This could be a
> driver like cfi_flash.c or a board specific implementation.

Yes, this seems to be a correct assumption.

Thanks,
Stefan

[U-Boot] [RFC PATCH v1] README: Describe CONFIG_SYS_NO_FLASH

[Chris Packham]

Unlike most configuration options defining this actually disables
support for a feature (parallel flash). Eventually the logic behind this
should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes
'#ifdef CONFIG_HAS_PARALLEL_FLASH' but for now lets document the
existing behaviour.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
So this is my attempt to describe (my understanding of) how this option
should be used. Any suggestions for improvement are most welcome.

 README | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/README b/README
index 3b406c2..c3fa549 100644
--- a/README
+++ b/README
@@ -3037,6 +3037,19 @@ CBFS (Coreboot Filesystem) support
 		this is instead controlled by the value of
 		/config/load-environment.
 
+- Parallel Flash support:
+		CONFIG_SYS_NO_FLASH
+
+		Traditionally U-boot was run on systems with parallel NOR
+		flash. This option is used to disable support for parallel NOR
+		flash. This option should be defined if the board does not have
+		parallel flash.
+
+		If this option is not defined one of the generic flash drivers
+		(e.g.  CONFIG_FLASH_CFI_DRIVER or CONFIG_ST_SMI) must be
+		selected or the board must provide an implementation of the
+		flash API (see include/flash.h).
+
 - DataFlash Support:
 		CONFIG_HAS_DATAFLASH
 
-- 
2.3.5

[U-Boot] [RFC PATCH v1] README: Describe CONFIG_SYS_NO_FLASH

[Stefan Roese]

On 10.06.2015 12:06, Chris Packham wrote:
> Unlike most configuration options defining this actually disables
> support for a feature (parallel flash). Eventually the logic behind this
> should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes
> '#ifdef CONFIG_HAS_PARALLEL_FLASH'

Yes, this should be the ultimate goal. But definitely a quite complex task.

> but for now lets document the
> existing behaviour.

Ack.

> Signed-off-by: Chris Packham <judge.packham@gmail.com>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan