[vpd 0]

Так а почему нельзя искать ключики в %USERPROFILE%/.TI/<any-dir>/0/key? Вообще было бы идеально. А у Вас такие файлики есть?

И вообще, это как-то документировано, где нынче найти установленный композер и узнать, что именно за версия?

Изменено 11 февраля, 2013 пользователем Hoodwin

[Sauris 0]

Нет, не документировано, и не будет документировано, они этим не парятся и не планируют какую то систему.

У меня эти "key" есть, но они появляются не от инсталлятора, а от запуска самого композера и сессий в нем. А то, о чем я выше говорил - инсталлятор создает. А вот почему у Вас не создал (причем Вы пока единственный из пользователей с такой проблемой) я понять не могу. Может быть, Вы какую-то часть не ставите, которая одновременно за это отвечает....

Изменено 11 февраля, 2013 пользователем SAURIS GmbH

[vpd 0]

Не, ну вот сегодня я честно поставил все вообще, выбрав typical install, вообще ничего не менял в штатных настройках, только папочку указал в c:\ti_5.3.

Правда я его сразу запустил. Так что отличить, что там в .TI создалось в какой момент, я не могу.

Такое ощущение, что теперь инсталятор ничего вообще гарантированно не прописывает.

[Sauris 0]

сегодня я честно поставил

 

Сегодня это нельзя назвать честно - русские буквы в пути это нечестно. А вот почему в линуксе нет папки, вот это уже совсем не ясно. Хоть sudo, хоть su, а все равно какой-то "~" и ${HOME} есть. Где то она все таки должна быть :) А по какому пути он у Вас держит в линуксе таргет конфигурейшены, создаваемые по "new target configuration" без проекта? У меня в линухе в том самом "ti", а в винде в %USERPROFILE%/user

Изменено 11 февраля, 2013 пользователем SAURIS GmbH

[vpd 0]

Ну вот нету, факт.

А таргеты тут живут:

/root/user/CCSTargetConfigurations

[Sauris 0]

э... А как они туда попали? Вы в нем из-под рута что-ли работаете? Я бы не решился....

[vpd 0]

Да, и русские буквы в винде - уже давно. Винда уже давно перешла на юникод, и нативные приложения уже давно работают с ними. Но вот некоторые java-программисты, как всегда, всех умнее.

Я помню в ISE 9 от Xilinx был такой глюк в coregen. Они проверяли, хватит ли места на диске таким вот интересным образом: выполняли system("dir") в пустом, вновь созданном каталоге, потом ловили вывод и парсили, сколько там в конце сообщалось свободного места. Ну и вот в английской винде разделителем тысяч была запятая, которую они просто удаляли перед вводом числа. А в русской винде запятая используется в качестве отделения дробной части, а между тысячами пишется пробел. В итоге у них свободного места на диске всегда было не более 1000 байт, так как пробелы они не удаляли. И коры не генерировались. Похоже программисты из Xilinx в TI подались ...

 

э... А как они туда попали? Вы в нем из-под рута что-ли работаете? Я бы не решился....

А, так я просто попробовал. Нет, так я работаю не из рута. Это был ответ на вопрос, где у рута хранятся конфиги таргетов безродных.

 

А так вообще они хранятся в /home/<user>/user/CCSTargetConfigurations, ну или ~/user/CCSTargetConfigurations в общем виде.

 

 

UPD:

 

Честно говоря, проще эти грабли аккуратно документировать, чем пытаться парсить тучу каталогов и файлов, на которые нет никакой документации. Распаковать архив в папочку common - дело абсолютно пустяковое, и это даже, видимо, будет верно для всех CCS 4+, так что треть страницы документации - это гораздо лучше, чем потом пожизненная поддержка для всех версий :)

Изменено 11 февраля, 2013 пользователем Hoodwin

[Sauris 0]

Честно говоря, проще эти грабли аккуратно документировать, чем пытаться парсить тучу каталогов и файлов, на которые нет никакой документации. Распаковать архив в папочку common - дело абсолютно пустяковое, и это даже, видимо, будет верно для всех CCS 4+, так что треть страницы документации - это гораздо лучше, чем потом пожизненная поддержка для всех версий :)

 

Я думаю, что одно другому не мешает. и попарсить все что известно, и сделать мини-инсталлятор отдельный через меню "пуск" - проинсталлировать в конкретный композер. А "архивчики" нынче мало кто понимает, из тех, кто "виндовозы"...

[TSS 0]

Один в один такая проблема возникла неделю назад у моего коллеги.

 

Обновлял композер с версии 5.2 на 5.3, и драйвер Сауриса не видел композера.

 

Тоже пробовал полностью его переустанавливать, результата не принесло.

 

Зато теперь он на Линукс перешёл.

 

Ну и на закуску хохма. Не смог проверить отладку эмулятором. Картинку приложил.

Видели такое. :)

[vpd 0]

Кстати, в линуксе я тоже видел какой-то косяк с SAU510-USB Plus, S/N: #00800. Кажется, проявляется он так. Берем эмулятор, втыкаем в таргет, втыкаем в виндовую машину. В виндовой машине сессия не состоялась по причине глюков винды. Ладно. Выдергиваем эмулятор из виндовой машины и втыкаем в линуксовую. Запускаем композер. У меня в линуксе композер версии 5.0.3. После этого он к таргету не коннектится и тупо повисает.

Вызов вот этого:

[user@user:/opt/ti/ccsv5/ccs_base/common/uscif$ sudo ./xdsprobe -rv -f iso.dat

тоже висит после вывода:

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libsm510usb.so'.

Вначале я пытался это подробнее поисследовать, потом пытался выдергивать эмулятор и из таргета, и из USB, чтобы он полностью обесточился, но он так и не профукался. Потом я перегрузил линукс, и все сразу заработало. Такое ощущение, что у него udev как-то не так отработал.

 

Конечно, это не очень фатально, но как-то линукс перезагружать немного не комильфо.

[Sauris 0]

Вначале я пытался это подробнее поисследовать, потом пытался выдергивать эмулятор и из таргета, и из USB, чтобы он полностью обесточился, но он так и не профукался. Потом я перегрузил линукс, и все сразу заработало. Такое ощущение, что у него udev как-то не так отработал.

 

Чтобы такое устранять, надо получить повторяемость... Да и дистрибутивов то гора - у нас поддержка полная (с исследованием проблем у себя) только для Redhat/CentOS, а для остальных - чем можем, тем поможем на уровне консультации, ну и если однозначно поймется проблема и найдется универсальный путь ее устранения, в дистрибутиве конечно подправим.

 

вообще, в случае чего - "ps -Af | grep sau" и смотрим, что там запущено - когда все ОК - должен sau_proxy. Также смотрим при втыкании, на светодиоды, чтобы предзагрузка софта прошла. Если прокси не запущен, может помочь ручная чистка в /dev/shm с последующим перевтыканием эмулятора заново - хотя вроде я все пытаюсь отслеживать, все падения и неадекватные завершения, но мало ли что...

 

Что касается выдергивания из таргета, для информации, эмулятор от таргета не питается никакими своими частями.

Изменено 12 февраля, 2013 пользователем SAURIS GmbH

[vpd 0]

Что касается выдергивания из таргета, для информации, эмулятор от таргета не питается никакими своими частями.

 

Что, и даже через I/O не сосет через clamping diodes? (У меня версия не ISO.)

[Sauris 0]

Что, и даже через I/O не сосет через clamping diodes? (У меня версия не ISO.)

туда, где может что-то вот такое сохраняться, не насосет, вся "насасывалка" заканчивается в домене питания, которое выдается повторителем от ноги PD, и питает несколько буферов и один IO банк мелкой CPLD, которая в общем то тоже буфер.

[vpd 0]

Ок. Я вообще почти что уже отвязался от эмулятора, он мне нужен теперь только U-Boot прошивать один раз на новой плате.

Постараюсь более пристально обратить внимание на порядок своих действий, когда оно все заклинивает, и его повторить, если снова напорюсь.

Вчера это было под конец дня (всего уже второй раз), но сил уже не было в 22.30 новые исследования разводить. :)

[Sauris 0]

У нас тут, кстати, зреет в недрах консоль для линукса через JTAG без остановов процессора (не CIO) для того, чтобы уарт не занимать под нее, с поддержкой в наших клонах sau-load, u-boot ну и драйвер для линукса разумеется. Спрос на это есть, у кого уартов не хватает. Так что, может быть, еще пригодится.

 

 

Когда повторится, то "ps -Af | grep sau" и список того, что в /dev/shm (да, shm в отдельных дистрах бывает и не в /dev, а в /var например)

Изменено 12 февраля, 2013 пользователем SAURIS GmbH