Как стать автором
Обновить

Комментарии 9

поэтому неплохой способ проверить базовый адрес регистров — это посмотреть посмотреть их в Линуксе

На будущее это можно посмотреть или в dtb файле которое идет с устройством или же в dts файле что идут с ядром :) Там же можно подглядеть адреса регистры и прерывания прочих устройств.

Кажется из dts этот адрес уарта было не достать так просто, он выражался через адрес gpio (надо бы проверить), плюс там ещё есть и другой уарт (который mini) и важно не перепутать, а тут сразу получаешь финальный адрес. Но в целом Вы правы, и я согласен, мы тоже часто смотрим в дтс :)

Вот кусок из DTS


                 uart3: serial@1c28c00 {
                        compatible = "snps,dw-apb-uart";
                        reg = <0x01c28c00 0x400>;
                        interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
                        reg-shift = <2>;
                        reg-io-width = <4>;
                        clocks = <&ccu CLK_APB1_UART3>;
                        status = "disabled";
                };

Регистры и прочее указано. Там разматывать единственное надо. Ну либо распаковывать dtb там он распаковывается в циферки обратно.

Извиняюсь за оффтоп, но может быть здесь получится найти ответ.
На x86 и ARM32 при возникновении исключения SIGSEGV в линуксе есть возможность через машинный контекст узнать, была ли попытка чтения или записи адреса. А на Aarch64 есть ли какой-то внятный способ это сделать, или проще всего декодировать инструкцию, и если это LD/STR, то заглянуть в бит направления передачи?
Ещё раз прошу извинить, если совсем мимо.
Не могу ответить, нужно копаться… А в ARM как узнать чтение или запись? В PSR регистрах я такой информации не вижу.
В структуре ucontext есть машинный контекст uc_mcontext, в котором есть поле error_code.
Его структура описана в репозитории Линукса есть описание битов:
github.com/torvalds/linux/blob/master/arch/arm/mm/fault.h#L10
В машинном контексте ARM64 error_code нету, а в файле github.com/torvalds/linux/blob/master/arch/arm64/mm/fault.c сложно выцепить что-то, что было бы полезно в данном случае.
Пока мыслей кроме как декодировать инструкцию просто нету.
Привет! Приятно видеть людей, которые занимаются такими вещами.
Год назад тоже имел дело с RPi 3B+/3A+. На голом железе.
Кстати, про QEMU — он здесь не всегда поможет, вывод на экран (например) нужно делать на самом железе.
Вообще, плата производит хорошее впечатление.
Компиляцию делал в Aarch64 (aarch64-linux-gnu, но и в других всё работает).
Среда программирования — EmBitz.
На тот момент было — инициализация системы, прерываний, GPIO, последовательные порты, SPI, экраны через HDMI, сторожевой таймер, чтение-запись файлов с SD карты, вывод звука с помощью ШИМ на 3.5 мм аудио разъем.
В качестве терминала (беспроводного) использовал телефон/планшет/часы на Андроиде в качестве указателя (мыши), клавиатуры и экрана через подключенный к последовательному порту RPi BLE модуль HM-11. Устройство управления памятью и кэш программ/данных не реализовал, для моих задач они не нужны, будут только мешать менять коды в памяти, если делать само-модифицирующиеся программы. Многозадачность тоже не сделал (можно было попытаться, хотя).
Здесь и так отлично работают совместно все 4 ядра, алгоритм задачи тоже распараллеливается, что производит в голове новые ощущения :), интересно всё это.
Изготовил электронику для прототипа аппликатора для самоклеящейся этикетки, работает уже год, всё собираются его в серию запустить… В качестве устройства ввода применил энкодер.

В принципе, можно было портировать свою простейшую ОС (StartOS) на Raspberry Pi. Но, дело это нелегкое, на него нужно время, и это время нужно на что-то жить (а спонсоров так и нет).
Пост про неё на Хабре
habr.com/ru/post/276633

Потом занялся нейрочипами, подключил NeuroShield с нейроморфным чипом NM500 по SPI, более 3 Мгц сам модуль не потянул. Сейчас уже есть модули для RPi с такими чипами.
Появилась задача вводить много данных, с камеры, например.
Вот тут и началось — родную камеру подключить — проблема, у них — проприетарный код.
На форуме советовали взять другую камеру и подключить ее по SPI.
Но я пошел по другому пути — в качестве зрения применил Esp32 Cam.
Дальше в лес — больше дров — появился Kendryte K210 RISC-V. И зрение, и слух, и AI с CNN, и Фурье аппаратно. Вот с ним я пока и работаю…

Немного картинок

image

image

image

Вывод на экран, старт через пару секунд после включения


Настольный прототип аппликатора


И вот — Kendryte K210


Удачи всем вам!
Спасибо, интересно!
Да, к210 хорошая штука.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий