[U-Boot] Environment and SPI drivers

[U-Boot] Environment and SPI drivers

[Albin Tonnerre]

Hello,

The SPI framework provided by u-boot (spi_setup_slave, spi_xfer and the like)
cannot currently be used to read the environment from SPI devices. The reason is
that all the drivers implement spi_setup_slave using malloc(), and malloc()
cannot be used when env_init is called - this happens before mem_alloc_init.

I'm wondering what would be a proper fix for this. I don't think it is OK to say
'drivers reading the environment should not use the SPI framework', as those
drivers might be used to do others things - that would make the SPI framework
unsuitable for (e.g.) any SPI EEPROM. The only sane alternative I can see is
that we introduce spi_setup_slave_$whatever, which would work the same way as
spi_setup_slave, with the difference that it should be given caller-allocated
storage, so that we avoid the use for malloc().

Thoughts ?

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[U-Boot] Environment and SPI drivers

[Wolfgang Denk]

Dear Albin Tonnerre,

In message <20100315192914.GA14032@pc-ran3241> you wrote:
> 
> The SPI framework provided by u-boot (spi_setup_slave, spi_xfer and the like)
> cannot currently be used to read the environment from SPI devices. The reason is

This depends on what sort of SPI devices you are talking about. Do you
have plain simple EEPROM in mind, or things like SPI flash, or
eventually MMC/SDCard?  These are pretty different thinngs...

> I'm wondering what would be a proper fix for this. I don't think it is OK to say
> 'drivers reading the environment should not use the SPI framework', as those
> drivers might be used to do others things - that would make the SPI framework
> unsuitable for (e.g.) any SPI EEPROM. The only sane alternative I can see is
> that we introduce spi_setup_slave_$whatever, which would work the same way as
> spi_setup_slave, with the difference that it should be given caller-allocated
> storage, so that we avoid the use for malloc().

If you are talking about SPI EEPROM, then just enable EEPROM support
and environment in EEPROM, and set CONFIG_SPI. The EEPROM framework in
"common/cmd_eeprom.c" includes support for SPI EEPROM (this actually
predates the SPI framework).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No man knows what true happiness is until he gets married.  By  then,
of course, its too late.

[U-Boot] Environment and SPI drivers

[Albin Tonnerre]

On Mon, 15 Mar 2010 21:25 +0100, Wolfgang Denk wrote :
> Dear Albin Tonnerre,
> 
> In message <20100315192914.GA14032@pc-ran3241> you wrote:
> > 
> > The SPI framework provided by u-boot (spi_setup_slave, spi_xfer and the like)
> > cannot currently be used to read the environment from SPI devices. The reason is
> 
> This depends on what sort of SPI devices you are talking about. Do you
> have plain simple EEPROM in mind, or things like SPI flash, or
> eventually MMC/SDCard?  These are pretty different thinngs...

In this particular case, mostly EEPROM, but that would apply to anything trying
to use the SPI framework before mem_malloc_init is called.

> 
> > I'm wondering what would be a proper fix for this. I don't think it is OK to say
> > 'drivers reading the environment should not use the SPI framework', as those
> > drivers might be used to do others things - that would make the SPI framework
> > unsuitable for (e.g.) any SPI EEPROM. The only sane alternative I can see is
> > that we introduce spi_setup_slave_$whatever, which would work the same way as
> > spi_setup_slave, with the difference that it should be given caller-allocated
> > storage, so that we avoid the use for malloc().
> 
> If you are talking about SPI EEPROM, then just enable EEPROM support
> and environment in EEPROM, and set CONFIG_SPI. The EEPROM framework in
> "common/cmd_eeprom.c" includes support for SPI EEPROM (this actually
> predates the SPI framework).

I know, I did that. The thing is, even with the support for SPI EEPROM, you
need a driver to actually issue the proper commands to read/write data from/to
the SPI EEPROM -- that is, implement spi_read/write. If you do that using the
SPI framework as, I guess, one would expect, then you're screwed since all the
implementations of spi_setup_slave call malloc(), and you can't read your
environment.

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com