nanorobot

Да, вопрос был сформулирован сумбурно. Проблема решена,. Причина была в том, что сброс UARTа в регистре BUS_SOFT_RST_REG4 производится не значением 1 в соотв. бите, как в привычных мне STM32 а значением 0. То есть я пытался инициализировать UART, находящийся в состоянии сброса.

вероятнее всего да. Особенно после пары перезагрузок...

да виден. Кроме того я ведь указал что сеггеровскими утилитами коннектится к v3s

OpenOCD новейший, 0.11.0-rc1+dev-00026-gaaa6110-dirty, - преследуется цель отладки Alwinner v3s. JLink лет 7 назад куплен в starterkit.ru, и ранее я активно его использовал. Начиналось (после переустановки системы) всегда с какими то сложностями, но всегда все решалось. Не думаю что самый свежий openocd перестал поддерживать JLink, тем паче что в списке поддерживаемых он присутствует.

Года два не доставал из ящика JLink, пользовался STLink'ом. Сегодня понадобился, и вот: -Error: No J-Link device found. Пересобрал openocd с опцией --enable-jlinк. Соответствующие rules в етс/udev/rules.d обновил. Что я еще забыл? Сеггеровские утилиты установил, JLinkExe работает, к Alwinner v3s коннектится...

Нахожусь в начале пути RT-Thread / Alwinner V3S Скачал с гитхаба RT-Thread и проект bsp_v3s. Удалось запустить проект bsp_v3s на Lichee PI Zero. Сорцев самой ОС в нем нет, взял из первой упомянутой загрузки. Несколько модифицировал проект, запустил три потока, каждый для своего LED. Обнаружил очень приятный бонус - на UART0 сделана консоль, можно выводить отладочные сообщения. Следующим шагом пытаюсь открыть UART2. Процедура rt_device_find(..) его не находит. Посмотрел как описан UART0, тот который для консоли, в драйвере. По аналогии описал UART1 / UART2 поменяв базовые адреса, вектора прерывания, пины Rx/Tx. Включил для каждого из них вызов uart_pin_config(..) в процедуру rt_hw_uart_init(..). После этого rt_device_find(..) стал обнаруживать UART1/2. Но попытка открыть любой из них, для любой комбинации записи/чтения подвешивает систему - LEDы перестают мигать. PS. Попытался по аналогии разобраться с устройством драйверов в скачанной c гитхаба RT-Thread, увидел, что там все иначе. Конфигурирование системы/драйверов идет через Env, что показалось очень удобным. Подозреваю, что у меня конфликтуют версия RT-Thread(самая последняя 4.0.3) с более ранними версиями драйверов из проекта bsp_v3s. Попытался сконфигурировать драйвера из 4.0.3, но обнаружил, (по базовым адресам UART) что сконфигурировать драйвера для V3S там невозможно. Пните в нужном направлении пжлст.. PPS. Посмотрел внимательнее - по другому только на первый взгляд, а так то же самое. Еще эксперимент провел. Если в качестве консоли выбрать UART1 или UART2, то система тоже виснет. Причем во всех случаях вмснет сразу по выходу из процедуры Open(), которая, кстати, возвращает результат = 0, то есть без ошибки

Собственно именно так, или почти так, у меня сейчас и происходит. Программа инита ДДР и загрузки XBOOT. Полагаю, что есть возможность оба этапа совместить в своем приложении, но это высший пилотаж, котрый мне (пока) не по плечу.

Первый шаг сделан. Светодиодиками помигал(бинарник 300 с чем то байт). Многое стало яснее... Но есть и неожиданности. Мигающее приложение загружаю/запускаю в RAM c адреса 0х4000 используя утилиту sunxi-fel. Утлиту для вычисления контрольной суммы заголовка написал сам(уважаемый mantech предложил мне свою, но она под винду, а у меня линукс). Точнее допилил пример с гитхаба который по факту не работал, все время выдавал КС = 0. Эксперимента ради загрузил без вычисления КС, тоже загружается и работает... Возможно я не до конца понял про заголовок и КС - в каком случае они нужны.. Возвращаясь к XBOOT. Использую его в единственном качестве - из него можно загрузить SPL, который инициализирует DDR память и дает возможность используя ту же самую утилиту sunxi-fel загрузить в эту память приложение не ограниченное размером 32к и запустить его. Вероятно есть более прямые пути для этого, но пока мне о них неизвестно(наверное это UBOOT с SPL), и мне удобно использовать этот. При этом не нужен ни UBOOT ни что либо еще. Отдаю себе отчет в том, что эта технология применима только на этапе отладки - ну этот этап еще надолго..

весьма признателен, буду изучать полагал, что инит уарта входит в инит RT-Thread.

сделано под RT-THREAD и не убирались неиспользуемые драйвера и сервисы. Видимо отсюда и весь объем.. само приложение простейшее, мигание лед и вывод в уарт хелловорд

мое приложение > 32k. про заголовок с CRC не в курсе.. запуск через усб (sunxi-fel) заголовка не требует? где прочитать про заголовки с CRC и способы их генерации? upd: разглядел что при запуске через USB заголовок тоже нужен. тем страннее неработа при запуске с SD через UBOOT

Соседний топик разросся и всем надоел. Попытаюсь задать теме новый старт. UBoot с поодержкой ethernet собрать так и не удалось. Помощь уважаемого aaarrr не спасла. Попробовал из текущего uboot два приложнения(свое, и чужое - xboot) запустить с sdcard. С адреса 0x400000000. В обоих случаях результат отрицательный. Свое приложение HelloWord я готов считать насквозь косячным. Но...Приложение xboot при запуске посредством утилиты sunxi-fel с того же адреса 0x40000000 таки работало.. UBoot стандартный, без моих допиливаний. XBoot загружал и запускал следующим образом: load mmc 0:1 0x40000000 xboot.bin go 0x40000000

uboot свежий, экспериментальный....))) git clone -b v3s-spi-experimental https://github.com/Lichee-Pi/u-boot.git спасибо, сейчас попробую CONFIG_SUN8I_EMAC=y менять не пришлось, так и было... // было изменено через menuconfig меняем все #if defined(CONFIG_MACH_SUNXI_H3_H5) и #ifdef CONFIG_MACH_SUNXI_H3_H5 . был единственный #if defined(CONFIG_MACH_SUNXI_H3) - добавлено -|| defined(CONFIG_MACH_SUN8I_V3S) - не помогло

Не удалось в u-boot запустить ethernet. Всегда сообщение 'no ethernet found'. Зато научился u-boot из spi flash запускать..