Kiedy BCM2837 uruchamia się po raz pierwszy, musi odczytać swój kod z pamięci trwałej, większość procesorów robi to, rozmawiając z pamięcią flash NAND (tj. BIOS), ponieważ jest to bardzo łatwe. Ale tego nie robimy, zamiast tego implementujemy kod odczytu systemu plików w bootromie, aby odczytać plik o nazwie bootcode.bin, a następnie go wykonać.

Z tego powodu musimy sformatować kartę SD w sposób, który jest łatwy do wdrożenia. Jeśli kiedykolwiek zastanawiałeś się, jak trudne może być wdrożenie ext4 go, spójrz na specyfikację ... Dla porównania napisałem kod FAT w około 250 bajtach.

Innym problemem jest to, że Karty SD były tradycyjnie formatowane przy użyciu FAT, gdy je kupujesz, dlatego nie ma sensu wdrażać niczego innego. Jedyną inną opcją jest exFAT ze względu na obsługiwane rozmiary plików> 4 GB.

Jeśli sformatujesz go za pomocą ext4, nie możesz go odczytać na komputerze (bez narzędzi innych firm), jeśli sformatujesz NTFS, nie można tego zapisać na Linuksie (w rzeczywistości są narzędzia, ale nie są one zbyt niezawodne), HFS jest ponownie zamknięty i nie jest udostępniany!

FAT i exFAT to jedyne systemy plików, które są wspólne systemy ...

Podejrzewam, że ten temat jest podobny do powodów, dla których Pi nie ma zegara czasu rzeczywistego (RTC) lub dlaczego nie można go uruchomić przez Wake on LAN. Mówiąc prościej, aby obniżyć koszty, Pi nie ma normalnego BIOS-u komputera. BIOS musi być przechowywany w pamięci flash ROM. Dodanie pamięci flash ROM do Pi kosztowałoby pieniądze. Po prostu przechowywanie odpowiednika Pi plików BIOS na oddzielnej partycji na karcie SD oszczędza pieniądze i pozwala na łatwiejszą i mniej ryzykowną aktualizację.

Jeśli chodzi o to, dlaczego ta partycja jest sformatowana w FAT32, sugerowałbym, że jest to bardzo prosty i pragmatyczny wybór kompatybilności. Większość ludzi korzysta z systemu Windows (ooh, słyszę, jak wszyscy zeloci z FOSS się kulą ... Przepraszam, ale to prawda). Aby sprawdzić, czy pliki rozruchowe zostały pomyślnie zapisane (w systemie Windows, Linux lub OSX), jest tylko jeden wybór: FAT32.

Oczywiście, możesz zainstalować program taki jak Linux Reader firmy DiskInternals, aby czytać partycję ext4 w systemie Windows, ale to po prostu dużo zamieszania wokół przeciętnego dzieciaka lub rodzica (do którego jest skierowane Pi) po prostu nie powinno nie muszę tolerować.

/ boot znajduje się na tej partycji, więc umieszczasz dysk w czytniku kart na komputerze i naprawiasz problemy z uruchamianiem, w tym edycję /boot/config.txt .

"Program ładujący" (aw wielu przypadkach jest to tylko "program ładujący pierwszego stopnia") jest odpowiedzialny za ładowanie kodu, który wprowadza resztę systemu operacyjnego.

W typowym PC BIOS robi to za pomocą kodu, który nie znajduje się nawet na partycji dysku. W przypadku Linuksa byłby to GRUB (wcześniej LILO). To kod, który trafia do partycji Linux / boot i ładuje ją, a to z kolei ładuje resztę systemu operacyjnego.

Na Pi, odpowiednik BIOSu trafia na kartę SD i szuka partycji FAT do załadowania. Z tego, co wiem, może być konieczne, aby ta partycja istniała z pewnym stałym przesunięciem na urządzeniu. Ładuje ten kod i to właśnie czyta system operacyjny z karty EXT4.

Mniej znam programy ładujące UEFI i nie mogę ich komentować. Mogę też nie mieć racji co do dwóch etapów programu ładującego. Może być więcej. Jeśli jesteś zainteresowany, uruchom program ładujący google PC, a znajdziesz więcej informacji.

Jest kilka sposobów zinterpretowania tego pytania:

• Dlaczego pojedynczy system operacyjny wymaga dwóch partycji; a dokładniej: dwa woluminy?
• Dlaczego ta dodatkowa partycja wymaga systemu plików FAT32, w przeciwieństwie do np. NTFS czy Ext4?
• (niejawne pytanie?): Jakie pliki znajdują się w tym systemie plików FAT32.

1. Odpowiedź na pierwsze to:
Nie technicznie wymaga dwóch partycji, wystarczy, że partycja z plikami rozruchowymi to FAT32 .
Ponieważ FAT32 nie nadaje się do uruchamiania cały system operacyjny, którego programiści są zmuszeni używać dwóch systemów plików, stąd dwie partycje. Uważam, że Ext4 jest wspólny dla partycji systemu operacyjnego Linux.

2. Dlaczego FAT32 dla plików startowych? Spekulujemy z następujących powodów:

• Łatwa / kompaktowa implementacja sterownika systemu plików w bootloaderze. Większość innych systemów plików jest bardziej złożona. Napisanie bootloadera nie jest łatwe, zwłaszcza jeśli chcesz zminimalizować jak najwięcej wbudowanej pamięci NAND.

• Inne systemy plików mogą obejmować (wyższe) koszty licencji lub nie są prawidłowo udokumentowane.

• System plików FAT32 jest obsługiwany przez popularne systemy operacyjne, takie jak Windows, MacOS i Linux. Nie ma więc potrzeby instalowania specjalnych sterowników, aby uzyskać dostęp do plików na karcie SD / obrazie.

3. Pliki startowe są jak wersja lobotomizowana GRUB i uważam, że to zamknięte źródło. Powinien zawierać wszystkie pliki potrzebne do załadowania wybranego jądra, w tym podstawowe sterowniki (które mogą różnić się od sterowników jądra ładowanych później lub do nich zostać dodane).

Odnośnie twoje analogie:

Widziałem to samo w przypadku bootowalnych pendrive'ów USB, jak również [...] zwykła instalacja Linuksa na twardym dysku nie wymaga tej gry, prawda ?

Właściwie to zrobili. W niektórych przypadkach tak. Na przykład. instalacja systemu Windows 7 na komputerze z systemem BIOS spowoduje utworzenie 2 partycji, 100 MB partycji NTFS zawierającej pliki rozruchowe. Maszyny z systemem Linux często mają oddzielną partycję / boot , która zawiera program ładujący (np. GRUB) oraz pliki jądra i sterowników. Oddzielenie nie jest absolutnie konieczne, ponieważ te programy ładujące używają MBR, ale używanie MBR jest „trudniejsze” niż użycie odpowiedniego systemu plików. Dlatego nowsze oprogramowanie układowe UEFI również preferuje osobny system plików FAT dla plików rozruchowych (co prawdopodobnie widzieliście na pendrive).