> Im happy to spend the 10 mins updating stellaris.c accordingly, but is > someone sitting on a binary package and brief instructions or some > such to regression test it? Do you of this machine have some sort of > kernel image handy?
I've attached a tarball with some test binaries. They're built from the example libraries shipped with this board. The first exercises the display, amongst other things. The second exercises the SD card. Simple SD card image also included (remember to ungzip it first). "ls" and "cat readme.txt" over the serial port to make it do something verifiable. Run them with: ./qemu-system-arm -M lm3s6965evb -kernel qs_ek-lm3s6965.bin ./qemu-system-arm -M lm3s6965evb -serial stdio -kernel sd_card.bin -sd sdcard.img I don't have any software handy that exercises both simultaneously. It's probably worth mentioning that we don't currently implement the all CS lines accurately for this board. Most pins on this device are dual-function. They can be configured either as regular GPIO, or driven from a periperal (aka "alternate function", e.g. the SSI controller). Config is cone via the GPIO controllers. There are 7 GPIO contollers (A-G) with 8 pins each. On reset all pins are configured as floating GPIO, and we let D0 float high. The frame start/chip select line from the SPI controller goes via GPIO A3. This is connected to the display controller (ssd0323) CS pin. The SD card CS pin is connected to GPIO D0. When comminucating with the display controller the SSI pins will be configured normally. When communicating with the SD card we configure A3 as a GPIO pin, set high (inactive), and pull D0 low to select the SD card. The current implementation ignores the SSI select pin (A3), and assumes the display controller is selected whenever the SD card (D0) is not. We do not implement the alternate function select in the GPIO controller. It's a bit of a strange setup, but I guess probably not that unusual. Paul
