Boundary Scan Description Language — с помощью такого файла-описания чипа и JTAG Boundary Scan (который как раз был в первую очередь придуман с целью упрощения тестирования плат с большим количеством взаимосвязанных чипов, а не для отладки/прошивки чипов, как многие думают), можно дрыгнуть любой ногой любого чипа, «сидящего на JTAG-chain, считать состояние любого пина и т.д., и все это без знания регистров и внутреннего устройства чипа (т.к. JTAG Boundary Scan-функционал реализован независимо от остальных частей кристалла, включая CPU). Минусом технологии является низкая скорость, т.к. данные последовательно загоняются с первый чип, потом во второй, третий и т.д., и потом возвращаются обратно в JTAG-железку, через которую идет управление.
У меня материнка на чипсете X79 (ASUS P9X79 WS), правда сокет не 2011-3, а первая самая версия. Хакинтош работает отлично — сеть, USB 3.0, звук, все на месте.
Статья хорошая, конечно, но, как правило, установка хакинтоша на новую конфигурацию всегда сопряжена с обильным гуглением, и все покрыть одной универсальной статьёй по-любому не получится. Чего стоит только процедура «отдельного «завода» графики Intel HD», или совсем не освещенная в статье область патчинга ACPI-таблиц и Kext-ов через Clover
А какого развития вы от него ждете? Это же такой же, как и многие другие более «серьезные» отладчики (Flyswatter2, Olimex ARM-USB-OCD, и др.) универсальный отладчик, использующий в своей основе примитивную схему на базе FTDI FT2232, только в нем еще и CPLD есть, что расширяет его возможности по сравнению с вышеупомянутыми аналогами. Кстати, такие отладчики используют в т. ч. в серьезных больших компаниях. Он просто работает, и особо развивать там нечего. Развиваться должен OpenOCD и другой софт, который с такими отладчиками (на FTDI) работает.
А по теме насчет серьезного недорогого отладчика, можно посмотреть на Segger J-Link EDU, J-Link BASE, только не уверен, что он поддерживает MIPSfpga.
UPD: BusyBox теперь запускается. Проблема была в не до конца и не совсем верно портированном коде обработчика асинхронного прерывания в ядре, в результате чего неправильно происходил возврат из обработчика прерывания в код, выполнявшийся до возникновения прерывания.
Тут небольшая ремарка — AVR у автора этого проекта эмулирует 32-битный процессор ARMv5TE. Поэтому не совсем правильно считать, что Linux запускается непосредственно на AVR-процессоре. Скорее в «виртуальной машине» поверх AVR :)
Тулчейн arm-buildroot-uclinux-uclibcgnueabi по-умолчанию собирает исполняемые файлы в формате bFLT для uCLinux и линкует с uClibc-ng. А arm-none-eabi — собирает ELF и ни с чем не линкует. Можно, конечно, использовать один тулчейн. Просто я начал работу с портирования ядра и собирал его первым тулчейном, а после того, как стало ясно, что ядро работает, взялся за userspace, для которого использовал BuildRoot как некий стандарт, а он собирает свой тулчейн по-умолчанию.
Да, конечно. Я пока детально не разбирался, но BusyBox успевает написать в консоль «sh», после чего возникает исключение «undefined instruction», но только на реальной FPGA — в эмуляторе он так и продолжает писать «sh» до бесконечности, плюс выводится сообщение об успешной инициализации источника энтропии. Думаю, решение довольно простое будет, просто пока руки не дошли.
Да, можно и на NIOS2 и на MicroBlaze. Но это не открытые архитектуры и нельзя заглянуть в исходный код. Хотя многие их используют, тот же Altera QSYS позволяет создать систему на кристалле удобно кликая мышкой и не написав ни строчки кода на HDL.
Из того, что «на слуху», можно запустить на некоторых моделях микроконтроллеров STM32. А на FPGA вообще можно и «нормальный» Linux с MMU запустить — главное, чтобы был соответствующий процессор с поддержкой MMU — например MIPSfpga, про который тут несколько раз писали, или OpenRISC, который вообще сложный многоядерный процессор. Вот только проблема с MIPSfpga в том, что, насколько я понял, его нельзя просто так взять и скачать, если ты не студент или преподаватель профильного учреждения.
Ну теперь и WhatsApp придется блокировать, там теперь тоже шифрование :) а это уже вызовет серьезное заметное недовольство миллионов пользователей в этой стране.
Скорее производственный брак, вызванный рядом причин, в т. ч. неравномерным термическим расширением компаунда, которым удерживается кремниевая подложка. Статистика показывает, что от такой болезни чаще других страдают как правило определенные серии определенных микросхем, а не все без исключения. Ну и конечно условия эксплуатации тоже важны — в ноутбуке с забитой пылью системой охлаждения вероятность перегрева чипа и «отвала» выше.
Уже давно все ремонтники говорят, что прогрев видео и других BGA-чипов феном/утюгом допустим только с целью диагностики неисправности, т.к. проблему это если и решает, то только на время, поскольку обычно дело не в «отвале» чипа от платы, а в «отвале» кристалла от основания чипа вследствие многократного термического расширения и сжатия. Под кремниевым чипом там точно такие же шарики, только в несколько раз меньше, и их «перекатать», в отличие от больших шаров на корпусе микросхемы, невозможно.
Тоже мне новость. Всё китайские программы этим грешат, а не только 美图
В последние годы все чаще слышится "если законопроект всё же будет принят, несмотря на...". ИЧСХ, принимают
А по теме насчет серьезного недорогого отладчика, можно посмотреть на Segger J-Link EDU, J-Link BASE, только не уверен, что он поддерживает MIPSfpga.
arm-buildroot-uclinux-uclibcgnueabiпо-умолчанию собирает исполняемые файлы в формате bFLT для uCLinux и линкует с uClibc-ng. А arm-none-eabi — собирает ELF и ни с чем не линкует. Можно, конечно, использовать один тулчейн. Просто я начал работу с портирования ядра и собирал его первым тулчейном, а после того, как стало ясно, что ядро работает, взялся за userspace, для которого использовал BuildRoot как некий стандарт, а он собирает свой тулчейн по-умолчанию.Похоже, проект может не собрать требуемой суммы — осталось всего 5 дней и больше 100 тыс. бабла
серьезноезаметное недовольство миллионов пользователей в этой стране.