2010-12-13 10:10:49     Booting Analog Devices SHARC DSP from BF5xx via SPI

Document created by Aaronwu Employee on Aug 25, 2013
Version 1Show Document
  • View in full screen mode

2010-12-13 10:10:49     Booting Analog Devices SHARC DSP from BF5xx via SPI

Ulrich Hatje (GERMANY)

Message: 96667   




we are in the process of adding some functionality to the spi_bfin5xx.c spi driver that should allow booting a SHARC DSP -- we require this for a custom board setup.


As the code implemented in the SHARC's boot rom interprets the loader file sent via SPI "on the fly", this requires a handshaking via MISO and manual setting of the chip selects. The spi_bfin5xx.c driver already implements some special functionality via MAX_CTRL_CS, so using a "special" chip select (like 254 / 255) to indicate this requirement seems logical.


We already have a driver running that uses cs=255 to entirely disable the drivers chip select functionality with the cs being driven from the high-level driver or even user space in that case -- this can also be used to boot FPGA or other peripherals.


The handshaking via MISO is more tricky though, as it has to be checked after each byte in, e.g., bfin_spi_pio_irq_handler. The MISO pin is assigned to the SPI peripheral on a per-bus basis blocking access via gpio read (to check the MISO state) using the normal kernel gpio functions.


The question is, how this is best handled -- one possibility would be to add some functions to bfin_gpio.c, that would allow "hot switching" the MISO from peripheral to gpio and reading the state, bypassing the frameworks checks for gpio/peripheral pin assignment. These functions could be called from spi_bfin5xx.c, but we are not sure if this is the way to go, as we do not want to run into issues with future updates.


Any thoughts on this are welcome.


Thanks, Ulrich / Algorithmix





2010-12-13 10:47:46     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Mike Frysinger (UNITED STATES)

Message: 96668   


is the SHARC the only device connected to the SPI device ?  if so, you could just write your own driver to manage the pins.  or have userspace claim them all as gpio andthen drive it completely from userspace, although i dont know what kind of speed you'd see with that.


MAX_CTRL_CS only exists to select between hardware CS and GPIO CS behavior.


any modification of existing code is going to cause issues between updates.




2010-12-13 11:15:39     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Ulrich Hatje (GERMANY)

Message: 96671   


There are standard SPI chips (like serial flash memory to boot the Backfin) as well as "custom peripherals" (like SHARC's and FPGA's) connected to the Blackfin SPI busses. We could, of course, go for an own driver that handles all the devices, but it looked tempting to use the existing spi framework as far as possible, as this works very well in general and implements DMA features etc... .


Adding some code that allows to entirely disable cs handling in the existing driver seems easy and is limited to a few places (those with MAX_CTRL_CS actually).


One idea avoiding the "MISO issue" might be to connect all the standard spi peripherals to a single bus, that is serviced by the framework driver and use a custom driver for the remaining busses -- we will probably check that possibility.


Thanks for the feedback,






2010-12-13 13:38:54     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Mike Frysinger (UNITED STATES)

Message: 96672   


if you have other devices, then you cant really have multiple drivers control the SPI bus as the resource framework would prevent it.


reading the SHARC HRM a bit, i'm not sure why you need to do this in kernel space.  it sounds like the ROM on the SHARC doesnt have any behavior hardcoded -- the handshaking protocol is completely up to the designer.  is this correct ?


if so, in what cases would you need to actually pause the transfer ?  do you send a chunk to the SHARC, wait for it to finish the chunk, and then send another ?  or is it like flow control in a UART where things could be held off on a per-byte basis ?  if the former, then you could do this all from userspace via spidev.  just set up a transfer out, and then keep watching the return values.  or use a dedicated GPIO line and poll that from userspace.


the existing cs_change member of a spi transfer should allow you to keep the CS asserted in between transfers without needing to modify the driver ... further, the newer SPI framework includes a bus lock feature so one client can lock the bus for itelf to prevent other spi messages from hopping in there.




2010-12-13 19:02:56     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Ulrich Hatje (GERMANY)

Message: 96673   


You are right concerning the handshaking being theoretically under user control during SHARC boot. A sort of bootstrap is read in automatically by the rom code, which then in turn sets up the peripherals and takes over the transfer of the remaining data.


If, however, you want to use standard ldr files to boot the SHARC (which is a good idea, as this is fast, space saving and seems to be best supported by the Visual DSP build tools) you send out encoded and posibly compressed data from the Blackfin to the SHARC without knowing what each byte you send really means. It may happen, that a certain command tells the Sharc to, e.g., set up a 4 MB data chunk in external DDR Memory filled with zero, which takes a while to process. In such a case the SHARC would signal the Blackfin to hold with the next byte until it is finished and able to process more ldr commands.


This scenario would require a check for the hold condition on a per-byte basis, if one do not want to parse the ldr file also on the sending side to figure out when potential waits may occur. I agree, that all this could be implemented entirely in user space by sending one single byte after another through spidev using ioctl messaging, but booting up 16 Sharcs takes a while then... .


I remember taking a look at bfin_spi_cs_active a while ago and (by measuring cs, clk and mosi) this looked like a possibility to switch between releasing the cs in-between each transferred chunk or holding it for a whole spi message, but still releasing cs immediately once a message is processed (cs release is actually done in bfin_spi_giveback in that case). If a peripheral requires the cs to be tied low for the entire boot process (spanning several spi messages) this probably can not be controlled with bfin_spi_cs_active in the current implementation.


Thanks again for looking into this,






2010-12-13 20:15:42     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Mike Frysinger (UNITED STATES)

Message: 96674   


i'm more than familiar with the Blackfin LDR process, but the SHARC HRM didnt indicate that the hand shaking is part of the bootrom LDR processing.  where in the HRM do you see the handshaking described in actual detail ?  and which HRM ?


i dont think the scenario you describe does require per-byte checking.  it requires per-LDR block checking which is clearly known by the host processor.  and parsing LDR files is trivial to do.


based on that, i dont think the number of slaves to boot is relevant.  you'd see largely the same speed with a kernel driver as a spidev driver.  the only possible difference is if you were doing broadcasting, but it doesnt sound like that is the case.


the CS behavior across messages could be worked around by calculating the delay necessary after each LDR block.  assuming your delays are constant across boots (i.e. you're delaying only with clock initializers, memory fills, etc...), you could set the delay_usecs of each block accordingly.  then you would do a single spi message with multiple spi transfers and each transfer would correspond to a single block.


the advantage of doing this is you can do it all from userspace without needing to patch anything in the kernel and thus should be movable across kernel versions.




2010-12-14 05:48:38     Re: Booting Analog Devices SHARC DSP from BF5xx via SPI

Ulrich Hatje (GERMANY)

Message: 96706   


You are right -- the handshaking is not part of the primary bootrom loader (at least not for the 21469 we are using in the most recent project). It is implemented as a "reporting back" from the Sharc (similar to cts) in the secondary spi example loader code from Analog Devices and we used that in our past projects before moving the Blackfin over to uclinux.


We will go for a userspace solution as you suggested first and see how fast this is. The size of the Sharc code is limited (several 10 k), so this might not be a big deal anyway.


Thanks for pointing us to the delay_usecs -- this is probably the way to go here.


Sticking to the standard driver should allow us to use DMA easily for the later transfers at application runtime, which is far more important than a perfectly fast boot.


Thanks again,