[linux][тион270][Багрепорт?] USB slave
laborer
которое мы делаем. Обнаружил, что после
modprobe g_file_storage file=/dev/sda1 (любое устройство, или образ
диска) в терминал валиться куча ошибок, модуль загружается и не
работает:
g_file_storage gadget: File-backed Storage Gadget, version: 28
November 2005
g_file_storage gadget: Number of LUNs=1
g_file_storage gadget-lun0: ro=0, file: /home/file2.data
# usb 1-2: new full speed USB device using pxa27x-ohci and address 27
usb 1-2: device descriptor read/64, error -62
usb 1-2: device descriptor read/64, error -62
usb 1-2: new full speed USB device using pxa27x-ohci and address 28
usb 1-2: device descriptor read/64, error -62
usb 1-2: device descriptor read/64, error -62
usb 1-2: new full speed USB device using pxa27x-ohci and address 29
usb 1-2: device not accepting address 29, error -62
usb 1-2: new full speed USB device using pxa27x-ohci and address 30
usb 1-2: device not accepting address 30, error -62
Ядро 2.6.22, патч linux-2.6.22_tion270_20090122.patch (кстати с вашим
последним патчем для ядра 2.6.22.19 оное собрать не получается).
Хорошо, что я в прошлом году проковырялся немного с этим модулем и
добился, что тогда у меня всё работало.
Проверил ядро с предыдущими патчами, в итоге установил:
с патчем linux-2.6.22_tion270_20081001.patch - модуль работает
нормально.
с патчем linux-2.6.22_tion270_20081201.patch - модуль не работает и
уже появляются ошибки, хотя и другие:
(в системном логе на PC при подключении к нему usb шнурка от платы)
Jun 9 16:26:20 sergeyhost kernel: [29351.582722] usb 6-2: new full
speed USB device using uhci_hcd and address 21
Jun 9 16:26:20 sergeyhost kernel: [29351.738729] usb 6-2: device
descriptor read/64, error -71
Jun 9 16:26:20 sergeyhost kernel: [29351.983988] usb 6-2: device
descriptor read/64, error -71
Jun 9 16:26:21 sergeyhost kernel: [29352.202982] usb 6-2: new full
speed USB device using uhci_hcd and address 22
Jun 9 16:26:21 sergeyhost kernel: [29352.344105] usb 6-2: device
descriptor read/64, error -71
Jun 9 16:26:21 sergeyhost kernel: [29352.601978] usb 6-2: device
descriptor read/64, error -71
Jun 9 16:26:21 sergeyhost kernel: [29352.876691] usb 6-2: new full
speed USB device using uhci_hcd and address 23
Jun 9 16:26:22 sergeyhost kernel: [29353.372289] usb 6-2: device not
accepting address 23, error -71
Jun 9 16:26:22 sergeyhost kernel: [29353.499058] usb 6-2: new full
speed USB device using uhci_hcd and address 24
Jun 9 16:26:22 sergeyhost kernel: [29353.954895] usb 6-2: device not
accepting address 24, error -71
Jun 9 16:26:22 sergeyhost kernel: [29353.954918] hub 6-0:1.0: unable
to enumerate USB device on port 2
Конфиг ядра во всех случаях использовал практически идентичный
(разница в плате colibri, tion270).
Sergey Alyoshin
> Ядро 2.6.22, патч linux-2.6.22_tion270_20090122.patch (кстати с вашим
> последним патчем для ядра 2.6.22.19 оное собрать не получается).
Что именно не получается, ядро или g_file_storage?
> Хорошо, что я в прошлом году проковырялся немного с этим модулем и
> добился, что тогда у меня всё работало.
> Проверил ядро с предыдущими патчами, в итоге установил:
> с патчем linux-2.6.22_tion270_20081001.patch - модуль работает
> нормально.
Это r218.
> с патчем linux-2.6.22_tion270_20081201.patch - модуль не работает и
> уже появляются ошибки, хотя и другие:
Это r285, изменилась конфигурация второго USB, чтобы он работал как host,
вероятно дело в этом.
laborer
получалось собрать с патчем
linux-2.6.22.19_tion270_svn483_200904161555. А вот с патчем
linux-2.6.22.19_tion270_svn483_200904301822 собралось. Но это для меня
кажется очень странным. Изменения между этими патчами, насколько я
понимаю, чисто косметические (делал diff -u и изучал разницу), тем
более вы даже номер ревизии svn не изменили. Ядро собрал, проверил -
ошибка на месте :(
> Это r285, изменилась конфигурация второго USB, чтобы он работал как host,
> вероятно дело в этом.
Изменения конкретно между этими двумя патчами я нашёл. Но ситуация
осложняется тем, что если дальше проследить за вашими патчами, то
видны изменения связанные с работой usb не только в файле tion270.c
(colibri.c) в этом же месте, но и в других файлах.
Резумируя, вы ошибку в последней ревизии вашего патча подтверждаете? И
стоит ли ждать обновлённого патча с исправлением этого бага?
Sergey Alyoshin
>> Что именно не получается, ядро или g_file_storage?
> Ядро в целом. Какая-то ошибка выскакивала на файле dmaengine.h Не
> получалось собрать с патчем
> linux-2.6.22.19_tion270_svn483_200904161555. А вот с патчем
> linux-2.6.22.19_tion270_svn483_200904301822 собралось. Но это для меня
> кажется очень странным. Изменения между этими патчами, насколько я
> понимаю, чисто косметические (делал diff -u и изучал разницу), тем
> более вы даже номер ревизии svn не изменили. Ядро собрал, проверил -
> ошибка на месте :(
В subversion ревизия инкрементируется с каждым commit'ом.
Так что они должны быть одинаковые, но разные благодаря ошибке
в скрипте.
linux-2.6.22.19_tion270_svn483_200904161555 не будет чисто накладываться,
поэтому был сделан 200904301822, той же ревизии.
>> Это r285, изменилась конфигурация второго USB, чтобы он работал как host,
>> вероятно дело в этом.
> Изменения конкретно между этими двумя патчами я нашёл. Но ситуация
> осложняется тем, что если дальше проследить за вашими патчами, то
> видны изменения связанные с работой usb не только в файле tion270.c
> (colibri.c) в этом же месте, но и в других файлах.
Было еще такое изменение
Index: drivers/usb/gadget/serial.c
===================================================================
--- drivers/usb/gadget/serial.c (revision 376)
+++ drivers/usb/gadget/serial.c (revision 393)
@@ -1377,20 +1377,29 @@
usb_ep_autoconfig_reset(gadget);
- ep = usb_ep_autoconfig(gadget, &gs_fullspeed_in_desc, 0, 0, 0);
+ ep = usb_ep_autoconfig(gadget, &gs_fullspeed_in_desc,
+ gs_acm_config_desc.bConfigurationValue,
+ gs_data_interface_desc.bInterfaceNumber,
+ gs_data_interface_desc.bAlternateSetting);
if (!ep)
goto autoconf_fail;
EP_IN_NAME = ep->name;
ep->driver_data = ep; /* claim the endpoint */
- ep = usb_ep_autoconfig(gadget, &gs_fullspeed_out_desc, 0, 0, 0);
+ ep = usb_ep_autoconfig(gadget, &gs_fullspeed_out_desc,
+ gs_acm_config_desc.bConfigurationValue,
+ gs_data_interface_desc.bInterfaceNumber,
+ gs_data_interface_desc.bAlternateSetting);
if (!ep)
goto autoconf_fail;
EP_OUT_NAME = ep->name;
ep->driver_data = ep; /* claim the endpoint */
if (use_acm) {
- ep = usb_ep_autoconfig(gadget, &gs_fullspeed_notify_desc, 0, 0, 0);
+ ep = usb_ep_autoconfig(gadget, &gs_fullspeed_notify_desc,
+ gs_acm_config_desc.bConfigurationValue,
+ gs_control_interface_desc.bInterfaceNumber,
+ gs_control_interface_desc.bAlternateSetting);
if (!ep) {
printk(KERN_ERR "gs_bind: cannot run ACM on %s\n", gadget->name);
goto autoconf_fail;
> Резумируя, вы ошибку в последней ревизии вашего патча подтверждаете? И
> стоит ли ждать обновлённого патча с исправлением этого бага?
Обновления ждать можно, но лучше исправить самостоятельно.
Последнее время USB slave не проверял.
IAP
Я столкнулся с ошибкой в работе USB gadget, когда портировал поддержку
Тиона-Про270 на ядро 2.6.29.
В патчах, начиная с 20090122, 2-й USB порт конфигурируется как хост,
независимо от того, присутствует в конфигурации поддержка USB gadget
или нет.
Например, в патче linux-2.6.22.19_tion270_svn483_200904301822 в
функции tion270_ohci_init видим:
/* Port 2 host */
UP2OCR = UP2OCR_IDON | UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE |
UP2OCR_DMPDE;
UP2OCR_HXOE - включаем передатчик 2-го порта - ок, нужно как для
хоста, так и для клиента.
UP2OCR_HXS - выбираем передатчик хоста, отключая передатчик клиента.
UP2OCR_DPPDE, UP2OCR_DMPDE - конфигурируем подтяжку линий данных для
работы хоста.
UP2OCR_IDON - непонятно, зачем. В коде драйверов USB я нигде не увидел
чтения OTG ID средствами USB контроллера. И более того, документация
на PXA270 рекомендует включать этот бит только на время чтения OTG ID
"для уменьшения энергопотребления".
Восстановить работоспособность USB-клиента можно одним из следующих
способов:
1) Вернув tion270_ohci_init к тому виду, в каком она была в патче
linux-2.6.22_tion270_20081001 (теоретически - я не проверял).
2) Конфигурируя 2-й порт в зависимости от того, требуется ли от него
быть хостом или клиентом.
Перекладывая мою реализацию 2-го способа для 29-го ядра на 22-е ядро
(для патча linux-2.6.22.19_tion270_svn483_200904301822), должно
получиться примерно следующее (исходник из 29-го ядра не привожу, т.к.
конфигурирование USB-хоста в 29-м ядре несколько отличается от 22-го):
1. Опираемся на переменную CONFIG_USB_GADGET_PXA27X: если ядро
собирается с поддержкой USB gadget, 2-й порт будет клиентским, если
без нее - хостом.
2. static int tion270_ohci_init(struct device *dev)
{
pxa_gpio_mode(GPIO89_USBH1_PEN_MD);
#ifndef CONFIG_USB_GADGET_PXA27X
UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
UHCHR = (UHCHR | UHCHR_SSEP3 | UHCHR_PCPL) &
~(UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_PSPL);
UHCRHDA |= UHCRHDA_NOCP;
#else
pxa_gpio_mode(GPIO88_USBH1_PWR_MD);
UHCHR = (UHCHR | UHCHR_SSEP2 | UHCHR_SSEP3 | UHCHR_PCPL |
UHCHR_PSPL) &
~(UHCHR_SSEP1);
#endif
return 0;
}
3. Возможно, в tion270_udc_command нужно управлять битом HXOE в
UP2OCR:
...
case PXA2XX_UDC_CMD_CONNECT:
UP2OCR = UP2OCR_HXOE | UP2OCR_DPPUE;
break;
case PXA2XX_UDC_CMD_DISCONNECT:
UP2OCR = 0;
break;
...
P.S. Приведенный выше код построен чисто умозрительно, на практике на
22-м ядре я его не проверял. Если где ошибся - прошу прощения,
поправьте меня, пожалуйста.