Речь идет именно о RS485, UART подключен к микросхеме трансивера RS485. Пин RTS используется для организации полудуплексной передачи.
Если вывод dev_err() поставить перед spin_lock_irqsave(&port->lock, flags); то всё работает.
serial8250_em485_stop_tx
вызывается после передачи только из serial8250_console_write
, а когда всё не работает эта функция не вызывается вообще?serial8250_handle_irq
я вижу, что обработка окончания передачи зависит от того, используется DMA или нет. Используется ли в вашей конфигурации DMA? Работает ли передача, если DMA отключить? почему-то не работает прерывание 0х20 для клавиатуры
во-первых компилятор даёт предупреждение, … , но ошибки не производит. Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi),
objdump -t bootx64.so | grep UND
0000000000000000 *UND* 0000000000000000 inportb
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
в команду линковки чтобы получать ошибку линковки при наличии ссылок на неопределённые символы.-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. Почему бы сразу не блокировать поток вызовом read и не ждать пока данные будут доступны
(в голову приходит только один вариант, когда необходимо принудительно прихлопнуть поток и если использовать таймаут, то не требуется прерывать системный вызов, хотя если принудительно завершить поток, то ядро по идее само прервет системный вызов)
В момент, когда функция read блокирована (по факту системный вызов (syscall) не вернул результат в пользовательское пространство), то при вызове другого системного вызова того же драйвера, например, write, необходимо ли в самом драйвере синхронизировать общие данные, которые используются и в read и в write?
Или выполнение системных вызовов как-то гарантировано регламентировано и прерывания отключены
Возможно ли это сделать на практике?
Сразу скажу, комп у меня слабенький и ждать 3-4 часа чтоб понять что забыл в конце оператора точку с запятой поставить, это не хорошо?!
*.o
. Т.е. можно взять и откомпилировать один файл из дерева исходников ядра. Например: make init/main.o
..c
-- перекомпилируется единственный соответствующий ему файл .o
.как можно тестировать компоненты ядра
ведь есть autosleep!? Подскажите что это за сущность и почему ее нет в современных дистрибутивах?
Для понимания моей проблемы: есть слушающие сокеты и нужно после epoll_wait(). запускать комп из (наверное) ждущего режима
make -C <каталог исходников ядра> \
O=<каталог сборки ядра> \
ARCH=<целевая архитектура> \
CROSS_COMPILE=<префикс кросс-компилятора> \
silentoldconfig
make -C <каталог исходников ядра> \
O=<каталог сборки ядра> \
ARCH=<целевая архитектура> \
CROSS_COMPILE=<префикс кросс-компилятора> \
vmlinux
make -C <каталог сборки ядра> \
M=<каталог исходников модуля> \
ARCH=<целевая архитектура> \
CROSS_COMPILE=<префикс кросс-компилятора> \
modules
Источник ошибки: Исправленная ошибка проверки компьютера