All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Gurevich <vag@paulidav.org>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] SPI support in U-boot
Date: Wed, 25 Jan 2006 00:15:59 -0800	[thread overview]
Message-ID: <43D733BF.4030207@paulidav.org> (raw)
In-Reply-To: <20060123104429.5A51D352B2B@atlas.denx.de>

Hello Wolfgang,

Wolfgang Denk wrote:

>They are not "outdated". It's just  a  different  (and  incompatible)
>implementation.  If you can come up with a patch tp cleanup please do
>so.
>  
>
I decided to do that (and it was pretty easy to do), but now I have even 
more questions...

The major issue is the way chip selects are controlled. Currently, 
do_spi() function that implements "sspi" command calls spi_xfer() this way:

    spi_xfer(spi_chipsel[device], bitlen, dout, din)

where spi_chipsel is a global array of pointers to functions that are 
supposed to assert/de-assert chip selects for the specified target(s).

I looked at the code for the boards that use this mechanism, and I can 
see the array statically initialized, like (in board/sacsng/sacsng.c):

    /*
     * The SPI command uses this table of functions for controlling the SPI
     * chip selects: it calls the appropriate function to control the SPI
     * chip selects.
     */
    spi_chipsel_type spi_chipsel[] = {
        spi_adc_chipsel,
        spi_dac_chipsel
    };
    int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);

My question is: where these addresses are relocated? My understanding is 
that relocation for this type of data should be done manually, but 
nowhere in the code can I see it. Not for a single board. That means 
that if people got lucky, they execute the copy of the code from the 
FLASH, not the relocated one.

Is that OK? I also noticed the same mechanism being used in the 
FPGA-related code.

And another question. The current implementation(s) of the "eeprom" 
command assume that there is only 1 SPI device and do not bothr 
themselves with the chip selects at all. That means, that if you try to 
execute "eeprom" command after you executed "sspi" (that will de-assert 
the chip-select at the end or can choose a different one), the results 
will be unpredictable. I have no problem modifying "eeprom" command for 
my board, but this will force other people to do modifications as well, 
so I am not sure what should we do.

Thanks,
Vladimir

  reply	other threads:[~2006-01-25  8:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-23  2:50 [U-Boot-Users] SPI support in U-boot Vladimir Gurevich
2006-01-23 10:44 ` Wolfgang Denk
2006-01-25  8:15   ` Vladimir Gurevich [this message]
2006-01-25 11:16     ` Wolfgang Denk
2006-01-26  6:56       ` Vladimir Gurevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D733BF.4030207@paulidav.org \
    --to=vag@paulidav.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.