Внезапный тестпоинт?

Проводил опыты с саспендом usb хоста. Единственное, что понял - система там очень хлипкая, зависит от кучи рейскондишинов и последовательности включения/выключения usb хоста и просыпания/засыпания bp.

И еще словил вот такой замечательный фокус:

[    8.480980] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00130103 PRSC PESC CSC PPS PES CCS
[    8.493472] hub 1-0:1.0: unable to enumerate USB device on port 3
[    8.505488] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0008
[    8.517448] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00030101 PESC CSC PPS CCS
[    8.529480] hub 1-0:1.0: port 3, status 0101, change 0003, 12 Mb/s
[    8.699736] hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x101
[    8.829765] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00100103 PRSC PPS PES CCS
[    8.899751] usb 1-3: new full speed USB device using pxa27x-ohci and address 6
[    9.029666] pxa27x-ohci pxa27x-ohci: GetStatus roothub.portstatus [2] = 0x00100103 PRSC PPS PES CCS
[    9.129612] usb 1-3: ep0 maxpacket = 8
[    9.142082] usb 1-3: default language 0x0409
[    9.151041] usb 1-3: udev 6, busnum 1, minor = 5
[    9.156380] usb 1-3: New USB device found, idVendor=22b8, idProduct=4903
[    9.167987] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    9.180013] usb 1-3: Product: S Blank Neptune LTE2
[    9.185511] usb 1-3: Manufacturer: Motorola
[    9.192990] usb 1-3: uevent
[    9.215618] usb 1-3: usb_probe_device
[    9.222460] usb 1-3: configuration #1 chosen from 1 choice
[    9.249015] usb 1-3: adding 1-3:1.0 (config #1, interface 0)
[    9.262191] usb 1-3:1.0: uevent
[    9.289933] usbserial_generic 1-3:1.0: usb_probe_interface
[    9.302780] usbserial_generic 1-3:1.0: usb_probe_interface - got id
[    9.340334] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0008
[   32.936371] rdy: 1

То есть bp ВНЕЗАПНО перезагрузился и его бут подумал, что флешка чистая, предлагая его шить с ap. Повторить не удалось - все остальные разы bp не хотел подключаться после резюма. На всякий случай - лог этого безобразия: http://pastebin.com/f33b62daa

UPD: опять вылезло. видимо, это не случайный глюк, а закономерный баг. А я был почти уверен, что в этот раз получу обратно модем.
UPD2: и опять...

Прелинкуемся

пока другие воюют с бп, таки вымучал prelink, постиг частично магию кросс-компиляции. На глаз особого профита от использования не заметил, но возможно он и есть. Надо было перед использованием и после сделать замеры :)

для пользования необходимо все разделы фс перевести в rw, положить в /etc http://ezxdev.org/qtopia/tmp_do/prelink.conf , после запустить http://ezxdev.org/qtopia/tmp_do/prelink с ключиком -amR

Как регистр назвали, то он и показывает

PEDR, defined in Table 3-20, indicates which GPIO pin (enabled through the PWER, PRER and
PFER registers) caused a wake-up from standby, sleep or deep-sleep mode. These bits can be set
only by a rising edge, falling edge, or either on the given GPIO pin, depending on the settings in the PRER and PFER registers.

Вобщем показывает на того педр^W^W ту ногу, за которую дернули, чтобы железка проснулась.

Следующий кандидат на жертву двухмесячного марафона "кто больше обматерит этот драйвер" - PCAP. Теперь, при входе в слип, нам мешает он - быстро-быстро вытаскивает обратно.

UPD: все не так страшно - это всего-то драйвер rtc.

Не верь глазам своим: магии не существует

Я все-таки нашел, почему BP не хотел идти спать.

Небольшая предыстория: в телефоне есть два проца AP и BP.

На ap имеем линупс, на bp имеем vrtx. Если кто не в курсе, bp - это LTE2 Neptune (arm7tdmi), огрызок старой платформы, отвечающий за GSM.

У процессоров есть два способа общения: первый - ноги gpio, их пять штук ( bp_rdy, ap_rdy, reset, flash и bp_wdi ), второй - usb.

По usb они гоняют данные, по ap_rdy и bp_rdy они при буте делаеют хендшейк (это их первое назначение). Когда bp что-то хочет от ap, он делает вот такой фокус:

смотрит, не спит ли ap, если спит, то:
ставит bp_rdy в 0, ждет чуть-чуть, ставит bp_rdy в 1 и опять смотрит.

Так до тех пор, пока AP не включится сам и не включит usb.

На это дело (мигание ноги bp_rdy) срабатывает прерывание и ap смотрит, чо там хочет этот убогий.

Если же ap что-то хочет от bp, он просто шлет по usb данные.

Дальше начинается самое интересное: когда ap хочет, чтобы bp ушел спать (сам ap не идет спать, пока bp не спит), он просто саспендит usb порт.

Если bp видит, что ap потормозил порт, но сам он еще имеет чего слать туда, то он саспендит порт, но при этом не саспендится сам, а один раз передергивает bp_rdy.

Когда ap видит, что bp дергает bp_rdy, он шлет по usb запрос на передачу.

Когда ap хочет что-то послать bp (например запрос на передачу), то сначала смотрит не спит ли bp если спит, то он передергивает ap_rdy, а потом уже врубает порт.

Что собственно происходило такого нехорошего и заставляло думать, будто bp не идет спать:

саспендим порт и видим, что дергается bp_rdy. BP не разрешает слип, думаю я.

BP не может отменять слип
BP не отменяет слип
BP совершенно незачем отменять слип
BP тупо пошел и слипнулся, как ему и сказали

...и поставил ногу bp_rdy в нуль.

А какой-то нехороший человек перепутал направление интеррапт лайна и генерит прерывание по переходу 1->0 (надо по 0->1, как в 2.4). В итоге ap думает, что bp отменило слип и врубает порт обратно. AP смотрит, что оно проснулося и спрашивает "нучо?". Тот молчит, потомучто нечего ему слать - он разрешил слип AP, сам тоже пошел спать, а тут к нему пристали.

Естественно, что после изменения типа ноги с IRQ_FALLING_EDGE на IRQ_RISING_EDGE все благополучно прошло.

UPD:... но ap он слипаться все равно не разрешает.
UPD: дергает ap из слипа через раз. ГРР

Прошивка из пингвина

Тем кто вообще не понимает, что такое оффсеты, кодовые группы и прочее, но не имеет маздая под рукой и не хочет вешать его в виртуалке...

Для себя написал скрипт, который всё делает быстро и красиво.
Для работы кроме него потребуется boot_usb, sbf_build и gen-blob.

boot_usb, sbf_build и flash.sh ложим в любую папку из $PATH - например /usr/local/bin/
Естественно на них надо дать права на выполнение.
chmod 755 /usr/bin/{flash.sh,sbf_build,boot_usb}
gen-blob - в /lib/firmware/

Теперь запускаем flash.sh и параметром передаём ему файл прошивки.
flash.sh /home/pupkin/qtopia-ezx-4.3.4_sdhc-30.04.09.sbf

Дальше всё просто - следуем указаниям скрипта и отвечаем на его вопросы.

Если телефон уже находится во флэш-режиме, то на вопрос "gen-blob уже загружен? (yes/no):" отвечаем "no"

Если необходимо прошить только определённые группы, то на "Все CG прошивать? (yes/no):" отвечаем "no". В этом случае перед прошивкой каждой кодовой группы скрипт будет спрашивать.

Т.к. boot_usb для работы нужны рутовые права, то скрипт запускаем либо от имени рута, либо добавляем SUID бит на boot_usb.
chmod +s /usr/bin/boot_usb

Новости

В гите openezx традиционно все сломано. Первая вещь, которая перестала работать (тоже традиционно) - звук... шучу. Звук работает, но интерфейс микшера поменяли и кутопию надо патчить или лезть в alsamixer.

Что хуже - в ванильном ядре что-то такое опять сделали, что BP перестал работать вообще. При чем в самый интересный момент, когда я собрался с мыслями и сделал нормальный невелосипедный субдрайвер для usb-serial. Что там такое произошло - фиг его знает, но надо лезть и разбираться. Последний рабочий коммит - 0533a7bcf9a07863a145c6463985d561be76ef56.

Что еще хуже - даже до поломки BP все равно не хотел уходить в слип, так что я сейчас постепенно пробираюсь в его недра и буду его жестоко мучить, чтобы выяснить, почему именно он дает запрет.

Первые результаты этого вандализма - патч к boot_usb для чтения памяти (флеша) BP. Как оказалось, там все плохо: родной загрузчик проверяет подписи того что пишут (это патчится), того что запускают (это ломается на лету) и не дает возможности читать и писать произвольные адреса и объемы данных.

Читать он дает только флеш BP, да и то не весь (зону PDS не дает), а писать - только определенные кодовые группы, при чем целиком. Придется делать как на EZX и запускать из-под родного бута кастомный (олдскульных мотохакеров с мотофана), при чем запускать через дыру, чем я сейчас и занимаюсь.