vvj

Спасибо - замаунтил! Под sda. Но точно могу сказать что тот флэш который с партишном (sda1) как был с ней - так и отался. Несмотря на форматирование в WXPSP2.

Вы уверены? Вот другая флэшка - только что форматнул в WXP. Как в FAT так и FAT32 - пробовал оба./ $ usb 1-1: USB disconnect, address 5 usb 1-1: new high speed USB device using ST40-ehci and address 6 usb 1-1: Product: Flash Disk usb 1-1: Manufacturer: USB 2.0 usb 1-1: SerialNumber: 91974500ab14b5 usb 1-1: configuration #1 chosen from 1 choice scsi5 : SCSI emulation for USB Mass Storage devices Vendor: USB 2.0 Model: Flash Disk Rev: 0.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 2015231 512-byte hdwr sectors (1032 MB) sda: Write Protect is off sda: assuming drive cache: write through SCSI device sda: 2015231 512-byte hdwr sectors (1032 MB) sda: Write Protect is off sda: assuming drive cache: write through sda:<7>usb-storage: queuecommand called sda1 sd 5:0:0:0: Attached scsi removable disk sda

Да, но что если маунтить нечего? Вот лог подключения usb-винта, который впоследствии успешно маунтится: / $ usb 1-1: USB disconnect, address 6 usb 1-1: new high speed USB device using ST40-ehci and address 7 usb 1-1: Product: Mass Storage Device usb 1-1: Manufacturer: Prolific Technology Inc. usb 1-1: configuration #1 chosen from 1 choice scsi6 : SCSI emulation for USB Mass Storage devices Vendor: TOSHIBA Model: MK8025GAS Rev: KA02 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: assuming drive cache: write through SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: assuming drive cache: write through sda:<7>usb-storage: queuecommand called sda1 sd 6:0:0:0: Attached scsi disk sda А вот лог подключения usb-флэшки: / $ usb 1-1: USB disconnect, address 2 usb 1-1: new high speed USB device using ST40-ehci and address 3 usb 1-1: Product: USB DISK usb 1-1: Manufacturer: SMI usb 1-1: SerialNumber: AA04012700553 usb 1-1: configuration #1 chosen from 1 choice scsi2 : SCSI emulation for USB Mass Storage devices Vendor: SMI Model: USB DISK Rev: 3000 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sda: 252928 512-byte hdwr sectors (129 MB) sda: Write Protect is off sda: assuming drive cache: write through SCSI device sda: 252928 512-byte hdwr sectors (129 MB) sda: Write Protect is off sda: assuming drive cache: write through sda:<7>usb-storage: queuecommand called unknown partition table sd 2:0:0:0: Attached scsi removable disk sda В случае с винтом видно что встал он под sda1, а здесь - unknown partition. Как я понимаю - и маунтить то нечего! А почему партишн анноун - потому как мусор всякий в поле partition->boot_ind. Посмотрите ещё раз линк из первого поста - этот патч на детекцию мсдос партиции на данный день официально "имплементирован" (как покажут исходники Ваших ядер). У винта(и у других флэшек) там в первой структуре 0х80 и по нулям в трёх следующих: если поле отлично от нуля и старший бит стоит - быть здесь мсдос партиции а если не стоИт то это не мсдос -> подбираем тип партиции дальше (и в конечном счёте обламываемся со всеми) Из комментариев к исходникам видно что старший бит означает что партишн активный. Так вот вопрос что это за boot_ind, нафик его проверяют и где вообще про него почитать? В WXP флэшка работает корректно.

Один из имеющихся четырёх флэшек (usb) не мог определиться в linuxе(2.6) - unknown partition. Полез в исходники - в сравнении с другими usb-дисками (жёсткими в том числе) , оказалось что не проходит проверку на старший бит в partition->boot_ind http://kernel.org/pub/linux/kernel/people/...-checking.patch так как там у него "сидит" не 0x80 а 0x20! Тем временем Windowsы работают с этой флэшкой(128M) корректно. Там же форматнул её FATом. Значение boot_ind - которое теперь читает linux - стало 0x6F, а у второй партишн - 0x69 (у "нормальных" флэшек все три следующие по нулям). Форматнул её FAT32ым. Всё то же. Что делать?

Логично. В данном случае железо, спректированное китайцами, изменять не собираются - да и кнопочек там кстати нету. Чип трёхядерный STx7100 - головной ST40(SH4 266MHz) плюс два ST231(400MHz) на видео и аудио стримы. Моя задача добавить туда режим спячки.

именно так и есть, еще и опрос кнопок присуствует Какой второй вариант - бегающий линукс на сниженном клоке? Тогда sdram придётся оставлять вкл. - система грузится больше шести секунд...

Я тоже думал... Но кнопочки парсит то драйвер в Linuxе - и просыпаться система будет от любой кнопочки и пульта! Каким образом система в спящем режиме фильтрует кнопки - просыпается, проверяет и засыпает вновь? А проснётся(загрузится) то тоже не сразу... Одним словом что-то не верится... А телевизор, DVD проигрыватель, SAT тюнер (в данном случае у меня на руках что-то подобное)? Однозначно все они сейчас с какой-либо embedded ОС. Понятно было бы если после IR сенсора стоял бы постоянно работающий микроконтроллер, который в случае обнаружения «своей» комбинации, выдавал системе тот самое прерывание. Но ведь это бред – везде IR подключен напрямую к RX ножке соотв. UARTа на чипе(системы на чипе).

Вроде было всё понятно. Но подвернулась система бегающая на портированном Linux - имеются и flash и sdram и кроме всего прочего IR порт. С отключением понятно - поймали с пульта на IR порту power кнопку и поотключали периферию и сами пошли спать. А кто будет ловить нажатие кнопки power на пульте? Ну получу я прерывание выводящие из сна – ну а дальше? Успею ли проверить пришедшее на IR? А если sdram отключать? Тогда заново систему надо грузить. Получается «спать» нельзя – надо в «заторможенном» состоянии выполнять проверку приходящего с IR на предмет power-батона, а с отключенной sdram вся эта ботва в кэше должна выполняться? Гемор какой-то получается… Может у кого есть опыт со всякими «спящими» DVD-проигрывателями и прочими приставками? Что там у них происходит когда они спят и в тоже время моментально реагируют на пульт?

Благодарю, пока и просто заработало :) Если кто знает - как в этот buidroot "врезать" компиляцию ядра? Вроде работает, но при смене компилятора надо будет ядро отдельно (заново) компилить... Да и ещё - как вместо ucLib-ов, gcLib-ы подставить? А то серьёзному софту стоковые либы "малы".

http://buildroot.uclibc.org/ Если кто пользуется, интерено узнать выбираемые параметры(опции и версии пакетовв в menuconfig) под AT91RM9200. Интересно что даже по умалчанию (выставил только архитектуру) собранный в руте busybox не запускается ядром (с OABI). Да и последующие эксперименты ни к чему не привели (пробовал EABI ядро, POSIX threadы и т.п.) :angry2:

а вот ещё "прикол": SSC_TCMR = 7000004 (PERIOD = 7, CKO = 1) SSC_TFMR = 50008f (DATLEN = 0xF, MSB, FSOS = 5) т.е. TF(фрейм) должен toggle'ить каждые 16 бит посылаю 0xFFFF, 0x0000, 0x5555, 0xF0F0, 0xAAAA, 0x0A0A используя PDC. на картинке данные наверху, фрейм внизу :cranky:

Регистры конфигурю следующим образом: TCMR = f000004 (PERIOD = 0xF) TFMR = 13018f (DATALEN = 0xF, MSBF, DATNB = 1, FSLEN = 3, FSOS = 1) Посылаю : 0xFFFF, 0x0000, 0x5555, 0xF0F0, 0xAAAA, 0x0A0A (через PDC, т.е. используя DMA) На осциллографе - сверху данные - снизу TF(фрейм) никак не соотносится с графиком со стр 465 (doc1768.pdf) - данные как минимум сразу или после фрейма

AT91RM9200 - system on chip. ARM 920T с DMA, MMU и туевой хучей периферийных интерфейсов. будет использовасться в том числе для вывода аудио на кодек, используя SPI и I2S. OS - linux 2.6 с патчем от san people'ов Беда такая: всё нормально если мапишь регистры и пишешь туда по одному байту - всё приходит - осциллограф подтверждает. А если используешь SPI драйвер - приходит не всегда(мой пост в форуме ARM) Можно также использовать DMA контроллер, который обслуживает все периферийные интерфейсы (т.е. контроллеры) - там у каждого соотв. группа регистров для "запуска" передачи/приёма. Но туда надо указывать физ. адрес буфера (как DMA используется в линуксе "цивильным" образом - пока непредставляю) ... ну это я имел ввиду буфер с аудио потоком, адрес и размер которого надо задать в регистры DMA группы. Может с DMA всё это надо по другому делать?

а вот ещё такой вопрос: дружит ли MT-Link с embedded-линуксом? у меня - не дружит. загружаю UBoot - JLink адекватен и JMem'ом также можно просмотреть память. гружу linux_kernel (2.6) - JLink ругается ****** Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Co mmand : 2). Unable to halt ARM core. Most common causes are: a) No CPU clock b) CPU blocked (nWait active) c) Ice breaker (Embedded Ice macrocell) disabled (DBGEN ... Jumper setting ?) память прочитать невозможно - Could not read memory. причины пока непонятны

http://lists.arm.linux.org.uk/pipermail/li...ary/007102.html тут на англоязычном линке у товарища такая же беда: делаешь устройство SPI, пишешь туда, а осциллограф гонит одни нули - кол-во переданных байт верное. Допустим, пишу 3 short'а - 0x0000,0xFFFF,0x5555.А приходит 0x0000,0x0000,0x5555. И только первый раз (после ребута). Подскажите как пользоваться SPI драйвером в 2.6 ядре с санпипловским патчем? Видел пример в uCLinux, но здесь не нашёл подобных дефайнов для использования с ioctl(). Сейчас просто открываю dev и пишу туда. То есть конфигурация default.