Guten Tag, ich habe ein Tablet mit einen M805ND-MB Mainboard welches einen ARM Cortex A9 Prozessor in einem Amlogic 8726-MX SoC besitzt incl. ARM Mali 400 MP. Der Kernel (Linux) für dieses Mainboard ist frei zugänglich und mit GPU Treibern quelloffen. Ich habe nun die Interesse das Tablet verstehen zu lernen und mehrere Fotos von der Plantine des Tablets gemacht: https://www.dropbox.com/sh/ux4pd4hezdkiwdx/AAA3I4Rm8DB-OJCyyyuw4R7Ra?dl=0 Auf Foto0094.jpg sind Anschlüsse mit dokumentierten also den weiß gestempelten Beschriftungen zu sehen. Einige davon sind mir klar wie B+, B- und TC, welche für den Akku sind. Auf der anderen Seite von der der SoC unter dem silber farbenden Deckel aufgelötet ist, gibt es RX, TX, GND und VCC Pins und ich benutze alle außer den VCC, weil der Akku schon die benötigte Energie oder das Netzteil die benötigte Energie bereitstellt. Ich frage mich jetzt wofür die anderen Anschlüsse alle da sind, irgendwie ist es sicherlich möglich zum Beispiel den MBR Code zu debuggen und somit zu sehen was genau gemacht wird? Mein Tablet hat irgendwo ein eingebautes BIOS, kann sein das dies im SoC oder auf der Plantine ist, das weiß ich aber nicht. Ich freue mich sehr auf Ideen, um die Anschlüsse zu benutzen. Danke, mit freundlichen Gruß, Joe
:
Verschoben durch User
Joe L. schrieb: > Mein Tablet hat irgendwo ein eingebautes BIOS, kann sein das dies im SoC > oder auf der Plantine ist, das weiß ich aber nicht. Nö, hat sie nicht. BIOS gibts nur auf dem PC, bei den ARM Kisten heist das Ding allgemein "bootloader" - meistens UBoot oder RedBoot. Der JTAG zum Debuggen ist gekennzeichnet (TDI,TDO,TMS, TCK). Aber Achtung: Ein JTAG Debugger sollte da besser einen Pegelwandler haben, keine Ahnung was der da an Spannung verträgt. Oftmals sind da aber Pullups dran, also einfach mal Multimeter ran halten.
Okay hört sich ja soweit ganz gut an. Das Tablet nicht in Rauch aufzulösen, ist keine gute Idee. Mein Tablet hat ein MBR: https://www.dropbox.com/s/n8rqhhwh9an6ccs/bootloader.img?dl=0 Danach folgt eine UCL Passage, näheres kann ich nicht herauffinden, danach 0x8000 ist eine MS-DOS binär ausführbare Datei (COM) dort ist in der Tat U-Boot als Bootloader drin, den MBR leer zu lassen hat mein Tablet garnicht zum starten gebracht. Und wenn ich die MS-DOS Executable weg lasse kommt eine sehr limitierte Shell wo ich die nachladen kann, fragt halt nach die Speicheradresse. Ich wprde mich sehr freuen wenn ich den U-Boot Bootloader mit einem neurem ersetzen kann und mich zum Mainstream hinzufügen kann. MBR kann trusted Firmware von ARM sein? Nicht wahrscheinlich. Will den auch mit etwas quelloffem ersetzen. mfg, Joe
Hallo, das mit dem MBR bei meinem Tablet, ist kein Spaß gewesen, sondern der ist wirklich da. (Amlogic Chipsatz). Ich habe den Nand Speicher ausgelötet war nur ein 8GB. Und dann gibt das Tablet in der seriellen Konsole nur sowas aus:
1 | EEEE I3000000032940xff00dead16<22030EEEE I600000006294NO boot up device found1286?1:2EEEE I500000005294enter serial boot13549030 |
Wenn ich dann meine MicroSD Karte einlege wo nur der MBR drauf ist gibt das Tablet folgendes aus:
1 | EEEE I3000000032940xf100110303;77500EEEE I400000004294_M6_BL1_3431>2534313 |
Diese Ausgabe gibt es aber nicht vom MBR selber sondern von einen versteckten Speicher. Das heißt irgendwo auf dem Mainboard wird noch ein weiterer Speicher sein, auch wenn es nur der SoC ist. In meiner Dropbox sieht man die MTD Partition Bootloader, also dessen Inhalt. Ich frage mich jetzt nur, kann es ein Tablet mit MBR geben? Ist das möglich?
:
Bearbeitet durch User
Auf einem PC enthält der MBR den x86-Bootcode (die ersten 448 Bytes) und die Partitionstabelle (die letzten 64 Bytes). Das Tablet wird nur die Partitionstabelle auswerten, um die Bootpartition zu finden, um davon booten zu können. Das interne Boot-ROM wird dafür einen FAT-Treiber beinhalten, mit dem es nach einer bestimmten Datei sucht, die es dann lädt und ausführt. Das Datenblatt sollte genaueres dazu sagen. Ansonsten gibt's xda-developers und ähnliche Quellen.
Hallo, ich bedanke mich erstmal für deinen Beitrag svenska. Klingt als wenn ich das umgehend ausprobieren sollte, werde Stück für Stück den Bootcode des MBR's auf Nullen setzen, und sehen ab wann der nicht mehr bootet. Aber leider gibt es auch schon einen Kritikpunkt, und zwar ist die FAT32 Partition genau da beginnend bei 1 MB oder so, wo nun wirklich nichts ist, ich kann das Tablet auch von MBR Anfang bis MBR Ende und dann bis zu 0x8000 wo dann die MSDOS COM EXE kommt flashen und dann ist der Bootloader weg, also U-Boot und nur eine sehr limitierte Eingabeaufforderung ist vorhanden:
1 | wait pll-0x03 target is 0204 now it is 0x00000203 |
2 | set ddr clock ok! |
3 | |
4 | DX0DLLCR:40000000 |
5 | DX0DQTR:ffffffff |
6 | DX0DQSTR:3db05001 |
7 | DX1DLLCR:40000000 |
8 | DX1DQTR:ffffffff |
9 | DX1DQSTR:3db05001 |
10 | DX2DLLCR:40000000 |
11 | DX2DQTR:ffffffff |
12 | DX2DQSTR:3db05001 |
13 | DX3DLLCR:40000000 |
14 | DX3DQTR:ffffffff |
15 | DX3DQSTR:3db05001 |
16 | Stage 00 Result 00000000 |
17 | Stage 01 Result 00000000 |
18 | Stage 02 Result 00000000 |
19 | Stage 03 Result 00000000 |
20 | HHH
|
21 | 0x000000c8
|
22 | ucl decompress |
23 | decompress finished |
24 | Enter Debugrom mode at /home/jxguo/work/m64.1/bootloader/arch/arm/cpu/aml_meson/common/firmware/loaduboot.c:0x0000003f |
25 | >
|
Also wenn der die EXE nicht bei 0x8000 findet befindet der sich in den oben gezeigten Modus, so und am Mittwoch oder Donnerstag habe ich dann den MBR soweit es geht auf Nullen gesetzt und wenn dann alles nich funktioniert, dann habe ich keine Zeit mehr mit den Teil zu verschwenden. ^^ U-Boot lädt das Kernel Image von einer bestimmten Speicheradresse, kann aber auch auf einem FAT32 Dateisystem sein, aber U-Boot lädt es, somit gibt es keine Boot ROM. Die Boot ROM also das Art BIOS ist das was mit den 4 E's anfängt, und dies ist nicht auf der MicroSD Karte sondern irgendwo im SoC eingebrannt. Die BootROM guckt nach ob ein Boot Gerät gefunden werden kann, andernfalls geht das in einem seriellen Boot-Modi. Mal schauen, bei Ideen einfach nur einen Beitrag schreiben und hoffentlich hilft der mir. Danke. Bis Mittwoch oder Donnerstag. :) MfG Joe
Normalerweise landen die einzelnen Bereiche des Flash in Slices. Siehe das folgende Beratungsmuster:
1 | brw------- root root 179, 0 2017-05-18 00:34 mmcblk0 |
2 | brw------- root root 179, 1 2017-05-18 00:34 mmcblk0p1 |
3 | brw------- root root 179, 10 2017-05-18 00:34 mmcblk0p10 |
4 | brw------- root root 179, 11 2017-05-18 00:34 mmcblk0p11 |
5 | brw------- root root 179, 12 2017-05-21 15:55 mmcblk0p12 |
6 | brw------- root root 179, 13 2017-05-21 17:18 mmcblk0p13 |
7 | brw------- root root 179, 14 2017-05-18 00:34 mmcblk0p14 |
8 | brw------- root root 179, 15 2017-05-18 00:34 mmcblk0p15 |
9 | brw------- root root 179, 16 2017-05-18 00:34 mmcblk0p16 |
10 | brw------- root root 179, 2 2017-05-18 00:34 mmcblk0p2 |
11 | brw------- root root 179, 3 2017-05-18 00:34 mmcblk0p3 |
12 | brw------- root root 179, 4 2017-05-18 00:34 mmcblk0p4 |
13 | brw------- root root 179, 5 2017-05-18 00:34 mmcblk0p5 |
14 | brw------- root root 179, 6 2017-05-18 00:34 mmcblk0p6 |
15 | brw------- root root 179, 7 2017-05-18 00:34 mmcblk0p7 |
16 | brw------- root root 179, 8 2017-05-18 00:34 mmcblk0p8 |
17 | brw------- root root 179, 9 2017-05-18 00:34 mmcblk0p9 |
18 | brw------- root root 179, 32 2017-05-18 00:34 mmcblk1 |
19 | brw------- root root 179, 33 2017-05-18 00:34 mmcblk1p1 |
In "mmcblk0" sind die Slices "mmcblk0p1" bis "mmcblk0p16". Im Slice "mmcblk1" ist nur ein Subslice. Auf dem wird in diesem Beispiel eine SD-Karte emuliert. Die jeweiligen Groessen koennen in einem Configbereich stehen. Das wuerde dann auch einer dieser Slices sein. Muss aber nicht. Das liegt alles in der Freiheit des Herstellers seine Spezifikation nach seinem Gusto zu stricken. Und wenn der SoC halt gerne einen MBR moechte, erzeugt das nur eine Indirektionsebene mehr. X86-Code aus dem MBR wird er deswegen trotzdem nicht ausfuehren. Und unter Umstaenden stimmen die Angaben im MBR auch fuer den realen Betrieb auch nicht, weil sie schlicht nicht benoetigt werden, sondern nur zum Booten... Was war jetzt das genaue Ziel? Ein selbst uebersetztes uBoot auf das System zu tun? Oder von der SD-Card zu booten?
Joe L. schrieb: > Klingt als wenn ich das umgehend ausprobieren sollte, > werde Stück für Stück den Bootcode des MBR's auf Nullen > setzen, und sehen ab wann der nicht mehr bootet. Du hast keine Ahnung, wie das System funktioniert, und stocherst ziemlich gewaltig im Nebel. Einfach mal das Flash löschen bringt nur wenig Erkenntnis. > Aber leider gibt es auch schon einen Kritikpunkt, > und zwar ist die FAT32 Partition genau da beginnend > bei 1 MB oder so, wo nun wirklich nichts ist, Ja, das macht man auf Flash-Speichern so. Nennt sich "Alignment" und hat nichts zu bedeuten. > ich kann das Tablet auch von MBR Anfang bis MBR Ende und dann bis > zu 0x8000 wo dann die MSDOS COM EXE kommt flashen Es gibt keine "MSDOS COM EXE" im MBR. Wenn da zufällig x86-Bootcode drin ist, dann nur, weil das Formatierungsprogramm da welchen hingekleistert hat. Der wird aber nie gelesen, geschweigen denn ausgeführt. Du laberst am Thema vorbei. > und dann ist der Bootloader weg, also U-Boot und nur eine > sehr limitierte Eingabeaufforderung ist vorhanden: Ich gratuliere dir schonmal herzlich, dass du dein Device nicht komplett gebrickt hast. "Einfach mal den U-Boot löschen" macht viele Devices zu JTAG-Pflegefällen, die man dann am ökonomischsten neu kauft, ehe man sie zu retten versucht. Schau ins Datenblatt vom Chip, wie der aus dem internen Flash bootet, und wenn es dafür kein Datenblatt gibt, dann nimmst du dir eben ein beliebiges anderes Datenblatt. Die modernen ARM-SoCs funktionieren alle mehr oder weniger gleich. > Also wenn der die EXE nicht bei 0x8000 findet befindet ...das ist grober Unfug. Schau ins Datenblatt. > U-Boot lädt das Kernel Image von einer bestimmten Speicheradresse, kann > aber auch auf einem FAT32 Dateisystem sein, aber U-Boot lädt es, somit > gibt es keine Boot ROM. Klar gibt es ein Boot ROM. Irgendwer muss den Speicher ja initialisieren und U-Boot laden... Schau ins Datenblatt. > Die Boot ROM also das Art BIOS ist das was mit den 4 E's anfängt, und > dies ist nicht auf der MicroSD Karte sondern irgendwo im SoC > eingebrannt. Ich dachte, es gibt kein Boot ROM? Jetzt auf einmal doch? > Die BootROM guckt nach ob ein Boot Gerät gefunden werden > kann, andernfalls geht das in einem seriellen Boot-Modi. Bist du sicher? > Mal schauen, bei Ideen einfach nur einen Beitrag schreiben und > hoffentlich hilft der mir. Dir hilft keine tolle Idee, sondern entweder eine Schritt-für-Schritt-Anleitung oder der Hinweis, dass du dir endlich ein Datenblatt besorgen sollst, um rauszukriegen, wie dein Chip überhaupt funktioniert. Du hast nämlich keine Ahnung, stocherst im Nebel und wunderst dich, dass du nichts sinnvolles erkennen kannst. Wie auch, der Nebel ist ja im Weg.
Hallo, der MBR also der Bootcode davon wird sehr wahrscheinlich x86 Code, und dahingekleistert sein. ^^ Mein Tablet bricken? Ich habe den Nand Flash Chip ausgelötet, und dann von einer MicroSD Karte unseren fake-MBR incl. die MSDOS EXE die bei 0x8000 beginnt geflasht dort ist U-Boot drinne. Ich werde nun umgehend den MBR durchleuchten, und schauen ob es ein Fatenbkatt dieses Mainboards oder besser gesagt des Chipsatzes gibt, bin aber nicht fündig geworden, im Kernel Device Tree Code, gibt es ein Bild wo das Schema des SoC Amlogic 8726-MX drauf ist, kann aber auch ein falsches Bild sein. MfG Joe
Hallo, ich habe jetzt die MBR Signatur 55AA durch Nullen ersetzt und das Tablet startet immernoch, auch wenn die FAT32 Partition weg ist startet das Tablet immernoch und zwar wartet es dann:
1 | ucl decompress |
2 | decompress finished |
3 | Enter Debugrom mode at /home/jxguo/work/m64.1/bootloader/arch/arm/cpu/aml_meson/common/firmware/loaduboot.c:0x0000003f |
4 | >
|
Und dann würde jetzt eigentlich die Datei von 0x8000 ausgeführt werden wo U-Boot drinne ist. Habe in den 512 Bytes Sektor auch die M3HHREV0 durch Nullen etnsprechend ersetzt und sas Tablet geht nicht mehr an. Allein das Flashen von einen 512 Byte Sektor der Nullen beinhaltet lässt das Tablet nicht starten. Ergebnis: Der MBR des Tablet's ist wichtig und kann aber ohne Signatur und FAT32 Partition ausgeführt werden. MfG Joe
Okay, ich habe tatsächlich mal Google angeworfen und bin fündig geworden. http://www.slatedroid.com/topic/95977-howto-create-a-rescue-sd-card-for-pretty-much-every-amlogic-8726-mx-device/ Erstens: Das, was du "MBR" nennst, ist kein MBR. Egal, wie oft du das wiederholst. Zweitens: Da ist auch keine DOS-EXE oder DOS-COM drin. Das gesamte Gerät hat mit DOS und der PC-Architektur nichts zu tun. Drittens: Das erste MB der SD-Karte enthält schlicht U-Boot, aber die Bytes 448 bis 512 enthalten eine gewöhnliche Partitionstabelle, damit die normalen Tools weiterhin funktionieren.
Ja genau, da muss es einen Übergang zu einem Computer geben, damit due SD Karte auch Partitionen haben kann. Mein Tablet hat als OS Android ich habe alles was das Tablet braucht auch die /data und die /system und die /cache Partitionen als ext2 auf meiner MicroSDKarte gemacht und dann bin ich in Android gelandet. Und das ohne den 8 GB Nand Chip, der bei mir zu viele Badblocks hatte. MBR kann bei der Signatur die ich weg lassen kann, nun wirklich nicht stimmen. ^^ Also das Tablet hat einen eingebrannten BootROM Code welcher seriell oder per MicroSDKarte oder wenn der Nand vorhanden wäre, gewissen Code nachlädt. Wäre nur gut wenn ich genau wüsste wie ich den Code der unnötig ist löschen kann und durch Nullen ersetzen kann, oder gleich sofort U-Boot Bootloader direkt ersetzen mit etwas was auch USB Boot kann. Wie ARM startet: http://www.fedevel.com/welldoneblog/2013/10/how-does-arm-boot/ Ich habe damals mein Tablet mit der Anleitung von Christian Troy wieder ans laufen bekommen nachdem es angeblich gebrickt war, U-Boot war aber noch da, und habe dann von einer MicroSD Karte dort drauf ein FAT32 Dateisystem über U-Boot ein uImage_recovery geladen was mir mein Tablet wieder einrichten lies. uImage_recovery ist eine Datei mit einem 64 Byte Kopf für U-Boot danach folgt ein *.lzma Archiv wo Kernel und ein rootfs.cpio Archiv ist mit einem Android Recovery wie TWRP oder ClocmworkMod oder das AOSP Teil, von Google. Habe schon bisschen gebraucht die rootfs ramdisk zu finden und zu bearbeiten. ^^ Hier hat mein Chipsatz Hersteller alle Downloads: http://openlinux.amlogic.com:8000/download/ARM/u-boot/ Ich frage mich nun wie ich ein anderes U-Boot oder ein paar nützliche Funktionen zu meinem bestehenden Bootloader hinzufügen kann? Mein Ziel ist es ein selbst übersetztes U-Boot auf meinem Tablet zu tun, damit UBS-Boot geht und ich auch up to date bin. --> Hinzufügen zum Mainstream von U-Boot. Wofür ist UCL decompress? Entpackt es den Rest nach irgendwo? Weil in der 0x8000 Bereich bis Ende sind Strings die aber sehr komisch sind, unter anderem finden sich dort Strings die dann auch über UART auftauchen: http://www.pclinuxos.com/forum/index.php/topic,141540.msg1209225.html#msg1209225 (nach Terminal started) Geht es direkt mit einer Zeile BootROM und dann mit U-Boot los. Wäre sehr gut, wenn ich das Tablet open source bekäme, Mali 400 MP GPU Treiber sind es schon von Werk. ;) MfG Joe
:
Bearbeitet durch User
Guten Mittag, wie bekomme ich jetzt eine neuere Version des U-Boot Bootloaders auf meinem Tablet? Jetzige Version ist: U-Boot 2011.03-00000-g019561f-dirty(m6_yifang@next) (Nov 24 2012 - 11:25:03) Ich brauche unbedingt eine neue Version des Bootloaders mit USB-Boot an meinem Tablet, mit freundlichen Grüßen, Joe
Ich kenn deinen SoC nicht direkt, allerdings ist bei anderen Herstelern die Bootfolge per Strap einzustellen. Das ist oft ein Pullup/Pulldown bzw. eine Brücke.
Joe L. schrieb: > wie bekomme ich jetzt eine neuere Version des U-Boot Bootloaders auf > meinem Tablet? Wenn du so fragst, garnicht. Du weißt nicht, wie sehr der vorhandene U-Boot gepatcht wurde, welche Funktionen es Upstream nicht gibt, und was er tun muss. Also kümmer dich, ist dein Tablet, oder lass es.
Okay, ich habe davon keine Ahnung, vielleicht mache ich erstmal beim Kernel weiter. Fragt sich nur warum die verwendete Version meines Bootloaders nicht open source ist, obwohl die das sein muss. Ist alles komplex aber ich gebe nicht auf. Was kann ich mit JTAG erreichen? Gibt es da Möglichkeiten Reverse Engineering zu betreiben, seitens des Bootloaders??? Was habe ich genau von JTAG? Zumal mir fehlt das Sehen was der Prozessor so macht und was wo drinne steht, also den Registern, kann ich das per JTAG sehen? mfg
:
Bearbeitet durch User
Joe L. schrieb: > vielleicht mache ich erstmal beim Kernel weiter. Allzuleicht wird das auch nicht. Joe L. schrieb: > Fragt sich nur warum die verwendete Version meines Bootloaders > nicht open source ist, obwohl die das sein muss. Frag beim Hersteller an, der muss das veröffentlichen (bzw. wenn der Kernel veröffentlicht wurde, dann liegt der U-Boot vermutlich daneben). Wenn nicht, an GPL-Violations melden. Joe L. schrieb: > Was kann ich mit JTAG erreichen? Direktzugriff auf Flash und Prozessor (= Debugger), aber dazu musst du wissen, was die Bits bedeuten. Guckst du, was OpenOCD kann.
Hallo, Intenso ist der Verkäufer meines Tablets und Yifang ist der Hersteller meines Tablets. Habe hier den Quellcode für den Kernel bezogen und den erfolgreich fpr mein Tablet gebaut: http://www.intenso.de/downloads_en.php?kategorie=33&&produkt=1322562274 Lineare Toolchain Kompiler musste ich nehmen und dann konnte ich den Kernel mit make uImage oder ./run.sh oder um die GPU Module mit zu bekommen ./built_kernel.sh M805ND Der Kernel funktioniert. Ist der U-Boot Bootloader in dem Archiv drinnen von meinem Tablet Kernel? Ich jedenfalls habe den seit 5 Monaten noch nicht gefunden. mfg Joe PS: Ich habe jetzt mal enter debugrom mode at gegoogelt, halt das was mein Tablet ohne U-Boot ausgibt, und ja es sieht so aus als wenn ich auf dem Holzweg bin, ich suche nicht nachnden Quellcode für U-Boot sonder den Lader davor der diese U-Boot Datei bei 0x8000 lädt? Das klingt doch so als wenn das sein kann, ider was sagt ihr dazu? https://github.com/Pivosgroup/buildroot-uboot/blob/master/README.amlogic https://github.com/j1nx/Amlogic-reff16-uboot/blob/master/README.amlogic Andernfalls habe ich keine Ideen, und warum ist U-Boot bei 0x8000 diese debugmode ist hardware spezifisch und der U-Boot aucb aber oben drauf das muss es sein, anders kann ich mir das nicht vorstellen zurzeit. Bitte antworten, hoffe wir bekommen das hin, will mir dann Debian ARMHF auf dem Tablet machen oder Android LineageOS mit coolen selbst kompilierten Programmen (GNU tools und so)
:
Bearbeitet durch User
Zwei Worte zu diesem Thread: "Au Backe" ! --- Einen schönen Sonntag für Euch Martin
Hört sich ja sehr zuversichtlich an was das betrifft. Spaß beiseite U-Boot ist nicht einfach so auf dem Tablet bei 0x0, sondern dort ist auch wichtiges für das Mainboard und andere Hardwarespezifische Dinge. ;) Wüsste nicht wie sonst die rote LED angeht und zeigt dass das Tablet auflädt. Oder die gelbe LED, das dass Tablet schon aufgeladen ist. Sogar U-Boot scheint auf den sogenannten Debugmodus zuzugreifen, und zeigt unteranderem BMP Bilder als Ladeanimation an. Ob der Kernel irgendwo auch das Mainboard, also so eine Board Datei hat, weiß ich nicht, aber bestimmt. Ich muss nur den Debugmodus bauen, und bei dem mit dabei U-Boot kompilieren. Kling für mich auch logisch, das UCL, ist irgendsoein Entkomprimierungsprogramm, die Datei bei 0x8000 entpackt in den RAM. Reverse engineering, des Ganzen, lohnt rein garnicht, weil wo ist den UCL? Wo ist das Art Mainboard Layout? Es macht Sinn erst den Kernel fertig zu bekommen und dann Bootloader und Debugrom Modus. Dann macht das für mich auch Sinn den Kernel, alle Treiber zu kopieren und in einem neuem Kernel einzufügen und somit einen aktuellen Kernel für mein Tablet bekomme. Wenn ich U-Boot und den Debugrommodus ersetzt bekomme, kann ich endlich das Kernelimage anders aufbauen, und zwar so das es ein initrd.img und ein kernel-3.0.8-joe1.img gibt. Ließe schnelle Änderungen am Kernel initramfs zu. Irgendwie alles sehr komplex, aber anfangen muss ich selber. mfg Joe
Eine andere Möglichkeit wäre es den ARMv7 Befehlssatz zu virtualisieren am Computer, und dann mein Bootloader dort ausführen und gucken was passiert, hat jemand Ahnung von Virtualisierungssoftware für ARMv7? Thx
Joe L. schrieb: > Bitte antworten, hoffe wir bekommen das hin, Was habe ich davon, wenn ich mich tagelang im chinesischen Müll vergrabe und dir am Ende sage, wie du dein Problem lösen kannst? Nichts. Du verschwindest, ich habe Lebenszeit verschwendet, und kann damit nichtmal was anfangen. Nee, deine Hausaufgaben musst du schon selbst machen, tut mir Leid. Qemu kann ARMv7 virtualisieren.
:
Bearbeitet durch User
Aha okayyy.. Bin sozusagen in dem Gebiet neu, aber ich werde dann mal selber gucken, zumal das ganze mit Quellcode nicht so schwer sein kann und den richtigen Board Dateien. Mal schauen.
Hallo, kann bitte jemand mir erlauben meine Beiträge zu bearbeiten? Das Mainboard ist falsch benannt es heißt: M805NC-MB es gibt kein Mainboard mit einem D anstelle des C's. Bitte ändern! ;) Ich habe jetzt den Quellcode für mein Gerät kompiliert und es ist ein Amlogic 8726-MX m3 Gerät. D.h. es gibt schlichtweg kein M805NC-MB Quellcode für das Yifang Mainboard, sondern ein Quellcode (Archiv) für den SoC und so weiter. Ist also gelöst das Thema, jetzt kommt das Testen und das Modifizieren des Quellcodes und ggf. das Verstehen. Mit freundlichen Grüßen, Joe, Danke!
:
Bearbeitet durch User
Hallo, kann auch in den Betreff die Mainboardbezeichnung geändert werden? Es gibt noch 28x die falsche Bezeichnung die jetzt aber M805NC-MB lauten muss. Danke! MfG Joe
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.