Hi Jason Sorry for the huge delay, but I had to take a week off and saw your replay just today.
Let me answer some of your questions. "I'm confused why this is here. Was this in the device tree you are using without being disabled? Seems like it is still here. " - Well I'm confused about that too. The PPS is part of the linux image I've installed and I should remove it. It's some sort of bloatware if I understand correctly. The PTP clock thing, is preinstalled in the Linux image I'm using as well, it should be removed along with the PPS. "It should be possible to extract the running device tree using dtc, but I'm not sure of the exact command. 'dtc -I fs -O dts -o ./extracted.dts /proc/device-tree' seg faults for me, which I find really odd." - I have the source of the main DTB. It's really long and hard to read. Also I'm not sure what to look for there. "Anyway, it sure seems like something is up with a conflicting device on spi 0 cs 0." - Now that you say that... There are two devices connected to SPI0 a 4 digit 7 segment display and the TPM. How ever wheter I'm addressing /dev/spydev0.0 or /dev/spidev0.1 the display activates and works it is the addressed device. "Did you disable the universal cape? Might be best if you do. See https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black Disable the setting of enable_uboot_cape_universal=1." - Yes. I disabled it by commenting the entire line in /boot/uEnv.txt. Do you think it's better to have the line active but equal to 0 Like: enable_uboot_cape_universal=0? "Interesting. Any idea what the other spi messages above are then?" I'm not sure if you refer to these: [ 13.605928] *** FUNCTION CALLED: int __init tpm_init(void): major = 0, minor = 0; [ 13.709981] *** FUNCTION CALLED: class_create(THIS_MODULE, "tpm") success. [ 13.857163] *** FUNCTION CALLED: class_create(THIS_MODULE, "tpmrm") success. [ 13.908264] *** FUNCTION CALLED: alloc_chrdev_region(&tpm_devt, 0, 2 * TPM_NUM_DEVICES, "tpmrm") success. [ 14.310132] *** FUNCTION CALLED: struct tpm_chip *tpm_chip_alloc(struct device *pdev, const struct tpm_class_ops *ops); , but they are debug messages I put in some of the functions of the TPM driver. To see if they are being called. "But, does the driver actually implement it? It is odd the driver writer didn't put in the binding information, or did I just miss it?" - Not really. I'm not sure how the driver would expect to be configured to use those pins, but it probably doesn't support interrupt based communication at all. Currently we work on two scenarios. 1. Since udev is responsible for giving the MAJOR and MINOR numbers needed for the driver, and creating the device file. We have to work out why the maj and min numbers are both 0. You input about a conflict is valuable in this regard. 2. Embarrassingly, we realized that the board we are testing which is designed in-house, was never properly tested to see if it works on hardware level. There could be a bad soldering joint or even an error in the very design of the PCB, although that's unlikely. Anyway thanks again for your reply. Feel free to write back if you have an idea or like to know some additional info. I'm going to write again when there's an update. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d723b361-75c0-4c61-85be-06dc4fe12556%40googlegroups.com.
