Pytanie:
Raspberry pi 3 - dlaczego partycja FAT?
Jessica 6
2016-03-14 18:02:32 UTC
view on stackexchange narkive permalink

Właśnie zaczynam pracę z Raspberry pi 3 z Wi-Fi. Buduję za pomocą jednego z pobranych obrazów Ubuntu. Po zapisaniu obrazu na karcie SD zobaczyłem, że pierwsza partycja to FAT32. Dlaczego jest to konieczne? Widziałem to samo w przypadku bootowalnych pendrive'ów USB, ale nigdy nie mogłem znaleźć dobrego powodu, dla którego. Wysłałem do StackOverflow.com i powiedziano mi, że powinienem pisać tutaj. Ale otrzymałem nieco mało informacyjną odpowiedź:

„Ponieważ program ładujący tylko wie, jak czytać pliki z systemu plików FAT”

Moje pytanie brzmi: „Dlaczego?”. Chodzi mi o to, że zwykła instalacja Linuksa na dysku twardym nie wymaga tej gry, prawda?

Nie będę zawracał sobie głowy udzielaniem pełnej odpowiedzi w nadziei, że ktoś, kto zna szczegóły techniczne lepiej, to zrobi, ale ta odpowiedź jest zasadniczo poprawna - ma to związek z zastrzeżonym twardym / firmą / oprogramowaniem, które uruchamia urządzenie (nie jest otwarta platforma). Jest to konieczne we wszystkich modelach pi niezależnie od systemu operacyjnego i nie można używać programów ładujących ogólnego przeznaczenia związanych z linuxem (np. GRUB).
Ale dlaczego nie dotyczy to instalacji dysków twardych? Jeśli sprawdzę mój dysk twardy Linux Mint, nie widzę na nim partycji FAT32. A może po prostu nie jest widoczny z fdisk?
Wyjaśnię, co mam na myśli przez „urządzenie” w * ”, ma to związek z ** zastrzeżonym ** sprzętem / firmą / oprogramowaniem, które uruchamia urządzenie (nie jest to otwarta platforma)" * - urządzenie jest raspberry pi i nie jest to dysk twardy, laptop, smartfon itp. (chociaż jest znacznie bliżej ostatniego niż dwa pierwsze). Zwykły komputer ma konfigurowalną firmę / oprogramowanie (BIOS, UEFI), które sprawdza, co jest podłączone i z jakiego urządzenia ma załadować kod rozruchowy. Pi też to robi, z wyjątkiem tego, że nie można go konfigurować i jest tylko jedna opcja: pierwsza partycja oparta na fat32 na karcie SD.
... A tam spodziewa się znaleźć zastrzeżony (?) Kod startowy. Uważam, że to może i zostało poddane inżynierii wstecznej (może nawet nie być tak naprawdę zastrzeżone), ale głównym problemem jest tylko jedna opcja, jeśli chodzi o sposób ładowania (i do czego jest następnie używany - uważam, że ładuje * GPU *, ładuje do niego oprogramowanie układowe, a następnie ładuje jądro systemu operacyjnego do pamięci RAM i właściwego procesora).
Zaczynam rozumieć, ale widziałem tego typu rzeczy podczas tworzenia bootowalnego pendrive'a dla standardowego komputera: Pierwsza partycja to FAT32. Po prostu pomyślałem, że to jest powód, dla którego jest taki sam dla malinowego pi. Więc moje pytanie dotyczy również bootowalnych pendrive'ów.
Standardowy PC ma NOR Flash z bardzo grubym bootloaderem. Bootloader RPI jest DUŻO prostszy.
Pięć odpowiedzi:
#1
+8
GSH
2016-03-17 02:12:01 UTC
view on stackexchange narkive permalink

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 ...

Przez FAT masz na myśli FAT32 i nie jestem pewien, czy exFAT jest tak powszechny: „Microsoft nie wydał oficjalnie pełnej specyfikacji systemu plików exFAT i wymagana jest restrykcyjna licencja firmy Microsoft, aby tworzyć i rozpowszechniać implementacje exFAT” [(wiki) ] (https://en.wikipedia.org/wiki/ExFAT#Restrictive_licensing_and_software_patents).
Właściwie ma to wpływ na to, dlaczego RPis może obsługiwać tylko urządzenia Flash / USB do 32 GB - ponieważ większe urządzenia o pojemności 64 GB lub więcej wydają się wymagać zastrzeżonego [exFAT] (https://en.wikipedia.org/wiki/ExFAT ) system plików, który, jak wskazuje @jiggunjer, nie będzie używany w systemie FOSS system operacyjny jak Raspbian ...
#2
+3
pd_au
2016-03-14 19:49:48 UTC
view on stackexchange narkive permalink

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ć.

Wybrano IMHO FAT, ponieważ jest bardzo łatwy do wdrożenia. Jest DUŻO prostszy niż ext2 czy xfs.
Myślę, że technicznie wersja BIOS-u Pi byłaby dowolnym kodem uruchamianym przed odczytaniem pierwszej partycji ...
#3
  0
PaulF8080
2016-03-16 00:43:30 UTC
view on stackexchange narkive permalink

/ 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 .

#4
  0
HankB
2016-03-16 01:23:50 UTC
view on stackexchange narkive permalink

"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.

#5
  0
jiggunjer
2017-01-19 18:22:25 UTC
view on stackexchange narkive permalink

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).



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...