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
next prev parent 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.