Почему не работает inportb(0x60)?

Question

[Qreen]

Я пишу простейший "драйвер", если его так можно назвать, для своего ядра (x86_64 архитектура), мне нужно каким то образом прочесть её буффер. Я делаю inportb(0x60), что должно быть аналогично in al, 60h - так я когда-то делал в стареньком 32-битном ядре, которое писалось ещё с загрузчиком для биоса, в таком случае все прекрасно работало. В этом же случае во-первых компилятор даёт предупреждение, что

warning: implicit declaration of function 'inportb' is invalid in C99 [-Wimplicit-function-declaration]
char status = inportb(0x60);

, но ошибки не производит. Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi), превращаю в .iso и запускаю на qemu. Происходит следующее: ядро печатает мое сообщение отладки, переходит к exitbootservices, спокойно завершает его и загружает драйвер клавы - все. Ядро застопилось, дальше дело не идёт, qemu висит с надписью "Exitbootservices...", что является признаком успешного выхода с сервисов UEFI, так что проблема именно в драйвере. Я специально удалил оттуда все строчки, кроме inportb(0x60), но проблема осталась. Без драйвера все отрабатывает спокойно и выключает компьютер, как и должно было быть

Comments

[jcmvbkbc]

Подробностей бы добавить:

Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi),

что в итоге в бинарнике, на том месте, где вызов inportb(0x60)?

превращаю в .iso и запускаю на qemu.

как именно "запускаю на qemu"?

[Qreen]

Вот так вот собирается .efi файлик:

cc -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -fno-stack-protector -fpic -fshort-wchar -mno-red-zone -DHAVE_USE_MS_ABI -c -o forqemu/bootx64.o main/bootx64.c -masm=intel

cc -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -fno-stack-protector -fpic -fshort-wchar -mno-red-zone -DHAVE_USE_MS_ABI -c -o forqemu/graphic.o main/graphic.c

ld -nostdlib -znocombreloc -T /usr/lib/elf_x86_64_efi.lds -shared -Bsymbolic -L /usr/lib /usr/lib/crt0-efi-x86_64.o forqemu/bootx64.o forqemu/graphic.o -o forqemu/bootx64.so -lefi -lgnuefi

objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym  -j .rel -j .rela -j .reloc --target=efi-app-x86_64 forqemu/bootx64.so bootx64.efi

Затем я копирую этот файл на fat32 раздел диска, созданный заранее:

cd ~
sudo mount /dev/sdb3 os
sudo cp ~/Desktop/myos/bootx64.efi ~/os/efi/boot/bootx64.efi
sudo umount os

И собираю образ:

cd Desktop/myos

sudo rm myiso.iso

sudo dd if=/dev/sdb3 of=fat.img

genisoimage -v -J -r -V "TEST"   -o myiso.iso   -eltorito-alt-boot   -e fat.img   -no-emul-boot  fat.img

После этого я запускаю qemu такой командой:

qemu-system-x86_64 -bios OVMF.fd -m 2G -cdrom myiso.iso

, соответственно, загружая OVMF.fd, что дает эмуляцию UEFI.

На первый вопрос, я, к сожалению, не могу ответить. С objdump я работаю плохо, не смог найти ваш запрос. Могу прикрепить его вывод, если нужно

[Qreen]

jcmvbkbc, Только что я понял, почему я не мог найти эту функцию. Более менее все исправил, вот вывод objump (вынес в отдельную функцию только эту строку, для удобного поиска в дизассемблере):

push   %rbp
mov    %rsp,%rbp
sub    $0x10,%rsp
mov    $0x60,%edi
mov    $0x0,%eax
call   9630 <_etext+0x10>
mov    %eax,-0x4(%rbp)
nop
leav
ret

А вот так выглядит функция на си;

void driver() {
int reg = inportb(0x60);
}

Answer 1

[jcmvbkbc]

во-первых компилятор даёт предупреждение, … , но ошибки не производит. Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi),

Дело в том, что у EFI-приложений нет динамической линковки, а неопределённый символ после копирования из .so в .efi просто ссылается в никуда. Если вывести неопределённые символы для bootx64.so, то inportb будет среди них:

objdump -t bootx64.so | grep UND
0000000000000000         *UND*  0000000000000000 inportb

В qemu результат вызова этой функции выглядит так:

Trace 0: 0x7fb15d338e80 [0000000000000000/000000007e6e22de/0x40c2b0]
----------------                      
IN: 
0x7e6e2081:  bf 60 00 00 00           movl     $0x60, %edi
0x7e6e2086:  b8 00 00 00 00           movl     $0, %eax
0x7e6e208b:  e8 90 57 00 00           callq    0x7e6e7820

Trace 0: 0x7fb15d3390c0 [0000000000000000/000000007e6e2081/0x40c2b0]
----------------                      
IN: 
0x7e6e7820:  af                       scasl    (%rdi), %eax
0x7e6e7821:  af                       scasl    (%rdi), %eax
0x7e6e7822:  af                       scasl    (%rdi), %eax
0x7e6e7823:  af                       scasl    (%rdi), %eax
0x7e6e7824:  af                       scasl    (%rdi), %eax
0x7e6e7825:  af                       scasl    (%rdi), %eax
0x7e6e7826:  af                       scasl    (%rdi), %eax
0x7e6e7827:  af                       scasl    (%rdi), %eax
0x7e6e7828:  af                       scasl    (%rdi), %eax
0x7e6e7829:  af                       scasl    (%rdi), %eax
0x7e6e782a:  af                       scasl    (%rdi), %eax
0x7e6e782b:  af                       scasl    (%rdi), %eax
…

С другой стороны, если предоставить такую функцию:

unsigned char
inportb(unsigned short port)
{
        unsigned char v;
        asm volatile ("in {%1|%b0}, {%b0|%1}\n" : "=a"(v) : "d"(port));
        return v;
}

то она прекрасно вызывается и возвращает значение.

Можно добавить опцию -zdefs в команду линковки чтобы получать ошибку линковки при наличии ссылок на неопределённые символы.

Чтобы посмотреть, какой именно код выполняется, я запускаю qemu с монитором в консоли (дополнительным ключом -monitor stdio). Я нажимаю ESC когда в QEMU запускается tianocore и выбираю Boot Manager -> EFI Internal Shell, а там пишу fs0:efi\boot\bootx64.efi, после этого в мониторной консоли включаю логгирование (командами logfile log, log in_asm,exec), после чего нажимаю enter в консоли EFI. После этого можно смотреть в файл log и искать в нём знакомые байты из objdump.

Comments

[Qreen]

Ух ты, сейчас проверю, благодарю за информацию. Не знал такого о efi файлах

[Qreen]

При попытке компиляции на этапе компилирования gcc встроенный ассемблер дает данную ошибку:
Error: operand type mismatch for `in'
Поискав в гугле я нашел вот это: https://stackoverflow.com/questions/27092867/inlin..., но, поменяв in на inb (тк char 8-битный), я не увидел никаких изменений. У вас есть предположения, в чем я ошибаюсь? Функция полностью скопирована у вас, команды компиляции представлены выше, в комментариях.

[jcmvbkbc]

встроенный ассемблер дает данную ошибку:

Qreen, а, да, я выкинул ключ -masm=intel из командной строки компилятора. Поправил ответ.

[Qreen]

jcmvbkbc, только что об этом подумал, спасибо

[Qreen]

Прошу прощения за вопрос не по теме, но, насколько я вижу, у вас высокий уровень знаний в низкоуровневом программировании. Не могли бы вы посоветовать, с чего начать "многоядерный прорыв" в ядре? За месяц пассивного гугления я вычитал, что нужно использовать I/O APIC, отключать PIC и посылать межпроцессорное прерывание, чтобы пробудить остальные ядра. В своем же коде я так и не смог это выполнить, пытался даже на чистом асме писать - не выходит. Нашел также вот такую статью, которая работает в биос, но, из за моей тупости, не смог перенести ее на си под свой код. https://translated.turbopages.org/proxy_u/en-ru.ru...

[jcmvbkbc]

Qreen, я, помню, вот тут писал о том, откуда можно начать с реально рабочим кодом. Моё мнение с тех пор не изменилось: если хочется быстро получить рабочее -- проще всего начать с линукса. Если хочется разобраться самому с нуля, ну не знаю, я бы начал отсюда.

[Qreen]

jcmvbkbc, на моём аккауте несколько человек сидят, я этого не видел, спасибо :)