jcmvbkbc

В risc вроде там куча csr регистров

Вот на этом месте остановись. RISC -- это не конкретный набор инструкций и регистров, это принцип организации набора инструкций. RISC-процессоры все разные, возьми крнкретный и разбирайся с ним, не вали их все в одну кучу, не ставь на вопрос теги процессоров которые не имеют к нему отношения.

на разных компиляторах одна си операция ассемблируется то в комбинацию lui + addi, то в комбинацию auipc +addi

Ты указал ARM в тегах, но у ARM нет инструкций lui и auipc. Такие инструкции есть у RISC-V.
Если ты посмотришь в The RISC-V Instruction Set Manual, раздел 2.4 Integer Computational Instructions, то увидишь, что опкод lui загружает константу собранную из 20 битов непосредственного значения из инструкции и 12 нулевых младших битов в целевой регистр, а auipc прибавляет такую же точно константу к PC и загружает в целевой регистр результат сложения, и в этом вся разница между ними.

где какая используется не совсем понимаю.

lui используется для генерации констант, которые не зависят от того, где расположен код, а auipc для генерации констант, которые двигаются вместе с кодом. Т.е. Если ты хочешь вызвать функцию, которая находится дальше чем ±2К от точки вызова, ты можешь сгенерировать её адрес инструкцией auipc, и полученный код будет работать одинаково, независимо от того, по какому адресу он будет размещён. А если тебе надо поместить в регистр константу, например 0x12345678, то ты можешь это сделать парой инструкций lui rd, 0x12345 ; addi rd, rd, 0x678 и значение константы будет всегда одинаковым, вне зависимости от того, где будет этот код.

Каким образом одинаковые адреса различаются. Или они просто не могут быть одинаковыми(типа ос позаботиться)?

Если есть MMU и он используется ОС, то есть и виртуальные адреса и они могут быть одинаковыми у разных процессов. Если MMU нет или он не используется, то ОС размещает все процессы в одном адресном пространстве, нет смысла говорить отдельно о виртуальных адресах, поскольку они равны физическим, адреса выделяемые ОС разным процессам могут быть как одинаковыми (например несколько процессов запущенных из одного исполняемого образа могут использовать один и тот же код и константные данные), так и разными (например изменяемые данные разные у всех процессов, а стеки разные у всех потоков).

Как они в tlb обрабатываются, если вдруг они реально могут быть одинаковыми, и там нету ни каких дополнительных индексов процесса)

Выбери конкретную процессорную архитектуру -- обсудим. у многих RISC-архитектур есть ASID, который идентифицирует адресное пространство и записывается вместе с виртуальным адресом в TLB. Но в любом случае ASID -- это просто оптимизация для повышения производительности, когда он отсутствует или переполняется ОС должна сбрасывать содержимое TLB при переключении адресного пространства.

У ARM есть регистры TTBR с примерно той же функцией, что и cr3 в x86.
У RISC-V есть CSR satp, содержащий ASID и базовый адрес корневого каталога страничных таблиц. Об этом можно прочитать в разделе 4.1.12 Supervisor Address Translation and Protection (satp) Register спецификации The RISC-V Instruction Set Manual Volume II: Privi....

Почему нужно 512-356 байт нулями заполнять, почему нельзя продолжить дальше. Ведь следующая после 86*4 байт инструкция(или переменная) будет выровнена

А вот еслы бы ты тупо взял и прочитал документацию на директиву .p2align, то у тебя таких вопросов не было бы. Потому что никто не заполняет 512-356 байт после. .p21lign выравнивает текущий адрес по заданной степени двойки. Обычно для этого есть аппаратные причины, например базовый регистр таблицы векторов прерываний может иметь 9 младших бит зафиксированных в 0. Или вот по границе страницы MMU выравнивают данные в ELF-файлах, чтобы можно было установить отдельно разрешения RX для кода и констант и RW для изменяемых данных.

для получения элемента допустим table[index_nBit] можно применять операцию ИЛИ вместо сложения. Что быстрее. В этом ли дело

Нет, не в этом.

Почему дефолтные значения выглядят так (первые два скришота)

Потому что это адреса. 8 байт адреса, на втором скрине первый -- 0x12df11a80, второй -- 0x12df11a60

Начало TEXT минус конец PAGEZERO, получается 0x104a60000 - 0x100000000 = 0x4a60000 (делта смещение)

Ты что-то странное тут посчитал. TEXT у тебя лежит начиная с адреса 0x104a60000, вот этот адрес и надо использовать.

Вот адрес ,к примеру, на котором я хочу установить breakpoint

Тебе ещё надо знать, с какого адреса T начинается TEXT в дизассемблере. Тогда для произвольного адреса A внутри TEXT адрес в отладчике будет A - T + 0x104a60000.

Слишком мало информации.

Я долго изучал код

Только по выводу дизассемблера или отладчиком ходил?

пытался менять ... "0x013ded84 ldr x1, [x8, 0x250]"

Выглядит разумно, но стоило бы под отладчиком посмотреть, что в x1 оказывается после этой инструкции. Я подозреваю, что адрес строки в памяти, а значит случайные изменения адреса откуда x1 загружается почти наверняка ничего не дадут.

Задача либо понять "1" на любое нужное число, либо сделать так чтобы количество скачиваний было равным цене товара.

Можно попробовать сохранить x1 каким он приходит к адресу 0x13ded40 в каком-нибудь callee-saved регистре (например x24) и перезагрузить обратно его вместо инструкции по адресу 0x13ded84. Как раз между этими адресами есть один nop и adrp x8, 0x2d71000 который теперь будет не нужен.

Какая из свободных OS/дистрибутивов Linux/BSD предоставляет такую возможность?

buildroot позволяет собрать образ ядра linux/юзерспейс для big-endian ARM.

Утилитами fw_printenv/fw_setenv U-Boot. см.

Виртуальная машина с Windows XP на железе Raspberry PI 3B — реально

Реально, с помощью какого-нибудь QEMU. Но про процессорную виртуализацию забудь -- она подразумевает, что процессор гостя совместим с процессором хоста, что, очевидно, не так. Только программная эмуляция.

Какие косяки меня могут поджидать?

Разный порядок передачи байтов (big/little endian), в двух ваших примерах он уже разный (учитывая, что STM32 -- little endian по умолчанию).

Есть способ лучше?

С точки зрения сгенерированного кода оба предложенных варианта одинаковы.
С точки зрения читабельности (и при отсутствии требований к порядку байтов) я бы предложил следующее:

void send_uint32(uint32_t v)
{
    uint8_t transmitBuffer[4];
    memcpy(transmitBuffer, &v, sizeof(v));
    HAL_UART_Transmit_IT(&huart1, transmitBuffer, sizeof(v));
}

При наличии требований к порядку байтов я бы выбрал сдвиги.