[U-Boot] Reg. CFI flash_init and hardware write protected devices

[Stefan Roese <sr@denx.de>]

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 at denx.de