[NON-DEV - OFFEN] IT Grundlagen über Android Geräte?

[Gelöschtes Mitglied 410096]

Hallo liebe Community,

mich interessieren schon lange Zeit die kleinen eingebetteten Systeme und da habe ich mich gefragt wie weiß das eingebettete System, was ja Android Geräte im sinne von Tablet, Smartphone und Smartwatch darstellt, das der Touchscreen dort gedrückt wird?

Ich habe etwas über HAL gelesen, was dafür sorgt das durch Software die Hardware so abstrakt wird, das wir mit dieser arbeiten können, es gibt halt so eine HAL Brille durch der wir gucken. Durch denLinux Kernel wird halt alles verei fachter aber auch für mich nicht verstehbar.

Wie wird zum Beispiel gemessen wie es um den Akku steht? Macht das der Prozessor, der ja alles blitzschnell seriell hintereinander verarbeitet, und für uns sieht das wie multitasking aus.

Ich fände es cool, wenn es endlich mal ein Thema um die Grundlagen der Android Geräte geht, was keine Betriebssysteme im dem sinne darstellt. Also Bootloader, Assembler, Prozessorbefehlssatz.

ARMv7 ist die Sprache die mein Prozessor beispielsweise versteht, also der Befehlssatz des Prozessors. Gibt es Assembler Befehle, die den Akku messen, Touchscreen, Bildschirmspeicher?

Sorry, falls das Thema für den ein oder anderen zu komplex erscheint, aber dieTechnik einfach blind zu verwenden ist doch langweilig, wenn man nicht weiß wie diese funktioniert.

Ich freue mich auf Antworten.

Mit freundlichen Grüßen,

Euer IntensoTab Forum Benutzer.

PS: Das Thema ist mir wichtig und ich weiß das Betriebssysteme nicht in diesem sinne, sondern in Hochsprachen programmiert werden müssen, um sich halt weniger Arbeit zu machen. Also man bedient sich sozusagen an einem Prozessor Alphabet

 

[swa00]

Hallo IntensoTab,

Deine Frage beruht eher auf das Grundwissen von Microcontrollern und dessen PeripherieChips - was Andres ist das Smartphone auch nicht

Vereinfacht erklärt gibt es eine CPU und diese wird über einen Signalbus betrieben (Jede Menge Pins)

Der Signalbus ist die Datenautobahn der angeschlossenen Chips , die wiederum ihre Arbeit tun.
Sei das ein Chip der die Spannung vom Akku misst , Sensoren auswertet und auch den Bildschirm unterstützt.
Die Ergebnisse dieser Chis werden wiederum über den Bus an den Prozessor geschickt, der dann die Bus-Signale auswertet.

Jeder Chip hat unterschiedliche Eigenschaften , weshalb es dann zu diesen Chips wiederum kleine Programme
gibt , die das wieder in eine genormte Schnittstelle liefern.(Die Treiber)

Für den Entwickler ist dann maximale Helligkeit immer 100 % , egal, was für ein Sensor-Hersteller verwendet wurde.

ARMv7 ist die Sprache die mein Prozessor beispielsweise versteht

Nein , das ist der Typ der CPU - Vergleichbar mit 4,5,6,8,12 Zylinder, Diesel oder Benziner.
Ohne PeripherieChips (Getriebe,Fahrgestell & Reifen) macht der Motor auch hier keinen Sinn)

Jede CPU wird in Maschinensprache betrieben. (Assembler). Auf Assembler bauen dann wieder
Low-Levelsprachen auf : z.b. C

Auf C baut dann wieder z.b. Java auf (Das hübsche Bunte auf deinem Display) -
welches in einer virtuellen Umgebung läuft (Zygote)
Und auf Java baut dann wieder die Android-Programmiersprache mit seinen Lego-Bausteinen auf
(Kopf & Fusszeilen , Menus, GoogleSearchleiste, Knöpfe, Regler usw.)

Wenn man also was Schnelles programmieren mag , dann macht man es am Besten direkt in Assembler
oder C (Allerdings dann ohne Blinki Blinki Bunti)

Treiber & Ansteuerung der CPU, verbaute Hardware und das Bootprogram werden dann im ROM
vom Hersteller "zusammengestellt". darüber wird dann Java gelegt.
Dann geht der Hersteller hin und packt noch seine UI Highlights dazu.



So das wäre es erst mal für die "Grundlagen"

Wenn du Interesse am Basteln hast : Es gibt jede Menge schöne Sachen für wenig Geld auf dem Markt
(Raspberry, Ardunio etc etc)

 

[Gelöschtes Mitglied 410096]

Danke nochmals für deine gute Antwort. Ich habe mich schon gefragt ob es eine North oder Southbridge gibt, aber denke nicht.

Mein Tablet ist wie ein Raspberry PI, nur die Hersteller und Verkäufer rücken den verpackten opensource Quellcode nicht heraus. Deswegen will ich das über Assembler -> Reverse engineering lösen.

Hier ist mein github: GitHub - IntensoTabcomputing/Bootloader: This repository contains the bootloader from the M805ND-MB Yifang SoC: Amlogic 8726-MX Tablet habe dies erst heute erstellt.

Weil ein SoC ein Chipsatz = Zusammenstellung von Chips ist, kann man optisch die unterschiedlichen Controller nicht sehen.

Auf ein Programm ohne Blink Blink in Assembler, da hätte ichrichtig lust drauf, aber das Ziel Gerät soll nunmal schon mein Tablet sein. Linux auf dem Desktop PC bin ich halt schon seit immer gewohnt. So lange gibt es mich ja noch nicht.

Ich frage mich nur wie ich das bewerkstellige die richtigen Assembler Befehle für den Bildschirm heraus zu bekommen. Ich muss ja die Beleuchtung einschalten, kann es sein das der Device-Tree (angepasster Linux-Kernel von mein Verkäufer), als eine Art Handbuch für die ein oder andere Komponente dienen kann?

Ist es möglich das allein der Bootloader und die vorherigen Boot Algorithm mein Tablet erst gewisse "Fähigkeiten" gibt? Zum beispiel das dass Display mit Beleuchtung nur wegen den Bootloader funktioniert, u d der Kernel keinen Einfluss darauf hat? Was ich aber direkt beantworten könnte damit, das wenn ich mein Gerät sperre dann die Beleuchtung und die Signale zum Bildschirm abgeschaltet werden.

Aber: Läuft der Bootloader mit dem Kernel als eine Komponente, oder nur der Kernel mit allem anderen Sachen?

Ich will mir zu dem oben genannten Punkt sicher sein, da ich erstmal meinen eigenen Betriebssystemkernel, also selbst kompiliert am laufen haben will. Kompiliert it der ja schon mit GPU Modulen, aber die RAMdisk ist noch nicht ganz komplett. ^^

Kann das funktionieren, das ich den Bootloader in Assembler Code erhalte und dann endlich meinen 2010 U-Boot bootloader aktualisieren kann?

Vielen Dank für weitere Antworten.

MfG

IntensoTab

 

[swa00]

Hallo Intenso

Auf ein Programm ohne Blink Blink in Assembler, da hätte ichrichtig lust drauf, aber das Ziel Gerät soll nunmal schon mein Tablet sein.

du gehst zu tief .

Du kannst auf jedem gerootetem Tablet/Smartphone schon mit SU arbeiten und dann auch jederzeit ein C/c++ prog einpflanzen.
(Sieh die Kiste wie einen Raspberry an)
Assembler lohnt sich nicht , du kannst aber gerne dazu dir die White Paper von der CPU nehmen
(Gibt ARM z.b. heraus)

Was die Peripherie-Chips betrifft , dann gibt es auch dazu White Papers - auch da kannst du eingreiffen.
Ich hätte aber erst mal meine Probleme damit , herauszufinden , welcher SensorChip verwendet wurde und was seine Kennlinie ist

Und auch unter AndroidStudio , kannst du dir jederzeit eine eigene C Library schreiben und schon sehr nahe
an die Systeme ebene kommen . (NDK)

SU Beispiele

////////////////////////////////////////////////////////////////////////////
    public void setDisplayOffset (int left,int top,int right,int bottom)
    {
     shootShell ("wm overscan " + left + "," + top + "," + right + "," + bottom);
    }
    ////////////////////////////////////////////////////////////////////////////
    public void setDisplayStatusbar (Boolean enabled)
    {
        if ( enabled ==  false)
        {
            shootShell("settings put global policy_control immersive.status=*");
        }
        else
        {
            shootShell("settings put global policy_control immersive.status=");
        }

    }
    ////////////////////////////////////////////////////////////////////////////
    public void setDisplayNavigationBar (Boolean enabled)
    {
        if ( enabled ==  false)
        {
            shootShell("settings put global policy_control immersive.navigation=*");
        }
        else
        {
            shootShell("settings put global policy_control immersive.navigation=");
        }

    }
    ////////////////////////////////////////////////////////////////////////////
    public void setDisplayFullScreen (Boolean enabled)
    {
        if ( enabled ==  true)
        {
            shootShell("settings put global policy_control immersive.full=*");
        }
        else
        {
            shootShell("settings put global policy_control immersive.full=");
        }

    }

 

[Gelöschtes Mitglied 410096]

Ein Gerät gerootet zu haben ist halt noch nicht alles, bzw für den ein oder anderen eine Sackgasse -> Brick

Da ich meine Kiste nicht bricken kann, außer ich ändere die EEPROM, kann man schön damit basteln. Es gibt sehr wenige optisch sichtbare Periperie Chips, Touchscreen Controller, Wifi-Controller sind so die Sachen die ich sehe.

Durch den Device-Tree kann ich vielleicht mehr erfahren, aber leider benutzt auch schon der Bootloader das Display, was schon interessant ist -> wie das halt funktioniert.

Nebebei kann der Bootloader Maleware und Virus und wie dasalles heißt haben. Wer gibt mir den dieSicherheit das das Gerät schon an seiner eigen
en Basis clean ist?
[doublepost=1500223745,1500216985][/doublepost]Immerhin weiß ich jetzt das ein 32-Bit Prozessor 32 Einheiten (können Nullen oder Einsen sein) sich so Stück für Stück durch das Programm begibt außer, wenn gesprungen wird, sowas wie Wenn Funktion.

Es gibt mehrere Passagen in dem Blob, also den Bootloader oder besser gesagr die 0x000 Software wo 32x Nullen sind, da macht der Prozessor nichts oder? Ist also zozusagen wie wenn eine Datei zu ende ist?

Ich mache lieber mit dem Kernel weiter, und sorge dafür das 4.x.x anstatt 3.0.8 auf dem Gerät läuft. Habe gelesen das die Kernel Kommandzeile von dem Bootloader auch einfach den Kernel nicht annimmt. Und der Kernel somit seine eigene Kommandzeile nimmt, wenn das dann so eingestellt ist.

Iwann bei langeweile versuche ich mal den Bootloader bis zu dem ersten 32x Nullen zurück zu entwickeln und dann teilweise die Software quelloffen zu bekommen. Oder nur Teile davon.

 

[markus.tullius]

Noch ein Nachtrag. Was du das siehst ist kein Assembler Code, sondern eine hexadezimale Darstellung des Maschiencode (Binärcode). Viele verwechseln das gerne.
Assembler ist ein Programmiersprache, wie C oder Java, mit mit normalen Befehlen. Nur nicht ganz so komfortable.

Hexadezimalsystem – Wikipedia
Maschinensprache – Wikipedia
Assemblersprache – Wikipedia


Wenn du das wirklich machen willst, solltest du C/C++ lernen. Und schau dich mal in den Forum um XDA-Developers Android Forums um.

Vielleicht bist mit ein Raspberry Pi besser bedient, es hat Schnittstellen für extra für Bastler, und ist super dokumentiert. Und ein Touchscreen kannst du dort auch anschließen. Raspberry Pi - Teach, Learn, and Make with Raspberry Pi

 

[Gelöschtes Mitglied 410096]

Was den Raspberry PI angeht, der hat ja eine GPIO ausgeführte Steckleiste. Es gibt hier den Quellcode meines verwendeten Amlogicsoftware+Bootloader: Amlogic-reff16-uboot/board/amlogic at master · j1nx/Amlogic-reff16-uboot · GitHub

Nun ist es so das ich dabei bin den Quellcode zu bauen, die Chancen stehen gut das es klappt. Und das es auch der Quellcode ist.

UART habe ich auch schon verwendet, hier sind weitere einzel Programme aufgelistet: Amlogic-reff16-uboot/README.amlogic at master · j1nx/Amlogic-reff16-uboot · GitHub

Und in U-Boot selber gibt es ein Befehl der ledon heißt und wenn ich den über UART ausführe geht die gelbe LED an ^^ es kann sein das solche Eigenschaften nicht von den SoC Hersteller sondern von den Plantinen Hersteller veeloren gehen, es kann wie gesagt sein. Selbst dann hätte ich noch die Möglichkeit über dem Device-Tree diese LED beispielsweise zu wissen über welchen GPIO das geht.

Und dann wird es interessant, sobald ich Quellcode → Ergebnis habe dann kann gelernt werden, Datenblätter über den SoC habe ich auch schon.

Mal sehen wo die Limits sind. Klar Raspberry ist einfacher, aber das Tablet, ist halt eine Herausforderung, kann auch zu schwer sein.

Hexeditorarbeiten sind mir gut gelegen, Hex, Bin, Dex, alles was ich unterscheiden zu weiß. Okteta ist nice. Wie du siehst hat die Bootloaderdatei am anfang Strings und dann keine, bzw welche die komprimiert aber dennoch sichtbar erahnbar waren.

Ziel ist es hinterher den Komprimierungsalgoritmus als EFL Bin für Linux über den Bin Bootloader laufen zu lassen und dann den Output evtl als Anleitung nehmen. ^^

Ich finde das Thema interessant, kann ruhig dauern.

 

[markus.tullius]

Hört sich interessant an. U-Boot ist schon eine feine Sache. Hört sich nach längerer Sache an.

Wenn du Dich auf Android austobst willst , wäre QT vielleicht etwas für dich. Es ist ein Framework für C++, und funktioniert auf mobile und embedded Device.
The future is written with Qt: Cross-platform software development for embedded & desktop

 

[Gelöschtes Mitglied 410096]

Ja, U-Boot ist richtig nett, bin Wolfgang Denk dafür dankbar und co. Habe mit ihm schon mehrere E-Mails geschrieben gehabt, bin erst später drauf gekommen das das Wort Meson und M1, M2, M3 und M6 meine Hardware Platform ist. Es soll nicht jedes Tablet ein eigenen nur für sich funktionierenden Bootloader oder Bootstrapcode haben.

Wenn dem so ich dann nice Sache, hat mir zwar einen Stein gelegt für meinen M805NC-MB Mainboard den Bootloader zu finden, aber jeder lernt dazu.

Kann es kaum abwarten einen Bootloader der opensource ist auf meinem Gerät mit Beachtung der Lizenzen zu bearbeiten. Erstmal fastboot, nand2usb, was den Nand am Computer einhängt, wäre nice.

Viele Grüße,

IntensoTab

 

[Gelöschtes Mitglied 410096]

Kann ein Moderator @swa00 beispielsweise den Beitrag hier drüber aktualisieren? Das was ich aktualisiert haben müsste ist die richtige Bezeichnung des Mainboards: M805NC-MB Es muss alles unter einem Dach sein, und die falsche Bezeichnung sollte gelöscht werden. Im Internet sieht man das Mainboard von dem Tab 814: M805NC-MB

Habe heute den Quellcode erfolgreich kompiliert für mein Tablet!!! War ja klar das es nicht Mainboard spezifisch ist. ;D

Danke!

Werde dann mal im IntensoForum weiter machen. Ich lerne sehr viel dann über C++/C und GCC und so Kompilern.
Halt das coole.

 

[Gelöschtes Mitglied 410096]

@swa00 ist der Beitrag #9

Hier findet man eine Webseite die sich damit beschäftigt das unteranderem Linux auf Intenso Tab 814 möglich macht. start [linux-meson]

Danke!