Istnieje możliwość, że plik uImage to obraz systemu plików (taki mini) który jest analogicznym odpowiednikiem linuxowego initrd.gz.
Oznaczałoby to, że sekwencja wygląda tak:
- Tablet wyszukuje plik Updater i gdy wynik jest pozytywny, to ładuje go i wykonuje instrukcje.
- Plik Updater wypakowywuje obraz systemu plików do dysku tymczasowego (trzymany jest w pamięci RAM)
- Updater jest przejmowany przez UBOOT.img (już odpowiednio przygotowany do działania)
- Bootloader zajmuje się wypakowywaniem plików i "wypalaniem" ich na dysk (burning file system... [czy jakoś tak]
- System jest końcowo konfigurowany (nie widzimy tego, ale chodzi o ustalenie położenia kernela, uboota, itp... a następnie zapisywanie tego w plikach konfiguracyjnych (tych też nie widzimy, lub są gdzieś spakowane).
- System jest gotowy do użycia. Wyjmujemy kartę SD.
- Reset!
Może udałoby się coś z tym zrobić, ale to nie jest kwestia kilku dni, tylko miesięcy, co w roku szkolnym dla mnie przekłada się na lata...
Pozdrawiam.
@aleksander002: Masz całkowitą rację. Kiedyś bawiłem się UBootem, i doliczyłem się tego samego efektu na różnych sprzętach (netbookach ARM...) i pomimo, że ustalanie bootsektora jest tutaj bardziej banalne, to wolę ustalać go na PC (wprawiłem się w wgrywanie MBR do OS'ów w wypadku, gdy ktoś chce mieć jednocześnie kilka systemów, które są w dodatku niewspierane przez NTLDR (Windows XP) i XELDR (Windows Vista/7).