Hi Frank,
On Tuesday 31 May 2011 15:55:56 Frank Svendsbøe wrote:
Understood. But why don't you disable write-protection when you first call flash_init()? And enable the write-protection after the chip is correctly detected?
Simply because disabling write-protection is not impossible after installation. Our device will be located 3000m below sea level.
I see.
As I explained Mike Frysinger, the write-protection settings is not controlled by the PPC device running U-Boot. We can enable write-protection in the lab (by setting a jumper), but not write software.
The whole purpose of this is to keep it "impossible" to destroy a factory default version. For "mutable" software, we utilize another flash.
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.
How is write-protection enabled/disabled on your board?
Two ways/levels: 1) A hardware jumper on the factory default flash. 2) On the non-factory default flash, write protection is enabled/disabled by an FPGA and implicitly and AVR. To make it short, we cannot change protection scheme from U-Boot (but we can via an SPI driver I wrote for Linux).
Theoretically also possible with U-Boot. But I understand that you don't want to do this.
<snip>
Why don't you think that you can't access the original function if it's defined as a weak default? This should work just fine, see for example ft_board_setup() in arch/powerpc/cpu/ppc4xx/fdt.c:
void __ft_board_setup(void *blob, bd_t *bd) { ... } void ft_board_setup(void *blob, bd_t *bd) __attribute__((weak, alias("__ft_board_setup")));
And then this weak default is overridden and still referenced in board/amcc/canyonlands/canyonlands.c:
void ft_board_setup(void *blob, bd_t *bd) { __ft_board_setup(blob, bd); ...
So no need for this ifdef in the common CFI driver. Or am I missing something here?
Oh. I didn't knew I could access the function that was overridden by the weak attribute. I guess that's the alias is for right?
Yep.
If both can be called, I'm happy to remove the ifdef.
I'll test that tomorrow and provide a patch if it works.
Good luck...
Best regards, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de