jcmvbkbc

Это ведь так легко узнать, смотри:

$ strace -f -e clone,write,chdir bash -c "cd | echo 'zz'"
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f1c61235a10) = 7494
strace: Process 7494 attached
[pid  7493] clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f1c61235a10) = 7495
strace: Process 7495 attached
[pid  7494] chdir("/home/jcmvbkbc")     = 0
[pid  7495] write(1, "zz\n", 3zz
)         = 3
[pid  7494] +++ exited with 0 +++
[pid  7495] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7494, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

strace запустил bash (7493), bash создал два процесса, один из них (7494) выполнил cd, второй (7495) -- echo.

Если взять за основу эту схему, то становится понятно, как код процесса может узнать адреса текста, инициализированных данных, неинициализированных данных

Если мы говорим про обычные (не PIE) исполняемые ELF-файлы, то они слинкованы под конкретный адрес куда они будут загружены, и все адреса внутри одного исполняемого файла посчитаны заранее. Поэтому загрузка адреса функции или пременной в секции данных -- это просто загрузка константы в регистр.

и кучи

С кучей всё по-другому, потому что куча и объекты в ней полностью динамические. Выделение памяти для кучи -- это всегда системный вызов, который возвращает адрес выделенной памяти (и sbrk, и mmap).

не ясно, как становится известен адрес стека и аргументов командной строки

они инициализируются ядром ОС, согласно ABI, см. например, ABI x86_64, раздел 3.4.1.

Как мне избавится от дублирования кода, который одинаковый для нескольких целей, однако, отличается именами файлов(пусть имена файлов совпадают с названием целей)?

Можно написать макрос-генератор целей. Изменяющиеся параметры можно передать как параметры макроса, внутри на них можно ссылаться по номеру. Например так:

define generate-targets
$(1): 
 make -j5 TARGET=unwired BOARD=$$(BOARD)/$$(CPU) -f makefiles/Makefile.$$@
 ../bootloader/generate-metadata/generate-metadata $$@.bin 0x0 0x01A00001 1
 srec_cat firmware-metadata.bin -binary $$@.bin -binary -offset 0x100 -o $$@-ota-image.bin -binary
 rm $$@.hex

$(1)-fb: $(1)-CLEAN
  ../../tools/backdoor-bootloader.py -e -w -v $(1)-firmware.hex

$(1)-f: $(1)-CLEAN
 /Applications/ti/Uniflash/flash_cc1310.sh $(1)-firmware.hex 

$(1)-ota: $(1)
 scp $(1)-ota-image.bin root@192.168.20.187:/root/unwired_smarthome

endef

Внутри макроса нужно экранировать $ заменяя его на $$.
Этот макрос можно вызывать в нужном месте следующим образом:

$(eval $(call generate-targets,ubrige))

Сгенерированный в этом месте код будет эквивалентен коду из вопроса.

Патч содержит в себе относительные пути к файлам и должен применяться в определённом каталоге. Обычно им должен быть корневой каталог проекта, а патч содержит на 1 уровень каталогов больше. Лишний уровень обрезается опцией -p1. Это единица, а не строчная l, как у вас написано.
patch -p1 --dry-run < patch

CC build-x86_64/lock/rwlock.o
src/lock/rwlock.c:114:1: fatal error: opening dependency file build-x86_64/lock/rwlock.d: No such file or directory
}
...
Что такое rwlock на ubuntu, почему у меня его нет и как его поставить?

Сообщение о том, что во время компиляции файла src/lock/rwlock.c из самого libre компилятор не смог открыть/создать build-x86_64/lock/rwlock.d
Я подозреваю, что вы его (libre) компилировали под рутом, а потом -- под обычным пользователем, где и увидели проблему. Если так, то решение -- удалить build-x86_64 перед сборкой.

Что значит такой вывод? Из-за чего он возникает?

Значит, что операция была неуспешной, но код ошибки был обработан неправильно.
Чаще всего такое возникает при работе с интерфейсами использующими errno -- библиотекой C или POSIX, из-за того, что после ошибочной функции выполняется ещё как минимум одна функция меняющая errno, которая отрабатывает успешно.

у них нет периодических прерываний от таймера. Зачем это делается?

Чтобы
- не будить ядро без надобности, когда нет активных задач;
- не расходовать ресурсы зря, в то время, когда активна единственная задача и скедулинг не требуется;
- не расходовать ресурсы на периодические прерывания, когда активны несколько задач, а прерывать выполнение ровно в тот момент, когда истекает квант времени текущего процесса.

имеет ли смысл использовать режим без тиков на компьютере (например, на встроенной системе), запускающем только один процесс?

Имеет. В зависимости от производительности вы этим сэкономите сколько-то вычислительного времени и сколько-то батарейки.

#include <unistd.h>

int main()
{
        int fd[2][2];
        pipe(fd[0]);
        pipe(fd[1]);
        pid_t pid_fork = fork();
        if (!pid_fork) {
                // Дочерний процесс
                close(fd[0][1]);
                close(fd[1][0]);
                dup2(fd[0][0], STDIN_FILENO);
                dup2(fd[1][1], STDOUT_FILENO);
                execl("/bin/tr", "/bin/tr", "l", "r", NULL);
        } else {
                // Родительский процесс
                close(fd[0][0]);
                close(fd[1][1]);
                char buf[1000];
                ssize_t sz;

                write(fd[0][1], "hello, world\n", sizeof("hello, world\n") - 1);
                close(fd[0][1]);
                sz = read(fd[1][0], buf, sizeof(buf));
                if (sz > 0) {
                        write(STDOUT_FILENO, buf, sz);
                }
        }
}

Открой для себя buildroot.