QEMU MIPS32 - реализация 16550 Uart на специальной плате - PullRequest
2 голосов
/ 22 октября 2019

Я пытаюсь использовать QEMU для эмуляции части прошивки, но у меня возникают проблемы с получением устройством UART правильного обновления регистра состояния линии и отображения входного символа.

Подробности:

Целевое устройство: Qualcomm QCA9533 ( Документация здесь , если вам интересно)

Целевое встроенное программное обеспечение: VxWorks 6.6 с загрузкой U-Boot

Процессор: MIPS 24Kc

Плата: mipssim (модифицированная)

Память: 512 МБ

Используемая команда: qemu-system-mips -S -s -cpu 24Kc -M mipssim –nographic -device loader,addr=0xBF000000,cpu-num=0 -serial /dev/ttyS0 -bios target_image.bin

IЯ должен извиниться здесь, но я не могу поделиться своим источником. Однако, когда я пытаюсь переоборудовать плату mipssim, я внес в код только незначительные изменения:

  • Перебазирован bios область памяти в0x1F000000

  • Изменено load_image_targphys () целевой адрес на 0x1F000000

  • Изменено начальное значение $ pc на 0xBF000000 (отображение TLB из0x1F000000)

  • Заменен mipssim serial_init () ¬call на serial_mm_init (isa, 0x20000, env-> irq [0], 115200, serial_hd (0), DEVICE_NATIVE_ENDIAN) .

Хотя кажется, что serial_init () , вероятно, является принятым в настоящее время стандартом, мне не повезло с его переопределением. Я заметил, что у мальты не было проблем с выводом на тестовое ядро ​​MIPS, которое я дал, поэтому я попытался имитировать то, что там было сделано. Тем не менее, я до сих пор не могу понять, как работает QEMU, и я не могу найти много хороших ресурсов, объясняющих это. Моя работа с источником и включенными документами продолжается, но в то же время я надеялся, что кто-нибудь сможет понять, что я делаю неправильно.

Двоичный файл загружается и выполняется правильно с адреса 0xBF000000, но зависает при обращении к первому циклу опроса UART. Просмотр mtree на мониторе QEMU показывает, что устройство ввода-вывода правильно сопоставлено с диапазоном адресов 0x18020000-0x1802003F, и когда микропрограмма записывает данные в буфер Tx, gdb показывает, что символ успешно записан в память,Последовательное устройство просто не предпринимает никаких действий по извлечению этого символа и его отображению, поэтому прошивка бесконечно опрашивает LSR в ожидании обновления.

Есть ли что-то, чего мне не хватает, когда дело доходит до последовательного / аппаратного обеспечениявзаимодействие в QEMU? Я бы предположил, что переназначения всех существующих функциональных компонентов платы mipssim будет достаточно, чтобы, по крайней мере, заставить работать последовательную связь, тем более что цель использует тот же 16550 UART, что и mipssim. Пожалуйста, дайте мне знать, если у вас есть какие-либо идеи. Было бы полезно, если бы я мог найти способ отладки самого QEMU с помощью символов, но в то же время я не совсем уверен, что я буду искать. Даже советы о том, как решить проблему, будут полезны.

Спасибо!

1 Ответ

0 голосов
/ 25 октября 2019

Ну, после тяжелой работы я получил UART. Ответ на вопрос лежит в функциях serial_ioport_read() и serial_ioport_write(). Эти два метода назначаются в качестве обратных вызовов, которые QEMU вызывает, когда данные считываются или записываются в MemoryRegion для последовательного устройства (которое инициализируется в serial_init() или serial_mm_init()). Эти функции немного маскируют адрес (передаваемый в функции как addr), чтобы определить, на какой регистр ссылаются, а затем возвращают значение из структуры SerialState, соответствующей этому регистру. Это удивительно просто, но я думаю, что все кажется простым, как только вы это поняли. Большим поворотным моментом стало осознание того, что QEMU эффективно реализует последовательное устройство как MemoryRegion со специальной функциональностью, которая запускается при операции с памятью.

В любом случае, надеюсь, это поможет кому-нибудь в будущем избежать кошмара, через который я прошел. Ура!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...