На всякий случай - qemu-user и qemu-system разные вещи, общее у них только TCG:
- qemu-user эмуляция отдельного Linux-приложения. Системные вызовы транслируются в вызовы ядра хоста. Быстро, но работает только под Linux/BSD;
- qemu-sytem (так же называется softmmu) эмуляция целой системы: процессора, памяти, периферии (UART, GPIO, АЦП и т.д.). Именно этот режим позволяет "крутить" операционную систему для другой архитектуры;
Более того следует различать режимы baremetal без MMU где используются физчиеские адреса и с MMU используются виртуальные адреса и памятью управляет ОС.
А -kernel и не должен. Это опция для загрузки U-Boot Proper или Linux kernel после отработки встроенного OpenSBI. А они вообще в S-MODE уже стартуют. Это первое.
Загрузи мне блоб по определнному адресу, и используя первый cpu (у cpu вообще говоря могут быть разные адресные пространства, например imx7d).
-device loader,addr=<address>,cpu-num=0
Принудительно задавай reset-vector указанное значение.
Четвертое, по умолчанию reset_vector для -M virt 0x1000 mrom который потом сам дойдет до 0x80000000 и всё собственно.
А вот если сделать:
$ build-qemu/qemu-system-riscv32 -M virt -bios none -device loader,file=riscv-tests/isa/rv32ui-p-add,addr=0x80001000 -device loader,addr=0x80001000,cpu-num=0 -nographic -serial mon:stdio -s -S
QEMU 11.0.0 monitor - type 'help' for more information
(qemu) info registers
CPU#0
V = 0
pc 80001000
Пожалуйста - принудильно установили PC в 0x80001000 для cpu0.
Про физику писать ничего не буду - там и так всё понятно - вот reset_vector, будь добр чтобы твоя программа начиналась и работала именно с этого адреса. Хотя там можно загрузить через gdb который сам позабодиться о pc === entry_point.
Loading Files
^^^^^^^^^^^^^
The loader device also allows files to be loaded into memory. It can load ELF,
U-Boot, and Intel HEX executable formats as well as raw images.
Более того в данном случае можно запускать с ключём -bios, тоже будет работать.
Если запускать бинарник c произвольным entry point, тогда:
Чтение порта ввода вывода занимает наносекунды, а передача такого события указанными вами способами будет занимать десятки и сотни микросекунд и даже миллисекунды. Разница в десятки тысяч и до миллионов раз.
И что ? Более того, если это I2C GPIO Expander (а это уже не "чтение порта ввода/вывода"), то будет еще дольше - и я не вижу в этом проблемы.
Для некоторых процессов это просто не имеет значения - например выполнить скрипт по кнопке. Для других процессов важна не скорость передачи события, а сама временная метка, которая, как я уже писал, присваивается ядром.
Ваш комментарий мне непонятен, что именно полагается под "ядерным реактором" ?
Подключиться к порту с помощью netcat/socat или пробросить порт по ssh "ssh -R 1500:localhost:1500 user@remote-server.com" ? Ни то ни другое мне не кажется сложной задачей или некими сакральными знаниями.
Так как epoll_wait блокирует поток, в котором он вызывается, до получения каких-либо событий,
Честно говоря не знаю применимо ли это к libcoro и к вашей ситуации, но в Linux есть такие штуки как timerfd, signalfd, а вместо pipe можно воспользоваться eventfd.
Конечно подходит. Но я не только про GD32, а в целом применительно к условно любой модели, которую потребуется создать - очень часто в наличии только TrM (что вообще говоря уже хорошо).
Во-вторых если просто брать дельту между появлением коммита и его Fixes:, без дополнительного анализа это нам вообще НИОЧЁМ не скажет. Например https://patchwork.kernel.org/project/linux-dmaengine/list/?series=856378&state=* - фиксы Intel IO/AT DMA "probing error path", они в приципе были найдены в очень специфических условиях, не опасны и не проявлялись при обычных условиях.
Надо править если нашли ? Безусловно. Критичны ли они ? Безусловно нет.
kvm-qemu или просто qemu (уже давно qemu-kvm не используется как отдельная сущность) или просто KVM - не бывает под неродные архитектуры;
за "неродные архитектуры" отвечает QEMU TCG (user или system) который занимается трансляцией инструкций на лету (да тот же самый JIT с некоторыми трюками, чтобы работать быстрее);
"эмуляция на x86_64 платформе" не только на x86_64, а вообще говоря практически на любой, если же трансляция на архитектуру не поддерживается, есть режим интерпретатора;
QEMU давно вышел за рамки академического интереса и применяется многими сущностями - например тестирование zephyr;
$ git clone https://git.openelbrus.ru/mcst/qemu.git
$ cd qemu
$ ./configure --target-list=e2k-linux-user
$ make
$ build/qemu-e2k --help
usage: qemu-e2k [options] program [arguments...]
Linux CPU emulator (compiled for e2k emulation)
Такие новости это всегда хорошо, тем более что в QEMU добавлена новая архитектура, что редкость и всегда хорошо в качестве примера.
Спасибо МЦСТ, за этот новогодний подарок !
Тем не менее, если я не ошибаюсь, эмулятор был сделан даже до выпуска первого процессора, поэтому интересно почему именно сейчас и почему так поздно это было сделано.
qemu‑system — эмулятор уровня системы, позволяющий запустить целую операционную систему, такую как Linux;
В предоставленном репозитории есть только qemu-user, qemu‑system отсутвует, так как не добавлено ни одной машины.
выпустила в открытый доступ
Очень жаль, что сделано это в отвратительной манере ctrl+c, ctrl+v с затиранием всей оригинальной истории и нахлобучиванием одного коммита в стиле One Patch Man.
Нет, к сожалению, никаких специальных инструментов, только расширение функционала QEMU.
Если порассуждать то в первую очередь пригодилась бы конвертация таблиц из pdf файлов в условно любой текстовый формат, чтобы генерировать код с описанием регистров.
Так же, в нашем случае уже был обширный набор реальных и тестировочных программ, но в случае разработки модели для нового SoC, особенно если у него плохая документация, надо начинать с набора тестов для проверки соответствия поведения моделей с реальным поведением устройств.
На всякий случай - qemu-user и qemu-system разные вещи, общее у них только TCG:
Более того следует различать режимы baremetal без MMU где используются физчиеские адреса и с MMU используются виртуальные адреса и памятью управляет ОС.
А -kernel и не должен. Это опция для загрузки U-Boot Proper или Linux kernel после отработки встроенного OpenSBI. А они вообще в S-MODE уже стартуют. Это первое.
Второе -M virt (впрочем как и другие RISC-V машины в QEMU) по умочанию стартуют с mrom (небольшой код в ~8 инструкций который содержит адрес fw_info -> https://elixir.bootlin.com/qemu/v11.1.0-rc3/source/hw/riscv/boot.c#L483.
Третье - тогда как loader в принципе обходит эту цепочку и его команды означают:
Загрузи мне блоб по определнному адресу, и используя первый cpu (у cpu вообще говоря могут быть разные адресные пространства, например imx7d).
Принудительно задавай reset-vector указанное значение.
Четвертое, по умолчанию reset_vector для -M virt 0x1000 mrom который потом сам дойдет до 0x80000000 и всё собственно.
А вот если сделать:
Пожалуйста - принудильно установили PC в 0x80001000 для cpu0.
Про физику писать ничего не буду - там и так всё понятно - вот reset_vector, будь добр чтобы твоя программа начиналась и работала именно с этого адреса. Хотя там можно загрузить через gdb который сам позабодиться о pc === entry_point.
Не вроде, а так и есть.
Более того в данном случае можно запускать с ключём -bios, тоже будет работать.
Если запускать бинарник c произвольным entry point, тогда:
Что имел ввиду автор я после первого прочтения не понял.
https://github.com/riscv-software-src/riscv-tests без проблем запускаются с ключом -bios=файл или через loader.
Не - он не нужен на самом деле. Просто тогда не получится в “пару кликов”.
Вот например человек на Makefile переделал - https://gitflic.ru/project/ogneyar/amur_c.
Пока мы на клавиатуре “раз-два-три-четыре”, они мышкой “раз-два, раз-два” =).
И что ? Более того, если это I2C GPIO Expander (а это уже не "чтение порта ввода/вывода"), то будет еще дольше - и я не вижу в этом проблемы.
Для некоторых процессов это просто не имеет значения - например выполнить скрипт по кнопке. Для других процессов важна не скорость передачи события, а сама временная метка, которая, как я уже писал, присваивается ядром.
У каждого процесса свои требования.
Ваш комментарий мне непонятен, что именно полагается под "ядерным реактором" ?
Подключиться к порту с помощью netcat/socat или пробросить порт по ssh "ssh -R 1500:localhost:1500 user@remote-server.com" ? Ни то ни другое мне не кажется сложной задачей или некими сакральными знаниями.
Всё правильно и разумно, но у меня есть вопросы к автору:
Как вы думаете, почему такие очевидные и само собой разумеющиеся вещи требуют дополнительного обоснования подобного рода?
Почему вы не развиваете идею дальше и не требуете подробного и исчерпывающего описания коммита ?
Спасибо за статью - прочитал с удовольствием.
Честно говоря не знаю применимо ли это к libcoro и к вашей ситуации, но в Linux есть такие штуки как timerfd, signalfd, а вместо pipe можно воспользоваться eventfd.
Да в таком случае можно автоматом сгенерировать таблицы регистров с использованием RegisterInfo/RegisterAccessInfo. Спасибо!
Да - выглядит неплохо. Жаль, что перестали обновлять.
Конечно подходит. Но я не только про GD32, а в целом применительно к условно любой модели, которую потребуется создать - очень часто в наличии только TrM (что вообще говоря уже хорошо).
Ну во-первых было https://habr.com/ru/news/983898/.
Во-вторых если просто брать дельту между появлением коммита и его Fixes:, без дополнительного анализа это нам вообще НИОЧЁМ не скажет. Например https://patchwork.kernel.org/project/linux-dmaengine/list/?series=856378&state=* - фиксы Intel IO/AT DMA "probing error path", они в приципе были найдены в очень специфических условиях, не опасны и не проявлялись при обычных условиях.
Надо править если нашли ? Безусловно. Критичны ли они ? Безусловно нет.
О как интересно! Я посмотрю сравню.
Видно ответ на мой комментарий.
У вас путаница в голове:
kvm-qemu или просто qemu (уже давно qemu-kvm не используется как отдельная сущность) или просто KVM - не бывает под неродные архитектуры;
за "неродные архитектуры" отвечает QEMU TCG (user или system) который занимается трансляцией инструкций на лету (да тот же самый JIT с некоторыми трюками, чтобы работать быстрее);
"эмуляция на x86_64 платформе" не только на x86_64, а вообще говоря практически на любой, если же трансляция на архитектуру не поддерживается, есть режим интерпретатора;
QEMU давно вышел за рамки академического интереса и применяется многими сущностями - например тестирование zephyr;
Какой ещё CMake в QEMU - его там никогда не было:
Такие новости это всегда хорошо, тем более что в QEMU добавлена новая архитектура, что редкость и всегда хорошо в качестве примера.
Спасибо МЦСТ, за этот новогодний подарок !
Тем не менее, если я не ошибаюсь, эмулятор был сделан даже до выпуска первого процессора, поэтому интересно почему именно сейчас и почему так поздно это было сделано.
В предоставленном репозитории есть только qemu-user, qemu‑system отсутвует, так как не добавлено ни одной машины.
Очень жаль, что сделано это в отвратительной манере ctrl+c, ctrl+v с затиранием всей оригинальной истории и нахлобучиванием одного коммита в стиле One Patch Man.
Это вас "обжиг кабелей" так возбудил или не верите, что платы занимают место в стойке и, о ужас, потребляют электричество ?
А если серьёзно, только пара человек заметила эту ошибку, она веселая и пусть будет как ОДПВ.
Нет, к сожалению, никаких специальных инструментов, только расширение функционала QEMU.
Если порассуждать то в первую очередь пригодилась бы конвертация таблиц из pdf файлов в условно любой текстовый формат, чтобы генерировать код с описанием регистров.
Так же, в нашем случае уже был обширный набор реальных и тестировочных программ, но в случае разработки модели для нового SoC, особенно если у него плохая документация, надо начинать с набора тестов для проверки соответствия поведения моделей с реальным поведением устройств.
Все верно - спасибо ! Чуть позже поправлю.
Опубликовано логическое продолжение "прозрачного" взаимодействия с устройствами внутри QEMU - QEMU: как организовать прозрачное взаимодействие с I2C-устройствами, которая является более удачным применением CUSE.