07.02.2013
Ввиду тяжелого продвижения и неактуальности проект решено остановить.
08.12.2012
Упал Linux драйвер:
[ 6640.765996] umse 1-1:1.0: umse_int_transfer_callback - invalid length: 0
[ 6640.766830] usb 1-1: USB disconnect, address 11
[ 6640.767021] umse 1-1:1.0: umse_int_transfer_callback - urb shutting down with status: -108
[ 6640.767027] umse 1-1:1.0: umse_stop_transport
[ 6640.767029] umse 1-1:1.0: umse_stop_transport: cancelling URB
[ 6640.776320] BUG: unable to handle kernel NULL pointer dereference at 00000024
[ 6640.776320] IP: [<f9b62a9a>] umse_release+0x2a/0xc0 [umse]
[ 6640.776321] *pde = 00000000
[ 6640.776321] Oops: 0000 [#1] SMP
[ 6640.776321] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0/energy_full
[ 6640.776321] Modules linked in: umse usbtest vboxvideo drm agpgart binfmt_misc vboxsf snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device fbcon tileblit font bitblit snd softcursor ppdev psmouse lp soundcore parport_pc joydev vga16fb serio_raw vboxguest vgastate snd_page_alloc i2c_piix4 parport usbhid hid e1000 ahci
[ 6640.776321]
[ 6640.776321] Pid: 2219, comm: umse_test Not tainted (2.6.32-45-generic #100-Ubuntu) VirtualBox
[ 6640.776321] EIP: 0060:[<f9b62a9a>] EFLAGS: 00010286 CPU: 0
[ 6640.776321] EIP is at umse_release+0x2a/0xc0 [umse]
[ 6640.776321] EAX: 00000000 EBX: f68d3200 ECX: f9b62a70 EDX: edfd86c0
[ 6640.776321] ESI: 00000008 EDI: ef8d5220 EBP: f69d1f44 ESP: f69d1f2c
[ 6640.776321] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 6640.776321] Process umse_test (pid: 2219, ti=f69d0000 task=ee154c80 task.ti=f69d0000)
[ 6640.776321] Stack:
[ 6640.776321] 00000000 f71794a8 00000008 edfd86c0 edfd86c0 00000008 f69d1f74 c020c23f
[ 6640.776321] <0> 00000003 00000000 00000000 f71794a8 ef8d5220 f7172b80 f71794a8 edfd86c0
[ 6640.776321] <0> f68d3000 00000000 f69d1f7c c020c36d f69d1f94 c020889c 00000003 f68d3000
[ 6640.776321] Call Trace:
[ 6640.776321] [<c020c23f>] ? __fput+0xdf/0x1f0
[ 6640.776321] [<c020c36d>] ? fput+0x1d/0x30
[ 6640.776321] [<c020889c>] ? filp_close+0x4c/0x80
[ 6640.776321] [<c0208945>] ? sys_close+0x75/0xc0
[ 6640.776321] [<c01033ec>] ? syscall_call+0x7/0xb
[ 6640.776321] Code: 00 55 89 e5 83 ec 18 89 5d f8 89 75 fc 0f 1f 44 00 00 8b 5a 70 85 db 75 0f b8 ed ff ff ff 8b 5d f8 8b 75 fc 89 ec 5d c3 8b 43 04 <8b> 70 24 83 c0 1c e8 cb 56 88 c6 89 74 24 08 8d 73 0c c7 44 24
[ 6640.776321] EIP: [<f9b62a9a>] umse_release+0x2a/0xc0 [umse] SS:ESP 0068:f69d1f2c
[ 6640.776321] CR2: 0000000000000024
[ 6640.776328] ---[ end trace 1b2334424bbba3bb ]---
[17238.900145] usb 1-1: new high speed USB device using ehci_hcd and address 12
[17239.240234] usb 1-1: configuration #1 chosen from 1 choice
[17239.246756] usbtest 1-1:1.0: FX2 device
[17239.246763] usbtest 1-1:1.0: high speed {control bulk-in bulk-out} tests (+alt)
scg@virt:~/src/umse/trunk/umse_linux_drv$
06.12.2012
Получил устойчивое чтение блоков в тестовой программе, которая работает через libusb. Однако, Linux пока не хочет видеть slave как USB накопитель. Разбираюсь, почему.
Также, из глюков, имеется зависание конечного автомата master'а если прервать slave в середине передачи блока. Пока не могу придумать, где именно следует сбросить состояние master'а, чтобы работа возобновилась автоматически.
04.12.2012
В тестовом окружение отработала команда READ10. Однако, когда я попытался прочитать тот же блок через штатные драйвер и утилиту в передаче блока возникли некоторые проблемы: во-первых группа блоков передается не кусками по блоку, а делится на какие-то неравные части, а во-вторых бывает, что эти части передаются не все. При этом, UMSE в статусе показывает, кто данные переданы успешно. Будем разбираться.
13.11.2012
Наконец-то установлена надежная связь между master и slave. Slave правильно обраатывает все необходимые SCSI команды. Все, кроме READ10.
scg@ebox:~/src/umse/trunk/ums_discovery$ sudo ./ums_discovery
scsi_inquiry()
cbw[31]: 55 53 42 43 01 00 00 00 24 00 00 00 80 00 06 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
data[36]: 00 80 00 01 1f 00 00 00 53 43 47 20 20 20 20 20 55 4d 53 20 45 6d 75 6c 61 74 6f 72 20 20 20 20 30 2e 30 31
csw[13]: 53 42 53 55 01 00 00 00 00 00 00 00 00
scsi_test_unit_ready()
cbw[31]: 55 53 42 43 02 00 00 00 00 00 00 00 80 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
csw[13]: 53 42 53 55 02 00 00 00 00 00 00 00 00
scsi_request_sense()
cbw[31]: 55 53 42 43 03 00 00 00 12 00 00 00 80 00 06 03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
data: 70 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
csw[13]: 53 42 53 55 03 00 00 00 00 00 00 00 00
scsi_read_capacity()
cbw[31]: 55 53 42 43 04 00 00 00 08 00 00 00 80 00 0a 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data[8]: ff 3f 00 00 00 02 00 00
csw[13]: 53 42 53 55 04 00 00 00 00 00 00 00 00
scsi_request_sense()
cbw[31]: 55 53 42 43 05 00 00 00 12 00 00 00 80 00 06 03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
data: 70 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
csw[13]: 53 42 53 55 05 00 00 00 00 00 00 00 00
scsi_inquiry()
cbw[31]: 55 53 42 43 06 00 00 00 24 00 00 00 80 00 06 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
data[36]: 00 80 00 01 1f 00 00 00 53 43 47 20 20 20 20 20 55 4d 53 20 45 6d 75 6c 61 74 6f 72 20 20 20 20 30 2e 30 31
csw[13]: 53 42 53 55 06 00 00 00 00 00 00 00 00
Поскольку, CBW и CSW пакеты (см. USM Mass Storage Bulk-only Transport) имеют нечетные размеры (31 и 13 байт соответственно), то от 16-битного режима FIFO пришлось пока отказаться.
Настало время заняться протоколом UMSE, на котором говорит USB порт master'а.
01.11.2012
Как оказалось, боялся я не зря: на slave отправлялся какой-то мусор. Проблема исчезла с помощью правки wave-формы. Заодно, перевел FIFO шину в 16-ти битный режим. Пришло время заняться приемом. Я-то думал, что про прием я знаю все, но не тут-то было: принимаем всякий мусор. В wawe-форме приемника ошибок пока не увидел. Буду разбираться дальше.
30.10.2012
Наконец-то удалось отправить блок данных от master к slave'у. К сожалению, в документацию к контроллеру вкралась неточность (вернее, непольность), так что пришлось потратить огромное количество времени на то, чтобы найти необходимую последовательность действий. И то, я пока что знаю, что при отправке нескольких байт с master на slave приходит ровно такое же количество, однако содержимое полученного пакета я еще не изучал.
18.02.2012
Сегодня наконец-то master контроллер получил первый CSW запрос от slave контроллера. Не важно, что в самом медленном: асинхронном и 8-ми битном режиме. Главное, что процесс пошел таки в нужном направлении. А скорость мы потом поднимем.
scg@eeebox:~/src/umse/umse_test_libusb$ sudo ./umse_test_libusb
UMS Emulator Test Program
UMSE Block Size: 512
umse_get_state(): umse_phase: 0; massbulk_phase: 0, cbwcb: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
umse_get_state(): umse_phase: 0; massbulk_phase: 0, cbwcb: 55 53 42 43 01 00 00 00 24 00 00 00 80 00 06 12
^Cscg@eeebox:~/src/umse/umse_test_libusb$
Master - это тот, который слева на фотографии. Именно он подключается к серверу. Флешкой прикидывается slave - справа на фотографии. Slave - потому что он переводится в режим Slave FIFO и становится просто преобразователем USB <-> Parallel I/O. Вся логика работы реализуется Master'ом.
04.02.2012
А вот и готовый макет. Под брюхом у него - хитросплетение проводов. Их я снимать не стал.
В качестве EEPROM'а на платы FX2 я впаял, оказывается, чипы на 8КБ, хотя контроллеры имеют 16КБ оперативки. Вчера долго парился с тем, что даже тестовая, незаконченная прошивка не влезает в этот EEPROM. Оказалось, что в библиотеке fx2lib по-умолчанию включена опция отладки, которая: кусь - и отгрызает аж 5 килобайт сразу. Главное, я все это знал. Знал, но забыл... :-(
30.01.2012
Собранные платы выглядят так:
Теперь, в ближайшее время, займусь созданием из них макета. Также, посмотрю, что в репозитории с прошлой весны осталось от попыток написать под это дело прошивку.
20.01.2012
Пришли макетные платы для USB контроллеров Cypress FX2. Буду придумывать UMSE2 с поддержкой USB2.0 High Speed, а то так и не получилось разогнать UMSE1 до нужной скорости.
На самом деле, это уже вторая попытка сделать UMSE2. До этого я пробовал обойтись без макетов, заказав сразу "чистовую" плату. Однако, после того, как на ней последовательно сгорели два FX2 контроллера, я понял, что где-то накосячил с разводкой.
26.12.2011
А вот эксперементв показали, что если поставить capacity хотя бы на блок больше размера ISO файла, то компьютер попытается прочитать этот лишний блок, на что получит ошибку чтения. Linux это еще как-то переживает, а вот Windows диск видить отказывается. После исправления прошивки устройство без проблем увидилось в обеих ОС.
А вот грузиться по-прежнему не получается. :-( В начале, правдв, что-то пытается считываться, но потом все останавливается. Fedora выдает ошибку подсчета контрольной суммы. При попытке чтения блоков, которые читаеются с UMSE при звгрузке с реального диска - они совпадают. В чем проблема - пока не ясно.
18.12.2011
Изучение исходников программы cdrecord показало, что размер дорожки совпадает с размером ISO файла. На два блока больше - общая занятость диска. Видимо, это место занимает lead-in и lead-out. Хотя вряд ли, они ведь в нумерации блоков не участвуют...
Разобрался, почему комп отказывался грузиться с эмулятора CD-ROM. Оказывается, за загрузку с USB отвечает специальний документ. В этом документе, за каким-то чертом изменили формат команды READ TOC PMA/ATIP. В поле CONTROL два старших бита стали означать format B, в котором должно лежать 01b, а поле FORMAT стало называться format A и должно содержать 0. Самое обидное, что результат работы этой новой команды практичеески полностью совпадает с результатом оригинальной MMC3 команды, при FORMAT равной 0001b. Остается только удивляться, как любят придумывать дополнительные проблемы разработчикам составители стандартов.
Небольшая можификация прошивки - и загрузка пошла. Правда, почему-то с ошибками. Попытался выгрузить всю ISO'шку через эмулятор и проверить сумму MD5 с оригинальной ISO'хой: оши сошлись. Теперь, есть подозрение, что ошибка тения не производится при последовательном доступе, а только при Randow Access. Нужно будет проверить.
Еще, стоит разобраться, что отмечает на MODE SENSE CD приводы.
13.12.2011
Попытка сделать из устройства также и эмулятор CD-ROM.
Для этого пришлось сделать не многое:
- поменять поле device_type в ответе INQUIRY на 5h; вообще добавлена возможность хостом установить это поле любым значением;
- добавить обработку запроса READ TOC PMA/ATIP (43h), который возвращает информацию об одной-единственной дорожке.
- увеличил размер блока до 2048 байт: на работу эмулятора флэшки это никак не отразилось, а на CD дисках в режиме Mode-1 блок имеет именно такой размер;
Как это ни странно, но Windows и Linux определили утройство как CD-ROM и без проблем читали с него файлы, однако, загружаться с этого привода компьютер отказался. Во время загрузки, BIOS находит USB CD-ROM.
Вот так выглядят запросы, которые компьютер отправляет эмулятору в момент закрузки:
Определение BIOS'ом
[101759.202321] umse: v2.0:USB Mass Storage Emulator device driver
[101808.362048] umse 2-6:1.0: UMSE_DBG: cbwcb [12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00]
[101808.368041] umse 2-6:1.0: UMSE_DBG: cbwcb [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
[101808.374059] umse 2-6:1.0: UMSE_DBG: cbwcb [03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00]
[101808.380053] umse 2-6:1.0: UMSE_DBG: cbwcb [25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
[101808.386050] umse 2-6:1.0: UMSE_DBG: cbwcb [03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00]
[101810.527913] umse 2-6:1.0: UMSE_DBG: cbwcb [12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00]
Попытка загрузки
[101844.726754] umse 2-6:1.0: UMSE_DBG: cbwcb [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
[101844.732757] umse 2-6:1.0: UMSE_DBG: cbwcb [03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00]
[101844.738750] umse 2-6:1.0: UMSE_DBG: cbwcb [25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
[101844.744755] umse 2-6:1.0: UMSE_DBG: cbwcb [03 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00]
[101846.880624] umse 2-6:1.0: UMSE_DBG: cbwcb [12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00]
[101846.886621] umse 2-6:1.0: UMSE_DBG: cbwcb [43 00 00 00 00 00 00 00 0c 40 00 00 00 00 00 00]
Из этого видно, что компьютер благополучно виснет после ответа на команду READ TOC PMA/ATIP.
Расшифровка последовательности загрузки выглядит так:
- TEST_UNIT_READY
- READ_CAPACITY
- INQUIRY
- READ TOC PMA/ATIP
Ответ на какую-то команду приводит компьютер в замешательство. На данный момент, есть подозрение, что конфликтуют между собой READ_CAPACITY и READ TOC PMA/ATIP, так как обе они сообщают о размере.
Эксперементы показали, что размер дорожки должен быть на два блока больше размера ISO-файла. Каким должна быть вместимость носителя - вопрос остается открытым.
