Dobre narzędzia lub metody do zrozumienia struktury bootloadera?

Niedawno odkryłem przyczynę paskudnego błędu, nad którym pracowałem z Atmel AT91SAM9G20 SBC z uruchomionym U-boot , bootloaderem typu open source. Istotą problemu było to, że U-boot oczekiwał, że sprzęt zostanie skonfigurowany inaczej niż ja go zbudowałem, więc niektóre rejestry urządzeń były źle skonfigurowane.

Teraz, gdy odkryłem problem, muszę dostosować U-boot, aby poprawnie skonfigurować rejestry. Mogę to zrobić na ślepo, dodając kilka wierszy kodu na końcu programu, ale to jest bałagan.

To prowadzi mnie do pytania: jak mogę dowiedzieć się, w jaki sposób U-boot działa wydajniej niż rozpoczynając od main () i czytając wszystkie możliwe ścieżki kodu we wszystkich plikach? Próbowałem przeszukiwać pliki i patrzeć na kod w pobliżu odpowiednich identyfikatorów. Okazało się to nieskuteczne; wygląda na to, że większość kodu to sterowniki dla podsystemów, na których mi nie zależy. Właściwie rozumiem, jak działa bootloader, ale mam nadzieję, że istnieje lepsza metoda niż moje naiwne podejście.

Istnieje kilka narzędzi / strategii, które mogą pomóc:

• Lepsze narzędzia do zrozumienia kodu źródłowego:

  • cscope to narzędzie do eksploracji kodu C, przypomina grep, ale rozumie składnię
  • Wywołaj generatory wykresów, aby narysować obraz struktury wywoływania funkcji
  • Fenris wygląda interesująco, chociaż tego nie próbowałem

• Analiza środowiska wykonawczego

  • Przejdź przez ciekawe sekcje za pomocą debugera i przeanalizuj, co się dzieje
  • Skorzystaj z funkcji instrumentacji gcc, aby wywołać kawałek dobra przy wejściu / wyjściu z każdej funkcji. na przykład. http://ndevilla.free.fr/etrace/

• Pisanie własnego mini-programu ładującego

  • Często uważam, że najlepszym sposobem na zrozumienie czegoś jest odtworzenie go osobiście

Niestety nie ma magicznej receptury, która działałaby na wszystko.

Jak skonfigurowałeś go do budowania dla AT91?

Drzewo kodu wydaje się być zaprojektowane w taki sposób, że wszelkie elementy specyficzne dla architektury znajdują się w drzewie „arch / (klasa procesora) / (typ procesora) / ...”. Znalazłem kod AT91 pod arch / arm / cpu / arm926ejs / at91 ... czy nie ma tam specyficznego wariantu, który chcesz zmienić? W tym katalogu nie ma aż tak okropnie dużo uwagi, zwłaszcza że prawie połowa plików jest specyficzna dla poszczególnych wariantów AT91.

Przepraszam, jeśli to oczywiste ... ale nie wspomniałeś o sprawdzeniu tego.

Nie patrzyłem jeszcze na drzewo kodu uBoot, ale twój post mnie wystraszył. Mój projekt tylnego palnika wymaga użycia uBoot i Linuksa na niestandardowej płytce drukowanej iMX233. Jestem bardzo zainteresowany otrzymywaniem tego rodzaju informacji zwrotnych na temat tego, jak dobrze architektura uBoot i elementy specyficzne dla wariantów są izolowane i jak duży będzie to ból.