Подстава при отладке u-boot

Очередные идиотские грабли, по которым я прошёлся с непоколебимой уверенностью в том, что я "Д'Артаньян", а окружают меня лица неторадиционной ориентации.

Отлаживаю код ethernet драйвера, проверяю инициализацию, вижу что значения пишутся хрен пойми куда.

...минула неделя разборок с отладчиком, компилятором и прочей нечистью...

Тут до меня доходит - u-boot же уже отрелоцировался в памяти и те адреса статических переменных которые у меня в символах прописаны, действительны уже чуть более чем никак! всё остальное правильно, но вот то, что я забыл про статичность данных переменных меня и подвело.

Идиот-с.

З.Ы. Кто-нибудь знает, как GDB сказать, что секция .bss лежит по некоторому адресу, не тому что в отлаживаемом бинарнике?

Кровавый enterprise

В очередной раз сталкиваюсь со всей кровавостью enterprise решений. Есть такая штука как teamcity, отличная вещь кстати говоря, но внутри использует jgit для выдёргивания исходников из репозитория. Есть репозиторий, который внутри содержит симлинки, так надо. Как оказалось, jgit не умеет правильно обрабатывать симлинки и вместо них создаёт обычные файлы в которых указано назначение симлинка... Про это товарищи писавшие teamcity знают и описали работающий воркэраунд.

А я-то думал, что за хрень происходит.

Очередной пример того, почему я не люблю make

В нагрузку к предыдущему псто можно сказать одно - make 3.81 и 3.82 - в некотором поведении между собой несовместимы.

В предыдущем псто был пример с ifndef  VAR и в нём делалось объявление этой самой VAR. Засада вылезла с той стороны с которой я её ну аще никак не ждал. Оказалось, что у make 3.81 и 3.82 по разному обрабатываются переменные командной строки. 3.82 их подставляет как надо, а вот 3.81 почему-то сначала выполняет присваивание которое в коде, гадит ошибками, после чего присваивает переменным те значения, которые переданы в параметрах командной строки. шозанах, я так и не понял. Пришлось устраивать трэш и передавать параметры как переменные окружения, вызывая

VAR=value make -e <target>

Вот такие пироги с котятами. Я допускаю, что я упорот и строю костыли там где не надо. Если так, разупорите примером. про ?= знаю, не помогло. 

Вот бывает что надо при сборке развесистого проекта брать информацию о id коммита, ветке и прочих радостях жизни.

Мы сделали так:

COMMIT=`git show --pretty=oneline|head -c 40`
BUILDN=`git log --pretty=format:'' | wc -l`
BRANCH=`git branch|grep '*'|awk '{print $2}'`

Так вот, так делать не надо. Потому что если захочется собирать проект чем-нибудь типа Teamcity, попадаешь на то, что все такие нормальные системы не выдёргивают полноценное дерево, а только последнюю ревизию, из-за чего всё вышенаписанное ломается.

Посему был приделан костыль такого вида:

ifndef COMMIT
COMMIT=`git show --pretty=oneline|head -c 40`
endif
ifndef BUILDN
BUILDN=`git log --pretty=format:'' | wc -l`
endif
ifndef BRANCH
BRANCH=`git branch|grep '*'|awk '{print $2}'`
endif

Теперь если эти параметры передаются в makefile из системы сборки(а она их знает), то обращений к гиту(которые по понятным причинам обламываются) не будет.

Знал бы где где костыль сломается, инвалидное кресло бы припас.

  ______________________________________

/ Хозяина этого блога захватила в плен \
| неимоверная куча работы, так что в   |
| ближайшее время рассчитывать на него |
\ видимо не приходится                 /
 --------------------------------------
  \
   \    (__)
        o o\
       ('') \---------
          \           \
           |          |\
           ||---(  )_|| *
           ||    UU  ||
           ==        ==

Лучи поно^Wдобра в сторону u-boot

В readme u-boot указана константа CONFIG_PHY_ADDR - которая отвечает за то, на каком адресе висит ethernet phy.

Вроде бы всё хорошо... Хрен там. Люди писавшие драйвер для AT91RM9200 emac, решили что они самые прикольные и запилили свою константу CONFIG_DRIVER_AT91EMAC_PHYADDR

Козлы.

Заметки о жизни после bootrom у at91rm9200

Себе напоминалка, если вдруг когда забуду.

1 - при использовании XMODEM для загрузки программы в SRAM PLL для клоков уже выставлен и трогать его не надо.
2 - там же, DBGU после ремапа SRAM на 0x00000000 сбрасывается на дефолтное состояние и настраивать его снова - НАДО!
3 - GCC оптимизации делает мудацкие и при сборке начального загрузчика весь код отвечающий за инициализацию железа надо собирать с -O0, либо раскуривать оптимизатор GCC и активно использовать volatile
4 - при использовании XMODEM клоки для PIO контроллера настраивать не надо, они выставляются в процессе работы bootrom.