Hallo,
Ich kenne mich mittlerweile ganz gut in der Linux Welt aus. Raspberry
und Co kann ich sicher bedienen und habe mir für Boards auch schon
Images selbst kompiliert. Aber die Vorgänge tief im Inneren kenne ich
noch nicht.
Ich suche gute Literatur die einmal den kompletten Weg beschreibt: Also
Hardwareminimalanforderungen (hier kenn ich bisher nur MMU) und auch
alle Vorgänge auf Hardwareebene beschreibt (evtl inkl einfache
Grafikausgabe?). Dann, wie man ein passendes Image erstellt (Board
Support Package?). Wo die einzelnen Bootloader liegen und wie das System
letztlich startet.
Ich möchte ein vollständiges Linux, kein ucLinux.
Welche Architektur beschrieben wird, ist erstmal egal. ARM bevorzugt.
Einfache Mikrocontroller kenne ich: Atmega, C167, MSP430, also bitte
dahingehend keine Tipps.
Langfristiges Ziel ist es, auch mal selbst ein Board zu bauen. Der
Raspberry kann zwar als Referenz dienen, aber bei fertigen Images fehlt
mir z.B. der Lerneffekt
tu dir einen gefallen und mach kein design-in von der cpu, ram und
flash...
highspeed-designs von modernen CPUs macht man nicht nebenbei und sind
auch nicht gerade einfach zu debuggen.
nimm beispielsweise ein RPi Compute Module 3(L) und sei damit
glücklicher.
Der RPi is dermaßen schlecht dokumentiert, dass du dich genügend mit so
kleinen detail wie den DeviceTree Fragmenten usw ärgern darfst...
das gilt aber imho für alle diese module...
73
Hans W. schrieb:> das gilt aber imho für alle diese module...
Schön, wenns auch Alternativen gibt. Ich habe hier ein komplett
durchdokumentiertes Industriemodul in nem Gerät, und erstaunlicherweise
kostet es weniger als die RPi Mogelpackung.
Und warum gerade nicht uClinux? Das nimmt etwas an Komplexität betr.
virtueller Adressierung raus, und kann im Prinzip alles wichtige. Für
embedded/non multiuser-Desktop Systeme ist das "echte VM" Linux eher der
Overkill und bringt keine zusätzliche Sicherheit, sofern das System
einen sinnvollen Supervisor-Mode mit geschützten Systembereichen
bereithält. Das einzige Pro-Argument wäre ev. die
Memory-Defragmentierung, die einem zum Programmierpfusch mit excessiven
'new <Class>' verleiten könnte, aber die SL*B algos willst du dir nicht
gleich als erstes antun...
Was Literatur angeht: $LINUX_SRC/Documentation/*/*.txt. Sonst gibts IMHO
nix anwendbares. Es hilft nur "learning by doing" und im Source
rumgraben. Der ist je nach Hersteller von ganz unterschiedlicher
Qualität..
Vielen Dank für die vielen Antworten, trotzdem sind sie alle etwas
ernüchternd. Wie gesagt, klassische Mikrocontroller sind nicht das
Problem, aber bei Mikroprozessoren hört mein Verständnis auf.
Ich habe ein altes Navi mit SirfAtlas-SOC aufgeschraubt und begutachtet,
gearbeitet mit Raspberry Pi 3, Banana Pro und Beaglebone Black. Aber das
sind ja fertige Systeme, mal ist die GPU unter Verschluss, mal irgendwas
anderes.
Zurück in die Steinzeit und mit 8086 und 68000 oder wie sie alle heißen
möchte ich auch nicht.
Ein halbwegs moderner Prozessor und sein System inkl. OS, das von A bis
Z erklärt wird, das suche ich.
Ich weiß wirklich nicht, wo ich bei Learning-by-doing anfangen soll.
Tonika schrieb:> Ein halbwegs moderner Prozessor und sein System inkl. OS, das von A bis> Z erklärt wird, das suche ich.> Ich weiß wirklich nicht, wo ich bei Learning-by-doing anfangen soll.
Da:
Websuche: Xilinx Zynq
Websuche: xilinx zynq ubuntu
Hast Du schon die ersten 10000 Seiten Dokumentation für den ersten
Überblick durch?
https://eewiki.net/display/linuxonarm/Home;jsessionid=41B4AA0C5C5AFE8D05D900AB100E8A85
Da gibts paar ganz gute Tutorials.
Tendentiell sind das auch Architekturen (bis auf Allwinner), zu den man
Dokus findet. Ganz ehrlich: Wenn du verstehen willst wie du so ein
System bootest, wie es funktioniert, was der Ablauf ist dann bleib bei
SoCs von Xilinx oder Intel(bzw. Altera). Die kleinen Zynqs oder die
Cyclone V haben einen Cortex A9 drauf (ein recht "einfacher" HPS. Und
der große Vorteil: Sie sind seeeehr ausführlich dokumentiert (dürften so
zw. 10k und 15k sein). Da findest du alles: Über boot-flow, zu
vernünftigen Device Trees, zu fertigen Yocto Images. Und teuer sind die
Boards auch nicht.
P.S. so richtig Spass macht der scheiß sicher nicht!
Tonika schrieb:> Aber das> sind ja fertige Systeme, mal ist die GPU unter Verschluss, mal irgendwas> anderes.
Naja "fertig" sind die nur insoferne, dass irgendjemand dir die Probleme
mit DDR timing, high-speed routing, dem bootloader und dem BSP
abgenommen hat.
Ganz ehrlich, nimm dir ein CM3(l) und bau dir mal die Perepherie drum
herum die du haben willst. Allein schon eine RTC am I2C0 zum laufen zu
bekommen bedarf doch einiges an Doku-Wälzen (und neubau eines
DeviceTree-Fragments).
Ein i.MX6 mit vllt. noch PCIe macht das System noch wesentlich
komplexer...
Strubi schrieb:> Ich habe hier ein komplett> durchdokumentiertes Industriemodul in nem Gerät, und erstaunlicherweise> kostet es weniger als die RPi Mogelpackung.
Name, Hersteller/Bezugsquelle??? Ich habe das CM3 nur genommen weil es
preis/leistungsmäßig schwer zu schlagen ist..
73
Strubi schrieb:> Schön, wenns auch Alternativen gibt. Ich habe hier ein komplett> durchdokumentiertes Industriemodul in nem Gerät, und erstaunlicherweise> kostet es weniger als die RPi Mogelpackung.
In einem Forum erwartet man, dass man solches auch benennt. Ansonsten
klingt irgendwie nach Kindergarten, wo man die Zunge raustreckt und "ich
weiss was, was du nicht weisst." ruft.
Tonika schrieb:> Welche Architektur beschrieben wird, ist erstmal egal. ARM bevorzugt.Tonika schrieb:> Ein halbwegs moderner Prozessor und sein System inkl. OS, das von A bis> Z erklärt wird, das suche ich.
Vielleicht ist
Computer Organization and Design: The Hardware/Software Interface
von David A. Patterson und John L. Hennessy etwas für Dich.
Der Fokus liegt auf MIPS 32 Bit.
https://www.amazon.de/exec/obidos/ASIN/1558606041/$%7B0%7D#reader_1558606041
Mach die größte Wand in deiner Wohnung frei und fang an die Sourcen
deines Linux aufzumalen/auszudrucken und häng sie an die Wand.
Das gibt bestimmt einen guten Überblick :-)
Mehmet K. schrieb:> In einem Forum erwartet man, dass man solches auch benennt. Ansonsten> klingt irgendwie nach Kindergarten, wo man die Zunge raustreckt und "ich> weiss was, was du nicht weisst." ruft.
In einem Forum erwartet man eigentlich, dass nicht zuviel Werbung
gemacht wird. Am Schluss schmeisst jeder sein Lieblingsmodul mit in den
Topf und die Trollwiese ist komplett.
Aber sei's drum, ich schmeiss mal ein paar Favoriten rein:
- Phytec Module: Für die die ptx-Buildmethode mögen
- MT7688 basierte Module auf OpenWRT-Basis, z.B. bei seeedstudio zu
kriegen
- Arietta von ACME
Ich würde zum Test-Reverse-Engineering und Lernen den Linkit Smart Duo
(MT7688) empfehlen, da ist noch ein AVR für einfache GPIO-Ansteuerung
oder gar Echtzeitgedöns mit drauf. Und er ist so robust, dass man ihn
für industrielle Kleinserien brauchen kann.
Naja, ich weiß nicht welche Bezugsquellen du hast aber
Arietta-G25 kostet mit 128MB Ram 25.- (laut homepage)
ein CM3L von farnell mit 1GB Ram 24.-
Da nehme ich das in Kauf, dass ich Doku Unzulänglichkeiten in Kauf...
btw der 4-core A53 kommt mir bei OpenCV auch gelegen...
73
Und schon gehts los...
der TO wollte keine Preise wissen, sondern ich lese das so, dass er nach
guter Doku und einem vernünftigen BSP sucht. Xilinx hat's nach Jahren
jetzt endlich einigermassen geschafft, RPI foundation halt eher nicht.
Was sonst noch so als Einstieg zur IMHO zur besten (uC)linux-Doku
gehörte, aber inzwischen etwas verwaist und nicht up to date ist:
https://blackfin.uclinux.org/doku.php
Gut, dass du den Verlauf wieder in die richtige Bahn gelenkt hast.
Einige gute Ideen sind durchaus dabei, wobei Preise wirklich
uninteressant sind. Deine Idee des "Test-Reverse-Engineering" beherzige
ich, da ist mir dann der Preis auch vollkommen egal. Für ein sehr gutes
Buch würde ich ja auch sagen wir mal 50€ investieren.
Hans W. schrieb:> Da nehme ich das in Kauf, dass ich Doku Unzulänglichkeiten in Kauf...
Und was kostet das "Compute Module"? Das ist nicht das gleiche wie der
Raspberry Pi Zero ...
Tonika schrieb:> Für ein sehr gutes> Buch würde ich ja auch sagen wir mal 50€ investieren.
Von O'Reilly hatte ich mal was, frag mich bloss nicht, wie das hiess,
finde es auch nicht auf die schnelle. Da es recht schnell nicht mehr
aktuell war, ging's auf den Flohmarkt. Basierte in etwa auf der online
"Kernel Hackers Guide", die ist aber auch längst nicht mehr aktuell.
Ich denke mal, das erste was man so typischerweise bei einer Anpassung
(wenn nicht alles von der Stange schon fertig tut), anreissen muss, ist
ein eigener Kerneltreiber, für irgend ein SPI-Device oder sowas, wo man
sich mit dem inzwischen recht angewachsenen Framework vertraut machen
muss (aka im Source graben). Vielleicht ist es auch besser, mal mit
älteren 2.x Kernels anzufangen und sich dann erst auf den Device-Tree
overkill einzustimmen. Da ist das Xilinx-Zeug zwar gut dokumentiert,
aber nicht gerade im Sinne von 'keep it simple'.
Wenn GPL keine Option ist, fängt man ganz unten an, da hilft dann im
Prinzip so ein Kernel Hacker's Guide.
Und wenn man dann so im Dreck am Wühlen ist, braucht man einen guten
Debugger, um richtig nachvollziehen zu können, was im Kernel aufm
niedrigsten Level so alles schiefgehn kann. Da wird's dann bei den
meisten Systemen mal recht dünn oder teuer.
Rufus Τ. F. schrieb:> Hans W. schrieb:>> Da nehme ich das in Kauf, dass ich Doku Unzulänglichkeiten in Kauf...>> Und was kostet das "Compute Module"? Das ist nicht das gleiche wie der> Raspberry Pi Zero ...
Das Compute Module bei Farnell kostet 24.-
Das ist in etwa ein Pi Zero (wenn gleich mit dem Prozessor und Speicher
vom 3er) nur als "Dimm-PC" im SO-DDR2 Formfaktor mit 200 Pins ...
Strubi schrieb:> Vielleicht ist es auch besser, mal mit> älteren 2.x Kernels anzufangen und sich dann erst auf den Device-Tree> overkill einzustimmen. Da ist das Xilinx-Zeug zwar gut dokumentiert,> aber nicht gerade im Sinne von 'keep it simple'.
Ganz dumme idee... ohne Device-Tree und mit himmelaltem Kernel bekommst
du nur ein gefrickel hin das weder spaß macht, noch in modernen systemen
anwendbares Wissen schafft.
IMHO war das der beste Tipp zu Literatur:
Strubi schrieb:> Was Literatur angeht: $LINUX_SRC/Documentation/*/*.txt. Sonst gibts IMHO> nix anwendbares. Es hilft nur "learning by doing" und im Source> rumgraben. Der ist je nach Hersteller von ganz unterschiedlicher> Qualität..
Wenn du wirklich ein komplettes Board mit modernern Hardware machen
willst, dann kommst du eigentlich nicht mehr ohne eine NDA und
entsprechenden Stückzahlen and die Doku die du bräuchtest (vernünftige
ibis modelle, ...).
Also nimm ein Board das von min. 3 distributionen supported wird und
spiel dich mal mit dem init-system und bastel ein paar kleine
Kerneltreiber...
"Linux From Scratch" und die genannten distributionen helfen dir dann
dabei ein "eigenes Linux" zu bauen. Das artet aber derart schnell aus,
dass es wirklich keinen spaß mehr macht...
Gute quellen für internas einer distribution sind übrigens die diversen
Slackware und Gentoo foren/wikis/... sowie deren build scripts.
Die slackware SlackBuilds sind imho verständlicher als die Gentoo
scripts.
Achja, da gibts dann noch ein paar versteckte scripts:
ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-devtools/
bzw im speziellen
ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-devtools/minirootf
s/
Falls du immer noch mit einem chip auf einem eigenen pcb aggieren
willst... nimm zumindest sowas:
http://hackaday.com/2016/05/10/new-part-day-a-beaglebone-on-a-chip/
Ich habe boards in dieser liega regelmäßig beruflich am tisch... das
macht man nicht "nebenbei"...
73
Hans schrieb:> Ganz dumme idee... ohne Device-Tree und mit himmelaltem Kernel bekommst> du nur ein gefrickel hin das weder spaß macht, noch in modernen systemen> anwendbares Wissen schafft.
Jetzt schreibst du Unfug. Es dürfte in Fachkreisen hinreichend bekannt
sein, dass die 2.6.x Kernel in Embedded Systemen die robustesten und
langlebigsten Kernel im Einsatz sind. Der 'neuartige'
Device-Tree-Overhead hat nur unnötige Verkomplizierung mitgebracht und
macht die Systeme anfälliger. Das wird dann zum Gefrickel, wie man zur
Genüge in den Xilinx-Foren nachlesen kann. Lernen kann man an der
DeviceTree-Geschichte sonst nicht viel, höchstens wie man es NICHT
machen sollte. Meine Meinung, aber wir schweifen ab.
Hans schrieb:> Wenn du wirklich ein komplettes Board mit modernern Hardware machen> willst, dann kommst du eigentlich nicht mehr ohne eine NDA und> entsprechenden Stückzahlen and die Doku die du bräuchtest (vernünftige> ibis modelle, ...).
Wenn du mit "modern" einen HDMI-Ausgang für 4K-Abspulung meinst, dann
sei's drum. Aber gerade das brauchen viele nicht.
Mit einem Coremodul ist ein eigenes Linux-System in der Kleinserie zu
erschlagen, und in Stückzahlen gehts auch ohne NDA und Ibis, sogar mit
Kicad (BTDT). Wozu die Wichtigtuerei?
Ich sag nur immer wieder: Keep it simple.
Strubi schrieb:> Jetzt schreibst du Unfug. Es dürfte in Fachkreisen hinreichend bekannt> sein, dass die 2.6.x Kernel in Embedded Systemen die robustesten und> langlebigsten Kernel im Einsatz sind.
Habe da andere Erfahrungen u.A. mit dem i.Mx3 ... viele mögen auch kein
udev im embedded bereich.. ich sehe es als immense entlastung...
Strubi schrieb:> Wenn du mit "modern" einen HDMI-Ausgang für 4K-Abspulung meinst, dann> sei's drum.
Es geht mir da eher um's speicherinterface...
der iMx3er hatte ja nur 133MHz und das war schon problematisch in
einigen details...
DDR3 wie am zynq oder am RPi3 sind der nächste schritt... und den würde
ich nicht so nebenbei gehen wollen...
KiCad ist kein thema... habe ich übrigens auch für mein 4layer mainboard
für das CM3 verwendet... da ist aber nur USB2.0 drauf... und das
verkraftet schon einiges an missmatch.
Ebenso bist du beim über SDIO angebunden flash auf der sicheren
seite....
Wenn ich wirklich so low-level beginnen würde, dann mit einem i.Mx233...
ich habe mir sagen lassen, das wäre der so ziemlich am besten
unterstützte ARM im Mainstream kernel und doku wäre auch nicht schlecht.
Nur ob der noch zeitgemäß ist, das muss jeder für sich entscheiden.
ich bin auch anhänger von K.I.S.S (also nicht der band;)... daher würde
ich für ein 0815 embedded lösung keinesfalls einen zynq verwenden...
Vielleicht sind wirklich die olinuxino board von olimex das was der TO
sucht...
Doku, schematics, board und einzelkomponenten sind verfügbar (in
europa!)
73
