Проблемы со SPIDEV, деревом устройств и именем .dtbo с Beaglebone Black

У меня странная проблема с деревом устройств. Я обнаружил, что изменение имени .dtbo изменило поведение ядра!

Я изменил файл BB-SPIDEV1-00A0.dts, указанный в / lib / firmware, с помощью Angstrom:

/*
 * Copyright (C) 2013 CircuitCo
 *
 * Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "BB-SPI1-01";
    version = "00A0";

    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */
        "P9.31",    /* spi1_sclk */
        "P9.29",    /* spi1_d0 */
        "P9.30",    /* spi1_d1 */
        "P9.28",    /* spi1_cs0 */
            "P9.42",    /* spi1_cs1 */
        /* the hardware ip uses */
        "spi1";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            /* default state has all gpios released and mode set to uart1 */
            bb_spi1_pins: pinmux_bb_spi1_pins {
                pinctrl-single,pins = <
                    0x190 0x13  /* mcasp0_aclkx.spi1_sclk,  OUTPUT_PULLUP | MODE3 */
                    0x194 0x33  /* mcasp0_fsx.spi1_d0,      INPUT_PULLUP | MODE3 */
                    0x198 0x13  /* mcasp0_axr0.spi1_d1,     OUTPUT_PULLUP | MODE3 */
                    0x19c 0x13  /* mcasp0_ahclkr.spi1_cs0,      OUTPUT_PULLUP | MODE3 */
                    0x164 0x12  /* eCAP0_in_PWM0_out.spi1_cs1   OUTPUT_PULLUP | MODE2 */
                    0x1A0 0x32  /* Other P42 pin, INPUT_PULLUP */
                >;
            };
        };
    };

    fragment@1 {
        target = <&spi1>;   /* spi1 is numbered correctly */
        __overlay__ {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&bb_spi1_pins>;

            #address-cells = <1>;
            #size-cells = <0>;

            spi1_0{
                #address-cells = <1>;
                #size-cells = <0>;

                compatible = "spidev";

                reg = <0>;
                spi-max-frequency = <16000000>;
            };


            spi1_1{
                #address-cells = <1>;
                #size-cells = <0>;

                compatible = "spidev";

                reg = <1>;
                spi-max-frequency = <16000000>;
            };
        };
    };
};

Я скомпилировал его под два имени: BB-SPIDEV1-00A0.dtbo и BB-SPI1-01-00A0.dtbo

Когда я загружаю один из них в /sys/devices/bone_capemgr.9/slots, spidev ведет себя иначе!

С BB-SPIDEV1 spidev1.0 работает без проблем. Но выбор микросхемы spidev1.1 не работает! Штырь 42 находится в неправильном режиме, и штифту не назначен spi1

С другой стороны, у BB-SPI1-01 (это имя не важно, другое имя - то же самое, просто оно должно отличаться от BB-SPIDEV1) вывод 42 хорошо распределен:

root@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux# cat pinmux-pins | grep spi
pin 89 (44e10964): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 100 (44e10990): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 101 (44e10994): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 102 (44e10998): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 103 (44e1099c): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 104 (44e109a0): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins

и в хорошем режиме:

root@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux# cat pins | grep 964
pin 89 (44e10964) 00000012 pinctrl-single 

НО на этот раз spidev1.0 не работает должным образом. Строка MISO (т.е. вход для BBB) видит только 0, даже если это ложь (я проверил с помощью осциллографа).

Так в чем может быть проблема?

заранее спасибо


person user3714405    schedule 10.06.2014    source источник
comment
Ваш dts выглядит почти идентично исходному источнику BB-SPIDEV1-00A0, за исключением того, что отсутствует строка: spi-cpha; находится во фрагменте 1, канал 0, под spi-max-frequency, и есть несколько отличий в мультиплексировании ваших контактов: SPI1_SCLK может быть INPUT_PULLUP , также я не вижу никакой связи между P9_42B (0x1A0) и подсистемами SPI - вы можете смешивать его с P9_42A (0x164), который имеет SPI1_SCLK (режим 4) и SPI1_CS1 (режим 2). Режим 2 P9_42B - «MCASPO_AXR2».   -  person TekuConcept    schedule 23.06.2014
comment
Я вижу, что P9_42B должен быть установлен как INPUT, поэтому вместо этого попробуйте режим 4 (который направляет его ни к чему): 0x34 ... или режим 7, который является gpio 0x37   -  person TekuConcept    schedule 23.06.2014
comment
ничего из этого не сработало ... Я попробовал режим 4, режим 7, установив SPI1_SCLK как INPUT_PULLUP, добавив spi-cpha, такое же поведение. Выбор второго чипа при загрузке в любом случае невысокий, в отличие от первого.   -  person user3714405    schedule 23.06.2014
comment
Но спасибо за ответ! В любом случае, это не решает проблему с другим именем   -  person user3714405    schedule 23.06.2014
comment
Думаю, я знаю, в чем проблема: все контакты 100-103 и 89 мультиплексируются с multichannel audio serial port subsystem 0 [mcasp0] при запуске как часть наложения BB-BONELT-HDMIN. Чтобы удалить наложения HDMI, следуйте инструкциям внизу этой страницы: tekuconcept.blogspot.com/2014/02/gpio-beaglebone-and-bash.html, а затем посмотрите, что произойдет.   -  person TekuConcept    schedule 24.06.2014
comment
Они уже отключены, у меня в uEnv.txt есть эта команда: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN И есть выгруженные (я вижу это с cat $SLOTS). `   -  person user3714405    schedule 24.06.2014


Ответы (2)


Установите P9_42B в режим 4 с высоким импедансом (0x2C) - в противном случае по умолчанию используется режим 4 Fast-In Pull-Down. Если этот вывод не изменен другим оверлеем, мультиплексирование для P9_42B не требуется.

Регистры SPI1 (а также SPI0, I2C и GPIO2) выдавали мне ошибки шины, когда я обращался к их регистрам, что приводило к отключению устройства (устройств), несмотря на то, что их статус был установлен на «нормально» в соответствующем оверлее. Я проверил регистр CM_PER и убедился: IDLEST=3 [disabled] и MODULEMODE=0 [disabled]. Хотя эти тесты проводились в системе Debian, я почти уверен, что то же самое касается Angstrom и всех других дистрибутивов.

Чтобы включить их, вам потребуется доступ к адресам памяти для управления питанием и синхронизацией на предпочтительном языке по вашему выбору:

Через сборку PRU:

.origin 0
.entrypoint START

START:
    MOV  r0, 0x44E00050 // CM_PER_SPI1_CLKCTRL Register [reset = 30000h / disabled]
    LBBO r1, r0, 0, 4   // load register value
    CLR  r1.t16         // set IDLEST to FUNC
    CLR  r1.t17
    SET  r1.t1          // set MODULEMODE to ENABLE
    SBBO r1, r0, 0, 4   // store value
    HALT

Через Python:
Beaglebone IO с использованием Python mmap

Через C / C ++: (аналогично приведенному выше примеру Python)
Ссылка на: vabi-robotics.blogspot.com

#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <stdio.h>
#include <iostream>
#define CM_PER 0x44E00000 //PG 157

using namespace std;

int main(){
    int fd = open("/dev/mem",O_RDWR | O_SYNC);
    ulong* pinconf1 =  (ulong*) mmap(NULL, 0x0FFF, PROT_READ | PROT_WRITE, MAP_SHARED, fd, CM_PER);

    printf("INFO: %X\n", pinconf1[0x50/4]);
    pinconf1[0x50/4] = 0x00000002;
    printf("INFO: %X\n", pinconf1[0x50/4]); // conf. initialized

    return 0;
}

Примечание. Если проблема не в этом и один канал действительно работает, убедитесь, что канал отключен, прежде чем включать следующий канал. Также убедитесь, что бит MS сброшен [master], бит PIN34 сброшен [SPIEN используется для выбора микросхемы], а SINGLE бит сброшен [подробнее используется более одного канала] в регистре MCSPI_MODULCTRL (SPI1: 0x481A0128)

person TekuConcept    schedule 25.06.2014
comment
Извините за поздний ответ, мне пришлось прочитать обо всех регистрах, о которых вы говорили. Ну, регистр 0x44E00050 равен 3000h (сброс), когда я его читаю, но когда я его читал ВО ВРЕМЯ передачи с spidev, это 02h, поэтому spidev должен включить регистр itslef, когда он ему нужен. - person user3714405; 03.07.2014
comment
Что касается регистра MCSPI_MODULCTRL, я не могу прочитать его без передачи (ошибка шины). Когда я его читаю, это 1 час, это означает: 1 час = В основном режиме будет использоваться только один канал. Этот бит должен быть установлен в режиме Force SPIEN. Фактически, я использую один канал, я просто хочу выбрать другой Chip select (SPIEN в документе). Но я не могу найти регистры, говорящие о различном выборе чипа (SPIEN) и их использовании. - person user3714405; 03.07.2014
comment
Скомпилируйте файл * .c по следующей ссылке на кости: github.com/ TekuConcept / BBB_Backup / tree / master / workspace /, загрузите сценарий * .sh в терминал (›source script.sh), а затем выполните команду:› readm 0x44E00000 0 (считывается из регистра CM_PER_L4LS_CLKSTCTRL) и дайте мне возвращаемое шестнадцатеричное значение. Если значение выглядит примерно как 0x4102, то причина в том, что ICLK и FCLK заблокированы, и устройство находится в режиме IDLE. (ICLK - это то, что позволяет получить доступ к регистрам устройства) - person TekuConcept; 06.07.2014
comment
Как и раньше, значение отличается, когда моя программа SPI запущена, а когда нет. 0x4102, если он не запущен, и 0x2004102, если он запущен (что означает, что spidev используется). - person user3714405; 07.07.2014
comment
›Writem 0x44E00000 0 0; writem 0x44E00000 50 2; Тогда вы сможете получить доступ к интерфейсу McSPI, даже если он не используется (мультиплексирование не требуется). 0x481A0000 12C и 140 [MCSPI_CHXCONF.FORCE / .EPOL] - регистры, зависящие от канала, которые управляют SPIEN. Кроме того, чтение из регистра MCSPI_MODULCTRL дает значение 0x4, что означает, что устройство находится в режиме Master / ChipSelect, а также в режиме SYSTEST по умолчанию. - person TekuConcept; 07.07.2014

Ну что ж, снова я сам отвечаю на свой вопрос. На самом деле проблема заключалась в следующем: мне не удалось использовать второй выбор микросхемы канала SPI 1 (spidev.1.1). Когда я попытался это сделать, возникла проблема с именами dtbo, и я разместил этот вопрос. Однако проблема с названием еще не решена.

Но проблема

НО на этот раз spidev1.0 не работает должным образом. Строка MISO (т.е. вход для BBB) видит только 0, даже если это ложь (я проверил с помощью осциллографа).

решено изменением режима Часов: 0x33 вместо 0x13. Хотя это выход, установка 0x33 изменит вывод на RXACTIVE_PULLUP. Этот способ получения данных должен быть включен.

Странно то, что 0x13 отлично работал с BB-SPIDEV1 ...

Спасибо TekuConcept за помощь с регистрами, если у меня будет несколько лишних раз, я попытаюсь покопаться в регистрах.

person user3714405    schedule 08.07.2014