Zastanawiam się, jaka jest sekwencja rozruchowa Raspberry Pi w typowej konfiguracji (powiedzmy NOOBS), od aplikacji mocy (lub ciepłego resetu, jeśli jest inaczej) aż do, powiedzmy, pojawienia się logo; lub gdzie to jest opisane.

Oprócz najbardziej potrzebnego ogólnego obrazu tej sekwencji, najbardziej interesują mnie wczesne etapy:

1. Jaki jest wektor resetowania procesora ARM i jak / gdzie to jest zdefiniowane?
2. Z jakiej pamięci pobierane są pierwsze instrukcje procesora ARM? Gdzie to jest i jaką technologię stosuje się do przechowywania tego kodu?
3. Czy to kod ARM32 lub kod Thumb (a może Jazelle)? Czy to zależy od bitu niskiego rzędu wektora resetowania?
4. Czy dostępne jest źródło (lub dezasemblacja lub zrzut) tego wczesnego kodu rozruchowego? Jeśli nie, to czy jest coś technicznego, co uniemożliwia użycie portu JTAG do ustalenia tego? _{^{Jeśli chodzi o kwestie prawne, jestem gotów przyjąć ryzyko, że ufam mojemu zrozumieniu prawa obowiązującego w moim miejscu zamieszkania (Francja), co oznacza, że ​​mam pełną analizę własnego komputera, przynajmniej w przypadku braku wyraźnej umowy wymóg, aby tego nie robić.}}
5. W jakiej kolejności są inicjowane urządzenia peryferyjne i według jakiego kodu?
6. Czy oprócz procesora ARM w BCM2835 działają jakieś procesory / automaty, a twierdząco, w jaki sposób jego sekwencja rozruchowa odnosi się do procesora ARM?

Jestem gotowy do zapoznania się z Instrukcją techniczną procesora ARM i urządzeniami peryferyjnymi ARM BCM2835 lub innymi dokumentami.

Aktualizacja: Po opublikowaniu znalazłem to i to , stwierdzając, że GPU BCM2835 działa jako master dla ARM i jest mocno zaangażowany w sekwencję rozruchową.

Sekwencja uruchamiania Raspberry Pi jest w zasadzie taka:

1. Rozruch pierwszego etapu znajduje się w ROM-ie na chipie. Ładuje etap 2 do pamięci podręcznej L2
2. Etap 2 to bootcode.bin. Włącza SDRAM i ładuje etap 3
3. Etap 3 to loader.bin. Wie o .elfformacie i obciążeniachstart.elf
4. start.elfładunki kernel.img. Następnie odczytuje również config.txt, cmdline.txta bcm2835.dtb jeśli plik dtb istnieje, jest ładowany do 0×100& kernel @ 0×8000 Jeśli disable_commandline_tagsjest ustawiony, ładuje jądro @ 0×0 W przeciwnym razie ładuje jądro @ 0×8000i ustawia ATAGS na0×100
5. kernel.img jest następnie uruchamiany na ARM.

Wszystko działa na GPU, dopóki nie kernel.imgzostanie załadowane na ARM.

Uważam ten schemat za bardzo przydatny: