Ich habe eine chinesische Retro-Spielmaschine gekauft, die in einigen Bereichen zu einem heißen Thema geworden ist, und habe sie daher analysiert. Es ist wie ein Memo für mich, der sehr vergesslich ist.
Ich frage mich, was das Ziel der Analyse sein sollte, aber ich denke, es wäre schön, wenn ich zeigen könnte, wie man eine Anwendungsentwicklungsumgebung für chinesische Retro-Spielautomaten erstellt.
Dann denke ich, dass viele Leute mit vielen Ideen etwas Gutes machen werden.
Beim Einschalten wurde der RetroFW-Bildschirm angezeigt. Wenn Sie dies als Keyword googeln, finden Sie RetroFW sofort.
Laden Sie die Release-Datei [RetroFW_v1.2.zip] herunter (https://github.com/retrofw/firmware/releases/download/1.2/RetroFW_v1.2.zip) und sehen Sie sich den Inhalt an.
Wenn Sie die Zip-Datei entpacken, werden RetroFW.img, die Batch-Datei, dd.exe und verschiedene uBoot.bin und uImage.bin in den Unterordnern angezeigt.
Wenn Sie in die Batchdatei schauen, können Sie sehen, dass der Prozess des Schreibens von uBoot.bin und uImage.bin an einen bestimmten Speicherort in RetroFW.img mit dd.exe geschrieben ist. RetroGame_v1.0_S_B.bat lautet beispielsweise wie folgt.
bat:RetroGame_v1.0_S_B.bat
dd if=kernel/RetroGame_v1.0_S_B.uBoot.bin of=RetroFW.img conv=notrunc bs=512 seek=1 && dd if=kernel/RetroGame_v1.0_S_B.uImage.bin of=RetroFW.img conv=notrunc bs=1024 seek=4096
Es ist ersichtlich, dass uBoot.bin vom Positionsversatz um 512 Bytes ab dem Dateianfang und uImage.bin vom Positionsversatz um 4 MB vom Dateianfang an geschrieben wird.
U-Boot wird unmittelbar nach dem Einschalten in der Anfangsphase in Betrieb genommen und startet das Betriebssystem nach der Initialisierung der Hardware. Es ist ein sogenannter Bootloader, der Leistung erbringt.
Da dies an einer Position geschrieben ist, die 512 Bytes vom Anfang der Datei entfernt ist, liest der in dieser chinesischen Retro-Spielmaschine verwendete Chip von der Position 512 Bytes, die vom Anfang der microSD (vorübergehend als LBA 1 eingestellt) versetzt ist, in den RAM und springt. Sie können sich vorstellen, dass es einen Mechanismus hat.
Darüber hinaus kann man sich vorstellen, dass dieser U-Boot so geschrieben ist, dass er uImage.bin liest, das sich an einer Position befindet, die vom Beginn der microSD um 4 MB vom Beginn der microSD in den RAM versetzt ist, und springt.
Bei RetroFW.img sieht es so aus, als wären die ersten 512 Bytes MBR.
Das Extrahieren nur des leicht verständlichen Teils der Partitionstabelle und das Erstellen einer Tabelle ist wie folgt.
| Partitionsnr. | Erster Sektor(LBA) | Anzahl der Sektoren | Partitionstyp |
|---|---|---|---|
| #1 | 0x0000_4000 | 0x0004_0000 | Linux |
| #2 | 0x0004_4000 | 0x0008_0000 | Linux swap |
| #3 | 0x000c_4000 | 0x0013_c000 | FAT32 |
| #4 | - | - | Frei |
Wenn Sie RetroFW.img mit einem Binäreditor wie oben beschrieben betrachten, sehen Sie, dass die erste Partition (ab Offset 0x0080_0000) rootfs und die zweite Partition (ab Offset 0x0800_0000) Swap ist.
Die dritte Partition (ab Offset 0x1800_0000) ist jedoch für eine Weile mit 0 gefüllt. In diesem Fall schlägt das Mounten unter Linux wahrscheinlich fehl, und es wird angenommen, dass der Vorgang im Fehlerfall vorinstalliert ist.
Insbesondere wenn die Bereitstellung mit FAT32 fehlschlägt, wird mkfs ausgeführt. Wenn Sie ein etwas raffinierteres Design haben, können Sie den FAT32-Bereich bis zum Ende der microSD und dann von mkfs (raspbian) erweitern. ) Weil das der Fall ist). Sie können die Bewegung tatsächlich überprüfen.
Der Ausführungscode sollte ab Offset 0 von MBR im Loader-Teil platziert werden, und es wird tatsächlich etwas geschrieben, aber es ist schwierig zu beurteilen, ob es mit diesem Chip identisch ist.
Versuchen Sie vorerst Reverse Assemble für die ersten 4 Bytes, FA B8 00 10 ...
00000000 1000b8fa b loc_fffee000
Es handelt sich also um einen relativen Sprungbefehl, und das Sprungziel scheint in Minusrichtung zu liegen. Fühlen Sie sich nicht so, als wäre das noch nicht erledigt. Anstatt weiter zu graben, sollten Sie versuchen, einen zufälligen Wert zu schreiben und tatsächlich zu sehen, was passiert.
Ich habe bisher mit einem Binäreditor gesucht, aber festgestellt, dass es einfacher ist, dies mit einem Linux-Computer zu überprüfen.
$ fdisk -l ./RetroFW.img
Disk ./RetroFW.img: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbb005712
Device Boot Start End Sectors Size Id Type
./RetroFW.img1 16384 278527 262144 128M 83 Linux
./RetroFW.img2 278528 802815 524288 256M 82 Linux swap / Solaris
./RetroFW.img3 802816 2097151 1294336 632M c W95 FAT32 (LBA)
Da habe ich nachgesehen. Es ist eine große Sache, also werde ich noch ein bisschen weiter gehen.
$ sudo mount -t ext4 -o ro,loop,offset=8388608 RetroFW.img /mnt
$ file /mnt/bin/busybox
/mnt/bin/busybox: setuid ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
$ readelf -a /mnt/bin/busybox
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x402fb0
Start of program headers: 52 (bytes into file)
Start of section headers: 800132 (bytes into file)
Flags: 0x50001007, noreorder, pic, cpic, o32, mips32
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 26
Section header string table index: 25
:
Attribute Section: gnu
File Attributes
Tag_GNU_MIPS_ABI_FP: Hard float (double precision)
Es ist eine Binärdatei von MIPS32 und scheint einen mit FPU ausgestatteten Chip zu verwenden.
Es gibt Informationen, dass ein Chip namens JZ4760 verwendet wird, wenn ich mit dem Produktnamen der chinesischen Retro-Spielmaschine gegoogelt habe, die ich tatsächlich gekauft habe Ingenic Semiconductor --Wikipedia Wenn Sie sich ansehen, können Sie Informationen mit FPU mit MIPS32 rev1 erhalten.
Sie können auch sehen, dass die Binärdatei für die Verwendung von [uClibc] erstellt wurde (https://www.uclibc.org/).
Wenn Sie sich die U-Boot-Binärdateien mit einem Binäreditor ansehen, sehen Sie, dass folgende Versionen verwendet werden.
text:RetroGame_v1.0_S_B.uBoot.bin
U-Boot 1.1.6 (Jul 26 2018 - 14:28:08)
Wenn es um 1.1.6 geht, ist es wahrscheinlich um 2006, und ich verwende eine sehr alte. Nun, da es ein Bootloader ist, kann es alt sein?
Die aktuelle Release-Version scheint v2019.07 zu sein, aber ich kann keine Implementierung für jz4760 [Implementierung von jz4780] finden (https://gitlab.denx.de/u-boot/u-boot/tree/master/arch/) mips / mach-jz47xx) Es scheint nur einen zu geben.
text:RetroGame_v1.0_S_B.uBoot.bin
Board: Ingenic LEPUS (CPU Speed %d MHz)
Ich habe auch die Zeichenkette gefunden. LEPUS scheint der Name des Referenzdesign-Boards zu sein. Wenn Sie also nach diesem Schlüsselwort suchen, finden Sie möglicherweise eine Implementierung für jz4760.
Vorerst habe ich so etwas wie u-boot-1.1.6-jz-20120904-r1819.patch.gz gefunden. Es enthält eine solide Implementierung für den jz4760. Die Implementierung des Teils, der RAM verfügbar macht, kann Parameter enthalten, die von Kartenkonstanten abgeleitet sind. Der Schlüssel ist, ob die Platine gemäß dem Referenzdesign entworfen wurde.
Wenn Sie sich die uImage-Binärdatei mit einem Binäreditor ansehen, sehen Sie, dass die verwendete Version wie folgt lautet.
text:RetroGame_v1.0_S_B.uImage.bin
Linux-2.6.31.3
Vielleicht ist es ungefähr 2009, ich benutze einen alten.
Die aktuelle stabile Version scheint 5.2.14 zu sein, aber ich kann auch keine Implementierung für jz4760 finden [Implementierung von jz4740, jz4770, jz4780](https://git.kernel.org/pub/scm/linux/kernel/ Es scheint git / stabile / linux.git / tree / arch / mips / jz4740 zu geben? H = v5.2.14). Es wurde geschrieben, dass der Unterschied zu jz4740 die Taktfrequenz, das Vorhandensein oder Fehlen einer FPU und das Vorhandensein oder Fehlen einer GPU ist, sodass es möglicherweise mit dem Build für jz4740 funktioniert (wirklich?).
Dies ist auch eine GPL. Wenn Sie also danach suchen, finden Sie möglicherweise eine Implementierung für jz4760.
Vorerst habe ich so etwas wie linux-2.6.31.3-jz-20120904-r1448.patch.gz gefunden. Es enthält eine solide Implementierung für den jz4760.
Als ich nach der Standardentwicklungsumgebung für RetroFW suchte, fand ich sie schnell.
[Tutorial](https: // Weiterleitung.) Geschrieben in Thema: RetroFW - Entwickler-Support-Thread. viglink.com/?format=go&jsonp=vglnk_156881591905714&key=5150cb74f98acee214af0b53b6829d41&libId=k0pcfxgc0102ljt2000DAwfv3cbhjannx&loc=https%3A2 % 2Fdocs.google.com% 2Fdocument% 2Fd% 2F19kJXO3EZ8XCoeporuUUgV_S93AaPbSagza3sAgBILu8% 2Fedit% 3Fusp% 3Dsharing & title = RetroFW% 20-% 20Developer% 20Support 20% 20% 2% 20% 20% 20% 20% 20% 20% 20% 20% % 20Konfigurieren von% 20a% 20Toolchain% 20for% 20RetroFW% 20Development) war es einfach, ein Beispiel-IPK zu erstellen.
Die wichtigsten Punkte im Tutorial sind wie folgt.
Im Tutorial habe ich VirtualBox verwendet, um die Betriebsumgebung von Ubuntu vorzubereiten, aber ich habe Windows Subsystem für Linux ausprobiert. Als ich versuchte, Ubuntu (/ wiki / Windows_Subsystem_for_Linux) zu verwenden, konnte ich es bis auf einige Teile ohne Probleme erstellen. Die Erklärung der Einführung der WSL entfällt.
Installieren Sie als Nächstes das Paket zum Erstellen von BuildRoot unter Ubuntu von WSL. Wie folgt.
$ sudo apt install build-essential libncurses5 libncurses5-dev git python unzip bc
Als nächstes holen Sie sich BuildRoot und bauen.
Die Version von BuildRoot ist für die Verwendung von 2018.02.9 angegeben, und es wird angegeben, dass sie nicht verwendet wird, selbst wenn Sie feststellen, dass eine neue Version veröffentlicht wird (da sie für die Version der Toolkette empfindlich ist).
$ wget https://buildroot.org/downloads/buildroot-2018.02.9.tar.gz
$ tar -xzvf buildroot-2018.02.9.tar.gz
$ cd buildroot-2018.02.9
$ make menuconfig
Die Buildroot-Konfiguration wird wie folgt beschrieben.
Target Options
Target Architecture - MIPS (little endian)
Disable soft-float
Toolchain
C library (uClibc-ng)
Enable WCHAR support
Enable C++ support
Target Packages
Graphic libraries and applications (graphic/text)
SDL
SDL_gfx
SDL_image
SDL_mixer
SDL_net
SDL_sound
SDL_TTF
Alles was Sie tun müssen, ist zu bauen. Das Erstellen der gesamten Toolkette (Cross Compiler) nimmt viel Zeit in Anspruch.
$ export FORCE_UNSAFE_CONFIGURE=1
$ make
Ich mache rootfs während make, aber in der WSL scheint dies ein Fehler zu sein (was fakeroot ist, was gefälscht ist). Dieses Mal muss nur eine Entwicklungsumgebung erstellt werden, und rootfs wird nicht verwendet, sodass es ignoriert wird. Als ich das gleiche Verfahren mit VirtualBox + Ubuntu 18.04.3 LTS versuchte, wurde der Build ohne Fehler abgeschlossen.
Danach wird es je nach Ihren Vorlieben geschrieben, um die Toolchain in das angegebene Verzeichnis zu kopieren und in den PFAD zu legen.
$ mkdir /opt/rs97tools
$ cp -R output/host/* /opt/rs97tools/
$ export PATH=/opt/rs97tools/mipsel-buildroot-linux-uclibc/sysroot/usr/bin:$PATH
$ export PATH=/opt/rs97tools/bin:$PATH
Es wäre schön, wenn mipsel-linux-gcc und sdl-config --libs damit ausgeführt werden könnten.
Sie können auch versuchen, das Beispielprojekt zu erstellen, wenn Sie möchten.
$ mkdir /opt/rs97apps
$ cd /opt/rs97apps
$ git clone https://github.com/jbanes/rs97-commander
$ cd rs97-commander
$ make
Es wurde festgestellt, dass Linux als Betriebssystem auf dem gekauften chinesischen Retro-Spielautomaten ausgeführt wird und der Emulator als Linux-Anwendung ausgeführt wird.
U-Boot und Linux sind ziemlich alt, aber da Tutorials vorbereitet sind, ist es einfach, eine Entwicklungsumgebung zu erstellen.
Beim Schreiben einer Anwendung, die SDL (1.2) entspricht, wurde außerdem festgestellt, dass sie auf einem chinesischen Retro-Spielautomaten betrieben werden kann.
SDL2 unterstützt RetroFW v2.0 befindet sich in der Entwicklung Ich freue mich darauf. Ich habe versucht, einen langfristigen Linux-Kernel zu portieren, um die Anwendungsentwicklungsumgebung zu verbessern, aber er wurde unterbrochen.
Versuchen Sie nun, U-Boot zu kompilieren, nachdem die Toolkette fertig ist.
U-Boot
$ wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.6.tar.bz2
$ tar jxvf u-boot-1.1.6.tar.bz2
$ cd u-boot-1.1.6
$ gzip -cd ../u-boot-1.1.6-jz-20120904-r1819.patch.gz | patch -p1
Lesen Sie dieses Beispiel und ändern Sie den Inhalt der Header-Datei unter "include / asm-mips". Grob gesagt wird es auf "statisch" korrigiert, wenn "extern" hinzugefügt wird, obwohl "inline" und "inline" hinzugefügt werden.
$ make lepus_msc_config
$ vi Makefile
(Beispiele aus SUBDIRS entfernt)
$ make
Dadurch wird "u-boot-msc.bin" erstellt. Ich habe nicht versucht, es zu funktionieren.
Es stellt sich heraus, dass die von BuildRoot erstellte Toolchain nicht mit der Version zum Erstellen von U-Boot übereinstimmt. Dies liegt daran, dass die Beschreibung von Page, die als Referenz zum Ändern der Header-Datei verwendet wurde, besagt, dass dieser Fehler auftritt, wenn die Toolchain neu ist.
Tatsächlich kann sogar gcc-mipsel-linux-gnu (gcc-7.4.0) erstellt werden, das unter Ubuntu von WSL installiert werden kann.
$ apt install gcc-mipsel-linux-gnu
Nachdem
Makefile
ifeq ($(ARCH),mips)
CROSS_COMPILE = mipsel-linux-gnu-
endif
Sie können es ändern, um zu machen.
Als ich nach .config fragte, wurde mir gesagt, dass ich keinen Quellcode habe (https://boards.dingoonity.org/ingenic-jz4760-devices/retrofw-developer-support-thread/msg190970/). # msg190970).
Darüber hinaus ist es besser, es von Grund auf neu zu machen. Nun, dieser wurde kompiliert und verlinkt, daher denke ich, dass es in Ordnung ist, wenn Sie ihn überprüfen und verschieben. Ich bin süchtig danach, wenn ich es nicht überprüfe, nachdem ich die Debugging-Methode untersucht habe, wenn es nicht funktioniert (ich frage mich, ob es LED-Debugging ist).
Linux
$ wget https://mirrors.edge.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.3.tar.gz
$ tar zxvf linux-2.6.31.3.tar.gz
$ cd linux-2.6.31.3
$ gzip -cd ../linux-2.6.31.3-jz-20120904-r1448.patch.gz | patch -p1
$ make lepus_defconfig
$ make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-mips
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
CC kernel/bounds.s
In file included from include/linux/compiler.h:40:0,
from include/linux/stddef.h:4,
from include/linux/posix_types.h:4,
from include/linux/types.h:14,
from include/linux/page-flags.h:8,
from kernel/bounds.c:9:
include/linux/compiler-gcc.h:86:30: fatal error: linux/compiler-gcc6.h: No such file or directory
#include gcc_header(__GNUC__)
^
compilation terminated.
/home/yochy/linux-2.6.31.3/./Kbuild:35: recipe for target 'kernel/bounds.s' failed
make[1]: *** [kernel/bounds.s] Error 1
Makefile:977: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
Daher wird es nicht so kompiliert, wie es ist. Der Compiler, den ich verwende, ist gcc-6.4.0, aber die Linux-Kernelquelle sagt, dass er gcc6 nicht kennt. In dem von Ingenic herausgegebenen Dokument (Ingenic Linux Development Guide) wird als gcc 4.1.2 verwendet.
Um weiterhin mit WSL arbeiten zu können, müssen Sie hierfür eine 64-Bit-Binärdatei erstellen. Für VirtualBox Ubuntu müssen Sie lediglich die 32-Bit-Zeilenzeitbibliothek und das vorgefertigte gcc-4.1.2 installieren.
Sobald Sie die Arbeit auf Ubuntu auf VIrtualBox ändern und die folgenden Schritte ausführen ...
$ cd /opt
$ sudo tar jxvf ~/mipseltools-gcc412-glibc261.tar.bz2
$ export PATH=/opt/mipseltools-gcc412-glibc261/bin:$PATH
$ sudo dpkg --add-architecture i386
$ sudo apt install libc6:i386
Jetzt können Sie es verwenden.
$ make lepus_defconfig
$ make
:
TIMEC kernel/timeconst.h
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at kernel/timeconst.pl line 373.
Diesmal beschwere ich mich über Perl. Sie können kernel / timeconst.pl unter hier neu schreiben.
Weiter ist so.
$ make
:
drivers/video/jz4760_lcd.c:141: error: 'LCD_CTRL_BST_64' undeclared here (not in a function)
Dies hängt mit der in .config definierten LCD-Deklaration zusammen.
.config
# CONFIG_JZ4760_LCD_TOPPOLY_TD025THEA7_RGB_DELTA is not set
CONFIG_JZ4760_LCD_TOPPOLY_TD043MGEB1=y
# CONFIG_JZ4760_LCD_TRULY_TFTG320240DTSW_18BIT is not set
Ich weiß nicht, welches auf y gesetzt werden soll, also ist es das fürs Erste. Das LCD_CTRL_BST_64 selbst befindet sich in arch / mips / include / asm / mach-jz4760b / jz4760blcdc.h, so dass # include es weitergibt.
Als ich nach .config gefragt habe, habe ich die Kernelquelle veröffentlicht erhalten ). Zu diesem Zeitpunkt ist die Portierung auf die aktuelle Kernel-Version nicht unmöglich, aber ich weiß nicht, ob die Anwendung ordnungsgemäß funktioniert. Ich denke, sie wird angehalten.
Ich habe festgestellt, dass RetroFW v1.2.1 angezeigt wurde, sodass der Unterschied zu v1.2 zum Zeitpunkt der Analyse nicht gut ist. Ich habe aus verschiedenen Richtungen nachgeforscht.
Zusammenfassend ist der Inhalt der gleiche. Wenn Sie sich die Release-Kommentare und die Commit-Nachricht ansehen, heißt das nicht, dass sich der Inhalt geändert hat.
Der Name der Batch-Datei, die den Inhalt von RetroFW.bin für jeden Spielautomaten neu schreibt, ist freundlich geworden.
Um ehrlich zu sein, wollte ich schreiben, dass Sie den FAT32-Bereich so aktualisieren können, wie er ist, ohne initialisiert zu werden, wenn Sie 0x0000_0000 bis 0x087f_ffff (Ende des Linux-Bereichs) von RetroFW.bin ausschneiden und in microSD schreiben, sodass Sie die Software nicht erneut installieren müssen. Es war. Es tut uns leid.
U-Boot/Linux kernel
U-Boot und Linux-Kernel waren gleich (sha256-Wert ist gleich). Es macht keinen Sinn, zu diesem Zweck zu aktualisieren.
RetroFW.img
Der Inhalt von RegroFW.img war unterschiedlich (der Wert von sha256 war unterschiedlich).
Da wir wissen, dass U-Boot und Linux-Kernel identisch sind, kann es einige Vorteile geben, wenn es einen Unterschied im Linux-Bereich gibt, der von MBR erhalten wird.
Deshalb habe ich RetroFW.img nach dem Offset 0x80_0000 (0x4000-Sektor in LBA) verglichen, aber leider war der Inhalt der gleiche.
Ich habe festgestellt, dass RetroFW v2.0 veröffentlicht wurde, daher habe ich den Unterschied zu v1.2 überprüft, der zum Zeitpunkt der Analyse verwendet wurde. ..
Aus der Schlussfolgerung heraus scheint es einen Versuch wert zu sein, da sich der Inhalt von BuildRoot geändert hat. Weitere Informationen finden Sie unter CHANGELOG.md.
Der U-Boot- und der Linux-Kernel sind (wahrscheinlich) gleich.
Beim MBR gab es einen kleinen Unterschied in der Partitionskonfiguration (Größe), daher werde ich ihn hier zeigen.
| Partitionsnr. | Erster Sektor(LBA) | Anzahl der Sektoren | Partitionstyp |
|---|---|---|---|
| #1 | 0x0000_4000 | 0x0004_f800 | Linux |
| #2 | 0x0005_3800 | 0x0007_0800 | Linux swap |
| #3 | 0x000c_4000 | 0x0013_c000 | FAT32 |
| #4 | - | - | Frei |
Der Linux-Bereich wurde leicht erweitert und der Swap-Bereich entsprechend reduziert. Der erste Sektor des FAT32-Gebiets hat sich nicht verändert.
Daher scheint es möglich zu sein, den FAT32-Bereich zu aktualisieren, ohne ihn zu initialisieren, indem nur die MBR- und Linux-Bereiche ersetzt werden.
Wenn Sie die gemeinsam veröffentlichte Version von BuildRoot überprüfen, wird anscheinend 2018.02.11 verwendet (von CHANGES). Das oben gezeigte Tutorial sagt, dass 2018.02.9 verwendet werden soll, aber es scheint, dass die Version aktualisiert wurde.
RetroFW v2.1 wurde veröffentlicht.
Seit Version 2.0 und höher werden die Aktualisierungsinformationen freundlicherweise geschrieben. Lesen Sie daher den verknüpften Versionshinweis und entscheiden Sie, ob dies erforderlich ist oder nicht.
Übrigens, als ich versuchte, den FAT32-Bereich und früher zu ersetzen und zu aktualisieren, wurde die Neuinitialisierung ausgeführt. Vergessen Sie nicht, es zu sichern, da es verloren gehen wird.
RetroFW v2.2 wurde veröffentlicht.
Aus irgendeinem Grund werden die Aktualisierungsinformationen diesmal nicht richtig geschrieben. Es gibt so etwas in Readme.md, aber was ist die Q.O.L.-Änderung der Systemwiederherstellung (Ist Q.O.L. in diesem Fall die Quarität des Lebens?).
Die Image-Datei ist diesmal etwas seltsam, sie enthält nur eine Partition.
| Partitionsnr. | Erster Sektor(LBA) | Anzahl der Sektoren | Partitionstyp |
|---|---|---|---|
| #1 | 0x0000_4000 | 0x0004_f800 | Linux |
| #2 | - | - | Frei |
| #3 | - | - | Frei |
| #4 | - | - | Frei |
Als ich es auf die microSD schrieb und die Stromversorgung einschaltete, lief der Initialisierungsprozess selbstverständlich ab. Es fühlt sich an, als wäre es früher als die vorherige Verarbeitung beendet. Die Partitionsstruktur nach dem Initialisierungsprozess war wie folgt.
| Partitionsnr. | Erster Sektor(LBA) | Anzahl der Sektoren | Partitionstyp |
|---|---|---|---|
| #1 | 0x0000_4000 | 0x0004_f800 | Linux |
| #2 | 0x0005_3800 | 0x0007_0800 | Linux swap |
| #3 | 0x000c_4000 | 0x01c6_a000 | FAT32 |
| #4 | - | - | Frei |
Der FAT32-Bereich ist breiter als zuvor.
Die Größe der Bilddatei beträgt übrigens 175.112.704 Byte, aber dies ist der Sektor 342.017 (0x53801), und er schneidet nur in die Partition der Auslagerungsdatei. Gibt es einen Grund, warum ich es nicht um einen Sektor kleiner gemacht habe?
Übrigens, wenn ich Readme.md ein wenig mehr lese, heißt es, dass libopk und opkrun importiert wurden und PyMenu und SimpleMenu verfügbar wurden. Ähm ... PyMenu, SimpleMenu.
Mal später etwas mehr sehen.
[Master Boot Record-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%83% 96% E3% 83% BC% E3% 83% 88% E3% 83% AC% E3% 82% B3% E3% 83% BC% E3% 83% 89)
Recommended Posts