[U-Boot] Reg. CFI flash_init and hardware write protected devices
Frank Svendsbøe
frank.svendsboe at gmail.com
Tue May 31 10:35:17 CEST 2011
We have a board that feature NOR flash and hardware write protection
is handled by controlling the write enable pin. When write protection
is enabled, the nWE pin is forced high by external logic. The memory
controller and/or CFI logic is unaware of this, and since CFI uses
write enable as part of the CFI command set, a CFI probing will fail
when write protection is enabled.
The rationale for controlling nWE and not WP (write protection) is
that WP only protects the first sector of the device. In our case this
is less than the size of the bootloader (U-boot), since that occupies
two sectors. Due to this the built-in NOR write protection is rather
useless.
Our current solution based on controlling nWE is to hardcode flash
geometry in board code when flash protection is enabled. In order to
use CFI as intended when write protection is disabled, we call the
generic flash_init function as defined in
drivers/mtd/cfi_flash.c. When protection is enabled we hardcode the
geometry info in board code. In order separate our flash_init and the
generic flash_init, and be able to call both, we've introduced a new
ifdef to cfi_flash.c called CONFIG_CFI_FLASH_OVERRIDE_INIT. Like
this:
----
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 6039e1f..772096e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -176,6 +176,10 @@ u64 flash_read64(void *addr)__attribute__((weak,
alias("__flash_read64")));
#define flash_read64 __flash_read64
#endif
+#ifdef CONFIG_CFI_FLASH_OVERRIDE_INIT
+#define flash_init __flash_init
+#endif
+
/*-----------------------------------------------------------------------
*/
#if defined(CONFIG_ENV_IS_IN_FLASH) ||
defined(CONFIG_ENV_ADDR_REDUND) || (CONFIG_SYS_MONITOR_BASE >=
----
Now, in board code our redefined flash_init will be called. But if
write protection is off, we call the original function,
eg. __flash_init.
Using the preprocessor is often considered bad design. However, the
alternatives here such as adding a weak attribute to flash_init will
not make us able to call the generic/original function. Therefore we
consider adding an ifdef as better design than making the function
weak, and it'll reduce the amount of redundant code in board code.
What do you think about this?
Best regards,
Frank E. Svendsbøe
More information about the U-Boot
mailing list