RTL871x ROM-BIOS

[pvvx]

У RTL8711AM, RTL8711AF, RTL8710AF коды в ROM-BIOS идентичны.
Наконец разобрал коды и данные ROM...
Теперь, после частичного "реверса" бинарника ROM есть правильные адреса и используемая память RAM из ROM-BIOS - Сделал себе правильные ld и хидеры...
Оказалось, что все файлы *.ld для линковщиков из всех SDK (хоть *.icf к IAR) и прочих прошивок не соответствуют имеющимся кодам в ROM-BIOS. Так-же не соответствует и кинутая rom.a. Во первых она предварительной версии, а ROM в чипе прошит V02.
Кратко можно ознакомиться в файле вложения. Полной информации не будет никогда. Описание заголовков и прочего войдет в мой SDK, но позже - долго оформлять.
Без правильной разметки данных в RAM невозможно их использовать совместно с ROM-BIOS. Использование совместно - сокращает задействованную RAM, исключая дубли, включая область boot-loadera. В оф. SDK все блоки данных, имеющихся в области RAM от ROM дублируются и согласования у них нет(!).

PS: Данная тема будет продолжаться с описанием ROM-BIOS для RTL... по мере накопления инфы и наличию обратной связи

 

[pvvx]

Тестовый проект по сборке сегмента данных RAM используемых ROM для теста совместимости и начальной инициализации в boot-лоадерах.
Производит подмену данных для ram от rom.a из rtl_bios_data.с с описанием всех полей в rtl_bios_data.h. Требуется для исключения включения в проект GCC rom.a старой версии и проверки по получившемуся build\obj\build.map правильной линковки данных, для последующей возможности создания и коррекции полей в project\ld\export-rom_v04.txt.
Для сборки ROM - добавить либу lib_rom.a (rom.a) в SDK и:
1) sdkset.mk: all: LIBS += _rom c nosys gcc
2) закоментировать в rtl_bios_data.h: #define NOT_USE_LIBROM_A
- тогда структуры данных будут братся из rom.a.
Не для "телепузиков" - на проекты "с миганием светодиодом" это не распространяется, а для тех кому надо собрать что-то правильное и надежное на RTL с коррекцией ошибок во всяких кривых вариантов скриптов линкера и различий их с реальной ROM.
Так-же напомню - в IAR проект линкуется с rom.a (от старой версии rom-bios!) и не используется export-rom_v0X.txt и поля в rom.a не совпадают с реальными - V02 rom используемой в чипах. Так-же rom.a не содержит всех имен локальных переменных в RAM. И у GCC линковщика (и их версий) своя политика сортировки данных в пределах сегмента и align их начал - итого совпадений не будет, если не задать всё ручками и не переписать в соответствие с дизасмом дампа реальной ROM, а не по имеющимся непонятно от куда взятых файлов.
Т.е. история доводки долгая и сложная. Пока совместил только интересуемые данные - область RAM переменных rom-bios. Остальное - адресация процедур в ROM для GCC - подходит уже имеющаяся в *.ld-*.txt.

 

[pvvx]

Выходят такие позиции у реальной ROM в начальной области RAM и Boot:

10000000 D NewVectorTable
10000100 D UserIrqFunTable
10000200 D UserIrqDataTable
10000300 D CfgSysDebugWarn
10000304 D CfgSysDebugInfo
10000308 D CfgSysDebugErr
1000030c D ConfigDebugWarn
10000310 D ConfigDebugInfo
10000314 D ConfigDebugErr
10000318 D HalTimerOp
10000334 D GPIOState
1000034c D gTimerRecord
10000350 D SSI_DBG_CONFIG
10000354 D _pHAL_Gpio_Adapter
10000358 D Timer2To7VectorTable
10000370 D _rand_first
10000374 D _rand_z1
10000378 D _rand_z2
1000037c D _rand_z3
10000380 D _rand_z4
10000384 D pUartLogCtl
10000388 D UartLogBuf
10000408 D UartLogCtl
10000430 D UartLogHistoryBuf
100006ac D ArgvArray
100006d4 D rom_wlan_ram_map
100006e0 D FalseAlmCnt
10000720 D ROMInfo
10000738 D DM_CfoTrack
10000760 D rom_libgloss_ram_map
10000780 D __rtl_malloc_av_
10000b88 D __rtl_malloc_trim_threshold
10000b8c D __rtl_malloc_top_pad
10000b90 D __rtl_malloc_sbrk_base
10000b94 D __rtl_malloc_max_sbrked_mem
10000b98 D __rtl_malloc_max_total_mem
10000b9c D __rtl_malloc_current_mallinfo
10000bc4 D __rtl_errno
10000bc8 D gRamStartFun
10000bcc D gRamPatchWAKE
10000bd0 D gRamPatchFun0
10000bd4 D gRamPatchFun1
10000bd8 D gRamPatchFun2
10000bdc D RAM_IMG1_VALID_PATTEN
10000be4 D rand_x
10000be8 D AvaWds
10001be8 D SdrDramInfo
10001bfc D SdrDramTiming
10001c30 D SdrDramModeReg
10001c4c D SdrDramDev
10001c60 A _rtl_impure_ptr
10001c68 D impure_reent
10002090 D _rom_неивестные_данные
100020b4 D _sdr_rnd2_y
100020b8 D _sdr_rnd2_z
100020bc D _sdr_rnd2_c

Конец использования у Ameba назначен вроде как 0x10002114. Но пока не встретил в IDA обращений из ROM по фиксед адресам выше 0x100020bc (ну кроме блока SDIO использующего конец RAM c 0x1006D000.. до конца).
Т.е., если обращаемся к процедурам rom-bios, то надо предоставить область c 0x10000000 по 0x10002100 c проинициализированными там данными... bss область rom-ram можно и очистить при старте уже в boot, но нарушатся отметки используемых i/o на периферию и прочие глупости... Так оно и работает у Ameba - Hal ругается не по делу и i/o не работают О SDRAM и SPIC вообще пока помолчу - том полный бардак и по этому всякие Ameba используют режим только SIO обращений к Flash и наблюдаем кучу бреда от разных версий загрузчиков и конфликтов их с калибровочными значениями...
Переинициализация SPIC в SDK при старте доходит до 5 раз и в разных вариантах кода (куча дублей - с пометками процедур как _patch и так и сяк - а достаточно всего одной и одного массива параметров в области ram-rom )
При загрузке их boot (ram_1.r.bin) перекрывает область параметров rom-bios со значениями для spic и поля у них не совпадают по адресации для текущей версии ROM - итог = мешанина и необходимость дублирования процедур инициализации и их данных в других областях RAM. Затем boot (ram_1.r.bin) загружает и запускает image2 - в нем новые инициализации и новые буфера для их данных калибровок... Потом инится mbed api - у него опять новые поля и данные калибровок... И т.д. В одном интерфейсе spic иниться на DIO, в другом на SIO и всё это как-то живет, требуя процедур с патчем на патче при обращении к специфичным функциям flash А пол мега процедур в rom - выходят ненужным хламом - как пример - процедура Random-а из ROM дублирована в SDK более 5-ти раз под разными именами...
Потом не удивительно, что 512к RAM не хватает ни для чего

Понятно, что это всё сделано ради совместимости с предыдущими патчами, как это ныне модно. Тут без OTAсовсем ни как. На пошлый патч нужен новый патч и их цикл бесконечен – это и есть основа и главные задачи современного ПО - обновление ради обновления, вместо исправления начального нарушения.

Отец...
вы так ошибаетесь.
Позвольте объяснить.
Жизнь, которой вы так благородно служите,
происходит из разрушения и хаоса.
Возьмем этот пустой стакан.
Вот он, спокойный...
скучный.
Но если его...
уничтожить.
Посмотри на этих малышей.
Как они теперь заняты.
Заметьте, как полезна каждая.
Что за прекрасный балет...
полный форм и красок.
Теперь подумайте обо всех тех людях
создавших их.
Техники, инженеры. Люди, которые
могут накормить сегодня своих детей...
чтобы эти дети затем выросли
и имели своих детей...
и так далее.
Таким образов создается
великая цепочка...
жизни.
Вода.
Фрукты.
Вот видите, святой отец,
создавая небольшое разрушение...
Я поддерживаю жизнь.
По сути, мы заняты одним делом.
(с) Пятый элемент

 

[sharikov]

Для чего используется область между UartLogHistoryBuf и ArgvArray - 676 байт?

 

[pvvx]

Для чего используется область между UartLogHistoryBuf и ArgvArray - 676 байт?

Откройте файлы rtl_bios_data.c и rtl_bios_data.h "и да прозреете" Уточнения в rtl_console.c
Есть такая функция в операционке - поиск называется. Ищет по знакомым буквам и словам в указанных файлах... Укажите SDK или прямо google
Мне гугла сказало RTL00MP3/RTL00_SDKV35a/component/soc/realtek/8195a/misc/driver at master · pvvx/RTL00MP3 · GitHub
А far на UartLogHistoryBuf в SDK это:

А Windows по "F3":

А в rtl_bios_data.c:
MON_RAM_BSS_SECTION u8 UartLogHistoryBuf[UART_LOG_HISTORY_LEN][UART_LOG_CMD_BUFLEN]; // 10000430 UartLogHistoryBuf[5][127] !
Далее вводим это дело в windows->стандартные->кУлькулятор:

Получаем ваши искомые 635 байт, с учетом align(4) будет что-то другое.
А IDA на бинарник ROM и область между эти переменными сказала:

что в процедуре ROM GetArgv() есть обращение к статической переменной за данным буфером. Она не интересна и не требует глобального имени.
Повторить описываемую примерную последовательность действий может каждый и на такие вопросы без приколов не отвечаю
Тем более когда немного доработаю rtl_bios_data.c и rtl_bios_data.h и выложу в git или куда ещё, то гугла вам сам ответит на эти вопросы.
И у вас, в отличии от автомата, останется единственная миссия - разделение на реальное и вымышленное. "Телепузики" для этого не нужны. Автомат и ИИ ещё сотни лет не сможет это сделать - он руководствуется ограниченным числом датчиков и не имеет... В общем фантасты забыли про это и пишут только хрень по консервные баночки с людьми в космосе

 

[pvvx]

Кто знает что-то о загрузке не в режиме с Flash, а в режиме с SDIO?
В текущих ROM-BIOS V02 стартовая процедура изменена:
Reset_Handler -> HalResetVsrV02() ->HalBootFlowV02()
и имеет ветку загрузки SDIO SDIO_Boot_Up() по регистру 0x40000038 (REG_SYS_EFUSE_SYSCFG6).