[ericN 3]

Есть кит OKMX6Q-S3 на базе модуля FETMX6Q (процессор imx6q). Есть ядро linux от производителя, которое временно заливается в модуль FETMX6Q и перепрошивает модуль через usb.

 

Сделали свою плату. Перепрошить модуль не получается. Нашел отличия в выводе dmes в ките и в свое плате:

В рабочем ките

Цитата

2184800.usbmisc supply vbus-wakeup not found, using dummy regulator
usb_otg_vbus: supplied by SWBST
usb_h1_vbus: supplied by SWBST
ci_hdrc ci_hdrc.1: EHCI Host Controller
ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected

после загрузки всего ядра стартует утилита uuc и идет перепрошивка по usb1

Цитата

Starting UTP
uuc 0.5 [built Sep 16 2016 02:36:28]
UTP: Waiting for device to appear
UTP: file/device node /dev/utp already exists
cpu_id is 0
UTP: received command 'send'
UTP: sending Success to kernel for command send.
UTP: received command '$ tar xf $FILE '
UTP: executing "tar xf $FILE "
UTP: sending Success to kernel for command $ tar xf $FILE .
usb 1-1: device no response, device descriptor read/64, error -71

Что я вижу в своей плате

Цитата

2184800.usbmisc supply vbus-wakeup not found, using dummy regulator
usb_otg_vbus: supplied by SWBST
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb_h1_vbus: supplied by SWBST
ci_hdrc ci_hdrc.1: EHCI Host Controller
ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected

и после запуска uuc попывтка перепрошить через usb2

Цитата

Starting UTP
uuc 0.5 [built Sep 16 2016 02:36:28]
UTP: Waiting for device to appear
UTP: file/device node /dev/utp already exists
cpu_id is 0
usb 2-1: device no response, device descriptor read/64, error -71
usb 2-1: device no response, device descriptor read/64, error -71
usb 2-1: new full-speed USB device number 3 using ci_hdrc
usb 2-1: device no response, device descriptor read/64, error -71
usb 2-1: device no response, device descriptor read/64, error -71
usb 2-1: new full-speed USB device number 4 using ci_hdrc
usb 2-1: device not accepting address 4, error -71
usb 2-1: new full-speed USB device number 5 using ci_hdrc
usb 2-1: device not accepting address 5, error -71
usb usb2-port1: unable to enumerate USB device

Т.е. и в ките и в моей плате выполняется одно и тоже ядро, с одним и темже rootfs и с одинаковым DT.

Принципиальные схемы в части usb особо не отличаются.

Кто может сказать, что означают строчки

usb_otg_vbus: supplied by SWBST
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected

в выводе лога? Почему у меня регистрируется новая usb шина, а в ките нет?

[makc 192]

Мне кажется нужно начинать разбираться с того, почему у вас одна строчка про vbus, а в ките их две:

Цитата

usb_otg_vbus: supplied by SWBST

usb_h1_vbus: supplied by SWBST

 

Но без полного лога ядра (dmesg) и без dts это всё гадания на кофейной гуще.

PS: загрузчики в платах одинаковые (u-boot или его аналог)?

[ericN 3]

В 26.06.2022 в 12:19, makc сказал:

почему у вас одна строчка про vbus, а в ките их две:

и у меня и в ките их две. просто у меня между этих строк дополнительно регистрируется шина усб (у меня между этих строк жёлтым выделил).

В 26.06.2022 в 12:19, makc сказал:

Но без полного лога ядра (dmesg) и без dts это всё гадания на кофейной гуще.

вот я и гадаю. dmesg в оттаче. А dts нет. Производитель предоставил готовую сборку. Есть dtd, roots, zImage.

forlinxLog.txt myLog.txt

Изменено 26 июня, 2022 пользователем ericN

[makc 192]

Приведите dtd. Из него элементарно получается dts.

[ericN 3]

а как из dtd получить dts?

imx6q-sabresdNxp.dtb

[makc 192]

dtc -I dtb -O dts -o devicetree.dts devicetree.dtb

[ericN 3]

это же нужно на целевой машине выполнять? Я же не могу на убунте x86 с linux5.15 выполнить конвертацию dtd для ARM-a и linux4? Возможно нужен кросс dtc?

А на целевой во первых отсутствует /usr/bin/dtc, во вторых там в кансоль сыпет постоянно 1-3 сообщения в секунду. Там невозможно даже ls глянуть.

[aaarrr 63]

On 6/26/2022 at 10:54 AM, ericN said:

Я же не могу на убунте x86 с linux5.15 выполнить конвертацию dtd для ARM-a и linux4?

Можете

[ericN 3]

получилос. спасибо.

а что дальше?

В 26.06.2022 в 12:19, makc сказал:

PS: загрузчики в платах одинаковые (u-boot или его аналог)?

да, одинаковые.

 

 

devtree.dts

Изменено 26 июня, 2022 пользователем ericN

[aaarrr 63]

On 6/26/2022 at 10:15 AM, ericN said:

Почему у меня регистрируется новая usb шина, а в ките нет?

Видимо, что-то заставляет на вашей плате usb запускаться в режиме хоста.

[ericN 3]

ну тут процедура какая: стартует апаратный загрузчик usb, прога с ПК по usb заливает в модуль временный линукс и передает управление этому линукс.

 

потом грузится этот линукс (от производителя). Должна запуститься утилита uuc на модуле, которая на ust-otg ждет команды с ПК.

 

На рабочей плате после включения

usb_otg_vbus: supplied by SWBST

ни чего нет.

На не рабочей плате, после включения на usb_otg поднимается хост

usb_otg_vbus: supplied by SWBST

ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected

поэтому uuc начинает ждать команды с ПК по др usb.

Почему может запускаться на usb-otg хост? Исходник драйвера ci_hdrc копать?

ps может на нерабочей плате ещё какойнить дополнительный GPIO "не подтянут"/"подтянут" и поэтому ядро решает что на usb-otg нужно хост поднимать?

[aaarrr 63]

On 6/26/2022 at 12:22 PM, ericN said:

может на нерабочей плате ещё какойнить дополнительный GPIO "не подтянут"/"подтянут" и поэтому ядро решает что на usb-otg нужно хост поднимать?

Вполне вероятно.

[sasamy 9]

On 6/26/2022 at 12:22 PM, ericN said:

ps может на нерабочей плате ещё какойнить дополнительный GPIO "не подтянут"/"подтянут" и поэтому ядро решает что на usb-otg нужно хост поднимать?

там не GPIO а конкретный пин который может выполнять функции USB_OTG_ID, у процессора всего два варианта куда можно скомутировать, на практике все  используют пин GPIO_1 так что с большой вероятностью и на вашем модуле используется он. Для прошивального линукса можно програмно указать в device tree что порт используется в режиме device чтобы не навешивать аппаратные "сопли" для подтяжки, при этом даже не надо знать какой пин используется для OTG_ID

&usbotg {
    status = "okay";
    dr_mode = "peripheral";
};

 

[ericN 3]

В 26.06.2022 в 15:57, sasamy сказал:

Для прошивального линукса можно програмно указать в device tree что порт используется в режиме device

может вопрос глупый, а как обратно из dts сделать dtd? Я обычно это делал с помощью buildroot вместе со сборкой всего линукса.

[makc 192]

2 минуты назад, ericN сказал:

может вопрос глупый, а как обратно из dts сделать dtd? Я обычно это делал с помощью buildroot вместе со сборкой всего линукса.

С помощью того же компилятор - утилиты dtc.